Subject: [dns-dir] Review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08

From: Ralph Droms <[email-masked]>
Date: Fri, 7 Oct 2011 12:09:15 -0400

draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08 is currently in
IESG review.  I would appreciate a DNS directorate review to help me
with my review of the doc.  Thanks... 

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 11 Oct 2011 12:57:47 -0400

Second try - is anyone willing to commit to a review before 10/18?

- Ralph

---

From: [email-masked]
Date: Tue, 11 Oct 2011 14:27:39 -0400

> Second try - is anyone willing to commit to a review before 10/18?

I thought, "Gee, I have time to read that now," so I started.  This is
from one very quick read.

I was fine until we get to section 4.2.  There, we have this:

   Because of the possible distinction between read-only and read-write
   versions of a filesystem, organizations SHOULD also publish the
   location of a writable instance of their root filesystems, and that
   NFSv4 clients SHOULD mount that filesystem under the organizational
   domain name preceded by a period (".").  Therefore, when names
   beginning with a period are looked up under the NFSv4 client's
   special directory, the SRV RR looked up in DNS uses a Service name of
   "_nfs4._write._domainroot", and the indicated server (or servers)
   SHOULD export the writable instance at "/.domainroot-write-{Name}"
   for a domain name Name.

This seems crazy to me.  Why add the additional label?  Why not just
distinguish between _nfs4read and _nfs4write.  It seems to me these
are just different services, so publish two different service names.
I'm not wedded to this -- the underscore mechanism is a mess anyway --
but I think it'd be tidier.  Note that the additional levels of
underscoring break the attempts so far made to do something like a
registry with underscores.

I like _very much_ the recommendation to worry about "abbreviated"
names (in section 4.3).

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.

Best,

A

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

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 12 Oct 2011 11:08:03 -0400

> Second try - is anyone willing to commit to a review before 10/18?

Here is my review: (I did see that Andrew posted one, but mine is 
written w/o reading his).

Disclaimer: I at one point sat down with some NFS people and talked 
about how to use the DNS by NFS. I pointed them at SRV records or told 
them define new type.

Summary:
NFSv4 proposed use of SRV records is an interesting extension as they 
want more functionality/naming than naive reading of the SRV spec 
implies. In particular they want to have the ability to do the 
following mapping:
  <domain><mount_name> --> <server>:/domainroot-<mount_name>.<domain>
or even
  <access_type>:<domain><mount_point>

Where: domain is the name  of the zone the SRV record resides in
        mount_point is a name under the
The document does accomplish this in a way that is strange and 
convoluted and I think in the long run counter productive thus below I 
propose few changes in registration and ask for clarifications.

Details:
Section #3:
The service name specified is a two label name "_nfs._domainroot"
so far there have been no such registrations and future extensions are 
likely to be of the form "_nfs._<newname>
If they want to have NFS specific names the order should be revised
	_domainroot._nfs
as that way they will not stomp on names by other protocols in the 
registration, i.e. do not prevent _domainroot. to be location of root 
DNS servers.
As the specification right now does not include any uses of other mount 
point name component than _domainroot  the question is why is this needed?
Are there other envisioned in the future?

Even if the NFSv4 spec says the export MUST be done at
<server>:/domainroot-<domain_name>
there is no real reason to include that in the DNS name or if it is 
included the _domainroot should be either before or after the string
"_nfs._tcp" in the domain name.

Same set of comments can be applied recursively to the 
_nfs._write._domainroot._tcp service name.

Section #4: has this golden nugget.
"This DNS SRV record evaluation, could in principle, be done either in 
the NFSv4 client or in the NFSv4 server....."

The fact is only the NFSv4 client can perform the DNS resolution as it 
may have a different resolution context than the server i.e. in an 
external view vs internal view
External is: _nfs._tcp.company_publications.<domain> SRV
Internal is:  company_publications.<domain> DNAME
		secret_documents.<inside>.<domain>

Another example one is that only a subset of clients can see some file 
systems and these clients are on a different LAN/VLAN with its own name 
resolution.

Section #4.2 First sentence: Seems to imply that each organization has 
only one mount point but I think this is just an artifact how it is 
written not of intent.

Section $4.2 Paragraph 4 (Because of the distinction..)
This section introduces the rationale for clients to be able to select 
between read/only and read/write versions of a mount point.
The proposed solution is leads to a question of are there other ways to 
accomplish this?
I think there are two ways to do this with names
	_write._nfs
or       _nfswrite
but not _nfs._write

For a client this makes no difference what strings they lookup and the 
client needs to know all the possible strings.
The specification of names used on SRV records does NOT have to match 
exactly what the NFS protocol says to translate that into.
(this comment is motivated by name-space cleanliness desire)

Section $4.2 Paragraph 5:
Nit: 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"?

Comment: 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 advise 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.

	Olafur