Re: [Mtgvenue] Update of RFC8719

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 29 December 2023 17:54 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41645C15C2AB for <mtgvenue@ietfa.amsl.com>; Fri, 29 Dec 2023 09:54:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfxkw0gHLwhG for <mtgvenue@ietfa.amsl.com>; Fri, 29 Dec 2023 09:54:00 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B9EC15C2AC for <Mtgvenue@ietf.org>; Fri, 29 Dec 2023 09:53:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 89C171800F; Fri, 29 Dec 2023 12:53:58 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id To3gs-ooqNWy; Fri, 29 Dec 2023 12:53:57 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 47EDD1800C; Fri, 29 Dec 2023 12:53:57 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1703872437; bh=PB0hREFyqZdIetW3767UOY+/LdZqpDCthaw5ZGSuFWM=; h=From:To:Subject:In-Reply-To:References:Date:From; b=i30z+LUjda+Xot/4ia421L9NCQHRGTIqegWtXKoiQiOO6fq4ZJA3OhkCvsXWTdtv+ BO8LCXiOkVQalboONKXSRW83VadUZuVZ8D6PaTpMDBQHPgYGkaW+NAbQFqBIqSjGZk 9F4W2LwCo3Bcz9k2qLIONivWm/JWy26s7wn8KcGdv+BhGnRiGCf7nZwGnzoxHGHGrm I4T+dN48trqFhRu2a3Rz4tQ5qpNFwWjaDbvBs4P3XqG9PyS+EojGsK6csV60hDUtQl vhY2aVPE8MwQgcD46pcl4fUQq5W0C58YESC4gjX7hU09xYzlTk7K/zDUYCsoq4FlbP y3saRnuU5pdTA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3F5421BF; Fri, 29 Dec 2023 12:53:57 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benson Muite <benson_muite@emailplus.org>, Mtgvenue@ietf.org
In-Reply-To: <937cb1c0-b718-7d78-c27f-7ecdffc81380@emailplus.org>
References: <937cb1c0-b718-7d78-c27f-7ecdffc81380@emailplus.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 29 Dec 2023 12:53:57 -0500
Message-ID: <2329.1703872437@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/_UAYaOMqpOkaHuJUPy2p5ZA1E74>
Subject: Re: [Mtgvenue] Update of RFC8719
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "List for email discussion of the IETF meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Dec 2023 17:54:04 -0000

I see Benson's point is that, going forward into an era where there are more
and more remote attendees, and perhaps some more intentionally all-online
meetings (vs pandemic forced meetings), that rather than document our
1-1-1 as Asia-Europe-NA, that we could do that via time zones instead.

What we would be doing is saying that we need to distribute the pain of who
stays up all night to remote attend, rather than distribute the pain of
travel for those who are in-person.

(It also means, I guess, that we can meet in Philadelphia in lieu of Bangkok,
as long as the in-person meeting occurs in Bangkok time zone.  Not that I
think we would do this, but we could)

UTC-12 for Americas means Hawaii is still in Americas, although we once
counted it as Asia :-)

What Benson's proposal also means is that if we were to return to South
America, or we were to try Johannessburg, that we'd be within rule to do it
during the appropriate time zone.

Brian and John's point: we will likely continue to meet where there are
people who are doing the work.  So in the end, changing the criteria likely
has no actual effect for a long time.  I don't object to the patch, but I
don't see it as helping much.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide