Subject: [nfsv4] [FedFS] agenda item

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Wed, 2 Sep 2009 15:34:58 -0400

Hi Craig

Here is what I want to send to James and 'cc [email-masked]. What do you think?

-->Andy

---------------------------------

Hi James

Could you please add an agenda item for an upcoming FedFS conference
call?  Craig Everhart and I have been looking at this question, and we
think it deserves the groups attention.

Agenda Item:
Does there need to be some formal correspondence between the domain
name used to search for the NFSv4 DNS SRV record
(draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt) and the NFSv4
Domain name described in Section 3.3 of
draft-adamson-nfsv4-multi-domain-access-00?

I believe there should be a connection because
draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01 is *the* FedFS
draft  that joins NFSv4 file name spaces with different name
translation services and so all the issues brought up in
draft-adamson-nfsv4-multi-domain-access-00 need to be formally
addressed before the NFSv4 DNS SRV concept is used.

I suggest reading Section 3 (3.1,3.2, and 3.3) of

http://www.ietf.org/id/draft-adamson-nfsv4-multi-domain-access-00.txt

Here is an example. Note the over loading of the word 'domain' and how
each time it is used it is preceded by what kind of domain it is.

Suppose that servers A and B are both the authoritative target for the
NFSv4 SRV RRs for toaster.net.  Server A and server B are administered
by different parties.  They may do some arms-length mutual trust of
their authentication domains, but that still preserves how distinct
they are.  Administrators for servers A and B log in to separate
authentication domains, and they're each authorized to operate on the
file systems housed in servers A and B. Server A and Server B are in
different DNS domains, and they're not necessarily in the same
authentication domain as NFS uses for the /nfs4/toaster.net/. file
system either.

Here are some requirements. Given client C which uses Server A to
resolve /nfs4/toaster.net and client D which uses Server B to resolve
/nfs4/toaster.net:

1) Server A and Server B must serve the same referral file namespace.
This means that users on client C should see the same file system as
users on client D.

2) toaster.net is an NFSv4 Domain as described in
draft-adamson-nfsv4-multi-domain-access-00. This means that Server A
and Server B share a name service, and every ACL returned by every
file server in the name space served by server A and server B uses the
form [email-masked]. Users on client C that do a getacl on any file
in the /nfs4/toaster.net/ file system should see the same ACL names as
users on client D.

-->Andy