Subject: [Ecrit] FYI: IESG has approved draft-ietf-sipcore-priority-00

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2013 16:59:05 -0500

You might be interested.

	Thanks,
	Paul

-------- Original Message --------
Subject: [sipcore] Protocol Action: 'IANA Registry for the Session 
Initiation Protocol	(SIP) "Priority" Header Field' to Proposed Standard 
(draft-ietf-sipcore-priority-00.txt)
Date: Mon, 14 Jan 2013 13:00:19 -0800
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
CC: sipcore mailing list <[email-masked]>,        sipcore chair 
<[email-masked]>,        RFC Editor 
<[email-masked]>

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.
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore