ietf
[Top] [All Lists]

Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace

2011-09-12 12:39:42
Hi, Nico,

On 9/12/2011 8:03 AM, Nico Williams wrote:
I disagree w.r.t. your comments regarding the use of SRV RRs for NFSv4
domain root location.

I think it would be a mistake to use TXT RRs to encode what SRV RR
RDATA does just fine just to get around whatever we think the rules
are or ought to be for using SRV RRs.

However, I'll note that the service here is NOT "NFSv4" but "NFSv4
domain root", thus, if it would make everybody happy I propose
changing this:

       _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
       _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.


to this:

       _nfs4domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
       _nfs4domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.

That would presume IANA would approve a new service name (i.e., an alias) for an existing service/port assignment - RFC 6335 indicates otherwise. (it also includes a version number in the string, which the same RFC deprecates).

You're locating the NFS service. You're using that to setup a domainroot. The former is a DNS SRV issue. The latter is an endhost configuration issue. Stuart's draft defining how to use TXT records to configure end services is already in widespread use, and sufficient for this purpose.

But IMO this is silly.  For example, Microsoft's Active Directory and
its Windows (and other) clients use SRV RRs like this:

     _ldap._tcp.gc._msdcs.<domain>
     _ldap._tcp.<site>._sites.<domain>
     ...

Microsoft's approach is to basically define a specific pattern to their FQDNs - using nonstandard syntax - to indicate that the server is a MS product:
http://technet.microsoft.com/en-us/library/cc961719.aspx

I don't agree with this approach; most others who use SRV records use TXT fields, and RFC 3088 provides a correct example of SRV use for LDAP.

If it's time to go update RFC2782, well, let's, but let's not hold up
the rest of the world over it.

It's up to you if you want to start by redefining SRV records.

This document does not propose to do that, so its use is simply noncompliant with existing specs.

Joe


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>