[Mtgvenue] Re: Mandatory / Important
Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 02 April 2026 19:37 UTC
Return-Path: <brian.e.carpenter@gmail.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 73E97D5B4EB7 for <mtgvenue@mail2.ietf.org>; Thu, 2 Apr 2026 12:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775158676; bh=rcQmdGMCAjyBDMvE4fiWFCVdhUdhLWdmyg6hScJhOeI=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=k+GkbWcb09sIqvKuenn9WyQlWCoAXBnv7pDCPw+AvnIxMrHkbz2XwIoOjNA4J/fxm PTZ9d0u2NHBfSJabO1NkhIOXQIiwqXnM+aCi1O7ULJaWoNLypidrfXnIYQYPAaks/5 sqqyOfRcIbc/SVOT6KzapnxYfWme8Ml7ABrblP88=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 ZRmI2xxonGhG for <mtgvenue@mail2.ietf.org>; Thu, 2 Apr 2026 12:37:55 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 D9A6AD5B4EAA for <mtgvenue@ietf.org>; Thu, 2 Apr 2026 12:37:55 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-82ce09b4197so574575b3a.2 for <mtgvenue@ietf.org>; Thu, 02 Apr 2026 12:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775158675; x=1775763475; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rcQmdGMCAjyBDMvE4fiWFCVdhUdhLWdmyg6hScJhOeI=; b=Y4I9sEfyy6nrWbUd/3BJgEUO0gYESD/r6MLT7hszw3I7yjgT0Za+AAuoQ+cN6w/XCi nI+BH61CMSxm0gZfzhFq/aXKl7TrOQUTeEPJ9W4Cqi3v0T6fIr/u+CcY6bAAKL4HCruk Q+H/BSpGQoxMKRJvMqqINDqqPFL2Y3Xfl9j3JIUfVbitq2iaBsg4EdD5KVz06jZSF4ha w947cMyVrifaJzgyqPiJex+7fu42eeL9tAIHZW3Le4ObRd6OVv/TGI3I0oxxaU0m+Tff WUK13a9LAxOxE7OKNLVpPX3i+42w5N8rtF9+q+pRfVqVaLTgDmVqWMrvLxNjSKtEE5eQ S/8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775158675; x=1775763475; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rcQmdGMCAjyBDMvE4fiWFCVdhUdhLWdmyg6hScJhOeI=; b=mvfG43NKghEljGFuI/c4lDKMY/R6r80ZcpXrmMQwPhZWWRyrGNnEE1quYk8zb+SSrk /QAboSyJa1KPAjPRa/nMaCpn9RzQoabuIU+EakdMZMDBduJoW8xhpsJcRzoERmI9HeWr 936QKLr4sz7PeDKOU+LHkrCfMtd1A4umnME7sOrqpfnSZaL7vfwngXiJTb6yha9AEIxd lO5VaZ0B3VLtyjenzYsR5SCjXSyjOqEBz6G/zQkO+QVZikjkSWQKB7NNxX9GW4Ht3toQ ZJ5jOBFRKH7RUMy5MZXKodCHgk/Bl/16nvOhQyUe73QysesGp2ymCSxBsujX8J90GEGp 3HKg==
X-Gm-Message-State: AOJu0YzbuXdxFmsJtY1lVLkPrqROgjj9kjSKZShqPp2R1NX6qEYPhCAg neGzx85yE8Paoz3NW9HhTGrbYEsDowG4v/1VK4A+o/a0LG04mBA6OaAb
X-Gm-Gg: ATEYQzyCpO524yIO0uQT2tZTIupTTO8gHo1QVBBeVM7/mPA4WxgQlfK0EccOO9oa2+X GymX8WNT5aFWCZyHgMOcmVGkJN1VJD+cIbuHyHkFHFcX1tVUWKEKEnuMEtPWsnU9/jzUZBoS6+/ 0rBC8fhztx0NKpVYIhY3M/ZwXs+LDZRcpcJFz1hYADJ3K7jr8N3UQwvzPEZAA821Seo4iXIV7Iz spleE8po682N2MxrtumVM3Ki2CZbG1ETGwVlW9Y3OCPeZRX7oVFWUzK8+MK4NbYEn7t/rydFitY 3RhriZVIf40aSN7ugza9GpHk1Br7GPc89RxkaB4CplnLGpC3b1aTROWAhERrmmXLqosVu1KBHvc Tb4pPCDZ70lBI1FxidL9/1M5h/c21HZ4wWpO7eNEfCARyiorfMFgKNjNmfhcm4SWhkpPrhBg6DL iHd4isTS4LGgi6gv2MmtQW4Dp18VwebyVtTxzqOY/AgNwmb1PhGAHzspT3A/u198K0voiM4X6ir fSQeKKMmt5WWLYKDw==
X-Received: by 2002:a05:6a00:ab87:b0:82c:24a9:d5f1 with SMTP id d2e1a72fcca58-82d0db3f376mr363501b3a.30.1775158674899; Thu, 02 Apr 2026 12:37:54 -0700 (PDT)
Received: from ?IPV6:2404:4400:a100:1829:5956:ca53:df83:6568? ([2404:4400:a100:1829:5956:ca53:df83:6568]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82cf9c3d439sm3944784b3a.35.2026.04.02.12.37.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2026 12:37:54 -0700 (PDT)
Message-ID: <93fb1a91-bac9-4766-a634-c67dd78b050e@gmail.com>
Date: Fri, 03 Apr 2026 08:37:49 +1300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Eliot Lear <lear@lear.ch>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <222a28c6-cd63-4e58-8549-3c82dfd337f3@lear.ch>
Content-Language: en-US
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <222a28c6-cd63-4e58-8549-3c82dfd337f3@lear.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Message-ID-Hash: NFL52KT23QU3JEZBKHUTDFYKTD2QJSCZ
X-Message-ID-Hash: NFL52KT23QU3JEZBKHUTDFYKTD2QJSCZ
X-MailFrom: brian.e.carpenter@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@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/VIRczdeIfbmhxKmwTfciTNHwII0>
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,
Thank you for changing the Subject when changing the subject.
I see that the 3 (not 2) Mandatory requirements in RFC 8718 include the phrase "there may be no additional limitation that would materially impact their Internet use." If (for example) a venue blocked VPN usage, that would kick in. But there's a strong case for arguing that intrusive breach of privacy is one of the many trade-offs in the "Important" category. In fact, if the sentence you quote below had read:
* Economic, safety, privacy, and health risks associated with this Venue are acceptable.
we probably wouldn't need to have this conversation. Given that we have a Privacy Considerations section in the RFC, this was a bit of an oversight.
Regards/Ngā mihi
Brian Carpenter
On 02-Apr-26 21:17, 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
- [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