Re: [Tools-discuss] updating interim meeting with webex

Christian Hopps <chopps@chopps.org> Fri, 03 April 2020 12:16 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420573A18D7 for <tools-discuss@ietfa.amsl.com>; Fri, 3 Apr 2020 05:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 G3JuKyoRYimB for <tools-discuss@ietfa.amsl.com>; Fri, 3 Apr 2020 05:16:37 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB773A18D4 for <tools-discuss@ietf.org>; Fri, 3 Apr 2020 05:16:37 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 66C116085E; Fri, 3 Apr 2020 12:16:36 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <8cb271d7-752f-0b22-9c82-c2484151fc90@levkowetz.com>
Date: Fri, 3 Apr 2020 08:16:35 -0400
Cc: Christian Hopps <chopps@chopps.org>, tools-discuss@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DBA4233-7CA7-4B9C-B897-38D5BA7C3A37@chopps.org>
References: <8B7D852A-2388-4F70-85FC-813B4FF22AB7@chopps.org> <ec2c80ce-27db-0db7-f6dd-720e798e633b@levkowetz.com> <0277B62A-6D1C-4302-8EEB-D49C1CE014CF@chopps.org> <8cb271d7-752f-0b22-9c82-c2484151fc90@levkowetz.com>
To: Henrik Levkowetz <henrik@levkowetz.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/SHSSqcrL2Qqa0yBnOiWbxb9kufk>
Subject: Re: [Tools-discuss] updating interim meeting with webex
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 12:16:47 -0000


> On Apr 3, 2020, at 8:00 AM, Henrik Levkowetz <henrik@levkowetz.com> wrote:
> 
> Hi Christian,
> 
> On 2020-04-03 13:13, Christian Hopps wrote:
>> Hi Henrik,
> 
>> Also worth mentioning on the experience, not assigning your webex
>> details get's the scheduled email sent from iesg-secretary with a
>> link pointing to a webex room for the WG which simply queues folks up
>> to be ignored while the actual meeting is running.
> 
> Huh.  Was this because the webex room for the WG didn't function, or
> because there wasn't a chair there?

It's not clear to me yet what was happening. The generic link appears to put the user in a waiting room (waiting on being let in by the host), I don't know if that person was somehow "let in" if they would enter the scheduled meeting or not. I did notice a webex created email sent to lsr-chairs during the meeting for one person (Bruno), I then looked at our current participants and saw him there so that was that.

After the meeting we were informed by another user that they tried 3 times and were placed in the waiting room 3 times and then gave up. We never received any email for this person.

I'm not even sure that the waiting room they are being stuck is for the scheduled meeting we were running anyway. I think this might just be like a general way to connect with the "lsr" webex user (like a phone call)?

>> The email auto generate function should probably not include a
>> generic link the WG webex account as it does the wrong thing.
> 
> Ok; however that begs the question of why not use the WG webex account
> for the interim?

We did, this was a scheduled meeting made by the LSR account. Here's something from the user who eventually got into the running meeting (Bruno):

> So may be my experience may help for next time(s). See below.
> 
> An email from the IESG secretary was sent on 2020-03-19, saying "Information about remote participation: https://ietf.webex.com/meet/lsr "
> Hence I used that URL.
> On this webex, the meeting did not start on time so I've waited for some time. Then 10-15 minutes past the start, I decided to 'notify the host', but never got accepted on the webex.
> At that point I assumed a technical issue with webex and monitored the mailing list, but no one was complaining, which is not inline with typical IETF reaction ;-) .
> So I assumed the error was only on my side and I searched for more emails and found one from Chris (2020-03-31) saying that the URL was https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8 
> And this one worked fine.
> My guess is that the 'interim' webex did not use the 'lsr' webex. Also the 'official' notification from the IESG secretary with the incorrect webex URL did not helped.
> 
> --Bruno


Aha! so it appears maybe we got the email about Bruno b/c he clicked "Notify the host"? I bet the other user (Robert) never clicked that, so we got no email. It's not clear what would have happened even if we had invited Bruno in, maybe b/c the LSR user was in the scheduled meeting it would have brought him in to that meeting as well, but that's only hoping.

In any case having the links default behavior be to stick users in a queue with no notification to the WG account means we probably shouldn't advertise that link.

Thanks,
Chris.