IETF WG meetings and remote participation

Robert Raszuk <robert@raszuk.net> Sat, 15 February 2020 19:41 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA601200F4 for <ietf@ietfa.amsl.com>; Sat, 15 Feb 2020 11:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 PQa02RjN1ksW for <ietf@ietfa.amsl.com>; Sat, 15 Feb 2020 11:41:57 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360581200E3 for <ietf@ietf.org>; Sat, 15 Feb 2020 11:41:57 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id a22so12942844oid.13 for <ietf@ietf.org>; Sat, 15 Feb 2020 11:41:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tFR6138ofVVT29JLQ91IE0twicprr8URD+/HtxnpyS8=; b=PsF8OQ+KHHQ8handZQEQ+AVbgOzEOC5Dd6K6F1pTLuwy5Pakh2iPMYe7C80EKK31IJ y0wBpsbFOAaU8u1RxAW7cc7ctN5YFCYL/UTGDdYAlwdd5kawvZNa+J/A9mJPK/6HudNk F1uPLjAGXeiM6MsLIIR7GxI7pTqNsfqTG+92UGRw+WfQ+6j18Bx/K8iHkE7FciC76JxB RPSgZ9hd1sPczHH0F1lHZ/5skHw5WfVLVy9jZOHGP2nAnNPg/yA7PnlcOlkPWVluwcRF 3D1v8s1oWFVqB5xp8wzBsn1lDqrtNBQiiUjmqeDMddTbV949rIoqil15ss80E72a01+D ocBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tFR6138ofVVT29JLQ91IE0twicprr8URD+/HtxnpyS8=; b=okELLrS8bF0nH+8KJjlTXc/aVNc3yXe0OlQX1xd0v+2ISwcc7ThPRtC2VmuPJfEHP0 xBxwNkBn55dOxVmtCkRTYUePjH0YytctLqbhtcS7EjoXn6Mse8Mgfh/tt+kDEgs8R9L5 6g0BBdrdiSyiVbXqfwe0i/TMUEKQsBldvncacuimKojAUfMHjjr6rcaLH2jN//xxSRp7 bQf/JhzkB+1bRmmi/D9+LUp2mX7OMt+n6boBbQWYpEqK/7BrKuwVll9wQQOGwZZ+p1Db aEoiSzhSZFp2DxrLbb0LJxjKbvKS+6fWJwhNWvg7KtLnEve7p6gFqGkoTftCV6SL1+fl I7pA==
X-Gm-Message-State: APjAAAUf6QqG31Tw8/8JWQEbHINhlFPeJxEx3OFcHERNNe5Hn3+I7okB U9M3RESqAoemLVEGRPU0hNYQGyYIA9g8sl54/bz37gZ5
X-Google-Smtp-Source: APXvYqyikm9K9WnX3pouzzouoyilFzmluIb5EmLHuG1CGAH798k16+PdbFM5fJ4x1TCPl8Zt4yWSY0kncHkJlBKNztY=
X-Received: by 2002:aca:d985:: with SMTP id q127mr5484158oig.132.1581795716336; Sat, 15 Feb 2020 11:41:56 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMEMY1gxtj70+5wPOG+XHsk_nX8af4kbXD30_ULDmHMyQg@mail.gmail.com> <666CACAD-F8D4-43A1-8336-3CC9BBCC4B08@puck.nether.net> <5CBB6602066BF4A674D4D092@PSB>
In-Reply-To: <5CBB6602066BF4A674D4D092@PSB>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 15 Feb 2020 20:41:47 +0100
Message-ID: <CAOj+MMH_mA0+0maq+oYJZ=_GcGk5BVU9N4v0mG7hs+_f7WUiqw@mail.gmail.com>
Subject: IETF WG meetings and remote participation
To: John C Klensin <john-ietf@jck.com>
Cc: IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c7a303059ea283bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/bM_fZjyhslhrUU8OxCUH0iZXaIk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 15 Feb 2020 19:42:00 -0000

/* Adjusting the subject as this is not virus related */

Hi John,

I think you have touched on the very key point. What is the value of WG
meetings if in many cases during WG meetings interactive discussions are
either minimal or non existent ?

And as you also correctly observed in most cases mic lines being cut to
proceed with another monologue just to fulfil the packed agenda.

I think each draft should have a youtube video attached such that instead
of wasting time to listen to one actor shows watch it before and then sped
those 10-15 min to interactively discuss.

Maybe even the ratio of "who has read the draft or watched the video"
significantly would raise from few hands to entire WG room or at least half
of it :).

For me personally most value in attending IETF is 70-80% to meet colleagues
during breaks, dinners, breakfasts or bar and remaining 20-10% is to
present new drafts hoping this may trigger more break time or on the list
discussions.

Sure some may have different agenda to attend (for example to use IETF as
new technology solution push piston), some may organize meetings with
customers around IETF etc ... but here I think we should focus on just the
real IETF values.

#1 how can we maximize time to get the most out of it to discuss new
technologies, protocol extensions etc ..

#2 how can we make it really open, easily accessible and equal for local
and remote participants

Kind regards,
Robert


On Sat, Feb 15, 2020 at 8:02 PM John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Saturday, Feb 15, 2020, at 10:27 AM, Robert Raszuk
>  <robert@raszuk.net> wrote:
>
> > If we only make it as a rule that questions from remote
> > participants can be submitted via notepad instead of live
> > conference chat window, the scaling properties could be more
> > than satisfactory even if 100s of folks join remotely.
>
> Based on a good deal of active remote participation experience,
> I don't know whether this is a good idea or not.  If it were to
> be a good idea and a much higher than usual level of remote
> participation were anticipated, every WG session (and the
> plenary) should be required [1] to have at least two notepad
> scribes/readers dedicated to the remote queue and at least two
> separate mic lines with one of the latter dedicated to those
> scribes.  For the latter, once someone got to the mic, he or she
> would exhaust every question or comment that had been logged
> while the other took notes, then they would switch off while
> people were taken from the in-room queues.
>
> That would still not be ideal in terms of queue management and
> fairness but I note that, in many WG sessions and plenaries in
> the past, remote participants have had trouble getting their
> questions and perspectives into the room even with low levels of
> active [2] remote participation.  For really active remote
> participation, I suggest that, in the last couple of years, we
> have done responsibly well in some WGs but barely squeaked by in
> others and in the plenaries, with the key problems being human
> rather than technology ones.
>
> I think it is also relevant to note that one of the problems
> with remote participation in the recent past has been that those
> who are typing into jabber and having their questions read often
> find that, by the time they are through typing in a question or
> comment, the jabber scribe notices and heads for the mic line,
> then waits to get to the front of the queue, and then reads
> whatever was typed in, the topic may have moved on to the point
> that the comment is no longer relevant.    I've even had mic
> lines cut off while I was typing and before the scribe can get
> to the mic.  Assuming the WG Chairs are paying attention to the
> indication that there is someone waiting in the Meetecho queue,
> it is much better in that regard because, just like standing in
> a mic line, one can signal a desire to speak but adjust actual
> comments to reflect ensuing conversation.
>
> >From the standpoint of that real-time input experience (and,
> again, assuming Chair are paying attention and cooperating) the
> Meetecho speaking queue works better than Jabber input and I
> would predict Jabber input would work better than the Etherpad
> or equivalent.  The latter might turn out to be lots better for
> logging a question or comment for the permanent record than for
> active discussion, but, at least IMO, the purpose of real-time
> WG sessions is active and real-time discussion, not logging
> comments in the hope that someone will look at them eventually.
>
> Noting that Ron asked an essentially technical question about
> capacity of the infrastructure and that he has yet to receive a
> response (at least on-list) from anyone who actually knows how
> the relevant systems work, I suggest that answers and plans
> about both his questions and the issues raised above are
> important to any decision that might significantly raise levels
> of remote participation.
>
> best,
>    john
>    (who would probably have been remote from Vancouver even
> without the virus)
>
> [1] "Required" as in "if the required level of support is not
> present in the room, the WG session is canceled in real time,
> everyone present goes out for coffee (or other beverages of
> choice), and any work expected to be done in that session either
> moves to the mailing list or is delayed for an all-virtual
> meeting or IETF 108".    Our usual way of handling remote
> participants who don't get to participate is to [maybe]
> apologize.  Because, in practice, we seem to be increasingly
> making decisions in f2f meetings with ratification on mailings
> lists --a process in which someone who was excluded from that
> discussion can raise objections on the list but often has no way
> to provide input into the discussion before the decision was
> made-- there are probably grounds for appeal if the ratification
> process assumes the validity of the f2f decision, but, AFAIK,
> that hasn't happened yet.  Yet.
>
> [2] In practice, we have three kinds of remote participants.
> (1) Those who listen (whom Meetecho identifies as Observers),
> (2) Those who sign up as participants but whose presence and
> visibility in the actual meeting session might be limited to one
> remark or question, and (3) Those who, despite being remote,
> expect to actively participate in, and contribute to,
> discussions going on in the room. The distinction is
> particularly important if some of the remote participants are WG
> Co-chairs, presenters, authors of documents, originators or
> major contributors to proposals or specifications under
> discussion, and so on.   At least in terms of IETF discussions
> and decision-making fairly representing all perspectives and
> points of view, we need to tune a remote participation system to
> that active participant group while not seriously discriminating
> against the other two.
>
>
>