IETF Logo Mail Archive

Re: Getting Taipei remote participants' input

Dave CROCKER <dcrocker@bbiw.net> Fri, 25 November 2011 20:09 UTC

Return-Path: <dcrocker@bbiw.net>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E320421F8B78 for <wgchairs@ietfa.amsl.com>; Fri, 25 Nov 2011 12:09:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfXRn7ehchRJ for <wgchairs@ietfa.amsl.com>; Fri, 25 Nov 2011 12:09:00 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3027E21F8B54 for <wgchairs@ietf.org>; Fri, 25 Nov 2011 12:09:00 -0800 (PST)
Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAPK8nAK029414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Nov 2011 12:08:57 -0800
Message-ID: <4ECFF5CA.4000903@bbiw.net>
Date: Fri, 25 Nov 2011 12:08:42 -0800
From: Dave CROCKER <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Simon Pietro Romano <spromano@unina.it>
Subject: Re: Getting Taipei remote participants' input
References: <47A5416C-33BF-44FB-B01B-D1FE59808AAD@vpnc.org> <CAC4RtVCdULyZ=-gp_tThMhwGYcMt81J32DUG0+NLHjP+26vF2A@mail.gmail.com> <4ECD1254.9010901@bbiw.net> <2247A63F-FF4C-43C4-AE16-6884B44C4A29@brianrosen.net> <4ECD21A1.5020003@bbiw.net> <C8429466-0E82-4C30-B5F0-FBB13E641130@brianrosen.net> <4ECD2B41.5090702@bbiw.net> <4ECD468D.80402@unina.it>
In-Reply-To: <4ECD468D.80402@unina.it>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 25 Nov 2011 12:08:59 -0800 (PST)
Cc: IETF WG chairs <wgchairs@ietf.org>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/wgchairs>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Nov 2011 20:09:01 -0000

On 11/23/2011 11:16 AM, Simon Pietro Romano wrote:
> Hi Dave,
>
>> If you mean aggregating the set of folk at all the mics and taking them in the
>> strict order of their coming to the (single) queue, that doesn't work on
>> average, unless the queue is tiny. The chair can't keep track of who arrived
>> to the queue and when.
>
> I personally like Brian's idea, and think the all thing might work smoothly if
> you make use of a tool capable to automatically collect and moderate floor
> requests, to be put in a (virtual) single queue. What I'm thinking of is RFIDs
> triggering BFCP (Binary Floor Control Protocol) requests,


An interesting challenge, for Paul's current contract, is to find a way to 
navigate between what the community wants, versus what is practical.  The fact 
that we are a group of engineers means that we tend to try to solve the problem, 
before agreeing on what problem we want to solve...

Suggestions like the above sound appealing.  Unfortunately, they are far beyond 
current products and making them useful is considerably more difficult than the 
suggestions imply.  That doesn't mean they should be ignored, but we need to be 
careful about slipping into the assumption that merely citing a bit of 
technology means that an issue is resolved.

We had an experiment with RFIDs.  It was awkward, at best.  In addition, it was 
extremely limited.  Only the person standing right next to the microphone could 
be identified.  For example, this means that it would not have been useful for 
identifying when someone /enters/ the queue.  Too far away.

So if folks are going to attempt to define the technical solution, at least 
please try to indicate how it would work throughout the requirement.

In the case of queue management, we have at least entering the queue, position 
in the queue, and the chair's control of the queue.  No doubt, there's even more 
complexity than that.  For example, there's "noise" such as someone walking by 
the queue but not entering it...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

v2.23.0 | Report a Bug | By Email