On Thu, Jan 25, 2024, at 10:06, S Moonesamy wrote: > Section 3.1 explains the rationale for the expiration of a > draft. Nowadays, it takes a few years, or more, instead of less than > 185 days, for a draft to reach Last-Call. Have you considered > changing the six months to X years to align with existing practice? I think that any insistence that a draft expire is silly, no matter the time scale. I don't think that there is any single value that works for all cases. (I understand why people think a hold-down timer is useful, but I simply disagree.) > If I had any problem, it would be about the IPR disclosure aspect or > the divergence between an IETF I-D and an I-D in another Stream. Are > such problems in scope for your draft? The whole mess we have when it comes to drafts in different streams isn't one we planned to address. > The "work in progress" (Section 2.2) might be viewed as mislabelling > when an I-D is abandonware. Having an expiry date is a way to get around that. I get that. But I also think that our insistence on the "work in progress" label isn't that helpful either. > The proposal paves the way for what is known as "living > standards". The idea of "living standards" originated from the > WHATWG in 2011. That may work well when all the major vendors are on board. I have some sympathy for the living standards approach, but I don't know how to address some of the inherent problems. Problems that their proponents staunchly ignore, by the way. That said, I think that RFCs, which sit at almost the extreme opposite end of the spectrum, have worse problems. So you might say I'm conflicted on the subject. I can't agree that this is about paving the way to a living standards approach though.
