Dave Crocker wrote:
On 3/28/2018 11:41 AM, Paul Vixie wrote:
dave, HEREIS. --paul
Cool. Thanks!
...
Inline questions/comments/concerns...
...
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.
when i chose _ it was right after the great \n PTR vuln in sendmail, and
so i was darn sure where the definition of host name was that did not
include _ as a valid character, having just wrestled those 'gators.
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.
The variability of such types can make it problematic to aggregate all
occurrences of them into the same node, even though they are associated
with that node. The underscore naming approach separates these subsets.
Again, SRV is interesting because it was designed with that naming as
part of its original design. However the fact that it was designed with
the solution from the start doesn't relieve it of needing that solution.
The text, here, is attempting to characterize a motivating issue, namely
a scaling challenge that occurs due to the variability of use for some
RR types.
your words, "needing that solution", have no subject here. the problems
you are describing for TXT will apply to NULL, and to JSON if we restart
that effort, and possibly to URI (i didn't check that), but they do not
occur with SRV, nor might they, ever.
other than the need to document _UDP and _TCP in the registry for the
SRV type, there is nothing in your effort that touches or is motivated
by SRV. having an _ doesn't make it "like TXT". there is an RRset for
SRV where it is used, and that RRset is selected by its attrleaf. it
passes like ships in the night with any other type of RRset at any child
of the same domain name.
s/RR/RRset/ (note, leave "RR"s alone)
The substitution command seems to be at odds with the comment. Please
explain.
i don't want you to change the quoted RR ("RR") only the unquoted RR (RR).
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.
the children of some node (www.example.com) that are of some type (SRV)
are in a different namespace, with respect to an application's ability
to fetch them discretely (_SMTP._TCP.www.example.com SRV) and also with
respect to conflicts with the same node being used by some other type
(_TCP.www.example.com TXT).
perhaps after "subordinate name space" i ought to have added "for the
purpose of allowing applications to fetch only the data they desire and
without also hearing unrelated data used by other services and apps."
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
