Subject: [Iptel] draft-ietf-iptel-reg-05

From: "Yu, James" <[email-masked]>
Date: Fri, 16 May 2008 05:30:50 -0400

Cullen, Vijay,

I was checking your I-D and RFC 3969 (for sip parameter registration) and found that the "Yes/No" assignments in this I-D's "Predefined Values" column is different from those in RFC 3969.

In RFC 3969, for example, "ttl" has value "No" because that parameter does not have any "registered" value, although it can contain a value to indicate TTL length. 

In your I-D, the assaignments of "Yes" or "No" for the "Predefined Values" column are based on if the parameter is a flag or not.

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.

James
_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: lconroy <[email-masked]>
Date: Fri, 16 May 2008 14:02:33 +0100

James,
  this is just over 1 month beyond IETF LC.

As an author on one of the RFCs referenced in the table, I believe  
that...
The current tel-reg draft IS internally consistent - the last  
paragraph in section 3 (across pages 3 and 4) is clear, and the table  
reflects this.
The description (earlier in section 3) for authors of future tel:  
parameters is also clear and precise on what needs to go into the  
required parameter description RFC.
The recommendation to IANA on what should go into the updated table  
in their registry is also clear.

I'm not comfortable with your proposed substantive change
(i) There is no suggested alternative text for section 3, and for the  
recommendations to
     IANA on the maintenance of the table.
(ii) It is unclear whether or not you have re-evaluated the RFCs  
referenced already in
      the table to ensure that they are consistent with your proposed  
re-interpretation
      of the column meaning.
(iii) The registered namespaces are the parameter strings themselves,  
not the
       numeric/textual values that an individual parameter can hold  
after the "=".
       The second column entry is always dependent on the parameter  
label string,
       and that is specified in the RFC in which the parameter string  
is defined.
       => there is no potential for clash => why is any change needed?

The current tel-reg draft IS internally consistent - the last  
paragraph in section 3 (across pages 3 and 4) is clear, and the table  
reflects this.
The description (earlier in section 3) for authors of future tel:  
parameters is also clear and precise on what needs to go into the  
required parameter description RFC.
The recommendation to IANA on what should go into the updated table  
in their registry is also clear.

The draft works as-is (and has done for **years**).
Whether it is the same as some other registry is not relevant to an  
IANA registry; I doubt that those registries are consistent with one  
another in their use of tables.

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.

   Lawrence

On 16 May 2008, at 10:30, Yu, James wrote:
> Cullen, Vijay,
>
> I was checking your I-D and RFC 3969 (for sip parameter  
> registration) and found that the "Yes/No" assignments in this I-D's  
> "Predefined Values" column is different from those in RFC 3969.
>
> In RFC 3969, for example, "ttl" has value "No" because that  
> parameter does not have any "registered" value, although it can  
> contain a value to indicate TTL length.
>
> In your I-D, the assaignments of "Yes" or "No" for the "Predefined  
> Values" column are based on if the parameter is a flag or not.
>
> 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.
>
> James

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 May 2008 10:48:14 -0500

Yu, James wrote:
> registration of predefined value(s) should be assigned "No" in Table
> 1.
[...]

> then chaning the logic of that text (and the table) isn't going to

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
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: lconroy <[email-masked]>
Date: Fri, 16 May 2008 17:18:08 +0100

Hi Vijay, folks,
   Your/the IESG's solution is fine - it is even clearer, which is  
always good.
I look forward to seeing this as an RFC real soon now :).
all the best,
   Lawrence