Subject: Re: WG last call: Kitchen Sink

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Oct 1999 11:19:11 -0400

This apparently got lost in transmission last week...

At 12:37 PM -0400 10/14/99, Olafur Gudmundsson wrote:
>This draft is targeted to become Experimental, if you disagree with that
>please state so during this last call.

I think that this proposal should not be pushed forward.

The strengths of DNS are the distribution of operations and administration,
and there is considerable amount of work going on to improve DNS in these
areas.  The richness of the formats of data in DNS has not been a priority,
DNS has long been a place to hold the necessary information for the
Internet's core protocols.

The Kitchen Sink, if it were to become a popularly used record type, would
have the potential of improving the data-holding-model of DNS.  However,
this improvement would be at a cost, as there are quite a few fields in the
RDATA with mnemonic values that would need maintenance by the assigned
numbers body (IANA).  With all of the current energy going into
strengthening DNS operations and administration and the integration with
other protocols (e.g., DHCP), I doubt that improvements to the data-model
could be easily managed.

I would propose a differnet approach to meet the basic requirements
spurring Kitchen Sink.   A much simpler and less flexible record could be
defined - such as a BIN (binary data) or ASN1 (ASN.1 encoding) - which has
no internal form, much like the ISDN address.  Such a record would satisfy
users desparate for a place to store experimental data, but not be
attractive enough to take DNS away from its main mission.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 26 Oct 1999 10:47:44 -0700

> Subject: Re: WG last call: Kitchen Sink
> 

I agree, for at least the reasons that Ed gave.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 31 Oct 1999 01:48:57 -0400

Hi,

From:  Edward Lewis <[email-masked]>
Message-Id:  <v03130306b43b76ce7b85@[10.33.10.36]>
Date:  Tue, 26 Oct 1999 11:19:11 -0400
To:  Olafur Gudmundsson <[email-masked]>
Cc:  [email-masked]

>numbers body (IANA).

On "improving the data-holding-model", I'm not sure whether it would
or not.  That's why I think Experimental is the right category.  If I
were sure enough it was an improvement, I would recommend standards
track status.

I'd appreciate it if you could point out what fields in the RDATA
would require any mnemonic values.  The Master File format is
specified as three decimal integers corresponding to the three one
byte fields followed by any remaining data base64 encoded.  I suppose
you could go with a fancier Master File format with mnemonics assigned
for these byte values.  That would be about 29 mnemonics as I count.
If these were assigned, which is beyond the current specification, I
don't think any more would be needed for quite some time.  There are
two reasons I think that.  First, I put everything I could think of
and everything all the commenters on the draft suggested in already
And second, there are many provisions for "private" sub-types/formats
where a domain name or an OID is used.  These private sub-types should
eliminate any need for IANA registration of new main type/byte values.

A major part of the idea of SINK is to decrease the work load on IANA
and on DNS working groups by making it easy for anyone with a domain
name or an OID to set up private "sub-types" under SINK to play with.
No IANA registration or WG effort is required for this.  And it seems
like the most appropriate way to handle, for example, a proprietary
type where the group wanting the type does not want to release
information on its internal structure.

>                       With all of the current energy going into

I'd appreciate it if you could point out what "manage"ment effort
would be required if this were approved as an Experimental RFC.  Those
who want to experiment with it would certainly have to put out effort.
But part of the idea is to divert the effort requirement back on those
who want private / proprietary / experimental structured RRs and away
from IANA and the DNS working group.

>attractive enough to take DNS away from its main mission.

I think the above paragraph has two separte ideas for change, first
more specific RR formats, such as ASN1, XML, etc. and second dropping
the additional fields within the RR beyond the simplification in the
first point.

More specific RR formats would be sort of like moving the current
"coding" byte up to the RR type.  Thus, instead of using one RR type
number, you could end up using as many as 8 RR types but each would be
simpler than the current proposal and have only a single main type of
data coding in it.  I have no particular objection to doing that and
editing the draft to reflect this if it is what the working group
wants.

The other change you suggest is dropping other internal structuring,
which currently consists of the subcoding byte and the optional
meaning field.  If more than one group of people is to experiment with
SINK, then the meaning field is necessary to avoid conflicts.  It was
not there in earlier versions and was specifically requested by a
potential user who was refered to me by IANA.  A generic RRs with no
provision for interoperable semantic tagging hasn't proven popular in
the past.  (Interoperable in the sense that you know where unambiguous
tagging is so you can easily test if it is something you understand or
not.  I certainly don't mean that every user can understand stuff put
in by any other user.)  There already is the NULL RR, type 10, and TXT
RR, type 16, both defined way back in RFC 1035.  I don't think they
have been particularly successful for the use which SINK is aimed at.
Neither has any standard way of lagging for "meaning" in such a way
that if you get one you can unambiuously tell if you understand it.
TXT has some data structure but it's pretty limited.  NULL is just
arbitrary binary data, like the BIN you sugggest, with no structure.
People have tried (and do successfully use in some limited domains)
TXT while, as far as I can tell, avoiding NULL like the plague.  This
tiny bit of evidence seems to argue for more structure.  Why not try
an experimental RR with more structure than TXT?

I believe that the criterion for advancing something as Experiment is
closer to 'is it such a terrible idea no one should be allowed to
experiment with it' than it is to 'balancing the factors, would it be
a net plus or minus if lots of people started using this in regular
production work'.

I suggest that some sort of poll be taken at the upcoming WG meeting
and the results confirmed as consensus on this list, unless further
pre-meeting discussion on this list indicates otherwise, with poll
options of (1) drop the whole SINK idea from the WG, (2) advance as
Experimental (assuming no substantial problems arise duing a new Last
Call, etc.) a document improved by Ed Lewis' suggestion of a small
number of more format specific RRs, or (3) advance the current
document as Experimental.

I'm fine with whichever of these the WG wants.

Thanks,
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