Re: [Alldispatch] Taking draft-thomson-gendispatch-no-expiry-03 forward

[Donald Eastlake <[e-mail]>]

I agree with many people that I don't really see a problem with a
6-month expiry. It serves a useful nudge function. To avoid drafts
appearing to be expired whose expiration has been suspended because of
their status, I suppose the expiry date could be moved to the
datatracker. ("All problems in computer science are solved by adding a
level of indirection" or something like that...)

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Thu, Jan 25, 2024 at 7:40 PM Greg Mirsky <[e-mail]> wrote:
>
> Hi Warren,
> thank you for sharing your thoughts. And I fully agree with you, "Non-expiring" must not be used for individual drafts. Where I see that such a state could be useful is in cases when there's a choice between publishing a document (in my experience, these were always Informational documents) or keeping them as a "living document" for reference in documents on the Standard track. Of course, refreshing the serial number once every 6 months is not a problem and certainly much less work compared to driving through the process, but, sometimes, situations change and it becomes a hassle to recover the proverbial pen. It all may be avoided by assigning that new state, based on the WG decision, only based on the WG consensus. With that, IESG might see fewer Informational drafts on its table.
>
> Regards,
> Greg
>
> On Thu, Jan 25, 2024 at 3:52 PM Warren Kumari <[e-mail]> wrote:
>>
>>
>>
>> On Thu, Jan 25, 2024 at 3:02 PM, Greg Mirsky <[e-mail]> wrote:
>>>
>>> I share concerns expressed by Joel and Loa.
>>>
>>> Furthermore, I support Loa's proposal to add the "Non-expiring" status that can be assigned to a WG draft based on WG consensus (it can be removed at a later time) to save from the necessity of technical refreshes.
>>
>>
>> I'm sorry, but I'm still not understanding the issue with having to refresh the document every 6 months or so.
>>
>> Take https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/ as an example.
>>
>> I wrote the initial document back in ~2014. It served its purpose then, and so I let it expire / didn't bother renewing it.
>>
>> The problem that it was written to address (people claiming that some individual draft meant that "The IETF thinks XXX") reoccured in Feb 2020, so I pulled out of of storage, dusted it off, and published a new version.
>> Every ~6 months since then, I've gotten an email reminding me that it's about to expire, and I go "Huh. Is this worth keeping around? Erm, sure…", update the version number and log, and push a new version. This takes me between 30 seconds and 1 minute. This document was written in the days of XML — with Martin's new Markdown/Github tooling it would take even less.
>>
>> Yup, that has taken probably a total of 9 or 10 minutes of my time over the past few years, but I think that the fact that I have to do something shows that I'm still interested and following it.
>>
>> I've had a bunch of other drafts where I get the email reminder, and have gone "Huh. Is this worth keeping around? Nah….", and the draft quietly does on the vine.
>>
>> These have all mostly been individual drafts — but IMO this goes double for WG documents. If the WG and authors are not sufficiently invested that they can take a minute or two to poke the document, then I think that this is a signal that either the document is no longer needed, or that there should be new authors appointed….
>>
>> The fact that someone is updating a document shows that someone still cares about it…
>> W
>>
>>> Regards,
>>> Greg
>>>
>>> On Wed, Jan 24, 2024 at 10:23 PM <[e-mail]> wrote:
>>>>
>>>> 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
>>>> >>>>
>>>> >>>
>>>> >
>>>> >
>>
>>