Subject: [RTG-DIR] RtgDir Review: draft-ietf-roll-of0

From: Julien Meuric <[email-masked]>
Date: Sun, 03 Jul 2011 02:06:22 +0200

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review. The purpose 
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-roll-of0-14.txt
Reviewer: Julien Meuric
Review Date: 2 July 2011
IETF LC End Date: 4 July 2011
Intended Status: Standards Track

*Summary:*
This document is basically ready for publication, but has nits that 
should be considered prior to publication.

*Comments:*
This document is clearly well written and clearly focused, though 
relying on many concepts defined within RPL. This is the first ROLL 
document I have reviewed, so it may mean that my review is not 
sufficiently in-depth.
I noted that many terms are capitalized: it seems unusual at the 
beginning but appears to be helpful so as to identify RPL-related concepts.

*Major Issues:*
No major issues found.

*Minor Issues:*
Just a few minor issues, which I could almost have put among the nits.
- In section 6.2, stretch_of_rank is defined as "the maximum 
augmentation" while, as far as I understand the formula at the end of 
section 4.1, it is rather "the minimum augmentation".
- Section 4.1 says "Stretching the step_of_rank is NOT RECOMMENDED" 
while "an implementation MAY stretch the step_of_rank": using both 
keywords does not seem consistent. Since stretch_of_rank is part of the 
document, it looks like "MAY" is correct. The capital letters of "NOT 
RECOMMENDED" should be removed, or the phrase may be replaced (e.g. 
"ought to be avoided").
- Section 4.2.1, 3rd bullet: what about multiple interfaces without 
policy? Section 4.2.2, 1st bullet: is there a reason why policy is no 
longer mentioned there? If the order of the rules may vary, why not 
writing, in the document, the list in the same order for the Preferred 
Parent and the Backup Feasible Successor? (1 -> 4; 2 -> 6; 3 -> 1...) 
Why different wording between sections?

*Nits:* (some may be deferred to the RFC Editor)
----------
Title:
- Should not RPL be expanded?
- Should not "0" be spelled as "Zero"?
----------
Introduction:
- LLN is expanded in the 1st sentence but not at the very 1st 
occurrence: how strict is the expansion rule?
- "Objective Function" is used 5 times and then"OF", without explicit 
association: it may just be added after the 1st occurrence;
- "DIO" is not expanded;
- s/selected)./selected./
- I could not parse "This is why
    it is not specific as to how the link properties are transformed into
    a rank_increase and leaves that responsibility to the implementation;"
  (s/is not specific as to/does not specify/?)
----------
Generally,  the document would benefit from more consistency when 
spelling the name: "Objective Function Zero" (once), "Objective Function 
0" and "OF0" are used without visible rule. I would suggest:
- full letters in the document title,
- "Objective Function 0" (or as above) at the beginning and in section 
titles,
- "OF0" in the remaining text.
----------
Section 3:
"Low Power and Lossy Network" is used while "LLN" has already been 
mentioned several times.
----------
Section 4.1:
- There 2 references about ETX: I would suggest to keep only one, thus 
use the other ROLL document only.
- "MAC" is not expanded (especially as it is not "Media Access Control" 
here).
- It would be more convenient for the reader if rank_increase, 
step_of_rank, rank_factor and stretch_of_rank were described as positive 
integers (or strictly positive integers when applicable).
- In the formula, why using aliases for step_of_rank, rank_factor and 
stretch_of_rank? rank_increase remains the same and is much easier to 
read. (Issue with the length of the line?)
----------
Section 4.2.1
s/Selection Of The/Selection of the/ (all the more as "OF" is common in 
the document)
----------
Section 4.2.2
s/Selection Of The/Selection of the/
----------
Section 5
- s/provide an interface/provides an interface/
- s/Updates: the OF0/Updates: The OF0/
----------
Section 6.2
s/the maximum/The minimum/
----------
Section 7.2
- s/when tthat/when that/
- s/Rank, he current/Rank, the current/
- s/be indicated/be indicated./
----------
Section 9
s/packet resulting/packet, resulting/
----------

Regards,

Julien

---

From: Julien Meuric <[email-masked]>
Date: Fri, 08 Jul 2011 18:53:31 +0200

Hi Pascal.

You are welcome. I have checked the release 15 you have pointed me to:
- the new definition of Sr addresses my comment;
- I am completely fine with lowercasing "may" rather than "NOT 
RECOMMENDED": I was not aware of the expected level of requirement, but 
it now avoids any inconsistency in RFC 2119, which was my point;
- I do not see any blocking point in section 4.2 (though improvable, 
obviously ;-) ).

Have a good week-end,

Julien

Le 05/07/2011 15:03, Pascal Thubert (pthubert) a écrit :
> Thanks a lot Julien for this very serious review.
>
> Please see in line
>> *Summary:*
> [Pascal]  If the parent set is large enough without stretching, there is
> no point doing it.
> 4.1 says:
> "
>     Still, an
>     implementation MAY stretch the step_of_rank with at most a
>     configurable stretch_of_rank (Section 6.2) of any value between 0 (no
>     stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3).
> "
> I do mean it is a maximum and that is consistent with 61.
>
> I think the confusion comes from the  definition of Sr in the formula
> "
>     The step_of_rank Sp that is computed for that link is multiplied by
>     the rank_factor Rf and then possibly stretched by a stretch_of_rank
>     Sr.
> "
>
> What about saying:
> "
>     The step_of_rank Sp that is computed for that link is multiplied by
>     the rank_factor Rf and then stretched by a term Sr that is between 0
>    and stretch_of_rank.
> "
>
> [Pascal] Adrian suggested "NOT RECOMMENDED"  in upper case and I agree
> with his point.
> I'm unclear why this is in opposition with the "MAY". If it is I'r
> rather lowercase the 'MAY' than the "NOT RECOMMENDED".
>
> [Pascal] It is there implicitly. The policy text explained what we mean
> by higher order. The same order plays in both sections.
>
> [Pascal] I agree with you, 1 of 4.2.2 should really move after the
> current 6. You'll note that the selection of the preferred parent cause
> the selection of the DODAG version, and once this is done, some options
> for the alternate are not available anymore, and that the backup does
> not have to be a parent (it can belong to a subsequent version).
>
>
> [Pascal] I'll fix those I can in the post. Some to be discusses with RC
> editor unless someone knowledgeable enlightens me first.
>
> Cheers,
>
> Pascal
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Jul 2011 15:03:06 +0200

Please see in line

What about saying:
"

Cheers,

Pascal