Re: Remote participation fees [Re: Updating BCP 10 -- NomCom ELEGIBILITY]

John C Klensin <> Sat, 14 February 2015 23:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7ACEE1A040B for <>; Sat, 14 Feb 2015 15:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ax6P7N9-rKO3 for <>; Sat, 14 Feb 2015 15:46:01 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B63CA1A0263 for <>; Sat, 14 Feb 2015 15:46:01 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1YMmPQ-000CRY-0s; Sat, 14 Feb 2015 18:46:00 -0500
Date: Sat, 14 Feb 2015 18:45:54 -0500
From: John C Klensin <>
To: Mary Barnes <>
Subject: Re: Remote participation fees [Re: Updating BCP 10 -- NomCom ELEGIBILITY]
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc: ietf <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Feb 2015 23:46:03 -0000

--On Saturday, February 14, 2015 16:46 -0600 Mary Barnes
<> wrote:

> Rather than respond inline, I'll respond generally as I
> personally haven't gone down the road towards looking at the
> impacts
> which rightly should be considered.   I'm not saying improving
> remote participation is just a piece of cake and there
> are no barriers to doing so.  I'm just suggesting it be a
> consideration and not be tossed aside or be given
> low priority  just because some folks are concerned about the
> impact on "IETF culture" and the financial bottom line.


I completely agree with the above.  I've just been thinking a
lot about remote participation since starting to do it fairly
frequently a couple of years ago.    The thing I've been saying
all along is, I think, consistent with your comment above: I
think improved arrangements for remote participation would be
helpful to the IETF and would improve overall technical
diversity and competence as well as whatever benefits it would
have for geographical, demographic, or sociological diversity.
But I think there is a key question about whether the IETF is
really serious about such participation.  If we are, it has
implications for a lot of ways in which we measure and evaluate
participation (including, but not restricted to, Nomcom
eligibility) as well as requiring clear responsibility and
accountability for having effective tools and mechanisms and
having them work.  

This is why I disagree slightly with Stephen (and Ray): I'm
willing to pay a registration fee even before all of the tools
are completely in place because I think that collecting such a
fee represents an IETF (or at least IAOC) commitment that remote
participants are "real" and need to be supported, not just
people who are nice to have around the periphery but who don't
really count.   From my point of view, Ray's endorsing a "don't
charge until everything is working well" position is fine, but,
if we (as a community) are serious, I'd expect to see a
comprehensive plan from the IAOC about what the steps are going
to be to get to an appropriate level of service and what the
planned schedule is for those steps.  And I'd expect to see it
at the IETF 92 plenary.    

Of course, it is also possible that we are not serious yet or,
as John Levine put it, simply not trying to make it work.