Subject: RE: [newtrk] IESG comments on ISD proposal

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 May 2005 08:48:04 -0700

> [mailto:[email-masked]] 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

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 10 May 2005 14:57:58 -0400

> lone exception amongst the basic infrastructure protocols and that is

The (multi-stage) process and its formalization are two different things.
Just look at the history of the development of the early protocols -- when
RFCs elicited Cs in the form of new RFCs.  Take SMTP, for example.  After
a couple versions of MTP (RFCs 772 and 780), it was supplanted by the
first SMTP (RFC 788) which evolved into STD 10, RFC 821.  Clearly there
were stages to the process, and the simplification corresponds roughly
to the removal of unused features expected at elevation to Draft Standard.

> not all be recognized as standards now.

And yet they haven't been.  Which is why I think we need to hear from the
IESG specifically why the advancement process in 2026 isn't being followed.
Has the IESG shot itself in the foot by prematurely disbanding WGs, or by
failing to charter them to do the work necessary for advancement?  Is there
some other resource shortfall?  Is there some procedural snag?  Is it
because bringing Draft Standards up to date would entail so many changes
(boilerplate, etc.) that they would have to be reset to Proposed?

> are well defined and stable or liable to change.

Like Archie and Gopher?
 
> look like the one in the document.

Agreed, yet RFC 2616 will have been stuck at Draft for six years as of
next month.

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

The multi-stage process did produce standards in widespread use.

More to the point, the original claim, viz. "the Internet runs mainly on
Proposed Standards", still hasn't been substantiated.  Even if you ignore
the same *type* of process, there is no way that IP is a mere "Proposed
Standard".
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 10 May 2005 15:35:43 -0500

> the same *type* of process, there is no way that IP is a mere 

I did not originate this assertion, but I believe it and have repeated 
it in public, so...

When I have repeated this assertion, it's often been in the context of 
TCP.

You might think that TCP is a full standard, since RFC 793 TCP is a 
full standard, but if you watch any modern TCP with tcpdump or some 
equivalent, you will discover that the TCP is implementing a larger 
initial congestion window, fast start/congestion avoidance, fast 
retransmit, fast reecovery, SACK, window scaling, maybe Eifel, and 
probably some other items that I never heard of or forgot. All of 
these are proposed standards.

RFC 793 TCP was prone to persistent oscillating congestion in network 
conditions encountered during the late 1980s. One can only imagine 
what the Internet would be like today, if it was running on THIS full 
standard. Happily, the Internet is running on proposed standards.

Your mileage may vary, if you're thinking of different protocols, of 
course.

Spencer 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 May 2005 11:34:52 +0200

> On Tue May 10 2005 11:48, Hallam-Baker, Phillip wrote:
...
> the same *type* of process, there is no way that IP is a mere "Proposed

RFC 791 (STD) is updated by RFC 1349 (PS).
RFC 1349 is obsoleted by RFC 2474 (PS).

And so it goes wherever you look. Fortunately, we have running code
to save us.

    Brian

.