Sharon, Thanks for your comments. See my responses below. Where I have made changes to the document these will be in the next version, whenever that should be required (depends on chairs / ADs I guess).
John > -----Original Message----- > From: Sharon Chisholm [mailto:[EMAIL PROTECTED] > Sent: 21 February 2007 16:16 > To: [email protected] > Cc: Elwell, John; Dean Willis; Keith Drage; Cullen Jennings > Subject: Gen-art review of draft-ietf-sip-connected-identity-04.txt > > 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'. [JRE]The abstract now reads: "This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request 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. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP)." I didn't understand your bit about the typo, but hopefully that too is fixed. > > 2. Some terms are capitalized and some are in quotes. Are these two > styles used consistently to mean two different things? [JRE]I am not sure what your refer to. The items in quotes are the new option tag "from-change" (I think the convention in SIP documents is to put option tags in quotes) and the expressions "connected identity" and "response identity", which are informal terms (maybe I could clarify by saying 'commonly called...'). Capitalised things seem to include keywords like "MUST" and SIP method names like "UPDATE", which are always capitalised. Did you have any other examples in mind? > > 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. [JRE] What is the appropriate formatting? I have seen indentations used in this way in a number of other RFCs, e.g., RFC 3261, RFC 4474, RFC 3841. Should I just remove the indent? > > 4. In section 2, third paragraph, the two commas should be deleted. [JRE] I regarded this as descriptive, rather than defining, and therefore commas are appropriate. Let me know if you disagree stongly. > > 5. In section 3, third paragraph, last sentence has 'to to'. [JRE] OK > > 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. [JRE] Standards track RFCs do not need to contain only normative statements and, I believe, can give reasons for things. I guess I could make this particular sentence a note, but in view of your comment above about notes I await your feedback. Or is it just the clause "since this has been expected for a considerable time", which I guess could be deleted if that would help. > A number of the sentences > that follow > in this section are also a bit loose. [JRE] Without specifics I am not sure what to change. > > 7. In each of the subsections of 4, the introduction sentence is > incomplete. Text along the lines of 'is as follows:" should be added. [JRE] I don't understand - there are no incomplete sentences there, apart from the sub-section header, which are not intended to be sentence. Can you give me an example of an offending sentence? > > 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. [JRE] Changed to "the last identity indicated in the From header field". > > 9. In section 4.4.1, the second paragraph is indented for no apparent > reason. [JRE] This is supposed to be a note (additional information), but I neglected to prefix it with "Note". I await you response on 3 above. > > 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. [JRE] "of this document" added. > > 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? [JRE] Good catch. I have added "If any other final response is sent the UA MUST NOT update the remote URI for this dialog." > > 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. [JRE] It is just making a prediction (since if the UA does not conform to this specification the Authentication Service will not in general be able to perform this authentication). It is not clear what change, if any, I should make. > > 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. [JRE] No, there is not intention to state that the proxy advertises this feature. Perhaps I should change the last bit to say "Supported: from-change is indicated in the received dialog forming request." Does the addition of the word "received" help? > > 14. In section 6, all the instructions to IANA are one-time. > Should the > RFC editor then delete the section before publishing? [JRE] I don't think it is common practice to delete this information. For example, see RFC 4474, RFC 4538, RFC 4488. > > 15. In section 7, third paragraph, it wasn't obvious to me > how this was > a security consideration. [JRE] It is a security consideration because this RFC does not protect against a rogue proxy that incorrectly retargets a request to a particular destination. > > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
