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

From: Yusuke DOI <[email-masked]>
Date: Wed, 02 Sep 2015 15:46:31 +0900

Dear Alia,

I finally updated the draft. I think the update can resolve your 
discussion point. Sorry for belated update.

 > 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)."
(snip)

Thanks for the comment. I clarified definition of the reserved bit as 
you suggested.

 > 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.

I added the reference to RFC6206 and cited definition from the RFC /w 
examples.

I hope it resolves your discussion point. Thanks again for your kind review.

Yusuke

On 2015-07-09 4:57, Alia Atlas wrote:
> 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.
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 9 Sep 2015 12:27:40 +0000

[Explicitly adding Alia.]

On 9/2/15, 2:46 AM, "iesg on behalf of Yusuke DOI" <[email-masked]
on behalf of [email-masked]> wrote:

>> Please refer to 
>>https://www.ietf.org/iesg/statement/discuss-criteria.html