Skip to main content

The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
draft-ietf-6man-rpl-option-06

Revision differences

Document history

Date Rev. By Action
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
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
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (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'
  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.
I have reviewed this draft. Some of the issues from the other draft are visible …
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
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 , 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 , 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 
        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