I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at
<
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
Please resolve these comments along with any other comments you may receive.
Document: draft-ietf-6man-rpl-routing-header-04.txt
Reviewer: Miguel Garcia <miguel.a.garcia at ericsson.com>
Review Date: 2011-10-23
IETF LC End Date: 2011-10-31
Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.
Major issues: none
Minor issues:
- Section 2 is titled "Overview". As such, I was expecting to find
descriptive text that makes the reader easier to understand the
technology that will be later described in detail and in a more normative
way. However, this Section contains a number of normative texts already
(MUSTs and MAYs), which defeats the purpose of an Overview Section. I
wonder whether those MUSTs and MAYs words need to be really written there
in that way, or whether the Overview section can be written in
descriptive non-normative way.
My recommendation: Turn all this normative text into informative. Make
sure that the normative text is written elsewhere later in the document.
- Section 2, second paragraph, says:
Third, routers along the way MUST verify that loops do not exist with
in the source route.
I don't know how to digest this sentence. If I am implementing the
protocol, is there something I can do to comply with the "MUST"? Or is
this "MUS"T addressing the operation of the network? I think it is a good
recommendation for network administrators, in which case, it should be
exactly like that, a recommendation, not normative. But please clarify
the intention.
- Section 2, bullet points 1 and 2. Is there a reason why the "should" in
the bullet point 1 is non-normative and the "SHOULD" in the second bullet
point is normative?
/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain