[nfsv4] Path forward for flex-files

David Noveck <davenoveck@gmail.com> Sat, 05 August 2017 13:21 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 C12E0131D38 for <nfsv4@ietfa.amsl.com>; Sat, 5 Aug 2017 06:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lVyOoY30-aaE for <nfsv4@ietfa.amsl.com>; Sat, 5 Aug 2017 06:21:43 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 7CB50131D28 for <nfsv4@ietf.org>; Sat, 5 Aug 2017 06:18:51 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id m34so2434666iti.1 for <nfsv4@ietf.org>; Sat, 05 Aug 2017 06:18:51 -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=+i0TETV+N79t1vd11PB1o9UHj+m3MYqzNC8PSwAUAhQ=; b=C5MwgL462mF1jMLMThS2EXr/sOvj52rLGYd5OsUWnvcmIy5ImrgxpBPBr/r6H1D+dT DMsnY38NQunmwfRYWZPRSUaTXmfhH98pNU5PoGGF7DmopZ1LmL7nF5hdJnHwB1FK4K7a OqQc7zhDrZWjlBMDp/eWMa99O+f7Ys7WfEg171X5uw/q8zQmP/H36S/3dgIGS7GzBxAV ABjuLG2DWrpOKnsGY2Dqbm1UvCXZUJTo6EPaeao5DQwSQ5vvPVo3Z9sKN5ANo6wvf1UA CWSOxMKUEhIMfaNFvOnKCgNxpL/fafTLPsnN27fTHk+DqvEl1Sqa8/G9f4TCg401jNwy 3Opw==
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=+i0TETV+N79t1vd11PB1o9UHj+m3MYqzNC8PSwAUAhQ=; b=EbXvgLA0IE3744TrPlCUaO9TfIqyA2ZCBE8K96QPMUZNc2B9crHaH4vN18h91YEqhc XfVVo0MlBoOzl1SACiL0s44wQib1GlYzJ2BcN7Z7BD1OL0zoq1NOEUX2+nqsczb+hqx4 R2NJtK16164EaNLV7R1azWejbzTh6z7Lc5ZqplM2/AceE4l2YmbjuLHHTzUmPqtB22aV +EKauvUKdlCsnC0HqCtLXIoJ95Bo9EBKhqcOYaOVmf0v6jhIk3I6OlzqjitPdIsJxWKV ap5x1RTdewEkuQfxATCMYGUk9toZ5lhkMn4GgOyPNZWFQ2f11FGCaq5tpxor6w0ukDM0 +2qA==
X-Gm-Message-State: AIVw112E9otyo5oHFcNoAW4h0X5S8OkVc8OlgQOPWz4TaNDXuIlbJo36 L8x2JxfQOFGIw8613MhSMER06hRLxg==
X-Received: by with SMTP id n143mr5409002ita.47.1501939130616; Sat, 05 Aug 2017 06:18:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 5 Aug 2017 06:18:50 -0700 (PDT)
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 05 Aug 2017 09:18:50 -0400
Message-ID: <CADaq8je82zvas0iAK+sSFzQ29g4pnYOVtqEpUaLpar7WdJxA6Q@mail.gmail.com>
To: Tom Haynes <loghyr@primarydata.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a11445f945ad2d00556017401"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/xYVotusDVRrSJi2RtxrK_HYdcfs>
Subject: [nfsv4] Path forward for flex-files
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: Sat, 05 Aug 2017 13:21:47 -0000

I've been holding off on doing a detailed review of flex-files-12 since Tom
has previously indicated there would be -13.

I've been following the discussion of the details of loose-coupling
security, but my lack of understanding of Kerberos meant
that most of the discussion went over my head.  However, I think it is
pretty clear that if Olga doesn't think the approach in -12
will work and Tom agrees, then it won't work and I'm glad we are moving
on.  I don't think that the deletion of RPCSEC_GSS
support for loose-coupling will be an issue for the IESG, since there is
support for this when used with tight couplling.

I'd like to see this document and layout-types go forward in the near
future and my initial comments will focused on making
sure that that happens.  Later I'll discuss the issues with regard to the
future work that Tom is thinking about.

As I understand things, -13 will include the changes that Chuck has
suggested to tie this document more closely to layout-types
and I think that's a good thing. When that change is made, it will need to
address the fact that these two documents define the
term "control protocol" differently, although there probably aren't
differences in actual usage to address.

As far as I am concerned, there is no need for another WGLC cycle for
layout-types-06, although Chuck (or others) might feel differently.

If we consider the longer-term perspective including the work Tom has
discussed, it seems to be that we have to decide on
how to divide the following items into RFCs:

   1. The definition of the XDR for the initial flex-files layout type
   (currently FLEX_FILES but I think FLEX_FILES_v1 should be considered) along
   with registration request for it.
   2. The registration request for the follow-on layout type, FLEX_FILES_v2
   (I briefly considered FLEXIER_FILES but somhow, sanity returned :-).  This
   one would not have an explicit RFC # but I believe that there is a way
   around that to create some sort of early registration with an RFC to be
   named later.
   3. The XDR corresponding to the follow-on layout type.
   4. The framework allowing co-operation between MDS and client to
   implement RPCSEC_GSS for loose coupling.  I expect this would allow use of
   RPCSEC_GSSV3 but see no need to say  so explicitly.
   5. The actual coordination scheme that Tom wants to standardize.

If this organization of the work does not make sense or is missing
something, please let me know.

I anticipate that the initial flex-files RFC would include 1) and 2).

The reasons that I don't want to include 3) are:

   - 3) doesn't make much sense without 4) and adding 4) would push the RFC
   off a while.
   - There's a small possibility further XDR issues will arise so we might
   as well avoid committing to a specific XDR until we have to.

It might make sense to do 3), 4) and 5) together but Tom might want to
divide these into multiple RFCs.