Re: [Roll] AD review of draft-ietf-roll-terminology-11.txt

Many Thanks Adrian for the thorough review. This may be annoying but I took all of your suggestions into account ;-)
New version has been posted.
Thanks.

JP. 

On Mar 3, 2013, at 3:03 PM, Adrian Farrel wrote:

> Hi,
> 
> I have done my usual AD review of your document prior to advancing it
> towards publication. The purpose of my review is to catch issues or nits
> that would be found during IETF last call or IESG review and which might
> delay the processing or hide other issues. The intent is to remove the
> issues efficiently at this stage.
> 
> As usual, all of my points are open for discussion.
> 
> I have found a number of relatively minor nits and small questions. 
> Given the volume I think it would be worth producing a new revision. 
> 
> When I see the new version I will start the IETF last call process. During
> IETF last call, I will be bringing this I-D explicitly to the attention of 
> several key working groups in other IETF areas so that they can
> consider alignment of terminology.
> 
> Thanks,
> Adrian
> 
> ---
> 
> s/A LLN/An LLN/ throughout
> 
> ---
> 
> Remove the 2119 boilerplate and the reference to [RFC2119]
> 
> ---
> 
> Decide on capitalisation of "Low power and Lossy Networks" and apply it
> uniformly throughout the document.
> 
> ---
> 
> Section 2 Actuator
> s/modulates/modulate/
> 
> ---
> 
> Section 2 Commissioning Tool
> s/expressed purpose/express purpose/
> 
> ---
> 
> Section 2 Downstream / Upstream
> 
> Are you convinced that these terms apply only to data entering / leaving
> the LLN at the LBR? They do not apply to traffic within the LLN?
> 
> Although I see you use "inwards" in the definition of "MP2P".
> 
> ---
> 
> Section 2 Field Device
> s/A field deviced/A field device/
> 
> ---
> 
> Section 2 Field Device
> 
>   Low power and Lossy Network Border Router (including LBR)
> 
> Is this right? Isn't a Low power and Lossy Network Border Router exactly
> an LBR?
> 
> ---
> 
> Section 2 Field Devices
> 
>   compared to computers and routers used in the Internet.
> 
> I know what you mean, but I think an LLN is part of the Internet.
> So maybe...
> 
>   compared to computers and routers used outside of LLNs.
> 
> ...or...
> 
>   compared to computers and routers used in the rest of the Internet.
> 
> ---
> 
> Section 2 Non-sleepy Node
> 
>   Non-sleepy Node: A non-sleepy node is a node that always remains in a
>   fully powered on state (i.e. always awake) where it has the
>   capability to perform RPL protocol communication.
> 
> I think that the specific reference to RPL is wrong in the context of 
> this document. You may mean "perform routing protocol communication" or
> you may mean "perform communication".
> 
> ---
> 
> Section 2 P2MP
> 
> You use the term DAG without explaining it. You either need to add it 
> to the terms (maybe DAG Root is more useful) or change what is written
> for P2MP.
> 
> ---
> 
> Section 2 RPL Domain
> 
> Fine, but no explanation of RPL. Since RPL is also used elsewhere in the
> document, I suggest you add an entry for RPL with a citation.
> 
> ---
> 
> Section 2 RPL Domain
> 
> Since someone is bound to ask what a RPL router is...
> Best add an entry.
> 
> ---
> 
> Section 2 Sensor
> 
> s/a analog/an analog/
> 
> ---
> 
> Section 2 Sleepy Node
> 
>   Sleepy Node: A sleepy node is a node that may sometimes go into a
>   sleep mode (i.e. go into a low power state to conserve power) and
>   temporarily suspend protocol communication.  A sleepy node may also
>   sometimes remain in a fully powered on state where it has the
>   capability to perform RPL protocol communication.
> 
> This doesn't quite make sense. You are using "Sometimes remain", I think
> to contrast with "sometimes go into a sleep mode".
> 
> I think it is enough to say "When no in a sleep mode, the sleepy node is
> in a fully powered on state...."
> 
> Additionally, is the only issue "to perform RPL protocol communication"?
> As for non-sleepy node you may mean "perform routing protocol
> communication" or you may mean "perform communication".
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll