Subject: [Manycouches] Fwd: New Version Notification for draft-duke-shmoo-cancel-meeting-00.txt

From: Martin Duke <[email-masked]>
Date: Wed, 13 Jan 2021 15:46:42 -0800

Hello shmoo,

Based on list feedback and comments at 109, I've updated the
remote-meetings draft (now named cancel-meeting to reflect what it actually
talks about)

The two main changes are:
- I added cancellation criteria from IETF 109
- I switched the preference to put virtualization ahead of postponement.

I have gotten many comments that some of the remedies, especially
postponement, are not practical. That's fine, but I view this document as a
statement of principle rather than assessment of likelihood.

I believe the sentiment at 109 was to adopt this draft.

Martin

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, Jan 13, 2021 at 3:32 PM
Subject: New Version Notification for draft-duke-shmoo-cancel-meeting-00.txt
To: Martin Duke <[email-masked]>

A new version of I-D, draft-duke-shmoo-cancel-meeting-00.txt
has been successfully submitted by Martin Duke and posted to the
IETF repository.

Name:           draft-duke-shmoo-cancel-meeting
Revision:       00
Title:          Considerations for Cancellation of IETF Meetings
Document date:  2021-01-13
Group:          Individual Submission
Pages:          7
URL:
https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.txt
Status:
https://datatracker.ietf.org/doc/draft-duke-shmoo-cancel-meeting/
Html:
https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.html
Htmlized:
https://tools.ietf.org/html/draft-duke-shmoo-cancel-meeting-00

Abstract:
   The IETF firmly believes in the value of in-person meetings to reach
   consensus on documents.  However, various emergencies can make a
   planned in-person meeting impossible.  This document provides
   criteria for making this judgment.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Jan 2021 11:42:31 +0000

Hi Martin,

This is good, and seems to match the process we followed.

In Section 3.2, any decision the IESG makes about canceling an in-person meeting, due to concerns about attendance, will affect any co-located IRTF events. The IESG ought to consult with the IRTF Chair before deciding, not just with the WG chairs.

Section 3.1 describes a process for the LLC to make cancellation decisions. The nature of such decisions is that they’re in response to emergencies and unpredictable events, and may sometimes need to be made quickly. Due to the potential need to decide quickly, and the possibility these criteria turn out to be insufficient, is it worth explicitly stating that while changes to these criteria SHOULD be made with IETF consensus, the LLC can use its discretion to make a cancellation decision in exceptional circumstances?

Colin

> On 13 Jan 2021, at 23:46, Martin Duke <[email-masked]> wrote:
> 
> Hello shmoo,
> 
> Based on list feedback and comments at 109, I've updated the remote-meetings draft (now named cancel-meeting to reflect what it actually talks about)
> 
> I have gotten many comments that some of the remedies, especially postponement, are not practical. That's fine, but I view this document as a statement of principle rather than assessment of likelihood.
> 
> From: <[email-masked] <mailto:[email-masked]>>
> To: Martin Duke <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.txt <https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-duke-shmoo-cancel-meeting/ <https://datatracker.ietf.org/doc/draft-duke-shmoo-cancel-meeting/>
> Html:           https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.html <https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.html>
> Htmlized:       https://tools.ietf.org/html/draft-duke-shmoo-cancel-meeting-00 <https://tools.ietf.org/html/draft-duke-shmoo-cancel-meeting-00>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches

-- 
Colin Perkins
https://csperkins.org/

---

From: Martin Duke <[email-masked]>
Date: Fri, 15 Jan 2021 07:23:12 -0800

Hi Colin, yes, the first is a good addition, and will be in the next
version.

I imagine that getting a time-consuming consensus would be the exception
rather than the rule. The intent of this document is to build a consensus
around cancellation criteria that the LLC can apply more or less
mechanically. I will add some text to make this intent clear.

On Fri, Jan 15, 2021 at 3:42 AM Colin Perkins <[email-masked]> wrote:

> In Section 3.2, any decision the IESG makes about canceling an in-person
> meeting, due to concerns about attendance, will affect any co-located IRTF
> events. The IESG ought to consult with the IRTF Chair before deciding, not
> just with the WG chairs.
>
> Section 3.1 describes a process for the LLC to make cancellation
> decisions. The nature of such decisions is that they’re in response to
> emergencies and unpredictable events, and may sometimes need to be made
> quickly. Due to the potential need to decide quickly, and the possibility
> these criteria turn out to be insufficient, is it worth explicitly stating
> that while changes to these criteria SHOULD be made with IETF consensus,
> the LLC can use its discretion to make a cancellation decision in
> exceptional circumstances?
>
> Colin
>
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Jan 2021 15:31:33 +0000

Hi,

> On 15 Jan 2021, at 15:23, Martin Duke <[email-masked]> wrote:
> 
> Hi Colin, yes, the first is a good addition, and will be in the next version.

Thanks!

> I imagine that getting a time-consuming consensus would be the exception rather than the rule. The intent of this document is to build a consensus around cancellation criteria that the LLC can apply more or less mechanically. I will add some text to make this intent clear.

Sure – I’m just conscious that, by definition, we’re documenting procedures for unusual and difficult to predict situations. We probably want some words to say that the LLC should do the right thing in an emergency, if the consensus criteria prove insufficient and there isn’t time to consult to gauge consensus.

Colin

> On Fri, Jan 15, 2021 at 3:42 AM Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Martin,
> 
>> On 13 Jan 2021, at 23:46, Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello shmoo,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/manycouches <https://www.ietf.org/mailman/listinfo/manycouches>
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>
> 
> 
> 
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Martin Duke <[email-masked]>
Date: Fri, 15 Jan 2021 11:38:36 -0800

Besides IRTF references, I am adding:

This document provides a consensus of principles the LLC can apply in
emergency situations, to avoid operating without such consensus or invoking
a
time-consuming consensus process. In the event of considerations this
document
does not foresee, the LLC should protect the health and safety of attendees,
as well as the health of the organization, with approval from the IESG and
a
plan to seek a later update of this document.

On Fri, Jan 15, 2021 at 7:31 AM Colin Perkins <[email-masked]> wrote:

> Sure – I’m just conscious that, by definition, we’re documenting
> procedures for unusual and difficult to predict situations. We probably
> want some words to say that the LLC should do the right thing in an
> emergency, if the consensus criteria prove insufficient and there isn’t
> time to consult to gauge consensus.
>
> Colin
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Jan 2021 20:36:48 +0000

LGTM.
Colin

> On 15 Jan 2021, at 19:38, Martin Duke <[email-masked]> wrote:
> 
> emergency situations, to avoid operating without such consensus or invoking a
> time-consuming consensus process. In the event of considerations this document
> as well as the health of the organization, with approval from the IESG and a 
> On Fri, Jan 15, 2021 at 7:31 AM Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>> On 15 Jan 2021, at 15:23, Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
>> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Jan 2021 15:14:38 -0600

What is LGTM?

Behcet

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Jan 2021 21:54:37 +0000

“Looks good to me”

> On 15 Jan 2021, at 21:14, Behcet Sarikaya <[email-masked]> wrote:
> 
> 
> What is LGTM?
> 
> Behcet
> 
>>>>>>> URL:            https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.txt
>>>>>>> Status:         https://datatracker.ietf.org/doc/draft-duke-shmoo-cancel-meeting/
>>>>>>> Html:           https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.html
>>>>>>> Htmlized:       https://tools.ietf.org/html/draft-duke-shmoo-cancel-meeting-00
>>>>>>> 
>>>>>>> 
>>>>>>> Abstract:

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Jan 2021 11:08:17 +0100

Hi,

Thanks for the draft.  I think it is a very good document.

I might have some comments, if necessary, but the document is good as is
already!

I think there are a few different perspectives for cancellation strategy.

A one-time event, like some Eyjafjöll volcan disturbing air travel once
every 500 years, and ending in 4 weeks or so.  This cancellation process
might last very short.  It has no risk of fragmenting the trust.

A start event followed by many monthly updates but eventually ending
after a couple or more years.  This cancellation process requires
periodic reviews.  The periodicity should be stated: every 3 months a
report.

Maybe other kinds of cancellation strategies.

> *  There is no quarantine or self-isolation requirement at the 
> location.

The criterion is very relevant, but its formulation might be improved
if necessary.

People seem to be able to travel even if quarantine is in place; the
additional week(s) surronding the effective meeting might be paid and
supported by third-parties.

This is why maybe the existence of the quarantine could be formulated as
a criterion weighing in a balance, but its absence not to be a
requirement for non-cancellation.

> *  Changes in visa policy or other unexpected governmental 
> restrictions might make the venue inaccessible to numerous 
> attendees.

This criterion makes think of the vaccination or PCR or other tests
checking proofs.  It could be expected that in the future the
'passports' or other so features might be required in order to travel,
at some points in time.  Just like with regular passports these 'new
passports' might follow different policies.  Some people might be
subject to them and others no, just like with regular visas.

IETF meeting does not ask for visa, but it might ask for such 'new
passport'.  Or it might not ask for it at all.

But, the travel will probably be conditioned by these 'new passports'.

(the existing 'biometric passports' already have bulitin memory chips
but I think there is not enough space to put more detailed data than
just person's height and eye color; 'bio passports' would be additional
passports with more kb in chips, or more paper space)

That is why it might be necessary to list them to the above bullet item.

> 4.4.  Cancellation
> 
> As a last resort, IETF may cancel the meeting totally.  This is a 
> last resort in the event that worldwide conditions make it difficult 
> for attendees to even attend remotely.  Not holding a meeting at all 
> has wide implications for the rhythm of IETF personnel policies, such
> as the nomination process and seating of new officers.
> 
> Cancellation is likely the only practical alternative when 
> emergencies occur immeidiately before or during the meeting, so that 
> there is no opportunity to make other arrangements.

Such a paragraph might benefit from an exception that, when Cancellation
is present for a long time, lists a small number of roles that must
always be allowed to meet in person, if they so wish.  For example, the
Chair, the IAB Director and the IESG Director must be able to meet, if
they so wish, at least once a year to discuss face to face.  Only them.

This is for maintaining trust when no f2f IETF for a long time.

Alex

Le 14/01/2021 à 00:46, Martin Duke a écrit :
> remote-meetings draft (now named cancel-meeting to reflect what it 
> actually talks about)
> 
> The two main changes are: - I added cancellation criteria from IETF 
> 109 - I switched the preference to put virtualization ahead of 
> postponement.
> 
> postponement, are not practical. That's fine, but I view this 
> document as a statement of principle rather than assessment of 
> likelihood.
> 
> ---------- Forwarded message --------- From: 
> <[email-masked] <mailto:[email-masked]>> Date: 
> Wed, Jan 13, 2021 at 3:32 PM Subject: New Version Notification for 
> draft-duke-shmoo-cancel-meeting-00.txt To: Martin Duke 
> <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> A new version of I-D, draft-duke-shmoo-cancel-meeting-00.txt has been
> successfully submitted by Martin Duke and posted to the IETF 
> repository.
> 
> Name:           draft-duke-shmoo-cancel-meeting Revision:       00 
> Document date:  2021-01-13 Group:          Individual Submission 
> Pages:          7 URL: 
> <https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.txt>
>
>
>
>
>
> 
Status:
> <https://datatracker.ietf.org/doc/draft-duke-shmoo-cancel-meeting/> 
> Html: 
> <https://www.ietf.org/archive/id/draft-duke-shmoo-cancel-meeting-00.html>
>
>
>
>
>
> 
> <https://tools.ietf.org/html/draft-duke-shmoo-cancel-meeting-00>
> 
> 
> Abstract: The IETF firmly believes in the value of in-person meetings
> to reach consensus on documents.  However, various emergencies can
> make a planned in-person meeting impossible.  This document provides
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org <http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________ Manycouches mailing 
> list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Jan 2021 11:17:29 +0100

Also,
the process should be made difficult to cancel, but easy to un-cancel.

All the gear used to run an f2f should be maintained oiled and 
self-tested somehow.

Alex

Le 18/01/2021 à 11:08, Alexandre Petrescu a écrit :
>> *  There is no quarantine or self-isolation requirement at the location.
> 
>> restrictions might make the venue inaccessible to numerous attendees.
> 
>> As a last resort, IETF may cancel the meeting totally.  This is a last 
>> resort in the event that worldwide conditions make it difficult for 
>> attendees to even attend remotely.  Not holding a meeting at all has 
>> wide implications for the rhythm of IETF personnel policies, such
>> Cancellation is likely the only practical alternative when emergencies 
>> occur immeidiately before or during the meeting, so that there is no 
>> opportunity to make other arrangements.
> 
>> postponement, are not practical. That's fine, but I view this document 
>> as a statement of principle rather than assessment of likelihood.
>>
>> ---------- Forwarded message --------- From: <[email-masked] 
>> <mailto:[email-masked]>> Date: Wed, Jan 13, 2021 at 3:32 PM 
>> Subject: New Version Notification for 
>> successfully submitted by Martin Duke and posted to the IETF repository.
>>

---

From: Martin Duke <[email-masked]>
Date: Sun, 24 Jan 2021 14:23:49 -0800

Hi Alexandre, replies inline.

> periodic reviews.  The periodicity should be stated: every 3 months a

IETF is currently evaluating each meeting on its own, and I think we'd keep
doing that rather than
cancelling many at once.

> requirement for non-cancellation.

I suspect there's a consensus that this may be financially possible, but
not desirable. I'm happy to be corrected if others feel we should press on
through a quarantine requirement.

> That is why it might be necessary to list them to the above bullet item.

The passport concept seems speculative and somewhat over-specific. Visas
are merely an example of the kind of governmental policy that the LLC
should consider.

> This is for maintaining trust when no f2f IETF for a long time.

Frankly, I'm skeptical that this is actually a need. If it were, I don't
see that we need an RFC to authorize the three of them to arrange a meeting.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Jan 2021 10:01:56 +0100

Le 24/01/2021 à 23:23, Martin Duke a écrit :
> On Mon, Jan 18, 2021 at 2:09 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> periodic reviews.  The periodicity should be stated: every 3 months
> a report.
> 
> 
> IETF is currently evaluating each meeting on its own, and I think
> we'd keep doing that rather than cancelling many at once.

