RE: Registration details for IETF 108

Larry Masinter <LMM@acm.org> Fri, 12 June 2020 23:08 UTC

Return-Path: <masinter@gmail.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 6A02F3A1640; Fri, 12 Jun 2020 16:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3M0geHT8eU0R; Fri, 12 Jun 2020 16:08:54 -0700 (PDT)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 E4F863A163F; Fri, 12 Jun 2020 16:08:53 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id m2so4487475pjv.2; Fri, 12 Jun 2020 16:08:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=bYJnzeSiOzBvFjYV84IcLzesyhqe9E7InyTX50dai2E=; b=V6AHdI0VRih9eyhFftrmibe04waF1mB6dLAoywF0sy/Euc7n5osRY+FXUtkWCRiqVo CeKo2sf8MQR01Hi6k29duDNWuhd/4GSA7iONvb6XK1dTvMvrO+pHXxv/Q3aXpAMEZECJ QbNNWY4UHaVnylVCc78fDoT6tTwbQX3294w2NG6vlI+2cdLDuaiv5FkUCZZ+eB9+VvhA sa6wi/TqLT72ikMMoOXqqulvg1wzLCVhMQUii9gyujAIcQfIX/kCz+4BzCv5ffOCvjiy PYKWPUknHC1odVYI5Z0KUx25QGt2xW5TI3mb9KLMZzq7N8vocsYvOvvV3ajk2lxPEpMF 7Iig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=bYJnzeSiOzBvFjYV84IcLzesyhqe9E7InyTX50dai2E=; b=X73ewhZuyimUJfFnnNTANBo9mnUM1NWOj+59wKobDXZj2Jg108giSY4jlV3je5ys0Z TOevFwdiEEJYOYUFpZ99z84Gh5QmIeMqJQfKe9/6bi5rSQMyVJM5chPHecfLy8PsdOzP Zb1dQ3KjBczsOyCDh69yUFlFBAWDbGr32ZiP0BDTyzF3Se2CTMdbq53NxO2W/WCqm8bb iGDtuJiqui1FQl0yof0zop3UgiYDplcH66HsrPV7hHQwUUmynQDssDtHkpHJehGlipiE G5Y1RAM04IERF1xslKiwvwRGm4xLwJsXiCaeVHgqJZYoVt42GtwEkckfXPlD0cljQiIx 1O+Q==
X-Gm-Message-State: AOAM531Wd4PEtXtYgss8BwrW4UBADUXVeU3G6rhKVbrSVWznC1yMl1G+ 6Hc2YyPe4Br7gxDPiN8BAiU9cows/1k=
X-Google-Smtp-Source: ABdhPJwV2+Dp47p9c3JSctTOAs6/9gApALS/is0vh5lCyTIVYQxJaO+nYzw9RIjurYyEDY4OWZ3h6Q==
X-Received: by 2002:a17:90a:aa83:: with SMTP id l3mr1109577pjq.73.1592003332702; Fri, 12 Jun 2020 16:08:52 -0700 (PDT)
Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id q92sm6170853pjh.12.2020.06.12.16.08.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 16:08:52 -0700 (PDT)
Sender: Larry Masinter <masinter@gmail.com>
From: Larry Masinter <LMM@acm.org>
X-Google-Original-From: "Larry Masinter" <lmm@acm.org>
To: "'John C Klensin'" <john-ietf@jck.com>, "'Jay Daley'" <jay@ietf.org>
Cc: "'IETF Rinse Repeat'" <ietf@ietf.org>
References: <159062833754.6110.5826748635235943562@ietfa.amsl.com> <9F71F116-D7B2-4ECE-9000-957A0C497404@ietf.org> <01d701d638ca$c096b5e0$41c421a0$@gmail.com> <CABcZeBOLAw_9s-gobFYB=5THu_Q70UmDLn_ZhVXhNRHN_nu_0w@mail.gmail.com> <607b7682-0a75-62b6-fd0e-5e2e1171a68b@cs.tcd.ie> <CA+9kkMBEqhn115ToB0SwOGavmXze4DdJdL941J4LeVMRrPngpQ@mail.gmail.com> <e1b804ae-4c2e-fdf3-8804-47820d35facf@cs.tcd.ie> <CA+9kkMC8ZWHaCBg=WzwtriVf-3bq=egupVgAH-J7dSqspwLoFw@mail.gmail.com> <a19c3066-bfa7-ded2-d98f-b5e367645451@cs.tcd.ie> <E8BE49F8-6FE8-4470-9314-21F8BFE9768A@gmail.com> <1UWAyqDxFn.1IOJoXgqe8i@pc8xp> <m2tuzpz0eg.wl-randy@psg.com> <94fdbedd-358b-7fae-c784-9550311d8aea@gmail.com> <m2h7voztz5.wl-randy@psg.com> <6F3828AD-FFE3-4331-8E76-E212F1357919@gmail.com> <m2ftb1reu1.wl-randy@psg.com> <2E2893AA-2BCC-4EA1-AF31-0B4BA437C46F@csperkins.org> <m2d065rcjt.wl-randy@psg.com> <496648EA-4D97-44CA-B45A-7AAC283A1025@ietf.org> <00b801d640f9$5afe7bf0$10fb73d0$@acm.org> <602817EB7E0004CD1FD5CCC5@PSB>
In-Reply-To: <602817EB7E0004CD1FD5CCC5@PSB>
Subject: RE: Registration details for IETF 108
Date: Fri, 12 Jun 2020 16:08:51 -0700
Message-ID: <002d01d6410e$704cb070$50e61150$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQIi94OafgxU9aBVwZLcOLw3dFWcqwFYyw8cAUd5JL0CLwV6QwEfvPhRAlPlkvUBdOq/mwKmB3ADAiOLQIIBz6b+yALCIOSpAUY+rJ0B6KVUqgH5soOiAXp+ZlIBIQWycwD7XauEAaSFKdkDbn24pgKeSa2lAna26RWnDFNoUA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/H8lPKxrrs4pkVYxkb13D9E78m8c>
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:08:55 -0000

"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>rg>; '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