Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 27 February 2013 19:48 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 5598221F888F for <sipcore@ietfa.amsl.com>; Wed, 27 Feb 2013 11:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.307
X-Spam-Level:
X-Spam-Status: No, score=-109.307 tagged_above=-999 required=5 tests=[AWL=0.942, 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 UuBs9rDvpG00 for <sipcore@ietfa.amsl.com>; Wed, 27 Feb 2013 11:48:21 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6E51D21F887F for <sipcore@ietf.org>; Wed, 27 Feb 2013 11:48:21 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1RJmDZV023047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Feb 2013 20:48:18 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 27 Feb 2013 20:48:16 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Adam Roach <adam@nostrum.com>, 'SIPCORE' <sipcore@ietf.org>
Date: Wed, 27 Feb 2013 20:48:15 +0100
Thread-Topic: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00
Thread-Index: Ac4VCH6yWaz6nTcRQg+DzBdbID6ogwAFs7+w
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE210701F272E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <512E35D2.6080400@nostrum.com>
In-Reply-To: <512E35D2.6080400@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.84
Cc: "draft-rosen-rph-reg-policy@tools.ietf.org" <draft-rosen-rph-reg-policy@tools.ietf.org>
Subject: Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00
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: Wed, 27 Feb 2013 19:48:22 -0000

I do not have a problem with relaxing the criteria and therefore we will need an I-D to do that, and therefore a milestone to cover that task.

I have the following comments on the document.

1)	Editorial. The document states internally that it updates RFC 4412 and this is correct. However that information also needs to appear in the top left of the document.

2)	The document gives no background material on why IETF review has been chosen, only that it no longer needs to be standards track (Note that I am not convinced "Standards Track" was selected in error). Personally I think "Specification Required" would be entirely appropriate, however if this is used see comment 3) below.

3)	As more relaxed criteria for IANA registration are defined, then material has to be defined to support those reviewing the registration; for a standards track defined protocol, this should be defined in a standards track document. For example RFC 4412 contains no information on when a new namespace is appropriate, as opposed to reuse of an existing namespaces. I have certainly been involved in discussions as to whether the "ETS" namespace is restricted only to usage of "US government telecommunications service" or whether another government body in a different country with identical requirements can reuse the same namespace, or whether they have to define a new namespace, and RFC 4412 does not answer this. So the proposed update currently contains no additional information (to RFC 4412) on:

-	what information needs to be provided for a new namespace or priority level;

-	what criteria need to be met for adopting a new namespace or priority level, versus reusing or modifying an existing one.

4)	Can a new document update an existing namespace with new priority levels or other functionality? I believe this would normally be bad practice for compatibility reasons, but the document does not cover this.

Keith


> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
> Of Adam Roach
> Sent: 27 February 2013 16:36
> To: 'SIPCORE'
> Cc: draft-rosen-rph-reg-policy@tools.ietf.org
> Subject: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00
> 
> [as chair]
> 
> During the processing of draft-polk-local-emergency-rph-namespace, the
> IESG, authors, and WG chairs determined that the policy described in
> RFC4412, section 9 for defining a new namespace (Standards-Track RFC)
> was probably selected in error, and that "IETF Review" is likely more
> appropriate. The ECRIT working group has already been informed of this
> situation, and no parties have objected to a change in policy:
> 
> http://www.ietf.org/mail-archive/web/ecrit/current/msg08292.html
> 
> Since this is a policy change to a core SIP header, our Area Director
> has requested that the document that formally changes the policy be
> processed as a SIPCORE document. The current draft is available here:
> 
> http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00
> 
> (Aside: ignoring the boilerplate, references, and table of contents, the
> document is about half as long as this email, and should take less time
> to read).
> 
> This message starts a call for adoption in parallel with a working group
> last call. Both periods end in just over two weeks, on Friday, March
> 15th (the final Friday of the Orlando IETF meeting). Please reply to the
> mailing list indicating support or opposition to such adoption, and with
> any comments on the document contents themselves.
> 
> /a
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore