[nfsv4] Review of draft-ietf-nfsv4-flex-files-13 (part one of two)
David Noveck <davenoveck@gmail.com> Tue, 22 August 2017 11:45 UTC
Return-Path: <davenoveck@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 0AAC8132983 for <nfsv4@ietfa.amsl.com>; Tue, 22 Aug 2017 04:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdJozHiDC5_L for <nfsv4@ietfa.amsl.com>; Tue, 22 Aug 2017 04:45:19 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 91F151326F4 for <nfsv4@ietf.org>; Tue, 22 Aug 2017 04:45:19 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id x187so5064250ite.1 for <nfsv4@ietf.org>; Tue, 22 Aug 2017 04:45:19 -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:cc; bh=tyF9AIIycjpfC+1mNUnHwPQZ1J2DfN7qQqvTNCSnXws=; b=cUn1ylAUOz8O5p+RsIK4YMjQhHBFtHoMu+BsRYFhh+Ugo/m1F9jMQLWKBc7NVA1Hjn 8+RGhYjekqryDSX8KHgnewSbZUMXB7/otrOzQZcdQZsp4X9f1+IIOEaeS2vNzXQzrpVc 8+p1GPxEalwnreURWB5kgDKKlPzAmoO3720Zng5AVLhuKFZ9uY0TVFZ0wWJWpcipS93I 3ePGP7AHp3crndyK2O4QrycI5J2w9S2f9T7F7g4job62vJLgIjdFE8fQZI6pIQoMSeJ6 /T3vuQBZUfTxz7LhEU290IRIe7zdK8ZZrDfSnkqzjKUo5a/WM0AxWCy42NZu4ajmWkmL 6lMw==
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:cc; bh=tyF9AIIycjpfC+1mNUnHwPQZ1J2DfN7qQqvTNCSnXws=; b=ubRB3QwvQRlASYcVtSMzrXda1f45131NusqiCP7Bn+1SLsuBOBAoSfpO0+X93LF0ir rC0qVEdrSI+0LKHfX40D0kk/BfVoj9nIff9cqvgo5xgLjgKYtCaMTVnhfU8UjWgepUzu smyKUKdgsyEsRr9RdYF/J20kDWfvqbgZ4mR+FxQ9w39rp416ge5zRftJ6F6i0rah96EJ XYN7HgX1sJGoSM7sjqN0NcVQUAR/pPeOOdmRhzpMlnk2/0n9MrSUZYMOvJd8kCNtJK2W hVVvqYm76fni57IEoS7mfuJxrUS0d56M5dUIKqSMPCxcaQ4Nzpvk9Eicrlr6CWki+jJz C6Ew==
X-Gm-Message-State: AHYfb5hKtg8avS9jtoqscnPyswr3jo7Lm/FErg10arJLnYp6oof97gHq uhRROjIVkBTgEq1yvMfauQkREDxF6g==
X-Received: by 10.36.16.75 with SMTP id 72mr210085ity.117.1503402318568; Tue, 22 Aug 2017 04:45:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.142.72 with HTTP; Tue, 22 Aug 2017 04:45:18 -0700 (PDT)
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 22 Aug 2017 07:45:18 -0400
Message-ID: <CADaq8jfHL4o=f6FC-pTbck=B-=4x_PRJ8tPht2u5C-hf4tVt_Q@mail.gmail.com>
To: Tom Haynes <loghyr@primarydata.com>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143849c2723830557562153"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/8MYQqiSZDAswBK_YmuHwNwxbfGQ>
Subject: [nfsv4] Review of draft-ietf-nfsv4-flex-files-13 (part one of two)
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, 22 Aug 2017 11:45:23 -0000
*Review Structure* This review hs been split up into multiple emails to avoid running afoul of mailing list size restrictions. This is the first section. *Current Section* This section contains all the general (non-section-specific) comments and the first section of the detailed per-section comments. *Next Section* Contains the bulk of the per-section comments, including those related to security considerations. *General Comments* *Background of Review* There are two significant recent changes that need to be addressed: - The major revision of security for loose coupling that was made in -13. - The need to co-ordinate this document with layout-types, which is also in last call. In addition, I feel there is a need for a review of other sections of the document because I never had a chance to review -12 and because the document has made enough progress that it is clearly headed to the IESG soon. Because of that, I am shifting the focus of the review to look more closely at the kind of issues that might arise during IESG review. *Overall Evaluation* In terms of technical content, this document is ready to go forward. The protocol is sound and it is explained in a manner that can be understood by the members of the working group who are familiar with pNFS. There are some issues of presentation that need to be addressed before the document goes forward: - There are still some typo-level issues that need to be addressed. - In some cases, the presentation, while understandable to those with the appropriate background, may be confusing to naive readers, who the IESG generally wants to accommodate. It appears that all of these issues can be addressed by changes of limited scope, allowing a -14 to go forward without a new last call. *Comments by Section (until Section 2.1)* *Abstract* In the last sentence, "Client side" needs to be replaced by "Client-side". *1. Introduction* There are a number of problems with the first sentence of the second paragraph: - The introductory clause seems to be coming out of the blue, given that may readers, including the IESG members, may not have the necessary background to understand it . One possibility is to add a reference to section 13 of RFC5661, but I don't think that fully solves the problem. - The reference to "a back-end control protocol" would be similarly confusing, especially since the definition of "control protocol" although not "back-end control protocol" appears later, in Section 1.1. - The use of the "MAY" in the second clause is confusing. It is true that when the storage devices are NFSv4.1+, this is. formally speaking, an option, most implementers will for various reasons have no such choice. The following suggested replacement is one way to address these issues: When the storage devices support the NFSv4.1 protocol, it possible for implementations to provide support for a global state model equivalent to that described in Section 13 of [RFC5661]. See Section 2.3.2 for further description. Any such implementation would a communiation mechanism between the MDS and the data storage devices,contituting a control protocol as defined below. With regard to the second sentece of the second paragraph: - If this is important enough to raise in the introduction, you cannot simply say "not my job. Goodbye." If it is not your job, which it isn't, you should give some indication of whose job it might be. - If the phrase "out of scope" is to be retained, it should be hyphenated. In any case, that phrase is jargon-ish and unhelpful. I'm going to suggest the following as a posible replacement: The definition of such a mechanism will not be provided in this document. An implementation is free to define its own mechanism. Alternatively, a standard protocol could be defined, allowing new implementations the option of choosing either it or an implementation-specific mechanism. *1.1. Definitions* I'm going to start by discussing the role of defnitions. In connection with a review of layout-types-05, Chuck suggested some elaboration of certain terms. While I agree with Tom's response that a "comprehensive" defnintion is not, in general, required, there were certain things about the specifics of Tom's response that were concerning and need to be addressed here. Tom seemed to say that he had his own definition of "definition". I'll be using the following that I got using Google as the standard I will use in my review: *a statement of the exact meaning of a word, especially in a dictionary* I don't think the IESG will be OK with anyone having a significantly different approach and there is no point in presenting the document to the IESG, if one thinks one can somehow get a waiver from the IESG's expectations, which are generally to expect that terms be clearly defined before use. These seem to be different from Tom's expectations, which treat these terms as well-understood and anticipates that they only be used later as a reminder of the gist of a term already used. The good news here is that the problems with the definitions in this section are quite limited and can be easily addressed. Another general issue that needs to be addressed up-front concerns the relationship between these definitions and those in layout-types-06. Where the same term is defined in both documents, the definitions should agree and I'll be noting cases where they do not. In the definition of "control protocol', the term "data access protocol" is used, although it is not defined either here of in layout-types-06 . Suggest using "storage protocol", which is defined in layout-types, instead. In the definition of "client-side mirroring", suggest replacing "is when" by "is a feature in which". The definition for the term "data file" matches that for the term "(file) data" in layout-types-06. The cases of "metadata file" and "(file metadata" are similar. It would be best if the same terminology ere used in these related documents. Otherwise the differences should be mentioned. For the following definitions, it would be better (clearer) to use the definitions in layout-types-06: "fencing", "layout" (first paragraph only), "layout iomode", "layout stateid", "layout type", "loose coupling", "metadata sever (MDS)". In the case of "tight coupling", the two documents need to be in alignment, but the phrase "is when" needs to be replaced by "is an arrangement in which". Suggest addIng a defnition of "storage protocol" matching that in layout-types-06. *2. Coupling of Storage Devices* Given that function of the section is to provide alternative coupling models I'd like to suggest: - That the section title be changed to something like: "Coupling Models Supported". - That the first sentence needs to be revised to make it clearer exactly who is choosing the coupling model. Suggest: A server implemetation may choose to implement either a loose or tight coupling model. With regard to the description of the two coupling models, while all of the statements are true, the text is not clear about what is necessary to provide these states of affairs and who is responsible for providing the necessary pre-requisites. For the tight coupling section, suggest the following replacement: To implement the tight coupling model, there needs to be a control protocol defined capable of managing security and LAYOUTCOMMITs, providing a global stateid model and related functions, all without imposing special requiremets on the client. For the loose coupling section, besides the same sort of lack of clarity, the following issues need to be adressed: - The statement that the control protcol "might be a version of NFS is confusing because it is impossible for the control protocol to be anything other than a version of NFS. - It is unclear who the statement that the semanntics "MUST be defined" is directed to. Normally such an RFC2119 term is directed to a client or servrer implementation. In this case, it is confusingly directed to the rest of this document. For the loose coupling section suggest that the following replacement be used: When implementing the loose coupling model, the only control protocol will be a version of NFS, with no ability to provide a global stateid model or to prevent clients from using layouts inappropriately. To enable client use in that environment, this document will specify how security, state, and locking are to be managed.
- [nfsv4] Review of draft-ietf-nfsv4-flex-files-13 … David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-flex-files… Thomas Haynes