Skip to main content

Multicast Protocol for Low-Power and Lossy Networks (MPL)
draft-ietf-roll-trickle-mcast-12

Revision differences

Document history

Date Rev. By Action
2018-12-20
12 (System)
Received changes through RFC Editor sync (changed abstract to 'This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast …
Received changes through RFC Editor sync (changed abstract to 'This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.

MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.')
2016-02-18
12 (System) RFC published
2016-02-12
12 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7731">AUTH48-DONE</a> from AUTH48
2015-12-10
12 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7731">AUTH48</a> from RFC-EDITOR
2015-11-30
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-10-27
12 (System) RFC Editor state changed to EDIT from IESG
2015-10-14
12 Alvaro Retana Notification list changed to aretana@cisco.com
2015-10-14
12 (System) Notify list changed from roll-chairs@ietf.org, draft-ietf-roll-trickle-mcast@ietf.org to (None)
2015-07-16
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-07-15
12 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-07-13
12 (System) RFC Editor state changed to IESG from EDIT
2015-07-08
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-07-08
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-07-06
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-06-30
12 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-06-29
12 (System) IANA Action state changed to In Progress
2015-06-29
12 (System) RFC Editor state changed to EDIT
2015-06-29
12 (System) Announcement was received by RFC Editor
2015-06-29
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-06-29
12 Amy Vezza IESG has approved the document
2015-06-29
12 Amy Vezza Closed "Approve" ballot
2015-06-29
12 Amy Vezza Ballot approval text was generated
2015-06-29
12 Amy Vezza Ballot writeup was changed
2015-06-29
12 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

We got recently comments for version 12 from a member of the Maling list, waiting for the reply of the authors related to that. Author replied to the concerns

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 09.

Version 12 addresses IESG Comments

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 3 warnings (==), 2 comments (--)..

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'--> this draft should wait until draft-ietf-6man-multicast-scopes is published.

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?
All authors have confirmed no IPR to be disclosed.

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. This draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Well-know Multicast Address: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282], ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2015-06-29
12 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-06-29
12 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2015-06-29
12 Stephen Farrell
[Ballot comment]
Thanks for adding the new text saying that this shouldn't be used
if those authorised to access the n/w can be a source …
[Ballot comment]
Thanks for adding the new text saying that this shouldn't be used
if those authorised to access the n/w can be a source of attacks.

I think you could improve the way you say that though, it'd be
better to s/attack vector/threat model/ in both the intro and
in the security considerations. But that's really a nit and is ok to
fix (or not) at AUTH-48 IMO.
2015-06-29
12 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2015-06-12
12 Brian Haberman
[Ballot comment]
Thank you for the updated text on the multicast addresses in section 4.1.  I will leave it up to you and your AD …
[Ballot comment]
Thank you for the updated text on the multicast addresses in section 4.1.  I will leave it up to you and your AD as to whether the text in section 5.1 needs to be updated in a similar fashion.
2015-06-12
12 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2015-06-11
12 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

We got recently comments for version 12 from a member of the Maling list, waiting for the reply of the authors related to that.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 09.

Version 12 addresses IESG Comments

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 3 warnings (==), 2 comments (--)..

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'--> this draft should wait until draft-ietf-6man-multicast-scopes is published.

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?
All authors have confirmed no IPR to be disclosed.

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. This draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Well-know Multicast Address: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282], ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2015-06-03
12 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 09.

Version 12 addresses IESG Comments

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 3 warnings (==), 2 comments (--)..

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'--> this draft should wait until draft-ietf-6man-multicast-scopes is published.

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?
All authors have confirmed no IPR to be disclosed.

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. This draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Well-know Multicast Address: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282], ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2015-06-02
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-06-02
12 Jonathan Hui IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-06-02
12 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-12.txt
2015-03-25
11 Amy Vezza Shepherding AD changed to Alvaro Retana
2015-02-05
11 Christer Holmberg Request for Telechat review by GENART Completed: Ready. Reviewer: Christer Holmberg.
2015-02-05
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2015-02-05
11 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-02-05
11 Stephen Farrell
[Ballot discuss]

There is no cryptographic security defined for MPL so
there is not way to ensure that MPL messages are not
spoofed by anyone …
[Ballot discuss]

There is no cryptographic security defined for MPL so
there is not way to ensure that MPL messages are not
spoofed by anyone with access to the LLN.  Doesn't
that mean that MPL is just not suitable for any
higher security of sensitive applications/LLNs?  I
bet this will be used for CCTV and in some cases
where the LLN contains nodes that are not trusted to
see or DoS that video. Why is it ok to not consider
this in the applicability statement section? (I'd
prefer if you had defined ways to secure MPL but as
you didn't I think you need to be clear about the
consequences.)
2015-02-05
11 Stephen Farrell
[Ballot comment]

- I would love to have seen more analysis of what can
go wrong when e.g. someone spoofs as a MPL Seed. Was …
[Ballot comment]

- I would love to have seen more analysis of what can
go wrong when e.g. someone spoofs as a MPL Seed. Was
that analysis done? If so then adding some references
would really help I think. If not, then perhaps the
WG should have, but I guess it's too late now.
2015-02-05
11 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2015-02-05
11 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-02-05
11 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-02-04
11 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2015-02-04
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-02-04
11 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2015-02-04
11 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-02-04
11 Kathleen Moriarty [Ballot comment]
Thank you for responding to the SecDir review addressing Tero's questions.
https://www.ietf.org/mail-archive/web/secdir/current/msg04411.html
2015-02-04
11 Kathleen Moriarty Ballot comment text updated for Kathleen Moriarty
2015-02-04
11 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-02-03
11 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-02-03
11 Jari Arkko
[Ballot comment]
Christer Holmberg's Gen-ART review had some minor editorial suggestions. Please treat these as comments that you may take into account in your editing …
[Ballot comment]
Christer Holmberg's Gen-ART review had some minor editorial suggestions. Please treat these as comments that you may take into account in your editing process.

Section 1:
------------

Q_1_1:

I assume "LLN" stands for "Low power and Lossy Networks", but there is no extension anywhere. Please insert "Low power and Lossy Networks (LLN)" on first occurance.


Section 3:
------------

Q_3_1:

In a few places the text says "this protocol". I would suggest to replace that with "MPL".


Section 4:
-----------
 
Q_4_2:

I would suggest to add something in front of "Overview" in the subject of section 4.3. Overview of what? :)
2015-02-03
11 Jari Arkko Ballot comment text updated for Jari Arkko
2015-02-03
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-02-02
11 Brian Haberman
[Ballot discuss]
I have two points that I want to discuss that should be relatively easy to address.

1. The document defines MPL Domain Address …
[Ballot discuss]
I have two points that I want to discuss that should be relatively easy to address.

1. The document defines MPL Domain Address and indicates that all multicast data dissemination within an MPL domain is sent to that address.  The document does not say how that address is selected or negotiated within a domain.  One might infer from the 2nd paragraph of section 4.1 that the MPL Domain Address is the ALL_MPL_FORWARDERS address, but the wording of that section would make that an inference. Additionally, point #2 below makes me wonder if that is really the case.  This document should be clear on the origin of the MPL Domain Address so that implementations do the right thing and can interact correctly.

2. Section 4.1 talks about devices participating in multiple MPL domains and segregating those domains by using different MPL Domain Addresses.  Given the question above about how the MPL Domain Address is assigned/selected/negortiated, using the address to separate zones of the same scope is problematic.  This spec should be clear that implementations need to follow the use of scope zone IDs (RFC 4007, Section 6) to keep different zones of the same scope separated.
2015-02-02
11 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2015-02-01
11 Adrian Farrel
[Ballot comment]
Updated after additional review...

While balloting "Yes" on this document I have a number of small editorials that I believe should be made …
[Ballot comment]
Updated after additional review...

While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. These are presented roughly in order of appearance in the document, you can fix them now or after the rest of the IESG ballots are in (5th February).

===

Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs.

---

I think the Abstract could be a bit clearer to note the two modes of operation.

Something like

  This document specifies the Multicast Protocol for Low power and
  Lossy Networks (MPL) that provides IPv6 multicast forwarding in
  constrained networks.  MPL avoids the need to construct or maintain
  any multicast forwarding topology, disseminating messages to all MPL
  Forwarders in an MPL Domain. 

  MPL has two modes of operation. One mode uses the Trickle
  algorithm to manage control- and data-plane message transmissions,
  and is applicable for deployments with few multicast sources. The
  other mode uses classic flooding. By providing both modes and
  parameterization of the Trickle algorithm, a MPL implementation
  can be used in a variety of multicast deployments and can trade
  between dissemination latency and transmission efficiency.

---

Section 2 : MPL Forwarder

Please add...

  The term "node" is used within this document to refer to a MPL Forwarder.

---

Section 3
OLD
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques.  By supporting both
  simple flooding and Trickle methods, MPL can be configured to operate
  well in a variety of situations [Clausen2013].
NEW
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques. [Clausen2013] questions
  the efficiency of Trickle's "polite gossip" mechanism in some
  multicast scenarios, so by also including a classic flooding mode of
  operation MPL  aims to be able to perform satisfactorily in a variety
  of situations
END

---

4.1 has a little mix of "scope value of nnn" and "scop value mmm".
Since 7346 uses "scop value" I suggest you change all to be in that style.

Ditto 5.1

---

In 5.4 under PROACTIVE_FORWARDING I think you need some simple statement like:

  All MPL interfaces on the same link SHOULD be configured with the same
  value of PROACTIVE_FORWARDING.

