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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 







On Thu, Jan 25, 2024 at 3:02 PM, Greg Mirsky <gregimirsky@xxxxxxxxx> 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 <loa@pi.nu> 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
>>>>
>>>
>
>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux