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

I fear you guys read a bit too much into the term "template". 

IANA typically wants to know what information a request for adding a new
value into an existing registry should contain. This is called the
template. As mentioned, here the required info is pretty obvious: a
label and a reference to a document that contains the semantic. If you
want to make it 100% clear add a sentence: "Registration requests to
IANA must include a label (value for the priority header field) and a
reference to a document that explains the semantic of that label." 

What is, however, missing from the IANA consideration is an indication
whether you envision entries to be updated, deleted, or deprecated. I
would write "Updating, deleting, or deprecating of entries in the
registry is not envisioned." 

Ciao
Hannes

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of ext Christer Holmberg
> Sent: Thursday, November 29, 2012 1:51 PM
> To: DRAGE, Keith (Keith); Paul Kyzivat; sipcore@ietf.org
> Subject: Re: [sipcore] Proposal: Call for adoption& WGLC: draft-roach-
> sipcore-priority-00
> 
> Hi,
> 
> >Regarding 1), noone has yet responded as to why we need a template
for
> a document where registration requires IETF work. The template
> >is in my view there to ensure all the information that is needed is
> available for expert review. The document management of an internet
> >draft means that if information is needed for review the next
revision
> can provide it. We only need a template if someone decides a different
> >registration policy is needed.
> 
> Fair enough. I hereby withdraw my request for a template :)
> 
> Regards,
> 
> Christer
> 
> 
> > -----Original Message-----
> > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> > Behalf Of Paul Kyzivat
> > Sent: 28 November 2012 22:04
> > To: sipcore@ietf.org
> > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC:
> > draft-roach-
> > sipcore-priority-00
> >
> > 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
> > > sipcore@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > >
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore