RE: [Ietf108planning] Registration open for IETF 108

"STARK, BARBARA H" <bs7652@att.com> Thu, 11 June 2020 19:47 UTC

Return-Path: <bs7652@att.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 AEA343A085B for <ietf@ietfa.amsl.com>; Thu, 11 Jun 2020 12:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 g6MfO8hSNF_7 for <ietf@ietfa.amsl.com>; Thu, 11 Jun 2020 12:47:30 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F413A085A for <ietf@ietf.org>; Thu, 11 Jun 2020 12:47:30 -0700 (PDT)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 05BJgCCV017531; Thu, 11 Jun 2020 15:47:29 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 31kdxy54w5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jun 2020 15:47:29 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 05BJlSqL001092; Thu, 11 Jun 2020 15:47:28 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 05BJlNbp001007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jun 2020 15:47:23 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 3AB3E4009E84; Thu, 11 Jun 2020 19:47:23 +0000 (GMT)
Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30486.vci.att.com (Service) with ESMTPS id 250C74009E78; Thu, 11 Jun 2020 19:47:23 +0000 (GMT)
Received: from GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) by GAALPA1MSGHUBAE.ITServices.sbc.com (130.8.218.154) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 11 Jun 2020 15:47:22 -0400
Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 11 Jun 2020 15:47:21 -0400
Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.1979.003; Thu, 11 Jun 2020 15:47:21 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "'Michael Thomas'" <mike@mtcc.com>, "'ietf@ietf.org'" <ietf@ietf.org>
Subject: RE: [Ietf108planning] Registration open for IETF 108
Thread-Topic: [Ietf108planning] Registration open for IETF 108
Thread-Index: AQHWPfZuvRn57zVqgUCiElQdaHe9YKjQ8q4AgAB92YCAABYxgIAAn7eAgAAHkoCAAARDAIAAa6qAgAARCACAACR9AIAACGCAgAAZPYCAAAU6gIAAAaUAgADD0SCAAE6TgIAAAWcA//++QTA=
Date: Thu, 11 Jun 2020 19:47:21 +0000
Message-ID: <692def4a182f4bbfabcae6ef283cd79e@att.com>
References: <159166311543.4506.736406779378278905@ietfa.amsl.com> <CAFgnS4WOjmNOf_MRfms1RD0e15xYP-xcfNiyqS7p5ofYBEQPdw@mail.gmail.com> <d65a8aeffc61b6d069afa87f3c91b10496c4d5b2.camel@lsl.digital> <5FCC8656386268B41681E1DE@PSB> <B4293B17-6F83-4B9E-89BF-C0B1388F346F@cable.comcast.com> <CABmDk8=gxXiQ60hpdCNB6jK0EG_ssAQnzjgJp=c9yXNKabHKeA@mail.gmail.com> <CABmDk8mwVfWZQmBwZ9c4xaoStwv7CeRRceihTR846iq_LYPFFw@mail.gmail.com> <F6BFB099-2526-4EEB-A267-F2A1D0A7DDFB@cooperw.in> <35fb0076-a240-096a-de7f-280d5e7ad1e3@cs.tcd.ie> <2F0FDD2B-03C8-4E76-9149-A2666147C66E@csperkins.org> <27875646-243d-8d03-b588-866b883fea7c@cs.tcd.ie> <8C935847-70C8-439B-8F4C-83DB9A43E4DF@ietf.org> <46159495-3bef-be6d-31f7-1b83737359ad@gmail.com> <B6DFDB6D-7A97-4EE3-8554-6AF005C73EC3@ietf.org> <2a36750841d34cb99695077d60760ceb@att.com> <3949E994-C3BA-4392-BB1A-0D66EDE84065@vigilsec.com> <71021dea-5bf0-ac05-f9d7-cc7396540767@mtcc.com>
In-Reply-To: <71021dea-5bf0-ac05-f9d7-cc7396540767@mtcc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.74.199]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-11_20:2020-06-11, 2020-06-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 suspectscore=0 cotscore=-2147483648 mlxscore=0 priorityscore=1501 impostorscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 mlxlogscore=922 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006110151
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DmGxysQ9H60Kkllujc_ZVtnfIKY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Jun 2020 19:47:32 -0000

> On 6/11/20 12:07 PM, Russ Housley wrote:
> >
> >> On Jun 11, 2020, at 2:42 PM, STARK, BARBARA H <bs7652@att.com>
> wrote:
> >>
> >>> If the fee waiver programme were uncapped then would you still regard
> that as a bandaid?
> >>> Jay
> >> I'm going to reply at this point in the thread with some thoughts I haven't
> seen expressed yet.
> >> Much of the commentary against registration fees has come from or on
> behalf of people who struggle to pay the fees.
> >> Much of the commentary for registration fees has come from people who
> do not struggle to pay the fees.
> >>
> >> As someone who doesn't struggle to pay the fee (because my employer
> finds it a significant savings over what would have been paid), but who
> recognizes that others do struggle, what I would have preferred would be:
> >>
> >> Put a statement on the registration page:
> >>
> >> IETF needs to raise $515,145 to pay for costs that would normally have
> been covered by in-person registration fees. See
> <url mauled by email filter>  for more
> details. We request that those who are able to pay the fees do so. Any who
> are not able, please simply check the "waiver request" box. You will then be
> able to register for free. If your company would like to help sponsor our
> experiment with unlimited waivers (to enable IETF to continue allowing all to
> contribute, regardless of situation) , please contact us at <email>.
> >>
> >> And then have unlimited and automatic waiver.
> >>
> >> IETF likes to experiment. So we should experiment with a trust model.
> Trust that only those who need the waiver will request it, and see what
> happens.
> >> Barbara
> >
> > I really like this idea.
> >
> Not to be a wet blanket but what happens if corpro bean counters find out
> that they can game the system for the cost of a checkbox?
> 
> Mike

A system as large as the IETF can handle a few who do this. When large numbers do this, the trust model breaks down, and creates a dysfunctional organization/society (because trust breaks down in more than just this area). This is not new. This is all understood and well-studied by economists, psychologists, etc. But there is a real advantage to groups that *can* operate with this level of trust. The org is more efficient and effective. Such organizations are more successful.

What needs to be done is to have appropriate mitigations to limit the effects of possible failure and have policies that discourage gaming. To mitigate, it's good to make sure there are sufficient funds in the bank to cover 1 or 2 massive failures of trust. Some policies could be that there is a public list of companies who commit to not gaming the system. The names of people who register with an affiliation or email address domain of one of these companies and requests a fee waiver could be made public. With this, there would be peer pressure and public perception that would discourage gaming. 
Barbara