Subject: Re: non-DNS name services

From: Keith Moore <[email-masked]>
Date: Wed, 28 Aug 2002 12:50:19 -0400

>no, all I need to prove is that we have an installed base that is dependent
>on the APIs that are used to do DNS lookup having DNS semantics.  whether
>those semantics are right or wrong is immaterial if changing them will break
>applications.

        as i have wrote repeatedly, use of multicast DNS did not break any
        applications for me.  if you have evidence that it actually broke
        your applications, you have to tell us the details so that we can fix
        things.  if you are making discussion based on armchair theory,
        i suggest you to speak up again only after trying it out for real.

that's just completely wrong.   you analyze the design *before* you 
deploy it widely.  experience with implementation and early deployment 
tells you whether the specification was precise enough, and whether
you have any unforseen problems (or benefits). it does NOT tell you
a number of other things - such as the impact on operations of existing
applications or networks, the degree to which it scales, or whether it
affects security.

for any new technology that affects an existing service, this idea 
of "you have to prove it's broken to stop it" is broken.  the burden 
needs to be on the proposers to demonstrate - certainly by analysis,
perhaps also by operational testing - that the proposal will not have 
a disruptive effect.

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 28 Aug 2002 13:03:16 -0400

On Wednesday, Aug 28, 2002, at 12:50 America/Montreal, Keith Moore 
> perhaps also by operational testing - that the proposal will not have

Keith,

	I understand that you believe the above.  However, the IETF process
does NOT require that the burden is 100% on the proposers.  As this is
an IETF WG, your preferred approach is not the same as the actual
ground rules in place here.

	Moreover, as Bernard has pointed out, you're raising your issue in
the wrong WG anyway.

Ran

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Aug 2002 13:09:56 -0400

> does NOT require that the burden is 100% on the proposers.

understood.  IMHO it's a change that is badly needed.
of course, this isn't the right group to discuss *that* either.

I noticed that dnsext has just revised the mdns draft so I'll comment 
on that draft to the dnsext mailing list.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 28 Aug 2002 16:22:43 -0400

> applications or networks, the degree to which it scales, or whether it

Actually, test deployments are part of testing. You cannot get a 
thorough or reliable analysis without real-world testing. That does NOT 
mean you deploy it across 50,000 machines on tuesday and see what 
happens. But you aren't going to get squat for reliable data on 
scaling, security, operational impact until you actually try it.

Because paper can be wrong...which is why the C-124 was the bumblebee 
of cargo planes.

> perhaps also by operational testing - that the proposal will not have

Analysis alone is never enough. On paper, lots of things look good. But 
you *need* operational testing to look at silly things like 
implementation details. Theoretical analysis can only go so far. At 
some point, someone's got to fire it up.

john

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Aug 2002 18:37:48 -0400

> Analysis alone is never enough.

didn't say it was.  but there are far more cases that you can analyze
than those you can test.  you need the tests to verify your analysis,
not to verify your design.

Keith

---

From: [email-masked]
Date: Thu, 29 Aug 2002 07:45:57 +0900

>perhaps also by operational testing - that the proposal will not have 

	"We reject Kings, presidents, and voting. We believe in rough
	consensus and RUNNING CODE".
	so what's bad about trying things out in real life?

itojun

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Aug 2002 19:19:59 -0400

nothing.  but we also need to recognize that it has its limitations.

also, the internet is a lot bigger place than it used to be.  
what was "good enough" in the mid-1980s when there were tens of
thousands of users on the net and nearly everyone on the
net ran some kind of BSD isn't necessarily good enough now.

as for the perils of trying things out in real life, I keep 
thinking of the Tacoma Narrows Bridge, which was built in spite
of analysis that showed that it would fail under wind loads.

Keith

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 28 Aug 2002 16:26:37 -0700

> of analysis that showed that it would fail under wind loads.

So is there some analysis (something other than pure speculation) that 
shows that IPv4 link local addresses or mDNS or NAIS will wreck havoc? 
I haven't seen anything yet, with the exception of issues with 
multihomed hosts and IPv4 link-local addresses.

-josh

---

From: [email-masked]
Date: Thu, 29 Aug 2002 08:31:03 +0900

>>net ran some kind of BSD isn't necessarily good enough now.

	tell me - what kind of service will break at utk.edu if i use multicast
	DNS in my network at itojun.org?  the network size argument you have
	been using does not convince me at all.

itojun

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Aug 2002 19:38:54 -0400

>         tell me - what kind of service will break at utk.edu if i use
>         multicast DNS in my network at itojun.org?

tell me - do you think that that software devleopers want their products
to act differently depending on whether they're run at utk.edu or itojun.org?

I'm in the middle of doing detailed analysis on LLMNR - so I'll refrain
from making detailed comments until that's done.  And I'll make those 
comments to the dnsext WG. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Aug 2002 22:07:10 -0400

> shows that IPv4 link local addresses or mDNS or NAIS will wreck havoc?

Yes, there are several problems with IPv4 LL, many of which I've described
in detail in comments to this WG and to the IESG.  No they are not 
addressed in the current draft.  I'm working on the analysis for LLMNR. 
Yes, there are problems with it also - descriptions are forthcoming.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 29 Aug 2002 00:17:42 -0400

> not to verify your design.

they do both in the end, analysis can't cover everything. Reality is 
too chaotic.

john

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 29 Aug 2002 00:19:35 -0400

> of analysis that showed that it would fail under wind loads.

Deliberate stupidity cancels everything out. on paper, a B-1B's ECM 
system is a snap to maintain, 200+ *easily replaceable" units....the 
reality is quite different, but for reasons you couldn't predict 
without doing the replacing.

john

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 29 Aug 2002 00:21:28 -0400

> to act differently depending on whether they're run at utk.edu or 

So far, I see no evidence that this will happen other than vague 
warnings of bad things.

john

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Aug 2002 08:30:27 -0400

> without doing the replacing.

truly, analysis can fail, just as testing can fail.  but it's certainly
appropriate to use analysis before you widely deploy something,
particularly something that changes the functionality of a widely-used
service.

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 29 Aug 2002 10:14:56 -0400

> particularly something that changes the functionality of a widely-used

There is a difference between testing deplyoments and production 
deployments. I agree that revamping anything for Zeroconf right now 
would be immature. *But*...I also think radically changing or dumping 
Zeroconf based on what is almost entirely theory would be just as 
immature. So you test the potential problems. *That* way, you have 
real, reproducible hard data. You can argue theory, you can argue 
analysis. It's real hard to argue with :

"If you set this system up under these parameter, it does the following 
bad things..."

As well, if you have real, hard data from real testing, then you make 
it *far* easier to implement spec changes in a methodical, coherent 
fashion.

Never ignore analysis, but don't insist that it's a substitute for 
firing up the system either.

john