Re: Summary: What to do with expired signatures

"Paul V. Mockapetris" <pvm@nominum.com> Sat, 16 February 2002 17:17 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14318 for <dnsext-archive@lists.ietf.org>; Sat, 16 Feb 2002 12:17:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1) id 16c8CU-000DEP-00 for namedroppers-data@psg.com; Sat, 16 Feb 2002 09:00:38 -0800
Received: from sh.lh.vix.com ([204.152.188.26]) by psg.com with esmtp (Exim 3.33 #1) id 16c8CT-000DEH-00 for namedroppers@ops.ietf.org; Sat, 16 Feb 2002 09:00:37 -0800
Received: from KEYSER (sh.lh.vix.com [204.152.188.26]) by sh.lh.vix.com (8.11.2/8.9.1) via ESMTP id g1GH0Yr15574; Sat, 16 Feb 2002 09:00:35 -0800 (PST) env-from (pvm@nominum.com)
Message-Id: <4.2.0.58.20020216085840.031ca7a0@127.0.0.1>
X-Sender: pvm@127.0.0.1 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sat, 16 Feb 2002 08:58:49 -0800
To: Paul Vixie <vixie@as.vix.com>, namedroppers@ops.ietf.org
From: "Paul V. Mockapetris" <pvm@nominum.com>
Subject: Re: Summary: What to do with expired signatures
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_546285==_.ALT"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 08:54 AM 2/13/2002 -0800, Paul Vixie wrote:
> > > All zone changes are made by RFC2136 "UPDATE" requests.  There is no
> > > "load" and there is no "zone file" and there is no way to map your
> > > "implied delete" to any process that it has.  Yet this server is entirely
> > > protocol compliant.
> >
> > as the docs do specify a zone file and format, this is interesting.
>
>Yes.  Since at no time in any interoperability workshop has it ever happened
>that one implementor handed the other a *.TXT file and said "read this and
>serve it so we can test interoperability", I can legitimately claim that a
>server which does not parse "zone file format" and does not have a concept
>of "loading" a zone is completely protocol compliant.

Interoperability and/or interoperability testing happened several times in 
the past, and among those times, one was to allow some newfangled DNS 
server call bind to interoperate with another  UNIX implementation of DNS 
from Stanford and the old TOPS20 implementation.

>   On the wire, you just
>can't tell how the other guy deals with backend storage of zone data.  And
>if an implementation can pass every possible on-the-wire compliance and
>interoperability test you can devise, then they are fully compliant with the
>protocol.

Yeah, but servers that can load zone files should get the same result.  If 
they don't, zone files shouldn't be either a standard or a BCP, so maybe we 
are in agreement.  But it should be testable if the specs are written 
correctly.

So a better way to decide this is just to have the argument about whether a 
text format for zone data is still useful or not, rather than whether it is 
possible.

>This supports my earlier statement that zone file format should be a BCP
>rather than a PS.  You can't have a PS that is by its nature untestable,
>according to my reading of the IETF charter documents.
>
>to unsubscribe send a message to namedroppers-request@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>