I thought about asking for "MUST", but I think that is too strong. However, if using
"SHOULD" it would also be good to have something like...

  An implementation MAY choose to vary the value of PROACTIVE_FORWARDING
  across interfaces on the same link if <supply text here>.

---

Section 6.3

  The Option Data (in particular the M flag) of the MPL Option is
  updated by MPL Forwarders as the MPL Data Message is forwarded.

s/in particular/specifically/

---

Section 13.

Please add a short paragraph on the comparative security implications of classic flooding mode.

---

Please update the reference to read as follows:

  [Clausen2013]
            Clausen, T., Colin de Verdiere, A., and J. Yi,
            "Performance Analysis of Trickle as a Flooding Mechanism",
            November 2013. The 5th IEEE International Conference on
            Communication Technology (ICCT2013)
2015-02-01
11 Adrian Farrel Ballot comment text updated for Adrian Farrel
2015-02-01
11 Adrian Farrel
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. …
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. These are presented roughly in order of appearance in the document, you can fix them now or after the rest of the IESG ballots are in (5th February).

===

Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs.

---

I think the Abstract could be a bit clearer to note the two modes of operation.

Something like

  This document specifies the Multicast Protocol for Low power and
  Lossy Networks (MPL) that provides IPv6 multicast forwarding in
  constrained networks.  MPL avoids the need to construct or maintain
  any multicast forwarding topology, disseminating messages to all MPL
  Forwarders in an MPL Domain. 

  MPL has two modes of operation. One mode uses the Trickle
  algorithm to manage control- and data-plane message transmissions,
  and is applicable for deployments with few multicast sources. The
  other mode uses classic flooding. By providing both modes and
  parameterization of the Trickle algorithm, a MPL implementation
  can be used in a variety of multicast deployments and can trade
  between dissemination latency and transmission efficiency.

---

Section 2 : MPL Forwarder

Please add...

  The term "node" is used within this document to refer to a MPL Forwarder.

---

Section 3
OLD
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques.  By supporting both
  simple flooding and Trickle methods, MPL can be configured to operate
  well in a variety of situations [Clausen2013].
NEW
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques. [Clausen2013] questions
  the efficiency of Trickle's "polite gossip" mechanism in some
  multicast scenarios, so by also including a classic flooding mode of
  operation MPL  aims to be able to perform satisfactorily in a variety
  of situations
END

---

4.1 has a little mix of "scope value of nnn" and "scop value mmm".
Since 7346 uses "scop value" I suggest you change all to be in that style.

Ditto 5.1

---

In 5.4 under PROACTIVE_FORWARDING I think you need some simple statement like:

  All MPL interfaces on the same link SHOULD be configured with the same
  value of PROACTIVE_FORWARDING.

I thought about asking for "MUST", but I think that is too strong. However, if using
"SHOULD" it would also be good to have something like...

  An implementation MAY choose to vary the value of PROACTIVE_FORWARDING
  across interfaces on the same link if <supply text here>.

---

Section 6.3

  The Option Data (in particular the M flag) of the MPL Option is
  updated by MPL Forwarders as the MPL Data Message is forwarded.

s/in particular/specifically/

---

Section 13.

Please add a short paragraph on the comparative security implications of classic flooding mode.

---

Please update the reference to read as follows:

  [Clausen2013]
            Clausen, T., Colin de Verdiere, A., and J. Yi,
            "Performance Analysis of Trickle as a Flooding Mechanism",
            November 2013. The 5th IEEE International Conference on
            Communication Technology (ICCT2013)
2015-02-01
11 Adrian Farrel Ballot comment text updated for Adrian Farrel
2015-02-01
11 Adrian Farrel
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. …
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. These are presented roughly in order of appearance in the document, you can fix them now or after the rest of the IESG ballots are in (5th February).

===

Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs.

---

I think the Abstract could be a bit clearer to note the two modes of operation.

Something like

  This document specifies the Multicast Protocol for Low power and
  Lossy Networks (MPL) that provides IPv6 multicast forwarding in
  constrained networks.  MPL avoids the need to construct or maintain
  any multicast forwarding topology, disseminating messages to all MPL
  Forwarders in an MPL Domain. 

  MPL has two modes of operation. One mode uses the Trickle
  algorithm to manage control- and data-plane message transmissions,
  and is applicable for deployments with few multicast sources. The
  other mode uses classic flooding. By providing both modes and
  parameterization of the Trickle algorithm, a MPL implementation
  can be used in a variety of multicast deployments and can trade
  between dissemination latency and transmission efficiency.

---

Section 2 : MPL Forwarder

Please add...

  The term "node" is used within this document to refer to a MPL Forwarder.

---

Section 3
OLD
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques.  By supporting both
  simple flooding and Trickle methods, MPL can be configured to operate
  well in a variety of situations [Clausen2013].
NEW
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques. [Clausen2013] questions
  the efficiency of Trickle's "polite gossip" mechanism in some
  multicast scenarios, so by also including a classic flooding mode of
  operation MPL  aims to be able to perform satisfactorily in a variety
  of situations
END

---

4.1 has a little mix of "scope value of nnn" and "scop value mmm".
Since 7346 uses "scop value" I suggest you change all to be in that style.

Ditto 5.1

---

In 5.4 under PROACTIVE_FORWARDING I think you need some simple statement like:

  All MPL interfaces on the same link SHOULD be configured with the same
  value of PROACTIVE_FORWARDING.

I thought about asking for "MUST", but I think that is too strong. However, if using
"SHOULD" it would also be good to have something like...

  An implementation MAY choose to vary the value of PROACTIVE_FORWARDING
  across interfaces on the same link if <supply text here>.

---

Right at the end of 5.4 you have

  where
  CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN.

I think that should read

  where
  CONTROL_MESSAGE_IMAX is greater than or equal to
  CONTROL_MESSAGE_IMIN.

---

Section 6.3

  The Option Data (in particular the M flag) of the MPL Option is
  updated by MPL Forwarders as the MPL Data Message is forwarded.

s/in particular/specifically/

---

Section 13.

Please add a short paragraph on the comparative security implications of classic flooding mode.

---

Please update the reference to read as follows:

  [Clausen2013]
            Clausen, T., Colin de Verdiere, A., and J. Yi,
            "Performance Analysis of Trickle as a Flooding Mechanism",
            November 2013. The 5th IEEE International Conference on
            Communication Technology (ICCT2013)
2015-02-01
11 Adrian Farrel Ballot comment text updated for Adrian Farrel
2015-02-01
11 Adrian Farrel
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. …
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. These are presented roughly in order of appearance in the document, you can fix them now or after the rest of the IESG ballots are in (5th February).

===

Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs.

---

I think the Abstract could be a bit clearer to note the two modes of operation.

Something like

  This document specifies the Multicast Protocol for Low power and
  Lossy Networks (MPL) that provides IPv6 multicast forwarding in
  constrained networks.  MPL avoids the need to construct or maintain
  any multicast forwarding topology, disseminating messages to all MPL
  Forwarders in an MPL Domain. 

  MPL has two modes of operation. One mode uses the Trickle
  algorithm to manage control- and data-plane message transmissions,
  and is applicable for deployments with few multicast sources. The
  other mode uses classic flooding. By providing both modes and
  parameterization of the Trickle algorithm, a MPL implementation
  can be used in a variety of multicast deployments and can trade
  between dissemination latency and transmission efficiency.

---

Section 2 : MPL Forwarder

Please add...

  The term "node" is used within this document to refer to a MPL Forwarder.

---

Section 3
OLD
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques.  By supporting both
  simple flooding and Trickle methods, MPL can be configured to operate
  well in a variety of situations [Clausen2013].
NEW
  MPL is parameterized to support different dissemination techniques.
  In one parameterization, MPL may utilize the classic flooding method
  that involves having each device receiving a message rebroadcast the
  message.  In another parameterization, MPL may utilize Trickle's
  [RFC6206] "polite gossip" method that involves transmission
  suppression and adaptive timing techniques. [Clausen2013] questions
  the efficiency of Trickle's "polite gossip" mechanism in some
  multicast scenarios, so by also including a classic flooding mode of
  operation MPL  aims to be able to perform satisfactorily in a variety
  of situations
END

---

4.1 has a little mix of "scope value of nnn" and "scop value mmm".
Since 7346 uses "scop value" I suggest you change all to be in that style.

Ditto 5.1

---

In 5.4 under PROACTIVE_FORWARDING I think you need some simple statement like:

  All MPL interfaces on the same link SHOULD be configured with the same
  value of PROACTIVE_FORWARDING.

---

Right at the end of 5.4 you have

  where
  CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN.

I think that should read

  where
  CONTROL_MESSAGE_IMAX is greater than or equal to
  CONTROL_MESSAGE_IMIN.

---

Section 6.3

  The Option Data (in particular the M flag) of the MPL Option is
  updated by MPL Forwarders as the MPL Data Message is forwarded.

s/in particular/specifically/

---

Section 13.

Please add a short paragraph on the comparative security implications of classic flooding mode.

---

Please update the reference to read as follows:

  [Clausen2013]
            Clausen, T., Colin de Verdiere, A., and J. Yi,
            "Performance Analysis of Trickle as a Flooding Mechanism",
            November 2013. The 5th IEEE International Conference on
            Communication Technology (ICCT2013)
2015-02-01
11 Adrian Farrel Ballot comment text updated for Adrian Farrel
2015-01-28
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2015-01-28
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2015-01-26
11 Barry Leiba
[Ballot comment]
Adrian comments: "Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs."

"Mipple", then?  Oy.  Ripple trickle mipple.  But don't …
[Ballot comment]
Adrian comments: "Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs."

"Mipple", then?  Oy.  Ripple trickle mipple.  But don't tipple.

