Building Automation Routing Requirements in Low-Power and Lossy Networks
RFC 5867

Note: This ballot was opened for revision 09 and is now closed.

(Adrian Farrel; former steering group member) (was Discuss, Yes) Yes

Yes (2009-09-22)
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2010-01-15)
No email
send info
The empty lines in Figure 1 make the viewing the picture hard.

> Fire systems are much more uniformly installed with smoke detectors
> installed about every 50 feet.

The rules on this are variable, but I have actually not come across
a distance metric. Typically, there is a requirement to have at least
one detector per floor per firewalled area, or even one per room.

> These cameras are atypical
> endpoints requiring upwards to 1 megabit/second (Mbit/s) data rates
> per camera as contrasted by the few Kbits/s needed by most other FMS
> sensing equipment.

The deployment models differ again, though. Some devices operate in
motion detection mode, others stream continuously, and yet others
operate as web servers and are used on a per need basis.

> A ten minute power outage may require many hours to regain building
> control.  Traffic flow may increase ten-fold until the building
> control stabilizes.

I wish it were made clearer that this is an undesirable state of
affairs.


> Typically, sensor battery life (2000mah) needs to extend for at least
> 5 years when the device is transmitting its data (200 octets) once
> per minute over a low power transceiver (25ma) and expecting a
> application acknowledgement.  This requires a highly efficient
> routing protocol that minimizes hops and hence latency in end-to-end
> communication.  The routing protocol MUST take into account node
> properties such as 'Low-powered node' which produce efficient low
> latency routes that minimize radio 'on' time for these devices.

There are of course wireless sensors in a building network. However,
I have serious trouble believing that the router nodes need to be
in this mode. Does this requirement mean that the routers have to
save power for themselves (which would be a major research project)
or merely that small or at least predictable latency would save
energy for hosts? Please clarify.

(Magnus Westerlund; former steering group member) No Objection

No Objection (2009-09-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Agree with Russ that the security requirements seems backwards. To me it appears that the protocol MUST have authentication, but it may not be used for specific reasons. However, I don't want to be in a building that deploys these systems without a security model. Especially if you they are using wireless communication.

(Pasi Eronen; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) (was Discuss) No Objection

No Objection (2009-09-22)
No email
send info
Adrian's Discuss points to feedback I provided to version -05 of this document. Please consider the points in that review that aren't also called out in Discuss a "Comment".

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was No Record, No Objection) No Objection

No Objection (2009-09-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info