Telechat Review of draft-ietf-6man-rpl-routing-header-
review-ietf-6man-rpl-routing-header-genart-telechat-garcia-2012-01-12-00
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 |
review-ietf-6man-rpl-routing-header-genart-telechat-garcia-2012-01-12-00
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