[Roll] AD review of draft-ietf-roll-p2p-rpl-14.txt

["Adrian Farrel" <[e-mail]>]

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?