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

Joe Touch <touch@ISI.EDU> Sun, 12 September 2004 17:48 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 NAA00288; Sun, 12 Sep 2004 13:48:09 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6YWx-000537-MQ; Sun, 12 Sep 2004 13:52:51 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6YQH-0006yW-Me; Sun, 12 Sep 2004 13:45:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6YO7-0006kB-Tq for ietf@megatron.ietf.org; Sun, 12 Sep 2004 13:43:43 -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 NAA29842 for <ietf@ietf.org>; Sun, 12 Sep 2004 13:43:42 -0400 (EDT)
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6YSd-0004y1-TH for ietf@ietf.org; Sun, 12 Sep 2004 13:48:25 -0400
Received: from [192.168.123.143] (lsanca1-ar42-4-61-182-099.lsanca1.dsl-verizon.net [4.61.182.99]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i8CHfqJ21363; Sun, 12 Sep 2004 10:41:52 -0700 (PDT)
Message-ID: <41448A64.2090300@isi.edu>
Date: Sun, 12 Sep 2004 10:41:56 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kai Henningsen <kaih@khms.westfalen.de>
References: <66EDBDB3-0331-11D9-B4E7-000A95E35274@cisco.com> <050a01c497f6$567e4000$0400a8c0@DFNJGL21> <050a01c497f6$567e4000$0400a8c0@DFNJGL21> <41439AE7.6030703@isi.edu> <9GjynSJXw-B@khms.westfalen.de>
In-Reply-To: <9GjynSJXw-B@khms.westfalen.de>
X-Enigmail-Version: 0.85.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: 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>
Content-Type: multipart/mixed; boundary="===============0485596116=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43


Kai Henningsen wrote:

> touch@ISI.EDU (Joe Touch)  wrote on 11.09.04 in <41439AE7.6030703@isi.edu>:
> 
> 
>>Spencer Dawkins wrote:
>>
>>
>>>Dear Harald-the-General-AD,
>>>
>>>Can we PLEASE do as Melinda says - change the policy now for new drafts?
>>
>>That may have a chilling effect on new drafts. I.e., this isn't as
>>simple as "let's just change it now for future stuff".
> 
> "Chilling effect" - from *publishing* already-published material that's  
> already copied all over the net?

Authors might wait longer to "publish" IDs, since they'd be officially 
citable (once they're public, despite any instructions to the contrary 
in the body). They'd wait longer to submit, to collect sections, etc., 
rather than turning in half-written things with calls for additional 
material.

The other, attractive alternative is to bury the ISOC in ID versions, 
such that previous versions are individually basically useless.

...
> How would that effect work on material meant for RFCs, or for working  
> group work (where the list archives are already public forever)?

See above - that's exactly the point. It puts a 'wait, this is going to 
be published - is it ready for that?' hurdle in the loop, one that the 
ID process was designed to avoid.

> And if it works on some other kind of draft, would we actually care?
> 
>>IMO, changing the policy would indeed be "making the problem worse".
> 
> I have yet to see a coherent argument for that.

I have yet to see a coherent argument for keeping the ID series if it's 
archived publicly. Why do we need to see the entire process - in public 
- of editing and revision? And if we do, why do we need two separate 
series to do this?

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