Re: on "positive" organizational culture
Toerless Eckert <tte@cs.fau.de> Tue, 10 March 2020 17:52 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0D13A0408; Tue, 10 Mar 2020 10:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgZ8ctR12P58; Tue, 10 Mar 2020 10:52:08 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B893A0765; Tue, 10 Mar 2020 10:52:07 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4BBA3548047; Tue, 10 Mar 2020 18:52:02 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 45310440040; Tue, 10 Mar 2020 18:52:02 +0100 (CET)
Date: Tue, 10 Mar 2020 18:52:02 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Keith Moore <moore@network-heretics.com>
Cc: Jay Daley <jay@ietf.org>, ietf@ietf.org
Subject: Re: on "positive" organizational culture
Message-ID: <20200310175202.GC13518@faui48f.informatik.uni-erlangen.de>
References: <7a0c887d-d259-3a75-b6a5-c33a62ee8d5d@network-heretics.com> <0DAAE6A4-9F3F-4F2F-9DF5-723D15EE9AB3@ietf.org> <46ca09d6-7c6a-de73-67b6-7b272678e247@network-heretics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <46ca09d6-7c6a-de73-67b6-7b272678e247@network-heretics.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/3PlRqURlmSrmroGfWjKdVtG-R04>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2020 17:52:11 -0000
On Sun, Mar 08, 2020 at 10:04:12PM -0400, Keith Moore wrote: > For instance, if a proposal is > motivated by a desire to use the standards process to gain an unfair > technical advantage over competitors, it almost always will do some harm to > Internet users - and that harm may be easier to demonstrate than the motive. I think this argument works only in simple, "evil" cases. In reality today, i observe quite the opposite: I think one can understand the competitive grounding of a lot of technical positions and in many cases, proponent can be quite open about it (*). Where we do get problem is when the "harm to the internet user" argument is (IMHO) intelligently "abused". Especially when in one option the harm comes through a particular standard and then the opposing option takes that harm out of the standard but creates more harm outside of the scope that the IETF can influence and reduces the business of the opposing option that maybe ultimately would have greated more ability for the IETF to limit and control the harm. > But sometimes inappropriate motive does rear its ugly head. > IMO current IETF processes are not well-designed to deal with these cases, but I'm not > sure what remedy to recommend. In the cases i am thinking of, the best solution may be not to permit only one standard enforced by the side that manages to engineer the rough mayority, but also for the otherwise oppressed rough minority. Aka: loosen up on the ability of a rough mayority to inhibit options that do not serve their commercial interests. > I've also seen cases (both inside and outside of IETF) in which a demand for > positivity has been deliberately used to suppress input that those in > leadership positions didn't want to have aired. Something like you pick the one word in an opposing view that can be misconstrued to be marginally offensive or rude and then you shift the discussion to one of pure language, not answering to the technical concern ? That is at least what i have seen happening, and only in one case i remember did this result in some serious backslash, aka: we are IMHO definitely living in a time of PC language as a weapon). > Bottom line: I believe that for IETF to be able to do its job well, > transparency must be more important than a vague notion of positivity. Indeed. Here was my personal (*) example how one can be open about commercial positions: In Multicast we have this complex protocol IGMPv3 (2000). 10 years later a new company and propose a simplified version. Whereupon i stood up in WG and said that this may be technically interesting, but creates even more new work for companies that have implemented the complex version, and makes only market entrance for new companies easer, effectively shifting the cost away from the proponents to their competitors. I have seen very little open discussion about commercial positions though over the years, i think more would be helpfull. Cheers Toerless
- IETF 107 Standard Registration and Internet Draft… IETF Secretariat
- Re: IETF 107 Standard Registration and Internet D… Scott O. Bradner
- Re: [107all] IETF 107 Standard Registration and I… Randy Bush
- Re: [107all] IETF 107 Standard Registration and I… Robert Raszuk
- Re: [107all] IETF 107 Standard Registration and I… Randy Bush
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Robert Raszuk
- Re: IETF 107 Standard Registration and Internet D… Scott O. Bradner
- Re: IETF 107 Standard Registration and Internet D… Ole Jacobsen
- Re: IETF 107 Standard Registration and Internet D… Randy Bush
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Scott O. Bradner
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Carsten Bormann
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Lou Berger
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Lou Berger
- Re: IETF 107 Standard Registration and Internet D… Salz, Rich
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Wrt. cancelling IETF107 in-person registration (w… Toerless Eckert
- Re: IETF 107 Standard Registration and Internet D… Kathleen Moriarty
- Re: IETF 107 Standard Registration and Internet D… Alissa Cooper
- Re: IETF 107 Standard Registration and Internet D… Alissa Cooper
- Re: IETF 107 Standard Registration and Internet D… Randy Bush
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- Re: IETF 107 Standard Registration and Internet D… Jay Daley
- RE: IETF 107 Standard Registration and Internet D… Larry Masinter
- Re: risk zones (was: IETF 107 Standard Registrati… Alexandre Petrescu
- Re: IETF 107 Standard Registration and Internet D… Dirk Kutscher
- Re: risk zones Joseph Potvin
- Re: risk zones Alexandre Petrescu
- Re: Wrt. cancelling IETF107 in-person registratio… Jared Mauch
- Re: IETF 107 Standard Registration and Internet D… Lou Berger
- Re: IETF 107 Standard Registration and Internet D… Phillip Hallam-Baker
- Re: IETF 107 Standard Registration and Internet D… Marc Petit-Huguenin
- Re: IETF 107 Standard Registration and Internet D… Phillip Hallam-Baker
- Re: risk zones Phillip Hallam-Baker
- Re: IETF 107 Standard Registration and Internet D… Toerless Eckert
- Re: risk zones Alexandre Petrescu
- Re: risk zones Rich Kulawiec
- Re: IETF 107 Standard Registration and Internet D… Alexandre Petrescu
- Re: IETF 107 Standard Registration and Internet D… Phillip Hallam-Baker
- Re: risk zones Christian Huitema
- Re: risk zones Randy Bush
- Re: IETF 107 Standard Registration and Internet D… Jim Fenton
- on "positive" organizational culture Keith Moore
- Re: on "positive" organizational culture Jay Daley
- Re: on "positive" organizational culture S Moonesamy
- Re: IETF 107 Standard Registration and Internet D… Toerless Eckert
- Re: on "positive" organizational culture Keith Moore
- Re: on "positive" organizational culture Jay Daley
- Re: on "positive" organizational culture Toerless Eckert
- Re: on "positive" organizational culture Keith Moore