APIs suffer the neverending debate of "not an IETF job, go to POSIX".
IMHO, IETF should define APIs, eg: let TAPS really do the work thats
now declared out of scope. And then go to POSIX with the results.
APIs are also not the complete answer.
OS independent, readily available and easily adopted network SDKs are the answer.
Upgradeable independent of app and OS. The only mayor instance of this
are browsers and then look at how slow web sockets are evolving. And
the issue really are the billions of embedded devices / apps where
browsers don't play.
And don't get me started on DNS-SD. Ever tried to use embedded home market equipment like
printers remotely when both client and server use mDNS ? Or trying to figure out
how to set up any form of DNS-SD across VPNs ? But sure, yes, lets first make sure
there is absolutely no way to permit configuration of IP addresses or
even DNS names so you surely can't get the service to work without configuring
some klunky CLI mDNS proxy from some 10 year old README file.
The road to hell is paved with good intentions.
Toerless
On Tue, Oct 03, 2017 at 10:13:55AM -0400, Phillip Hallam-Baker wrote:
> On Mon, Oct 2, 2017 at 3:26 PM, Brian E Carpenter <
> brian.e.carpenter@xxxxxxxxx> wrote:
>
> > On 02/10/2017 21:42, Randy Bush wrote:
> > ...
> > > yes, it has been compelling cgns and nat44444 all the hell over the
> > > place. major win!
> >
> > In a way I regret not having completely blocked deployment of the http
> > nonsense back in 1993, when I ran the team that ran the network that
> > Tim Berners-Lee first polluted with this web stuff. But since I
> > didn't do that, just as Tim's managers didn't stop him wasting time
> > on it instead of doing his day job, the massive growth of the IPv4
> > network (before IPv6 was ready) became inevitable, so NAT44 and
> > NAT444 became inevitable, so CGNs and NAT64 became inevitable, so
> > here we are.
> >
>
> ???Since I spent much of the morning looking at material posted by Internet
> Research Agency bots ???peddling false stories in the hope of exploiting the
> Vegas shooting, I am rather short on tolerating sarcasm right now.
>
> But for the Web, OSI might well have won. When the killer apps of the
> Internet were email and file transfer, interconnection between networks
> could be achieved as well through gateways as by establishing a consistent
> namespace. The Web ended the network wars because URLs didn't work across
> network namespaces. So even though you could run HTTP over DECNET phase IV,
> there was no point in doing that as all the content was on the Internet.
>
> As for carrier grade NAT being inevitable, it took a very long time for
> IETF to accept that fact. People who suggested that the IETF had to work
> out how to live with NAT and make it part of the solution were bullied and
> isolated. And you were chair while much of the unpleasantness was going on.
>
>
> The only way to effect any technology change is to make it as seamless and
> transparent as possible. That used to be understood, that is why flag days
> were considered to be a bad thing.
>
> The strategy adopted instead was to reserve new features for the new
> protocol. With the result that new features were also delayed or botched.
> It is a long time since I used an IPSEC VPN because they still didn't work
> reliably through NAT last time I bothered to try while SSH works pretty
> much flawlessly.
>
> If you want IPv6 to work, how about considering doing it my way, just the
> once? Not doing it mind, just considering the alternative approach without
> driving out the heretics.
>
>
> It really is quite simple in my view. If you want IPv6 to become
> unbiquitous, you need to provide people with a new internet API that
> isolates the application from ALL of the IPv4/IPv6/NAT issues. And thanks
> to Stuart Cheshire and co, 90% of the work is already done.
>
> At the moment, the network API is in effect:
>
> Address = nslookup_its_an_ipv4_address_right ("example.com")
> Socket = get_socket_ipv4 (Address, 80)
>
> (for the other Internet protocol, replace port 80 with 443).
>
>
> The problem here is that the application programmer is asked to implement
> whatever the IPv6 transition strategy is this week. And frankly, why would
> any of my engineers bother when IPv4 is guaranteed to work and they have
> plenty of other features that are higher in priority.
>
> If you want transition to work, then you need to give the application
> programmer a black box that they can plug into their code and just works
> without them having to think about it. i.e.
>
>
> Client = GetOutbound ("example.com", "_http._tcp")
> Service= GetInbound ("example.com", "_http._tcp")
>
> or for legacy
>
> Client = GetOutbound ("example.com", 80)
> Service= GetInbound ("example.com", 80)
>
> A call to any of those should do all the work for the programmer including:
>
> * Configure NAT (if required) - see TURN/STUN rfc5766
> * Resolve the DNS name
> * Decide on the session protocol TCP or QUIC
> * Decide whether to use a transport layer security (e.g. TLS)
> * Validate any cert chain presented
>
> As I said earlier, we already have a spec that almost completely constrains
> the space, its RFC6763. I would like to see the space constrained further
> and establish standard tags for service properties so that a service can
> offer QUIC or mandate use of TLS in a consistent way.
>
>
> We have all the parts, what has held us back is a series of niche interest
> groups who are so obsessed with achieving their own technology transition
> that they are oblivious to the fact that they are sabotaging the mission of
> the IETF as a whole:
>
> * The IPv6 purists who insisted on sabotaging protocols to prevent use of
> NAT
>
> * The DNS purists who insist that the answer to every DNS issue is a new
> DNS resource record.
>
>
> IP and DNS are just plumbing. They matter but nobody ever bought a house
> because they were impressed by how beautiful the pipework was. The only
> time it enters into the picture is when it isn't working.
--
---
tte@xxxxxxxxx