Hi John, I confirm receipt of your appeal. Thanks, Lars > On Aug 15, 2023, at 22:03, John C Klensin <john-ietf@xxxxxxx> wrote: > > --On Tuesday, August 15, 2023 10:23 -0700 IESG Secretary > <iesg-secretary@xxxxxxxx> wrote: > >> The IESG has issued a Statement on Guidance on In-Person and >> Online Interim Meetings: >> >> 14 August 2023 >> >> This statement provides IESG guidance on hybrid and online >> interim IETF working group (WG) meetings. >> >> Read more: >> >> https://www.ietf.org/about/groups/iesg/statements/interim-meet >> ings-guidance/ > > > > IESG, > > (I am bypassing the normal procedure of a discussion with the > IETF Chair before creating an appeal because there was a > discussion with him about some of the issues in the prior > version of the guidelines, including a request that those issues > be considered as part of another appeal and any resulting > rewriting. Most of those have not been addressed and are > reiterated below.) > > While I appreciate the effort to update this document, this > revision raises several concerns (most raised earlier and not > addressed) in addition to including a key statement, apparently > as justification, that I do not believe to be true. > > (1) The guidelines for online interim meetings now read as if > they can reasonably be run as effectively closed sessions, > announced only to those who happen to be on the mailing list of > that WG. There is not even a requirement to let the responsible > AD know that the meeting is being scheduled (the text says > "should discuss" which would not be requirement even if "should" > were in upper case). That is less open than we usually require, > exclusionary of those who are not very active WG participants, > potentially hostile to newcomers, and, most important, > undermines the traditions of encouraging IETF participants to > look in on WGs in which they are not actively participating and > hence undermining cross-area reviews prior to IETF Last Call > except when WG Chairs explicitly ask for those reviews. There > are more quibbles about that section including about timing of > the "reminders" for recurring meetings. > > (2) For hybrid meetings, the decision as to whether "extended > sequences" of such meetings are needed and acceptable appears to > be left entirely to the WG, even though, unlike online meetings, > AD approval of some type is required (but, for a sequence, it is > not clear what the AD has to approve). That raises most of the > same issues as above. > > (3) The statement "Interim meetings of any type are integral to > the IETF way of working," is, AFAICT, false. Every WG that has > managed to get through all of its work in the last > quarter-century without holding even one interim meeting is a > counterexample. Perhaps it is the intention of the IESG to > change that or perhaps the IESG is just adjusting to trends in > that direction, but those would be rather fundamental changes, > for which see the next two items. > > (4) We can repeat the requirements of RFC 2418 (especially > Section 3.2) as often as we like but the reality is that, > especially if a WG moves to regularly scheduled and frequent > interim meetings, those meetings (and not mailing lists) are > almost certain to become the primary discussion venue for the > WG. In many cases (and I think I have seen examples), if a WG > becomes used to working that way, "reviewed and confirmed on the > mailing list" becomes a note to the mailing list saying > something close to "the interim decided XYZ; anyone with serious > objections should speak up". > > (5) Almost separate from the above, but equally or more > important, portions of this document are essentially an update > or reinterpretation of RFC 2418. As such, with the probable > exception of the discussion of visas and meeting invitations, > establishing policies like those outlined by an internal IESG > discussion and IESG Statement violates principles about > community decision-making established in the wake of the Kobe > incident as well as the provisions of BCP 9 (RFC 2026 and > updates). This policy document should be presented to the > community in I-D form, discussed and revised as needed, and then > subjected to IETF Last Call. Unless the IESG believes that it > can fairly and objectively evaluate Last Call comments on a > document that it wrote and approved, it should devise some other > way for the Last Call to be evaluated such as handoff to the IAB. > > thanks, > john >
Attachment:
signature.asc
Description: Message signed with OpenPGP
