Re: [Ietf108planning] Registration open for IETF 108

Michael Thomas <> Thu, 11 June 2020 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D86DD3A0861 for <>; Thu, 11 Jun 2020 12:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NKALPrVttgc7 for <>; Thu, 11 Jun 2020 12:54:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC1873A0860 for <>; Thu, 11 Jun 2020 12:54:36 -0700 (PDT)
Received: by with SMTP id m7so2725383plt.5 for <>; Thu, 11 Jun 2020 12:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=SG4/VhWvGG4xzbLKWHx+adrI6U/CV02ONK0tWFNHKbM=; b=cP6uYXhuax3rUcM7ip4xUR6Xc+eK+2V4M+zHM1EHoEjFYSjVxwt3NB59YOwpzG55r5 j2VNoidwpj7jMgcx/pkgp7L2v1nA8Ke7y44tx+CKW8HeoBLyDKQKP4kVqzgdFxZ9rTWs ugBvxJY/x2Rt/H3OTGfr/0lzMQQnk8XBA+1vkPvyPU3yvEguzof7VVJ2laJERtkt1iIw Mw3xQSwjLWFo8Cuzlwwobe+LIQFXFTB1sazJYI1JrGqaf10Lxeog2d6gluzVmYwJVSvy bGQfyev2ebiAHb6ezUP9xhqPcTQwGM+vdDqALSorlPzE24LNzdPlZyf7Oy5ioRCa1X1A rwDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=SG4/VhWvGG4xzbLKWHx+adrI6U/CV02ONK0tWFNHKbM=; b=AK9aYa23osXT2py4QzXrgsfzuTvoG/xQrdxvIgg3efVGG+Pf+T33ljSWY1IJj10cC8 48iewOoVuC8gPDLSGFseRXBHJFI/2Y2XPEiIj+QEWMJzqmfSyTzGqctzgTUu3zlu9B32 0qsWWjKyot3QtoelQqO3hjvH2YWkqMlmAZ69ZDtgryU4H0LhdT1He+lMs/gtGWVH+zpE VxgYe1FJIwT5WwCqroYv1NNm1uoYGTNx6UUkdZY2tU+W8qGWyqz4yD86xIpnxIy3tPgH CghAJZtBaInncLtYW3zzao0g+HNnCjeKmbLBqNWzVvG8NSWGky+c9OkP1vIVLNiBGuVD TgWw==
X-Gm-Message-State: AOAM53375tRKFmhHLKfoFBDQGE1Sp9QiDxxijUtPFH27ybNCdhPgTPys 1U6O1yWGMPZ/Snho9lcwSDLWV+AoFU8=
X-Google-Smtp-Source: ABdhPJzzxLiY/nUa+eqdITtCPcwdTw903CKWJpOK7+MUkfT/2nmgMkZeSLK77BtZEiVnO3YlOgxxpA==
X-Received: by 2002:a17:90b:28d:: with SMTP id az13mr9924032pjb.67.1591905275444; Thu, 11 Jun 2020 12:54:35 -0700 (PDT)
Received: from MichaelsMacBook.lan ( []) by with ESMTPSA id i22sm3846430pfo.92.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2020 12:54:34 -0700 (PDT)
Subject: Re: [Ietf108planning] Registration open for IETF 108
To: "STARK, BARBARA H" <>, "''" <>
References: <> <> <> <5FCC8656386268B41681E1DE@PSB> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Thu, 11 Jun 2020 12:54:33 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jun 2020 19:54:38 -0000

On 6/11/20 12:47 PM, STARK, BARBARA H wrote:
>> On 6/11/20 12:07 PM, Russ Housley wrote:
>> 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

PHB is probably right: bureaucracy > peephole optimization.