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

[Omprakash Gnawali <[e-mail]>]

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

Recommendations for Efficient Implementation of RPL
http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03

(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 <[e-mail]> 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 http://dx.doi.org/10.1145/1096166.1096174 -- 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll