Sign in
Version 5.13.0, 2015-03-25
Report a bug

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

No Objection
(was Discuss)
(was Discuss)
(was Discuss)

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

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

[David Harrington]

Comment (2011-08-09 for -)

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.

[Pete Resnick]

Comment (2011-08-11 for -)

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.

[Ralph Droms]

Comment (2011-09-05 for -20)

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"?

[Stewart Bryant]

Comment (2011-08-08 for -20)

"An implementation SHOULD allow to configure a... "

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


Comment (2011-08-09 for -)

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.