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

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.

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

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

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.

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.

[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.)

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

[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? :)

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

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

---

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)

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

---

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)

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

---

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)

[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)

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

[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)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (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)'
  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/

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.

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.

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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (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)'
  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/