Dig.
2015-01-26
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-01-21
11 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-01-18
11 Adrian Farrel
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. …
[Ballot comment]
While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. These are presented roughly in order of appearance in the document, you can fix them now or after the rest of the IESG ballots are in (5th February).

===

Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs.

---

I think the Abstract could be a bit clearer to note the two modes of operation.

Something like

  This document specifies the Multicast Protocol for Low power and
  Lossy Networks (MPL) that provides IPv6 multicast forwarding in
  constrained networks.  MPL avoids the need to construct or maintain
  any multicast forwarding topology, disseminating messages to all MPL
  Forwarders in an MPL Domain. 

  MPL has two modes of operation. One mode uses the Trickle
  algorithm to manage control- and data-plane message transmissions,
  and is applicable for deployments with few multicast sources. The
  other mode uses classic flooding. By providing both modes and
  parameterization of the Trickle algorithm, a MPL implementation
  can be used in a variety of multicast deployments and can trade
  between dissemination latency and transmission efficiency.

---

Section 2 : MPL Forwarder

Please add...

  The term "node" is used within this document to refer to a MPL Forwarder.

---

4.1 has a little mix of "scope value of nnn" and "scop value mmm".
Since 7346 uses "scop value" I suggest you change all to be in that style.

Ditto 5.1

---

In 5.4 under PROACTIVE_FORWARDING I think you need some simple statement like:

  All MPL interfaces on the same link SHOULD be configured with the same
  value of PROACTIVE_FORWARDING.

---

Right at the end of 5.4 you have

  where
  CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN.

I think that should read

  where
  CONTROL_MESSAGE_IMAX is greater than or equal to
  CONTROL_MESSAGE_IMIN.

---

Section 6.3

  The Option Data (in particular the M flag) of the MPL Option is
  updated by MPL Forwarders as the MPL Data Message is forwarded.

s/in particular/specifically/

---

Section 13.

Please add a short paragraph on the comparative security implications of classic flooding mode.

---

Please update the reference to read as follows:

  [Clausen2013]
            Clausen, T., Colin de Verdiere, A., and J. Yi,
            "Performance Analysis of Trickle as a Flooding Mechanism",
            November 2013. The 5th IEEE International Conference on
            Communication Technology (ICCT2013)
2015-01-18
11 Adrian Farrel Ballot comment text updated for Adrian Farrel
2015-01-18
11 Adrian Farrel Ballot has been issued
2015-01-18
11 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2015-01-18
11 Adrian Farrel Created "Approve" ballot
2015-01-18
11 Adrian Farrel Placed on agenda for telechat - 2015-02-05
2015-01-18
11 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2015-01-18
11 Adrian Farrel Ballot writeup was changed
2014-11-24
11 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-11.txt
2014-11-10
10 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-10.txt
2014-09-12
09 Gunter Van de Velde Request for Last Call review by OPSDIR Completed. Reviewer: Benoit Claise.
2014-09-12
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Benoit Claise
2014-09-12
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Benoit Claise
2014-09-12
09 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Withdrawn'
2014-04-14
09 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 09.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 3 warnings (==), 2 comments (--)..

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'--> this draft should wait until draft-ietf-6man-multicast-scopes is published.

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?
All authors have confirmed no IPR to be disclosed.

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. This draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Well-know Multicast Address: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282], ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-04-14
09 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-09.txt
2014-04-08
08 Ines Robles draft-ietf-roll-trickle-mcast replaces draft-hui-6man-trickle-mcast
2014-04-08
08 Ines Robles This document now replaces draft-hui-6man-trickle-mcast instead of None
2014-04-06
08 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 08. Email sent asking for confirmation on it- waiting for it-


3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 3 warnings (==), 2 comments (--)..

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'--> this draft should wait until draft-ietf-6man-multicast-scopes is published.

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?
All authors have confirmed no IPR to be disclosed.

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. This draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Well-know Multicast Address: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282], ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-04-06
08 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 08.


3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 3 warnings (==), 2 comments (--)..

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'--> this draft should wait until draft-ietf-6man-multicast-scopes is published.

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?
All authors have confirmed no IPR to be disclosed.

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. This draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Well-know Multicast Address: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282], ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-04-06
08 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 08.


3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 3 warnings (==), 2 comments (--)..

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'--> this draft should wait until draft-ietf-6man-multicast-scopes is published.

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?
All authors have confirmed no IPR to be disclosed.

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. This draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-04-06
08 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Nits were addressed in version 08.


3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-03-28
08 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-08.txt
2014-02-24
07 Christer Holmberg Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg.
2014-02-24
07 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

Some nits still should be addressed:


3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-02-17
07 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues and the issues from late email reviews.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-02-17
07 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

Version 07 addresses IANA issues.

There was also a late review email, tickets for that #145, and #149

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-02-14
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-02-14
07 Jonathan Hui IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2014-02-14
07 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-07.txt
2014-02-12
06 Adrian Farrel Some late review comments necessitate edits
2014-02-12
06 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::Point Raised - writeup needed
2014-02-12
06 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

