Re: [sipcore] Establishing a "Priority" header field registry

In this particular case, I think using UPDATES is the right thing to do.

As Adam has noted, RFC3261 left _how_ to exercise this particular 
extension point less well-defined than it did for most. In clearing up 
the ambiguity that left, this document is changing the (what had to be 
implicitly inferred) consensus on what needs to be done to add a 
recognized value for this header field. (We would be using UPDATES if 
there had been a registry defined for this in RFC3261 and we were 
changing its registration policy).

RjS

On 11/6/12 2:33 PM, DRAGE, Keith (Keith) wrote:
> I have reviewed the document and saw no issues with the current contents. It performs a useful function and should be proceeded with.
>
> As the document stands, I still see no reason why the document should update RFC 3261. It makes no normative changes within the scope of RFC 3261, which is to define the protocol between two entities.
>
> Part of this discussion may relate to whether one sees the creation and entry of material into IANA registries as being a normative action or not. I don't. To me they are just the housekeeping that has to be done.
>
> As regards the template (which other mails have suggested), we possibly do not need one.
>
> Part of this down to the level of review that is required; in the document this is set as IETF review. At this level, an RFC has to exist and go through IETF community review. There will be enough people around in this process to ensure that all the information that people need to see outside the IANA table actually exists. Conversely where we are allocating values on expert review, a template could be essential if only to ensure the expert doing the review has enough information available to perform the review; that information may well exceed the information that needs to appear in the template itself.
>
> Note that I did have a discussion with IANA on both these issues, and it would be wrong to say an opinion was expressed, Michelle seemed to be in alignment with these points.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
>> Of Adam Roach
>> Sent: 06 November 2012 15:54
>> To: sipcore@ietf.org; ecrit@ietf.org
>> Subject: [sipcore] Establishing a "Priority" header field registry
>>
>> [as an individual]
>>
>> The document draft-ietf-ecrit-psap-callback has identified a desire to
>> add a new value to the "Priority" header field for SIP. While RFC 3261
>> clearly intended the values in this header field to be extensible, it
>> did not define a registry of such values.
>>
>> To address this oversight, I have put together a small draft that
>> defines such a registry and populates it with the values defined by RFC
>> 3261. Because this is a correction to the core SIP specification, it is
>> my belief that it falls within the charter of the SIPCORE working group.
>>
>> The only real open issue, in my opinion, is the IANA registration policy
>> that should apply to new "Priority" header field values. To avoid
>> blocking any work in ECRIT, we need to move this work (or something
>> equivalent) forward very quickly. If you have any interest in the topic,
>> please review and comment with some urgency.
>>
>> http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt
>>
>>
>> [The following request is being made in my WG chair role]
>> As this is a SIPCORE matter, please discuss it on the SIPCORE list
>> rather than the ECRIT list.
>>
>> Thanks!
>>
>> /a
>> _______________________________________________
>> 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