Re: [Roll] Last Call: <draft-ietf-roll-admin-local-policy-02.txt> (MPL forwarder policy for multicast with admin-local scope) to Informational RFC
"Adrian Farrel" <adrian@olddog.co.uk> Wed, 10 December 2014 18:45 UTC
Return-Path: <adrian@olddog.co.uk>
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 BDEF11A1B80; Wed, 10 Dec 2014 10:45:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 trFBliDZUOIM; Wed, 10 Dec 2014 10:45:26 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9334E1A1B57; Wed, 10 Dec 2014 10:44:03 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAIi1pc024583; Wed, 10 Dec 2014 18:44:01 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAIhtFQ024548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 18:44:01 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: ietf@ietf.org
References: <20141210182425.6387.29651.idtracker@ietfa.amsl.com>
In-Reply-To: <20141210182425.6387.29651.idtracker@ietfa.amsl.com>
Date: Wed, 10 Dec 2014 18:43:50 -0000
Message-ID: <010101d014a9$40b50ca0$c21f25e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGDspU+bH+68Bq5vmYqQRhEa360FJ0h6lCg
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21166.001
X-TM-AS-Result: No--13.799-10.0-31-10
X-imss-scan-details: No--13.799-10.0-31-10
X-TMASE-MatchedRID: gzVbiXtWD9szx9GDMr0HvzYTypjB3iDVuikHZcC6ceATVJPv0YKEKWn7 AlTb8W2x9Us4ZrjPeq9kG+By0KzAPUIFCJ5KkAbPVo6mn+xXmdXZph2fCfuodxxUkJPe1WBquwh qyc+q/JDlZ3R4RzLT0TgJ1V1R6K4hUapouPacYiqMcPlFNKd81tMGD8JuBXZPc4wJc2thNaIZ4o BrlanIO2CX9xIquPuxS9KN/ejlLD5cNOa3zFU5Xy97pb4g5HCtCI3p+Ju8mqqijw51EnZ2OCzyb VqWyY2NeC7pQ35xbkrI0IFszHQxmZV35HEp+SsiVUIE0/jxA/257wrN/2ZIygW3kEiN4kyf7fKx aM2xqkABDoeeLVMaqIlf3U2W48KAKgsbwct+M1+PmEs8Jfdl0/a/bRHEsPI3xaQNbiRXdZqLtYN ZwGGp+8CzDGl+ASOWO29ybNxer1TUzvcPSorAlMAmcZEx8XHJWjRJreaOWv5UjspoiX02F2qzO+ SzheZk4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjOwBXM346/+ykql3fPsqGp5HaT/Y1b5k3fYrZ1 x3xCqKyxDIsQDDebUDy1pMfzQL9
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/hr8kgvMDz5_2TaHT090AcPxzJOw
Cc: roll@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: adrian@olddog.co.uk, 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: Wed, 10 Dec 2014 18:45:27 -0000
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] Last Call: <draft-ietf-roll-admin-local-po… The IESG
- Re: [Roll] Last Call: <draft-ietf-roll-admin-loca… Adrian Farrel
- Re: [Roll] Last Call: <draft-ietf-roll-admin-loca… peter van der Stok