Re: [Roll] Last Call: <draft-ietf-roll-rpl-11.txt> (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard
"Colin O'Flynn" <coflynn@newae.com> Fri, 20 August 2010 08:59 UTC
Return-Path: <coflynn@newae.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461263A682F for <ietf@core3.amsl.com>; Fri, 20 Aug 2010 01:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level:
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IEJPk0w9tJU for <ietf@core3.amsl.com>; Fri, 20 Aug 2010 01:59:31 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 21C243A6824 for <Ietf@ietf.org>; Fri, 20 Aug 2010 01:59:31 -0700 (PDT)
Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from <coflynn@newae.com>) id 1OmNSG-00041w-Tt for Ietf@ietf.org; Fri, 20 Aug 2010 05:00:05 -0400
From: Colin O'Flynn <coflynn@newae.com>
To: Ietf@ietf.org
Subject: Re: [Roll] Last Call: <draft-ietf-roll-rpl-11.txt> (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard
Date: Fri, 20 Aug 2010 09:59:59 +0100
Message-ID: <00c201cb4046$13af6020$3b0e2060$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActARhCcgELfLTJURlSA4pvJwTBbmQ==
Content-Language: en-ca
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - newae.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2010 08:59:32 -0000
Hello, I'd like to comment on some mostly editorial problems I see with RPL-11. Note the following don't affect the protocol itself, messages, or mechanisms proposed. These comments come from someone who has worked to implement part of the RPL draft and they DO result in problems implementing the specification. #1) Trickle to RPL Interation The trickle timer is an integral part of RPL, but defined in another draft (draft-ietf-roll-trickle-04.txt). In that draft section 5 details that "A protocol specification that uses Trickle MUST specify": * Default values for Imin, Imax, and k * What constitutes a "consistent" transmission. * What constitutes a "inconsistent" transmission * What "events", if any, besides inconsistent transmissions that reset the Trickle timer. However in roll-rpl-11.txt they are not clearly worded as such. Section 8.3.1 details Imin, Imax, and k well. Section 8.3 details the other three, though does not use the keyword "consistent transmission" or "inconsistent transmission". RPL-11 also includes a blanket statement which allows implementers to consider any event a chance to reset the Trickle timer. Such a blanket statement may give too much flexibility, since it would allow a node to constantly reset the Trickle timer and yet adhere to the specification. #2) Problems in 'Protocol Overview' The 'protocol overview' section is needlessly convoluted and complex. As a few examples: -Section 3.3.7 is called "Datapath Validation and Loop Detection", which has the same information but written a different way from section 3.8, "Loop Avoidance". It's not clear why there is two of essentially the same sections. -Section 3.8.1 devotes two pages to the description of what greediness is, how it happens etc. It then mentions that such a condition as just described could never happen in RPL due to the design. A simple sentence saying that RPL disallows greediness, and giving a reference for readers to consult if they want to learn about greediness would be sufficient. -Objective Function (OF) is defined on page 9, page 14 in a section titled 'Objective Function', then defined again on page 20 (paragraphs 2 & 3). #3) Complexity of English This is not a specific concern, but throughout RPL-11 the language used is very complex and not always consistent. As a few examples: -'Option Length' is defined for each option, 10 in total I count. Almost every definition uses some different wording. (Search for "Option Length:" to see what I mean). -"Indeed, whereas the OF dictates rules such as DODAG parents selection, load balancing and so on, the set of metrics and/or constraints used, and thus determine the preferred path, are based on the information carried within the DAG container option in DIO messages." --Sentence from page 20, paragraph 3. I'm not even sure what that sentence should be saying. -Though the preceding is a particularly bad example, a more common sentence might be something like this: " Unfortunately, such an approach is not desirable in constrained environments such as LLN and would lead to excessive control traffic in light of the data traffic with a negative impact on both link loads and nodes resources." --Page 100, paragraph 2. Which does make perfect sense, but could easily be shortened or even removed. By page 100 you probably get the idea that you don't want to be sending excessive data. Problems #1/#2 are fairly specific and could be fixed with minor editing. Problem #3 would essentially require a re-write of the entire draft to use clearer English throughout. Again this isn't affecting the protocol/messages, just the language used! Regards, -Colin O'Flynn
- Re: [Roll] Last Call: <draft-ietf-roll-rpl-11.txt… Alexandru Petrescu
- Re: [Roll] Last Call: <draft-ietf-roll-rpl-11.txt… JP Vasseur
- Re: [Roll] Last Call: <draft-ietf-roll-rpl-11.txt… Colin O'Flynn
- Re: Last Call: <draft-ietf-roll-rpl-11.txt> (RPL:… Pekka Savola
- Re: [Roll] Last Call: <draft-ietf-roll-rpl-11.txt… Michael Richardson
- Re: Last Call: <draft-ietf-roll-rpl-11.txt> (RPL:… Alexandru Petrescu
- RE: Last Call: <draft-ietf-roll-rpl-11.txt> (RPL:… Dearlove, Christopher (UK)
- Re: [Roll] Last Call: <draft-ietf-roll-rpl-11.txt… Cullen Jennings