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

["roll issue tracker" <[e-mail]>]

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


Comment (by [e-mail]):

 Date: Tue, 20 Nov 2012 22:59:27 +0000
 From: Robert Cragie <[e-mail]>
 To: Michael Richardson <[e-mail]>
 Cc: [e-mail]
 Subject: Re: [Roll] [roll] #108: trickle-mcast: should there be an
         explicit version field?
 Message-ID: <[e-mail]>
 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"


 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>

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-roll-trickle-
  [e-mail]       |  [e-mail]
     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:3>
roll <http://tools.ietf.org/wg/roll/>