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

Yusuke DOI <yusuke.doi@toshiba.co.jp> Thu, 02 July 2015 00: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 6758F1B2B3A; Wed, 1 Jul 2015 17:44:42 -0700 (PDT)
X-Quarantine-ID: <aRjL9S9LgkbL>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level:
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aRjL9S9LgkbL; Wed, 1 Jul 2015 17:44:40 -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 C1C5C1B2B39; Wed, 1 Jul 2015 17:44:39 -0700 (PDT)
Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t620iauu006671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 09:44:36 +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 t620ibmr007069; Thu, 2 Jul 2015 09:44:37 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 618; Thu, 2 Jul 2015 09:44:37 +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 t620ibxJ007060; Thu, 2 Jul 2015 09:44:37 +0900
Received: (from root@localhost) by arc1.toshiba.co.jp id t620iaBJ014358; Thu, 2 Jul 2015 09:44:36 +0900 (JST)
Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA14321; Thu, 2 Jul 2015 09:44:34 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t620iX6K002790; Thu, 2 Jul 2015 09:44:33 +0900 (JST)
Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t620iRuX016357; Thu, 2 Jul 2015 09:44:27 +0900 (JST)
Received: from [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8] (unknown [IPv6:2001:200:1b1:1010:e95c:15be:95b0:42d8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id A7DDD18F4D9; Thu, 2 Jul 2015 09:44:28 +0900 (JST)
Message-ID: <5594896C.4090802@toshiba.co.jp>
Date: Thu, 02 Jul 2015 09:44:28 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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: <D1B98C80.BD4AE%aretana@cisco.com>
In-Reply-To: <D1B98C80.BD4AE%aretana@cisco.com>
Content-Type: text/plain; charset=euc-kr
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t620ibxJ007060
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/AW_9xsD-A4O7pCmnB3dION0FHzU>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <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: <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: Thu, 02 Jul 2015 00:44:42 -0000

Hi Alvaro,

Thank you again for the review. I think the document is almost ready and I will submit it later today.

Best Regards,

Yusuke

On 2015-07-02 01:30, Alvaro Retana (aretana) wrote:
> Yusuke:
> 
> Hi!
> 
> I didn’t see a follow up from you, but I’m assuming that we’re on the same
> page.
> 
> This draft is on the agenda for discussion in the IESG next week (July/9).
>   The IETF Last Call has ended, and there are outstanding comments (minor
> and nits) from IANA, SecDir and GenART.
> 
> Please take a look at the comments and post an update before next week.
> The sooner the better to give the IESG a good chance to review the latest
> text.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> On 6/18/15, 1:49 PM, "Roll on behalf of Alvaro Retana (aretana)"
> <roll-bounces@ietf.org on behalf of aretana@cisco.com> wrote:
> 
>> On 6/17/15, 1:43 PM, "Yusuke DOI" <yusuke.doi@toshiba.co.jp> wrote:
>>
>> Yusuke:
>>
>> Hi!
>>
>> . . .
>>>> 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...
>> . . .
>>>
>>>>   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.
>>
>> The use of ³MAY² above gives the impression that joining is optional.  But
>> you¹re saying that even if the node wants to join it may not be able to,
>> which is different.
>>
>> Suggestion:
>>
>> OLD>
>>
>>    If a DHCPv6 client requests and receives MPL Parameter Configuration
>>    Option, the node MAY join the MPL domain given by the option and act
>>    as an MPL forwarder.
>>
>>
>> NEW>
>>
>>    If a DHCPv6 client requests and receives MPL Parameter Configuration
>>    Option, the node SHOULD join the MPL domain given by the option and act
>>    as an MPL forwarder.  Note that there may be cases in which a node may
>>    fail is to join a domain (or domains) due to local resource
>> constraints.
>>
>> I¹m not sure if you/the WG want to add something else to that paragraph..
>>
>>
>>
>>>>        * "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.
>>> """
>>
>> How about this instead:
>>
>> NEW>
>>
>>    A node SHOULD leave an MPL domain if it receives an updated
>>    MPL Parameter Configuration Option without a configuration for the
>>    MPL domain, unless it has overriding external configuration.
>>
>>
>> I¹m not sure if ³external² is the right word..or if ³manual² might be
>> better.  Look at the point #1 above about how other nodes may be
>> configured.
>>
>> In this section (2.3) there¹s a priority of configuration shown:
>>
>>    The priority of MPL Parameter Configuration applied for an MPL Domain
>>    is as follows (high to low).
>>
>>    o  Specific MPL Parameter Configuration to the MPL Domain (optlen=34)
>>
>>    o  Wildcard MPL Parameter Configuration (optlen=18)
>>
>>    o  Default configuration given in the MPL specification.
>>
>>
>> But there is no mention anywhere in the document to external/manual
>> configuration.  Where in that priority list should it fit?
>>
>> Thanks!
>>
>> Alvaro.
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>