Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT)
Yusuke DOI <yusuke.doi@toshiba.co.jp> Wed, 08 July 2015 23:26 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 30A6D1A1ABB; Wed, 8 Jul 2015 16:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.859
X-Spam-Level:
X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] 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 80mKzn1r3j2H; Wed, 8 Jul 2015 16:26:04 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053271A1AB9; Wed, 8 Jul 2015 16:25:57 -0700 (PDT)
Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id t68NPumW026490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 08:25:56 +0900 (JST)
Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NPtEL006762; Thu, 9 Jul 2015 08:25:55 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 887; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t68NPtUd006759; Thu, 9 Jul 2015 08:25:55 +0900
Received: (from root@localhost) by arc11.toshiba.co.jp id t68NPt5U024470; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA24469; Thu, 9 Jul 2015 08:25:55 +0900
Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id t68NPtX6025535; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t68NPtXY005611; Thu, 9 Jul 2015 08:25:55 +0900 (JST)
Received: from [133.199.17.8] (ivpn-2-8.mobile.toshiba.co.jp [133.199.17.8]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id D4D4218F4B6; Thu, 9 Jul 2015 08:25:53 +0900 (JST)
Message-ID: <559D3EE0.4000904@toshiba.co.jp>
Date: Thu, 09 Jul 2015 00:16:48 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <20150708080446.7700.80046.idtracker@ietfa.amsl.com>
In-Reply-To: <20150708080446.7700.80046.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/gPRBrWxampwh5UsOKZiOmdD1A0o>
Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org
Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with 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, 08 Jul 2015 23:26:07 -0000
Hi Stephen, Thank you very much for the review. On 2015-07-08 17:04, Stephen Farrell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I don't get the update model - if all MPL forwarders have > to use the same parameters but they don't all do DHCPv6 at > the same time, then won't new parameter settings take a > while to propagate to most of the network? And won't that > cause a problem? Don't you need a "start using this set of > parameters in N seconds" field in the dhcp option to handle > that? This is not a DISCUSS as I think it relats to Barry's > so please try address this when addressing that. I believe your question is beyond Barry's DISCUSS. Let me clarify it here. In general, all MPL Forwarders should have identical parameters to make a better load balance. However, the parameter synchronization is 'better to have' and even if there are mismatched parameter set it does not break interoperability or operation. Some forwarders would do more retransmission than others if the parameter is not identical. I consider this is acceptable behavior for MPL. To ease the unbalanced retransmission, I added some text to limit parameter update ratio per information refresh time. For join and leave on forwarders, some node may not be able to receive messages during transitive period (not all forwarders have joined). However, adding some delay on the configuration will not ease the case. It's up to application to send a multicast message after all nodes have acquired the newest configuration, or to send a message during constructing MPL domain if the message is good even for delivered to a fraction of nodes. > - please do not pretend rfc 3315 is a solution for anything > unless you mean it and I don't think you do. 3315 is I think > the canonical example for mythical security:-( To be honest, my situation is to go without DHCPv6 security and expects network-level security. We do strict node admission using RFC5191 and assumes no untrusted node in a network. I'm wondering how would I describe security consideration beyond my situation in the document, without relying on 3315. I appreciate if you give me some suggestion on this topic. Thanks, Yusuke
- [Roll] Stephen Farrell's No Objection on draft-ie… Stephen Farrell
- Re: [Roll] Stephen Farrell's No Objection on draf… Yusuke DOI
- Re: [Roll] Stephen Farrell's No Objection on draf… Stephen Farrell