Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-11

Note added 'OLD
parsing and interpreting "isdn- interwork" the same way as "isdn-uui" when receiving messages.

NEW
parsing and interpreting "isdn-interwork" the same way as "isdn-uui" when receiving messages.'

[Ballot discuss]


(1) section 14 says: "As this capability is defined to
interwork with the ISDN, if the ISDN forms part of the route,
any usage needs to assume that the security level of the ISDN
is the highest level of security available." That makes no
sense to me. I think what you mean is that ISDN security isn't
great so don't expect too much, and that'd be fine.  However if
what you mean is "ISDN security isn't great, so there's no
point in doing better for SIP" then I'd disagree. I can't tell
if you mean that latter thing though.

(2) I expected to see some listing of known security and
privacy issues with the ISDN services (or a reference to
something on that).  Without that, how can a SIP developer or
deployer know the level of sensitivity of these headers? For
example, can I only use the ISDN service or innocuous stuff or
could e.g. banking PINs be included? Can you explain why its ok
to not include any such discussion?

[Ballot comment]
Scott Brim made the following comment in his Gen-ART review:

A new sentence needs reworking:

"If an interworking point is reached, and the limitations of the ISDN (see section 3.1) are not met, then the UUI data will not be transferred, although the SIP request will otherwise be interworked, rather than have the interworking point attempt to resolve the non- compliance with the limitations of ISDN."

I suggest splitting it into two sentences, something like:

"If an interworking point is reached, and the limitations of the ISDN (see section 3.1) are not met, then the UUI data will not be transferred, although the SIP request will otherwise be interworked. This is  rather than have the interworking point attempt to resolve the non- compliance with the limitations of ISDN."

[Ballot comment]
In this text from 10.  Considerations for ISDN interworking gateways

  ISDN interworking gateways MUST support only the "isdn-uui" package
  on dialogs that are interworked.

I'm confused as to whether this is saying that this package is only supported on dialogs that are interworked, or saying that this is the only package gateways support on dialogs that are interworked. Could you help me understand what's being intended?

Either way - is this saying only if the gateway is doing interworking, as opposed to encapsulation?

[Ballot comment]
No response or discussion needed for any of this; just please consider:

-- Section 2 --

  This usage is not limited to scenarios where interworking will occur.
  Rather it describes a usage where interworking is possible if
  interworking is met.

Say what?

-- Section 6 --

  The general principals of this package of the UUI mechanism are
  therefore as follows:

"principles"

-- Section 13 --
I'll make my usual comment that it's always seemed inappropriate to me to specify an individual, usually the primary editor of the document, as the contact for registrations done in working group documents.  As this seems to be the norm in RAI documents (and has been done in other areas as well, including APP), that's all I'll say: just please consider specifying a role (such as rai-ads@tools.ietf.org) instead.No response or discussion needed here.

-- Section 15 --

  Joanne McMillen was a major contributor and co-author of earlier
  versions of this document.

We are allowed to use a "Contributors" section, which goes before the "Acknowledgments" section, to identify especially significant contributors, and such a section is particularly used to identify former authors.  Might it be appropriate to do that here?

[Ballot comment]
7:

                                            The UAC SHOULD set the
  "purpose" header field parameter to "isdn-uui".  Non-inclusion of the
  "purpose" header field parameter is permitted, but this is primarily
  to allow earlier implementations to support this package.
 
It seems to me that SHOULD ought to be MAY, and you can strike the second sentence. It is already the case that draft-ietf-cuss-sip-uui defaults to isdn-uui, so there is no harm in not including it.

8:
 
  When sending UUI for the ISDN package, the UAS SHOULD set
  the User-to-User "purpose" header field parameter to "isdn-uui".
  Non-inclusion of the "purpose" header field parameter is permitted,
  but this is primarily to allow earlier implementations to support
  this package.

Same comment as above.

[Ballot comment]
Thanks for addressing the SecDir review comments.  I just have one additional comment that is non-blocking as I would not expect this draft to address security concerns, but rather just make sure it is clear they are handled elsewhere.  I think the last paragraph of the Security Considerations section makes that point clear enough.

I had a little trouble reading the second paragraph of the Security Considerations section, and it's too long.  I'd suggest rephrasing it.  Since you are talking about information that has higher security requirements, I'd just say it needs a higher level of protection in that case rather than using the word may.  If it doesn't need a higher level of protection, this sentence doesn't apply to their decision process.  How about...

Change from:
  Information that might otherwise reveal private information about an
  individual, or where a level of authenticity needs to be guaranteed,
  may need a higher level of protection, and may indeed not be suitable
  for this package, particularly taking into account the statement in
  the following paragraph.
To:
  Information that might otherwise reveal private information about an
  individual or where a level of authenticity needs to be guaranteed,
  requires a higher level of protection and may not be suitable
  for this package.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-cuss-sip-uui-isdn-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that at least one of the actions requested in the IANA Considerations section of this document is dependent on the approval another Internet Draft.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in a registry to be created by the approval of the document draft-ietf-cuss-sip-uui-13, called UUI packages, a new value is to be registered as follows:

Value: isdn-uui
Description: The associated application is being used with constraints suitable for interworking with the ISDN user-to-user service, and therefore can be interworked at ISDN gateways.
Reference: [ RFC-to-be ]
Contact:

Second, also in a registry to be created by the approval of the document document draft-ietf-cuss-sip-uui-13, called UUI Content Parameters, a new value is to be registered as follows:

Value: isdn-uui
Description: The associated contents conforms to the content associated with the ISDN user-to-user service. In the presence of the "purpose" header field parameter set to "isdn-uui" (or the absence of any "purpose" header field parameter) this is the default meaning and therefore need not be included in this case.
Reference: [ RFC-to-be ]
Contact:

