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

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 10 January 2013 01:46 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED801F0CF5; Wed, 9 Jan 2013 17:46:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.248
X-Spam-Level:
X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5xM+UiU3WbS; Wed, 9 Jan 2013 17:46:58 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1231F0C6A; Wed, 9 Jan 2013 17:46:58 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 7F8B2A36F6; Wed, 9 Jan 2013 17:46:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8D7741C0B58; Wed, 9 Jan 2013 17:46:55 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.155.107.75] (unknown [129.192.170.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 62BAA1C07B6; Wed, 9 Jan 2013 17:46:55 -0800 (PST)
Message-ID: <50EE1D8F.6050407@joelhalpern.com>
Date: Wed, 09 Jan 2013 20:46:55 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
References: <F64C10EAA68C8044B33656FA214632C823D40C@MISOUT7MSGUSR9O.ITServices.sbc.com>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C823D40C@MISOUT7MSGUSR9O.ITServices.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org
Subject: [Roll] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2013 01:46:59 -0000

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