On Sun, Mar 17, 2024 at 11:41 AM John C Klensin <john-ietf@xxxxxxx> wrote:
The question that started the thread is whether other mechanism
of getting documents posted --other than, e.g., mailing list
discussions-- frustrate the intent of that two week limit and,
if so whether they are reasonable. I had intended to open up,
and ask for community consideration of, the much broader set of
questions and was not asking about localized patches. Pete
clarified that point and said what I should have said more
explicitly -- that we need to look at the whole collection of
interrelated issues rather than applying isolated small patches.
I would add that we should not get distracted by possible
patches to the point of losing sight of that collection of
issues. I don't know that it is what either Keith or Carsten
intended, but a discussion of any of whether the cutoff should
be two weeks before the meetings start, what "starts" means for
that purpose, whether it should be 14 days, 20 or 10 days, one
day, some other number, or abolished entirely would be, IMO,
just the sort of distraction from the larger issues that I think
Pete and I are concerned about.
So, btw and IMO are discussions on the tools list about ways to
make Github more or less efficient for document review and
whether it is time to prohibit some I-D preparation tools or
formats. They are probably all part of the larger set of
questions but, like others of those questions, they raise
important policy questions including, again IMO, just what they
IETF means when we talk about being open, welcoming,
transparent, etc., and what we all mean when we say that
something represents IETF community consensus.
> I'm less sure about opening submission to new drafts one day
> before a meeting. I might prefer that they be opened again the
> day after the meeting closes.
Again, part of the broader problem (with interactions with other
parts), as are the questions of when WGs are expected (or
required) to firm up agendas and organize and post meeting
materials.
Speaking only for myself and not for the IESG:
The diversity of opinions on this topic over the years has been noteworthy and interesting. Personally, I'm indifferent as to the period of time the embargo lasts. I recognize the value it has (or, at least, had), and I've seen how frustrated some participants can be when they come prepared to discuss version -xx only to discover that version -yy is now visible and substantially different than what they had previously reviewed.
Two points, then:
(1) Integration with, or generally use of, GitHub as a place to conduct WG business certainly has its advantages, but it has also essentially become a second datatracker and WG mailing list. I imagine (but could be wrong) that asserting control over what participants are allowed to do there as a meeting approaches will be difficult if not impossible. I don't think it's possible to put that back in its bag at this point.
(2) The diversity of opinions makes me think we should consider allowing working group chairs to decide for their working groups whether, and how long, an embargo should last. I suggest that the datatracker should empower working group chairs to:
* decide whether, and how long, to create a pre-meeting embargo for their WG's documents
* optionally enforce that embargo only against documents that appear on the WG's meeting agenda
* arrange that the embargo automatically ends when the WG submits minutes for its meeting
-MSK, solo
