[nfsv4] Milestone draft for working group review

David Noveck <davenoveck@gmail.com> Thu, 17 August 2017 11:35 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 B6ABD132113 for <nfsv4@ietfa.amsl.com>; Thu, 17 Aug 2017 04:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 9cvLgiz3akb5 for <nfsv4@ietfa.amsl.com>; Thu, 17 Aug 2017 04:35:39 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 855E71204DA for <nfsv4@ietf.org>; Thu, 17 Aug 2017 04:35:39 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id g71so21965195ioe.5 for <nfsv4@ietf.org>; Thu, 17 Aug 2017 04:35:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zAwAHlpC5Fk8M6dg3pYuyjQ4kEOI6UYNbWz75vwM4fY=; b=LQZxS9yjYdRkcBc/nCJ3w4MowCZaMORQpcQ75RM6PzXHZLkXBIWdaguzUco8dTrkfF x/VF/xju002CCVz0FZXYQAyYj0y6XBlS8h4lImGLJ75U+52hyReGXZyNX4wVPEc5Gmgl B8lBgEl6hvp6qWshG6xu5k7y1yJ3/ZdjiUav278FUo+2rXEtjqOGEhcH6ksGePkpvPF3 7UwJhQ6uCoi7erMnHgyjQKiewwV6Pj6pbU36NaGLHBhQZHusGRzWMW9Wpg9gFQkmdgh4 1Mb2o39Pm7J1yypG13zDLFkcgCsl1OcxabZx94lX5Tj3C7/M8B0YvniUkdNGCfmvXPv3 2pwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zAwAHlpC5Fk8M6dg3pYuyjQ4kEOI6UYNbWz75vwM4fY=; b=WzglhNXCIKWGD1vJtO5eXUpWPqgm4zsJy0vpjLIC2p4MUC6d4XkobgzVHjcoqztzLq x7Be25gyt9NpiLJ9sf9GXFJFpMFwWMKLjPpJQxteAdBghDEh0eH5BTpzHTvXr20TxtmB 6UR8BJ+EmtyK4oTQniUZamBcUMmoJlixFtp88tLlpE0mIMjvHnk4tYcSB/TVi2M0Jwk3 Yg/mNRr4skHhVaZbyYVjjNQoVHu/Jx5EiFagRR38OudyggC5oSGGR2cUA2RX3bKs4Vj1 SnhZkrQZycZXmbPp7GpE43te9LuBEdBMLD7zn6h84G8ZSdKMZtIYkWAWQOkgvA8amCgr 4Irg==
X-Gm-Message-State: AHYfb5jCvlETxqP3S6lrpKsPMoJ662llFL5FauKKizZLyWRx0OOcADhx 5+ovN3wIeivee7sVzECazJbhj6e2vw==
X-Received: by 10.107.50.136 with SMTP id y130mr4341254ioy.70.1502969738518; Thu, 17 Aug 2017 04:35:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.142.72 with HTTP; Thu, 17 Aug 2017 04:35:37 -0700 (PDT)
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 17 Aug 2017 07:35:37 -0400
Message-ID: <CADaq8jcAn_VAZCO=B_VbAZGoOK2LYB9n3FEr4zwnwC1MWL2yjQ@mail.gmail.com>
To: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/mixed; boundary="001a11447aca5f9e2f0556f16915"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/dOhC1nJRl-QgySN1keQ4iwsfh6g>
Subject: [nfsv4] Milestone draft for working group review
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 17 Aug 2017 11:35:43 -0000

We've previously discussed and reviewed a proposal for a new working group
charter.  The only thing missing was a set of proposed milestones.

Since that time, I've been discussing this subject with the authors of
active working group dcuments and I-D's that appear likely to become
working group documents (except for Benny HaLevy who seems to no longer be
active in the working group).  The draft of what we (Chuck, Tom, Christoph
and I) have come up with is attached, so that the working group can review
it.  I had assumed that others in the working group did not have any
proposed milestones that they would like to include and work on.  If I was
wrong about that, please bring any proposed new milestones to the attention
of the working group as part of this review.  If you have an idea for a
milestone which is not quite ready for this list, hold that thought.  There
is a mechanism for the working group to create new milestones later, once
the charter is approved.

It would be good if the working group could review this by Friday 8/25, so
that we can make any necessary adjustments and provide the chairs and ads
with a consolidated charter proposal including the stuff I sent to them on
7/31 but with the milestones included.  If anyone thinks theey need more
time to do this review, please let me know.

Most of the items on this list are not yet working group documents but I
hope I haven't included anything that people would object to becoming
working group documents.  If you do object or have issues with any of these
becoming working group douments, we need to address that as part of the
milestone review.

There are some notes below about the documents associated with the proposed
milestones, in time order.  Please let me know if you need any
clarification.

First are documents associated with the 2018 milestones:

The 3/2018 milestone is for the working group document deriving from
draft-hellwig-nfsv4-scsi-layout-nvme.  This document was discussed at
IETF99 and there was general agreement that it would become
standards-track.  There were a number of structural changes proposed at
that time and I assume Christoph is dealing with those before formally
requesting working group status for this document.

The 6/2018-10/2018 milestones all concern documents relating to changes for
trunking and state migration.  I presented slides about these at IETF99.
If these are not easily available, please let me know.  There are four
milestones and three documents as follows:


   - The 6/2018 milestone concerns draft-ietf-nfsv4-migration-issues.  It
   has become clear that fixing migration and trunking are inherently related
   so -13 has been retitled to reflect this fact.  If people have the time,
   I'd appreciate reviews of this document to make sure that we adress issue
   now, rather than in a rush at WGLC.  Although this document is
   informational, there will be a number of standards-track documents that
   derive from it.


   - The 8/2018 milestone concerns a document addressing trunking discovery
   in NFSv4.0.  This document addresses the same issues that had been dealt
   with in Andy's previous trunking discovery document although the treatment
   is significantly different.  In the IETF99 slides, the prospective I-D on
   which this will be based is referred to as
draft-adamson-nfsv4-mv0-truunking-update.


Since then, Andy has retired and his co-author Chuck Lever has agreed to
submit draft-cel--nfsv4-mv0-trunking-update, based on the work Andy has
already done.  I think Chuck will work on submitting this as soon as he has
had an opprtuunity to catch his breath after completing the work on the
last of the documents associated with RPC-over-RDMA version 1.  I expect to
be a co-author of the trunking update document and will work to keep the
trunking discussion for both minor versions consistent.


   - The two 10/2018 milestones will most likely be satisfied by the same
   docment, specfically the working group document to come, based on
   draft-dnoveck-nfsv4-mv1-msns-update.   I've previously promised to
   submit that I-D by the end of August and expect to be able to do that.

These are listed as two separate milestones because the working group has
not made any decision yet about how to go forward to address v4.1 issues
with regard to trunking and state migration.  If the working group decides
that these will be addressed in a single document, as I believe is best,
these two milestones can be coalesced.

One possible occasion for the working group to make this decision is when a
proposal is made to convert this document to working-group status.  Another
is to address this as part of the milestone review.  In any case, there is
no need to rush this decision since we could maintain these as two
milestones indefinitely.

Now let's look at the documents for the 2019 milestones:

The first 1Q2019 milestone is for a WG document deriving from
draft-cel-nfsv4-rpcrdma-cm-pvt-msg.  Although that document's current
proposed status is standards-track, Chuck has decided that the milestone is
for an anicipated informational document.  The working group can discuss
the issue of the document's status as part of the milestone review or when
Chuck formally asks to turn this into a working group document.  I
understandthat there may be controversy about the  issue, but I don''t
anticipte difficulty arrving at a consensus everyone can live with.

The other 1Q2019 milestone is for a WG document deriving from
draft-hellwig-nfsv4-rdma-layout.  As the discussion at IETF99 showed, there
are still significant issues to resolve before this document will be
complete.  I think we will want to identify those as part of the milestone
review, but it is not necesssary to address them now, or even when the
document becomes a WG document.  For those who think that Christoph's date
is optimistic/aggressive, I agree but feel that given the guidance we have
gotten from Spencer D., optimistic milestones are OK.  If, on the other
hand, you feel that Christoph has a date which is unachievable/delusional,
we can discuss that issue as part of milestone review.  If we do push that
date off and Christoph does get this done by 3/31/2019, then he gets to
tell all of us, "I told you so."

The 3Q2019 milestone, is for a WG document deriving from
draft-cel-nfsv4-rpcrdma-version-two, of which I am a co-author.  There are
still some technical issues to resolve, principally about the credit
mechanism, but those do not need to resolved as part of the milestone
review.  However, they do need to be identified so that we can go on to
resolve them as the document is refined further over the next two years.