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

[Darrell Heng <[e-mail]>]

Thomas Narten wrote:
> 
> 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
pls remove me from your mass mailing list, thanks. i did not subscribe
to this particular column in the first place.


thanks, and happy surfing. 

regards,
heng