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

Omprakash Gnawali <> Thu, 17 May 2012 02:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F358B11E80A0 for <>; Wed, 16 May 2012 19:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.31
X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EQiKYy6jEWht for <>; Wed, 16 May 2012 19:11:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF5C611E8073 for <>; Wed, 16 May 2012 19:11:34 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id D001323CA89 for <>; Wed, 16 May 2012 21:11:34 -0500 (CDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pm48DIsEc6a3 for <>; Wed, 16 May 2012 21:11:31 -0500 (CDT)
Received: from ( []) by (Postfix) with ESMTP id 197A423CA86 for <>; Wed, 16 May 2012 21:11:31 -0500 (CDT)
Received: from ( []) by (Postfix) with ESMTP id 787752A280C3 for <>; Wed, 16 May 2012 21:43:20 -0500 (CDT)
Received: by yenq13 with SMTP id q13so1600390yen.31 for <>; Wed, 16 May 2012 19:11:30 -0700 (PDT)
Received: by with SMTP id i43mr5961285yhe.53.1337220690059; Wed, 16 May 2012 19:11:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 16 May 2012 19:11:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Omprakash Gnawali <>
Date: Wed, 16 May 2012 21:11:05 -0500
Message-ID: <>
To: Carsten Bormann <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 02:11:36 -0000

Here is a link to a constructive document on related topics we started
a while ago:

Recommendations for Efficient Implementation of RPL

(just wanted to refresh WG's memory)

As always, happy to edit the document with experiences from the trenches.

- om_p

On Wed, May 16, 2012 at 7:31 PM, Carsten Bormann <> wrote:
> 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.)
> _______________________________________________
> Roll mailing list