Return-Path: 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 129BED287880 for ; Fri, 27 Mar 2026 09:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1774630797; bh=oIjPmPyxXoM2tVI756M4FMGfGEtc2qZ33jOqVqW3xEM=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=myCEXMF7Dix62Li6XbyV1+L09/y+WzMmuqee3U4mZiRZ7xSTl2dPFF8GlV4kUDtX0 NelmEYTjSGRqQPLrjpXi8Q07rIcha5yoDTMdweBcfwt+5whmga7ZWsqoZ+UmK0M+dE /csU9m85IkvJi8yR10PunIaj/zllE1Tvl2G7drWA= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9YeSt-pahkDu for ; Fri, 27 Mar 2026 09:59:54 -0700 (PDT) Received: from mail-yx1-xb131.google.com (mail-yx1-xb131.google.com [IPv6:2607:f8b0:4864:20::b131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5C8FCD28767A for ; Fri, 27 Mar 2026 09:58:38 -0700 (PDT) Received: by mail-yx1-xb131.google.com with SMTP id 956f58d0204a3-64c9a6d7f81so2383794d50.3 for ; Fri, 27 Mar 2026 09:58:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774630718; cv=none; d=google.com; s=arc-20240605; b=f+y+4QsBC5zVqN8uO1JbQWxpHVZTujqAfpZ1967hYf717reJJD3GLMFn2AN1UhUsqs 2Qj046q7S6hgnO2kDOzBBzmIp63Pt2IAwhQy6oGwiIulfY9BPWQvvSXwZ65xir3Y74SY B8KSKWRwF2mD1KWWBI8/g9NEOD0fkd6OPhzrC3M3jlFNa2rc2Pi/84tIC8qFlKUl10wl gdaZpH7YdGFHzbx58MWI/UFc4XzTxhILW7EPHwSIaMpczunL4c+Sh1JFPhTAPBx1OtDp sSPwZogNqTlz5d2J5qSeVoL1vFvSwBD1sOKgpvT6OAatQMy5OSF2ZWMQzDIzgtp6+sc9 1TrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=yA57dDjiUcH13QBsLz7kqaOIEqHSa/4ypvFrRgIBnhI=; fh=Mk4RYf/Meho/daQ813aBbeySa2CjoRQDEciSqleeIzY=; b=d2El6+ATH31ugOCC9hgZS9OL3CMMp8phAmMryqvxHyVvkecTCsgQn6wuV/NavnqBtQ JF2qHSu461eKY2ItwMVKwetPpH8YC27Oke0y1QLAB+0YQYWXgqh4VdGZ5xUY7yT23l2W zVuK+l4XBaviYsVp16n0Mybrv/JX5JP67j0ev5ufW08866mY6seKt7JOphlTxMCU6mFF /tokGO4xyc0lOsZrkUG7Y7KoE7D4gWNGK+uVyRRsoM747BNyJd68tXkdaBMeIh/FV2tC WwOzIXrPzI+KhvCPCxyJcph3Qu19CtM4Q/KUGSJ9NHVYqfqnA2A1nBo8RRWcOja//Pef Imqg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774630718; x=1775235518; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yA57dDjiUcH13QBsLz7kqaOIEqHSa/4ypvFrRgIBnhI=; b=nWSNb6GcS8ZJ5HmBe75rRSE1oBzIiBLx/4w+NFp+E8DtUMSjjGUXxjBSJMV+gfbejZ K3NT10PAMOYcvIt2uMduZdKSCm8y5AcOs4ffYlnhevttqCezaUms9ThyBK85fX0hYtst 7L0/vYZYKMwOFO6451C4NEz088kR0mRKF9q2uIAs0BQ1Eo4brnpobs52P3/caQIrEdod tH6so63SAqh94G8MoNHqp53PQhQ0RdkyOYj32MonAwCPMw77OGd2jSFjeVaoriBZn2Rc SUpZPzu5WKWaGzMc/z2LJBBoLWMYf+mvdaTc/5qU1DN5fF3WudixjIOlkCdxg0Nu1KXo OFww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774630718; x=1775235518; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yA57dDjiUcH13QBsLz7kqaOIEqHSa/4ypvFrRgIBnhI=; b=aOy9801bbp4yT1YipnCWZNqisYOZcuZxLVkh/CmWW6bL4D+HcZon6XovZtVLTmWDkg QaX5YvGTY771do+ADpTC1wcEEj9xmyKUyP45raWm0Sps8RLfXPIGERMQ9zeZ4U7XFdqu Fjuq1E46dt1rbqe4npw4Qxb+UNk+LX32fQdkzhgQxditUlyN6UoXw1BG82yLkqNgGhi5 aHNmxFqqTQYzyVU1dQb/zwwT5YRp/4YNqwdKtt4TGFkHwVQaiGe9TVXdUc2/1i4b8pig HsInkdboBe+XDPIUdczMm2w3rQaZiaJU5DDeRcM9Iw7wMk8zC41bDlBEgACZL5U/hfK3 g9+Q== X-Gm-Message-State: AOJu0Yx4fssLgSmR1F59aWdfG7sIv5+XEy4jHPFoo58u9i7Xkmbb7C5n MA741+U/GqVuFiEuD/9o1OMo7tto6A1zBwvJXyNHlZt0QZAvBQZ8bv6zxDmM2fT/VrHqwPeV3tR hGYq+DrJvW9wrV+/dZKy/J078s3fJ8r8rw+SO X-Gm-Gg: ATEYQzzbg+Ri9w03lqjHdNVQjhZAPanU1cIAO9B7l23MUR2iD4h0uRBx5zGEUqb9mE/ Mm8PCSqBhe4P7w5rijF6260ImA+T7Af8zssKFDXizyrd11h0a3yT2GnfmhSU7VaPKyXyoAyEzFa eO8+yX3myYvhfYCzq6J+vtAAv7k4xJg5Cjk16nuU2PzNlWrsqHt53lsKVWjMGyVbCZrYNuzUBKl 7br/ZLMQ7XPQzqxYLftfhJoDcBv/arhB2x4THpJGRCQHvhWUKbUIH6qJMNPMavDFWPwwzFWBwZj g097XVl7Z9vooJ/rECXpT+Z0hC/9JwiYfNwWGC3aco0ouR67gUgvFvOBGLXt4l3yzm37SWZxL7T MF3IhMSOOHk1S2Gc0VltvTuGiM442xfFSCcLXUY7zUqXvIuOTrXezD5ojElf7clxBB3QdDncYrs YWpnPzK2SDBKKvijqj2xoxFFc3c3jVqP3GDM9VuAoauXoFVXuwutqwm26K X-Received: by 2002:a05:690e:14cd:b0:64f:fc0d:6242 with SMTP id 956f58d0204a3-64ffc0d63f8mr2444399d50.61.1774630717633; Fri, 27 Mar 2026 09:58:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Fri, 27 Mar 2026 16:58:10 +0000 X-Gm-Features: AQROBzCm9z2Od0-c0o9044kLhtZLcCdPLLdcRd_BiLIIdlM3Qdlu0Fh16YXxb6g Message-ID: To: John C Klensin Content-Type: multipart/alternative; boundary="000000000000883899064e04694d" Message-ID-Hash: BKG7HQCBFPKXQND5RQHRYJ5L6BFDWZOW X-Message-ID-Hash: BKG7HQCBFPKXQND5RQHRYJ5L6BFDWZOW X-MailFrom: ted.ietf@gmail.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 CC: mtgvenue X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BMtgvenue=5D_Re=3A_Venue_selection=2C_transparency=2C_and_the_ra?= =?utf-8?q?te_of_change?= List-Id: "List for email discussion of the IETF meeting venue selection process." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000883899064e04694d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Thanks for your reply. I'm top posting to clarify one aspect of my original message, which read: "To give an additional data point, another change occurred just after the meeting ended, which impacted some of us transiting Hong Kong" By that I meant it changed the risk profile for those going through Hong Kong after this came into effect, not that I was personally requested to supply my credentials. My apologies for any confusion. regards, Ted Hardie On Fri, Mar 27, 2026 at 4:41=E2=80=AFPM John C Klensin = wrote: > 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 > 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=E2=80=AFPM S Moonesamy > >> 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 > > --000000000000883899064e04694d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi = John,

Thanks for your rep= ly.=C2=A0 I'm top posting to clarify one aspect of my original message,= which read:
"To give an additional data point, another change occurre= d just after the meeting ended, which impacted some of us transiting Hong K= ong"

By that I meant it changed the risk profile for tho= se going through Hong Kong after this came into effect, not that I was pers= onally requested to supply my credentials.=C2=A0 My apologies for any confu= sion.

regards,

Ted Hardie



On Fri, Mar 27, 2= 026 at 4:41=E2=80=AFPM John C Klensin <john-ietf@jck.com> wrote:
Ted,

I think we largely agree.=C2=A0 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?=C2=A0 Unfortunately that&#= 39;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<= br> >> decision was made.=C2=A0 This clause in RFC 8711 being the importa= nt
>> one:
>>
>> "The Board is not intended to directly define the IETF's = needs; to
>> the extent that is required, the IETF community should document it= s
>> needs in consensus-based RFCs (e.g., as the community did in
>> [RFC8718]) and provide more detailed input via consultations with<= br> >> the Board (such as takes place on email discussion lists or at IET= F
>> 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.=C2=A0 That's a sensible posit= ion,
> 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.=C2=A0 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<= br> > were already en route.

Exactly.=C2=A0 Note, however, that we probably could still have taken the meeting all-remote had a decision been made to do that around
February 10.=C2=A0 =C2=A0I'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.=C2=A0 Also, hypothetically, had Greg's not appeared closer to=
the first of the year, it would even more likely to have been
possible.=C2=A0 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.=C2=A0 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.=C2=A0 =C2=A0That 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).

>=C2=A0 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=E2=80=AFPM 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.=C2=A0 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/.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 =C2=A0A month out was effectively = too
> late, but we have had earlier warning for similar issues, and we
> likely will again.=C2=A0 Some guidance on this to the LLC would be
> useful, and I hope we can provide it.

Agreed.=C2=A0 I'd also like to see some discussion of two related thing= s.
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.=C2=A0 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.=C2=A0 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.=C2=A0 I think we should avoid<= br> 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,
=C2=A0 =C2=A0 john

--000000000000883899064e04694d--