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

On 9/11/2011 11:32 PM, Keith Moore wrote:
> On Sep 11, 2011, at 6:23 PM, Joe Touch wrote:
>
> > On Sep 11, 2011, at 2:09 PM, Keith Moore wrote:
> >
> > > On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
> > >
> > > > We've been discussing this in the Transport area lately.
> > > >
> > > > DNS SRVs are defined in RFC 2782 as I have described. Additional info is passed 
> > > > in TXT records for current DNS SRVs.
> > > >
> > > > I.e. what I have proposed is what is both current spec and current widespread 
> > > > practice.
> > > >
> > > > Before proposing a change (which would need to happen before we would use it in 
> > > > a new spec anyway), is there something the current syntax (and use of TXTs for 
> > > > additional info) cannot do that you want?
> > > Why use SRV records at all if you also need TXT records to convey part of the 
> > > information needed by apps (and thus, have to do multiple queries for the same 
> > > level of information)?  Why not just encode all of the information in TXT 
> > > records?
> > The SRV records provide a standard way of mapping a service (as per the IANA 
> > ports and service names registry) on a specific transport to a hostname and 
> > port number.
> >
> > The TXT records are linked to the SRV records, and provide additional bootstrap 
> > info that the service does not provide in-band.
> You did not answer the question.
I had assumed familiarity with how SRV and TXT records are used 
together. See: draft-cheshire-dnsext-dns-sd
The SRV record has the semantic structure that allows the DNS query to 
be processed, e.g., weight, port number, target, etc.
The TXT record of the same name gives the additional information needed 
for service bootstrap.
> > If you're looking for a more generic database query system, you might consider 
> > using LDAP rather than the DNS.
> I'm not looking for anything in particular. I just don't see any
> justification for insisting that SRV records always be used with RFC
> 2782 style labels.
I have provided two:

        1) that's the current standard (i.e., changing it requires
        an update to RFC 2782, which this draft does not request)

        2) service lookups already depend on the semantic structure of
        IANA service names, which is already only [name, transport]

Adding further structure to these entities requires both a change to the 
standard and a change to the registry.
> Nor do I immediately see any justification for using
> SRV at all if the application also needs to look up TXT records to get
> the service's profile.
SRV records specify the structure that yields the port number, target, 
weight, etc.
Sure, you could define TXT record fields for anything you wanted - 
effectively redefining the DNS inside TXT records. However, you would 
also need to define an indicator *required in all TXT records* that 
would tell you whether to interpret the contents as A, AAAA, CNAME, SRV, 
etc.
Right now, the DNS indicates these as separate RR types. Stuart's draft 
defines TXT's with names matching corresponding SRV records as having 
additional info.
Yes, you could just have the TXT record, but you'd then need to define 
the SRV info in the TXT record as fields. For at many services, 
additional fields beyond the SRV info isn't needed.
> Of course, one of the problems with using SRV more widely (in
> addition to backward compatibility issues) is that in many cases
> what's desired is not merely to map a service name (as defined in the
> IANA registry and equated with a default port) onto an address and
> port, but rather, to provide instructions as to how a service may be
> accessed - a service profile, if you will. So I can certainly see why
> SRV alone would not do the job. What I don't immediately see is why
> it's worth the trouble of using SRV at all for those cases when it
> won't do the job.
The point is that there's one place to get the port number and hostname; 
additional info - which isn't needed in many cases (see the IANA ports 
list) - is added only when needed in these supplemental TXT records.
> (LDAP by itself wouldn't solve this problem either - you'd still
> need to define a way to represent an application service profile in
> LDAP. And if the name of the service is reasonably represented by a
> DNS name, then arguably, the profile belongs in DNS. Or at least, a
> pointer to the profile belongs in DNS. The last thing we need is to
> have LDAP and DNS providing conflicting information about what a DNS
> name means.)
If you want a service that takes [service-description, hostname] and 
returns a [port, hostname, additional-info] tuple, the DNS is fine.
(note that IANA *defines* service description as [name, transport] - 
there's no "read-only" attribute to that query). I.e., this presumes 
that the client parses the "additional-info" and determines whether this 
record is relevant - NOT that the DNS performs this filter for the client.
If you want more sophisticated DNS filters inside the DNS, I'd argue you 
really want LDAP.
Joe

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