Terminology for Constrained-Node Networks
draft-ietf-lwig-terminology-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-05-12
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-04-30
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-04-18
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-02-21
|
07 | (System) | IANA Action state changed to No IC from In Progress |
2014-02-21
|
07 | (System) | IANA Action state changed to In Progress |
2014-02-21
|
07 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-02-21
|
07 | (System) | RFC Editor state changed to EDIT |
2014-02-21
|
07 | (System) | Announcement was received by RFC Editor |
2014-02-21
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-02-21
|
07 | Amy Vezza | IESG has approved the document |
2014-02-21
|
07 | Amy Vezza | Closed "Approve" ballot |
2014-02-21
|
07 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2014-02-21
|
07 | Brian Haberman | Ballot writeup was changed |
2014-02-21
|
07 | Brian Haberman | Ballot approval text was generated |
2014-02-21
|
07 | Brian Haberman | Changed consensus to Yes from Unknown |
2014-02-12
|
07 | Adrian Farrel | [Ballot comment] Thanks to the authors for a long road to addressing my Discuss. I am left with one point that I will not hold … [Ballot comment] 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. |
2014-02-12
|
07 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-02-12
|
07 | Adrian Farrel | [Ballot comment] Thanks to th authors for a long road to addressing my Discuss. I am left with one point that I will not hold … [Ballot comment] Thanks to th 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. |
2014-02-12
|
07 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2014-02-10
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-02-10
|
07 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-07.txt |
2014-01-30
|
06 | Brian Haberman | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2014-01-05
|
06 | Stephen Farrell | [Ballot comment] 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 … [Ballot comment] 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 |
2014-01-05
|
06 | Stephen Farrell | Ballot comment text updated for Stephen Farrell |
2014-01-05
|
06 | Stephen Farrell | [Ballot comment] write-up: I slightly dislike being told that "experts from companies x, y & z" think something. Much better would be to have been … [Ballot comment] 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 |
2014-01-05
|
06 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to Abstain from Discuss |
2013-12-18
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-12-18
|
06 | Carsten Bormann | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-12-18
|
06 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-06.txt |
2013-11-05
|
05 | Brian Haberman | Document shepherd changed to Zhen Cao |
2013-10-03
|
05 | Suresh Krishnan | Request for Telechat review by GENART Completed: Ready. Reviewer: Suresh Krishnan. |
2013-08-15
|
05 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-08-15
|
05 | Stephen Farrell | [Ballot discuss] I have one discuss point, that I'll probably quickly clear when told the wg could rather not, and then I'll move to abstain. … [Ballot discuss] I have one discuss point, that I'll probably quickly clear when told the wg could rather not, and then I'll move to abstain. My discuss is: I think we're missing an opportunity here to do much better than this and could do so if this document were re-worked with the goal of making the text be such that it would likely still be useful in 5 years time. Would the WG like to do that? Assuming the answer will be "no, thanks" then I'll move to an abstain since I think that's unfortunate, and very little, but some, harm will ensue, in terms of confusion when these terms are used in the not too distant future. I'm happy discuss my comments of course, in any case, but really handling many of them would only make sense if the wg wanted to re-do this, so if I do end up abstaining, it'll be entirely fine to pretty much ignore my comments:-) |
2013-08-15
|
05 | Stephen Farrell | [Ballot comment] write-up: I slightly dislike being told that "experts from companies x, y & z" think something. Much better would be to have been … [Ballot comment] 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 |
2013-08-15
|
05 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-08-14
|
05 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to Abstain from No Record |
2013-08-14
|
05 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-08-14
|
05 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-08-14
|
05 | Ted Lemon | [Ballot comment] Maybe the term is best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI]. This doesn't actually make sense—why does "area" belong … [Ballot comment] 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." :) |
2013-08-14
|
05 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-08-13
|
05 | Joel Jaeggli | [Ballot comment] mostly this is an observation, I am however curious how this is addressed? I have a lot of trouble with section 2 discussion … [Ballot comment] 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. |
2013-08-13
|
05 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-08-13
|
05 | Joel Jaeggli | [Ballot comment] mostly this is an observation, I am however curious how this is addressed? I have a lot of trouble with section 2 discussion … [Ballot comment] 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 mentione dlate in otehr places. |
2013-08-13
|
05 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-08-13
|
05 | Joel Jaeggli | [Ballot comment] mostly this is an observation, I am however curious how this is addressed? I have a lot of trouble with section 2 discussion … [Ballot comment] 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. |
2013-08-13
|
05 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-08-13
|
05 | Adrian Farrel | [Ballot discuss] I have struggled hard in my review of this document, and Brian Habermann has helped me a lot with understanding the value and … [Ballot discuss] I have struggled hard in my review of this document, and Brian Habermann has helped me a lot with understanding the value and purpose of the work. In my Discuss, below, I have tried to list actionable work that I feel is necessary for the publication of this document as a definition of terminology, and I have pushed out to my Comment other issues that I think would be good to fix but which are not blocking. Before reading and attempting to resolve the Discuss issues, the authors might like to consider whether this document could be re- positioned as "A Discussion of Some Concept in Constrained Networks". I believe that this re-branding complete with a few minor tweaks to the text to be consistent would pretty much defuse most of my Discuss comments (except, perhaps some on the Abstract and Section 2.3.1). --- The Abstract is confusing in that it introduces a "small device with severe constraints" and uses it to define a "constrained node network", but never says what a "constraint" is. It then goes on to use the term "constrained environment" without explaining what this means. I think that the Abstract could give several examples of constraint for a node (memory, CPU, power). It could also replace "constrained environment" (which is not used in the rest of the document - except in a similar paragraph in the Introduction) with "constrained network" together with a mention that links may also be constrained, and some examples of link constraints. --- Section 2.1 I agree that the definition of Constrained Node "is less than satisfying." Indeed, I think that the definition you provide is useless as a definition. I find it odd that the definition includes the reasons why the node is different, but not a list of the ways it might be different. some of the characteristics that are otherwise pretty much taken for granted for Internet nodes in 2013 ...is so vague and unscoped. Of course, the text that follows does list some of the constraints and these are helpful to an understanding of the definition. Probably the best way to handle this is to turn the whole section into prose and dispense with the formal definition that isn't. The same problem exists in Section 2.2. [These concerns are consistent with my suggestion to back away from providing definitions, and to offer a discussion of concepts instead.] --- Section 2.3.1 is full of issues. In common usage, LLN often stands for "the network characteristics that RPL has been designed for". Asides from being cryptic (or possibly sarcastic), that definition is so clearly circular as to be of no value. You could, instead stop after the quote from draft-ietf-roll-terminology. Also, please expand RPL and give a reference. LLNs do appear to have significant loss at the physical layer How do you mean "appear"? Do they or don't they? Actual "low power" does not seem to be required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences]. Again "seem to be". If you cannot provide a definition in this document then probably best to not try. The reference to [I-D.clausen-lln-rpl-experiences] in the discussion of scaling LLNs is curious. That document talks about experiences trying to scale RPL. It does not, as far as I can tell, discuss the size or scalability of a LLN. The ROLL terminology document states that LLNs typically are composed of constrained nodes; this is also supported by the design of operation modes such as RPL's "non-storing mode". So, in the terminology of the present document, an LLN seems to be a constrained node network with certain network characteristics, which include constraints on the network as well. What do you mean "is also supported by"? Are you saying that the composition of a network is defined by the widgits built into a protocol that runs over it? What do you mean "an LLN seems to be..." Can you not write a clear definition? --- Section 2.3.2 I don't see a definition in this section of either LoWPAN or 6LoWPAN. I only find a discussion of the expansion of the acronym. [Again, if the document is not seeking or claiming to provide definitions this is not a problem.] --- In Section 3, the description of a Class 0 node seems to be prejudging the work of LWIG. It is mixing what the physical capabilities of the node are (memory, CPU, power) with what the node will be capable of doing (using security). That is surely interesting and equally surely not part of the definition of the node class. Similar issues apply to the discussion of Class 1 and Class 2 nodes. [Yet again, if you are not defining but only discussing then this issue is much less pronounced.] --- Section 5 is missing some thoughts about the availability of security mechanisms in constrained devices. Since these are mentioned in Section 3, you can't duck them in Section 5. |
2013-08-13
|
05 | Adrian Farrel | [Ballot comment] In pulling terms and ideas from non-consensus documents, this document assigns the terms more weight than they actually have. For example, in 2.3.2... … [Ballot comment] In pulling terms and ideas from non-consensus documents, this document assigns the terms more weight than they actually have. For example, in 2.3.2... Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") is now also being used for networks built from similarly constrained link layer technologies [I-D.ietf-6lowpan-btle] [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz]. ...is undoubtedly correct, but implies that there is acceptance of this use of the term. I don't believe this document is supposed to be a survey of the way terms are used in works in progress, but is supposed to be a set of definitions to help future work. This can be handled by a small change in wording so that "is now also being used for" is replaced with "also refers to". --- Section 1 Small devices with limited CPU, memory, and power resources, so called constrained devices (also known as sensor, smart object, or smart device) can constitute a network, becoming "constrained nodes" in that network. Such a network may itself exhibit constraints, e.g. with unreliable or lossy channels, limited and unpredictable bandwidth, and a highly dynamic topology. I question "also known as..." A sensor, smart object, or smart device does not need to be constrained. A constrained device does not need to be a sensor, smart object, or smart device. It might be reasonable to say that "...many sensors, smart objects, and smart devices are constrained devices..." I think "constitute a network" is wrong. These constrained nodes may be included in a network, but do they constitute the network? Are the elements of constrained connectivity between nodes (nodes which may or may not themselves be constrained nodes) relevant to the work of LWIG? It is possible that the behavior of the data channels has an impact on the code and buffering needed in a node. If so, perhaps this could be drawn out more in the Introduction. --- Section 2 might be better named "Core Terminology" otherwise we wonder why other sections are not just subsections of section 2. --- I don't like "this field of work" (which field?) and "appears to be" (appears to whom?) in Section 2. Maybe you could give: There are two important aspects to scaling within the IoT: BTW, is underbar _really_ necessary? --- Section 4.1 Instead of defining classes or clusters, we propose simply stating, in SI units, an approximate value for one or both of the quantities listed in Table 2: You "propose"? You have moved beyond that. Now you "do". --- I am surprised that Ps is a useful measure. In my experience devices often operate power availability on a curve (usually a series of steps) as a function of remaining energy in the store. Thus devices that are running short of energy reduce the available power to try to eke out what is left. That would, of course, make the average an ambiguous measure. --- Section 4.3 I was amused by he term "Always Off". "Always" as in "except for the exceptions"? :-) --- In section 4.3 it would be useful to align with (or at least mention) the terms "sleepy node" and "non-sleepy node" as presented in draft-ietf-roll-terminology. |
2013-08-13
|
05 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2013-08-13
|
05 | Jari Arkko | [Ballot comment] 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 … [Ballot comment] 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 |
2013-08-13
|
05 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2013-08-09
|
05 | Spencer Dawkins | [Ballot comment] I'm a Yes, and think this document is in good shape and worth publishing at version -05. That said, I am sensitive to … [Ballot comment] 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. |
2013-08-09
|
05 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2013-08-08
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-08-08
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-08-08
|
05 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-07-09
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2013-07-09
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-07-09
|
05 | Barry Leiba | [Ballot comment] 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. … [Ballot comment] 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? |
2013-07-09
|
05 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-07-09
|
05 | Brian Haberman | Ballot has been issued |
2013-07-09
|
05 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2013-07-09
|
05 | Brian Haberman | Created "Approve" ballot |
2013-07-09
|
05 | Brian Haberman | Placed on agenda for telechat - 2013-08-15 |
2013-07-09
|
05 | Brian Haberman | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-07-09
|
05 | Brian Haberman | Ballot writeup was changed |
2013-07-09
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-07-09
|
05 | Carsten Bormann | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-07-09
|
05 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-05.txt |
2013-06-05
|
04 | Brian Haberman | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-06-05
|
04 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-05-30
|
04 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Ben Laurie. |
2013-05-29
|
04 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2013-05-29
|
04 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-lwig-terminology-04, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-lwig-terminology-04, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. If this assessment is not accurate, please respond as soon as possible. |
2013-05-23
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2013-05-23
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2013-05-23
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2013-05-23
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2013-05-22
|
04 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2013-05-22
|
04 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Terminology for Constrained Node Networks) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Terminology for Constrained Node Networks) to Informational RFC The IESG has received a request from the Light-Weight Implementation Guidance WG (lwig) to consider the following document: - 'Terminology for Constrained Node Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Internet Protocol Suite is increasingly used on small devices with severe constraints, creating constrained node networks. This document provides a number of basic terms that have turned out to be useful in the standardization work for constrained environments. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lwig-terminology/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lwig-terminology/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-05-22
|
04 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-05-22
|
04 | Brian Haberman | Last call was requested |
2013-05-22
|
04 | Brian Haberman | Last call announcement was generated |
2013-05-22
|
04 | Brian Haberman | Ballot approval text was generated |
2013-05-22
|
04 | Brian Haberman | Ballot writeup was generated |
2013-05-22
|
04 | Brian Haberman | State changed to Last Call Requested from AD Evaluation |
2013-05-21
|
04 | Brian Haberman | State changed to AD Evaluation from Publication Requested |
2013-05-20
|
04 | Amy Vezza | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. The document supplies terminology and is not a protocol specification. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The Internet Protocol Suite is increasingly used on small devices with severe constraints, creating constrained node networks. This document provides a number of basic terms that have turned out to be useful in the standardization work for constrained environments. Working Group Summary The document originally was extracted as a stable part of the LWIG guidance document that the WG considered to be immediately useful. After extraction, additional terminology was added on energy/power availability and usage. This document was finished collectively by a number of people who worked in the constrained network area. The WGLC was conducted on April 7 for two weeks. Five supports have been expressed on the mailing list, with positive discussion. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This is a document that summarizes the terminologies that has been and will be used for people and groups that are working on constrained networks. This is generally considered to be a useful document for people to refer when they would like to find the definition of certain terms. Experts from Philips, Orange, Ericsson reviewed the document, from the time when it still was an individual document. Several wording details in the draft before the WGLC had been discussed and the draft was updated to incorporate these changes. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Zhen Cao (caozhen@chinamobile.com) is the Document Shepherd. Brian Haberman is the Responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed the draft before its adoption as an IETF work. Three aspects were reviewed. First, the definitions and descriptions of the terminologies, for example, constrained networks and constrained node networks. Second, the classifications of different types of contrained devices, this section has reflected the discussion on the mailing list and now is used by many drafts. Third, some editorial changes had been posted to the mailing list and the document had been updated to accommodate the changes. . The document shepherd believes that this document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Document Shepherd thinks that the review within the group is thorough and comprehensive. While there is considerable overlap in people, explicit review has not yet been performed in other related groups, for example, core, roll, 6lowpan. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. NO. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. NO (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. YES (all three on Friday, April 26, 2013). (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. NO. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG understand and agree with it. During the WGLC, the WG received five messages from key participants from the group and all of them supported it moving forward. On several meetings before, the chairs asked for hum for support of its merits as a right directions, and clear conconsus was received. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) NO. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. NONE. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? YES. ALL are INFORMATIVE. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? NO. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. NO. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. NO. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). N/A (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. NO. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2013-05-20
|
04 | Amy Vezza | Note added 'Zhen Cao (caozhen@chinamobile.com) is the Document Shepherd.' |
2013-05-20
|
04 | Amy Vezza | Intended Status changed to Informational |
2013-05-20
|
04 | Amy Vezza | IESG process started in state Publication Requested |
2013-05-20
|
04 | (System) | Earlier history may be found in the Comment Log for draft-bormann-lwig-terms |
2013-05-20
|
04 | Zhen Cao | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2013-05-19
|
04 | Zhen Cao | Changed document writeup |
2013-04-23
|
04 | Zhen Cao | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2013-04-22
|
04 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-04.txt |
2013-03-31
|
03 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-03.txt |
2013-03-28
|
02 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-02.txt |
2013-02-25
|
01 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-01.txt |
2013-02-18
|
00 | Carsten Bormann | New version available: draft-ietf-lwig-terminology-00.txt |