Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 22 Oct 2004 05:59:35 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark Andrews

> "Hallam-Baker, Phillip" writes:
> > Paul writes:
> > > if new rr's take too long on deployment to be useful for 
> new globally
> > > deployed services and service models to be practical, somebody had
> > > better tell microsoft that using SRV was a mistake.
> > 
> > Microsofts use is a bad example. Microsoft use SRV to 
> configure windows
> > in an environment where Windows is the infrastructure. To take
> > advantage of the SRV all your infrastructure has to have been 
> > upgraded already.
> 
> 	Well lets look at another example AAAA.  The ends that
> 	wanted to use AAAA upgraded their servers and apart from a
> 	few load balancers, which also usually didn't handle SOA/NS/MX
> 	records, there were no major problems.  AAAA as we know
> 	required much more than just adding a new rdata type.

If it is that easy then why don't you go get everyone to
deploy and let me know when you are finished. Just get off
my critical path until you are done.

If Ipv6 is the best example you can propose then I guess
we don't need to argue this any more.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 22 Oct 2004 15:16:38 +0200

On Fri, Oct 22, 2004 at 05:59:35AM -0700,
 Hallam-Baker, Phillip <[email-masked]> wrote 
 a message of 38 lines which said:

> > 	Well lets look at another example AAAA.  
...
> we don't need to argue this any more.

Mark Andrews mentioned the deployment of AAAA-capable servers and
clients (which is quite advanced), not the deployment of IPv6-capable
hosts and routers, which is far from being done.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Oct 2004 00:49:47 +1000

> we don't need to argue this any more.

	I choose AAAA because it was a example where there are
	literally millions of clients making queries today and there
	is basically no problems despite clients making queries to
	servers that don't know how to serve AAAA.

	Every time we add a new RR type people say it can't be done.
	It will take to long to upgrade all the servers.

	Guess what you don't have to upgrade all the servers.

	Guess what you get servers capable of serving the new type
	in weeks, if not days or earlier of the type definition
	being finalised.  After that it is up to the people who
	want to use the type to upgrade there servers.
	
	I've never been worried about the ability to deploy new
	types.  We did it wrong the first few times by allowing
	compression of rdata but we are well past that now.

	If we had listened to the naysayers none of RP, AFSDB, X25,
	ISDN, RT, NSAP, NSAP-PTR, SIG, KEY PX, GPOS, AAAA, LOC,
	NXT, EID, NIMLOC, SRV, ATMA, NAPTR, DNSKEY, NSEC and RRSIG
	would have deployed.  Some of them are not used much but
	there are servers available for all of them.

	As for marid the people you need to convince are the SMTP
	developers.  You need to convince them to move to a new
	type *and* to rip out the old TXT based code.  If you don't
	do the later changover will take a long time as people will
	continue to use the TXT based crutch.  Pull the crutch away
	and they will use the new type.  I realise that by doing
	this forgeries will get through that would otherwise be
	caught but a little short term pain is better that a long
	drawn out transition.

	I'm seeing the same thing w/ the IP6.INT -> IP6.ARPA
	transition.  It is taking a long time because people left
	the IP6.INT crutch in place.  We really should not be
	shipping resolvers that use IP6.INT.  Stop making the old
	lookups and the new records will appear.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked]
Date: Fri, 22 Oct 2004 15:06:03 +0000

> 	lookups and the new records will appear.

	actually, when the queries stop (e.g. the old resolvers
	are upgraded) the servers will be turned off. the new 
	delegations (and by extention RR types) need to be visable
	first.  

--bill

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Oct 2004 07:34:22 +1000

> 	delegations (and by extention RR types) need to be visable

	The problem is that new resolvers try IP6.ARPA then if they
	don't get a answer they try IP6.INT.  You will never see
	the IP6.INT queries drop off as there will always be a
	significant number of addresses that have neither a IP6.ARPA
	or IP6.INT PTR record.  The only way out of this is for OS
	vendors to be brave enough to stop using IP6.INT as a crutch
	or for someone to be brave enough to put in "IP6.INT DNAME
	IP6.ARPA".  Once that is done you can say to the OS vendors
	that it is now pointless to try IP6.INT if you don't get a
	IP6.ARPA response and the later can't exist.

	Look like KAME has bitten the bullet.  Hopefully the rest will
	follow.  The following is from FreeBSD.
	Note: I havn't checked any of the others.

	MFC: now e.f.f.3.ip6.arpa is delegated, we no longer need to
	query ip6.int

	Mark