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