Re: [Iptel] draft-ietf-iptel-reg-05
"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Fri, 16 May 2008 15:48 UTC
Return-Path: <iptel-bounces@ietf.org>
X-Original-To: iptel-archive@megatron.ietf.org
Delivered-To: ietfarch-iptel-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B6028C188; Fri, 16 May 2008 08:48:44 -0700 (PDT)
X-Original-To: iptel@core3.amsl.com
Delivered-To: iptel@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D943128C188 for <iptel@core3.amsl.com>; Fri, 16 May 2008 08:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 sFdP8fNi4qEW for <iptel@core3.amsl.com>; Fri, 16 May 2008 08:48:42 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id C35403A6B3A for <iptel@ietf.org>; Fri, 16 May 2008 08:48:42 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m4GFmFxE003711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 10:48:15 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m4GFmCCU006102; Fri, 16 May 2008 10:48:12 -0500 (CDT)
Message-ID: <482DACBE.2090505@alcatel-lucent.com>
Date: Fri, 16 May 2008 10:48:14 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Yu, James" <james.yu@neustar.biz>
References: <C6105D088233254CA462CEE2B399CD7101FACEEF@STNTEXCH12.cis.neustar.com>
In-Reply-To: <C6105D088233254CA462CEE2B399CD7101FACEEF@STNTEXCH12.cis.neustar.com>
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: fluffy@cisco.com, iptel@ietf.org, lconroy@insensate.co.uk
Subject: Re: [Iptel] draft-ietf-iptel-reg-05
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Telephony <iptel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/iptel>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: iptel-bounces@ietf.org
Errors-To: iptel-bounces@ietf.org
Yu, James wrote: > Since the purpose of the I-D is to register "values" to avoid > duplicated assignments, any tel URI parameter that does not require > registration of predefined value(s) should be assigned "No" in Table > 1. [...] And Lawrence Conroy wrote: > Changing things now does not help, generates more work, and adds > precisely nothing - if someone isn't going to read the guidance text, > then chaning the logic of that text (and the table) isn't going to > help. James: By and large, I concur with Lawrence. However, during the IESG review, there was a COMMENT raised to clarify the table contents a bit more. Note that this was a COMMENT, and not a DISCUSS; so pedantically we could have left the table as-is; but I believe that addressing the COMMENT does do some good, and it may alleviate your problem as well. The suggested -- and accepted -- text does not deviate from what is currently there in -05, just uses different words to render equivalent impact more cleanly. Here is the change that was agreed to: Section 3: OLD Accordingly, the tel URI parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. The column can contain "Yes", or "No". A value of "Yes" in the column implies that certain predefined values exist for this parameter and the accompanying RFC or other permanent and readily available public specification should be consulted to find out the accepted set of values. A value of "No" in the column implies that the parameter is used either as a flag, or does not have a set of predefined values. The accompanying RFC or other permanent and readily available public specification should provide more information on the semantics of the parameter. NEW: Accordingly, the tel URI parameter registry contains a column that indicates whether or not each parameter accepts a value. The column may contain "No value" or "Constrained". A "Constrained" in the column implies that certain predefined values exist for this parameter and the accompanying RFC or other permanent and readily available public specification should be consulted to find out the accepted set of values. A "No Value" in the column implies that the parameter is used either as a flag, or does not have a set of predefined values. The accompanying RFC or other permanent and readily available public specification should provide more information on the semantics of the parameter. and accordingly, change the table as follows: OLD: Parameter Name Predefined Values Reference -------------- ----------------- --------- isub Yes [RFC 3966] isub-encoding Yes [RFC 4715] ext Yes [RFC 3966] phone-context Yes [RFC 3966] enumdi No [RFC 4759] npdi No [RFC 4694] rn Yes [RFC 4694] rn-context Yes [RFC 4694] cic Yes [RFC 4694] cic-context Yes [RFC 4694] tgrp Yes [RFC 4904] trunk-context Yes [RFC 4904] NEW: Parameter Name Value Type Reference -------------- ------------ --------- isub Constrained [RFC 3966] isub-encoding Constrained [RFC 4715] ext Constrained [RFC 3966] phone-context Constrained [RFC 3966] enumdi No value [RFC 4759] npdi No value [RFC 4694] rn Constrained [RFC 4694] rn-context Constrained [RFC 4694] cic Constrained [RFC 4694] cic-context Constrained [RFC 4694] tgrp Constrained [RFC 4904] trunk-context Constrained [RFC 4904] Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel
- [Iptel] draft-ietf-iptel-reg-05 Yu, James
- Re: [Iptel] draft-ietf-iptel-reg-05 lconroy
- Re: [Iptel] draft-ietf-iptel-reg-05 Vijay K. Gurbani
- Re: [Iptel] draft-ietf-iptel-reg-05 lconroy