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

Tom Haynes <loghyr@gmail.com> Wed, 24 January 2018 22:32 UTC

Return-Path: <loghyr@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 C444212AF6E; Wed, 24 Jan 2018 14:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE9QJwnKdleZ; Wed, 24 Jan 2018 14:32:26 -0800 (PST)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 9BD9F1270FC; Wed, 24 Jan 2018 14:32:26 -0800 (PST)
Received: by mail-pf0-x243.google.com with SMTP id y26so4255425pfi.10; Wed, 24 Jan 2018 14:32:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CH90p2U05CGKNrBQ0AD3uf10TzphqSRcWeOBz8WD1tM=; b=nrYj59yxGbflILOK3zEBG6MdV9y0ztFqxMbfTRX1RcgTFxf5o2QhRE23fvkbGpS7xS L3dePQZJ2ic2cUhaFiOUhumHIsmmyj8ZT7W2Jv37xETjaJQqrD+WuUxuqheBainPQedT MtncEwmVFIdKGOyO2COYFA2SQWJlybz+SbQZMKuhcTEi7jdSCZ57bbLwlGg1vR1CgwdV 4XiFUsabIWfT0yOu3CtjXT3pC5X7any07WMTEXwE35VySKvC9P6P0KYNnWctHqpzd/Z7 cOrh2C97wIugqnSwGr2RsG49m6YgmE7vb3gif8UnkfOMqS+WPZkJtEhPAH7ueB+LUbXv t2rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CH90p2U05CGKNrBQ0AD3uf10TzphqSRcWeOBz8WD1tM=; b=FJjg8fpb4h5TnaAV8tdU4BGt5XI6Xy46+PbXlmoTviQbkBj3w51a0nIXs2dbJO7kLq rCbpxNwEkVxt1PW1kskfsbLfPT6bcTzlSDPjKOnRZWR4ayGo5VHrLAzdg6Zb9dVdeP/q cqtrw1O/dnehP7u7Sb1YHkcQsDfaHntoxIFMgdt4sfyAU7IaO6z4LIFQj0CGd8KjrtRD hBQtM1FrFKWBNK6hViDB2Tazuefrt0aIoHn8vKG627t1Fz1gnlEf/emPVMUemodxipwx 08C0OcQ3iX+J5dMJjGXzeeLHpVb/YCTCeeN24k1ygjaSwnFmcOvg4/c6vxNgWyVq8bcz k0Mg==
X-Gm-Message-State: AKwxytfhGyIZlp6kTs04dAmj8EyJGh5ffcMmx1cHdJS08+hkfNigRY1T QVXkKfKN+AvMs7fW75aa8XM=
X-Google-Smtp-Source: AH8x224IvyxtY3clsRixwhzIUnaOgpkOANfwZXzQopuSwFsRsSaoa7LU2oH+HSTRc1V96/PywBLdFg==
X-Received: by 2002:a17:902:68ca:: with SMTP id x10-v6mr9122910plm.367.1516833146155; Wed, 24 Jan 2018 14:32:26 -0800 (PST)
Received: from kinslayer.corp.primarydata.com (63-157-6-18.dia.static.qwest.net. [63.157.6.18]) by smtp.gmail.com with ESMTPSA id k7sm954003pgo.31.2018.01.24.14.32.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 14:32:25 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Tom Haynes <loghyr@gmail.com>
In-Reply-To: <151683050192.22597.10931170494891133045.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 14:32:24 -0800
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-flex-files@ietf.org, nfsv4@ietf.org, nfsv4-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9FD918F5-D08C-45FC-B6BB-30CBB3D4EC51@gmail.com>
References: <151683050192.22597.10931170494891133045.idtracker@ietfa.amsl.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/guz1JVAEOa7bGwrsfN6ql3blXaY>
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:32:29 -0000


> 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.

> 
> ----------------------------------------------------------------------
> 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.



> 
> - 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.



> - 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