Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Carsten Bormann <> Thu, 17 May 2012 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D6C511E8072 for <>; Wed, 16 May 2012 17:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5-zAxAlKGr6L for <>; Wed, 16 May 2012 17:31:35 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id DB6C021F85FB for <>; Wed, 16 May 2012 17:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q4H0VLRU005340; Thu, 17 May 2012 02:31:21 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D36C620; Thu, 17 May 2012 02:31:20 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: Carsten Bormann <>
In-Reply-To: <>
Date: Thu, 17 May 2012 02:31:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Ulrich Herberg <>
X-Mailer: Apple Mail (2.1278)
Cc: roll WG <>, Michael Richardson <>
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 May 2012 00:31:36 -0000

On May 16, 2012, at 19:09, Ulrich Herberg wrote:

> Many of the observations in the draft are directly concluded from the RPL RFC

I'm a bit reluctant to pitch in here as I definitely don't want to take sides in what appears to be an argument (the sides of which I'm just starting to understand).

For me, the draft reads less as a list of observations, but as a list of hypotheses.
An extremely useful list, as I think most people commenting in this thread have agreed.

Where these hypotheses are generated by drawing conclusions from the specs, I think it is prudent to try to corroborate them based on actual experience.  Previously, people have concluded from the available physics that airplanes cannot fly.  Other people have proven them wrong.  I think there are a number of "heavier than air" arguments in the document, and there may be Bernoullis in this WG shaking their heads.  We need the scientific dispute to nail down these hypotheses.

Where these hypotheses are already corroborated by experiments, we need to know enough about these so it doesn't appear to be a "I tried to build an  airplane and it didn't fly" argument.  Some discussion of minimum standards for documentation could be found, say, in -- I wouldn't want a WG document that also qualifies as one of "the incredibles".

The draft may lay the basis for/become an RFC 4815 style "here is some more information that allows you to do it right" document.  This may, in part, be an applicability statement, or it may contain additional specifications/constraints that are crucial to actually making things work and may later become part of a revised spec.

So what I'm saying here is that more work is needed on this document.  But I'm not saying the onus for this is *only* on its authors*):

If it becomes a custom that members of the WG say "smart people know how to make this work but we won't tell you how", this would demonstrate that RPL is a "trapdoor" spec -- it is useful only to those readers who already know how to interoperate, but it is not useful to create interoperability.  Of course, nobody is obliged to do the work to provide this kind of information, and it's certainly not our job to provide a basic engineering education.  But if too much of the information needed beyond that, is not becoming readily available, RPL is not a viable IETF standards-track specification and MUST be withdrawn.

Grüße, Carsten

*) (One of my pet peeves, after 30 years of standardization. Actually the point that is drawing me into this discussion against my better instinct.)