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

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 14 Oct 2009 15:53:02 +0200

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.

# 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.

# 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.

# 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.

# 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

---

From: Tim Winter <[email-masked]>
Date: Wed, 14 Oct 2009 20:34:31 -0400

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:
> 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. 
> 
> - enabling the formation of paths towards this destination that optimize
> a given metric,
> 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.
> 
> 
> 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: 
Thanks for the suggestion.

> destination. This may be used to simplify the document a bit.
This will be reflected in -04.

> These can proabably be trimmed down since we should just talking about
> one DAG in the document.
> 
> # Section 3.2.2.
> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 15 Oct 2009 10:44:38 +0200

Hi Emmanuel,
 
I very much agree with your comments. Especially with the two points
below that could reduce a lot the complexity.

# Section 2
Agree, for me siblings are note part of the core.
 
 # 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. 
Agree. I think what is needed are just procedures to join a DAG and
leave a DAG.  

Best,
Mathilde

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 15 Oct 2009 10:47:31 +0200

My 2 cents...

> Agree, for me siblings are note part of the core.

+1

>
>  # 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.

+1

Thomas