Re: Registration details for IETF 108

Ole Jacobsen <olejacobsen@me.com> Fri, 12 June 2020 23:14 UTC

Return-Path: <olejacobsen@me.com>
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 D94783A1643 for <ietf@ietfa.amsl.com>; Fri, 12 Jun 2020 16:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.com
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 wepZVtrLqY8U for <ietf@ietfa.amsl.com>; Fri, 12 Jun 2020 16:14:31 -0700 (PDT)
Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A283A1640 for <ietf@ietf.org>; Fri, 12 Jun 2020 16:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1592003671; bh=xdgtGbc7FjRl79XXXQw4bD5if1FLrT4rZJsFgG97SKw=; h=Content-Type:Subject:From:Date:Message-Id:To; b=aqmjFRAO0u+xgep4PphJpzZeRb6GOzYL0T3sTa9kT0WEX13EyrXk9DkrVq1Kw4oXm eepJMfnHxIGvPwAdOXad6NoS2TZXyBwk5eC97dv+M5ioQXQ9RhjcOfSz2Qxbz2rER8 +IROltLRqBNiHedap6qXIQFQWGiiuy4Z04Pv1mcT/mxlfJe9ChaQLw/FgTBFHeaY18 Dwg39C+s8EnjS4ShxY2/czHc/EYQDFDBmv/ELPM/PdcsdyIqxqw/ykXQ7dUhc5ZlQb m0xuUbM7Xvpd6AO3hXPkAUnEOji8INfMo0fAoP854rNEp9PDvKfsGVZGWn0QhKGZSJ 28ouZVq4Yf3gQ==
Received: from [172.16.1.2] (173-11-110-134-SFBA.hfc.comcastbusiness.net [173.11.110.134]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id 1F6EAC02B1; Fri, 12 Jun 2020 23:14:31 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-417D348B-B993-4F34-A6B0-768F7BA5726B"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: Registration details for IETF 108
From: Ole Jacobsen <olejacobsen@me.com>
In-Reply-To: <002d01d6410e$704cb070$50e61150$@acm.org>
Date: Fri, 12 Jun 2020 16:14:30 -0700
Cc: John C Klensin <john-ietf@jck.com>, Jay Daley <jay@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Message-Id: <5A62B7C7-A28B-4FB7-99AE-E8A7E16E1662@me.com>
References: <002d01d6410e$704cb070$50e61150$@acm.org>
To: Larry Masinter <LMM@acm.org>
X-Mailer: iPhone Mail (17F80)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-12_17:2020-06-12, 2020-06-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006120174
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_typgGapSNJDNPkJFmju1przw8Y>
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: Fri, 12 Jun 2020 23:14:34 -0000

Larry,

The history of the relationship between the IETF and “The Meetecho Guys” goes back a decade or more. They have been working closely with the NOC and others to tailor the system to our needs.

Ole J. Jacobsen
Editor & Publisher
The Internet Protocol Journal
Cell: +1 415 370-4628
T-Mobile: +1 415 889-9821
Docomo: +81 90 3337 9311‬
http://protocoljournal.org

Sent from my iPhone

> On 12 Jun 2020, at 16:09, Larry Masinter <LMM@acm.org> wrote:
> 
> "I believe IETF chose for good reason" doesn't sound open or transparent.
> 
> Why don't we focus on what are the unique IETF technical requirements
> that would drive a system choice?  Are they listed in the
> conference-tech-lab's
> list of things to consider?  Something that the system chosen uniquely
> meets?  Those considerations are important to capture, and would
> then become part of the RFP. Surely if they can run a conference
> using any of the listed systems, they could run one using meetecho too.
> 
> I'd think we'd want to contract with SOMEONE to actually manage
> logistics, rather than roll our own, in a hurry.
> 
> 
>> -----Original Message-----
>> From: John C Klensin <john-ietf@jck.com>
>> Sent: Friday, June 12, 2020 3:05 PM
>> To: Larry Masinter <LMM@acm.org>; 'Jay Daley' <jay@ietf.org>
>> Cc: 'IETF Rinse Repeat' <ietf@ietf.org>
>> Subject: RE: Registration details for IETF 108
>> 
>> 
>> 
>> --On Friday, June 12, 2020 13:37 -0700 Larry Masinter <LMM@acm.org>
>> wrote:
>> 
>>> ...
>>> For moving IETF online, I'd suggest hiring some group that  does it
>>> for a living
>>> 
>>> https://www.diplomacy.edu/conference-tech-lab
>>> 
>>> in consultation with IETF in an open transparent manner, of course.
>> 
>> Larry, that path leads to a rathole-rich environment with very smart and
>> well-fed rats. Among other things, I note that Diplo's list does not
> include
>> Meetecho, which I believe IETF chose for good reasons and with the
>> limitations of other systems for our purposes in mind and then, more
>> important, assorted people (including Ray and the Secretariat) worked
>> closely with the developers to further adapt to our needs.
>> 
>> Moreover, unless something has changed that you or Jay know about but I
>> don't, prior experience with Meetecho strongly suggests that, if we
> discover
>> deficiencies that we would like to have corrected before IETF 108 and give
>> them reasonable notice, the chances of getting those changes made are
>> quite good.
>> Having tried, in non-IETF contexts, to work with the providers of three or
>> four of the systems Diplo lists to get bugs or unfortunate features fixed,
> a
>> year or two might be plausible, but not six weeks... unless , of course,
> one is
>> a government making demands and/or threats.
>> 
>> It seems to me that Jay has, to his credit even if he has not gotten it
> right
>> every time, been struggling to avoid such ratholes.  If nothing else, even
> if
>> Diplo were a perfect match, there almost certainly is not enough time to
>> work out a contract with them, have them understand our needs, adjust fees
>> as needed, and then go into a meeting that is now only six weeks away
>> without creating unacceptable risk.
>> 
>> So, at minimum, can we postpone that particular discussion until we get
>> through IETF 108 and can start assessing what we learned and what to do
>> next?
>> 
>> thanks,
>>   john
> 
>