Re: let's talk about RFC2136bis

[<namedroppers@botham.net>]

---- Original message ----
>Date: Mon, 10 Mar 2003 21:43:08 +0000
>From: Paul Vixie <paul@vix.com>  
>Subject: Re: let's talk about RFC2136bis   
>To: namedroppers@ops.ietf.org
>
>> >...  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.

If I could comment,

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?


Dave...

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