Re: draft-ietf-dnsind-kitchen-sink-01.txt

[Jerry Scharf <scharf@vix.com>]

Don,

Two small things and one big thing.

As a small thing, does sink want to refer to EDNS1 and that discussion of
global token compression?

In the text encoding section, you mention first and odds as labels. It
might be worth mentioning that this doesn't count a possible label as
indicated by the meaning octet. 

As the larger thing, I think it is a bad choice to punt the issue of
selection within sink records. My reason for wanting the sink record is to
give people like Mr Costanzo a viable alternative to creating a standards
track RFC for adding what he hopes is very widespread data. This is a very
different desire than what the abstract discusses as records "where
interoperability is not required." Is this a general extension method to
do things that do require interoperability or not? 

It would be a real pain for programs to have to slog through all the
different types of sink RRs looking for the ones you want. It's a big
downside with current text records and that is being propagated with this
record. If my program is looking for GL records, it really wants to get GL
records or NXRR. I think we should plan for success and success disasters
rather then limited use. 

It is clear after a couple readings that one of the purposes for the label
indicated by the meaning field is for matching, but it takes a couple
readings and is not as clear as it could be. Can you add a sentence or two
in section 2 explaining that there is an optional label.

As for the new query, that could either be tackled here or in an EDNS(n)
RFC. It seems pretty easy, you need two extra fields in the query, the
type and value of the label to be matched. All records with no labels
fail to match any extended sink queries.

Question for implementors (following along on my interoperable use
assumptions.) Would you be willing to allow records that looked just like
regular RR types, but are converted into sink RRs for sending? Using the
GL example again, would you allow the implementation of a GL pseudo RR
that looks just like what was in the draft? Also, what kind of interface
would people put on top of the resolvers for passing this information to
apps?  It's not a protocol question, but it seems like a fair question
given the differences between sink and existing RRs. 

jerry