Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)
draft-ietf-sipcore-proxy-feature-12

[Ballot comment]

- Is the consumer of the information in feature-capabilities
well-defined? Is it intended just for the recipient of the SIP
message or is it ok for it to really be intended e.g.  for one
SIP proxy to tell stuf to a downstream proxy but not to the
final recipient? (I may have missed where you said that, in
which case, sorry:-)

The remainder of my comments are really security points, but
given that we're not going to solve e2e (never mind
middle-to-end) security for SIP now, these are just comments.
I'd still be very interested in answers though.

- Are SIP proxies allowed to remove feature capabilities added
upstream? Presumably they MUST NOT re-order them?

- I suspect the last paragraph of section 9 is wishful thinking
at best as it relates to confidentiality. Defining a solution
for middle-to-end or middle-to-middle confidentiality like that
seems like its just not going to happen (and is quite hard in
any case). I think you'd be better to say that you SHOULD NOT
define feature capabilities that need confidentiality that's
better than hop-by-hop as provided by TLS.

- I wondered what'd happen if someone defined a DKIM-like
signature scheme for SIP messages. Has anyone thought about
that?

[Ballot comment]
I find the 2119 keywords in sections 5 & 8 to be completely superfluous. This is about documentation, not about interoperability or network damage. I think they should all be gotten rid of.

[Ballot comment]
I have no objection to the publication of this document.

Note that it has become customary to include a reference to the normative definition of the ABNF variant used.

[Ballot comment]
I have no objection to this document, and no blocking comments.  These are non-blocking, but please consider them, and feel free to chat with me about them:

-- Section 4.2.1 --
  When a SIP entity adds a Feature-Caps header field to a SIP message,
  it MUST place the header field before any existing Feature-Caps
  header field in the message to be forwarded, so that the added header
  field becomes the top-most one.  Then, when another SIP entity
  receives a SIP request or the response, the SIP feature capability
  indicators in the top-most Feature-Caps header field will represent
  the supported features and capabilities "closest" to the entity.

I understand the mandatory ordering, and I'm not asking about that.  But addressing the last point in particular, why is it important to know about supported features and capabilities "closest" to me?  Suppose the entities involved are A -> B -> C -> D, and suppose that A and B put Feature-Caps header fields on but C does not.  Will there be any issue when D sees the field that B put on and "thinks" that it was put there by C?  (I suspect that's not a problem, but I wanted to ask.)

-- Section 5.3.6 --

  If there are specific security considerations that apply to the
  feature capability indicator, the feature capability indicator
  specification MUST document such considerations.

That seems an odd requirement.  If a feature capability indicator specification comes in that has nothing for its security considerations, how does anyone know whether that's because the authors thought that none applied, or that they just decided to skip this item?  Why not just this?:

NEW
  The feature capability indicator specification MUST document
  any specific security considerations that apply to the
  feature capability indicator.

And similarly for Section 5.3.5, about interop considerations.

IANA has reviewed draft-ietf-sipcore-proxy-feature-09 and has the following comments:

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are three
actions that need to be completed.

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

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

a new SIP Header field will be added as follows:

Header Name: Feature-Caps
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

a new header field will be added as follows:

Header Field: Feature-Caps
Parameter Name: + *
Predefined Values: No
Reference: [ RFC-to-be ]

This entry will have an asterisk and footnoted text for the subregistry will
read:

*  denotes parameter names conforming to the syntax
defined in [ RFC-to-be ]. Valid feature capability indicators are registered in
the Proxy-Feature Feature Capability Indicator Trees subregistry located at: [
URL of new registry created in step three below ].

Third, a new sub registry in the IANA "Session Initiation Protocol (SIP)
Parameters" Protocol Registry, located at:

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

will be created. The name of the sub registry is "Proxy-Feature Feature
Capability Indicator Trees". New registrations are done through "Specification
Required" and "Designated Expert Review" as defined in RFC 5226.

