On 23 Jun 2024, at 04:58, Mark Andrews <ma...@isc.org> wrote:
> Turning off escape processing prevents turning off multi line processing.
https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template
Our expert review guidelines are explicitly lenient so I suppose I'm not
surprised this was accepted. However, it does seem like there is an actual cost
to accepting things like this. Using WALLET as an example, the constrained
RDATA format provides an implementation cost to parse and check the syntax of
the resource record in DNS servers that is presumably going to be duplicated in
the systems that consume this data from the DNS, as they apparently already do
with TXT RRs. If, in fact, this new RRType had RDATA defined as "exactly like
TXT" it would be a lot cheaper to implement in nameservers. Since some people
think new RRTYPEs are hard to deploy specifically because they take a long time
to be supported, perhaps this would be a win in more ways than one.
It seems like we could do three things about this:
(a) do nothing, this is fine, Mark enjoys this stuff and he'd be bored if he
didn't have more of it
(b) change the expert review guidelines to push back on this kind of thing and
say "no, use exactly TXT with underscore labels, you are not as special as you
think"
(c) write some guidance for future applications of the form "basically TXT but
with a different RRTYPE" to make things as cookie-cutter as possible for
implementers, and add a question to the application template of the form
"explain why you can't just use the cookie-cutter approach described in RFCxxx"
with some guidance for expert reviewers in assessing the answer.
Personally I think underscore labels are a better and cheaper solution for a
lot of applications, which makes me like (b). But I appreciate other people
think differently and perhaps are already OMG NO PLEASE NOT AGAIN about the
idea of restarting that conversation.
If anybody has any appetite for (c) then I could write something up.
It seems like it would be nice to be able to implement future new RRTypes like
WALLET simply by adding an RRType to an array of RRTypes that are all
implemented the same way, rather than writing new parsers for every one of
them. It would also make applicants' lives easier since they could say "I want
cookie-cutter WALLET" and not have to think about the consequences of how they
define their RDATA. Of course there's some XKCD-927 risk in this approach.
Joe
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
