Note: This ballot was opened for revision 15 and is now closed.
Summary: Has enough positions to pass.
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.
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.
"An implementation SHOULD allow to configure a... "
Do you mean "An implementation SHOULD allow the operator to configure a..." ?
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
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.
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"?