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
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.
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
12Grüße, Carsten
15        Adrian Farrel
17*       Discuss (2013-08-13)
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.
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).
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.
43        ---
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.
50        I think that the Abstract could give several examples of constraint for
51        a node (memory, CPU, power).
53I like small abstracts.
54If this absolutely needs to be done, let's try to do this without
55creating a monster abstract.
58   The Internet Protocol Suite is increasingly used on small devices
59   with severe constraints,
61   The Internet Protocol Suite is increasingly used on small devices
62   with severe constraints on power, memory and processing resources,
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.
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.
75Constrained network is not necessarily the term intended here.
76(Really, this is mostly about constrained nodes and constrained node networks.)
79   document provides a number of basic terms that have turned out to be
80   useful in the standardization work for constrained environments.
82   document provides a number of basic terms that have turned out to be
83   useful in the standardization work for constrained node networks.
85        ---
87        Section 2.1
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.
94(We imported some of the words from the 6lo charter, yielding:
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.
102But these are really just ancillary to our primary definition.)
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.
107Yes, see above.
109              some of the characteristics that are
110              otherwise pretty much taken for granted for Internet nodes in 2013
112 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.
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.
121The definition is formal, just not rigorous.
123        The same problem exists in Section 2.2.
125Yes, but we don't agree it is a problem.
127        [These concerns are consistent with my suggestion to back away from
128        providing definitions, and to offer a discussion of concepts instead.]
130        ---
132        Section 2.3.1 is full of issues.
134Well, it is trying to use the term LLN.
136           In common usage, LLN often stands for "the network characteristics
137           that RPL has been designed for".
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.
143Yes, maybe we should.
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].
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].
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.
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.
184        Also, please expand RPL and give a reference.
186Good point.  [x]
188           LLNs do appear to have significant loss at the
189           physical layer
191        How do you mean "appear"? Do they or don't they?
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.
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].
202        Again "seem to be". If you cannot provide a definition in this document
203        then probably best to not try.
205See above.
206(Added before section 2.3.1:
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.
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.
218Removed above.
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.
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?
231See above.
233        What do you mean "an LLN seems to be..." Can you not write a clear
234        definition?
236Changed as above.
238        ---
240        Section 2.3.2
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.
245        [Again, if the document is not seeking or claiming to provide
246        definitions this is not a problem.]
248Yes, again, this subsection is not trying to define the term.
250        ---
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.
258It is an observed characteristic of the node class.
260        Similar issues apply to the discussion of Class 1 and Class 2 nodes.
262        [Yet again, if you are not defining but only discussing then this
263        issue is much less pronounced.]
265We very much do intend to provide a definition here.
267        ---
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.
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]
277*       Comment (2013-08-13)
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...
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].
288 undoubtedly correct, but implies that there is acceptance of this
289        use of the term.
291LoWPAN is introduced in RFC 4919.  The way the charter of the new 6lo
292WG uses the term is consistent with that.
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.
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".
301OK. [x]
303Also added before 2.3.1:
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.
310        ---
312        Section 1
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.
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..."
328s/also known as/often used as/
330        I think "constitute a network" is wrong. These constrained nodes may be
331        included in a network, but do they constitute the network?
334s/ constitute/ form/
336(The network may also include wiring, which we are ignoring here.)
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.
344Not necessarily.  It is, however, useful to distinguish network
345constraints not rooted in node constraints from those of a constrained
346node network.
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.
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.
358        ---
360        Section 2 might be better named "Core Terminology" otherwise we wonder
361        why other sections are not just subsections of section 2.
363Good point. [x]
365        ---
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:
370           There are two important aspects to scaling within the IoT:
372Good point (spelled out IoT).
374        BTW, is underbar _really_ necessary?
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...
380        ---
382        Section 4.1
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:
388        You "propose"? You have moved beyond that. Now you "do".
390Good point. [x]
392        ---
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.
401Good point. [x]
403        ---
405        Section 4.3
407        I was amused by he term "Always Off". "Always" as in "except for the
408        exceptions"? :-)
410One of the valuable aspects of this term is indeed that it is slightly
411provocative.  However, we have reverted to "Normally-Off".
413        ---
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.
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]
426        Barry Leiba
428*       Comment (2013-07-09)
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?
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.)
442s/2013/at the time of writing/
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.
448        Jari Arkko
450*       Comment (2013-08-13)
452        Thanks for writing this useful document. A couple of comments that you may
453        consider:
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.
460Good point.  [X]
462        2) I agree with other ADs that tying the definitions to 2013 state of the world
463        may not be useful.
465(See above)
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.
470        ---
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
476        Please wait for direction from your document shepherd
477        or AD before posting a new version of the draft.
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
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.
487        Minor
488        =====
490        * Section 1
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.
496Yes! [x]
498        * Section 2.1
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.
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]
511        * Section 2.2
513        Would it be worth mentioning the asymmetric nature of some of these link
514        as a constraint?
516Yes. [X]
518        * Section 2.3.1
520        This sentence does not read right. Suggest rewording.
522        OLD:
523        In its terminology document, the ROLL working group is saying
524        [I-D.ietf-roll-terminology]:
526        NEW:
527        The ROLL terminology document [I-D.ietf-roll-terminology] defines LLNs
528        as follows:
530(Covered above.)
532        * Section 3
534        Please add a reference to the CoAP draft at first use of CoAP.
538        * Section 4.3
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?
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:
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").
553        Thanks
554        Suresh
556        Joel Jaeggli
558*       Comment (2013-08-13)
560        mostly this is an observation, I am however curious how this is addressed?
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.
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
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.
575The considerations are indeed more about the constrained nodes than
576about the backbone network supporting them.
578        another observation
580        section 2.2
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.
589Constrained node networks aren't new, what is new is that we are
590accommodating them more.  But maybe we don't understand the comment.
592        Spencer Dawkins
594*       Comment (2013-08-09)
596        I'm a Yes, and think this document is in good shape and worth publishing at
597        version -05.
599        That said, I am sensitive to Barry's point about "constrained" not being the
600        same as "constrained in 2013".
602(See above.)
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.
611Actually, the distinction has turned out to be surprisingly useful.
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  ..."
617        But unless people think that's helpful ... ship it.
619        Stephen Farrell
621*       Discuss (2013-08-15)
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:
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?
633(I don't see that we can.)
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.
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)
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.)
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.
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!)
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?
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.
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.
691        section 2: why is 5x10^10 an interesting number? That's
692        just 7 devices per person.
694It's the next step.
695(It is probably also the milestone at which it is worth to revise the present document.)
697        section 2: I don't understand the 2nd bullet at all. What
698        is it meant to say?
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.)
710        2.1: I assert that mentioning 2013 in the definition is a
711        mistake.
713(see above.)
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.)
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?
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.)
732(See above.)
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.
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?
748TO DO.
750        2.2: again 2013 in the definition is an error IMO.
752(See above.)
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.
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).
765        2.3: Just to note that this defintion is fine!
767        2.3.x: again you seem to be just dealing with territory
768        here but I guess this could be useful
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.
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.
781        4.1 says you're not defining classes, but then 4.2 seems to
782        do exactly that, which I find confusing.
784(we are not defining classes for 4.1)
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.
794E∞ isn’t ASCII, so E9?
796        - table 4: Sn as classes is a terrible choice since it
797        conflicts with existing sleep state terminology for ACPI.
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.)
808           [1]
810        Ted Lemon
812*       Comment (2013-08-14)
814           Maybe the term is
815           best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI].
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.
821True. Removed "Best", but left the existing usage in.
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?
828Class 0.  But the real world chips correlate a lot here, as they are
829designed to be useful for a class of applications.
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.
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.)
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.