Subject: Re: [newtrk] Re: updated draft on cruft / draft-alvestrand-newtrk-cruft-00.txt

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 01 Sep 2004 22:51:17 +0200

--On 31. august 2004 21:06 -0500 Spencer Dawkins <[email-masked]> 
wrote:

> I'll wait, and not go out on a limb with my prediction that there are no
> counter-examples, but if we don't end up deciding that reclassification
> will not affect what's running on the Internet today in any significant
> way, I'll be AMAZED...
>
> I DO like "cleaning out the cruft/obsolete/historical/whatever", but
> that's because it makes it easier for people to newly implement and
> deploy what is left over, not because I have any poorly-justified faith
> that people will turn anything off or upgrade anything because we
> reclassified something obsolete, especially if we don't also reclassify
> anything as obsolete-and-dangerous.

I'll just repeat what I've said before.... if we don't (somehow) move stuff 
to Historic when it's not being used at all, we should abandon all pretense 
that we do so.

If it has any effect, it will be on the takeup of what's left (because it's 
easier to see what makes sense and what can be safely ignored), not on the 
retirement of what's being reclassified.

BTW: I'm happy if we have a "cruft" document without the new "obsolete" 
classification. It was worth having the WG discuss it rather than have the 
document authors decide on their own - but my current reading is that the 
WG is more comfortable with just using the Historic label for the documents 
that are no longer on the standards track.

                      Harald

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 01 Sep 2004 21:05:54 -0700

At 01:51 PM 9/1/2004, Harald Tveit Alvestrand wrote:
>BTW: I'm happy if we have a "cruft" document without the new "obsolete" classification. It was worth having the WG discuss it rather than have the document authors decide on their own - but my current reading is that the WG is more comfortable with just using the Historic label for the documents that are no longer on the standards track. 

I prefer not to induce a new classification.  To me, a Historic
document is simply one which is no longer on a standards track.
The status says nothing about the dangers (if any) of the
specification.  As far as those who think Historic implies
"Dangerous", I ask, does non-Historic mean not Dangerous?

Kurt 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Sep 2004 10:39:23 +0200

Margaret Wasserman wrote:
(under a different subject header)

> Do others have counter-examples where the reclassification of RFCs would 
> have some sort of positive effect on real-world implementations or 
> deployments?

I think the answer is probably no (at least nobody has given a convincing
example yet) and it's a clear consequence of the fact that non-IETF people
mostly do not distinguish among types of RFC.

That's why I believe the most powerful tool we could implement, which
does *not* require any change to the standards process, is an alternative
to http://www.rfc-editor.org/rfcxx00.html that combines Standards, Draft
Standards and Proposed Standards in a single Current Standards table
(i.e. one where SMTP would lead you to RFC 2821 not to STD 10, etc.)

Such a web page would become one-stop shopping for IETF standards,
and wouldn't require a degree in IETFology.

     Brian
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 3 Sep 2004 06:34:29 -0500

From: "Brian E Carpenter" <[email-masked]>

>> Do others have counter-examples where the reclassification of RFCs 
>> would have some sort of positive effect on real-world 
>> implementations or deployments?
>

Sigh. Agree with Brian. I'm wondering what changes we actually need to 
the standards track if we focus on a design for this alternative web 
page first...

As Brian points out, not only does this not require a New Standards 
Track, it doesn't even require a July 14 experiment.

Is there anything NEWTRK can do, to help this happen? Is the John and 
John draft going to provide this, or is it related-but-not-the-same?

Spencer 

.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 3 Sep 2004 12:26:26 -0400

Hi Brian,

>(i.e. one where SMTP would lead you to RFC 2821 not to STD 10, etc.)

I completely agree.

We should think about how non-IETF-ers find IETF standards and make 
it the path of least resistance to find the right one -- where right 
== the one that the IETF currently things you should implement.

If the IETF believes that is important that the WGs and IESG have 
some control over what is listed as a single standard on these pages, 
then this could also tie in with the ideas, but not the details, of 
the various named standards proposals (from Harald, John L. and John 
K.).

>and wouldn't require a degree in IETFology.

Excellent.

How could we organize to do this?

Margaret

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 2004 11:56:03 +0200

Margaret Wasserman wrote:
> We should think about how non-IETF-ers find IETF standards and make it 
> the path of least resistance to find the right one -- where right == the 
> one that the IETF currently things you should implement.
> 
> If the IETF believes that is important that the WGs and IESG have some 
> control over what is listed as a single standard on these pages, then 
> this could also tie in with the ideas, but not the details, of the 
> various named standards proposals (from Harald, John L. and John K.).
> 

Nobody answered that... I'm wondering whether someone from the RFC Editor
side of the house can comment on feasibility, since they already
maintain the existing page referenced above.

    Brian
.

---

From: Aaron Falk <[email-masked]>
Date: Thu, 16 Sep 2004 14:39:40 -0700

> maintain the existing page referenced above.

Brian-

Sorry for the slow response.  So many lists, so little time....

I have to admit that I don't understand, from the short description you 
give above, exactly what you are thinking of.

We've discussed -- and I've seen a lot of support for -- a web page 
thingee which shows the inter-relationship of documents on a particular 
technology, e.g., TCP.  This might include works-in-progress as well as 
standards I suppose.  Either way, putting the first map together is a 
major effort which needs to be performed by people very familiar with 
the technologies in question.  For example, new standards update only a 
portion of older standards, sometimes only under certain circumstances.

However, I don't think this is what you have in mind.  It *sounds* like 
you'd like to see a web page that groups RFCs -- regardless of category 
-- together under some technology label.  I don't really understand how 
one would do this and either not restrict oneself to trivially simple 
cases or end up doing the first thing (which I've heard called a 
'roadmap').  But I'm guessing that I don't fully understand what you 
have in mind.

If you (or Margaret or anyone) could expound on it a bit more, I'd be 
happy to give some RFC Editor perspective.

--aaron

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Sep 2004 16:29:32 +0200

Aaron,

> happy to give some RFC Editor perspective.

I had in mind something simpler than requiring full analysis of every
RFC about a particular topic.

RFC 821 is listed as obsoleted by RFC 2821. So when you look for the standard
called SMTP, you should be led to 2821 not to 821. That doesn't require
analysis - it is already explicit in the official RFC index. Any STD document
that is obsoleted or updated by DS or PS, and any DS that is obsoleted or updated
by a PS, should be trivial to identify. The necessary hyperlinks are actually
almost there, right in the RFC index:

0821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Format:
      TXT=124482 bytes) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also
      STD0010) (Status: STANDARD)

2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001.
      (Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869)
      (Status: PROPOSED STANDARD)

It's mechanical from that to identify 2821 as the valid document for
the protocol formerly known as STD0010. It should possible to write
a script to generate HTML with pointers to latest versions regardless
of whether they are STD, DS, or PS.

    Brian

     Brian

.

---

From: Aaron Falk <[email-masked]>
Date: Fri, 17 Sep 2004 08:25:04 -0700

Brian-

Take a look at http://www.rfc-editor.org/rfc-index2.html and see if 
this is what you are looking for.

--aaron

.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Sep 2004 11:04:51 +0200

Aaron,

Aaron Falk wrote:
> Take a look at http://www.rfc-editor.org/rfc-index2.html and see if this 
> is what you are looking for.

That's part of it - it shows that the "obsoletes" and "updates" information
in the RFC index can be translated into hypertext terms. For the rest of my
answer, see my response to Bob that I'm about to type...

Thanks
     Brian
.