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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 06 November 2012 19:33 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5821021F8A17 for <sipcore@ietfa.amsl.com>; Tue, 6 Nov 2012 11:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.749
X-Spam-Level:
X-Spam-Status: No, score=-109.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PAbGMb6Woix for <sipcore@ietfa.amsl.com>; Tue, 6 Nov 2012 11:33:52 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8676D21F8A14 for <sipcore@ietf.org>; Tue, 6 Nov 2012 11:33:52 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA6JXl1d018178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <sipcore@ietf.org>; Tue, 6 Nov 2012 20:33:51 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 6 Nov 2012 20:33:30 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Tue, 06 Nov 2012 20:33:29 +0100
Thread-Topic: [sipcore] Establishing a "Priority" header field registry
Thread-Index: Ac28NvOrbUWItqiIRqSTYX5lc2XL1AAHC/Ag
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE202D2F701CB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <50993285.4020408@nostrum.com>
In-Reply-To: <50993285.4020408@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: Re: [sipcore] Establishing a "Priority" header field registry
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2012 19:33:53 -0000

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