some IANA issues should be addressed.

There was also a late review email from Axel Colin de Verdière and Kerry Lynn that should be answered, tickets for that #145, #146 and #147, #148 and #149

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-02-10
06 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

some IANA issues should be addressed.

There was also a late review email from Axel Colin de Verdière that should be answered, tickets for that #145, #146 and #147

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-02-09
06 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

some IANA issues should be addressed.

There was also a late review email from Axel Colin de Verdière that should be answered

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-02-09
06 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

There was also a late review email from Axel Colin de Verdière that should be answered

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-02-09
06 Adrian Farrel Some questions from IANA need to be addressed.
There was also a late review email from Axel Colin de Verdière that should be answered
2014-02-09
06 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::Point Raised - writeup needed from Waiting for AD Go-Ahead
2014-02-07
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-01-31
06 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2014-01-31
06 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2014-01-29
06 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2014-01-29
06 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-trickle-mcast-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-trickle-mcast-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA still has questions about this document's IANA actions. Please see below.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First in the Destination Options and Hop-by-Hop Options registry in the Internet Protocol Version 6 (IPv6) Parameters page at

http://www.iana.org/assignments/ipv6-parameters/

the following option, already registered per the IESG, will be updated as follows:

Hex Value: 0x6D
act: 01
chg: 1
rest: 01101
Description: MPL Option
Reference: [ this document ]

QUESTIONS:

1) The following early allocation was completed for this document as per a request from the IESG Secretary:

0x6D 01 1 01101 MPL Option [draft-ietf-roll-trickle-mcast]

Is this still valid? If yes, please update the text in the next version for section 12.1,  "MPL Option Type," to indicate that 0x6D has been  assigned to MPL Option.

2) Table 1 in Section 12.1 includes a field called "Mnemonic". However, we do not have
a field called "Mnemonic" in the "Destination Options and Hop-by-Hop Options."


Second, in the ICMPv6 "type" Numbers registry in Internet Control Message Protocol version 6 (ICMPv6) Parameters at

http://www.iana.org/assignments/icmpv6-parameters/

a new type is to be added to the registry as follows:

Type: [ TBD-at-registration ]
Name: MPL Control Message
Reference: [ this document ]

Third, in the Variable Scope Multicast Addresses registry in the Internet Protocol Version 6 Multicast Registry at

http://www.iana.org/assignments/ipv6-multicast-addresses/

IANA will assign one IPv6 multicast address and update the reference for an IPv6 multicast address already assigned through this document.

IANA will allocate an IPv6 multicast address, with Group ID in the range [0x01,0xFF] as follows:

Address: [ TBD-at-registration ]
Description:
Reference: [ RFC-to-be ]
Date Registered: [ TBD-at-registration ]

QUESTION:
What is the description to be used in the registration of this new IPv6 multicast address?

IANA will also update the following IPv6 multicast assignment:

FF0X:0:0:0:0:0:0:FC ALL_MPL_FORWARDERS [draft-ietf-roll-trickle-mcast] 2013-04-10

QUESTION:
Is this address still valid? If so, please update the text in the next version for section 12.3, "Well-known Multicast Addresses," to include the assigned address.

IANA understands that these are only actions required to be completed upon approval of this document.


Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-01-27
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Kiran Chittimaneni
2014-01-27
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Kiran Chittimaneni
2014-01-24
06 Amy Vezza
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <roll@ietf.org>
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <roll@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-roll-trickle-mcast-06.txt> (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard

The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Multicast Protocol for Low power and Lossy Networks (MPL)'
  <draft-ietf-roll-trickle-mcast-06.txt> as Proposed Standard

This is a second last call, the first one having been abandoned to send
the document back to the working group. But the latest revision addresses
comments that were received during the first last call.

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-02-07. 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

  This document specifies the Multicast Protocol for Low power and
  Lossy Networks (MPL) that provides IPv6 multicast forwarding in
  constrained networks.  MPL avoids the need to construct or maintain
  any multicast forwarding topology, disseminating messages to all MPL
  Forwarders in an MPL Domain.  MPL uses the Trickle algorithm to
  manage message transmissions for both control and data-plane
  messages.  Different Trickle parameter configurations allow MPL to
  trade between dissemination latency and transmission efficiency.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1858/



2014-01-24
06 Amy Vezza State changed to In Last Call (ends 2013-10-24) from Last Call Requested
2014-01-24
06 Adrian Farrel Last call was requested
2014-01-24
06 Adrian Farrel State changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup
2014-01-24
06 Adrian Farrel Last call announcement was changed
2014-01-24
06 Adrian Farrel Last call announcement was generated
2014-01-22
06 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] -->  TBD

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-01-22
06 Ines Robles
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


