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.
Regards,
Greg
On Wed, Jan 24, 2024 at 10:23 PM <loa@xxxxx> 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
>>>>
>>>
>
>
