Telechat Review of draft-ietf-cuss-sip-uui-14
review-ietf-cuss-sip-uui-14-opsdir-telechat-korhonen-2014-03-27-00
Request | Review of | draft-ietf-cuss-sip-uui |
---|---|---|
Requested revision | No specific revision (document currently at 17) | |
Type | Telechat Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2014-03-25 | |
Requested | 2014-03-13 | |
Authors | Alan Johnston , James Rafferty | |
I-D last updated | 2014-03-27 | |
Completed reviews |
Genart Last Call review of -10
by Joel M. Halpern
(diff)
Genart Telechat review of -14 by Joel M. Halpern (diff) Secdir Last Call review of -10 by Scott G. Kelly (diff) Opsdir Telechat review of -14 by Jouni Korhonen (diff) |
|
Assignment | Reviewer | Jouni Korhonen |
State | Completed | |
Request | Telechat review on draft-ietf-cuss-sip-uui by Ops Directorate Assigned | |
Reviewed revision | 14 (document currently at 17) | |
Result | Has nits | |
Completed | 2014-03-27 |
review-ietf-cuss-sip-uui-14-opsdir-telechat-korhonen-2014-03-27-00
Hell'o I have reviewed the document "A Mechanism for Transporting User to User Call Control Information in SIP" (draft-ietf-cuss-sip-uui-14) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Standards Track Current draft status: IESG Evaluation IANA Review State: IANA - Not OK IANA Action State: None The draft is: Almost ready. Summary: This document defines a new SIP header field, User-to-User, to transport User to User Information (UUI) data during session establishment (and related extension mechanism). My review is done as a SIP illiterate, therefore I cannot really comment of the possible technical flaws (if any). My generic feeling is that the technicals are sound. There are no operational issues that I found. 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 ;) - Jouni