Subject: Re: [Gendispatch] Internet-Drafts Don't Expire

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Nov 2019 11:37:23 -0500

Thinking the issues through since the meeting, I think this could
potentially save a huge amount of time at all levels in the IETF.

The question that came to me on the plane back was 'how many documents have
to be put through IETF process purely to stop them expiring?'

Steve Crocker's original concept for the RFC series was that it would be a
kitchen sink of rough thoughts and design sketches capturing as much
information as possible. But RFCs started tracking operational details such
as port assignments and link info which required editorial consideration.
The tensions between these two notions had led to the IEN series being spun
out in 1977 as an attempt to separate the streams. Publication of RFC821/2
kind of put paid to the 'design sketch' as a sustainable notion. RFC became
a brand. The EIN series was discontinued as Jon did not want to edit two
different streams.

We can argue about the history if people must. But my main point here is
that the Internet has completely changed our concept of publication since.
Back in the 1980s, the concept of publication was embedded in a set of
cultural values that I and others of my generation understand but are
completely alien to the youngsters. They are natives to this land we have
created, we are the immigrants.

The biggest objection made to ending expiry of IDs was that it might lead
to a reduction in draft quality as people might not bother submitting their
drafts for processing by IESG etc.

Is that really an objection though? Reducing the number of drafts the IESG
is required to read could be the ideal outcome if it is the right drafts
that are dropped.

It is my belief that design considerations have no place in a normative
document. They result in confusion and ambiguity. See: 'A well regulated
militia'. It is important to capture use cases and requirements but they
should not be presented in a normative document.

Test vectors are another tricky area. When writing code, the more test
vectors I have, the better. But unless the IESG are going to implement the
spec and run the test vectors for themselves, they are really not going to
be able to review them.

I believe that there is a wealth of supporting material that could be
captured in the IETF process that really has no need of a document shepherd
or IETF review.

Of course, there is always the risk that someone might try to pass off an
ID as an IETF standard because that is already happening. If this is a
concern, we should have a rule that only drafts accepted as AD Sponsored or
WG drafts can be listed as 'Standards Track'.

But that really doesn't worry me very much because the only standards that
matter are the ones people use. There are plenty of IETF standards that
have been published as RFCs that have died the death and there are plenty
of folk out there on the net who have found that a project has morphed into
a de-facto standard that they do not have either the means or the
motivation to maintain.

Consider what might have happened if one of the early markdown efforts had
been written up and published as a permanent Internet draft early on. It
might not have prevented the needless proliferation of markdown schemes but
it would have allowed those people who wanted to try to avoid divergence to
do so. So what some people are presenting as nightmare scenario looks more
like a beneficial situation to me. The document author gets to hand off
change control. The IETF gets the option to take it up should it choose to
do so.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2019 08:26:14 +1300

> The question that came to me on the plane back was 'how many documents have to be put through IETF process purely to stop them expiring?'

None. Since expired documents are available for ever, there is absolutely no point in "refreshing" a draft with no changes except the date. People do so, but I'm not sure why. I quite often cite https://tools.ietf.org/html/draft-carpenter-aeiou-00 when people propose alternatives to IPv6, as an example of a failed solution.

Regards
   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Nov 2019 14:34:29 -0500

As a working group chair, I do expect the editors of WG drafts to 
refresh them.  This tells me that they are continuing to participate, 
and I do not need to find a new editor (or, conversely, that I do need 
to find a new editor.)  Yes, I could set calendar reminders and send 
email of my own.  For WG drafts, I think the expiration is useful to 
help folks get a more accurate image from the WG page.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2019 10:45:57 +1300

Joel,

To be clear, I'm in favour of applying "ain't broke, don't fix" to this.
I agree that 6 months of inactivity is a useful trigger. However, an update
where *only* the date changes isn't much use, IMHO. It tells you that the
editor is still active, but it adds no value to the draft.

Regards
   Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2019 17:31:53 -0500

On 11/26/19 2:26 PM, Brian E Carpenter wrote:

> None. Since expired documents are available for ever, there is absolutely no point in "refreshing" a draft with no changes except the date.

It's been my experience that expired I-Ds are not taken as serious 
proposals; that renewing an I-D even with minor changes provides some 
indication that a draft is still being maintained; and that this is a 
useful if somewhat imprecise metric.

So I'm opposed to eliminating expiration dates on I-Ds.   I think it's 
an example of action bias that requires a significant amount of work to 
accomplish nothing useful.

Keith

p.s. OTOH, if we had the idea to set up some new kind of document that 
is a living document, subject to continuous modification, but with a 
mechanism to take snapshots and cite them, I might be in favor of 
that.   Even better would be if such documents were editable via an 
etherpad-like mechanism, and authors/editors never had to deal with xml2rfc.