> On 11 Sep 2018, at 8:51 am, John R Levine <jo...@taugh.com> wrote: > > On Tue, 11 Sep 2018, Mark Andrews wrote: >>> Since the type code is a 16-bit field, if we allocate a new type every >>> week, it'll take over a thousand years to run out. I think this is one we >>> can safely ignore. >> >> If we end up with a type per protocol because people want wildcards to work >> we will burn through types much faster. We don’t know exactly what the >> future >> will bring. > > Uh, what? In the past 30 years we've assigned under 100 rrtypes. If that > rate increases by an order of magnitude, we still have a thousand years of > them. Sure we don't know exactly what the future will bring, but we can make > some reasonable guesses.
We have assigned 100 types with the myth that it is hard to deploy a new type slowing down the rate of assignment. >> I do know that saying that classes can’t work is self defeating and will >> take a lot, lot, lot more of work to undo than just continuing to support >> multiple classes. > > Classes were a mistake. We should deprecate every class except IN, perhaps > keeping the one special case for CH server.bind. That doesn't require > changing any of the bits on the wire. And keeping classes working doesn’t changing any bits on the wire. Using a second class is almost all administrative. The resolver libraries I’ve been using for last 30 years have supported lookups in different classes. The recursive servers we have been delivering support multiple classes. Now the one thing that needs to be done with a new class is to define what a A record means in that class. QUERY supports multiple classes. UPDATE supports multiple classes. DNSSEC supports multiple classes. NOTIFY supports multiple classes. There are no reasons to kill multiple class support. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
