Document: draft-ietf-sip-connected-identity-04.txt
          Connected Identity in the Session Initiation Protocol (SIP)
Reviewer: Chisholm, Sharon (CAR:ZZ00)
Review Date:   2/21/2007
IETF LC End Date:  2/19/2007

Summary: This document is ready for publication, but has the following
nits that should be resolved.

Comments
---------

1. The abstract is a bit awkward. It would read better if it started
with "This document provides a means for that User Agent (UA) to supply
its identity to the peer UA by means of a request in the reverse
direction and for that identity to be signed by an Authentication
Service." instead of having this sentence buried in the middle. That the
typo in that sentence though with the 'for that'.

2. Some terms are capitalized and some are in quotes. Are these two
styles used consistently to mean two different things?

3. The document seems to have the habit of indenting paragraphs that
begin with the word 'Note'. This doesn't seem appropriate for an RFC. 

4. In section 2, third paragraph, the two commas should be deleted.

5. In section 3, third paragraph, last sentence has 'to to'.

6. In section 3, fifth paragraph, has the sentence 'It is assumed that
deployed proxies will already be able to tolerate a change of URI, since
this has been expected for a considerable time.' which doesn't sound
like a standards-track RFC to me. A number of the sentences that follow
in this section are also a bit loose.

7. In each of the subsections of 4, the introduction sentence is
incomplete. Text along the lines of 'is as follows:" should be added.

8. In section 4.3, second paragraph, replace "that last indicated in the
>From header field " with "that last identity indicated in the From
header field" to ensure no ambiguity.

9. In section 4.4.1, the second paragraph is indented for no apparent
reason.

10. In section 4.4.1, third paragraph, refers to section 4.4.2 but also
refers to RFC 3261. It should be clarified whether that section number
is in this document or the other RFC.

11.  In section 4.4.2, second paragraph, it says "if the UA sends a 2xx
response", but what if it doesn't? Are there no expectations then?

12. In section 4.4.5, second paragraph, "Note that when UAs conform with
this specification the Authentication Service will normally be able to
authenticate the sender of a request as being the entity identified in
the From header field and hence will be able provide a signature for
this identity.". It wasn't clear whether this was defining a requirement
or making a prediction about what other features might be supported by
the implementation.

13. In section 4.7, the proxy itself advertises the from-change feature?
If so, this could be stated more clearly and earlier in the section. The
second paragraph is not parsable.

14. In section 6, all the instructions to IANA are one-time. Should the
RFC editor then delete the section before publishing?

15. In section 7, third paragraph, it wasn't obvious to me how this was
a security consideration.