[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
- [Mtgvenue] Venue selection, transparency, and the… Ted Hardie
- [Mtgvenue] Re: Venue selection, transparency, and… John C Klensin
- [Mtgvenue] Re: Venue selection, transparency, and… Ted Hardie
- [Mtgvenue] Re: Venue selection, transparency, and… S Moonesamy
- [Mtgvenue] Re: Venue selection, transparency, and… Ted Hardie
- [Mtgvenue] Re: Venue selection, transparency, and… S Moonesamy
- [Mtgvenue] Re: Venue selection, transparency, and… Livingood, Jason
- [Mtgvenue] Re: Venue selection, transparency, and… Eliot Lear
- [Mtgvenue] Re: Venue selection, transparency, and… Livingood, Jason
- [Mtgvenue] Re: Venue selection, transparency, and… Eliot Lear
- [Mtgvenue] Re: Venue selection, transparency, and… John C Klensin
- [Mtgvenue] Re: Venue selection, transparency, and… Eliot Lear
- [Mtgvenue] Re: Venue selection, transparency, and… John C Klensin