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

"Alvaro Retana (aretana)" <> Wed, 09 September 2015 12:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 911511B2A2A; Wed, 9 Sep 2015 05:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uSf0BZ6Q4-oo; Wed, 9 Sep 2015 05:30:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97ACB1B2AD6; Wed, 9 Sep 2015 05:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4442; q=dns/txt; s=iport; t=1441801857; x=1443011457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wS10l6shYC0MSU+XBa9J6ag8BXdaATheEgNOZ8sZAhE=; b=dx8oJeFrQx+nTV4DCdAN2PevW9ZG2MVnJV8iAxGhvGhB3iLqB2VZ4LXt lWeHcsnx5sxKMsmpLHPx7UIQXNstw/etAZ5XZEpYGQTC0pkXqQhsGVHhV dqpHYth0g/1m8xg84qmgTfMIg+so+PgRGSiVPqVpMxtHJcJWds31iES6t w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,496,1437436800"; d="scan'208";a="30700095"
Received: from ([]) by with ESMTP; 09 Sep 2015 12:30:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t89CUuVY006211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 12:30:56 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 07:30:55 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 07:30:55 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 07:30:55 -0500
From: "Alvaro Retana (aretana)" <>
To: Yusuke DOI <>, Brian Haberman <>
Thread-Topic: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)
Thread-Index: AQHQuYnUlrU5N5zZwECQSPYsc22SyQ==
Date: Wed, 9 Sep 2015 12:30:54 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, Routing Over Low power and Lossy networks <>, "" <>, The IESG <>, "" <>, "" <>
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, 09 Sep 2015 12:30:59 -0000

[Explicitly adding Brian.]

On 9/2/15, 3:32 AM, "Yusuke DOI" <> wrote:

>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
>> 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
>> 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
>> 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?
>> 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,