IETF 100, Singapore -- proposed path forward and request for input

Richard Barnes <rlb@ipv.sx> Sat, 21 May 2016 23:32 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFC612D584 for <ietf@ietfa.amsl.com>; Sat, 21 May 2016 16:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxKSLGuFatiJ for <ietf@ietfa.amsl.com>; Sat, 21 May 2016 16:32:01 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8715D12D539 for <ietf@ietf.org>; Sat, 21 May 2016 16:32:01 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id f66so184353599vkh.2 for <ietf@ietf.org>; Sat, 21 May 2016 16:32:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gmbf0RQ7ZERMYAHJxBWTC4n6wa71QwlfLo7XzQ6W4Ig=; b=chWnUgMTnU3WPHwgVyWpWsXi5k2hIQ22cD6RKy1qao33rPUrHDGKj/7R2x89XQsmpI i1Hc+TV2KaP16d3slRrUkYtqGKvmJQVoFPSAgYKIFqMYadcndCxYUfIU6p42Ch6Lkr7o o6ihfIVyKcbmuduwNVMNDgg/L1BZxY+u5MImpb5yiIv378mGHlXIhnG8pJPlGQCnQRq8 LQcAvmv9Mjkpqh46i04zF6lJHuChPsL2iAtSSqRyk9VQs3tm/42NXqTn9AJ5Q1+UPtll yJfQUuiY2UBGmHIEDFeEVvXnTjEfP3Mbg7mZ2HJNRzQZxSN4kDi88kz/aLRSZxOyjGWx lrKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gmbf0RQ7ZERMYAHJxBWTC4n6wa71QwlfLo7XzQ6W4Ig=; b=axGvGHcY+QhgrW0A0gZa7uleuTxo0YHAK364roAK/JJfy3comT/+iFw2G6gTHH2z8X OOrGs26oNBgeda+yLP3UP+NQOLf0CzG0RfqdqRibyL1JrIid4I5eH0pA9BWtE2U4JxR7 2FvgWi5ypTgSFXdbroHbbbuqI+KDAOMjiQqKSIIStLE009LZIsuciziBZbHCpUmvbw62 6YRCLM8cllbQYb0euP/uwECgxzmES8Kbh+Mb9PXEC62ZvADZ3Vg5lRNa/77qmxUzdaWH wQhiaMYOdftCpNjZ4z0mcAZReNPE3HyfT2rK3U/SzJkBrwxzGOz51ZPveyaclw8NZnF1 ktuw==
X-Gm-Message-State: AOPr4FWWpjQWWHBgmkI+2ezKc4BupPzBI+ZwYgW/9JnVsNy7lL7MtV2xqAUCQus7Y8NfMPtWQ9+LxvLSXN0bUQ==
MIME-Version: 1.0
X-Received: by 10.31.61.134 with SMTP id k128mr5723022vka.89.1463873520548; Sat, 21 May 2016 16:32:00 -0700 (PDT)
Received: by 10.31.48.71 with HTTP; Sat, 21 May 2016 16:32:00 -0700 (PDT)
In-Reply-To: <5740DB04.9070305@cs.tcd.ie>
References: <D3662363.190A96%jon.peterson@neustar.biz> <5740DB04.9070305@cs.tcd.ie>
Date: Sat, 21 May 2016 19:32:00 -0400
Message-ID: <CAL02cgRx7s=wTaF3C7wPOGMs2tG7HbboSmYKQ2x9Ym1h3xrGog@mail.gmail.com>
Subject: IETF 100, Singapore -- proposed path forward and request for input
From: Richard Barnes <rlb@ipv.sx>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a114dbd343051a90533629d58
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/njKf6c2sv5jxm0xqJZOLBoa5DPw>
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 May 2016 23:32:09 -0000

On Sat, May 21, 2016 at 6:02 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
<javascript:_e(%7B%7D,'cvml','stephen.farrell@cs.tcd.ie');>> wrote:

>
>
> On 21/05/16 22:38, Peterson, Jon wrote:
> >
> > On 5/21/16 1:00 PM, Brian E Carpenter wrote:
> >
> >> I agree, but I also agree with Jordi. The main reason for having a
> >> diversity policy is ethical and moral, but there's also a
> >> 'business' reason - making use of everybody's talents to the
> >> maximum - and that surely is the fundamental reason for the whole
> >> site selection policy anyway. It certainly isn't providing tourist
> >> and vacation opportunities for family members. So...
> >
> >
> > There's a reason this discussion has come up around IETF 100, though.
> > While I'm sure IETF participants would be tempted to view this as
> > just another meeting, there's a sense in which it has to be more than
> > that. A lot of us have spent much of our careers working in this
> > organization, and developing professional and personal relationships
> > here. IETF 100 will be a work meeting and not a vacation opportunity,
> > but I think attached to that work meeting should also be a
> > celebration, and one where the personal relationships may matter more
> > than usual.
> >
> >
> > When I hear that long-time participants, people that have been around
> > longer than me, feel like they need to sit this one out because of
> > where it is happening, or worry about bringing their families to a
> > meeting where we expect that these enduring relationships will be
> > celebrated, that makes me think we as a community need to arrive at a
> > consensus about whether or not this is okay, and if not, what we
> > should do about it.
> >
> >
> > We do need to set better general policies for venue selection, and it
> > sounds like the IAOC is starting to look into that. But I think
> > there's a further question about this specific meeting location that
> > we should resolve with some urgency.
>
> I think we should celebrate at IETF-128. We can start by
> practising at IETF-96 and then have fun every 32 meetings
> thereafter. We ought not be ruled by decimalisation:-)
>
> More seriously, I'd have to agree with folks who've said
> or implied that deciding what's on the list of criteria
> and where is hard, and to be frank, I'm not at all sure
> if I'd include family accompaniment and if I did, I don't
> know where I'd put it relative to other priorities. So I'd
> say it's not unreasonable that the IAOC are similarly
> puzzled. We ought not aim for perfection at that level of
> granularity I think. (Transparency and effectiveness, yes,
> perfection, no.)
>
> That IMO is all the more reason why the IAOC need to move
> to a default-open policy to the fullest extent they can,
> which I believe is way more than has been the case to date.
> I suspect that that opinion perhaps now has the kind of
> critical mass that someone might declare it as a rough
> consensus of the IETF.
>

This seems like the clearest consequence of this debate.  The IAOC's
opacity in choosing this venue and in their subsequent decision-making has
not helped to reassure the community that their input is being taken into
account.



> In the meantime, wrt IETF-100, at this point I do think we
> ought not make it a mega-celebration of any kind, regardless
> of where it's held, but we can finesse that via powers of 2
> (as per the above) or in whatever other way works.
>

Unfortunately, in practice, this is ultimately going to be up to us.  Even
if the IETF doesn't throw a party, one can easily imagine some enthusiastic
sponsor or reporter seeing an opportunity for celebration.



> I'm ok to leave the decision as to whether to stick with
> Singapore or not to the IAOC. I don't think there's any way
> we could decide that by consensus. I would just hope that
> the IAOC can re-assure the rest of us that they have
> explored all avenues before they come to a conclusion. (And
> that they can explain those avenues when the time is right.)
>

Obviously, this is ultimately a practical decision, and the IAOC will have
to make the call together with the sponsor and other stakeholders.

But as I said at the mic in Yokohama, as long as something is in the
future, there's a possibility for change -- and IETF 100 is still more than
a year out.  In this light, and in light of the feedback received so far,
it seems like the minimum the IAOC owes the community is a thorough
evaluation of what would be required to move the meeting elsewhere, and a
thorough explanation of their basis for concluding that those requirements
will or will not be met.

--Richard



>
> S.
>
> >
> >
> > Jon Peterson
> >
> > Neustar, Inc.
> >
>
>