Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
RFC 6552

Note: This ballot was opened for revision 20 and is now closed.

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2011-08-08)
No email
send info
"An implementation SHOULD allow to configure a... "

Do you mean "An implementation SHOULD allow the operator to configure a..." ?

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2011-09-05)
No email
send info
I've cleared my DISCUSS.  I hope the Working Group and the authors
will consider these COMMENTs before the document is published.

1. I consider the following comment to be a technical rather than an
editorial suggestion because of the redundancy and potential conflict
between the text in the Introduction of this document and the contents
of draft-ietf-roll-rpl-19.  It would improve the document to edit the
Introduction down to a paragraph that combines the following sentence
from the first paragraph with the content from the last paragraph:

   An Objective Function
   defines how a RPL node selects and optimizes routes within a RPL
   Instance based on the information objects available.

I think Adrian may have suggested some other text that better defines
an Objective Function.

2. (withdrawn)

3. (withdrawn)

4. In section 7.1, why is support of the DODAG Configuration option
only a SHOULD?

   An OF0 implementation SHOULD support the DODAG Configuration option
   as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the
   parameters contained therein.

5. I see that text has been added in section 4.2.1 about validating a
router.  The section still doesn't explain what the phrase "validate a
router" actually means.  Is there text in draft-ietf-roll-rpl that can
be cited here to explain the semantics or other intended meaning of
"validate a router"?

(Wesley Eddy) No Objection

(David Harrington) No Objection

Comment (2011-08-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I reviewed this document, but need to trust others with more background in routing to have reviewed it for its impact on forwarding.

I reviewed the management considerations, and am pleased that they provided an information model to monitor the parameters in use. It would have been nice to have a mandatory-to-implement management protocol and data model to ensure interoperable management.

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2011-08-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I now understand the history of the document between WGLC and now. However, there is scant little evidence of what happened in either the document writeup or the proto writeup. That would be useful in the future.

(Peter Saint-Andre) No Objection

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) No Objection

Comment (2011-08-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
from the nits-checker:

  == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
     does not include the phrase in its RFC 2119 key words list.

  == Unused Reference: 'I-D.ietf-roll-security-framework' is defined on line
     569, but no explicit reference was found in the text

Note that for the 1st one you can keep 'NOT RECOMMENDED' in the text you just need to add it to the 2119 paragraph immediately after RECOMMENDED.