Return-Path: <russw@riw.us>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
 (Postfix) with ESMTP id CCFE41A0810 for <internetgovtech@ietfa.amsl.com>;
 Tue, 25 Feb 2014 09:05:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level: 
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8,
 RP_MATCHES_RCVD=-0.547] autolearn=ham
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 4StAeOHZBNAe for
 <internetgovtech@ietfa.amsl.com>; Tue, 25 Feb 2014 09:05:49 -0800 (PST)
Received: from server.riw.us (server.riw.us [162.144.32.236]) by
 ietfa.amsl.com (Postfix) with ESMTP id 60AB31A072F for
 <internetgovtech@iab.org>; Tue, 25 Feb 2014 09:05:46 -0800 (PST)
Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:62470
 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim
 4.82) (envelope-from <russw@riw.us>) id 1WILRu-0003qU-1x;
 Tue, 25 Feb 2014 17:05:42 +0000
From: "Russ White" <russw@riw.us>
To: "'Andrea Glorioso'" <andrea@digitalpolicy.it>,
 "'Arturo Servin'" <arturo.servin@gmail.com>
References: <8E82AC16-6428-412E-A862-6F53AFE632C7@isoc.org>
 <074FE4AC-76B0-45C2-B849-3BFE5D4782DD@vigilsec.com>
 <73481820-F228-434C-814A-070F6A2C1F93@gmail.com>
 <83E315B6-2059-490A-A892-19CF6D74EA62@vigilsec.com>
 <6DCAB3E586E6A34FB17223DF8D8F0D3D0101E71E6F@W8-EXMB-DP.unam.local>
 <CALo9H1a+Tebzmbx=FauNeW5y6Axzhqt5ngE2GYwDBxOz-mBbSQ@mail.gmail.com>
 <CAOLD2+aimJo05q7KVXYFcSRJdBDxJkqa2q3sH8vFLBsKVnUt5w@mail.gmail.com>
 <CALo9H1Y-XxR-zEOKh-6n3m6utK+h2U6u5Q_8+nvb_sEer9pZrQ@mail.gmail.com>
 <CALo9H1amXVE2KX5Yh1+HGQvj7cmJPh5ibm0uQZxxHC2Cvm7GOw@mail.gmail.com>
 <CAOLD2+ZP9K+rnrw3cNA7dft3JjVRE0a83rXO97TV+kDyWLN+JQ@mail.gmail.com>
In-Reply-To: <CAOLD2+ZP9K+rnrw3cNA7dft3JjVRE0a83rXO97TV+kDyWLN+JQ@mail.gmail.com>
Date: Tue, 25 Feb 2014 12:05:41 -0500
Message-ID: <01c601cf324b$d0fd9750$72f8c5f0$@riw.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJMFih2b/pqIL5HvUFCBvP9zfnmIAHwS+XUAcF8GWsC7qp9sgH+vKWhAszX6ToCRYMQCgN5j4kmAhEOGroCAPUEa5kifMag
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.riw.us
X-AntiAbuse: Original Domain - iab.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/q6maxPOCSTLDEqmIQ6RJXKcs2ug
Cc: internetgovtech@iab.org
Subject: Re: [Internetgovtech] US Government response to the European
 Commission statement
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>,
 <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>,
 <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 17:05:55 -0000

(Speaking only for myself, and not for any organization of which I might
happen to be a member, work for, etc., etc.)

> Why not? Too much structure certainly can stifle discussion. But too
little
> structure can easily lead to energy waste, duplication, lack of
information,
> etc.

Structure doesn't necessarily solve these problems, in my experience.
Structure can be used to reduce wasted energy, but it can also be used to
force nonoptimal solutions by saying, "we've already discussed this; the
debate is over," even when no real debate has taken place. It can also be
used to freeze suboptimal solutions in place far beyond their marginal
usefulness. What we often tend to forget is that the structure itself
accrues value (look at the value placed on holding a leadership position in
the IETF, for instance -- something that wouldn't have been really thinkable
just ten years ago), and hence attempts to be self-perpetuating whether or
not it is still useful.

> Structure is just one of the ways in which human beings handle complexity.

Yes. But sometimes structure adds complexity that isn't necessary, as well.

> (1) the world of Internet technologies is becoming more complex,
> because the Internet has become such a planetary success that it underlies
> almost all kinds of human transactions for billions people on this planet,
and
> 
> (2) that this introduces the need to take into account other constraints
than
> simply
> "does this packet get from point A to point B as efficiently as possible",

> then I fail to see how we can disagree that it would be a good thing to
> introduce more structured  ways (or, if you prefer, more "efficient",
> "effective", etc) to ensure that cross-constituency dialogue in this
"more
> complex" world truly scales.

The problem here is this line of thinking assumes "more structure == more
efficient." It simply isn't true in all cases. The right structure is more
efficient than the wrong structure and no structure. The wrong structure is
often worse than no structure at all. The key point is not, "should we put
structure around this or not," the key point is, "how much, and where do we
need to apply structure." The underlying themes should be to err on the side
of less structure rather than more, and allow structure to grow rather than
being imposed. We'll more often misread and put the wrong structure in place
rather than making the right choice the first time, or in the "early days." 

This argument can even be made in the case of government sponsored research,
which can warp a market in the name of creating one. We're often reminded of
the wonderful things government sponsored research has provided (TANG,
anyone?); we're not often reminded of the many and varied mistakes
governments have made in choosing one technology over another, etc. (TANG,
anyone?). I know this will make some folks mad (and I apologize in advance
for anyone who's offended) -- but, IMHO, BGPSEC is a case in point (not the
RPKI, but BGPSEC proper). Government money has warped the discussion to the
point that useful discussion can no longer take place. The technology was
chosen before the requirements were actually investigated, and no proper
evaluation of actual tradeoffs was taken into consideration. Rather, one
problem was pinpointed that one government sponsored solution could "solve,"
and all effort, since then, has gone into "solving" that one problem,
regardless of what else must be considered "out of bounds," etc., to get
there. IMHO, this end result isn't a good piece of technology, and it
doesn't solve the problems that need to be solved.  

Hence there is both potential danger, as well as potential "progress," down
this path. We should be aware of both, and try not to override the natural
progression of things on a technology front.

Just my 2c. 

:-)

Russ


