I've re-reviewed draft-ietf-sipping-nat-scenarios. I have several comments below, but I'd like to start with an observation and a question. The draft started out as set of example flows. Along the way, some things that we would like implementations to do got added as normative requirements, leading to treating this as a BCP. Trying to do both of those at the same time has made it hard to read either. Would the implementation community be better served with either two very clearly defined sections, or even two different drafts? Either way, some editing of the introduction and the early paragraphs of sections to make it clearer what's intended to be normative and what's examples would help. For the examples part - there have been threads on mmusic suggesting even more examples be added to this draft (to cover ice-tcp for example). I would recommend that we make sure this draft is clear that it is not intended to be comprehensive, and ship what we have. More drafts with more examples can follow. That would be easier to do if the draft were split. On the part of the draft that is a BCP, we have the following 2119 requirements (the obvious missing ones in each sequence were the boilerplate from the terminology section) MUST-2: When operating behind a NAT and using the 'latching' technique described in [I-D.ietf-mmusic-media-path-middleboxes], SIP user agents **MUST** implement 'Symmetric RTP/RTCP'. MUST-3: For the response to successfully traverse the NAT, all of the conventions defined in RFC 3581 [RFC3581] **MUST** be obeyed. S-2: Even if the SIP Outbound draft is not used, clients generating SIP requests **SHOULD** use the same IP address and port (i.e., socket) for both transmission and receipt of SIP messages. Rec-2: It is **RECOMMENDED** that SIP compliant entities follow the guidelines presented in this section to enable traversal of SIP signaling through NATs. Rec-3: Usage of [RFC5626] is **RECOMMENDED**. Rec-4: A TURN service will almost always provide media traffic to a SIP entity but it is **RECOMMENDED** that this method would only be used as a last resort and not as a general mechanism for NAT traversal. Rec-5: Interactive Connectivity Establishment (ICE) is the **RECOMMENDED** method for traversal of existing NATs if Symmetric RTP and media latching is not sufficient. Rec-6: An example is included for both STUN and ICE with ICE being the **RECOMMENDED** mechanism for media traversal. Rec-7: For this reason, ICE is **RECOMMENDED** over the mechanism described in this section. Rec-8: The **RECOMMENDED** mechanism for traversing all varieties of NAT is using ICE, as detailed in Section 4.2.3.3. Remember that BCPs are stronger than Standards when we are talking about protocols - they bypass the standards ladder and go immediately to "full and immediate instantiation". Given that, are the recommendations above appropriate? MUST-2 is a good example of a requirement that probably is, and it's what makes this a BCP instead of an informational document - we're truly saying that _RIGHT NOW_, _ALL_ SIP user agents MUST implement symmetric RTP/RTCP. (If you don't think that's the right thing to require, speak now). MUST-3 reads oddly - I suspect this sentence (part of an example flow) would be better stated without 2119 language. Similarly REC-2 is inappropriate - it says "implementations SHOULD conform to the following MUSTs/SHOULDs, etc." I think, instead, that we're just trying to say "the following is a good idea", and natural language should do the job. Would it be possible to more concisely say use ICE, and say it once? ---- Some nits for consideration: Abstract: s/aims to provide/provides/ The phrase "hosted NAT traversal" is not defined here, in 5853, or in draft-ietf-mmusic-media-path-middleboxes. I suggest rephrasing the paragraph mentioning it to "The use of non-TURN based media intermediaries is not considered in this document. More information can be obtained from [RFC5853] and [I-D.ietf-mmusic-media-path-middleboxes]." The fourth paragraph of the Problem Statement should be clear that it is talking about baseline 3261 behavior. I suggest replacing "Normal SIP response routing over UDP" with "SIP response routing over UDP as defined in RFC3261 without extensions" s/the SIP Outbound draft/RFC5626/g (or use "the SIP Outbound mechanism" instead) The use of "exonerates" in 5.1.1.1 is correct, but likely to be very hard to translate for implementers whose primary language is not English. The 'received' Via mechanic is not specific to UDP - see section 18.2.1 of 3261. The examples in 5.1.1.2 have bare IP addresses in their via, so adding a received parameter is not required, but it would be better for the prose to not imply it would only appear in a UDP Via. At the end of 5.1.4.1, it would help to call out 5626 explicitly rather than just saying 3263 is overridden without saying why The references should be updated - some of them have been published as RFCs _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