Third, in the iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4) tree of the Media Feature Tags - iso.org.dod.internet.features (1.3.6.1.8) registry located at:

http://www.iana.org/assignments/media-feature-tags/

A new value is to be registered as follows:

Decimal: [ TBD-at-registration ]
Name: sip.uui-isdn
Description: This media feature-tag when used in a Contact header field of a SIP request or a SIP response indicates that the entity sending the SIP message supports the UUI package "uui-isdn".
Reference: [ RFC-to-be ]

IANA understands that these are the only actions that are 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:  (Interworking ISDN Call Control User Information with 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:
- 'Interworking ISDN Call Control User Information with 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 2014-05-14. 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


  The motivation and use cases for interworking and transporting ITU-T
  DSS1 User-user information element data in SIP are described in the
  "Problem Statement and Requirements for Transporting User to User
  Call Control Information in SIP" document.  As networks move to SIP
  it is important that applications requiring this data can continue to
  function in SIP networks as well as the ability to interwork with
  this ISDN service for end-to-end transparency.  This document defines
  a usage (a new package) of the User-to-User header field to enable
  interworking with this ISDN service.

  This document covers the interworking with both public ISDN and
  private ISDN capabilities, so the potential interworking with QSIG
  will also be addressed.

  The package is identified by a new value "isdn-uui" of the "purpose"
  header field parameter.




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

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


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

(1) What type of RFC is being requested?
    A Standards Track RFC.

    Why is this the proper type of RFC?
    The draft standardizes SIP headers, parameters and their
    interpretation by SIP actors.  As such, a Standards Track
    is the proper type of designation.

    Is this type of RFC indicated in the page header?
    Yes, it is.

(2) Technical Summary:
    The move of communications networks to SIP does not ameliorate
    the need to support use cases for interworking and transporting
    legacy PSTN-related information in SIP.  This document defines
    a package and associated semantics that allows SIP endpoints to
    exchange information related to the ISDN UUS1 service.

    Working Group Summary:
    A WGLC was held from Nov-13-2013 to Nov-29-2013.  As part of the
    WGLC, reviews were performed by WG members (Andrew Allen, Atle
    Monrad and Celine Serrut-Valette) and other members affirmed the
    need to move ahead with the draft.

    There was one area on which consensus was eventually acheived:
    draft-ietf-cuss-sip-uui-isdn uses the value of "isdn-uui" for
    the "purpose" header field parameter.  Older versions of the
    draft used the value "isdn-network".  Consequently, there are
    implementations that use "isdn-network" and doubtlessly, for
    some valid reasons these implementations are not amenable to
    change.  Text was added to -06 version of the draft that
    adequately addressed the issue of implicitly supporting "isdn-
    network" in certain cases.  The participants to the discussion
    are okay with the proposed resolution.

    Document Quality:
    The document has been reviewed by multiple WG members and has
    been affirmed by many more.  There are no known issues with
    document quality.  There appear to be existing implementations
    of the draft, especially since the issue requiring consensus
    (described above) was specifically so that existing code can
    continue to work.

    Personnel:
    Vijay K. Gurbani is the Document Shepherd.  Alissa Cooper is
    the Responsible Area Director.

(3) Document Shepherd has reviewed the document.
    Besides three minor nits that can be fixed during AUTH-48, there
    weren't any substantive issues that will prohibit the document
    from moving forward.

(4) The Document Shepherd does not have any concerns on the depth
    or the breadth of the reviews that have been accorded to this document.

(5) The document does not need particular reviews from security,
    operations, AAA, DNS, DHCP, XML or internationalization.
    Aspects of the proposed package in the draft are (obviously)
    related to SIP, but among the working group there have been
    enough personnel with SIP expertise who have vetted the draft
    appropriately.

(6) The Document Shepherd does not have any specific concerns or
    issues with this document that need to be elevated to the
    attention of the AD.

(7) Authors have confirmed that they are not aware of any IPR
    disclosures related to the draft. 

(8) There has not been any IPR disclosure filed with reference to
    the draft.

(9) There is solid WG consensus behind the document.  In fact, other
    SDOs remain interested in this document and have urged the
    timely publication of it.  The WG as a whole understand and agrees
    with the contents of this document.

(10) No one has threatened an appeal or otherwise indicated extreme
  discontent with this draft.  About the closes we have come to
  discontent has been regarding the slow movement of this draft
  since other SDOs remain interested in using this draft.

(11) No substantive nits found beyond an outdated reference.

(12) The contents of the document do not merit any formal review
  criteria related to MIB, media or URI types.

(13) Yes, all references are either normative or informative.

(14) There is a normative reference to draft-ietf-cuss-sip-uui
  document.  However, that document has been submitted to IESG
  for publication.

(15) There are no downward normative references.  There is a normative
  reference to an ITU-T document [Q931], but it is the Document
  Shepherd's understanding that the ITU-T document being referenced
  is at the equivalent level of maturity targeted by the draft itself.

(16) The publication of this draft will not change the status of
  any existing RFCs.

(17) The Document Shepherd has reviewed the IANA Considerations
  section of the draft and found it to be consistent with the
  expectation of updating the SIP parameter registry.  In addition,
  the draft also defines a SIP media feature tag that is added
  to the features.sip-tree of the Media Features tag registry.
  The artifacts related to the SIP media feature tag are appropriately
  specified in the IANA Considerations Section.

(18) This document does not establish any new IANA registries.

(19) The document does not contain XML or JSON code, so no automated
  checks are required.  The document does contain ABNF rules, which
  appear adequate as specified.