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

Hi,

>> I support the adoption.
>>
>> As I have indicated before, I think there should be some kind of template for the registration.
>
> I guess that means you aren't ready to approve it.

What do you mean by approve? I assumed that adopting the draft would mean that it becomes draft-ietf-sipcore-priority. I think we can do that even if the template text yet does not exist.

Of course, before we finalize WGLC and send the draft to IESG, we would need to have the template text.

> Can you suggest some text?

I'll try to come up with something.

Regards,

Christer

> Regards,
>
> Christer
>
> ________________________________________
> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu]
> Sent: Monday, 12 November 2012 10:49 PM
> To: SIPCORE; sipcore-ads@tools.ietf.org
> Subject: [sipcore] Proposal: Call for adoption & WGLC:  draft-roach-sipcore-priority-00
>
> 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
>