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

["David Botham" <namedroppers@botham.net>]

> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org [mailto:owner-
> namedroppers@ops.ietf.org] On Behalf Of Paul Vixie
> Sent: Tuesday, March 11, 2003 10:16 AM
> To: namedroppers@ops.ietf.org
> Subject: zone management (Re: let's talk about RFC2136bis )
> 
> > >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.

Well, maybe zone management was the wrong term for what I was
suggesting.  After reading your comments, I agree that zone management
would necessarily have implementation-dependent components.

Maybe Zone Provisioning is better choice of words.  This topic goes back
to a discussion on the bindusers list starting back in sep-2002.  It was
suggested that Notify could be used for the purpose of auto provisioning
of zones on slaves.  

If this topic has already been pummeled here, please let me know.  If
not, and it seems like something worth pursuing, I would be interested
in working on the development. 

> 
> therefore a zone management protocol, in order to be worthy of a
standard,
> would have to enumerate some common forms of implementation-dependent
> data,

Yes, but, would a zone provisioning protocol be worth pursuing?

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


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