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

[Christian Groves <[e-mail]>]

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... "
>