[Roll] [roll] #172 (draft-doi-roll-mpl-parameter-configuration): Describe which parameters are considered time values

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

#172: Describe which parameters are considered time values

 From Alia Atlas 07-08, source: https://datatracker.ietf.org/doc/draft-
 ietf-roll-mpl-parameter-configuration/ballot/

 In general, this draft is well-written and easy to understand.  I do have
 a few points of technical clarity that I think are important.

 First, a minor point on the "Reserved" bits.  In Sec 2.1, it says "Z (7
 bits):  Reserved.  Should be 0." and then in Sec 2.2:
 "   Clients MUST discard the MPL Parameter Configuration Option if it is
 invalid (e.g., it sets reserved bits)."  Frequently,
 Reserved bits are available for future enhancements - so setting to zero
 on write and ignoring the value on read is a useful
 default.  If these bits are really always going to be zero and interpreted
 as an error, then could you rename them to MBZ (Must Be Zero) and indicate
 in the field definition that a value other than zero is an error.   Also,
 from what I read in the rest of the draft,
 if an invalid option is received, that could cause the client to be
 removed from the MPL region.  Could you clarify in the document what the
 expected behavior is if an invalid option is discarded?  Is that like
 having no option?  Is that pretending that the client didn't get one and
 staying with the previous option?  It seems like it would be pretty easy
 to remove a client from the MPL region by flipping a bit.  I would also
 like to see better clarification of how an option is considered invalid;
 while it may seem obvious, it's these details that impact
 interoperability.  In the write-up, I don't see any indications that there
 have been interoperable implementations yet?

 Second, given that the meaning of the *_IMAX values is based on RFC6206
 (as indicated in the update history) and that the *_IMAX and *_IMIN are
 confusing values, PLEASE have a reference to RFC6206.   To continue, it
 seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units -
 as is explained in RFC6206 where *_IMAX is the number of doublings and
 *_IMIN is the value in milliseconds.  However, in draft-ietf-roll-trickle-
 mcast-12, Section 5.4, the definition of DATA_MESSAGE_IMIN and
 DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given as:

 "   DATA_MESSAGE_IMIN  The minimum Trickle timer interval, as defined in
       [RFC6206], for MPL Data Message transmissions.  DATA_MESSAGE_IMIN
       has a default value of 10 times the expected link-layer latency.

    DATA MESSAGE_IMAX  The maximum Trickle timer interval, as defined in
       [RFC6206], for MPL Data Message transmissions.  DATA_MESSAGE_IMAX
       has a default value equal to DATA_MESSAGE_IMIN.

    CONTROL_MESSAGE_IMIN  The minimum Trickle timer interval, as defined
       in [RFC6206], for MPL Control Message transmissions.
       CONTROL_MESSAGE_IMIN has a default value of 10 times the worst-
       case link-layer latency.

    CONTROL_MESSAGE_IMAX  The maximum Trickle timer interval, as defined
       in [RFC6206], for MPL Control Message transmissions.
       CONTROL_MESSAGE_IMAX has a default value of 5 minutes.
 "

 Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is
 only an 8-bit value, they are expected to have different ranges.
 Additionally, it's quite unclear which actually needs to be divided by
 TUNIT.  The draft describes this as happening for DM_IMIN and C_IMIN, but
 then goes on to say
   " Note that all time values (Trickle timers and expiration periods) are
    in TUNIT milliseconds precision.  For example, if TUNIT is 20 and the
    data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
    DM_IMIN shall be set to 50."

 Unfortunately, the draft doesn't describe which parameters are time values
 and apparently draft-ietf-roll-trickle-mcast-12
 has some confusion as well.  For instance, CONTROL_MESSAGE_IMAX is defined
 as a time value (5 minutes).

 I suspect that the solution here is to clarify/fix draft-ietf-roll-
 trickle-mcast-12, add references in Sec 2 to where the parameters
 are defined, indicate which are considered "time values", and clean up the
 language in Sec 2.1.

 Thanks!  It looks like a useful document to address an operational problem
 once these clarity issues are addressed.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  [e-mail]          |  [e-mail]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-doi-roll-mpl-      |    Version:
  parameter-configuration            |   Keywords:
 Severity:  Submitted WG Document    |
-------------------------------------+-------------------------------------

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