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

NO - that's feature creep that takes something that's already been discussed and on which there is consensus and adds a boatload more discussion that will likely be a long discussion (see how much discussion we have had just on whether to use a new or existing value for PSAP callback) and delay the IANA registration of the new value.

I know it is Christmas season but let's not create a snowball that grows and grows as it rolls along!

If there are people willing to do the additional work of defining and discussing the semantics of these values then that can be a follow on draft.

Andrew

----- Original Message -----
From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
Sent: Wednesday, November 28, 2012 04:41 PM Central Standard Time
To: sipcore@ietf.org <sipcore@ietf.org>
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
>> 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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.