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