[ih] IETF relevance (was Memories of Flag Day?)

[John Klensin]

Scott,

Sorry for the slow response time.  It took me a long time to write this and
even longer to decide whether to post it.

No real disagreement with your comments, but I see things from a different
perspective...  In the IPv6 case, not only was it not different enough to
create significant "pull" but, as I see it, the one really important area
of innovation/difference was the inclusion of mechanisms for encryption at
the IP layer.  I'm, not aware of any specific problems with that technology
as specified, but slow uptake doomed us to widespread use of SSL and then
TLS at the application layer and that, in turn, has, I think, contributing
to protocol designs that have undermined both parts of the TCP/IP model and
the IETF.   However, there was an impediment at the other end of the design
that I think may have retarded IPv6 deployment even more:  It was not
similar enough to IPv4 to allow deploying it in a single, albeit enhanced,
stack environment.  Consequently, we didn't have easily-deployed IPv4-IPv6
interoperability but, instead, had gateways and address translation and,
often, applications that had to be aware of the difference.   Had one of
the "IPv4 with long addresses" models that would have permitted a single
stack prevailed instead, who knows?

The other thing I think we counted on to drive deployment -- running out of
IPv4 space-- was, as you suggest, decelerated by NATs, possibly encouraged
by the realization that different address spaces on LANs than on the WANs
to which they were connected posed some advantages for both security and
multihomed network perspectives.  That seems to be catching up with us now,
20-odd years after it was expected, and driven precisely by the perceived
need for public addresses for phones, IoT devices, etc.

Isn't a quarter-century of hindsight wonderful?

But, with the understanding that I don't know whether patterns and
behaviors I see from my peculiar corner of the world are general patterns
or just risks, nor do I know if it is wise and good for the Internet to say
things things "in public"...

 I think the IETF's relevance issues come from somewhere else, probably a
few other places.  From experience in completely different fields, there
are differences between successful standards development effor   that are
concerned with the specification of new/ innovative technologies and those
that are primarily concerned with extending, enhancing, and tuning existing
ones.  The observation has been made repeatedly that, at early stages of,
e.g., protocol design, companies are willing to send their best
design-level people to participate.  Academic and other researchers at the
leading edge show up, participate, and contribute (or lead) too.  Because
of its roots in research and design discussions and a focus on getting
something that would work, when the IETF (and its predecessor arrangements)
started talking about "standards", it had huge advantages over more
established standards developers.  However, when the main focus evolves
away from  initial development of core protocols (or equivalent), things
shift.  Many of the core design-level people with inherently broad
perspectives stop showing up -- the organizations that supported their work
and their primary research and thought agendas shift elsewhere.  In many
cases, their seats are filled by people who are interested in protecting
their company's products or feeling important by putting their particular
marks on things.

Flag day was possible because it occurred in a small, administratively
centralized, network in which that decision could be made and enforced.
Contrast that with jokes about the "protocol police" in the last couple of
decades.  Had NCP lasted longer --perhaps long enough for some analogy of
what I saw as the decisions that core Internet protocols and operations
were not research any more  to occur-- it seems to me quite possible that
we would either be running a great grandchild of NCP today (with a
patchwork of fixes and kludges to allow it to function) or that OSI would
actually have taken over because of longer addresses, better scaling
properties, and the very real possibility that ISO, its National Member
Bodies, and ITU would eventually have gotten their acts together and
produced something that would have worked globally without multiple
non-interoperable options and profiles.

Those early-stage efforts have another advantage as well: Not only is it
possible from a design standpoint to say "got that wrong (at least given
considerations about the future), let's discard it and do something else"
--the critical prerequisite of a successful Flag Day transition -- but
interoperability is in everyone's best interest.  Later, if there is enough
deployment, especially commercial deployment accompanied by the emergence
of a few dominant players (or players who are self-confident or arrogant
enough to aspire to dominance), making variations on the protocols, ones
that don't quite interoperate, in order to advertise one's advantages over
others or, more commonly, to lock users in by making vendor-switching very
painful, is often treated as very attractive.  If that becomes a regular
pattern, It of course conflicts with interoperability as a primary goal.,

Other standards bodies have recognized those trends (even if often not
explicitly) and adapted their ways of doing things to adjust for them or
reduce the risks to quality and credibility of standards to which they
might lead.  Sometimes they have been successful, sometimes not, but .
AFAICT, the IETF has been unable or unwilling to recognize or engage on
them.

