Subject: [newtrk] FWD: I-D ACTION:draft-klensin-newtrk-antiques-00.txt

From: John C Klensin <[email-masked]>
Date: Thu, 27 May 2004 10:23:27 -0400

For whatever it is worth, this document is a first cut at the 
"let's get what should be promoted, promoted" specification that 
I promised as the complement to Eliot's/Harald's draft on 
cleaning up the history.

It really addresses the other end of the process from the one 
Scott wants to concentrate on -- from my point of view, more 
clarity and specificity about what we really want out of 
Proposed would benefit either of this pair of proposals.  In 
that sense, this document is an attempt to address the next-step 
question or what our real expectations are for Draft/Full and 
whether those expectations are mostly about the protocol (and 
its usefulness, deployment, interoperability, etc) or mostly 
about the documents.

    john

Subject: I-D ACTION:draft-klensin-newtrk-antiques-00.txt
From: [email-masked]
To: [email-masked]
Date: Tue, 25 May 2004 11:03:43 -0400
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Valuable Antique Documents: A Model for Advancement
	Author(s)	: J. Klensin
	Filename	: draft-klensin-newtrk-antiques-00.txt
	Pages		: 8
	Date		: 2004-5-24
	
RFC 2026 and some of its predecessors require that Proposed and Draft
   Standards either advance in grade within a reasonable period of time
   or that they expire and be moved to Historic.  That procedure has
   never been followed on a systematic basis.  A new procedure has been
   proposed that would make that action easier for protocols that have
   not gotten any real acceptance.  In the interest of symmetry,
   fairness, and an orderly attic, it is worth noting that there are a
   number of protocol descriptions which have been at less than Full
   Standard level for a long time but which have proven their value by
   the traditional criteria of multiple interoperable implementations
   This document provides a procedure for upgrading such documents to
   Full Standards without creating an unreasonable burden on authors
   purely to meet the needs of procedural rituals or placing an
   unreasonable load on groups charged with performing other tasks in
   the IETF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-klensin-newtrk-antiques-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-klensin-newtrk-antiques-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-klensin-newtrk-antiques-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.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

---

From: Larry Masinter <[email-masked]>
Date: Fri, 28 May 2004 03:00:48 -0700

I believe that we can improve IETF processes more effectively by
focusing on finer granularity ways of improving the information
about documents once they've been published, and supporting the
development of that information with appropriate tools. This isn't
inconsistent with the current attempts to tweak the "big labels"
of the state transition diagram, (giving new names to the nodes,
creating new processes for state transition), but I'd like
to encourage you to also think about some of the finer-granularity
processes:

* Implementation reports
I'd like to see a more formal, supported and standardized way
of maintaining and tracking information about implementations
and their deployment status.  The most serious question about
existing standards track documents are: who implements this,
which features are implemented, which ones have been tested
as interoperable.

While this is currently a requirement (more or less) for
Draft Standard status, the information is useful for
Proposed Standard, too. And many of the judgements (about
whether something is historic, etc.) will depend on this
information.

Can we create a better, standardized way in which someone can
post information about implementations?

* Errata
While there are now standard errata pages for noting errors
in existing documents, there is no documented process around
errata. How can someone raise an issue, even if they don't
yet have a solution? Who is authorized to submit an errata?
What is the process for tracking errata.

Understanding the state of implementations and errata
to the documents seem like they could be usefully supported
for life-after-proposed.

In addition, some other simple bookkeeping things would
be very helpful.

* Mailing lists
Over the years, the hosts supporting individual mailing lists
have gone away for many of the working groups I've been
associated with. ([email-masked]?) 

Mailing lists should remain open and archived accessible 
forever. I think this means some IETF resources applied
to doing this.

If you have a question about an RFC or protocol, it's sometimes
hard to find the mailing list on which to discuss it, raise the
issue, etc.  I know about the mailing lists for standards I've
participated in, but have difficulty figuring out where the
current list & archive are for other standards track documents.

Larry

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