4 ms·
Security is incredibly important. If I give someone my WiFi password, I'd really rather they didn't have the ability to open/close my windows, turn off my heati
by CHY872 12y ago
Security is incredibly important. If I give someone my WiFi password, I'd really rather they didn't have the ability to open/close my windows, turn off my heating, turn on my lights etc. Introducing such a system to the consumer domain would be the most socially irresponsible thing Apple could do. Now when your kid downloads dodgy porn and gets a virus, you don't just get a slower computer demanding your cash, your central heating stops working pending payment!
So what you're saying is that you'd make a new version of BACnet to make it suitable? A new standard? Were I Apple, I'd refuse to let my devices connect to any insecure devices - it'd lead me open to many horrible 'I got a virus and it unlocked my door' online stories which would be horrible for business and stop the process in its tracks - and so the new standard would not be backwards compatible. So, if we had a new standard, there'd be loads of BACnet devices that did not support my stuff (consumer confusion), huge trouble negotiating the standard with all the current stakeholders, and a lot of cruft that I'd have to implement that I don't really want to implement (lift controls etc).
What I meant by the IPv6 comment was that consumer networks are switching to IPv6 at a high rate, and IPv6 only networks might become a reality in 10-15 years (with an external ISP 6to4). It's ok for businesses to stay on IPv4, but most in the consumer space use their ISP provided routers. In this case, we'd likely see large incompatibilities with most of the BACnet devices - we'd end up with this weird split standard.
In this case, we have this interesting situation where we have many BACnet branded devices, but only a few are relevant for the average consumer.
The reason that home users have ethernet and IP is because of the hourglass model. The reason that most services just work is that they talk TCP/UDP - anything below that they can ignore - so if we use a new hardware layer, if we use FDDI etc we can still use TCP because everything talks in IP. BACnet kinda breaks that - you mentioned ZigBee adding BACnet support - ZigBee has supported IP for ages - had BACnet followed the hourglass model (as literally every other internet service I have ever seen has done) then support for BACnet would have been immediate and unnecessary to trumpet.
Re overkill - again, it's about the hourglass principle. http://named-data.net/wp-content/uploads/hourglass.png http://named-data.net/wp-content/uploads/hourglass.png - the idea is that we all achieve massive interoperability by using IP. BACnet doesn't quite fit into that, mostly because it replaces IP for (as I understand it) no particularly good reason.
You want standards when you have a mature market and you want to prevent lockin. Standards in an emerging market can lead to stagnation and reduced innovation, as each change must be agreed by the stakeholders (who might have opposing visions) - like what happened with OAuth 2.0. This is why (say) new programming languages typically have a few years of backwards incompatibilities before they get standardised.
- Frozenlock 12y agoYes, security is important. What I asked was if the BACnet layer should have its own security, or if we should rely on the network security. (My router at home already gives me a 'guest' wifi with restricted access.) And no, by adding new stuff I don't mean a new standard. It's called an addendum. Which, I'm surprised I overlooked, some were made especially to address the security issues: http://www.bacnet.org/Addenda/ http://www.bacnet.org/Addenda/ If security really is a big issue, the LAST thing I want is give access to the secured network to my PHONE. Is your phone secure? Would you store your bitcoins on it? The reason that home users have ethernet and IP is because of the hourglass model. The reason that most services just work is that they talk TCP/UDP - anything below that they can ignore - so if we use a new hardware layer, if we use FDDI etc we can still use TCP because everything talks in IP. BACnet kinda breaks that - you mentioned ZigBee adding BACnet support - ZigBee has supported IP for ages - had BACnet followed the hourglass model (as literally every other internet service I have ever seen has done) then support for BACnet would have been immediate and unnecessary to trumpet. And by supporting IP, it was also (indirectly) supporting BACnet. You just explained how services using TCP/UDP could ignore everything below... I don't understand why you don't understand it's the same thing for BACnet. Those 'official' transport layers offer you alternatives. But guess what, by supporting Ethernet and IP, BACnet can already use pretty much all the network architecture around.. BACnet doesn't quite fit into that, mostly because it replaces IP for (as I understand it) no particularly good reason. Ok, this might be the source of the confusion. Yes, the BACnet network layer needed to be defined, because at the time IP wasn't everywhere like it is today. BUT, you can easily embed this into other protocols. That's exactly how you talk about your hourglass model: BACnet devices don't care if they are connected by MS/TP, Ethernet, IP, Arcnet... They just look at the BACnet level. Just like many services look at the TCP level, not at the IP or Ethernet level. About IPv6 for new networks, if they become required, I see no real obstacle into extending the standard for IPv6. IPv6 is itself an example of a standard changing with time. Would you prefer to throw away IP a start from scratch because IPv4 devices might not be able to communicate with IPv6? You want standards when you have a mature market and you want to prevent lockin. Standards in an emerging market can lead to stagnation and reduced innovation(...) But why do you consider the consumer domain to be an emerging market? For all intended purposes, you still have lighting, HVAC, access... those all already exist in bigger organizations! There's nothing new here!