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

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

Return-Path: <aretana@cisco.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 911511B2A2A; Wed, 9 Sep 2015 05:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSf0BZ6Q4-oo; Wed, 9 Sep 2015 05:30:58 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97ACB1B2AD6; Wed, 9 Sep 2015 05:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0ABAgAtJfBV/4UNJK1WB4MjgT0GvR4BCYdwAoE3OBQBAQEBAQEBgQqEJAEBBDoNMhACAQgYHgULMiUCBAENBYguunyPIwEBAQEBAQEBAQEBAQEBAQEBAQEZhnMBg3WBBYRBA0gHhCwBBIcxjiUBjHmBTIQzkQ2DbCaCQoE+cYcBIyCBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,496,1437436800"; d="scan'208";a="30700095"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2015 12:30:56 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (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 xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 07:30:55 -0500
Received: from xhc-rcd-x14.cisco.com (173.37.183.88) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 07:30:55 -0500
Received: from xmb-aln-x15.cisco.com ([169.254.9.140]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 07:30:55 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Yusuke DOI <yusuke.doi@toshiba.co.jp>, Brian Haberman <brian@innovationslab.net>
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: <D2159E9D.CE128%aretana@cisco.com>
References: <20150708141537.17660.50617.idtracker@ietfa.amsl.com> <55E6A5FE.2050309@toshiba.co.jp>
In-Reply-To: <55E6A5FE.2050309@toshiba.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.36.7.20]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7E53FDD0EB7780468B8ADB7523B3E617@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/f6ax_STbHeYDqKberGqNNjLt7AU>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "draft-ietf-roll-mpl-parameter-configuration@ietf.org" <draft-ietf-roll-mpl-parameter-configuration@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "maria.ines.robles@ericsson.com" <maria.ines.robles@ericsson.com>, The IESG <iesg@ietf.org>, "draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org" <draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org>, "draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org" <draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org>
Subject: Re: [Roll] Brian Haberman's Discuss on draft-ietf-roll-mpl-parameter-configuration-06: (with DISCUSS and COMMENT)
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: Wed, 09 Sep 2015 12:30:59 -0000

[Explicitly adding Brian.]

On 9/2/15, 3:32 AM, "Yusuke DOI" <yusuke.doi@toshiba.co.jp> 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:
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> 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
>reference.
>
>> 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'
>
><draft>
>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
>applies.
></draft>
>
>> 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,
>
>Yusuke
>