Re: [72attendees] Clarifying Host Responsibilities (was Re: Guestroom Network not under NOC Control)

Dave Crocker <> Wed, 30 July 2008 16:13 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id CD6783A6C30; Wed, 30 Jul 2008 09:13:27 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B980A3A6BF6 for <>; Wed, 30 Jul 2008 07:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XXPDch+aPF7E for <>; Wed, 30 Jul 2008 07:49:27 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:76:0:ffff:4834:7146]) by (Postfix) with ESMTP id 2795228C311 for <>; Wed, 30 Jul 2008 07:49:24 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id m6UEmt9c019578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 07:48:57 -0700
Message-ID: <>
Date: Wed, 30 Jul 2008 15:48:55 +0100
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Ole Jacobsen <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Virus-Scanned: ClamAV 0.92/7891/Wed Jul 30 03:03:53 2008 on
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 30 Jul 2008 07:48:57 -0700 (PDT)
X-Mailman-Approved-At: Wed, 30 Jul 2008 09:13:23 -0700
Subject: Re: [72attendees] Clarifying Host Responsibilities (was Re: Guestroom Network not under NOC Control)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the attendees of IETF 72 meeting." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"


   This script that you and I are following has become a cliche.  To break out
of it and conduct serious discussion, we need to think harder about underlying
assumptions, as well as treating asserted data with some skepticism.

Ole Jacobsen wrote:
> De-coupling the two issues is a fine idea on paper and in my 
> experience almost unworkable in practice. Hosts DO want some
> say in where we meet and they DO want to be near a place where
> they can provide "local" support (if only from a remote office).

1. You are quite wrong.  Most conferences, association meetings, and the like,
choose a venue independent of sponsorship.  Hence sponsorship is about
sponsoring, not about doing the grunt work.  Long ago, we developed a meeting
model based on some coupling of roles and services, which are so entrenched any
attempt to suggest changing it gets responses that are firm, reflexive and not
supported by the facts.  Responding rigidly and defensively is not a good way to
pursue necessary changes.  It is a good way to ensure that persistent problems

2. The IETF insists on a model that performs what it claims is an optimization
when a) it's highly local while ignoring larger inefficiencies, and b) probably
isn't all that optimal locally.

When looking at persistent problems, improvement is never achieved by starting
to defend core assumptions that are, in fact, the primary reasons for the problem.

By insisting that the IETF start with choosing a host, most of our meeting venue
problems ensue.  It ensures all of the instabilities we repeatedly experience.
It ensures hidden costs -- thereby making claims of reduced cost, by virtue of
having hosts perform tasks off the IETF's books -- that offset supposed savings.
  Note, for example, the substantially higher cost of taxis because the Dublin
facility is so remote.  While taxi cost might seem a silly, small point, it
becomes a large one when applied to the entire population of attendees, as well
as applied repeatedly if attendees want to get elsewhere.  (Yes, the added bus
service helps, but not enough.)

When this core error is highlighted, we always get series of tautological
arguments attempting to assert that the error is required.  It isn't.  There is
more than sufficient experience in the rest of the world to show that the error
need not be made.

> I would be wonderful if we had a pool of money from lots of
> vendors that simply took care of all costs and logistics and
> we then just get to pick the venue. Oh, wait, there is such
> a pool, it's called "Organizational Membership in ISOC".

Again, the IETF walked down a path that created a strategic problem and would
rather continue an operational mode that ensure significant IETF meeting
problems periodically, rather than fix the underlying problem.

In this case, I think that trade association funding details could be relevant:
  They have both "membership" and "sponsorship" and it works fine.



   Dave Crocker
   Brandenburg InternetWorking

72attendees mailing list