Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

[Paul Vixie <[e-mail]>]

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