Joel,
On Fri, Jan 26, 2024, at 00:47, Joel Halpern wrote:
Lucas, what you describe is not the meaning most working groups assign to I-Ds. There are some WGs that have agreed to work that way, but that does not justify changing the underlying structure.
Also, I believe we are all well aware that "expired" does not mean "gone and inaccessible".
That's a sweeping statement. I can recount many examples where different people inside and outside ask the same questions about what a draft expiry means. Because there is no way to signal any intent or reason, it falls to people having to ask on lists etc. This wastes time.
It's trivial to publish new drafts but it's a waste of resources. It's also a waste of document reader's time to make them diff every I-D version to determine if there's substantial changes or it waste a pointless keepalive draft.
No individual occasion is a big deal. En masse it's death by a thousand cuts.
Cheers
Lucas
Yours,
Joel
On 1/25/2024 7:02 PM, Lucas Pardue wrote:In my experience as author, consumer, and WG chair, expiry creates needless busy work, stress, and confusion.The work I follow is done on GitHib, where a live editors copy is always available. I-Ds are published to capture what the authors believe to be a logically complete changeset. The timeliness for working through issues don't march to the beat of arbitrary draft deadlines. Publishing logically incomplete changesets is a waste of time; it can be better to postpone and let a draft expire rather than publish something that's broken. Does that mean the document is dead? No. It's active as evidenced by the progress of mailing list discussion and GitHub activity. But what happens is cycles are wasted by people trying to figure this out from plain English statements that are cryptic to apply to our tooling and processes.Furthermore, I'm surprised nobody has brought up the fact that expiry is trivially gamed by anyone that wants to keep an I-D permanent alive. No-change keepalive updates are a blot on the archive.