* Responsible Area Director: Adrian Farrel …
Draft-ietf-roll-trickle-mcast - Write Up

Previous state: WG Document
Current state:  Last Call Finished on 09-13
--------------------------------------

1. Summary


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

This document specifies the Multicast Protocol for Low power and Lossy Networks
(MPL) that provides IPv6 multicast forwarding in  constrained networks.  MPL avoids
the need to construct or maintain any multicast forwarding topology, disseminating
messages to all MPL Forwarders in an MPL Domain.  MPL uses the Trickle algorithm
to manage message transmissions for both control and data-plane messages. 
Different Trickle parameter configurations allow MPL to trade between dissemination
latency and transmission efficiency.

The Intended RFC status is Proposed Standard, because a protocol is defined to
interchange multicast messages in low power and lossy environments.

2. Review and Consensus

The last issues were solved in version 06.

WG recommended to consider drafting a template or specific applicability statement
for MPL, which will make it clear what needs to be in an applicability statement to
explain topics, such as Hop Limit Range.

3. Intellectual Property

Email sent to the Authors asking confirmation:

Richard Kelsey replied on 08/30/2013.
Jonathan replied on 10/07/2013

There is one IPR
2012-08-03
ID # 1858
"Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01
                  belonging to Nokia Corporation"

4. Other points

Checklist for draft 06

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 (~~), 2 warnings (==), 1 comment (--).

-- Possible downref: Normative reference to a draft: ref.
    'I-D.ietf-6man-multicast-scopes'

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?
All authors have confirmed no IPR to be disclosed.

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, this draft should wait until draft-ietf-6man-multicast-scopes is published.

Are all normative references made to documents that are ready for advancement and
are otherwise in a clear state? Yes.

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? Yes.

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? Yes.

a. MPL Option Type --> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

b. MPL ICMPv6 type --> TBD -http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2

c. Two - Well-know Multicast Addresses: -
  i. IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] --> http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#lowpan_nhc

  ii. ALL_MPL_FORWARDERS --> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#ipv6-multicast-addresses-4

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

IANA is requested to allocate an IPv6 multicast address, with Group ID in the
      range [0x01,0xFF] for 6LoWPAN compression [RFC6282] should mention IPv6 Low Power Personal Area Network Parameters - LOWPAN_NHC Header Type registry.

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

Have reasonable registry names been chosen (that will not be confused with those of
other registries),? Yes.

and have the initial contents and valid value ranges been clearly specified? TBD for
MPL Option Type, MPL ICMPv6 type and  Well-known Multicast Addresses.
2014-01-21
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-01-21
06 Jonathan Hui IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2014-01-21
06 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-06.txt
2013-11-24
05 Christer Holmberg Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg.
2013-11-21
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tero Kivinen.
2013-11-05
05 Adrian Farrel State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2013-10-24
05 (System) State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-10-24)
2013-10-22
05 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-trickle-mcast-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-trickle-mcast-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about the IANA Actions requested in this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First in the Destination Options and Hop-by-Hop Options subregistry of the Internet Protocol Version 6 (IPv6) Parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters/

a new option will be registered as follows:

Hex Value: [ TBD-at-registration ]
Binary Value:
act: 01
chg: 1
rest: [ TBD-at-registration ]
Description: MPL Option
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value of 01101 as the value for the parameter rest.

QUESTION:
1) The following early allocation was completed for this draft
document as per a request from the IESG Secretary:

0x6D 01 1 01101 MPL Option [draft-ietf-roll-trickle-mcast]

Is this still valid?  If yes, please update the text in the next version
for section 12.1 for "MPL Option Type" to indicate that 0x6D has been
assigned to MPL Option.

2) Table 1 in Section 12.1 has "Mnemonic".  However we do not have
a field called "Mnemonic" in the sub-registry "Destination Options
and Hop-by-Hop Options".


Second, in the ICMPv6 "type" Numbers subregistry of the Internet Control Message Protocol version 6 (ICMPv6) Parameters located at:

http://www.iana.org/assignments/icmpv6-parameters/

a new type is to be added to the registry as follows:

Type: [ TBD-at-registration ]
Name: MPL Control Message
Reference: [ RfC-to-be ]

Third, in the Variable Scope Multicast Addresses subregistry of the Internet Protocol Version 6 Multicast Registry located at:

http://www.iana.org/assignments/ipv6-multicast-addresses/

IANA will allocate an IPv6 multicast address, with Group ID in the range [0x01,0xFF] as follows:

Address: [ TBD-at-registration ]
Description:
Reference: [ RFC-to-be ]
Date Registered: [ TBD-at-registration ]

QUESTION:
What is the description to be used in the registration of this IPv6 multicast address?

IANA has made the following IPv6 multicast assignment for this draft
document:

FF0X:0:0:0:0:0:0:FC ALL_MPL_FORWARDERS [draft-ietf-roll-trickle-mcast] 2013-04-10

