Taking another look at this now that the IETF dust has settled. First, when I wrote my earlier note on the 21st, I had just glanced through the spec, not studied it, and was under the impression that either the SRV entries and registry would not be affected or that all entries in the SRV registry would be folded into the new one. The former would be fine, the latter plausible if it could be done smoothly but I gather there are reasons why it cannot.
Two additional, possibly more important, thoughts after reading -05 more closely... (1) The introductory material in the I-D seems to imply that use of labels styled with "_" is a reasonable alternative to creating a new label type. My impression has been that, while there is nothing we can change about what is done and deployed, there has been community consensus that it is a bad idea and that changes have been made to the procedures for defining and registering new RRTYPEs to reinforce the principle that new RRTYPEs should be used and to make their use easier. "Significantly challenging over the life of the DNS" is undoubtedly correct, but that should not be, and presumably is not, the situation today or in recent years. I believe this document should not be advanced until that material is changed to be clear that use of underscore or similar conventions may be a reality but is not a desirable substitute for separate RRTYPEs (with or without that convention as appropriate). (2) I'd encourage people to think through another possibility. I'm not sure it is the right answer, but it is worth more consideration than this draft (at least at -05) appears to be giving it. The issues associated with QTYPE=ANY notwithstanding, it is not clear to me that the set of labels starting with "_" constitute a namespace, any more than the set of labels starting with "xn--" do. It is just a naming convention that identifies the labels as keywords with defined meaning. From that point of view, namespaces are actually per-RRTYPE and the right way to design this document would be as a registry of "_"-introduced keywords, with subregistries for each RRTYPE with which those keywords can be used. Given the way the DNS works, at least as I understand it, there is no DNS protocol conflict between _foo IN XYZ Data1 and _foo IN ABC Data2 Using the same keyword in both cases may be a bad idea but the zone files don't care and, given that queries are typically made for QNAME and QTYPE (etc.) and not the name alone (i.e., with QTYPE=ANY) except for other purposes, I see some advantages of [sub]registry-per-RRTYPE rather than pretending that every label starting with "_" is the same namespace. Of course, one of them is that there is no need to treat SRV as a special, legacy, case or even debate that. The coverage of the current document would be simply a subregistry for SRV (reorganized from the current registry, but that is simply an IANA organizational matter, not a change to what is registered, protocols, etc., plus a subregistry for RRTYPE=TXT and provisions for other subregistries as might be needed in the future. Organizing things that way would have at least one additional advantage: while FCFS may be appropriate for some RRTYPEs, other procedures may be appropriate for others. In a way, SRV is a good example of that distinction. Again, that might not be the right thing to do on balance, but I think it should be examined carefully as an alternative to trying to treat "everything starting with '_' as long as it occupies a particular place in the tree" as a namespace. best, john _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop