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

Olga Kornievskaia <aglo@citi.umich.edu> Tue, 08 August 2017 15:56 UTC

Return-Path: <olga.kornievskaia@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 6E2BB132195 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 08:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 JoNOnf2mscSj for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 08:56:53 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 74A1D1325CE for <nfsv4@ietf.org>; Tue, 8 Aug 2017 08:56:53 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id a18so22229980qta.0 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 08:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=XJeih6iVsZO4dCRGnExOtT7kxraOQxNPJ2ifFtzS5MI=; b=hwdrf7AVY1YoQQp43WsZOIYv7VkKlB3hMx7uPkTkZAyWEAgBb2zuXpxynrKsOtgdSH f+JvrCdg/TOObICeoQbWlAMLL0DarV4MF2VChvhzTlsqk1jDuYzTKgLbnqT4+7y8CmpM LbfaIwnzwZHshKt0aRWnfKUmCpAptqm6ZW8+XWENJd8aELY2dRhJ4yKFx65355a8oX+s CuedSF2JdUTon1sCx4z51dSvo6vFLjV2IL28DPmg1aqszzBrdDd4d4gonBJDtP/jPM7e hPW6UQOEnvFxA0CIlnHdBs0JqQdQxIUl1mLNwQdgnj7wCKd7aB53SbFBcf03QdQhxHX4 k6Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=XJeih6iVsZO4dCRGnExOtT7kxraOQxNPJ2ifFtzS5MI=; b=cINbRRMF3SxUAHH4Q8DvhDP1uxU/Fl/1qPUsWlcaVDVwyQhq6aY6uamn/kRjts9JGw FEHlYsM5AFGaI+KZTLK1lvdgPVtrK/34S7ah3TD6MdHZnO96WWvyghMl6AcFYEa6B9TR UF5O3yHPtlr/nEJEKAdZfP3QXRh9m7qTeH6W9CLVmiaG1Ki0ZzzqFB+YsMLDk+JH5Gx7 9M2/g8I/r9pLBe1SDFccHh6iDZ7/lKVBQsUA09MO6DhNzL5ddL3mrueHTuXnKnrcRvje VSqGhoBra+tmQSXLxJLgvjFJhTZYb/W/BzGo/hoIjvSF27Q4sp8d2XqTc1+zPAzgXZmc qJRg==
X-Gm-Message-State: AHYfb5gHOfSefG9fnkQk28n1E1XtbZceZcBxrdrosPoCnaq4WD647IF+ D2yYQMG4vgVywkp3o95onYyZljqJaQ==
X-Received: by 10.237.60.122 with SMTP id u55mr5995775qte.169.1502207812456; Tue, 08 Aug 2017 08:56:52 -0700 (PDT)
MIME-Version: 1.0
Sender: olga.kornievskaia@gmail.com
Received: by 10.12.186.148 with HTTP; Tue, 8 Aug 2017 08:56:51 -0700 (PDT)
In-Reply-To: <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com>
References: <150215110527.12392.18161698955589691126.idtracker@ietfa.amsl.com> <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com>
From: Olga Kornievskaia <aglo@citi.umich.edu>
Date: Tue, 8 Aug 2017 11:56:51 -0400
X-Google-Sender-Auth: nn8mLU-4flHV2IogvUQWdZIb68E
Message-ID: <CAN-5tyETNMCPVC5wJ-_77vM5+hVB+-uasd37kn+M=hoCeK6P7w@mail.gmail.com>
To: Thomas Haynes <loghyr@primarydata.com>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/HuW2HagHtcEiMfw9_fVXy7-_o3Q>
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 15:56:55 -0000

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
>