>I believe that dns-choices is fundamentally flawed, it will be ignored
>by developers that decide to use TXT and does not provide an useful
>way forward.

I agree that the draft is fairly badly flawed, but I completely
disagree about what the problems are.

The first 2/3 is basically fine, the discussions about all of the ways
that one might add new data to the DNS and why most of them are bad
are fine. But then section 5 waves its hands, and makes lame
arguments against the difficulty of adding new RR types. The reality
is that adding new RR types is hard, and the honest thing to say is
yes, it's hard, there are barriers to doing so, but they're worth the
pain.

The claim that most DNS servers and clients handle unknown RR types
is, unfortunately, just false. One of the things we learned during
the MARID fiasco is that for some reason our pals in Redmond defined a
DNS API with a separate call for each RR type, and no escape for RR
types not in the API. They then have built this API into a whole lot
of computers in use all over the world, and none of those computers
can handle new RR types at all, neither serve them nor look them up.
Yes, they should fix it, but getting them to do so and to get it
shipped to all the customers won't happen overnight.

It also understates the difficulty in assigning type numbers to RRs.
I am surely not the first person to note that the number of RR types
is the same as the number of TCP ports, and to wonder why assigning RR
numbers has been so much more of a problem than assigning TCP ports.

It also needs to address the issue of how front end and back end tools
will deal with hitherto unknown RR types beyond dumping them out in
hex. It occurs to me that proposed RR types invariably consist of
sequences of a small set of basic data types, integers of various
lengths, IP addresses, strings, and names. I would think it would be
easy to define a template language to describe new RRs, perhaps in
XML, so to upgrade our tools to handle new types we only need to
install an updated template, not a new version of the program. (XML
bloat doesn't matter, this XML only goes into the DNS management
applications, not into the DNS itself.)

A more honest assessment of the current problems of new RR types and
some direction about solving those problems would make this document
a whole lot more persuasive.

R's,
John

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: