> On 12 Feb 2016, at 17:14, Dan York <[email protected]> wrote: > > Dave, > >> On Feb 12, 2016, at 9:32 AM, Dave Crocker <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 2/11/2016 10:57 AM, Ted Lemon wrote: >>> To be fair, there is really no way at present for IoT vendors to >>> deliver service without running the data collection end, unless they >>> sell you a workstation to do it at home. If there were a place at >>> home where data collection apps could run... >> >> I do not know of any reason the model for IoT needs to be different from >> email. That is, yes, servers are needed. They might reside with end-users, >> but they do not have to. > > On this point, I think RFC 7452 ( https://tools.ietf.org/html/rfc7452 > <https://tools.ietf.org/html/rfc7452> ) did a nice job with spelling out the > different "communication patterns" seen in IoT deployments. > > To Ted's point, what I think we're seeing is a very large number of vendors > pursuing the "Device-to-Cloud" model (section 2.2) of sending all the data > back to some central application service provider, versus the > "Device-to-Gateway" model (2.3) where there is a local hub in the home. > > You're right, Dave, that this is quite similar to email... people *could* > operate their own home email servers, or they could just use some big > cloud-based vendor (<insert favorite name here>). There is a technichal issue that also drives vendors to the cloud. As long as we have NAT, we won’t be able to reach the stuff in the home with apps on a mobile device. We need to come up with some sort of standardized “back to my mac” like platform that works both over IPv4 and IPv6 with a security architecture that is trustworthy.
> >> The essential point is to have an open interconnection specification that >> permits mixing different vendors' products together. (This is true for >> mixing IoT end devices, not just IoT data servers.) > > This *is* the ideal I think we want to shoot for, BUT… +1 But as stated below, this will not happen without significant market pressure. I work a bit in the health care area and every vendor is building their own systems, which will drive public spending up through the roof at the same time as it causes severe issues with regards to privacy laws - data flowing in uncontrolled ways, ending up on clouds anywhere on the planet provided by more or less unknown vendors. Hopefully the public sector can control their spending and force some change in this area. >> >> I think the real issue here is that the vendors have a strong incentive to >> /retain/ their data acquisition role. So they won't give it up unless and >> until there is a strong consumer-driven pressure for it. > > ... I think you're right on target here. I think with IoT consumer devices > we're still in the early deployment stages where the vendors are trying to > capture the ecosystem and obtain de facto standards purely by market success. > I think it will take some significant level of consumer frustration with > not being able to buy, for instance, two lightbulbs from different vendors > and have them work together before there will be enough pressure to get > vendors to start interoperating. Oh yes, as long as there’s money in the big data and selling user’s privacy that will happen. I think we need a showcase of an architecture that works to show vendors that don’t want to play that game and as a proof if vendors claim it doesn’t work without their wonderful superfantastic cloud service connected to Google, Facebook et al. Customers/users need good examples and today there are not that many out there. My 2 öre :-) /O > > My 2 cents, > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > [email protected] <mailto:[email protected]> +1-802-735-1624 > Jabber: [email protected] <mailto:[email protected]> > Skype: danyork http://twitter.com/danyork <http://twitter.com/danyork> > > http://www.internetsociety.org/ <http://www.internetsociety.org/> > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
