Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

[Paul Vixie <[e-mail]>]

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