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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sep 12, 2011, at 4:22 PM, Joe Touch wrote:

> On 9/12/2011 1:15 PM, Keith Moore wrote:
>> On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
>> 
>>> On 9/12/2011 11:41 AM, Keith Moore wrote:
>>>> I think at this point we're just talking past each other, but I
>>>> simply disagree with your assertion that RFC 2782 should be taken as
>>>> a prohibition on using SRV RRs in any way other than defined in RFC
>>>> 2782.
>>> 
>>> It might be useful to explain to this list what you think a spec means, so we can understand what you think it means to comply with a spec.
>> 
>> I think RFC 2782 inappropriately specified SRV RRs by defining both the label syntax and the RDATA syntax at the same time.
> 
> How is that different from every other RR except TXT?

Most RRs tie some set of data to a domain name which is historically a host name, though in recent years it's become a somewhat more nebulous concept (e.g. "a collection of services", or in the case of MX records "a collection of recipient mailboxes").    SRV is odd in that it overloads the domain to include "service name" and transport protocol.

Part of the problem with the way SRV is defined is that often, "service name" (in the sense of something that's tied to port number, is not what the application is looking for).   Another part of the problem is that "transport protocol" is often not appropriately part of the query - it's something that the application needs to know, rather than something the application should provide when doing the query.

SRV appears to have been designed with the idea that the DNS was a good place to advertise port numbers of services, and that it would make sense to have a standard mechanism to advertise alternate port numbers that would work across all applications.   For a wide variety of reasons, this is not a good idea.  But because SRV already exists and is deployed, and we occasionally find applications that need something similar to SRV, people keep trying to use it in ways that are contrary to its design.  

If DNS were easier to extend - in particular if RR types weren't limited to small integers but rather something like OIDs, and if the format of RDATA weren't hard-coded into DNS servers - I'd absolutely agree that the thing to do would be to deprecate SRV for new applications and define new RR types whenever needed.

Keith

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]