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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 03 March 2013 20:03 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C3A21F8883 for <roll@ietfa.amsl.com>; Sun, 3 Mar 2013 12:03:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhO7FiZJLwVS for <roll@ietfa.amsl.com>; Sun, 3 Mar 2013 12:03:39 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id AA0E921F8884 for <roll@ietf.org>; Sun, 3 Mar 2013 12:03:38 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r23K3aR2025962; Sun, 3 Mar 2013 20:03:36 GMT
Received: from 950129200 (089144192226.atnat0001.highway.a1.net [89.144.192.226]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r23K3Y2r025940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 Mar 2013 20:03:35 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-roll-terminology@tools.ietf.org>
Date: Sun, 3 Mar 2013 20:03:37 -0000
Message-ID: <005501ce184a$3290ccc0$97b26640$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4YSc1+RX4kliqKTde8YWkqYxrpoQ==
Content-Language: en-gb
Cc: roll@ietf.org, roll-chairs@tools.ietf.org
Subject: [Roll] AD review of draft-ietf-roll-terminology-11.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Mar 2013 20:03:40 -0000

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