Re: IAOC requesting input on (potential) meeting cities

Loa Andersson <loa@pi.nu> Wed, 12 April 2017 04:12 UTC

Return-Path: <loa@pi.nu>
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 0F4451287A7 for <ietf@ietfa.amsl.com>; Tue, 11 Apr 2017 21:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 0iVXt_WN9Hhx for <ietf@ietfa.amsl.com>; Tue, 11 Apr 2017 21:12:32 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988B1127342 for <ietf@ietf.org>; Tue, 11 Apr 2017 21:12:31 -0700 (PDT)
Received: from [192.168.1.10] (unknown [112.200.233.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8D31E18014F3 for <ietf@ietf.org>; Wed, 12 Apr 2017 06:12:29 +0200 (CEST)
Subject: Re: IAOC requesting input on (potential) meeting cities
To: ietf@ietf.org
References: <93404c29-78ba-ff9b-9170-f5f2a5389a31@gmail.com> <E068F01A-B720-4E7A-A60F-AA5BDA22D535@consulintel.es> <20170404181505.GA4004@localhost> <CAAQiQRcvu-BfBA_NEqZwXsHEn6ujpa2=w7P5Vu2f6GLXjKqkcA@mail.gmail.com> <20170404202446.GB4004@localhost> <20170404211526.GA25253@gsp.org> <003F08E0-D80E-40F7-AB15-6588B7B140CF@tzi.org> <20170410180555.GA20454@gsp.org> <AF3B5F0A-EEA7-402D-B61E-EDE6CE2AE16C@tzi.org> <8546635c-f838-e7f7-a5ec-3a855a14c0f9@dcrocker.net> <20170411232408.GE48535@verdi> <15694.1491965723@obiwan.sandelman.ca>
From: Loa Andersson <loa@pi.nu>
Message-ID: <f1481391-b477-0596-d8ea-adc02ec48e94@pi.nu>
Date: Wed, 12 Apr 2017 12:12:14 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <15694.1491965723@obiwan.sandelman.ca>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/OFfcQdLFiGi10xv8t7IDWGw9fXo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 12 Apr 2017 04:12:34 -0000

Michael,

On 2017-04-12 10:55, Michael Richardson wrote:
>
> John Leslie <john@jlc.net> wrote:
>     >> It is fast looking as if the ability to sustain a large and very
>     >> well-attended network of interconnected remote hubs might become a
>     >> necessity rather than merely an appealing alternative...
>
>     >    +1
>
>     >    (and this will require some formal process for mike queuing at the
>     > "interconnected remote hubs".)
>
> Agreed.
>
> Don't cancel SFO; just renegotiate it for much a smaller group of west-coast
> "locals".   Maybe we can do this with minimal impact to the contract.
>
> So we have 99, 100, and 101 to get all the mike queue and remote hubs working.
>
It is hard to see the logic. I've just had the experience of "attending"
an IETF meeting remotely.

Let me first say that I very much appreciate the effort made by e.g. the
meetecho people. The experience of listening to a meeting on meetecho
and sitting in the room listening is very close. All the time until
someone that sits in the middle of the room don't care to go the mike
to make a comment, but just shout it out. When this happens you just
don't lose the comment, but you also lose much of the context for the
continued discussion.

Participate in the discussion remotely, is just not there yet. This is
not (primarily) technology, but queue management and queue discipline.

I know that this is getting better, but to work smoothly I think we need
the set uo e.g. ITU-T have in Geneva where every participant has his/her
own microphone and the management of the for remote participants and
people attending in the room would be the same.

It quite often happens (it has happened to me) that someone notify the
chairs that "there is someone wanting to say something on the meetecho",
only when that happens that particular discussion is already "taken to
the list".

But an IETF meeting is so much more than the moderate number of hours
you spend in meeting rooms, if you participate remotely you miss what
is probably the most important aspect of an IETF F2F - the 10-15
corridor meetings you have each day.

I'd say cancel SFO and move to place where we all have an equal chance
to attend, even if you have made a business trip to Iran or somewhere
else in the Middle East, and where we don't have to give out passwords
to e.g. laptops that may contain business critical information.

/Loa


> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64