Re: [Recentattendees] Remote Participation for IETF 95: Meetecho Details

John C Klensin <john-ietf@jck.com> Fri, 01 April 2016 00:28 UTC

Return-Path: <john-ietf@jck.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 D8DAA12D925 for <ietf@ietfa.amsl.com>; Thu, 31 Mar 2016 17:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Qm-kse9MlWHM for <ietf@ietfa.amsl.com>; Thu, 31 Mar 2016 17:28:16 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B0712D921 for <ietf@ietf.org>; Thu, 31 Mar 2016 17:28:16 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1almwf-0005cp-4U; Thu, 31 Mar 2016 20:28:13 -0400
Date: Thu, 31 Mar 2016 20:28:08 -0400
From: John C Klensin <john-ietf@jck.com>
To: joel jaeggli <joelja@bogus.com>, Melinda Shore <melinda.shore@nomountain.net>, ietf@ietf.org
Subject: Re: [Recentattendees] Remote Participation for IETF 95: Meetecho Details
Message-ID: <4C79795B5F7E7C8345C9DC31@JcK-HP8200.jck.com>
In-Reply-To: <b982c83c-7de7-516e-11be-0fe7522a93ed@bogus.com>
References: <20160330202243.4795.63685.idtracker@ietfa.amsl.com> <56FC7167.4010409@nomountain.net> <A4B09E64B56CD0B8C4379A99@JcK-HP8200.jck.com> <b982c83c-7de7-516e-11be-0fe7522a93ed@bogus.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/clWiXgshuNz93H8Rt9M0tD0hbEE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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, 01 Apr 2016 00:28:21 -0000


--On Thursday, March 31, 2016 16:20 -0700 joel jaeggli
<joelja@bogus.com>; wrote:

> On 3/31/16 11:29 AM, John C Klensin wrote:
> 
>> A registration requirement for remote participants is a major
>> policy change and one for people who merely want to passively
>> observe is something I believe the community has several times
>> concluded is inappropriate given privacy, etc., concerns.  So,
>> who made this decision and how?  Unless the answer involves a
>> community discussion and Last Call or equivalent process that
>> I missed (and apparently Melinda did too), if the answer to
>> "who decided" involves anyone in the IETF Leadership, would
>> they please offer to resign?
> 
> I think you are accusing the community selected committee
> members of malfeasance. At least now we are clear on where we
> stand.
> 
> We have advanced No BCP or standards track document to describe
> requirements or procedures for the operation of remote
> participation nor should we IMHO unless:
> 
> We view it as a core function of the IETF activiity.
> 
> It is mature enough that the thing we describe is neither
> obsoleted or overtaken by events or at least is not focused on
> the technology and method of delivery before the document is
> published.

Joel,

We aren't talking about the "technology or method of delivery"
for remote participation.  AFAICT, I raised two issues, neither
of which was about that.  The issues were:

(1) The unexpected decision to impose a registration requirement
on remote participants.  

I would believe there should have been at least an announcement
but otherwise that it was not a big deal had there not been
extensive discussion in the community about the possibility of
asking some or all remote attendees to register.  I think the
clear conclusion from those discussions was "no" (and I was on
the losing side, so I'm not trying to back anyone into or out of
a policy I like here).  That was "no, it is not a core
function", "no, it raises too many privacy issues", and "no,
there is no need to do it".  

In general, if the community has a discussion that concludes
with either "don't do that" or "needs more thought", there is an
expectation that it won't be done without reopening the
discussion or making a clear statement as to why the change was
needed.  Neither of those occurred, at least as far as I can
tell.  I've said nothing about malfeasance, nor do I believe
there is any evidence of evil intentions.  However, I think
there has been a significant breach of community norms and
expectations about openness, consultation, and transparence.   I
also don't know if that failure was by "the community selected
committee members" or if some staff member is making decisions
without adequate supervision, but it is a problem either way and
I hope that whomever is involved will take the situation
seriously, explain the source or reason for the disconnect to
the community, and evaluate (along with the community) whether
they really want to do whatever job they are doing.

(2) There are some almost-unrelated issues about how remote
participation information is presented and made available and
about remote access to, e.g., Sunday tutorials.  Those topics
are old news but there is some question about why we are having
to discuss them, or scrambling around to fix them, a few days
before IETF sessions begin.  That seems important to me not only
because we've had these discussions fairy regularly but also
because, IMO, things were getting steadily better for some time
but we now seem to have reversed course and gotten a little too
relaxed again.  Again, I think the community is entitled to know
who bears the responsibility for having such things under
control and how the apparent lapses this time occurred.  That
isn't a claim of malfeasance either, although it is possible
that there are some issues of non-feasance.

best
    john