Draft-ietf-roll-trickle-mcast - Write Up
Previous state: WG Document
Current state: Last Call Finished on 09-13
* Responsible Area Director: Adrian Farrel firstname.lastname@example.org
* Document Shepherd: Ines Robles email@example.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
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
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?
Is the intent of the document accurately and adequately explained in the introduction?
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.
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.