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

[Emmanuel Baccelli <Emmanuel.Baccelli at inria.fr>]

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