Terminology for Constrained-Node Networks
draft-ietf-lwig-terminology-07

mostly this is an observation, I am however curious how this is addressed?

I have a lot of trouble with section 2 discussion of scaling... imho there are no problems associated with scaling the internet to 50 billion devices that are actually addressed or described in this document.

As a network operator I don't see the considerations for hosts to be dramatically different with merely an order  of magnitude more devices then we have at present.

another observation

section 2.2 

network technologies associated associated with limited resource devices exist today, whether these are cdma schemes running on rs485, 802.15.4, ongoing work in 802.11ah, bluetooth 4.0 low energy and so on.  while these technologies will be more present in the future then they are today some aren't that rare (zigbee in particular) and that seems like an odd thing to omit from that particular dicussion, only to be mentioned later in other places.

I'm abstaining because I think there's a missed opportunity
here to define terms that would last significantly longer 
if they were not based on absolutes, which seems short
sighted to me. 

write-up: I slightly dislike being told that "experts from
companies x, y & z" think something. Much better would be
to have been told that "Fred Bloggs, Joe Blow and
A.N.Other" read it and said on the list that they were ok
with it.  I've worked for large companies and some of our
company "experts" were not. And even if they were, they
were sometimes more intersted in achieving company goals
and not in objectively applying their expertise. (And just
in case, for a protocol spec, it would be fine to say that
company x have implemented since that's something one could
in principle check. So I'm not saying that write-ups ought
never mention comapanies.)

abstract: Devices years ago were arguably far more
constrained in some ways than the ones you mean here. The
tendency to forget what happened a decade or more ago is a
real one, and it'd be good if some lwig document reflected
that.  That's not really actionable, but if you wanted, you
could remove the first sentence of the abstract and still
be ok.

intro: all devices have limited CPU etc. (Except maybe some
in THHGTTG:-) That's not entirely a nit - all the
terminology here needs to be relative, and relative to what
we consider today's "standard candle" which could be a
typical laptop. If you re-cast the discussion here in to
only use relative terms, (except for examples) then perhaps
this terminology could be current for far longer? 

intro: sigh. The Internet has always been made of things.
The IoT is of course a new marketing term, but doesn't
reflect any new reality really. And "becomes a reality" is
just pure marketing which'd be better omitted. 

section 2: why is 5x10^10 an interesting number? That's
just 7 devices per person.

section 2: I don't understand the 2nd bullet at all. What
is it meant to say?

section 2: I disagree with the last sentence - there will
always be "constrained" nodes (relative to some standard
candle) and both the practical definition of constrained
and standard will move as technology develops. I don't see
how that *has to* to relate to scaling at all. (There are
relationships, but I don't think "scaling down" is
causitive.)

2.1: I assert that mentioning 2013 in the definition is a
mistake.

2.1: A definition that does not consider a smartphone a
constrained node seems wrong. Those are differently
constrained compared to a tension sensor, but both should
be considered constrained IMO. ("My problems are worse than
your problems" doesn't seem like a good basis for
terminology.)

2.1, bullet list: I would argue that you ought include
"constrained user interfaces" here. (A LED is a user
interface as is a factory-reset button, or even a
replacable battery arguably.)

2.1: bullet list: I think you're again making the mistake
of not being relative, e.g. "maximum node complexity" isn't
even really understandable (why's it a max? can't I just
add more? yes, I can!  but of course then its a different
device). Again the right approach (I claim:-) would be to
cast all this in relative terms.

2.1: batterys vs. harvesting is not a real dichotomy, afaik
almost all harvesting nodes have a battery or charge up a
capacitor. There are vanishingly few nodes with no energy
storage or accumulation mechanism and if they did become
popular I suspect they ought be a class of their own. Or am
I wrong there?

2.2: again 2013 in the definition is an error IMO. 

2.2: constrained n/w definition also seems wrong in that
there are networks today that are high speed that fit this
definition e.g. fibre based networks doing quantum key
distribution.
 
2.2.1: I don't think this is really a useful section at
all, unless the goal is simply to say that DTN protocols
are out of scope, which they are, since all protocols are
out of scope. I'd say just delete this section (if you fix
the definitions).

2.3: Just to note that this defintion is fine!

2.3.x: again you seem to be just dealing with territory
here but I guess this could be useful

3 - I bet you some beers you live to regret using absolute
numbers here. I don't find this table that useful. The text
definitions saying what the nodes in various classes can
and cannot do however is good and should be used in the
definitions.

4.1 says you're not defining classes, but then 4.2 seems to
do exactly that, which I find confusing.

4.2: I'd suggest s/E3/Einf/ so you could introduce new
classes when you find out that E0..2 aren't sufficiently
descriptive of interesting classes of device. For example,
this section doesn't seem to consider duty-cycles which IMO
can siginifcantly influence designs and which also provide
a handy way to talk about device power requirements and
capabilities in a n/w.

- table 4: Sn as classes is a terrible choice since it
conflicts with existing sleep state terminology for ACPI.

- I agree with the secdir reviewer's suggestion [1] that
it'd be good to note the security characteristics of the
various classes defined (even if the current classes are
kept). A table could usefully do that. (The exercise of
generating that table might also help to see if the current
class definitions are meaningful.)

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03964.html