Subject: RE: [nfsv4] NFSv4 Global namespace: joining NFSv4 domains with a newDNS nfsv4 SRV.

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 1 Mar 2006 15:25:09 -0500

Replying to the message From: Nicolas Williams
[mailto:[email-masked]] 
> 
> On Tue, Feb 28, 2006 at 05:52:29PM -0500, Everhart, Craig wrote:
> > So draft-everhart-nfsv4-namespace-via-dns-srv-00.txt is intended to 
> > document an NFSv4 global namespace.
> > 
> > Some possible sticking points are
> > 	- no recommendation on whether DNS SRV processing is 
> done on NFS 
> > client or NFS server
> 
> I expect the client to do DNS SRV lookups to find the NFSv4 "root"
> servers for a domain.  I expect clients to know how to cross 
> server-side mounts and follow referrals.
> 
> If servers wish to issue referrals to a domain's NFSv4 root, 
> that's fine, and for this they'd have to know how to do DNS 
> SRV lookups.  But really, this is something clients will want 
> to know how to do.

I think the attractiveness is that it doesn't matter where the lookups
are done--that someone else could provide this mechanism on the server
side, assuming only an NFSv4 referral-capable client without DNS SRV
interpretation abilities.  That someone could build a special NFSv4
server that hosted no data on its own, but rather filled in its data as
a TTL-controlled cache of data it had acquired from DNS servers.  The
client could mount that server's (virtual) filesystem as "/nfs4" and its
user-visible namespace would be the same as the one that your proposed
client structure would deliver.

So the hard-to-achieve agreement is how a domain might publish a
filesystem that it wants associated with itself, and given that, either
a client-side or a server-side implementation would provide the same
result.

> > 	- security recommendations referring to DNSSEC as part 
> of a chain, or 
> > the KITTEN WG's domain-based service principal names
> 
> Right now only DNSSEC is available for normative references.  
> If you're willing to wait one more IETF we could get the 
> domain-based service principal names I-Ds prioritized and 
> through to Proposed-Standard.

Hm.  Good point.  Do you think that domain-based service principal names
are that close?

> > Or is it so clear and uncontroversial as not to elicit comments?
> 
> The first one is.  The second is not -- you must at least 
> document the security problem in the security considerations section.

presumably, you mean the dependency on a the standardization status of
the concepts referred to.

> > Admittedly, lots of discussions have happened already
> 
> Yes, but we all seem to (finally) be on the same page about 
> the structure of the NFSv4 global namespace (domains with 
> root servers discovered via DNS SRV RRs).

Hear, hear.

> Nico

		Craig

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Mar 2006 14:57:05 -0600

On Wed, Mar 01, 2006 at 03:25:09PM -0500, Everhart, Craig wrote:
> interpretation abilities.

Yes, yes, but if you want an AFS-like experience then you'll definitely
want the clients to know how to do this.

>                            That someone could build a special NFSv4

This is fine, but clients can't expect this to be available, and clients
would have to know how to discover this one root, or have it configured,
which gets us back to: clients should know how to do discover NFSv4 root
servers.

> a client-side or a server-side implementation would provide the same

Nonsense -- once you have this NFSv4 root server disovery mechanism
we've obtained agreement.  Why?  Because it's far easier to teach
clients how to do this than it is to teach them something else and
require that folks deploy NFSv4 servers that proxy these discoveries.

> Hm.  Good point.  Do you think that domain-based service principal names

They're very small, non-controversial and have no dependencies on any
other documents that are not already RFCs.  Therefore they could be
moved quickly -- we've just focused on other things.

KITTEN WG has move three small documents through to published Proposed
Standard status fairly quickly.

No, I meant your first item:

> >       - no recommendation on whether DNS SRV processing is done on NFS
> > client or NFS server

and the second ("security recommendations...").

> > root servers discovered via DNS SRV RRs).

Well, if you're on board with that then what's this stuff about clients
not knowing how to do this but relying on NFSv4 servers (discovered who
knows how, or else configured) to proxy DNS SRV lookups instead?

I don't get it.  What could possibly be controversial about saying that
clients SHOULD know how to do this?  What clients nowadays don't know a
modicum of DNS?  And if you have an example of a small [embedded?]
device that couldn't possibly speak DNS but would speak NFSv4 (which,
excuse my skepticism, just does not seem likely), surely it could at
least use DHCP, and if so then why not specify a DHCP option to find a
client's root NFSv4 servers?  What am I missing?  Or are you just trying
to avoid potential controversy and causing some in the process :)?  Or
is the concern that small-footprint (or any) DNSSEC-capable resolvers
arent' widespread?  If so, how can the client securely discover root
NFSv4 servers that would proxy DNSSEC DNS SRV RR lookups?  DHCP doesn't
exactly offer a good answer right now.

Nico
--