In practice, I find drafts expiring useful. There's been many times, both as an author and as a chair, I've been able to use the expiration as a forcing function/nudge to give a draft some love. Is it perfect? No. Is the current expiration mechanism useful? Yes. Let's not change it. -- Mike -----Original Message----- From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Joel Halpern Sent: Thursday, January 25, 2024 3:15 PM To: Martin Thomson <mt@xxxxxxxxxxxxxx>; Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> Cc: no-draft-expiry@xxxxxxxx; ietf@xxxxxxxx; alldispatch@xxxxxxxx Subject: Re: [Alldispatch] Taking draft-thomson-gendispatch-no-expiry-03 forward Martin, I find the email below confusing. I don't care where the expiry information lives. I care that it exists, and is treated as meaningful. If all you want to do is what Brian asks, to remove the date from the draft and replace it with a pointer to the datatracker, but keep the expiring process otherwise intact, I could live with that. But it is not what your draft requests. Yours, Joel On 1/25/2024 5:35 PM, Martin Thomson wrote: > On Fri, Jan 26, 2024, at 05:56, Brian E Carpenter wrote: >> None of that works if we leave any statement at all (either the 6 >> months text, or a purported expiry date) in the document itself. The >> only thing to say in the document, with today's hacked scheme or any >> future scheme, is "see the tracker for status". > Which is, when you get right down to it, all this document is doing. It's moving the TTL from the packet to the envelope. In doing so, it has opened up the question of what the right TTL assignment policy is. That seems to be the real source of contention. > > Not exclusively, I think that some people still believe that boilerplate actually does something other than increase the amount of scrolling you have to do to get to the good parts. > > Goodness me, if this hasn't caused an amazing amount of fuss. >
