On 3/16/2024 6:49 AM, Brian E Carpenter wrote:
On 16-Mar-24 10:17, Pete Resnick wrote:
Agreed. We really need to have a bit of a general re-think on what we
really want out of these rules instead of (IMO) silly point-fixes that
don't really address the issue. Re-opening the queue on Sunday is
completely counter-productive if the point was not to have new versions
just before the f2f. (Similarly, the current proposal to remove the I-D
expiry date, which I agree is anachronistic and not serving its original
purpose, is another attempt at a simple point fix that does not address
the original reason those dates existed.)
Can we have a go at why we want these mechanisms in the first place
instead of making arbitrary changes?
As far as I recall, it was originally intended to ensure that in the
face-to-face meeting of each WG, people had all read the same version
of each I-D. As hacks to bypass the posting deadline have emerged
(with github PRs only being the latest hack), this has become less and
less effective. Maybe that battle has now been lost.
However, we should consider two other effects of the deadline:
1. Negative: A ridiculously large number of drafts are posted within
~72 hours, as Carsten pointed out recently**. So anybody who tries to
track the IETF very broadly is swamped three times a year.
2. Positive: People are deadline-driven. If we didn't have the deadline
two weeks before the meeting, the ridiculous number of drafts would
be posted... today!
Let's add a third effect.
3. The IETF hackathon positive effect. People start meeting on Sat/Sun
before the IETF week, discussing the different open issues, ideally
around code development. Some issues are potentially solved during the
week-end, leading to new draft revisions being posted, as prerequisite
for the WG discussion. If not posted as a new draft revision, the WG
slide deck will anyway contain the hackathon findings (which has the
same positive effect)
Regards, Benoit
