Skip to main content

Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)
RFC 7732

Revision differences

Document history

Date Rev. By Action
2016-02-18
03 (System) RFC published
2015-12-18
03 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-12-10
03 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-12-03
03 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2015-11-13
03 (System) RFC Editor state changed to AUTH from EDIT
2015-10-27
03 (System) RFC Editor state changed to EDIT from REF
2015-10-14
03 Alvaro Retana Notification list changed to aretana@cisco.com
2015-10-14
03 (System) Notify list changed from maria.ines.robles@ericsson.com, roll-chairs@ietf.org to (None)
2015-07-14
03 (System) RFC Editor state changed to REF from EDIT
2015-07-02
03 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2015-06-29
03 (System) RFC Editor state changed to EDIT from MISSREF
2015-03-25
03 Amy Vezza Shepherding AD changed to Alvaro Retana
2015-03-11
03 (System) IANA Action state changed to No IC from In Progress
2015-03-10
03 (System) IANA Action state changed to In Progress
2015-03-09
03 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-03-09
03 (System) RFC Editor state changed to MISSREF
2015-03-09
03 (System) Announcement was received by RFC Editor
2015-03-09
03 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-03-09
03 Amy Vezza IESG has approved the document
2015-03-09
03 Amy Vezza Closed "Approve" ballot
2015-03-09
03 Amy Vezza Ballot approval text was generated
2015-03-08
03 Adrian Farrel IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2015-03-08
03 Adrian Farrel Ballot writeup was changed
2015-03-06
03 Adrian Farrel Ballot writeup was changed
2015-02-19
03 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2015-02-19
03 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-02-19
03 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-02-19
03 Kathleen Moriarty
[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 …
[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
2015-02-19
03 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-02-19
03 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-02-18
03 Spencer Dawkins
[Ballot comment]
One question: In this text:

4.1.  Legal multicast messages

  Multicast messages can be created within the node by an application
  or …
[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?
2015-02-18
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-02-18
03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-02-17
03 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-02-17
03 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-02-12
03 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2015-02-12
03 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2015-02-06
03 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-02-06
03 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2015-02-06
03 Adrian Farrel Ballot has been issued
2015-02-06
03 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2015-02-06
03 Adrian Farrel Created "Approve" ballot
2015-02-06
03 Adrian Farrel Ballot writeup was changed
2015-02-06
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-02-06
03 Peter Van der Stok IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-02-06
03 Peter Van der Stok New version available: draft-ietf-roll-admin-local-policy-03.txt
2015-02-05
02 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Scott Bradner.
2015-02-05
02 Adrian Farrel Placed on agenda for telechat - 2015-02-19
2015-02-05
02 Adrian Farrel Changed consensus to Yes from Unknown
2015-01-02
02 Tero Kivinen Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Steve Hanna.
2014-12-28
02 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2014-12-24
02 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-12-17
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2014-12-17
02 Pearl Liang
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 …
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.
2014-12-11
02 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2014-12-11
02 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2014-12-11
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Steve Hanna
2014-12-11
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Steve Hanna
2014-12-10
02 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-12-10
02 Amy Vezza
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 …
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.
2014-12-10
02 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-12-10
02 Adrian Farrel Last call was requested
2014-12-10
02 Adrian Farrel Ballot approval text was generated
2014-12-10
02 Adrian Farrel IESG state changed to Last Call Requested from AD Evaluation
2014-12-10
02 Adrian Farrel
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 …
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.
2014-12-10
02 Adrian Farrel Ballot writeup was changed
2014-12-10
02 Adrian Farrel Last call announcement was changed
2014-12-10
02 Adrian Farrel Last call announcement was generated
2014-12-10
02 Adrian Farrel Last call announcement was generated
2014-12-10
02 Adrian Farrel Ballot writeup was changed
2014-12-10
02 Adrian Farrel Ballot writeup was changed
2014-12-10
02 Adrian Farrel Ballot writeup was changed
2014-12-10
02 Adrian Farrel Ballot writeup was generated
2014-12-08
02 Ines Robles
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 …
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
2014-12-05
02 Adrian Farrel IESG state changed to AD Evaluation from AD Evaluation::Point Raised - writeup needed
2014-12-05
02 Adrian Farrel IPR status will be checked with authors at the same time as the document progresses
2014-12-05
02 Adrian Farrel Point raised with document shepherd to check on the status of IPR disclosures.
2014-12-05
02 Adrian Farrel IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation
2014-12-05
02 Adrian Farrel IESG state changed to AD Evaluation from Publication Requested
2014-11-24
02 Ines Robles
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 …
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
2014-11-24
02 Ines Robles
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 …
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
2014-11-24
02 Peter Van der Stok New version available: draft-ietf-roll-admin-local-policy-02.txt
2014-11-23
01 Ines Robles
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 …
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
2014-11-23
01 Ines Robles State Change Notice email list changed to roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, roll-chairs@tools.ietf.org
2014-11-23
01 Ines Robles Responsible AD changed to Adrian Farrel
2014-11-23
01 Ines Robles IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-11-23
01 Ines Robles IESG state changed to Publication Requested
2014-11-23
01 Ines Robles IESG process started in state Publication Requested
2014-11-23
01 Ines Robles Intended Status changed to Informational from None
2014-11-21
01 Ines Robles Changed document writeup
2014-10-22
01 Peter Van der Stok New version available: draft-ietf-roll-admin-local-policy-01.txt
2014-07-04
00 Ines Robles Document shepherd changed to Ines Robles
2014-04-08
00 Ines Robles ROLL WG adopts this document, because this document is necessary to handle MPL topic
2014-04-08
00 Ines Robles This document now replaces draft-vanderstok-roll-admin-local-policy instead of None
2014-04-08
00 Peter Van der Stok New version available: draft-ietf-roll-admin-local-policy-00.txt