Hi Lars,
While the draft is much improved, I still have one major and one minor issue that I think should be addressed before considering publication.
I will start with the minor issue: changing the language from expired to inactive is not helpful, and defeats the purpose of the notion of a "draft". The plain English definitions of "draft" and "expired" accurately reflect a draft's proper use: as something that is not finished and is intended to be temporary. "Expired" implies that the draft should no longer be considered fit for purpose, just as an expired driver's license indicates that it is no longer valid for permission to be on the road. I wouldn't suggest gumming up the works were this the only point, but it's not.
While it is understandable that expiration of certain drafts should at least be delayed, as is already the case with works that have entered the RFC publication queue, not expiring works that have no clear value in our own processes creates incentives for abuse and misuse. Furthermore, the justification that we should do this to permit reference by IANA can lead to interoperability problems. I have previously detailed both on the no-draft-expiry mailing list, and will do so here for the benefit of others:
- We occasionally see drafts that are misrepresented as our
works. Creating a stable reference will encourage that abuse
and contravene our own messaging that drafts are not works of
the IETF and should not be taken as such: if it's sitting on our
disks in our name space (and a draft is in the IETF namespace
whether it contains "-ietf-" or not as far as anyone else is
concerned). We have spent decades educating people not
to do this, and most people do not. I won't claim it
doesn't happen, but it is not a regular practice. I have not
seen any drafts in customer RFPs and government
documents in over a decade, with the small exception of those
that had already been approved for publication. I've seen ONE
recent instance in an external standards document, and they are
now regretting it. Because...
- Reference to unfinished works can lead to interoperability
problems. This would have happened with each and every draft I
have ever written and read, to one extent or another. Some
changes are small, like a field size, and some are dramatic,
like encoding changes. Confusion can set in when we say that a
draft has become inactive/expired when it may again become
active. This community has barely any control over if/when that
will happen. We can say that this is the fault of the authors,
but the harm itself might not accrue to them. A perfect example
of this would be IANA considerations that reference a draft. If
a value is allocated for a particular version of a draft and a
new version comes out, does that code point still map to the
protocol behavior previously described? Absent additional
information, no one can say. For our own processes, at least we
can require that the reference be updated as part of the
publication process, as we do. But once drafts are no longer
tombstoned, this passes from our control in other circumstances.
Again, I can see value in extending the life of a draft in which our community has expressed interest. But even that lifetime should be limited to the community's interest since these drafts exist for the purpose of us completing our work.
There are some things that might remedy my concerns:
- Require that someone in our circle– not just an author – take
responsibility for a draft not expiring. A WG/RG chair would be
a good example. In this case, the draft can be extended to no
longer than the interest in the WG/RG's interest in that work or
that group's lifetime, whichever comes first. This provides a
clear signal as to our community's interest in the work.
- Lock a draft if it has become inactive for some period
of time so that it can never be updated. That reduces any
confusion that occurs with regard to IANA allocations, at
least. This still won't solve the potential abuse problem, but
at least it will ameliorate the interoperability risks, and a
better solution would be to not accept drafts in IANA
registrations except as early allocations.
- Identify the work as a draft in a MUCH MUCH louder way than just boilerplate, that the work is not suitable for broad implementation. Blinky watermark text with repeating sounds and animated gifs of explosions might only be a LITTLE over the top. This might reduce the abuse risk, but I don't think it will help with interoperability.
So... Acceptable = (1)|((2)&(3)). There may be other paths
as well, but more discussion is needed.
Eliot
Hi, I was asked to AD sponsor draft-thomson-gendispatch-no-expiry-03, and am willing to do so. Before I initiate a formal last-call, I'd like to do a substitute of a WGLC and ask interested IETF participants to give this a final read and indicate whether they are OK with seeing this go forward. Please send feedback along those lines by Feb 4. Thanks, Lars
Attachment:
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
