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

[Brian E Carpenter]

On 25-Aug-23 11:07, John Klensin via Internet-history wrote:
> Jack,
> 
> I'm confident there are people on this list who are more in the mainstream
> of today's IETF than I am and should respond to the rest of your note, but
> two quick comments (maybe corrections but at least adjustments):
> 
> (1) The IETF has certainly not "become the ISO".  While there are a wide
> range of opinions about how successful they have been (and answers may
> differ by TC), ISO has made serious efforts to understand the evolutionary
> processes I described and to create procedural and other mechanisms to deal
> with the risks and issues they present.   At least IMO, the IETF has,
> instead, largely pretended that those processes and their consequences do
> not exist and continues to do so.
> 
> (2) The IETF already had an active Applications area by the time I started
> getting actively involved with it as an organization (circa 1990 or 1991)
> rather than just reviewing or contributing to an occasional document.  I
> was involved with parts of the IANA and RFC Editor functions much earlier
> but, as you know, they were not part of the IETF or under its control at
> the time.  Probably a larger fraction of applications work has come to the
> IETF already half-developed and in search of refinement and validation by
> the community than has been the case in many other Areas, but that doesn't
> mean the work did not come in and benefit from IETF involvement.  The web
> of the mid-1990s is actually a fairly good example with the some of the
> CERN-developed protocols and systems undergoing significant discussion and
> refinement in the IETF and, btw, HTTP is still primarily and IETF protocol.

I believe I was the first person from CERN to attend the IETF (#25, November
1992, Washington DC). My main interest then was IP over ATM and other "high
speed" links, and in what was about to be named IPng. Tim Berners-Lee was not
there, except in spirit. The first meeting of the Uniform Resource Identifiers
Working Group (URI) took place and a paper 'titled "Universal Resource Locators"
by Tim Berners-Lee was reviewed.'

At IETF 26, Tim was present (I wasn't) and there was a World-Wide Web (WWW) BOF.
Tim continued attending for a while, basically until the W3C was formed and
HTML moved away from the IETF.

So, yes, the IETF was involved at a crucial stage of the Web's childhood, even
before Mosaic 1.0 was released and changed everything. However, in fairness,
the Web was its own best advertisement.

      Brian

P.S. In those days, the minutes of IETF meetings were done properly. Historians
trying to find out who said what in recent years will be disappointed.

> 
> best,
>     john
> 
> 
> 
> 
> On Wed, Aug 23, 2023 at 3:13 PM Jack Haverty <jack at 3kitty.org> wrote:
> 
>> John,
>>
>> Thanks for the perspective on the history.  I wasn't involved in the IETF
>> for much of that period, but what you say sounds very plausible.  I've also
>> seen similar evolutions of patterns and behaviors in other situations.
>> After reading your message, my reaction was "Oh, now I see, the IETF has
>> become the ISO."   I have always thought that the IETF was an Engineering
>> activity.   I hadn't realized it has become a Standards Body.   The
>> "Internet Standards Organization"?
>>
>> Fifty years or hindsight is even better than twenty-five.  A couple of
>> other comments and observations about how history might record the last 40+
>> years...
>>
>> In the early days of the 80s, I agree it was a much smaller and simpler
>> environment.  But there were some other characteristics which IMHO made a
>> huge difference.
>>
>> First, at the time in the 70s/80s, there was a tight coupling between the
>> designers and the operators of the technology.   People who attended
>> Internet meetings, argued about protocols and algorithms, and debated how
>> many bits to have in headers, also wrote the code, debugged it, and kept it
>> working out on the operational Internet.  ARPA sponsored a lot of projects
>> to create such code, and then made it freely available for anyone to use as
>> a "reference implementation".   That behavior led to the Internet Mantra --
>> "Rough Consensus and Running Code".   The "shelf" was stocked with code;
>> documents and specifications followed somewhat later.
>>
>> With such tight coupling between design and operation, and the small size
>> of the community, change was a lot easier than today.  Although the
>> NCP->TCP "Flag Day" was dramatic, TCP itself had several later transitions,
>> progressing from TCP 2, to 2.5, to 2.5+espilon, to 3, and eventually to 4,
>> all in a period of a year or two.  We expected that rapidity of change to
>> continue as the theory of protocol design met the harsh reality of
>> operational systems, and the imposing list of unsolved research topics
>> evolved into rough consensus and running code.   Much of the changes that
>> occurred in those transitions were results of experiences in Internet
>> operations, which either caused some change or added another item to the
>> to-do list of research topics.
>>
>> Over time, it seems that such tight coupling has perhaps dissolved.   Are
>> IETF participants actually involved in deploying and operating pieces of
>> today's Internet -- not just their company, but the individuals themselves?
>>
>> Second, again at the time in the early 80s, the "Internet Project"
>> embraced a wide view of its role.   Everything that was involved in using
>> the neonatal Internet was part of the engineering task of making the
>> Internet usable.  At the time, most usage fit into three categories: remote
>> login (Telnet), file manipulation (FTP), and electronic mail (SMTP).
>> During the various transitions, much effort was placed into designing and
>> implementing strategies and mechanisms for making sure that all of those
>> services continued to work during and after transitions.
>>
>> Today, the IETF seems to have drawn a fuzzy line around the Internet, with
>> the IETF's "Internet" on one side and "Applications" on the other.   The
>> IETF focuses on the "Internet" side.   As far as I can tell, no one, or
>> everyone, or anyone, deals with "Applications".
>>
>> In the early 90s, the Web appeared (thanks TimBL!) as the next "killer
>> app" that we had been seeking since the earliest days of the Arpanet.  I
>> was at Oracle at the time, arranged for Oracle to join W3C as a founding
>> member, and then participated as the corporate rep.   I recall wondering,
>> even then, why the IETF wasn't involved.   There were individuals belonging
>> to both IETF and W3C, but IIRC no organizational level interactions.   Now
>> I surmise that the Web was, in IETF's view, even then an "Application" and
>> not a component of The Internet.   In the non-techie users' view, many
>> think the Web is the Internet.
>>
>> Third, TCP introduced a fundamental change in the network architecture,
>> which may have made it much harder to make transitions as the size
>> exploded.   In the NCP world, the packet switches - the IMPs in the Arpanet
>> - contained much of the mechanisms for providing a reliable "virtual
>> circuit" service.   In the TCP world, most of those mechanisms are
>> contained in the "host" computers, and the network itself is only
>> responsible for a best efforts delivery of individual IP datagrams,
>> possibly lost, duplicated, corrupted, reordered, or otherwise mangled.
>> TCP, in the computers, compensates for whatever happens in the underlying
>> networks.
>>
>> In effect, the mechanisms of the Arpanet IMPs contained the functional
>> equivalent of TCP.   The Internet architecture moves those mechanisms into
>> the computers that interact over the Internet.    I'm wondering if that
>> restructuring is part of the problem in getting new technology deployed to
>> replace the old.
>>
>> In today's Internet, there are of course many more network switches than
>> were in the Arpanet.  So it would be a hard problem to change the software
>> in all the routers now in the Internet.   But there are now far more
>> computers, each containing TCP, attached to each of those routers.
>> Anecdotally, on my own home LAN I'm nearing a two order of magnitude
>> difference.   There are almost 100 times as many computers (each containing
>> TCP) on my LAN than routers, manufactured by many more vendors, some of
>> whom no longer exist.   Changing all of just my software and hardware is a
>> very hard problem.   With billions of computers?
>>
>> I've always wondered about the motivation for that movement of TCP
>> functionality from network switches to attached computers.  Was the impact
>> of growth considered?  Or perhaps the motivation was simple pragmatism?
>> The Arpanet managers were unwilling to risk removing the internal
>> management mechanisms and provide datagram service - so the only place
>> where such changes could be tried was in the computers themselves.
>>
>> -----
>>
>> Regardless of the history, today's Internet has arguably become a global
>> infrastructure.   I'm still curious about how that infrastructure is and
>> will be managed, and how the technology will be evolved.  Other
>> infrastructures seem to have evolved over decades or even centuries to be
>> surrounded by a morass of management mechanisms - standards bodies,
>> government regulators and laws, safety codes, industry organizations, and
>> even international treaties.  Telephony, airlines, railroads, highways and
>> vehicles, postal services, radio/TV, finance, et al are examples.
>>
>> Is the Internet somehow different, and doesn't need more mechanisms?   Or
>> is it simply too young and they haven't developed yet?  How will
>> "applications" be managed?   How is the IETF involved?
>>
>> Jack Haverty
>>
>>
>>
>> On 8/19/23 07:32, John Klensin wrote:
>>
>> 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
>>>
>>
>>