YEs, I think that is very good.

But what is the evaluation plan, can one see precise dates of when this
evaluation happens?  For example, we do have a precise schedule of BoF
and I-D deadlines.

> The criterion is very relevant, but its formulation might be
> improved if necessary.
> 
> additional week(s) surronding the effective meeting might be paid
> and supported by third-parties.
> 
> This is why maybe the existence of the quarantine could be formulated
> as a criterion weighing in a balance, but its absence not to be a 
> I suspect there's a consensus that this may be financially possible,
> but not desirable. I'm happy to be corrected if others feel we should
> press on through a quarantine requirement.

I think the quarantine requirement is, maybe, at times, a gov't imposed
rule.  It changes very often.  Some times it is put on a paper, some
times simply announced on TV by an authoritative person.

This is a 'sanitary emergency state'.  In this state, decisions are very
dynamic at gov't level.

I agree in some countries there are no such states, but it will come.

In such a situation, I still think it might not be feasible or desirable
to have local organisation to impose quarantine.

But, IETF might agree with a quarantine requirement that is clearly set
in one place, and agree to enforce it prior to a f2f meeting.

> 'passports' or other so features might be required in order to
> travel, at some points in time.  Just like with regular passports
> these 'new passports' might follow different policies.  Some people
> might be subject to them and others no, just like with regular
> visas.
> 
> (the existing 'biometric passports' already have bulitin memory
> chips but I think there is not enough space to put more detailed data
> than just person's height and eye color; 'bio passports' would be
> additional passports with more kb in chips, or more paper space)
> 
> The passport concept seems speculative and somewhat over-specific.
> Visas are merely an example of the kind of governmental policy that
> the LLC should consider.

The health passport concept is speculative in large part at this time.
Where I live it is accepted (as a concept) by some, and refused by
others.  The privacy issue is raised extensively.

However, the premisses of such passports might be already in place.
Maybe what we debate is whether or not to uniformise these papers that
are already required.  We might not debate the creation of a new paper.
Existing papers are: self-attestation pdfs, QR codes on smartphones,
PCR proofs (and their respective fakes) and many other such
COVID-related papers that are already required to cross borders or to
move at curfew times with exceptional reasons.

If such a universal common health-related paper is uniformised and
accepted at gov't level, then how would the IETF meeting organiser
facilitate the obtention of such papers?

A technical concept, on which some WG might  work, is about self
attestation: I prove myself that I declare under honour that what I say
is true.  A sort of self-signed certificate that is accepted by Acroread
instead of requiring a Certificate Authority as a 3rd party (as currently).

An administrative concept is the following: for places that require a
job-related attestation in order to allow to move through, the IETF
might provide a paper that states that this is a job-related
('essential', or similar) movement.

>> last resort in the event that worldwide conditions make it
>> difficult for attendees to even attend remotely.  Not holding a
>> meeting at all has wide implications for the rhythm of IETF
>> personnel policies, such as the nomination process and seating of
>> new officers.
>> 
>> emergencies occur immeidiately before or during the meeting, so
>> that there is no opportunity to make other arrangements.
> 
> Such a paragraph might benefit from an exception that, when
> Cancellation is present for a long time, lists a small number of
> roles that must always be allowed to meet in person, if they so wish.
> For example, the Chair, the IAB Director and the IESG Director must
> be able to meet, if they so wish, at least once a year to discuss
> face to face.  Only them.
> 
> Frankly, I'm skeptical that this is actually a need. If it were, I
> don't see that we need an RFC to authorize the three of them to
> arrange a meeting.
As time advances, and as we head - I speculate - into a range of years 
(not of months) of impossibility to meet f2f, the trust desintegrates.

Maybe we dont need an RFC for that, but I think there is a need to plan 
for something that helps increase the trust levels back to normal.

About RFCs, I suspect there are many places in RFCs that discuss 
'meeting' and that would need update.  For example, in the Tao of the 
IETF RFC it says:
> There is no membership in the IETF. Anyone may sign up to working group mailing lists, or register for a meeting and then attend. 

remark the 'then attend'.  Right now that is very ambiguous.  Actually, 
nobody can 'then attend'.  Or maybe that 'attend' assumes a 'virtually 
attend'.

And I suspect this situation will last for long time now, if we dont do 
anything.

The overall concept of IETF CityName - might no longer have any 
relevance.  We might want to stick to the style, but really what does it 
mean?

This text on the ietf.org site:
> IETF Meetings are held three times per year around the world to promote in-person attendance by IETF participants.

really what does it mean?  'in-person'?  Sorry for the rhetorics.  I 
purposefully accentuate the question marks in order to tell there is a 
problem.  I know I take a risk when writing that.

Alex