Re: Summary: What to do with expired signatures

[Josh Littlefield <[e-mail]>]

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.

Well... This is *exactly* what happened at the 46th IETF (DC) interoperability
event, and perhaps at prior events as well.  The results are posted here:
<http://www.isc.org/interop/>.  Note the reference to the Perl config file
generator and the Perl master file generator.

Still, I agree completely that a protocol compliant server can exist which does
not parse zone files (we make one here at Cisco).  However, having a user
interface which does parse zone files can make life a lot easier, as it did for
me in this particular case.  I think BCP status for zone file format might make
sense.  I certainly don't see it as part of the protocol, but as an aspect of a
useful user interface.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[e-mail]                                      250 Apollo Drive
tel: [phone]  fax: same               Chelmsford, MA  01824-3627

to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>