[Roll] AD review of draft-ietf-roll-admin-local-policy

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 10 December 2014 17:33 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 E8DD11A877D for <roll@ietfa.amsl.com>; Wed, 10 Dec 2014 09:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 h62pMa77GAwb for <roll@ietfa.amsl.com>; Wed, 10 Dec 2014 09:33:18 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16E21A8791 for <roll@ietf.org>; Wed, 10 Dec 2014 09:33:11 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAHX9KD029973; Wed, 10 Dec 2014 17:33:09 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBAHX8bK029952 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:33:08 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-roll-admin-local-policy.all@tools.ietf.org>
Date: Wed, 10 Dec 2014 17:33:02 -0000
Message-ID: <00d401d0149f$5a27d5a0$0e7780e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01D0149F.5A2DF020"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdAUns1ZeEFdemsRToicEMjWtYKqkg==
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--9.973-10.0-31-10
X-imss-scan-details: No--9.973-10.0-31-10
X-TMASE-MatchedRID: J1szhq7AkrGnykMun0J1wnBRIrj8R47F2aYdnwn7qHccVJCT3tVgarsI asnPqvyQBanBF8QGgaZzE0lHhciiaLqUgEs+NGTpPmVMROjFDVWEDRWMikvPr0+0uGVOF08Qfak zcDIig/r/0JAKNeBLGBCg2PoqeXoJtVWReSlqXeouLk8NfSpYeqAPS3vFyaW6TDoylMQmcK9kwP NPtwx5z8XTAxA0oGwP0GLM4Oc8DhnwVBpSQYeaV05GBIYERk6jGGXRndNt79VZHPhWEMwl32kxA fYuAMQ88WLYesSso7RMh8d3WwUaAv29AWmTKYuEdAg4yd14qATTDXgcUlCNo2so23uKlCJjyukE y6JD/uYHY+yWZHCX2tgTRdG1XXJ3D0VXqQ1iI8dCnGIuUMP0VToSfZud5+GgGNAPebYwJ/vqSqR s8y+G0dmd6fJDFhEQLb6XLHjqIvRHW+94FA8JF0K9qlwiTElfrogFtKd/P7fSlkoRLCKfE56QVn lXMIygXrfYosn++oqhIBgkfoHq9iIdmtkBwO3DlwOGeK/WrXNT4DtiSkMnWBON+Q7elv5YPSawi BLK6fcf9nvUckM1oVpzKEH0vVqvEnerDpp3+WMAGGKG8CG8Akh41hM/w6ZM+TdKNkxxkWRSUGH6 RuK0zz8NRz8HpCmSZEZKdSp4I705BGX7329oyQwfhKwa9GwDWq9ln3+CkiGlF7MF/8ayEtQaDtB Vy9LI//nkqRz73/pz3XExg2oeRXAUwvUpRIyqTVa+L3Zgqc7RaXpm7mwQnLkY3WUw/B8Xu8iyJC yNt6l2+AZuxakJy3inb860CrQoRezVZvE21UueAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vbyah9aCYUCHq8PW4IxJUDbAiNggLo/5lOLzop1boWPUaLUHuAwT92Ibu2aKJC+Rb4x/oyK7 JsdAwp4Mc0I73sYNePgBUtf89WzH1sHCOz44
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/1wgaEhOCPgAxsXGbDDorQgICO2w
Cc: roll@ietf.org
Subject: [Roll] AD review of draft-ietf-roll-admin-local-policy
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 17:33:21 -0000

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.