Home Automation Routing Requirements in Low-Power and Lossy Networks
draft-ietf-roll-home-routing-reqs-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-16
|
11 | (System) | Changed document authors from "Jakob Buron, Anders Brandt" to "Jakob Buron, Anders Brandt, Giorgio Porcu" |
2015-10-14
|
11 | (System) | Notify list changed from roll-chairs@ietf.org, draft-ietf-roll-home-routing-reqs@ietf.org to (None) |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Ross Callon |
2010-04-06
|
11 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2010-04-06
|
11 | Cindy Morgan | [Note]: 'RFC 5826' added by Cindy Morgan |
2010-04-06
|
11 | (System) | RFC published |
2010-01-28
|
11 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-01-20
|
11 | (System) | IANA Action state changed to No IC from In Progress |
2010-01-20
|
11 | (System) | IANA Action state changed to In Progress |
2010-01-19
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-01-19
|
11 | Amy Vezza | IESG has approved the document |
2010-01-19
|
11 | Amy Vezza | Closed "Approve" ballot |
2010-01-19
|
11 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2010-01-15
|
11 | Robert Sparks | [Ballot comment] The prose frequently assumes radio-based wireless. The charter for the group calls out other technologies. Is it possible that some requirements motivated by … [Ballot comment] The prose frequently assumes radio-based wireless. The charter for the group calls out other technologies. Is it possible that some requirements motivated by those other technologies have been missed? You might want to consider devices like robot-vacuum cleaners as nodes that can be both transmitters and receivers that will be highly portable. (Pasi captured this better in his discuss, but this was already written so I'm leaving it here to inform that conversation). Has the group begun to explore the conflict between the authentication requirements in the security consideration section and the zero-configuration for access requirements earlier in the document? If so, capturing some of that discussion would be helpful. If not, there may be related requirements that the group hasn't uncovered yet. ---- Old DISCUSS text downgraded to Comments ---- I support Lars' discuss regarding requirements on applications vs requirements on the routing protocol. There are several constants presented as requirements without motivation. Where did the .5 second, 2 second, and 4 second convergence times come from? Why is the receiver-moved-only requirement in 3.2 separated in the text from the sender-moved-only requirement in 3.6? What is section 4 informing? If it is truly necessary, then many of the claims (frequency of switch/remote use, frequency of sensor reporting) needs to point to some reference for authority. The end of that section also makes some claims about mechanism ("typically as UDP" for example) that are out of place. Can the section be deleted? The paragraph motivating "MUST support 250 devices" is not persuasive (plugs and switches are not inherently going to be low-power nodes). What led to the choice of this particular constant? |
2010-01-15
|
11 | Robert Sparks | [Ballot discuss] |
2010-01-15
|
11 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks |
2010-01-15
|
11 | Ross Callon | [Ballot Position Update] Position for Ross Callon has been changed to No Objection from Discuss by Ross Callon |
2010-01-15
|
11 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2010-01-14
|
11 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
2010-01-14
|
11 | Cullen Jennings | [Ballot comment] |
2010-01-14
|
11 | Cullen Jennings | [Ballot discuss] Glad to see this doc - I'm very keen on this work and look forward to being able to use it. Few issues … [Ballot discuss] Glad to see this doc - I'm very keen on this work and look forward to being able to use it. Few issues that if we can resolve them now as requirements, I think will help get the protocol work done faster. |
2010-01-14
|
11 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2010-01-13
|
11 | (System) | New version available: draft-ietf-roll-home-routing-reqs-11.txt |
2010-01-06
|
10 | (System) | New version available: draft-ietf-roll-home-routing-reqs-10.txt |
2009-12-01
|
11 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-11-30
|
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-11-30
|
09 | (System) | New version available: draft-ietf-roll-home-routing-reqs-09.txt |
2009-10-08
|
11 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2009-10-08
|
11 | Tim Polk | [Ballot comment] I share Pasi's and Cullen's discuss regarding the disconnect between security requirements and zero configuration requirements. |
2009-10-08
|
11 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2009-10-08
|
11 | Ross Callon | [Ballot discuss] I have two questions with section 3.4 which discusses Healthcare Routing, and an overall issue. To me it seems like an error for … [Ballot discuss] I have two questions with section 3.4 which discusses Healthcare Routing, and an overall issue. To me it seems like an error for the routers, or the routing layer, to know that a particular packet is specifically related to Health Care. Are routers also going to know separately about financial data, fire alarms, burgular alarms, and other high-priority classes of packets? It certainly would make good sense for the routers to know that a particular packet is high priority and really must get through (even if delayed), whereas another packet is lower priority. It also would make sense for routers to know that some packets if delayed might as well be discarded, while other packets if delayed should be stored and delivered when possible. This seems like a sensible application of diff serve. I think that this whole section needs to be re-thought. As one example of how this might be reconsidered, the sentence "the routing protocol MUST deliver a health-care related message" might better be written "the routing protocol MUST deliver a packet that is marked with the diff serve class "high priority, don't discard". Also, the next paragraph "The routing protocol SHOULD support acknowledged transmission". Again this is mixing layers. The routing protocol MUST support bi-directional traffic. The way in which the transport layer or the applications make use of the network SHOULD (or MUST?) allow acknowledgment of data packets in cases where reliable delivery is needed. My overall issue is that this document seems to imply a major shift in the architecture away from a model where the routers deliver packets, which some knowledge of the QoS requirements of the packets, to an architecture where the routers know about what each application is. On the one hand this would seem to be a serious limitation on the potential future uses of the network, and the home seems like one place where there are potentially huge numbers of possible future uses. Also, if we are going to make this major architectural shift, then there should be some explicit discussion of it. |
2009-10-08
|
11 | Ross Callon | [Ballot Position Update] New position, Discuss, has been recorded by Ross Callon |
2009-10-08
|
11 | Jari Arkko | [Ballot comment] > Unlike other categories of Personal Area Networks (PANs), the > connected home area is very much consumer-oriented. Surely this is not true. … [Ballot comment] > Unlike other categories of Personal Area Networks (PANs), the > connected home area is very much consumer-oriented. Surely this is not true. I think most sports performance measurement gear, phone & music player, etc. applications are very consumer oriented. Perhaps you meant to say that other ROLL areas (like industrial plant monitoring) are less consumer oriented than home and PAN areas. > One event may cause many actuators to be activated at the same > time. > Using the direct analogy to an electronic car key, a house owner > may activate the "leaving home" function from an electronic house > key, mobile phone, etc. For the sake of visual impression, all > lights should turn off at the same time. At least, it should > appear to happen at the same time. A well-known problem in > wireless home automation is the "popcorn effect": Lamps are turned > on one at a time, at a rate so slow that it is clearly visible. I am wondering what value this paragraph adds. This may be a well known problem, but it is certainly one of poor implementation and/or choice of L2. I have a very hard time seeing this being a problem due to routing, or even being a problem in a well design network. In particular when home networks are naturally quite limited in physical size, unlike factories or commercial buildings. > If assignment of unique addresses is performed by a central > controller, it must be possible to route the inclusion request > from the joining node to the central controller before the joining > node has been included in the network. While this requirement is logical, I wonder to what extent it assumes that we somehow have to redo many of the basic building blocks and concepts that we have in IP networks. Does ROLL require something AUTOCONF-like? I would certainly hope that we can still have subnets and the basics of IP addressing stay the same, and that things like DHCP and DHCP relays work. > In contrast to other applications, e.g. industrial sensors, where > data would mainly be originated by a sensor to a sink and vice > versa, this scenario implicates a direct inter-device > communication between ROLL devices. I'm not convinced that the home network is any more peer-to-peer driven than other environments. Most equipment that we have today is still centrally controlled, even if running on top of IP. |
2009-10-08
|
11 | Jari Arkko | [Ballot discuss] This is an important area and a document in this space is very welcome. That being said, I'm not sure what to think … [Ballot discuss] This is an important area and a document in this space is very welcome. That being said, I'm not sure what to think of this document. If I had written a document on this topic, it would probably say very different things. I realize what the charter of the ROLL WG is, but the biggest problem this document has is its high focus on the routing tools. There are plenty of issues in building home networks like this, and one has to find the right architecture and right tools to solve the issues. This document goes too far in my opinion as positioning routing protocols as the solution for some of the problems. Application layer mechanisms for instance may be far more appropriate for some things. This is not to say that there are no routing related requirements in wireless ad hoc home networks. But the requirements seems relatively easy: - must support self-organized routing setup for a few dozen networks and few hundred devices - must support QoS based routing and forwarding - must support capability/constraint based routing So I would suggest that the document be shortened to address my Discuss. Some specific comments below. > The routing protocol MUST provide mobility with convergence time > below 0.5 second if only the sender has moved. > > The routing protocol MUST provide mobility with convergence time > below 4 seconds if the receiver has moved. This presumes a particular solution to mobility, i.e., doing it at the routing layer. It is not clear that this would be the right solution. I would probably personally employ a BAN and a cellular/WLAN uplink from my phone which would solve the problem at L2, or an application layer solution that would require nothing from the routing layer and would work well in any existing network. > A controller sending commands to a sleeping actuator > node via ROLL devices will have no problems delivering the packet > to the nearest powered router, but that router may experience a > delay until the next wake-up time before the command can be > delivered. > > Sleeping nodes may appear to be non-responsive. The routing > protocol MUST take into account the delivery time to a sleeping > target node. Hmm. I wonder what the real effect to the routing protocol is. I am absolutely certain that application, transport, layer 2, and even IP forwarding/queuing techniques change dramatically because of this. But as far as I can tell, doesn't routing stay unaffected? > The routing protocol SHOULD support acknowledged transmission. If > the routing protocol does not support acknowledged transmission, > some higher-layer transport protocol or application MUST ensure > delivery of such messages. Maybe I am misreading the first sentence, but I hope we are not somehow changing the IP model or forwarding because of ROLL requirements. IP should deliver packets, unreliably. Routing should find out what the best and most reliable path is. Link layers that are inherently very unreliable may increase their reliability by proper MAC design (and e.g., L2 acknowledgements). But I'm not sure what all this has to do with routing... |
2009-10-08
|
11 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2009-10-07
|
11 | Cullen Jennings | [Ballot comment] What's the requirement to use V6 on a network with 250 devices? The message with a 5 byte payload will take substantial longer … [Ballot comment] What's the requirement to use V6 on a network with 250 devices? The message with a 5 byte payload will take substantial longer and more power to transmit than if one used v4. I realize the HC is designed to solve that problem but it seems like it is layer complexity on top of complexity. I suspect you have the wrong "Status of memo boilerplate". You want the one that has "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008." |
2009-10-07
|
11 | Cullen Jennings | [Ballot discuss] Glad to see this doc - I'm very keen on this work and look forward to being able to use it. Few issues … [Ballot discuss] Glad to see this doc - I'm very keen on this work and look forward to being able to use it. Few issues that if we can resolve them now as requirements, I think will help get the protocol work done faster. I'm not comfortable with the discussion of Health Care messages and specifically: If possible at all, the routing protocol MUST deliver a health- care related message. I would like the requirements to make it clear if the requirement is to support safety critical messages or not. I have no problem with two (or more) levels of QoS where one has a better change of being delivered than the others but if this is going to specify enough to support safety critical messages, it needs to be crisp about the requirements that entails. I don't think I understand what you mean by the following requirement. The routing protocol SHOULD support acknowledged transmission. The way I read this, I would say that IP does not provide that, but an application on top could. And SHOULD in requirements are pretty confusing to start with. Can you rephrase this requirement to be more concrete as a requirement and less of a solution? Could you put more about the requirements around security and zero configuration of adding new elements. It must be secure, but new elements can automatically add themselves and disrupt routing seems contradictory. I also wonder about about how message integrity and zero conf enrollment will work. I think it is possible to come up with a set of requirements that represent a reasonable balance here. Making it really easy to add or replace devices to the network, while still maintaining security, seems to be the key part of this system but seems both underspecified in the draft while at the same time being over constrained. Surely the alarm system case must impose some security requirements. |
2009-10-07
|
11 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2009-10-07
|
11 | Robert Sparks | [Ballot comment] The prose frequently assumes radio-based wireless. The charter for the group calls out other technologies. Is it possible that some requirements motivated by … [Ballot comment] The prose frequently assumes radio-based wireless. The charter for the group calls out other technologies. Is it possible that some requirements motivated by those other technologies have been missed? You might want to consider devices like robot-vacuum cleaners as nodes that can be both transmitters and receivers that will be highly portable. (Pasi captured this better in his discuss, but this was already written so I'm leaving it here to inform that conversation). Has the group begun to explore the conflict between the authentication requirements in the security consideration section and the zero-configuration for access requirements earlier in the document? If so, capturing some of that discussion would be helpful. If not, there may be related requirements that the group hasn't uncovered yet. |
2009-10-07
|
11 | Robert Sparks | [Ballot discuss] DISCUSS I support Lars' discuss regarding requirements on applications vs requirements on the routing protocol. There are several constants presented as requirements without … [Ballot discuss] DISCUSS I support Lars' discuss regarding requirements on applications vs requirements on the routing protocol. There are several constants presented as requirements without motivation. Where did the .5 second, 2 second, and 4 second convergence times come from? Why is the receiver-moved-only requirement in 3.2 separated in the text from the sender-moved-only requirement in 3.6? What is section 4 informing? If it is truly necessary, then many of the claims (frequency of switch/remote use, frequency of sensor reporting) needs to point to some reference for authority. The end of that section also makes some claims about mechanism ("typically as UDP" for example) that are out of place. Can the section be deleted? The paragraph motivating "MUST support 250 devices" is not persuasive (plugs and switches are not inherently going to be low-power nodes). What led to the choice of this particular constant? |
2009-10-07
|
11 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks |
2009-10-07
|
11 | Lars Eggert | [Ballot comment] Section 3.2., paragraph 4: > The routing protocol MUST provide mobility with convergence time > below 0.5 second if only the … [Ballot comment] Section 3.2., paragraph 4: > The routing protocol MUST provide mobility with convergence time > below 0.5 second if only the sender has moved. There's an unstated assumption here regarding the size/diameter of the network. You might want to point to Section 3.5 here. Section 3.8., paragraph 1: > The routing protocol MUST support the ability to isolate a > misbehaving node thus preserving the correct operation of the > overall network. > In other words, if a node is found to fail often compared to the > rest of the network, this node should not be the first choice for > routing of traffic. At least to me, the second paragraph isn't talking about the same thing as the first paragraph. The first one says "never use", the second says "not prefer." Section 2.1., paragraph 3: > acknowledged singlecast messages to each device. Nit: s/singlecast/unicast/ (?) |
2009-10-07
|
11 | Lars Eggert | [Ballot discuss] Section 3.4., paragraph 3: > If possible at all, the routing protocol MUST deliver a health- > care related message. It … [Ballot discuss] Section 3.4., paragraph 3: > If possible at all, the routing protocol MUST deliver a health- > care related message. It is NOT a requirement that such message is > delivered in less than a second. > The routing protocol SHOULD support acknowledged transmission. If > the routing protocol does not support acknowledged transmission, > some higher-layer transport protocol or application MUST ensure > delivery of such messages. DISCUSS: I may be misunderstanding something, but why is reliable delivery of healthcare *application* data something that the *routing* protocol needs to do? If end-to-end reliability is required, the app or app protocol needs to be involved anyway. Clearly routing can aid this by providing paths to such apps that are more stable, but that's about it, no? |
2009-10-07
|
11 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2009-10-06
|
11 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2009-10-06
|
11 | Alexey Melnikov | [Ballot comment] I am supporting Pasi's DISCUSS about conflict of zero-configuration with security. 3.5. Scalability Looking at the number of wall switches, power outlets, … [Ballot comment] I am supporting Pasi's DISCUSS about conflict of zero-configuration with security. 3.5. Scalability Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of low power devices may form a home automation network in a fully populated "smart" home. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol MUST support 250 devices in the network. Should this be "... MUST support at least 250 devices ...". And to use Chris Newman's trick: why not say 257? |
2009-10-06
|
11 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-10-06
|
11 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-roll-home-routing-reqs-08, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document: - The … [Ballot discuss] I have reviewed draft-ietf-roll-home-routing-reqs-08, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document: - The last paragraph of Section 3.4 seems to suggest that the routing protocol could deliver acknowledgements to applications about whether an IP packet was delivered or not (but this is more forwarding than routing thing anyway). I think I'm probably misunderstanding this text, and the intent was to say something else. But what exactly? - Sections 3.7 and 5 seem to have conflicting requirements about security and zero-configuration (adding a new node to the network without any human intervention is pretty hard to combine with the requirement to keep unwanted nodes out). - It looks like [I-D.Hui-HeaderCompression] should be an informative reference, not normative. |
2009-10-06
|
11 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2009-10-06
|
11 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2009-09-20
|
11 | Adrian Farrel | [Note]: 'JP Vasseur (jvasseur@cisco.com) is the document shepherd' added by Adrian Farrel |
2009-09-20
|
11 | Adrian Farrel | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Adrian Farrel |
2009-09-20
|
11 | Adrian Farrel | Telechat date was changed to 2009-10-08 from by Adrian Farrel |
2009-09-20
|
11 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2009-09-20
|
11 | Adrian Farrel | Ballot has been issued by Adrian Farrel |
2009-09-20
|
11 | Adrian Farrel | Created "Approve" ballot |
2009-09-20
|
11 | Adrian Farrel | Placed on agenda for telechat - 2009-10-08 by Adrian Farrel |
2009-09-16
|
08 | (System) | New version available: draft-ietf-roll-home-routing-reqs-08.txt |
2009-09-14
|
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-09-14
|
07 | (System) | New version available: draft-ietf-roll-home-routing-reqs-07.txt |
2009-04-29
|
11 | Adrian Farrel | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from AD Evaluation::Revised ID Needed by Adrian Farrel |
2009-04-29
|
11 | Adrian Farrel | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Adrian Farrel |
2009-04-19
|
11 | Adrian Farrel | State Changes to AD Evaluation from Waiting for AD Go-Ahead by Adrian Farrel |
2009-04-02
|
11 | Adrian Farrel | Responsible AD has been changed to Adrian Farrel from David Ward |
2009-02-19
|
11 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Alan DeKok. |
2008-12-24
|
11 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-12-19
|
11 | Amanda Baber | IANA Last Call comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2008-12-13
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2008-12-13
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2008-12-10
|
11 | Amy Vezza | Last call sent |
2008-12-10
|
11 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-12-10
|
11 | David Ward | State Changes to Last Call Requested from Publication Requested by David Ward |
2008-12-10
|
11 | David Ward | Last Call was requested by David Ward |
2008-12-10
|
11 | (System) | Ballot writeup text was added |
2008-12-10
|
11 | (System) | Last call text was added |
2008-12-10
|
11 | (System) | Ballot approval text was added |
2008-11-20
|
11 | Cindy Morgan | Proto-write-up for draft-ietf-roll-home-routing-reqs-06 Intended status : Informational Track > (1.a) Who is the Document Shepherd for this document? Has the > Document … Proto-write-up for draft-ietf-roll-home-routing-reqs-06 Intended status : Informational Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? JP Vasseur is the document shepherd. He has personally reviewed the document and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The I-D has been discussed and reviewed by the Working group. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues 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. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. > (1.e) 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? Good consensus. > (1.f) 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 > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? Checks have been made. No Errors. > (1.h) Has the document split its references into normative and > informative? 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 > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? No IANA action. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) 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 > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Basic home control modules such as wall switches and plug-in modules may be turned into an advanced home automation solution via the use of an IP-enabled application responding to events generated by wall switches, motion sensors, light sensors, rain sensors, and so on. Network nodes may be sensors and actuators at the same time. An example is a wall switch for replacement in existing buildings. The push buttons may generate events for a controller node or for activating other actuator nodes. At the same time, a built-in relay may act as actuator for a controller or other remote sensors. Because ROLL nodes only cover a limited radio range, routing is often required. These devices are usually highly constrained in term of resources such as battery and memory and operate in unstable environments. Persons moving around in a house, opening or closing a door or starting a microwave oven affect the reception of weak radio signals. Reflection and absorption may cause a reliable radio link to turn unreliable for a period of time and then being reusable again, thus the term "lossy". Unlike other categories of PANs, the connected home area is very much consumer-oriented. The implication on network nodes is that devices are very cost sensitive, which leads to resource- constrained environments having slow CPUs and small memory footprints. At the same time, nodes have to be physically small which puts a limit to the physical size of the battery; and thus, the battery capacity. As a result, it is common for low-power sensor-style nodes to shut down radio and CPU resources for most of the time. The radio tends to use the same power for listening as for transmitting Section 2 describes a few typical use cases for home automation applications. Section 3 discusses the routing requirements for networks comprising such constrained devices in a home network environment. These requirements may be overlapping requirements derived from other application-specific routing requirements. A full list of requirements documents may be found in the end of the document. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? No controversy. > 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? The I-D is informational and specifies routing requirements. |
2008-11-20
|
11 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2008-11-19
|
06 | (System) | New version available: draft-ietf-roll-home-routing-reqs-06.txt |
2008-11-19
|
05 | (System) | New version available: draft-ietf-roll-home-routing-reqs-05.txt |
2008-10-27
|
04 | (System) | New version available: draft-ietf-roll-home-routing-reqs-04.txt |
2008-09-11
|
03 | (System) | New version available: draft-ietf-roll-home-routing-reqs-03.txt |
2008-07-14
|
02 | (System) | New version available: draft-ietf-roll-home-routing-reqs-02.txt |
2008-07-07
|
01 | (System) | New version available: draft-ietf-roll-home-routing-reqs-01.txt |
2008-05-21
|
00 | (System) | New version available: draft-ietf-roll-home-routing-reqs-00.txt |