Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks
draft-ietf-roll-p2p-rpl-17

[Ballot discuss]
The security of RPL is either unsecured, pre-installed, or authenticated.  We'll dismiss authenticated because it's not fully defined in RPL and you don't do define it in this draft  Assuming an implementation can support pre-installed, I get how you can try to find a new route to the target because the origin and target share a key.  If there's no route, then does that mean that the target isn't yet part of the DODAG but has a key or does that mean the target has to get a key to become part of the DODAG?  If it's the former, then no issue and I'll clear right away if it's the later, then is there an when reusing the key from the previous DODAG for this temporary DODAG?

I share the INT AD's concerns about the data object, but mostly because I think RPL security isn't really going to get implemented.  More importantly, there's also concerns with encrypting really small amounts of data.  What if the data to be secured is only 1 byte?

[Ballot comment]
BTW - I find this rpl thing fascinating.

s4: I'm not sure it's worth adding but maybe: "they have the key necessary to join the network, if acting in a secure fashion" or something like that.

s6.1: Is there a statement in 6550 that says the default for the Authentication Flag is cleared? I know it's not defined and obviously can't be one, but I'm just looking for an explicit statement that says the default is cleared.

[Ballot comment]
(Apologies, I had to read this document in chunks due
to other time pressures, so this review might also be a
bit chunky;-)

- I agree with Sean's DISCUSS

- section 3, the term Target might create an irritating
conflict with how that same term is used in geopriv but
I'm guessing you won't want to change.

- section 4, I don't quite get how this is triggered,
in the remote-conrol/lamp case, is the remote-control
the Origin or a non-router host? If the latter, then
I'm not sure how the remote-control's next-hop router
could know to trigger this process. The former option
seems quite constraining, since it'd mean that all
hosts that can benefit from this need to be p2p-rpl
aware routers, and that seems less rather than more
likely.

- section 4, I'm also not sure how the remote-control
knows the lamp's IP address to start with. How's that
work?  Specification for that probably doesn't belong
here, but I wondered and it might be good to explain a
bit in this draft.

- section 4, 3rd last para: I don't see how the guy who
makes the remote-control (if its the Source LLN router)
can know how to set all those things that the "network
designer" knows how to set. Maybe I'm just missing the
point?

- section 5: sending application data with routing
messages seems to have security issues since the DIOs
are sent more or less all over I think? That implies
that a one-to-many confidentiality service might be
needed which seems very very hard (i.e. silly) in a p2p
context. And of course that also assumes that the
application runs on the "Source" LLN router as well so
you can know what is and is not time-critical. I also
wonder what'd happen if the "application data" you mean
were a TCP SYN packet which seems likely isn't it? The
same security issues arise with the data option in a
DRO. (FYI in case it helps this would have generated a
DISCUSS from me for a standards track protocol but
since there are already two discusses about this I'll
not pile on.)

- 6.1, Why is "Authentication Enabled: 0" the default
and why does that differ from 6550? (If it does.)

- 7.1, Lifetime field - it wasn't clear to me when a
router starts counting down to the end of the Lifetime
for the DAG.

- 7.2, Only allowing 256 bytes here may effectively
mean securing that data is never possible. That seems
undesirable.

- 7.2 saying a deployment SHOULD take security into
consideration seems meaningless.

- section 8 says the DODAGID identifies the Origin and
that confused me, do you mean its value is the origin's
IP address?

- section 13 says: "Each RPL control message has a
secure version that allows the specification of the
level of security and the algorithms used to secure the
message. " and " These DIOs can be used in their secure
versions if desired" but I have to say I'm unconvinced
that that's sufficiently well defined here (or in 6550)
to allow interop and offer useful security. There
doesn't seem to be any mention of the "secure DRO" in
section 11 for example. I'd love to be proven wrong
however, so can you try convince me that I'm wrong?
(This would also have been a DISCUSS on a standards
track document, even if the authors could justifiably
say that the real fault lies in 6550.)

