On Sep 13, 2011, at 7:38 AM, Cullen Jennings <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
