The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
RFC 6553
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
06 | (System) | Notify list changed from 6man-chairs@ietf.org, draft-ietf-6man-rpl-option@ietf.org to (None) |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Ralph Droms |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
|
2012-03-27
|
06 | (System) | RFC published |
|
2011-12-22
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-12-22
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2011-12-22
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2011-12-22
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-12-21
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2011-12-21
|
06 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-12-20
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-12-20
|
06 | (System) | IANA Action state changed to In Progress |
|
2011-12-20
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2011-12-20
|
06 | Amy Vezza | IESG has approved the document |
|
2011-12-20
|
06 | Amy Vezza | Closed "Approve" ballot |
|
2011-12-20
|
06 | Amy Vezza | Approval announcement text regenerated |
|
2011-12-20
|
06 | Amy Vezza | Ballot writeup text changed |
|
2011-12-20
|
06 | Jari Arkko | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
|
2011-12-18
|
06 | Ralph Droms | [Ballot comment] Discuss cleared, 2011/12/18. Disposition of previous Discuss points: 1. From section 4: Datagrams sent between RPL routers MUST include a RPL Option … [Ballot comment] Discuss cleared, 2011/12/18. Disposition of previous Discuss points: 1. From section 4: Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY include both. A datagram including a SRH does not need to include a RPL Option since both the source and intermediate routers ensure that the SRH does not contain loops. Are there any other circumstances under which a datagram would require both a RPL Option and a RPL SRH? For example, would a datagram with an SRH also need a RPL Option to identify the RPL Instance the datagram is to be forwarded through? 2. Cleared, based on updated text in rev -06. |
|
2011-12-18
|
06 | Ralph Droms | [Ballot discuss] 1. Moved to a Comment, based on updated text in rev -06. |
|
2011-12-18
|
06 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
|
2011-12-15
|
06 | Cindy Morgan | Removed from agenda for telechat |
|
2011-12-14
|
06 | Jari Arkko | Placed on agenda for telechat - 2011-12-15 |
|
2011-12-14
|
06 | Stephen Farrell | [Ballot comment] |
|
2011-12-14
|
06 | Stephen Farrell | [Ballot discuss] Same discuss point as for the other RPL doc. Should have the same solution as well. What countermeasures exist for the attacks listed … [Ballot discuss] Same discuss point as for the other RPL doc. Should have the same solution as well. What countermeasures exist for the attacks listed in section 6? I guess at least some hop-by-hop authentication and integrity would provide some accountability and prevent some spoofs. Doesn't RPL have some such mechanism that can be used? If so, then wouldn't it be right to RECOMMEND support for that and maybe even use of that? |
|
2011-12-14
|
06 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
|
2011-12-14
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-12-14
|
06 | (System) | New version available: draft-ietf-6man-rpl-option-06.txt |
|
2011-12-04
|
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Matt Lepinski. |
|
2011-12-01
|
06 | Cindy Morgan | Removed from agenda for telechat |
|
2011-12-01
|
06 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
|
2011-12-01
|
06 | Jari Arkko | [Ballot comment] Sorry, posted the IANA issue in wrong tracker window... |
|
2011-12-01
|
06 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss |
|
2011-12-01
|
06 | Jari Arkko | [Ballot discuss] Holding a discuss for IANA: IESG: IANA has questions about draft-ietf-6man-rpl-routing-header-04.txt: The IANA Considerations section asks us to register the following: 1) … [Ballot discuss] Holding a discuss for IANA: IESG: IANA has questions about draft-ietf-6man-rpl-routing-header-04.txt: The IANA Considerations section asks us to register the following: 1) a Routing Type at http://www.iana.org/assignments/ipv6-parameters 2) a code under "Destination Unreachable" in the ICMPv6 "Code" Fields registry at http://www.iana.org/assignments/icmpv6-parameters However, it does not tell us how to fill in the description field for these registrations. We could guess that the description for the latter might be "the router cannot satisfy the strict source-route requirement," but the document isn't clear. Please add the precise text you want us to use in the registry for both registrations. 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. Thanks, Amanda Baber IANA |
|
2011-12-01
|
06 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from Yes |
|
2011-12-01
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-30
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-30
|
06 | Sean Turner | [Ballot comment] I support Stephen's discuss. |
|
2011-11-30
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-30
|
06 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-30
|
06 | Adrian Farrel | [Ballot comment] I have no objection to the publication of this document, but I have a umber of questions/nits that I hope you will consider. … [Ballot comment] I have no objection to the publication of this document, but I have a umber of questions/nits that I hope you will consider. Section 1 To that end, this document proposes a new IPv6 option, s/proposes/defines/ --- Setion 2 Every RPL router along a packet's delivery path processes and updates the RPL Option. If the received packet does not already contain a RPL Option, the RPL router must insert a RPL Option before forwarding it to another RPL router. Surely that means that the absence of the option indicates a defect in the upstream router. This issue is also present in section 4 where there is some flexibility about whether to include the RPL Option, but no guidance. --- Section 3 Please consider using RFC2119 language (e.g. "shall") --- Section 3 Nodes that do not understand the RPL Option MUST discard the packet. You cannot state this in this way. Nodes that do not understand the option will not implement this spec! You probably simply need: As defined in [foo] nodes that do not understand an option on a received packet MUST discard the packet. --- Sections 3 and 7 Please check "sub-TLV" and "TLV". I think you have used them interchangeably. |
|
2011-11-30
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-29
|
06 | Ralph Droms | [Ballot discuss] 1. The first sentence of section 4: Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route … [Ballot discuss] 1. The first sentence of section 4: Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY include both. Under what circumstances would a RPL router include an SRH but not a RPL Option? 2. This issue requires a little clarification before I can provide an actionable Discuss issue. Is it possible to deploy RPL in a network in which not all of the nodes in the network participate in RPL? E.g., can there be "leaf" nodes, the equivalent of hosts, that do not participate in RLL and that exchange datagrams with immediate neighbors that are RPL routers? There is a hint that such a deployment is anticipated in the phrase "attachment router" in section 4. If so, I think there needs to be additional text similar to that in section 5 describing how a RPL router must ensure that it doesn't forward a datagram containing a RPL Option to a non-RPL leaf node. |
|
2011-11-29
|
06 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-11-29
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-29
|
06 | Robert Sparks | [Ballot comment] Please double-check the first paragraph of section 4 to make sure that "ICMPv6 errors generated by inserting the RPL option" is really what … [Ballot comment] Please double-check the first paragraph of section 4 to make sure that "ICMPv6 errors generated by inserting the RPL option" is really what you mean to say - are you talking about errors that resulted from inserting the option itself, or possibly other ICMP errors that might result from other data in the tunnel header? |
|
2011-11-29
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-29
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-28
|
06 | Russ Housley | [Ballot comment] The Gen-ART Review by Joel Halpern on 22-Nov-2011 included a suggestion for improved clarity. Please consider it. While calling a bit … [Ballot comment] The Gen-ART Review by Joel Halpern on 22-Nov-2011 included a suggestion for improved clarity. Please consider it. While calling a bit the O bit does not appear unreasonable, I note that when looking at the packet form, the difference between the O bit and the mbz bits marked as 0 is small, and a likely source of confusion for the reader. |
|
2011-11-28
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-28
|
06 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-28
|
06 | Stephen Farrell | [Ballot comment] - Why does this header need an instance ID when the SRH did not? - I don't get why this wasn't part of … [Ballot comment] - Why does this header need an instance ID when the SRH did not? - I don't get why this wasn't part of the core RPL spec, if in fact "RPL requires..." this as stated at the start of section 2. - s2, s/This draft specifies the use.../This draft also specifies the use.../ would be clearer as the non-tunnelled option is also allowed here. - s4, this says the router MUST include the RPL option - but is that needed in *every* packet? - s6, it would be better to give more detail of the several potential attacks, so that people could know to look out for or mitigate those. |
|
2011-11-28
|
06 | Stephen Farrell | [Ballot discuss] Same discuss point as for the other RPL doc. Should have the same solution as well. What countermeasures exist for the attacks listed … [Ballot discuss] Same discuss point as for the other RPL doc. Should have the same solution as well. What countermeasures exist for the attacks listed in section 6? I guess at least some hop-by-hop authentication and integrity would provide some accountability and prevent some spoofs. Doesn't RPL have some such mechanism that can be used? If so, then wouldn't it be right to RECOMMEND support for that and maybe even use of that? |
|
2011-11-27
|
06 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-11-27
|
06 | Stephen Farrell | [Ballot comment] - Why does this header need an instance ID when the SRH did not? - I don't get why this wasn't part of … [Ballot comment] - Why does this header need an instance ID when the SRH did not? - I don't get why this wasn't part of the core RPL spec, if in fact "RPL requires..." this as stated at the start of section 2. - s2, s/This draft specifies the use.../This draft also specifies the use.../ would be clearer as the non-tunnelled option is also allowed here. - s4, this says the router MUST include the RPL option - but is that needed in *every* packet? - s6, it would be better to give more detail of the several potential attacks, so that people could know to look out for or mitigate those. |
|
2011-11-27
|
06 | Stephen Farrell | [Ballot discuss] What countermeasures exist for the attacks listed in section 6? I guess at least some hop-by-hop authentication and integrity would provide some accountability … [Ballot discuss] What countermeasures exist for the attacks listed in section 6? I guess at least some hop-by-hop authentication and integrity would provide some accountability and prevent some spoofs. Doesn't RPL have some such mechanism that can be used? If so, then wouldn't it be right to RECOMMEND support for that and maybe even use of that? |
|
2011-11-27
|
06 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-11-22
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
|
2011-11-22
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
|
2011-11-22
|
06 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
|
2011-11-22
|
06 | Jari Arkko | Ballot has been issued |
|
2011-11-22
|
06 | Jari Arkko | Created "Approve" ballot |
|
2011-11-22
|
06 | Jari Arkko | Placed on agenda for telechat - 2011-12-01 |
|
2011-11-22
|
06 | Jari Arkko | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-11-14
|
05 | (System) | New version available: draft-ietf-6man-rpl-option-05.txt |
|
2011-10-31
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-10-28
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
|
2011-10-28
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
|
2011-10-26
|
06 | Amanda Baber | IANA has a question about one of the actions to be performed upon approval of this document. ACTION 1: IANA will register the following in … IANA has a question about one of the actions to be performed upon approval of this document. ACTION 1: IANA will register the following in the Destination Options and Hop-by-Hop Options registry at http://www.iana.org/assignments/ipv6-parameters TBD 01 1 TBD RPL Option [RFCthis] ACTION 2: IANA will create the following registry: Registry Name: RPL-option-TLV Registration Procedures: IETF Review Reference: [RFC-to-be] Type Description Reference ------ ----------- --------- 0-255 Unassigned QUESTION: Should "0" or any other value be marked "Reserved"? |
|
2011-10-17
|
06 | Amy Vezza | Last call sent |
|
2011-10-17
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <ipv6@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-6man-rpl-option-04.txt> (RPL Option for Carrying RPL Information in Data-Plane Datagrams) to Proposed Standard The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'RPL Option for Carrying RPL Information in Data-Plane Datagrams' <draft-ietf-6man-rpl-option-04.txt> as a 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 2011-10-31. 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 The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL Option for use within a RPL domain. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ No IPR declarations have been submitted directly on this I-D. |
|
2011-10-17
|
06 | Jari Arkko | Last Call was requested |
|
2011-10-17
|
06 | (System) | Ballot writeup text was added |
|
2011-10-17
|
06 | (System) | Last call text was added |
|
2011-10-17
|
06 | (System) | Ballot approval text was added |
|
2011-10-17
|
06 | Jari Arkko | State changed to Last Call Requested from AD Evaluation::AD Followup. |
|
2011-10-17
|
06 | Jari Arkko | Last Call text changed |
|
2011-10-11
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-10-11
|
04 | (System) | New version available: draft-ietf-6man-rpl-option-04.txt |
|
2011-06-17
|
06 | Jari Arkko | State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>I have reviewed this draft. Some of the issues from the other draft are visible in … State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>I have reviewed this draft. Some of the issues from the other draft are visible in this one as well, and I saw two additional substantive issues: - we need to specify the behavior with regards to the data in this option better - the text about processing packets in RPL border routers should be written in a different manner Both of these should be easily addressed, however. Please revise the draft and we can send the draft to IETF Last Call. Here are my comments in more detail: > Datagrams being forwarded within a RPL domain MUST include a RPL > Option. For datagrams sourced within a RPL domain, the RPL Option > MAY be included in the datagram itself. I'm not sure I understand the difference or its motivation. Do you really mean that a packet might not have the option until it hits the first router? Or are you just talking about something that happens internally on a host, but on the wire all packets would still have the option? Also, since the tunnel (or something else) is used to include the option for datagrams sourced outside the RPL domain, wouldn't it be easier to just say this: "Datagrams sent between nodes within an RPL domain MUST include an RPL Option." > For datagrams sourced > outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in > [RFC2473] SHOULD be used to include a RPL Option. This text should be aligned with whatever conclusion we will have for the issue that I raised with the other document. > To help avoid IP-layer fragmentation, the RPL Option has a maximum > size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain > SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop > Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional > extension headers or options needed within RPL domain). There's a same MTU issue here as in the other document. > The action taken by using the RPL Option and the potential set of > sub-TLVs carried within the RPL Option MUST be specified by the RFC > of the protocol that use that option. No TLVs are defined in this > document. I think you should define the behavior when a node encounters a sub-TLV that it does not recognize. E.g., ignore and move on to the next sub-TLV. Or do you want a stricter policy? In any case, for future extensions it will be necessary to know how they are treated by legacy RPL nodes. > In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due > to the added cost and complexity required to process and carry a > datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes > how to avoid using IPv6-in-IPv6 tunneling in such specific cases and > the risks involved. Again, the same comments as in the other draft. Please delete this paragraph. > For datagrams exiting the RPL domain, RPL Border Routers MUST remove > the RPL Option from the datagram. If the RPL Option was included > using tunneled mode and the RPL Border Router serves as the tunnel > end-point, removing the outer IPv6 header serves to remove the RPL > Option as well. Otherwise, the RPL Border Router assumes that the > RPL Option was included using transport mode and MUST remove the RPL > Option from the IPv6 Hop-by-Hop Option header. The part about removing the RPL option even in a non-tunneled case relates to the issue of supporting that particular mode of operation. But in addition, I wonder if you should write the above text not in terms of packet modification operations but rather in terms of forwarding decision outcomes. Like this, for instance: "For datagrams destined to the RPL Border Router the router processes the packet in the usual way. For instance, if the RPL Option was included using tunneled mode and the RPL Border Router serves as the tunnel end-point, the router removes the outer IPv6 header, at the same removing the RPL Option as well. Datagrams destined elsewhere within the same RPL domain are forwarded to the right interface. Datagrams destined outside the RPL domain are dropped." > 6. Usage of the RPL Option > > The RPL Option is only for use within a RPL domain. RPL routers MUST > process and include the RPL Option when forwarding datagrams to other > nodes within the RPL domain. Routers on the edge of a RPL domain > MUST remove the RPL Option when forwarding datagrams to nodes outside > the RPL domain. What is it that this section says that is not already covered by sections 2 and 5: Sect 2: Datagrams being forwarded within a RPL domain MUST include a RPL Option. Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 header serves to remove the RPL Option as well. Otherwise, the RPL Border Router assumes that the RPL Option was included using transport mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option header. > This option may be used to mount several potential attacks since > routers may be flooded by bogus datagram containing the RPL option. > It is thus RECOMMENDED for routers to implement a rate limiter for > datagrams using the RPL Option. Please open this up a bit. What specific danger does flooding by bogus datagrams and RPL options cause? What would be the default settings for the rate limiter? > Opt Data Len: 8-bit field indicating the length of the option, in > octets, excluding the Option Type and Opt Data Len fields. > > Down 'O': 1-bit flag as defined in Section 11 of > [I-D.ietf-roll-rpl]. > > Rank-Error 'R': 1-bit flag as defined in Section 11 of > [I-D.ietf-roll-rpl]. > > Forwarding-Error 'F': 1-bit flag as defined in Section 11 of > [I-D.ietf-roll-rpl]. > > RPLInstanceID: 8-bit field as defined in Section 11 of > [I-D.ietf-roll-rpl]. > > SenderRank: 16-bit field as defined in Section 11 of > [I-D.ietf-roll-rpl]. > > Values within the RPL Option are expected to change en-route. This specification needs to describe what the behavior of a router is with the content of the option. I think this is easy, you should just add to the end: "The processing shall follow the rules described in Section 11.2 of [roll-rpl]. As an aside, the entire Section 11 is marked in roll-rpl as non-normative. I don't think that's actually right as far as 11.2 goes, because it contains tons of MUSTs and SHOULDs. Perhaps you want to fix that in AUTH48... |
|
2011-06-09
|
06 | Jari Arkko | State changed to AD Evaluation from Publication Requested. |
|
2011-03-30
|
06 | Cindy Morgan | Document Writeup draft-ietf-6man-rpl-option-03.txt As required by RFC 4858 </rfc/rfc4858.txt>, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This … Document Writeup draft-ietf-6man-rpl-option-03.txt As required by RFC 4858 </rfc/rfc4858.txt>, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Brian Haberman is the document shepherd for this document, has reviewed this version, and believes it is ready for IESG review. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This draft has been reviewed by both members of the 6man WG and the ROLL WG. The shepherd does not have concerns with the depth or breadth of these reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has strong concurrence from a small number of WG participants. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist </id-info/checklist.html> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? This draft passes ID-nits with three warnings which can be resolved during the next editorial pass. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All references are in order modulo a reference to a draft that has been published as an RFC. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA Considerations are in order. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL option for use within a RPL domain. Working Group Summary This document was reviewed by the 6man and RPL WGs and represents the consensus of those groups. Document Quality Several external groups have indicated their plans to carry out large-scale deployments using the RPL option defined in this document. |
|
2011-03-30
|
06 | Cindy Morgan | Draft added in state Publication Requested |
|
2011-03-30
|
06 | Cindy Morgan | [Note]: 'Brian Haberman (brian@innovationslab.net) is the document shepherd.' added |
|
2011-03-29
|
03 | (System) | New version available: draft-ietf-6man-rpl-option-03.txt |
|
2011-02-08
|
02 | (System) | New version available: draft-ietf-6man-rpl-option-02.txt |
|
2010-10-22
|
01 | (System) | New version available: draft-ietf-6man-rpl-option-01.txt |
|
2010-07-26
|
00 | (System) | New version available: draft-ietf-6man-rpl-option-00.txt |