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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
