[Ecrit] Comments on draft-ietf-ecrit-local-emergency-rph-namespace-03

"DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> Fri, 27 March 2009 00:16 UTC

Return-Path: <drage@alcatel-lucent.com>
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E6D28C0E7 for <ecrit@core3.amsl.com>; Thu, 26 Mar 2009 17:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.228
X-Spam-Level:
X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gglTNyczybeL for <ecrit@core3.amsl.com>; Thu, 26 Mar 2009 17:16:08 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 2B9B13A67DA for <ecrit@ietf.org>; Thu, 26 Mar 2009 17:16:07 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2R0GvYH020945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <ecrit@ietf.org>; Fri, 27 Mar 2009 01:16:58 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 27 Mar 2009 01:16:57 +0100
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: 'ECRIT' <ecrit@ietf.org>
Date: Fri, 27 Mar 2009 01:16:56 +0100
Thread-Topic: Comments on draft-ietf-ecrit-local-emergency-rph-namespace-03
Thread-Index: AcmucVZwqa8WZkvrRxGMXk2uwk8tnA==
Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE90B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.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.57 on 155.132.188.13
Subject: [Ecrit] Comments on draft-ietf-ecrit-local-emergency-rph-namespace-03
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 00:16:09 -0000

Aside from some editorials, I have the following comments on the latest revision of this document:

1)	Remove the abbreviation RPH. It is never used alone and not a real abbreviation associated with this header field.

2)	Align the abstract and introduction text with RFC 5478.

3)	Section 1:

   Within controlled environments, such as an IMS infrastructure or 
   Emergency Services network (ESInet), where misuse can be reduced to 
   a minimum because these types of networks have great controls in 
   place, this namespace can be to provide an explicit priority 
   indication that facilitates differing treatment of emergency SIP 
   messages according to local policy, or more likely, a contractual 
   agreement between the network organizations.  This indication is 
   used to differentiate SIP requests, or dialogs, from other requests 
   or dialogs that do not have the need for priority treatment.

I would suggest inserting the word "solely" before "to differentiate SIP requests". It is not used outside the scope of the Resource-Priority header field.

4)	Section 1:

   It can also be imagined that Voice Service Providers (VSP) directly 
   attached to an ESInet can have a trust relationship with the ESInet 
   such that within these networks, SIP requests (thereby the session 
   they establish) make use of this "esnet" namespace for appropriate 
   treatment.

The use of the term VSP throughout the document gives the impression that this is only intended for voice emergency calls. It can be used on any SIP request that relates to an emergency call. Can we preface this sentence with "As an example" and check other usages in the document.

5)	Section 1:

   Usage of the "esnet" namespace is to be defined in a future 
   document(s). 

I think this prejudges what other standardisation is required. I do not believe another document is required and certainly we do not have one chartered. I would prefer to remove this sentence. If the solution is not this simple, then at least replace it with "Usage of the namespace is governed by agreements between domains, in accordance with the guidance already given in RFC 4412" or something like this.

6)	Section 2:

   This document updates the behaviors of the SIP Resource Priority 
   header, defined in [RFC4412], during the treatment options 
   surrounding this new "esnet" namespace only. 

I think the use of the word "updates" here is a poor choice, as it does not update RFC 4412, nor indeed does it really provide any additional normative behaviour on the Resource-Priority header field.

7)	Section 3.2:

This section discusses preemption. I would prefer to just say: 

"The namespace definition has to indicate whether the namespace is preemption or priority. It is envisages that use of this namespace is primarily priority, however in accordance with the current practice of some regulatory bodies, preemption of emergency calls is permitted by this namespace definition. Such preemption is not defined further in this document."

I will send the editorials directly to James.

regards

Keith