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

From: Jerry Scharf <[email-masked]>
Date: Wed, 25 Aug 1999 13:10:11 -0700 (PDT)

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

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 26 Aug 1999 22:13:35 -0400

From:  Jerry Scharf <[email-masked]>
Date:  Wed, 25 Aug 1999 13:10:11 -0700 (PDT)
To:  "Donald E. Eastlake 3rd" <[email-masked]>
cc:  [email-masked]
In-Reply-To:  <[email-masked]>
Message-ID:  <[email-masked]>

>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
>indicated by the meaning octet. 

That's a good clarification...

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

>records or NXRR. I think we should plan for success and success disasters

You seem very optimistic about widespread havey use of SINK.

>in section 2 explaining that there is an optional label.

Sure, that's the most likely use of the semantic label.

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

>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   [email-masked]
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     [email-masked]
 Carmel, NY 10512 USA