Subject: [Roll] Few comments before sending the publication request to IESG

From: JP Vasseur <[email-masked]>
Date: Sun, 8 May 2011 08:55:39 -0700

Hi,

Just minor comments before sending the publications request:

1) If the node does not have metrics to compute the

Gnawali & Levis         Expires November 4, 2011                [Page 4]
Internet-Draft    draft-ietf-roll-minrank-hysteresis-of         May 2011

   path cost through any of the candidate neighbors, it MUST join one of
   the candidate neighbors as a leaf node.
JP> You many replace that "it must join one of the candidate neighbors as a 
leaf node" according to I-D.ietf-roll-rpl.

2) I would suggest to add a manageability section pointing out that the following
parameters should be configurable:

- PARENT_SWITCH_THRESHOLD
- If the configuration disallows a node to be a Floating root and
       no neighbors are discovered, the node does not have a preferred
       parent, and MUST set cur_min_path_cost to MAX_PATH_COST.
=> The configuration SHOULD allow for configuring whether or not a node could be
a floating root.

- PARENT_SET_SIZE

3) s/covert the the /convert the

4) In the absence of metric container, MRHOF uses ETX as its metric.  It
   locally computes the ETX of links to its neighbors and adds this
   value to their advertised Rank to compute the associated Rank of
   routes.  Once parent selection and rank computation is performed
   using the ETX metric, the node advertises a Rank equal to the ETX
   cost and SHOULD NOT include a metric container in its DIO messages.
JP> You are suggesting here to not use the metric container if the link metric in use is
the ETX and embed it in the rank. Don't you think that this may lead to interoperability 
issues ? How do I need when receiving a DIO if the value of the rank reflects the ETX or
some other scalar ? By looking at the OCP, deduct that there is no container ? Wouldn't it
be "cleaner" to simply use of the metric container and use the ETX metric defined in 
draft-ietf-roll-metrics ?

5) In section 5, these values are RECOMMENDED (please indicate it), then add a manageability
section allowing to configure these values.

6) The following IDs should be normative:

[I-D.ietf-roll-routing-metrics]
              Vasseur, J. and D. Networks, "Routing Metrics used for
              Path Calculation in Low Power and Lossy Networks",
              draft-ietf-roll-routing-metrics-01 (work in progress),
              October 2009.

   [I-D.ietf-roll-rpl]

Gnawali & Levis         Expires November 4, 2011                [Page 9]
Internet-Draft    draft-ietf-roll-minrank-hysteresis-of         May 2011

              Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
              Protocol for Low power and Lossy Networks",
              draft-ietf-roll-rpl-05 (work in progress), December 2009.

7) Outdated references:

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-19) exists of
     draft-ietf-roll-routing-metrics-01

  == Outdated reference: A later version (-19) exists of
     draft-ietf-roll-rpl-05

  == Outdated reference: A later version (-05) exists of
     draft-ietf-roll-terminology-01
Thanks.

JP.