Re: [nfsv4] How the NFSv4 working group "meets" - what are the options...

David Noveck <davenoveck@gmail.com> Tue, 29 October 2019 09:55 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 A7EF7120133 for <nfsv4@ietfa.amsl.com>; Tue, 29 Oct 2019 02:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=0.01, 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 KvRAB6ddZ7jW for <nfsv4@ietfa.amsl.com>; Tue, 29 Oct 2019 02:55:01 -0700 (PDT)
Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 1541A12010F for <nfsv4@ietf.org>; Tue, 29 Oct 2019 02:55:01 -0700 (PDT)
Received: by mail-oi1-x243.google.com with SMTP id n16so6142155oig.2 for <nfsv4@ietf.org>; Tue, 29 Oct 2019 02:55:01 -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=7RZra86iHAWA4VB/gIG/HOzd+F9YRabpUAlQHfs1HMw=; b=BfTUQUols7U7LTet/JRjqxCS3a9z+M9hgsJasdQACegZcmmnMecn45thiAPtlF1a64 ZxZzRSI6gY3rvAXrhZG9SGBATnX39c7i9ojjWPOlaCEdloM6bLjftYZkDu6fPvqmAtiD NJkJ/5TDvgtNuVNto5ieyrR191/7eMR6FDJVoh4fT0X/3CrxQfWJJaUiMaiXu9iM8hvP uuElq8wAC9UUW4a3mSjr694z74W4jrU+hfqdgfj1yZN+i1KYiFzYFMWmmUkF4rEZ4c6a z95aufJuhvRJ9LahMDEIslFcAmETQONvMwSesz/d18LSPIX0nq4Cale32fhe3FCCdmUM UxVw==
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=7RZra86iHAWA4VB/gIG/HOzd+F9YRabpUAlQHfs1HMw=; b=lvEhSvdDaIHMabaY+gscXa8+benW3f8lk2aWSdS3bLTOuteadomMAibj8xP0hBloPb q0y5sfjkzl5h/0OawOCxrQnbDAHsMONQgccs3a/CQSIvCht7F0JIRsyO3VE63UKJimBq ThI5o14R1zjWkfw+FhUIOu3yIAJ3pzFykoGSzxblikfRkXWAmM/1/NrhEzifDScZuMfj mdHoDZem1fZ454YxW6PPue43cMP7YbdSNTuMnT3/aRMzj+eDztLwTvUeG7Bz9g5/Y0Vd kg+uEcpxXnOXKWfmhXMtkhoSdrhJ2Yu9R788j95LCkcVmDpQA7E/9bB2dm1iM0YvdcR2 hiaw==
X-Gm-Message-State: APjAAAXvFd8AsrCU+uHc63dq7QQFvmAaXQMdm2awLWYPq0ESTFACH/wQ L3JUbnlgabHrfiby/ki99tIfIemJO3+AisoZF2Y=
X-Google-Smtp-Source: APXvYqz+IF8jZTeInkjrpepfgdE/1hdz7f+ghpA0HsvHEIXEznlD18FsxyxTfo/X4sMhe0jtnbtFWWPuhr9e3eFZa3U=
X-Received: by 2002:aca:281a:: with SMTP id 26mr3161391oix.82.1572342900156; Tue, 29 Oct 2019 02:55:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAFt6BanTAdFt6YyyoDLE_G+3VH28HrP0LnHzABmh_qDJBrYthA@mail.gmail.com> <CADaq8jfVBkd310nTq870rXvGVHnwHwFA+dKnKkoKNrwsk+y5+Q@mail.gmail.com> <CAFt6Bamh-oGwVh_G+KkEnn_yN7Sej5po1wdCHSCKOaWat4upgw@mail.gmail.com>
In-Reply-To: <CAFt6Bamh-oGwVh_G+KkEnn_yN7Sej5po1wdCHSCKOaWat4upgw@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 29 Oct 2019 05:54:48 -0400
Message-ID: <CADaq8jebYJxcfNJ7n2-VwcsM6usqpdnvA1vxE14vpjxpTpcOyQ@mail.gmail.com>
To: spencer shepler <spencer.shepler@gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000076ea70596099c34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/-BsZzUPPgNsxE2iqmhLs0k7VNwM>
Subject: Re: [nfsv4] How the NFSv4 working group "meets" - what are the options...
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: Tue, 29 Oct 2019 09:55:04 -0000

On Mon, Oct 28, 2019, 12:22 PM spencer shepler <spencer.shepler@gmail.com>
wrote:

>
> Dave,
>
> With my email, I have now corrected the any perception of what the default
> is for meeting during the main IETF meetings.
>

You have articulated an appropriate default. Unfortunately, changing
existing perceptions, built up over years, is more difficult. Also, when
you state that nothing has changed, it has the effect of undercutting the
message you want to present to those whose view of the recent past is
different from yours.

There is no point in continuing to rehash our different perceptions of the
scheduling for the last few IETF meetings.  Instead, given that the working
group is now fighting for its life, we need to draw a line under those
earlier events and clearly establish a practice to be followed going
forward. I don't think you have done that.

Given the current situation of the working group, it would be best if you
or Brian or Magnus would make clear to people that we will be meeting in
Vancouver and that it would be helpful if everyone who wants the working
group to continue would participate, preferably in person, but remotely if
necessary.  If we start now, there will be time to deal with scheduling
issues including how many sessions to schedule and deciding on priorities
for our limited time together. Later on, there will be occasions on which
we can treat the question of whether to meet as an open question but not
now. Not meeting in Vancouver or failing to take full advantage of this
opportunity could make it impossible for the working group to continue.
That is the unfortunate reality and we have to adapt to it.



> I believe that I have also addressed the alternative methods of conducting
> working group activities.
>

You have but there are some problems that need to be addressed.

Prime among these is the question of what "well in advance" means.   If
this applies to conference calls, and I believe it does, and is longer than
a few days, the value of this mode of communication would be significantly
compromised.

The other potential issue is the over-reliance on chairs to transmit stuff
most probably done by someone else.  Not only is this a waste of chairs'
time, but it also adds a delay of uncertain length.  A third co-chair will
help here but we also need to reset our expectations regarding such routine
administrative tasks, to something like 24-48 hours. To deal with chair
absences, we need to stop sending such requests to individuals but to a
special mailing list designed for that purpose, e.g.
nfsv4-chairs-right-now.

>
>
> On Mon, Oct 28, 2019 at 4:16 AM David Noveck <davenoveck@gmail.com> wrote:
>
>> > Therefore, we always plan to meet.
>>
>> Your emails regarding the last three IETF meeting do not reflect that
>> approach to planning.   I think there is a need to reflect this
>> always-plan-to-meet model more explicitly, particularly given the group's
>> current situation.
>>
>>
>>    - For IETF104, the message title was "IETF 104 - WG sessions
>>    scheduling is open - NFSv4 in Prague?" suggesting that there was as yet no
>>    plan to meet.
>>
>> It goes on to say "This email is solicitation of potential agenda items
>> and overall meeting interest to determine *if* (emphasis added) an NFSv4
>> WG meeting should be scheduled.
>>
>> Further, the deadlines are based on the time for requesting a session
>> rather than for providing an agenda for a scgeduled meeting.
>>
>>
>>    - For IETF105, the message title was "IETF 105 - Montreal - NFSv4 WG
>>    meeting ?" also suggesting that a decision was yet to be made.
>>
>> The message text continued the same approach: "Does the working group
>> have the topics/agenda items necessary to meet face to face?"
>>
>> As it turned out some people had to eliminate valuable discussion items
>> to fit within one session and we still found ourselves running over.
>>
>>
>>    - For IETF106, the message title avoided the question mark: "IETF 106 NFSv4
>>    WG meeting"
>>
>> However, the text of the message left the meeting as an unresolved
>> question suggesting that there was no intention to meet (which made sense
>> in the case of Singapore):
>>
>> Scheduling requests are now open for IETF 106.
>>
>>
>> I would like to solicit input from the working group as to the need to
>> meet at IETF106.
>>
>>
>> Please let me know by Sept 20th *if *(emphasis added) we have agenda
>> items that necessitate an IETF106 meeting
>>
>> Given this history, it was certainly reasionable for participants to wait
>> until a decision is actually made, before making their own travel plans.
>>
>> In none of these case, is there any indication that the actual
>> need/likelyhood of meeting had any role in the decision process or in the
>> approach to planning.
>>
>> In the case of IETF107, the group's current situation and the meeting
>> location means that we will need to have a meeting and that many
>> participants would be able to attend if given sufficient notice.   It is
>> necessary to soon make clear that we will be meeting and that the important
>> scheduling issue is the number and size of sessions to schedule.
>>
>>
>>
>>
>>
>>    -
>>
>>
>>
>>    The deadline for the meeting request is 08 Feb 2019.
>>
>>    Given the upcoming holidays, I would like to make a decision by Jan
>>    21st.
>>
>>
>>
>> On Mon, Oct 28, 2019 at 3:20 AM spencer shepler <
>> spencer.shepler@gmail.com> wrote:
>>
>>> Given recent comments on the WG alias about how the work of the NFSv4
>>> working group “works” needs to be addressed.  I am starting a separate
>>> thread such that all working group members might benefit from a reminder of
>>> what resources are available to accomplish the work of the working group.
>>>
>>> First, the brief, “marketing” message of how the IETF accomplishes work
>>> is here:
>>>
>>>
>>> https://www.ietf.org/how/
>>>
>>>
>>>
>>> However, the more fruitful reference is from RFC 2418 “IETF Working
>>> Group Guidelines and Procedures”
>>>
>>> I have included a quote from that RFC below for reference.
>>>
>>>
>>>
>>> As working group co-chair, I always assume that the working group is
>>> meeting at the main IETF meetings.  While I have in the past suggested that
>>> the WG work under the assumption that it would “not” meet, the consensus at
>>> the time that this position was inappropriate.  Therefore, we always plan
>>> to meet.
>>>
>>> However, the NFSv4 working group does not always meet and I am required,
>>> as a working group co-chair, provide an agenda well in advance of the
>>> meeting.  I have queried the working group for an agenda to build that
>>> content and secondarily query working group members about their planned
>>> participation at an upcoming meeting.
>>>
>>> Given the small numbers of active participants, all it takes is the
>>> absence of 2 member of the active core to make it difficult to have an
>>> effective face to face meeting at the IETF meeting.  Case in point is the
>>> most recent IETF 105 meeting and there were 11 participants. Four of these
>>> are active authors/editors and the remaining participants were there for
>>> administrative support or general interest.  My point is if 2 of those 4
>>> individuals were missing – it would have been significantly less
>>> productive.  That could be perfectly fine to have small numbers but it is
>>> obviously prudent to plan ahead to ensure that the meeting is a good use of
>>> everyone’s time and a good use of the space utilized during the broader
>>> IETF meeting – space is a premium.
>>>
>>> As for other meetings, conference calls, interim meetings, and other
>>> working group meetings are all perfectly fine.  As the quoted text below
>>> indicates, these meetings can occur as long as there is broad knowledge of
>>> the meeting, it is open to participation, and that minutes are collected
>>> and reported out.  The co-chairs do not have to be present for these
>>> alternative working group meetings – our responsibility is that the minutes
>>> are collected and reported broadly.  So, if there is going to be working
>>> group meeting, notify enough in advance, invite everyone, take minutes and
>>> record them.
>>>
>>>
>>>
>>> Spencer
>>>
>>>
>>> https://www.rfc-editor.org/rfc/rfc2418.txt
>>>
>>>
>>>
>>>
>>>
>>> 3.1. Session planning
>>>
>>>
>>>
>>>    For coordinated, structured WG interactions, the Chair(s) MUST
>>>
>>>    publish a draft agenda well in advance of the actual session. The
>>>
>>>    agenda should contain at least:
>>>
>>>
>>>
>>>    - The items for discussion;
>>>
>>>    - The estimated time necessary per item; and
>>>
>>>    - A clear indication of what documents the participants will need to
>>>
>>>      read before the session in order to be well prepared.
>>>
>>>
>>>
>>>    Publication of the working group agenda shall include sending a copy
>>>
>>>    of the agenda to the working group mailing list and to
>>>
>>>    agenda@ietf.org.
>>>
>>>
>>>
>>>    All working group actions shall be taken in a public forum, and wide
>>>
>>>    participation is encouraged. A working group will conduct much of its
>>>
>>>    business via electronic mail distribution lists but may meet
>>>
>>>    periodically to discuss and review task status and progress, to
>>>
>>>    resolve specific issues and to direct future activities.  IETF
>>>
>>>    Plenary meetings are the primary venue for these face-to-face working
>>>
>>>    group sessions, and it is common (though not required) that active
>>>
>>>    "interim" face-to-face meetings, telephone conferences, or video
>>>
>>>    conferences may also be held.  Interim meetings are subject to the
>>>
>>>    same rules for advance notification, reporting, open participation,
>>>
>>>    and process, which apply to other working group meetings.
>>>
>>>
>>>
>>>    All working group sessions (including those held outside of the IETF
>>>
>>>    meetings) shall be reported by making minutes available.  These
>>>
>>>    minutes should include the agenda for the session, an account of the
>>>
>>>    discussion including any decisions made, and a list of attendees. The
>>>
>>>    Working Group Chair is responsible for insuring that session minutes
>>>
>>>    are written and distributed, though the actual task may be performed
>>>
>>>    by someone designated by the Working Group Chair. The minutes shall
>>>
>>>    be submitted in printable ASCII text for publication in the IETF
>>>
>>>    Proceedings, and for posting in the IETF Directories and are to be
>>>
>>>    sent to: minutes@ietf.org
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>