+1
The reason I pushed to archive drafts was precisely because I was involved in a patent case and relying on private copies of mailing lists was really not at all satisfactory.
It is not actually unusual for an active draft to expire. This happens with some regularity with multi-draft bundles in late publication stage and cases where a draft is laid to one side while a WG looks at other things.
Expiring drafts comes from the same mentality that causes my idiot telephone provider to force me to listen to and delete old voicemails before listening to the new ones. Once upon a time, storage was expensive. One of my colleagues once built a room with 6TB of storage built out of 2GB drives (5 1/4 inchers). I am currently decommissioning my 6TB hard drives.
Times have changed. expiring drafts only makes work for people for no purpose.
On Sat, Dec 7, 2024 at 4:30 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 07-Dec-24 17:07, Christian Huitema wrote:
>
> On 12/2/2024 1:52 PM, Randy Bush wrote:
>> michael,
>>
>> perhaps some of your perceived ambiguities could be reduced by the
>> ietf returning to no longer playing git repo for us, and stop formally
>> archiving expired internet-drafts? after all, they are expired.
>
> We initially did that for a patent reasons -- having documented prior
> art is sometimes very useful, even if the prior are was in a draft. I do
> not think that reason has disappeared.
>
> Then, it is also very useful to examine the diff between successive
> versions. You call that "playing git repo", but i would rather have the
> archive on an IETF server than in a third party tool like GitHub.
+1. However, I'd like us to get rid of the "expires in six months" myth.
Because we *need* an I-D archive for IPR reasons and to meet the IETF's
goal of an open process, there really isn't any point at all to
artificial churn every 6 months. For active drafts, we get churn every
4 months (or less). Anyone can see the date on inactive drafts and draw
the appropriate conclusion. I like the fact that the tracker flips
the status to inactive after 6 months, but we can eliminate makework
churn by removing the word "expired" and the expiry warning messages.
BTW this is an IETF process discussion, not an RFC process discussion.
I've attempted to move it to the IETF list.
Can we do something with draft-thomson-gendispatch-no-expiry?
Brian
