A Mechanism for Transporting User-to-User Call Control Information in SIP
draft-ietf-cuss-sip-uui-17

[Ballot comment]
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.

[Ballot comment]
-- 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.

[Ballot comment]
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

[Ballot discuss]
4:

  The "purpose" header field parameter identifies the package
  which defines the generation and usage of the UUI data for a
  particular application.

I think you need to add something like: "The value of the 'purpose' parameter is the package name, as registered in the uui-packages sub-registry defined in section 6.3." It took me a while to figure out that that's what you intended. (I *think* that's what you intended.)

  For the case of interworking with the ISDN
  UUI Service, the ISDN UUI Service interworking package is used.  If
  the "purpose" header field parameter is not present, interworking
  with the ISDN UUI Service MUST be assumed.

This creates a hard dependency on draft-ietf-cuss-sip-uui-isdn, since you are making ISDN the default. You'll need to move that document to Normative References if you do that. I think it's best not to do that and instead strike the sentence and instead say that 'purpose' is REQUIRED.

5:

  UUI packages defined using this SIP UUI mechanism MUST follow the
  "Standards Action" guideline as defined in [RFC5226] and publish a
  standards track RFC which describes the usage.

This seems bogus. First of all, "Standards Action" is a registration guideline, not a use guideline, so this MUST seems completely wrong. If I want to use a private-use package I see absolutely no interoperability reason I should be disallowed from doing so. See comments on section 6 below for more on the choice of the guideline.

6.3:

"Standards Action" seems like complete overkill. I would like to hear an explanation of why First Come First Served (FCFS) is not appropriate for these packages. If I get a package I don't understand, I'm going to ignore it, so if you want to send (and register) one that is not already defined, I don't see why you can't just register it. We know that anything more than FCFS does actual interoperability damage by encouraging the community to do all sorts of unregistered extensions. What is the problem with doing these things as FCFS, or maybe "Expert Review"?

6.4:

I don't understand why this needs an IANA registry at all. As far as I can tell, content is entirely dependent on the package definition. That means that if I define "foo" content for my package, you could define "foo" content for your package and there will be no problem with the two names colliding. Why do you need a registry for these? Is there going to be content that is package-independent? If so, you may want to explain what those would be like in section 4.

[Ballot comment]
Abstract: s/The rules which apply for a specific application/The syntax and semantics for the UUI data used by a specific application/

1:

-  s/A mechanism is defined/It defines a mechanism/

- I don't understand what the following means:

  Note that in most cases, there
  is an a priori understanding between the UAs in regard to what to do
  with received UUI data.

Please explain.
 
3: This section should be an appendix.

4:

- "MUST be assumed" does not help an implementer. Which end is doing the assuming? What is the implementation supposed to do once it makes this "assumption".

Here are my attempts to fix. Feel free to edit:

OLD
  If the "purpose" header field parameter is not present, interworking
  with the ISDN UUI Service MUST be assumed.
NEW
  If the "purpose" header field parameter is not present, the sending
  implementation is indicating that it interworks with the ISDN UUI
  Service and the receiving implementation MUST use the ISDN UUI
  Service.
END
 
OLD
  If not present, the content MUST be assumed to be the default defined
  for the package.
NEW
If not present, the default content defined for the package MUST
be used.
END

OLD 
  If the "encoding" header
  field parameter is not present, the encoding MUST be assumed to be
  the default defined for the package.
NEW
  If the "encoding" header field parameter is not present, the default
  encoding defined for the package MUST be used.
END

However, see DISCUSS points.

- "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

4.2: Can we strike most of this section and simply refer to RFC 4648? Essentially, say "This document defines the hex encoding of UUI data. When the value of 'hex' is used in the 'encoding' paramater of a header field, the data is encoded using Base16 encoding according to section 8 of RFC 4648.  The hex-encoded value is normally represented using the 'token' construction from RFC 3261, although the 'quoted-string' construction is permitted, in which case the quotes MUST be ignored." Then in section 6.5, set the description to "Base 16 encoding" and make the reference RFC 4648, section 8.

8: This section should not be a numbered section.

[Ballot comment]
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.

[Ballot discuss]
No objection to the document in general -- just a small point that should be easy to fix:

-- 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?

[Ballot comment]
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

[Ballot discuss]

I have a bunch of should-be-easily-fixed things to chat about...

(1) section 3: Would I be wrong to claim that SIP S/MIME
stuff being mythical means that REQ 13 is not met in any
meaningful sense? (REQ 14 is sort of met via hop by hop TLS
I guess.) I suggest you just say that SIP end-to-end data
integrity is practically non existent so REQ 13 is not in
fact met. You do recognise this reality in section 7, but
nonetheless the claim that REQ-13 has been met isn't really
tractable.

(2) 4.2: this says BEEF == beef but what if real data
integrity had been provided, which is canonical, upper or
lower case? Picking one now will mean that when REQ-13 does
get met, things will work as expected.  (Or say that there
no c14n and that case mapping MUST NOT be done.) Had REQ-13
really been met you would have had to address this already
btw.

(3) 4.3, last para: Why does the User-to-User parameter in a
History-info field functionality "win" over a privacy
protecting proxy or B2BUA? Sounds to me like a SHOULD NOT
that will not be honoured. Wouldn't it be better to simply
note that a B2BUA might break the User-to-User stuff and
leave it at that?

(4) section 5: what is an "overriding privacy issue"? How
will a future IETF LC and IESG decide that? (The RPC thing
is also odd, can't anything be that?)

[Ballot comment]


- Section 7 could note the potential uses of this as a
covert channel (for a dishonest user) and/or as yet another
way that an application could spy upon a user (e.g. embed
PII or the fact that the user also has a competitor's SIP UA
installed as well as yours).

- I'm not clear what q.931 and q.763 are for. Would I
be upset if I did know? :-)

- 4.1: is "User-to-User" case sensitive? Looks like it is to
me, so just checking.

- 4.1: saying >1 MAY be present is not IMO as good as saying
that implementations MUST support >1 (you're using a 2119
MAY to say MUST there really I think)

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has reviewed [draft-enter-here].  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there are six actions which we must complete.

First, in the Header Fields subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml

a new Header Field will be registered as follows:

Header Name: User-to-User
Compact:
Reference: [ RFC-to-be ]

Second, in the Header Field Parameters and Parameter Values subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml

three new parameters will be registered as follows:

Header Field: user-to-User
Parameter Name: encoding
Predefined Values: hex
Reference: [ RFC-to-be ]

Header Field: user-to-User
Parameter Name: content
Predefined Values:
Reference: [ RFC-to-be ]

Header Field: user-to-User
Parameter Name: purpose
Predefined Values:
Reference: [ RFC-to-be ]

Third, a new subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml

is to be created called the "UUI Packages" registry.  The new subregistry will be maintained through "Specification Required" as defined by RFC 5226.  The descriptive text for the UUI Packages registry will be: "UUI Packages provides information about the usage of the UUI data in a User-to-User header field [ RFC-to-be ].

The layout of the registry is as follows:

+------------+------------------------------------------+-----------+
| Package    | Description                              | Reference |
+------------+------------------------------------------+-----------+

We understand that there are no initial registrations in this new subregistry.

Fourth, a new subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml

is to be created called the "UUI Content" registry.  The new subregistry will be maintained through "Specification Required" as defined by RFC 5226.  The descriptive text for the UUI Packages registry will be: "UUI Content provides information about the content of the UUI data in a User-to-User header field [ RFC-to-be ].

The layout of the registry is as follows:

+------------+------------------------------------------+-----------+
| Content    | Description                              | Reference |
+------------+------------------------------------------+-----------+

We understand that there are no initial registrations in this new subregistry.

Fifth, a new subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml

is to be created called the "UUI Encoding" registry.  The new subregistry will be maintained through "Specification Required" as defined by RFC 5226.  The descriptive text for the UUI Encoding registry will be: "UUI Encoding provides information about the encoding of the UUI data in a User-to-User header field [ RFC-to-be ].

The layout of the registry is as follows:

+------------+------------------------------------------+-----------+
| Encoding  | Description                              | Reference |
+------------+------------------------------------------+-----------+

There is a single initial registration in this new subregistry as follows:

Encoding: hex
Description: The UUI data is encoded using hexadecimal
Reference: [ RFC-to-be ]

Sixth, in the Option Tags subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/sip-parameters.xml

a new Option Tag will be registered as follows:

Name: uui
Description: This option tag is used to indicate that a UA supports and understands the User-to-User header field.
Reference: [ RFC-to-be ]

We understand these six actions to be the only ones required to be
completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Mechanism for Transporting User to User Call Control Information in SIP) to Proposed Standard


The IESG has received a request from the Call Control UUI Service for SIP
WG (cuss) to consider the following document:
- 'A Mechanism for Transporting User to User Call Control Information in
  SIP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  There is a class of applications which benefit from using SIP to
  exchange User to User Information (UUI) data during session
  establishment.  This information, known as call control UUI data, is
  a small piece of data inserted by an application initiating the
  session, and utilized by an application accepting the session.  The
  rules which apply for a specific application are defined by a UUI
  package.  This UUI data is opaque to SIP and its function is
  unrelated to any basic SIP function.  This document defines a new SIP
  header field, User-to-User, to transport UUI data, along with an
  extension mechanism.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui/ballot/


No IPR declarations have been submitted directly on this I-D.