[Mtgvenue] Re: Mandatory / Important
Toerless Eckert <tte@cs.fau.de> Fri, 03 April 2026 02:22 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 A229AD5DFBBE for <mtgvenue@mail2.ietf.org>; Thu, 2 Apr 2026 19:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775182934; bh=9anGl3Vjpoqv7OywNOeNkA9dFad1Dpa2WBg7e2aMUwY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=tBlmL0zHh/JWkYRCfAuG3HFBlLy2bOXpSzLH+Q6f9jseWZN941/4TSRheB+39PR6p URy8ykWIjTh05d17+5gcEiCJpfKkDbTDS0jshkLWFLXn3Nqy4V6PpreY9/IDDhBrAK PTMBj3soI6gKlxBfl6/klF465jRQfdGGpo3luMyg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cs.fau.de
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 Pdh5hFWrhVn3 for <mtgvenue@mail2.ietf.org>; Thu, 2 Apr 2026 19:22:13 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7CD72D5DFBB9 for <mtgvenue@ietf.org>; Thu, 2 Apr 2026 19:22:12 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4fn2Y75Z3pz1RCZ4; Fri, 3 Apr 2026 04:22:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.fau.de; s=r20250630-faui40; t=1775182925; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hPdd9Ec9TztsRyDxhP1x/03IbpPM7Y1K9LduunPamRA=; b=J95nYAcnagDZPhiSuIMZhlFIe+zXUgPBILdhpya1lwkMd5zPp5Ztd2n8BmzUMFVyA0A5C+ cA7XGtvXlTU3npB1fBpVAWJyHnPLKvRcZ01rtza1eu11SGNvfglxEGs6kaBIRG+2uZXNHz BUWhKw2uGv1tUcngBZz2lUgmPoG1PWs7vIfI1A2kRG/lz/vV5jE9qp3x8WVN+icv6Cm7e0 OQfj8+Nwb2ZU/kPeq5NODfzHVLaaxg3rGkVmZKseT2/jpYYwroXyktpCnR47h3s4X1Kjk9 wLHcyYimCni3aiaUQcM4hJFyCw2wlB+ZqWAIpa9HCv9+G5V/4bVouup8//nMUw==
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4fn2Y74tjczkXCV; Fri, 03 Apr 2026 04:22:03 +0200 (CEST)
Date: Fri, 03 Apr 2026 04:22:03 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Eliot Lear <lear@lear.ch>
Message-ID: <ac8kSz3gjOUlZQmy@faui48e.informatik.uni-erlangen.de>
References: <222a28c6-cd63-4e58-8549-3c82dfd337f3@lear.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <222a28c6-cd63-4e58-8549-3c82dfd337f3@lear.ch>
Message-ID-Hash: OREZOJMQ5ELPGRPCUHTMLBHGFDNDJJTT
X-Message-ID-Hash: OREZOJMQ5ELPGRPCUHTMLBHGFDNDJJTT
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
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: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Mtgvenue] Re: Mandatory / Important
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/_1xPyu-ExDTGkvERSp1OAnAd0uk>
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>
Eliot:
I am obviously using a much better, 40 year old email system (;-), but:
Its IMHO not thunderbirt: I think that this is a controversial topic that would benefit from
a more interactive discussion option such as conf call or side meeting at
next IETF.
My main problem has been that the document so far is too terse and does not
explain the reasoning of the contentuous point to the extend that the possible
requirements do not looks - as they do in erics current draft - es explicitly
targeted to bias against China when what's being done is not substantially
different than what other countries do.
Yet nobody beside me seems to be concerned about this and continues to think
we can provide a good resolution by just refining our degree of importance
for the subject matter. Without any sufficient justification/explanation.
Cheers
toerless
On Thu, Apr 02, 2026 at 10:17:58AM +0200, Eliot Lear wrote:
> Hiya,
>
> I'm starting a new thread because y'all make Thunderbird painful with so
> many messages.
>
> Stephen, thank you. I like your summary as well modulo a slight nuance: RFC
> 8718 puts considerations into three categories (Mandatory/Important/Other
> Considerations). That's somewhat analogous to MUST/SHOULD/MAY. I would be
> considerably more comfortable, at least for now, if EKR's draft used the
> Important category. What the difference means:
>
> Mandatory:
>
> > If criteria in this subsection cannot be met, a particular location
> > is unacceptable for selection, and the IASA MUST NOT enter into a
> > contract.
>
> There are only *two* mandatory criteria. There are a few reasons for that
> but from my perspective, both are filtered through the lens of whether it is
> simply impossible to have a successful meeting if either are not met, and I
> might have written the accessibility one differently today.
>
> Important:
>
> > The criteria in this subsection are not mandatory, but they are still
> > highly significant. It may be necessary to trade-off one or more of
> > these criteria against others. A Venue that meets more of these
> > criteria is, on the whole, preferable to another that meets fewer of
> > these criteria. Requirements classed as Important can also be
> > balanced across Venue selections for multiple meetings. When a
> > particular requirement in this section cannot be met but the Venue is
> > selected anyway, the IASA MUST notify the community at the time of
> > the venue announcement. Furthermore, it may be appropriate for the
> > IASA to assist those who, as a result, have been inconvenienced in
> > some way.
>
> There are a good number of Important criteria, but in my experience, the LLC
> does an exceedingly good job at satisfying *all* of them as well for just
> about *all* attendees, and a good hint that this is the case is that you
> don't see a lot of announcements from the LLC about Important criteria not
> being met. There are I think there are two cases where it's not 100% for
> 100% of attendees:
>
> > * Travel barriers to entry, including visa requirements, are likely
> > to be such that an overwhelming majority of participants who wish
> > to do so can attend. The term "travel barriers" is to be read
> > broadly by the IASA in the context of whether a successful meeting
> > can be had.
> >
> > * Economic, safety, and health risks associated with this Venue are
> > acceptable.
>
> In the first case, I am unaware of a single country that makes it easy to
> get into for *all* attendees. That's why we move around, and we anticipated
> that aspect when we wrote 8718. In the second case, I am aware of at least
> one attendee suffering allergies in IETF hotel rooms, but that was a while
> ago.
>
> The second case is very close to the proposed new privacy criterion, so
> let's at least consider them in the context of one another.
>
> Why Important and not Mandatory for the privacy text? There are other risks
> that the LLC has to consider, principal among them (IMHO) being our physical
> safety and well-being. I really don't see how, even on paper, we could put
> the privacy considerations above those, not because privacy isn't important,
> but because those other ones are. I'm also not suggesting we put privacy
> considerations below those others either.
>
> The second reason for Important and not Mandatory is that if the LLC must
> formally evaluate venues for this criterion as Mandatory, we might well
> indeed find that many do have certain requirements to release information
> under certain circumstances, and that we would have inadvertently wheedled
> down our candidate list to just a handful of venues.
>
> That stated, I could be entirely wrong about the last point. Running code
> and experience could provide us valuable insights, and if it turns out that
> I am, we could promote the requirement later. Going in this direction
> rather than Mandatory first meets the principle of least astonishment. The
> world is a volatile place right now; just ask the FIA who had to cancel two
> F1 races, where average attendance is between 300,000 and 400,000 people.
>
> If we go the Important route, I imagine that we could also finish quickly
> (though I could be wrong about that as well). In particular, I would really
> want to hear from those who would object to such a criterion being
> considered.
>
> Finally, I would like that Ted's point about regulatory surprise not get
> lost in all of this. Perhaps the best way to deal with that is a PR?
>
> Eliot
>
>
>
> > Hiya,
> >
> > On 02/04/2026 00:42, Toerless Eckert wrote:
> > > On Wed, Apr 01, 2026 at 10:43:38AM -0400, stndrds-inacio stndrds-
> > > inacio wrote:
> > > > immaterial. My home country and its governance is immaterial
> > > > to>> the operation of the IETF network. ...
> >
> > > I think that if we start to make decisions about policy desires
> > > against host countries
> >
> > I think the above nicely demonstrates a core mismatch in this
> > discussion. (*)
> >
> > Some people (Chris, I think, and me, and others) consider that
> > the IETF meeting n/w is a small, temporary, meeting n/w that
> > ought follow policies the IETF community control for how to run
> > a better-than-good meeting network (and allow experimentation).
> >
> > Others, (Toerless, I guess, but not alone despite the many mails:-),
> > consider that if community-preferred meeting n/w policies conflict
> > with venue-local regulations, we ought preference the latter for
> > diversity reasons, esp. if that might affect the set of locations
> > considered acceptable for possible future in-person meetings.
> >
> > I don't think Toerless is alone is his opinion, nor that Chris
> > and I are part of a small group of oddballs. Nor do I think the
> > different positions are reconcilable. (Mine is the right one,
> > obviously:-) But I do think, in the light of the IETF-125 n/w
> > experience, we could and should document more about what we
> > consider a better-than-good meeting n/w is, and, separately,
> > how we think that affects location choices and ought feed into
> > LLC venue selection.
> >
> > For me, that suggests we ought iterate on ekr's draft text,
> > and then have a fairly typical MUST vs. SHOULD debate as to
> > the impact on considering venues not clearing that bar.
> >
> > Cheers,
> > S.
> >
> > (*) The word "against" is just wrong. It assumes that anyone
> > who didn't like the IETF-125 n/w setup is anti-China or some
> > such. That seems like a classic case of a mail reader assuming
> > they know the inner thinking of a mail sender, a setup that
> > basically never works out.
> >
> >
> > _______________________________________________
> > Mtgvenue mailing list --mtgvenue@ietf.org
> > To unsubscribe send an email tomtgvenue-leave@ietf.org
>
> _______________________________________________
> Mtgvenue mailing list -- mtgvenue@ietf.org
> To unsubscribe send an email to mtgvenue-leave@ietf.org
--
---
tte@cs.fau.de
- [Mtgvenue] Mandatory / Important Eliot Lear
- [Mtgvenue] Re: Mandatory / Important Brian E Carpenter
- [Mtgvenue] Re: Mandatory / Important Toerless Eckert
- [Mtgvenue] Re: Mandatory / Important Ted Lemon
- [Mtgvenue] Re: Mandatory / Important S Moonesamy
- [Mtgvenue] Re: Mandatory / Important Rob Sayre