Subject: [newtrk] I-D ACTION:draft-ietf-newtrk-decruft-experiment-00.txt

From: [email-masked]
Date: Tue, 13 Sep 2005 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the New IETF Standards Track Discussion Working Group of the IETF.

	Title		: Getting rid of the cruft: an experiment to identify obsolete standards document
	Author(s)	: E. Lear, H. Alvestrand
	Filename	: draft-ietf-newtrk-decruft-experiment-00.txt
	Pages		: 11
	Date		: 2005-9-13
	
   This memo documents an experiment to review and classify Proposed
   Standards as not reflecting documented practice within the world
   today.  The results identify three classes of documents marked as
   Proposed Standards that should be considered for retirement in some
   way or another.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-newtrk-decruft-experiment-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-newtrk-decruft-experiment-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-newtrk-decruft-experiment-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Sep 2005 16:51:22 +0200

Can working group members please comment on this draft?

Thanks,

Eliot

[email-masked] wrote:
> -------------------------------------------------------------------------
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> -------------------------------------------------------------------------
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is prohibited 
> by this policy. The attachment has been removed from this message and 
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email or 
> notifications from anti-virus systems. We will clearly mark a seperation
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
> 
> For further reference information about viruses and email antivirus 
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the full 
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html 
> 
> * This unique quarantine identifier: j8DN2qv0008973
> 
> If the matter is urgent, you may follow up by calling one of the below 
> referenced numbers. Please make every effort to provide the above 
> requested information via the support web tool prior to calling as it 
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc
.
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, 20 Sep 2005 12:00:15 -0500

> Can working group members please comment on this draft?

I'm not sure what flavor of commenting I should be doing, but

I agree that pruning our active standards list would be a good thing to do, 
especially if we can do it with little impact to ongoing standards work.

I agree that this draft matches my understanding and recollextion of what 
Newtrk did in this area.

I still believe Option 1 ("Accept the results of this experiment, issue a 
last call, and deprecate standards that remain on the list past last call. 
This is an aggressive approach that would preserve the intent of RFC 2026") 
is the right thing to do.

I believe Option 2 ("Do not accept the results of this experiment and update 
RFC 2026 to indicate a new practice") is impractical to the point of 
hallucination ("oh, all we have to do is update 2026. Why didn't *I* think 
of that?").

I believe Option 3 ("Revise the procedure based on the results of this 
experiment, based on feedback from the IESG") is admitting that we really 
can cycle forever while trying to garbage-collect, and if we choose this 
option, we should have chosen Option 4 instead.

I believe Option 4 ("Do nothing") is a final admission that our documented 
process doesn't matter and that's OK with us. And I mean "final" in the 
"fatal" sense.

So I think we should forward this document to the IESG for publication, 
recommending Option 1.

Thanks,

Spencer 

.

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Sep 2005 10:30:47 -0700

I agree with Spencer's conclusion.

If Option 4 is considered, it should be be applied to this document
itself (i.e., do not publish as RFC).

;-)

Joe

Spencer Dawkins wrote:
> I agree that pruning our active standards list would be a good thing to
> do, especially if we can do it with little impact to ongoing standards
> work.
> 
> I agree that this draft matches my understanding and recollextion of
> what Newtrk did in this area.
> 
> I still believe Option 1 ("Accept the results of this experiment, issue
> a last call, and deprecate standards that remain on the list past last
> call. This is an aggressive approach that would preserve the intent of
> RFC 2026") is the right thing to do.
> 
> I believe Option 2 ("Do not accept the results of this experiment and
> update RFC 2026 to indicate a new practice") is impractical to the point
> of hallucination ("oh, all we have to do is update 2026. Why didn't *I*
> think of that?").
> 
> experiment, based on feedback from the IESG") is admitting that we
> really can cycle forever while trying to garbage-collect, and if we
> choose this option, we should have chosen Option 4 instead.
> 
> I believe Option 4 ("Do nothing") is a final admission that our
> documented process doesn't matter and that's OK with us. And I mean
> "final" in the "fatal" sense.
> 
.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Sep 2005 10:43:08 -0700

> Can working group members please comment on this draft?

Option 1 is what I recall as the general consensus at the last  
meeting.  Option 1 provides a tangible benefit, so moving forward  
with a last call seems like the best choice.

-Doug
.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2005 15:31:52 +0200

Section 5 states the choice of option 1. To me it's clear that
if this reaches the IESG as is, and is approved by the IESG,
option 1 is thereby implemented.

As AD, I'm waiting to see what the WG thinks.

As an individual, I think this is ready for WG Last Call.

     Brian

Douglas Otis wrote:
> meeting.  Option 1 provides a tangible benefit, so moving forward  with 
> a last call seems like the best choice.
> 
> -Doug
> .

.

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 21 Sep 2005 19:34:04 -0700 (PDT)

> Can working group members please comment on this draft?

1.) I see that RFCs 1518 and 1519 are on the list of documents to be
obsoleted.  However, the new CIDR draft draft-ietf-grow-rfc1519bis
will request that status for those documents, along with RFC 1517
and several other obsolete CIDR documents.  Since RFCs 1518 and 1519
will be decommissioned in the normal way (i.e., with a new spec and
an explanation), they should be excluded from the bulk
decommissioning procedure.

2.)  Today I sent a message to the ietfmibs at ops.ietf.org mailing
list in order to alert the MIB folks of the plans to number of older
MIB documents to HISTORIC status, and Bert Wijnen forwarded that
message to the mib doctors's mreview list.  I also sent somewhat
more targeted messages to the RMONMIB and BRIDGE-MIB mailing lists
pointing out the plans to move RFCs 1513 and 1525 (respectively) to
HISTORIC.  I don't think there is a problem with any of the proposed
reclassifications, but I wanted to make a targeted audience aware of
the plans.  I asked folks to send their comments (if any) to the
Newtrk WG list or to the draft authors.

3.) Subject to the revisions requested in #1 (and any resulting from
#2), I would like to see this document go to IETF Last Call, and I
support moving all of the listed documents that have no defenders to
HISTORIC status.

//cmh

.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Sep 2005 15:34:49 +0200

With the group's permission I will make the changes in (1) below.  If I
learn of other changes based on (2) we can go through them if necessary,
but again, this is meant to be a conservative exercise.

Eliot

.