Subject: [Manycouches] Benjamin Kaduk's No Objection on draft-ietf-shmoo-cancel-meeting-05: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 07 Jul 2021 13:27:17 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-shmoo-cancel-meeting-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-shmoo-cancel-meeting/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I made a pull request with a few editorial suggestions at
https://github.com/martinduke/draft-ietf-shmoo-cancel-meeting/pull/7

It is perhaps interesting to note that we allow corporate travel
bans/restrictions to be used as a factor in cancelling a meeting (if
only by virtue of assessing how will be able to be present physically)
but specifically do not allow using them as a factor in who to offer
refunds to.  This doesn't seem inherently problematic, but is the type
of "edge case" that a security reviewer gravitates towards...

Section 1

   This document provides criteria to aid the IETF Administration LLC
   (LLC) in deciding to postpone, move, or cancel an in-person IETF
   meeting.

It seems like there is also some guidance to the IESG and IRTF chair in
here (and the authority to cancel may not lie solely with the LLC, as
well).

Section 3.1

   In non-emergency situations, if the LLC determines the scheduled
   meeting clearly cannot proceed (e.g., the venue has permanently
   closed), then it MUST consult with the community on the reason(s) and
   its proposed remedy.  [...]

Just to confirm: these are the reason(s) why the meeting "clearly cannot
proceed"?  I would hope that the need for cancellation is sufficiently
clear that nothing comes out of such a consultation, but don't object to
the requirement.

   The LLC will collect information about the likely impact to in-person
   attendance of national travel advisories, national and corporate
   travel bans, quarantine requirements, etc. and report the results to
   the IESG.

The shepherd writeup notes that there was some controversy about the
inclusion in earlier versions of the document regarding the use of
governmental travel advisories as a cancellation criterion.  Since this
usage is just as part of determining likely attendance, it seems like it
should not suffer from the same controversy, but I just wanted to
confirm that that is the case.

   In the event of considerations this document does not foresee, the
   LLC should protect the health and safety of attendees and staff, as
   well as the fiscal health of the organization, with approval from the
   IESG and a plan to seek a later update of this document.

That almost sounds like the LLC would be driving the document update,
which does not match with my understanding of the LLC's remit.

Section 4.1

   In particular, the LLC SHOULD strive to meet the criteria in
   [RFC8718] and [RFC8719].

"strive to" is already hedging language, so the weakness of "SHOULD" may
not be needed.

Section 5

   *  When a meeting becomes remote, the LLC MUST refund registered
      attendees the difference between their paid registration fee and
      the equivalent fee for a remote meeting.  [...]

[just noting that this is a "MUST refund", not the "offer a refund [that
does not have to be accepted]" phrasing we use elsewhere.  This seems
fine to me, but the inconsistency seemed worth confirming.]

NITS

Section 1

   Various major events may affect the suitability of a scheduled in-
   person IETF meeting, though for some this may not be immediately
   obvious.  For example:

Some [of these] events or some people?

Section 3.1

   These criteria, some of which are derived from Section 3 of
   [RFC8718], apply to venues that are re-evaluated due to an emergency:

The items that follow don't seem to all have a consistent grammatical
structure, so the list overall is a bit jarring.  E.g., the first one
seems like something that can be tested ("do the local guidelines allow
this") but the second is a straight-up requirement ("MUST be possible").
We might want to tweak some of the items' phrasing and/or add some
introductory text about how the criteria are to be applied.

Section 4.3

   Although it is more disruptive to the schedules of participants, the
   next best option is to delay a meeting until a specific date, at the
   same venue, at which conditions are expected to improve.  The new end
   date of a meeting must be at least 30 days before the beginning of
   the following IETF meeting, and a meeting must begin no earlier than
   1 month after the postponement announcement.

Is the distinction between 30 days and 1 month so critical that we need
to use different units in the same sentence?

---

From: Martin Duke <[email-masked]>
Date: Fri, 9 Jul 2021 11:50:02 -0700

Hi Ben,

Most of your comments are directly addressed in this merged PR:
https://github.com/martinduke/draft-ietf-shmoo-cancel-meeting/pull/8

the others are inline below:

> clear that nothing comes out of such a consultation, but don't object to

That is correct.

> confirm that that is the case.

Yes, the local authority is now the only one with the ability to "veto" a
meeting going ahead. In practice, I expect travel advisories to move in a
herd and therefore make the decision obvious. If they diverge then the IESG
will have to decide.