Subject: Re: [Tools-team] Draft submission authentication

From: Alex Rousskov <[email-masked]>
Date: Tue, 31 Aug 2004 16:31:30 -0600 (MDT)

On Tue, 31 Aug 2004, Allison Mankin wrote:

> Hi, everyone,

Hi Allison,

 	It is nice to hear a fresh voice :-). Just one quick 
clarification regarding your statement below, if I may.

> - The IETF also has pretty formally decided that it cannot retain
>  old drafts, and so a tool can't change the actual repository policy
>  without getting into modifying the standards process.  But I do
>  think a cvs-like and diff-supporting tool could be cool and
>  important.

Do you think that archiving older versions until the latest draft 
version expires would violate the above formal decision? Or, as a 
minor variation, archiving all unexpired versions of a draft? 
Providing an online "what has changed since I last checked" interface 
would be very useful, and I wonder if current IETF policies can 
accommodate that?

Does anybody know where is the non-archival policy for drafts formally 
documented?

Thanks,

Alex.

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: Allison Mankin <[email-masked]>
Date: Tue, 31 Aug 2004 16:44:40 -0700

Alex,

> would be very useful, and I wonder if current IETF policies can 

I like the idea of a working set, but I'm not sure of the upshot...

One idea would be for IESG (with input from the team) to propose 
the idea in one of the process experiment documents (draft-klensin-july14).  
The usefulness for working groups  would ground the discussion.

> Does anybody know where is the non-archival policy for drafts formally 

What I've seen happen with this question is citation of the section on
internet-drafts in RFC 2026, which fairly strongly implies no archiving 
because of the very specific way it treats i-d citation and because of its
description of expiration.

So it isn't formally *prohibited, but an IETF archive is impossible in the
sense that the IETF policy defines i-ds as necessarily shortlived.