Re: Question about pre-meeting document posting deadlines for the IESG and the community

["Murray S. Kucherawy" <[e-mail]>]

On Sun, Mar 17, 2024 at 11:41 AM John C Klensin <[e-mail]> 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