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

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 25 Aug 1999 14:10:50 -0400

I've received a private comment to the effect that few comments on a
draft are a bad sign.  I suppose that may be so but I would remind
people that this was previously draft-eastlake-kitchen-sink- and as
such it went through six revisions before being renamed and renumbered
into the dnsind WG.  Thus this represents the eighth version of the
draft and numberous earlier comments have been taken into account.

Thanks,
Donald

------- Forwarded Message

Message-Id:  <[email-masked]>
cc:  [email-masked]
Subject:  draft-ietf-dnsind-kitchen-sink-01.txt
Date:  Tue, 24 Aug 1999 09:59:47 -0400
From:  "Donald E. Eastlake 3rd" <dee3>

Hi,

I think this draft is in moderately good shape.  It has been up for a week
and the only comment I have received so far is the typo in

   All references to "domain name" in this document mean domain name in
   the IP DNS class.

which should say "IN" rather than "IP.  However, on further thought, I
think that domain names appearing in a SINK RR should refere to names
in whatever CLASS that SINK RR appears and intend to make that change.
I'd appreciate any further comments on this or other aspects of this
draft and plan to ask for either an official WG last call or that it
be forwarded to the IESG, at decided by the co-chairs, in aabout one
week.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA

------- End of Forwarded Message

---

From: John Gilmore <[email-masked]>
Date: Thu, 26 Aug 1999 10:56:38 -0700

> draft and numberous earlier comments have been taken into account.

One comment that has not been taken into account is that we shouldn't
waste any more time on this RR proposal.  It fills a "need" that doesn't
appear to actually exist.  Yes, it takes pressure off the wildly
successful TXT record, of which there must be at least a couple
hundred in the entire worldwide domain name system.  It also addresses
the other problem that every proposer of a wonderful new RR rejects
the demeaning idea that "you could just put that information into a
TXT record".  The Kitchen Sink record solves that by providing an even
more demeaning RR into which wonderful new RR ideas can be directed.
I'm sure it will be just as popular with new inventors anxious to get
their names on an RFC.

Don Eastlake is a prolific writer of Internet-Drafts, and he's very
energetic in pushing *all* of them down the standards track.  Many of
them are useful, and I appreciate Don's initiative and support for
these.  Not every Internet-Draft contains a good enough idea that the
Working Group should make a standard out of it, though.  Too many of
these I-D's seem like those bad electoral initiatives Californians are
subjected to, which keep coming back despite year after year of
rejection by the voters, until eventually some fluke in the voting
statistics causes them to pass.

There should someday be a way to finally kill off a bad proposal in
the IETF, once and for all.  In the meantime, IETF already has a
mechanism to give serious weight to apathy, though it takes a tiny bit
of backbone on the part of the Working Group.  It involves *ignoring*,
or if pressed by the author, *rejecting* bad ideas, rather than
forwarding them up the chain as if we approved of them.  RFC proposals
should be rejected not only for internal technical flaws, but also for
uselessness, inapplicability, or other lack of a serious reason for
existence.

Since the author is pressing us and mere ignoring will not suffice, I
suggest that *rejecting* this I-D is the Working Group's most
appropriate response.

	John Gilmore

---

From: Greg Hudson <[email-masked]>
Date: Thu, 26 Aug 1999 20:20:51 EDT

> Yes, it takes pressure off the wildly successful TXT record, of
> which there must be at least a couple hundred in the entire
> worldwide domain name system.

There are a lot more than in ns.athena.mit.edu alone, because Hesiod
uses TXT.  Hesiod records tend to be separated from other records by
domain name (the ns. prefix), which helps to make up for the
questionable choice of resource type.

(I'm not arguing in favor of the kitchen sink RR, just contradicting
a particular factual claim.)

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 26 Aug 1999 21:12:47 -0500

I disagree strongly, almost viscerally, with everything in John
Gilmore's message.  I won't even waste time rebutting those
remarks which sank to a more personal level as I'm sure everyone
in the working group knows better.

			Matt Crawford

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 27 Aug 1999 08:57:58 -0400

It's always interesting to see what things look like from someone
else's point of view...

From:  John Gilmore <[email-masked]>
Message-Id:  <[email-masked]>
To:  "Donald E. Eastlake 3rd" <[email-masked]>
cc:  [email-masked], [email-masked]
In-reply-to:  <[email-masked]> 
Date:  Thu, 26 Aug 1999 10:56:38 -0700

>> draft and numerous earlier comments have been taken into account.
>
>appear to actually exist.

Well, the easiest way to save time right now would be to either
approve the draft in this working group or flush it from the working
group.  The second course certainly won't get rid of it, however, as
explained below.

The original need that motivated this draft was the amount of time
being wasted by clue-ful people in the DNS area explaining to others
why it was a bad idea for them to define new RRs with complex, bulky,
and obscure data structures.  I mentioned the idea to many in the DNS
community before writing the -00 version and got clear consensus among
those I talked to in favor to it.  Unfortunately I don't seem to have
the original motivation wording, which probably was a bit too harsh
and never made it out to Ineternet-Drafts but was only circulated
privately.

To that has been added the motivation of decreasing the burden on
IANA.  The draft was languishing as a personal draft, being updated
just often enough to keep alive, while I was working on higher
priority things like updating the DNS SEC specs.  Then IANA
specifically suggested to two corporations that wanted to put
proprietary stuff into the DNS that they contact me concerning SINK.
This movtivated me to really get working on this again.

>                          Yes, it takes pressure off the wildly

It isn't much do with the the TXT record.  It's so IANA and others can
easily and quickly point to it when people want to do something
proprietary or something which, while claiming to be appropriate for
standards track, probably wouldn't make it due to
complexity/bulk/lack-of-clue, etc.

Somehow I think that TXT RRs are for text.  I'm certainly not stopping
people from using it for other things and I'd even agree that its OK
to use it for other things in your own part of the names space.  But I
would prefer not to see more overloading of TXT.

Consider those with bad ideas and those with proprietary data.  If
someone with a bad idea are sufficiently offended by the Kitchen Sink
RR, I wouldn't really mind if they went away.  And for those who want
their own thing in an RR for their proprietary format, using an RR
called SINK seems like a small price to ask them for the freedom of
setting up however many differnt formats or variations they want
without having to ask IANA or anyone, as long as they stick to the
guidelines in the draft.

Anyway, the IETF is supposed to have a sense of humor.  If a consensus
of the WG wants to rename it something bland like OMNI, they certainly
can.  But only as long as its a WG draft and the WG has control.  If
the WG tosses it out, then it's all mine again :-)

>energetic in pushing *all* of them down the standards track.

Thanks for the complement but lets look at the facts.  Here are all
the RFCs of which I am author or co-author with their category:

1455	Experimental (now Historic)
1750	Informational
1898	Informational
2065	Standards Track (Obsoleted by 2535)
2137	Standards Track
2535, 2536, 2537, 2538, 2539	Standards Track
2540	Experimental
2541	Informational
2606	Best Current Practice

You will note that all, I repeat *all* of my drafts that have come out
as Standards Track have been for DNS Security, something which, while
having controversial pieces, I think you can hardly claim is a area I
came up with by myself or without good motivation (it was an ARPA
solicitation and, along with routing security, is part of the US
government infrastructure hardening effort).

>                                                              Many of

I haven't tried to advance most of my ideas as Standards Track.  While
I initially proposed the kitchen sink draft as Standards Track, in
Oslo people wanted to change it to Experimental and, after two seconds
thought, I decided they were right and that's were it is now headed.

>uselessness, inapplicability, or other lack of a serious reason for

I find it easy enough to think of ideas that I have dropped because of
opposition.  The initial DNS SEC has a complex revocation mechanism
that, at the ADs request, I split off into a separate draft and then
decided there was enough opposition I never even bothered to submit
it.  My inverse-key proposal (draft-ietf-dnssec-in-key-*), no longer
in the ID directories even in stub form, is another example of
something I dropped because of opposition.

>suggest that *rejecting* this I-D is the Working Group's most

Kitchen Sink was an individual draft (draft-eastlake-kitchen-sink-*)
for some time before it was invited into the DNS working group by the
chair(s) and some members.  Although I'm sure it can be improved
further, if people want to toss it out, I wouldn't mind persuing it
through the RFC-edtior as Experimental which, at least in principle,
bypasses the working group and IESG.  Last I knew IANA and the
RFC-Editor still talked to each other and given that I have at least a
hint that IANA would like to see something like SINK be adopted so
they can send proprietary RR type applicants there, I suspect it would
not be that hard to get through.  [Of course, in reality, the
RFC-editor would ask the IESG's opinion which might easily in turn ask
the DNS WG's opinion ... but I suppose it would be substantially less
work for the WG to take a fixed draft and do a thumbs up/down on
whether it is so bad it shouldn't even be Experimental as opposed to
the WG having change control and working to make the draft better,
even if Experimental, as is now the case.]

But, John, in the absense of a bunch more messages like yours, I still
think the WG wants to move forward with it.

>	John Gilmore

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