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

From: Brian Reitz <[email-masked]>
Date: Wed, 23 Jul 2014 15:00:01 -0400

1)  In section 4.1:

      The name portion of name@domain MUST be unique within the
      specified NFSv4 domain.

Is this really a unique/new requirement of multi-domain FedFS?  Seems like this really is a requirement in 3530 but perhaps not stated as succinctly in that document?

Brian

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 24 Jul 2014 14:57:23 +0000

> Is this really a unique/new requirement of multi-domain FedFS?  Seems like this really is a requirement in 3530 but perhaps not stated as succinctly in that document?

Thanks for the review Brian

I’ll clarify that section.

—>Andy
> 
> 
> Brian
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Tom Haynes <[email-masked]>
Date: Thu, 31 Jul 2014 17:28:26 -0400

>    This document describes constraints to the NFSv4.0 and NFSv4.1
> 

Need to define NFS here (first use in abstract and in body).

>    1.  NFSv4 Domain, Pseudo file system and referrals: The NFSv4.0
> 

“,” after system.

>          entity.  E.g. a Kerberos Realm.  While a typical configuration
> 

‘,’ after either “e.g.” or “i.e.”.

>          NFSv4 domain: a set of users, groups and computers running
> 
‘,’ after ‘groups’

I wish this:

>          NFSv4 domain: a set of users, groups and computers running
>          NFSv4 protocols running a single name service, and identified
>          by a unique NFSv4 domain name.  See [RFC5661] Section 5.9
>          "Interpreting owner and owner_group".  An NFSv4 domain can
>          include multiple DNS domains and multiple security realms but
>          only one name service.
> 
>          Multi-domain: In this document this always refers to multiple
>          NFSv4 domains.
> 

came after the first paragraph in the Introduction. That section dives
right in as if the reader is aware of what the issues are. I’d like to see
right off the bat, something that says a representative issue is:

How do we tell if [email-masked] is the same as [email-masked]?

>    services.  In order to interoperate in a multi-domain NFSv4 FedFS
>    file system, NFSv4 servers must use such services in compatible ways.
> 

Is this a MUST?

>       canonical name@domain, and it must be possible to return the
> 

MUST?

>    user's authorization identities using small integers, uidNumber and
>    gidNumber [RFC2307], as user and group identity representations.
> 

‘,’ after uidNumber.

> AUTH_SYS
>    can not be used in an NFSv4 multi-domain federated file system.
> 

MUST?

> 5.  Resolving Multi-domain Authorization Information
> 

This section does not read as if it were requirements. Instead, it is a collection of best practices.

> 6.  Setting and Retrieving NFSv4 Multi-domain ACLs
> 

While a collection of requirements (with too many “must”s and not enough “MUST”s), I don’t
see where the thrust of this section is going?

Are you listing requirements or how satisfying the requirements leads to solving the second mapping of Section 3?