[Roll] Alia Atlas' Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)
"Alia Atlas" <akatlas@gmail.com> Wed, 08 July 2015 19:57 UTC
Return-Path: <akatlas@gmail.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 EB3A91A875D; Wed, 8 Jul 2015 12:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.898
X-Spam-Level:
X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] 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 Cr-t-wSxh-AF; Wed, 8 Jul 2015 12:57:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3755A1A871A; Wed, 8 Jul 2015 12:57:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alia Atlas <akatlas@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150708195730.18658.96701.idtracker@ietfa.amsl.com>
Date: Wed, 08 Jul 2015 12:57:30 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/mYgVVJLW2JYztBGSxhlC1Wy2J5s>
Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org
Subject: [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
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, 08 Jul 2015 19:57:33 -0000
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] Alia Atlas' Discuss on draft-ietf-roll-mpl… Alia Atlas
- Re: [Roll] Alia Atlas' Discuss on draft-ietf-roll… Yusuke DOI
- Re: [Roll] Alia Atlas' Discuss on draft-ietf-roll… Alvaro Retana (aretana)