Re: [dnsext] request to adopt draft-andrews-dnsext-expire-00.txt

[Mark Andrews <Mark_Andrews@isc.org>]

In message <20081125172801.GG8879@unknown.office.denic.de>, Peter Koch writes:
> On Thu, Nov 20, 2008 at 03:52:59AM +1100, Mark Andrews wrote:
> > 
> > 	As per the chairs' instructions, this is a request for
> > 	dnsext to adopt draft-andrews-dnsext-expire-00.txt as a wg
> > 	item.
> 
> this draft seems to assume that EXPIRE is a tool to deterministically bring
> a zone out of service, controlled by and to the benefit of the zone
> maintainer.  My reading of RFC 1034, section 4.3.5 is different: EXPIRE
> is just a relief for the slave, so it doesn't have to waste more resources
> on SOA checks.  I do not see how self-sustaining XFR-loops would hurt there.
> Actually, many zones use dangerously low EXPIRE values and accelerating
> expiration (independent of loops) might be counterproductive for them.

	The purpose of expire is to stop stale data being served.

	"If the secondary finds it impossible to perform a serial
	check for the EXPIRE interval, it must assume that its copy
	of the zone is obsolete an discard it."

	No where do I see any text which says that a slave will
	stop attempting to transfer the zone if it's old copy has
	expired.

	As for dangerously low EXPIRE values they are a problem with
	or without loops in the zone trasnfer graph.

> This suggests that a clarification of the meaning of the EXPIRE field is
> probably needed. If EXPIRE was a reliable zone removal tool, how would slave
> servers be expected to maintain state -- or would they be allowed to
> occasionally re-query?  What's the operational scenario in which zone
> removal would apply? Shouldn't this question be better addressed by a
> name server control protocol?

	It's not a zone removal tool.  It a stale data removal tool.
 
> That said, I do not believe adopting the draft is the best way forward, becau
> se
> it is too deep in solution space.  Seeking clarification of EXPIRE is a
> different work item and I'd support that.
> 
> -Peter
> 
> --
> 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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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