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

Yusuke DOI <yusuke.doi@toshiba.co.jp> Wed, 02 September 2015 06:49 UTC

Return-Path: <yusuke.doi@toshiba.co.jp>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E71AD079; Tue, 1 Sep 2015 23:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.197
X-Spam-Level:
X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8aR1FrDsw08; Tue, 1 Sep 2015 23:49:19 -0700 (PDT)
Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1161B34EA; Tue, 1 Sep 2015 23:49:12 -0700 (PDT)
Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t826nAUW022195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2015 15:49:10 +0900 (JST)
Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t826nA3t018902; Wed, 2 Sep 2015 15:49:10 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 419; Wed, 2 Sep 2015 15:49:10 +0900 (JST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t826nAId018894; Wed, 2 Sep 2015 15:49:10 +0900
Received: (from root@localhost) by arc1.toshiba.co.jp id t826n93v009564; Wed, 2 Sep 2015 15:49:09 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id RAA09544; Wed, 2 Sep 2015 15:49:09 +0900
Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t826n7BC023712; Wed, 2 Sep 2015 15:49:08 +0900 (JST)
Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t826moGt028168; Wed, 2 Sep 2015 15:48:50 +0900 (JST)
Received: from [133.199.145.164] (ivpn-5-164.mobile.toshiba.co.jp [133.199.145.164]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 1013518F4A6; Wed, 2 Sep 2015 15:48:48 +0900 (JST)
Message-ID: <55E69B47.8070102@toshiba.co.jp>
Date: Wed, 02 Sep 2015 15:46:31 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Routing Over Low power and Lossy networks <roll@ietf.org>, The IESG <iesg@ietf.org>
References: <20150708195730.18658.96701.idtracker@ietfa.amsl.com>
In-Reply-To: <20150708195730.18658.96701.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/L-y8L0lp0PzLvqTMB_V6X6XttHM>
Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org
Subject: Re: [Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2015 06:49:22 -0000

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