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

["Adrian Farrel" <[e-mail]>]

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