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

[Phillip Hallam-Baker <[e-mail]>]

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.