--On Monday, March 26, 2018 09:44 +0100 "John R. Levine" <jo...@iecc.com> wrote:
>... >>> i have reproduced your entire second suggestion here, >>> because i think it's solid. rrset atomicity means you're >>> right, and that underbar'ed labels need only be unique >>> within an RRTYPE, and any registry of such labels can and >>> therefore should be per-RRTYPE. > > Technically, you are completely correct. But since the > namespace is in effect infinite I would just as soon not have > to explain to anyone why _foo for SRV means the same thing as > _foo for URI but different from _foo for TXT. As we've seen > it's hard enough to understand the separate second level > underscore namespaces and we're stuck with them. Ah, but pulling them together into one registry is our old problem, in disguise, of trying to control behavior by what we allow to be registered. If, for example, I'm stupid enough to use "_tcp" as the label of a TXT RR, a single registration tree won't stop me or cause any DNS problems, it will just help me add to the confusion. If they are separated, I'm at least marginally encouraged to document what I'd doing. At least as I see it, the purpose of a registry like this is to help non-stupid people avoid conflicts and to provide documentation pointers for information about the keywords. Especially if the registry is not expected to grow to a huge number of entries, asking IANA to create an alphabetical index of all label keywords (I'm resisting "_Node Name" because I don't believe this is really a namespace) that could link names to particular subregistries (possibly more than one) would not be a big deal. By contrast, Table 1 of the I-D is +-------------+-----+------------+ | _NODE NAME | RR | REFERENCE | +-------------+-----+------------+ | _tcp | SRV | [RFC2782] | | _udp | SRV | [RFC2782] | | _sctp | SRV | [RFC2782] | | _dccp | SRV | [RFC2782] | | _domainkey | TXT | [RFC6376] | | _spf | TXT | [RFC7208] | | _dmarc | TXT | [RFC7489] | | _vouch | TXT | [RFC5518] | +-------------+-----+------------+ While not very large, it is sorted by RRTYPE and then not sorted in any obvious way. Were it to grow significantly, one would either want the same sort of index or would want to sort it by label string ("_Node name") and then create an index by RRTYPE. If we are going to separate "SRV" out, as you and several other have argued is necessary, we've got two separate registries already -- SRV and "everything else", with the latter consisting exclusively of TXT. So, again, going to two subregistries and provision for expansion from a table that is halfway there anyway does not seem to me to be a big deal while being closer to the reality of the DNS (as Paul explained better than I could). best, john _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop