This seems to mix two notions:
Aspect 1: Should drafts expire? There are clearly different opinions. I am in the camp that for IETF purposes, draft should expire. As far as I can tell, that is the question the draft under discussion attempts to change.
Aspect 2: Where should the expiration be record, tracked,
reported, etc. There is a reasonable argument that having that
information in the draft is somewhat misleading. Having drafts
say "check the datatracker", with or without stating an expected
expiration date, seems useful. I can live with keeping the date
in the draft. While I do not think it is worth the effort, I can
live with removing the date from the draft, while being clear that
process-wise, drafts still expire. However, as far as I can tell,
that is not what the draft in front of us does. I would suggest
that if someone thinks that change is worth making, they write a
draft that explicitly makes it.
Yours,
Joel
On Sat, Jan 27, 2024 at 9:53 AM Eliot Lear <lear@xxxxxxx> wrote:
Want a messier example? An X.509 certificate. Geech.
That last one is interesting. I just use a "managed certificate", and I never even need to monitor it. It would be a little cheaper if I did it myself.
But I think the point here is that the expiry date is not helpful. What's it doing here? Of course, I'm going to cite some expired ones now.*
It doesn't tell you whether there's a newer one. Since, sometimes a new draft comes out every few weeks. For example, the -02 there is not expired by date.
Alternatively, it could be that the situation is "this looks pretty good, let's see what happens". Some WGs work that way. There are also some tough problems like HTTP and TLS (these are the ones I know), where the commonly cited RFC is usually the wrong one.
So, does a non-expiring I-D damage the RFC series? I think it's actually better, because then we don't need to publish informational ones about rejected approaches and such.
thanks,Rob
*
