[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
- [Roll] RtgDir review: draft-ietf-roll-p2p-measure… Joel M. Halpern
- Re: [Roll] RtgDir review: draft-ietf-roll-p2p-mea… Mukul Goyal
- Re: [Roll] [RTG-DIR] RtgDir review: draft-ietf-ro… Joel M. Halpern