APL and other new RR's

[Paul A Vixie <vixie@mfnx.net>]

DNSEXT and its predecessors seem to deal just fine with new RR's which have
to do with the DNS itself (as in SIG, KEY, OPT, and TSIG come to mind here.)

DNSEXT as an "oversight committee" for new RR types which originate elsewhere 
seems to work fine (NAPTR, SRV, LOC, NSAP, NSAP_PTR, are all examples) seems
to work.  All DNSEXT is being asked to do in those situations is ensure that
the RDATA encoding and other DNS-relevant issues are right -- NOT determine
whether the proposed RR is going to be useful or whether the design that it is
part of is really the right way to build some Internet application.

But trying to get something like APL "started" inside DNSEXT is not working,
because the implicit question is "what has this got to do with the DNS?" and
the implicit answer is "nothing."

I have an application that needs distributed, reliable, coherent, autonomous
access to a list of CIDR blocks.  I would like to store these in the DNS since
the DNS is already a distributed, reliable, coherent, autonomous "database."
My application has nothing to do with the DNS protocol.  DNS's existing types
don't deal well with this.  A RR's don't have a mask.  I can't use subdomains
like ._addr and ._mask because then a single RRset won't have the whole list
(._addr and ._mask would be separate RRsets and are not order-dependable.)

Apparently, from comments posted here in response to the APL RR draft, most of
the DNSEXT WG does not understand why this is being discussed in DNSEXT at all
since it has nothing to do with the DNS protocol, any more than NAPTR or NSAP
does.

Therefore I hope the author will withdraw the draft and reoffer it as an
individual, non-WG product, on an "experimental" track, which is what worked
when SRV ran afoul of this same lack of support.  (I'm just sooooo sure that
Microsoft worries about whether Win2000's SRV support is really
"experimental".)


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