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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf