Re: [Mtgvenue] New Version Notification for draft-daley-gendispatch-venue-requirements-02.txt

Benson Muite <benson_muite@emailplus.org> Sun, 03 March 2024 08:04 UTC

Return-Path: <benson_muite@emailplus.org>
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 88BE3C14F699 for <mtgvenue@ietfa.amsl.com>; Sun, 3 Mar 2024 00:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 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, NICE_REPLY_A=-0.091, 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=emailplus.org header.b="J7ppQPim"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="ELgCecRL"
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 bnpe44NKsW3a for <mtgvenue@ietfa.amsl.com>; Sun, 3 Mar 2024 00:03:56 -0800 (PST)
Received: from fout2-smtp.messagingengine.com (fout2-smtp.messagingengine.com [103.168.172.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA729C14F61D for <mtgvenue@ietf.org>; Sun, 3 Mar 2024 00:03:55 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id EA63B13800A1; Sun, 3 Mar 2024 03:03:54 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 03 Mar 2024 03:03:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emailplus.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1709453034; x=1709539434; bh=56DT6lzxxcVQ0mDS4XCGFzTrR9Ihw9I5 3OuwZ9Aa3lI=; b=J7ppQPimh9/tmo3EnXDPcdXRyMq6YeDTS/5hy4IqUJEDdFts NlgH19UMzGfjFn1tzONtVpVr3D/vUFpoOokY4PDAy8KsryrJIhW11iaYM8Fdyp+7 S40IJPwlvUY5TrZInIdFxEECzBEL1r/Ix7qX1CyeSvIN8d958x0djolYumpxLxEe XIeOhwkixyp0+u063t1R67dtb7CaLLe5kXcndwFsC7Qa8uM9F1bRBaFeCG1uRqmI NcE8vW3b/EQ0scc5HuWhGrmOfdotJzoDSnoPm4CWeFteWcfW/Ua/28AYrlyp97RL 1Oj7jHoNjAg+3OC2a5q59aUiwb+gt27aRwzY2Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1709453034; x= 1709539434; bh=56DT6lzxxcVQ0mDS4XCGFzTrR9Ihw9I53OuwZ9Aa3lI=; b=E LgCecRLWFk+JtiG6PDBzy1c2KAruVytqTP8a1rPOBs0+DwuujnkEuwOXBmDrAEd/ 4r+/qH60AE5fm3GQP8b38HTCf0Vsoaof+ec5a4XObAo0n60FifznNDrzfD5J+i+S 3FsgWineiSoNE05XSzqrPqMlhzEyF0qVEdeWP7kqcy9QCFXd4wcG7wb/OT5108AB YFdrLFzeF0CPQOsun9SL+uRr68qqYJCy9zpRAGJTS6mY7rMkx8q5Z7VHOAoaaH0Y xVu/nG3ip6A17a3+ZwhyoPgO7+uOPRqmZPHv/i8Mew9r0xex7OP9lduuLxjZzkKz EfhJcNqPaTy2GGY6FDMcw==
X-ME-Sender: <xms:6i7kZZgICQm1THcWBishP08zRa2lMcdHHx4UZXBgvDuz8-A2kpDH4Q> <xme:6i7kZeBUp_p-hFP99-FHcGMu_3csXHkfSv6BPTiQjw2Y90qxuYas5NmZE5vPCAVD3 clftuVh9CL6flOL>
X-ME-Received: <xmr:6i7kZZG7YIWPt9O4x9gdCCCU41HeRArG75gLzxbHJRBN58yZ9GE_QGZCx2FQogceb_mJEQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrheeggdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfvfevfhfhufgjtgfgsehtkeertddtfeejnecuhfhrohhmpeeuvghn shhonhcuofhuihhtvgcuoegsvghnshhonhgpmhhuihhtvgesvghmrghilhhplhhushdroh hrgheqnecuggftrfgrthhtvghrnhepuddtvdegheeltdetvdeuvedvudeileeffeetiedu heekfeekudfhfeejkefgueegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepsggvnhhsohhnpghmuhhithgvsegvmhgrihhlphhluhhsrdhorhhg
X-ME-Proxy: <xmx:6i7kZeSOQ5-k4dQBsaleptO0-VRcGtumbuadkBBOl7UIGjPHuOYnHA> <xmx:6i7kZWxzmDBe9BYfJ007gMZ6C7TQBk8gBXFfMqT_h_lrMHpSFJfMbg> <xmx:6i7kZU7JEjlvWNfbb89vC9o-dZCEe3iE0q4e8m9kcJZM1YtwqlUsJw> <xmx:6i7kZQsmpLeBplXQVp9I21_QfuHwVY9wviyg1Bw1dCvNotES363X-g>
Feedback-ID: ic1e8415a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 3 Mar 2024 03:03:52 -0500 (EST)
Message-ID: <1a5b3997-2778-d265-afe3-d76f74d0cbbd@emailplus.org>
Date: Sun, 03 Mar 2024 11:03:48 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-US
To: Eric Rescorla <ekr@rtfm.com>
Cc: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>, John R Levine <johnl@taugh.com>, mtgvenue@ietf.org
References: <20240229190603.4E224842AE6E@ary.qy> <73C7B5D1-22CD-4CFA-8A6F-D1A75EE120D3@mnot.net> <8140ac05-63dc-1701-209f-6de9d45cb759@taugh.com> <2EBD8C64-E02F-4520-B45B-CFCE7805539E@mnot.net> <CABcZeBMA_b6pu4+rQC8nsXwOX8WX+9eaPnej778-=QhMxOwC9Q@mail.gmail.com> <fac34d30-5c82-9033-9450-e446e200e54c@emailplus.org> <CABcZeBN-Vn=Gwq8QJ4d4xgrCVDFqteNLRrG54PUp2VCTMn2NAw@mail.gmail.com>
From: Benson Muite <benson_muite@emailplus.org>
In-Reply-To: <CABcZeBN-Vn=Gwq8QJ4d4xgrCVDFqteNLRrG54PUp2VCTMn2NAw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/5np2DK97BnmqnhSdSnhGTTMp_ow>
Subject: Re: [Mtgvenue] New Version Notification for draft-daley-gendispatch-venue-requirements-02.txt
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: Sun, 03 Mar 2024 08:04:00 -0000

On 02/03/2024 17.27, Eric Rescorla wrote:
> 
> 
> On Fri, Mar 1, 2024 at 9:58 PM Benson Muite <benson_muite@emailplus.org
> <mailto:benson_muite@emailplus.org>> wrote:
> 
> 
>     >
>     > I think this is a good illustration of why it's difficult to come up
>     > with a complete
>     > set of objective criteria about the suitability of a specific venue.
>     > Rather, I think
>     > the right way to proceed is by having a smaller set of screening
>     criteria
>     > (as the current document does) and then asking whether a proposed new
>     > venue is problematic for a large enough [0] fraction of attendees, for
>     > whatever
>     > reason, without interrogating the validity of those reasons.
>     >
>     This seems a reasonable way to give a meeting exploratory status. 
> 
> 
> I'm not sure what you mean ehre.
It would be good to separate the rotation policy from determining
whether a meeting is exploratory.

If a meeting location will be more problematic than usual for a
significant number of attendees, then it is reasonable to classify the
meeting as exploratory.  This could be left to IESG to determine with
community input.
> 
> I don't think we should have even exploratory meetings in locations
> that are significantly more problematic for current attendees.
> 
>  
> 
>     New
>     venues may also lead to greater engagement, for example Hyderabad or
>     Shenzhen would likely be successful new meeting venues for growing the
>     number of active participants.
> 
> 
> My understanding of the data is that previous exploratory meetings in areas
> where there was believed to be low engagement did not in fact meaningfully
> grow the number of new participants beyond that one meeting..
> Do you have evidence to the contrary?
> 
> 
>  
> 
>     > With that said, I agree with John that time zone is not a good
>     replacement
>     > for our existing geographic zone system. I could imagine a new
>     criterion
>     > based on travel time, but I don't think time zone is a good choice
>     for the
>     > reasons John indicated.
> 
>     Travel time may be difficult, other than being close to a major airport.
>      The aim of using time zones to split the globe is to have a more
>     precise and equitable criteria for distribution of meetings than North
>     America, Europe and Asia.
> 
> 
> I understand that that's your view, but it's not clear to me that time zones
> are in fact more equitable.
Travel time is tricky.  If all attendees add their closest departure
airport to the data tracker, one could create a program to calculate
minimum travel time for a certain fare level.  Some attendees also face
visa issues, which may be difficult to factor into travel time.
> 
> -Ekr
> 
>     >
>     > -Ekr
>     >
>     > [0] Where "large enough" is defined as "significantly more than
>     for the
>     > existing
>     > venues"
>     >
>