Skip to main content

Terms Used in Routing for Low-Power and Lossy Networks
draft-ietf-roll-terminology-13

Note: This ballot was opened for revision 13 and is now closed.

Adrian Farrel Former IESG member
(was Discuss, Yes) Yes
Yes (2013-10-27) Unknown
The IESG is broadly supportive of the idea of merging this document with draft-ietf-lwig-terminology, but the authors of both documents suggest that there is no significant overlap between the two documents.

I am content that merging the documents would involve the authors in a lot of work that would result in two documents in a single volume rather than two documents in separate volumes.
Barry Leiba Former IESG member
No Objection
No Objection () Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2013-10-22) Unknown
I'm pretty sure that JP doesn't live in Boxborough any longer ;-)

Below is the OPS-DIR review from Dan Romascanu. Take it or leave it.

    It is a well written and seems to be a useful document. My only editorial question is whether it really is necessary to include here definitions of very common terms like MAC or LAN, which can be found in other standards like the IEEE standards. Such terms do not have a different meaning in roll. 

    The only definition that somehow differs from the common used definition is definition of Data sink as 'A device that collects data from nodes specific in an LLN.'. Is this something specific to roll? The text implies some active role for 'data sinks' ('device that collects data') while in other environments a data sink is just a device that receives data. If this is a mistake better fix this.
Brian Haberman Former IESG member
No Objection
No Objection (2013-10-22) Unknown
I agree with Benoit/Dan that there are some definitions that are globally accepted and don't need to be in this document.

Question 8 of the shepherd write-up says that an IPR disclosure was filed against this draft.  Really?
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2013-10-23) Unknown
Thanks for writing this good document!
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-10-22) Unknown
needs another rev to capture all the comments otherwise fine.
Martin Stiemerling Former IESG member
No Objection
No Objection (2013-10-22) Unknown
I was about to raise a DISCUSS, just for the reason that nobody has really read the document ;)

The title says "Terms used in Ruting for Low power And Lossy Networks", but it should read "Terms used in Routing for Low power And Lossy Networks. 

So please replace  'Ruting' by 'Routing' in the title.
Richard Barnes Former IESG member
(was Discuss) No Objection
No Objection (2013-10-23) Unknown
They typo in the title does not really inspire confidence in the level of review this document has received.
Sean Turner Former IESG member
No Objection
No Objection (2013-10-23) Unknown
I'm with Joel.
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-10-22) Unknown
In addition to Stewart's comments, and Benoit-channeling-Dan's comments, which I agree with, I had a few comments you might wish to consider along with any other comments you receive during IESG evaluation.

I'm thinking this text 

   HVAC: Heating, Ventilation and Air Conditioning.  A term applied to
   the comfort level of an internal space.

should be something like 

   HVAC: Heating, Ventilation and Air Conditioning.  A term applied to
   mechanisms used to maintain the comfort level of an internal space.
   ^ inserted text             ^

I understand what this text is saying

   P2P: Point To Point.  This refers to traffic exchanged between two
   nodes (regardless of the number of hops between the two nodes).

but wonder if it should be something like 

   P2P: Point To Point.  This refers to traffic exchanged between two
   nodes (regardless of the number of network hops between the two 
                                      ^ inserted "network"

   nodes).

In this text,

   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.  When no in a sleep mode,
                                                     ^not, I think

   the sleepy node is in a fully powered on state where it has the
   capability to perform communication.
Stephen Farrell Former IESG member
No Objection
No Objection (2013-10-22) Unknown
- The definition of LBR assumes that there is only one
per LLN which is probably not an intentional limitation.
To fix: s/The LBR/An LBR/g

- RAM - NVRAM is RAM but wouldn't fit this definition.
Deleting the definition would be best here I'd say.
Chances of it being needed are smaller than of getting
it wrong.

- Schedule - a single device can have a power duty-cycle
schedule, e.g. if an LBR is not a challenged device, so
the "two or more" here is just wrong.

- Sleepy Node - that definition is broken. A node can be
in a power state that's not asleep but where the radios
are off. Even ACPI has multiple sleep states, as do
processors so this just isn't binary. 

- Timeslot - "fixed time interval" is tricky - do you
mean fixed duration (and cycle) or fixed (modulo cycle)
when compared to UTC?
Stewart Bryant Former IESG member
No Objection
No Objection (2013-10-22) Unknown
Ruting - typo

==

Channel: Radio frequency sub-band

I think that this is a most unfortunate truncation in a document used about routing, since we have other channels such as OAM channels. Might I propose that you use "Radio Channel" a term which would normally be acceptable to radio engineers and which would not confuse network engineers. 

==
Channel Hopping: A procedure by which field devices synchronously change channels during operation.

This may need some clarification I imagine you refer to RX TX pairs sync rather than TX TX sync in any case you should probably expand the meaning.

==
   Closed Loop Control: A procedure whereby a device controller controls
   an actuator based on input information sensed by one or more field
   devices.

To be closed loop, surely you need to emphasis that the actuator causes an effect that has a (normally negative feedback) impact on  the sensor to result in a converged behaviour.

==
   Open Loop Control: A process whereby a plant operator manually
   manipulates an actuator over the network where the decision is
   influenced by information sensed by field devices.

Surely OLC has nothing to do with manual intervention and everything to do with the absence of feedback.

==
   Schedule: An agreed execution, wake-up, transmission, reception,
   etc., time-table between two or more field devices.

Schedule does not normally imply synchronisation, are you sure this term is not going to lead to confusion?
==