Shepherd writeup
rfc7731-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.
Back