RE: [dnsop] [dean@av8.com: Mismanagement of the DNSOP list]

"Thomas Gal" <tom@triagewireless.com> Thu, 29 September 2005 00:07 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKlx9-0007W6-94; Wed, 28 Sep 2005 20:07:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKlx6-0007Vy-QP for ietf@megatron.ietf.org; Wed, 28 Sep 2005 20:07:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22294 for <ietf@ietf.org>; Wed, 28 Sep 2005 20:07:07 -0400 (EDT)
Message-Id: <200509290007.UAA22294@ietf.org>
Received: from epsilon.postal.redwire.net ([64.186.240.40]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EKm4d-00089M-Ul for ietf@ietf.org; Wed, 28 Sep 2005 20:14:57 -0400
Received: (qmail 1300 invoked from network); 28 Sep 2005 17:06:36 -0700
Received: from c-064-186-224-138.sd2.redwire.net (HELO horatio) (tom.gal@64.186.224.138) by smtp.redwire.net with SMTP; 28 Sep 2005 17:06:36 -0700
From: Thomas Gal <tom@triagewireless.com>
To: 'Stephen Sprunk' <stephen@sprunk.org>, ietf@ietf.org
Date: Wed, 28 Sep 2005 17:06:37 -0700
Organization: Triage Wireless
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcXDyXbdeTEejCWYQoulVZWPPHg4YwAudtmQ
In-Reply-To: <009901c5c3c9$3624ee80$efc511ac@ssprunk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Cc:
Subject: RE: [dnsop] [dean@av8.com: Mismanagement of the DNSOP list]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: tom@triagewireless.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0792408818=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Behalf Of Stephen Sprunk
> 
> Note that I consider it irrelevant 
> whether his position in this or any past instance turns out to be
> correct: it's the form, not the content, of his efforts that 
> is the problem.
> 
> S
> 

	That is a perilous line of reasoning indeed. You're saying if I
don't like the way you put something then I should be able to get you
booted. 

	In fact we're talking about DOS here. IF the subject matter is
relevant to the working group, or in the case of the IETF list, generally
converning the IETF's activities, procedures, and standards etc. than the
discourse is serving it's purpose. Getting things done is not *typically*
easy and pain free. In fact, if it is, then likely something was supressed,
or the issues wasn't really in need of discussion. 

	Is this issue preventing a working group from reaching consensus? Is
the issue here that maybe this concern was addressed, not accepted to be
calamitous enough by the working group to change course, and yet the same
issue was raised again (that's what it seems like to me)? That may justify
possibly suspending posting rights to the dnsop list (though I'm not making
that claim) but how does that just extend to the IETF list in any way?
Backing down because of fear of retribution from AD/Chairs/IESG etc.
certainly is not condusive to progress so I don't consider much of this
discussion off topic. As for what I've seen from the DNSOP list, as well as
past history with Dean is that he is certainly forceful and opinionated in
the way many of the vocal, active, and frankly productive members of the
IETF are. I think we've gotten Dean's summary explanation of the situation
from the message forwarded to the IETF list along with his other comments. 

	What I've not seen is any sort of detail/outline with references to
a series of emails which demonstrate a pattern of abuse, a warning, and
continued abuse that one could verify but examining archives of email
transmissions. It seems that rather quickly upon commencement of this topic
people diverged into arguing the technical issues associated with his
challenge, and personal matters relating to Dean.

	So in summary I pointedly disagree, and believe that the content of
the messages ( and frankly the lack of pointed content in the challenge )
should be the primary factor in this matter, and I hope that being too
forceful, stubborn, or persistent (NOT oblivious or ambivalent) doesn't
become justification for reprimand.

-Tom
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf