A Mechanism for Transporting User-to-User Call Control Information in SIP
Summary: Has enough positions to pass.
Note: This ballot was opened for revision 14 and is now closed.
Alissa Cooper Yes
Jari Arkko No Objection
Alia Atlas No Objection
( Richard Barnes ) No Objection
Benoit Claise No Objection
Comment (2014-03-25 for -14)
As mentioned by Jouni in his OPS DIR review: More on the document nits.. ** Generic: o The document assumes that the reader knows a bunch of related acronyms (like ISDN, PSTN, UA, SIP, URL, URI, MIME, S/MIME, ISUP, IPsec etc). I urge them to be expanded on the first occurrence. o Mixed use of references. Pick one style. Currently there are: - bla bla in RFC 1234 bla bla - bla bla in RFC 1234 [RFC1234] bla bla - bla bla in [RFC1234] bla bla. Be consistent with the referencing style. o Use of RFC 2119 language. One should check when use "must" or "MUST" etc, since currently use of those keywords are mixed even in the same sentence. Also, in places "shall" is used where I think "SHALL" would be more appropriate. Anyway, do the authors try to indicate a difference between "shall" and a "must"? In places a sentence using "shall" is immediately followed by other sentence using "MUST". Be consistent with the requirements language use. o One thing confuses me slightly though. In Section 3 it is stated that proxies and other intermediates are not expected to understand UUI data etc. However, later in Sections 4.3 the text about border elements (regarding proxies and B2BUAs) indicate that User-to-User and UUI data should be understood under a specific context. Maybe this could be clarified in Section 3..? ** Section 1: "This mechanism was designed to meet the use cases, requirements, and.." ^^^^^ It is unclear to what "this" refers to, specifically since the "this" word begins a new paragraph. "The mechanism is a new SIP header field, along with a new SIP option tag. The header field carries the UUI data, along with parameters.." Which header and which option? ** Section 4.1: "The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 and extends RFC 3261 (where token o RFC 5234 defines an ABNF not BNF. o Should it be "updated RFC 3261" and should that also be reflected in the document boiler plate? "[RFC3515] or the 3xx to the INVITE SHOULD support the UUI mechanism. ^^^^^ o Should it be "3xx response" ? "Here is an example of an included User-to-User header field from the redirection response F2 of Figure 2:" o Figure 2 in where? This document does not have any caption with "Figure". ** Section 5: "3. User Agents (UAs) are the generators and consumers of the UUI data. Proxies and other intermediaries may route based on the.." ^^^^^^^^^^^ o May route what? Requests? Responses? "into a request or response. (The default is one per encoding.)" ^^^ ^^^ o Why parenthesis? Consider restructuring the sentence. ** Section 6: o To my understanding RFC2119 language is not appropriate for IANA considerations. ** Section 7: "User to user information can potentially carry sensitive information.." ^^^^^^^^^^^^ o "User-to-User" since the rest of the document uses that convention. "using S/MIME or IPSec can be used, as discussed in the review of.." ^^^^^^ ^^^^^ o References missing. ** Section 8: "described: MIME body and URI parameter transport." ^^^^^ o References missing. ** Section 8.2: "However, the CUSS working group believes, consistent with its charter, that SIP needs to have its own native UUI data transport mechanism. It is not reasonable for a SIP UA to have to implement.." o Do not refer to a WG and a charter.. both of these are moving targets and will change or vanish during time. ** Section 8.3: "not clear how this mechanism could meet REQ-9." and "As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, although the authors do not have a specific mechanism to propose. Meeting REQ-3 is problematic, but not impossible for this mechanism. However, this mechanism does not seem to be able to meet REQ-9." o It is not clear which requirement defined or discussed where this references.. Add references in which document I can find these requirements. ** Section 8.4: "The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and REQ-11. It is possible the approach could meet REQ-12 and REQ-13. The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and REQ-14." o Same comment as for Section 8.3. ** Section 10: o I do not recall ever seen references starting with Informative instead of Normative. I guess this is ok though
Spencer Dawkins No Objection
( Adrian Farrel ) No Objection
Comment (2014-03-13 for -14)
The only solution in Section 7 that makes just the UUI opaque to inspection by transit nodes seems to be the first option... One model treats the SIP layer as untrusted and requires end-to-end integrity protection and/or encryption. This model can be achieved by providing these security services at a layer above SIP. In this case, applications are encouraged to use their own integrity and/or encryption mechanisms before passing it to the SIP layer. This mechanism appears to require that the source and destination applications have a security association of some sort. The reality of this is that every pair of applications in the SIPiverse have to maintain SAs of their own construction. There would appear to be two options not covered here: 1. The local SIP speaker is responsible for maintaining an SA with the remote speaker and for encrypting just the UUI (maybe this is what the second option is saying, but it also says "this will not work in practice"). 2. SIP is enhanced to provide key exchange for the applications. I don't for a moment propose that this document should be blocked on this issue, but I would like to hear that some mechanism is being developed to provide protection for this data.
Stephen Farrell (was Discuss) No Objection
Comment (2014-04-08 for -15)
Thanks for handling my discuss points and comments.
Brian Haberman No Objection
Joel Jaeggli No Objection
Comment (2014-03-24 for -14)
This is not a discuss but I'd observe that I'm a little dissatisfied with the security considerations section. Of the options enumerated there, option three is clearly the one frequently employed. It seems like the least adequate, and I don't know how sip moves out of that space into actually protecting data etierh inband or by wrapping the whole thing in a consistent fashion.
Barry Leiba (was Discuss) No Objection
Comment (2014-04-03 for -15)
-- Section 4.1 -- UAs SHOULD ignore UUI data from packages or encoding that they do not understand. That SHOULD seems odd. What else could they possibly do with things they don't understand? It would seem that trying to make sense of something I fundamentally don't understand could open me up to all sorts of problems, including security or privacy exposures, no? If it's a SHOULD, then under what conditions might one not ignore them, and what would one then do? UPDATE: Version -15 changes "SHOULD" to "SHALL", addressing this issue. Thanks very much for considering my comment.
Kathleen Moriarty No Objection
Comment (2014-03-21 for -14)
I support Stephen Farrell's position and have the following additional comments: In the Security Considerations Section: On privacy - suggest the following words, change from: User to user information can potentially carry sensitive information that might require privacy or integrity protection from third parties that may wish to read or modify the UUI data. To: User to user information can potentially carry sensitive information that might require confidentiality protection for privacy or integrity protection from third parties that may wish to read or modify the UUI data. Third paragraph: IPSec should be IPsec
( Pete Resnick ) (was Discuss) No Objection
Comment (2014-04-30 for -16)
Thanks for addressing some of my comments, especially the Discuss comments. I understand that the WG is using "Standards Action" as a placeholder for the moment until a different kind of registration mechanism is worked out. I think that's OK. You did miss some of the earlier comments for which you agreed to make changes, and there are a couple of others that I think would clarify, but I'll leave these for the WG and Alissa to work out: 1: I'm not sure what the following sentence adds: Note that in most cases, there is an a priori understanding between the UAs in regard to what to do with received UUI data. I'd delete it, but maybe I just don't understand why this is important to mention. 3: I think this section would work better as an appendix. 4: OLD If the "purpose" header field parameter is not present, interworking with the ISDN UUI Service MUST be assumed. NEW The default value for the "purpose" header field is "isdn-uui" as defined in [I-D.ietf-cuss-sip-uui-isdn]. If the "purpose" header field parameter is not present, the ISDN UUI MUST be used. END - "This mechanism SHOULD NOT be used to convey a URL or URI" Why not? And (assuming there's a good reason), why doesn't this say MUST NOT? What are the exceptions? It would be nice to state them here. 4.1: OLD RFC 3261 (where token and quoted-string are defined). NEW RFC 3261 (where token, quoted-string, and generic-param are defined). END OLD The rules for how many User-to-User header fields of each package may be present in a request or a response are defined for each package. NEW Each package defines how many User-to-User header fields of each package may be present in a request or a response. END 8: This section should not be a numbered section. The RFC Editor will likely fix this, but if you do another edit, might as well fix it.