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

[Paul Vixie <[e-mail]>]

John C Klensin wrote:
> ...
>
> 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.  ...

i think you mean "RRTYPE" as used below, and not "label type". we 
flirted with extended label types in the original EDNS0, but found them 
to require end-to-end scale (forklift) DNS protocol evolution which is 
impossible, rather than hop-by-hop scale (incremental) evolution which 
is all we've got left given the installed base.

> ...  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).

while i am sympathetic to this point of view, and even share it, i know 
that developers of new apps learned from the SPF RR example "never 
again" and that they can and have and will continue to create new apps 
based on TXT with or without the IETF's blessing. so i'm expecting your 
call for the stated clarification to not reach consensus in this WG.

> (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.

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.

good catch.

-- 
P Vixie