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
- Re: Remote Participation for IETF 95: Meetecho De… Alexandre Petrescu
- Re: Remote Participation for IETF 95: Meetecho De… Alexandre Petrescu
- Re: Remote Participation for IETF 95: Meetecho De… Alexandre Petrescu
- Re: [95all] Remote Participation for IETF 95: Mee… Mauricio Esteban
- Re: [Recentattendees] Remote Participation for IE… Melinda Shore
- Re: [Recentattendees] Remote Participation for IE… John C Klensin
- Re: [Recentattendees] Remote Participation for IE… Ray Pelletier
- Re: [Recentattendees] Remote Participation for IE… Dave Crocker
- Re: [Recentattendees] Remote Participation for IE… Lucy Lynch
- Re: [Recentattendees] Remote Participation for IE… John C Klensin
- Re: [Recentattendees] Remote Participation for IE… John C Klensin
- Re: [Recentattendees] Remote Participation for IE… Melinda Shore
- Re: [Recentattendees] Remote Participation for IE… joel jaeggli
- Re: [Recentattendees] Remote Participation for IE… Melinda Shore
- Re: Remote Participation for IETF 95: Meetecho De… SM
- Re: [Recentattendees] Remote Participation for IE… Brian E Carpenter
- Re: [Recentattendees] Remote Participation for IE… joel jaeggli
- Re: [Recentattendees] Remote Participation for IE… John C Klensin
- Re: [Recentattendees] Remote Participation for IE… Rich Kulawiec
- Re: [Recentattendees] Remote Participation for IE… Tobias Gondrom
- Re: [Recentattendees] Remote Participation for IE… Alexandre Petrescu
- Re: [Recentattendees] Remote Participation for IE… Stephen Farrell
- Re: [Recentattendees] Remote Participation for IE… John C Klensin
- Re: [Recentattendees] Remote Participation for IE… Jari Arkko
- Re: [Recentattendees] Remote Participation for IE… John C Klensin
- Re: [Recentattendees] Remote Participation for IE… Stephen Farrell