Is the address still valid?  If yes, please update the text in the next
version for section 12.3 for "Well-known Multicast Addresses" to include
the assigned address.

IANA understands that these are only actions required to be completed upon approval of this document.


Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2013-10-22
05 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2013-10-17
05 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2013-10-17
05 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2013-10-17
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2013-10-17
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2013-10-11
05 Ines Robles Changed document writeup
2013-10-10
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2013-10-10
05 Cindy Morgan
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <roll@ietf.org>
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <roll@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-roll-trickle-mcast-05.txt> (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard

The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Multicast Protocol for Low power and Lossy Networks (MPL)'
  <draft-ietf-roll-trickle-mcast-05.txt> as Proposed Standard

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 2013-10-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

  This document specifies the Multicast Protocol for Low power and
  Lossy Networks (MPL) that provides IPv6 multicast forwarding in
  constrained networks.  MPL avoids the need to construct or maintain
  any multicast forwarding topology, disseminating messages to all MPL
  Forwarders in an MPL Domain.  MPL uses the Trickle algorithm to
  manage message transmissions for both control and data-plane
  messages.  Different Trickle parameter configurations allow MPL to
  trade between dissemination latency and transmission efficiency.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1858/
2013-10-10
05 Cindy Morgan State changed to In Last Call from Last Call Requested
2013-10-10
05 Adrian Farrel Last call was requested
2013-10-10
05 Adrian Farrel Ballot approval text was generated
2013-10-10
05 Adrian Farrel State changed to Last Call Requested from AD Evaluation
2013-10-10
05 Adrian Farrel Last call announcement was changed
2013-10-10
05 Adrian Farrel Last call announcement was generated
2013-10-10
05 Adrian Farrel Note changed to 'Ines Robles is the document shepherd.'
2013-10-10
05 Adrian Farrel Ballot writeup was changed
2013-10-07
05 Ines Robles Changed document writeup
2013-10-07
05 Adrian Farrel Changed document writeup
2013-10-03
05 Adrian Farrel Changed document writeup
2013-10-03
05 Adrian Farrel Ballot writeup was changed
2013-09-29
05 Adrian Farrel State changed to AD Evaluation from Publication Requested
2013-09-22
05 Ines Robles Changed document writeup
2013-09-19
05 Amy Vezza State changed to Publication Requested from I-D Exists (IESG: Dead)
2013-09-18
05 Michael Richardson Changed consensus to Yes from No
2013-09-18
05 Michael Richardson Some issues raised during WGLC were resolved without a new ID needed.
2013-09-18
05 Michael Richardson IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2013-09-18
05 Michael Richardson Changed document writeup
2013-09-04
05 Michael Richardson New revision addresses all open issues.
2013-09-04
05 Michael Richardson IETF WG state changed to In WG Last Call from WG Document
2013-08-30
05 Michael Richardson Document shepherd changed to Ines Robles
2013-08-29
05 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-05.txt
2013-08-29
04 (System) Document has expired
2013-08-29
04 (System) State changed to Dead from AD is watching
2013-05-22
04 Adrian Farrel Publication request issued in error
2013-05-22
04 Adrian Farrel State changed to AD is watching from AD Evaluation
2013-05-22
04 Michael Richardson IETF WG state changed to WG Document from Submitted to IESG for Publication
2013-05-20
04 Ted Lemon Last call announcement was generated
2013-05-18
04 Adrian Farrel Ballot writeup was changed
2013-05-18
04 Adrian Farrel Ballot writeup was generated
2013-05-17
04 Adrian Farrel State changed to AD Evaluation from Publication Requested
2013-05-17
04 Adrian Farrel Changed consensus to No from Yes
2013-05-15
04 Cindy Morgan Note added 'JP Vasseur (jpv@cisco.com) is the document shepherd.'
2013-05-15
04 Cindy Morgan Intended Status changed to Proposed Standard
2013-05-15
04 Cindy Morgan IESG process started in state Publication Requested
2013-05-15
04 Michael Richardson IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2013-03-14
04 Michael Richardson Annotation tag Revised I-D Needed - Issue raised by WGLC cleared.
2013-03-14
04 Michael Richardson IETF WG state changed to In WG Last Call from WG Document
2013-03-14
04 Michael Richardson Annotation tag Revised I-D Needed - Issue raised by WGLC set.
2013-03-14
04 Michael Richardson Changed consensus to Yes from Unknown
2013-02-25
04 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-04.txt
2013-01-24
03 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-03.txt
2012-10-19
02 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-02.txt
2012-08-16
01 Michael Richardson Changed shepherd to JP Vasseur
2012-08-03
(System) Posted related IPR disclosure: Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast belonging to Nokia Corporation
2012-07-13
01 Jonathan Hui New version available: draft-ietf-roll-trickle-mcast-01.txt
2011-10-13
00 (System) Document has expired
2011-04-11
00 (System) New version available: draft-ietf-roll-trickle-mcast-00.txt