The obstinacy and unreasonablness of Donald Eastlake Re: draft-ietf-dnsind-kitchen-sink-01.txt

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

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

From:  John Gilmore <gnu@toad.com>
Message-Id:  <199908261756.KAA02852@cygint.cygnus.com>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
cc:  namedroppers@internic.net, gnu@cygnus.com
In-reply-to:  <199908251810.OAA02630@torque.pothole.com> 
Date:  Thu, 26 Aug 1999 10:56:38 -0700

>> into the dnsind WG.  Thus this represents the eighth version of the
>> draft and numerous 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.

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

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

>Don Eastlake is a prolific writer of Internet-Drafts, and he's very
>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
>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.

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.

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

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.

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

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   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA