Re: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values?

[Christer Holmberg <[e-mail]>]

NO.

(We can have a separate discussion whether we want to, as part of another draft/errata, want to define the semantics for existing value(s), but let's not that stop the progress of the registry work.)

Regards,

Christer


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
Sent: 29. marraskuuta 2012 0:41
To: [e-mail]
Subject: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values?

We are in the process of adopting draft-roach-sipcore-priority-00 as a wg document. We already ran a WGLC on it in anticipation of the adoption.

One issue raised during the WGLC was whether the document should spell out the semantics of all the priority values defined in 3261. (Currently
3261 only defines "emergency".) Dan, James, and Roy were in favor, Adam and I prefered not to do it *in this document*.

I think everyone agrees that 3261 is lacking in this regard, and it would be good to have these defined. The question is whether to do that in *this* document. The answer to that depends on a number of factors:
- the urgency of getting the iana registry established, so that ecrit
   won't be blocked in defining a new value for their work.
- how much pain is lack of semantics for these values causing right now?
- how long would it take to to agree on definitions of the semantics?
- acceptability of alternatives to this document for defining the
   semantics.

Please indicate your preference on this issue:

- NO: do not add semantic definitions to this draft.
   (That means they will be done some other way or not at all)

- YES: this document should be delayed while semantic defintions
   of existing priority values are added to it.

If you vote NO, feel free to indicate what mechanism you would like have used to define the semantics. (E.g. errata / another draft.)

	Thanks,
	Paul

On 11/28/12 5:03 PM, Paul Kyzivat wrote:
> 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