Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-rpl-14.txt>

[Mukul Goyal <[e-mail]>]

Hi Adrian

I have updated p2p-rpl draft based on your comments. The updated draft can be found at:

https://pantherfile.uwm.edu/mukul/public/draft-ietf-roll-p2p-rpl-15.txt

Please let me know if the updated draft meets your concerns or if further modifications are required. Once, you have no concerns left, I will post the new version of the document.

Please see my response to your individual comments below.

Thanks
Mukul

---

[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.

[Mukul]

See the additional line towards the end of Section 9.2 (search for mods_1_)

[Adrian]

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.

[Mukul]
See the new paragraph towards the end of Section 1 (search for mods_2_).

---
[Adrian]
Some abbreviations will need to be spelled out:
DODAG
RPL

[Mukul]

Done. Search for mods_3_ and mods_4_
---

[Adrian]
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.

[Mukul]

Done. Search for mods_5_ and mods_6_.

---

[Adrian]
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?

[Mukul]
Done. Search for mods_7_.

---
[Adrian]
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?

[Mukul]
Done. Search for mods_8.

---

[Adrian]
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.

[Mukul]
Done. Search for mods_9.

[Adrian]
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.

[Mukul]
Actually, we insist that version number be set to zero else DIO has to be discarded. RPL uses (RPLInstanceID, DODAGID, VersionNumber) tuple to uniquely identify a DODAG and we dont want to change that in P2P-RPL.

[Adrian]
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.

[Mukul]
Right, the document was not very clear regarding when should a received DIO be dropped. I have added text at a number of places explicitly requiring a received DIO/DRO message to be dropped if given conditions are not met. Please search for mods_10_ to see this text.
 
---
[Adrian]
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"

[Mukul]
Yes. Done. Search for mods_11.
---
[Adrian]
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/

[Mukul]
Done. Search for mods_12_.
---
[Adrian]
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?

[Mukul]

We were using a new registry because this field was 4 bits earlier. Now that it is 8 bits now, we can use 5237 registry. The change has been made. Please search for mods_13_ to see the new text.

---

[Adrian]
Section 8: Options

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

[Mukul]
There are no ordering rules. RPL does not specify any ordering rules either.
---
[Adrian]
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?

[Mukul]
Since the Data Option is inside a DIO/DRO message, it has the same level of protection as the message it is inside. A deployment may use link layer security or RPL's security mechanisms to meet its needs regarding security. I have added text in the Security Section (Section 13) as well as in the section defining Data Option (Section 7.2) to make this clear. I have also added text to clarify that P2P-RPL does not guarantee successful delivery of the data contained in a Data Option. Please search for mods_14 to see this text.

In addition, I have made one more small modification (search for mods_15) to the document clarifying that a DRO MUST contain one and only one P2P-RDO.

Thanks
Mukul