Re: Remote participation fees

Simon Pietro Romano <spromano@unina.it> Sun, 15 February 2015 23:29 UTC

Return-Path: <spromano@unina.it>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E461A0273 for <ietf@ietfa.amsl.com>; Sun, 15 Feb 2015 15:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.03
X-Spam-Level:
X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 AAWGhdzXT02w for <ietf@ietfa.amsl.com>; Sun, 15 Feb 2015 15:29:11 -0800 (PST)
Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E79C1A0217 for <ietf@ietf.org>; Sun, 15 Feb 2015 15:29:11 -0800 (PST)
X-ASG-Debug-ID: 1424042943-05f27518c91ede360001-h9jmKw
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id FAmdGGDhVFoAiXto (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2015 00:29:03 +0100 (CET)
X-Barracuda-Envelope-From: spromano@unina.it
X-Barracuda-Apparent-Source-IP: 192.132.34.62
Received: from u554079.nwas2.nw2.tachikawa.mopera.net ([37.227.113.36]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id t1FNSxk3011505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2015 00:29:00 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <863EA2292A43BD86D9416B5D@JcK-HP8200.jck.com>
References: <54DE7F09.8030500@gmail.com> <C5FC0DB6-82F8-4C38-ABFD-D5D9A6E65933@isoc.org.ec> <54DE90C6.6030609@gmail.com> <E39AF4E0-58AB-4249-8A37-3D1CD2D5A691@gmail.com> <54DE9844.1010807@gmail.com> <61FBB27B-4EF3-40A0-8981-00EB89698295@isoc.org.ec> <B90F5E29-06C5-41D1-9F31-1BE42382995F@gmail.com> <CABmDk8=YPZ1W2tTOqP23U2PFVLoDh-3+wwmcA8mpta-Y05op2A@mail.gmail.com> <54DFBAF6.30409@cs.tcd.ie> <71F05D3C-95F1-4424-B6AA-49EBCCB7065A@isoc.org> <20150214225128.GS14296@verdi> <B754B188-1FC2-4E6B-B374-F3B882D99742@nominum.com> <0724649757D3500A9E6C7FAE@JcK-HP8200.jck.com> <5E479E1A-7929-431D-B27D-0D5547EB00B3@unina.it> <863EA2292A43BD86D9416B5D@JcK-HP8200.jck.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----QJ5F3NXA2E07ZHFPEDLF4BKR2A7IFP"
Content-Transfer-Encoding: 8bit
Subject: Re: Remote participation fees
From: Simon Pietro Romano <spromano@unina.it>
X-ASG-Orig-Subj: Re: Remote participation fees
Date: Mon, 16 Feb 2015 00:28:58 +0100
To: John C Klensin <john-ietf@jck.com>, Ted Lemon <Ted.Lemon@nominum.com>
Message-ID: <EED7CD7F-4C4C-4E0D-8029-B4E7622C3C0D@unina.it>
X-Barracuda-Connect: smtp2.unina.it[192.132.34.62]
X-Barracuda-Start-Time: 1424042943
X-Barracuda-Encrypted: AES256-SHA
X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi
Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 37.227.113.36 as permitted sender)
X-Virus-Scanned: by bsmtpd at unina.it
X-Barracuda-BRTS-Status: 1
X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SPF_SOFTFAIL, HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.15358 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/k9JzebVVcnK6X-jkwWzovWCBdv4>
Cc: John Leslie <john@jlc.net>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Feb 2015 23:29:14 -0000

John,

I share all of your wise comments. And I do know that the most challenging issues associated with remote participation (and with Meetecho as well) are of non-technical nature.  We're working hard, together with the IETF leadership and tech team, on further improving remote participation in view of the meeting in Dallas.  Hope you'll keep on helping us with your active participation, your feedbacks...and your patience!

Cheers,

Simon

Il 15 Febbraio 2015 23:49:23 CET, John C Klensin <john-ietf@jck.com> ha scritto:
>
>
>--On Sunday, February 15, 2015 21:24 +0100 Simon Pietro Romano
><spromano@unina.it> wrote:
>
>> If we were serious (as we are) we'd keep on doing our best to
>> improve remote participation support. Most of the functions
>> you cite are, in my view, if not already there ay least VERY
>> close to what can be defined a reliable service suite for
>> remote participation. I encourage you to look back at past
>> meetings and compare the remote experience you had from one
>> meeting to the other in the last three years. Please don't
>> tell me we didn't do giant steps towards a good service. And
>> when I say 'we', I mean the IETF leadership, the secretariat,
>> the NOC, some people like you who have provided invaluable
>> feedback on end users experience...and the Meetecho team.
>
>Simon,
>
>I know you are serious and that you and your colleagues have
>been making incredible efforts to make things work.  I've said
>that several times, tried to say it in this thread, and want to
>say it again now.  I feel the same way about the Secretariat and
>NOC staff. 
>
>I agree that giant steps have been made, largely because of your
>collective efforts.
>
>At the same time, Monday morning problem patterns continue and
>are dealt with as emergencies rather than something that can be
>eliminated by adequate testing.   I've had you and your
>colleagues tell me that a particular problem can't be fixed
>during a WG session because it would be disruptive to the
>session.  We've had a brief discussion or two about what you
>could do with high-end remotely controllable cameras, especially
>with a few more people helping out your team.  We still don't
>have a regular plan (defined as something I can know about and
>count on when I'm deciding whether to travel to a meeting) for
>coverage of Sunday tutorial sessions.  We've also had a bit of a
>discussion about whether it would be reasonable to interrupt
>speakers to remind them not to pace the floor out of the camera
>frame.
>
>On a different dimension, several people, notably SM, have
>pushed for better recognition of remote participants in the
>process --including but not limited to concerns about binding a
>Nomcom eligibility formula that stresses in-person meeting
>attendance to several other things where rights to participate
>in various ways are tied to Nomcom eligibility.  I don't know if
>he would agree, but my sense has been that his ideas haven't
>gotten off the ground --not because they were the wrong
>solutions, but because there is a shortage of general
>recognition that the issues are important.
>
>I think there is a difference between "the best it is possible
>to do with volunteer efforts (even nearly superhuman efforts)
>and some help from the Secretariat" and "what we could be doing
>if we really believed that effective and reliable remote
>participation was critical to the IETF".  I agree that we
>(again, due in very large measure to your efforts and that of
>your colleagues) are getting quite close to that first
>objective.  I think we would be even closer if the community
>stopped wasting time, facilities, and bandwidth on WebEx and
>concentrated those resources on Meetecho.  But what we are not
>doing -- and what I think the community and its formal
>leadership are not serious enough about-- is that second
>category.  
>
>As examples, should your colleagues and the NOC be told by the
>IESG that, if there are technical problems with remote feeds or
>input, you are entirely justified in stopping a WG meeting to
>get those problems resolved and should do so?  If there is an
>active discussion in a WG and a remote participant cannot
>contribute to it do to lag, some technical problem, or how the
>mic line is being managed, does she have the right to protest
>and, if so, how should that protest be expressed?   As someone
>else suggested, should we have a "put hand up" or "put me in the
>queue"  function that applied to both those in the room and
>remote participants on an equal (or fair) basis?   Should we
>really move toward moderation of sessions and, if so, how and
>under what rules?    If I'm remote and asking a question at the
>virtual mic (or having it asked on my behalf) should my picture
>be on the screen in the meeting room and projected to others
>and, if so, how would be do that?
>
>I'm sure you have a list of your own.  I also note that the
>items on the list above are at least partially non-technical.
>
>"Not serious" was a comment entirely about things like that
>second list and the amount of serious (sic) attention it seems
>(or, more accurately, does not seem) to be getting, despite your
>efforts, my efforts, and the efforts of several others.
>
>Thanks again for your efforts, without while remote
>participation would be, IMO, hopeless rather than just about
>good enough from a technical standpoint (and that in spite of
>some factors working against you).
>
>     john