Subject: [nfsv4] review of draft-ietf-nfsv4-multi-domain-fs-reqs-03

From: David Noveck <[email-masked]>
Date: Mon, 10 Aug 2015 15:12:45 -0400

*Overall Comments*

This document is in good shape and it fills an important gap.

Almost all of my issues/comments are basically editorial.

One possible exception is that I add material:

   - about the use of name services by clients.
   - discuss the the fact that stringified ID''s cannot be used in ACL's.

*General (i.e. multi-section) Issues*

There have previous statements that this document is standards-track
because it modifies some things specified in previous standards-track
documents.   Given that, should this be marked as updating some previous
RFC's?

I'll address specific uses, but I should note that text which mentions
machines "running" NFSv4 tend to be unclear as to what exactly is meant.

*Comments by Section*

*Abstract*

Suggest replacing the first sentence by

This document discusses issues relevant to the deployment of the NFSv4
protocols in situations allowing for the construction of an NFSv4 file
namespace supporting the use of multiple NFSv4 domains and utilizing
multi-domain capable file systems.

Suggest replacing the penultimate sentence by:

Also described are constraints on name resolution and security
services appropriate to the administration of such a system.

*Introduction*

As far as the first paragraph, I can only see how users and groups are part
of NFSv4 domains (e.g. user1@domain1, groupXYZ@domain2),  I don't see how
computers can be part of NFSv4 domains The following represents my
understanding:

An NFSv4 domain is defined as a set of users and groups named by a
particular domain using the NFSv4 name@domain syntax.  This includes
NFSv4.0 [RFC7530],  NFSv4.1 [RFC5661], and minor versions yet to be
published. Often, a computer which acts as an NFSv4 client and always
acts on behalf of users belonging to a particular NFSv4 domain is
thought of a part of that NFSv4 domain.  Similarly, a computer acting
as an NFSv4 server that is only aware of users within a particular
NFSv4 domain may be thought of as part of that NFSv4 domain.

Given how ungainly the phrase "multi NFSv4 domain" is, I would add a new
paragraph as follows at this point enabling us to get rid of uses of "multi
NFSv4 domain" from here on and deleting the corresponding definition in the
terminology section:

In this document, the term "multi-domain" always refers to multiple NFSv4
domains.

Once you do that, you can replace any subsequent appearance of the phrase
"multi NFSv4 domain" by "multi-domain".  I won't note specific instances
below.

With regard to the third paragraph:

   - In the first sentence, suggest replacing "enterprise wide" by
   "enterprise-wide".
   - In the second sentence, suggest replacing "be they" by "whether they
   are".

Regarding the fourth paragraph

   - I have some doubts about the phrase "in the exporting of on-disk local
   identity representation".  Presumably the "exporting" of such identities is
   dealt with in the first half of this sentence.  Also the juxtaposition of
   "global identities (in the first clause) and "local identity" (here) seems
   not very clear.  Suggest the sentence to read something like the followings

Multi-domain deployments require support for global identities in name
services and security services, and file systems capable of the
on-disk representation
of identities belonging to multiple NFSv4 domains.

   - With regard to the second sentence, I'm thinking you're pulling too
   many punches here.  Is the problem with "many"  standalone deployments or
   all of them.  Is the problem that they don't provide full support, or
   adequate support,, or any support for multiple domains?  Suggest something
   like the following:

Typically, stand-alone NFSv4 domain deployments only provide support
for identities belonging to a single NFSv4 domain.

In the fifth paragraph, I'm wondering whether the word "administrative". I
don't think we mean to constrain how people might choose to administer
their deployments and the phrase "administrative constraints" suggests
otherwise. I'm suggesting something like the following:

This document describes administration-related constraints applying to
the deployment of the NFSv4 protocols in environments supporting  the
construction of an NFSv4 file system namespace supporting the use of
multiple NFSv4 domains and utilizing multi-domain capable file
systems.  Also described are constraints regarding the name resolution
and security services appropriate to such a deployment.  Such a
namespace is a suitable way to enable a Federated File System
supporting the use of multiple NFSv4 domains.

*Terminology*

Regarding the "Name Service" section, suggest the following changes:

   - would rewrite the first sentence as follows:

facilities that provides the mapping between {NFSv4 domain, group or
user name} and the appropriate local representation of identity.  Also
includes facilities providing mapping between a security principal and
local representation of identity.

   - Would rewrite the second sentence as follows:

Can be applied to global identities or principals from within local and
remote domains.

Regarding the "domain" section, suggest taking advantage of what is done by
doing the following:

   - Rewrite the lead paragraph as follows:

Domain: This term is used in multiple contexts where it has different
meanings. Definitions of "nfsv4 domain" and "multi-domain" have already
appeared above (in Section 1). Below we provide other specific definitions
used this document.

   - Delete the "NFSv4 domain" definition.
   - Delete the "multi-domain" definition.

Regarding the section "Local representation of identity", I have a few
issues:

   - It seems odd to describe SID's designed to be global as "Local"
   - The fact that the uid space and the gid space probably overlap needs
   to be mentioned somewhere.

I've come up with the following potential replacement:

A representation of a user or a group of users capable of being stored
persistently within a file system.  Typically such representations are
identical to the form in which users and groups are represented within
internal server API's. Examples are numeric id's such as a uidNumber
(UID) or gidNumber (GID) [RFC2307
<http://tools.ietf.org/html/rfc2307>], a Windows Security Identifier
(SID) [CIFS <http://tools.ietf.org/html/draft-ietf-nfsv4-multi-domain-fs-reqs-02#ref-CIFS>].
In some case the identifier space for user and groups overlap,
requiring the one using such an id to know a priori whether the
identifier is for a user or a group.  Note that the fact that SID's
are designed to be globally unique is compatible with our treatment of
them here as "local", since that uniqueness cannot be taken advantage
in an NFSv4 context.

Regarding the section "Multi-domain capable filesystem", I have the
following issues:

   - In the first sentence suggest replacing "both local and remote
   domains" with "multiple domains".
   - The second sentence needs to be clarified, but I'm not sure how.  Part
   of the problem is that I have not been able to find any
   definition/explanation of "SSID".

*New Section 3*

I'm proposing that we create a new section three which includes the
existing section 3 as a subsection. My suggested title for the new section
is "Identity Mapping".

NFSv4 Server Identity Mapping

I'm proposing that the current Section 3 become section 3.1.

In the fourth non-numbered paragraph, suggest replacing "multiple
NFSv4 domain file system" by "multi-domain environment".

In the final paragraph (numbered "2") , suggest making the following changes:

   - End the sentence  right after the existing close-parenthesis.
   - Add a new sentence as follows:

This mapping  is needed because NFSv4 messages use identity
representations of the form name @ domain which normally differs from
the server's local representation of identity.

New Section 3.2

The proposed title for this section is  "NFSv4 Client Identity Mapping"

I think the following material should appear in this section.

There are a number of situations requiring the client to have access
to identity mapping services:

   - A client setting the owner or group attribute will often need
access to identity mapping services.  This is because API's within the
client will specify the identity in a local form (e.g UNIX using a
uid/gid) so that when stringified id's cannot be used, the id must be
converted to a global form.
   - A client obtaining value for the owner or group attributes will
similarly need access to identity mapping services.  This is because
the client API will need these attributes in a a local form, as above.
As a result name services need to be available to convert the global
identity to a local form.

Note that each of these situations arises because client-side API's
require a particular local identity representation.  The need for
mapping services would not arise if the clients could use the global
representation of identity directly.

Stand-alone NFSv4 Domain Deployment Examples

With regard to he first sentence of the last paragraph, I'm wondering
whether "32-bit" still needs to be there.  The reason is that
stringified ID's are limited to 32-bit unsigned quantities.

AUTH_SYS with Stringified UID/GID

I propose adding the following as a new second paragraph:

Note that stringified identifiers cannot be validly used to set or
interrogate ACL's.  This is because a given numeric value may
represent the user with that value as a uid and the group with that
value as a gid. As there is no way to resolve this ambiguity, aces
cannot contain stringified id's to represent a particular identity.
This is opposed to identities of the form name@domain, for which the
mapping process will determine both the associated local ID and
indicate whether a user or group is being designated.

AUTH_SYS with name@domain

In the first sentence:

   - Suggest replacing "The next level of complexity is to not use" by
"Another possibility is express identity using the form 'name@domain',
rather than using"
   - Suggest replacing "listing" by "setting and listing".

*RPCSEC_GSS with name@domain*

In the second paragraph Suggest replacing "the complexity" by "use".

*Name@domain Constraints*

In the first sentence, suggest replacing "on wire" by "on-the-wire".

*NFSv4 Domain and Name service and Domain Aware File Systems*

In the title suggest replacing "Domain Aware" by "Domain-aware".

Suggest rewriting the first paragraph as follows:

As noted above in Section 5.1, each name@domain is unique across the
multi-domain namespace. and maps, on each NFSv4 server to the local
representation of identity used by that server.  Typically, this
reprsentation consists of an indication of the particular domain
combined with the uid/gid corresponding to the name component.  To
support such an arrangement, each NFSv4 domain needs to have a single
name resolution service capable of converting the names defined within
the domain to the corresponding uid/gid.

As far as I can see, the second paragraph refers to exactly the sort
of practices that the third paragraph says are beyond the scope of
this document.  Perhaps it should be removed.

In the first sentence of the third paragraph, suggest making the
following changes:

   - Replacing "domain aware" by "domain-aware".
   - Replacing "can not" by "cannot"

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 13 Aug 2015 21:10:37 +0000

> On Aug 10, 2015, at 3:12 PM, David Noveck <[email-masked]> wrote:
> 
> Overall Comments
> 

Good - and thanks for the review.

> 	• about the use of name services by clients.
> 	• discuss the the fact that stringified ID''s cannot be used in ACL's.
> 
> General (i.e. multi-section) Issues
> 
> There have previous statements that this document is standards-track because it modifies some things specified in previous standards-track documents.   Given that, should this be marked as updating some previous RFC’s?

Maybe - these modifications only apply to the multi-domain case.

> 
> I'll address specific uses, but I should note that text which mentions machines "running" NFSv4 tend to be unclear as to what exactly is meant.

OK - thus the rewrite of the Abstract and intro :)

> Comments by Section
> Abstract
> This document discusses issues relevant to the deployment of the NFSv4 protocols in situations allowing for the construction of an NFSv4 file namespace supporting the use of multiple NFSv4 domains and utilizing multi-domain capable file systems. 

OK - I like it.

> Also described are constraints on name resolution and security services appropriate to the administration of such a system.

Yes, that is better. OK.

> Introduction
> 
> As far as the first paragraph, I can only see how users and groups are part of NFSv4 domains (e.g. user1@domain1, groupXYZ@domain2),  I don't see how computers can be part of NFSv4 domain. The following represents my understanding:
> 
> An NFSv4 domain is defined as a set of users and groups named by a particular domain using the NFSv4 name@domain syntax.  This includes NFSv4.0 [RFC7530],  NFSv4.1 [RFC5661], and minor versions yet to be published. Often, a computer which acts as an NFSv4 client and always acts on behalf of users belonging to a particular NFSv4 domain is thought of a part of that NFSv4 domain.  Similarly, a computer acting as an NFSv4 server that is only aware of users within a particular NFSv4 domain may be thought of as part of that NFSv4 domain.

I can incorporate that language into the Intro.

> Given how ungainly the phrase "multi NFSv4 domain" is, I would add a new paragraph as follows at this point enabling us to get rid of uses of "multi NFSv4 domain" from here on and deleting the corresponding definition in the terminology section:
> 
> In this document, the term "multi-domain" always refers to multiple NFSv4 domains.
> 
> Once you do that, you can replace any subsequent appearance of the phrase "multi NFSv4 domain" by "multi-domain".  I won't note specific instances below.

Good idea.

> 	• In the first sentence, suggest replacing "enterprise wide" by "enterprise-wide".
> 	• In the second sentence, suggest replacing "be they" by "whether they are”.

OK

> 	• I have some doubts about the phrase "in the exporting of on-disk local identity representation".  Presumably the "exporting" of such identities is dealt with in the first half of this sentence.  Also the juxtaposition of "global identities (in the first clause) and "local identity" (here) seems not very clear.  Suggest the sentence to read something like the followings

> Multi-domain deployments require support for global identities in name services and security services, and file systems capable of the on-disk representation of identities belonging to multiple NFSv4 domains.

That is more clear. OK.

> 	• With regard to the second sentence, I'm thinking you're pulling too many punches here.  

> Is the problem with "many"  standalone deployments or all of them.  

“many” as some standalone deployments already meet the multi-domain requirements.

> Is the problem that they don't provide full support, or adequate support,, or any support for multiple domains?  

I see: exactly what does full support mean ….

> Suggest something like the following:

> Typically, stand-alone NFSv4 domain deployments only provide support for identities belonging to a single NFSv4 domain.

OK - that is better “NFSv4-ease” ;)

> In the fifth paragraph, I'm wondering whether the word "administrative".   I don't think we mean to constrain how people might choose to administer their deployments and the phrase "administrative constraints" suggests otherwise.  I'm suggesting something like the following:
> 
> This document describes administration-related constraints applying to the deployment of the NFSv4 protocols in environments supporting  the construction of an NFSv4 file system namespace supporting the use of multiple NFSv4 domains and utilizing multi-domain capable file systems.  Also described are constraints regarding the name resolution and security services appropriate to such a deployment.  Such a namespace is a suitable way to enable a Federated File System supporting the use of multiple NFSv4 domains.

OK

> Terminology
> 	• would rewrite the first sentence as follows:
> facilities that provides the mapping between {NFSv4 domain, group or user name} and the appropriate local representation of identity.  Also includes facilities providing mapping between a security principal and local representation of identity.
> 	• Would rewrite the second sentence as follows:
> Can be applied to global identities or principals from within local and remote domains. 
> 
> Regarding the "domain" section, suggest taking advantage of what is done by doing the following:
> 	• Rewrite the lead paragraph as follows:
> Domain: This term is used in multiple contexts where it has different meanings. Definitions of "nfsv4 domain" and "multi-domain" have already appeared above (in Section 1). Below we provide other specific definitions used this document.
> 	• Delete the "NFSv4 domain" definition.
> 	• Delete the "multi-domain" definition.
> Regarding the section "Local representation of identity", I have a few issues:
> 	• It seems odd to describe SID's designed to be global as "Local"
> 	• The fact that the uid space and the gid space probably overlap needs to be mentioned somewhere.
> 
> A representation of a user or a group of users capable of being stored persistently within a file system.  Typically such representations are identical to the form in which users and groups are represented within internal server API's. Examples are numeric id's such as a uidNumber (UID) or gidNumber (GID) [RFC2307], a Windows Security Identifier (SID) [CIFS].  In some case the identifier space for user and groups overlap, requiring the one using such an id to know a priori whether the identifier is for a user or a group.  Note that the fact that SID's are designed to be globally unique is compatible with our treatment of them here as "local", since that uniqueness cannot be taken advantage in an NFSv4 context.
> 
> Regarding the section "Multi-domain capable filesystem", I have the following issues:
> 	• In the first sentence suggest replacing "both local and remote domains" with "multiple domains".
> 	• The second sentence needs to be clarified, but I'm not sure how.  Part of the problem is that I have not been able to find any definition/explanation of "SSID".
> 
> New Section 3
> 
> I'm proposing that we create a new section three which includes the existing section 3 as a subsection.  My suggested title for the new section is "Identity Mapping".
> 
> In the fourth non-numbered paragraph, suggest replacing "multiple NFSv4 domain file system" by "multi-domain environment".
> 
> 	• End the sentence  right after the existing close-parenthesis.
> 	• Add a new sentence as follows:
> This mapping  is needed because NFSv4 messages use identity representations of the form name @ domain which normally differs from the server's local representation of identity.
> 
> 
> New Section 3.2
> 

