[nfsv4] mv1 msns update, The Final Chapter.

David Noveck <davenoveck@gmail.com> Tue, 25 June 2019 14:05 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 17F3712013C for <nfsv4@ietfa.amsl.com>; Tue, 25 Jun 2019 07:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yhlPZVjkY1NV for <nfsv4@ietfa.amsl.com>; Tue, 25 Jun 2019 07:05:06 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 D402A120019 for <nfsv4@ietf.org>; Tue, 25 Jun 2019 07:05:05 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id z23so17307003ote.13 for <nfsv4@ietf.org>; Tue, 25 Jun 2019 07:05:05 -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=FKNZ4np+CthRJfAuMWcYy8xJ0mGQBlgxiShpgaDI08o=; b=X2VmKiecijfefUYWL8Et8pLMLknCu7XXI563OoStkgf5/Ygfom/dVDU2vok4INCXyK u49c353d7EnM7PGrIBkkzicNyKCAOKc0F/iZ6jaQy7YMVfD/fvP7OrkI8UFyV2WUrgO+ qo+2ABVBi2AQnYOPeqCO8EGazsLdNtwz5+GUkB/ax81pFXzPwSwGf+BToGrqMiLlHjNa zbHhwnPqeqLxV1r7kYk0mGNCDzurKPDDvDsC/aQtGjFMM2mARY33t7XCBpDNBT09litn c8+wL4kaX6TcIZ3C09roC4OEF5jJURcorhX83s+po+na8Wlw2SkaSG1W1o9mz6Q4d1Dr nKrg==
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=FKNZ4np+CthRJfAuMWcYy8xJ0mGQBlgxiShpgaDI08o=; b=t9kgDB+yhkfyz0E6QlL316noYb+4ZUdzR4NnA0JkdlePG3BRSJ+6shBc1PKN8GQzfk TdbtNbSvGH94tUGVVm5gCyTJu8v/INsJ3pLwlZNlghu0sz4J82CVn3IYqZYtQR71wM4c fFCFH8XDy16SED2sGYA8Vm/256pB2hnmx6Mu+BCS4335h1inEPfPf8ihVsJWc5gdYyo+ TdcC7vpIYvOgoWg6AdJh9huvGeEJcDdo5xbYdzqRtI2wDpngBvwWPXIKDUAv/JKNYKR/ ndvzuSVzrFZwsGR9sMJYUB0ic5uDPVuwKGsRC/dlCQlpgdvqI7mrUqN2G0CFwjZUgI2s 7MVw==
X-Gm-Message-State: APjAAAVFtWtzY2dB+A73rrKXsz4ZvtaLOLSzeMBaEx6+ziclZC7xhhyS 3BlQqZYOK26gi0S5wqKHU2tP7JXAsAMjy0RtZGkYVQ==
X-Google-Smtp-Source: APXvYqyT6cbkTdoun5+a1YjHyoCJ25bYOrYDCOWQc/tFIfut8v/2Ua1t55ITi/nHUu/yyC27Ti+4MFXbhIUk7FZifWI=
X-Received: by 2002:a9d:70d3:: with SMTP id w19mr4390613otj.208.1561471504829; Tue, 25 Jun 2019 07:05:04 -0700 (PDT)
MIME-Version: 1.0
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 25 Jun 2019 10:04:53 -0400
Message-ID: <CADaq8jffFzWEyi1txbV-ot5Nv81BdhKWRJ6dPjK3CrSt+dTcjg@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f550a058c266a7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/xP5SA2naf6xQTSTVH1VV4VuOFVs>
Subject: [nfsv4] mv1 msns update, The Final Chapter.
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, 25 Jun 2019 14:05:11 -0000

I really hope this is the final chapter even though it is likely to be a
long one.

I've just submitted draft-ietf-nfsv4-rf5661sesqui-msns-00 which replaces
draft-ietf-nfsv4-rfc5661-msns-update which in turn replaced
draft-ietf-nfsv4-mv1-msns-update.    All these three documents had the same
goal, which is to to update the multi-server namespace features of NFSv4.1
to include support for trunking discovery and transparent state migration.
 The different formats were a series of attempts to arrive at a document
format that the IESG is comfortable with, with the current format being a
very bis-like document which is intended to obsolete RFC5661 and replace it
with a document that makes the required changes directly, rather than
explain the changes to be made to RFC5661.

We need to give this document a meaningful review before asking the IESG to
consider it for publication as a Proposed Standard.   I'd like us to focus
that review on the parts that actually need review given that RFC5661 is
already published and that the working group has already gone through WGLC
for draft-ietf-nfsv4-rfc5661-msns-update and
draft-ietf-nfsv4-mv1-msns-update.   A good way to do that is to base the
review on an rfcdiff of this document and rfc5661, keeping in mind that the
new section 11 is pretty much the same as the section 11 replacement in

In doing the rfcdiff there are a few things to take note of:

   - An rfcdiff of rfc5661
   against draft-ietf-nfsv4-rf5661sesqui-msns-00.txt (produced with xml2rfc
   version 2) produces a number of spurious diffs, because version 2 formats
   some things differently than version 1 which produced rfc5661 (principally
   text tables).  I've found it helpful to rfcdiff against a .txt produced
   using the a .txt obtained using version 1 (at
   https://xml2rfc.tools.ietf.org/old.html).   I will send a v1 .txt file
   to the working group and hope it doesn't get sidetracked by the whole
   filesize-limit-moderation rigamarole.
   - A lot of differences show up only because of reference renumbering.
   Given that there are new normative references, all informative references
   get a new higher reference id given that rfc5661 was done with numeric
   references :-(
   - There is an annoying bug in rfcdiff that causes it to think
   (incorrectly) that the new .txt file has dropped sections 18.45 through the
   end of Section 19 and then ignore all the actualdiffs beyond that (e.g the
   new and changed appendices).   I have sent mail to Henrik Lewkowetz, who
   apparently deals with issues in rfcdiff but some email communication issues
   have resulted in a situation in which it might be a while before the issue
   is fixed..   Luckily, it only screws up past the point where rfcdiff is
   useful in showing changes within the document.

It is best to focus the review on the following sections which are either
new or significantly changed from the corresponing sections in

   - the Abstract (siginificantly revised from the one in rfc561)
   - Section 1.1, which is new.
   - Section 2.10.4 which has a significant update beyond the corresponding
   section in draft-ietf-nfsv4-rfc5661-msns-update.
   - Section 11.6, which is new (i.e. it didn't appear
   in draft-ietf-nfsv4-rfc5661-msns-update).
   - Section 22.1, which is new.
   - Appendices A, B, C which are new.
   - The Acknowledgments Section (was Appendix A; is now Appendix D) which
   has been restructured to include acknowledgments for both rfc5661 and the

The draft submission cut-off for IETF105 is 7/8.   That makes it unlikely
that I will submit a -01 before IETF105.   I will try to get an updated
document out as soon as draft submissions are allowed again.  This update
will reflect any comments I get up to and during  the working group