Subject: [newtrk] new cruft draft due out today or tomorrow

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Sep 2004 14:52:55 +0200

Hi,

As promised Harald and I are publishing a new draft, that should be 
visible in the I-D directory today or tomorrow.  Based on this working 
group's feedback the changes include the following:

  - removal of any new status and use of Historic.
  - clarification of when a standard can be reviewed by the Committee
    (only after the 2026 timers expire and then it's only if the
     Committee decides to, and only for immature standards)
  - Limiting of review to that which is old and unused, or that which
    is old and dangerous where there is a clear standard alternative
    (that's really a subset as the first category).

The draft's biggest NON-goal is to 2nd guess the IESG.

The way I see it, there are three alternatives for this group:

  - Do nothing;
  - Adopt the aforementioned draft or one like it as a WG document
    with the idea of getting rid of old cruft.
  - Write an update to 2026 removing the timers.

My personal opinion is that the worst alternative is the first, because 
it belies reality, and every time the IETF belies reality we get into 
trouble (NATs and firewalls were a good example).

I believe we're proposing the best alternative because it helps the IETF 
  to document existing practice on the Internet.

The third alternative documents existing practice within the IETF and 
notably NOT the Internet.

Opinions?  Which would your choice be?

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Sep 2004 11:10:29 +0300 (EEST)

Quick read of -01 just published..

>   - removal of any new status and use of Historic.

There's still one instance of "Outdated"

>   - Write an update to 2026 removing the timers.

This draft already includes "Updates: 2026".  I believe this is 
unnecessary and could be removed?

A couple of comments:

 1. IMHO, the committee must produce a "bulk" informational RFC which 
explains the reasoning for each and every document which is made 
Historic.  We need to have that for historical and record-keeping 
purposes.  

This way there is no need for any process changes.  The committee
produces an I-D about RFCs they want to make historic.  This is
circulated on appropriate communities.  An AD shepherds the document,
issuing IETF last call.  The IESG considers the document.  If some
RFCs are not moved to historic, they are removed from the document.  
The document is sent to the RFC-editor, and when it's published, the 
RFCs listed in the doc are marked historic.

 2. This approach should be applicable for non-standards track
documents as well.  The easy way would be to just leave it up to the 
committee to decide what to do with those (if anything), but if RFCs 
on standards track are historized, then the RFC2026 timelines must 
have expired.

Editorial nits: 

 - remove the uppercase special keywords, they are not good for
process docs like this.
 - add Security Considerations
 - trim down the line lengths, there are 12 lines of 73 chars
 - (two already mentioned above: remove 'Updates: 2026', and the one 
Outdated left in the doc)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 15 Sep 2004 10:46:03 +0200

> Historic.  We need to have that for historical and record-keeping

Only if we believe the theory that all history must be recorded in RFCs.
This has never been true, and we shouldn't try to make it true.

See the document's comments about "xxx to Historic" RFCs.

(noted - I think we should make our archive of decisions a lot more easily 
searchable than the archives for the ietf-announce list currently are. 
Different topic.)

> RFCs listed in the doc are marked historic.

I see no benefit in adding this overhead.
Actually there has never been a requirement for an RFC to be published when 
something is made Historic; this is an invention based on practice, and was 
never part of RFC 2026. In my opinion, it is a bad practice, and should be 
abandoned. (should come as no surprise - that's why I wrote it in the 
document)

> on standards track are historized, then the RFC2026 timelines must

(naive question) Why should we (the IETF, as part of its standards process) 
do anything to those documents that are not on the standards track?

Thanks for the comments!

                             Harald
.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Sep 2004 13:59:43 +0300 (EEST)

> This has never been true, and we shouldn't try to make it true.

As far as I've understood, most technical decisions have been recorded 
as RFCs.  This should be as well, if not for other reason as to:

 1) be able to more easily develop community consensus on the wording 
of deprecation (in the form of I-D and its revisions)

 2) be able to document the honed consensus to someone who later on 
comes along and wants to know why this happened.  We might be able to 
cope with archives, if well-indexed, for this as well, but we'd always 
need to point out the people to those archives.  I'd hope RFCs would 
be sufficiently widely used to make such queries unnecessary.
 
> See the document's comments about "xxx to Historic" RFCs.

Yes, I noticed this.

The text basically argues that producing one RFC to make one RFC 
historic doesn't make sense.  I fully agree with that.

But you also seem to be making a conclusion that producing one RFC to 
make 100 RFCs historic doesn't make sense.  I disagree completely.  It 
makes IMHO perfect sense to me.  That's the only way we can do this 
reasonably, because we have to achieve consensus on moving stuff to 
historic, and there is no better way to do that than through I-D 
development process.

> searchable than the archives for the ietf-announce list currently are. 

If we manage that, and get good results out of it, then maybe this
approach would be possible, but today (and probably in the next 6
months) I disagree.

> Actually there has never been a requirement for an RFC to be
> published when something is made Historic; this is an invention
> based on practice, and was never part of RFC 2026. In my opinion, it
> is a bad practice, and should be abandoned. (should come as no
> surprise - that's why I wrote it in the document)

I just have to disagree.  Building consensus practically requires 
writing an I-D, and revising it to take different input into account.  
If we already have documentation, why not just turn it into RFC.

We may have different assumptions in mind: I assume that such a
committee would propose to historicize 50 or 100 RFCs at the same
time, maybe once or twice a year, not a couple documents every week or
month.

This effort is very much comparable (IMHO) to
draft-ietf-v6ops-ipv4survey-XXX (now RFCs).  Both went through a lot
of RFCs in more or less detail, and somehow wanted to report and
record the results.
 
> do anything to those documents that are not on the standards track?

Because the IETF also produces BCP's, Informational and Experimental
documents which may be equally (or even more so) misleading.  
(Consider, for example, outdated applicability statement (Info) for a
historicable standards track document.)

Standards Track should be the focus, but I see nothing why we should
be excluding the rest from the process.  The issues are the same,
except that there are no RFC2026 language to already require doing
that.

.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Sep 2004 14:19:43 +0200

Pekka,

You write:

> Building consensus practically requires 

If your premise holds true then I MAY or MAY NOT agree with you. 
However, the draft takes into consideration two types of standards: 
those that are most obviously old and crufty, and those that aren't. 
The former should not require all that much out of anyone.

For the other, we may disagree.  I don't know.  You may even be right.
My solution to this problem is simple: let's run an experiment and see 
what happens.  I think an experiment also allows for Margaret to see 
whether her concerns are borne out.

Eliot
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 15 Sep 2004 14:53:36 +0200

--On onsdag, september 15, 2004 13:59:43 +0300 Pekka Savola 
<[email-masked]> wrote:

> as RFCs.

Nope.

All the NEGATIVE decisions (not to publish something) have never been 
published as RFCs.

Nor have WG decisions (chartering, rechartering, closure) ever been 
recorded as RFCs.

Nor have decisions to push documents up the standards track without 
republication been recorded as RFCs - neither the fact nor the 
justification (interoperability reports and so on).

Only the protocols themselves have (mostly) consistently been recorded as 
RFCs.

>  This should be as well, if not for other reason as to:
>

While I should never speak ill of community consensus.... if we need to 
develop community consensus on these decisions, it's outside the scope the 
committee should address. It's either obvious or it's not - and if it's not 
obvious, the committee is not the right forum for depreciation.

> be sufficiently widely used to make such queries unnecessary.

Same argument as above.

> historic, and there is no better way to do that than through I-D

For the 100 documents case, we have to document that there is no usage, and 
that the search for usage was adequate.
That's not consensus process. And not what we usually publish as RFCs.

>> (noted - I think we should make our archive of decisions a lot more
>> easily  searchable than the archives for the ietf-announce list
>> currently are.  Different topic.)
>

Same argument turned around: If we have the documentation (which will 
mostly be lists of queries sent and archives of responses coming back), and 
we have adequately archived it and made it accessible, why bother pulling 
it into RFC format and spending publishing cycles on it?

> of RFCs in more or less detail, and somehow wanted to report and

That particular effort took one person's PAID efforts from April 2000 
(draft-ietf-ngtrans-ipv4survey-00) to (almost) today - more than four 
years. (OK - far from full time, and VERY reasonable rates. Still - paying 
him was the only way the job got done.)
If you're looking for a lightweight, reasonably fast process to copy, that 
one is NOT one I should like to use as a model.

>> (naive question) Why should we (the IETF, as part of its standards
>> process)  do anything to those documents that are not on the standards
>> track?
>

Apart from "let's see if we can get the essential stuff done before we do 
the optional stuff", I kind of sympathize.

Nit - ASes are supposed to be standards-track, not Informational. See RFC 
2026. However, some "applicability statements" are not what 2026 envisioned.

                          Harald

.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Sep 2004 09:10:06 +0300 (EEST)

Hi,

I think Scott raised my concerns pretty well.  We need to document the
reasons why we withdraw something.  If it's obvious like "nobody is
using it anymore", then documenting that would be trivial and we'd be
done.  I'm just worried that when there is a disagreement whether
something should go or not, or the reasons for that deprecation, these
WILL need to be written out properly.

As to Eliot's, "let's just run the experiment and see", I agree.  I
would just like to run the experiment properly, and that could also be
input whether it's feasible to write one RFC per 100 historic
documents, whether it's feasible to consider anything but "has been
rotting in a corner for at least 10 years", etc. -- if we don't try
these, we won't know, and experiment doesn't give us nearly as much
useful input for the future.  That would be undesirable.

Further inline,

> Nor have WG decisions (chartering, rechartering, closure) ever been 

These are IMHO not comparable.
 
> justification (interoperability reports and so on).

This is seems somewhat comparable, but it's kind of understandable, 
because interop reports etc. include a lot of timely vendor-specific 
information which may or may not be useful as RFCs.
 
> Only the protocols themselves have (mostly) consistently been recorded as 

Yes, and now that we want to remove them from the standards track (or
whatever track), it would seem to make sense to document the reason
"why?".  The reason may be obvious, but such reasons are very easy to
write down.
 
> obvious, the committee is not the right forum for depreciation.

Let's see.

1) There is a class of RFCs which are probably obvious, and the
reasoning can be documented in just one sentence or paragraph.

For example, maybe something like RFC 891 ("IP over DCN"), RFC 895
("IP over experimental Ethernet") [though these are full standards,
but could be likewise historized if the scope was more generic..]

2) There is a class of RFCs which can equally be documented in one or
so paragraphs, but there is likely going to be some debate on the
wording used.

For example, possibly RFC 1209 ("IP over SMDS"), RFC 951 ("BOOTP"),
RFC 2067 ("IP over HIPPI")

3) Then there is a class of RFCs which probably require at least a
couple of paragraphs of text [wordsmithing] (everyone still agrees
that it makes sense to make these to historic), but are still fairly
trivial to make historic.  An example of this is
draft-ietf-idr-rfc1863-historic-00.txt, probably the RIPv1 and LDAPv1
to historic RFCs, etc.

4) Then there is a class of RFCs where getting community consensus on
whether to make historic or not would take quite a while, because
there is no unanimous or very clear consensus to do that.  I think we
both agree that the committee should not be working on these RFCs.

I argue that having all 1), 2), and 3) could be useful, but the 
committee could obviously decide to work on the easier cases first, 
e.g., 1) and 2).  But if those are so trivial, producing an I-D and 
RFC to document those trivial reasons shouldn't be such a big deal?

The benefit here would also be that by tackling all of 1)-3) the 
amount of "request rfc xxx to be moved to historic" -RFCs should 
decrease, reducing the quoted unnecessary load.
 
> For the 100 documents case, we have to document that there is no
> usage, and that the search for usage was adequate. That's not
> consensus process. And not what we usually publish as RFCs.

You can always find *someone*'s old system gathering dust in a corner 
which still implements Foo or Bar.  There is no 100% sure way to be 
certain of whether something is used or unused (heck, just trying to 
define what you mean by those would be a challenge).

Hence, I don't see this as so black and white.  If it's obvious, it's 
trivial to document.  If it's not obvious, it should still be 
relatively straightforward to document, and if not, then it could just 
be dropped or de-priorized.
 
> it into RFC format and spending publishing cycles on it?

Because, at least,
 - that'll provide more visible (and easily found) record on it,
 - that's more natural for people to comment during IETF last call and 
requires no new policies,
 - if the issues are so trivial, turning it to an RFC and publishing 
it are equally trivial

It's much better to write this out as an I-D and request last call on 
it than just compile a long list of email threads or just one huge 
email summarizing the different queries and proposed resolutions.

I-Ds is what we're used to dealing with, and I see very few problems
with it.  Producing an I-D is a trivial exercise if you already have
the data.
 
> one is NOT one I should like to use as a model.

Maybe I was careless in using that example -- what I tried to refer to
was the process in how the results were documented (and personally,
that was a lousy job) [FWIW, the actual RFC reading took way less than
that, the rest of the time the documents were just sitting idle].

Here, we don't want to have to read the RFCs we want to make historic;
just look at the headlines and be done.
 
> the optional stuff", I kind of sympathize.

Yep, which is why we should not exclude the other kinds of RFCs from 
the committee.  There could be recommendations on which ones to 
(generally) look at first, or we could leave that up to the discretion 
of the committee and its steering group (if any).
 
> 2026. However, some "applicability statements" are not what 2026 envisioned.

Counter-nit: such protocols couldn't advance past PS if the AS was PS,
unless AS was advanced at the same time. (Looking at the status from
RFC-editor search page, it seems there are a couple of standards track
AS's and a bit over a dozen Informational AS's.)

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Sep 2004 08:23:29 +0200

--On torsdag, september 16, 2004 09:10:06 +0300 Pekka Savola 
<[email-masked]> wrote:

>> Only the protocols themselves have (mostly) consistently been recorded
>> as  RFCs.
>

Pekka,

you and I are in perfect agreement that the reasons must be published, and 
the publication of the reasons must be archived.

But you keep on insisting that these be published *AS RFCS*. I keep on 
insisting that this is not only unnecessary, it is a departure both from 
current rules and current practice with comparable decisions.

Please make sure you argue against what I disagree with, and not against 
what I agree with.

But I'd like to hear other voices here too. I think Pekka and I have made 
our opinions very, very clear by now...

                          Harald

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Sep 2004 08:36:35 +0200

--On torsdag, september 16, 2004 09:10:06 +0300 Pekka Savola 
<[email-masked]> wrote:

>> Nit - ASes are supposed to be standards-track, not Informational. See
>> RFC  2026. However, some "applicability statements" are not what 2026
>> envisioned.
>

The way 2026 described ASes, ASes would refer to the protocols; the 
protocols would not refer to the AS. So the protocol could advance; 
certainly OSPF has managed to advance while leaving its applicability 
statement (RFC 1370) behind....

The following RFCs have "applicability statement" in their title:

1370 Applicability Statement for OSPF. Internet Architecture Board, L.
     Chapin. October 1992. (Format: TXT=4303 bytes) (Status: PROPOSED
     STANDARD)

1517 Applicability Statement for the Implementation of Classless
     Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R.
     Hinden. September 1993. (Format: TXT=7357 bytes) (Status: PROPOSED
     STANDARD)

1722 RIP Version 2 Protocol Applicability Statement. G. Malkin.
     November 1994. (Format: TXT=10236 bytes) (Also STD0057) (Status:
     STANDARD)

1923 RIPv1 Applicability Statement for Historic Status. J. Halpern, S.
     Bradner. March 1996. (Format: TXT=5560 bytes) (Status: INFORMATIONAL)

2005 Applicability Statement for IP Mobility Support. J. Solomon.
     October 1996. (Format: TXT=10509 bytes) (Status: PROPOSED STANDARD)

2081 RIPng Protocol Applicability Statement. G. Malkin. January 1997.
     (Format: TXT=6821 bytes) (Status: INFORMATIONAL)

2333 NHRP Protocol Applicability Statement. D. Cansever. April 1998.
     (Format: TXT=20164 bytes) (Status: PROPOSED STANDARD)

2721 RTFM: Applicability Statement. N. Brownlee. October 1999.
     (Format: TXT=21200 bytes) (Status: INFORMATIONAL)

3197 Applicability Statement for DNS MIB Extensions. R. Austein.
     November 2001. (Format: TXT=8610 bytes) (Status: INFORMATIONAL)

3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels.
     D. Awduche, A. Hannan, X. Xiao. December 2001. (Format: TXT=17691
     bytes) (Status: INFORMATIONAL)

3213 Applicability Statement for CR-LDP. J. Ash, M. Girish, E. Gray,
     B. Jamoussi, G. Wright. January 2002. (Format: TXT=14489 bytes)
     (Status: INFORMATIONAL)

3257 Stream Control Transmission Protocol Applicability Statement. L.
     Coene. April 2002. (Format: TXT=24198 bytes) (Status: INFORMATIONAL)

3346 Applicability Statement for Traffic Engineering with MPLS. J.
     Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S.
     Lai. August 2002. (Format: TXT=33754 bytes) (Status: INFORMATIONAL)

3410 Introduction and Applicability Statements for Internet-Standard
     Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart.
     December 2002. (Format: TXT=61461 bytes) (Obsoletes RFC2570) (Status:
     INFORMATIONAL)

3612 Applicability Statement for Restart Mechanisms for the Label
     Distribution Protocol (LDP). A. Farrel. September 2003. (Format:
     TXT=35677 bytes) (Status: INFORMATIONAL)

3638 Applicability Statement for Reclassification of RFC 1643 to
     Historic Status. J. Flick, C. M. Heard. September 2003. (Format:
     TXT=8676 bytes) (Obsoletes RFC1643) (Status: INFORMATIONAL)

On scanning, for instance, RFC 3257, I find that it gives introductory 
material and advice - nothing that looks like a requirement anywhere.

But so does RFC 1722 (RIPv2), and it is not only standards-track, but full 
standard..... in fact, if you take away the "introduction to RIPv2" 
material, RFC 1722 might be a model for the John/John "this is what the 
standard consists of" document....

Perhaps "applicability statement" is a term for which we need an 
applicability statement....?

                          Harald

.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Sep 2004 15:12:25 +0200

Well, I am the cause of a cruft case that will be on Harald's reading
list soon, having submitted draft-carpenter-obsolete-1888-01.txt
a few minutes ago.

There are 27 substantive lines of text explaining why RFC 1888
is both OBE and broken, and 11 lines saying what the IESG,
the remaining OSI proponents, and the IANA should do next.

On the one hand, 38 lines is a bit light for an RFC. On the other
hand, this information clearly needs to be published somewhere,
since RFC 1888 is cited surprisingly often. For the moment,
another RFC is the only tool we have.

    Brian

Harald Tveit Alvestrand wrote:
> you and I are in perfect agreement that the reasons must be published, 
> and the publication of the reasons must be archived.
> 
> But I'd like to hear other voices here too. I think Pekka and I have 
> made our opinions very, very clear by now...
> 
>                          Harald
> 
> 
> .
.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Sep 2004 15:26:40 +0300 (EEST)

I've been waiting for follow-ups on this, but as only Brian has stated 
something...

> the publication of the reasons must be archived.

OK.
 
> current rules and current practice with comparable decisions.

My argument for doing it as RFCs is that that for the trivial cases,
it's also a trivial exercise -- extremely light load.  For non-trivial
cases, it's slightly more work, but that's why the cruft committee
would have the option to decide which RFCs it wants to tackle.  If
they only did "trivial" cases, the documentation would also be
trivial.  If they also did non-trivial cases, the appropriate
documentation would still be possible.

The technologies are archived as RFCs.  I don't see why we shouldn't
or couldn't document the reasons for retiring those technologies as
RFCs as well.

.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 30 Sep 2004 23:30:25 -0400

Ok, here's another voice weighing in.

Consider how we move protocol documents FORWARD in the standards track.

   1)	Sometimes we issue new versions of an RFC while moving the
	protocol forward.
   2)	Sometimes we just recategorize an RFC.

However we DON'T publish:

    *	The reasons we think the RFC can be moved forward.
	These are discussed in mailing lists, which are usually archived
	somewhere.

    *	The interopability reports associated with how
	the protocol works between implementations
	These are discussed in mailing lists and sometimes published on
	web sites.

Note, we do NOT require an RFC that simply says "let's move RFC forward 
in status because of such and such."

Now consider the situation of moving a document to obsolete or historic, 
which are just other statuses on the standards track. Obviously there's 
no need to republish the actual RFC that's being downgraded.

Now, think about the why's and wherefor's of WHY the RFC is being 
downgraded.

Do we need to discuss why the action is being done? Absolutely. And this 
should be done in various mailing lists.

Do we need to publish yet another RFC just to say why we're changing the 
status of that RFC? Absolutely NOT.

To summarize, I have a serious problem with publishing any such 
documents as RFCs.

Here's an alternative suggestion for consideration on WHERE to put a 
summary of why an RFC was downgraded. 27 lines is sufficiently small 
that it could actually be stored in rfc-index.xml.

	Tony Hansen
	[email-masked]

Brian E Carpenter wrote:

>> insisting that this is not only unnecessary, it is a departure both 
>> from current rules and current practice with comparable decisions.
>>
>> Please make sure you argue against what I disagree with, and not 
>> against what I agree with.
>>
.