RE: [newtrk] IESG comments on ISD proposal

["Hallam-Baker, Phillip" <[e-mail]>]

> [mailto:[e-mail]] On Behalf Of Bruce Lilly

> I'm growing weary of hearing that claim, which I've not seen 
> substantiated. I'll stop short of calling "bullshit" and 
> simply say that I don't believe it.  The Internet runs mainly 
> on full Standards, as I see it: IP (STD 5), UDP (STD 6) and 
> TCP (STD 7), Telnet (STD 8), FTP (STD 9), SMTP (STD 10), the 
> Internet Message Format (STD 11), DNS (STD 13), MIBs (STD 17) and
> SNMP (STD 62), PPP (STD 51), POP (STD 53), etc.   In 
> addition, there are
> some Draft Standards which are widely used: NTP (RFC 1305, 
> March 1992), HTTP (RFC 2616, June 1999), and MIME (RFCs 
> 2045-2049, November 1996). I will grant that IMAP (RFC 3501, 
> March 2003) is a Proposed Standard that is widely used. [I 
> have included dates for a reason]  Where precisely are the 
> supposed PSs that have supplanted IP, TCP, and UDP on the Internet?

Perhaps someone who was there at the time the STD series was created
could tell us how many of the STD series documents got there as a result
of the process and how many were grandfathered in.

I'll bet that none of the documents that predate the first meeting of
the IETF went through the IETF process. Not coincidentally the vast
majority of the core Internet protocols are in this category. DNS is the
lone exception amongst the basic infrastructure protocols and that is
only by a few meetings.

I took a look at the current roster of Draft protocols, with a tiny
number of exceptions that relate to essentialy obsolete protocols like
X.400 and FDDI that hang on in a few places I can't see why they should
not all be recognized as standards now.

I don't think something has to necessarily be widely used to recognize
it as a standard. The real issue is whether the document and protocol
are well defined and stable or liable to change.

HTTP may or may not continue to be widely used in 20 years time. What is
certain however is that if there is something called HTTP/1.1 it will
look like the one in the document.


> Either abandoning the Standards Track which has produced IP, 
> UDP, TCP, SMTP, FTP, Telnet, POP, etc., or creating yet 
> another set of documents that need to be maintained -- 
> without first identifying and documenting specific problem(s) 
> that either action would remedy without introducing more 
> serious problems -- might prove fruitless at best, or 
> harmful. . newtrk 

Again, the IETF standards track NEVER produced IP, the exact reverse is
the case.

One of the main reasons for the problems with the IETF is that the
institution has a problem with its creation mythology. Do not confuse
what Vint Cerf, Jon Postel and co did together in a fifteen person cabal
thirty years ago with the institutions they then went on to help create.
Saying that the IETF invented the Internet is as nonsensical as saying
that ICANN invented the Internet.

It is important also to realize that part of the original starting point
for the IETF was the realization that the legacy protocols, IPv4, FTP,
SMTP etc. were not particularly good, the documents were in many cases
ambiguous, the protocol design in many cases poor. The expectation being
that unless these got fixed that OSI would be eating the Internet's
lunch.

The IETF did successfully develop a technical replacement for IPv4 which
was considered the most eggregious technical deficiency. The problem
being that in the interim the market had been forced to develop NAT as
an interim measure and IPv6 has not been able to develop a coherent
deployment strategy that has the necessary support from the critical
stakeholders since.


.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html