RE: Agenda experiment for IETF 103 in November in Bangkok

John C Klensin <john-ietf@jck.com> Sun, 13 May 2018 15:25 UTC

Return-Path: <john-ietf@jck.com>
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 317D3126C22; Sun, 13 May 2018 08:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no 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 JdbCHcDyYIfu; Sun, 13 May 2018 08:25:49 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB731243F6; Sun, 13 May 2018 08:25:48 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fHssa-000Ms6-PF; Sun, 13 May 2018 11:25:44 -0400
Date: Sun, 13 May 2018 11:25:39 -0400
From: John C Klensin <john-ietf@jck.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, IETF Chair <chair@ietf.org>
cc: ietf <ietf@ietf.org>
Subject: RE: Agenda experiment for IETF 103 in November in Bangkok
Message-ID: <46881575D8716155C71E14F7@JcK-HP5.jck.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B043AE7@sjceml521-mbx.china.huawei.com>
References: <3678CC52-1F1B-4B17-8654-E75C9B63AD39@ietf.org> <4A95BA014132FF49AE685FAB4B9F17F66B043AE7@sjceml521-mbx.china.huawei.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/kjhk6p_nIK4tyoHLe7sZ0_jGT0w>
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: Sun, 13 May 2018 15:25:50 -0000


--On Sunday, 13 May, 2018 13:20 +0000 Linda Dunbar
<linda.dunbar@huawei.com> wrote:

> IMHO, no meeting on Friday doesn't really facilitate more
> unstructured discussion as most people will book flight
> leaving on Friday if no meeting is scheduled on Friday. It is
> much more effective to facilitate more unstructured discussion
> if less sessions are scheduled per day, longer break time,
> etc. such as morning sessions start later, say 10am (giving
> people time to have morning informal discussions), longer
> lunch break or session break in afternoon.

Linda,

I've always hated Friday sessions and believe that the decision
to expand into Friday, rather than saying "this is all we have
time for and we need to prioritize meeting schedules, approval
of WGs, and the threshold for shutting down WGs that are not
making progress accordingly".  Part of my reason is that people
who are anxious to get home before the weekend will leave
Thursday night or Friday anyway, resulting in a very different
profile of participants on Friday that earlier in the week.
Another part, probably more important, is the observation that,
for people who are really participating actively, four very long
and intense days (even without intense tutorials and
side-meetings on Sunday) are burned out.  I have vivid memories
of Friday IAB and IESG wrap-up sessions in which most people
could do little more than sit around and stare at each other.  

More opportunities for informal interactions are clearly part of
that story, but I don't believe that trying to push them into
Friday is the solution, especially if one sees the problem as
IESG inability to prioritize.

    john