On Sep 13, 2011, at 7:38 AM, Cullen Jennings <fluffy@xxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf