Subject: [nfsv4] draft-adamson-nfsv4-multi-domain-federated-fs-reqs-03 review comments

From: Chuck Lever <[email-masked]>
Date: Thu, 7 Nov 2013 10:35:20 -0800

Hi-

I'm not qualified to comment on specific security issues discussed by this document, but I still saw some mechanical issues (language and specification) that I'll pass along, for what they're worth.

The abstract describes "constraints … to fully enable" I thought this was a best current practices document.  Shouldn't the abstract say that?  If this document is Informative, should you consider changing the Intended Status?

You could drop the first paragraph of the Introduction section, as it is the same as the Abstract.

You might consider updating RFC3530 references to RFC3530bis.  The reference on page 8 could even be updated to "Section 5.9 of RFC 5661", for example.

In the third paragraph of Section 1, which finishes "into a common multi-domain name space" -- I've been using "filename space" in cases like this.  "name space" is another one of those overloaded terms like "domain."  After more review, it looks like you often use "name space" as a synonym for "domain", and perhaps that needs clarification.

Next paragraph: what is a "uniform file server based namespace" ?  That term is encountered a few times in this document, but I don't see a definition.

Next paragraph: I understand what you mean by "A local filesystem that uses a local ID form that can represent identities from both local and remote domains."  But readers who did not attend the multi-domain presentation Tuesday might not understand what is meant by "local" -- and you are using that term in at least two different contexts in this sentence.  You could say "physical filesystem shared by a fileserver" (or something more concise) for the first one.   Is "local and remote" used in the same context as "local ID form" ?

Next paragraph: "uses the FedFS" is probably better said "uses FedFS".

Same paragraph: "join multiple NFSv4 domains each consisting of NFSv4 servers that export multi-domain capable filesystems, into a uniform NFSv4 server-based name space capable of spanning multiple enterprises."

Your terminology section says an NFSv4 domain is "a set of users, groups and computers running NFSv4 protocols running a single name service, and identified by a unique NFSv4 domain name."  How do you join "a set of users and groups" into a "uniform NFSv4 server-based name space?"  Are you not referring to a file namespace here?  Or are you referring both the file name space and the name space of identities?

Given the extensive use of the terms "local" and "remote" you might consider adding definitions to your 
Terminology section for "local" "remote" and "NFSv4 home domain".

First paragraph of Section 3 should be unpacked and expanded for clarity.  At least split it into two or three paragraphs.

Section 4.2: An AUTH_SYS credential _does_ contain a DNS domain name, but it's the hostname where the credential was created.  The language here could be made more precise and take into account that there is a domain name involved, just not a usable one?

Section 5: "A mechanism specific GSS-API authorization payload containing credential authorization data described in the following section."  The payload is requested by whom, from whom?  There's a lot of passive tense going on in Section 5 (esp. the last paragraph in the section), it would help to untangle some of it.

Section 6: Just a nit, instead of "in the ACE who field" it might be better to say "in an ACE "who" field".  The previous reference to this field is in Section 4.1:  "of the "who" field of an NFSv4 access control entry (ACE) for users and groups." -- it uses "an" and quotes around "who".

The summary of best practices presented during Tuesday's meeting would be a very nice addition to this document as, say, an Executive Summary.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com