John R. Levine wrote:
Catching up:
...
if you view the use of _tcp by more than one rrtype as a coincidence
rather than as evidence for the need for a registry, then we can
simply define the global registry out of existence (where it has been
until now) and ensure that every rrtype's registry of "_" names is
public and easily found on the IANA web site.
I don't think it's a coincidence, but as you noted people will do what
they do. One registry should make it easier for sensible people to look
and say aha, _foo already means something for BAR records so I will use
a different name for unrelated tags for BAZ records. Or for unsensible
people, we can at least be aware of what they do.
in one sense there is a registry but in another sense there are
registries for each RR type whose applications will use underscored
names for extended subtyping.
what this means is, if someone sees _TCP in use for some rr type, and
they needed something like this for their own new rr type, they should
be encouraged to either use _TCP if they find it's the best fit, or use
something else if they find that a best fit. they should not worry
either away about either reusing, or not reusing, an existing name.
so while i agree that having a set of per-type registries will inform
future application developers, my expected use case is the opposite of
what you said here.
it's vital that the relevant technical constraint be restated at every
level of underscore documentation, and that is, there is no relationship
other than coincidence between a given _LABEL used by one rr type and
that same label used by some other rr type. i know that we think of
names having rrsets, and they do; however, in practical terms of whether
conflicts will arise, we can in this case think of an rrset having its
own parent _LABEL.
dave may profit by referring to the "let's all stop returning ANY
results" draft, since it's only if ANY actually worked, that we would
see performance problems from _LABEL reuse across types. but note, even
in that performance-degrading situation, there would be no *conflicts*,
only coincidences.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
