Re: Summary: What to do with expired signatures

[Paul Vixie <[e-mail]>]

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

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