[Mtgvenue] Re: is identification of individuals already cove red by BCP 226

S Moonesamy <sm+ietf@elandsys.com> Tue, 31 March 2026 20:33 UTC

Return-Path: <sm@elandsys.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 50A78D458E3A for <mtgvenue@mail2.ietf.org>; Tue, 31 Mar 2026 13:33:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1774989200; bh=c2L5P+sRestxLT0cm95TxXZj4QEaIm6un7VIGJ8zDjg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ySWh9n/UyNYBhY/VKe4pZiRqNT6hS8dc8twluLqe1VMNsCnCsKVT7LjF20YCo+2yP 7cIEwMXtyFbE61knJH1M4EmXNpjI7f31T9dCCz2Z89l8QkZh5Hj5jLmcV7+AqFFZka 9g9ffPp2fwzGwSGE/0zkW/idiL7rDSdTfZ5m+mpY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 o5kiqVcXhxiL for <mtgvenue@mail2.ietf.org>; Tue, 31 Mar 2026 13:33:17 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail2.ietf.org (Postfix) with ESMTP id 143CFD458E2A for <mtgvenue@ietf.org>; Tue, 31 Mar 2026 13:33:17 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.117.112.82]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 62VKWCGx021704 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2026 13:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elandsys.com; s=mail; t=1774989169; x=1775075569; i=@elandsys.com; bh=c2L5P+sRestxLT0cm95TxXZj4QEaIm6un7VIGJ8zDjg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0zmgkI7wtXwFpZK+Su20cEB8nhfbppn9xgxJOlMP/9qOZDzcJHMPkHSwuxIHrpwoD ty+CiPoLknYy4+ZFBUo8EfMJWobMAcROj71kqaLfHXcUhe4hkYCJasfjdCAlWa6x/2 f2lqLBpJZyr4O4Z4ERiX7qkZyjSpDkyTYsLIf84M=
Message-Id: <6.2.5.6.2.20260331112004.09c8b2b0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 31 Mar 2026 13:23:27 -0700
To: Toerless Eckert <tte@cs.fau.de>, mtgvenue@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <acmQnsg-BrJ3jRgl@faui48e.informatik.uni-erlangen.de>
References: <BY5PR11MB42580943EF4BD96BB35CFD74C756A@BY5PR11MB4258.namprd11.prod.outlook.com> <CABcZeBPOrRSZeHkqQCOYyTEnhpzR=6psN2hM3t95RRgy0J-Mcg@mail.gmail.com> <45a16e50-4977-4763-b667-ddc8b3c18366@huitema.net> <acXvrIs5iQh9ZM2Q@faui48e.informatik.uni-erlangen.de> <CABcZeBNgK4NzfuZuCD73skQK1594qO63WB64MwJXXFb5Wc4NJA@mail.gmail.com> <acYLVMd8tw1lbv0j@faui48e.informatik.uni-erlangen.de> <CABcZeBMF4oDWvOzB7hb=uADgeBHeFeOmsKWxYC7ht2jM-Pn1Nw@mail.gmail.com> <accSyAJATtw5Iakr@faui48e.informatik.uni-erlangen.de> <14d573e0-6dd0-4511-8669-5096551a7906@cs.tcd.ie> <DM6PR11MB4268B655CEE4635BA0C27D1BC755A@DM6PR11MB4268.namprd11.prod.outlook.com> <acmQnsg-BrJ3jRgl@faui48e.informatik.uni-erlangen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID-Hash: KFT2HB5V42T4HKVDHREZLN3YBGVRUXVP
X-Message-ID-Hash: KFT2HB5V42T4HKVDHREZLN3YBGVRUXVP
X-MailFrom: sm@elandsys.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: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Livingood, Jason" <Jason_Livingood@comcast.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Mtgvenue] Re: is identification of individuals already cove red by BCP 226
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/BuYVlwdmNgMM9hxM6P0x_4u7ooc>
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>

Hi Toerless,
At 01:50 PM 29-03-2026, Toerless Eckert wrote:
>First of all, except for Stephen, all people arguing here in favor of banning
>network authentication for future IETF ar americans or working for american
>companies (sorry if i am forgetting folks). So it is easy to view the
>discussion as "americans bullying China", and we should be aware of 
>that perception.

That could be the perception.

Here's the attendee statistics for the last meeting:

   North America  15%
   China          56%

There would be more meetings in China if the 2010 approach was still in use.

The draft which started this discussion mentioned protocols such as 
IPsec, DNSSEC, TLS, and SSH.  I didn't see any complaints about not 
being able to use software using those protocols at the last 
meeting.  For what it is worth, the usage of those protocols is 
already covered in the "best current practice".

>Just as an excourse for those interested because i think it also limited
>the number of technical options that IETF NOC had to deal with the situation
>(such as advanced networking configes if/when using normal gear):
>
>USA EAR export regulation does not allow for advanced technology to be shipped
>to china without a license. This includes most routers. And licenses may
>take eternities or never come. In around 2018 we even had the case that
>research routers solely made in China but shipped to the USA could not be
>shipped back because of EAR. Some time later China started AFAIK similar
>export limitations for "reciprocity". So, sending normal IETF gear from USA
>and China and back is likely about the most complex paper work import/export
>exercise with the most number of unknowns you can expect.
>(And i was involved for a few years with shipping networking gear to
>  various places on the globe, so i have also a tiny bit of 
> background here ;-)

I changed the ordering of your comment.

Some countries have rules affecting technology.  It can affect the 
network setup.  It can be quite complicated to get hardware to some 
other part of the world.  It's not the type of problem which the 
"best current practice" tried to address.

Regards,
S. Moonesamy