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

[Robert Sparks <[e-mail]>]

For clarity - this was the message I was pointing to in my AD review.

RjS

On 11/29/12 6:20 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> 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
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore