Re: [clue] WGLC for draft-ietf-clue-protocol-10

[Simon Pietro Romano <[e-mail]>]

Hello Christian,

> [CNG] I agree with Paul in that any new response code will need to be registered by IANA. However I don't see the problem with having two mechanisms to define codes within the protocol. It should be possible to add an error code to CLUE without having to bump the version. I think if you delete "(by adding them to the related IANA registry)," and add a sentence along the lines of:
> "In both cases the new response code MUST be registered with IANA”.

We followed your advice in version -13 of the draft. 

Cheers,

Simon


                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: [phone] -- Fax: [phone]
                                           e-mail: [e-mail] <mailto:[e-mail]>

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/



> On 24 Jan 2017, at 06:08, Christian Groves <[e-mail]> wrote:
> 
> Hello Simon and Roberta,
> 
> Thanks for addressing the comments. Please see below.
> 
> Regards, Christian
> 
> ..snip
>> 
>>>> Cl.5.7: It says future protocol version can introduce error codes? How about options? It seems like an option could introduce a specific error code.
>>>> Based on the discussion in section 8, a new response code might indeed be added through the “extension” mechanism. Though, the “cleanest” way for achieving such a task in a formal way is by adding
>>>> the new response code to the list of codes published in the dedicated IANA registry (see section 12.4.2 fo the draft). In the mentioned section, we refer to future versions of the standard.
>>> [CNG] By saying that error codes can be designed in future versions seems to preclude them being defined by extensions. (BTW 5.7 uses "designed", I think "defined" would be better).
>> 
>> We rephrased the sentence as follows:
>> 
>> "Further response codes can be either defined in future versions of the
>> protocol  or defined
>> by leveraging the extension mechanism. In any case, such new response
>> codes MUST NOT overwrite the ones here defined and they MUST
>> respect the semantics of the first code digit.”
>> 
>> Does this sound OK to you?
> [CNG] I agree with Paul in that any new response code will need to be registered by IANA. However I don't see the problem with having two mechanisms to define codes within the protocol. It should be possible to add an error code to CLUE without having to bump the version. I think if you delete "(by adding them to the related IANA registry)," and add a sentence along the lines of:
> "In both cases the new response code MUST be registered with IANA".
> 
>> 
>>> I agree one could simply update the IANA registry with the new code but I was thinking more of how an end point would know that it would be used. That's where registering an extension would make sense. Of course if you made a new version you wouldn't need an extension.
>> 
>> OK. See above.
>> 
>>> ..snip
>>>> Cl.6 para 5: "Otherwise <if> ("channel error")…"
>>>> Should we add an "if" between “Otherwise” and the parenthesis? Please advise on that.
>>> [CNG] If doesn't need to be in parentheses just "Otherwise if …"
>> 
>> You’re the English master! We modified accordingly:
>> 
>> "Otherwise if ("channel error"), it moves back to the IDLE state.”
> [CNG] You can delete the ( and ), i.e. just "Otherwise if "channel error", it... "
>> 
> 
>