Shepherd writeup
draft-ietf-roll-trickle-mcast
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.
Back