Paul,
On 3/29/2018 9:31 AM, Paul Vixie wrote:
in: 1.1. _Underscore Scoping
...
s/[RFC1035]/[RFC952]/ (first occurrence)
hmmm. I suggest listing both, since RFC1035 both cites the precedence of
RFC952 as well as supplying an (apparently redundant) formal syntax
specification for host name.
the reference to 952 in 1035 is only in the bibliography, and does not
specifically discuss its relationship to A RR owner names or to MX RR
targets. if you can show me the part of 1035 you think is relevant to
the definition of a host name, i'd like to see it.
The text in RFC 1035 I have in mind is:
> 2.3.1. Preferred name syntax
...
When creating a new host name,
the old rules for HOSTS.TXT should be followed. This avoids problems
when old software is converted to use domain names.
The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
So, no, it doesn't explicitly cite the RFC number, but I read it as
citing the substance.
in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records
s/SRV,//; S/"SRV",//
OR s/Some resource records are generic and support a variety of uses.//;
s/Their use can scale poorly.*different uses\.//;
s/increasingly-popular//; s/approach,/approach/
Sorry, not understanding the issue(s). Please clarify.
Here's my guess at the concern:
SRV is viewed as not generic and/or doesn't have scaling problems?
...
it's not increasingly popular, it doesn't scale poorly, and it's not
generic. so you can either remove those descriptions of SRV, or you can
remove SRV as the object of your description, or you can finesse it.
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>
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.
Note, for example, that RFC 1034 says:
> 2.4. Elements of the DNS
...
The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
specifications for a tree structured name space and data
associated with the names. Conceptually, each node and leaf
of the domain name space tree names a set of information, and
query operations are attempts to extract specific types of
information from a particular set.
which is not language that lends itself towards saying that an RR type
has its own namespace. I don't see anything in RFC 1035 that works for
that view, either.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
