Subject: Re: non-DNS name services

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

YP (later NIS) did indeed break applications, and is one of the things 
that demonstrated to me that overloading of new services on existing 
interfaces was a dubious idea.   There are lots of examples:

- YP could return inconsistent results from DNS both in obvious ways
(different name-to-address bindings) and subtle ways (canonical name
for an address might be an FQDN in one case and not in another).
this could result in different hosts in a conversation having
different views of "DNS" (i.e. host name<>address mapping) and 
causing things to break in subtle ways.

- failure modes were different: a host could wait indefinitely on YP
binding when a DNS query would have timed out - this could cause 
failures for applications that were time-critical. (to some degree 
this was a result of overloading the gethostbyname interface to do 
DNS queries rather than local-file lookup - hence the clunky h_errno 
hack - which was at first only supported for DNS queries)

- capabilities were different: originally YP tried to completely substitute
for DNS, which meant that essential services like MX lookup were not 
available.    For many years Sun distributed two version of sendmail -
one with DNS/MX support and one which used only YP - the latter would
simply bounce mail for any domain that didn't have an A record (even
if it had an MX record).

of course, YP was deployed a long time ago, and at a time when the Internet
was much smaller than it is now - so the impact was much less than it would be
now.  and both applications and host implementations have adjusted since YP
was initially deployed.  for many years it was necessary to explicitly
link -lresolv to your applications in order to get the version of 
gethostbyname() that did DNS lookups. nowdays -lresolv might not actually 
redefine gethostbyname() to use DNS but the chances are good that the sysadmin 
has included "dns" in the nss switch file.  but to be sure you might have to
call the res_* routines explicitly if you really need DNS lookup. and modern 
implementations of NIS are probably better at setting h_errno to return 
similar error codes for similar conditions across different services.  but
even now, NIS is a potential source of DNS inconsistency from one host to 
another (producing problems similar to those produced by multi-faced DNS) 
and it's still possible for applications to get bitten by it.

one other important difference - NIS was never standardized.  we can't 
stop vendors from putting dubious features in products, but we shouldn't
bless such practices.  and yes, even though many of the problems
have been sorted out (if memory serves it took about 10 years for this 
to happen) using NIS for hostname lookup is *still* a dubious idea.
it mostly serves to increase the potential for errors, while adding
very little additional functionality - the chief benefit seems to be
that it provides a way to do the equivalent of two-faced DNS (which 
is also known to cause problems) in a more complex and error-prone fashion.

	you have been arguing that multicast DNS (or LLMNR) is bad as it mimics
	DNS behavior and breaks applications.  i would like to hear your
	comment about NIS and NIS+.  they are widely deployed, integrated
	into name resolution functionality of systems (gethostbyname), and
	certainly overrides DNS in NIS-configured network.

	from my experience, all NIS, NIS+ and multicast DNS work just fine,
	no problem observed.  if you are okay with NIS/NIS+, you should be
	okay with multicast DNS.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Aug 2002 05:30:23 -0700 (PDT)

On Wed, 28 Aug 2002, Keith Moore wrote:

> - YP could return inconsistent results from DNS

> - failure modes were different:

> - capabilities were different:

> NIS was never standardized.

> many of the problems have been sorted out

This reads like an argument for careful review of mDNS/LLMNR to make sure
that the problems you cite are minimized.

I'd note that mDNS and LLMNR do have some important differences along
these dimensions.

---

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

> that the problems you cite are minimized.

yes, that's what I expect should be done - while also considering the 
possibility that it might be better to abandon the approach altogether.

---

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

> possibility that it might be better to abandon the approach altogether.

two questions:

1)	Have you done a careful review?

2)	What do you propose in Zeroconf's place?

john

---

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

> 1)      Have you done a careful review?

I'm working on it now.  
 
> 2)      What do you propose in Zeroconf's place?

now is not the time to ask.  suffice it to say that reviewing this
document hasn't raised my opinion of the group.

Keith

---

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

>> 1)      Have you done a careful review?

<sigh> commenting on something without having carefully reviewed it.

> document hasn't raised my opinion of the group.

well, blasting the idea without a good replacement is a waste of time, 
eh?

john

---

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

> <sigh> commenting on something without having carefully reviewed it.

I had in fact carefully reviewed an earlier version of mdns;
I just hadn't read it recently.  So it was possible that the problems
had been fixed.  But they haven't.
 
> well, blasting the idea without a good replacement is a waste of time, eh?

frankly I think it would be more constructive if people would actually try to 
address the technical problems with their proposals rather than claim that they
don't exist and to malign the person who points them out.

---

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

> don't exist and to malign the person who points them out.

I, and a lot of people, simply want *proof* of these problems...yes or 
no. So far, we haven't been able to test them. All the criticism has 
been "may" or "could" or "might", but until someone can say "did" and 
"does", then we *don't know for sure*.

Which is why real, physical testing of potential problems is needed. 
Otherwise, we knife something based on theory. That would be an even 
greater waste of time.

john

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Aug 2002 11:12:06 -0400

> "does", then we *don't know for sure*.

nope.  you've got it backwards.  when you're trying to standardize 
technologies that change how IP and DNS work - i.e. two of the three 
most critical parts of Internet technology - the burden needs to be on 
the proposers to analyze the risks and persuasively argue that the
changes you are propsing will not cause harm to existing infrastrucutre
or applicatoins.  mere testing is unpersuasive because it cannot even 
begin to cover the conditions that will be encountered in the real world.

> Otherwise, we knife something based on theory. That would be an even

no, the greater waste of time is trying to fix problems caused by 
irresponsible widespread deployment of poorly-analyzed technology.

Keith

---

From: [email-masked]
Date: Fri, 30 Aug 2002 00:18:55 +0900

>irresponsible widespread deployment of poorly-analyzed technology.

	from the recent measurement results made against lame delegation, TTL
	misconfiguration and such, i don't believe DNS behavior is analyzed
	well enough (it is still a mistery why it works this well).
	so if i follow your logic you need to remove DNS from your
	infrastructure.  you have to type in IP addresses in numeric form :-P

itojun

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 29 Aug 2002 11:32:27 -0400

> begin to cover the conditions that will be encountered in the real 

Sigh...so in other words, since you cannot cover 100% of every 
situation, then we should sit on our hands and never test anything 
again, but rely on the perfect and complete accuracy of theoretical 
analysis...which gave us such great and widely implemented protocols 
like OSI.

According to your logic, nothing should be done anywhere unless every 
possible contingency can be accounted for. So no more software updates, 
because you cannot predict and test for every single situation. No more 
new hardware, you cannot predict and test for every situation. What the 
heck, we didn't need anything more than what we have now anyway. 
Obviously any work on dns and TCP/IP should be immediately halted until 
a 100% guarantee can be made that all possible problems have been 
predicted and corrected.

Pardon me if I think that this is of course, silly. Obviously we cannot 
build a replica of the internet. But if enough people test in different 
situations, we get a good sample that will minimize the unpredictable. 
Murphy's law is not a theory.

I don't expect that any testing will be 100% effective. But in 
combination with analysis, it will be *really* close.

> irresponsible widespread deployment of poorly-analyzed technology.

Um...have you read anything I've written? I said *testing* not 
*production deployment*. I really fail to understand why you think that 
testing and analysis are mutually exclusive, and that testing and 
production are not..

john

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Aug 2002 11:32:47 -0400

>         well enough (it is still a mistery why it works this well).

I'd probably agree.

>         infrastructure.  you have to type in IP addresses in numeric form :-P

no, it doesn't follow.
for better or worse, DNS is already deployed, and people depend on it.

the fact that DNS is already deployed doesn't justify deploying other 
things that change how DNS or IP operates, for which there is plenty of
reason to suspect that they will break applications, and for which 
analysis provides no reason to be confident that they will not break
applications.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Aug 2002 12:13:11 -0400

> analysis...

No, that's not what I said, and your interpretation of it is unwarranted.

But if you can't even interpret plain English text then you are obviously 
incapble of performing analysis on a technical protocol specification.
Hence, further discussion along these lines with you is futile.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 29 Aug 2002 12:34:37 -0400

> Hence, further discussion along these lines with you is futile.

If people continually misinterpret you, maybe you should make an effort 
to be more concise and precise in your language.

You *said*:

"mere testing is unpersuasive because it cannot even begin to cover the 
conditions that will be encountered in the real world."

which of course no one has advocated.

you've also *said*:

"as for your supposed real-world testing, I don't think MIT can even 
approach the diversity that exists in the internet.  So I'd consider it 
useless."

now, it's not unreasonable to derive from these statements that you 
seem to think that if you cannot test for *everything* and *anything*, 
then testing is useless and shouldn't even be attempted.

I, nor anyone else has advocated testing without analysis, although you 
have continually acted as though we have. If you aren't listening to 
anyone who disagrees with you is saying, then you're right, further 
discussion is futile.

john

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Aug 2002 12:52:59 -0400

> then testing is useless and shouldn't even be attempted.

yes it is unreasonable to derive that,  because that's not what was said.
what I said was that you need to do analysis about possible failure modes, 
and that the kinds of tests that are done need to be driven by the
analysis - not by merely deploying it somewhere and seeing if it works. 

something that I didn't say (but which I believe) is that testing can reveal 
failures that weren't disclosed by analysis, but that the failure of a 
test to demonstrate a flaw doesn't necessarily mean that the analysis that 
said there was a flaw was wrong - since you usually can't provide sufficient 
test coverage.

> I, nor anyone else has advocated testing without analysis

perhaps not, but I haven't seen any attempt to actually *do* the analysis.

Keith

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Aug 2002 09:59:22 -0700

Hello John,

I've read most of the volumes of discourse on this, trying to
see all sides.  I'd be interested in your short answers to
these questions:

- Is there any non-DNS solution that would make sense to you?

- Do you agree that name resolution is qualitatively different
  than service resolution?

- Could you imagine changing SLP in some way to fit the
  needs as you perceive them?  If so, then why isn't that
  a better idea than changing DNS?

- Is anyone contending that zeroconf (per se) is itself
  harmful?  I hope not, but some of the messages seem to
  be ambiguous on this point.

My idea on analysis vs. testing, by the way, is that both
are crucial.  And I thought everyone agreed on that.
Unfortunately, it's totally easy to find examples where
one or the other was omitted, and success still happened.
It's also possible to find examples where one was omitted,
and blame consequent failure on that.  It's also possible
to find examples where analysis indicates "failure" and
yet success still happens (maybe NAT as an example), but
because somehow the costs shown by analysis are not
perceived as outweighing the benefits.  Maybe even
the costs are cumulative and the customers do not somehow
mind until it's too late (consider the parable of the
lobster in the cooking pot).  The point of this rambling
paragraph is that the debate can go on forever without
conclusion because both sides have ample evidence that
they're correct because they are both close enough to
being correct.

Regards,
Charlie P.

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 29 Aug 2002 13:12:39 -0400

> analysis - not by merely deploying it somewhere and seeing if it works.

I *never* said "Just deploy it and see if it works". I said test it and 
see how the analysis really works, and get some real, as opposed to 
theoretical data. If there's something broke, testing will quickly 
reveal it, and likely give you a better idea of how to fix it.

> said there was a flaw was wrong - since you usually can't provide 

Then design a test to beat on a theoretical flaw. If analysis shows a 
likely problem, you can test for that.

> perhaps not, but I haven't seen any attempt to actually *do* the 

Um...right. Everyone here has just advocated blindly implementing 
Zeroconf as is, with no testing or analysis whatsoever.

john

---

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

> - Is there any non-DNS solution that would make sense to you?

So far, no. I haven't seen hide nor hair of one that would be 
implementable across the range of platforms and work in a predicable, 
usable fashion.

> - Do you agree that name resolution is qualitatively different

It depends on how you look at it. If you mean that service resolution 
has to return all possible capabilities of a device, then yes.

However, if all you want are a list of names of things that do <task>, 
then not really. And so far, the best, and most useful implementations 
of service discovery return names of things that print, share files, 
etc. So, based on that, and the fact that humans look for things by 
name, not capabilities, then name resolution is the best way to go for 
service resolution. And we already have a name resolution system, that 
on paper, is unwieldy, kludgy, limited, yadda, yadda....but, it works, 
it works well, and I have yet to see any hard data of any sort from any 
naysayer that shows how Zeroconf is going to somehow globally pooch 
DNS. I'm going to test it on my own, and see how things actually work. 
If more people take what little analysis has been done, test that, add 
to the valid list of what is good and bad, then we will quickly get a 
valid idea of the way to refine and implement, or not implement 
Zeroconf.

>   a better idea than changing DNS?

I first have to imagine an implementation of SLP that isn't so poor as 
to be unusable., and it has to be usable on more than three platforms. 
So far, *maybe* Novell has a usable SLP implementation. Apple's is file 
sharing only and sucks. Sun's is too complex to be taken widely usable, 
and therefore isn't. It doesn't exist as far as Microsoft is concerned. 
It's a great protocol, but the designers completely pooched 
implementation, and in fact, Apple is *dropping* SLP anyway. So none of 
the two majority desktop systems really support SLP anymore. Maybe if 
implementation  and testing had mattered as much as theory, we wouldn't 
need to have this argument.

As far as SLP itself goes? It's too complicated. It tries to do too 
much, and in doing so, works really poorly on the platforms that it 
works at all on. Engineerspeak aside, humans just want a list of 
printers, servers, etc. near them. Name the printers well, and you're 
golden. People just want a list of stuff that does what they need with 
meaningful names. Unless you get that, you are going to be barking up 
the wrong tree forever.

>   be ambiguous on this point.

some people do. I'm not one of them until I see proof.

> are crucial.  And I thought everyone agreed on that.

so did I. Evidently, we were wrong.

> they're correct because they are both close enough to

I just think that any idea that gets to the point where it can be 
tested should be. Theory is good, analysis is good, but in the end, 
testing data is still better, and in concert, all three give you the 
best data.

john

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 29 Aug 2002 10:50:51 -0700

> - Is there any non-DNS solution that would make sense to you?

I haven't seen anything else either. Why would we want to invent 
another protocol to work for an unconfigured network when one that is 
already out there will work so well?

> - Do you agree that name resolution is qualitatively different

DNS stands for Domain Name System right? Was it ever stated that DNS is 
really just a Domain Host Name System. What is the difference in using 
DNS to name services in addition to hosts. They're all just named RRs.

>   a better idea than changing DNS?

SLP could be changed, but the degree of change required to make SLP 
work appears to be a lot more effort that just using what already 
exists in DNS. In addition, the effort to get SLP deployed appears to 
be much more work than DNS. DNS doesn't need to change to support 
finding services, all of the necessary RRs and infrastructure are 
already there. DNS-NIAS does not require any changes to the DNS 
protocol, it is just a usage model. There are no additional RRs 
required. There are no changes required of servers. There are no 
changes required of the client, though libraries that give application 
developers a simpler API than res_query would make things a lot easier. 
It is not at all clear how DNS-NIAS would lead to the meltdown of the 
internet as one on this list has so passionately argued would happen.

>   be ambiguous on this point.

I don't think anyone has said that.

---

From: Robert Elz <[email-masked]>
Date: Fri, 30 Aug 2002 21:26:29 +0700

Date:        Fri, 30 Aug 2002 00:18:55 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	from the recent measurement results made against lame delegation, TTL
  | 	misconfiguration and such, i don't believe DNS behavior is analyzed
  | 	well enough (it is still a mistery why it works this well).

Actually, there's no real mystery at all - if you think a little about
what is failing, and what is working, and add some knowledge of the
DNS design to all of that, it is all blindingly obvious why it works.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 30 Aug 2002 21:26:47 +0700

Date:        Thu, 29 Aug 2002 13:28:16 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I just think that any idea that gets to the point where it can be 
  | tested should be. Theory is good, analysis is good, but in the end, 
  | testing data is still better, and in concert, all three give you the 
  | best data.

I think you're missing the point that it is useless to test unless
you have some idea what to test for.

Basic operation under ordinary circumstances is fine - but also easy.
Other than in the wildest circumstances, if someone can look at a
protocol and believe it will work (which its author at least generally
does) then it is probably close enough that if you just turn in on
it will "work".    Testing to see that is a waste of time (and you usually
get plenty of it anyway, as a side effect, while shaking out implementation
bugs, as distinct from protocol bugs).

To achieve anything worthwhile, you have to know what to test for.
That is, you look at the protocol, and you're suspicious that it doesn't
scale well, so you test a very large installation, and see what happens.
Or you look at the protocol, and are suspicious that it won't work well
if responses are slow, so you stick it on a slow server on a very heavily
loaded network, with a long RTT, and see.   Or you are suspicious that it
won't do well if there's heavy packet loss, so you ...

But just "try it and see if it works ok for me" kind of testing is
completely useless for our purposes.   It is just fine if your aim
is to decide whether to use the thing or not yourself, but not if
the aim is (as ours is here) to recommend to others that they use it.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 30 Aug 2002 21:26:59 +0700

Date:        Thu, 29 Aug 2002 00:10:40 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | well, blasting the idea without a good replacement is a waste of time, 
  | eh?

This is total nonsense.    If an idea is a poor one, then that is
what it is, whether or not there's an alternative.

Sometimes, pressing need, and the lack of an alternative might drive
one to accept a poor idea.  But it is still a poor idea,  it doesn't
become better just because people are forced into using it.

kre

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 30 Aug 2002 09:46:50 -0500

----- Original Message -----
From: "Robert Elz" <[email-masked]>
To: "John C. Welch" <[email-masked]>
Cc: "Zeroconf" <[email-masked]>
Sent: Friday, August 30, 2002 9:26 AM
Subject: Re: non-DNS name services

> become better just because people are forced into using it.

IPv6 is a good example of that. It can be expensive to blindly accept poor ideas.

http://www.iht.com/articles/69229.html
PARIS Europe's bold hopes for third-generation mobile-phone services have come crashing down to earth. By one estimate, perhaps half
of the licenses that West European companies bought two years ago for fast networks will never be used - meaning $50 billion will
have been spent for nothing."
================================

Who pays for bad ideas ?

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 11:52:17 -0400

> what it is, whether or not there's an alternative.

It doesn't mean a poor idea isn't poor. But if you're going to spend 
the time to blast away at any idea, then it's far more constructive to 
spend just as much time trying to come up with a better way to solve 
the problem.

john

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 11:59:12 -0400

> you have some idea what to test for.

Of course...but at the moment, we *do* have things to test for:

1)	Interaction with current DNS setups
2)	Interaction with current network addressing setups
3)	Interaction with current security setups
4)	Interaction with current services

> bugs, as distinct from protocol bugs).

I've no doubt that you can get basic operation out of anything. You 
test to see what happens when you beat on it. When you do 'cool' things 
with it. When you do silly things with it. When you do deliberately 
stupid things to it. When you let people who *aren't* network geeks at 
it.

> scale well, so you test a very large installation, and see what 

Right. No argument

> won't do well if there's heavy packet loss, so you ...

Right. No argument.

> the aim is (as ours is here) to recommend to others that they use it.

The idea is to get a *lot* of people testing it in different setups, to 
probe for faults and bugs, to see how it holds up under the infinite 
varieties of what we call 'normal' use. And *abnormal use*, whatever 
that means.

I'm working to see what happens when you get a *lot* of people banging 
on it, how well it holds up, what the network does, etc.

there are already very obvious things to test for, and as the analysis 
continues, we'll get more things to test for. And Zeroconf will either 
become better, or it will be obvious that it isn't going to work. But 
you won't know for sure with *just* testing, or *just* analysis. You 
*have* to have both.

john

---

From: james mcmurry <[email-masked]>
Date: Fri, 30 Aug 2002 09:38:30 -0700

Very great idea !

This will help everyone to understand zeroconf more!

http://maccentral.macworld.com/news/0208/29.rendezvous.php

---

From: John Schnizlein <[email-masked]>
Date: Fri, 30 Aug 2002 13:01:32 -0400

Thank you for bringing this to our attention.
There are several problems with this text.

ZeroConf is not a standard (yet).

This language is not consistent with the fact that the IETF is not
composed of company representatives, but individual contributors.

How can it be "first documented" when there is no RFC yet?
Internet Drafts are explicitly not to be referenced. 

    Rendezvous is Apple's implementation of the ZeroConf standard 
    documented by the Internet Engineering Task Force (IETF), 
    the group responsible for defining Internet standards. 

    First documented in the late 1990s by the IETF and sponsored 
    by Apple, Rendezvous is a zero configuration technology that 
    brings together Internet IP standards and LAN networks.

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 30 Aug 2002 12:13:33 -0500

----- Original Message -----
From: "John Schnizlein" <[email-masked]>
> composed of company representatives, but individual contributors.

http://www.ietf.org
"The IETF is an organized activity of the Internet Society"

...the Internet Society is a company...it has "company representatives"...

http://www.icann.org/announcements/announcement-19aug02.htm
"We received eleven very strong and thoughtful proposals," noted Stuart Lynn, President of ICANN. "We appreciate the response of the
institutions behind these proposals. The ISOC proposal was the only one that received top ranking from all three evaluation teams.
====

The ISOC plans to be a Registry.....Apple is a Registry.....both are companies....
http://www.iana.org/assignments/ipv4-address-space
017/8           Apple Computer Inc.                     Jul 92
====

Jim Fleming

P.S. CISCO is a company....

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Aug 2002 13:23:11 -0400

> Very great idea !

very bad idea - this will propagate buggy protocols that isn't yet up 
to standards-track quality.

actually I have no problem with distributing code for use on an 
experimental basis as long as people are aware that the protocols
are subject to change - I think it's very unfortunate that this code
is in shipping production products.

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 30 Aug 2002 13:27:07 -0400

On Friday, Aug 30, 2002, at 13:23 America/Montreal, Keith Moore wrote:
> I think it's very unfortunate that this code

	Since it works just fine, I'm sure glad that it is
running in my laptop today (and not at some future decade
when IETF gets its process unwedged)...

	Oh, and Apple is to be commended for making their
source code available.  Thanks also to Stuart Cheshire,
who no doubt had some hand in this happening...

Cheers,

Ran

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Aug 2002 13:29:33 -0400

> spend just as much time trying to come up with a better way to solve

a bit of analysis shows that that's not necessarily true. 

if a proposal will do harm if propagated, then any effort which results
in minimizing and/or delaying the harm done is well spent.

on the other hand, a half-baked competing proposal - even one which has 
the kernel of a better idea buried in it - is often little better than 
no proposal.  sometimes it is worse, because an apparently-complete 
proposal (even if it is based on a bad idea) may seem to compare favorably 
with an incomplete one (even if it is based on a good idea).  this is 
usually a fallacy based on failure to compare both proposals with
respect to the same set of requirements, but it's a mistake that is 
commonly made.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Aug 2002 13:32:57 -0400

> But you won't know for sure with *just* testing, or *just* analysis. 
> You *have* to have both.

but you do not need to have all of your analysis verified by testing,
or vice versa.  analysis and testing tend to cover different cases -
you learn from each of them, but you can only use one to verify the
other when they overlap.

for instance, there's no practical way to test the effect of zeroconf
protocols on the wide variety of applications and wide variety of
network configurations that are out there.  the most test coverage you
can hope for is to try it with the applications you use normally and 
on a few specific network configurations.  that's not even a drop in the
bucket.

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Aug 2002 13:34:39 -0400

> when IETF gets its process unwedged)...

ah, but it *doesn't* work just fine - it just hasn't broken when
you tried it - at least not in a way that you noticed.

I do appreciate their giving the code away - it makes it more likely
that there will be free implementations of the fixed version of zeroconf
once we get the protocols fixed.  The problem is in misleading the public
that this is a robust protocol.

Keith

---

From: james mcmurry <[email-masked]>
Date: Fri, 30 Aug 2002 10:36:24 -0700

I think this is a great experiment that the zeroconf group should 
follow.

Think of it, suddenly there is a base of over 100,000 (Apple Press 
Release on monday stating they had sold 100,000 copies over the 
weekend, not counting the sell out of 10.2 in England)  users who have 
this implementation of zeroconf running on their systems.  Granted not 
everyone will be using it immediately, but they will over time.

I think Apple, by releasing their source code, is making a gesture that 
they want a speedier process, and want others (like printer 
manufacturers) to get up to speed quicker.

Now Keith may think this is a very BAD idea, I know.  Keith is very 
important in this process, you always need a Keith around to be the 
real Devils-Advocate to ensure we really dont do anything stupid.  But 
in the end, you need to draw a line in the sand, and jump.......good 
bad, right or wrong.....

Jim

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 30 Aug 2002 13:36:15 -0400

Keith,

	If you'd spent the time doing analysis this week,
instead of blathering on the wrong IETF mailing list,
you might have actually been able to generate a list
of technical problems you perceive.

	Its rather a pity that you preferred to send high
volumes of repetitive non-technical email rather than
spend the time doing the analysis you seem to think is
required.

	Sigh.

Ran

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 30 Aug 2002 12:40:24 -0500

----- Original Message ----- 
From: "james mcmurry" <[email-masked]>
To: "Zeroconf" <[email-masked]>
Sent: Friday, August 30, 2002 11:38 AM
Subject: Slightly OT: Apple to Release Source Code to its zeroconf implementation 

> http://maccentral.macworld.com/news/0208/29.rendezvous.php

Should we release the C@t ?
http://www.ddj.com/articles/1993/9310/

http://maccentral.macworld.com/news/0208/25.jaguar.php

Jim Fleming

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 30 Aug 2002 13:42:51 -0400

On Friday, Aug 30, 2002, at 13:34 America/Montreal, Keith Moore wrote:
> ah, but it *doesn't* work just fine

Keith,

	Please send a formal proof that it is broken.

	Until then, I will continue to believe that you have
NO DATA, NO ANALYSIS, and NO CLUE what you are blathering about.
No amount of ongoing random whiney non-substantive email from you
is going to change what the rest of the world thinks.  You get
no points for volume of irrelevant email either.

Ran
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Aug 2002 13:47:26 -0400

Ran,

>         Please send a formal proof that it is broken.

that's essentially what they said about the Tacoma Narrows Bridge -
we don't believe your wind analysis because you can't formally prove it.

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Aug 2002 13:46:16 -0400

Ran, 

As I've said repeatedly I'm working on analysis of mDNS, but it's extremely 
time-consuming.

Furthermore, when members of this group clearly indicate that they're not 
capable of understanding analysis, that seems like a good indication that 
the analysis is a waste of time - at least for this audience.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 30 Aug 2002 12:57:14 -0500

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "RJ Atkinson" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; "Zeroconf" <[email-masked]>
Sent: Friday, August 30, 2002 12:34 PM
Subject: Re: Slightly OT: Apple 

> that this is a robust protocol.

Has the public been mislead about how robust IPv6 is ?

Has anyone seen how many changes have to be made to the BSD version of 6to4 to make it robust ?

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
Have you tried ?....2911: ?...or next year's version ?...2003: ?...or 3911: ?
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://www.ethereal.com
http://www.netfilter.org

---

From: james mcmurry <[email-masked]>
Date: Fri, 30 Aug 2002 10:58:56 -0700

Well,

Yes and No...

http://www.failuremag.com/arch_science_tacomanarrows.html

Jim

(disclaimer - I actually worked for 3 years at Failure Analysis 
Associates......)

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 30 Aug 2002 11:21:54 -0700

> we don't believe your wind analysis because you can't formally prove 

So Keith,

What is your wind analysis?

-josh

---

From: joe holt <[email-masked]>
Date: Fri, 30 Aug 2002 11:43:25 -0700

The Golden Gate Bridge also experienced unexpected and disturbing
undulations after it was first opened in 1937, requiring retrofitting. In
1951 a violent storm swayed the bridge 27 ft side to side. Because of the
retrofits the bridge survived with only minor damage.

People of vision do their best and put something out there. It's never
perfect the first time 'round. Great ideas get refined by experience and
time in the real world. This next year is going to be an exciting one for
ZeroConf.

/joe

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 15:34:41 -0400

> Internet Drafts are explicitly not to be referenced.

It's *MacCentral*...we aren't talking about Jim Leherer here.

john

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 15:33:45 -0400

> to standards-track quality.

It will also help get any bugs in the code fixed. It will also help it 
get looked at by a wide range of eyes and expertise. That is *a good 
thing*

> is in shipping production products.

Well, the world doesn't have time to wait for more arguing over the 
concept. We have work to do, and this will help it get done.

john

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 15:35:44 -0400

> in minimizing and/or delaying the harm done is well spent.

Well, when you get from "if" to "will" with solid proof, you let me 
know.

> respect to the same set of requirements, but it's a mistake that is

Well, so far, MIT's DNS hasn't come crashing down.

john

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 15:36:41 -0400

> you learn from each of them, but you can only use one to verify the

You still get better results from both, and unverified analysis is 
never as reliable.

> on a few specific network configurations.  that's not even a drop in 

If enough people test it, the bucket is filled.

john

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 15:39:30 -0400

> you tried it - at least not in a way that you noticed.

Actually, *so far* it does work fine. If it only breaks in unnoticeable 
ways, then it's not broken at any level that we care about.

unless it breaks something real, in a repeatable fashion, it's a 'what 
if'. you can always 'what if' something to the grave.

> that this is a robust protocol.

Prove it's not robust, since you've made the accusation. Show me 
something it's *actually* broke. Not theoretically broke, not may break 
some day. Show me something it's actually broken, and document it so it 
can get fixed.

john

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 15:42:55 -0400

> As I've said repeatedly I'm working on analysis of mDNS, but it's 

Good analysis always is, as is good testing.

> the analysis is a waste of time - at least for this audience.

Dude, you show me a balanced, objective, repeatable analysis that shows 
proof that Zeroconf will break stuff, and I will stand right next to 
you and demand it gets fixed.

The only thing this group appears to be not capable of is taking vague 
'chicken little' warnings with no proof seriously. Screaming "bad 
things may happen" is not analysis.

john

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 30 Aug 2002 15:45:09 -0400

> we don't believe your wind analysis because you can't formally prove 

That was one case, and they were dumb to ignore the analysis.

*However*, at least in that case, there was an analysis to ignore. You 
have yet to provide an analysis of any kind.

I can also point to quite a few things where analysis said it wouldn't 
work, yet it did, and well. Aeronautics is full of them. I for one am 
glad that the Wright brothers tested ideas as well as analyzed them.

remember...studied analysis said you couldn't fly faster than the speed 
of sound.

john