Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)
draft-ietf-roll-admin-local-policy-03

[Ballot comment]
Thank you for the additions in text that resulted from the SecDir review and subsequent discussion.  I found the discussion helpful to better understand the draft and security concerns.  The current text looks good, but I did get additional context from the discussion that is not in the draft.  The 4 possibilities listed int he security considerations look good and I don't have any recommendations as reading it again after the SecDir discussion made more sense.

https://www.ietf.org/mail-archive/web/secdir/current/msg05435.html

[Ballot comment]
One question: In this text:

4.1.  Legal multicast messages

  Multicast messages can be created within the node by an application
  or can arrive at an interface.

  A multicast message created at a source (MPL seed) is legal when it
  conforms to the properties described in section 9.1 of
  [I-D.ietf-roll-trickle-mcast].

  A multicast message received at a given interface is legal when:

  o  The message carries an MPL option (MPL message) and the incoming
      MPL interface is subscribed to the destination multicast address.

  o  The message does not carry an MPL option, the multicast address is
      unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the
      interface has expressed interest to receive messages with the
      specified multicast address via MLD [RFC3810] or via IGMP
      [RFC3376].  The message was sent on according to PIM-DM [RFC3973]
      or according to PIM-SM [RFC4601].

  Illegal multicast messages are discarded.

4.2.  Forwarding legal packets

  A legal multicast message received at a given interface is assigned
  the network identifier of the interface of the incoming link . A
  message that is created within the node is assigned the network
  identifier "any".

  Two types of legal multicast messages are considered: (1) MPL
  messages, and (2) multicast messages which do not carry the MPL
  option.
 
Is "legal/illegal" the right terminology for this?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-admin-local-policy-02, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (MPL forwarder policy for multicast with admin-local scope) to Informational RFC


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'MPL forwarder policy for multicast with admin-local scope'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review
======

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 hav 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.

draft-ietf-roll-admin-local-policy - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 11-17
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel adrian@olddog.co.uk
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

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.

The Intended RFC status is Informational.

2. Review and Consensus

During the last call there were no comments against this document.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Peter van der Stock replied on 11/21/2014 for version 01, it applies as well for version 02, since version 02 fixed typo errors.
Robert Cragie did not reply yet, email sent to Robert on 11/20/2014. Robert Cragie replied on 12/07


4. Other points

Checklist for draft 02

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? No apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.) 

      Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 0 comments (--).

== It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 12 pages



Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Peter van der Stock replied
Robert Cragie replied

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes. 

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes. I-D.ietf-roll-trickle-mcast is mentioned in normative references. This document should
wait until I-D.ietf-roll-trickle-mcast is published.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  No apply.

If this is a "bis" document, have all of the errata been considered? No apply.

IANA Considerations:
Are the IANA Considerations clear and complete? No apply.

Remember that IANA have to understand unambiguously what's being requested, so
they can perform the required actions.

Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? No apply.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? No apply.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? No apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? No apply

draft-ietf-roll-admin-local-policy - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 11-17
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel adrian@olddog.co.uk
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

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.

The Intended RFC status is Informational.

2. Review and Consensus

During the last call there were no comments against this document.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Peter van der Stock replied on 11/21/2014 for version 01, it applies as well for version 02, since version 02 fixed typo errors.
Robert Cragie did not reply yet, email sent to Robert on 11/20/2014


4. Other points

Checklist for draft 02

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? No apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.) 

      Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 0 comments (--).

== It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 12 pages



Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Peter van der Stock replied, Robert Cragie should reply still.

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes. 

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes. I-D.ietf-roll-trickle-mcast is mentioned in normative references. This document should
wait until I-D.ietf-roll-trickle-mcast is published.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  No apply.

If this is a "bis" document, have all of the errata been considered? No apply.

IANA Considerations:
Are the IANA Considerations clear and complete? No apply.

Remember that IANA have to understand unambiguously what's being requested, so
they can perform the required actions.

Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? No apply.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? No apply.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? No apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? No apply

draft-ietf-roll-admin-local-policy - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 11-17
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel adrian@olddog.co.uk
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

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.

The Intended RFC status is Informational.

2. Review and Consensus

During the last call there were no comments against this document.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Peter van der Stock replied on 11/21/2014 for version 01, it applies as well for version 02, since version 02 fixed typo errors.
Robert Cragie did not reply yet, email sent to Robert on 11/20/2014


4. Other points

Checklist for draft 01

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? No apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.) 

      Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 0 comments (--).

== It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 12 pages



Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Peter van der Stock replied, Robert Cragie should reply still.

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes. 

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes. I-D.ietf-roll-trickle-mcast is mentioned in normative references. This document should
wait until I-D.ietf-roll-trickle-mcast is published.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  No apply.

If this is a "bis" document, have all of the errata been considered? No apply.

IANA Considerations:
Are the IANA Considerations clear and complete? No apply.

Remember that IANA have to understand unambiguously what's being requested, so
they can perform the required actions.

Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? No apply.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? No apply.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? No apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? No apply

draft-ietf-roll-admin-local-policy - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 11-17
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel adrian@olddog.co.uk
* Document Shepherd: Ines Robles mariainesrobles@googlemail.com

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.

The Intended RFC status is Informational.

2. Review and Consensus

During the last call there were no comments against this document.

This document was reviewed in roll working group.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Peter van der Stock replied on 11/21/2014
Robert Cragie did not reply yet, email sent to Robert on 11/20/2014


4. Other points

Checklist for draft 01

Does the shepherd stand behind the document and think the document is ready for
publication? Yes.

Is the correct RFC type indicated in the title page header?  Yes.

Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
Yes

Is the intent of the document accurately and adequately explained in the introduction?
Yes.

Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested
and/or completed? No apply.



Has the shepherd performed automated checks -- idnits (see ​
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules,
XML code and schemas, MIB definitions, and so on -- and determined that the
document passes the tests? (In general, nits should be fixed before the document is
sent to the IESG. If there are reasons that some remain (false positives, perhaps, or
abnormal things that are necessary for this particular document), explain them.) 

      Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
    or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
    use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
    mean).
   
    Found 'MUST not' in this paragraph:
   
    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.

  -- The document date (October 22, 2014) is 30 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: A later version (-10) exists of
    draft-ietf-roll-trickle-mcast-09

  == Outdated reference: A later version (-08) exists of
    draft-ietf-6lo-lowpanz-07



Has each author stated that their direct, personal knowledge of any IPR related to this
document has already been disclosed, in conformance with BCPs 78 and 79?
Peter van der Stock replied, Robert Cragie should reply still.

Have all references within this document been identified as either normative or
informative, and does the shepherd agree with how they have been classified?
Yes. 

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state?
Yes. I-D.ietf-roll-trickle-mcast is mentioned in normative references. This document should
wait until I-D.ietf-roll-trickle-mcast is published.

If publication of this document changes the status of any existing RFCs, are those
RFCs listed on the title page header, and are the changes listed in the abstract and
discussed (explained, not just mentioned) in the introduction?  No apply.

If this is a "bis" document, have all of the errata been considered? No apply.

IANA Considerations:
Are the IANA Considerations clear and complete? No apply.

Remember that IANA have to understand unambiguously what's being requested, so
they can perform the required actions.

Are all protocol extensions that the document makes associated with the appropriate
reservations in IANA registries? No apply.

Are all IANA registries referred to by their exact names (check them in ​
http://www.iana.org/protocols/ to be sure)? No apply.

For any new registries that this document creates, has the working group actively
chosen the allocation procedures and policies and discussed the alternatives? No apply.

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? and have the initial contents and valid value ranges been clearly specified? No apply