IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field
draft-ietf-sipcore-priority-00

[Ballot comment]
I chatted with Robert about these two items, so I don't feel the need to DISCUSS them with the rest of the IESG. And I'm not willing to stand in the way of publishing this document on these two points alone. But I do want to make it clear that I'd much prefer if the following two things were changed.

- This is simply a procedural document, not a protocol document. It should be BCP. It can still update 3261 as a BCP.

- I agree with Barry that a paragraph explaining that IETF Review is necessary because of potential interoperability problems (i.e., the fact that SIP implementations would need upgrading if they would have to understand bogusness that will go into this field if people can register willy-nilly) would be a good addition and prevent people refer to this as a precedent in the future.

[Ballot comment]
I support Russ's DISCUSS, but it's trivial to fix and discussion has already converged on that.

The shepherd writeup says this:

    The policy for adding new values to the registry was intentionally
    chosen to be IETF Review. We do not anticipate many additions, and
    feel this level of review will ensure that any such additions are
    well considered.

I have discussed this with Robert, and am happy to clear my DISCUSS on it (having had the discussion) and move it to a non-blocking comment.  Our discussion made it clear that there have been problems with attempts to use this header field, that scrutiny of the usage proposals is important, and that a single expert isn't appropriate because conversation within the SIP community is often important in teasing out issue with proposals.

That said, if you can find a way to put a paragraph explaining that into the document, as an explanation to and a warning to those who might want to mint new values for this header field, I think it would be useful.  I don't think it should take much, though I understand that there are political land mines that you'll want to step around as you do it.

And remember that this is non-blocking, so if you really can't see a good way to say it I'm not going to insist further.

[Ballot discuss]
The shepherd writeup says this:

    The policy for adding new values to the registry was intentionally
    chosen to be IETF Review. We do not anticipate many additions, and
    feel this level of review will ensure that any such additions are
    well considered.

I'm glad to see that there was actually discussion about this.  I'd like to add myself to the discussion for a bit, because I question the need for IETF Review for this sort of header field.  "Well considered" is fine, but is it really necessary to go through the (expensive) IETF process for something for which there's no shortage of possible code points?  More to the point, what's the... um... priority here?  If an implementation should introduce a new priority field value -- say, "lowest-possible" -- and others should pick it up, which is more important: having it registered, or having it reviewed by the IETF?

I could even see First Come First Served here (especially as you don't expect any/many registrations), but certainly Expert Review ought to be sufficient, no?

[Ballot discuss]

  I agree with the concern raised in the Gen-ART Review by Dan Romascanu
  on 6-Jan-2013, and I think this change needs to be made for clarity.
  >
  > In the IANA considerations section this document requires IANA to
  > create a new registry with the suggested name "Priority Header Field
  > Values". For clarity purposes, taking into account that other
  > protocols may also carry priority fields in headers, I suggest that
  > a better name would be "SIP Priority Header Field Values"

IANA has reviewed draft-ietf-sipcore-priority-00 and has the following comments:

IANA understands that, upon approval of this document, there is
a single action which IANA must complete.

In the Session Initiation Protocol (SIP) Parameters registry located at:

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

A new subregistry called the "Priority Header Field Values" registry is to be created.

New registrations and maintenance of the new subregistry is to be done through IETF Review as defined by RFC 5226.

There are initial registrations in the subregistry as follows:

+------------+-----------+
| Priority  | Reference |
+------------+-----------+
| non-urgent | RFC 3261  |
| normal    | RFC 3261  |
| urgent    | RFC 3261  |
| emergency  | RFC 3261  |
+------------+-----------+

IANA understands this to be the only action 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'IANA Registry for the Session Initiation Protocol (SIP) "Priority"
  Header Field'
  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-01-07. 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 document defines a new IANA registry to keep track of the values
  defined for the Session Initiation Protocol (SIP) "Priority" header
  field.  It updates RFC 3261.




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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-priority/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 purpose of this document is to update RFC 3261,
        introducing the use of an IANA registry where that
        RFC did not call for one. It changes the procedures
        for making extensions to that header.

    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 document defines a new IANA registry to keep track of the values
    defined for the Session Initiation Protocol (SIP) "Priority" header
    field.  This header field was defined in [RFC3261], section 20.26.
    It was clearly specified in a way that allows for the creation of new
    values beyond those originally specified; however, no registry has
    been established for it.

Working Group Summary

    This work was initiated because the ECRIT WG had a need to define
    a new value for the Priority header field, for use in new document
    draft-ietf-ecrit-psap-callback. RFC 3261 was written to allow such
    extensions, but had no mechanism to manage extensions.
    The chairs of ECRIT and SIPCORE and the ADs discussed this and
    considered various mechanisms to move forward. The alternatives
    considered were:

    - construct the ECRIT document as an update to RFC 3261,
      extending the syntax of the Priority header field.

    - construct the ECRIT document as an update to RFC 3261,
      introducing an IANA registry for Priority header field values,
      populating it with those values defined in RFC 3261 and also
      the desired new value.

    - publish a new draft, in the SIPCORE WG, that updates RFC 3261,
      introducing an IANA registry for Priority header field values,
      and populating it with those values defined in RFC 3261.
      Then the ECRIT WG can modify their document to register the new
      value in accord with the new registration procedures.

    We concluded that the last approach was the cleanest one.
    This draft is result.

Document Quality

  Are there existing implementations of the protocol?

      This defines no new protocol.

      draft-ietf-ecrit-psap-callback is progressing in parallel and
      will make use of the new registration mechanism.

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

      N/A

  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 is very simple, so didn't require great effort
      to review. The primary commenters on the draft were
      Christer Holmberg and Keith Drage.

  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?

      N/A

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 was party in the decision to create this document.
    My co-chair authored it and I reviewed it.
    I have checked for nits.

    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 sufficiently 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 no concerns.

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

    By its nature this document is non-controversial.
    We ran a two week WGLC. There was support from those who cared.
    The only significant issue that came up was whether the document
    should include a template to be filled in by those registering
    new values, to be used to help IANA in accomplishing the registration.
    After discussion we concluded that this was unnecessary because of
    the simplicity of the registry and because we require an RFC to
    register new values.

(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.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
      have content which was first submitted before 10 November 2008. If
you
      have contacted all the original authors and they are all willing
to grant
      the BCP78 rights to the IETF Trust, then this is fine, and you can
ignore
      this comment.  If not, you may need to add the pre-RFC5378
disclaimer.
      (See the Legal Provisions document at
      http://trustee.ietf.org/license-info for more information.)

    The only content carried over from RFC 3261 is the list of values
    for the Priority field that were defined there.

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

        This document updates RFC 3261.

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

        Yes

      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 the sole purpose of this document.
    There is substantial precedent in RFC 3261 for registries
    analogous to this one. The new registry introduced here follows
    that precedent. This document prepopulates the new registry with
    the defined values from RFC 3261. There have been no prior extensions
    to this header field so that is the complete set of existing values.

    The policy for adding new values to the registry was intentionally
    chosen to be IETF Review. We do not anticipate many additions, and
    feel this level of review will ensure that any such additions are
    well considered.

    I noted one small issue while preparing this writeup:
    The IANA instructions do not say that the new registry should be
    placed under "Session Initiation Protocol (SIP) Parameters".

(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.

    None

(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.

    N/A