[Roll] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt

["Joel M. Halpern" <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-roll-p2p-measurement-07.txt

Reviewer: Joel M. Halpern
Review Date: 9-Januar-2013
IETF LC End Date: 21-January-2013
Intended Status: Experimental

Summary: I have some minor concerns about this document that I think 
should be resolved before publication.

Comments:
     Generally, this is a well written and readable specification 
addressing an understandable problem.

Major Issues:

Minor Issues:
     I had not realized until section 4.3 that NUM (and the structure of 
the message) had to allow for the desired limit on the Address 
Accumulation.  (I had originally inferred a rather painful strategy.) 
Could this be stated earlier in the document please?

     Can the first sentence of the text in the nested bullet on Source 
Routed Address vectors ("When the Measurement Request is traveling along 
a Source Route...") be moved before the description of the bits  (sorry, 
it may need to be slightly reworded to do so.)  This restriction is very 
helpful in understand the behaviors defined by the various flags in the 
message header.  (Also, if it wouldn't bother the ROLL/RPL experts too 
much, a comment about he root not needing to add a source route for a 
local RPLInstance would complete the picture nicely.  I am merely 
inferring this behavior from the fact that accumulate is allowed with 
hop-by-hop and local RPLInstances.)

     It appears that the loop prevention requirement on source routes 
requires every router that handles the packet to examine every entry in 
the source route to make sure that the inspecting router does not appear 
anywhere except a the current index entry.  ("MUST ensure that o address 
appears more than once" in section 5.1, and text in section 5.3.)  That 
would seem to be a significant cost, for no obvious benefit.  Why is it 
required?  (Yes, I have read the last bullet of section 9.  This seems 
to be a very expensive set of extra protections.  Given that the index 
gets increment, the cost of a loop seems pretty small.)

     I section 5.2 and 5.3, how can the processing node determine the 
"Address vector is present in the received message" if the Num field is 0?

Nits:
     Could the first bullet in section 5.1 be re-ordered so that the 
condition ("if it does not know how to reach the End Point") occurs 
before the "MUST discard".  As written, the reader is startled by 
thinking that the first thing the root must do is discard the request.
     Could the same be done to the second and third paragraphs of 5.2?
     And the second and third paragraphs of section 5.3?
     And the second paragraph of section 5.4?  (The third paragraph of 
5.4 has things in the order which I think is clearer for the reader.)
     The last sentence of the next to last paragraph of 5.5 could also 
be reversed, although for some unknown reason I find that one less 
bothersome.

     Section 7, second paragraph could also be usefully reversed.

     I presume that all the "dropped with no further processing" is not 
intended to preclude updating error counters and similar actions.  Is 
there a place that could be said?

Yours,
Joel M. Halpern