>Return-Path: <[EMAIL PROTECTED]>
>Delivered-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>From: [EMAIL PROTECTED]
>Subject: BOUNCE [EMAIL PROTECTED]: Non-member submission from [Dave Crocker
><[EMAIL PROTECTED]>]
>Date: Sat, 17 Jul 1999 22:52:05 -0400 (EDT)
>
>>From [EMAIL PROTECTED] Sat Jul 17 22:52:03 1999
>Return-Path: <[EMAIL PROTECTED]>
>Delivered-To: [EMAIL PROTECTED]
>Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13])
> by ns1.vrx.net (Postfix) with ESMTP id 046DBF059
> for <[EMAIL PROTECTED]>; Sat, 17 Jul 1999 22:52:00 -0400 (EDT)
>Received: from shell2.bayarea.net (shell2.bayarea.net [205.219.84.7])
> by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id TAA02908;
> Sat, 17 Jul 1999 19:45:49 -0700 (PDT)
>Received: from dave-vaio (free.88.106.bayarea.net [205.219.88.106])
> by shell2.bayarea.net (8.8.8/8.8.5) with ESMTP id TAA12291;
> Sat, 17 Jul 1999 19:46:18 -0700 (PDT)
>Message-Id: <[EMAIL PROTECTED]>
>X-Sender: [EMAIL PROTECTED]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
>Date: Sat, 17 Jul 1999 19:32:34 -0700
>To: Andy Gardner <[EMAIL PROTECTED]>
>From: Dave Crocker <[EMAIL PROTECTED]>
>Subject: Re: [IDNO-DISCUSS] Re: [IFWP] Why fail on purpose
>Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED]
>In-Reply-To: <v03102805b3b6cb8c771c@[202.27.208.23]>
>References: <[EMAIL PROTECTED]>
> <v03102802b3b6759a12eb@[202.27.208.23]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>Andy,
>
>Thank you for the serious and responsive note.
>
>At 05:24 PM 7/17/99 , Andy Gardner wrote:
>> >Refusal to accept IDNO is hardly proof of being closed.
>>Just one of a huge list of proofs, actually.
>
>A short discourse on the relationship between the two, which demonstrates
>it to be one of those proofs, would be helpful.
>
>Or at least entertaining.
>
>> >As Kent noted, there are some operational aspects to IDNO which should
>> >cause any reasonable evaluator to question its legitimacy as a
>> >representative body for the constituency it claims.
>>
>>Which operational aspects are these? As you have just stated that you know
>>what they are (I assume you _do_ know what they are?), please list them
>
>I always manage to leave something off of lists like these, but here are
>the ones that come to mind, some momnths later.
>
>By the list owner:
>
>1. Enforcement of participation rules, post hoc and without documentation
>or group approval
>
>2. Assertion of organizational goals which were without documentation and
>without group approval
>
>3. By fiat calling for a couple of ostracism votes against participants
>with whom he disagreed, again without any documentation of procedures about
>ostracism or acceptable/unacceptable participation behavior (and the
>results of those votes were never announced.)
>
>4. By fiat removing a participant who never expressed any desire to be
>removed.
>
>As I say, the list is probably longer, but this will no doubt provide
>enough fuel.
>
>At the least it gives a good indication of a consistent failure to
>comprehend rather basic concepts of due process.
>
>> >>You haven't done your homework. Memebers are assigned a password by the
>> >>system, not the other way around. You can set up as many e-mail address as
>> >>you want, but you'd only have one that was issued a password.
>> >
>> >Your statement means that "email address" is not the "identifier" for
>> >distinguishing between people. What is? What prevents one person from
>> >having/using multiple such ID's?
>>
>>Why are you asking me? Just before you told us "there are some operational
>>aspects to IDNO which should cause any reasonable evaluator to question its
>>legitimacy" (FUD alert!). If you know what these "operational aspects" are,
>>why are you wanting details on them? I say again, please list them.
>
>Sorry. I assumed you were able to distinguish between a comment about list
>operational policies, versus voting security technology deficiencies.
>
>I made an assertion about the former. Your comment was about the latter
>and I was asking you to consider and pursue one aspect to that system's
>weakness.
>
>> >The reality is almost certain to prove to be that a serious security audit
>> >to the desig the design to be massively laced with holes and poor
>> assumptions.
>>
>>FUD, FUD, FUD. You're full of it, Dave.
>
>I'm glad to hear that you have sufficient experience in the arcane field of
>networking security to make such an assertion.
>
>The shame is that you seem unwilling to pursue the content of the issue,
>instead preferring ad hominems.
>
>>"Almost certain to prove". Heh heh. Lovely. Have you got an automatic
>>program that comes up with these gems, or did you buy the book?
>>
>> >1. Getting this sort of system design right is really a remarkably
>> >difficult technical task, particularly for large scale use. Even if you
>> >can fully prove the legitimacy of your 21-person system,
>>
>>21? Where this figure come from?
>
>Number of voters in the IDNO system, according to one of the notes in this
>thread.
>
>> >it will be quite
>> >another task to prove it for 21,000-person use,
>>
>>The system scales quite easily. ICANN could have put on together using its
>>preliminary cash injection and had a sizeable sum left over.
>
>Such comfort with scaling a system by 3 orders of magnitude is
>impressive. The pity is that most professionals would be rather less
>automatically certain.
>
>Perhaps you could educate the rest of us about the professional experience
>you have which permits such assurances?
>
>> >>Stick to your day job.
>> >
>> >It happens that Kent's day job IS network security and he's quite good at
>> >it.
>>
>>The reality is almost certain to prove to be that there are some
>>operational aspects to the above statement which should cause any
>>reasonable evaluator to question the legitimacy of such.
>>
>>Gee, hang on, I might write that one down for future use. It almost sounds
>>like I know what I'm talking about. I'm certainly feeling all puffed up
>>with self-importance and hoping like hell that I've cast doubt in the minds
>
>Indeed, your puffery is well-displayed. Unfortunately it has produced
>cleverness without content.
>
>>of people that haven't got the time to do the research and find out that
>>I'm full of it.
>
>Or, perhaps, you have done a sufficiently splendid job to make that
>additional research necessary.
>
>> >I have to work with experts in security and most of them are only good
>> >at highly focused issues, rather than at looking at system-wide
>> >concerns. Kent happens to be good at systems issues. Care to reconsider
>> >you overly-quick dismissal of the issues he raised?
>>
>>Care to do you homework correctly? Care to stop making out you know
>>"operational aspects to IDNO which should cause any reasonable evaluator to
>>question its legitimacy" then later in the same email asking _us_ what they
>>are?
>
>You seem to have missed the small fact that I was a direct participant at
>the times of these problems, so that there is no need to ask others about
>the behaviors. I witnessed them directly.
>
>d/
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Dave Crocker Tel: +1 408 246 8253
>Brandenburg Consulting Fax: +1 408 273 6464
>675 Spruce Drive <http://www.brandenburg.com>
>Sunnyvale, CA 94086 USA <mailto:[EMAIL PROTECTED]>
>
>
--
Richard Sexton | [EMAIL PROTECTED] | http://dns.vrx.net/tech/rootzone
http://killifish.vrx.net http://www.mbz.org http://lists.aquaria.net
Bannockburn, Ontario, Canada, 70 & 72 280SE, 83 300SD +1 (613) 473-1719
