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

From: "roll issue tracker" <[email-masked]>
Date: Thu, 16 May 2013 15:07:29 -0000

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

Comment (by [email-masked]):

 Date: Mon, 19 Nov 2012 12:48:26 +0000
 From: Robert Cragie <[email-masked]>
 To: [email-masked]
 Subject: Re: [Roll] [roll] #108: trickle-mcast: should there be an
         explicit version field?
 Message-ID: <[email-masked]>
 Content-Type: text/plain; charset="utf-8"; Format="flowed"

 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

-- 
-------------------------+-------------------------------------------------
 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:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 16 May 2013 15:09:26 -0000

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

 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>

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

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 20 May 2013 23:15:02 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 The version field was added in the version 03 - Section 6.1 “V: 1-bit
 flag. 0 indicates that the MPL Option conforms to this specification.  MPL
 Data Messages with an MPL Option in which this flag is 1 MUST be dropped “

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

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