uh..thats two independent implementations at a minimum. I am hearing two
complain BIND and DENT. The complexity for what you say is to complex. So
what we need to do is revisit it. So we are following the process sir.
/jim
> -----Original Message-----
> From: ext Christian Huitema [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday,February 07,2001 9:30 PM
> To: [EMAIL PROTECTED]
> Subject: RE: The case against A6 and DNAME
>
>
> I think we are hearing the same argument over and over again, so let's
> repeat the other side of the story:
>
> 1) Perl script don't help you if you must compute RSA signatures for
> 10,000 records -- or 10 millions. Having to sign one record instead of
> 10,000, on the other hand, is very beneficial.
>
> 2) If your site has 4 prefixes and 10,000 hosts, then A6 allows you to
> have four times less DNS records to handle.
>
> 3) With A6, you can exercize "site redirection" by publishing short
> lived A6 records for your site, while leaving the host and server
> records unchanged.
>
> The argument in the page is essentially an argument against dependency
> loops. The dependency loop occurs when one needs to contact a
> nameserver
> in order to get the address of that same nameserver. The problem is
> aggravated by "anti-poison" protections that essentially
> prevent serving
> cached records from domains for which the local server is not
> authoritative. May I observe that if "zone administrators
> (could) write
> trivial perl scripts", then they could just has well write a trivial
> perl script that checks for dependency loops? In any case, it
> is fairly
> easy to write reasonable guidelines on how to use the
> technology without
> creating loops -- the AOL example is a great way to explain what to do
> and what not to do.
>
> As for deprecating or otherwise removing standards, we have a
> clear IETF
> process. A standard progresses if it is implemented and used,
> and if we
> can demonstrate successful inter-operation between independent
> implementations. Let's just follow the process...
>
> -- Christian Huitema
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