[Ballot comment]

(Apologies, I had to read this document in chunks due
to other time pressures, so this review might also be a
bit chunky;-)

- section 3, the term Target might create an irritating
conflict with how that same term is used in geopriv but
I'm guessing you won't want to change.

- section 4, I don't quite get how this is triggered,
in the remote-conrol/lamp case, is the remote-control
the Origin or a non-router host? If the latter, then
I'm not sure how the remote-control's next-hop router
could know to trigger this process. The former option
seems quite constraining, since it'd mean that all
hosts that can benefit from this need to be p2p-rpl
aware routers, and that seems less rather than more
likely.

- section 4, I'm also not sure how the remote-control
knows the lamp's IP address to start with. How's that
work?  Specification for that probably doesn't belong
here, but I wondered and it might be good to explain a
bit in this draft.

- section 4, 3rd last para: I don't see how the guy who
makes the remote-control (if its the Source LLN router)
can know how to set all those things that the "network
designer" knows how to set. Maybe I'm just missing the
point?

- section 5: sending application data with routing
messages seems to have security issues since the DIOs
are sent more or less all over I think? That implies
that a one-to-many confidentiality service might be
needed which seems very very hard (i.e. silly) in a p2p
context. And of course that also assumes that the
application runs on the "Source" LLN router as well so
you can know what is and is not time-critical. I also
wonder what'd happen if the "application data" you mean
were a TCP SYN packet which seems likely isn't it? The
same security issues arise with the data option in a
DRO. (FYI in case it helps this would have generated a
DISCUSS from me for a standards track protocol but
since there are already two discusses about this I'll
not pile on.)

- 6.1, Why is "Authentication Enabled: 0" the default
and why does that differ from 6550? (If it does.)

- 7.1, Lifetime field - it wasn't clear to me when a
router starts counting down to the end of the Lifetime
for the DAG.

- 7.2, Only allowing 256 bytes here may effectively
mean securing that data is never possible. That seems
undesirable.

- 7.2 saying a deployment SHOULD take security into
consideration seems meaningless.

- section 8 says the DODAGID identifies the Origin and
that confused me, do you mean its value is the origin's
IP address?

- section 13 says: "Each RPL control message has a
secure version that allows the specification of the
level of security and the algorithms used to secure the
message. " and " These DIOs can be used in their secure
versions if desired" but I have to say I'm unconvinced
that that's sufficiently well defined here (or in 6550)
to allow interop and offer useful security. There
doesn't seem to be any mention of the "secure DRO" in
section 11 for example. I'd love to be proven wrong
however, so can you try convince me that I'm wrong?
(This would also have been a DISCUSS on a standards
track document, even if the authors could justifiably
say that the real fault lies in 6550.)

[Ballot discuss]
I have no general objections to the publication of the draft, but I have a few points to be discussed.

And here is my full review:

*Issue 1): data piggybacking:
Section 1., paragraph 9:

>    o  The utility and the implementation complexity of the Data Option
>      (Section 7.2) that provides a facility to piggyback time-critical
>      application data on the routing messages;

My DISCUSS is basically the same as Ralph's DISCUSS about the data piggybacking is actually in this protocol. I do not see any good justification for this in the draft and the introduction of this mode raises tons of questions on how this is handled in real life.
There is some light text about the purpose of this piggybacking in Section 5., paragraph 8, but there is for instance no central place where the usage of this mode and its implications is described. This looks like a hack, but not like a good idea. See also right down here for some further questions, just a few that came immediately to my mind:

Section 7.2., paragraph 9:

>    Data Option received inside a parent's DIO and MUST include this Data
>    Option in all its future DIO transmissions for this temporary DAG.
>    The same is true for a Target that needs to propagate the DIOs
>    further (required when the route discovery involves multiple
>    Targets).  If a Target chooses to include a Data Option inside a DRO,

  So this effectively means that the data is copied into multiple
  other messages and send out to the network, isn't it? Is there any
  control on whether this is causing congestion in that area where
  the messages are multiplied?


Section 7.2., paragraph 11:

>    Note that the data inside a Data Option has the same level of
>    security as the DIO/DRO message it is part of.  A P2P-RPL deployment
>    SHOULD take in consideration the security requirements of the data
>    being sent inside the Data Options when deciding the overall security
>    requirements.  Further, note that P2P-RPL does not guarantee
>    successful delivery of the data contained in a Data Option.

  There is a not so obvious dependency between the data carried in
  the Data Option and the P2P-RDO's R flag: If the upper layer is
  TCP and it is a TCP SYN the R flag must be set in order to carry
  the SYN ACK back to the originator.


Section 8.2., paragraph 2:

>    o  Reply (R): This flag MUST be set to zero on transmission and
>      ignored on reception.

  What if the piggybacked data requieres a response and a reply on
  the rpl level is not allowed?

Section 7.2., paragraph 8:

>    If the Origin chooses to include a Data Option inside its DIO, it
>    MUST include the same Data Option in all its future DIO transmissions
>    for this temporary DAG.  An Intermediate Router MUST NOT modify the

  What is 'same Data Option' meaning? Is it just the option itself
  or is the option with always the same data?


*Issue 2) Extemely vague retransmission handling of DRO-ACK
Section 10., paragraph 3:

>    A DRO message may fail to reach the Origin due to a number of
>    reasons.  Unlike the DIO messages that benefit from Trickle-
>    controlled retransmissions, the DRO messages are prone to loss due to
>    unreliable packet transmission in LLNs.  Since a DRO message travels
>    via link-local multicast, it cannot use link-level acknowledgements
>    to improve the reliability of its transmission.  Also, an
>    Intermediate Router may drop the DRO message (e.g., because of its
>    inability to store the state for the Hop-by-hop Route the DRO is
>    establishing).  To protect against the potential failure of a DRO
>    message to reach the Origin, the Target MAY request the Origin to
>    send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO
>    message.  Failure to receive such an acknowledgement within the
>    DRO_ACK_WAIT_TIME interval of sending the DRO message forces the
>    Target to resend the message.

  Is there anyback off mechanism for the retransmission of the DRO-ACK
  message? I haven't seen any.


*Issue 3) Missing safety margin for the reuse of RPLInstanceID:
Section 6.1., paragraph 2:

>    o  RPLInstanceID: RPLInstanceID MUST be a local value as described in
>      Section 5.1 of [RFC6550].  The Origin MUST NOT reuse an
>      RPLInstanceID for a route discovery if its previous route
>      discovery using this RPLInstanceID might still be going on.  As
>      described in Section 7.1, the Life Time parameter in the P2P Route
>      Discovery Option specifies the time duration the route discovery
>      lasts.  So, the Origin MUST NOT reuse an RPLInstanceID in a route
>      discovery until the Life Time of its previous route discovery
>      using this RPLInstanceID is over.  When initiating a new route
>      discovery to a particular Target, the Origin MUST NOT reuse the
>      RPLInstanceID used in a previous route discovery to this Target if
>      the previously discovered routes might still exist.  The Default

  What is the safety margin associated with 'might still exists'? In
  TCP there is the Maximum Segment Lifetime (MSL) that is an upper
  bound on how long something is expected to be in the network. Your
  phrasing is a bit weak in that respect, especially not all routers
  along a path will forget the RPLInstanceID at the same time. However,
  as this is an experimental specification where such an ultimate
  timeout is not known, I would be happy to have this documented in
  a separate section under 'Known Issues/Future Work'.


Section 6.1., paragraph 3:

>      Lifetime and Lifetime Unit parameters in the DODAG Configuration
>      Option specify the lifetime of the state the routers, including
>      the Origin and the Target, maintain for a Hop-by-hop or a Source
>      Route discovered using P2P-RPL.  Thus, an Origin can safely reuse
>      an RPLInstanceID to discover a new route to a Target if the
>      lifetime of all previously discovered routes to this Target using
>      this RPLInstanceID is over.

  I would suggest is over plus some delta on top of it, in order to
  have a safety margin.

[Ballot comment]
I suggest to add a section that describes more the experimental framework of this draft, including a list of items that a unclear by now, potentially in a (sub-)section 'Known Issues/Future Work'. I have found several places where open issues exists (see below) and also issue 3 in the DISCUSS part that should be documented in a single place -- for clarity and also for the simplicity of finding them in one spot and not scatterd around in the draft.


Section 6.1., paragraph 27:

>    Individual P2P-RPL deployments are encouraged to share their
>    experience with these default values with ROLL working group to help
>    guide the development of standards track version of the protocol.

  I would add this to the proposed section 'Known Issues/Future Work',
  just to have the possible 'construction areas' documented in a
  single place.


Section 9.2., paragraph 16:

>    Individual P2P-RPL deployments are encouraged to share their
>    experience with these rules with ROLL working group to help guide the
>    development of standards track version of the protocol.
>    Applicability Statements that specify the use of P2P-RPL MUST provide
>    guidance for setting Trickle parameters, particularly Imin and the
>    redundancy constant.

  This section until here seems to raise a number of questions that
  can only be answered in real deployments. I would add a pointer here
  to the proposed section 'Known Issues/Future Work'. The description
  itself in this section looks pretty comprehensive.

Section 2., paragraph 1:

>    One use case, common in home [RFC5826] and commercial building
>    [RFC5867] environments, involves a device (say a remote control or an
>    airduct controller) that suddenly needs to communicate with another
>    device (say a lamp or a humidity sensor) to which it does not already
>    have a route.  In this case, the remote control (or the airduct
>    controller) must be able to discover a route to the lamp (or the
>    humidity sensor) "on demand".

  I would remove the 'airduct controller' from the example as it
  doesn't add anything to the example, but just makes the text harder
  to read.

Section 8., paragraph 4:

>    A DRO message MAY serve the function of letting the routers in the
>    LLN know that a P2P-RPL route discovery is complete and no more DIO

  I am confused about the 'MAY'. Is the function now to let the routers
  know that the discovery is complete or not? I guess it should more
  read 'messages can server'?

[Ballot discuss]
I have no general objections to the publication of the draft, but I have a few points to be discussed. This is a placeholder until I have finished my review.

One item ahead: I'm in full support of Ralph's DISCUSS about the piggyback time-critical application data on the DIO messages.

[Ballot discuss]
I have no principal objections to the publication of the draft, but I have a few points to be discussed. This is a placeholder until I have finished my review.

One item ahead: I'm in full support of Ralph's DISCUSS about the piggyback time-critical application data on the DIO messages.

[Ballot comment]
1. selection of routes by the Target and sending the DRO:

In the Hop-by-Hop case, after the route is selected and DRO is sent,
can the Target send a better route to override the route sent earlier?
I'm thinking of the case in which an optimization occurs while the
temporary DODAG is running and the Target gets a better route.  Or,
once it has sent a DRO, does it resend the same route after receipt
subsequent DIOs?

In the Source-route case, does the Target send N DROs, one with each
selected route, and then stop sending DROs?

2. In section 9.7: Why is the DRO multicast to the next hop on the
path to the Origin?  Isn't the address of the next hop in the DRO
address list?

3. Does RPL have the same behavior that routes installed by RPL may
be retained beyond the lifetime of the DAG that caused the routes to
be installed?  If not, it might be helpful to add a note giving
implementors a heads-up.

4. Related to earlier comments about address selection, in section
9.4, this text:

  if the router cannot elide Compr (as specified in
  the P2P-RDO) prefix octets from its IPv6 address

ought to be edited to reflect that the Intermediate Router may have
multiple IPv6 addresses to choose from.  Should the Intermediate
Router consider the Target prefix and Compr in the selection of an
address to add to the P2P-RDO?

5. What link-scoped multicast address is used for forwarding
DROs?

