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