Re: my summary of discussion regarding IETF #100

John Curran <> Fri, 03 June 2016 12:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC28D12D581 for <>; Fri, 3 Jun 2016 05:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hxaINgta0ly3 for <>; Fri, 3 Jun 2016 05:54:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9736612D09E for <>; Fri, 3 Jun 2016 05:54:58 -0700 (PDT)
X-MHO-User: 652c79d8-298a-11e6-a0ff-e511cd071b9b
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from [] (unknown []) by (Halon Mail Gateway) with ESMTPSA; Fri, 3 Jun 2016 12:55:05 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: my summary of discussion regarding IETF #100
From: John Curran <>
In-Reply-To: <1a8801d1bc30$df1962d0$9d4c2870$>
Date: Fri, 3 Jun 2016 08:54:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <1a8801d1bc30$df1962d0$9d4c2870$>
To: Jari Arkko <>, Tony Hain <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Jun 2016 12:55:01 -0000

+1 to Tony’s statement (and for invocation of BCP 14 :-)  

There are hard requirements and there are soft requirements.

If in a particular year no meeting venue can be found _anywhere_ that meets the 
hard requirements, then the IETF shouldn’t meet (yes, I understand that this is quite
unlikely, but the point is that hard requirements such as the safety of the participants 
and ability to travel there at all (visas) or ability to provide for remote participation are 
essential to the point that their absolute requirement should be clearly documented.) 

Nearly everything else (suitability of the venue for participants' family members,
local governments beliefs in equality or climate change, relative cost of travel 
or accommodations, etc.) need to be considered as desirable goals and weighed 
_in total_.  It is not an easy job for the IAOC, and hopefully they’ll gain insight from
increased engagement with the community (& the abundant feedback), but at the 
end of the day they need to be able to select sites that meet the hard requirements 
and be left to their best judgement on maximizing satisfaction of the additional soft

It is possible to find political objections to nearly any country, and if it is not careful, 
the IETF risks having its fine protocol development work be made secondary to its 
emerging political advocacy initiatives – an outcome that would represent far greater 
loss to global community given the enormous role of the Internet as mechanism for 
social change and understanding. 


Disclaimer: my views alone - critique not only accepted but encouraged. 

> On Jun 1, 2016, at 2:10 PM, Tony Hain <> wrote:
> +1 (including the hat)
> Issues beyond those critical for getting work done SHOULD be used to select
> between otherwise equal venues in a region, but MUST NOT be used as the
> primary discriminators. 
> Tony
>> -----Original Message-----
>> From: ietf [] On Behalf Of Dean Willis
>> Sent: Tuesday, May 31, 2016 6:40 PM
>> To: Jari Arkko
>> Cc: Discussion
>> Subject: Re: my summary of discussion regarding IETF #100
>>> On May 28, 2016, at 12:49, Jari Arkko <> wrote:
>>> Several people have pointed out that it is very important that the IETF
>> treats everyone's issues the same. I'd point out though that not everyone
>> reacts in the same fashion, e.g., we need to be aware of people who are or
>> have been silent about their issues, attempt to identify such issues, and
>> consider those as well, fairly, *while* still needing to find a reasonable
> set
>> of real-world venues.
>> <cowboy hat on>
>> No, we don't. If they aren't the sort of issues that prevent real work
> from
>> getting done in the IETF, we do NOT need to be identifying or considering
>> them.
>> This is not a social club. It is not a debating forum. It is not a
> junket-factory
>> for family-friendly excursions. It is work, and work is hard and requires
>> sacrifice.
>> I understand that it is trendy for everyone to need safe-spaces, group
> hugs,
>> and lemon-scented-napkins before takeoff these days, but this is getting
>> ridiculous.
>> Being able to get through customs at a destination, being able to afford
> that
>> destination, and being safe once one gets there are critical issues.
> Adequate
>> meeting, hospitality, and bandwidth accommodations are critical issues.
>> Most of the rest of this debate needs to be taken somewhere else. Sure, we
>> can each have personal concerns about how to get more of our clique-du-
>> jour into the process, but that, in general, is something the IETF as a
> whole
>> needs to avoid wasting time on.
>> So stop being a silly wanker, kick some ass, and call an end to playtime.
>> Everybody back to work!
>> <cowboy hat off>
>> -
>> Dean