Subject: Re: non-DNS name services

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

> >>         this is no different from having entry different from DNS in
> >>         /etc/hosts.
> >>         i don't see the point.
> >the existence of one source of error does not justify introducing another.
> 
>         then why DNS is the only one true mechanism for host-to-address lookup?

actually I wouldn't claim that at all - quite the opposite. I think we need 
lots of mechanisms for host-to-address lookup, service-to-address lookup,
resource-to-address lookup.

but DNS *is* the one true mechanism for lookup of DNS names :)  
because it is what defines the meanings of those names.

> >> >- 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)
> >> 
> >>         timeout behavior is different between NIS and DNS, that's all.
> >>         i can't say that DNS timeout behavior is *the* right behavior,
> >>         nor NIS.
> >
> >it wasn't just a difference in the delay before timing out, it was
> >a difference in the way errors were reported.  and under some conditions
> >(ypbind failure) YP lookups would not time out at all.
> 
>         i don't think we are talking.  you have been arguing that DNS is the
>         only one true mechanism for host-to-address lookup.  you need to prove
>         that DNS timeout vaulue as well as the behavior is *the* right one.

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.

Keith

---

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

> those semantics are right or wrong is immaterial if changing them will 

<sigh>...which is why we need to TEST this, and get real data that can 
be verified, and duplicated. Otherwise, all of this is just arguing 
about angels doing the gavotte on sewing hardware.

john

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Aug 2002 18:36:16 -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.
> 

My airplane has a design max speed of 171 miles per hour.  This figure is 
based on analysis of the airframe structure and measured strength of the 
materials used in its construction.  However, it will probably go faster 
than that before it falls completely apart - both because there is some
design margin to account for slight variation in materials and wear over 
time, and because the analysis techniques used when the airframe was 
designed could not exactly predict fatigue under all flight conditions.

Why don't you get an airplane like mine (I want to keep the one I own), 
take it up to its ceiling (about 12,500 feet), push the throttle forward 
and nose down, and TEST it to see when it fails?

Testing on live users and networks is no substitute for analysis.

Keith

---

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

> and nose down, and TEST it to see when it fails?

The military does this all the time...they're called test pilots for a 
reason. You'll note they find all kinds of things the design didn't 
point out. This is how we discover all kinds of interesting things 
about the limits of an airframe..sometimes unintentionally...like the 
B-52 that survived a barrel roll...or that a KC-135R model can climb at 
a 70 Degree angle with no real problems.

The real world hits you with variables you can't predict, which is 
where a paper-only test fails miserably. Paper testing helps you deal 
quickly with the predictable issues, so you can focus real world 
testing on the odd things humans do.

> Testing on live users and networks is no substitute for analysis.

It's not *supposed* to be a *substitute. They work *together*. Either 
alone is *useless* because you miss too much overly relying on a single 
method. Both together shore up each other's weaknesses and provide a 
picture of what you are testing that *neither* can ever provide on 
their own.

which is why the intelligent tester uses both methods.

john

---

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

> B-52 that survived a barrel roll...

my understanding is that properly done, a barrel roll is a 1G maneuver.  
so I see no reason any sufficiently powered aircraft couldn't survive it 
as long as its engines, fuel system, etc could handle the brief inverted 
operation.  it won't stress the airframe.

but I certainly agree that testing and analysis are both useful, and
that both are often necessary.  my beef is with the idea that testing 
alone is sufficient when the potentail for disruption (and the associated 
cost) are high.

Keith

---

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

> operation.  it won't stress the airframe.

Actually, in the B-52's case, the spine of the aircraft looked like a 
human spine...the pilot almost lost control of his bladder when he saw 
it. Went from 20-30,000 feet to 1,000 feet...B-52's aren't designed for 
that at all...

> alone is sufficient when the potentail for disruption (and the 

I've never advocated denying analysis for testing. Nor have I advocated 
breaking things for testing. Plan the test and test the plan.

john