Subject: [sipcore] Protocol Action: 'IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field' to Proposed Standard (draft-ietf-sipcore-priority-00.txt)

From: The IESG <[email-masked]>
Date: Mon, 14 Jan 2013 13:00:19 -0800

The IESG has approved the following document:
- 'IANA Registry for the Session Initiation Protocol (SIP) "Priority"
   Header Field'
  (draft-ietf-sipcore-priority-00.txt) as Proposed Standard

This document is the product of the Session Initiation Protocol Core
Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-sipcore-priority/

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 

RFC-Editor Note:

Please make the following three changes to version -00 of this draft)

Change 1 (replaces text):

OLD:
This document adds a new registry, "Priority Header Field Values."

NEW:
This document adds a new sub-registry, "Priority Header Field Values" to the
"Session Initiation Protocol (SIP) Parameters" registry page. 

Change 2 (only adds text):

OLD:
The policy for registration of values in this registry is "IETF Review," as that term is defined by [RFC5226].

NEW:
The policy for registration of values in this registry is "IETF Review," as that term is defined by [RFC5226]. This policy was chosen over lighter-weight policies due the potential architectural impact of the semantics associated with new values. Efforts considering adding a Priority value should consider whether the SIP Resource-Priority [RFC4412] or even a different protocol would be more appropriate for achieving their requirements.

Change 3 :

Please add an informational reference to RFC4412.