Subject: Re: [nfsv4] Ralph Droms' Discuss ondraft-ietf-nfsv4-federated-fs-dns-srv-namespace-09: (withDISCUSS and COMMENT)

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 11 Nov 2011 12:28:30 -0500

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2011 1:20 PM
> To: The IESG
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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

Thanks.  Given this reading, I'd like to move ahead with this #2 scheme,
which we can simplify to remove the RO/RW distinction.  This leads to
a name for the NFS-accessible domain roots of

  _domainroot._nfs._tcp.example.com

Would this be acceptable?

Would this "_domainroot" subtype then be subject to registration
with the RFC 6335 registry (without an associated port number)?
If so, would it be done as a separate registration, or by registering
the name as composed with the "_nfs" service name?

> 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.

I'll remove any hint that this resolution could happen other than
in the NFSv4 client.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 1. To make sure I'm understanding the use of this SRV RR, is it
> intended to provide information about the root of an NFS file system
> published as the "uniform file name space" for an organization?
> Although the target field of the RR could point to any NFSv4 file
> server, by convention as defined in this document, the target is the
> root of this "uniform file name space."

Yes, this is the intent.  The intent is to indicate only those NFSv4
file servers that can provide service for the root of this "uniform
file name space" for an organization.  This is likely a subset of all
the NFSv4 file servers that provide file service within that
organization.

> 2. Section 4.2 Paragraph 5:
> 
> One of the main points of SRV records is to allow the usage of
> different ports on servers for provision of service I would like to
> see the example here use other port than 2049 in at least one example.
> Or does the NFSv4 specification say "YOU MUST ONLY USE PORT 2049"?

The NFSv4 spec allows for other port numbers, and I'll include such an
example.

> 3. In order to facilitate the provision of both R/O and R/W copies of
> the same mount point, in theory the Priority field can be used.
> Lowest priority field is RO, RW are higher priority.  This document
> would give advice on Priority ranges to use for different kinds of
> systems.
> 
> Example:
>   0.10 Read-only
>   100..110  Read/Write copies
>   10000..10010 Fresh Read/Write copies
> 
> Thus only clients that know what kind of copy they need will use the
> appropriate subset of SRV records when selecting a server.  In this
> case different sever ports would provide the different access, not
> different external names.
> 
> Example:
>     _nfs._tcp SRV 0 1 45503    BigServer.example.net.
>     _nfs._tcp SRV 0 2 2049     SmallServer.example.net.
>     _nfs._tcp SRV 101 1 49934  BigServer.example.net.
>     _nfs._tcp SRV 10010 3 2049 Backend.example.net.
> 
> Due to the way how records are selected (if RFC2782 selection
> algorithm is followed) the probability of using high priority servers
> by read-only clients is quite low.

This is a reasonable idea.  Ultimately, though, NFSv4 itself provides a
rather rich set of attributes that the client can use to navigate the
set of representatives for a file system, including the file system used
for the domain root.  Probably it makes sense to allow the NFSv4 client
to navigate these representatives of the domain root case in much the
same way as it navigates all other sets of representatives.
 
> 4. It might not be a bad idea if the draft analyzed the likely effects
> of split-brain, DNS64, and so on, but I'm not sure it's necessary.

These are likely issues for the base NFSv4 capability that allows it
to project a uniform file name space in the first place.  This DNS
usage may have a little more exposure to them than the base case, since
it is targeting a broader area, but it's only a difference of degree.

> 5. Assuming IANA is being asked to register these service names in the
> Service Name and Transport Protocol Port Number Registry [RFC6335], it
> would be helpful to identify the registry explicitly and cite RFC 6335
> in section 7.

Yes.

> Comments 6, 7 and 8 are related to NFS rather than the SRV record
> defined in this document.
> 
> 6. The convention of using /domainroot-example.net and
> /.domainroot-example.net for the read-only and read-write versions of
> the example.net file system is not intuitive to me.  Why use the "."
> prefix rather than, say, /domainroot-ro_example.net and
> /domainroot-rw_example.net?

The requirement is for the export point to begin with a dotted name
in the NFS server's pseudo-root name space simply to allow the
NFS server to export other file systems as well, and to allow those
other file systems to have whatever human-friendly names the NFS server
administrator might choose to support.

> 7. Similarly, why use the "." convention for mounting the filesystem
> in the client?

This is probably a flaky idea, and the latest draft removes it.

> 8. Are the details of the integration process sketched in section 5
> written down in more detail somewhere else?  In my opinion, I'm not
> sure section 5 will ensure a uniform use of the SRV record across all
> clients.

Section 5 mostly covers the same material as is in the opening
text in section 4, but focusing more on the conventional client
mechanics.  It is not intended to stand on its own.

		Craig

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Nov 2011 11:30:22 -0500

Craig - thanks for your response.  My answers are in-line...

- Ralph

Yes.

Yes.

> the name as composed with the "_nfs" service name?

Good question.  My unresearched answer would be to make separate registrations, but I'll look into it.

> I'll remove any hint that this resolution could happen other than

OK.

> the NFSv4 file servers that provide file service within that

OK, thanks for the clarification.

> The NFSv4 spec allows for other port numbers, and I'll include such an

OK.

> same way as it navigates all other sets of representatives.

OK.

> it is targeting a broader area, but it's only a difference of degree.

To be clear, you text about split-DNS would be better in a separate
document targeting the base NFSv4 spec?

>> would be helpful to identify the registry explicitly and cite RFC 6335

To be added to the next rev of the draft?

> administrator might choose to support.

I'm not quite sure I understand.  I'll take another look at the text in question...

> This is probably a flaky idea, and the latest draft removes it.

OK.

> mechanics.  It is not intended to stand on its own.

I'll take another look at the text in those sections to see if I have
concrete suggestions.

- Ralph