Re: [sidr] Interim Meeting Dates/Locations (Proposed)

Samuel Weiler <> Tue, 27 March 2012 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0960D21F8680; Tue, 27 Mar 2012 14:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WDnrK3Sguv8R; Tue, 27 Mar 2012 14:52:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4682621F867E; Tue, 27 Mar 2012 14:52:46 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id q2RLqgjM085172; Tue, 27 Mar 2012 17:52:42 -0400 (EDT) (envelope-from
Received: from localhost (weiler@localhost) by (8.14.4/8.14.4/Submit) with ESMTP id q2RLqg7S085169; Tue, 27 Mar 2012 17:52:42 -0400 (EDT) (envelope-from
X-Authentication-Warning: weiler owned process doing -bs
Date: Tue, 27 Mar 2012 17:52:42 -0400 (EDT)
From: Samuel Weiler <>
To: "Murphy, Sandra" <>
In-Reply-To: <>
Message-ID: <>
References: <>, <> <>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 ( []); Tue, 27 Mar 2012 17:52:42 -0400 (EDT)
Cc: Christopher Morrow <>, "" <>, "" <>
Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Mar 2012 21:52:47 -0000

On Tue, 27 Mar 2012, Murphy, Sandra wrote:

> Moderate badness in the Monday meeting was due to my laptop 
> communication problems.  Suggestions welcome as how to handle such a 
> situation better.

Thank you for asking.

1) First and foremost, delegate the tech issues to two or more persons 
who do not have responsibilities to chair, present, scribe, or jabber 
scribe.  Ideally, find people who are unlikely to be active 
participants in the meeting.  It's fine to bring in outside help.

2) Have spares for all key hardware.  This includes laptops, audio 
gear, network gear, network connections, and phone connections. 
Cables and power supplies need spares, also -- a dead power supply can 
mean a dead laptop.  Based on experience in San Diego I suggest having 
at least three pieces of all key gear.  Have fallbacks in case a 
service provider fails: if you're planning to use Meetecho, ALSO have 
a WebEx session and a PSTN bridge set up and ready to go.

3) Test both primary and spare hardware and service providers in 
multiple combinations prior to the meeting.  The more testing you do, 
the more you can get away with only a single spare.  Testing needs to 
happen in the real meeting environment using the same phone lines, net 
connections, and audio hardware that will be available during the 
meeting.  The more removed your testing environment is from the real 
meeting environment, the more you need that second spare.

4) When a relatively large number of participants will be in a single 
space, provide high-quality microphones.  The average Polycom 
microphone still sounds like a speakerphone, and listening to people 
talking through one all day gives remote participants a clearly 
second-class experience.  If possible, give every participant his own 
microphone (with mute switch!).  At the very least, provide a floor or 
wireless handheld microphone as we have at the regular IETF meetings 
and make sure people use it.

Yes, this is a lot to do.  Yes, I'm saying to have three net 
connections[1].  Remember, you're not doing this yourself (at least, 
not if you're following suggestion #1).  In fact, no one person is 
stuck with all of this.  And "spares" don't have to be 
sitting-in-a-box-and-hauled-around-the-world-the-to-be-a-spare: they 
can be a meeting participant's personal power brick, so long as you're 
sure there's going to be that spare in the room and the person is 
willing to part with it should the need arise.

-- Sam

[1] This is based on the San Diego experience where the hotel net 
connection was terrible and the backup net was a 4G hotspot.  While 
both could move some packets, they were not enough to handle both 
remote participation and the normal packet-pushing desires of those in 
the room.  A 3G or 4G device could easily be the backup net, so long 
as 1) there is actually service in the meeting space and 2) the device 
gives priority to the remote participation traffic and avoids getting 
bogged down by routine email checking and web browsing.