On 3/29/2018 10:30 AM, Paul Vixie wrote:
since the _ was chosen as nonconflicting, and since you desire to
explain what it is we aren't conflicting with, and since the RFC 1035
language is both non-normative and archaic by inspection, i really think
that 952 is the correct, and only correct, reference to use.
Thanks for the detailed explication. I think it's odd to have a DNS
naming-related discussion that does not cite either of the seminal
standards documents for domain naming, but I suppose there's isn't much
downside at this place in the document, to cite only RFC 952.
as a side node, RFC 952 permits host names of only 24 characters or
less, including those which have interior periods for RFC 921 purposes.
therefore, a protocol lawyer could say that any name longer than 24
characters, or beginning with a number, was by definition
non-conflicting with RFC 952, and needs no underscore to achieve same. i
do not harbor this view, and i believe that the LEXICAL GRAMMAR section
is more definitional than the ASSUMPTIONS section of RFC 952.
To me, that's an example of the problem with citing only that document:
It is not definitive on 'host name'. That RFC 1035 isn't, really,
either was my reason for wanting to cite both. But anyhow, the next
version will have only 952.
Trying to eliminate the issue entirely, is this sufficient:
<section title="Scaling Benefits">
<t>Some resource record types are used in a fashion that can create
scaling problems, if an entire RRset associated with a domain name is
aggregated in the leaf node for that name. An increasingly-popular
approach, with excellent scaling properties, places the RR under a
node having an underscore-based name, at a defined place in the DNS
tree under the 'parent' name. This constrains the use of particular
<spanx style="verb">RR</spanx> types associated with that parent
name. A direct lookup to the subordinate leaf node produces only the
desired record types, at no greater cost than a typical DNS
lookup.</t>
<t>The definition of a underscore global registry, provided in this
specification, primarily attends to the top-most names used for
coping an RR type; that is the _underscore "global" names. </t>
</section>
it's almost 100% of the way there. but, you should say "places the
RRset"
oops. quite correct.
in: 2. DNS Underscore Scoped Entry Registries Function
...
/name space/name space, just as every RR type owns a distinct,
subordinate name space./
An RR type owns a name space? I don't understand what that means or how
it is correct.
While I think I see a computer science basis for saying that an RR type
has a namespace, I'm continuing to find the point more confusing than
helpful, and fear that other readers will, too.
At the least, can you point me to official documents that explain that
view? I've looked around a bit an haven't found such a specification or
discussion.
it only contains a namespace for the purposes of your underscore
registry. no use of _TCP by any other RR type will conflict with the use
of _TCP by SRV, for example. thus, each RR type effectively has its own
registry, whose names need only be unique within that registry. you may
prefer to call it a dictionary rather than a namespace in order to avoid
confusion around what other DNS RFC's call a "namespace".
Oh. Alas, I'm still not seeing how this is helpful pedagogy for the
average reader. Let's suspend this until the next version and see how
the doc sits with folks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
