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

[Ulrich Herberg <[e-mail]>]

Mukul,

On Wed, May 16, 2012 at 7:53 AM, Mukul Goyal <[e-mail]> wrote:

> I agree with Cedric. Issues that Cedric has raised are very basic and
> should have already been taken care of in the document. Seriously, do the
> authors think that this document would pass the muster for publication in
> any decent academic journal?



I don't know since when that is any criteria for IETF work. Was it a
criteria for the standardization of RPL itself?



> Right now, the draft reads more like propaganda than information: written
> to bad mouth a protocol on the basis of biased/frivolous arguments.


I am sorry that you see the draft that way. We have tried to be as
objective as possible. Can you point out any concrete paragraph or section
that you see as "propaganda"? And honestly, I would have hoped that we can
have an objective, argumentative discussion on the mailing list, and not a
dismissal of our arguments without any constructive discussion.



> Why would the authors completely ignore P2P-RPL even though it resolves
> many issues they have pointed out.


1) Because P2P-RPL is not even an RFC yet, whereas RPL is, and is already
deployed.
2) There is no dependency from RPL to P2P-RPPL, i.e., it should work
stand-alone.
3) P2P-RPL is experimental, RPL is std. track.
4) I thought that ROLL is chartered to provide routing solutions for
extremely constrained devices (which was, I assume, one of the reasons to
not consider MANET work). One of our arguments in the draft is that RPL is
very complex (the specification alone plus necessary companion documents
has several hundred pages). Adding P2P-RPL as necessity to mitigate some of
the issues would increase the code size even more.



> There are numerous similar sins of omission spread throughout the
> document.


Where?


> As a result, most conclusions the document reaches are open to doubt if
> not outright incorrect.


Is that proof by authority or a real argument? Please be more constructive.



> Sure, RPL is not a perfect protocol - no protocol is. But this document is
> not an unbiased scientific analysis of the protocol.


How do you come to that conclusion? We provide concrete, objective
arguments. I do not see that in your email.



> As Pascal said, this document could have served a valuable constructive
> purpose. But, perhaps this was not the intention of the authors. This
> document should be recognized for what it is: a political document written
> to further a particular destructive agenda.
>

I really don't know what to say to that non-constructive argument.

Best regards
Ulrich



>
> Thanks
> Mukul
>
> ----- Original Message -----
> From: "C Chauvenet" <[e-mail]>
> To: "JP Vasseur" <[e-mail]>
> Cc: "roll WG" <[e-mail]>, "Michael Richardson" <[e-mail]>
> Sent: Wednesday, May 16, 2012 9:13:56 AM
> Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
>
> Hi,
>
> I definitely agree that implementation feedback is always good to know, so
> your experiences are welcomed.
>
> I also think that problems investigations need a complete and exact view,
> so I would encourage you to put much more details about the scenario and
> the environment where you experimentations took place.
> For instance, I would enjoy a "RPL Implementation Description" section in
> you draft listing the hardware your used, your RPL parameters, the RPL
> drafts and mechanisms implemented, your OS etc...
> If I read a paper with orthogonal observations with the same level of
> details as in your draft, then how could I forge my opinion ?
>
> Looking at this draft, it seems that it gathers lots of previous
> discussions that occurred during the past year on various mailing lists,
> and IETF meetings.
>
> Does your experimentations takes care about these recommendations ?
> If not, does your draft mention the propositions that have been made to
> address the problems you point out in your draft ?
> I think it could be worth to leverage on these previous discussions.
>
> Your draft is a list of Description and Observations.
> Maybe you could add a "Resolution Proposal" section for each problem,
> gathering previous discussion and your own proposals ?
> Identifying what is wrong in your implementation is a good first step, but
> the hardest part is to propose some corrections.
>
> Best Regards,
>
> Cédric Chauvenet.
>
> Le 16 mai 2012 à 15:04, JP Vasseur a écrit :
>
> > Dear Thomas,
> >
> > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote:
> >
> >> Dear JP and Michael,
> >>
> >> Thank you for your mail.
> >>
> >> On May 16, 2012, at 09:18 , JP Vasseur wrote:
> >>
> >>> Dear Thomas,
> >>>
> >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote:
> >>>
> >>>> Dear JP, Michael, all
> >>>>
> >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented
> and discussed at the Paris meeting.
> >>>>
> >>>> The authors consider the document complete and "done", and are
> looking to take it forward in the IETF
> >>>> process for publication as "Informational RFC" in the very near
> future.
> >>>>
> >>>> We would therefore like to ask the WG chairs, if the ROLL WG is
> willing to accept and progress this
> >>>> document towards publication?
> >>>
> >>> Thanks for your suggestion. So far we haven't see a lot of
> discussion/interest from the WG but your request is
> >>> perfectly fair.
> >>
> >> Thank you - I aim to be fair.
> >>
> >>> So far there are no details on the scenarios and testing environments
> that led to the issues that
> >>> you reported, thus I would suggest you to first include them so that
> people interested could be able to reproduce
> >>> it. Once the drat is updated, we'll be happy to pool the WG.
> >>>
> >>> Does that make sense ?
> >>
> >> Not really. Let me explain my disagreement.
> >>
> >> We tried RPL (and, I note, several different independent
> implementations of RPL) in a number of different scenarios and deployments,
> and observed the behaviors exhibited - noting that what we observed across
> the different implementations, scenarios and deployments was fairly
> universal.
> >>
> >> We then went back to the specification, to understand these behaviors
> in detail, and understand their universality as independent from a specific
> scenario or deployment or implementation - but rather, as artifacts of the
> RPL protocol design.
> >>
> >> We therefore believe that _any_ deployment, scenario or testing
> environment of RPL needs to pay attention to the issues presented, and find
> a way of addressing them. The way of addressing these issues in a given
> deployment or scenario would be appropriate for an "applicability
> statement" for that deployment or scenario.
> >
> > JP> Thanks for the clarification; that being said, for the WG to make
> sure that nothing is "scenario" dependent and the outcome could indeed
> apply to all scenarios,
> > it might be worth being more explicit. For example, you pointed out to
> the MTU issue, to which I mentioned that 15.4g would bring a solution, so
> you may want to
> > explain that you did not use 15.4g and there are a number of such
> examples ….
> >
> >>
> >> (For example, a deployment using only L2s which provides guaranteed
> bi-directional links  for L3 would address this by in the applicability
> statement stating "As all L2-links are guaranteed bi-directional, this
> addresses the issues raised in section 9 in
> draft-clausen-lln-rpl-experiences".)
> >>
> >> Thus, we believe that it would actually be misleading (not to mention,
> unnecessarily verbose) to put the "details on the scenarios and testing
> environments" into this I-D.
> >>
> >> Doing so would mislead the reader to believe that the issues presented
> only manifest themselves in those precise scenarios - which definitely
> isn't the case.
> >
> > JP> see the previous comment and tell us what you think; we could
> provide other examples.
> >
> > Note that we do not oppose to asking to the WG; we just request you
> first to add additional information to proceed forward.
> >
> > thanks.
> >
> > JP and Michael.
> >
> > JP.
> >
> >>
> >> Best,
> >>
> >> Thomas
> >>
> >>> Thanks.
> >>>
> >>> JP and Michael.
> >>>
> >>>>
> >>>> Best,
> >>>>
> >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel
> >>>
> >>
> >
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> >
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>