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.