Re: [clue] AD Review: draft-ietf-clue-protocol-13

[Roni Even <[e-mail]>]

>> BLOCKER: Section 5.1: The description of <supportedVersions> 
>> describes a scheme in which multiple supported versions can be 
>> listed; and, if the list is omitted, it implies that only the version 
>> described in <v> is supported. This text does not define (nor does 
>> any other text that I can find) what <v> should be set to when 
>> <supportedVersions> is used. Intuitively, it seems that <v> should be 
>> set to the largest minor version of the smallest major version 
>> advertised in <supportedVersions>, but that (or whatever the correct 
>> answer is) needs to be clearly spelled out.
>>
> [SPR] I believe we were giving for granted that “v” should be, in such 
> case, the highest supported version (i.e., largest major and larger 
> minor numbers). Now that you make me think around that, I would simply 
> say that the “v” attribute MUST be set to one of the versions that the 
> entity in question supports, as per the <supportedVersions> list. I 
> can, e.g., decide that I send an ‘options’ with “v=12.23” if the 
> <supportedVersions> list is like in the following:
>
> <version>33.44</version>
> <version>27.0</version>
> <version>12.345</version>
> <version>1.44</version>

I think this formulation is a problem. I assume the intention behind the "v" field is that some implementation that receives a version number in the "v" field with a major number higher than it understands is supposed to close the connection, since it runs a risk of misinterpreting the contents of messages. So, in your example, if you sent "v=12.23" to my implementation that only spoke major version 1, I would reject it, even though you also support major version 1. That's why I was thinking it should contain the smallest major version being advertised.

The minor version is obviously less useful in this context, since they're defined to be backwards and forwards compatible, but it's more useful to know the highest minor version supported than some random minor version, as it indicates the full feature set that is supported. 
The reason it's less useful is that the value can be parsed out of the <version> list.


[Roni] I think that even selecting the lower major for "v" does not solve the problem since in the example above the Channel Receiver may support any of the above versions and the channel initiator does not know which. I think recommending the higher version is also how RFC6120 specify it