Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

[John C Klensin <[e-mail]>]

--On Monday, March 26, 2018 00:07 -0700 Paul Vixie
<[e-mail]> wrote:

> 
> 
> John C Klensin wrote:
>> ...
>> 
>> Two additional, possibly more important, thoughts after
>> reading -05 more closely...
>> 
>> (1) The introductory material in the I-D seems to imply that
>> use of labels styled with "_" is a reasonable alternative to
>> creating a new label type.  ...
> 
> i think you mean "RRTYPE" as used below, and not "label type".
> we flirted with extended label types in the original EDNS0,
> but found them to require end-to-end scale (forklift) DNS
> protocol evolution which is impossible, rather than hop-by-hop
> scale (incremental) evolution which is all we've got left
> given the installed base.

Yes, sorry.  Late at night.

>> ...  My impression has been that, while there is nothing we
>> can change about what is done and deployed, there has been
>> community consensus that it is a bad idea and that changes
>> have been made to the procedures for defining and registering
>> new RRTYPEs to reinforce the principle that new RRTYPEs
>> should be used and to make their use easier. "Significantly
>> challenging over the life of the DNS" is undoubtedly correct,
>> but that should not be, and presumably is not, the situation
>> today or in recent years.   I believe this document should
>> not be advanced until that material is changed to be clear
>> that use of underscore or similar conventions may be a
>> reality but is not a desirable substitute for separate
>> RRTYPEs (with or without that convention as appropriate).
> 
> while i am sympathetic to this point of view, and even share
> it, i know that developers of new apps learned from the SPF RR
> example "never again" and that they can and have and will
> continue to create new apps based on TXT with or without the
> IETF's blessing. so i'm expecting your call for the stated
> clarification to not reach consensus in this WG.

If you are telling me I've fighting a losing battle, I
understand that.  At the same time, as I trust people have
figured out from RFC 8324 and/or Bert's presentation in DNSOP
last week, I think there is reason for concern that continuing
to add features, especially features with either high intrinsic
complexity or significant kludge properties, may eventually push
things over some virtual cliff.   That makes the fight worth
fighting even if most of the battles are lost.
 
>> (2) I'd encourage people to think through another
>> possibility. I'm not sure it is the right answer, but it is
>> worth more consideration than this draft (at least at -05)
>> appears to be giving it. The issues associated with QTYPE=ANY
>> notwithstanding, it is not clear to me that the set of labels
>> starting with "_" constitute a namespace, any more than the
>> set of labels starting with "xn--" do. It is just a naming
>> convention that identifies the labels as keywords with defined
>> meaning. From that point of view, namespaces are actually
>> per-RRTYPE and the right way to design this document would be
>> as a registry of "_"-introduced keywords, with subregistries
>> for each RRTYPE with which those keywords can be used. Given
>> the way the DNS works, at least as I understand it, there is
>> no DNS protocol conflict between _foo IN XYZ Data1
>> and
>>       _foo IN ABC Data2
>> 
>> Using the same keyword in both cases may be a bad idea but
>> the zone files don't care and, given that queries are
>> typically made for QNAME and QTYPE (etc.) and not the name
>> alone (i.e., with QTYPE=ANY) except for other purposes, I see
>> some advantages of [sub]registry-per-RRTYPE rather than
>> pretending that every label starting with "_" is the same
>> namespace. Of course, one of them is that there is no need to
>> treat SRV as a special, legacy, case or even debate that. The
>> coverage of the current document would be simply a
>> subregistry for SRV (reorganized from the current registry,
>> but that is simply an IANA organizational matter, not a
>> change to what is registered, protocols, etc., plus a
>> subregistry for RRTYPE=TXT and provisions for other
>> subregistries as might be needed in the future.
>> 
>> Organizing things that way would have at least one additional
>> advantage: while FCFS may be appropriate for some RRTYPEs,
>> other procedures may be appropriate for others. In a way, SRV
>> is a good example of that distinction.
>> 
>> Again, that might not be the right thing to do on balance,
>> but I think it should be examined carefully as an alternative
>> to trying to treat "everything starting with '_' as long as
>> it occupies a particular place in the tree" as a namespace.
> 
> i have reproduced your entire second suggestion here, because
> i think it's solid. rrset atomicity means you're right, and
> that underbar'ed labels need only be unique within an RRTYPE,
> and any registry of such labels can and therefore should be
> per-RRTYPE.
> 
> good catch.

Thanks.

best,
    john