Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 24 January 2018 22:34 UTC

Return-Path: <ekr@rtfm.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 0ACE512D7EA for <nfsv4@ietfa.amsl.com>; Wed, 24 Jan 2018 14:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 bNi-r5M1o3jh for <nfsv4@ietfa.amsl.com>; Wed, 24 Jan 2018 14:34:55 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 DCB4212D7E6 for <nfsv4@ietf.org>; Wed, 24 Jan 2018 14:34:54 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id m84so2127095ywd.5 for <nfsv4@ietf.org>; Wed, 24 Jan 2018 14:34:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Fya+iwDaXGWyWPW+FefH37LsYL9DhLO1btxloH2MzY=; b=qrPQMEBjkQEalny0OUCef3bC0VWM0RGVEL5uebIa9e+76vSN9cdtqdIQo48H/AFeK9 eWnXBa0+hEkWTrnoU0DugrG+OszZTy6G7s3+RNY2nlFMjTHkWhnm+QO8bJP1kk8ecCIR RAcJ4dIUrp69pTUCCgkw1UtDZAC4aL7Uf+lvanQ6YpF2O3kx5jd6wSjjt/H6Ef4fkbJO UEDJ8qJbnmh0EtpvlPiPkGgF19085cv95HAYx3iFj5R+JpKuEa7UpZkNKkTAqO1K4MWT limTzC1JC+ubaOT71v6LdIAOFP7yfdeZ8iuussc/2CBMVXenPCH6nz6VJBVNUNWY1/Y9 JriQ==
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=+Fya+iwDaXGWyWPW+FefH37LsYL9DhLO1btxloH2MzY=; b=XamimvdmgN4AW16Vf+6bnTp1E7VUwA/sp5m76hyMkzh450jRj1dxtMHOPLuEYY5dBF zbBC3W+ayYai5TQv2QIdXVsZ3o9mC08oYFZfSiIJbCXjrhXEymUluqNBmkXEh0tKyeYe Ej2tG7tf/O0QOny2zGMpPlmH+0ZSIuhnrlko5ziVCwS082zsGOYwPxLyDSgDsm3TUzDr oIym/lPl5JX444WeASWIJFGpWFqiow9rV+eQzRmbRuCyA3DywJdA38YzCLKvepL+dPOn ufHQ/fjYFmjqVsu8wJHX2mTQEE8Fq0Lj3Q5tnuRlIfSonCAPVrpKx5clKdNlN5OHQnQy UOMw==
X-Gm-Message-State: AKwxytfChcO76uRlIOouhV3fvGY8IWRtRJXfWzJlwOu+9uQB7YXHmpbC ucFcLmsN8orov7qJnyxX1sqiwwZWeM9txSZUhIGh5A==
X-Google-Smtp-Source: AH8x226vJJx2QmZ8l9OJY63JzN7cGnXMjcxAlALFnpT9tY5v/+nkyKb1yTUgP9vh4Wjhyq7QstkRgerwPQPCKH0OvdM=
X-Received: by 10.129.152.138 with SMTP id p132mr6848706ywg.378.1516833293959; Wed, 24 Jan 2018 14:34:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.201 with HTTP; Wed, 24 Jan 2018 14:34:13 -0800 (PST)
In-Reply-To: <9FD918F5-D08C-45FC-B6BB-30CBB3D4EC51@gmail.com>
References: <151683050192.22597.10931170494891133045.idtracker@ietfa.amsl.com> <9FD918F5-D08C-45FC-B6BB-30CBB3D4EC51@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 24 Jan 2018 14:34:13 -0800
Message-ID: <CABcZeBPE5gV3KPpRpRxAtYRSSCZh8+3-fcf-1VsxF3AxmomnwQ@mail.gmail.com>
To: Tom Haynes <loghyr@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-flex-files@ietf.org, NFSv4 <nfsv4@ietf.org>, nfsv4-chairs@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0b8fe4ab9d1105638d45d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/7sq5AwwGB64CY-pzRyyouVyHGnc>
Subject: Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)
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: Wed, 24 Jan 2018 22:34:58 -0000

On Wed, Jan 24, 2018 at 2:32 PM, Tom Haynes <loghyr@gmail.com> wrote:

>
>
> > On Jan 24, 2018, at 1:48 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-nfsv4-flex-files-15: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I concur with Kathleen's discuss. To put a finer point on it, I think the
> > security considerations section here needs to really clearly state what
> the
> > security properties of this design are and how they differ from existing
> NFS.
> > That's not true yes.
>
>
> Could you please clarify the last sentence?
>
> That’s not true yet.
>
> Or:
>
> That’s not true, yes?
>
> If yet, then hopefully pushing the next version will suffice.
>

Sorry. "yet"


>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > - I'm a bit confused on whether the client can tell which model the
> server is using. I see:
> >
> >   An implementation can always be deployed as a loosely coupled model.
> >   There is however no way for a storage device to indicate over a NFS
> >   protocol that it can definitively participate in a tightly coupled
> >   model:
> >
> > But then there is a flag that you use to indicate you are tightly
> coupled. So I'm confused.
> >
>
> Ah, the flag ffdv_tightly_coupled is used between the metadata server
> and the client. Not between the storage device and the metadata server.
>

OK. Thanks.



> - I note that some of your PDUs have /// in front and some do not. E.g.,
> Section 5. Is that a bug.
> >
>
> No, the ones with a /// are to be extracted and the other ones refer to
> existing fragments
> from other IDs. So for example, the one in Section 5 is referring to
> RFC5662.
>

Makes sense.

-Ekr


>
>
> > - S 2.2.
> > " Note: it is recommended to implement common access control methods at"
> >
> > Do you want RECOMMENDED.
>
> Yes, this was pointed out by Brian Weis in the SecDir review.
>
>
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
>