Re: limiting our set of cities

"Deen, Glenn (NBCUniversal)" <> Thu, 20 February 2020 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FE5A1200C3; Thu, 20 Feb 2020 11:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qsi09KwaMkNV; Thu, 20 Feb 2020 11:01:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 157FF120045; Thu, 20 Feb 2020 11:01:48 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 01KIrsfc018816; Thu, 20 Feb 2020 14:01:48 -0500
Received: from ([]) by with ESMTP id 2y8ud6uqxb-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Thu, 20 Feb 2020 14:01:48 -0500
Received: from unknown (HELO ([]) by with ESMTP; 20 Feb 2020 11:01:46 -0800
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 20 Feb 2020 13:53:09 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 20 Feb 2020 13:53:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=igtnxHiNekhtH0vupuMz59llHoqcU4i827eXkMFaSkjBiKjJHye4lW8tlbqIu7yASzG7y7FdmRsxBIOIMgwsfn0YWZfGyoQxMOK8EgjXCa0zycLgLbUdWRmOlvELJOHc+lTBGCZtMdCdi1qMmGURV3RZEmNyddZYFIQiNsC3+d+r65Sd+4lYpgU8cj5MrNq0kDi/0KAAyLQkpe+1KpQ4YthUPiEYyboJpCw96tmyUcJ6N5Hj9bIy1LwY5AhyI+F2fhnzXCvGYXmfYzGKVEjBgWqlU67LKOOPOe+Nx8XcHNcTOZ7enUoE0t0C1vi682JdXZ9dOXkBpezrbZTBZySp3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XS+bAxh/s6ya6F6X7Xn25xNXqfnXu4DeYoJdQk9ul7s=; b=cNv/ukLrMxUd1ajcnGuNHRskRycl94HkRi+6SLYjVLpxMeE5ShyxlT1falnmokA6T7m2YhcmWt/pJGqLZ1oMGMP+rliYuYHScJfsGPcPhmJ+LhnIVkZnzeixnxdDc7iz/OYQw+OkTtm9zBbPKu6CqQL4h9waPDTBl2wN85o9M/K0ro/m/P0b2cW9AngMoL1WKnPpQ22QYrLvnzSVZttvFnZ0uQw+evSr25l5308QcEfafFL/K/DNMTMlceUkPFHBje/JTX95h0p8BrKGCpovayKc6MFjqXld2VW/qcU/niyT14+jzaBVQXSlyIzPjtEOXnyqSvw0oWcAdubzOpE3hQ==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XS+bAxh/s6ya6F6X7Xn25xNXqfnXu4DeYoJdQk9ul7s=; b=oGw/G6FMkCvAXTdlBT+h+94hGRxY5ceeL13XWDVgUSuDg75iL1j5rRVX5WSOQL2BirBrRMXKbJCraH74FzS/8s3k4AgjhaA1EYLGGsONvWDYpIyHnqq/qwX/mUklUYD9ue31wfmRrWlAgu2Qm0B8GpM7Ll14XfFQMMl/NtbiSjA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17; Thu, 20 Feb 2020 16:59:06 +0000
Received: from ([fe80::44ca:35e1:ac08:608d]) by ([fe80::44ca:35e1:ac08:608d%7]) with mapi id 15.20.2729.032; Thu, 20 Feb 2020 16:59:06 +0000
From: "Deen, Glenn (NBCUniversal)" <>
To: Michael Richardson <>, Jay Daley <>, IETF discussion list <>
Subject: Re: limiting our set of cities
Thread-Topic: limiting our set of cities
Thread-Index: AQHV6A8P0/y3zckUCUyYYiy7iJpqwQ==
Date: Thu, 20 Feb 2020 16:59:05 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a33705ad-336b-4c06-55ea-08d7b6263228
x-ms-traffictypediagnostic: BYAPR14MB2789:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 031996B7EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(199004)(189003)(2616005)(478600001)(6512007)(4326008)(6486002)(5660300002)(8676002)(71200400001)(107886003)(8936002)(36756003)(81166006)(81156014)(316002)(110136005)(66556008)(6506007)(186003)(86362001)(76116006)(66476007)(66946007)(26005)(2906002)(33656002)(66446008)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR14MB2789;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lcnNrF5hV99UlTNo4CqEm08+CSyMUFacxXsZ8CXWo3zxUMimmojIhVuSBx/5q7X6+vVSWPbtwaTPADY8Ov7bDFyxU7aD247N3pYQjGbH4wfaFrXjtfedrL7/UQgMrV8Aqb3L/NkDegm7zJAwsJs2oFtnU96udiCcCxn3mQ9vK6O98nStiawgWZNNdM+mk7EBtOZMj/wncDtt/zNtTHiWyLONpV7abpXLddx9QBcAO2FIcu3cUg/Olh/1IujiXzp9pPwyfEHDGZpxVxKuy9hU+dSAdi63eE9w5kQ4fkdckpfx1/VjGeby0sDJ4b+I95mBaPid2RQ4eAAI4sBBiypCLqewt2GbtYIrmOreDFVTDhApENf3TgD86uROiDnembEaT5NfF9Jh7wXveOIHUzcTjmnygxtKGRcFfpOgGSCWHVzYCtnTaGA/a1AUEq+ObFL7
x-ms-exchange-antispam-messagedata: ixM0/pSb/8lRiQU8Y/fMdTN8eN06qitI4Cy1C+sNzdD9hUjiC5WdjgfU/9u/mUcl/e8NzGXLM0mvFHpCK8xjb4rLzDQpzZ0nBqFahjKBJ9q6NFWclEndvwkwb7qL+33ERlzhlnVvKOeVUGu6Vy+5vQ==
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a33705ad-336b-4c06-55ea-08d7b6263228
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 16:59:05.9842 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KJ02fFmkZID2Rs/RhOwx4zbImS5/TXsDKYqmVbgaLjyQb4owXVp9fvEgFKw+JPg4+m03w9VMtTKAzz1T5dQcEg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR14MB2789
X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45
X-CFilter-Loop: Forward
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-20_16:2020-02-19, 2020-02-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1011 malwarescore=0 adultscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 phishscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002200137
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Feb 2020 19:01:52 -0000

Hi Michael,

I'm wondering why you think having a smaller fixes list should be an objective?    It was not an aspect that ended up in the meeting venue criteria document when that was developed via the MTGVENUE working group.   

Going back to the same cities over and over creates a lot of problems:  

1) Venues that believe that they've locked us in will often not work as hard to give us the best deals.  This has come up in other orgs that frequent the same city year after year - they've found they needed to switch hotels every 2-3 meetings because the incumbent location no longer worked to earn their business.   While small meetings can jump to new hotels, the number of places in any given city that can accommodate a meeting the size of the IETF is more limited - sometimes only 1-2 hotels even in large cities such as London for example.

2) Meeting host fatigue.   Some hosts and some locations just have a natural affinity for one another due to the host's organizational location, or due to the host doing a lot of business in the location.  It's wonderful that the IETF enjoys great support from a number of committed host sponsors, but we have to recognize that even the most supportive host can become fatigued.   Even if the host skips having a social event the cost to sponsor an IETF is still hundreds of thousands dollars.  If we visited the same location, even on a 9-12 meeting frequency finding hosts will be a challenge.  Recall that  while attendee fees contribute to the meeting cost, the IETF also depends on meeting hosts.   If you look in the IETF budgets, meeting sponsorships contribute about 1.4 Million a year to the IETF.    While we have weathered the occasional in-frequent meeting without a host, having that become the rare event would really hurt the IETF's finances.

Not having a larger list of qualified venues in Asia definitely also contributed to the problem you raise about Asia locations, though it's not as simple as just that.    I'm no longer involved in IETF meeting planning but in 2018 and 2019 when I was, we recognized the pipeline in Asia was limited and so we put an extra focus on finding and qualifying new Asia locations.    We also recognized that having the Asia meeting in the November meeting slot also contributed to the limited number of venues options the IETF that had availability for future IETF meetings, and so the decision was made to switch the March meeting to the Asia region to open up previously closed options.    Both of these changes will bear fruit down the road but because meeting planning for a group the size of the IETF is a multi-year pipeline it will take a bit for the improvements to show up.   

A big benefit of a larger list of cities being qualified to be IETF meeting locations is that it gives the meeting planners more venues to send out bid requests to and that drives competition by the venues for the IETF's business.  That is good for the IETF's budget and for IETF attendees budgets.    If you want to see what happens when there isn't competition by venues look at the hotel prices paid by attendees of big events like CES, or IBC in Amsterdam, or MWC (when it isn’t cancelled) - it's not uncommon for hotel prices to go up by x4 to x10 during the week of the event.  While the IETF is not at the scale of any of these big event, it does show that in the hotel/venue world supply and demand are not in your favor when you only have a small fixed set of choices to choose from.

We meet 3 times a year, if we only had 10-15 cities in the selection list we would exhaust the list in 3-5 years.   Such a small list doesn't support the meeting planners in getting the best deals for us.

So I'm left wondering what the downsides are of having a larger list of cities that have been qualified as potential locations for IETF meetings?   It's not a big investment to create or maintain the list and it can help the IETF and attendees budgets in a positive way.


On 2/20/20, 2:35 AM, "ietf on behalf of Michael Richardson" < on behalf of> wrote:

    Jay, and/or Jason:
    Can you tell the community if the LLC has any plans/thoughts to stop looking
    for new places to meet, rather to just establish a list of 10-15 cities where
    we have successfully met, and simply repeat?
    Many have suggested this as a better policy, but it seems that it's just
    Christian Huitema made a good case already for the Asia list being not just
    Bangkok/Singapore, but also including Tokyo/Yokohama and Seoul.
    That's four for Asia.
    One could easily add: North America: Vancouver, San Francisco, Montreal, Philadelphia.
    Europe: Prague, Berlin, London, (Paris?)
    There, that's 12 cities already, and I said 10-15.
    Could probably add another three.  Maybe Madrid will wind up on the list.
    I'm sure that many of the cities on your list are potentially interesting,
    but why bother make the effort?
    Yes, we should have "*" in the rotation 1-1-1-*, but we should do it
    intentionally as reach out.
    I don't see Austin (or Ottawa, or Malta) as being reach-out, as nice as they
    might be.
    Michael Richardson <>ca>, Sandelman Software Works
     -= IPv6 IoT consulting =-