Re: let's talk about RFC2136bis

[Paul Vixie <paul@vix.com>]

> >...  what else has anybody got against 2136 that they'd like to see
> >fixed in 2136bis?

> Remove the more-or-less arbitrary restriction on dynamic addition or
> deletion of SOA RRs. The "security improvements" changes you've proposed
> above would seem to moot the security-based objections to this, and the
> only other objections of which I'm aware -- concerns (one might say FUD)
> over how dynamic zone-creation/removal would work in practice -- confuse
> (IMO) implementation issues with protocol ones.

the restriction isn't arbitrary.  at the moment, data needed for a zone
to exist has to be transmitted out of band, since there is no defined
format in any standard protocol for carrying things like zone data source
(file name, sql table name, etc) or if it's a slave server, the list of
axfr targets, or etc.  then there's the problem of the zone section -- an
soa by definition does not go into an existing zone, so the zone section
would have to specify the new zone, which would not exist at the time of
[rfc2136 3.1].

adding soa creation/deletion in 2136bis would not be a case of removing
a restriction (arbitrary or not), it would be a fundamental change to the
data model.  i don't think we should attempt this in a "bis" document since
we're really just trying to fix the things that implementors have found
unclear or misleading or inconsistent or just plain wrong.

i think a zone management protocol is badly needed, but 2136 (or 2136bis)
is not it.

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