Subject: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Sep 2011 15:59:03 +0100

Hi,

Here is my AD review of your draft. I was hoping to get away with a few
typos we could punt to a later stage, but I think there are a couple of
issues we need to iron out with a quick new revision.

I have put the I-D into "revised I-D needed" state and will issue the IETF Last
Call when I see a new revision.

Thanks,
Adrian

---

In progressing the OG0 draft we learnt that there was no clear
understanding of what an objective function is. I think your draft does
a good job at explaining, but in an attempt to learn from the past, can
you please have a look at the text that got added to the OF0 document to
see whether anything can be added here.

---

Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not 
MROFH?

---

During the review process for OF0 we ended up adding the following 
paragraph. Would you consider adding something similar to make this
point crystal clear?

   The RPL specification [I-D.ietf-roll-rpl] requires the use of a
   common OF by all nodes in a network.  The possible use of multiple
   OFs with a single network is for further study.

---

Section 2...

   This document introduces two terms:

There are three terms!

---

Section 5.1

Can you add a statement on default values?

Can you also have a look at Section 7 of the OF0 draft. This gives a
more substantive approach to describing manageability.

---

7.  IANA Considerations

You need to point the IANA at the specific registry. This would be the
"Objective Code Point (OCP)" sub-registry of the "Routing Protocol for
Low Power and Lossy Networks (RPL)" registry.

   This specification requires an allocated OCP.  A value of 1 is
   requested.

s/requested/suggested/

---

8.  Security Considerations

   Security considerations to be developed in accordance to the output
   of the WG.

I don't think we will get this past the Security directorate :-)

How about...

   This specification makes simple extensions to RPL and so is
   vulnerable to and benefits from the security issues and mechanisms
   described in [I-D.ietf-roll-rpl] and
   [I-D.ietf-roll-security-framework].  This document does not introduce
   new flows or new messages, thus requires no specific mitigation for
   new threats.

   MRHOF depends on information exchanged in a number RPL protocol
   elements.  If those elements were compromised, then an implementation
   of MRHOF might generate the wrong path for a packet, resulting in it
   being misrouted.  Therefore, deployments are RECOMMENDED to use RPL
   security mechanisms if there is a risk that routing information might
   be modified or spoofed.