[Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)

["Alia Atlas" <[e-mail]>]

Alia Atlas has entered the following ballot position for
draft-ietf-roll-mpl-parameter-configuration-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Sec 2.1, it says: "OPTION_MPL_PARAMETERS:  DHCPv6 option identifier
(not yet assigned)"
Instead of "not yet assigned", it would be better to use TBD1 and then
reference TBD1 in the IANA section.
That makes it easy and clear how to update the draft as it is prepared to
be an RFC.