Re: TKEY compatibility problems

Robert Elz <kre@munnari.OZ.AU> Fri, 20 July 2001 12:56 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20128 for <dnsext-archive@lists.ietf.org>; Fri, 20 Jul 2001 08:56:47 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZeP-0006U4-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:45:01 -0700
Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZeO-0006Tw-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:45:00 -0700
Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZeI-0000bi-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:44:54 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Robert Elz <kre@munnari.OZ.AU>
To: "D. J. Bernstein" <djb@cr.yp.to>
cc: namedroppers@ops.ietf.org
Subject: Re: TKEY compatibility problems
In-Reply-To: <E15NPXv-000CPz-00@psg.com>
References: <E15NPXv-000CPz-00@psg.com> <E15MbJe-00056a-00@psg.com> <E15LHAw-0007rZ-00@psg.com> <E15KpfA-000ISO-00@psg.com> <E15LDdz-0002Xy-00@psg.com> <E15LHAw-0007rZ-00@psg.com> <E15LpAZ-000Ctn-00@psg.com> <E15MbJe-00056a-00@psg.com> <E15MqkK-000Iql-00@psg.com> <E15N36L-000570-00@psg.com> <200107191320.f6JDKMD23052@kcmso1.proxy.att.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15NZeP-0006U4-00@psg.com>
Date: Fri, 20 Jul 2001 05:45:01 -0700
Content-Transfer-Encoding: 7bit

    Date:        Thu, 19 Jul 2001 18:57:39 -0700
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <E15NPXv-000CPz-00@psg.com>

  | I agree that this potential compatibility problem disappears if TKEY
  | clients ignore unexpected records. Guess what? That also eliminates the
  | potential compatibility problems with AXFR!

Yes, exactly, this is what we have been trying to tell you - just ignore
unexpected records (anything at all in the auth or additional sections)
and potential compatibility problems will be eliminated.

Glad you have finally conceded the point.

  | What stops incompetent implementors from
  | demanding another code change every week?

Because the community as a whole will react negatively.   Here the
community as a whole is telling you this is a good thing to do, and
in fact, this was what was always intended that you should do - it
is just that the doc didn't say that as well as it should, it just
assumed that readers would be able to infer it.   It is quite correct
to point out that the doc wasn't clear - and the solution to that is
to clarify it.

  | Huh? I explicitly pointed out an important violation of RFC 2181 by
  | 
  |    * the BIND 4 cache,

Yes, it was what it had been doing, that everyone conceded was incorrect
and harming the internet - it was to document a better scheme (and knowingly
a new scheme) that those rules were created (after quite a bit of
discussion).   That's what the WG agreed that servers (not having dnssec
yet available to them) should be doing to improve things.   No-one was
pretending that it was current practice.

kre



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.