Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration

Ines Robles <mariainesrobles@googlemail.com> Wed, 17 June 2015 20:01 UTC

Return-Path: <mariainesrobles@googlemail.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 A8C6F1B2DB6; Wed, 17 Jun 2015 13:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 rX56T9ssPO9a; Wed, 17 Jun 2015 13:01:13 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AB91B2DB1; Wed, 17 Jun 2015 13:01:10 -0700 (PDT)
Received: by labbc20 with SMTP id bc20so40730100lab.1; Wed, 17 Jun 2015 13:01:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kqt8qRnzb9GSzyxMW7wKNrlVUbq19iMPRysrVx6YSCY=; b=Oer9eD+c7vwA1CxdVi9PVgXTlUxih8wVNFEXzEHbU1Imonn6i7JbbVppMUi85Kng7f IqiRC/KUtytkCQrMyjg05a+rpv3bRC3Gg6DNQLkZZ99pPFDxiDoCwn4pCHiHtDBNg7zd 8kc+OkmmmPi5RLXiUv5j7oKViP89sJV4KLgm4J1C747rhW3wzC0WgHH1pnPkfes/HvtO iUdtKmukXXxp9v4S2HKVeFNj468vlbaxRmuLo7FG3pG0xkNGid56SI9DrnSTaTq8XVBR jpj86Lwud2Gqx/q1WUpUPF/bQUA+ubBnt/qUXfBrYw3yNhREYqRYCIDOQAN4TuKu+BnS DeJQ==
MIME-Version: 1.0
X-Received: by 10.152.1.4 with SMTP id 4mr9608090lai.25.1434571269314; Wed, 17 Jun 2015 13:01:09 -0700 (PDT)
Received: by 10.25.208.70 with HTTP; Wed, 17 Jun 2015 13:01:09 -0700 (PDT)
Received: by 10.25.208.70 with HTTP; Wed, 17 Jun 2015 13:01:09 -0700 (PDT)
In-Reply-To: <5581A3AD.8060309@toshiba.co.jp>
References: <D1A4F4BA.B8391%aretana@cisco.com> <5581A3AD.8060309@toshiba.co.jp>
Date: Wed, 17 Jun 2015 23:01:09 +0300
Message-ID: <CAP+sJUf57dLMCykbsDwDodAsbzpEJ491sa85vP5jLg7tS5v0YA@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: roll <roll@ietf.org>, Yusuke DOI <yusuke.doi@toshiba.co.jp>
Content-Type: multipart/alternative; boundary=089e013c66a8e9a09b0518bc2658
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/6WIEABDoPvNKplB4fIIDBx7NEw8>
Cc: roll-chairs@ietf.org, MARIA INES ROBLES <maria.ines.robles@ericsson.com>, draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org
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 20:01:15 -0000

Hi Yusuke,
you could update the document in a couple of days.
Thank you very much
On 17 Jun 2015 19:44, "Yusuke DOI" <yusuke.doi@toshiba.co.jp> wrote:

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