Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration
Yusuke DOI <yusuke.doi@toshiba.co.jp> Wed, 17 June 2015 16:44 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 144C51B2A70; Wed, 17 Jun 2015 09:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.497
X-Spam-Level: **
X-Spam-Status: No, score=2.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 3x6taG2622Ql; Wed, 17 Jun 2015 09:44:04 -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 A443E1B2A56; Wed, 17 Jun 2015 09:43:34 -0700 (PDT)
Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t5HGhVeS015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2015 01:43:31 +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 t5HGhVxh024607; Thu, 18 Jun 2015 01:43:31 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 280; Thu, 18 Jun 2015 01:43:31 +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 t5HGhVjm024598; Thu, 18 Jun 2015 01:43:31 +0900
Received: (from root@localhost) by arc1.toshiba.co.jp id t5HGhV44010091; Thu, 18 Jun 2015 01:43:31 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id BAA10088; Thu, 18 Jun 2015 01:43:31 +0900
Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t5HGhUqJ017102; Thu, 18 Jun 2015 01:43:30 +0900 (JST)
Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t5HGhUk8024934; Thu, 18 Jun 2015 01:43:30 +0900 (JST)
Received: from [133.199.16.46] (ivpn-1-46.mobile.toshiba.co.jp [133.199.16.46]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 593F518F4D8; Thu, 18 Jun 2015 01:43:28 +0900 (JST)
Message-ID: <5581A3AD.8060309@toshiba.co.jp>
Date: Thu, 18 Jun 2015 01:43:25 +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: "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" <draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org>
References: <D1A4F4BA.B8391%aretana@cisco.com>
In-Reply-To: <D1A4F4BA.B8391%aretana@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t5HGhVjm024598
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/cw0F7-2uvjjDrlGOdbFw2LG5edo>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, Ines Robles <maria.ines.robles@ericsson.com>
Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration
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: <http://www.ietf.org/mail-archive/web/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, 17 Jun 2015 16:44:07 -0000
Hi Alvaro, Thank you for the review, (Chairs, it's first time to go throught the process for me. Shall I update the document accordingly as soon as possible? or shall I wait for further discussion?) On 2015-06-16 9:31, Alvaro Retana (aretana) wrote: > Major: > > 1. Sending this Option. It is "RECOMMENDED that all MPL Interfaces > attached to the same link of a given MPL Domain use the same values > for the Trickle Parameters” (I’m quoting > draft-ietf-roll-trickle-mcast because it is not a MUST, even though > rfc6206 talks about “unintended behaviors”). This document says > (Section 2.4) that "the server will send MPL Parameter > Configuration Option only if configured…and the client requested > it”..and (Section 2.2) says that a client "MAY request MPL Parameter > Configuration Option”. In summary, the server won’t send the Option > unless the client requests it; is that what is intended? > Furthermore, the request is optional (I’m assuming there may be > resource considerations here), so there may be cases in which not > all clients request the Option, resulting in potentially mismatched > parameters. Am I interpreting the text correctly? If so, why was > it specified this way (instead of having the server send the Option > (when configured for a specific MPL Domain) always? Does the client > then require configuration to be able to request the additional > configuration parameters? > * I don’t necessarily want to change the behavior proposed, as I’m > assuming it has been discussed in the WG and there are good > reasons behind it. > * Instead, I would like to see some discussion about it in the > Operational Considerations section. Pointing to rfc6206 may be > enough to remind people who are implementing this Option. > * Related to this point: I recommend moving the discussion in > Appendix B to the Operational Considerations section. As Michael stated, I think this is normal behavior and intended behavior. 'unintended behaviors' are mostly unbalanced (unfair) data relay or loss of message. I think the reason is not critical enough to mandate the option. > Minor: > > 1. Section 1 (Introduction): "Some managed wireless mesh networks may > have a DHCP server to configure network parameters.” How common is > the use of DHCP? “Some..may” doesn’t sound like this extension will > be used a lot. How do other networks configure their parameters? > I’m assuming manually.. I have no other experience, but I assume the configuration will be done manually... > 2. Section 2.1. (MPL Parameter Configuration Option Format). The > descriptions of the fields need to be very specific, specially if > invalid contents are to be discarded (per 2.2 and rfc7227). > * When is P set? It may be obvious that it is set > when PROACTIVE_FORWARDING is TRUE, but please specify it. > * TUNIT: "Unit time of times”, what does that mean? > * DM_T_EXP/C_T_EXP: > DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_TIMER_EXPIRATIONS > are defined as the number of expirations, so how do you end with ms? > * The "MPL Domain Address” field is not defined. Thanks, I'll fix them. *_EXP are mistakes. It should be just integers as defined in MPL. > 3. Section 2.3 (MPL Forwarder Behavior) Joining and leaving the > domain. I must be missing something.. > * "the node MAY join the MPL domain given by the option” Why > would the client request the Option and then not join the domain? One reason is resource constraint. As joining to a MPL domain requires certain amount of buffers allocated, a node may fail to join all of the domains given by the option. > * "A node MAY leave from an MPL domain..” The conditions seem to > say that the domain in the Option changed, is that true? If the > domain in the option changed, why would the node not leave the > domain? There's no reason except the domain is configured manually at the same time (the first condition is not met). If there are a manual configuration, implementation may consider it's overriding the DHCPv6 Option. Is this clear?: """ A node SHOULD leave from a MPL domain if the node received a new option without configuration for the MPL domain, unless it has overriding external configuration on the MPL domain. """ > 4. Section 4. (Security Considerations) Please include references and > comments (where needed) to the security considerations in rfc3315 > and rfc7227. Thanks. I'll add this. > Nits: > > 1. The word “draft” is used in a couple of places to refer to this > document and MPL; use “document” instead. > 2. Section 2 (MPL Parameter Configuration Option) s/there are following > 10 parameters/there are the following 10 parameters > 3. 2.5. (DHCPv6 Relay Behavior). A reference to rfc6422 would be nice. > 4. Section 2.6. (Operational Considerations) "A parameter set for an > MPL domain SHOULD NOT be updated more often than two times of > expected refresh interval.” I’m assuming that the “expected refresh > interval” is Information Refresh Time, right? If so, please call it > what it is. > 5. I would consider rfc7227 a Normative Reference. Thanks for pointing it out. Best Regards, Yusuke
- [Roll] AD Review of draft-ietf-roll-mpl-parameter… Alvaro Retana (aretana)
- Re: [Roll] AD Review of draft-ietf-roll-mpl-param… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-mpl-param… Yusuke DOI
- Re: [Roll] AD Review of draft-ietf-roll-mpl-param… Ines Robles
- Re: [Roll] AD Review of draft-ietf-roll-mpl-param… Alvaro Retana (aretana)
- Re: [Roll] AD Review of draft-ietf-roll-mpl-param… Alvaro Retana (aretana)
- Re: [Roll] AD Review of draft-ietf-roll-mpl-param… Yusuke DOI
- Re: [Roll] AD Review of draft-ietf-roll-mpl-param… Yusuke DOI