Inside the new Proxy-Feature Feature Capability Indicator Trees subregistry,
two new trees will be created.

The first of these is the Global Feature Capability Indicator Registration Tree
Entries in this tree begin with the leading facet is "g.".
New registrations are done through "Specification Required" and "Designated
Expert Review" as defined in RFC 5226.

The format of the global tree is as described below:


Name Description Reference
------------------------------

IANA Question --> Are there any initial values to be registered in the new
Global Feature Capability Indicator Registration Tree?

The second new tree to be inside the Proxy-Feature Feature Capability Indicator
Tree is the "SIP Feature Capability Indicator Registration Tree"
Entries in this tree begin with the leading characters "
New registrations are done through "Specification Required" and "Designated
Expert Review" as defined in RFC 5226.

The format of the global tree is as described below:


Name Description Reference
------------------------------

IANA Question --> Are there any initial values to be registered in the new
Global Feature Capability Indicator Registration Tree?

IANA understands that these are the only IANA actions that need 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Mechanism to indicate support of features and capabilities in the
  Session Initiation Protocol (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 2012-09-18. 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


  This specification defines a new SIP header field, Feature-Caps, to
  convey feature capability indicators, which are used by SIP entities
  not represented by the URI of the Contact header field to indicate
  support of features and capabilities, where media feature tags cannot
  be used to indicate the support.

  This specification also defines feature capability indicators, and
  creates a new IANA registry, "Proxy-Feature Feature Capability
  Indicator Trees", for registering feature capability indicators.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature/ballot/


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

----------------------------------------------------------------------

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?

        Proposed Standard

    Why is this the proper type of RFC?

        The intent of this document is to define a new SIP header field.
        RFC 5727 spells out the rules for doing so. Header fields that
        might significantly change the behavior of those entities that
        support them can only be defined in a standards track RFC.

        The new header field defined in this document provides
        information that COULD cause entities to alter their behavior.
        Further, this mechanism is related to and aligned with the
        callee-capabilities mechanism of RFC 3840. It was discussion
        within the sipcore work group that refined the mechanism to
        its current form.

    Is this type of RFC indicated in the title page header?

        "Standards-Track" is indicated, in accord with xml2rfc.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

    This specification defines a new SIP header field, Feature-Caps, to
    convey feature capability indicators, which are used by SIP entities
    not represented by the URI of the Contact header field to indicate
    support of features and capabilities, where media feature tags cannot
    be used to indicate the support.

    This specification also defines feature capability indicators, and
    creates a new IANA registry, "Proxy-Feature Feature Capability
    Indicator Trees", for registering feature capability indicators.

Working Group Summary

  This document was driven by, and appears to be of interest
  primarily to the IMS community. However the resulting mechanism
  is of general applicability.

Document Quality

  Are there existing implementations of the protocol?

      It is my understanding that there are implementations
      in existence or under development.

  Have a significant number of vendors indicated their plan to
  implement the specification?

      3GPP IMS has a dependency on this document. It will be
      incorporated by reference in an upcoming version of IMS,
      and will thus eventually be implemented widely.

  Are there any reviewers that merit special mention as having done
  a thorough review, e.g., one that resulted in important changes
  or a conclusion that the document had no substantive issues?

      The document shepherd has been a reviewer and critic
      of this document, and promoted significant changes in
      the contemplated mechanism.

      Shida Shubert provided an in depth WGLC review.

  If there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

      There is nothing in this document that calls for an
      expert review.

Personnel

  Who is the Document Shepherd?

      Paul Kyzivat

  Who is the Responsible Area Director?

      Robert Sparks

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

    I have followed this document throughout its evolution.
    I also did a final read-through while preparing this writeup.
    And I ran IdNits on it.

    In my opinion this doc is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

    No. This document has been thoroughly reviewed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    In my opinion this document doesn't require any such
    specialized review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

    I have yet to identify a case when I would feel a need for this
    functionality, outside the 3GPP IMS environment. (Some possibilities
    have been discussed, but I haven't found the compelling.) However
    the IMS community says they have a need for this.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes, all have confirmed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    None filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    There is strong consensus among the substantial group who have
    interest in the draft. The non-IMS part of the community has been
    largely, but not completely, silent.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    No one has indicated extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      idnits has 0 errors, 1 warning, 0 comments.

      The warning is spurious.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    None of these apply to this document.

(13) Have all references within this document been identified as
either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    No.

(16) Will publication of this document change the status of any
      existing RFCs?

        No

      Are those RFCs listed on the title page header, listed
      in the abstract, and discussed in the introduction?

        N/A

      If the RFCs are not
      listed in the Abstract and Introduction, explain why, and point to the
      part of the document where the relationship of this document to the
      other RFCs is discussed. If this information is not in the document,
      explain why the WG considers it unnecessary.

        N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    IANA registration is a substantial focus of this document. The
    shepherd has worked closely with the authors to determine the best
    way to do this. The appropriate old and new registries have been
    identified and the new ones carefully specified. The processes for
    future allocations are defined. The new registries are established
    in an empty state by this document.

    There has been considerable attention to IANA registries during the
    development of this document. There is a close relationship between
    the registries used in this document and those used by RFC 3840.

    RFC 3840 reused the Media Feature Tag mechanism and registries that
    were defined in RFC 2506 for an entirely different purpose. It
    reused a few of the preexisting media feature tags. But defined a new
    sub-registry for itself, and all new media feature tags that have
    since been registered have been applicable solely to RFC 3840.

    Initially the current document planned to also reuse those same
    registries. But problems were identified in doing so. For tags to be
    usable with this new draft we have a requirement for specification of
    the semantics of the tag in this usage. Tags without such a
    specification should not be used. But the rules for making
    registrations in the existing media feature tag registry have no
    requirement for a specification.

    So it was decided to establish a new set of registries, specifically
    for this draft, that are structured in a similar way to those used
    for media feature tags. But for the new registries a specification is
    required.

    One editorial issue just noted: section 7.3.3 calls for IETF
    Consensus for the sip tree. It seems that name is now obsolete in
    5226, and is now called IETF Review. The doc should probably be
    updated to use the new name during the next editorial update.

    It was also noted while reviewing this draft that RFC 3840 had
    defined a whole class of sip header field parameters (those starting
    with "+") that had not been registered in the "Header Field
    Parameters and Parameter Values" sub-table of the "Session
    Initiation Protocol (SIP) Parameters" table. This draft has adopted
    the same syntax. So this draft adds a "meta-entry" to that table for
    all parameters starting with "+".

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

    This specification creates a new sub registry to the IANA "Session
    Initiation Protocol (SIP) Parameters" Protocol Registry, according to
    the process of RFC 5226 [RFC5226].  The name of the sub registry is
    "Proxy-Feature Feature Capability Indicator Trees".

    This specification creates a new feature capability indicator tree in
    the IANA "Proxy-Feature Feature Capability Indicator Trees" registry.
    The name of the tree is "Global Feature Capability Indicator
    Registration Tree", and its leading facet is "g.".  It is used for
    the registration of feature capability indicators.

    The document calls for addition of entries into this tree to follow
    the Expert Review policy, as defined in RFC 5226. However it also
    requires a specification document. In retrospect I believe the policy
    should be changed to Specification Required. The WG has been polled
    for any objections to this change, and there were none.

    Because of the close relationship between the new registries created
    by this document and those established by RFCs 2506 and 3840, I
    recommend that the same expert be used for both. (As it happens, the
    currently designated expert for the Media Feature Tag registries is
    also the shepherd for this document.)

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    The only formal language usage in this draft is ABNF.
    I used http://tools.ietf.org/tools/bap/abnf.cgi to check that.