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

[Explicitly adding Alia.]

On 9/2/15, 2:46 AM, "iesg on behalf of Yusuke DOI" <iesg-bounces@ietf.org
on behalf of yusuke.doi@toshiba.co.jp> wrote:

>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-configurat
>>ion/
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>
>