On 2/12/2016 8:24 AM, Olle E. Johansson wrote:
On 12 Feb 2016, at 17:14, Dan York <[email protected]
<mailto:[email protected]>> wrote:
On Feb 12, 2016, at 9:32 AM, Dave Crocker <[email protected]
<mailto:[email protected]>> wrote:
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.
...
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.
There are a number of separate issues:
1. For rendez-vous, such as the user being mobile and wanting to contact
or monitor their IoT environment, there has to be some way for the user
to 'find' the IoT environment from over the public Internet. (A
rendez-vous function is independent of any storage-and-analysis function.)
2. Other than users accessing their IoT environment from the Internet,
what services are /required/ for IoT operation and involving a server --
on the public Internet or on the user's network? What dictates using
the public Internet?
3. From what I'm seeing, nothing technical requires the public server to
be owned or operated by the IoT equipment vendor. Nothing technical
restricts the server from being a public, commodity opportunity.
Note that these issues are not restricted to -- or new to -- IoT and
that while rendez-vous does require some sort of public server (given
address translation barriers at the user's network) it does not require
the server on the Internet to be owned or operator by the IoT equipment
vendor.
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.
Vendor lock-in has problems that are worse than just cost. It
significantly increases the likelihood of systemic vulnerabilities,
since lack of transparency in the design, development, testing and
operation of the services means far less, and far less varied, review.
For an environment subject to the degree of information accountability
that the health industry has, I'd expect this to be a very serious
problem, indeed.
A coalition of consuming groups with similar concerns might be enough to
press for open protocols and a free market for public servers and services.
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.
It is worth remembering that commercial networking used to be entirely
proprietary.
The move towards open standards and public networks was not a vendor
initiative. It came about only because of consumer and enterprise demand.
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.
The challenge is that open efforts tend to move slower and produce less
functionality. That doesn't make them very appealing as an alternative.
So they need to provide some other benefit that is very strongly appealing.
While, yes, R&D and proof-of-concept can be useful here, I think the
deeper challenge is to find and exploit consumer leverage.
In the case of networking, the need to have an environment in which a
consumer/enterprise network permitted interoperability among products
from different vendors, and interoperability across administrative
domains, is what produced the market pressures.
d/
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
