Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt

Trond Myklebust <trondmy@gmail.com> Tue, 08 August 2017 18:55 UTC

Return-Path: <trondmy@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 49355132A02 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 11:55:07 -0700 (PDT)
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_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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rhZOGhFvehg for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 11:55:04 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 1ECA9132327 for <nfsv4@ietf.org>; Tue, 8 Aug 2017 11:55:00 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id q25so19345921uah.1 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 11:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4FU0ftEVvNJnpWlvt+ruV7O397R/vdnWNV9yiCkWc4c=; b=mYHBK+odgfBtuTY5QzKL/Nuz4zoU6jgB/SyXw9yFXYpZKzmiCDDKtftDv3awMUbmzt IqjNUb2gBIBRYLxcSnR7pZyKvZMenW60RGtBft7P2sncWH0O01Q0+H4ddwA8GXMy2//l /phJEBXDhSIsKfTpbal0vo4xEMwhF7ZgFBONmFTS0GC6Np/2CXZiDTzmqArjSS36enGF n44ExVkiEliTap6YFmCbyuVtlwJcKJmT75pjY/Ss9ZHnTgs2+oijl/1T2FpQr+G/OaxX ydRRzNyjvtdJS1bA6KrBSMPGiqvVLUdy3WeHWGk9/MhNwPagmbgpjU0dohxAM5jAweqN dtKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4FU0ftEVvNJnpWlvt+ruV7O397R/vdnWNV9yiCkWc4c=; b=IkMi0XU5MaAf8CTtR7SnraEDBMABQuRm6lWkXZfnHMGmlQ4RV+s2jsS4hW/i0tYcRJ XfXDO/QI/pB/LC7DznVkyvUk1KLC/rmVM8daIk0A8vIDexZwBWxVubGKd5vWU310qPWR n/6uXXA6LWqTgDC1VSzJndYcTDJG3bDppE9Umzm3p2ZJFVS4vL5KzoM76s3bGxIa1OA1 h7R3psdObStq8nH0Olz3fv5QZ/TDRhqOd36hU9tBKQ7ZKUlzSw4ix1kKxteUfNbdo52Q L0zfd3aiYrCx4nR7wI/eOO6ENF+BfK9uxhl+y/PhLBdYeEGBsGk3bK/inyMJeIObrwQx GESQ==
X-Gm-Message-State: AHYfb5gACBPdCjjKugaff5sjtnhXDZ8sDi9HTl0C4KLH94NDloRrhsr9 NbYqLrbUKF6AsCBjEa/71tUk5sfG0MmN
X-Received: by 10.176.4.7 with SMTP id 7mr3726393uav.215.1502218499166; Tue, 08 Aug 2017 11:54:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.27.28 with HTTP; Tue, 8 Aug 2017 11:54:58 -0700 (PDT)
In-Reply-To: <CAN-5tyETNMCPVC5wJ-_77vM5+hVB+-uasd37kn+M=hoCeK6P7w@mail.gmail.com>
References: <150215110527.12392.18161698955589691126.idtracker@ietfa.amsl.com> <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com> <CAN-5tyETNMCPVC5wJ-_77vM5+hVB+-uasd37kn+M=hoCeK6P7w@mail.gmail.com>
From: Trond Myklebust <trondmy@gmail.com>
Date: Tue, 8 Aug 2017 14:54:58 -0400
Message-ID: <CAABAsM6rmrDU4BR6Ho7YFjjYA2amEkwuRGtzN537VXUZ-Eh-hg@mail.gmail.com>
To: Olga Kornievskaia <aglo@citi.umich.edu>
Cc: Thomas Haynes <loghyr@primarydata.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05ffae0498e605564280a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/BbaSkocaFIXtFwMVkIAtc43Kwg8>
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
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: Tue, 08 Aug 2017 18:55:07 -0000

Why pass Kerberos tickets around? Is there any reason not to just pass an
initialised RPCSEC_GSS session handle?

Cheers
  Trond

On 8 August 2017 at 11:56, Olga Kornievskaia <aglo@citi.umich.edu> wrote:

> Hi Tom,
>
> Are you planning to expand the 4.1.1? The same comment that I wrote on
> my last email applies here where I suggested to specify 4things. It's
> needed to have interoperable implementations. As something can choose
> to return back TGTs (something like and AS_REP) and some might return
> server tickets (something like a TGS-REP). Some server implementation
> might encrypt needed info under the session key from the secured
> communication, some might encrypt it with the user's main key. How
> would the client know what to expect?
>
> Also when I wrote about opaque_auth being 400bytes I was talking about
> including just a single credential reply back. I'm looking on the
> network trace and my AS_REP is 801bytes and TGS_REP is 960bytes. And
> if somebody plans to include any authorization data in their tickets,
> well that will blow up even more.
>
> On Mon, Aug 7, 2017 at 8:25 PM, Thomas Haynes <loghyr@primarydata.com>
> wrote:
> > So here is a first hack at Flex Files v2. I thought it would come in much
> > smaller than 11 pages,
> > so perhaps some pruning will be necessary.
> >
> > I’m aware Ben had some comments on:
> >
> >    Can I suggest putting in a typed opaque auth blob instead of explicit
> >    synthetic uid/gid fields?
> >
> > I have purposely done:
> >
> >    /// struct ffv2_data_server4 {
> >    ///     deviceid4               ffds_deviceid;
> >    ///     uint32_t                ffds_efficiency;
> >    ///     stateid4                ffds_stateid<>;
> >    ///     nfs_fh4                 ffds_fh_vers<>;
> >    ///     fattr4_owner            ffds_user;
> >    ///     fattr4_owner_group      ffds_group;
> >    ///     opaque_auth             ffds_auth;
> >    /// };
> >
> > Because of AI1:
> >
> >    [[AI1: after the lesson learned from ffds_stateid, we either need to
> put
> > an
> >    array here or define all of the file handles to share the same
> >    credentials.  And as Olga points out in her email, this gets big
> >    fast.  Especially if we throw in many mirrored copies!  --TH]]
> >
> > I.e., the ffds_auth is inside an array of ffv2_data_server4 which is
> > in itself inside an array of ffv2_mirror4 AND it could be argued that
> > ffds_auth (and ffds_user/ffds_group) need to be an array.
> >
> > Even if we decide to make all FHs share the same credentials, we
> > eventually can hit a limit of the number of mirrored copies.
> >
> > And Ben, the other reason not to use a typed opaque auth blob
> > is because the  ffds_user and ffds_group are strings, and do
> > not fit into AUTH_UNIX. We could define AUTH_SYNTHETIC. :-)
> >
> > Begin forwarded message:
> >
> > From: <internet-drafts@ietf.org>
> > Subject: New Version Notification for draft-haynes-nfsv4-flex-
> filesv2-00.txt
> > Date: August 7, 2017 at 5:11:45 PM PDT
> > To: Thomas Haynes <thomas.haynes@primarydata.com>
> >
> >
> > A new version of I-D, draft-haynes-nfsv4-flex-filesv2-00.txt
> > has been successfully submitted by Thomas Haynes and posted to the
> > IETF repository.
> >
> > Name: draft-haynes-nfsv4-flex-filesv2
> > Revision: 00
> > Title: Parallel NFS (pNFS) Flexible File Layout v2
> > Document date: 2017-08-07
> > Group: Individual Submission
> > Pages: 11
> > URL:
> > https://www.ietf.org/internet-drafts/draft-haynes-nfsv4-
> flex-filesv2-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-haynes-nfsv4-flex-filesv2/
> > Htmlized:
> > https://tools.ietf.org/html/draft-haynes-nfsv4-flex-filesv2-00
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-flex-filesv2-00
> >
> >
> > Abstract:
> >   The Parallel Network File System (pNFS) allows a separation between
> >   the metadata (onto a metadata server) and data (onto a storage
> >   device) for a file.  The flexible file layout type is an extension to
> >   pNFS which allows the use of storage devices in a fashion such that
> >   they require only a quite limited degree of interaction with the
> >   metadata server, using already existing protocols.  This document
> >   describes two extensions to the flexible file layout type to allow
> >   for multiple stateids for tightly coupled NFSv4 models and an
> >   additional security mechanism for loosely coupled models.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>