RE: Registration details for IETF 108

[Larry Masinter <[e-mail]>]

"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 <[e-mail]>
> Sent: Friday, June 12, 2020 3:05 PM
> To: Larry Masinter <[e-mail]>; 'Jay Daley' <[e-mail]>
> Cc: 'IETF Rinse Repeat' <[e-mail]>
> Subject: RE: Registration details for IETF 108
> 
> 
> 
> --On Friday, June 12, 2020 13:37 -0700 Larry Masinter <[e-mail]>
> 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