Subject: [newtrk] Date: Tue, 10 May 2005 13:16:08 -0700

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 May 2005 13:16:12 -0700 (PDT)

> [mailto:[email-masked]] On Behalf Of Bruce Lilly

> On Tue May 10 2005 11:48, Hallam-Baker, Phillip wrote:
> > 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.
> 
> The (multi-stage) process and its formalization are two 
> different things. 

No they are not. There is a huge difference between the origin of RFC
822 and the process that produced any of the IETF protocols.

We even have the minutes of the meetings at which the decisions were
taken preserved as RFCs themselves. We can see that there was no
oversight or top level review of the proposal whatsoever and certainly
no multi-stage process. 

> 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.

There was no process, people went to meetings and at the end someone
wrote up a document that described what had been decided. The document
was implemented, revised and published.

The difference between RFC 821 and its predecessors looks to me to be
much closer to resembling a series of working group drafts.

> > 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.
> 
> 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. 

Why? What is the utility in deciding which are the five or six draft
standards that are obsolete out of sixty that have been in that state
for four years or more?

If the draft is irrelevant because nobody uses X.400 or FDDI anymore the
advancement to standard is not going to suddenly cause a revival in
obsolete networking technologies.

> > 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.
> 
> Like Archie and Gopher?

Neither of which was on standards track. Gopher (1436) is informational,
Archie is not even an RFC, it is described in 1580 which is also
informational.

> > Again, the IETF standards track NEVER produced IP, the 
> exact reverse 
> > is the case.
> 
> The multi-stage process did produce standards in widespread use.

OK, name one.

> 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". 

But IP as has been repeatedly pointed out was not produced by the IETF
standards process and cannot be used as a proof point that the system
has ever worked.

I don't think it is very likely that any RFC before 1310 went through
the IETF process. If you look at the standards numbers it is pretty
obvious that STD2-50 were all issued their number at the same time. That
leaves STD 51-66 - 0nly 25% of Internet 'standards' ever went through
the process!

That would make the only commonly used application protocol to make it
to standard through the process to be POP3, all the rest of the
protocols are routing level protocols (BGP, OSPF etc) and SNMP. Plus a
couple of obsolete 'standards' like ONEPASS.

I think it is pretty obvious why routing infrastructure would (and
should) command urgent IESG and IAB attention. The problem is that the
standards process has not worked for any of the non-routing area
standards.

If anyone thinks that I or anyone else who worked on HTTP/1.1 has any
intention of doing any more work on that draft to get it advanced in
IETF process they are mad. If you think what reopening the process would
mean it becomes clear that it is impossible. People would start
re-opening old debates that are long closed and irrelevant. Moreover the
group of individuals who would work on the project would be self
selecting and probably have no relationship at all to the original group
who created the protocol. It would not be Berners-Lee, Frystyk-Nielsen,
Ragget, Connoly, Masinter, Luotenen, Andressen, Hallam-Baker, Fielding
et. al. working on the draft, it would be a group of folk whose real
objective was to replace our vision for the Web with their own. 

The same is doubtless true for most of the other draft standards that
are permenently in queue. You can't put something on the back burner for
six years and then come back expecting anyone to take notice of your
comments. 

I certainly do not see any logic in continuing to publish a list that
describes RFC 821 and RFC 822 as 'standards' when they are long
obsoleted by 2822 and 2821 which are themselves becoming obsolete due to
deployment of Sender-ID and DKIIM. At current rates of progress a clear
majority of email servers will reject email that only complies with RFC
2821 by the time it becomes a 'standard'.

If you do not see this as a sign that the STD process is completely
broken then I wonder what would.

.
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 17:43:55 -0400

On Tue May 10 2005 16:16, Hallam-Baker, Phillip wrote:
[...]
> standards that are obsolete out of sixty that have been in that state

Huh?  The 2026 section 6.2 process (q.v.) provides for review, decisions,
and notification to the IETF at large.  A valid decision is movement to
Historic.

> obsolete networking technologies.

If literally nobody uses it, movement to Historic is appropriate, and
would clear the recurring work item from the IESG's plate.
 
> Archie is not even an RFC, it is described in 1580 which is also

But both were sufficiently well defined to produce multiple client
implementations, both are stable (unlikely to change).  So I disagree
with your dismissal of utility as a criterion.

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

POP3.
 
> standards process and cannot be used as a proof point that the system

It hasn't been used that way.  It's been used to ask "where is the
corresponding alleged Proposed Standard that the Internet runs on?".
 
<much elided>
You're not helping the case for the "runs on Proposed Standards" claim
by changing the subject every time it's challenged...

> re-opening old debates that are long closed and irrelevant.

Not with a suitably-defined charter and an active chair.

> Moreover the 
> who created the protocol. 

Perhaps they would do a better job on the Security Considerations -- I 
note that 2616 makes no mention of "web bugs".

> six years and then come back expecting anyone to take notice of your

Presumably why the review period is 24 months, then annually.
 
> obsoleted by 2822 and 2821

If and when 2821/2822 successors reach Standard status, 821/822 will
be obsolete and presumably moved to Historic.  The fact is that now
much of the infrastructure and deployed UAs use 821/822.

> which are themselves becoming obsolete due to 
> deployment of Sender-ID

Widely rejected due to patent issues.

> and DKIIM.

Maybe, but unlikely.  Spam is a fairly difficult problem.

> At current rates of progress a clear  

Conjecture.  The real problem is that it isn't already a Standard more
than 4 years after publication of 2821.  Not for lack of implementations
or utility, but because the WG was dissolved before the work was finished.
 
> broken then I wonder what would.

I agree that as currently being managed, there is breakage,  But
vacuous claims that there is some vast number of Proposed Standards
bearing the bulk of Internet traffic isn't a cure.  If anything,
that myth is a large part of the problem.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html