Re: archives (was The other parts of the report....

John C Klensin <john-ietf@jck.com> Sat, 11 September 2004 23:16 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18067; Sat, 11 Sep 2004 19:16:02 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6HAa-00019y-LN; Sat, 11 Sep 2004 19:20:36 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6H3q-0002ly-FL; Sat, 11 Sep 2004 19:13:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6H3G-0002bK-Eh for ietf@megatron.ietf.org; Sat, 11 Sep 2004 19:13:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17915 for <ietf@ietf.org>; Sat, 11 Sep 2004 19:12:59 -0400 (EDT)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6H7c-000174-Mz for ietf@ietf.org; Sat, 11 Sep 2004 19:17:33 -0400
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1C6H35-000MaN-Vp; Sat, 11 Sep 2004 19:12:51 -0400
Date: Sat, 11 Sep 2004 19:12:51 -0400
From: John C Klensin <john-ietf@jck.com>
To: Carl Malamud <carl@media.org>, Ole Jacobsen <ole@cisco.com>
Message-ID: <EAB02FED496629E633EE4850@scan.jck.com>
In-Reply-To: <200409112048.i8BKmm6r013591@bulk.resource.org>
References: <200409112048.i8BKmm6r013591@bulk.resource.org>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Content-Transfer-Encoding: 7bit
Cc: scott bradner <sob@harvard.edu>, ietf@ietf.org
Subject: Re: archives (was The other parts of the report....
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: 7bit

Folks,

I'm not sure whether this puts me in agreement with Paul
Hoffman's "re-flogging" comment or not, but The Report was
presented to the community as not interacting with the Standards
Process at all.  Well, the issues about how to handle expired
I-Ds, whether or not they expire, etc., etc., are definitely
connected with the Standards Process.  So we either need to
redefine what the report, and discussions about the report, are
about, or this discussion needs to be taken into a distinctly
separate thread.

Just my opinion, of course.
   john


--On Saturday, 11 September, 2004 13:48 -0700 Carl Malamud
<carl@media.org> wrote:

> Ole -
> 
> I agree that the IETF has a special responsibility to properly
> present the archive ... we can't simply lay a big ftp
> directory out there and make no efforts to show how a
> particular file fits in context.
> 
> On the other hand, ietf.org could certainly beg/borrow/steal
> some of  the work being done in places like potaroo.net and
> watersprings.org.   Some things that could be done include:
> 
> 1. Add some clear text that explains the role of the i-d
> historical repository
> 
> 2. Link to previous and future versions of a draft (including
> any resulting  RFC)
> 
> 3. Link to any relevant mailing list discussions
> 
> 4. Find related drafts or place the draft in the context of a
> working group
> 
> 5. Add a very clear indication that the particular document in
> question is "Expired"
> 
> As to citing work-in-progress instead of the final standard,
> well, hmmm ... if we don't have our own repository, there
> isn't much we can do.  On the other hand, if a
> customer/reader/journalist were able to go to ietf.org and
> pull up the document in question, perhaps it could be really
> clear what the status is?  If we want to make clear that a
> document is expired, it is much better to say so rather than
> pretend it doesn't exist.
> 
> Regards,
> 
> Carl
> 
>> 
>> - Vendors are "stupid" and will claim compliance with a
>> work-in-progress document instead of a final standard. This
>>   is "very bad"
>> 
>> - Drafts often change along the way (including being
>> completely discarded as "bad ideas") and we should discard
>>   such snapshots in case someone gets the wrong idea from
>>   reading one.
>> 
>> Needless to say, I don't really buy these arguments. As
>> someone who publishes articles where the only existing
>> reference might be an ID at the time of writing, I believe
>> there are better mechanisms we could use (as we do with RFCs
>> and the "Obsoletes/Obsoleted by" tags).
>> 
>> Ole
>> 
>> 
>> 
>> Ole J. Jacobsen
>> Editor and Publisher,  The Internet Protocol Journal
>> Academic Research and Technology Initiatives, Cisco Systems
>> Tel: +1 408-527-8972   GSM: +1 415-370-4628
>> E-mail: ole@cisco.com  URL: http://www.cisco.com/ipj
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf