Joe, it’s actually not the complexity in BIND (although I view everything as extra complexity), it’s the interop for new players that need to implement every piece of rusty junk that's in the protocol to be interoperable.
While it seems to be attractive to keep the existing open-source tetrapoly (insert your favorite Greek numerical prefix), the fact is that new implementations do pop up from time to time, and if we can reduce the protocol a little bit, so they can actually implement what’s important, that would be the noble goal here. Let me repeat again - we are speaking about stuff that was declared either OBSOLETE or EXPERIMENTAL already in RFC1035. I’ll elaborate more about why I think we locked ourselves into this when I am not typing on small phone screen in reply to Jared’s message later today. Cheers, Ondrej -- Ondřej Surý — ISC > On 24 Mar 2018, at 14:48, Joe Abley <jab...@hopcount.ca> wrote: > >> On Mar 24, 2018, at 13:49, Jared Mauch <ja...@puck.nether.net> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
