Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00

[Paul Kyzivat <[e-mail]>]

The WGLC and adoption deadline has now passed for 
draft-roach-sipcore-priority-00. Nine people (other than chairs and 
authors) made meaningful comments.

I conclude there is consensus to adopt this draft as a wg document.

Regarding WGLC, two notable issues were raised, and I don't yet see a 
clear consensus on those issues:

- should there be a registration template?
   Christer advocates this, Keith opposes, Adam finds it unnecessary.

- should this document also spell out the semantics of all the priority
   values defined in 3261? (Currently it only defines "emergency".)
   Dan, James, and Roy in favor, Adam and I prefer not to do it *in this
   document*.

So, I will ask Adam to submit a wg draft version of this document, 
otherwise unchanged.

While he is doing that, I would like to get a broader consensus on the 
issues above. I'll post a separate question on each of those, to keep 
the discussions separate.

	Thanks,
	Paul

On 11/12/12 3:49 PM, Paul Kyzivat wrote:
> PLEASE RESPOND TO THIS MESSAGE
>
> This is a request to the sipcore wg to adopt the new individual draft
> draft-roach-sipcore-priority-00, and a start of WGLC on that document,
> to end on Sunday, November 25, 2012. (This is a trivial doc to review,
> but people may be slow getting back to work after the meeting and there
> is a holiday coming in the US, so I'm giving more time than I otherwise
> would.)
>
> The reason for this is that the ecrit wg wants to define a new value for
> the Priority header field. RFC 3261 defines that header field and an
> initial set of values. It also mentions the possibility of extension.
> But it failed to establish an IANA registry for that purpose, and didn't
> otherwise define a process for extension.
>
> The intro to *this* document explains its purpose:
>
>     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.
>
> Once that is done, ecrit will be able to make their extension in accord
> with the registration procedures that have been defined. The
> registration policy is "IETF Review", so discussion of the merits of
> that new value can be discussed as part of the review of *that*
> document: draft-ietf-ecrit-psap-callback.
>
> REQUESTED ACTIONS:
>
> - indicate (ASAP) willingness, or not, for the sipcore wg to work on
>    this problem, and adopt this draft as the basis for that work.
>
> - provide any comments you have on this document before the end of
>    the WGLC period (Friday, November 25.)
>
>      Thanks,
>      Paul
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>