Re: [nfsv4] my (partial) review of draft-ietf-nfsv4-multi-domain-fs-reqs-00

["Adamson, Andy" <[e-mail]>]

> On Dec 30, 2014, at 8:49 PM, David Noveck <[e-mail]> wrote:

Hi Dave

Thanks for your review.

> 
> I have gone through this document and think that it is good work that needs to be published, but there are  a few matters that the working group needs to discuss before a more extensive review is useful. So this review is limited to the first sixteen lines of the draft (intended-status, title, abstract).  Given that I've found so many things that I don't like in such a short space, my claim that I like this document might seem kind of strange.  However, my big issue is that most of this preliminary material doesn't really match the document that we have before us.  One or the other has to change and I would much prefer that the preliminary material be changed to match the document body rather than the reverse.
> 
> BTW, I have no issues with lines 1-2,  4-6,  and 9-11, so actually I have only eight lines to review :-)
> 
> So let's start at line 3, "intended status":
> 
> I don't see how this document can be standards-track.  It does not define a new feature and it is not marked as updating RFC5661 or RFC3530bis. 

True. But it does use the key words 'MUST’, ‘MUST NOT’, and ‘REQUIRED' that describe what must be in order to deploy a multiple NFSv4 domain file system namespace. AFAICS these key words are not part of an informational RFC. 

Neither RFC5661 nor RFC3530bis mention multiple NFSv4 domain deployments.

>  
> 
> I understand that this document is intended to satisfy the charter item that refers to "constraints and clarifications to the current NFSv4.0 and NFSv4.1 protocols"  but the current document isn't written to do that.

I disagree. 

>  It is true that the handling of users and groups in RFC5661 and RFC3530bis could use some clarification but I think that is best done in a document solely devoted to that cleanup.

I don’t think any clarification of handling users and groups is needed for stand-alone NFSv4 domains.

> My view regarding these matters:
> 	• Those sections are written assuming that if the client and server agree on how they handle name and domain everything will out, which is true, but it doesn't even begin to specify how clients and servers might come to agreement on that.

There are many ways to run stand-alone NFSv4 domains - three of which are described in draft-ietf-nfsv4-multi-domain-fs-reqs-00. "how clients and servers might come to agreement on that” is up to the administrator of the stand-alone domain. No problem there that I see.

> 	• Although the problems are most pressing in the case of multi-domain deployments,

Not ‘are more pressing’ - but ‘prevent deployment’ 

>  there are problems with single-domain deployments as well.


>  Consider the case in which the server is set up to do the appropriate uid-name mapping and the client isn't.  In this case, the client will receive name strings it is not prepared to decode.

Which is fine if the administrator wants it that way - the file system name space still works. There is no need to force a stand-alone NFSv4 deployment to do anything. All the pieces are there to be used in any way the administrator desires. As per all of NFS, plenty of rope …..

> 	• To really clarify this, you would have to be prepared to rewrite the relevant sections and I don't think anyone is up for that right now.

Not needed for stand-alone deployments. They already work.

> 	• if you did go down that path, you wold face the issue of required protocol extensions, if not to allow client and server to negotiate appropriate handling, at least to allow client and server to decide whether they match.  I don't think that could be done until we have an NFSv4 versioning RFC.
> 
> This document specifies how one might deploy/administer an NFSv4 namespace that involves multiple domains,

The document specifies what is REQUIRED in order to deploy/administer an NFSv4 namespace that involves multiple domains - not how one “might” deply/administer such a namespace. In other words, you can not run a multiple NFSv4 domian namespace without the “MUST, MUST_NOT and REQUIRED” portions of draft-ietf-nfsv4-multi-domain-fs-reqs-00.

> and is helpful in that regard.  It makes sense to me as an informational RFC.
> 
> Regarding charter issues, I think we need to focus on clearly saying what needs to be said and what we think people need to understand and leave it to Spencer, Beepy, and Martin to address any purported charter issues.
> 
> Now Let's go to line 7, the title:
> 
> A more descriptive title would be "Creation of Multi-domain NFSv4 Namespaces."  The words "Requirements for" could be prepended.  They don't add anything but they might be helpful in avoiding having to change the file name, which might lead to document management difficulties. 

I agree that the title can be changed to not include the word ‘requirements’.
>  
> 
> 
> We now move from the "Document Title Chainsaw Massacre" portion of our program to the sequel "Document Chainsaw Massacre II, the Abstract".
> 
> "This document describes constraints"
> 
> The heart of the problem as I see it is that it seems that the abstract was written to match the charter item, rather than summarizing  the document in question.

Actually, the other way around.

>  
> 
> It is not clear what "constraints to the protocols" means and we should clearly say what is done which is to specify constraints to the deployment/administration of the protocols.

I agree. “constraints to the protocols” should be changed to "constraints to the deployment/administration of the protocols”

> 
> Any such constraints are a minor part of the Document

No, the contraints is the whole point of the document. What can work in a stand-alone deployment in some cases will _not_ work in a multi domain deployment!

> and should not be mentioned so prominently (with more major item relegated to "as well as").
> 
> "to the NFSv4.0 and NFSv4.1 protocols"
> 
> This is really about all NFSv4 protocols.

OK.

> 
> "as well as the use of multi-domain capable file systems"
> 
> This is really the heart of the matter.  As I understand it, the line of demarcation between this document and the subsequent one is that this one is built assuming the use of multi-domain-capable file systems.

Correct. You can not deploy a read/write multiple NFSv4 domain namespace exporting non multi-domain capable file systems.

> 
> "name resolution services, and security services required"
> 
> Yup.
> 
> "to fully enable a multiple NFSv4 domain file system,"
> 
> Not clear what "fully enable" means.

The (not described) idea here is that a fully enabled multiple NFSv4 domain file system namespace is read/write capable for all users. This means that users from remote domains can create files, change ACLs etc on files on servers not in their NFSv4 domain, which requries said servers to export multi-domain capable file systems, have unique NFSv4 domain names, etc.

One could export a single-domain capable file system as read-only in a multiple NFSv4 domain file system name space: this is not “fully enabled”.


> 
> Also, we are supporting a namespace rather than a filesystem 
> 
> such as a multiple NFSv4 domain Federated File System.
> 
> call me "old-fashioned" but I have trouble parsing phrases like that which have lots of nouns used as adjectives.

:) 

> 
> So how about the following as a summary of the document:
> 
> This document describes an approach to the construction of a file system name space supporting use of the NFSv4 protocols and allowing use of multiple NFSv4 domains.  This approach involves use of multi-domain capable file systems.  Also described are name resolution services and security services as well as administrative constraints appropriate to such a system.  Such a namespace is a suitable way to enable a Federated File System supporting the use of multiple NFSv4 domains.
> 

Dave, could you please describe an "approach to deploying a multi-domain NFSv4 file system name space" that :

1) Doesn’t require exporting multi-domain capable file systems
2) Allows NFSv4 domain name collisions
3) Allows stringifiedUID/GID
4) Allows AUTH_SYS

or any combination of the above? In other words, this is not 'an approach'.

How about this for a document summary: 

This document describes administrative constraints to the deployment of the NFSv4 protocols required for the construction of an NFSv4 file system name space supporting the use of multiple NFSv4 domains. Also described are adminstrative constraints to name resolution and security services appropriate to such a system. Such a name space is a suitable way to enable a Federated File System supporting the use of multiple NFSv4 domains.

I have not come up with an appropriate title change - but I do agree “requirements’ should be removed from the title.

—>Andy

>