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

["Donald E. Eastlake 3rd" <dee3@torque.pothole.com>]

From:  Jerry Scharf <scharf@vix.com>
Date:  Wed, 25 Aug 1999 13:10:11 -0700 (PDT)
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
cc:  namedroppers@internic.net
In-Reply-To:  <199908251723.NAA02438@torque.pothole.com>
Message-ID:  <Pine.BSI.3.95.990825113728.25377R-100000@sh.lh.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?

Not particularly, especially since EDNS1 is not out yet.  Do you think
it really needs to say anything?  Where domain names are used for
taging parts of a SINK, compression is prohibited.  When they are used
inside encapsulated RRs, compression is permitted with an offset
origin, as specified in the draft, but that only matters to software
that packs and unpacks the stuff, which I think is application level
stuff that wants to use that feature of SINK.

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

That's a good clarification...

>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? 

Well, my current claim is that RRs that are planned to have wide
deployment throughout the DNS namesapce should be standards track RR
types.

>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. 

You seem very optimistic about widespread havey use of SINK.

>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.

Sure, that's the most likely use of the semantic 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.

I really want this to be simple so it will be rapidly implemented and
serve its purpose of being where we can point people when appropriate.
Just implementing a new TT type whose RDATA is pretty much opaque as
far as resolvers and DNS servers is concerned seems adequatly simple.
Deploying a new OpCode, even if it is a simple one, seems a lot
harder.  But it is the best solution to the "success disaster".  I
think it should be in an EDNS(n).  (n=2?)

>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. 

You're thinking of pseudo-RR-type mnemonics which can appear in a
master file but translate into a SINK?  Well, I guess you could have
that but if its worth modifying all the DNS servers in the world to
understand some special format, sure seems to me that its worth
allocating a real.  RR Type code.

>jerry

Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA