Re: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)

Yusuke DOI <> Wed, 02 September 2015 07:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5CC541B4B78; Wed, 2 Sep 2015 00:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hWs6kOj5jBqV; Wed, 2 Sep 2015 00:36:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBA231B4AAC; Wed, 2 Sep 2015 00:36:16 -0700 (PDT)
Received: from ([]) by with ESMTP id t827aFYC014949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2015 16:36:15 +0900 (JST)
Received: from tsbmgw-mgw02 (localhost []) by (8.13.8/8.14.5) with ESMTP id t827aFm6028231; Wed, 2 Sep 2015 16:36:15 +0900
Received: from localhost ([]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 792; Wed, 2 Sep 2015 16:36:14 +0900 (JST)
Received: from ([]) by (8.13.8/8.14.5) with ESMTP id t827aEQJ028219; Wed, 2 Sep 2015 16:36:14 +0900
Received: (from root@localhost) by id t827aEFU028121; Wed, 2 Sep 2015 16:36:14 +0900 (JST)
Received: from [] by with ESMTP id SAA28116; Wed, 2 Sep 2015 16:36:14 +0900
Received: from (localhost []) by with ESMTP id t827aExc019268; Wed, 2 Sep 2015 16:36:14 +0900 (JST)
Received: from by id t827aDPX026082; Wed, 2 Sep 2015 16:36:13 +0900 (JST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 9973B18F4A6; Wed, 2 Sep 2015 16:36:12 +0900 (JST)
Message-ID: <>
Date: Wed, 02 Sep 2015 16:32:14 +0900
From: Yusuke DOI <>
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Routing Over Low power and Lossy networks <>, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Sep 2015 07:36:18 -0000

Hi Brian,

Thank you very much for your kind review.
I updated the document. Sorry for late response.

On 2015-07-08 23:15, Brian Haberman wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Some of these points come from Bernie Volz's INT-Dir review...
> 1. This is one of the few options that is not a singleton, as defined in
> section 16 of RFC 7227. While the use of multiple options seems
> appropriate here, it would be best to clarify that clients (section 2.2)
> and servers (section 2.4) must be able to support multiple instances of
> this option. Given the discussion around supporting multiple MPL domains
> in draft-ietf-roll-trickle-mcast, I would expect there to be situations
> where the option appears multiple times.
> 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief
> discussion of the role of the MPL Domain Address and include a reference
> to [I-D.ietf-roll-trickle-mcast].

Thank you for suggestion. I added some notes on multiple options and 

> 3. In section 2.6 (Operational Considerations), the text is a bit odd.
> Why should a parameter set not be updated more often than twice the
> Information Refresh Time? How does the failure to refresh the option play
> with text in section 2.3 that indicates a missing option means the node
> should leave the MPL domain? Perhaps defining what "failure to refresh"
> means (i.e., I think it refers to lack of a DHCPv6 server response to a
> Renew or Information Request). Note also that Information Refresh Time is
> only applicable to Information-Request messages (see RFC 4242) so work
> may be needed as to how this this sections relate to Renew/Rebind
> operations? I am also not sure why 2.6 is a standalone section when it
> appears to be only applicable to clients and should be in either section
> 2.2 or 2.3.

I modified text with reference to RFC6206, with clarification on 'failure'

If a DHCPv6 client with an MPL forwarder configured by the MPL Parameter 
Configuration Option is unable to receive a valid response from a server 
within T2 of the las\
t valid DHCPv6 message sent from the server (if stateful) or twice the 
Information Refresh Time (if stateless), it MUST suspend the MPL 
forwarders of the MPL domains \
configured by the option. MPL forwarders configured by other methods 
such as static configuration file MUST NOT be suspended.

Clients MUST ignore all MPL Parameter Configuration Options if the 
options in a DHCPv6 message contains any invalid value (e.g., it uses 
reserved all-0 or all-1 value\
s in parameters). In this case, the message is considered not received 
in MPL context and the condition described in the previous paragraph 

> 1. I support Barry's DISCUSS on the lack of an option potentially forcing
> a node to leave an MPL domain.

I hope answer to Barry's DISCUSS can make this resolved.

> 2. Why is the text in Appendix B not in the Operational Considerations
> section?

No reason to have separate section so I merged it on local copy (will be 
submitted as -08). Thanks for suggestion.

> 3. Please be consistent with the use of MUSTs and SHALLs.  Pick one.

Agreed and fixed.

> 4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a
> client discard the option if the reserved bits are set? I would think
> you'd want to use a new option if you're changing things drastically? But
> it certainly is your choice as to whether you want to do that. Perhaps a
> better reason is if one of the not-permitted values is used (such as 0
> and 'all-bits-set') where are clearly reserved? 0 in many of these case
> could be bad since that would yield 0 time values? This really is up to
> you, but do think about what you might want to do any maintain backwards
> compatibility. Adding a new flag bit to the reserved field is probably
> not going to break things if existing implementations ignore the bit(s).

Thanks. As I stated on Alia's DISCUSS, I changed the definitions of 
reserved bits as you suggested.

Best Regards,