All, I mostly agree with Joel, removing the 6-month expiry seems ill-advised. For wg chairs and authors, the reminders we get from the tracker is useful. However, there are sometimes cases where it would be convenient if a working group don't have to request publication (just yet), but could keep "non-expiring". I think I have seen 4 or 5 over twenty years as wg chair. I.e. a working group can make the rough consensus decision to put the draft in that state, e.g. to keep it available as background information and for normative references. What I imagine is that we'll have a new header in the tracker for working group documents "Non Expiring Documents". And the processing is entirely with the working group. /Loa > 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. > > 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 >>>> >>> > >
