Re: [Roll] AD review of draft-ietf-roll-applicability-home-building

[peter van der Stok <[e-mail]>]

Dear Adrian,

thanks for your encouragement.
A new version will be prepared in the coming 1-2 weeks, addressing all 
issues mentioned below.

Greetings,

Peter

Adrian Farrel schreef op 2015-03-04 22:38:
> Thanks for this really nice document. I found it an easy read.
> 
> I have done my usual AD review to catch issues before IETF last call 
> and
> IESG evaluation.
> 
> I only have a handful of small issues, but I think it would be worth
> resolving them with a new revision before we go to last call. I have
> marked the datatracker to show "Revised I-D needed" and I'll wait to
> see you post a new version.
> 
> Thanks for the work,
> Adrian
> 
> ===
> 
> The chairs and I have discussed moving this document onto the Standards
> Track in accordance with the description of an Applicability Statement 
> in
> Section 32 of RFC 2026. The only thing you need to do is update the
> "Intended status" to say "Proposed Standard".
> 
> The Shepherd will also need to update the write-up and flip the field 
> in
> the datatracker.
> 
> ---
> 
> In 1.1. you have
> 
>    The ROLL working group has specified a set of routing protocols for
>    Lossy and Low- resource Networks (LLN) [RFC6550]
> 
> Yet 6550 defines
> 
>    Low-Power and Lossy Networks (LLNs)
> 
> ---
> 
> Section 1.2 seems to only be necessary for a use of "MUST" in section
> 7. I am comfortable with you having used normal case ("must", "should",
> "recommended") in the text. Could Section 7 also drop this to "must"
> and then you could remove Section 1.2?
> 
> ---
> 
> 2.2.7 mentions AODV without expanding the abbreviation and without a
> reference.
> 
> ---
> 
> A few abbreviations need to be expanded on first use:
> DIO
> DAG
> MPL
> DAO
> RA
> ULA
> DODAG
> ETX
> 
> ---
> 
> 4.1.7 has...
> 
>    Repetition of the message can be inhibited by a small
>    value of k.
> 
> I think this is lacking a little context. What is k?
> 
> ---
> 
> Please mark Section 11 "To be deleted by the RFC Editor before
> publication."