Re: IETF 109 Preliminary Agenda

Benjamin Kaduk <> Tue, 20 October 2020 00:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C35E23A12B0 for <>; Mon, 19 Oct 2020 17:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uvpRtUViL5kJ for <>; Mon, 19 Oct 2020 17:17:39 -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 BB4D93A12AE for <>; Mon, 19 Oct 2020 17:17:39 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 09K0HW8l016272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 20:17:37 -0400
Date: Mon, 19 Oct 2020 17:17:32 -0700
From: Benjamin Kaduk <>
To: David Noveck <>
Cc: "Andrew G. Malis" <>, Working Group Chairs <>
Subject: Re: IETF 109 Preliminary Agenda
Message-ID: <>
References: <> <30344.1602894208@localhost> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Oct 2020 00:17:41 -0000

On Sun, Oct 18, 2020 at 01:52:28PM -0400, David Noveck wrote:
> On Sun, Oct 18, 2020, 9:17 AM Andrew G. Malis <> wrote:
> > David,
> >
> > Speaking as another person in the upcoming midnight-6 AM zone ....
> >
> > Think about how the folks in Asia feel when we schedule a virtual meeting
> > for our daylight hours.
> >
> I would not do that of it were a real issue.  Nfsv4wg has no active members
> in Asia.   And no non-member has ever expressed an interest in attending,
> regardless of time zone  issues.

It is hard to be certain that all or even most people who would consider
attending would ever "express an interest" in doing so -- there's not a
good way to get any real data.  That said, my opinion informed by
experience is that NFSv4 is a fair bit away from being an "average" IETF
WG in terms of being tied in to the overall participant pool.

> It's convenient for us, but not for them.
> >
> So, in this case, except for the prospect of cross-polination, about which
> I am becoming rather dubious, there is no "them" to be inconvenienced.

Well, I know one sample does not make a data set, but NFSv4 is regularly on
my list of WG sessions that I want to go to at the in-person meeting but
I'm unlikely to carve time out of my normal schedule to attend a virtual
interim for it.  There are many reasons why I'm interested, but only
loosely interested, in NFSv4 (I like GSS and NFSv4 uses RPCSEC_GSS, I
maintain a different XDR-and-RPC-using network filesystem, ...), and of
course everyone can have their own opinion about whether it is useful to
get comments from me (whether early in the process or late in the process),
but I fall into the "cross-pollination" bucket for this case.

> We do 1+1+1 for a reason
> >
> Understood.
> to spread the pain.
> >
> There's a difference between spreading unavoidable pain and creating
> unnecessary pain.
> It's only fair. And to your other point, the survey results were very clear
> > that people prefer a shorter day (6 hours) for the online IETF meetings.
> >
> We've never had an explanation of why those particular six hours were
> chosen and I don't think we ever will.

Recall that these six (well, five) hours were first used for Vancouver,
which was converted into a virtual meeting on a very tight schedule.  My
recollection, which I cannot currently substantiate, is that we were quite
set on respecting the "working hours in Vancouver" boundaries, but put some
thought into picking a subset of those working hours that was "least bad"
globally.  At that point it was not clear how quickly (or slowly) things
would return to normal, and so trying to optimize for which five/six hour
slot would be least bad when averaged over 1-1-1 was not anywhere close to
the top of the (frantic) priority list.  It does seem to have
(inadvertently?) set a precedent, though.  Hopefully SHMOO can give some
more input in time for 110 and we can shift things around if needed.