Re: Concerns about Singapore

"HANSEN, TONY L" <> Tue, 12 April 2016 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AE2012E1D4 for <>; Tue, 12 Apr 2016 11:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H186ZKW4EN5j for <>; Tue, 12 Apr 2016 11:33:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57FCE12E4B4 for <>; Tue, 12 Apr 2016 11:33:14 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u3CIT75k048172; Tue, 12 Apr 2016 14:32:57 -0400
Received: from ( []) by with ESMTP id 2294t0usp2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Apr 2016 14:32:57 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id u3CIWtrH017114; Tue, 12 Apr 2016 14:32:56 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u3CIWoGw016999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Apr 2016 14:32:53 -0400
Received: from ( []) by (RSA Interceptor); Tue, 12 Apr 2016 18:32:39 GMT
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 12 Apr 2016 14:32:39 -0400
From: "HANSEN, TONY L" <>
To: Rich Kulawiec <>, ietf <>
Subject: Re: Concerns about Singapore
Thread-Topic: Concerns about Singapore
Date: Tue, 12 Apr 2016 18:32:37 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <B1E54FC82D93D5418890AAB578F5F8D2@LOCAL>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-12_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604120265
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Apr 2016 18:33:23 -0000

I encourage people who have suggestions on how to do remote meetings to join the conversation in

	Tony Hansen

On 4/12/16, 7:02 AM, "ietf on behalf of Rich Kulawiec" < on behalf of> wrote:

>On Mon, Apr 11, 2016 at 07:54:25PM -0400, Ted Lemon wrote:
>> If we were to attempt such a thing, how do you think it would work?
>Let me preface this by saying that I think attempts to completely
>mimic the current in-person meeting experience as it exists probably
>won't work.  They might: but they probably won't.  But then again,
>I don't think that's entirely necessary: processes and procedures
>change (compare boarding a steamship in 1930 with an aircraft in 2005)
>and evolve in order to work with technology.
>So if I were to envision this, things I'd want to experiment with
>would include:
>- passive view-only, listen-only read-only access to anyone, anonymously.
>(That is: no registration required.)
>- levels of read-write access, perhaps (roughly speaking) distinguished
>as text, audio, and video.  Participants could select based on their
>available bandwidth and on the level they're comfortable with.  I think
>it's reasonable to require registration for write access.
>- a channel for presentation content only. Again, this is an option for
>those with limited bandwidth or limited time.
>- ability to delay/time-shift.
>- perhaps restructuring long sessions into smaller time slots.  If people
>have all travelled to the same place, then it makes sense to get a lot
>done in a short time, and so a four hour session (for example) makes
>sense.  But if people are in disparate locations, then maybe four one-hour
>sessions make more sense.  This also better accomodate people who have
>trouble carving out four hours in the middle of their day.  Or night.
>- integrated storage of sessions, so that someone can watch, listen,
>read, and absorb the entire experience.  Useful for someone half a
>planet away who won't be (or can't be) awake for real-time participation.
>- translations and/or text captioning and/or some kind of assistance
>for non-native speakers and the hearing impaired.
>- emphasis on the inclusion of participants who can't make it to meetings
>today, either because of time, money, politics, distance, family, job, etc.
>Over and above all of this: a willingness to experiment and to have
>some of those expirements fail -- which they will.