In addition to those general trends, it appears to me that there have been
several changes in the IETF in recent years that I see as (at least
potentially) self-inflicted wounds with likely effects on the credibility
and relevance of our work.  While I'm sure others might look at the same
things and see increased efficiency and consistency, I see an increasing
reliance on, and control of decisions by, staff, and  increasing transfers
of authority to people with roles that have little or no accountability to
the community.  Some of that is accompanied by increasing numbers of
specific, overly rigid, rules and procedures, many of them created with
little involvement from the broader IETF community.  Some of them determine
policy or create Procrustean beds because there are no effective override
mechanisms for unusual cases.  I'm not yet ready to conclude that it is a
regular and long-lasting pattern but others seem to believe that, in
practice, many recent rules about behavior and the like do not apply to
people who are close to the leadership but are are instead used as weapons
against some of those who are not or who disagree with leadership
positions.  Whether that view of things is accurate or not, the perception
that it occurs is damaging to the IETF's credibility and, at least
potentially, to its relevance.

Has the IETF become irrelevant?   Probably not yet but perhaps working on
it.  And I don't see any realistic signs of a fallback plan.

Sadly,
   john

p.s. I don't see attendance at a particular meeting, or even a sequence of
meetings, as providing much useful information, especailly when many of
those are first-time (or very infrequent) attendees from the general local
area.   It is too easy to drop in out of curiosity, to say one has been to
a meeting, or even to play a specialized version of "go to the zoo and see
the geeks".  Data on the number of people who show up at a given meeting
who, a few years later, are participating and contributing actively would
be far more interesting.






On Thu, Aug 10, 2023 at 12:35 PM Scott Bradner via Internet-history <
internet-history at elists.isoc.org> wrote:

