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

[lconroy <[e-mail]>]

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
_______________________________________________
Iptel mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iptel