Subject: [nfsv4] Comments/Discuss on draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09

From: Spencer Shepler <[email-masked]>
Date: Wed, 19 Oct 2011 18:58:11 +0000

We have received the following "discuss" from the DNS directorate
via Ralph Droms.

We need comment/feedback on this approach. Comments today or early
tomorrow would be helpful in that the IESG has a meeting tomorrow
and if we have these issues cleared, we can move forward.

Thanks,
Spencer

==================================
This document proposes the use of SRV records for mapping of names
of the form <domainroot-service>.<domain> to a mounted filesystem in
an NFS client namespace.  My review is based on two reviews from the
DNS Directorate and my own reading of the document.

1. The service name specified for the "domainroot" function are a two
label name "_nfs._domainroot." and a three label name
"_nfs._write._domainroot."  As I understand the use of these two
service names, they identify two unique, related services for NFS
clients.  Based on the use of these service names described in this
document, there is no need for multi-label service names, and the
specification could be simplified by using, e.g., "_nfs-ro." and
"_nfs-rw." for the service names.

2. If there is some expectation for future service sub-types for
NFS-related service names, it would be appropriate to define a "_nfs."
service with, e.g., "_domainroot-ro." and "_domainroot-rw." subtypes.
In this case, the names for read-only and read-write domain roots
would be:

_domainroot-ro._nfs._tcp.example.com
_domainroot-rw._nfs._tcp.example.com

3. In section 4:

   "This DNS SRV record evaluation, could in principle, be done either
   in the NFSv4 client or in the NFSv4 server....." 

Only the NFSv4 client can perform the DNS resolution as it
may have a different resolution context than the server in split DNS
scenarios.

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 23:32:49 -0500

> and if we have these issues cleared, we can move forward.

Thanks.  Comments below.

> _domainroot-rw._nfs._tcp.example.com

I'd also be fine with:

_nfs._tcp._domainroot-X.foo.example.

Whether to have an "option" such as read-only vs. read-write be a
separate label or part of the _domainroot label is just six of one and
half a dozen of the other to me :)  However, I do not think such
options should be affixed to the _nfs label -- that label identifies
the access protocol, and that access protocol is not made different by
the fact that the domain root filesystem is read-only or read-write.

> may have a different resolution context than the server in split DNS

I think that paragraph is completely wrong anyways, since at the point
that the client needs to resolve a domainname to a domain root
filesystem there's no suitable NFSv4 server to the client's knowledge
that could "in principle" have done the SRV RR lookup on the client's
behalf.  That paragraph should simply be removed.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Oct 2011 11:19:43 -0500

Hmmm, I'd also be OK with dropping the read-only/read-write thing.
The client can always ask whatever replica it picked to tell it where
to write (or it can even try them all).  No?

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 20 Oct 2011 14:16:13 -0400

inline

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Thursday, October 20, 2011 12:33 AM
> To: Spencer Shepler
> Cc: [email-masked]
> Subject: Re: [nfsv4] Comments/Discuss ondraft-ietf-nfsv4-federated-fs-
> dns-srv-namespace-09
> 

I could do without the RW/RO distinction.  The fs_location* attributes are more than adequate for locating a RW instance of a discovered RO filesystem.

But the expectation about future service sub-types is more that there could be a variety of protocols that non-NFS clients use to access the domain root.  I think that would leave us with

  _nfs._domainroot._tcp.example.com

with the fudging about possible future transports, not just TCP.  As much as this is a document about the usage of NFS (and NFSv4 in particular), should we leave room for other protocols that want to use the "domain root" concept", or are they on their own?

I'd propose we coalesce on the "_nfs._domainroot" service name.

> behalf.  That paragraph should simply be removed.

Much as I don't think the paragraph is "completely wrong", there's rough consensus that this document doesn't need to leave architectural room for clients to lean on servers to do this for them.  I'll take it out.

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Oct 2011 15:31:47 -0500

> I could do without the RW/RO distinction.  The fs_location* attributes are more than adequate for locating a RW instance of a discovered RO filesystem.

Right.

> But the expectation about future service sub-types is more that there could be a variety of protocols that non-NFS clients use to access the domain root.  I think that would leave us with

I'd say let's leave that for when we need that; lose the ro/rw label /
label affix.

> with the fudging about possible future transports, not just TCP.  As much as this is a document about the usage of NFS (and NFSv4 in particular), should we leave room for other protocols that want…

Yes.  This:

_nfs._tcp._domainroot.example.com.

or this:

_domainroot._nfs._tcp.example.com.

seems more "correct" to me than putting _domainroot between service
and transport protocol.

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 20 Oct 2011 17:53:34 -0400

> Sent: Thursday, October 20, 2011 4:32 PM
> To: Everhart, Craig
> Cc: [email-masked]
> Subject: Re: [nfsv4] Comments/Discussondraft-ietf-nfsv4-federated-fs-
> dns-srv-namespace-09
> 
> > I could do without the RW/RO distinction.  The fs_location*
> attributes are more than adequate for locating a RW instance of a
> discovered RO filesystem.
> 
> Right.
> 
> > But the expectation about future service sub-types is more that there
> could be a variety of protocols that non-NFS clients use to access the
> domain root.  I think that would leave us with
> 
> > with the fudging about possible future transports, not just TCP.  As
> much as this is a document about the usage of NFS (and NFSv4 in
> particular), should we leave room for other protocols that want to use
> the "domain root" concept", or are they on their own?
> 
> Yes.  This:
> 

I'm happy to work with the SRV <service>.<protocol>.<name> regime, myself, granting "_tcp" as the label of choice for <protocol>.  I think we live with that, like lots of other protocols that actually exist in layers.

I think we can quickly get wrapped around the axle of just what's a protocol and what's a service here, not to mention what's in the <name> part.  Ultimately I think it can soon become a metaphysical red herring.  I've argued that it's the "domainroot-accessible-by-NFS" service, trying to leave room for the "domainroot-accessible-by-XXX" for filesystem protocol XXX.  What does this WG think?

In any case, I'm not planning to wait for "_tcp" to be dislodged from the <protocol> spot.

		Craig

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Oct 2011 17:05:37 -0500

> I think we can quickly get wrapped around the axle of just what's a protocol and what's a service here, not to mention what's in the <name> part.  Ultimately I think it can soon become a metaphysic…

I think of it as the "NFS service [over TCP] for the domain's root filesystem".

> In any case, I'm not planning to wait for "_tcp" to be dislodged from the <protocol> spot.

That's not what I was proposing.  I was proposing, effectively, to
have _domainroot be considered part of the domainname to which
_nfs._tcp is prefixed.

Nico
--