Re: Last Call: The Kitchen Sink Resource Record to Proposed Standard

[Thomas Narten <[e-mail]>]

Folks,

Speaking as an individual, I have a question about the document
draft-eastlake-kitchen-sink-02.txt (and Standards Track protocols in
general) that I'd be interested in getting other folks opinions on.

The DNSIND working group has requested that this document be issued as
a Standards Track document. I've always had the notion that Standards
Track protocols were those that were somehow "good" (or at a minimum
"not bad") for the Internet. That is, the IETF thinks that a protocol
is a reasonable way to solve a particular problem, and that folks are
encouraged to implement and deploy the protocol.

With that in mind, the document's introduction says:

>    New RRs that are reasonably spartan and designed with some care are
>    periodically added via the IETF standards process as new needs become
>    apparent.  But there are periodically people who want to put some
>    complex and frequently large structured data in the DNS.  They
>    usually come up with some kludge way of reinterpreting the TXT RR,
>    since that is one of the least constrained RR.  This is likely a bad
>    idea since all previous kludge ways to reinterpreting the TXT RR have
>    sunk without a trace.  (Well, if they actually got an RFC out, it's
>    still there, but, practically speaking, nobody actually uses it.)
> 
>    If a new type of data is really needed for common use in the DNS, the
>    best course is to design a new RR that efficiently meets the need
>    through the IETF standards process.
> 
>    People who want to shoe-horn bulky or complex and obscurely
>    structured data into the DNS, which may not appropriate there, don't
>    want to hear that. This draft defines an extremely general and
>    flexible RR which can be pointed out to such people.  It includes
>    representations of OSI ASN.1, MIME, and, recursively, DNS RRs.

Summarizing, I interpret the document as saying: the right thing to do
when placing a new kind of data in the DNS is to define a new
RR. However, folks don't want to do the right thing, so here's a
standard "wrong way" for them to solve their problem.

The question I have is whether the IETF should be giving Standards
Track status to protocols that even a document itself suggests is not
really the right way to solve a problem? Should such documents be made
Experimental rather than Standards Track?

My question is motivated by what happens long term, when the document
proceeds further down the Standards track to Draft and Full
Standard. Will the community ever want this protocol to be a full
Internet Standard? If the answer is no, Standards Track seems totally
inappropriate, and the IETF should not suggest otherwise by allowing
it to enter the Standards Track in the first place. At the same time,
I've had private conversations that suggest elevating documents to
Proposed is not considered a big deal, and they can be nixed later if
necessary. Thus, now is not the time to worry about these sorts of
issues.

The underlying meta question concerns what criteria should be used for
deciding Experimental vs. Standards Track. For Standards Track,
scalability, does no harm, can be made secure, and solves an important
problem would seem to be minimal considerations. Are there others?

In the case of this particular protocol, there may be scalability
issues. For example, suppose that 10 different applications go off and
use SINK RRs to do their thing. When any one of those applications
queries the DNS, it will get back *all* SINK RRs for a given name,
even though it doesn't want but the one associated with *that*
service. But only the application knows which RR is useful to it, so
the DNS has to return the entire RRSet (if each service had its own RR
type, the problem wouldn't exist -- an application could ask for the
RR of the specific type it wants). Consequently, SINK RRs seem to have
negative scaling properties. Only a limited number of different services 
can use a SINK RR, because the sum of the sizes of all SINK RRs for a
name needs to be bounded to fit in a DNS response. If this is the
case, should we advocate deployment of SINK RRs?

Comments?

Thomas