On 3/28/2018 11:41 AM, Paul Vixie wrote:
dave, HEREIS. --paul
Cool. Thanks!
(Sorry for the sloppy vocabulary usage. By way of an empathy signal cf,
common use of 'header' in email when it should be 'header field'...)
I've gone through the entire document and reviewed all occurrences RR
and resource record strings. The results don't exactly the match the
set of changes you specify, but did produce quite a few changes.
The RFC 2181 definition resource record set is a set of records of the
/same/ type. In some cases, that isn't what's meant, so I didn't change
the text. In some cases, the text's intent is to to cover RRs of
/different/ types populating the same leaf. As I read the definition,
that's not covered by RRset.
Inline questions/comments/concerns...
in: 1.1. _Underscore Scoping
...
s/specific resource records/specific resource record sets/
Current text:
"That scope is a leaf node, within which the uses of specific
resource records can be formally defined and constrained."
I often find that there is wording danger in using plurals, that can be
avoided with the singular. I think the issue here can be simplified by
changing the text to:
"That scope is a leaf node, within which the uses of a specific
resource record type can be formally defined and constrained."
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.
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?
There is a type of variability to the use of some RR types that
effectively means they have variation in their role, not just their
payload. TXT is the extreme example of this. SRV is more interesting,
because it was designed for that variability. Glad to use a term other
than generic, but I don't have an obvious alternative that suits.
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.
s/RR/RRset/ (note, leave "RR"s alone)
The substitution command seems to be at odds with the comment. Please
explain.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
