Considerations for Cancellation of IETF Meetings
RFC 9137

Thank you for this document. Some minor comments below.

Francesca

1. -----

   *  An economic crisis could sharply reduce resources available for
      travel.


FP: While the other examples seem clear and somewhat more easy to judge, this looks very vague to me: it might be better to explicitly state something on the sort of "... resource available for travel, leading to a much lower expected low attendance." This is still vague, but in my opinion gives a better idea of what to look for, and should be in line with later text about impact on attendance.

2. -----

Section 3.1

FP: As for the criteria, I was expecting to see something about reachability of the venue, especially because of this sentence:

   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

(travel ban) - I don't think that's covered by any of the other criteria.

3. -----

Section 4

FP: It seems that the subsection have a specific order - from most preferred to least preferred. It should be spelled out.

1. A small suggestion for the Abstract:

OLD:
   The IETF holds three in-person meetings per year to discuss and

NEW:
   The IETF ordinarily holds three in-person meetings per year to discuss and


2. I think this may have been raised already, but just in case:

   *  The number of critical support staff and contractors who can be at
      the venue.

Does this adequately capture the need for critical volunteers as well? I'm thinking in particular of the NOC.

3. I reviewed the Github Editor's copy (as of July 13 16:00 EDT or so) and noticed that the text "These remedies are listed in approximate declining order of preference" was added to the end of §4. That directly conflicts with version 5's "presented in no particular order". I like the text in v5 and don't particularly like the proposed edit.

4. Regarding

   The IETF SHOULD NOT reimburse registered attendees for unrecoverable
   travel expenses (airfare, hotel deposits, etc).

Has any consideration been given to adding some kind of text to the effect that attendees might choose to protect themselves against such losses with appropriate travel insurance? I appreciate that it would represent scope creep (it's not directly germane to "providing criteria for making this judgement") so I'm not bothered if this isn't adopted; however, I can see some benefits to including it.

5. Regarding

   *  Cancellation SHOULD result in a full refund to all participants.
      It MAY be prorated if some portion of the sessions completed
      without incident.

I presume this has been discussed to death, and it's understood this may result in the IETF eating sunk costs? (Similar applies to the rest of the bullets in the list.) I do see there's an escape clause for "extraordinary threats to the solvency of the organization".

6. Regarding

   This document introduces no new concerns for the security of internet

s/internet/Internet/. The NYT style is wrong, wrong, wrong on this one.

7. Is the Acknowledgements section empty deliberately?

I suggest the shepherd writeup should have been sent back for revision.  It answers the first three questions (What is the status, why is this the right status, is it shown on the front page?) with just "BCP".  Also, "N/A" is not an appropriate answer to question 7.

Given the capitalization in Section 3.1, it appears some terms were also imported from RFC 8718 (e.g., "Facility", which is formally defined there).  We might want to make it explicit that these definitions are imported.

Hi Martin,

Thanks for driving this document.

A couple of minor comments:

1. MUST consult with the community on the reason(s)

This is just a nit, but this could be read as having a discussion with the community about why the meeting cannot proceed as scheduled (E.g., analyzing why the hotel failed).  I presume that the intended consultation should be just what the IETF/LLC should do about it. 

2. Consulting with the community on the form of the assessment report.

Although I have no objection to the LLC doing this, I don't really see this as something that must be consulted on.  Discussing the content seems fine, but needing to consult on what the report looks like feels like a step too far to me.

Regards,
Rob

Thank you to David Mandelberg for the SECDIR review

** Section 3.1.  Editorial. s/Internet Access/Internet access/

** Section 3.1.  Editorial.  Section 2 defined venue to be the facility and IETF hotel, so shouldn’t the text s/Facility and IETF Hotels/venue/?

** Section 4.  Improve readability

OLD
Ensure the available time and resources allow the alternative to
      be adequately prepared.

NEW
Ensure sufficient time and resources to allow an alternative to
      be adequately prepared.

Thanks for the efforts put in this document and in the discussions.

I would suggest this - " This document provides criteria to aid the IETF Administration LLC
   (LLC) in deciding to postpone, move, or cancel an in-person IETF
   meeting." to be added in the abstract of this document to make the purpose more clear. 
  
Then I agree with Ben's comment that his document seems also helping IESG and IRTF chair in the assessment (see section 3 ) hence wondering if that also should be clear in the purpose statement made in this document.

Thank you, Martin, for the work put into this document.

Please find below some non-blocking COMMENT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
"to discuss and understand issues." this looks not very positive for the IETF if the community is only about "issues" and not about "advancing the Internet"...

-- Section 3 --
"if the projected attendance is sufficient" while attendance is a big part of the decision, it is probably not the only one (I can imagine other conditions to have a real "live" meeting)

-- Section 3.2 --
I was about to DISCUSS the point about "projected attendance is high enough" because it is not only about sheer number of attendees but also about diversity, e.g., IETF-112 with only EU attendees will not be very fruitful.

-- Section 5 --
The last bullet uses "nation" but there may be more granular level at the attendee's residency (state, province, ...).

(1) §3.1:

   The LLC SHOULD cancel a meeting if it judges a meeting to be
   logistically impossible or inconsistent with its fiduciary
   responsibilities.

s/LLC SHOULD cancel a meeting/LLC SHOULD cancel an in-person meeting and explore potential remedies

Given the possible remedies, it seems that logistic issues (for example) may be addressed by virtualizing or postponement.  IOW, the in-person part of the meeting may be canceled.  I feel that I may be missing some additional context...


(2) §3.2: The first paragraph mentions both the IESG and IRTF Chair, but the others only mention the IESG.  Is this an oversight (or maybe shorthand), or an indication that the assessment is driven only by the feasibility of an IETF meeting?


(3) §3.2: It seems to me that (similar to §3.1), there should be text indicating when the IESG should cancel the in-person meeting.  Something like this:

   The IESG SHOULD cancel the in-person meeting if the assessment 
   indicates that attendance won't be high enough to be of benefit.


(4) If the meeting is virtualized, then no one really is remote -- everyone is online/virtual.  

§4.2: s/fully remote/fully online   

§4.4: s/even attend remotely/even attend online

§5: s/meeting becomes remote/meeting is virtualized

§5: s/for a remote meeting/for an online meeting

§5: s/attend a remote meeting/attend an online meeting


(5) §4.3: Is there a reason to not use normative language in this sentence: 

   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.

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?