Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
Note: This ballot was opened for revision 15 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 for -20)
Nit "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 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"?
( Wesley Eddy ) No Objection
( David Harrington ) No Objection
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.
( Russ Housley ) No Objection
( Pete Resnick ) No Objection
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.
( Peter Saint-Andre ) No Objection
( Robert Sparks ) (was Discuss) No Objection
( spt ) No Objection
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.