Re: [Roll] Last Call: <draft-ietf-roll-admin-local-policy-02.txt> (MPL forwarder policy for multicast with admin-local scope) to Informational RFC

peter van der Stok <stokcons@xs4all.nl> Thu, 11 December 2014 09:06 UTC

Return-Path: <stokcons@xs4all.nl>
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 6AC7B1ACD24; Thu, 11 Dec 2014 01:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 pKwN3ChM_thH; Thu, 11 Dec 2014 01:06:00 -0800 (PST)
Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABF41ACD39; Thu, 11 Dec 2014 01:05:36 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.203]) by smtp-cloud2.xs4all.net with ESMTP id S95Y1p00P4NtgTm0195YKt; Thu, 11 Dec 2014 10:05:34 +0100
Received: from [2001:983:a264:1:f876:6e0:dbd0:cb40] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 11 Dec 2014 10:05:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 11 Dec 2014 10:05:32 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <010101d014a9$40b50ca0$c21f25e0$@olddog.co.uk>
References: <20141210182425.6387.29651.idtracker@ietfa.amsl.com> <010101d014a9$40b50ca0$c21f25e0$@olddog.co.uk>
Message-ID: <998b4a1ea725e8ab778f39d63cbe8c7a@xs4all.nl>
X-Sender: stokcons@xs4all.nl (b2q1NWzWj4sXfeVKSUxe9KbPTf+tjpAz)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/zZtO4mMRJ7dmso1eLsHvlA-Wapo
Cc: ietf@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org
Subject: Re: [Roll] Last Call: <draft-ietf-roll-admin-local-policy-02.txt> (MPL forwarder policy for multicast with admin-local scope) to Informational RFC
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, 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: <http://www.ietf.org/mail-archive/web/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, 11 Dec 2014 09:06:03 -0000

Hi Adrian,

Many thanks for your comments and in particular your suggestions.
Using them will be my pleasure.

Your edge router/border router drawing is absolutely right. I will 
rephrase to cover possible future cases as well.

concerning "any" and "undefined": Although originally they were distinct 
in my head, I see that effectively there is no distinction.
I will remove "undefined".

I will wait for more LC comments and produce a new version, including 
text addressing all comments on this version 02.

Greetings,

Peter


Adrian Farrel schreef op 2014-12-10 19:43:
> All,
> 
> My usual AD review of this document threw up a few small issues that 
> don't need
> to delay the start of IETF last call.  Could you please treat them as 
> last call
> comments and address them with any other points that are raised.
> 
> Thanks,
> Adrian
> 
> ===
> 
> Hi authors,
> 
> Thanks for this document. Sorry I sat on it for a little while.
> 
> The document is very readable and doesn't waste words.
> 
> There are a few small nits that need to be sorted out. I think we can
> handle these as part of the IETF last call, so I will start that 
> process
> and then send these comments as last call comments.
> 
> Thanks for the work,
> Adrian
> 
> ===
> 
> "MPL" is not a well-known abbreviation so we need to expand it:
> - in the document title
>   OLD
>        MPL forwarder policy for multicast with admin-local scope
>   NEW
>     Forwarder policy for multicast with admin-local scope in the
>      Multicast Protocol for Low power and Lossy Networks (MPL)
> - in the Abstract
>   OLD
>    The purpose of this document is to specify an automated policy for
>    the routing of MPL multicast messages with admin-local scope in a
>    border router.
>   NEW
>    The purpose of this document is to specify an automated policy for
>    the routing of Multicast Protocol for Low power and Lossy Networks
>    (MPL) multicast messages with admin-local scope in a border router.
> - in the third paragraph of the Introduction
>   OLD
>    The admin-local scope must therefore be administratively configured.
>    This draft describes an automated policy for the MPL forwarding of
>    multicast messages with admin-local scope within a border router.
>   NEW
>    The admin-local scope must therefore be administratively configured.
>    This draft describes an automated policy for the Multicast Protocol
>    for Low power and Lossy Networks (MPL) 
> [[I-D.ietf-roll-trickle-mcast]
>    forwarding of multicast messages with admin-local scope within a
>    border router.
> 
> ---
> 
> I think it would be worth scoping the term "border router" in the
> Introduction. Something like...
> 
> OLD
>    multicast messages with admin-local scope within a border router.
> NEW
>    multicast messages with admin-local scope within a border router
>    that lies between a network running MPL and some other network.
> 
> ---
> 
> The last paragraph of the Introduction reads...
> 
>    It is expected that the network of an organization, building, or
>    home, is connected to the Internet via the edge routers provided by
>    an ISP.  The intention is that within the network of an 
> organization,
>    building, or home, MPL messages with multicast addresses of admin-
>    local scope are freely forwarded but are never forwarded to edge
>    routers which MUST NOT enable their interfaces for MPL messages.
> 
> This suggests that your vision is...
> 
> 
>   ISP network --- Access --- Border --- MPL network
>                   Router     Router
> 
> 
> That is fine. But wouldn't it be possible to have an access router that
> also served as a border router?
> 
>                    ---------------------
>                   |       Access Router |
>                   |                     |
>                   |          -----------| MPL i/f
>                   |non-MPL  | multicast +---------- MPL network
>   ISP network --- +---------| forwarder |
>                   |traffic  |           | MPL i/f
>                   |         |           +---------- MPL network
>                   |          -----------|
>                    ---------------------
> 
> What you wrote may be a reflection of the boxes on the market today, 
> and
> that is fine, but perhaps you are being too limiting of future
> developments.
> 
> ---
> 
> A few more abbreviations need to be expanded on first use.
> 
> Section 2.1  "PAN"
> Section 2.2  "SSID"
> 
> ---
> 
> In section 2.4 you note that Bluetooth does not have the concept of
> associating more than one network with a channel. You say that the way
> to handle this is to set the network identifier of a BTLE link is 
> "any".
> 
> Add the head of section 2 you say
>   When no network identifier exists for a given link, the network
>   identifier has the value "undefined".
> 
> Are these two statements consistent?
> 
> ---
> 
> Section 3
> s/with an scope/with a scope/
> 
> ---
> 
> Section 3
> You have "MPL zone". Do you mean "MPL4 zone"?
> 
> ---
> 
> Please add a note to Section 10 saying that the change log can be
> removed before publication as an RFC.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll