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

[David Noveck <[e-mail]>]

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.

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

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.
   - Although the problems are most pressing in the case of multi-domain
   deployments, 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.
   - 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.
   - 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, 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.


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.


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.


Any such constraints are a minor part of the Document 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.


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


"name resolution services, and security services required"


Yup.


"to fully enable a multiple NFSv4 domain file system,"


Not clear what "fully enable" means.


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.