From: ietf <ietf-bounces@xxxxxxxx> on behalf of loa@xxxxx <loa@xxxxx> Sent: 25 January 2024 06:23 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. <tp> This is probably the first post in a very long thread that makes sense to me. We already have many expired I-D in the datatracker - 64 over 33 years in IDR with a further 34 active I-D - and turning those into unexpired seems just to clutter the system and render it harder to keep track of what matters. Already there are times when expiry is put on hold, as when an I-D heads towards the IESG; allowing WG Chairs to invoke that seems a sensible addition. And if the WG Chairs do not initiate it, then a request to do so can be posted to the list with the WG Chairs being responsible for judging consensus. But the case for keeping an I-D active needs to be a good one, such as a Normative dependency on another WG whose progress is slow (I have two such WG in mind!) An LSR I-D was recently 'parked' by the WG Chair because of just such a situation. Tom Petch 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 >>>> >>> > >
