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

[Ted Hardie <[e-mail]>]

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 PM John C Klensin <[e-mail]> 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
> <[e-mail]> 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
> >> <[e-mail]> 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
>
>