> There are a number of situations requiring the client to have access to identity mapping services:
> 	• A client setting the owner or group attribute will often need access to identity mapping services.  This is because API's within the client will specify the identity in a local form (e.g UNIX using a uid/gid) so that when stringified id's cannot be used, the id must be converted to a global form.
> 	• A client obtaining value for the owner or group attributes will similarly need access to identity mapping services.  This is because the client API will need these attributes in a a local form, as above.  As a result name services need to be available to convert the global identity to a local form.
> Note that each of these situations arises because client-side API's require a particular local identity representation.  The need for mapping services would not arise if the clients could use the global representation of identity directly.

> With regard to he first sentence of the last paragraph, I'm wondering whether "32-bit" still needs to be there.  The reason is that stringified ID's are limited to 32-bit unsigned quantities.
> 
> Note that stringified identifiers cannot be validly used to set or interrogate ACL's.  This is because a given numeric value may represent the user with that value as a uid and the group with that value as a gid. As there is no way to resolve this ambiguity, aces cannot contain stringified id's to represent a particular identity.  This is opposed to identities of the form name@domain, for which the mapping process will determine both the associated local ID and indicate whether a user or group is being designated.
> 
> 	• Suggest replacing "The next level of complexity is to not use" by "Another possibility is express identity using the form 'name@domain', rather than using"
> 	• Suggest replacing "listing" by "setting and listing".
> RPCSEC_GSS with name@domain
> 
> Name@domain Constraints
> NFSv4 Domain and Name service and Domain Aware File Systems
> 
> As noted above in Section 5.1, each name@domain is unique across the multi-domain namespace. and maps, on each NFSv4 server to the local representation of identity used by that server.  Typically, this reprsentation consists of an indication of the particular domain combined with the uid/gid corresponding to the name component.  To support such an arrangement, each NFSv4 domain needs to have a single name resolution service capable of converting the names defined within the domain to the corresponding uid/gid.
> 
> As far as I can see, the second paragraph refers to exactly the sort of practices that the third paragraph says are beyond the scope of this document.

That is not the way I see it. The 2nd paragraph give the reason that multi-domain aware file systems are needed - e.g to be able to represent a user from a remote NFSv4 domain on disk.

The third paragraph notes that POSIX UID/GID file systems are not domain aware, and can not “easily” do what paragraph 2 states, since there is no on-disk domain component to a UID or GID.

What is beyond the scope of this document is how one manages to turn a non-domain aware POSIX filesystem into a domain aware one WRT NFSV4.

>  Perhaps it should be removed.

Since NFS exporting of POSIX UID/GID file systems is typical, I thought it to be a good idea to note it. I’ll consider removing it, or at least changing it with your comments in mind.

> 
> In the first sentence of the third paragraph, suggest making the following changes:
> 	• Replacing "domain aware" by "domain-aware".
> 	• Replacing "can not" by “cannot"

Thanks again for the good suggestions

I’ve got many of these changes in a draft-04 - but I won’t put it out until tomorrrow

—>Andy