The following are simply editorial nits:

1. It would be clearer (for me, anyway!) if the mode were simply given
as "Hop-by-Hop mode" or "Source routing mode" rather than by "H flag
is zero".

2. In section 11, "An Origin MAY use a Source Routing Header (SRH)
[RFC6554]...".  What else would it use?  How about "An Origin uses the
Source Routing Header (SRH) [RFC6554]..."

3. section 9.3: "send or receive" -> "send or process" (it's hard to
not receive the messages)

4. This sentence might benefit from more detail: "The temporary DAG
MUST NOT be used to route packets" (unless using a DAG to route data
packets [which is what I think is implied] is a term of art).

5. For consistency, could the DRO be named P2P-DRO?

[Ballot discuss]
I am confused by the last bullet in 6.1.  It states that a P2P-mode DIO may carry a PIO option, but no where does this document describe why (or how) that option would be used in this approach.  What benefit would including a PIO have?  Where would an arbitrary node in a RPL network get the information to include in a PIO?

I support Ralph's concern about the inclusion of the Data Option in this specification.

[Ballot discuss]
I have several architectural issues with the protocol specified in
draft-ietf-roll-p2p-rpl that I would like to discuss.

1. The Data Option introduces a new style of datagram delivery,
roughly based on IPv6, but with different delivery semantics.  The
Data Option also appears to be underspecified; for example:

* How is the checksum in the "upper layer protocol header ... in the
  Data field ..." computed; what is the pseudo-header?
* Does it make sense to carry, e.g., TCP in a P2P-RPL message that
  might be delivered to multiple targets?

I'm especially concerned by:

      "By not allowing the generation of DRO messages,
      an Origin can use P2P-RPL as purely a mechanism to deliver time-
      critical application data to the Target(s)."

which seems to allow P2P-RPL to operate solely as a Internet-layer
delivery mechanism without generating any routing information.

I had a brief discussion with Adrian about the Data Option. In my
opinion, the Data Option needs a more careful review, for example by
the 6man working group (someone in Transport, as well?), before it can
be published.  Adrian made the suggestion to remove the Data Option
from this document and publish it as a separate draft, which would
avoid delaying this document and allow for additional refinement of
the Data Option specification.

2. The use of the PIO option in P2P-RPL needs to be reviewed by 6man.
In my opinion, the PIO option should not be used here.  We already
have ND and RPL for disseminating information about prefixes.

3. Does it matter which of its addresses an intermediate node inserts
in the address list in the P2P-RDO?  If it does - and I expect it
might make a difference if, for example, the node has multiple non-LL
addresses from multiple RPL instances or the node has multiple
interfaces - how does the node know which address to select?  Are LL
addresses OK?

4. How does a node process and forward P2P-RPL control messages if it
has multiple interfaces?  For example, does it forward those messages
on all interfaces, including the one on which the control message was
received (as it would if the node has one interface)?

[Ballot comment]

1. selection of routes by the Target and sending the DRO:

In the Hop-by-Hop case, after the route is selected and DRO is sent,
can the Target send a better route to override the route sent earlier?
I'm thinking of the case in which an optimization occurs while the
temporary DODAG is running and the Target gets a better route.  Or,
once it has sent a DRO, does it resend the same route after receipt
subsequent DIOs?

In the Source-route case, does the Target send N DROs, one with each
selected route, and then stop sending DROs?

2. In section 9.7: Why is the DRO multicast to the next hop on the
path to the Origin?  Isn't the address of the next hop in the DRO
address list?

3. Does RPL have the same behavior that routes installed by RPL may
be retained beyond the lifetime of the DAG that caused the routes to
be installed?  If not, it might be helpful to add a note giving
implementors a heads-up.

4. Related to earlier comments about address selection, in section
9.4, this text:

  if the router cannot elide Compr (as specified in
  the P2P-RDO) prefix octets from its IPv6 address

ought to be edited to reflect that the Intermediate Router may have
multiple IPv6 addresses to choose from.  Should the Intermediate
Router consider the Target prefix and Compr in the selection of an
address to add to the P2P-RDO?

The following are simply editorial nits:

1. It would be clearer (for me, anyway!) if the mode were simply given
as "Hop-by-Hop mode" or "Source routing mode" rather than by "H flag
is zero".

2. In section 11, "An Origin MAY use a Source Routing Header (SRH)
[RFC6554]...".  What else would it use?  How about "An Origin uses the
Source Routing Header (SRH) [RFC6554]..."

3. section 9.3: "send or receive" -> "send or process" (it's hard to
not receive the messages)

4. This sentence might benefit from more detail: "The temporary DAG
MUST NOT be used to route packets" (unless using a DAG to route data
packets [which is what I think is implied] is a term of art).

5. For consistency, could the DRO be named P2P-DRO?

[Ballot discuss]
I am confused by the last bullet in 6.1.  It states that a P2P-mode DIO may carry a PIO option, but no where does this document describe why (or how) that option would be used in this approach.  What benefit would including a PIO have?  Where would an arbitrary node in a RPL network get the information to include in a PIO?

[Ballot comment]
I have no objections to the publication of this document, but I do have one comment:

The 2nd paragraph of Section 2 reads as if it is desirable to route traffic through a point of congestion.  I would suggest re-wording the second part of the paragraph to say that avoiding the congestion near the root is desirable using P2P routes.

[Ballot comment]
A small, non-blocking editorial point:

-- Section 5 --

The second paragraph and the fourth both start with the same sentence; I thought I was reading the same thing over again.  I thought I was reading the... ah.  I suggest re-phrasing to avoid that.

While we're on the fourth paragraph, there's some odd commatosis here:

  A P2P-RPL route discovery takes place by forming a temporary DAG
  rooted at the Origin.  The DIOs, used to create the temporary DAG,
  are identified by a new Mode of Operation (P2P Route Discovery mode
  defined in Section 6).  The DIOs, listing the P2P Route Discovery
  mode as the Mode of Operation, are henceforth referred to as the P2P
  mode DIOs.

When you set a clause off by commas, as you do twice in the quoted paragraph, you (often) make that clause non-restrictive, which means that it can be removed without changing the meaning of the sentence (try it with this sentence, and the phrase "as you do twice in the quoted paragraph").  In this case, both clauses (after "The DIOs" each time) are restrictive; all four commas need to disappear in a puff of orange smoke.

IANA has reviewed draft-ietf-roll-p2p-rpl-15 and has the following comments:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Mode of Operation subregistry of the Routing Protocol for Low Power and Lossy Networks (RPL) located at:

http://www.iana.org/assignments/rpl/rpl.xml

a new Mode of Operations will be registered as follows:

Value: [ tbd ]
Description: P2P Route Discovery Mode of Operation
Reference: [ RFC-to-be ]

Second, in the RPL Control Message Options subregistry of the Routing Protocol for Low Power and Lossy Networks (RPL) located at:

http://www.iana.org/assignments/rpl/rpl.xml

two new Control Message Options will be registered as follows:

Value: [ tbd ]
Meaning: P2P Route Discovery Option
Reference: [ RFC-to-be ]

Value: [ tbd ]
Meaning: Data Option
Reference: [ RFC-to-be ]

IANA understands that these are the only actions that need to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks) to Experimental RFC


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
  Networks'
  as Experimental RFC

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 2013-01-03. 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

  This document specifies a point-to-point route discovery mechanism,
  complementary to the RPL core functionality.  This mechanism allows
  an IPv6 router to discover "on demand" routes to one or more IPv6
  routers in the LLN such that the discovered routes meet specified
  metrics constraints.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review
======
Hi,

I have done my usual AD review of your document as part of processing
the publication request. This review should be considered alongside
my review of draft-ietf-roll-p2p-measurement as the documents are
closely linked.

I have a number of questions and minor issues that I would like to
resolve before advancing the documents.

As usual, all of my comments are up for discussion, but I think that a
new revision will be needed, so I have moved the document into "Revised
I-D Needed" state in the data tracker and will wait for your emails
and/or a new revision.

Many thanks for your work,
Adrian

---

I would like you to include some discussion of the "experiment". There
is a note in section 6.1 encouraging deployments to share their
experience of the default values, but that seems like the tip of the
iceberg. Section 9.2 might also usefully contain such a statement.

A way to approach this is to put a paragraph or two at the end of
Section 1 saying:

- This document is presented as an Experimental specification
  because...
- Reports of observations in implementation and deployment are
  encouraged in particular with respect to...
- It is anticipated that, if there is interest and positive reports
  of experimental research and deployments, this specification might
  be revised at some time in the future to progress it on to the
  Standards Track.

---

Some abbreviations will need to be spelled out:
DODAG
RPL

---

Section 1

  Also, the discovered routes may not
  be optimal.

I prefer s/may/might/

Similarly in Section 5

  Also, the discovered routes may not be the best available.

---

There are several mentions of the fact that this I-D allows discovery
of up to four Source Routes per Target. Should you include a comment
about why that limit is acceptable?

---

I am slightly worried by Section 5 saying

  The Target may
  remember the discovered route for use as a Source Route to reach the
  Origin.

Of course, this is true, but there is no evidence that the discovered
Origin-to-Target route can be reversed, so there is no evidence that the
discovered route will work as a Source Route to reach the Origin. I feel
that suggesting this option without qualifying it very heavily is rather
unwise.

Now 7.1 says

      *  The IPv6 addresses in the Address vector MUST be reachable in
        both Forward and Backward directions.  Reachability in the
        Backward direction allows a DRO message to use the route
        accumulated in the Address vector to travel from the Target to
        the Origin.

This would address my concern, but I don't see how a node filling an
address into the Address vector knows that that address is reachable in
the backward direction. That could, itself, be fixed if there is a
process that says a node receiving an Address vector MUST check the last
address in the list and drop the whole message if the address is not
reachable in the backward direction - ah, and there it is in Section
9.4.

So it is all a bit buried! Can you put in some forward pointers?

---

Starting at the top of Section 6 there are some rules about how messages
must be formed. E.g.:

  A P2P mode DIO
  MUST carry one and only one P2P Route Discovery Option

We need a statement (presumably a catch-all, and possibly a pointer to
6550) that tells an implementation what to do with a malformed message.
Some cases will be reject/discard, but I think some will be ignore. For
example, in Section 6.1:
  Version Number: MUST be set to zero
...can surely be safely ignored by the receiver.

And, a number of the fields if set wrongly will simply break things, but
it may be possible to protect against this by cross-checking with the
MOP.

At the end of 6.1, I do find...

  A router MUST discard a received P2P mode DIO if it violates any of
  the rules listed above.

...but it feels like this is intended to apply to the immediately-
preceding bullet list.

---

Section 6.1 has

  o  Mode of Operation (MOP): MUST be set to 4, corresponding to P2P
      Route Discovery mode.

I think this "4" needs to be replaced with "TBD1"

---

Section 7.1

      *  A router adding its address to the vector MUST ensure that its
        address does not already exist in the vector.

s/its address does/any of its addresses do/

---

Section 7.2 and 14.4

Why do you feel it necessary or good to create a new registry of payload
protocols?  Is the 5237 registry a problem for some reason?

Furthermore, why have you reserved 0xff for Private Use? Given that the
whole document is Experimental, this seems a bit extreme. Do you have
a specific motivation for this unusual assignment?

---

Section 8: Options

Since multiple options may be present, you need to describe any ordering
rules.

---

Section 13

Do you think you should advise applications sending data in the Data
Option to take their own precautions to:
a. secure against modification
b. encrypt
c. retransmit/acknowledge
the data they are sending?

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

The intended track of the RFC is Experimental, and the RFC type is indicated in
the title page header.

