Philip ... FWIW, GTW is completing research what are SDO activities in the IOT
space. Have been focused more on industry-sector SDOs than cross-cutting ones.
So far results show promoting interoperability is a common element in various
sectors ...
If your idea “We need to have some forum at which all the SDOs meet and
exchange ideas.” gains further traction happy to contribute
George T. Willingmyre
President GTW Associates
From: Phillip Hallam-Baker
Sent: Tuesday, September 20, 2016 10:52 AM
To: IETF Discussion Mailing List ; IETF Chair
Cc: IETF Announcement List
Subject: Re: Working with IEEE 802
Liaisons are good. But I have noticed that each of the SDOs I have been
involved in (IEEE, IETF, W3C, OASIS) is very interested in liaising with the
SDOs that were established before it was started and not so interested in
liaising with those that came after. There is also a distinct bias towards
talking to the layers in the stack beyond the one a given SDO works at,
In short, SDOs tend to look back and look down when they should be looking
forward and looking up.
Right now we have something of a situation with HTTP/2 and QUIC that I don't
think many folk in the HTTP world realize is happening. HTTP was of course
designed as transport for HTML above all else but even from the start we
realized that it also made a decent presentation layer for what became Web
Services, at any ate it was better than anything else around.
HTTP/2 broke that connection, the protocol is 100% optimized for HTML and Web
browser transport. HTTP/2 is not a good transport for Web Services. It could
have tried to be both but the WG didn't want to do that. And that was probably
the right thing to do. Because the needs of Web browsing and Web services are
actually rather different. It is clear to me that Web Services should look to
transition from HTTP/1.1 to whatever QUIC becomes. and that is not a bad
outcome.
My problem is that this is an outcome that we appear to have arrived at by
chance rather than with a dialogue with the stakeholders in the Web Services
world, 95% of which are outside IETF. The principal SDO developing Web Services
is OASIS but we don't seem to be talking to them much or even acknowledge their
existence. And beyond that I am aware of roughly a dozen more SDOs either being
formed, operating or collapsing in the IoT space.
I think that the pairwise model of dialogue isn't scaling. We need to have some
forum at which all the SDOs meet and exchange ideas. So rather than spending
the next three years building QUIC in a corner and then presenting it as a fait
accompli to the Web Service developer community and then waiting ten years for
adoption, get them involved at the start. And rather than having the design
process being decided by one large vendor who nobody else can dare say boo to,
have the other parties round the table and have skin in the game.
Looking down in the stack, there are features that I really want to see go away
because they have moved up the stack. When Ethernet was first introduced, all
the machines on a network sat on the same coax cable. So Ethernet absolutely
had to have a link layer mechanism for identifying packet destinations.
Today, networks are rather different. My wired LAN in the house has about a
hundred IP enabled devices on it. But the behavior of that network is very
difficult to predict because much of the routing is happening in stupid
switches at the Ethernet layer rather than at the IP layer which is actually
designed for the task.
I have solid engineering reasons for wanting Ethernet layer routing to just go
away as fast as it possibly can and replace my opaque Ethernet switches with IP
routers.
The problem I have with the idea of 'working together' is that this sort of
change which is natural and obvious is the sort of thing that I suspect most
folk are not going to want to propose in IEEE for fear of causing a rupture in
relations.
And don't get me started on our ICANN entanglements. I have no idea why so many
of you are so keen to invest so much IETF time and political capital in
promoting a project that doesn't actually advantage IETF at all.