> mixed picture of IETF relevance
>
> the world's telephony runs over IETF technology (SIP & RTP) except for
> some pockets of analog phones,
> IETF technology specified by ITU and 3GPP
>
> of the 100s of proposed and full standards, only a few are in significant
> use
>
> IPv6 has had a very slow deployment - most, imo, because it does not offer
> enough difference from IPv4
> and because NATs have reduced the pressure to change - but, according to
> Google, they are getting a lot
> of IPv6 queries (about 45%) ( see
> https://www.google.com/intl/en/ipv6/statistics.html) - e.g. your iPhone
> runs IPv6 by default
>
> people still show up for IETF meetings (> 1500 paid for Yokohama in March
> - in person & remote)
>
> Scott
>
> > On Aug 10, 2023, at 12:16 PM, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > I've been wondering if the IETF is still effective today.   It's been
> trying for decades to cajole the Internet into adopting IPV6.
> >
> > Instead we now live with a multi-protocol Internet, and the complexity
> and problems that come with it.  In the 90s, the world embraced TCP and got
> rid of all the other protocols.   As I understand it, the IETF now "puts
> new technology on the shelf, where anyone is free to pick it up and use it"
> - quite different from the management process that orchestrated "Flag Day"
> and managed the evolution of the Internet technology in the field.   Some
> people have "picked up" IPV6, but many have not.   I can't tell if I have.
> I also have no idea how I would do it.   Or why I should.
> >
> > Perhaps someone can fill in the history of how the Internet got from
> then to now?  I sent an email on this topic a week or so ago, but it seems
> to have never come out of the elists.isoc.org system.   FYI, here it is,
> in case you didn't get it:
> >
> > --------------------
> >
> > IIRC, the "Flag Day" was one piece of a larger plan.
> >
> > I don't recall the timing of the pieces - it was 40+- years ago. But
> there was also a bureaucratic action in that same era to declare TCP a "DoD
> Standard", and require its presence in DoD procurements - any computer
> system in a DoD purchase using networking had to have TCP. Also, there was
> a program created by NIST (or was it still NBS then?) to provide a test
> suite for conformance to the TCP standard.   So any contractor who wanted
> to sell something to DoD had to have TCP, and by going through the NIST
> test suite they could get a certificate proving that they had TCP
> implemented properly. I don't remember which of these happened in what
> order or how it related to Flag Day (1/1/1983).   But it all seems to me to
> be part of some larger plan to migrate the admittedly small existing
> network to a new standard.
> >
> > At BBN, we went through the NIST process to become a certified testing
> lab, so we could run the tests for anyone who needed it and issue
> conformance certificates.  I'm not sure how many other such labs there
> were.  We also provided consulting services to help people understand TCP
> and figure out why their software didn't pass the tests.   This was never
> seen as any kind of "money maker", but seemed important to do it, since we
> had access to IMPs and such which made it easy to set up a small test lab.
> >
> > I never saw "the plan", but it struck me that there was a lot going on
> behind the scenes to make things like this happen, outside of the research
> or Arpanet community or technology per se, in order to facilitate the
> introduction of TCP to DoD.  Maybe someone else knows more about who was
> involved in all that activity.   Somebody made those things happen...
> >
> > In retrospect, it seems to me that such "soft technology" (conformance
> certification etc.) was complementary to the technical work documented in
> the stream of RFCs, and was important to making TCP "real", and
> establishing a bit of regulation around its use "in the field" with
> mechanisms such as "Flag Day" to enforce a migration from old to new.
> >
> > The Internet is now arguably world class "infrastructure".   But, IMHO,
> it still lacks a lot of the mechanisms that surround other, older,
> infrastructures that move things from point A to point B - e.g., highways,
> electrical service, railroads, airplanes, etc.   The early work on things
> like Flag Day, TCP Conformance Tests, DoD Standardization, and such were
> the beginning of adding a management structure around the Internet
> technology.
> >
> > As near as I can tell, no such effort continues today.   It may have
> faded away back in the 1980s, before TCP became the dominant technology.
>  Perhaps the Internet is just too new for such machinery to be created?
> >
> > Other infrastructures have gone through stages as rules, regulations,
> and practices congeal.  In the early days of electricity it was common for
> accidents to occur, causing fires, deaths, or other disasters.  Electrical
> Codes, safety mechanisms, licensing, rules and practices have made using
> electricity much less dangerous.  The same is true of highways, railroads,
> etc.
> >
> > I've always wondered what happened to that "management framework" that
> started in the 1980s around the Internet infrastructure, and why it hasn't
> resulted in mechanisms today to make the Internet "safer".   I suspect all
> infrastructures need things like electrical codes, UL testing, development
> of fuses, circuit breakers, GFIs, etc., that are used in the electrical
> infrastructure.   But nobody seems to be doing that for the Internet?
> >
> > There's lots of such mechanisms I know about in the US to manage
> infrastructures.  My car occasionally gets a government-mandated recall.
> Airplanes get grounded by FAA.  Train crashes are investigated by the
> Department of Transportation.   Other governments have similar mechanisms
> to manage infrastructure.
> >
> > Has any Internet component, hardware or software, ever been
> recalled...?   "Flag Day" was the last enforcement action I can remember.
> >
> > Jack Haverty
> >
> >
> > --------------------
> >
> > On 8/9/23 18:50, John Gilmore via Internet-history wrote:
> >> I had a "tourist" account at the MIT-AI system running ITS, back in the
> >> NCP days.  I used to log in to it over a TIP that had RS232 cables
> >> quietly connecting it to a Telenet node.  I'd dial in to a local Telenet
> >> access point, connect to the cross-connect's node and port, and be
> >> talking to a TIP, where I'd "@o 134" to get to MIT-AI.
> >>
> >> When NCP was turned off on the Flag Day, that stopped working.  At MIT,
> >> as I understand it, they decided not to implement TCP/IP for ITS.  The
> >> workaround for tourists like me was to borrow someone's account at
> >> MIT-OZ, which had TCP support and could also talk to ITS (over
> >> Chaosnet?).  So I'd connect from the TIP using TCP to MIT-OZ, and then
> >> connect to MIT-AI.  It worked OK, though I had to remember when (and how
> >> many times) to double the escape characters.  My access was via a dialup
> >> modem, which was probably the slowest part of the whole system.
> >>
> >> Moving to the present day...
> >>
> >> I continue to see Internet old-timers who long nostalgicly for somebody,
> >> somewhere, to force a "flag day" to shut down IPv4.  The IETF has
> >> unfortunately been captured by these folks, who object to making even
> >> tiny improvements to IPv4 protocols on the grounds that "we shouldn't
> >> make it easier to use IPv4 because that would reduce the urgency of
> >> switching to IPv6".  It is taken for granted in much of IETF that "IPv4
> >> is dead, or it should be" even though it carries far more global daily
> >> traffic, to a far broader range of locations, than IPv6 does.  There was
> >> even a move to "declare IPv4 Historic" which would officially recommend
> >> that nobody use it any more.  That draft RFC was approved in 2017 by the
> >> Sunset4 working group on a vote of three zealots, but it got killed once
> >> saner heads looked at the implications.  For a discussion of that
> >> history, and pointers to the source materials, see section 4 of:
> >>
> >>
> https://www.ietf.org/archive/id/draft-schoen-intarea-ietf-maintaining-ipv4-01.txt
> >>
> >> (The IETF, predictably, declined to support the publication of an RFC
> >> describing this history or succinctly stating that IETF would continue
> >> maintaining IPv4.)
> >>
> >> John
> >>
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>