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

"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 09 September 2015 12:27 UTC

Return-Path: <aretana@cisco.com>
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 1BF9C1A904A; Wed, 9 Sep 2015 05:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 BMC0BwgBnQ92; Wed, 9 Sep 2015 05:27:50 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A4E1A9058; Wed, 9 Sep 2015 05:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6870; q=dns/txt; s=iport; t=1441801664; x=1443011264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LQw05vFDDMdCrUoaEpKnr7Uoq1acRLs6q0vICXu94eA=; b=BIDSr5f64+ILg1gTNa8dknDruw5Xnp97+M77flji6TH2163kt9tHNoG4 5MF55PWAEfpvIHWw5NUiN9ef7xjwiBEMgw6ugnFkZwKizsGW/Ra1dXSWW Wq5tGlq7Ys0YcLJSB65tWL0Gw7St9CiATn/ZNSjxLH+Qax6yXNP6gg7tS 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAgD3JPBV/4kNJK1dgyNUaQa9HgEJgW0MhXcCgTc4FAEBAQEBAQGBCoQjAQEBAwEBAQE3NAsQAgEIGB4FCycLJQIEAQ0FG4gLCA3KEgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnMBg3WBBYQpEQFRAgWELAWHMYptgzgBhQmHcIFMhDODH3SIMYRJg2wmgkKBPnEBhwk6gQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,496,1437436800"; d="scan'208";a="186442445"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 09 Sep 2015 12:27:42 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t89CRgKg011879 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 12:27:42 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 07:27:41 -0500
Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-aln-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 07:27:41 -0500
Received: from xmb-aln-x15.cisco.com ([169.254.9.140]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 07:27:41 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Yusuke DOI <yusuke.doi@toshiba.co.jp>, Alia Atlas <akatlas@gmail.com>
Thread-Topic: [Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)
Thread-Index: AQHQubhVExP7PSQ+FEaLhHT/au8Qjg==
Date: Wed, 9 Sep 2015 12:27:40 +0000
Message-ID: <D2159DB7.CE123%aretana@cisco.com>
References: <20150708195730.18658.96701.idtracker@ietfa.amsl.com> <55E69B47.8070102@toshiba.co.jp>
In-Reply-To: <55E69B47.8070102@toshiba.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.36.7.20]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8661A389A19DB74DAE5179E0AA8A149C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/aR37cv3fgzAliQvbFceUB3naMVM>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "draft-ietf-roll-mpl-parameter-configuration@ietf.org" <draft-ietf-roll-mpl-parameter-configuration@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "maria.ines.robles@ericsson.com" <maria.ines.robles@ericsson.com>, The IESG <iesg@ietf.org>, "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" <draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org>, "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" <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, 09 Sep 2015 12:27:52 -0000

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