Skip to main content

Telechat Review of draft-ietf-6man-rpl-routing-header-

Request Review of draft-ietf-6man-rpl-routing-header
Requested revision No specific revision (document currently at 07)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2011-11-29
Requested 2011-11-29
Authors David Culler , Jonathan Hui , JP Vasseur , Vishwas Manral
I-D last updated 2012-01-12
Completed reviews Genart Telechat review of -?? by Miguel Angel García
Genart Telechat review of -?? by Miguel Angel García
Secdir Last Call review of -?? by Chris M. Lonvick
Assignment Reviewer Miguel Angel García
State Completed
Request Telechat review on draft-ietf-6man-rpl-routing-header by General Area Review Team (Gen-ART) Assigned
Completed 2012-01-12
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

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>
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 A. Garcia
Ericsson Spain