Re: [Roll] [roll] #108: trickle-mcast: should there be an explicit version field?

[Robert Cragie <[e-mail]>]

On 20/11/2012 5:40 PM, Michael Richardson wrote:
>>>>>> "Robert" == Robert Cragie <[e-mail]> writes:
>      Robert> Regarding having an explicit version field: I have thought
>      Robert> about this more and I am happy with the text in draft 02 as
>      Robert> it stands, as it leaves it free for future versions to
>      Robert> define the reserved fields in more detail providing at least
>      Robert> 1 bit is set to 1. I certainly wouldn't see the point in
>      Robert> making the whole set of reserved bits into a version number
>      Robert> as this could limit flexibility in the future.
>
> What would an existing implementation do when it sees these reserved
> bits?
<RCC>Discard the packet if any are set - that's what's specified now. So 
this can be implicitly regarded as a version number, where (rsvd == 0) 
-> version 0, (rsvd > 0) -> not version 0.</RCC>
>
> Turning reserved bits into a version number after the fact is a bad
> idea... how much would change with the version number?
> This needs to be thought out beforehand.
<RCC>
So there are currently 5 reserved bits. How many do we want to use for a 
version number? It could be argued that one bit is enough as to some 
extent in the next version, you are free to change the format providing 
earlier versions discard newer versions.

So maybe:

       0                   1 2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |  Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | S |M|V| rsv   |   sequence    |      seed-id (optional)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

would be adequate where:

V = version number. Must be set to 0, must be received as 0.

Some may argue about backwards compatibility but this means you have to 
ignore bits set on receipt and you are not at liberty to change the 
header apart from filling in the reserved fields. This only works 
acceptably if the fields aren't tightly packed and there are plenty of 
reserved fields - not in this case.
</RCC>