Subject: RE: Status of MARID WG?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 23 Nov 2004 08:22:52 -0800

> [mailto:[email-masked]] On Behalf Of Dean Anderson

> Sure, the consensus among network engineers and scientists. 
> Sure they aren't typical of internet users.  Phone engineers 
> are atypical of phone users.  Auto engineers are atypical of 
> auto drivers, too. But who do you want making decisions at 
> the Department of Transportation or running the engineering 
> department at a car company?  

I think it is ok for us to take decisions for others, but we have to be
willing to understand that their needs and concerns are not the same as
ours.

There is a difference between a prototype and a product. Unfortunately we
have a habbit of inflicting PERL lash up style schemes that are really no
more than prototypes onto end users.

I spend too much of my time dealling with the technology problems of friends
and familly. RTFM is not an acceptable answer here, there should never have
been the need for a manual. The only manuals I ever read are the ones that
come with safety warnings, things like tables saws, joiners, planers etc.

> I'm not so concerned about the selection of decision makers 
> and leaders from the technical community, so much as I'm 
> concerned about whether the decision makers selected actually 
> represent the technical community, rather than a certain 
> small group in the community. 

I am starting to get to a clearer explanation of the perception gap I see in
standards making. 

When writing a standard people imagine that they are writing the rules. The
problem is that the people who read the standards are looking to find WHAT
WORKS, not what is right.

I do not do normative ethics, you cannot arrive at an ought from an is.
Regardless of what people imagine SHOULD be the situation the fact is that
the way standards documents are used is very different from the way people
writing them imagine.

If we want to get the implementers to produce stuff that complies with the
specs we have to make it so that what works and what is right are the same
thing. Test suites help close that gap. Designing specs for compatability
with actual legacy deployments is another part.

> The process is somewhat opaque alright.  And it resembles 
> more of a private club than an public service organ or NGO or 
> standards body.  But nominations imply elections however 
> informal or exclusive the consensus is. 

Open and inclusive implies open and inclusive elections.
 
> There is a fundamental concept of democracy and consensus to 
> the IETF. Its just insufficient and flawed.  Most standards 
> organizations have a membership concept, and /all/ members 
> get to vote on certain things.

If someone wants to trump my opinion in my field of expertise on an issue I
believe is critical to the security of the Internet on the basis of an
unelected appointment through the old boy club then they are going to have a
big fight on their hands.

I find it utterly ludicrous that we are on the brink of taking a spec to an
alternative working group due to a technical dispute where the pragmatic
approach is so clear.

If people don't want a fight then the answer is clear, give me an
alternative way to deploy MASS that does not create a dependency on the
deployment of new DNS infrastructure. The dependency is real and it is
neither necessary nor even advantageous.

> Right. "Combining relative weights" sounds very much like Bayes rule.

But Bayesian inference makes some assumptions that are not valid for a real
corpus, the probabilities are not disjoint and Bayes developed his theory of
probability for that area. It's a bit like saying Einstein's cosmology is
Euclidean because on almost any terrestrial measurable scale it approximates
to the same thing, but the whole point is that Einsten's cosmology is
non-Euclidean.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 23 Nov 2004 12:26:25 -0500

> more than prototypes onto end users.

What's the saying... "Build a foolproof system and only fools will use 
it."

Not that the assertion you are making is incorrect, but I do not think 
it can be a generalization.  The computer sciences have been taking a 
beating lately because the technology being produced cannot be quickly 
grasped by simpletons.

Well, guess what?  Despite all the research and will of the auto 
industry, training and a drivers license are still required.  And 
certainly while many jurisdictions see no need for making sure 
gun-owners know more than point-and-shoot, I think most reasonable 
people wish they did.

So I think the "my mother must understand it" requirement is not always 
applicable.  After all, isn't the driver for mta-to-mta authorization 
caused because our collective mothers simply will not take on this 
responsibility with their click-driven MUAs?

-andy

---

From: Dean Anderson <[email-masked]>
Date: Fri, 26 Nov 2004 04:41:39 -0500 (EST)

> neither necessary nor even advantageous.

"If someone wants to trump [your] opinion ..."? 
"If people don't want a fight, [...] give me ..."? 

These are another set of dictatorial statements.  It is odd that you talk
about democratic process and make threats about trumping your opinion at
the same time.  It seems you like the democratic process until it doesn't
go your way. Then its threats.

Well, I think it is ludicrous that we (that is, the ietf) are still
talking about a non-working, demonstrably harmful specification such as
SPF and Sender-ID in /any/ working group.  But I guess that is part and
parcel of a democratic process:  The spam-profiteers and others will
continue to promote it, in any way they can. The rest of us have to
continue exposing the problems.  So far, 2 working groups have rejected
SPF/Sender-ID. Why not a third try?  It couldn't be that the IETF has
better things to do.

> probability for that area. 

First, Bayes rule makes no ssumptions that aren't valid for a real corpus.
That assertion seems to be nonsense.  Second, there is a partition of
events on the spam sample space. Indeed, there are many, as in any
probability application.  And like any probability application or textbook
problem, choosing the partition is the hard part. Then integrating that
into a working mail system in ways that are easy for users is even harder.  
But, by comparison, when Radio was first invented, you basically had to be
able to build your own radio receiver to listen--that was pretty hard.  
Now you just go to Circuit City and buy one.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000