Terminology for Constrained-Node Networks
draft-ietf-lwig-terminology-07
Yes
(Brian Haberman)
(Richard Barnes)
No Objection
(Martin Stiemerling)
(Sean Turner)
Abstain
Note: This ballot was opened for revision 05 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -05)
Unknown
Jari Arkko Former IESG member
Yes
Yes
(2013-08-13 for -05)
Unknown
Thanks for writing this useful document. A couple of comments that you may consider: 1) In my experience, power/memory/cpu are important considerations, but equally often user interface and deployment considerations are the cause of even more constraints or challenges. E.g., ability to set keys, update software, etc. Perhaps these kinds of limitations could be listed as well. 2) I agree with other ADs that tying the definitions to 2013 state of the world may not be useful. 3) I found the below comments from Suresh Krishnan's Gen-ART review useful. In particular, I'd not limit constrained devices to sensors. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-lwig-terminology-05.txt Reviewer: Suresh Krishnan Review Date: 2013/08/12 IESG Telechat date: 2013/08/15 Summary: This draft is ready for publication as an Informational RFC but I do have a few comments that the authors may wish to consider. Minor ===== * Section 1 Aren't actuators also one class of constrained devices? The section talks about gathering information but does not talk about constrained devices acting on information. * Section 2.1 When speaking about the multiple facets of constraints on the nodes shouldn't processing power be included as well? There is an item for power but it is unclear if that means energy/power or processing power. In either case one of them probably needs to be added. * Section 2.2 Would it be worth mentioning the asymmetric nature of some of these link as a constraint? * Section 2.3.1 This sentence does not read right. Suggest rewording. OLD: In its terminology document, the ROLL working group is saying [I-D.ietf-roll-terminology]: NEW: The ROLL terminology document [I-D.ietf-roll-terminology] defines LLNs as follows: * Section 3 Please add a reference to the CoAP draft at first use of CoAP. * Section 4.3 Should this section also talk a bit about the term "duty cycle" since this term is used frequently in the constrained device context? Thanks Suresh
Richard Barnes Former IESG member
Yes
Yes
(for -05)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2013-08-09 for -05)
Unknown
I'm a Yes, and think this document is in good shape and worth publishing at version -05. That said, I am sensitive to Barry's point about "constrained" not being the same as "constrained in 2013". If I wasn't looking at this document for the first time at the end of the process, I probably would have asked how useful Table 1 really is, because what matters isn't whether you have 100 KiB of flash memory, it's what you have enough flash memory to do. So, not based on physical characteristics, but on functional characteristics - and the distinctions based on functional characteristics are well-described in the paragraphs that follow Table 1. What I was thinking, was more like "there are three classes of devices, and you know you have a Class 0 device when it's too constrained to communicate directly with the Internet ..." But unless people think that's helpful ... ship it.
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2014-02-12)
Unknown
Thanks to the authors for a long road to addressing my Discuss. I am left with one point that I will not hold the document on. There is a statement that constrained nodes do not have the characteristics of network nodes to which we have become accustomed. I see a distinction between "constraints" and "characteristics". It is quite clear to me that a constraint might limit the behavior and that might remove a characteristic that we have previously been used to. But that does not mean they are the same thing. Characteristics (I am guessing) would be things like "ability to process messages at line speed" or "ability to buffer messages" etc. It would be really nice if the document gave a few examples of the characteristics that constrained nodes might not have.
Barry Leiba Former IESG member
No Objection
No Objection
(2013-07-09 for -05)
Unknown
Do we really want to tie the general definitions of "constrained [thing]" (in Sections 2.1 and 2.2) to 2013? I wouldn't think so. It makes sense to say that the numbers in Table 1 represent constraint levels in 2013, but whether something is a constrained node or not should be relative to when the evaluation is being made, not relative to 2013, no?
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2013-08-14 for -05)
Unknown
Maybe the term is best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI]. This doesn't actually make sense—why does "area" belong in this sentence, given that no statement as to the size of the area is given? I would suggest deleting this sentence. In Table 1, are the column's or'd or anded? That is, for example, is a C0 device a device that either has <<10k of RAM or <<100k of code? Or a device that has both <<10k or RAM _and_ <<100k of code? Is a device with 10k of RAM and 10k of code a C0 or a C1 device? In Table 3, "mains powered" is a regional name, which likely will not be understood by all readers. I notice that "mains power" is used elsewhere in the document; it might be good to define it somewhere. I realize that this may sound very nit-picky, but you never know who is going to be reading the document. I think it would be obvious to me in context, even if I hadn't heard the term before, what the term means, but I am unsure enough that it would be obvious to any reader that I think it's worth defining the term. Other than that, the document looks good. I think a lot of IETFers could benefit from reading this document, because these terms have been coming up in conversation quite a bit recently. For example, I heard "LLN" a lot long before I learned what it stood for, and I have since used it on people who responded by saying "what's an LLN." :)
Joel Jaeggli Former IESG member
Abstain
Abstain
(2013-08-13 for -05)
Unknown
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.
Stephen Farrell Former IESG member
(was Discuss)
Abstain
Abstain
(2014-01-05 for -06)
Unknown
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