[ih] A revolution in Internet point-of-view - Was Re: Internet analyses (Was Re: IPv8...)

[John Day]

s

> On Apr 30, 2026, at 00:42, Dave Crocker <dhc at dcrocker.net> wrote:
> 
> On 4/29/2026 5:04 PM, John Day via Internet-history wrote:
>> Choosing TCP. 
> What were the viable alternatives then? I don't recall hearing of any until later, with the problematic OSI TP* suite of choices.
> 
INWG 96, a synthesis of TCP and CYCLADES TS, that was approved by a 2-1 margin. Authors were Cerf, McKenzie, Scantlebury, and Zimmermann. It was operational and being used.
> If you are saying the 'direction' was from the government, rather than from government-funded researchers working based on their own assessments of needs and opportunities, please explain.
> 
See Alex McKenzie’s 2011 article in the Annals of the History of Computing. The decision to not compromise with INWG (which DARPA had helped found) was made by DARPA.
> And then there is the considerable body of documents showing a multi-group participation in the effort as it developed, as has been common in the Internet's history.
> 
> 
> 
> 
> 
>>  Choosing SNMP over HEMS.
> I'm my usual version of fuzzy about the details, but it appears I was the Network Management AD at the time, for whatever that might be worth.  The only 'directed' choice I recall was to use ASN.1, much to the IETF-constitueny's chagrine.  But that was due to the persistent and vigorous politics coming from the OSI side.
> 
I have previously explained what the IETF didn’t understand about ASN.1.  BTW, when was this?  The OSI Management work started in IEEE 802 in 1985.
> My vague sense of the competition -- besides the solid politicking-over-implementing that characterized the CMIP folk -- was that HEMS was cleaner but lacked experience, whereas SNMP was an increment over the deployed SGMP. Worse, Alas, HEMS also did not develop enough traction to counter  advocacy by the other two communities.
> 
;-) And as I have often said, so simple it was too complex to use. In fact, this is my point. The IETF went for tradition and being conservative. People had been using OO methods for years at this point. There were fun use cases where SNMP generated 10,000 messages while CMIP generated 2.

(Also SNMP had the largest implementation of the 3.)
> There is quite a bit of history of choosing experience over elegance, especially given the benefits (and in spite of the detriments) of installed base.
> 
Exactly my point, the IETF always acted too conservatively. It was years behind current practice. 
> By the time of this particular competition, participation in the IETF was wide open and the participation in the IETF was extensive and vigorous.  So the model of rough consensus even benefit from pretty good market sampling.
> 
Thanks for confirming what I have said previously. The IETF’s focus was on market success rather than technical excellence or even technical advance. SNMP was probably the worst protocol the IETF has done. 

Remember the success of SNMPv2?
>>  Choosing IPng over IPv7,
> Prior to Kobe, my own sense was that CLNP was going to win.  Kobe killed that.  
> 
> As for Tuba vs. SIPP, we are back to theory vs. practice.  Deering's proposal was quite an elegant increment over IPv4.  And, again, I saw no indication that this was anything other than community rough consensus.  And again, if you have information to the contrary, please elucidate.
> 
> 
> 
There was more IPv7 deployed in the Internet in 1992 than IPv6 in 2014. Seems to me there was more experience with IPv7.
> 
>>  I am probably wrong but was the choice of domain-names broadly decided.
> Again, as opposed to what, that would scale?
> 
IPv7, There were two problems the IETF had to solve at this point: 1) recognizing that hosts were part of the network (this enabled multihoming as well as other things) and 2) not losing the Internet Layer, which the Internet had already done.

The secret to scaling was there.
>>  There was a real fascination at the time with ‘host-names’, even though it has been known since the early 80s that ‘host-hames’ are irrelevant to creating end-to-end connections.
> You mean, except for the User Experience benefits, compared with using numeric addresses?
> 
Huh? No, using application names like open(ucsd/telnet) which had existed since 1975.
> And, again, when, how, and who generated the 'direction' that forced this choice?  
> 
Could you explain the question? There was a push to do it right, but Joy was too fascinated with his toy.
> And by the mid-1980s, there was a highly diverse and independent community of participants making DNS work and scale.  Craig has nice comments about getting other networking groups to come on board using it.
> 
Doesn't make it any less a major step backwards. Contributing in a major way to limiting the Internet to a rudimentary client/server model.

Which is another thing. When I read through these developments, there is an overriding sense of the lack of technical leadership. No one saying ’no, we need to follow good software engineering practice’, no one saying, ’no, that limits what is going to be needed soon.’ etc. As I have said, OSI made lots of mistakes and was being held back by the PTTs. The IETF had a great opportunity to leapfrog them, but chose to do the opposite and mark time or go backwards. Very unfortunate given where it has left us.
> Note:  For many of the Internet's technical and operational work, it has certainly been common for someone to hold an authority role that aided in breaking logjams. Their success resolving something has relied on community respect, rather than positional authority. I seem to recall Jake Feinler taking credit/blame for resolving the question of an initial set of what we now call 'generic' domain names, after the community stalled.  I've no doubt there are cases where the deciding person was at DARPA and hence held extra sway, of course.  But I think that has never been a dominant tone to any of the Internet's technical work. 
> 
It has been for the most part done as you describe. However, I have heard rumblings of the use of classic committee games to affect the process. I really don’t want to go further.

Take care,
John
> d/
> 
> --
> 
> Dave Crocker
> 
> dhc at dcrocker.net <mailto:dhc at dcrocker.net>
> bluesky: @dcrocker.bsky.social
> mast: @dcrocker at mastodon.social
> +1.408.329.0791
> 
> Volunteer, Silicon Valley Chapter
> Northern California Coastal Region
> Information & Planning Coordinator
> American Red Cross
> dave.crocker2 at redcross.org <mailto:dave.crocker2 at redcross.org>