Re: IETF 109 Preliminary Agenda

David Noveck <davenoveck@gmail.com> Sun, 18 October 2020 10:34 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D8A3A09DF for <wgchairs@ietfa.amsl.com>; Sun, 18 Oct 2020 03:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Uj_S8f8SKOVP for <wgchairs@ietfa.amsl.com>; Sun, 18 Oct 2020 03:34:37 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 0A5483A09DE for <wgchairs@ietf.org>; Sun, 18 Oct 2020 03:34:37 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id a3so9800094ejy.11 for <wgchairs@ietf.org>; Sun, 18 Oct 2020 03:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=slIltZVal0EYJx20hPrHOzjxwEQhuLeKuQnEv5ylz2I=; b=DQAU1tbAHniwRx+1ohyBnmE7LlROBBPvY8zusJzoilc02c6xxkuoHHicDfJprecMhv qAwmTaXfLngPZpvD4EQDFnkE4OxofvW3qAspHkxCTW4Jw/6/iXsydMTtfuQVr0n8NjU6 TTeHaT9JCLkh4uP4J9kGL9Y129lsiLDJkw+dfq7Q7TQUuB/bwvm7huW+rGdh8oXBvKES K/E9tmijrPSnURiVl58OMlsH2tABRaSlVKHP96Dk73LmOGHM5vHdVLvqjYyMoQYbLGLs aAIUIYdmECpss1ZjRdDs8LzmiaQH1HmTAjOPT/Rt9OY22gs9tX/QY50QVg+ppoXk3y0j JjKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=slIltZVal0EYJx20hPrHOzjxwEQhuLeKuQnEv5ylz2I=; b=VV/vVZZmXUVkrkgAkk70DGfe+wOUlBIx7BQwtME8W2Zvp6uYDtD+0m3cnHc9OCUHbI ST1MW+5fVvFzdiSF9By2nkxbPztSTd9M8n02FetnXwpCOCKiSOLU/n18TQ7MZCH0Aoky kSZD5OHs52DggMV3N2+0gOdOkL6eoMyZIg6Exx8BkrQmChZMaRIH/STtWdlPU4YVq2ov HdZALP9PQcFzeuKfAyH5xL7TW5QJSYdvfhMQdeYMOnlo3Xl2N1Yn6mf/qsMDjZOoxGav la/vWUCmwbf0/ArXqH1xwCBVXke8q5szIL1vW1m4cw6rHBeaSwSbbTsfaBslPS1CwPzm osxg==
X-Gm-Message-State: AOAM533wD44QsQwgUpjjck6+aJYTnDX7gLUoXwa4prPrtdd+RNaXN2sU QXcZOr3f5/GoBke2iei0a9L2rI3PjNAUTkeNvAc=
X-Google-Smtp-Source: ABdhPJy3PeRJCU4IIJ9/5EKbZc5r53jJR35I+Ld9d5rLyiHRF9eCzbZEO73tnRYF4K4ufg4pyWPk0Mbx/atoSV/GMuY=
X-Received: by 2002:a17:906:c802:: with SMTP id cx2mr11632583ejb.298.1603017275363; Sun, 18 Oct 2020 03:34:35 -0700 (PDT)
MIME-Version: 1.0
References: <160288855079.14008.13967692974159638979@ietfa.amsl.com> <30344.1602894208@localhost> <FD995870-E9C6-4099-93AF-253F0A11F56B@tzi.org> <CADaq8jcKK5kUvU3v7+6gEaeqjqxtw-Bii5is_hoq1ugogCoWPg@mail.gmail.com> <20201017193610.GA39170@kduck.mit.edu>
In-Reply-To: <20201017193610.GA39170@kduck.mit.edu>
From: David Noveck <davenoveck@gmail.com>
Date: Sun, 18 Oct 2020 06:34:23 -0400
Message-ID: <CADaq8je4nFVKkGw3X+Yo53N1xaXrgNRvOw4ZaNA0mT3dsDi-kQ@mail.gmail.com>
Subject: Re: IETF 109 Preliminary Agenda
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Working Group Chairs <wgchairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000044540205b1ef8b26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/1LJmdHOK7fEPYQu5MUCuCncnyJU>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Oct 2020 10:34:39 -0000

On Sat, Oct 17, 2020, 3:36 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Sat, Oct 17, 2020 at 07:33:09AM -0400, David Noveck wrote:
> > On Fri, Oct 16, 2020, 8:34 PM Carsten Bormann <cabo@tzi.org> wrote:
> >
> > > On 2020-10-17, at 02:23, Michael Richardson <mcr@sandelman.ca> wrote:
> > > >
> > > > It appears that session are scheduled starting at 05:00 UTC, which
> would
> > > be
> > > > 12:00(noon) Bangkok time.   It's really as if this meeting was being
> > > held in Madrid.
> > >
> > > I don’t think you are aware when Spanish people tend to get up :-)
> > >
> >
> > Fair enough but I don't know when people in Bangkok typically get up and
> > I'm not sure it is really relevant.  Typically on-site meetings start at
> > 10am local time and go on to 5:30, creating a 7.5-hour window for meeting
> > sessions.
> >
> > Given that this is a virtual meeting,  it would make sense to widen those
> > windows to allow some amelioration of the problems that this creates for
> > some time zones, in this case, for those in the Americas.  Instead, the
> > window has been shortened to six hours and I'm not sure why.
>
> Could you expound a bit on why you think widening the block of time in
> which sessions occur would be helpful?


First of all, given that the current block (midnight to 6AM) was unworkable
for me, I was looking to provide options that would allow us to schedule an
nfsv4wg meeting during IETF.

It never occurred to me that there were people who would attend the entire
12Am-6Am meeting and had no expectation of people attending an expanded
version of that.  It now appears that there are such people but I expect
there will be very few.

IIRC we have survey results showing
> that in a virtual format even the 7.5-hour window is too long to be
> practical, and having a longer window is going to push more of the session
> timeslots into times that are quite painful for more participant timezones.
> My understanding was that the idea of having a consolidated virtual IETF
> was to enable the cross-polination that occurs at in-person IETF meetings
> where most participants are attending sessions in most of the timeslots.
>

If that is the goal, it does not appear to be realizable for those in the
Americas given the current ICT session times, except for a small group
willing to turn their lives upside down to attend the meeting. Although
these times were not chosen to make this difficult, if you were trying to
do exclude us, it would be hard to pick a more forbidding time slot.


> Thanks,
>
> Ben
>