On Sep 13, 2011, at 7:38 AM, Cullen Jennings <fluffy(_at_)cisco(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf