source: lwig-term-iesg2-88.txt

Last change on this file was 36, checked in by cabo@…, 6 years ago

… and send the discussion to the IESG.

File size: 33.1 KB
Line 
1This is a common response of the authors to the IESG comments on
2draft-ietf-lwig-terminology-05, explaining the choices in
3draft-ietf-lwig-terminology-06.  It took us quite a while to process
4these comments; in part, the below is based on the results of the
5Vancouver face-to-face LWIG WG meeting.
6
7Since there is a lot of overlap between the comments of the various
8ADs, the editors have decided to combine this into one document.
9(Indented text is the DISCUSS/comment, outdented text is the
10discussion.)
11
12Grüße, Carsten
13
14
15        Adrian Farrel
16
17*       Discuss (2013-08-13)
18
19        I have struggled hard in my review of this document, and Brian
20        Habermann has helped me a lot with understanding the value and
21        purpose of the work.  In my Discuss, below, I have tried to list
22        actionable work that I feel is necessary for the publication of
23        this document as a definition of terminology, and I have pushed
24        out to my Comment other issues that I think would be good to fix
25        but which are not blocking.
26
27        Before reading and attempting to resolve the Discuss issues, the
28        authors might like to consider whether this document could be re-
29        positioned as "A Discussion of Some Concept in Constrained Networks".
30        I believe that this re-branding complete with a few minor tweaks to
31        the text to be consistent would pretty much defuse most of my
32        Discuss comments (except, perhaps some on the Abstract and Section
33        2.3.1).
34
35
36It is meant to supply some terminology.
37This terminology already is in day-to-day use at the IETF.
38It is a good idea to write it up.
39It may not be mathematically precise or even good enough to use for
40taxation purposes, but it is good enough to shape requirements
41documents and design considerations.
42
43        ---
44
45        The Abstract is confusing in that it introduces a "small device with
46        severe constraints" and uses it to define a "constrained node network",
47        but never says what a "constraint" is. It then goes on to use the term
48        "constrained environment" without explaining what this means.
49
50        I think that the Abstract could give several examples of constraint for
51        a node (memory, CPU, power).
52
53I like small abstracts.
54If this absolutely needs to be done, let's try to do this without
55creating a monster abstract.
56
57OLD:
58   The Internet Protocol Suite is increasingly used on small devices
59   with severe constraints,
60NEW:
61   The Internet Protocol Suite is increasingly used on small devices
62   with severe constraints on power, memory and processing resources,
63CONTINUE:
64   creating constrained node networks.  This
65   document provides a number of basic terms that have turned out to be
66   useful in the standardization work for constrained environments.
67
68
69        It could also replace "constrained
70        environment" (which is not used in the rest of the document - except in
71        a similar paragraph in the Introduction) with "constrained network"
72        together with a mention that links may also be constrained, and some
73        examples of link constraints.
74
75Constrained network is not necessarily the term intended here.
76(Really, this is mostly about constrained nodes and constrained node networks.)
77
78OLD:
79   document provides a number of basic terms that have turned out to be
80   useful in the standardization work for constrained environments.
81NEW:
82   document provides a number of basic terms that have turned out to be
83   useful in the standardization work for constrained node networks.
84
85        ---
86
87        Section 2.1
88
89        I agree that the definition of Constrained Node "is less than
90        satisfying."  Indeed, I think that the definition you provide is useless
91        as a definition.
92
93Disagree.
94(We imported some of the words from the 6lo charter, yielding:
95
96  The tight limits on power, memory and processing resources lead to
97  hard upper bounds on state, code space and processing cycles, making
98  optimization of energy and network bandwidth usage dominating design
99  requirements.  Also, some layer 2 services such as full connectivity
100  and broadcast/multicast may be lacking.
101
102But these are really just ancillary to our primary definition.)
103
104        I find it odd that the definition includes the reasons why the node is
105        different, but not a list of the ways it might be different.
106
107Yes, see above.
108
109              some of the characteristics that are
110              otherwise pretty much taken for granted for Internet nodes in 2013
111
112        ...is so vague and unscoped. Of course, the text that follows does
113        list some of the constraints and these are helpful to an understanding
114        of the definition.
115
116Yes.
117
118        Probably the best way to handle this is to turn the whole section into
119        prose and dispense with the formal definition that isn't.
120
121The definition is formal, just not rigorous.
122
123        The same problem exists in Section 2.2.
124
125Yes, but we don't agree it is a problem.
126
127        [These concerns are consistent with my suggestion to back away from
128        providing definitions, and to offer a discussion of concepts instead.]
129
130        ---
131
132        Section 2.3.1 is full of issues.
133
134Well, it is trying to use the term LLN.
135
136           In common usage, LLN often stands for "the network characteristics
137           that RPL has been designed for".
138
139        Asides from being cryptic (or possibly sarcastic), that definition is so
140        clearly circular as to be of no value. You could, instead stop after the
141        quote from draft-ietf-roll-terminology.
142
143Yes, maybe we should.
144
145OLD:
146   In common usage, LLN often stands for "the network characteristics
147   that RPL has been designed for".  Beyond what is said in the ROLL
148   terminology document, LLNs do appear to have significant loss at the
149   physical layer, with significant variability of the delivery rate,
150   and some short-term unreliability, coupled with some medium term
151   stability that makes it worthwhile to construct medium-term stable
152   directed acyclic graphs for routing and do measurements on the edges
153   such as ETX [RFC6551].  Actual "low power" does not seem to be
154   required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the
155   positions on scaling of LLNs appear to vary widely
156   [I-D.clausen-lln-rpl-experiences].
157
158NEW:
159   Beyond that, LLNs often have significant loss at the
160   physical layer, with significant variability of the delivery rate,
161   and some short-term unreliability, coupled with some medium term
162   stability that makes it worthwhile to construct medium-term stable
163   directed acyclic graphs for routing and do measurements on the edges
164   such as ETX [RFC6551].  Actual "low power" does not seem to be
165   a defining characteristic for an LLN [I-D.hui-vasseur-roll-rpl-deployment].
166
167OLD:
168   The ROLL terminology document states that LLNs typically are composed
169   of constrained nodes; this is also supported by the design of
170   operation modes such as RPL's "non-storing mode".  So, in the
171   terminology of the present document, an LLN seems to be a constrained
172   node network with certain network characteristics, which include
173   constraints on the network as well.
174
175NEW:
176   LLNs typically are composed
177   of constrained nodes; this leads to the design of
178   operation modes such as RPL's "non-storing mode".  So, in the
179   terminology of the present document, an LLN is a constrained
180   node network with certain network characteristics, which include
181   constraints on the network as well.
182
183
184        Also, please expand RPL and give a reference.
185
186Good point.  [x]
187
188           LLNs do appear to have significant loss at the
189           physical layer
190
191        How do you mean "appear"? Do they or don't they?
192
193It is not the intention of this document to define this term.
194So far, we have the definition in roll-terminology, and that doesn't
195mention this.
196
197           Actual "low power" does not seem to be
198           required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the
199           positions on scaling of LLNs appear to vary widely
200           [I-D.clausen-lln-rpl-experiences].
201
202        Again "seem to be". If you cannot provide a definition in this document
203        then probably best to not try.
204
205See above.
206(Added before section 2.3.1:
207NEW:
208   The rest of this subsection introduces two additional terms that are
209   in active use in the area of constrained node networks, without an
210   intent to define them: LLN and (6)LoWPAN.
211)
212
213        The reference to [I-D.clausen-lln-rpl-experiences] in the discussion of
214        scaling LLNs is curious.  That document talks about experiences trying
215        to scale RPL. It does not, as far as I can tell, discuss the size or
216        scalability of a LLN.
217
218Removed above.
219
220           The ROLL terminology document states that LLNs typically are composed
221           of constrained nodes; this is also supported by the design of
222           operation modes such as RPL's "non-storing mode".  So, in the
223           terminology of the present document, an LLN seems to be a constrained
224           node network with certain network characteristics, which include
225           constraints on the network as well.
226
227        What do you mean "is also supported by"? Are you saying that the
228        composition of a network is defined by the widgits built into a protocol
229        that runs over it?
230
231See above.
232
233        What do you mean "an LLN seems to be..." Can you not write a clear
234        definition?
235
236Changed as above.
237
238        ---
239
240        Section 2.3.2
241
242        I don't see a definition in this section of either LoWPAN or 6LoWPAN. I
243        only find a discussion of the expansion of the acronym.
244
245        [Again, if the document is not seeking or claiming to provide
246        definitions this is not a problem.]
247
248Yes, again, this subsection is not trying to define the term.
249
250        ---
251
252        In Section 3, the description of a Class 0 node seems to be prejudging
253        the work of LWIG. It is mixing what the physical capabilities of the
254        node are (memory, CPU, power) with what the node will be capable of
255        doing (using security).  That is surely interesting and equally surely
256        not part of the definition of the node class.
257
258It is an observed characteristic of the node class.
259
260        Similar issues apply to the discussion of Class 1 and Class 2 nodes.
261
262        [Yet again, if you are not defining but only discussing then this
263        issue is much less pronounced.]
264
265We very much do intend to provide a definition here.
266
267        ---
268
269        Section 5 is missing some thoughts about the availability of security
270        mechanisms in constrained devices. Since these are mentioned in Section
271        3, you can't duck them in Section 5.
272
273Yes, this could be considerably expanded, but maybe not in this document.
274draft-ietf-core-coap-18 is being referenced.
275Maybe draft-garcia-core-security should be, as well. [x]
276
277*       Comment (2013-08-13)
278
279        In pulling terms and ideas from non-consensus documents, this document
280        assigns the terms more weight than they actually have. For example, in
281        2.3.2...
282
283           Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6,
284           "6LoWPAN") is now also being used for networks built from similarly
285           constrained link layer technologies [I-D.ietf-6lowpan-btle]
286           [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz].
287
288        ...is undoubtedly correct, but implies that there is acceptance of this
289        use of the term.
290
291LoWPAN is introduced in RFC 4919.  The way the charter of the new 6lo
292WG uses the term is consistent with that.
293
294        I don't believe this document is supposed to be a survey of the way terms
295        are used in works in progress, but is supposed to be a set of
296        definitions to help future work.
297
298        This can be handled by a small change in wording so that "is now also
299        being used for" is replaced with "also refers to".
300
301OK. [x]
302
303Also added before 2.3.1:
304
305NEW:
306   The rest of this subsection introduces two additional terms that are
307   in active use in the area of constrained node networks, without an
308   intent to define them: LLN and (6)LoWPAN.
309
310        ---
311
312        Section 1
313
314           Small devices with limited CPU, memory, and power resources, so
315           called constrained devices (also known as sensor, smart object, or
316           smart device) can constitute a network, becoming "constrained nodes"
317           in that network.  Such a network may itself exhibit constraints, e.g.
318           with unreliable or lossy channels, limited and unpredictable
319           bandwidth, and a highly dynamic topology.
320
321        I question "also known as..." A sensor, smart object, or smart device
322        does not need to be constrained. A constrained device does not need to
323        be a sensor, smart object, or smart device. It might be reasonable to
324        say that "...many sensors, smart objects, and smart devices are
325        constrained devices..."
326
327->
328s/also known as/often used as/
329
330        I think "constitute a network" is wrong. These constrained nodes may be
331        included in a network, but do they constitute the network?
332
333->
334s/ constitute/ form/
335
336(The network may also include wiring, which we are ignoring here.)
337
338        Are the elements of constrained connectivity between nodes (nodes which
339        may or may not themselves be constrained nodes) relevant to the work of
340        LWIG? It is possible that the behavior of the data channels has an
341        impact on the code and buffering needed in a node. If so, perhaps this
342        could be drawn out more in the Introduction.
343
344Not necessarily.  It is, however, useful to distinguish network
345constraints not rooted in node constraints from those of a constrained
346node network.
347
348OLD:
349 Constrained devices may work under severe resource constraints such
350   as limited battery and computing power, little memory, as well as
351   insufficient wireless bandwidth and ability to communicate.
352NEW:
353 Constrained devices may work under severe resource constraints such
354   as limited battery and computing power, little memory, as well as
355   insufficient wireless bandwidth and ability to communicate; these
356   constraints often exacerbate each other.
357
358        ---
359
360        Section 2 might be better named "Core Terminology" otherwise we wonder
361        why other sections are not just subsections of section 2.
362
363Good point. [x]
364
365        ---
366
367        I don't like "this field of work" (which field?) and "appears to be"
368        (appears to whom?) in Section 2. Maybe you could give:
369
370           There are two important aspects to scaling within the IoT:
371
372Good point (spelled out IoT).
373
374        BTW, is underbar _really_ necessary?
375
376No.  This is an artifact of XML2RFC, which is unable to show emphasis
377in the soon canonical XML and the HTML version without also leaving
378marks in the TXT version.  The RFC editor will undoubtedly fix this...
379
380        ---
381
382        Section 4.1
383
384           Instead of defining classes or clusters, we propose simply stating,
385           in SI units, an approximate value for one or both of the quantities
386           listed in Table 2:
387
388        You "propose"? You have moved beyond that. Now you "do".
389
390Good point. [x]
391
392        ---
393
394        I am surprised that Ps is a useful measure. In my experience devices
395        often operate power availability on a curve (usually a series of steps)
396        as a function of remaining energy in the store. Thus devices that are
397        running short of energy reduce the available power to try to eke out
398        what is left.  That would, of course, make the average an ambiguous
399        measure.
400
401Good point. [x]
402
403        ---
404
405        Section 4.3
406
407        I was amused by he term "Always Off". "Always" as in "except for the
408        exceptions"? :-)
409
410One of the valuable aspects of this term is indeed that it is slightly
411provocative.  However, we have reverted to "Normally-Off".
412
413        ---
414
415        In section 4.3 it would be useful to align with (or at least mention)
416        the terms "sleepy node" and "non-sleepy node" as presented in
417        draft-ietf-roll-terminology.
418
419Good point. One definition of a sleepy node is that it is not
420Always-On.  Others use it as a synonym of Always-Off.  We have
421introduced Low-Power and Always-Off to be more specific.
422-> Add a quick discussion of the terms at the end of the definition
423list in 4.3.  [x]
424
425
426        Barry Leiba
427
428*       Comment (2013-07-09)
429
430        Do we really want to tie the general definitions of "constrained [thing]" (in
431        Sections 2.1 and 2.2) to 2013?  I wouldn't think so.  It makes sense to say
432        that the numbers in Table 1 represent constraint levels in 2013, but whether
433        something is a constrained node or not should be relative to when the
434        evaluation is being made, not relative to 2013, no?
435
436(The reference to 2013 is needed only in so far as "what is expected"
437is likely to change over time.  Once there are more IoT nodes than
438classic Internet nodes, the expectation is going to be shaped by
439IoT nodes!  "At the time of writing" is maybe a better term.)
440
441->
442s/2013/at the time of writing/
443
444More generally, the authors are expecting these terms to evolve over a
445period of a decade or so; maybe it's then simply time to make a new
446version of the document.
447
448        Jari Arkko
449
450*       Comment (2013-08-13)
451
452        Thanks for writing this useful document. A couple of comments that you may
453        consider:
454
455        1) In my experience, power/memory/cpu are important considerations, but equally
456        often user interface and deployment considerations are the cause of even more
457        constraints or challenges. E.g., ability to set keys, update software, etc.
458        Perhaps these kinds of limitations could be listed as well.
459
460Good point.  [X]
461
462        2) I agree with other ADs that tying the definitions to 2013 state of the world
463        may not be useful.
464
465(See above)
466
467        3) I found the below comments from Suresh Krishnan's Gen-ART review useful. In
468        particular, I'd not limit constrained devices to sensors.
469
470        ---
471
472        I have been selected as the General Area Review Team (Gen-ART)
473        reviewer for this draft (for background on Gen-ART, please see
474        http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
475
476        Please wait for direction from your document shepherd
477        or AD before posting a new version of the draft.
478
479        Document: draft-ietf-lwig-terminology-05.txt
480        Reviewer: Suresh Krishnan
481        Review Date: 2013/08/12
482        IESG Telechat date: 2013/08/15
483
484        Summary: This draft is ready for publication as an Informational RFC but
485        I do have a few comments that the authors may wish to consider.
486
487        Minor
488        =====
489
490        * Section 1
491
492        Aren't actuators also one class of constrained devices? The section
493        talks about gathering information but does not talk about constrained
494        devices acting on information.
495
496Yes! [x]
497
498        * Section 2.1
499
500        When speaking about the multiple facets of constraints on the nodes
501        shouldn't processing power be included as well? There is an item for
502        power but it is unclear if that means energy/power or processing power.
503        In either case one of them probably needs to be added.
504
505We touch this in the introduction.  However, the constraints in
506processing power (CPU speed) are only a secondary issue with today's
507chips; we even have so much CPU power that we trade it aggressively
508for communication cost.  Clarified that this is mainly about
509power as in energy per time.  [x]
510
511        * Section 2.2
512
513        Would it be worth mentioning the asymmetric nature of some of these link
514        as a constraint?
515
516Yes. [X]
517
518        * Section 2.3.1
519
520        This sentence does not read right. Suggest rewording.
521
522        OLD:
523        In its terminology document, the ROLL working group is saying
524        [I-D.ietf-roll-terminology]:
525
526        NEW:
527        The ROLL terminology document [I-D.ietf-roll-terminology] defines LLNs
528        as follows:
529
530(Covered above.)
531
532        * Section 3
533
534        Please add a reference to the CoAP draft at first use of CoAP.
535
536[x]
537
538        * Section 4.3
539
540        Should this section also talk a bit about the term "duty cycle" since
541        this term is used frequently in the constrained device context?
542
543Hmm, maybe.  This is often a L1 thing, below what we discuss here.
544Maybe add at the end of the definition list in 4.3:
545
546NEW:
547  A term often used to describe power-saving approaches is
548  "duty-cycling".  This describes all forms of periodically switching
549  off some function, leaving it on only for a certain percentage of
550  time (the "duty cycle").
551
552
553        Thanks
554        Suresh
555
556        Joel Jaeggli
557
558*       Comment (2013-08-13)
559
560        mostly this is an observation, I am however curious how this is addressed?
561
562        I have a lot of trouble with section 2 discussion of scaling... imho there are
563        no problems associated with scaling the internet to 50 billion devices that are
564        actually addressed or described in this document.
565
566Somebody has to pay for these 5e10 devices.  Somebody has to set up
567all of them etc.  So the technologies have to scale down to a level of
568cost (manufacturing, installation, operation) that enables these
569numbers.
570
571        As a network operator I don't see the considerations for hosts to be
572        dramatically different with merely an order  of magnitude more devices then we
573        have at present.
574
575The considerations are indeed more about the constrained nodes than
576about the backbone network supporting them.
577
578        another observation
579
580        section 2.2
581
582        network technologies associated associated with limited resource devices exist
583        today, whether these are cdma schemes running on rs485, 802.15.4, ongoing work
584        in 802.11ah, bluetooth 4.0 low energy and so on.  while these technologies will
585        be more present in the future then they are today some aren't that rare (zigbee
586        in particular) and that seems like an odd thing to omit from that particular
587        dicussion, only to be mentioned later in other places.
588
589Constrained node networks aren't new, what is new is that we are
590accommodating them more.  But maybe we don't understand the comment.
591
592        Spencer Dawkins
593
594*       Comment (2013-08-09)
595
596        I'm a Yes, and think this document is in good shape and worth publishing at
597        version -05.
598
599        That said, I am sensitive to Barry's point about "constrained" not being the
600        same as "constrained in 2013".
601
602(See above.)
603
604        If I wasn't looking at this document for the first time at the end of the
605        process, I probably would have asked how useful Table 1 really is, because what
606        matters isn't whether you have 100 KiB of flash memory, it's what you have
607        enough flash memory to do. So, not based on physical characteristics, but on
608        functional characteristics - and the distinctions based on functional
609        characteristics are well-described in the paragraphs that follow Table 1.
610
611Actually, the distinction has turned out to be surprisingly useful.
612
613        What I was thinking, was more like "there are three classes of devices, and you
614        know you have a Class 0 device when it's too constrained to communicate
615        directly with the Internet  ..."
616
617        But unless people think that's helpful ... ship it.
618
619        Stephen Farrell
620
621*       Discuss (2013-08-15)
622
623        I have one discuss point, that I'll probably quickly clear
624        when told the wg could rather not, and then I'll move to
625        abstain. My discuss is:
626
627        I think we're missing an opportunity here to do much better
628        than this and could do so if this document were re-worked
629        with the goal of making the text be such that it would
630        likely still be useful in 5 years time. Would the WG like
631        to do that?
632
633(I don't see that we can.)
634
635        Assuming the answer will be "no, thanks" then I'll move to
636        an abstain since I think that's unfortunate, and very
637        little, but some, harm will ensue, in terms of confusion
638        when these terms are used in the not too distant future.
639
640        I'm happy discuss my comments of course, in any case, but
641        really handling many of them would only make sense if the
642        wg wanted to re-do this, so if I do end up abstaining,
643        it'll be entirely fine to pretty much ignore my comments:-)
644        Comment (2013-08-15)
645
646        write-up: I slightly dislike being told that "experts from
647        companies x, y & z" think something. Much better would be
648        to have been told that "Fred Bloggs, Joe Blow and
649        A.N.Other" read it and said on the list that they were ok
650        with it.  I've worked for large companies and some of our
651        company "experts" were not. And even if they were, they
652        were sometimes more intersted in achieving company goals
653        and not in objectively applying their expertise. (And just
654        in case, for a protocol spec, it would be fine to say that
655        company x have implemented since that's something one could
656        in principle check. So I'm not saying that write-ups ought
657        never mention comapanies.)
658
659        abstract: Devices years ago were arguably far more
660        constrained in some ways than the ones you mean here. The
661        tendency to forget what happened a decade or more ago is a
662        real one, and it'd be good if some lwig document reflected
663        that.  That's not really actionable, but if you wanted, you
664        could remove the first sentence of the abstract and still
665        be ok.
666
667My PDP-11 in 1980 had more electrical power available to it than the
668chips we are working with today, even if other characteristics were
669indeed similar (and it was hard to get IPv4 running on the things!)
670
671        intro: all devices have limited CPU etc. (Except maybe some
672        in THHGTTG:-) That's not entirely a nit - all the
673        terminology here needs to be relative, and relative to what
674        we consider today's "standard candle" which could be a
675        typical laptop. If you re-cast the discussion here in to
676        only use relative terms, (except for examples) then perhaps
677        this terminology could be current for far longer?
678
679The term limited is used in the sense of "living on limited income":
680When the fact that the income is limited starts to dominate your life,
681and constrains you beyond what is considered normal in society, you
682"live on limited income".  A constrained device is one where those
683constraints permeate all design and limit what can be achieved beyond
684what is "normal" in the Internet today.
685
686        intro: sigh. The Internet has always been made of things.
687        The IoT is of course a new marketing term, but doesn't
688        reflect any new reality really. And "becomes a reality" is
689        just pure marketing which'd be better omitted.
690
691        section 2: why is 5x10^10 an interesting number? That's
692        just 7 devices per person.
693
694It's the next step.
695(It is probably also the milestone at which it is worth to revise the present document.)
696
697        section 2: I don't understand the 2nd bullet at all. What
698        is it meant to say?
699
700
701
702        section 2: I disagree with the last sentence - there will
703        always be "constrained" nodes (relative to some standard
704        candle) and both the practical definition of constrained
705        and standard will move as technology develops. I don't see
706        how that *has to* to relate to scaling at all. (There are
707        relationships, but I don't think "scaling down" is
708        causitive.)
709
710        2.1: I assert that mentioning 2013 in the definition is a
711        mistake.
712
713(see above.)
714
715        2.1: A definition that does not consider a smartphone a
716        constrained node seems wrong. Those are differently
717        constrained compared to a tension sensor, but both should
718        be considered constrained IMO. ("My problems are worse than
719        your problems" doesn't seem like a good basis for
720        terminology.)
721
722That is a fundamental problem with the LWIG terminology.
723"Constrained node" is a shorthand for "Constrained node of class 1 or 2."
724Do we want to create monster terms that say this or an equivalent all
725the time?
726
727        2.1, bullet list: I would argue that you ought include
728        "constrained user interfaces" here. (A LED is a user
729        interface as is a factory-reset button, or even a
730        replacable battery arguably.)
731
732(See above.)
733
734        2.1: bullet list: I think you're again making the mistake
735        of not being relative, e.g. "maximum node complexity" isn't
736        even really understandable (why's it a max? can't I just
737        add more? yes, I can!  but of course then its a different
738        device). Again the right approach (I claim:-) would be to
739        cast all this in relative terms.
740
741        2.1: batterys vs. harvesting is not a real dichotomy, afaik
742        almost all harvesting nodes have a battery or charge up a
743        capacitor. There are vanishingly few nodes with no energy
744        storage or accumulation mechanism and if they did become
745        popular I suspect they ought be a class of their own. Or am
746        I wrong there?
747
748TO DO.
749
750        2.2: again 2013 in the definition is an error IMO.
751
752(See above.)
753
754        2.2: constrained n/w definition also seems wrong in that
755        there are networks today that are high speed that fit this
756        definition e.g. fibre based networks doing quantum key
757        distribution.
758
759        2.2.1: I don't think this is really a useful section at
760        all, unless the goal is simply to say that DTN protocols
761        are out of scope, which they are, since all protocols are
762        out of scope. I'd say just delete this section (if you fix
763        the definitions).
764
765        2.3: Just to note that this defintion is fine!
766
767        2.3.x: again you seem to be just dealing with territory
768        here but I guess this could be useful
769
770        3 - I bet you some beers you live to regret using absolute
771        numbers here. I don't find this table that useful. The text
772        definitions saying what the nodes in various classes can
773        and cannot do however is good and should be used in the
774        definitions.
775
776The categories defined here have held since at least 2004, if not
777longer back.  They are indeed formed by what can and cannot be done;
778Moore's law goes into cost and energy improvements instead.  So we
779believe these categories will remain relevant for quite some more time.
780
781        4.1 says you're not defining classes, but then 4.2 seems to
782        do exactly that, which I find confusing.
783
784(we are not defining classes for 4.1)
785
786        4.2: I'd suggest s/E3/Einf/ so you could introduce new
787        classes when you find out that E0..2 aren't sufficiently
788        descriptive of interesting classes of device. For example,
789        this section doesn't seem to consider duty-cycles which IMO
790        can siginifcantly influence designs and which also provide
791        a handy way to talk about device power requirements and
792        capabilities in a n/w.
793
794E∞ isn’t ASCII, so E9?
795
796        - table 4: Sn as classes is a terrible choice since it
797        conflicts with existing sleep state terminology for ACPI.
798
799Right.
800
801        - I agree with the secdir reviewer's suggestion [1] that
802        it'd be good to note the security characteristics of the
803        various classes defined (even if the current classes are
804        kept). A table could usefully do that. (The exercise of
805        generating that table might also help to see if the current
806        class definitions are meaningful.)
807
808           [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03964.html
809
810        Ted Lemon
811
812*       Comment (2013-08-14)
813
814           Maybe the term is
815           best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI].
816
817        This doesn't actually make sense—why does "area" belong in this sentence, given
818        that no statement as to the size of the area is given?  I would suggest
819        deleting this sentence.
820
821True. Removed "Best", but left the existing usage in.
822
823        In Table 1, are the column's or'd or anded?   That is, for example, is a C0
824        device a device that either has <<10k of RAM or <<100k of code?   Or a device
825        that has both <<10k or RAM _and_ <<100k of code?   Is a device with 10k of RAM
826        and 10k of code a C0 or a C1 device?
827
828Class 0.  But the real world chips correlate a lot here, as they are
829designed to be useful for a class of applications.
830
831        In Table 3, "mains powered" is a regional name, which likely will not be
832        understood by all readers.   I notice that "mains power" is used elsewhere in
833        the document; it might be good to define it somewhere.   I realize that this
834        may sound very nit-picky, but you never know who is going to be reading the
835        document.   I think it would be obvious to me in context, even if I hadn't
836        heard the term before, what the term means, but I am unsure enough that it
837        would be obvious to any reader that I think it's worth defining the term.
838
839(I haven't really found a much better, non-regional term.  Most US
840speakers are aware of this British usage.  Added a quick definition.)
841
842        Other than that, the document looks good.   I think a lot of IETFers could
843        benefit from reading this document, because these terms have been coming up in
844        conversation quite a bit recently.   For example, I heard "LLN" a lot long
845        before I learned what it stood for, and I have since used it on people who
846        responded by saying "what's an LLN."  :)
Note: See TracBrowser for help on using the repository browser.