I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments you may receive. Document: Connected Identity in the Session Initiation Protocol (SIP) 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. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
