Re: [nfsv4] IETF 107 draft agenda planning

David Noveck <davenoveck@gmail.com> Mon, 18 November 2019 10:45 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38D412086F for <nfsv4@ietfa.amsl.com>; Mon, 18 Nov 2019 02:45:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 q8Tt9kgNGT6j for <nfsv4@ietfa.amsl.com>; Mon, 18 Nov 2019 02:45:21 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 6A2FD120851 for <nfsv4@ietf.org>; Mon, 18 Nov 2019 02:45:21 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id u13so14092191ote.0 for <nfsv4@ietf.org>; Mon, 18 Nov 2019 02:45:21 -0800 (PST)
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=NnnGRcQepGzWCozb1FA8Et5KpiWap7IAITJF3xaATco=; b=m5JczASqtAdzsseK7jXKyNBokSlDKfOSeGkzwBOKIP4FMPARZMFtxfAVJpPZ/jwsoT NyTSqcGaRbA7c1Sct0gAJwRHuzDAF6r5WgNy/UEnAyamvI4JxljaoZIjHApNrDjhDsTr ITViA6XkpzCsfNCvVoJZh4BQXMqk/n3H/cTmfkNdn0GxzQm5KRcMcfaT5tXbo4/FzsxS 16aQkpUwTIeKTvbSElXHoOG9OpxJjqfFanuE8Cdqm4y96/1LDjslhCAM6jPJEeQixf8z gTOj1Gk7WXUj+96ojy5aoiArLjr6B9sIeeP7S82zWZMhE9IVIHM4ChbPA+0N9ZgKfGPp fUcw==
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=NnnGRcQepGzWCozb1FA8Et5KpiWap7IAITJF3xaATco=; b=rKcIOEQWd/+MrdZSn2hDGs/IFAdbkdmRL7Adw6VeBaiW6lsvpjLHRfu2s9Uq5sioF8 qIfRr0rccW2SD1WyvhMReHXy+XVGgomD1Db8mEk3rK8suXxgyyhAgrrOK5+yRGgZgOJZ T3L8F9RETih40n3nW0mXKQ5ZKNJUD9472wq30qEhXwv8QdQt1QPdo5WgRTaPff+/F22j v8PffwSXvr+SPMMkDqcnhIfNyirN9qb/Sk9l6TnqWJwuCJVedsmmjzyGUhGyN7OFJXfN 1X+7mx67ld4/T+bJZaaBMZ1jbCjUYWvHKPi9uuTY3BakMuDJ4pOet0WtpwWpZs77uLIM cmKA==
X-Gm-Message-State: APjAAAVXLPMV1J/JOpEucvz2qEuoYe7iTGMRFG+dSXWOTcWhO8DnJlu7 Jx4OK3yX0B6ql5tFg6sVboRVzdG7BoSEHHSqNiY=
X-Google-Smtp-Source: APXvYqyw/2FheZBy3mIfV8PSpNH7ZXern7d0HSEmifeGXQuQRVjBedfokMlFxSEs3r9I3C2wVODboX2khMSN/1xvAdQ=
X-Received: by 2002:a9d:154:: with SMTP id 78mr13277930otu.294.1574073920356; Mon, 18 Nov 2019 02:45:20 -0800 (PST)
MIME-Version: 1.0
References: <30A75E5B-D2D1-4C28-A6DC-33F104E8DDD3@oracle.com> <CADaq8jcDbz2qQxuS0yNLEoF5C9jhnm4QcqM6qA-iyqxYvwm=sQ@mail.gmail.com> <CAFt6BanuLd+D1aBautrkVkdHe7b-ZB6N6cjh-3Hq3-K8a_FihA@mail.gmail.com>
In-Reply-To: <CAFt6BanuLd+D1aBautrkVkdHe7b-ZB6N6cjh-3Hq3-K8a_FihA@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 18 Nov 2019 05:45:11 -0500
Message-ID: <CADaq8jfO5NGqFQHa5a0yu=qZU4P_FA-eGH-hUikuFKwd5HcSqw@mail.gmail.com>
To: spencer shepler <spencer.shepler@gmail.com>
Cc: Chuck Lever <chuck.lever@oracle.com>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df872905979ca42e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/_8nDhvEsgDBGP5l8DsICuA7b2ts>
Subject: Re: [nfsv4] IETF 107 draft agenda planning
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 10:45:24 -0000

On Mon, Nov 18, 2019, 2:30 AM spencer shepler <spencer.shepler@gmail.com>
wrote:

>
>
> On Sun, Nov 17, 2019 at 11:05 PM David Noveck <davenoveck@gmail.com>
> wrote:
>
>>
>> On Wed, Nov 13, 2019, 1:52 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>>> Reminder: IETF 107 is March 22 - 27 in Vancouver, CA.
>>>
>>> In a recent thread, Spencer Shepler said:
>>> > I would appreciate it if the WG spend some time in building a draft
>>> agenda so that content and schedule can be built.
>>>
>>
>> The draft agenda will be needed about two weeks before the meeting, i.e.
>> about four months from now.  Still, I think it makes sense to start the
>> planning process, as you have done, early although, given that things may
>> change between now and then, we want to retain some flexibility/agility.
>>
>
> Yes, that is correct.  A formal agenda is needed two weeks prior to the
> meeting.  I was attempting to respond to your earlier comments about
> needing to define the meeting content with enough advanced notice so that
> potential attendees could assess and plan their participation accordingly.
>

Fair enough.  However, especially with regard to this specific meeting, the
agenda details are not critical.  For this meeting the critical elements
are:

   - That Magnus has made clear that we need to make substantial progress
   on our existing agenda.

I expect people to decide to attend (whether remotely or in-person) based
on whether they think that agenda is important and are prepared to help,
rather than on whether they want to hear about one pariculrar document.


   - The fact that we have a sessions devoted to new ideas, both for
   protocol extensions and as far as new ways for us to do business, if we
   can.   I remember that both of these had trouble getting time in recent
   meetings and that Chuck's ideas in the latter ctegory were dropped from
   IET105 because of lack of time.

For the latter category people will make decisions based on items scheduled
for discussion.  However, they might also make decisions based on ideas
they want to present.  For that reason, we need to leave some free time for
late deciders although, it might be only a half-hour making it necessary
for late deciders to fight-it-out for working group interest.


My apologies if I didn't ask for that appropriately.
>

No issue there..


>
>>
>> I think we should plan based on the framework that Magnus has suggested:
>> one session devoted to the working group's current agenda and a second
>> about things for future consideration.
>>
>
> Is that 2 x 2.5 hours sessions or 2 x 1 hour sessions.
>

We don't know yet.  2.5-hour sessions might not be available but I feel
that at least two hours will be needed for the first session. For the
second session, we will have a better idea in about a month.


>
>>
>> As far as the first session, I would need some time to discuss matters
>> related to rfc5661bis and related documents. I'm guessing 30-40 minutes
>> will be needed.
>>
>
> Is there a reason that we are waiting 4 months before discussing this
> information?
>

There was a lot of discussion at IETF105. The discussion should be captured
in the minutes and the slides are available onthe web.

The thing holding up further work in this area is the uncertain state of
rfc5661sesqui. Since that document would be the base for the bis, I have
been staying away from bis issues until the fate of sesqui is clearer.

I hope that you have a plan to introduce these ideas prior to the
> face-to-face meeting such that there can be discussion of what plan to
> undertake with rfc5661bis.
>

I'll send something once I am clearer about the fate of sesqui


>
>>
>> As far as possible contributions to the second session, this is kind of
>> early, but I expect people to come up with interesting ideas.
>>
>> For my own part,  I'll be sending out a proposal for some topics (about
>> 20 minutes worth) in the next few weeks.
>>
>
> I hope, again, that these ideas can be discussed on the working alias
> prior to the meeting to garner wider feedback and input.
>

As I said, I will send something out in the next few weeks

I still doubt that in-person presence will be broad so capturing the
> valuable input from the email threads would be great.
>

Also, if there is no interest, there is no point getting a presentation
together


>
>>
>>
>>> I can start by listing the items I'm working on and what kind
>>> of meeting resources IMO might be needed for discussion. I'm
>>> going to assume that we will avoid "status reporting" here,
>>> and strive to use the meeting time mainly for interactive
>>> discussion of open questions.
>>>
>>
>> I anticipate there will be some need for status-related time in the first
>> session. Let's say five minutes. I hope we will be hearing from those with
>> active wg documents and/or milestones.  The critical areas requiring wg
>> consideration of status are for those documents not otherwise represented.
>>
>
> I would prefer that we stop making the face-to-face working group meetings
> status meetings.
>

I asked for five minutes. I don't understand the reaction.


> If there is status to report, put it into a paragraph or two and send it
> to the working group alias such that it is recorded, broadly disseminated.
> Much better use of everyone's time.
>

I disagree. If the status is that nobody is working on something important
or that a milestone date is unreachable, putting it in an email paragraph
makes it easy to forget about.

Since our approach to email will not accommodate a paragraph in 40-point
bold Arial Black saying "We're screwed", it is sometimes necessary to have
status discussions at face-to-face IETF meetings.


>
>>
>>
>>> - rpcrdma-cm-pvt-data: Hoping this will be published by March.
>>>
>>
>> Me too.
>>
>> In any event, no meeting time needed for this document.
>>>
>>
>> I sure hope not, given that the document was finished in June.
>>
>>
>>> - rpc-tls: I'm hoping this document will be in post-WG publication
>>> process in March. I anticipate there will be no need for meeting
>>> time for this work, unless something changes significantly.
>>>
>>
>> Part of the 5661bis discussion will be about security but I think the
>> role of rpc-tls will be as a base for what it is possible to do in a
>> revised v4 security framework.
>>
>>
>>> - rpcrdma-version-two: The protocol is nearing feature completion.
>>> I anticipate this may be in WGLC in March, but it might need
>>> further discussion. Let's say 15 minutes on this one.
>>>
>>
>> Sounds about right..
>>
>> Note that this document also has implications for the new security
>> framework, just as rpc-tls does.
>>
>>
>>> - integrity-measurement: I want to have an IMA metadata format
>>> document in draft form for this meeting. Let's say 15 minutes
>>> for this discussion.
>>
>>
>> That's reasonable although it is possible to not get a real resolution no
>> matter how much time we spend :-(
>>
>> In addition, we could schedule a phone call
>>> or two before March to get through the objections to the current
>>> document.
>>>
>>
>> I think we should do that and use the meeting time to make sure that
>> everyone is ok with whatever resolution was reached previously
>>
>
> Put them on the calendar and plan ahead.
>

I'm sure Chuck will do that when he thinks it would be productive.


>
> 2 weeks notice and the US holiday season is starting soon
>

Sure, but this is a case on which sooner is not necessarily better.


> Spencer
>