Re: [Roll] feedback on draft-ietf-roll-rpl-03

[Tim Winter <wintert at acm.org>]

Hi Emmanuel,

Thanks for preparing this feedback.

We will work to incorporate your comments into the upcoming revision -04.  A
bit more inline below:

Regards,

-Tim

Emmanuel Baccelli wrote:
> Hi all,
> 
> Here are some comments I have about the new version of the RPL draft
> (draft-ietf-roll-rpl-03).
> 
> General comment: the document is still 100 pages long, similar to -02,
> and does not take into account the consensus reached at the interim
> meeting in Geneva, regarding the needed simplification of the draft. 
> 
> I think that at this point, just like we discussed at the interim, we
> should revamp the structure of the doc. Aiming to steer in that
> direction, here are some initial, more detailed, comments on the
> document up to section 4:
> 
> # Section 1.1: 
> the "core set of functionalities" are not explicitely listed. I think
> they must be in order to effectively revamp the structure. Just saying:
> "being able to operate in the most severe environment" is too vague.
> What exactly do we want to be able to do in such environment?
> Communication between sensors? Communication from sensor to sink?
> Communication from sink to sensor? With what QoS? This needs to be very
> explicit at this point. It will help the whole document a lot. 
> 
> I think at this point we could bluntly say something like: 
> "
> In this specification, we focus on:
> - enabling communication from sensors to a well-known destination,
> - enabling the formation of paths towards this destination that optimize
> a given metric,
> - the choice of which metric to use is outside of the scope of this
> document.
> "
> 
> # Section 2
> I am wondering if some of the terms are unecessary at this point. In
> particular, DAG siblings. Since siblings introduce quite a tricky
> complexity/benefit trade-off, I would be in  favor of getting rid of
> these in the core RPL document. This could be a welcomed simplification.
> 
> 
> # Sections 3.1.1. up to 3.1.3. 
> I think these sections should be collapsed in a new Applicability
> section. By the way, I still have a hard time understanding what is
> meant by "constraint-based" routing. Are we sure this document is where
> we want to talk about this in the core RPL document anyways?
> 
> # Section 3.2: 
> The first paragraphs should be collapsed in the above mentionned
> Applicability section.
Thanks for the suggestion.

> 
> # Section 3.2.1: 
> "RPL constructs one or more DAGs". The consensus is that the core RPL
> document should specify how to build a single DAG to reach a single
> destination. This may be used to simplify the document a bit.
This will be reflected in -04.

> 
> # Sections 3.2.1.2 and 3.2.1.4 : 
> These can proabably be trimmed down since we should just talking about
> one DAG in the document.
> 
> # Section 3.2.2.
> Ideally, I still think such communication, from sink to sensor, is a
> different matter that should be addressed in a companion document...
> This would make the core RPL document focused, clearer and shorter.
Im not so sure this can be removed from the core document- the sink to
sensor (outward) flow seems important to many applications, and provides the
basis for the base P2P scheme supported by RPL as well.  It is true that not
all applications/deployments may use the functionality, but in support of
interoperation all implementations should understand it.

> 
> # Section 3.3.
> This section can be made much shorter, especially if we do not consider
> siblings.
> 
> # Section 3.5.
> This section is either saying too much or saying not enough. So either
> we expand on the subject of "reactive" behavior, or we just do not
> mention it at this point.
Hmm.. I think you are right - this is getting a bit too detailed for section 3.

> 
> # Section 4.
> Part of this section should be collapsed in the new Applicability
> section. The rest may be out of scope (probably more part of the metrics
> document?)
> 
> 
> Regards,
> Emmanuel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll