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

John C Klensin <john-ietf@jck.com> Fri, 01 April 2016 15:47 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 A19F312D69D for <ietf@ietfa.amsl.com>; Fri, 1 Apr 2016 08:47:37 -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 9X7U3godyxwA for <ietf@ietfa.amsl.com>; Fri, 1 Apr 2016 08:47:36 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 E306C12D64E for <ietf@ietf.org>; Fri, 1 Apr 2016 08:47:35 -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 1am1IG-00085q-HW; Fri, 01 Apr 2016 11:47:28 -0400
Date: Fri, 01 Apr 2016 11:47:23 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Recentattendees] Remote Participation for IETF 95: Meetecho Details
Message-ID: <6E69E3CBF10E406DF7EB72B0@JcK-HP8200.jck.com>
In-Reply-To: <56FE49A1.2030607@cs.tcd.ie>
References: <20160330202243.4795.63685.idtracker@ietfa.amsl.com> <56FC7167.4010409@nomountain.net> <A4B09E64B56CD0B8C4379A99@JcK-HP8200.jck.com> <b982c83c-7de7-516e-11be-0fe7522a93ed@bogus.com> <4C79795B5F7E7C8345C9DC31@JcK-HP8200.jck.com> <56FE49A1.2030607@cs.tcd.ie>
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/OT3LwMUhpigaavurk2PBpc1utWg>
Cc: Melinda Shore <melinda.shore@nomountain.net>, ietf@ietf.org
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 15:47:37 -0000


--On Friday, April 01, 2016 11:12 +0100 Stephen Farrell
<stephen.farrell@cs.tcd.ie>; wrote:

>...
> I agree that requiring registration of remote attendees
> without having announced that was a mistake.

See below.  However, some of this (and my reaction) is OBE given
Tobias's note, so I'll save a longer and more detailed response
for another time.
 
> I agree with those who've said that it might be reasonable
> to require remote attendees who want to be in the meetecho
> queue-thing to have registered. But even so, that ought be
> a thing gets announced ahead of time. Personally I doubt
> that such registration is really needed even for the queue
> thing, but I'm willing to believe there may be an anti-DoS
> benefit there somewhere. That one can ask questions in the
> jabber room without registering for the IETF meeting is IMO
> just fine.)

To reprise part of the discussion the last time the community
discussed this, there are IPR and (while the IETF continues to
ignore them and hope there will never be a problem)
competitiveness/ antitrust issues that suggest that we should,
to the extent possible, know who is participating in and
influencing our decisions (see the recent threads about IPR/Note
Well revisions).   That point of view suggests registration for
Jabber participants too.  There are tradeoffs with that line of
reasoning (presumably including those that cause your doubts),
but they are exactly why an open community discussion is needed.

> So yeah, I think someone (I dunno who) made a mistake. I
> expect it's not fixable for this meeting, but can be fixed
> for next time.

See below.  Because of the tradeoffs, I'm less worried about
what the decision is than that we discuss it openly and
carefully.

> Having an easier registration experience for those who do
> want to register as remote attendees is also something to
> fix.

As Dave Crocker pointed out, fine-tuning the details is a
different problem and something we can improve as we go along.
Certainly I would have preferred that things have been
sufficiently thought out to get them closer to right the first
time, but so it goes.  On the other hand, it is clearly the
IAD's and IAOC's responsibility to be sure that a change is
really ready before deploying it.  As Tobias acknowledges, that
didn't work this time.

>>  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.

> That last is just over-reaction and nowhere near justified. I
> figure someone made a smallish mistake, nobody died, it can be
> and will be fixed. IMO taking the situation seriously requires
> us to not over-react in such ways.

Well, maybe. I think we should probably defer the rest of this
discussion until Tobias gets to BA and is able to consider the
situation and explain in more detail.  However, I recall a long
series of difficulties with the IASA failing to come up to
expectations for transparency and disclosure that seemed very
clear when BCP 101 was deployed.  That pattern can't be blamed
on Tobias because it started long before he go onto the IAOC.
However, I believe that every IAOC member appointed by the IETF
community has two sets of responsibilities -- to be sure the
administrative side of things is run properly and responsibly
and to operate a transparent process with the community kept
informed and that is responsive to community discussions and
conclusions.   

It is a huge oversimplification, but, whether we are talking
about this issue with changes in registration policy, questions
about meeting site selection and criteria, late and/or
uninformative minutes, posting of contracts, or other issues, it
appears to me that there has been enough of a pattern that it
really is time for IAOC members to carefully examine whether
they, and the people and systems for whom they are responsible,
are really as committed to the transparency, openness,
consultation, and responsiveness of their role as they are to
simple prudent financial management... and for the community to
start requiring that they be accountable if IASA behavior is not
consistent with those principles.

If you think _that_ is an overreaction, I suppose we will just
have to disagree.

    best,
     john