zone management (Re: let's talk about RFC2136bis )

[Paul Vixie <paul@vix.com>]

> >i think a zone management protocol is badly needed, but 2136 (or 2136bis)
> >is not it.
> 
> If I could comment,

it's ietf, everybody can comment.  however, knowing only that your first
name is "dave" and that your e-mail address is namedroppers@botham.net does
not exactly fill me with the kind of warmth i'd like to experience when
evaluating a proposal.  (can maybe you spruce up your .signature a bit?)

> If "zone management" is restricted to the implementation independent
> tasks of adding or dropping of zones, then could we develop a draft
> that goes something like:
> 
> For an add:
> 
> Master loads zone and sends a "zone add" directive to the slaves.
> Slaves receive the "zone add" and add the zone via a zone tranfer
> (provided the human has decided to trust the master)
> 
> For a drop:
> 
> Master drops a zone and sends a "zone drop" directive to the slaves.
> Slaves receive the "zone drop" and drop the zone.
> 
> I realize that there are many other tasks associated with zone
> management depending on the implementatin. The protocol could set part
> of the packet(s) aside for implementation specific data that can be
> safely ignored by servers that may not understand things like views or
> acl's, for example.
> 
> I know this is way over simplified, but, would that be the bulk of it?

in my opinion, no.  there are implementation-dependent zone metadata
elements (such as backing store or data source... zone file or sql table
name or whatever) which, when unspecified, leave the zone in an error
state (all queries would be answered SERVFAIL).  i don't think a protocol
which is only reliably capable of creating an error state is a good idea.

therefore a zone management protocol, in order to be worthy of a standard,
would have to enumerate some common forms of implementation-dependent data,
like "master file name" and "slave file name" and "sql table name" and 
"active directory domain name" and so on.  implementors from mydns, 
nominum, ultradns, isc/bind, and so on would all have to contribute.  the
nonimplementors in the crowd would have to participate in order to ensure
that the result was both complete and extensible.

it's a big effort.  the minimal size of the effort is larger than what you
proposed, in my opinion.)

(and 2136bis will NOT address this area at all, since the lack of zone
management features in 2136 is not due to editorial error or oversight,
and has not led any implementor to scratch their head wondering what the
document means.)

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