Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Joe Abley <[e-mail]>]

On Mar 24, 2018, at 13:49, Jared Mauch <[e-mail]> wrote:

>    isc/bind can and perhaps should implement logging for these
> rrtypes that say they may be going away so folks can see the impact.

I'm actually surprised to see that support for rarely-used RRTypes is
really upsetting the camel.

A combinatorial explosion of annoying workarounds for the inability of
middleboxes or upstream authority servers to implement EDNS(0)
properly seems like a much more plausible camel irritant to me. I'm
sure there are many more like that.

I can see why you could strip out lines of code by eliminating the
need to parse the canonical formatting of WKS and friends, but I'm
surprised that it's a notable source of complexity. It is, after all,
complexity that I heard is causing the camel strain, not just lines of
code.

If future-BIND stops parsing an archaic RRType that I happen to use,
I'm going to have to change whatever code or processes that depend on
it. Maybe someone (ISC, even) is going to publish a filter that will
turn all the old RRs in canonical syntax into TYPExxxx representation,
and back again. New RRTypes might then need to get implemented in both
BIND (because presumably they are camel-friendly) and also in the
filter or filters, because perhaps we are targeting multiple
nameserver implementations with our zone file.

This all sounds like we're just sharing the complexity around. It
doesn't sound any simpler. Maybe it's a silly example? I don't know.
Could be. But I think brushing the grains RRType parsing dust off the
camel is not going to do much for its posture.


Joe