Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Tue, Sep 13, 2011 at 10:20 AM, Joe Touch to...@isi.edu wrote: On Sep 12, 2011, at 5:56 PM, Nico Williams n...@cryptonector.com wrote: On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch to...@isi.edu wrote: On 9/12/2011 2:43 PM, Nico Williams wrote: I meant existence as in how it's used. I don't see why Windows/AD/Samba/... can use SRV RRs the smart way while the rest of us must not. That would be silly. It's not our fault that RFC2782 is outdated. Nor is it our job to update it. The Windows examples explain their use as basically a naming convention for servers, where they a) add a few prefixes to the FQDN b) some of which violate DNS specs c) where the FQDN doesn't match the hostname i.e., they add foo._bar.nsf.example.net when they intend a FQDN of nsf.example.net They have prefixes for domainnames, yes (of course FQDN), where the domainnames do not correspond to hosts, but to what we colloquially refer to as domains. All of the most important of these SRV RR uses in Windows use RRset naming conventions that differ from those in RFC2782. There are many implementations of this (I know of at least four in the *nix space, probably more if we include proprietary scripts written using Perl5, Python, ..., that must abound in corporate land). And of course, there's Widnows'. I know of at least three server-side implementations (though, of course, the DNS server component itself requires no special sauce in order to support any of this, as DNS servers do not encode RRset naming conventions like RFC2782's). There are three problems with that - which could interfere with other interpretations of those SRV records (e.g., tools that might scan those records to monitor service liveness). Nonsense. This stuff exists and has been deployed for over a decade. I've never heard of a tool choking on these SRV RRsets. If you have, please list them and explain why anyone should care that there exist tools which cannot cope with a widely deployed system like this. But, let's see if we can change the direction of this thread (we're going in circles). Would you oppose an update to RFC2782 to standardize different SRV RRset _name_ conventions? I would, as per above. That would be pushing context-dependent syntax into the SRV record rather than using a separate RR - where that syntax belongs. Note that SRVs changed DNS RRset name conventions but only for the SRV RR. I.e., the precedent is that changing the syntax requires a new RR. Then there's no point continuing this discussion without participation from IESG members. The I-D authors will have to negotiate without my participation. I recommend continuing the process until the IESG balks, if they do. If the IESG balks, then appeal. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 1:00 PM, Robert Thurlow wrote: Joe Touch wrote: Either this is an nfs service or it isn't. If it is, then it should be using _nfs._tcp.example.com, etc. If it isn't, then: a) a new service name is required which then *requires* b) a new port number be assigned This doesn't show any real understanding of what we're actually trying to do. To recap: We don't want to enumerate all NFS servers in a domain. That is not an interesting enumeration. We want to find certain ones that are known to share a domain root (hence the syntax we chose). When we find those servers, we will talk NFSv4 to them (not a new service). And we will talk NFSv4 on port 2049 (not a new port). Your proposal above makes things worse in that it will no longer be clear what the SRV record means. It also ensures that we have a problem if we ever want to enumerate other subsets of NFS servers (none of which have been discussed). Rob T Hi Rob, Few inputs you can take with a huge grain of salt 1) some people on this list have suggest TXT records. Keep in mind this is totally the wrong group to tell you how to use DNS. Last time I discussed TXT records with the DNS directorate they certainly would not have recommended them for this use. I suspect the advice to use TXT is very bad but either way, if you want advice on that, go talk to the DNS Directorate not the transport guys. 2) My understanding is that you have two types of service you want to be able to find using SRV. Now these two services both happen to use the same protocol to talk to them and both run on same default port so you don't need two ports allocated for them but you do need to be able to make separate DNS entries for the two because some servers offer one of the service and some don't. Using SRV and having one labels like _service1._tcp.example.com for one service and _service._tcp.example.com for the other service seem perfectly reasonable to me, but this is the TSV review and I don't know why the TSV directorate would be providing any comment on how you use DNS. Now the fact that both will likely point as the same port and same server in some times seems fine to me. 3) Nothing to do with TSV but, your motivation for separating the _service1._tcp into _service1._foo._tcp seems like something you don't really need and is going to make this harder for you to get this all approved. Unless you need this, I'd think carefully about how much you want it. Keep in mind if some other protocol wants the domain concept, they can just go allocate two tags for use in SRV DNS. 4) I have not seen a single transport issue raised in this thread Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi, Nico, On Sep 12, 2011, at 5:56 PM, Nico Williams n...@cryptonector.com wrote: On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch to...@isi.edu wrote: On 9/12/2011 2:43 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote: My claim is that: SRVs represent services as they are currently assigned by IANA a new RR could be useful for things that aren't sufficiently expressible in the IANA service/port registry Existence proofs show that this is not *actually* so. The existence proof is that many SRV names have defined TXT fields, including the following: I meant existence as in how it's used. I don't see why Windows/AD/Samba/... can use SRV RRs the smart way while the rest of us must not. That would be silly. It's not our fault that RFC2782 is outdated. Nor is it our job to update it. The Windows examples explain their use as basically a naming convention for servers, where they a) add a few prefixes to the FQDN b) some of which violate DNS specs c) where the FQDN doesn't match the hostname i.e., they add foo._bar.nsf.example.net when they intend a FQDN of nsf.example.net There are three problems with that - which could interfere with other interpretations of those SRV records (e.g., tools that might scan those records to monitor service liveness). But, let's see if we can change the direction of this thread (we're going in circles). Would you oppose an update to RFC2782 to standardize different SRV RRset _name_ conventions? I would, as per above. That would be pushing context-dependent syntax into the SRV record rather than using a separate RR - where that syntax belongs. Note that SRVs changed DNS RRset name conventions but only for the SRV RR. I.e., the precedent is that changing the syntax requires a new RR. If not, are you aware of any others who might? If you don't object, who should be responsible for making the update, keeping in mind that these alternative SRV RRset naming conventions shipped long ago? There are plenty of cases of protocols and extensions that are deployed that don't meet spec. If we should take a cue from deployed code, we should (IMO) follow Apple not Microsoft in this case. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 8:09 PM, Keith Moore mo...@network-heretics.com wrote: ... SRV indicates the port number (useful if not the default) and weight, etc. right. but given that you can include the same things in a TXT record, if you have to query for TXT RRs anyway, what's the value added by doing an additional query for SRV RRs? ... I'd be very happy to see SRV records deprecated, or at least discouraged, for new protocols. ... But I don't think the Internet is desperate enough to want to fix DNS yet. I conclude from this sequence that you would prefer to reinvent the DNS inside TXT records (which is possible, but fruitless), and that others do this on your behalf. This is outside the focus of this thread. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 13, 2011, at 7:38 AM, Cullen Jennings flu...@cisco.com wrote: Hi Rob, Few inputs you can take with a huge grain of salt 1) some people on this list have suggest TXT records. Keep in mind this is totally the wrong group to tell you how to use DNS. Last time I discussed TXT records with the DNS directorate they certainly would not have recommended them for this use. I suspect the advice to use TXT is very bad but either way, if you want advice on that, go talk to the DNS Directorate not the transport guys. Agreed, however the point that TXT records are currently used this way can be part of the decision of how to approach the issue. 2) My understanding is that you have two types of service you want to be able to find using SRV. Now these two services both happen to use the same protocol to talk to them and both run on same default port so you don't need two ports allocated for them but you do need to be able to make separate DNS entries for the two because some servers offer one of the service and some don't. Using SRV and having one labels like _service1._tcp.example.com for one service and _service._tcp.example.com for the other service seem perfectly reasonable to me, but this is the TSV review and I don't know why the TSV directorate would be providing any comment on how you use DNS. Now the fact that both will likely point as the same port and same server in some times seems fine to me. RFC 6335 is a TSV document, and the TSV area oversees IANA service and port assignments. I agree that this is not solely the purvue of TSV, though. 3) Nothing to do with TSV but, your motivation for separating the _service1._tcp into _service1._foo._tcp seems like something you don't really need and is going to make this harder for you to get this all approved. Unless you need this, I'd think carefully about how much you want it. Keep in mind if some other protocol wants the domain concept, they can just go allocate two tags for use in SRV DNS. Agreed. This is the current approach being documented in TSV area for consideration (though not yet widely discussed). 4) I have not seen a single transport issue raised in this thread Please review *your own* posts from Feb of this past year, where you will find the precursor to RFC 6335 named draft-ietf-tsvwg-. JOe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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. 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 ... If it's time to go update RFC2782, well, let's, but let's not hold up the rest of the world over it. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Mon, Sep 12, 2011 at 12:39 PM, Joe Touch to...@isi.edu wrote: On 9/12/2011 8:03 AM, Nico Williams wrote: 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. No. We do not normally locate the NFS service. If you know a server, that's the server hosting the NFS service. This is a distinct concept to NFS server. And the whole point is to avoid end host configuration, if by end host you mean the *client*. 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. I'm uninterested in saying no to plainly working and deployed solutions out of dogmatic inflexibility. Update RFC2782 if you like. 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. I'm unwilling to do that because I don't believe we have to. I'm even less willing to use TXT RRs to duplicate SRV RR functionality. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Joe Touch wrote: Either this is an nfs service or it isn't. If it is, then it should be using _nfs._tcp.example.com, etc. If it isn't, then: a) a new service name is required which then *requires* b) a new port number be assigned This doesn't show any real understanding of what we're actually trying to do. To recap: We don't want to enumerate all NFS servers in a domain. That is not an interesting enumeration. We want to find certain ones that are known to share a domain root (hence the syntax we chose). When we find those servers, we will talk NFSv4 to them (not a new service). And we will talk NFSv4 on port 2049 (not a new port). Your proposal above makes things worse in that it will no longer be clear what the SRV record means. It also ensures that we have a problem if we ever want to enumerate other subsets of NFS servers (none of which have been discussed). Rob T ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Mon, Sep 12, 2011 at 2:56 PM, Joe Touch to...@isi.edu wrote: On 9/12/2011 12:00 PM, Robert Thurlow wrote: Joe Touch wrote: We don't want to enumerate all NFS servers in a domain. That's what SRV records do. If that's not what you want, you should consider defining a new RR type. No We don't want to enumerate *all* NFSv4 servers in a domain. We want to enumerate all NFSv4 domain-root servers in a domain. Slight difference. Now, if we only ever intended to discovery domain-root NFSv4 servers, then we could just follow RFC2782. But what if we want to add some new role like domain-root, but not domain-root, for NFSv4 servers? I suppose we could punt on this till then, but it seems unclean to do so -- it's much cleaner to denote the role of the server (domain root) in the RRset name. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Mon, Sep 12, 2011 at 3:08 PM, Joe Touch to...@isi.edu wrote: On 9/12/2011 1:00 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.edu wrote: On 9/12/2011 12:00 PM, Robert Thurlow wrote: No We don't want to enumerate *all* NFSv4 servers in a domain. We want to enumerate all NFSv4 domain-root servers in a domain. Slight difference. I know what you *want* to do. But short of assigning another port number for that capability and getting another service name, this simply isn't a service in the IANA service/port numbers sense, so I'm not surprised it doesn't uniquely map to SRV records. I don't think that's the correct way to go about this. I see nothing wrong with what's proposed. I say we let the LC run and see where we stand on consensus at the end. If we end up on the rough side of consensus, so be it -- in that case then I think we'd want to undertake an update of RFC2782, rather than bend to it. We want to do what's right. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Mon, Sep 12, 2011 at 3:15 PM, Keith Moore mo...@network-heretics.com wrote: On Sep 12, 2011, at 3:50 PM, Joe Touch wrote: I think RFC 2782 inappropriately specified SRV RRs by defining both the label syntax and the RDATA syntax at the same time. I think we can all agree that RFC2782 is authoritative for the SRV RR RDATA specification. It can be no other way. The RRset name, OTOH, we could easily agree that RFC2782 is authoritative as to the construction of the RRset name for one use of SRV RRs. I don't see how RFC2782 can constrain forevermore the SRV RRset names, but quite clearly there's not much we could or should do to change the SRV RR RDATA specification (at most we could change the interpretation of some of the RDATA fields in some circumstances, but not the RDATA format itself). Now, IF the IETF consensus is that we must update RFC2782 in spite of the many SRV RR uses that exist which do not match the RFC2782 RRset naming convention, well, fine, we can do that -- it's not a big deal, only a small delay. But until then my position is that we do not have to do this. Nico -- Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touch to...@isi.edu wrote: My claim is that: SRVs represent services as they are currently assigned by IANA a new RR could be useful for things that aren't sufficiently expressible in the IANA service/port registry Existence proofs show that this is not *actually* so. It's only what RFC2782 was aiming for. Time has passed. That ship has sailed. Someone should update RFC2782 for the benefit of the community, but I don't see how that could be a requirement here. Much less do I think anything could preclude such an update. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
-Original Message- From: nfsv4-boun...@ietf.org [mailto:nfsv4-boun...@ietf.org] On Behalf Of Joe Touch Sent: Monday, September 12, 2011 3:31 PM To: Nico Williams Cc: ietf@ietf.org; draft-ietf-nfsv4-federated-dns-srv- namesp...@tools.ietf.org; tsv-...@tools.ietf.org; nf...@ietf.org; tsv- d...@ietf.org; Keith Moore Subject: Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv- namespace On 9/12/2011 2:43 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote: My claim is that: SRVs represent services as they are currently assigned by IANA a new RR could be useful for things that aren't sufficiently expressible in the IANA service/port registry Existence proofs show that this is not *actually* so. The existence proof is that many SRV names have defined TXT fields, including the following: ftp sftp-ssh ssh telnet http nfs (already defines path to the mount point) Interesting; do you have a reference for that one? Spencer qttp (quicktime) webdav It's only what RFC2782 was aiming for. Time has passed. That ship has sailed. Seems like that ship sails just fine. There are bigger issues with widescale SRV use, but the use of associated TXT records isn't one of them as far as I've seen. Joe ___ nfsv4 mailing list nf...@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
-Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Monday, September 12, 2011 3:42 PM To: Spencer Shepler Cc: Nico Williams; ietf@ietf.org; draft-ietf-nfsv4-federated-dns-srv- namesp...@tools.ietf.org; tsv-...@tools.ietf.org; nf...@ietf.org; tsv- d...@ietf.org; Keith Moore Subject: Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv- namespace On 9/12/2011 3:33 PM, Spencer Shepler wrote: ... The existence proof is that many SRV names have defined TXT fields, including the following: ftp sftp-ssh ssh telnet http nfs (already defines path to the mount point) Interesting; do you have a reference for that one? Spencer http://dns-sd.org/ServiceTypes.html The IANA service/ports registry is supposed to include everything here, but does not as yet (they're working on it). That entry is wishful thinking at best and wholly unspecified in anything that I have ever seen and certainly not implemented (to my knowledge). Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch to...@isi.edu wrote: On 9/12/2011 2:43 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote: My claim is that: SRVs represent services as they are currently assigned by IANA a new RR could be useful for things that aren't sufficiently expressible in the IANA service/port registry Existence proofs show that this is not *actually* so. The existence proof is that many SRV names have defined TXT fields, including the following: I meant existence as in how it's used. I don't see why Windows/AD/Samba/... can use SRV RRs the smart way while the rest of us must not. That would be silly. It's not our fault that RFC2782 is outdated. Nor is it our job to update it. But, let's see if we can change the direction of this thread (we're going in circles). Would you oppose an update to RFC2782 to standardize different SRV RRset _name_ conventions? If not, are you aware of any others who might? If you don't object, who should be responsible for making the update, keeping in mind that these alternative SRV RRset naming conventions shipped long ago? Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 13, 2011, at 11:25 AM, Joe Touch wrote: On Sep 12, 2011, at 8:09 PM, Keith Moore mo...@network-heretics.com wrote: ... SRV indicates the port number (useful if not the default) and weight, etc. right. but given that you can include the same things in a TXT record, if you have to query for TXT RRs anyway, what's the value added by doing an additional query for SRV RRs? ... I'd be very happy to see SRV records deprecated, or at least discouraged, for new protocols. ... But I don't think the Internet is desperate enough to want to fix DNS yet. I conclude from this sequence that you would prefer to reinvent the DNS inside TXT records (which is possible, but fruitless), and that others do this on your behalf. This is outside the focus of this thread. Again, Joe, you're really bad at trying to discern my motives. I suggest you reread what I've written and take it at face value. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Keith Moore wrote: 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? I fully agree with you. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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. 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. 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. 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. (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.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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, , 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 10:57 AM, Joe Touch wrote: 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) Yes, but arguably 2782 is a poor fit for this application, and for many other applications also. 2) service lookups already depend on the semantic structure of IANA service names, which is already only [name, transport] There's nothing about the definition of the SRV RR that inherently constrains the label that such RRs are associated with. Adding further structure to these entities requires both a change to the standard and a change to the registry. Well, you can't really change the structure of SRV RRs, as they're already in use for some things and in widely deployed code. But there's no reason why an app couldn't specify a new use of SRV RRs with different labels than specified by 2782. As long as there were no potential for collisions between 2782-style labels and the labels used by the app, it wouldn't break anything. The fact that there's already a standard existing for SRV RR labels shouldn't inherently preclude standardization of a different kind of label associated with SRV. 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, , CNAME, SRV, etc. Well, that's the problem with TXT records. Or, to look at it differently, it's a problem with the design of the DNS protocol in that its way of labeling RR types is too limited. But looking at it still a different way, if you pick labels that are unique to a particular application, there's no need for a type indicator to be embedded in the TXT record. (Effectively this is moving the type to the label.) 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. In principle, the apps that don't need anything beyond what SRV provides could still use the SRV RR as it's defined in 2782 (whether or not the same style of labels are used).It's (partially) the warts-on-warts approach of TXT + SRV (or NAPTR + SRV, in a different context), that I'm concerned about. I get the impression that there's a set of people out there who keep insisting that SRV be used even though it turns out not to be a good fit for many situations. Like this document. I've become fairly convinced that SRV is at best not widely applicable,
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi, Keith, On 9/12/2011 10:47 AM, Keith Moore wrote: ... 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) Yes, but arguably 2782 is a poor fit for this application, and for many other applications also. You're welcome to: a) submit a proposal to redefine RFC 2782 or, more usefully AFAICT: b) submit a proposal for a new DNS record type 2) service lookups already depend on the semantic structure of IANA service names, which is already only [name, transport] There's nothing about the definition of the SRV RR that inherently constrains the label that such RRs are associated with. RFC 2782 specifies the syntax of the label - to the point of stating which transports are allowed - not the target, though. That's a place you can play if you want, AFAICT. Adding further structure to these entities requires both a change to the standard and a change to the registry. Well, you can't really change the structure of SRV RRs, as they're already in use for some things and in widely deployed code. But there's no reason why an app couldn't specify a new use of SRV RRs with different labels than specified by 2782. I don't understand what you just said; I agree with the first part, but that prevents the second. As long as there were no potential for collisions between 2782-style labels and the labels used by the app, it wouldn't break anything. The fact that there's already a standard existing for SRV RR labels shouldn't inherently preclude standardization of a different kind of label associated with SRV. IMO, you're suggesting a new RR, but seem to want all the benefits of using SRV with none of the responsibility. That's not how it works. If you want a new RR, declare it, and deal with deployment, etc. If you want to use SRV RRs, either use them as specified or change the spec. 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, , CNAME, SRV, etc. Well, that's the problem with TXT records. Or, to look at it differently, it's a problem with the design of the DNS protocol in that its way of labeling RR types is too limited. You're welcome to define a new name service lookup protocol, either using LDAP or custom too. I.e., I agree that RR types are limited, but this WG doesn't get to unilaterally redefine SRV types. But looking at it still a different way, if you pick labels that are unique to a particular application, there's no need for a type indicator to be embedded in the TXT record. (Effectively this is moving the type to the label.) If you want to make that argument as a change to RFC 2782, then you need to propose it in the DNS WG and wait for it to be accepted. I don't think it will suffice, because for any label structure there will be a use outside the intended that wants an exception. That's basically the conversation we're having now. You're just kicking the ball down the field. ... 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. In principle, the apps that don't need anything beyond what SRV provides could still use the SRV RR as it's defined in 2782 (whether or not the same style of labels are used). It's (partially) the warts-on-warts approach of TXT + SRV (or NAPTR + SRV, in a different context), that I'm concerned about. I get the impression that there's a set of people out there who keep insisting that SRV be used even though it turns out not to be a good fit for many situations. Like this document. Fair enough. Then don't use SRVs. I've become fairly convinced that SRV is at best not widely applicable, and at worst fairly harmful. One reason it's not widely applicable is that there are too many cases where the application needs to know more more than a list of (address,port) pairs to successfully choose an instance of a service and use it. (Part of this is because SRV isn't just being used to help an application connect to a protocol service, but also, to choose an instance of a somewhat more abstract service which might actually be implemented using multiple protocols and/or multiple sets of optional features of a protocol). A discussion about this document is not the place
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi, Nico, On 9/12/2011 10:49 AM, Nico Williams wrote: On Mon, Sep 12, 2011 at 12:39 PM, Joe Touchto...@isi.edu wrote: On 9/12/2011 8:03 AM, Nico Williams wrote: 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. No. We do not normally locate the NFS service. If you know a server, that's the server hosting the NFS service. This is a distinct concept to NFS server. And the whole point is to avoid end host configuration, if by end host you mean the *client*. Either this is an nfs service or it isn't. If it is, then it should be using _nfs._tcp.example.com, etc. If it isn't, then: a) a new service name is required which then *requires* b) a new port number be assigned 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. I'm uninterested in saying no to plainly working and deployed solutions out of dogmatic inflexibility. Update RFC2782 if you like. The issue is that if this document wants to go outside the spec, *it* needs to update RFC2782 - and survive the discussion that will incur. If your claim is that we should ignore specs once we find any extant exception, then there's simply no point in even proceeding with this doc. There's no need for this spec. No need for any spec. Why do you even participate in spec discussions then? 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. I'm unwilling to do that because I don't believe we have to. I'm even less willing to use TXT RRs to duplicate SRV RR functionality. SRV RRs define the port, weight, target, etc. TXT RRs for the same name provide supplemental information. If you're fond of extant implementations driving the argument, why won't you consider the dozens of extant SRVs that define TXT fields and already use them for exactly this purpose? Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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. My bigger concern is why you insist on wanting to play in the SRV sandbox and change the rules, but won't consider defining your own RR, or even your own service for lookup. You can't have it both ways - you cannot benefit from the distribution of stable code based on standards and declare that you aren't required to follow those standards. Frankly, I'm not sure that it's feasible to define a generic service location/selection facility (using DNS or LDAP or anything else) that will be applicable to a wide range of services. That's why I'm arguing against a Procrustean interpretation of the definition of the SRV RR (trying to make all apps fit into one bed, so to speak). Let the apps that can make good use of the SRV RR as it's defined do so even if they don't use labels the same way as specified in RFC 2782.Let the other apps define a way to use use TXT RRs, or define their own RRs. But I think the mechanism is almost inevitably going to need to be application-specific. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote: The issue is that if this document wants to go outside the spec, *it* needs to update RFC2782 - and survive the discussion that will incur. Well, in a pedantic sense I'm sure that's true. But it doesn't need to update RFC2782 as it pertains to anything but the ability to locate a certain subset of NFS-based services. It certainly doesn't have to change how SRV works with respect to other protocols. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 11:46 AM, Keith Moore wrote: On Sep 12, 2011, at 2:31 PM, Joe Touch wrote: The issue is that if this document wants to go outside the spec, *it* needs to update RFC2782 - and survive the discussion that will incur. Well, in a pedantic sense I'm sure that's true. But it doesn't need to update RFC2782 as it pertains to anything but the ability to locate a certain subset of NFS-based services. It certainly doesn't have to change how SRV works with respect to other protocols. That's trivially true for all protocol variations - they're all as local as you define them. But again if that's your goal - a ships-in-the-night variant - you should consider doing declaring a new RR type. That's the point of the RR type - to indicate when the interpretation of an RR changes. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi, Robert, On 9/12/2011 12:00 PM, Robert Thurlow wrote: Joe Touch wrote: Either this is an nfs service or it isn't. If it is, then it should be using _nfs._tcp.example.com, etc. If it isn't, then: a) a new service name is required which then *requires* b) a new port number be assigned This doesn't show any real understanding of what we're actually trying to do. To recap: We don't want to enumerate all NFS servers in a domain. That's what SRV records do. If that's not what you want, you should consider defining a new RR type. That is not an interesting enumeration. We want to find certain ones that are known to share a domain root (hence the syntax we chose). That can be accomplished as noted below. When we find those servers, we will talk NFSv4 to them (not a new service). And we will talk NFSv4 on port 2049 (not a new port). Your proposal above makes things worse in that it will no longer be clear what the SRV record means. It also ensures that we have a problem if we ever want to enumerate other subsets of NFS servers (none of which have been discussed). You can enumerate any subset of NFS servers you by differentiatiung them in the TXT records or Target fields. I.e., when you ask for nfs in a domain, you should get back the SRVs for all servers in that domain; further filtering should be done on the information returned by the client. To expect otherwise is to confuse the DNS with a true search engine. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi, Nico, On 9/12/2011 1:00 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.edu wrote: On 9/12/2011 12:00 PM, Robert Thurlow wrote: Joe Touch wrote: We don't want to enumerate all NFS servers in a domain. That's what SRV records do. If that's not what you want, you should consider defining a new RR type. No We don't want to enumerate *all* NFSv4 servers in a domain. We want to enumerate all NFSv4 domain-root servers in a domain. Slight difference. I know what you *want* to do. But short of assigning another port number for that capability and getting another service name, this simply isn't a service in the IANA service/port numbers sense, so I'm not surprised it doesn't uniquely map to SRV records. Now, if we only ever intended to discovery domain-root NFSv4 servers, then we could just follow RFC2782. But what if we want to add some new role like domain-root, but not domain-root, for NFSv4 servers? I suppose we could punt on this till then, but it seems unclean to do so -- it's much cleaner to denote the role of the server (domain root) in the RRset name. It's never clean to continually redefine the syntax of a structured record (SRV). The better solution is to add new fields to the TXT record, and filter on that. That's the point - the TXT record use with SRV is intended for all the stuff you might filter on or need for boot that isn't in the SRV record. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote: On 9/12/2011 11:46 AM, Keith Moore wrote: On Sep 12, 2011, at 2:31 PM, Joe Touch wrote: The issue is that if this document wants to go outside the spec, *it* needs to update RFC2782 - and survive the discussion that will incur. Well, in a pedantic sense I'm sure that's true. But it doesn't need to update RFC2782 as it pertains to anything but the ability to locate a certain subset of NFS-based services. It certainly doesn't have to change how SRV works with respect to other protocols. That's trivially true for all protocol variations - they're all as local as you define them. But again if that's your goal - a ships-in-the-night variant - you should consider doing declaring a new RR type. That's the point of the RR type - to indicate when the interpretation of an RR changes. You and I both know that RR types are limited in number, require significant time and effort to define, and can take many years to deploy to the point where applications can expect to use them. Which, I suppose, is why people keep trying to use SRV even for situations in which it's poorly suited - it's too much trouble to define and deploy a new one. I'm merely suggesting that the 2782 definition should be relaxed a bit and in a way that's compatible with existing DNS server code. Perhaps the appropriate thing to do is to publish a separate document that updates 2782 and explains this. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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? Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 1:17 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 3:08 PM, Joe Touchto...@isi.edu wrote: On 9/12/2011 1:00 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.eduwrote: On 9/12/2011 12:00 PM, Robert Thurlow wrote: No We don't want to enumerate *all* NFSv4 servers in a domain. We want to enumerate all NFSv4 domain-root servers in a domain. Slight difference. I know what you *want* to do. But short of assigning another port number for that capability and getting another service name, this simply isn't a service in the IANA service/port numbers sense, so I'm not surprised it doesn't uniquely map to SRV records. I don't think that's the correct way to go about this. I see nothing wrong with what's proposed. I say we let the LC run and see where we stand on consensus at the end. If we end up on the rough side of consensus, so be it -- in that case then I think we'd want to undertake an update of RFC2782, rather than bend to it. We want to do what's right. I believe have made my position on behalf of the TSVDIR clear. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 4:23 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 3:15 PM, Keith Moore mo...@network-heretics.com wrote: On Sep 12, 2011, at 3:50 PM, Joe Touch wrote: I think RFC 2782 inappropriately specified SRV RRs by defining both the label syntax and the RDATA syntax at the same time. I think we can all agree that RFC2782 is authoritative for the SRV RR RDATA specification. It can be no other way. The RRset name, OTOH, we could easily agree that RFC2782 is authoritative as to the construction of the RRset name for one use of SRV RRs. I don't see how RFC2782 can constrain forevermore the SRV RRset names, but quite clearly there's not much we could or should do to change the SRV RR RDATA specification (at most we could change the interpretation of some of the RDATA fields in some circumstances, but not the RDATA format itself). Now, IF the IETF consensus is that we must update RFC2782 in spite of the many SRV RR uses that exist which do not match the RFC2782 RRset naming convention, well, fine, we can do that -- it's not a big deal, only a small delay. But until then my position is that we do not have to do this. +1 Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 1:20 PM, Keith Moore wrote: On Sep 12, 2011, at 3:50 PM, Joe Touch wrote: On 9/12/2011 11:46 AM, Keith Moore wrote: On Sep 12, 2011, at 2:31 PM, Joe Touch wrote: The issue is that if this document wants to go outside the spec, *it* needs to update RFC2782 - and survive the discussion that will incur. Well, in a pedantic sense I'm sure that's true. But it doesn't need to update RFC2782 as it pertains to anything but the ability to locate a certain subset of NFS-based services. It certainly doesn't have to change how SRV works with respect to other protocols. That's trivially true for all protocol variations - they're all as local as you define them. But again if that's your goal - a ships-in-the-night variant - you should consider doing declaring a new RR type. That's the point of the RR type - to indicate when the interpretation of an RR changes. You and I both know that RR types are limited in number, require significant time and effort to define, and can take many years to deploy to the point where applications can expect to use them. Which, I suppose, is why people keep trying to use SRV even for situations in which it's poorly suited - it's too much trouble to define and deploy a new one. Maybe they use this because it works too. I'm merely suggesting that the 2782 definition should be relaxed a bit and in a way that's compatible with existing DNS server code. Perhaps the appropriate thing to do is to publish a separate document that updates 2782 and explains this. Start there (but it will be an uphill battle, vs. creating a new RR), but then this doc would be held until that change occurs AFAICT. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 1:23 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 3:15 PM, Keith Mooremo...@network-heretics.com wrote: On Sep 12, 2011, at 3:50 PM, Joe Touch wrote: I think RFC 2782 inappropriately specified SRV RRs by defining both the label syntax and the RDATA syntax at the same time. I think we can all agree that RFC2782 is authoritative for the SRV RR RDATA specification. It can be no other way. The RRset name, OTOH, we could easily agree that RFC2782 is authoritative as to the construction of the RRset name for one use of SRV RRs. I don't see how RFC2782 can constrain forevermore the SRV RRset names, but quite clearly there's not much we could or should do to change the SRV RR RDATA specification (at most we could change the interpretation of some of the RDATA fields in some circumstances, but not the RDATA format itself). The original DNS spec declared the valid RRset syntax until RFC 2782 changed it for that RR type. *That* is the precedent. If you want another RRset syntax, then you need another RR type IMO. That's the only way to ensure that new RRset syntaxes (or RDATA syntaxes) will work in all implementations anyway. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi, Keith, On 9/12/2011 1:42 PM, Keith Moore wrote: 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. Yes - it was defined that way. 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. Yes - this has been a persistent problem in the IANA service/port registry. Here's where we are today: service = L5-L7 inclusive transport = L4 It would be useful to have a richer way to describe services, which could include: - late-binding of transport (or even network) - layering of protocols e.g., CMD-over-SOAP-over-HTML-over-SSL - out-of-band service bootstrap info - richer descriptions of service variants that support richer searches than DNS supports Any of these requires an overhaul to the IANA notion of services and port numbers, as well as SRV records. 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. Port numbers are inherently meaningful only between pairs of consenting endpoints. The ability to indicate the local map of service:port seems entirely appropriate in an E2E sense. Further, it avoids the burden of pre-allocating port numbers (a quite constrained resource) for services that might never be used at a given endpoint, and allows that map to be assigned dynamically and locally. Consider that the DNS distributed /etc/hosts, and basically SRVs distribute /etc/services Or would your arguments against SRV use also apply to the DNS? :-) 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. OK. So basically you claim that new RR types are bad because they are defined in a way that doesn't do what you want. But then you want to change SRVs - for the same reason you don't want a new RR type. Again, I remain confused as to your position. My claim is that: SRVs represent services as they are currently assigned by IANA a new RR could be useful for things that aren't sufficiently expressible in the IANA service/port registry Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 4:57 PM, Joe Touch wrote: 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. Yes - it was defined that way. It was defined poorly, based on assumptions that were already disconnected from reality and have become even moreso over time. It would be useful to have a richer way to describe services, which could include: - late-binding of transport (or even network) - layering of protocols e.g., CMD-over-SOAP-over-HTML-over-SSL - out-of-band service bootstrap info - richer descriptions of service variants that support richer searches than DNS supports Any of these requires an overhaul to the IANA notion of services and port numbers, as well as SRV records. It's not clear to me that this would actually be useful, or to put it another way, that defining such a service description mechanism would solve more problems than it creates. Yes there are corner cases where something like this would be nice. But do we really need a generic mechanism that encourages so much agility? Do we want the additional complexity and degraded reliability that would inevitably go along with it? 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. Port numbers are inherently meaningful only between pairs of consenting endpoints. Mumble. I'd argue that in the case of SMTP at least that port 25 is much more significant than that. Sure, any given SMTP session could potentially occur over a different port as long as client and server had some mechanism for agreeing to use it. But the worldwide basis for exchange of email is that MX servers for a domain listen on port 25, and clients know to use port 25 to contact them. The ability to indicate the local map of service:port seems entirely appropriate in an E2E sense. Actually it breaks the E2E model, by introducing the potential for a third party (in the form of a NAT + DNS server) that expects to be able to mediate between client and server. Further, it avoids the burden of pre-allocating port numbers (a quite constrained resource) for services that might never be used at a given endpoint, and allows that map to be assigned dynamically and locally. Yes, it does that, and I agree that pre-allocated port numbers are precious. Though I think this particular mechanism causes more problems than it solves. Consider that the DNS distributed /etc/hosts, and basically SRVs distribute /etc/services /etc/services is itself a dubious idea. When a protocol specification defines a constant port to be used (even if just as a default), and /etc/services purports to override that, that extra layer of indirection harms interoperability.I remember a time when the MTA for my mail domain dropped a significant amount of mail on the floor because getservbyname(smtp, tcp) failed (it was implemented in terms of NIS). I immediately changed the code to replace that line with htons(25), and it never failed again. Since then, I never use getservbyname when implementing protocol engines, because it's simply wrong to do so. (Disclaimer: I do use /etc/services as documentation. e.g. when I want to know which port a particular protocol uses, it's easier to grep /etc/services than it is to look up the port number in the IANA registry. I just don't use getservbyname whenever I can help doing so.) Or would your arguments against SRV use also apply to the DNS? :-) In general, there's an unfortunate potential for DNS to get out of sync with reality. DNS as it was originally designed made more sense when all hosts were large boxes that required a significant portion of a room and dedicated air conditioning and power, and thus were mostly immobile. It's not such a good fit for PCs and even less applicable to mobile hosts. My preferred way to use DNS for mobile hosts is to have each host be its own authoritative DNS/LLMNR server, with its domains explicitly delegated to it by its parent zones, and replicated from there to secondary servers with stable IP addresses. That way, the master copy is always in sync with reality, DNS and LLMNR are always in sync, and the replica copies of the zone are always in sync with the master
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 2:39 PM, Keith Moore wrote: On Sep 12, 2011, at 4:57 PM, Joe Touch wrote: 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. Yes - it was defined that way. It was defined poorly, based on assumptions that were already disconnected from reality and have become even moreso over time. It would be useful to have a richer way to describe services, which could include: - late-binding of transport (or even network) - layering of protocols e.g., CMD-over-SOAP-over-HTML-over-SSL - out-of-band service bootstrap info - richer descriptions of service variants that support richer searches than DNS supports Any of these requires an overhaul to the IANA notion of services and port numbers, as well as SRV records. It's not clear to me that this would actually be useful, or to put it another way, that defining such a service description mechanism would solve more problems than it creates. Yes there are corner cases where something like this would be nice. But do we really need a generic mechanism that /encourages/ so much agility? Do we want the additional complexity and degraded reliability that would inevitably go along with it? Again I'm confused. You claim there's a clear need to revise SRV syntax, but not the registry that basically defines that syntax? If you don't need a generic mechanism with agility, just use TXT records and move on IMO. That's what most other SRV users *have already done*. If you insist on a clean, generic, system that solves this problem for nfsv4 domain-root and other similar cases, you're clearly arguing for the deep slog of fixing this throughout the IETF. 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. Port numbers are inherently meaningful only between pairs of consenting endpoints. Mumble. I'd argue that in the case of SMTP at least that port 25 is much more significant than that. Sure, any given SMTP session could potentially occur over a different port as long as client and server had some mechanism for agreeing to use it. But the worldwide basis for exchange of email is that MX servers for a domain listen on port 25, and clients know to use port 25 to contact them. The worldwide default for services with assigned ports is to assume that port number. The worldwide system for doing otherwise is SRV records. Either one works fine, and either one assumes that both sides make the same assumption. SMTP is not unique in this sense. The only port that is difficult to change is the DNS. You need to *know* that for the host on which the DNS resides for the endpoints you want to contact before contacting them. The ability to indicate the local map of service:port seems entirely appropriate in an E2E sense. Actually it breaks the E2E model, by introducing the potential for a third party (in the form of a NAT + DNS server) that expects to be able to mediate between client and server. That third party could be at the same endpoint as the destination; in that case you'd be using that endpoint's DNS to bootstrap other services. Moving that capability to a separate location does compromise E2E, but the ability to remap ports has nothing to do with it per se. Endpoints already can (and do) assume services on ports other than their IANA defaults, e.g. The point is that this is an endpoint decision, under control of the endpoints. Yes, it'd be nice to late-bind that without an SRV lookup. I wrote a TCP option about that a while back (port names), and there are other similar mechanisms that don't use the DNS (TCPMUX). Further, it avoids the burden of pre-allocating port numbers (a quite constrained resource) for services that might never be used at a given endpoint, and allows that map to be assigned dynamically and locally. Yes, it does that, and I agree that pre-allocated port numbers are precious. Though I think this particular mechanism causes more problems than it solves. I don't disagree; I would prefer port-names (for those not familiar, the idea was to use the IANA service names as a TCP option in the SYN packet, and to demux to the service based on that name string rather than the incoming port). Consider that the DNS distributed /etc/hosts, and basically SRVs distribute
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 2:43 PM, Nico Williams wrote: On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote: My claim is that: SRVs represent services as they are currently assigned by IANA a new RR could be useful for things that aren't sufficiently expressible in the IANA service/port registry Existence proofs show that this is not *actually* so. The existence proof is that many SRV names have defined TXT fields, including the following: ftp sftp-ssh ssh telnet http nfs (already defines path to the mount point) qttp (quicktime) webdav It's only what RFC2782 was aiming for. Time has passed. That ship has sailed. Seems like that ship sails just fine. There are bigger issues with widescale SRV use, but the use of associated TXT records isn't one of them as far as I've seen. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 3:33 PM, Spencer Shepler wrote: ... The existence proof is that many SRV names have defined TXT fields, including the following: ftp sftp-ssh ssh telnet http nfs (already defines path to the mount point) Interesting; do you have a reference for that one? Spencer http://dns-sd.org/ServiceTypes.html The IANA service/ports registry is supposed to include everything here, but does not as yet (they're working on it). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 6:23 PM, Joe Touch wrote: Again I'm confused. You claim there's a clear need to revise SRV syntax, but not the registry that basically defines that syntax? I don't claim that there's a clear need to revise the syntax of the RDATA. I claim that the syntax defined in RFC 2782 for the domains used with SRV RRs is relevant only when SRV is used as anticipated in RFC 2782... which is to say, almost never. If you don't need a generic mechanism with agility, just use TXT records and move on IMO. That's what most other SRV users *have already done*. Given that I think service location is almost inherently application-specific anyway, that solution is also fine with me. I don't know what value is added by SRV, other than confusion. If you insist on a clean, generic, system that solves this problem for nfsv4 domain-root and other similar cases, you're clearly arguing for the deep slog of fixing this throughout the IETF. Eventually yes. But I'm also arguing against holding up this document for reasons that seem to me to be pedantic. Port numbers are inherently meaningful only between pairs of consenting endpoints. Mumble. I'd argue that in the case of SMTP at least that port 25 is much more significant than that. Sure, any given SMTP session could potentially occur over a different port as long as client and server had some mechanism for agreeing to use it. But the worldwide basis for exchange of email is that MX servers for a domain listen on port 25, and clients know to use port 25 to contact them. The worldwide default for services with assigned ports is to assume that port number. yes. The worldwide system for doing otherwise is SRV records. no. Either one works fine, and either one assumes that both sides make the same assumption. SMTP is not unique in this sense. False. SRV records are poorly designed and broken for several reasons already cited. And SMTP is somewhat unique in that it doesn't make sense to think of it entirely in terms of pairwise connections. The only port that is difficult to change is the DNS. You need to *know* that for the host on which the DNS resides for the endpoints you want to contact before contacting them. Using DNS to look up the port number opens Pandora's box and creates a great many opportunities for failure as well as encouraging pollution of the architecture. The ability to indicate the local map of service:port seems entirely appropriate in an E2E sense. Actually it breaks the E2E model, by introducing the potential for a third party (in the form of a NAT + DNS server) that expects to be able to mediate between client and server. That third party could be at the same endpoint as the destination; in that case you'd be using that endpoint's DNS to bootstrap other services. Moving that capability to a separate location does compromise E2E, but the ability to remap ports has nothing to do with it per se. In abstract theory, perhaps. But in practice, you and I both know that there continues to be considerable pressure to impose additional layers of NAT and prolong use of IPv4. Endpoints already can (and do) assume services on ports other than their IANA defaults, e.g. The point is that this is an endpoint decision, under control of the endpoints. In many cases it's purely an endpoint decision. Not all of them. Further, it avoids the burden of pre-allocating port numbers (a quite constrained resource) for services that might never be used at a given endpoint, and allows that map to be assigned dynamically and locally. Yes, it does that, and I agree that pre-allocated port numbers are precious. Though I think this particular mechanism causes more problems than it solves. I don't disagree; I would prefer port-names (for those not familiar, the idea was to use the IANA service names as a TCP option in the SYN packet, and to demux to the service based on that name string rather than the incoming port). I identified several issues with port-names at the time you made that proposal. One of the bigger problems IIRC was that they assumed that there could only be one service with a particular name on a particular host, when these days virtual hosts (by which I mean multiple services acting on behalf of different domains all supported by the same physical host) are quite common, and the notion of host has become fairly blurry. I also think that IANA service names as currently defined are not a reasonable constraint to impose. But in general I'd like to find a way to escape the 2^16 limitation on port numbers, and I think that that area deserves further study. Consider that the DNS distributed /etc/hosts, and basically SRVs distribute /etc/services /etc/services is itself a dubious idea. When a protocol specification defines a constant port to be used (even if just as a default), and /etc/services purports to override that, that extra
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On 9/12/2011 3:49 PM, Keith Moore wrote: On Sep 12, 2011, at 6:23 PM, Joe Touch wrote: Again I'm confused. You claim there's a clear need to revise SRV syntax, but not the registry that basically defines that syntax? I don't claim that there's a clear need to revise the syntax of the RDATA. I claim that the syntax defined in RFC 2782 for the domains used with SRV RRs is relevant only when SRV is used as anticipated in RFC 2782... which is to say, almost never. If you don't need a generic mechanism with agility, just use TXT records and move on IMO. That's what most other SRV users *have already done*. Given that I think service location is almost inherently application-specific anyway, that solution is also fine with me. I don't know what value is added by SRV, other than confusion. SRV indicates the port number (useful if not the default) and weight, etc. If that's not what you want, just use the corresponding TXT record, but include a field that indicates whether this is the correct record (e.g., domain-root). If you insist on a clean, generic, system that solves this problem for nfsv4 domain-root and other similar cases, you're clearly arguing for the deep slog of fixing this throughout the IETF. Eventually yes. But I'm also arguing against holding up this documentfor reasons that seem to me to be pedantic. All protocol specs are pedantic. The way to avoid holding this doc up, IMO, is to use SRV records as they're currently used - with TXT records where additional info is needed. ... The worldwide default for services with assigned ports is to assume that port number. yes. The worldwide system for doing otherwise is SRV records. no. I'll let Apple know. Either one works fine, and either one assumes that both sides make the same assumption. SMTP is not unique in this sense. False. SRV records are poorly designed and broken for several reasonsalready cited. And SMTP is somewhat unique in that it doesn't make sense to think of it entirely in terms of pairwise connections. What exactly isn't pairwise about mail relay? The only port that is difficult to change is the DNS. You need to *know* that for the host on which the DNS resides for the endpoints you want to contact before contacting them. Using DNS to look up the port number opens Pandora's box and creates a great many opportunities for failure as well as encouraging pollution of the architecture. Good. Then stop using SRV records. That's what they're for, in case it was at all vague in RFC 2782. (NAT discussion omitted - NATs break SRV use anyway) Further, it avoids the burden of pre-allocating port numbers (a quite constrained resource) for services that might never be used at a given endpoint, and allows that map to be assigned dynamically and locally. Yes, it does that, and I agree that pre-allocated port numbers are precious. Though I think this particular mechanism causes more problems than it solves. I don't disagree; I would prefer port-names (for those not familiar, the idea was to use the IANA service names as a TCP option in the SYN packet, and to demux to the service based on that name string rather than the incoming port). I identified several issues with port-names at the time you made that proposal. One of the bigger problems IIRC was that they assumed that there could only be one service with a particular name on a particular host, when these days virtual hosts (by which I mean multiple services acting on behalf of different domains all supported by the same physical host) are quite common, and the notion of host has become fairly blurry. Talk about breaking E2E. You are confusing a port with an endpoint ID. ... ... New RR types are what they are. Some are inevitably defined better than others. For the specific case of SRV, I don't think the RR was well defined. But DNS is not as extensible as we'd like, new RR types are scarce and difficult to deploy, and so there's some weight to the idea that we should make do with what we have whenever it doesn't break anything. RIGHT! Which is why using TXT records with SRVs - which is what most other SRV users do when they need OOB info - is the right way to go. Nah, if you're going to use TXT records, don't bother with SRVs. Avoid the extra lookup and the resulting hit in latency and reliability. If you already know the port number, there's nothing that prevents you from doing this, FWIW. If DNS would reliably let you get both RR types in a single query, that would be fine, but it doesn't. So go fix *that*. ;-) Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 7:06 PM, Joe Touch wrote: Given that I think service location is almost inherently application-specific anyway, that solution is also fine with me. I don't know what value is added by SRV, other than confusion. SRV indicates the port number (useful if not the default) and weight, etc. right. but given that you can include the same things in a TXT record, if you have to query for TXT RRs anyway, what's the value added by doing an additional query for SRV RRs? If you insist on a clean, generic, system that solves this problem for nfsv4 domain-root and other similar cases, you're clearly arguing for the deep slog of fixing this throughout the IETF. Eventually yes. But I'm also arguing against holding up this documentfor reasons that seem to me to be pedantic. All protocol specs are pedantic. Perhaps, but their interpretations don't have to be pedantic. The way to avoid holding this doc up, IMO, is to use SRV records as they're currently used - with TXT records where additional info is needed. Your notion of currently seems like a stretch. My understanding is that they're currently used in several different ways, the RFC notwithstanding. The worldwide default for services with assigned ports is to assume that port number. yes. The worldwide system for doing otherwise is SRV records. no. I'll let Apple know. Thanks. :) Either one works fine, and either one assumes that both sides make the same assumption. SMTP is not unique in this sense. False. SRV records are poorly designed and broken for several reasonsalready cited. And SMTP is somewhat unique in that it doesn't make sense to think of it entirely in terms of pairwise connections. What exactly isn't pairwise about mail relay? Right now, if you want to be able to receive mail reliably, you have to have an MX which listens on port 25. If you want to send mail across administrative boundaries, in general, you have to be able to send to port 25. There's no way to do pairwise port negotiation. Of course, in some hypothetical other world with a slightly different mail protocol, the problem could be solved differently. The only port that is difficult to change is the DNS. You need to *know* that for the host on which the DNS resides for the endpoints you want to contact before contacting them. Using DNS to look up the port number opens Pandora's box and creates a great many opportunities for failure as well as encouraging pollution of the architecture. Good. Then stop using SRV records. That's what they're for, in case it was at all vague in RFC 2782. I'd be very happy to see SRV records deprecated, or at least discouraged, for new protocols. Further, it avoids the burden of pre-allocating port numbers (a quite constrained resource) for services that might never be used at a given endpoint, and allows that map to be assigned dynamically and locally. Yes, it does that, and I agree that pre-allocated port numbers are precious. Though I think this particular mechanism causes more problems than it solves. I don't disagree; I would prefer port-names (for those not familiar, the idea was to use the IANA service names as a TCP option in the SYN packet, and to demux to the service based on that name string rather than the incoming port). I identified several issues with port-names at the time you made that proposal. One of the bigger problems IIRC was that they assumed that there could only be one service with a particular name on a particular host, when these days virtual hosts (by which I mean multiple services acting on behalf of different domains all supported by the same physical host) are quite common, and the notion of host has become fairly blurry. Talk about breaking E2E. You are confusing a port with an endpoint ID. You might have an easier time understanding what I'm saying, if you weren't so busy trying to prove to yourself that I'm confused. New RR types are what they are. Some are inevitably defined better than others. For the specific case of SRV, I don't think the RR was well defined. But DNS is not as extensible as we'd like, new RR types are scarce and difficult to deploy, and so there's some weight to the idea that we should make do with what we have whenever it doesn't break anything. RIGHT! Which is why using TXT records with SRVs - which is what most other SRV users do when they need OOB info - is the right way to go. Nah, if you're going to use TXT records, don't bother with SRVs. Avoid the extra lookup and the resulting hit in latency and reliability. If you already know the port number, there's nothing that prevents you from doing this, FWIW. Or if you really need to support arbitrary ports, just encode the port number in the TXT record. If DNS would reliably let you get both RR types in a single query, that would be fine, but it doesn't. So go fix *that*. ;-) If
TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This document describes the use of DNS SRV records to coordinate NFS4 use and a global file namespace across a groups of clients and servers. There are no transport protocol issues in this document. The key transport issue is the definition of a new DNS SRV record and its associated syntax. There are issues with the intended syntax of the proposed DNS SRV record. The current syntax is defined in RFC 2782 as: _service._transport.NAME service is an IANA SRV name, the namespace of which is defined in RFC 6335 transport is _TCP or _UDP NAME is a DNS FQDN Given other considerations below (on versioning), the record should be one of the following _nfs._tcp.example.com TTL Class SRV Priority Weight Port Target _nfs._udp.example.com TTL Class SRV Priority Weight Port Target All other information specific to the exchange, e.g., organization (which may or may not be a suffix of the Target, FWIW), desired mount point, and various NFS-specific capabilities (e.g., mount options) ought to be expressed in an associated TXT record as defined fields, as is the case with other services that use SRV records. These options can have defaults if not otherwise present. Some other issues are discussed below. Overall, the above is the key concern, and needs to be addressed before proceeding. Issues below are indicated as either critical or suggestions for clarification. Joe Critical issues: - the IANA section is incomplete This document needs to request IANA assign an SRV service name, e.g.: SRV nfs TCP SRV nfs UDP It is not clear whether an additional assignment of SRV nfs SCTP is required; recent discussions on other SCTP SRV uses suggest that UDP is indexed in these cases instead. This might warrant further discussion. - the service name should not include the version number As per RFC 6335, and to be consistent with the existing port assignments for NFS Version 4. - the discussion of list of organizations as with root.afs should be described in a little more detail The current sentence is a bit cryptic; this could be a full paragraph, perhaps with an example. - there is no appropriate place to indicate write vs read-only in the DNS request The DNS request should return all available options, and indicate write vs. read-only in the associated TXT records. The client should then determine which is desired. -- Other issues (intended as suggestions): - version 4 Throughout this document, version 4 is used wherever NFS is used. Since V4 (more specifically, 4.1) is the current common version, it does not seem necessary to include this marking in most places except where differences in the NFS versions are being highlighted. - colloquial advice Terms like appropriate and useful should be removed throughout. They represent judgements whose evaluation criteria is not discussed. - overall writing style The document is written in the tense and style of a proposal. It should be revised to read as the intended specification it will become. We propose and We use, and similar styles should be replaced with this document specifies and this record uses. - clarify overloaded terms Terms like root and name space are widely used in different ways in the DNS and file systems. Because this document combines the two, each use should be clarified by a preceding term, e.g., DNS name space or file system name space, DNS root or file system root. - the use of RFC 2119 terms should be reviewed In particular, SHOULD should be used only where a specific exception is currently known or suspected, and that exception described. This provides the motivation for the selection of SHOULD vs. MAY or MUST. - the discussion of client vs server implementation (sec 4.3, as well as partly in sec 4.2) should consider client-specific DNS responses The DNS could provide responses that vary based on the IP of the client. This could be a desirable feature. Further, the client knows whether it wants write or read-write copies. AFAICT, the client is not only the better place to implement this capability, it is the only viable place. - I found the hidden directory name discussion odd It does not make sense to overload read-only with directory visibility; these are orthogonal issues. The desired mount point should be indicated in the TXT record; if a default convention is desired, it should be indicated in the
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
I've always thought that insistence on the use of RFC 2782 labels with SRV records unreasonably overconstrained the use of SRV records; and thus, limited their applicability. Part of the problem, I suspect, is that at the time that 2782 was being drafted there may have been some belief that SRV records could reasonably be retroactively applied to all existing protocols, and thus there would be a need for a uniform syntax for DNS labels used with SRV records. But if (as is IMO appropriate) SRV records are only used with applications that are specified to use them, there is little benefit for the format of DNS labels used with SRV to be uniform across all uses of SRV. (I won't say no benefit. A DNS API designed to facilitate easy SRV record lookup might benefit from a standard label syntax, but even then, it would make more sense to not embed that knowledge in the API and let the application construct the label to be queried.) So IMO all uses of SRV records should not be constrained to use RFC 2782 DNS labels. Keith On Sep 11, 2011, at 4:12 PM, Joe Touch wrote: Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This document describes the use of DNS SRV records to coordinate NFS4 use and a global file namespace across a groups of clients and servers. There are no transport protocol issues in this document. The key transport issue is the definition of a new DNS SRV record and its associated syntax. There are issues with the intended syntax of the proposed DNS SRV record. The current syntax is defined in RFC 2782 as: _service._transport.NAME service is an IANA SRV name, the namespace of which is defined in RFC 6335 transport is _TCP or _UDP NAME is a DNS FQDN Given other considerations below (on versioning), the record should be one of the following _nfs._tcp.example.com TTL Class SRV Priority Weight Port Target _nfs._udp.example.com TTL Class SRV Priority Weight Port Target All other information specific to the exchange, e.g., organization (which may or may not be a suffix of the Target, FWIW), desired mount point, and various NFS-specific capabilities (e.g., mount options) ought to be expressed in an associated TXT record as defined fields, as is the case with other services that use SRV records. These options can have defaults if not otherwise present. Some other issues are discussed below. Overall, the above is the key concern, and needs to be addressed before proceeding. Issues below are indicated as either critical or suggestions for clarification. Joe Critical issues: - the IANA section is incomplete This document needs to request IANA assign an SRV service name, e.g.: SRV nfs TCP SRV nfs UDP It is not clear whether an additional assignment of SRV nfs SCTP is required; recent discussions on other SCTP SRV uses suggest that UDP is indexed in these cases instead. This might warrant further discussion. - the service name should not include the version number As per RFC 6335, and to be consistent with the existing port assignments for NFS Version 4. - the discussion of list of organizations as with root.afs should be described in a little more detail The current sentence is a bit cryptic; this could be a full paragraph, perhaps with an example. - there is no appropriate place to indicate write vs read-only in the DNS request The DNS request should return all available options, and indicate write vs. read-only in the associated TXT records. The client should then determine which is desired. -- Other issues (intended as suggestions): - version 4 Throughout this document, version 4 is used wherever NFS is used. Since V4 (more specifically, 4.1) is the current common version, it does not seem necessary to include this marking in most places except where differences in the NFS versions are being highlighted. - colloquial advice Terms like appropriate and useful should be removed throughout. They represent judgements whose evaluation criteria is not discussed. - overall writing style The document is written in the tense and style of a proposal. It should be revised to read as the intended specification it will become. We propose and We use, and similar styles should be replaced with this document specifies and this record uses. - clarify overloaded terms Terms like root and name space are widely used in
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
Hi Keith, On 9/11/2011 1:22 PM, Keith Moore wrote: I've always thought that insistence on the use of RFC 2782 labels with SRV records unreasonably overconstrained the use of SRV records; and thus, limited their applicability. Part of the problem, I suspect, is that at the time that 2782 was being drafted there may have been some belief that SRV records could reasonably be retroactively applied to all existing protocols, and thus there would be a need for a uniform syntax for DNS labels used with SRV records. But if (as is IMO appropriate) SRV records are only used with applications that are specified to use them, there is little benefit for the format of DNS labels used with SRV to be uniform across all uses of SRV. (I won't say no benefit. A DNS API designed to facilitate easy SRV record lookup might benefit from a standard label syntax, but even then, it would make more sense to not embed that knowledge in the API and let the application construct the label to be queried.) So IMO all uses of SRV records should not be constrained to use RFC 2782 DNS labels. 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? Joe On Sep 11, 2011, at 4:12 PM, Joe Touch wrote: Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This document describes the use of DNS SRV records to coordinate NFS4 use and a global file namespace across a groups of clients and servers. There are no transport protocol issues in this document. The key transport issue is the definition of a new DNS SRV record and its associated syntax. There are issues with the intended syntax of the proposed DNS SRV record. The current syntax is defined in RFC 2782 as: _service._transport.NAME service is an IANA SRV name, the namespace of which is defined in RFC 6335 transport is _TCP or _UDP NAME is a DNS FQDN Given other considerations below (on versioning), the record should be one of the following _nfs._tcp.example.com TTL Class SRV Priority Weight Port Target _nfs._udp.example.com TTL Class SRV Priority Weight Port Target All other information specific to the exchange, e.g., organization (which may or may not be a suffix of the Target, FWIW), desired mount point, and various NFS-specific capabilities (e.g., mount options) ought to be expressed in an associated TXT record as defined fields, as is the case with other services that use SRV records. These options can have defaults if not otherwise present. Some other issues are discussed below. Overall, the above is the key concern, and needs to be addressed before proceeding. Issues below are indicated as either critical or suggestions for clarification. Joe Critical issues: - the IANA section is incomplete This document needs to request IANA assign an SRV service name, e.g.: SRV nfs TCP SRV nfs UDP It is not clear whether an additional assignment of SRV nfs SCTP is required; recent discussions on other SCTP SRV uses suggest that UDP is indexed in these cases instead. This might warrant further discussion. - the service name should not include the version number As per RFC 6335, and to be consistent with the existing port assignments for NFS Version 4. - the discussion of list of organizations as with root.afs should be described in a little more detail The current sentence is a bit cryptic; this could be a full paragraph, perhaps with an example. - there is no appropriate place to indicate write vs read-only in the DNS request The DNS request should return all available options, and indicate write vs. read-only in the associated TXT records. The client should then determine which is desired. -- Other issues (intended as suggestions): - version 4 Throughout this document, version 4 is used wherever NFS is used. Since V4 (more specifically, 4.1) is the current common version, it does not seem necessary to include this marking in most places except where differences in the NFS versions are being highlighted. - colloquial advice Terms like appropriate and useful should be removed throughout.
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
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. If you're looking for a more generic database query system, you might consider using LDAP rather than the DNS. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
