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

["DRAGE, Keith (Keith)" <[e-mail]>]

If you look at some IANA tables, you will see a link to template, where the template contains more information than the IANA registry.

My assumption has been that this is to allow the gathering of extra information beyond the bare table, where an expert is designated to review the entry to ensure it makes sense. This of course depends on the guidance given to the expert who is performing the expert review from the original RFC that established the registry. If the expert is just expected to make sure all the table entries are present then you probably don't need one. If the expert is required to investigate in a more technical sense, then they need more information. 

Additionally RFC 3265 and its successor have a template for documenting event packages for example, which carries much more information than is needed for the IANA registry.

Keith

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[e-mail]]
> Sent: 29 November 2012 12:21
> To: ext Christer Holmberg; DRAGE, Keith (Keith); Paul Kyzivat;
> [e-mail]
> Subject: 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: [e-mail] [mailto:[e-mail]] On
> > Behalf Of ext Christer Holmberg
> > Sent: Thursday, November 29, 2012 1:51 PM
> > To: DRAGE, Keith (Keith); Paul Kyzivat; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Paul Kyzivat
> > > Sent: 28 November 2012 22:04
> > > To: [e-mail]
> > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > >
> > >
> > > _______________________________________________
> > > sipcore mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore