Joel,
The draft doesn't preclude the IETF having an additional procedure such as automatically switching the status to inactive after time T, unless someone such as a WG Chair decides otherwise. We don't have to specify everything in a BCP.
One other comment while I'm here. The current system means that the expiry date of a draft is built into the text of the draft. So we have the rather ludicrous situation that often a draft says "I'm expired"** but the tracker says "It's active".
** As in "This Internet-Draft will expire on 3 January 2024", which is extracted from one of the drafts currently under IESG consideration.
It's really no wonder that outsiders get confused. Simply deleting that sentence from the boilerplate would help.
Regards
Brian Carpenter
On 25-Jan-24 08:24, Joel Halpern wrote:
While the draft retains a way for chairs to mark drafts as inactive,
this seems to be an awkward way to keep the WG listings clean when it
comes to drafts that are not receiving attention. The chairs have to pay
attention to things which are not receiving attention?
Yours,
Joel
On 1/24/2024 1:44 PM, Paul Hoffman wrote:
On 24 Jan 2024, at 8:30, Ted Hardie wrote:
Seeing Eliot and Russ's points, I think that this could be the basis of a
valuable change, but that it may need additional work. We have changed our
system to recognize that these drafts no longer disappear, because it was
clear that external archives had made that a fait accompli. But this is
asking for something different, declaring that the TTL field has no meaning
at all.
This is kind of a mis-statement about what the draft says. The draft says that there is no "TTL field", not that it exists but has no meaning.
I think we can probably do better, by making it more variable, allowing any
party to set it shorter than the default 6 months, but requiring some
action beyond the author's preference to set it longer than a specific
amount. With a specific set of circumstances, I can easily see one of the
values being "no expiry". If there are concerns that this does not fit all
cases, the answer may be to allow both that and other choices, using a set
of processes which need to be ironed out.
It sounds like you are proposing keeping the concept of expiration, but making it have variable time. Maybe I'm being uncreative, but I don't see how this could possibly be implemented given that the expiration time is instantiated in the draft itself. Can you model out how you thought the variable expiration time would be known to the reader of the draft, or in the many places that the draft is stored?
--Paul Hoffman
