[Roll] [Gen-art] review: draft-ietf-roll-admin-local-policy-02

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 15 December 2014 22:59 UTC

Return-Path: <jmh@joelhalpern.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 3219C1A6F62; Mon, 15 Dec 2014 14:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 qOnYgwop3MA2; Mon, 15 Dec 2014 14:59:50 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4FB1A1EED; Mon, 15 Dec 2014 14:59:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B429A1BC82AF; Mon, 15 Dec 2014 14:59:50 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-121.clppva.east.verizon.net [70.106.135.121]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8572F1BC82AE; Mon, 15 Dec 2014 14:59:49 -0800 (PST)
Message-ID: <548F67D8.9080402@joelhalpern.com>
Date: Mon, 15 Dec 2014 17:59:36 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: gen-art@ietf.org, maria.ines.robles@ericsson.com, IETF discussion list <ietf@ietf.org>
References: <548A29DC.6080303@nostrum.com>
In-Reply-To: <548A29DC.6080303@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/UxiFSiOeuha6cgM6GObu2Kb4rTk
Cc: roll@ietf.org, "A. Jean Mahoney" <mahoney@nostrum.com>
Subject: [Roll] [Gen-art] review: draft-ietf-roll-admin-local-policy-02
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: <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: Mon, 15 Dec 2014 22:59:52 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-roll-admin-local-policy-02
     MPL forwarder policy for multicast with admin-local scope
Reviewer: Joel M. Halpern
Review Date: 15-December-2014
IETF LC End Date: 24-December-2014
IESG Telechat date: N/A

Summary: This document is not ready for publication as an Informational RFC.

Major issues:
     There seems to be a disconnect between the notion of 
administratively configured and the behavior described in this draft for 
admin-local multicast scope.  As far as I can tell, the forwarding 
behavior described here has no mechanism for administratively 
configuring the administrative boundary.  The only knob that is used is 
PROACTIVE_FORWARDING, which is used for intra-realm multicast 
forwarding.  Thus, if you have a roll multicast router with two 
interfaces in one realm and two interfaces in another realm, in order to 
provide realm multicast services for each realm, this router according 
to this draft will always forward admin-local multicast messages between 
the two realms.  That does not seem to me to match the requirement for 
administrative configuration of the admin-local scope.

Minor issues:
     I believe that MPL In the title should be expanded.  It should also 
be expanded upon first use within the document.

Nits/editorial comments: