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

From: "roll issue tracker" <[email-masked]>
Date: Thu, 01 Nov 2012 14:29:54 -0000

#108: trickle-mcast: should there be an explicit version field?

 > 3. Version field:
 > I think adding an explicit version field ( 2 bits should be enough)
 > will help.

 OK.  Any additional inputs from the WG?

-- 
-----------------------------+---------------------------------------------
 Reporter:  mcr@…            |      Owner:  draft-ietf-roll-trickle-mcast@…
     Type:  defect           |     Status:  new
 Priority:  major            |  Milestone:
Component:  trickle-mcast    |    Version:
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+---------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/108>
roll <http://tools.ietf.org/wg/roll/>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 19 Nov 2012 12:48:26 +0000

Regarding having an explicit version field: I have thought about this 
more and I am happy with the text in draft 02 as it stands, as it leaves 
it free for future versions to define the reserved fields in more detail 
providing at least 1 bit is set to 1. I certainly wouldn't see the point 
in making the whole set of reserved bits into a version number as this 
could limit flexibility in the future.

Robert

---

From: Robert Cragie <[email-masked]>
Date: Tue, 20 Nov 2012 22:59:27 +0000

On 20/11/2012 5:40 PM, Michael Richardson wrote:
>>>>>> "Robert" == Robert Cragie <[email-masked]> 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>

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 30 Nov 2012 19:12:11 -0000

Comment (by [email-masked]):

 {{{

      0                   1                   2                   3

 would be adequate where:

 }}}

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-roll-trickle-
  [email-masked]       |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  trickle-     |     Version:
  mcast                  |  Resolution:
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/108#comment:1>
roll <http://tools.ietf.org/wg/roll/>