[Mtgvenue] Re: Venue selection, transparency, and the rate of change

John C Klensin <john-ietf@jck.com> Fri, 27 March 2026 16:42 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: mtgvenue@mail2.ietf.org
Delivered-To: mtgvenue@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6CFF5D2853A6 for <mtgvenue@mail2.ietf.org>; Fri, 27 Mar 2026 09:42:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1774629747; bh=NPF+D3NLQCqde7BxDHhhFT6wOGKrk3iMK3lLL/XEMuo=; h=Date:From:To:Subject:In-Reply-To:References; b=I6M71yafVu4KS3HI0oTMtYHhNDiB65svMiD5YReKgLj5+U326kgLs5w9U+nCK0hHf YL/PyEtnNVlvO38DYjmOfh4j3EKdFZpUsTar6PewVzHxCfrDj9ImjkdJsZbZ04rc8S KyHc3LLjIMhKWpYyy6XhmSUhX92EL/sMNHgbsLgU=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN1SCXBPqSDL for <mtgvenue@mail2.ietf.org>; Fri, 27 Mar 2026 09:42:25 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id 68949D2852E2 for <mtgvenue@ietf.org>; Fri, 27 Mar 2026 09:41:39 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1w6AFe-0003LJ-18; Fri, 27 Mar 2026 12:41:38 -0400
Date: Fri, 27 Mar 2026 12:41:32 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ted Hardie <ted.ietf@gmail.com>, mtgvenue <mtgvenue@ietf.org>
Message-ID: <D01A4E8497EB4B3EC667F65E@PSB>
In-Reply-To: <CA+9kkMBMn8a+_N1ThfSmO4bqMqo+CQ6KnS1Q2Kp9+AciDb8HWg@mail.gmail.com>
References: <CA+9kkMBMn8a+_N1ThfSmO4bqMqo+CQ6KnS1Q2Kp9+AciDb8HWg@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Message-ID-Hash: B4MQ5AN3WS56HPL3DB366XYGD27AEBPJ
X-Message-ID-Hash: B4MQ5AN3WS56HPL3DB366XYGD27AEBPJ
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mtgvenue.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Mtgvenue] Re: Venue selection, transparency, and the rate of change
List-Id: "List for email discussion of the IETF meeting venue selection process." <mtgvenue.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/cE5JWwM0POBDl3fO3JGq-LjMFBM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Owner: <mailto:mtgvenue-owner@ietf.org>
List-Post: <mailto:mtgvenue@ietf.org>
List-Subscribe: <mailto:mtgvenue-join@ietf.org>
List-Unsubscribe: <mailto:mtgvenue-leave@ietf.org>

Ted,

I think we largely agree.  A few additional comments, some of them
drawing on a few of Rob Wilton's notes...

--On Friday, March 27, 2026 09:58 +0000 Ted Hardie
<ted.ietf@gmail.com> wrote:

> Howdy,
> 
> I'm pulling out a statement of Jay's from the thread "is identity of
> individual already covered by BCP 226", because I think it speaks to
> something that is a more general concern, which is when community
> consultation is necessary or desirable.
> 
>> While I'm here I should also address the other big question - had
>> the LLC known far in advance that these are the legal requirements
>> then would we have booked this meeting?  Unfortunately that's too
>> much of a hypothetical for me to answer but I can say that it is
>> likely a community consultation would have taken place before any
>> decision was made.  This clause in RFC 8711 being the important
>> one:
>> 
>> "The Board is not intended to directly define the IETF's needs; to
>> the extent that is required, the IETF community should document its
>> needs in consensus-based RFCs (e.g., as the community did in
>> [RFC8718]) and provide more detailed input via consultations with
>> the Board (such as takes place on email discussion lists or at IETF
>> meetings)."

> I very much appreciate Jay's confirmation that these conditions
> would have resulted in a community consultation, had they been
> known before the venue was selected.  That's a sensible position,
> and I think we as community should be happy knowing that the
> interpretation of RFC 8711 is biased toward community consultation
> in the face of new issues.

Strongly agree with both the appreciation and the conclusion.

> I think we all also recognize that the information on this change
> came too late to actually change the venue; the meeting could have
> been cancelled at short notice (as some were during the initial
> phases of the Covid-19 lock downs), but there was no effective way
> to move it.  Greg's message conveying the initial changes was
> February 10th, about a month out, and Jay's follow-up with the
> actual conditions we experienced was March 10th. That message was
> close enough to the hackathon timing that I'm guessing some folks
> were already en route.

Exactly.  Note, however, that we probably could still have taken the
meeting all-remote had a decision been made to do that around
February 10.   I'm not suggesting that would have been a good idea
(I'm guessing it would not have been), only that, in thinking about
what that example tells us about future guidance, it might have been
possible.  Also, hypothetically, had Greg's not appeared closer to
the first of the year, it would even more likely to have been
possible.  Consistent with your other suggestions, I think that some
general discussion and guidance about conditions for canceling an
in-person meeting and taking it all-remote would be desirable.

> Given this experience, what guidance can we provide for the future?
> First, I think we should be clear in our guidance that the risk of
> regulatory surprise should be taken into account in venue
> selection.

Without taking away from, or disagreeing with, your further comments
about this, there is some question about whether, given developments
in Hong Kong and Guangdong Province over the last few years, these
particular changes and their announcements should have been
considered a surprise.  In other words, while the specifics of the
changes were clearly a surprise, it is not clear to me that we should
have been astonished by changes of that general sort, nor of the ones
in Hong Kong you mention below.   That may call for another sort of
discussion, which is the community's expectations about the LLC
maintaining ongoing situational awareness about scheduled meeting
venues (a special cast of that appears below).

>  In this instance, Jay's message of March 11th, in reply
> to SM, confirmed that the regulations which set these requirements
> were confidential:
> 
>> On Wed, Mar 11, 2026 at 7:41 PM S Moonesamy
>> <sm+ietf@elandsys.com> wrote:
>> 
>>> 
>> Would it be possible to share a link to the regulation(s)?
>> 
>> 
>> When we asked we were told that all details regarding this are
>> confidential and cannot be shared with us.

> The overall risk of late surprises in territories where regulatory
> rules are not public is very high, and I think we should provide
> guidance to avoid them and any other territories in which it is
> clear the regulatory environment that would effect us is undergoing
> rapid change. 

Guidance, yes.  See below.

> (To give an additional data point, another change
> occurred just after the meeting ended, which impacted some of us
> transiting Hong Kong:
> https://hk.usconsulate.gov/security-alert-2026032601/.  That made
> it a criminal offense not to provide passwords or decryption
> assistance to access all personal electronic devices including
> cellphones and laptops.)

Ironically, while the odds of its application to semi-random
travelers --a category that, as far as the Chinese government is
concerned, probably includes most IETF participants -- that rule
takes us back very close to rules in effect at the time of the
Beijing meeting.  Those rules figured prominently in the decision by
many of us to take only thoroughly sanitized laptops and other gear
-- gear that, in principle at least, we could afford to lose-- to
that meeting.  That meeting was generally judged to be very
successful and non-intrusive, but the potential for problems was
there.

When you say it impacted you this time, were you (and others)
actually stopped, detained, and required to supply that information?

> As part of the discussion of lessons learned from IETF 125, I hope
> that we can discuss when a venue selection should be taken back to
> the community for discussion.   A month out was effectively too
> late, but we have had earlier warning for similar issues, and we
> likely will again.  Some guidance on this to the LLC would be
> useful, and I hope we can provide it.

Agreed.  I'd also like to see some discussion of two related things.
One is whether the LLC should be strongly encouraged to make checks
for changed circumstances between when the venue is chosen and
announced and closer to the meeting.  Recognizing that, as you
mention above, it would typically require a huge amount of advanced
notice to change the location of a meeting, it would generally take
far less notice to cancel the venue and take the meeting all-remote,
we should also probably discuss guidance for such a decision.  In
both cases, but especially the latter, those discussions should be
informed by an understanding that there may be details the LLC cannot
reasonably share with the community lest contractual arrangements or
negotiation possibilities be impeded (or worse).

Finally, and maybe most important, I think we should consider all of
these things, including suggestions and proposals arising our of the
recent experience, as sources of guidance, adding to or modifying the
list of criteria to be considered, and topics on which the community
should be consulted as and when appropriate.  I think we should avoid
any firm and absolute rules, or even rank-ordering priorities,
because circumstances are always different and such rules will either
capture the completely obvious or, eventually, provide good
mechanisms for shooting ourselves in the feet. 

best,
    john