On 25-Jan-24 10:18, Joel Halpern wrote:
Getting rid of a helpfu mechanism, and excusing it with "well, the IESG
can add it back" does not seem appropriate. I think the draft needs to
acknowledge that it is affecting existibng mechanisms, and either
explicitly say "and we think that is okay" or explain how they should be
covered if the draft is published as an RFC.
Actually I agree with that, which is why my preference is to add
some rules for IETF I-Ds, as I've already suggested. But each RFC
stream might want different rules.
Brian
I don't disagree that our current handling is somewhat unclear and
inconsistent.
Yours,
Joel
On 1/24/2024 3:42 PM, Brian E Carpenter wrote:
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
.
