6bone/ip6.int interaction

[bmanning at vacation.karoshi.com]

On Wed, Jun 14, 2006 at 06:24:00PM +0200, Mohsen Souissi wrote:
> Sorry for my late answer (below):
> 
>  On 13 Jun, Doug Barton wrote:
>  | Bernhard Schmidt wrote:
>  | 
>  | > Do you have the necessary force to avoid ip6.int sneaking in through
>  | > ns.isi.edu (which is a listed authoritative server of .int and has
>  | > ip6.int loaded into)?
>  | 
>  | Well, it's slightly worse than that actually. Not only does ns.isi.edu still
>  | have the zone loaded, but it's (the only INT server) still running the
>  | 2006050200 version of the INT zone which still has the delegation. Bill,
>  | time to play nice with others. :)
>  | 
>  | As long as we're at it, ns3.nic.fr is still serving the ip6.int zone as
>  | well. Stephane? Anyone else from AFNIC?
> 
> ==> Maybe that wasn't the best way to do it but I wished to see 
> the delegation from .int to ip6.int cut before asking ip6.int
> authoritative servers to stop serving that zone. If I had to
> deconfigure ip6.int on ns3.nic.fr before the delegation int -->
> ip6.int being cut, I would simly have caused a lame delegation which
> is not a clean way to make ip6.int disappear from the DNS.
> 
> I removed all RIR-based *ip6.int zones on ns3.nic.fr because RIRs had
> already cut the delegation. I presume that was the right order of
> actions.
> 
> Now, the ip6.int has gone from ns3.nic.fr thus creating a lame
> delegation. It's up to the parent zone maintainer to take the
> appropriate actions.
> 
> Regards,
> 
> Mohsen.

	amen.  and ns.isi.edu is still prohibited from doing 
	zone transfers from ICANN, so the copy of the int zone
	it serves will be lame until ICANN removes the block.

--bill