The rationale for proceeding with the Experimental track was that this document
and it companion ID (draft-ietf-roll-p2p-rpl-13)?are using the RPL protocol
specified in RFC6550 in a slightly different mode as originally specified by the
RFC.

Thus we think that it was reasonable to first get more experience on actual
deployment before moving to the Standard?track. There was no discontent on that
decision.

(2) 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:

  Targeting Low power and Lossy Networks (LLNs), the RPL routing
  protocol [RFC6550] provides paths along a Directed Acyclic Graph
  (DAG) rooted at a single router in the network.  Establishment and
  maintenance of a DAG is performed by routers in the LLN using DODAG
  Information Object (DIO) messages.  When two arbitrary routers
  (neither of which is the DAG's root) need to communicate, the data
  packets are restricted to travel only along the links in the DAG.
  Such point-to-point (P2P) routing functionality may not be sufficient
  for several Home and Building Automation applications [RFC5826]
  [RFC5867] due to the following reasons:

  o  The need to pre-establish routes: each potential destination in
      the network must declare itself as such ahead of the time a source
      needs to reach it.

  o  The need to route only along the links in the DAG: A DAG is built
      to optimize the routing cost to reach the root.  Restricting P2P
      routes to use only the in-DAG links may result in significantly
      suboptimal routes and severe traffic congestion near the DAG root.

  This document describes an extension to core RPL that enables an IPv6
  router in the LLN to discover routes to one or more IPv6 routers in
  the LLN "on demand", such that the discovered routes meet the
  specified metrics constraints, without necessarily going along the
  links in an existing DAG.  This reactive P2P route discovery
  mechanism is henceforth referred to as P2P-RPL.  P2P-RPL does not
  guarantee discovery of a route.  Also, the discovered routes may not
  be optimal.  However, any discovered routes are guaranteed to satisfy
  the desired constraints in terms of the routing metrics and are thus
  considered "good enough" from the application's perspective.

  A mechanism to measure the end-to-end cost of an existing route is
  specified in [I-D.ietf-roll-p2p-measurement].  As discussed in
  Section 4, measuring the end-to-end cost of an existing route may
  help decide whether to initiate the discovery of a better route using
  P2P-RPL and the metric constraints to be used for this purpose.

Working Group Summary:

No discontent. Once again, few comments, request for clarifications that have
all
been addressed by in this revision.

Document Quality:

Yes there are several known implementations of these specification, with interop
testing.

An interoperability was carried out last month with INRIA's implementation
against Sigma Design's?
implementation. The report can be found:
http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf

Experiments with P2P-RPL have also taken place on the Senslab testbed gathering
boards based?
on MSP430 and 802.15.4 at 2.4GHz:
http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf

Personnel:

The Document Shepherd is JP Vasseur (ROLL co-chair) and the responsible Area
Director is Adrian Farrel (AD Routing Area)

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The document is sound, has received a very good level of attention and reviews
including by the Shepherd prior to requesting publication, and is ready for
publication as experimental track.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

No Concern.

The I-D has been discussed in great detail by a number of key members of the
Working group. Number of comments have been made on the mailing list
during two WG Last Calls and have all been addressed in this revision. Note that
several tickets have been opened and have been successfully closed.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

No need for broader review.

(6) Describe any specific concerns or issues that the Document Shepherd has 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.

No particular concern. Some questions were raised has to whether using a
pro-active protocol in a "reactive" way was scalable; thus the choice to advance
the document along the experimental track.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes. I have checked with each co-author.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) 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?

Good consensus.

(10) 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 publicly available.)

No threats. No discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

Checks have been made. No Errors.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as either
normative or informative?

References split has been done.

(14) 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 plan for their completion?

All normative references are RFCs.

(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The IANA action is properly documented. The document has been updated after
discussion with AD.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

The IANA section specifies several new registries - IANA expert reviews should
be similar to those required by the RPL protocol (RFC6650)

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

No other automated checks performed.