From nobody Mon Nov 1 10:10:15 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B023A18AF; Mon, 1 Nov 2021 10:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 Ye4zNJmzuTGT; Mon, 1 Nov 2021 10:10:09 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::730]) (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 08BBE3A17D8; Mon, 1 Nov 2021 10:10:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gRnMzbGX1h+rrN/+Xj8BZZSUvk+y+9BBf1PWXla4lIOyRgZkv23oS6oe38zZ7sNcVMRhkmV7Gdn0Br7AAcnPW97dfLYaevkeMItQhA2txYAqXOGOIe7I3XB935Da6Vdf+yEkpjGpz11BIZ5/jn0jbcr7NNwacSjrr5TKCOFi4Z5giQaUteUrWob/3+C0FRskUusj8FMixtqfvoC7iynrDsovbyix5bgP/4do2P0Xg+imnX7l9WXA8GsRU/g0oxCSuu1cZFQO5HBNDOXSCUjvwAr3kHT7aKVii1FV1Oz08oGZMr6x99F4PlOz4zSpcM5vDNwh0K6G7YR/cDVUFPun7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LK+3gLK2Ak5RZ+5wZ/PW5vVk6Br53cGNWD3rVMc6XxU=; b=GJGVHtJcerEjbXkRTJoPABmJHhrcS43uwRmUrmdwAbubMAOT+t5wPqS27ERBHk+qW5MU6yctV+IWuTjmgbNxu6UN4O4iTwGxsdnmcT7vh/r/z5S7y62AauE+wOZpbvdQ9KFCEheyBFzMkfaatPpwaAaMe2ThMh9xZ8oXQcP+l6y65m3i9f5/o3ejH+ODQq90BoEG3z2TYQ5iYEilvn/SYw68DnHjNDh9WDftq4xHfjesw79orO5v+dl9HDnWBVBeocegWenysfPI6dFkfBTeGqHZqMfG2BWmlz7NlTWoEih3XBGJ0NKO7oxLGbJye38FzMb/bg0aSckXYGAr1Gmf8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LK+3gLK2Ak5RZ+5wZ/PW5vVk6Br53cGNWD3rVMc6XxU=; b=NHHp3UjvURnW5HxxrP69yEe4MZJEfRj2O3VjTEuiLvkt4ttAv/4Y4i149DY5Z62GvlFt6hVZ2uvG0POJdILhH7hJPkpWOnR0u9DQg0dEU1/2tVLqXwJuvCw/ywvaVEM6XSbrYtfvFe2VGxOqBhzVMQKcgWKQ3BIAXY12VQE273Y= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB4112.eurprd07.prod.outlook.com (2603:10a6:803:29::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.6; Mon, 1 Nov 2021 17:10:00 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::da:1b00:ebb3:ffd9]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::da:1b00:ebb3:ffd9%2]) with mapi id 15.20.4669.009; Mon, 1 Nov 2021 17:09:59 +0000 To: last-call@ietf.org References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> Cc: gendispatch@ietf.org, draft-eggert-bcp45bis@ietf.org From: tom petch Message-ID: <61801F61.60807@btconnect.com> Date: Mon, 1 Nov 2021 17:09:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <163465875866.13316.15860075014903480611@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0196.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::16) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 Received: from [192.168.1.65] (109.145.246.78) by LO2P265CA0196.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4649.18 via Frontend Transport; Mon, 1 Nov 2021 17:09:59 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: db116822-8a39-42b2-dc21-08d99d5a6fab X-MS-TrafficTypeDiagnostic: VI1PR07MB4112: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Dk2Uoe5fNDNtJTJelejkQRWrM4IM3/L8cTjcPScXFDmEgQND5T/JWyzEagJa3324REQIBtdEEavL0Lanwa7aPw9vX4Jhw7x60AqBjkP9DVZVrf6YaOrbfldmBcda50QfrHJdoK2qHQwQ5oxfZgdAUB7ZPijuCqp6q0fPVCut8XbP2cwYB0iSgzeXkBWeRqPkPnLfdFshbn5oea+q/y5tWT6ZH02Fxa5DDNfvZx4lxr85iPuUOtxY/ZViXOq6/T1XbpDDptDNnfAJd05bLEQ05x7OtVgaem7bd3AVLyxZF0I98qmL6+ZQVluObDl8LHGSCB9pkC41U9eC4FsaWPxLtgiwQYBjhnyoA1Qzrh5iuoR0sIw5refP3+9tq6PzYm7wp8ndIjQxtr+VwiHKKjw0luBda+Kr8haI14MRc8N9sGESrkNUUQR6rwvBwDSwgJ2KZgB5kyDQW9d7hUq4VdFY/vviAWlVZWfqsb1WeU1LLVNyahq1wBtANLCDyviUUUQCEoZei6Yv5lXT2RT0Vro29ly3xH0sxjPrV2BrF9PAc/AxDysvGnN2A+3NVuAc37rmw7Tv5ZjoiQz2P14gulhvTvr2yeYsehZiLXzCvqJZwL5ky1C8AOqAwdWrbAL28NoMAn5AIM0hzr+WMitEnRmZ5zxklwyeTmYdvJxdoH+j1Gb9pQ8oGzdP6uaaEbYhUg2MhIRdKTvjRtp0yoM6HyXHjPMbPq1AUIoXDKV4Qel2IjSBupFVX2koeGtfaSSpqw3iMzIfQ9hrZeBpJrWQasJcK8MeaDFZiCAc3sex8zhJoEO5q3VDGkmg1K+WyMOOASIXRlkodYt5Xuvs8Z35kNwox17JupUFLmDAbvXdmhvjTTs= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(6486002)(508600001)(66946007)(83380400001)(450100002)(66556008)(66476007)(33656002)(4326008)(66574015)(8936002)(8676002)(6666004)(186003)(956004)(36756003)(53546011)(86362001)(6916009)(2906002)(316002)(82960400001)(16576012)(52116002)(38350700002)(2616005)(26005)(966005)(5660300002)(38100700002)(4001150100001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?3kTDJvJhf+lvyBNFJHFf823JEdHJDUSoRH5oh45VmG37TdaAFsY/2wgM?= =?Windows-1252?Q?y7Jwk5ozWLoQaiSQUpkzP13L9qAQ5XRBG+A8F61PdZNx3n52zrwmd8Da?= =?Windows-1252?Q?1C6yKNMn+d9cQHhlGC9YxxmOWZxplzageW7PbBeBPOWAim/c2KYVqLOV?= =?Windows-1252?Q?wJco+lAfaPT5CxhCtJZDH5xKog2+aFZD3DnwUOgH92oh/dLrvUs0D4Ql?= =?Windows-1252?Q?K6zbJCrgZFsyjSW/vWArhsfm8t+vhQQaeMiumL9P3oSkaX83os/pHlce?= =?Windows-1252?Q?fkCL2Co4XfSMDegns2jx8zOqNku9A8m/uwHq9PqWq201l0P7U3N7tCap?= =?Windows-1252?Q?G586n5wwY4maTj66+nJA0qs9L1+yuaBL0h5POsj2pmDCD5MTdNAV/eKi?= =?Windows-1252?Q?y/3mFOFpvlqwCVJFuopyCxrmr9PUFb7IvubiuTTH3XXgQcHVFgQo4lc0?= =?Windows-1252?Q?Ya4J47LgjkCf3ETFpNknRXB3HuMLTQBy41+DVi0yU0Hep0haF228fx0c?= =?Windows-1252?Q?JjXSHJG1GvIkmYJZNYMdsfZo9gZssjRlkzKvQUHIKNdsKPHr82+CZ2sz?= =?Windows-1252?Q?MQo4WSbgRBL7I3ccFRrM4hpSJzqde2e1WbvFCIeWUe3upsr0keSdDlox?= =?Windows-1252?Q?CwiSZarH5wNQE7aqDX8BjNnsVzRrQ4I8SKu9ynkqh1UTtBjLLXO1n85u?= =?Windows-1252?Q?sY0DPceAJU43v6KX0gQGWHhQTcP4/97+mUXtuAX+3vayUBhTjxjSA7Lr?= =?Windows-1252?Q?y5jUaS3usjd6QsJ5EnCCi4Dx1LSKky+wl+B+T9JUcG0N+nAqWtG36Typ?= =?Windows-1252?Q?wbfiBPaNbBFXy1ghjtT72czZ1XFIpfW0hjorpxhhe3H7iWm8dg9eeAk3?= =?Windows-1252?Q?2PXhVZOqNndLxm+dpsq92FN9UDosO7Wa2Gi+2hcT2zrPdPildY641f38?= =?Windows-1252?Q?OM17kuQ+8JOHQ0AUeHnggyDg4ikrfpnBTeUVX5Mxes9YhQ5cyyxaaipv?= =?Windows-1252?Q?uDu7f0yyaBc8kvvXtJg+Q3HzekGsH0Q+c9Powsnta1xsGBBeSvPS+tMs?= =?Windows-1252?Q?mdkZ9a/b1vcGcDBx658BuDTP3fuQTuZFq1ElhibTTDLv0BleE1jlB5sX?= =?Windows-1252?Q?ly3G221cjgqcNdejEOliR8e2cjA+Eo9LHOJMz6QJUKqRRIFskz0oQz39?= =?Windows-1252?Q?+2Ph4WWyrExFQAtlt5JjAdnnDp0SlyDLfMTr+Hy1ii0y4cGm7omPKtU9?= =?Windows-1252?Q?U8DoR9OdAFoQz29NL+YKi0VohV/i/LbXEB2V+4dyUz2sfHt3mnKLnHFF?= =?Windows-1252?Q?hhj2y87VgFDb38acHIZ4gs+VQsehH3CHS254fv2cThbfUhn/PztlREaP?= =?Windows-1252?Q?zv8XVRMBbZR8ArhNphQ3P3M5bBUxBzT4zA4DGTwtp/t9lYrU6l9ozCRP?= =?Windows-1252?Q?lu/nYjT2oQFfFIkHW4ai4uInCFGSgMGjYgxZYllaWuAtGcCNId5Ihj0d?= =?Windows-1252?Q?KrPPUs+zcRRjVz3Cw3K/pfuaxk3XD6IF86EUGQ8T27n/nutc87B1ffXb?= =?Windows-1252?Q?W0raLHGA9Ku14jGs6JRxMfyZlR2W7L/bsUL4hVdf6SZ26U9pzmXculOr?= =?Windows-1252?Q?ToIT569vFnUbbJEavVOtfivh88+ZX+qqGn+3nNdkhWlN1Fymlj+UFqlb?= =?Windows-1252?Q?57ZRZGj639nVwi9C+1F9ugfsmGJMMPlEjDA9DdwAYAQi2x4qMdAVc0eb?= =?Windows-1252?Q?DGF7vg4PN/OZQ4JcD5A=3D?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: db116822-8a39-42b2-dc21-08d99d5a6fab X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2021 17:09:59.7529 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: U+19hL/OJPmD90zAWb4Z/juqxAgVLMqRHAeEdFyvE00OH3efenFkZBXAcZGkzT6a/b4QfIxgK+gLGJbFzl7nZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4112 Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 17:10:14 -0000 I read the Abstract and thought 'So what? This is fairly pointless.' Moving on to the Introduction, I found that it made sense, the difference being that the extra sentence in the first paragraph without which - well, seems pointless:-) I suggest that you add that sentence to the Abstract. There are several references to 'Last Calls' and while that may be the title of the web page about that list, it is not what I see anywhere else. I suggest you use 'Last Call' except where a URI requires otherwise. Tom Petch On 19/10/2021 16:52, The IESG wrote: > > The IESG has received a request from an individual submitter to consider the > following document: - 'IETF Discussion List Charter' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > The Internet Engineering Task Force (IETF) discussion mailing list > furthers the development and specification of Internet technology > through the general discussion of topics for which no dedicated > mailing lists exists. As this is the most general IETF mailing list, > considerable latitude is allowed, but there are posts and topics that > are unsuitable for this mailing list. > > This document obsoletes RFC3005. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > . > From nobody Wed Nov 3 08:37:23 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E243A08D7; Wed, 3 Nov 2021 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 QhjUzAwQm7jr; Wed, 3 Nov 2021 08:37:16 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 894473A08BD; Wed, 3 Nov 2021 08:37:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HkrVh1W17z1nv1S; Wed, 3 Nov 2021 08:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635953836; bh=jNP2A1M+5AEqThE0oLluxAXgD89rjFlHfTmpMukL5ow=; h=Date:Subject:References:To:Cc:From:In-Reply-To:From; b=Oj+fSbttUMxz6cJ84/+mcoVbYo+YBA8IMlZZLm8y4j3hBYAwo/lvOlcgx+eapuXjx 2uVJkNSuGJGUQUG9PrVlPI2qveEIjR1pktv6V0vGzUj4VZmi9qTrj9Kdt5xTnb53NO DFVcEBidT2RpozcIMFO1H+/nl8QuiEdhl5YYZHgg= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4HkrVg57Klz1ntfH; Wed, 3 Nov 2021 08:37:15 -0700 (PDT) Message-ID: <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> Date: Wed, 3 Nov 2021 11:37:13 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> Content-Language: en-US To: "gendispatch@ietf.org" Cc: gendispatch-chairs@ietf.org From: "Joel M. Halpern" In-Reply-To: <163595251682.11706.5053299985084837548@ietfa.amsl.com> X-Forwarded-Message-Id: <163595251682.11706.5053299985084837548@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 15:37:21 -0000 This is a significant revision of the draft on IETF antitrust guidelines. We tried to address what we heard in the previous feedback, and tightened the language related to legal issues. Chairs, if it is possible I would like to present this for dispatching at the upcoming session. Thank you, Joel -------- Forwarded Message -------- Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt Date: Wed, 03 Nov 2021 08:15:16 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Antitrust Guidelines for IETF Particiants Authors : Joel M. Halpern Brad Biddle Jay Daley Filename : draft-halpern-gendispatch-antitrust-01.txt Pages : 8 Date : 2021-11-03 Abstract: This document provides guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 3 11:57:44 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2283A0E26; Wed, 3 Nov 2021 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 erX0GdphC-K9; Wed, 3 Nov 2021 11:57:38 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CA63A0E23; Wed, 3 Nov 2021 11:57:38 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id e144so4076056iof.3; Wed, 03 Nov 2021 11:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kZUeaH/4F/CF64G7HX7gnD/FYAXtcsErNXNx5/jyDNU=; b=I1o9eseWF/BAtYDEN0EXkWQ/waFzy25sOcdztD8gSp1oLhktWaadbgz4Gx5VdMYEDC y6+4QpdH9UsVXgTBIjtxXNVeK2igB4ZxGrz+ZKNe9IDBpI9ts8Npl/U/zSnEUML7PS9Q 5vesHAruZwRtPJcg4j1Zr1O98wMCDEZ3r+FSngX5Jsf5JzlB5/0T6Y+QZpT7xRa5aMXD LvTrjNyWSToJaRGUrmlZRvHnP5R7zjeX4axUGN6dsK0j+UDVRuQ54r1YvSFggl2PlOCw JQpOMYJc8FB90SKenCyo/R5nCpek4b6yAeF7xwXe+Qod4RG/kO2UgVfVb0ONrTQhqLIh GOhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kZUeaH/4F/CF64G7HX7gnD/FYAXtcsErNXNx5/jyDNU=; b=Sb3VtnsflpCN2UTXYL6IM/udZG2hDprGkyhSFNckcDLJ8IbbI0/Feh49+Nj5gAUfqt ayMqAQzc5hQI9Y6wTHViarxSjU6YG3VBCnbtiiQtNONi+m320k/Y6/DDIEtbuv61l1eE WIFDy3Kh1gMI2e4Av+mZCMLHWwB2GquAIahRza4nNOrySlpmVOfuIef5RBZ2pUurJ061 9agTaGIlMalSgDu8AwnOU2OUJhhLxQ0S9yn48Q6XzB6OpQ1fz0VvI/4uI/5xnozXGoFc AljbFHYGH1W1hiyJ2DRkjcoqFknZJqCvHEBtZuzcE+hx4yA+a/wIV0IBfpnWNl/+xSoF C8hw== X-Gm-Message-State: AOAM5315QxsuLvQo0p5xAOEhbL0eO6aHi21I72Aq8D45hQObic/XLJ7A vnpUOsVaAnTbjb8lyUITW+LK2SMb8o3YJ1jR1ps= X-Google-Smtp-Source: ABdhPJyJvFI8lYmyldGf5fndixetmW12oMTutxNS/fNslNy6aPJW/hRGoL+r64FcoZznPrij1NKg+JweoIxWnNsr75E= X-Received: by 2002:a05:6638:240e:: with SMTP id z14mr202899jat.87.1635965856650; Wed, 03 Nov 2021 11:57:36 -0700 (PDT) MIME-Version: 1.0 References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> In-Reply-To: <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> From: Rob Sayre Date: Wed, 3 Nov 2021 11:57:25 -0700 Message-ID: To: "Joel M. Halpern" Cc: "gendispatch@ietf.org" , gendispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c018ae05cfe6fb0b" Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 18:57:43 -0000 --000000000000c018ae05cfe6fb0b Content-Type: text/plain; charset="UTF-8" This draft looks a lot better to me. More precise, and thus less overbroad. I am not sure about the paragraph concerning patent discussions. It comes up all the time, and there is even an IPR disclosure process in the IETF. I'm sure the authors know that, but I found the paragraph confusing for that reason. Maybe just take it out, or reference whatever document outlines IPR disclosures. thanks, Rob On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern wrote: > This is a significant revision of the draft on IETF antitrust > guidelines. We tried to address what we heard in the previous feedback, > and tightened the language related to legal issues. > > Chairs, if it is possible I would like to present this for dispatching > at the upcoming session. > > Thank you, > Joel > > > -------- Forwarded Message -------- > Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt > Date: Wed, 03 Nov 2021 08:15:16 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Antitrust Guidelines for IETF Particiants > Authors : Joel M. Halpern > Brad Biddle > Jay Daley > Filename : draft-halpern-gendispatch-antitrust-01.txt > Pages : 8 > Date : 2021-11-03 > > Abstract: > This document provides guidance for IETF participants on compliance > with antitrust laws and how to reduce antitrust risks in connection > with IETF activities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --000000000000c018ae05cfe6fb0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This draft looks a lot better to me. More precise, and thu= s less overbroad.

I am not sure about the paragraph conc= erning patent discussions. It comes up all the time, and there is even an I= PR disclosure process in the IETF. I'm sure the authors know that, but = I found the paragraph confusing for that reason. Maybe just take it out, or= reference whatever document outlines IPR disclosures.

=
thanks,
Rob


On Wed, Nov 3, 2021 at 8:37 = AM Joel M. Halpern <jmh@joelhalpe= rn.com> wrote:
This is a significant revision of the draft on IETF antitrust
guidelines.=C2=A0 We tried to address what we heard in the previous feedbac= k,
and tightened the language related to legal issues.

Chairs, if it is possible I would like to present this for dispatching
at the upcoming session.

Thank you,
Joel


-------- Forwarded Message --------
Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt
Date: Wed, 03 Nov 2021 08:15:16 -0700
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Antitrust Guidelines for IETF Particiants
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Joel M. Halpern
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Brad Biddle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jay Daley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-hal= pern-gendispatch-antitrust-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-11-03

Abstract:
=C2=A0 =C2=A0 This document provides guidance for IETF participants on comp= liance
=C2=A0 =C2=A0 with antitrust laws and how to reduce antitrust risks in conn= ection
=C2=A0 =C2=A0 with IETF activities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-halpern-gendispatch-antitrust/

There is also an HTML version available at:
https://www.ietf.org/arch= ive/id/draft-halpern-gendispatch-antitrust-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-halpern-gendispatch-antitrust-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--000000000000c018ae05cfe6fb0b-- From nobody Wed Nov 3 13:43:50 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E12D3A1136; Wed, 3 Nov 2021 13:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 POJcg8x4XSk2; Wed, 3 Nov 2021 13:43:43 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA123A1130; Wed, 3 Nov 2021 13:43:43 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id f8so3492640plo.12; Wed, 03 Nov 2021 13:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=H+QmZ+PmNaGMcu1z8T9n6dPJWyjaxJI1KZfzZkBvdQw=; b=H9TmIBXKsT9bhoryOfCXCl6tYIxbXdTft4zx81kPIWWnbzUuzFBF+srV0c9Pb8LRGP W3sePvk9Nn9RoktlekpdJpkgWuleES/dYJmwLwogHdqX//mzwIq3QuA8muMhrsG1zhIF 3BEmp6DAnw+WNy0kIsdYTM7xNJ+xJlO02j6u0xHLjTShy83TxNaYM28QELWxcc6VBHga vtIeFZ3HOtoT3uBaKXcBGXcq0udXULoMqIlV/B9B5WU2lYGxoMLFrAPtI0VKwOsuvl8e KB3mVFGdsq8aY5rStXe2f8wFvZ8uUcO1oGn0xNcrGCzgYnmc7R66R/U9Pr52TujoBLpw yeoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H+QmZ+PmNaGMcu1z8T9n6dPJWyjaxJI1KZfzZkBvdQw=; b=f0UNr9QbEV65SvJfeNtboW/VT22xpKt9HVIPRGFAqFYLevRW8OHF0DSVkrP41+H84/ 1CFDZ6hTfYmmJEkBX3vYqkXyV94gAOA2vnuJWnRk+4fi7vpicy8lnC/jIjM+wBELTVL3 U0VYj01qV2GDF9BEhNAWm0yGNPrentN8rRH7dDBfXiptHHwwXwJXX1s4Fcyf796V7Faq 8bW71gkKLgz5/OpTmCYCFLrg7Ht0IdEtu6WKDl/FWzdqCFx+zbR7eLpcP0ZpMojp8wW0 q5YP+1bN3lITFcJIqbLlxlShR8uu+iH8E0u3gDWuwyYAZXE4Le/vQQfb1ms4MaAf4js0 Plng== X-Gm-Message-State: AOAM531Pr3qTHJfap2WGYFk205OhWnpI21TE481gAK0pbctjRAEbzsh7 EPwJ4VRcyLC5ZtIOCUoVRXKJDhX4RfRC6A== X-Google-Smtp-Source: ABdhPJyk75YLpWIDAgmnjxTGhoPWrj/oTKIhYKxY2qpb7ihejuO8h8dLfuNCIzrZ5PUXfOovHOQ56A== X-Received: by 2002:a17:902:7804:b0:13e:d4c6:e701 with SMTP id p4-20020a170902780400b0013ed4c6e701mr40368616pll.66.1635972221577; Wed, 03 Nov 2021 13:43:41 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id y25sm3496768pfa.70.2021.11.03.13.43.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Nov 2021 13:43:40 -0700 (PDT) To: Rob Sayre , "Joel M. Halpern" Cc: "gendispatch@ietf.org" , gendispatch-chairs@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> From: Brian E Carpenter Message-ID: <11fade7c-24cc-4930-69b3-0e108a06029f@gmail.com> Date: Thu, 4 Nov 2021 09:43:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 20:43:48 -0000 As well as the formal rules in BCP 79 (RFC 8179) we have informational gu= idance in RFC 3669, 6701 and 6702. I'm not convinced that the capsule sum= mary in this draft is helpful, and it certainly should not trump BCP 79. Regards Brian On 04-Nov-21 07:57, Rob Sayre wrote: > This draft looks a lot better to me. More precise, and thus less overbr= oad. >=20 > I am not sure about the paragraph concerning patent discussions. It com= es up all the time, and there is even an IPR disclosure process in the IE= TF. I'm sure the authors know that, but I found the paragraph confusing f= or that reason. Maybe just take it out, or reference whatever document ou= tlines IPR disclosures. >=20 > thanks, > Rob >=20 >=20 > On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern > wrote: >=20 > This is a significant revision of the draft on IETF antitrust > guidelines.=C2=A0 We tried to address what we heard in the previous=20 feedback, > and tightened the language related to legal issues. >=20 > Chairs, if it is possible I would like to present this for dispatch= ing > at the upcoming session. >=20 > Thank you, > Joel >=20 >=20 > -------- Forwarded Message -------- > Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt > Date: Wed, 03 Nov 2021 08:15:16 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0: Antitrust Guidelines for IETF Particiants > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0: Joel M. Halpern > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brad Biddle > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jay Daley > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : = draft-halpern-gendispatch-antitrust-01.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0: 8 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 : 2021-11-03 >=20 > Abstract: > =C2=A0 =C2=A0 This document provides guidance for IETF participant= s on compliance > =C2=A0 =C2=A0 with antitrust laws and how to reduce antitrust risk= s in connection > =C2=A0 =C2=A0 with IETF activities. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrus= t/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust= -01.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antit= rust-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch >=20 >=20 From nobody Wed Nov 3 13:49:15 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71673A1161 for ; Wed, 3 Nov 2021 13:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qIlThJ04Ej7A for ; Wed, 3 Nov 2021 13:49:09 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7273A1160 for ; Wed, 3 Nov 2021 13:49:09 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id y1so3531231plk.10 for ; Wed, 03 Nov 2021 13:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=zF47G+QMDZn8ya842ZXsYZcrMAEf999DC6O3lSlIrcw=; b=Tbk3D22vTZC+1zlGdlIejGFJBLmdkD0uQrU8+BCkIHGfWjKab6B6FnWwijrABRiZ8a 1P9IK31P4RIU8hXIHj6lJ3mHA2kdH4WVCt3a3pUco2Mp8745kGXdgBp4qejT3IqCKsmM OdUfdtng48PqNNUxdKClHDDC8WUWQhaqaymg4CK0gwGdt4f9W4HAzDWFeUabzhET4SXq 82WsSlsbzKvl18bvb+Od5OZoJy3hLPWin9lFhYNJ5MnaEfAPh6AH/ORIrqhMXlVn9HaW TrPJns2jV8NeBLefJGs8BlnCJDWkJU8Q+Yc8sMH8zAmKrULwePNiiF2IFtTzwhTsumuA bxqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zF47G+QMDZn8ya842ZXsYZcrMAEf999DC6O3lSlIrcw=; b=XB64WJLBIJUfFbdAxcCkN7RJ90pUQG74TPwX4+RnDK0wR3vNsM/9eDdkWgRNinz+CW QxeMV869EtVUSF8kJIt79gUnTEMwEW33iaFgU7S2kdtQgXsQEgQaCdN9kEVz9TivmTUe zQumO7RsecQpaVbT8ahUyafPkLSzKe+QHYPLdU/iPFvs8WuVZuP3FfQxKson7qwyRHjs zNEGQq3n0PBRlAU01gO2NwCJP731+h4rDMClkDUexE3bbTzDRfrWc45rCxoSkMkAOKWr 9J0F1e+iAr/CKTCpe2OrnGErWSPVcJz0vRu3qyJdYowyspOwUKoxPXn5tZvaLNxq+107 s1NA== X-Gm-Message-State: AOAM531wgui/myBiqTOnlnPB3jMdnorAddOtBRTFUgD712tVrdygilZk TZbk3eGP4WJ06mvZLvgNBgFRi97eag9DXg== X-Google-Smtp-Source: ABdhPJzk0wZPsWmgKL7S+8lotW/DdOY9TghNelA9fFXQR0s1w++iX1Htee9CN3VgIpkq+BXIfRbYlw== X-Received: by 2002:a17:90a:9906:: with SMTP id b6mr17039868pjp.180.1635972547620; Wed, 03 Nov 2021 13:49:07 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id b10sm3390748pfl.200.2021.11.03.13.49.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Nov 2021 13:49:06 -0700 (PDT) To: gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Thu, 4 Nov 2021 09:49:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <163595251682.11706.5053299985084837548@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 20:49:14 -0000 Hi, There are two new things in this draft that seem highly problematic as written: "There should be no agreement among participants to implement or to adhere to IETF standards" That seems to forbid collaborating on open-source implementations and would seem to forbid much of what happens at the hackathon. What else are we doing there than implementing and checking adherence to standards? "No IETF participants should engage in, direct, or encourage other IETF participants to engage in, the use of IETF facilities for surveys of customers or gathering of statistical data about market requirements." That seems to forbid using IETF mailing lists for, or collaborating in any way, for surveys of deployment or requirements. Some examples: RFC6036, draft-ietf-v6ops-ipv6-deployment, and perhaps RFC7872. Taken to the extreme, it would forbid requirements surveys at the BOF stage. I'm sure it wasn't intended to forbid such work, but the language needs to be significantly clarified. Regards Brian On 04-Nov-21 04:15, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Antitrust Guidelines for IETF Particiants > Authors : Joel M. Halpern > Brad Biddle > Jay Daley > Filename : draft-halpern-gendispatch-antitrust-01.txt > Pages : 8 > Date : 2021-11-03 > > Abstract: > This document provides guidance for IETF participants on compliance > with antitrust laws and how to reduce antitrust risks in connection > with IETF activities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > . > From nobody Wed Nov 3 14:02:41 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0003A11AD for ; Wed, 3 Nov 2021 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 nlybs0LoglVs for ; Wed, 3 Nov 2021 14:02:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 6B45E3A11A6 for ; Wed, 3 Nov 2021 14:02:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Hkzk144wnz1nv0D; Wed, 3 Nov 2021 14:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635973353; bh=LNeb69x643due1KUvCfcPhvSfQmqkViAdL7OmeNBPc0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=iW8g/Se428r1BBGGPy7PpANj7YBV3/VtmOsbJaUx16MQ8Uvmc8kJsl1uLFHMmpHJh 0SbXLZkh4XEr8MVcebDRPviu/DFxGb8xlJLBcg5Xc4miYwqjH9oFmyxWbIoo2oykJD ksdfWpxmC8OzRz/aLYmj4+ClxIKGczIiCj/cwUZ8= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Hkzk06Z4bz1nv0C; Wed, 3 Nov 2021 14:02:32 -0700 (PDT) Message-ID: <99546340-15dc-cecb-9deb-b8b495644d4e@joelhalpern.com> Date: Wed, 3 Nov 2021 17:02:31 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Brian E Carpenter , Rob Sayre Cc: "gendispatch@ietf.org" References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <11fade7c-24cc-4930-69b3-0e108a06029f@gmail.com> From: Joel Halpern Direct In-Reply-To: <11fade7c-24cc-4930-69b3-0e108a06029f@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 21:02:39 -0000 Point taken. I will have to talk to my co-authors as to whether we want to completely drop that item, or reword it to say roughly "The rules for IETF Patent handling are in RFC ... Having said that, IETF participants should understand that discussions such as about the risks of litigation may also carry risks relative to antitrust." Thank you for the prompt reading. More feedback is of course welcome. Yours, Joel On 11/3/2021 4:43 PM, Brian E Carpenter wrote: > As well as the formal rules in BCP 79 (RFC 8179) we have informational > guidance in RFC 3669, 6701 and 6702. I'm not convinced that the capsule > summary in this draft is helpful, and it certainly should not trump BCP 79. > > Regards >    Brian > > On 04-Nov-21 07:57, Rob Sayre wrote: >> This draft looks a lot better to me. More precise, and thus less >> overbroad. >> >> I am not sure about the paragraph concerning patent discussions. It >> comes up all the time, and there is even an IPR disclosure process in >> the IETF. I'm sure the authors know that, but I found the paragraph >> confusing for that reason. Maybe just take it out, or reference >> whatever document outlines IPR disclosures. >> >> thanks, >> Rob >> >> >> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern > > wrote: >> >>     This is a significant revision of the draft on IETF antitrust >>     guidelines.  We tried to address what we heard in the previous > feedback, >>     and tightened the language related to legal issues. >> >>     Chairs, if it is possible I would like to present this for >> dispatching >>     at the upcoming session. >> >>     Thank you, >>     Joel >> >> >>     -------- Forwarded Message -------- >>     Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt >>     Date: Wed, 03 Nov 2021 08:15:16 -0700 >>     From: internet-drafts@ietf.org >>     Reply-To: internet-drafts@ietf.org >>     To: i-d-announce@ietf.org >> >> >>     A New Internet-Draft is available from the on-line Internet-Drafts >>     directories. >> >> >>               Title >    : Antitrust Guidelines for IETF Particiants >>               Authors >  : Joel M. Halpern >>                                 Brad Biddle >>                                 Jay Daley >>              Filename        : draft-halpern-gendispatch-antitrust-01.txt >>              Pages >  : 8 >>              Date >   : 2021-11-03 >> >>     Abstract: >>          This document provides guidance for IETF participants on >> compliance >>          with antitrust laws and how to reduce antitrust risks in >> connection >>          with IETF activities. >> >> >>     The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ >> >> >>     There is also an HTML version available at: >> >> https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html >> >> >> >>     A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 >> >> >> >> >>     Internet-Drafts are also available by anonymous FTP at: >>     ftp://ftp.ietf.org/internet-drafts/ >> >> >> >>     _______________________________________________ >>     I-D-Announce mailing list >>     I-D-Announce@ietf.org >>     https://www.ietf.org/mailman/listinfo/i-d-announce >> >>     Internet-Draft directories: http://www.ietf.org/shadow.html >> >>     or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>     --     Gendispatch mailing list >>     Gendispatch@ietf.org >>     https://www.ietf.org/mailman/listinfo/gendispatch >> >> >> > From nobody Thu Nov 4 02:33:28 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D33A0CD1; Thu, 4 Nov 2021 02:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk 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 viZ750JMgY-L; Thu, 4 Nov 2021 02:33:22 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-lo2gbr01on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe15::705]) (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 1D2AF3A0CC7; Thu, 4 Nov 2021 02:33:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TLLd8qRkSekL7QxbRekOldDoxYjDSg/3QkT3e0352cXDVprhmxxHukG7sZZZEpTAbX4Ewrq86p/ZVPUDs84A8neLJtnVF+Jn8G2Wy4/uXyu59BJm/wXjbnnGXZOSR07nqV8y4Aqg0U2JZeJ26HqyDbHEIfNEL6sJN9iOWWVFv99YqRseD46r78oh2fkLR7+V3b20JLjh9EiKnLEDgw6gOKN1u92aud0TdxZwz4yjhZimNR7svHtXbS6bB4N7CDlAPbAytVChNOMbhQRBbhCctXKbVxvo0EDiYrh8HCygrC6DHuX6PU41mDxDaqoLH1KKO/JW+fJuFwfhsB8BlR8aWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b17bhSrGotNen9zcGw0tqs4N8ki9RYoP+cPYoo5aaT4=; b=ZT0q24dJSo9C/5X8O9xws30fELFUdKJdPFlCWREE5OP6cW4zJX6Ck4Y98xVX/R2m+J//i7kbN9ZSd5nTjaP0oA/iZbwuP5oUeR2L63gEVAd26PCZKyIGkbrvGk3YSTxQAbAInivfp2O2Xti2HsR79q7GwKABUgYriSCAJGvFvxQvVc0dKFLqwSYslJ4HEY/3rnKYJFbfDIQplE/7zjWNMsyC5dxREYURYhafwfau0uJs+4jIhbZAmXpmRis5Q7l+hlNLHddj+ig46w4HuYXr5KiEDl3yYAYDVPeXgCjJhU+M3U1/vKJibrgjvo8NJYA6DiJCpvEvx5mdfQAK76TkOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b17bhSrGotNen9zcGw0tqs4N8ki9RYoP+cPYoo5aaT4=; b=A7366ax8DQgFDD3Eh8wKpWGmyMPZXhvBlCbd9tyGVWp3nM1kGL3xIJVdE73xlqg8UOPjDsmf9F2NeBxlzpGj3XVeOo3QOre4Mr/lQp8yLekJkd78yojAVnnk0uBdw9ykQ2XSR/jf59WxE+ehrAX0KWvBAqqMQzXs2p6eSck/UC0z7rtjZOO07oZymkeUW39N2u45hz4L7A/nYVKIlOIOZtExiG3FrKfQT/eu99SFXHLhBKltEFanwfsX/7N0IUDx6lgKJcsnC0xLAc1PaV4knVwbIKOVfGePxJp81EHoT4CECQKveU7O29PF1aSaWYWo7WUJSAWkRKE7OQ04+1iffQ== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO3P123MB2972.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:b1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11; Thu, 4 Nov 2021 09:33:16 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::91af:a946:6f54:775a%7]) with mapi id 15.20.4649.021; Thu, 4 Nov 2021 09:33:16 +0000 From: Kirsty P To: GENDISPATCH List CC: "gendispatch-chairs@ietf.org" Thread-Topic: IETF 112 gendispatch agenda Thread-Index: AQHX0V3P5J9FVxRgJ0CZVMjQqkplbw== Date: Thu, 4 Nov 2021 09:33:16 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: cedbce32-b9a6-6d0a-e3af-39f71b740393 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b2360d21-c6fe-4baf-f99e-08d99f76219c x-ms-traffictypediagnostic: LO3P123MB2972: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uBGAr8yiwvIxlUXhDc1aXnxvn7cqO54FtyVdJOJfgT2lS+cjjOLadcwvN21fwscXT4y/tURm0fXrGKI0xz1+xq45wEHJGmOVGD79mp9UI2NT12GC20i/zqkfuG3KrtTBzZkX/YEcY1CUdGhJ/734IbWynOEp3HJD+/WAS7eCvl2meh70bH8V6EF1KOYugiIPQOdNtYMJQecn+MegH/5F96LcrRCCwDwzVg5eeU4poTk0k+DXclK21ZHmQWnS1SuSZNltjxNFMoHltNKxr1F+u/Iblbht3Nh+zasgnUIPPjFPbd3W6UbsfVQfmKnWLYy3rXekGRugsTTPvxC+oVolN3ENVT2RpnuZurND7gqdkNlRfc2HFTo+1xIb6QSg8thZP6l4lawHeARImF0b8nWA+vSOYWH0lSi7ufPnoMT8PWR5PXQCI2csy7khavcODRW/+6v6bsi0PysVN3pRSuThqyoeOx+EBHbP+LcbCoXx1df/7iLTyeJimBxA8GU+GJ/zU0dAbUmsd1VVlHRJuSJHiV9r2j00Bv1UEMcUQ0zuqtvkjwd6r/BDnciz7Fg+++VrPKcZ7AlpJ712c5cbwf546PfIjWMPpQ+LUKocXnWoG+MRtBk+m/A+15rBkh0fZzKAhyDLyomNLit9PYsC+fWsC5eZ6mKMtYBDEro88V3Z7GpM5/Tn8Q4fGcY9ilCQyrBl9jaiojUI/dOcEA4B2lbIz+YlzsaKr4OviJg3L6DIKlSqpmVRS1/GZ4kMaxJ8F5VskNSMK6jqUbEhgqcCPG8mXtp9iw1QjI7a6EC77WyaeHQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(55016002)(33656002)(6506007)(8676002)(316002)(8936002)(38070700005)(71200400001)(122000001)(38100700002)(26005)(4744005)(4326008)(7116003)(5660300002)(7696005)(450100002)(86362001)(66946007)(66446008)(64756008)(66556008)(66476007)(19627405001)(186003)(508600001)(52536014)(966005)(2906002)(6916009)(76116006)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?RuVTsIRjwMKZ5tk/brHHskw0sCZJvB04gUgxXq9T1yuXymzyJKLn2HyhFf?= =?iso-8859-1?Q?yeAeNJMpGnJ+H9xPZw0o3IWwELfhVND0dR/8aAZkBxdh8HBnP4YxJwHCts?= =?iso-8859-1?Q?ONkEcMfGCG437IPhtB1XNxjbXCbkFZSELoI8CMPOCoJhYcYmlexURUIxnd?= =?iso-8859-1?Q?JzyMijiBVt5odsqyFKzZ04QQ76P78ZYt7JZrF+I5Y1Gw8f8/ENgtRlG52n?= =?iso-8859-1?Q?RW81ej3JuDdjU0a1l2gyZWDfle2HvwxKUcaPDQWcIfQjp2jQ6b7jz6c+xu?= =?iso-8859-1?Q?FrO3vce7bvNFy/WwmkbtS2+B21aAuqztrzXtwT2tKBYC4W+9gBIXlKF8Ns?= =?iso-8859-1?Q?JGT01EqV+hleZIbBcW1dk+dwBIWj7pmu4eArHISt4HxbEDwNxVH8kW6Bgp?= =?iso-8859-1?Q?wDU10fUBsLLdzxiMN81dDLHs2aRQ9ASQoVqcI9eyjFu83pKpJ3zunK6auw?= =?iso-8859-1?Q?k17et+DhaHtnQOZ2wv4u2RQyozqhA2BgL6a0AFPDJdrePKfU3NowFD6vSE?= =?iso-8859-1?Q?w292c0ZtAnaA2vOzQZvathwNeScEzi4hTSw+DQdIWV9BXm42KnhNZBwGEB?= =?iso-8859-1?Q?N2wiNisZivIVsQ2Nmk6hV7rWueKmlNIWDkf37con55K+LI7DRwmmKIAr+R?= =?iso-8859-1?Q?zG8JV7+oBVVWTp9AWlKgpGXy/QSaSn21LUd8ai/mPleTLRy+eE1vWedOZr?= =?iso-8859-1?Q?K9XoKn0j7GtzElz5eub6iWOdrtylQoJ9mPIJXB4+CHktYBn3hznJwWFJIn?= =?iso-8859-1?Q?y0vkkRInfUqrOTm24xBvFNJXZFM16CEzpeMznRNLWJDAhn8thtlJPdd8VZ?= =?iso-8859-1?Q?IBzFHlEJxE24VvXw36wDcnIg6BiYiMWobC38O6XNZ3fn5KWbWufULihs2l?= =?iso-8859-1?Q?mBJB3PxImuE14PPGk3uIyOrcuZ3UlFIVWG5zTRL5i+3gLTirCnPKUJgf6I?= =?iso-8859-1?Q?Hk5ct5RihdMc6dY3TeSX/p316FgyVEsmf6YTfThBDGjyQBq4Lgs/A4espV?= =?iso-8859-1?Q?5hzR9x4HnqyTKb/cox3j29tPU+3EghZ2z0T2vEjIgEi7yUNcCSLrIIeCGY?= =?iso-8859-1?Q?nGYP1MCwNS74VRyasM2+FxCM583rKZIjIw0QrcvRFLSVYi6dBMFBdRwGuh?= =?iso-8859-1?Q?nDN2vemWljkqOcMxPWM2zmz0a6Jlq7cbUeSanda1UPVKMD73SjHBXyW438?= =?iso-8859-1?Q?SaV8LmPXOItM7D8WKVqbPY/W96ZvhdWuAntJjEt+FXcOcCrv23dAwRbsF+?= =?iso-8859-1?Q?elJSrsB5MS/IWy3vQGEM4aMzhRMZFDIpurIO64BpPrMae+GsRskeu6t9Vk?= =?iso-8859-1?Q?wtYNs7bLnh9r1f7On/fAhBX426IeQ9NAUylZ8L3BCT0ZpRuowGfNqfGc8O?= =?iso-8859-1?Q?OcI7KCLlDcfRzPzYaVdbOWlxrcdCjS5gMIPDwn6USePPPg/h1+T9C9n+lg?= =?iso-8859-1?Q?R+a9q/OIwFiG7ain5QSkv2Mjd3IPZ+4piezTHlZeyutyapLwD0TJ5Atm2c?= =?iso-8859-1?Q?cpqgydaCOJ+iQnEe1VRLkWc2HVRe6iwjyfXDgU2aFUnty7dOOLERDB6s+n?= =?iso-8859-1?Q?UWxZoYJQxyCdaimo6dWRyQ1+m5E2OD+IENkb52xObPfntsJFoMPFVfgD2W?= =?iso-8859-1?Q?b41mmWEp1p0FVmD2fsJvHwVmUXaWxHegwffA2yvo0Osu9CkCSDbLtMOQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599E3964EAF2735EA43A76AD78D9LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b2360d21-c6fe-4baf-f99e-08d99f76219c X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2021 09:33:16.7602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 35UxeCtHzrbELX/kdIB+yARFfydk/ymhBOka5gdPx0cVxuit6Pkg4Bv8/Nl6YJ5zKPfF9tz4bIJo/itWPItz6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO3P123MB2972 Archived-At: Subject: [Gendispatch] IETF 112 gendispatch agenda X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 09:33:27 -0000 --_000_LO2P123MB3599E3964EAF2735EA43A76AD78D9LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi gendispatchers, With apologies for the delay (due to illness), please find our agenda uploa= ded ahead of the gendispatch meeting on Monday: https://datatracker.ietf.org/doc/agenda-112-gendispatch/ Corrections and clarifications to the chairs are welcome. You'll find slides, associated drafts, and other meeting materials at this = link: https://datatracker.ietf.org/meeting/112/session/gendispatch See you on Monday, Kirsty This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599E3964EAF2735EA43A76AD78D9LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi gendispatchers,

With apologies for the delay (due to illness), please find our agenda uploa= ded ahead of the gendispatch meeting on Monday:
https://datatracker.ietf.org/doc/agenda-112-gendispatch/
Corrections and clari= fications to the chairs are welcome. 

You'll find slides, associated drafts, and other meeting materials at this = link:
https://datatracker.ietf.org/meeting/112/session/gendispatch 

See you on Monday,

Kirsty


This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599E3964EAF2735EA43A76AD78D9LO2P123MB3599GBRP_-- From nobody Sat Nov 6 18:08:03 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876C53A0CB9 for ; Sat, 6 Nov 2021 18:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.com 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 J8wXKaXr7kQt for ; Sat, 6 Nov 2021 18:07:58 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54693A0CBA for ; Sat, 6 Nov 2021 18:07:57 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id f13so294078iov.4 for ; Sat, 06 Nov 2021 18:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/0fRdpsAM2Gy7ZuZpUfS/JM4BitLtjYar6EyJ7C5IoQ=; b=qvk3oeyCiV8xDWTKGK5O6XXhOCNbIfWhCmXUtDFluTlpKAZ8z6wL02mqcSmyR6eJ+2 NvPdBCgCl+NMt99YsiWRdIpdsUICeca9Hj3MTPdUbAmvFUYQcrNL6u39a+0Cd/wYoKKu slkuSQsgwoVw5+/HSFRXO5YRds8Ak8sXqRDOv8tue5q7S7UWn5DbYiPsQX5RX/hhvvRT i/scsFjz2V1LcNufCnWJb8/i2WebzL50slzYqyO+Y+Cx1aBQRzpklIAnDsZEPPWcNbz6 z5+aRw+bUR5E+qveSmkWI8cu1PeMDRnZiF2rH8kf+bla1wy4zYa2J6/h3tjUeQFIP2XU mQtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/0fRdpsAM2Gy7ZuZpUfS/JM4BitLtjYar6EyJ7C5IoQ=; b=Bqs9s0J/pcEhpJxHGhAJxsg7TpNaSlaaj6flQ3sNP9x+GG9DjHv84Sfju5x9gPF8rb r7Ss7Or0yIg/gmz2ND5jltr35j2tlrpJUgR0jTWaQJsQMNA7wf/BLL4O4FKEhcKvsJKv AVAbyIDseHkFYsVTYVcJqe2vSljEsC7D5WX4+5h6Jz/bcnJBenWwhajE8Z3AZTWlzTsC G1Vgcs/1r5kcMTfas/sj+vZlYT6m9QAZFC6P6O1CDLWFvqUzVB5jv6BlxNwMQsHyIFbc 46JqdDEbt9hCdCECsNnozpFt8lqAji3orLtcwPPf7qdbEKalW1ewnBtlwt8wIo28JIM8 q++A== X-Gm-Message-State: AOAM533mQORIBH5/mKRjREkf11SVU6IAFMPj/dXk3YAO4b/zlJhhioVV 6OrT6kyqibdSMvyxSva1WgJk4kaidC0eP9zhsI+LGA== X-Google-Smtp-Source: ABdhPJzBQOp4jcRXa1nOOkle+LshyTiynNjuSOoByOUwmwZuICKLZeTV7vL/Q2gTI9n9VVKza9Q4Bp4YHSIoiTddEm4= X-Received: by 2002:a5e:8c05:: with SMTP id n5mr6215089ioj.0.1636247272588; Sat, 06 Nov 2021 18:07:52 -0700 (PDT) MIME-Version: 1.0 References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> In-Reply-To: <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> From: Eric Rescorla Date: Sat, 6 Nov 2021 18:07:16 -0700 Message-ID: To: "Joel M. Halpern" Cc: "gendispatch@ietf.org" , gendispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000072983105d028819b" Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 01:08:02 -0000 --00000000000072983105d028819b Content-Type: text/plain; charset="UTF-8" Hi Joel, This paragraph stood out to me in this document. There should be no agreement among participants to implement or to adhere to IETF standards, or any discussions as to when participants will begin to offer products conforming to IETF standards. In groups I am in, WG participants pretty routinely discuss shipping timelines and often try to coordinate changes so that they happen at similar times (e.g., disabling SHA-1, rolling out new code that can interop). -Ekr On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern wrote: > This is a significant revision of the draft on IETF antitrust > guidelines. We tried to address what we heard in the previous feedback, > and tightened the language related to legal issues. > > Chairs, if it is possible I would like to present this for dispatching > at the upcoming session. > > Thank you, > Joel > > > -------- Forwarded Message -------- > Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt > Date: Wed, 03 Nov 2021 08:15:16 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Antitrust Guidelines for IETF Particiants > Authors : Joel M. Halpern > Brad Biddle > Jay Daley > Filename : draft-halpern-gendispatch-antitrust-01.txt > Pages : 8 > Date : 2021-11-03 > > Abstract: > This document provides guidance for IETF participants on compliance > with antitrust laws and how to reduce antitrust risks in connection > with IETF activities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --00000000000072983105d028819b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Joel,

This paragraph stood out to me in this= document.

=C2=A0 =C2=A0There should be no agreement among participa= nts to implement or to
=C2=A0 =C2=A0adhere to IETF standards, or any dis= cussions as to when participants
=C2=A0 =C2=A0will begin to offer produc= ts conforming to IETF standards.

In groups I am in, WG participants = pretty routinely discuss shipping
timelines and often try to coordinate = changes so that they happen
at similar times (e.g., disabling SHA-1, rol= ling out new code that
can interop).

-Ekr

On Wed, Nov 3, 2021= at 8:37 AM Joel M. Halpern <jmh@= joelhalpern.com> wrote:
This is a significant revision of the draft on IETF antitrus= t
guidelines.=C2=A0 We tried to address what we heard in the previous feedbac= k,
and tightened the language related to legal issues.

Chairs, if it is possible I would like to present this for dispatching
at the upcoming session.

Thank you,
Joel


-------- Forwarded Message --------
Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt
Date: Wed, 03 Nov 2021 08:15:16 -0700
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Antitrust Guidelines for IETF Particiants
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Joel M. Halpern
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Brad Biddle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jay Daley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-hal= pern-gendispatch-antitrust-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-11-03

Abstract:
=C2=A0 =C2=A0 This document provides guidance for IETF participants on comp= liance
=C2=A0 =C2=A0 with antitrust laws and how to reduce antitrust risks in conn= ection
=C2=A0 =C2=A0 with IETF activities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-halpern-gendispatch-antitrust/

There is also an HTML version available at:
https://www.ietf.org/arch= ive/id/draft-halpern-gendispatch-antitrust-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-halpern-gendispatch-antitrust-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--00000000000072983105d028819b-- From nobody Sat Nov 6 18:30:45 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB613A0D29 for ; Sat, 6 Nov 2021 18:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 S6EdLqlRxE6X for ; Sat, 6 Nov 2021 18:30:39 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 86A563A0D20 for ; Sat, 6 Nov 2021 18:30:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HmxWy6Kphz1nsPx; Sat, 6 Nov 2021 18:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1636248638; bh=u42nmTGXnu+fONjICLpnot5oR7QrUkABOnHO1pWsUl8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qNSXh/hyCVfCLeEnPV5rOwpOA+aGPYfVtW1DGX/tksj7VThHRdSjN8U5F/V1yzjPl ZCoV+zSht1Wx5qLgxUoiszNVwU3m7+zOB4bNlC9bXjxMZh1bgTjOK22cY2yGlb3uaE BZnLNJQCF4h5s15/0f7PuILrrlz/2OSEhfIhlHc4= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4HmxWy2P0jz1ntxD; Sat, 6 Nov 2021 18:30:38 -0700 (PDT) Message-ID: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> Date: Sat, 6 Nov 2021 21:30:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Eric Rescorla Cc: "gendispatch@ietf.org" References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 01:30:44 -0000 Finding the right balance on the wording of this issue is something I expect the discussion once dispatched will need to do. From what the lawyers tell me, I believe this kind of discussion does head towards incurring significant risks. So having guidelines that help us stay on the right side of that seems desirable to me. Yours, Joel On 11/6/2021 9:07 PM, Eric Rescorla wrote: > > Hi Joel, > > This paragraph stood out to me in this document. > >    There should be no agreement among participants to implement or to >    adhere to IETF standards, or any discussions as to when participants >    will begin to offer products conforming to IETF standards. > > In groups I am in, WG participants pretty routinely discuss shipping > timelines and often try to coordinate changes so that they happen > at similar times (e.g., disabling SHA-1, rolling out new code that > can interop). > > -Ekr > > On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern > wrote: > > This is a significant revision of the draft on IETF antitrust > guidelines.  We tried to address what we heard in the previous > feedback, > and tightened the language related to legal issues. > > Chairs, if it is possible I would like to present this for dispatching > at the upcoming session. > > Thank you, > Joel > > > -------- Forwarded Message -------- > Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt > Date: Wed, 03 Nov 2021 08:15:16 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > >          Title           : Antitrust Guidelines for IETF Particiants >          Authors         : Joel M. Halpern >                            Brad Biddle >                            Jay Daley >         Filename        : draft-halpern-gendispatch-antitrust-01.txt >         Pages           : 8 >         Date            : 2021-11-03 > > Abstract: >     This document provides guidance for IETF participants on compliance >     with antitrust laws and how to reduce antitrust risks in connection >     with IETF activities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > > From nobody Sat Nov 6 18:53:15 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1F43A045B for ; Sat, 6 Nov 2021 18:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qGYESoPqf3le for ; Sat, 6 Nov 2021 18:53:09 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145123A00B2 for ; Sat, 6 Nov 2021 18:53:09 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id f5so11752261pgc.12 for ; Sat, 06 Nov 2021 18:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=H4jUrropp+gf6XCca5J+TZ6ctECjrPH2JVmHnaeNf6w=; b=FYLRqxQgW4upiSeudqoGPB+K7S3j2pF2C69ysPfHCurNlMAx0Z2RacqWBeV264AChf sLdtvqnuGKGHC6zHN5hTNn/KlFjamVQzcpGAszJN8bmM36WYp+HcysmThaYWXcZwqcvB z3SuQqjQ4kSnozmz2xyskXk6Ws643OgAT01rpjntNKzaypgjldPE4WmtAjIjB/bHFgkd CE/SddPnJhQH9Yn48v3G5Y3WJId1/ygsZarocX7lwvlmVoizYwEF8lhUHdHm6r2YdVAx 4oZWqkM0TDnATxhTqFA3wHx95dVbJkaE19doZTtlrVEaKxpqLTOcRrOQVG2assp9lm7n OweA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H4jUrropp+gf6XCca5J+TZ6ctECjrPH2JVmHnaeNf6w=; b=xQMn0PNP8++BtsuSssf/KefO/kbVSx9RL3YxBnUdbOxJCn/1a43RFOC7TUjZi/ziQw xSlcxpm5qoOEfomysJvJtVsDUyG4OUohF+F0tjCWTvaHBNliRN9IsqkxCS/BOw7j7gvP MsPEuaBMfHdBDlsVHcklP5XCXXask2i3GtZ3NwOvkNReaWGkGe000OzA529OA1zm5Xgv YPc8u2PbyybAPCuZkBk1aEJdoYLr3cfsWnM5bC9ja3We40svJTR9XNIkfZyJwg2HdK0P lPCpkwQNw6QnJNg34TbL5Gxms1lNjQI1OAKuMUPUdXZYpyoUoJOCjPPqoZ6Q1sq02BZb r/Iw== X-Gm-Message-State: AOAM5337Rts+etOYoS2I3nynfGSodoUtLZTNgx+bFLOh/ppgVh7uYGSy OyYVuOcAR7YFnMYhBny7uyUebZeuZMIQbA== X-Google-Smtp-Source: ABdhPJxEU9A3uP1YqY+YDQdtf146YalotRHKI+SkbEDinw/vT4uVcAfgXvfzAf0+OOKZF5wzEAAHVA== X-Received: by 2002:a05:6a00:238d:b0:47c:2232:80d8 with SMTP id f13-20020a056a00238d00b0047c223280d8mr69902643pfc.12.1636249987729; Sat, 06 Nov 2021 18:53:07 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id f7sm11700723pfv.98.2021.11.06.18.53.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Nov 2021 18:53:07 -0700 (PDT) To: gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> From: Brian E Carpenter Message-ID: <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> Date: Sun, 7 Nov 2021 14:53:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 01:53:14 -0000 Joel, On 07-Nov-21 14:30, Joel M. Halpern wrote: > Finding the right balance on the wording of this issue is something I > expect the discussion once dispatched will need to do. >=20 > From what the lawyers tell me, I believe this kind of discussion does= > head towards incurring significant risks. So having guidelines that > help us stay on the right side of that seems desirable to me. Help us understand. Since the IETF's motto is rough consensus and running=20 code, and our participants are individuals not company representatives (a= nd who therefore simply *cannot* make agreements about companyy products)= , how can discussing and agreeing to implement certain features and test = interoperability *before* reaching rough consensus conceivably breach com= petition law? That the IETF is not a venue for companies to make agreements with each o= ther has been established, if not since 1986, then certainly since 1992 (= RFC1310): "Participation is by individual technical contributors, rather = than formal representatives of organizations." I do not understand why the legal advice given in 1992, 102 years after t= he USA's Sherman Act, needs revisiting. The same goes for the other new doctrine that I queried in https://mailar= chive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/ . I'm having second thoughts about whether this should be dispatched at all= =2E Since the formalisation of the standards process almost 30 years ago = was done with clear awareness of US and EU competition law, I'm far from = convinced that it's the IETF's job to give people advice in this area. Pa= rticipants who are employees should get such advice from their employers.=20 We certainly shouldn't be publishing advice that has a chilling effect on=20 rough consensus and running code. Brian >=20 > Yours, > Joel >=20 > On 11/6/2021 9:07 PM, Eric Rescorla wrote: >> >> Hi Joel, >> >> This paragraph stood out to me in this document. >> >> =C2=A0 =C2=A0There should be no agreement among participants to impl= ement or to >> =C2=A0 =C2=A0adhere to IETF standards, or any discussions as to when=20 participants >> =C2=A0 =C2=A0will begin to offer products conforming to IETF standar= ds. >> >> In groups I am in, WG participants pretty routinely discuss shipping >> timelines and often try to coordinate changes so that they happen >> at similar times (e.g., disabling SHA-1, rolling out new code that >> can interop). >> >> -Ekr >> >> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern > > wrote: >> >> This is a significant revision of the draft on IETF antitrust >> guidelines.=C2=A0 We tried to address what we heard in the previo= us >> feedback, >> and tightened the language related to legal issues. >> >> Chairs, if it is possible I would like to present this for dispat= ching >> at the upcoming session. >> >> Thank you, >> Joel >> >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt >> Date: Wed, 03 Nov 2021 08:15:16 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Draft= s >> directories. >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0: Antitrust Guidelines for IETF Particiants >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Joel M. Halpern >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brad Biddle >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jay Daley >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 = : draft-halpern-gendispatch-antitrust-01.txt >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 8 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 : 2021-11-03 >> >> Abstract: >> =C2=A0 =C2=A0 This document provides guidance for IETF participa= nts on compliance >> =C2=A0 =C2=A0 with antitrust laws and how to reduce antitrust ri= sks in connection >> =C2=A0 =C2=A0 with IETF activities. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitr= ust/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitru= st-01.html >> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-ant= itrust-01 >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> -- >> Gendispatch mailing list >> Gendispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/gendispatch >> >> >=20 From nobody Sat Nov 6 19:19:57 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851FE3A0D2A for ; Sat, 6 Nov 2021 19:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 U6tKrKCHVygF for ; Sat, 6 Nov 2021 19:19:51 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 089693A0AB9 for ; Sat, 6 Nov 2021 19:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Hmyck6TNmz1ntx5; Sat, 6 Nov 2021 19:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1636251590; bh=EAXoIEv+CS/Rf1ayAQ26a9V4thE4Ow+WRRKc3gCu5q4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=N0VaoiLyX0bu1BBxqoPypHUmnyL0LYjsovIEtKqrtVF0L3KAeovknI65IS0xOR+vv 296tt+81LsSj+pG0fKuRSyJtG/KjUbMex4s4DKvYaRIxC4YnpopVss+l/bByx3Tspg 7RnmNJGsdJlWmmenMVDphl7PXTgxC6L5dLRAS29w= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Hmyck2n0cz1nscX; Sat, 6 Nov 2021 19:19:50 -0700 (PDT) Message-ID: Date: Sat, 6 Nov 2021 22:19:49 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Brian E Carpenter , gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> From: "Joel M. Halpern" In-Reply-To: <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 02:19:56 -0000 Brian, the fact that we say people participate as individuals does not suddenly make them no longer employees of their company. And if they act in ways that are anti-competitive on behalf of those employers, it can place the IETF as a whole, and other participants in the IETF, at risk. particularly if they are from a company that is considered to have a dominant position in the market. So I am looking for the IETF to give participants advice to help avoid these risks. I do not know who wrote the advice 30 years ago, or what assumptions they made. I know that about 15 years ago our lawyer thought it would be helpful to clarify these things, but we chose not to. Put differently, if we thought there was no effect from employers on people's actions here, we would not have the rules that each company may have no more than 2 members on the nomcom. or the expectation that when there is more than one chair of a working group they will be from different companies. or that we expect that ADs in a given area will come from different companies. Or that the nomcom almost never appoints more than two ADs to the IESG from the same company. We do understand that affiliation affects thing. Yours, Joel On 11/6/2021 9:53 PM, Brian E Carpenter wrote: > Joel, > On 07-Nov-21 14:30, Joel M. Halpern wrote: >> Finding the right balance on the wording of this issue is something I >> expect the discussion once dispatched will need to do. >> >>   From what the lawyers tell me, I believe this kind of discussion does >> head towards incurring significant risks.  So having guidelines that >> help us stay on the right side of that seems desirable to me. > > Help us understand. Since the IETF's motto is rough consensus and > running code, and our participants are individuals not company > representatives (and who therefore simply *cannot* make agreements about > companyy products), how can discussing and agreeing to implement certain > features and test interoperability *before* reaching rough consensus > conceivably breach competition law? > > That the IETF is not a venue for companies to make agreements with each > other has been established, if not since 1986, then certainly since 1992 > (RFC1310): "Participation is by individual technical contributors, > rather than formal representatives of organizations." > > I do not understand why the legal advice given in 1992, 102 years after > the USA's Sherman Act, needs revisiting. > > The same goes for the other new doctrine that I queried in > https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/ > . > > I'm having second thoughts about whether this should be dispatched at > all. Since the formalisation of the standards process almost 30 years > ago was done with clear awareness of US and EU competition law, I'm far > from convinced that it's the IETF's job to give people advice in this > area. Participants who are employees should get such advice from their > employers. We certainly shouldn't be publishing advice that has a > chilling effect on rough consensus and running code. > >    Brian > >> >> Yours, >> Joel >> >> On 11/6/2021 9:07 PM, Eric Rescorla wrote: >>> >>> Hi Joel, >>> >>> This paragraph stood out to me in this document. >>> >>>      There should be no agreement among participants to implement or to >>>      adhere to IETF standards, or any discussions as to when > participants >>>      will begin to offer products conforming to IETF standards. >>> >>> In groups I am in, WG participants pretty routinely discuss shipping >>> timelines and often try to coordinate changes so that they happen >>> at similar times (e.g., disabling SHA-1, rolling out new code that >>> can interop). >>> >>> -Ekr >>> >>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern >> > wrote: >>> >>>      This is a significant revision of the draft on IETF antitrust >>>      guidelines.  We tried to address what we heard in the previous >>>      feedback, >>>      and tightened the language related to legal issues. >>> >>>      Chairs, if it is possible I would like to present this for >>> dispatching >>>      at the upcoming session. >>> >>>      Thank you, >>>      Joel >>> >>> >>>      -------- Forwarded Message -------- >>>      Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt >>>      Date: Wed, 03 Nov 2021 08:15:16 -0700 >>>      From: internet-drafts@ietf.org >>>      Reply-To: internet-drafts@ietf.org >>> >>>      To: i-d-announce@ietf.org >>> >>> >>>      A New Internet-Draft is available from the on-line Internet-Drafts >>>      directories. >>> >>> >>>                Title >    : Antitrust Guidelines for IETF Particiants >>>                Authors         : Joel M. Halpern >>>                                  Brad Biddle >>>                                  Jay Daley >>>               Filename        : >>> draft-halpern-gendispatch-antitrust-01.txt >>>               Pages           : 8 >>>               Date >   : 2021-11-03 >>> >>>      Abstract: >>>           This document provides guidance for IETF participants on >>> compliance >>>           with antitrust laws and how to reduce antitrust risks in >>> connection >>>           with IETF activities. >>> >>> >>>      The IETF datatracker status page for this draft is: >>> >>> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ >>> >>> >>>      There is also an HTML version available at: >>> >>> https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html >>> >>> >>> >>> >>> >>>      A diff from the previous version is available at: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 >>> >>> >>> >>> >>> >>>      Internet-Drafts are also available by anonymous FTP at: >>>      ftp://ftp.ietf.org/internet-drafts/ >>>      >>> >>> >>>      _______________________________________________ >>>      I-D-Announce mailing list >>>      I-D-Announce@ietf.org >>>      https://www.ietf.org/mailman/listinfo/i-d-announce >>>      >>>      Internet-Draft directories: http://www.ietf.org/shadow.html >>>      >>>      or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>      >>> >>>      -- >>>      Gendispatch mailing list >>>      Gendispatch@ietf.org >>>      https://www.ietf.org/mailman/listinfo/gendispatch >>>      >>> >> > From nobody Sat Nov 6 19:32:17 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6323A0DD5 for ; Sat, 6 Nov 2021 19:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Pyfb7oK3; dkim=pass (2048-bit key) header.d=taugh.com header.b=I+Tz70uL 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 qji40MQVb2Ah for ; Sat, 6 Nov 2021 19:32:10 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2E5B63A0DCE for ; Sat, 6 Nov 2021 19:32:09 -0700 (PDT) Received: (qmail 12373 invoked from network); 7 Nov 2021 02:32:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=3053.61873aa3.k2111; bh=Rn2L6tifDqpAqe3OsY4buxHao2/FGbSD44wdAi5Ww9I=; b=Pyfb7oK3gwvBBA15R+dtzUdiphzYJVwo3kgSaPHxQPxv3Ng7aNQBaf8H6BLSrxy8PmmClIAnVK84OKJtOrBmctOr7WqIZhnFvbPKWW7MIjEOY3ZKVyBEcJRJxL5zOrw9a6xpPj53BbpDYXuqL06g3zcy3kecgYbvyAzRrBJIJMpl4wyySYirKC9PgHOLc+MkCFILWN1oEN1gmu4Y9E0/udBAvzgD+CTIofo3UiIJXy58qWiRmDbjZ6GNpiHHIdZHvBjnL7VCtDd4uLJYgusW0tLK9LKksxcrrjCaq7zseK8GfYvIzueBYR36v2ZT7j2sEeDVmNCG/HGOqaEza+y14Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=3053.61873aa3.k2111; bh=Rn2L6tifDqpAqe3OsY4buxHao2/FGbSD44wdAi5Ww9I=; b=I+Tz70uLaRZIRa0/6YPB1TVIiLuSIU+3NWLdpYA4O6i6H2pNibgd5JEMaBCl0flrffZ/wD5P+XG6wJTM90yoaIpWMvovgT9HeMXEr/IorgDIPzod/OwmluiqJdELmxWHIzPIa+aivAjIrOFpBRj4ubP9ePEEKGNNOfYoGkekUvobe79JDZZccX51XMFbFDuSccLBiAaqo20IcaQNkbtEChFBxBuvQTk3nHNfHOoz2FSqfsUcMSvfyfRO4u4p0j3vAel4+J4eUWzsENAMqGoZI3bd4yBxa7b2d3zmZg0T/tDAUvqiVOgE2WijWBaqu84TtN/5zfCPGCZz7t+HJ7Uslw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 Nov 2021 02:32:03 -0000 Received: by ary.qy (Postfix, from userid 501) id DF2EC2FA2360; Sat, 6 Nov 2021 22:32:02 -0400 (EDT) Date: 6 Nov 2021 22:32:02 -0400 Message-Id: <20211107023202.DF2EC2FA2360@ary.qy> From: "John Levine" To: gendispatch@ietf.org In-Reply-To: <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 02:32:16 -0000 It appears that Brian E Carpenter said: >"Participation is by individual technical contributors, rather than formal representatives of organizations." > >I do not understand why the legal advice given in 1992, 102 years after the USA's Sherman Act, needs revisiting. If I work for big company A and you work for big company B and we agree at an IETF meeting to do something naughty, no court will care what it said on our badges. That was true in 1992 and it's true now. >    There should be no agreement among participants to implement or to >    adhere to IETF standards, or any discussions as to when participants >    will begin to offer products conforming to IETF standards. I think this is one of those sentences where the words mean somehing different to lawyers than they do to engineers. We have been doing interop tests and informally asking "does anyone plan to implement this" to tell whether it's worth working out the details since forever. It would be helpful to get examples of agreements that would pose a problem, e.g., are they secret? Intended to exclude others through patent shenanigans? Coordinating the timing of product releases? Something else? R's, John From nobody Sat Nov 6 19:37:23 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883A03A0DE1 for ; Sat, 6 Nov 2021 19:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UNhNU_jkmroL for ; Sat, 6 Nov 2021 19:37:16 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDDF3A0CF1 for ; Sat, 6 Nov 2021 19:37:16 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id c3so1742211iob.6 for ; Sat, 06 Nov 2021 19:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KLEEw4+cSpLByK+s9ZlY1DrtGBalWxey5smk9GOPOzM=; b=UEB7lWkgGmd5KqZIwOFWHrmz234SaqTK/SuL+jWo1j+Kd5AaeQxeSnvX4FIGnjKrH9 TTdzN1s4gip0v7b/6sUimdVSvjb2L3jWKRhs7CH4SAGggDlAcgvsg5xyNhWXUrazJf1G RmbiK1zDlpHxwF0myHt0qjqoHyc71KnNdd9c5UObvJ9ICvBSMIXji+qjmRyXHWO1nuzM +w1cUK6lf46ANywZlMZ0pkGkHnxX1ym2bFWngDKqTfzH1YI00tVaPrcvUxAMmxp3eElG EyUeNmV4HcRzF28H0l+G2QpOkxh2UjLb3hNZiLFRi9chSFnacIHE+KY6dqEL9qfnzTI1 ccYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KLEEw4+cSpLByK+s9ZlY1DrtGBalWxey5smk9GOPOzM=; b=c8t2HRGq2DCqiI3bEaJlthhBJy4Go7ETeu5vyVoEb822sZLe0krC4364rehZNXhJPR t1xgDGc3IfWRXgW0Mta3SUDySQHOT4+1uuPurrgLI2QguZl7J7VXqq8afoNgioWr8lpY HTve2lS4YvmOsEL35ZwtN1PGLjBYMO03iT5CpMnHQ2bi8dogbbKPxAZRHN35bPZOAMuu yGLRaRUcmbQso8bzgp0U+Wb8+PC7uy0UDXU3wj6cSx/aXsguiFqjqwGGTvWqEbquZQCB OHYDtq6HGBH+uM46bhZbU/t7TxsF8hXw5parwxHhD4n3p5PxKaIMaaQQ8vZfl7sbnFDZ jUAA== X-Gm-Message-State: AOAM531B/N19HwA7k4Wufquz2v0dTmiH6ul89Szx3A4e+WqwjvSc3Grj qBkngBeBc1j7HVaBcy4BLijKERmMvK1gTyqrMQeqisQuu19UGA== X-Google-Smtp-Source: ABdhPJzmhPja9Ble7rzDGEtGVRD2Kw/go6/uYbeKQOY1YG1M5o8IgHGrnWooOgMFCqNl3XSWeWDVNsYZSPBVF3gkCSI= X-Received: by 2002:a5d:9b0f:: with SMTP id y15mr6667122ion.5.1636252635299; Sat, 06 Nov 2021 19:37:15 -0700 (PDT) MIME-Version: 1.0 References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> In-Reply-To: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> From: Rob Sayre Date: Sat, 6 Nov 2021 19:37:04 -0700 Message-ID: To: "Joel M. Halpern" Cc: Eric Rescorla , "gendispatch@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001704a005d029c1ed" Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 02:37:22 -0000 --0000000000001704a005d029c1ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 6, 2021 at 6:30 PM Joel M. Halpern wrote: > Finding the right balance on the wording of this issue is something I > expect the discussion once dispatched will need to do. > > From what the lawyers tell me, I believe this kind of discussion does > head towards incurring significant risks. So having guidelines that > help us stay on the right side of that seems desirable to me. Not convinced this paragraph should be included, but I=E2=80=99d add that i= t would also seem to apply to arguments arguing for continuing to define extensions for older protocol versions (e.g. HTTP/1.1 or TLS 1.2) thanks, Rob > > Yours, > Joel > > On 11/6/2021 9:07 PM, Eric Rescorla wrote: > > > > Hi Joel, > > > > This paragraph stood out to me in this document. > > > > There should be no agreement among participants to implement or to > > adhere to IETF standards, or any discussions as to when participant= s > > will begin to offer products conforming to IETF standards. > > > > In groups I am in, WG participants pretty routinely discuss shipping > > timelines and often try to coordinate changes so that they happen > > at similar times (e.g., disabling SHA-1, rolling out new code that > > can interop). > > > > -Ekr > > > > On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern > > wrote: > > > > This is a significant revision of the draft on IETF antitrust > > guidelines. We tried to address what we heard in the previous > > feedback, > > and tightened the language related to legal issues. > > > > Chairs, if it is possible I would like to present this for > dispatching > > at the upcoming session. > > > > Thank you, > > Joel > > > > > > -------- Forwarded Message -------- > > Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt > > Date: Wed, 03 Nov 2021 08:15:16 -0700 > > From: internet-drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Antitrust Guidelines for IETF Partician= ts > > Authors : Joel M. Halpern > > Brad Biddle > > Jay Daley > > Filename : draft-halpern-gendispatch-antitrust-01.t= xt > > Pages : 8 > > Date : 2021-11-03 > > > > Abstract: > > This document provides guidance for IETF participants on > compliance > > with antitrust laws and how to reduce antitrust risks in > connection > > with IETF activities. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ < > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/> > > > > There is also an HTML version available at: > > > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.ht= ml > > < > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.ht= ml > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitrust-0= 1 > > < > https://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitrust-0= 1> > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > -- > > Gendispatch mailing list > > Gendispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/gendispatch > > > > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --0000000000001704a005d029c1ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 6, 2021 at 6:30 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Finding the right balance on the wording of= this issue is something I
expect the discussion once dispatched will need to do.

=C2=A0From what the lawyers tell me, I believe this kind of discussion does=
head towards incurring significant risks.=C2=A0 So having guidelines that <= br> help us stay on the right side of that seems desirable to me.
<= div dir=3D"auto">
Not convinced this paragraph s= hould be included, but I=E2=80=99d add that it would also seem to apply to = arguments arguing for continuing to define extensions for older protocol ve= rsions (e.g. HTTP/1.1 or TLS 1.2)

thanks,
Rob





Yours,
Joel

On 11/6/2021 9:07 PM, Eric Rescorla wrote:
>
> Hi Joel,
>
> This paragraph stood out to me in this document.
>
>=C2=A0 =C2=A0 =C2=A0There should be no agreement among participants to = implement or to
>=C2=A0 =C2=A0 =C2=A0adhere to IETF standards, or any discussions as to = when participants
>=C2=A0 =C2=A0 =C2=A0will begin to offer products conforming to IETF sta= ndards.
>
> In groups I am in, WG participants pretty routinely discuss shipping > timelines and often try to coordinate changes so that they happen
> at similar times (e.g., disabling SHA-1, rolling out new code that
> can interop).
>
> -Ekr
>
> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jm= h@joelhalpern.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0This is a significant revision of the draft on IETF= antitrust
>=C2=A0 =C2=A0 =C2=A0guidelines.=C2=A0 We tried to address what we heard= in the previous
>=C2=A0 =C2=A0 =C2=A0feedback,
>=C2=A0 =C2=A0 =C2=A0and tightened the language related to legal issues.=
>
>=C2=A0 =C2=A0 =C2=A0Chairs, if it is possible I would like to present t= his for dispatching
>=C2=A0 =C2=A0 =C2=A0at the upcoming session.
>
>=C2=A0 =C2=A0 =C2=A0Thank you,
>=C2=A0 =C2=A0 =C2=A0Joel
>
>
>=C2=A0 =C2=A0 =C2=A0-------- Forwarded Message --------
>=C2=A0 =C2=A0 =C2=A0Subject: I-D Action: draft-halpern-gendispatch-anti= trust-01.txt
>=C2=A0 =C2=A0 =C2=A0Date: Wed, 03 Nov 2021 08:15:16 -0700
>=C2=A0 =C2=A0 =C2=A0From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>= ;
>=C2=A0 =C2=A0 =C2=A0Reply-To: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>=C2=A0 =C2=A0 =C2=A0To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>
>
>=C2=A0 =C2=A0 =C2=A0A New Internet-Draft is available from the on-line = Internet-Drafts
>=C2=A0 =C2=A0 =C2=A0directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Antitrust Guidelines for IETF Particiants<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joel M. Halpern
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brad Biddle
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jay Daley
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 = =C2=A0 =C2=A0 : draft-halpern-gendispatch-antitrust-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : 2021-11-03
>
>=C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This document provides guidance for = IETF participants on compliance
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with antitrust laws and how to reduc= e antitrust risks in connection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with IETF activities.
>
>
>=C2=A0 =C2=A0 =C2=A0The IETF datatracker status page for this draft is:=
>=C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ <https://datatracker.ietf.org/doc/dr= aft-halpern-gendispatch-antitrust/>
>
>=C2=A0 =C2=A0 =C2=A0There is also an HTML version available at:
>=C2=A0 =C2=A0 =C2=A0h= ttps://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html<= /a>
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.h= tml>
>
>=C2=A0 =C2=A0 =C2=A0A diff from the previous version is available at: >=C2=A0 =C2=A0 =C2=A0ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitrust-01
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitrust-0= 1>
>
>
>=C2=A0 =C2=A0 =C2=A0Internet-Drafts are also available by anonymous FTP= at:
>=C2=A0 =C2=A0 =C2=A0ftp://ftp.ietf.org/internet-drafts/ >=C2=A0 =C2=A0 =C2=A0<ftp://ftp.ietf.org/internet-drafts/>
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0I-D-Announce mailing list
>=C2=A0 =C2=A0 =C2=A0I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailm= an/listinfo/i-d-announce
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/m= ailman/listinfo/i-d-announce>
>=C2=A0 =C2=A0 =C2=A0Internet-Draft directories: http://www.ietf.o= rg/shadow.html
>=C2=A0 =C2=A0 =C2=A0<http://www.ietf.org/shadow.html> >=C2=A0 =C2=A0 =C2=A0or ftp://ftp.ietf.org/ietf/1shadow-= sites.txt
>=C2=A0 =C2=A0 =C2=A0<ftp://ftp.ietf.org/ietf/1shadow= -sites.txt>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Gendispatch mailing list
>=C2=A0 =C2=A0 =C2=A0Gendispatch@ietf.org <mailto:Gendispatch@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailma= n/listinfo/gendispatch
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/ma= ilman/listinfo/gendispatch>
>

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--0000000000001704a005d029c1ed-- From nobody Sat Nov 6 20:48:49 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E413A0E99 for ; Sat, 6 Nov 2021 20:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BhswG000CFTG for ; Sat, 6 Nov 2021 20:48:42 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A265B3A0E9E for ; Sat, 6 Nov 2021 20:48:42 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id x131so7543479pfc.12 for ; Sat, 06 Nov 2021 20:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1FEwSzaPwVxEcG5QQf0iNOWFPDF2cBJiD8HfV4pysR8=; b=UI2D8JF1+S5TRzO9AwLtts8AQhB5qrw08SR8VcbfBg0qDNopVu8qzAFgaDduHy7lFE bEta0p//hVzk0d0RYX16gcfWmFZqFTSblqAOpSYhiNieq4OU15IagrFpGWOf+OXjmV4u beqfjUY0VTBuVzctldCUSc/ESboFo0GbnyDQ4+ZGtZqB5HHnoE2ynPZLisNb0BK3bjQT vuKt2tF+5yy1HKCWeOiePggsYX3snUeKjoGVOJMINgoikbBFw5bQie87F29Nuj9bJYn6 ouRo5C1H40LrvIUS3fvmghnC4Xv62qxmVRtqI+qHwSIHeU9VCbBb+XWhgPySE9RXwRmC AK1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1FEwSzaPwVxEcG5QQf0iNOWFPDF2cBJiD8HfV4pysR8=; b=kIAHr4bZpDJlidH0NDCKy19RxPpHsGAOLrpGO/sbxo2RBlTtjFm590fQH1FSwSUi7n f2nXUpYY+LYLiRkHVvU0ZuCohGdsAjoZh8eKoiGhxS5K7L94ZXzMQr4IwBSJW0rMp/9x mPigggFZYfzYSl/UdRXFuj6CbCdAdPxZjjWKzTigG/f4Jx8oqwxPVBELNVODtHFnX6AC HQ4Tyo2NEqcJmz+kbGcOSkgkJ8WJGprDQeCc/0PNnmG4FpiUMGyF9dEo7rMXpSuFE9GY h5LGiREZiOWrjNc8mpv0OMaJjZe6nWZG3sv99Ma3agdLpM7oJZm+pNf/y5KdJ9evtIV8 B20Q== X-Gm-Message-State: AOAM533pGiMDUEo+9a4RqzxoPxt8judzkct41tiQrS1nxbWom2eUBfJp rwzfS+t3srrUQNzzDHOdaRsrKolUvO0QBg== X-Google-Smtp-Source: ABdhPJw9NS8payhBy0iEldlYWzkigoEqpPH8vP5+na9AO3Ql7M/SS2T0WP4fLVo1IlRyRamKGAyzHw== X-Received: by 2002:a05:6a00:2181:b0:44c:f4bc:2f74 with SMTP id h1-20020a056a00218100b0044cf4bc2f74mr70268209pfi.68.1636256920916; Sat, 06 Nov 2021 20:48:40 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 8sm12717719pjt.46.2021.11.06.20.48.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Nov 2021 20:48:40 -0700 (PDT) To: "Joel M. Halpern" , gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> From: Brian E Carpenter Message-ID: <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> Date: Sun, 7 Nov 2021 16:48:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 03:48:48 -0000 On 07-Nov-21 15:19, Joel M. Halpern wrote: > Brian, the fact that we say people participate as individuals does not > suddenly make them no longer employees of their company. And if they > act in ways that are anti-competitive on behalf of those employers,=20 That is why our rules say what they say. The draft IMHO confuses the issu= e. It talks about how participants might infringe competition law *if* they break the IETF rules by not acting as individual contributors. Introduction, sentence 1, says "Standards development frequently requires= collaboration between competitors." That's simply not what the IETF does.= It would apply to SDOs that are membership organisations whose members are competing companies. On reflection, the whole document is written fro= m the wrong premise. Section 5 starts "As the IETF is a standards development environment wher= e representatives from competitors are highly likely to be present..." Wrong. By definition, there are *no* representatatives present. [I believe the original legal advice came at least partly from Geoff Stew= art, and the IBM corporate standards people, who knew a lot about antitrust because of the big antitrust suits against IBM, were also giving advice in those days.] I think the whole draft needs a rewrite on the basis that anyone who acts for their employer in an IETF forum is in breach of the IETF's rules= =2E That should be the starting point, not the two sentences quoted above. I do agree that WG Chairs and ADs should be advised to shut down any such= behaviour. And a description of what might be incorrect behaviour is useful. But the original sin here is acting as a company rep, in direct violation of RFC 2026 and its predecessors. Regards Brian > it > can place the IETF as a whole, and other participants in the IETF, at > risk. particularly if they are from a company that is considered to > have a dominant position in the market. >=20 > So I am looking for the IETF to give participants advice to help avoid > these risks. I do not know who wrote the advice 30 years ago, or what > assumptions they made. > I know that about 15 years ago our lawyer > thought it would be helpful to clarify these things, but we chose not t= o. >=20 > Put differently, if we thought there was no effect from employers on > people's actions here, we would not have the rules that each company ma= y > have no more than 2 members on the nomcom. or the expectation that whe= n > there is more than one chair of a working group they will be from > different companies. or that we expect that ADs in a given area will > come from different companies. Or that the nomcom almost never appoint= s > more than two ADs to the IESG from the same company. We do understand= > that affiliation affects thing. >=20 > Yours, > Joel >=20 > On 11/6/2021 9:53 PM, Brian E Carpenter wrote: >> Joel, >> On 07-Nov-21 14:30, Joel M. Halpern wrote: >>> Finding the right balance on the wording of this issue is something I= >>> expect the discussion once dispatched will need to do. >>> >>> =C2=A0 From what the lawyers tell me, I believe this kind of discuss= ion does >>> head towards incurring significant risks.=C2=A0 So having guidelines = that >>> help us stay on the right side of that seems desirable to me. >> >> Help us understand. Since the IETF's motto is rough consensus and >> running code, and our participants are individuals not company >> representatives (and who therefore simply *cannot* make agreements abo= ut >> companyy products), how can discussing and agreeing to implement certa= in >> features and test interoperability *before* reaching rough consensus >> conceivably breach competition law? >> >> That the IETF is not a venue for companies to make agreements with eac= h >> other has been established, if not since 1986, then certainly since 19= 92 >> (RFC1310): "Participation is by individual technical contributors, >> rather than formal representatives of organizations." >> >> I do not understand why the legal advice given in 1992, 102 years afte= r >> the USA's Sherman Act, needs revisiting. >> >> The same goes for the other new doctrine that I queried in >> https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHph= dYJZYAw/ >> . >> >> I'm having second thoughts about whether this should be dispatched at >> all. Since the formalisation of the standards process almost 30 years >> ago was done with clear awareness of US and EU competition law, I'm fa= r >> from convinced that it's the IETF's job to give people advice in this >> area. Participants who are employees should get such advice from their= >> employers. We certainly shouldn't be publishing advice that has a >> chilling effect on rough consensus and running code. >> >> =C2=A0=C2=A0 Brian >> >>> >>> Yours, >>> Joel >>> >>> On 11/6/2021 9:07 PM, Eric Rescorla wrote: >>>> >>>> Hi Joel, >>>> >>>> This paragraph stood out to me in this document. >>>> >>>> =C2=A0 =C2=A0 =C2=A0There should be no agreement among participants=20 to implement or to >>>> =C2=A0 =C2=A0 =C2=A0adhere to IETF standards, or any discussions as=20 to when >> participants >>>> =C2=A0 =C2=A0 =C2=A0will begin to offer products conforming to IETF=20 standards. >>>> >>>> In groups I am in, WG participants pretty routinely discuss shipping= >>>> timelines and often try to coordinate changes so that they happen >>>> at similar times (e.g., disabling SHA-1, rolling out new code that >>>> can interop). >>>> >>>> -Ekr >>>> >>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern >>> > wrote: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 This is a significant revision of the draf= t on IETF antitrust >>>> =C2=A0=C2=A0=C2=A0=C2=A0 guidelines.=C2=A0 We tried to address what=20 we heard in the previous >>>> =C2=A0=C2=A0=C2=A0=C2=A0 feedback, >>>> =C2=A0=C2=A0=C2=A0=C2=A0 and tightened the language related to lega= l issues. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Chairs, if it is possible I would like to = present this for >>>> dispatching >>>> =C2=A0=C2=A0=C2=A0=C2=A0 at the upcoming session. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Thank you, >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Joel >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 -------- Forwarded Message -------- >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Subject: I-D Action: draft-halpern-gendisp= atch-antitrust-01.txt >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Date: Wed, 03 Nov 2021 08:15:16 -0700 >>>> =C2=A0=C2=A0=C2=A0=C2=A0 From: internet-drafts@ietf.org >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Reply-To: internet-drafts@ietf.org >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 To: i-d-announce@ietf.org >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 A New Internet-Draft is available from the=20 on-line Internet-Drafts >>>> =C2=A0=C2=A0=C2=A0=C2=A0 directories. >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ti= tle >> =C2=A0 =C2=A0: Antitrust Guidelines for IETF Particiants >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Au= thors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joel M. Halpern >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brad Biddle >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jay Daley >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename= =C2=A0 =C2=A0 =C2=A0 =C2=A0 : >>>> draft-halpern-gendispatch-antitrust-01.txt >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 8 >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date >> =C2=A0 : 2021-11-03 >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Abstract: >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 This document provides=20 guidance for IETF participants on >>>> compliance >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 with antitrust laws an= d how to reduce antitrust risks in >>>> connection >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 with IETF activities. >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 The IETF datatracker status page for this = draft is: >>>> =20 >>>> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust= / >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 There is also an HTML version available at= : >>>> =20 >>>> https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-= 01.html >>>> >>>> =20 >>>> >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 A diff from the previous version is availa= ble at: >>>> =20 >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitr= ust-01 >>>> =20 >>>> >>>> >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Internet-Drafts are also available by anon= ymous FTP at: >>>> =C2=A0=C2=A0=C2=A0=C2=A0 ftp://ftp.ietf.org/internet-drafts/ >>>> =C2=A0=C2=A0=C2=A0=C2=A0 >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 __________________________________________= _____ >>>> =C2=A0=C2=A0=C2=A0=C2=A0 I-D-Announce mailing list >>>> =C2=A0=C2=A0=C2=A0=C2=A0 I-D-Announce@ietf.org >>>> =C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/i-d-= announce >>>> =C2=A0=C2=A0=C2=A0=C2=A0 >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Internet-Draft directories: http://www.iet= f.org/shadow.html >>>> =C2=A0=C2=A0=C2=A0=C2=A0 >>>> =C2=A0=C2=A0=C2=A0=C2=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.t= xt >>>> =C2=A0=C2=A0=C2=A0=C2=A0 >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 -- >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Gendispatch mailing list >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Gendispatch@ietf.org >>>> =C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/gend= ispatch >>>> =C2=A0=C2=A0=C2=A0=C2=A0 >>>> >>> >> From nobody Sun Nov 7 08:23:14 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BEE3A0773 for ; Sun, 7 Nov 2021 08:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 q5lSSHmzbqmg for ; Sun, 7 Nov 2021 08:23:07 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 0B1153A0762 for ; Sun, 7 Nov 2021 08:23:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HnKKk6dLcz1nspr; Sun, 7 Nov 2021 08:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1636302186; bh=wruT/haLgm1SB6CAWL6gnys6Y0ilqKC6vCZTWo+1WiE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=KYEEf5NHpvxDX1izX4U8x6hAoY6yi/XTVIjTfS/C6h0mmFRrEGqB/nofPgErTAmEq Ut0D1fAyPcJG1+87A8CuWp3NVGHaK1RxHM2l6oCGwgnyHkjIHkfFLE6rTcEUzvVedj g39SX8tVv77j6+rMJ56zJ4n6xmI28YfPaHzDO4tw= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4HnKKk2w10z1nsTj; Sun, 7 Nov 2021 08:23:06 -0800 (PST) Message-ID: Date: Sun, 7 Nov 2021 11:23:05 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Brian E Carpenter , gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> From: "Joel M. Halpern" In-Reply-To: <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 16:23:12 -0000 Folks can act both as individuals and employees at the same time. Even in the same action. The point of these guidelines is to provide advice to participants about things which, if they do them, could create risk for them, their fellow participants, and the IETF as a whole. As far as I can tell, none of the policies you consider sufficient are clear about any of these behaviors. (That is why as part of our revision we went through and made sure we were not getting into general behavior, but only giving guidance on things related to antitrust.) I am not expecting rigid rules. I don't think the community would want that. I doubt they would serve us well. And legal matters are always nuanced. Separately, I have many times watched competitors compromise. While it is always couched as :I can't live with that", it is clearly often driven by product, plans, etc. EKR even pointed to folks negotiating when an interop test would make sense, and what features should be tested. This is driven by a lot more folks than the individuals in the room. The example of folks speaking in ways that are grounded in their employer are myriad. Most of them are fine, even though one could argue that they contravene the letter of the policy. The guidelines are to point out when it is not fine. It sure seems to me we need a venue to work out what we as a community can live with. I would not be surprised if we discover that there are one or two things we do routinely that are actually bad ideas from an antitrust perspective. We will then have to decide what we as a community want to recommend (not require) about that. It was suggested at one point that the Note Well advice could be just "obey the law". My problem with that is that it does not give people any advice about widely agreed pitfalls that should be avoided. Yours, Joel On 11/6/2021 11:48 PM, Brian E Carpenter wrote: > On 07-Nov-21 15:19, Joel M. Halpern wrote: >> Brian, the fact that we say people participate as individuals does not >> suddenly make them no longer employees of their company.  And if they >> act in ways that are anti-competitive on behalf of those employers, > > That is why our rules say what they say. The draft IMHO confuses the issue. > It talks about how participants might infringe competition law *if* they > break the IETF rules by not acting as individual contributors. > > Introduction, sentence 1, says "Standards development frequently requires > collaboration between competitors." That's simply not what the IETF does. > It would apply to SDOs that are membership organisations whose members > are competing companies. On reflection, the whole document is written from > the wrong premise. > > Section 5 starts "As the IETF is a standards development environment where > representatives from competitors are highly likely to be present..." > Wrong. By definition, there are *no* representatatives present. > > [I believe the original legal advice came at least partly from Geoff > Stewart, > and the IBM corporate standards people, who knew a lot about antitrust > because of the big antitrust suits against IBM, were also giving advice > in those days.] > > I think the whole draft needs a rewrite on the basis that anyone who > acts for their employer in an IETF forum is in breach of the IETF's rules. > That should be the starting point, not the two sentences quoted above. > > I do agree that WG Chairs and ADs should be advised to shut down any such > behaviour. And a description of what might be incorrect behaviour is > useful. But the original sin here is acting as a company rep, in direct > violation of RFC 2026 and its predecessors. > > Regards >     Brian > >> it >> can place the IETF as a whole, and other participants in the IETF, at >> risk.  particularly if they are from a company that is considered to >> have a dominant position in the market. >> >> So I am looking for the IETF to give participants advice to help avoid >> these risks.  I do not know who wrote the advice 30 years ago, or what >> assumptions they made. > > >> I know that about 15 years ago our lawyer >> thought it would be helpful to clarify these things, but we chose not to. >> >> Put differently, if we thought there was no effect from employers on >> people's actions here, we would not have the rules that each company may >> have no more than 2 members on the nomcom.  or the expectation that when >> there is more than one chair of a working group they will be from >> different companies.  or that we expect that ADs in a given area will >> come from different companies.  Or that the nomcom almost never appoints >> more than two ADs to the IESG from the same company.   We do understand >> that affiliation affects thing. >> >> Yours, >> Joel >> >> On 11/6/2021 9:53 PM, Brian E Carpenter wrote: >>> Joel, >>> On 07-Nov-21 14:30, Joel M. Halpern wrote: >>>> Finding the right balance on the wording of this issue is something I >>>> expect the discussion once dispatched will need to do. >>>> >>>>    From what the lawyers tell me, I believe this kind of discussion >>>> does >>>> head towards incurring significant risks.  So having guidelines that >>>> help us stay on the right side of that seems desirable to me. >>> >>> Help us understand. Since the IETF's motto is rough consensus and >>> running code, and our participants are individuals not company >>> representatives (and who therefore simply *cannot* make agreements about >>> companyy products), how can discussing and agreeing to implement certain >>> features and test interoperability *before* reaching rough consensus >>> conceivably breach competition law? >>> >>> That the IETF is not a venue for companies to make agreements with each >>> other has been established, if not since 1986, then certainly since 1992 >>> (RFC1310): "Participation is by individual technical contributors, >>> rather than formal representatives of organizations." >>> >>> I do not understand why the legal advice given in 1992, 102 years after >>> the USA's Sherman Act, needs revisiting. >>> >>> The same goes for the other new doctrine that I queried in >>> https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/ >>> >>> . >>> >>> I'm having second thoughts about whether this should be dispatched at >>> all. Since the formalisation of the standards process almost 30 years >>> ago was done with clear awareness of US and EU competition law, I'm far >>> from convinced that it's the IETF's job to give people advice in this >>> area. Participants who are employees should get such advice from their >>> employers. We certainly shouldn't be publishing advice that has a >>> chilling effect on rough consensus and running code. >>> >>>      Brian >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/6/2021 9:07 PM, Eric Rescorla wrote: >>>>> >>>>> Hi Joel, >>>>> >>>>> This paragraph stood out to me in this document. >>>>> >>>>>       There should be no agreement among participants > to implement or to >>>>>       adhere to IETF standards, or any discussions as > to when >>> participants >>>>>       will begin to offer products conforming to IETF > standards. >>>>> >>>>> In groups I am in, WG participants pretty routinely discuss shipping >>>>> timelines and often try to coordinate changes so that they happen >>>>> at similar times (e.g., disabling SHA-1, rolling out new code that >>>>> can interop). >>>>> >>>>> -Ekr >>>>> >>>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern >>>> > wrote: >>>>> >>>>>       This is a significant revision of the draft on IETF antitrust >>>>>       guidelines.  We tried to address what > we heard in the previous >>>>>       feedback, >>>>>       and tightened the language related to legal issues. >>>>> >>>>>       Chairs, if it is possible I would like to present this for >>>>> dispatching >>>>>       at the upcoming session. >>>>> >>>>>       Thank you, >>>>>       Joel >>>>> >>>>> >>>>>       -------- Forwarded Message -------- >>>>>       Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt >>>>>       Date: Wed, 03 Nov 2021 08:15:16 -0700 >>>>>       From: internet-drafts@ietf.org >>>>>       Reply-To: internet-drafts@ietf.org >>>>> >>>>>       To: i-d-announce@ietf.org >>>>> >>>>> >>>>>       A New Internet-Draft is available from the > on-line Internet-Drafts >>>>>       directories. >>>>> >>>>> >>>>>                 Title >>>      : Antitrust Guidelines for IETF Particiants >>>>>                 Authors         : Joel M. Halpern >>>>>                                   Brad Biddle >>>>>                                   Jay Daley >>>>>                Filename        : >>>>> draft-halpern-gendispatch-antitrust-01.txt >>>>>                Pages           : 8 >>>>>                Date >>>     : 2021-11-03 >>>>> >>>>>       Abstract: >>>>>            This document provides > guidance for IETF participants on >>>>> compliance >>>>>            with antitrust laws and how to reduce antitrust risks in >>>>> connection >>>>>            with IETF activities. >>>>> >>>>> >>>>>       The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ >>>>> >>>>> >>>>> >>>>>       There is also an HTML version available at: >>>>> https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>       A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>       Internet-Drafts are also available by anonymous FTP at: >>>>>       ftp://ftp.ietf.org/internet-drafts/ >>>>>       >>>>> >>>>> >>>>>       _______________________________________________ >>>>>       I-D-Announce mailing list >>>>>       I-D-Announce@ietf.org >>>>>       https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>       >>>>>       Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>       >>>>>       or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>       >>>>> >>>>>       -- >>>>>       Gendispatch mailing list >>>>>       Gendispatch@ietf.org >>>>>       https://www.ietf.org/mailman/listinfo/gendispatch >>>>>       >>>>> >>>> >>> > From nobody Sun Nov 7 11:14:21 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF933A11F6 for ; Sun, 7 Nov 2021 11:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IH8XcfbLCDr0 for ; Sun, 7 Nov 2021 11:14:15 -0800 (PST) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D978B3A11F0 for ; Sun, 7 Nov 2021 11:14:14 -0800 (PST) Received: by mail-yb1-f174.google.com with SMTP id j75so37860453ybj.6 for ; Sun, 07 Nov 2021 11:14:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dPUC97n89N9JBzu3z9bYAWHHbelGFatRbf1DaxHjv/k=; b=oFMSh+DODnA/SfxJwXgypS2g6pEapDakpl4vnwOesHVy/OtwK2BILp6WJ4fqXfrRYo MZFFDKAixVPtXOxvIi6YJ8UaxjIfIjOYLEmSOFtoZ1qYFG6C6Gcqa44/EyyQEHFN3jBN +0YtJDAET8IArHnofK09bmIy61rX5sXfiUSbbTRqAvYSnt3O0Dc0lUZ3noEfteT9+bn3 ppdtLWeCSfvD8Ggpw8lVfCtHDAWclN6o64F6pIfsYyrT50/NnuYmJbS4bpFHYwm3PRG6 JzvM0uqkWCqI83FXEIi48Mfz86u8tG913n0zUaiLrTbYy+yZ3wZhux3eQ92WbQYf0JJh YyXw== X-Gm-Message-State: AOAM531Agtrwft/IjwQV2T8fOjtxIS4fmIKPqCF67yIe6RvGTQfodHzW kdkngdqV7zQZRZdtm2kQr3URgqtc8cNegpbuSww= X-Google-Smtp-Source: ABdhPJzPvk5witBGroRKH0aZkkG8dxAh264dw6NyenFZHEqmIPvrqU56oxadfBD8ltOCLjY5YbcZ2zgqCE+4CPn+958= X-Received: by 2002:a25:1906:: with SMTP id 6mr75057968ybz.334.1636312452824; Sun, 07 Nov 2021 11:14:12 -0800 (PST) MIME-Version: 1.0 References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> In-Reply-To: From: Phillip Hallam-Baker Date: Sun, 7 Nov 2021 14:13:59 -0500 Message-ID: To: "Joel M. Halpern" Cc: Brian E Carpenter , GENDISPATCH List Content-Type: multipart/alternative; boundary="0000000000007e05f405d037aebf" Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 19:14:20 -0000 --0000000000007e05f405d037aebf Content-Type: text/plain; charset="UTF-8" CABForum has an anti-trust statement that is considerably narrower than the one proposed and that has been subject to a lot of lawyering. The big concerns for anti-trust are price fixing and use (or threatening use) of market power to prevent a product being offered. CABForum has in fact negotiated mandates to cease use of crypto algorithms. In fact it is the only organization that can enforce a mandate to stop use of an algorithm. Dropping SHA-1 did not pose a concern because the ultimate rights owner was NIST and they were hardly likely to complain. Things might have been a bit different if there were royalties involved. Which probably makes it important to get the right to deprecate an algorithm agreed before accepting any encumbered algorithm. On Sun, Nov 7, 2021 at 11:23 AM Joel M. Halpern wrote: > Folks can act both as individuals and employees at the same time. Even > in the same action. > > The point of these guidelines is to provide advice to participants about > things which, if they do them, could create risk for them, their fellow > participants, and the IETF as a whole. > > As far as I can tell, none of the policies you consider sufficient are > clear about any of these behaviors. (That is why as part of our > revision we went through and made sure we were not getting into general > behavior, but only giving guidance on things related to antitrust.) > > I am not expecting rigid rules. I don't think the community would want > that. I doubt they would serve us well. And legal matters are always > nuanced. > > Separately, I have many times watched competitors compromise. While it > is always couched as :I can't live with that", it is clearly often > driven by product, plans, etc. EKR even pointed to folks negotiating > when an interop test would make sense, and what features should be > tested. This is driven by a lot more folks than the individuals in the > room. The example of folks speaking in ways that are grounded in their > employer are myriad. Most of them are fine, even though one could argue > that they contravene the letter of the policy. The guidelines are to > point out when it is not fine. > > It sure seems to me we need a venue to work out what we as a community > can live with. I would not be surprised if we discover that there are > one or two things we do routinely that are actually bad ideas from an > antitrust perspective. We will then have to decide what we as a > community want to recommend (not require) about that. > > It was suggested at one point that the Note Well advice could be just > "obey the law". My problem with that is that it does not give people > any advice about widely agreed pitfalls that should be avoided. > > Yours, > Joel > > > On 11/6/2021 11:48 PM, Brian E Carpenter wrote: > > On 07-Nov-21 15:19, Joel M. Halpern wrote: > >> Brian, the fact that we say people participate as individuals does not > >> suddenly make them no longer employees of their company. And if they > >> act in ways that are anti-competitive on behalf of those employers, > > > > That is why our rules say what they say. The draft IMHO confuses the > issue. > > It talks about how participants might infringe competition law *if* they > > break the IETF rules by not acting as individual contributors. > > > > Introduction, sentence 1, says "Standards development frequently requires > > collaboration between competitors." That's simply not what the IETF does. > > It would apply to SDOs that are membership organisations whose members > > are competing companies. On reflection, the whole document is written > from > > the wrong premise. > > > > Section 5 starts "As the IETF is a standards development environment > where > > representatives from competitors are highly likely to be present..." > > Wrong. By definition, there are *no* representatatives present. > > > > [I believe the original legal advice came at least partly from Geoff > > Stewart, > > and the IBM corporate standards people, who knew a lot about antitrust > > because of the big antitrust suits against IBM, were also giving advice > > in those days.] > > > > I think the whole draft needs a rewrite on the basis that anyone who > > acts for their employer in an IETF forum is in breach of the IETF's > rules. > > That should be the starting point, not the two sentences quoted above. > > > > I do agree that WG Chairs and ADs should be advised to shut down any such > > behaviour. And a description of what might be incorrect behaviour is > > useful. But the original sin here is acting as a company rep, in direct > > violation of RFC 2026 and its predecessors. > > > > Regards > > Brian > > > >> it > >> can place the IETF as a whole, and other participants in the IETF, at > >> risk. particularly if they are from a company that is considered to > >> have a dominant position in the market. > >> > >> So I am looking for the IETF to give participants advice to help avoid > >> these risks. I do not know who wrote the advice 30 years ago, or what > >> assumptions they made. > > > > > >> I know that about 15 years ago our lawyer > >> thought it would be helpful to clarify these things, but we chose not > to. > >> > >> Put differently, if we thought there was no effect from employers on > >> people's actions here, we would not have the rules that each company may > >> have no more than 2 members on the nomcom. or the expectation that when > >> there is more than one chair of a working group they will be from > >> different companies. or that we expect that ADs in a given area will > >> come from different companies. Or that the nomcom almost never appoints > >> more than two ADs to the IESG from the same company. We do understand > >> that affiliation affects thing. > >> > >> Yours, > >> Joel > >> > >> On 11/6/2021 9:53 PM, Brian E Carpenter wrote: > >>> Joel, > >>> On 07-Nov-21 14:30, Joel M. Halpern wrote: > >>>> Finding the right balance on the wording of this issue is something I > >>>> expect the discussion once dispatched will need to do. > >>>> > >>>> From what the lawyers tell me, I believe this kind of discussion > >>>> does > >>>> head towards incurring significant risks. So having guidelines that > >>>> help us stay on the right side of that seems desirable to me. > >>> > >>> Help us understand. Since the IETF's motto is rough consensus and > >>> running code, and our participants are individuals not company > >>> representatives (and who therefore simply *cannot* make agreements > about > >>> companyy products), how can discussing and agreeing to implement > certain > >>> features and test interoperability *before* reaching rough consensus > >>> conceivably breach competition law? > >>> > >>> That the IETF is not a venue for companies to make agreements with each > >>> other has been established, if not since 1986, then certainly since > 1992 > >>> (RFC1310): "Participation is by individual technical contributors, > >>> rather than formal representatives of organizations." > >>> > >>> I do not understand why the legal advice given in 1992, 102 years after > >>> the USA's Sherman Act, needs revisiting. > >>> > >>> The same goes for the other new doctrine that I queried in > >>> > https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/ > >>> > >>> . > >>> > >>> I'm having second thoughts about whether this should be dispatched at > >>> all. Since the formalisation of the standards process almost 30 years > >>> ago was done with clear awareness of US and EU competition law, I'm far > >>> from convinced that it's the IETF's job to give people advice in this > >>> area. Participants who are employees should get such advice from their > >>> employers. We certainly shouldn't be publishing advice that has a > >>> chilling effect on rough consensus and running code. > >>> > >>> Brian > >>> > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 11/6/2021 9:07 PM, Eric Rescorla wrote: > >>>>> > >>>>> Hi Joel, > >>>>> > >>>>> This paragraph stood out to me in this document. > >>>>> > >>>>> There should be no agreement among participants > > to implement or to > >>>>> adhere to IETF standards, or any discussions as > > to when > >>> participants > >>>>> will begin to offer products conforming to IETF > > standards. > >>>>> > >>>>> In groups I am in, WG participants pretty routinely discuss shipping > >>>>> timelines and often try to coordinate changes so that they happen > >>>>> at similar times (e.g., disabling SHA-1, rolling out new code that > >>>>> can interop). > >>>>> > >>>>> -Ekr > >>>>> > >>>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern >>>>> > wrote: > >>>>> > >>>>> This is a significant revision of the draft on IETF antitrust > >>>>> guidelines. We tried to address what > > we heard in the previous > >>>>> feedback, > >>>>> and tightened the language related to legal issues. > >>>>> > >>>>> Chairs, if it is possible I would like to present this for > >>>>> dispatching > >>>>> at the upcoming session. > >>>>> > >>>>> Thank you, > >>>>> Joel > >>>>> > >>>>> > >>>>> -------- Forwarded Message -------- > >>>>> Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt > >>>>> Date: Wed, 03 Nov 2021 08:15:16 -0700 > >>>>> From: internet-drafts@ietf.org internet-drafts@ietf.org> > >>>>> Reply-To: internet-drafts@ietf.org > >>>>> > >>>>> To: i-d-announce@ietf.org > >>>>> > >>>>> > >>>>> A New Internet-Draft is available from the > > on-line Internet-Drafts > >>>>> directories. > >>>>> > >>>>> > >>>>> Title > >>> : Antitrust Guidelines for IETF Particiants > >>>>> Authors : Joel M. Halpern > >>>>> Brad Biddle > >>>>> Jay Daley > >>>>> Filename : > >>>>> draft-halpern-gendispatch-antitrust-01.txt > >>>>> Pages : 8 > >>>>> Date > >>> : 2021-11-03 > >>>>> > >>>>> Abstract: > >>>>> This document provides > > guidance for IETF participants on > >>>>> compliance > >>>>> with antitrust laws and how to reduce antitrust risks in > >>>>> connection > >>>>> with IETF activities. > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > >>>>> < > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/> > >>>>> > >>>>> > >>>>> There is also an HTML version available at: > >>>>> > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > >>>>> > >>>>> > >>>>> < > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html> > > >>>>> > >>>>> > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > >>>>> > >>>>> < > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> I-D-Announce mailing list > >>>>> I-D-Announce@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>> > >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>>>> > >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>> > >>>>> > >>>>> -- > >>>>> Gendispatch mailing list > >>>>> Gendispatch@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/gendispatch > >>>>> > >>>>> > >>>> > >>> > > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --0000000000007e05f405d037aebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
CAB= Forum has an anti-trust=C2=A0statement that is considerably narrower than t= he one proposed and that has been subject to a lot of lawyering.

The big concerns for anti-trust=C2= =A0are price fixing and use (or threatening use) of market power to prevent= a product being offered.

CABForum has in fact negotiated mandates to cease use of crypto algorithms= . In fact it is the only organization that can enforce a mandate to stop us= e of an algorithm.

Droppi= ng SHA-1 did not pose a concern because the ultimate rights owner was NIST = and they were hardly likely to complain. Things might have been a bit diffe= rent if there were royalties involved. Which probably makes it important to= get the right to deprecate an algorithm agreed before accepting any encumb= ered algorithm.



On Sun, N= ov 7, 2021 at 11:23 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Folks can act both as individuals and employees a= t the same time.=C2=A0 Even
in the same action.

The point of these guidelines is to provide advice to participants about things which, if they do them, could create risk for them, their fellow participants, and the IETF as a whole.

As far as I can tell, none of the policies you consider sufficient are
clear about any of these behaviors.=C2=A0 (That is why as part of our
revision we went through and made sure we were not getting into general behavior, but only giving guidance on things related to antitrust.)

I am not expecting rigid rules.=C2=A0 I don't think the community would= want
that.=C2=A0 I doubt they would serve us well.=C2=A0 And legal matters are a= lways
nuanced.

Separately, I have many times watched competitors compromise.=C2=A0 While i= t
is always couched as :I can't live with that", it is clearly often=
driven by product, plans, etc.=C2=A0 EKR even pointed to folks negotiating =
when an interop test would make sense, and what features should be
tested.=C2=A0 This is driven by a lot more folks than the individuals in th= e
room.=C2=A0 The example of folks speaking in ways that are grounded in thei= r
employer are myriad.=C2=A0 Most of them are fine, even though one could arg= ue
that they contravene the letter of the policy.=C2=A0 The guidelines are to =
point out when it is not fine.

It sure seems to me we need a venue to work out what we as a community
can live with.=C2=A0 I would not be surprised if we discover that there are=
one or two things we do routinely that are actually bad ideas from an
antitrust perspective.=C2=A0 We will then have to decide what we as a
community want to recommend (not require) about that.

It was suggested at one point that the Note Well advice could be just
"obey the law".=C2=A0 My problem with that is that it does not gi= ve people
any advice about widely agreed pitfalls that should be avoided.

Yours,
Joel


On 11/6/2021 11:48 PM, Brian E Carpenter wrote:
> On 07-Nov-21 15:19, Joel M. Halpern wrote:
>> Brian, the fact that we say people participate as individuals does= not
>> suddenly make them no longer employees of their company.=C2=A0 And= if they
>> act in ways that are anti-competitive on behalf of those employers= ,
>
> That is why our rules say what they say. The draft IMHO confuses the i= ssue.
> It talks about how participants might infringe competition law *if* th= ey
> break the IETF rules by not acting as individual contributors.
>
> Introduction, sentence 1, says "Standards development frequently = requires
> collaboration between competitors." That's simply not what th= e IETF does.
> It would apply to SDOs that are membership organisations whose members=
> are competing companies. On reflection, the whole document is written = from
> the wrong premise.
>
> Section 5 starts "As the IETF is a standards development environm= ent where
> representatives from competitors are highly likely to be present...&qu= ot;
> Wrong. By definition, there are *no* representatatives present.
>
> [I believe the original legal advice came at least partly from Geoff <= br> > Stewart,
> and the IBM corporate standards people, who knew a lot about antitrust=
> because of the big antitrust suits against IBM, were also giving advic= e
> in those days.]
>
> I think the whole draft needs a rewrite on the basis that anyone who > acts for their employer in an IETF forum is in breach of the IETF'= s rules.
> That should be the starting point, not the two sentences quoted above.=
>
> I do agree that WG Chairs and ADs should be advised to shut down any s= uch
> behaviour. And a description of what might be incorrect behaviour is > useful. But the original sin here is acting as a company rep, in direc= t
> violation of RFC 2026 and its predecessors.
>
> Regards
>=C2=A0 =C2=A0=C2=A0=C2=A0 Brian
>
>> it
>> can place the IETF as a whole, and other participants in the IETF,= at
>> risk.=C2=A0 particularly if they are from a company that is consid= ered to
>> have a dominant position in the market.
>>
>> So I am looking for the IETF to give participants advice to help a= void
>> these risks.=C2=A0 I do not know who wrote the advice 30 years ago= , or what
>> assumptions they made.
>
>
>> I know that about 15 years ago our lawyer
>> thought it would be helpful to clarify these things, but we chose = not to.
>>
>> Put differently, if we thought there was no effect from employers = on
>> people's actions here, we would not have the rules that each c= ompany may
>> have no more than 2 members on the nomcom.=C2=A0 or the expectatio= n that when
>> there is more than one chair of a working group they will be from<= br> >> different companies.=C2=A0 or that we expect that ADs in a given a= rea will
>> come from different companies.=C2=A0 Or that the nomcom almost nev= er appoints
>> more than two ADs to the IESG from the same company.=C2=A0=C2=A0 W= e do understand
>> that affiliation affects thing.
>>
>> Yours,
>> Joel
>>
>> On 11/6/2021 9:53 PM, Brian E Carpenter wrote:
>>> Joel,
>>> On 07-Nov-21 14:30, Joel M. Halpern wrote:
>>>> Finding the right balance on the wording of this issue is = something I
>>>> expect the discussion once dispatched will need to do.
>>>>
>>>> =C2=A0=C2=A0 From what the lawyers tell me, I believe this= kind of discussion
>>>> does
>>>> head towards incurring significant risks.=C2=A0 So having = guidelines that
>>>> help us stay on the right side of that seems desirable to = me.
>>>
>>> Help us understand. Since the IETF's motto is rough consen= sus and
>>> running code, and our participants are individuals not company=
>>> representatives (and who therefore simply *cannot* make agreem= ents about
>>> companyy products), how can discussing and agreeing to impleme= nt certain
>>> features and test interoperability *before* reaching rough con= sensus
>>> conceivably breach competition law?
>>>
>>> That the IETF is not a venue for companies to make agreements = with each
>>> other has been established, if not since 1986, then certainly = since 1992
>>> (RFC1310): "Participation is by individual technical cont= ributors,
>>> rather than formal representatives of organizations."
>>>
>>> I do not understand why the legal advice given in 1992, 102 ye= ars after
>>> the USA's Sherman Act, needs revisiting.
>>>
>>> The same goes for the other new doctrine that I queried in
>>> https://m= ailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/ <= br> >>>
>>> .
>>>
>>> I'm having second thoughts about whether this should be di= spatched at
>>> all. Since the formalisation of the standards process almost 3= 0 years
>>> ago was done with clear awareness of US and EU competition law= , I'm far
>>> from convinced that it's the IETF's job to give people= advice in this
>>> area. Participants who are employees should get such advice fr= om their
>>> employers. We certainly shouldn't be publishing advice tha= t has a
>>> chilling effect on rough consensus and running code.
>>>
>>> =C2=A0 =C2=A0=C2=A0 Brian
>>>
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 11/6/2021 9:07 PM, Eric Rescorla wrote:
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> This paragraph stood out to me in this document.
>>>>>
>>>>> =C2=A0=C2=A0 =C2=A0 =C2=A0There should be no agreement= among participants
> to implement or to
>>>>> =C2=A0=C2=A0 =C2=A0 =C2=A0adhere to IETF standards, or= any discussions as
> to when
>>> participants
>>>>> =C2=A0=C2=A0 =C2=A0 =C2=A0will begin to offer products= conforming to IETF
> standards.
>>>>>
>>>>> In groups I am in, WG participants pretty routinely di= scuss shipping
>>>>> timelines and often try to coordinate changes so that = they happen
>>>>> at similar times (e.g., disabling SHA-1, rolling out n= ew code that
>>>>> can interop).
>>>>>
>>>>> -Ekr
>>>>>
>>>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern <jmh@joelhalpern.com
>>>>> <mailto:jmh@joelhalpern.com>> wrote:
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is a significant r= evision of the draft on IETF antitrust
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 guidelines.=C2=A0 We tr= ied to address what
> we heard in the previous
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 feedback,
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and tightened the langu= age related to legal issues.
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Chairs, if it is possib= le I would like to present this for
>>>>> dispatching
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at the upcoming session= .
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank you,
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Joel
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------- Forwarded Mess= age --------
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Subject: I-D Action: dr= aft-halpern-gendispatch-antitrust-01.txt
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Date: Wed, 03 Nov 2021 = 08:15:16 -0700
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 From: internet-drafts@ietf.org &= lt;mailto:int= ernet-drafts@ietf.org>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reply-To: internet-drafts@ietf.org
>>>>> <mailto:internet-drafts@ietf.org>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To: i-d-announce@ietf.org <mailt= o:i-d-announce@i= etf.org>
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A New Internet-Draft is= available from the
> on-line Internet-Drafts
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directories.
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Title
>>> =C2=A0 =C2=A0 =C2=A0: Antitrust Guidelines for IETF Particiant= s
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joel M. Halpern=
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Brad Biddle
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jay Daley
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 :
>>>>> draft-halpern-gendispatch-antitrust-01.txt
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 8
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Date
>>> =C2=A0 =C2=A0 : 2021-11-03
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Abstract:
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 Thi= s document provides
> guidance for IETF participants on
>>>>> compliance
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 wit= h antitrust laws and how to reduce antitrust risks in
>>>>> connection
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 wit= h IETF activities.
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The IETF datatracker st= atus page for this draft is:
>>>>> https://da= tatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/
>>>>> <https:= //datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/> >>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is also an HTML v= ersion available at:
>>>>> http= s://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html=
>>>>>
>>>>>
>>>>> <= https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html= >
>>>>>
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A diff from the previou= s version is available at:
>>>>> https= ://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitrust-01 <= br> >>>>>
>>>>> <h= ttps://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitrust-01>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Internet-Drafts are als= o available by anonymous FTP at:
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ftp://ftp.iet= f.org/internet-drafts/
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <ftp://ftp= .ietf.org/internet-drafts/>
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _______________________= ________________________
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I-D-Announce mailing li= st
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.= org>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Internet-Draft director= ies: http://www.ietf.org/shadow.html
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://www.ie= tf.org/shadow.html>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or ftp:= //ftp.ietf.org/ietf/1shadow-sites.txt
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <ftp= ://ftp.ietf.org/ietf/1shadow-sites.txt>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Gendispatch mailing lis= t
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Gendispatch@ietf.org <mailto:Gendispatch@ietf.org<= /a>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/gendispatch
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <https://www.ietf.org/mailman/listinfo/gendispatch>
>>>>>
>>>>
>>>
>

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--0000000000007e05f405d037aebf-- From nobody Sun Nov 7 12:40:27 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF623A0C9F for ; Sun, 7 Nov 2021 12:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 hKvjF8IGWK8i for ; Sun, 7 Nov 2021 12:40:20 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 805E33A0CA0 for ; Sun, 7 Nov 2021 12:40:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HnR2X1D6Sz1ntx1; Sun, 7 Nov 2021 12:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1636317620; bh=w7a7zsIKSjzNtaI+3kWsP0aakafCRgLDOoIkFf0Ww6k=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=e8vlcZd4FirCv7MKBLfW8dVCKdo16YPrkwOMfHrY7kBSGhIZ0eJFol8savJ8vmk8h rC1d5rGeAlhufaitWiJy8rUgTfN8+MUTtPu3C+/7az22U7/hX1RS3lw/6/+LnW4BH4 MqOZkisxSr63YewPN0lk6Qgz78+KDngsFLMWfgCA= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4HnR2W3K4Sz1ntwy; Sun, 7 Nov 2021 12:40:19 -0800 (PST) Message-ID: Date: Sun, 7 Nov 2021 15:40:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Phillip Hallam-Baker Cc: GENDISPATCH List References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 20:40:26 -0000 Once we get a venue to discus this, clearly folks can propose dropping parts (or adding parts, or rewording, etc.) I find many of the policies from other bodies to be much less than helpful to understand what to avoid. Yours, Joel On 11/7/2021 2:13 PM, Phillip Hallam-Baker wrote: > CABForum has an anti-trust statement that is considerably narrower than > the one proposed and that has been subject to a lot of lawyering. > > The big concerns for anti-trust are price fixing and use (or threatening > use) of market power to prevent a product being offered. > > CABForum has in fact negotiated mandates to cease use of crypto > algorithms. In fact it is the only organization that can enforce a > mandate to stop use of an algorithm. > > Dropping SHA-1 did not pose a concern because the ultimate rights owner > was NIST and they were hardly likely to complain. Things might have been > a bit different if there were royalties involved. Which probably makes > it important to get the right to deprecate an algorithm agreed before > accepting any encumbered algorithm. > > > > > On Sun, Nov 7, 2021 at 11:23 AM Joel M. Halpern > wrote: > > Folks can act both as individuals and employees at the same time.  Even > in the same action. > > The point of these guidelines is to provide advice to participants > about > things which, if they do them, could create risk for them, their fellow > participants, and the IETF as a whole. > > As far as I can tell, none of the policies you consider sufficient are > clear about any of these behaviors.  (That is why as part of our > revision we went through and made sure we were not getting into general > behavior, but only giving guidance on things related to antitrust.) > > I am not expecting rigid rules.  I don't think the community would want > that.  I doubt they would serve us well.  And legal matters are always > nuanced. > > Separately, I have many times watched competitors compromise.  While it > is always couched as :I can't live with that", it is clearly often > driven by product, plans, etc.  EKR even pointed to folks negotiating > when an interop test would make sense, and what features should be > tested.  This is driven by a lot more folks than the individuals in the > room.  The example of folks speaking in ways that are grounded in their > employer are myriad.  Most of them are fine, even though one could > argue > that they contravene the letter of the policy.  The guidelines are to > point out when it is not fine. > > It sure seems to me we need a venue to work out what we as a community > can live with.  I would not be surprised if we discover that there are > one or two things we do routinely that are actually bad ideas from an > antitrust perspective.  We will then have to decide what we as a > community want to recommend (not require) about that. > > It was suggested at one point that the Note Well advice could be just > "obey the law".  My problem with that is that it does not give people > any advice about widely agreed pitfalls that should be avoided. > > Yours, > Joel > > > On 11/6/2021 11:48 PM, Brian E Carpenter wrote: > > On 07-Nov-21 15:19, Joel M. Halpern wrote: > >> Brian, the fact that we say people participate as individuals > does not > >> suddenly make them no longer employees of their company.  And if > they > >> act in ways that are anti-competitive on behalf of those employers, > > > > That is why our rules say what they say. The draft IMHO confuses > the issue. > > It talks about how participants might infringe competition law > *if* they > > break the IETF rules by not acting as individual contributors. > > > > Introduction, sentence 1, says "Standards development frequently > requires > > collaboration between competitors." That's simply not what the > IETF does. > > It would apply to SDOs that are membership organisations whose > members > > are competing companies. On reflection, the whole document is > written from > > the wrong premise. > > > > Section 5 starts "As the IETF is a standards development > environment where > > representatives from competitors are highly likely to be present..." > > Wrong. By definition, there are *no* representatatives present. > > > > [I believe the original legal advice came at least partly from Geoff > > Stewart, > > and the IBM corporate standards people, who knew a lot about > antitrust > > because of the big antitrust suits against IBM, were also giving > advice > > in those days.] > > > > I think the whole draft needs a rewrite on the basis that anyone who > > acts for their employer in an IETF forum is in breach of the > IETF's rules. > > That should be the starting point, not the two sentences quoted > above. > > > > I do agree that WG Chairs and ADs should be advised to shut down > any such > > behaviour. And a description of what might be incorrect behaviour is > > useful. But the original sin here is acting as a company rep, in > direct > > violation of RFC 2026 and its predecessors. > > > > Regards > >      Brian > > > >> it > >> can place the IETF as a whole, and other participants in the > IETF, at > >> risk.  particularly if they are from a company that is considered to > >> have a dominant position in the market. > >> > >> So I am looking for the IETF to give participants advice to help > avoid > >> these risks.  I do not know who wrote the advice 30 years ago, > or what > >> assumptions they made. > > > > > >> I know that about 15 years ago our lawyer > >> thought it would be helpful to clarify these things, but we > chose not to. > >> > >> Put differently, if we thought there was no effect from employers on > >> people's actions here, we would not have the rules that each > company may > >> have no more than 2 members on the nomcom.  or the expectation > that when > >> there is more than one chair of a working group they will be from > >> different companies.  or that we expect that ADs in a given area > will > >> come from different companies.  Or that the nomcom almost never > appoints > >> more than two ADs to the IESG from the same company.   We do > understand > >> that affiliation affects thing. > >> > >> Yours, > >> Joel > >> > >> On 11/6/2021 9:53 PM, Brian E Carpenter wrote: > >>> Joel, > >>> On 07-Nov-21 14:30, Joel M. Halpern wrote: > >>>> Finding the right balance on the wording of this issue is > something I > >>>> expect the discussion once dispatched will need to do. > >>>> > >>>>    From what the lawyers tell me, I believe this kind of > discussion > >>>> does > >>>> head towards incurring significant risks.  So having > guidelines that > >>>> help us stay on the right side of that seems desirable to me. > >>> > >>> Help us understand. Since the IETF's motto is rough consensus and > >>> running code, and our participants are individuals not company > >>> representatives (and who therefore simply *cannot* make > agreements about > >>> companyy products), how can discussing and agreeing to > implement certain > >>> features and test interoperability *before* reaching rough > consensus > >>> conceivably breach competition law? > >>> > >>> That the IETF is not a venue for companies to make agreements > with each > >>> other has been established, if not since 1986, then certainly > since 1992 > >>> (RFC1310): "Participation is by individual technical contributors, > >>> rather than formal representatives of organizations." > >>> > >>> I do not understand why the legal advice given in 1992, 102 > years after > >>> the USA's Sherman Act, needs revisiting. > >>> > >>> The same goes for the other new doctrine that I queried in > >>> > https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/ > > > >>> > >>> . > >>> > >>> I'm having second thoughts about whether this should be > dispatched at > >>> all. Since the formalisation of the standards process almost 30 > years > >>> ago was done with clear awareness of US and EU competition law, > I'm far > >>> from convinced that it's the IETF's job to give people advice > in this > >>> area. Participants who are employees should get such advice > from their > >>> employers. We certainly shouldn't be publishing advice that has a > >>> chilling effect on rough consensus and running code. > >>> > >>>      Brian > >>> > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 11/6/2021 9:07 PM, Eric Rescorla wrote: > >>>>> > >>>>> Hi Joel, > >>>>> > >>>>> This paragraph stood out to me in this document. > >>>>> > >>>>>       There should be no agreement among participants > > to implement or to > >>>>>       adhere to IETF standards, or any discussions as > > to when > >>> participants > >>>>>       will begin to offer products conforming to IETF > > standards. > >>>>> > >>>>> In groups I am in, WG participants pretty routinely discuss > shipping > >>>>> timelines and often try to coordinate changes so that they happen > >>>>> at similar times (e.g., disabling SHA-1, rolling out new code > that > >>>>> can interop). > >>>>> > >>>>> -Ekr > >>>>> > >>>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern > > >>>>> >> wrote: > >>>>> > >>>>>       This is a significant revision of the draft on IETF > antitrust > >>>>>       guidelines.  We tried to address what > > we heard in the previous > >>>>>       feedback, > >>>>>       and tightened the language related to legal issues. > >>>>> > >>>>>       Chairs, if it is possible I would like to present this for > >>>>> dispatching > >>>>>       at the upcoming session. > >>>>> > >>>>>       Thank you, > >>>>>       Joel > >>>>> > >>>>> > >>>>>       -------- Forwarded Message -------- > >>>>>       Subject: I-D Action: > draft-halpern-gendispatch-antitrust-01.txt > >>>>>       Date: Wed, 03 Nov 2021 08:15:16 -0700 > >>>>>       From: internet-drafts@ietf.org > > > >>>>>       Reply-To: internet-drafts@ietf.org > > >>>>> > > >>>>>       To: i-d-announce@ietf.org > > > >>>>> > >>>>> > >>>>>       A New Internet-Draft is available from the > > on-line Internet-Drafts > >>>>>       directories. > >>>>> > >>>>> > >>>>>                 Title > >>>      : Antitrust Guidelines for IETF Particiants > >>>>>                 Authors         : Joel M. Halpern > >>>>>                                   Brad Biddle > >>>>>                                   Jay Daley > >>>>>                Filename        : > >>>>> draft-halpern-gendispatch-antitrust-01.txt > >>>>>                Pages           : 8 > >>>>>                Date > >>>     : 2021-11-03 > >>>>> > >>>>>       Abstract: > >>>>>            This document provides > > guidance for IETF participants on > >>>>> compliance > >>>>>            with antitrust laws and how to reduce antitrust > risks in > >>>>> connection > >>>>>            with IETF activities. > >>>>> > >>>>> > >>>>>       The IETF datatracker status page for this draft is: > >>>>> > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > >>>>> > > > > >>>>> > >>>>> > >>>>>       There is also an HTML version available at: > >>>>> > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > > > >>>>> > >>>>> > >>>>> > > > > >>>>> > >>>>> > >>>>> > >>>>>       A diff from the previous version is available at: > >>>>> > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > > > >>>>> > >>>>> > > > > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>       Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > > >>>>>       > > >>>>> > >>>>> > >>>>>       _______________________________________________ > >>>>>       I-D-Announce mailing list > >>>>> I-D-Announce@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > > >>>>>       > > >>>>>       Internet-Draft directories: > http://www.ietf.org/shadow.html > >>>>>       > > >>>>>       or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >>>>>       > > >>>>> > >>>>>       -- > >>>>>       Gendispatch mailing list > >>>>> Gendispatch@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/gendispatch > > >>>>>       > > >>>>> > >>>> > >>> > > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > > From nobody Sun Nov 7 12:58:44 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF963A0D30 for ; Sun, 7 Nov 2021 12:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RrEQXRNPauIW for ; Sun, 7 Nov 2021 12:58:37 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26563A0D32 for ; Sun, 7 Nov 2021 12:58:37 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id gt5so6669843pjb.1 for ; Sun, 07 Nov 2021 12:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=6J9m6LY1A7ZYiTZWAwyXA8Nmn0KVggpTUFXLvYeNIC4=; b=FpPbf6kVJJHncCGdUG4LbvzdGnempjK7w0RH7A+FaNDV1oAdi65gQOKExlLjxetROw 18g13Wq7+4G47ALx7Fcz8itc+eJZQZ7jrencnYyRNDCnbtlL0le5AdjerVa4/WcsaS3h Vit46nSW9ret940qvon8OM8Zho4fHckWuzpy8wJhIgmQlxCo+0R/RzxgMSYMYI7DExt9 wNpoipBfcYDDtLWfu0wKXRRtSIcRMdEdPrEKjaVTWnUFDrhdKlaoVMz/mii/dsAS7Ntw 75i98feYY4+28OzPpwnaWMTl8D1oUthfPTWlnpxFjpKu4E2OwZiT55Je/cMV1WA3yHWC gbbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=6J9m6LY1A7ZYiTZWAwyXA8Nmn0KVggpTUFXLvYeNIC4=; b=WBVaZIDQc76UTpmKz+Nwjwm2Ssi+hqYC2ufziGj2QCwoCQnmodaI+OyrFDT8/ZIu9M ya3Hw+NvkmR6Zh1/yc5uNZqWInyt2V+il9mTog2i+9e2mcgBO8jQ1uKvCbVNf7Ro4nje JU0X+54lk5RFpBnnEQ8C3gD5wj8D/Uf5E6Z70w5/vHdCKrlyLTS9MfMDd0XR/IVdzhdo lZZRhCXcmo6z2B2uwwGcOJp1IlNw29ALrSM0DcK8tM1YpRbnOgdw6gVVfuW15hT7lIxc i5N5VphyIBKumGWOJVh84fG1rteXvD1pjQksJ6xyJ06ZT896wPwjM8qhqeRTB4t/Y+1t Dr+w== X-Gm-Message-State: AOAM533coX8S02HU7BI3S+CJs+2HXDgSI/oSHDkgRLpi3PU0K7pH4XER l5nnbfEEgrfMP4cJdzgkqOLUsEdUAGPXyw== X-Google-Smtp-Source: ABdhPJyxQaIpzuIZAYbzbPnvNgPPg33UvOAh4eCLSV0ywbmKwym6kOrQ+5PqtVJd2jp/fpfTd6Bwew== X-Received: by 2002:a17:90b:1c8f:: with SMTP id oo15mr47247404pjb.87.1636318716503; Sun, 07 Nov 2021 12:58:36 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id y28sm2012715pfa.208.2021.11.07.12.58.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Nov 2021 12:58:35 -0800 (PST) To: "Joel M. Halpern" , gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> From: Brian E Carpenter Message-ID: Date: Mon, 8 Nov 2021 09:58:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------FC0EC2CB19CC43CBF8CB95A6" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 20:58:41 -0000 This is a multi-part message in MIME format. --------------FC0EC2CB19CC43CBF8CB95A6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Rather than arguing in the abstract, I've attached a set of proposed changes to the draft, which I hope will be found to be constructive.. I do believe that getting the stance of the document right before dispatching it is important. Regards Brian --------------FC0EC2CB19CC43CBF8CB95A6 Content-Type: text/plain; charset=UTF-8; name="antitrustComments.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="antitrustComments.txt" T0xEOg0KSW50ZW5kZWQgU3RhdHVzOiBCZXN0IEN1cnJlbnQgUHJhY3RpY2UNCg0KTkVXOg0K SW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFsDQoNClJhdGlvbmFsZTogTm90aGluZyBp biB0aGlzIGRvY3VtZW50IGNoYW5nZXMgYW55IElFVEYgcHJvY2VzcyBydWxlcy4gSXQgZXhw bGljaXRseSBzZXJ2ZXMgYXMgYWR2aWNlIHRvIHBhcnRpY2lwYW50cy4gVGhhdCBzaG91bGQg YmUgSW5mb3JtYXRpb25hbC4NCg0KT0xEIFRJVExFOg0KQW50aXRydXN0IEd1aWRlbGluZXMg Zm9yIElFVEYgUGFydGljaWFudHMNCg0KTkVXIFRJVExFOg0KQW50aXRydXN0IGFuZCBDb21w ZXRpdGlvbiBMYXcgR3VpZGVsaW5lcyBmb3IgSUVURiBQYXJ0aWNpYW50cw0KDQpSYXRpb25h bGU6IFRoZSB1c2FnZSBvZiAiYW50aXRydXN0IiBmb3IgdGhpcyB0b3BpYyBpcyBhIFVTIHBl Y3VsaWFyaXR5LiANCg0KT0xEOg0KMS4gSW50cm9kdWN0aW9uDQoNClN0YW5kYXJkcyBkZXZl bG9wbWVudCBmcmVxdWVudGx5IHJlcXVpcmVzIGNvbGxhYm9yYXRpb24gYmV0d2VlbiBjb21w ZXRpdG9ycy4NCg0KTkVXOg0KMS4gSW50cm9kdWN0aW9uDQoNClN0YW5kYXJkcyBkZXZlbG9w bWVudCBpbiBtYW55IHN0YW5kYXJkcyBkZXZlbG9wbWVudCBvcmdhbmlzYXRpb25zIGZyZXF1 ZW50bHkgcmVxdWlyZXMgY29sbGFib3JhdGlvbiBiZXR3ZWVuIG1lbWJlcnMgd2hvIGFyZSBj b21wZXRpdG9ycy4gVGhlIElFVEYgaXMgZGlmZmVyZW50IGluIHRoYXQgcGFydGljaXBhbnRz IGFjdCBhcyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9ycyBbQkNQOV0gYW5kIG5vdCBhcyByZXBy ZXNlbnRhdGl2ZXMgb2YgdGhlaXIgZW1wbG95ZXJzLiBOZXZlcnRoZWxlc3MsIHBhcnRpY2lw YW50cyBuZWVkIHRvIGJlIGF3YXJlIG9mIGxlZ2FsIGNvbmNlcm5zIHJlbGF0ZWQgdG8gYW50 aXRydXN0IGFuZCBjb21wZXRpdGlvbiBsYXcuDQoNClJhdGlvbmFsZToNClRoZSBzdGF0ZW1l bnQgdGhhdCBJRVRGIHBhcnRpY2lwYW50cyBhcmUgaW5kaXZpZHVhbCBjb250cmlidXRvcnMg ZGF0ZXMgYmFjayB0byAxOTkyIChSRkMxMzEwKSBhbmQgaGFzIGFsd2F5cyBiZWVuIGZ1bmRh bWVudGFsIHByZWNpc2VseSBiZWNhdXNlIG9mIGFudGl0cnVzdCBjb25zaWRlcmF0aW9ucy4N Cg0KREVMRVRFIHRoaXMgc2VjdGlvbiBiZWNhdXNlIGl0J3MgcmVkdW5kYW50Og0KMi4gVGVy bWlub2xvZ3kgDQoNCk9MRDoNCjUuIEFkZGl0aW9uYWwgR3VpZGVsaW5lcw0KDQpBcyB0aGUg SUVURiBpcyBhIHN0YW5kYXJkcyBkZXZlbG9wbWVudCBlbnZpcm9ubWVudCB3aGVyZSByZXBy ZXNlbnRhdGl2ZXMgZnJvbSBjb21wZXRpdG9ycyBhcmUgaGlnaGx5IGxpa2VseSB0byBiZSBw cmVzZW50LCB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgZ3VpZGVsaW5lcyBhcmUgcmVjb21t ZW5kZWQgdG8gYXZvaWQgdGhlIHBvc3NpYmlsaXR5IG9mIHBhcnRpY2lwYW50cyB2aW9sYXRp bmcgYW50aXRydXN0IGxhd3MuDQoNCk5FVzoNCjUuIEFkZGl0aW9uYWwgR3VpZGVsaW5lcw0K DQpBbHRob3VnaCB0aGUgSUVURiBpcyBhIHN0YW5kYXJkcyBkZXZlbG9wbWVudCBlbnZpcm9u bWVudCBjb25zaXN0aW5nIG9mIGluZGl2aWR1YWwgY29udHJpYnV0b3JzLCBtYW55IG9mIHRo ZW0gYXJlIGVtcGxveWVlcyBvZiBvciBjb25zdWx0YW50cyBmb3IgY29tcGFuaWVzIHRoYXQg bWF5IGJlIGNvbXBldGl0aXZlIHdpdGggZWFjaCBvdGhlci4gVGh1cywgdGhlIGZvbGxvd2lu ZyBhZGRpdGlvbmFsIGd1aWRlbGluZXMgYXJlIHJlY29tbWVuZGVkIHRvIGF2b2lkIHRoZSBw b3NzaWJpbGl0eSBvZiBwYXJ0aWNpcGFudHMgdmlvbGF0aW5nIGFudGl0cnVzdCBsYXdzLg0K DQpSYXRpb25hbGU6IEFzIGFib3ZlLg0KDQpJbiAgNS4xLiBBZG9wdGlvbiBhbmQgaW1wbGVt ZW50YXRpb24gb2Ygc3RhbmRhcmRzOg0KDQpPTEQ6DQpUaGVyZSBzaG91bGQgYmUgbm8gYWdy ZWVtZW50IGFtb25nIHBhcnRpY2lwYW50cyB0byBpbXBsZW1lbnQgb3IgdG8gYWRoZXJlIHRv IElFVEYgc3RhbmRhcmRzLCBvciBhbnkgZGlzY3Vzc2lvbnMgYXMgdG8gd2hlbiBwYXJ0aWNp cGFudHMgd2lsbCBiZWdpbiB0byBvZmZlciBwcm9kdWN0cyBjb25mb3JtaW5nIHRvIElFVEYg c3RhbmRhcmRzLg0KDQpORVc6DQpUaGVyZSBzaG91bGQgYmUgbm8gaGlkZGVuIGFncmVlbWVu dCBhbW9uZyBwYXJ0aWNpcGFudHMgdG8gaW1wbGVtZW50IG9yIHRvIGFkaGVyZSB0byBJRVRG IHN0YW5kYXJkcywgb3IgYW55IGhpZGRlbiBkaXNjdXNzaW9ucyBhcyB0byB3aGVuIHBhcnRp Y2lwYW50cyB3aWxsIGJlZ2luIHRvIG9mZmVyIHByb2R1Y3RzIGNvbmZvcm1pbmcgdG8gSUVU RiBzdGFuZGFyZHMuIEZvciB0aGUgYXZvaWRhbmNlIG9mIGRvdWJ0LCB0aGlzIGRvZXMgbm90 IHByZWNsdWRlIG9wZW4gdGVjaG5pY2FsIGRpc2N1c3Npb24gb3IgYWN0aXZpdHkgdG8gdmVy aWZ5IGNvcnJlY3QgdGVjaG5pY2FsIG9wZXJhdGlvbiBvZiBkcmFmdCBvciBmaW5hbCBzdGFu ZGFyZHMgb3Igb3BlbiBhbm5vdW5jZW1lbnQgb2YgYXZhaWxhYmxlIHByb3RvdHlwZXMgb3Ig cHJvZHVjdHMuIEluIHBhcnRpY3VsYXIsIGl0IGRvZXMgbm90IHByZWNsdWRlIGNvbGxhYm9y YXRpb24gb24gb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb25zLg0KDQpSYXRpb25hbGU6IFdl IHZhbHVlIHJ1bm5pbmcgY29kZSwgaW50ZXJvcCB0ZXN0aW5nLCBoYWNrYXRob25zLCBhbmQg b3BlbiBzb3VyY2UuDQoNCk9MRDoNCjUuMy4gTWFya2V0IFJlcXVpcmVtZW50cw0KDQpObyBJ RVRGIHBhcnRpY2lwYW50cyBzaG91bGQgZW5nYWdlIGluLCBkaXJlY3QsIG9yIGVuY291cmFn ZSBvdGhlciBJRVRGIHBhcnRpY2lwYW50cyB0byBlbmdhZ2UgaW4sIHRoZSB1c2Ugb2YgSUVU RiBmYWNpbGl0aWVzIGZvciBzdXJ2ZXlzIG9mIGN1c3RvbWVycyBvciBnYXRoZXJpbmcgb2Yg c3RhdGlzdGljYWwgZGF0YSBhYm91dCBtYXJrZXQgcmVxdWlyZW1lbnRzLiBIb3dldmVyIElF VEYgcGFydGljaXBhbnRzIG1heSBtYWtlIHByZXNlbnRhdGlvbnMgYWJvdXQgYnJvYWQgbWFy a2V0IHBvdGVudGlhbCBvciBtYXJrZXQgcmVxdWlyZW1lbnRzIGZvciBpbmZvcm1hdGlvbmFs IHB1cnBvc2VzLg0KDQpORVc6DQo1LjMuIE1hcmtldCBSZXF1aXJlbWVudHMNCg0KTm8gSUVU RiBwYXJ0aWNpcGFudHMgc2hvdWxkIGVuZ2FnZSBpbiwgZGlyZWN0LCBvciBlbmNvdXJhZ2Ug b3RoZXIgSUVURiBwYXJ0aWNpcGFudHMgdG8gZW5nYWdlIGluLCB0aGUgdXNlIG9mIElFVEYg ZmFjaWxpdGllcyBmb3Igc3VydmV5cyBvZiBjdXN0b21lcnMgb3IgZ2F0aGVyaW5nIG9mIHN0 YXRpc3RpY2FsIGRhdGEgYWJvdXQgbWFya2V0IHJlcXVpcmVtZW50cy4gRm9yIGF2b2lkYW5j ZSBvZiBkb3VidCwgdGhpcyBub3QgcHJlY2x1ZGUgYW55IG9wZW4gSUVURiBhY3Rpdml0eSBp bnZvbHZpbmcgYSBzdXJ2ZXkgb2YgcGFydGljdWxhciB0ZWNobmljYWwgcmVxdWlyZW1lbnRz IG9yIG9mIHRoZSBjdXJyZW50IGRlcGxveW1lbnQgb2YgcGFydGljdWxhciB0ZWNobmljYWwg c29sdXRpb25zLiBBbHNvLCBJRVRGIHBhcnRpY2lwYW50cyBtYXkgbWFrZSBwcmVzZW50YXRp b25zIGFib3V0IGJyb2FkIG1hcmtldCBwb3RlbnRpYWwgb3IgbWFya2V0IHJlcXVpcmVtZW50 cyBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3Nlcy4NCg== --------------FC0EC2CB19CC43CBF8CB95A6-- From nobody Sun Nov 7 13:40:20 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57923A0E5B for ; Sun, 7 Nov 2021 13:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 0HkgGcmPKTda for ; Sun, 7 Nov 2021 13:40:14 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 715613A0E59 for ; Sun, 7 Nov 2021 13:40:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4HnSMf0m34z6G9NP; Sun, 7 Nov 2021 13:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1636321214; bh=ToJPcLtR7seOQmo8ne5OBeOk6HczUG3/5IPcLvoJqkk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=eBvGPpjGePyZkXnduXOILos/6LAbDr9rRLs5QqjZ2ghW8oabWqqPgNgI9C5nW6ygr PkA5SvX/j8aBSog8mVl1RNWxyfbR75bm/juOME0urCCR6fMXFkd/AphkWe2BwjTXEi n5KngmZt9DaexsehiLyN6sj1T8hGsSIPq+3lcbp0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4HnSMd3yxsz6G9NN; Sun, 7 Nov 2021 13:40:13 -0800 (PST) Message-ID: <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> Date: Sun, 7 Nov 2021 16:40:13 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Brian E Carpenter , gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 21:40:19 -0000 I agree with some of your proposals, and disagree with others. But I do not see any of the actual proposals as substantive enough to affect the dispatching concern. They all seem things we can fairly discuss once dispatching has taken place. As an example, the question of whether "hidden" is an important part of the agreements issue clearly needs legal input. And discussion of tradeoffs. But we can't do that (particularly the community input on tradeoffs) until the draft is dispatched. Yours, Joel On 11/7/2021 3:58 PM, Brian E Carpenter wrote: > Hi, > > Rather than arguing in the abstract, I've attached a set of proposed > changes to the draft, which I hope will be found to be constructive.. I > do believe that getting the stance of the document right before > dispatching it is important. > > Regards >    Brian > From nobody Sun Nov 7 16:38:59 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72333A1367 for ; Sun, 7 Nov 2021 16:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk 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 7ZGFtB5K0hpp for ; Sun, 7 Nov 2021 16:38:53 -0800 (PST) Received: from sonic308-19.consmr.mail.ir2.yahoo.com (sonic308-19.consmr.mail.ir2.yahoo.com [77.238.178.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC6D3A1369 for ; Sun, 7 Nov 2021 16:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1636331929; bh=9y7p86L0N/r9voVzVkeOoOqPfS4Qf7LIRNwdY14wBP8=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From:Subject:Reply-To; b=XNGQuW6AP9CAj0pddz9LAsApZzXZxf0vyGSGpPRe6DYLcSXiPeWGhj1BhIK4hl6pvHPkuze3C/ygs4TlZSSJMt/sDbc7yxGBR1L7ceU0Xpla9TpR3W/grRtc1CR3unSkEL1rsNL8jcXw8fc3l7d/k/KsqJpHd67GHVpsYvQMGisBhkvkdkKuVN1OTkX8YXbsTuPmwwmPRexkMXjtlAB/QtNXVfvWMwawquH2ufc3pVXoQVEt2aE+iRdGGhZaOeKd85CN8lnt7TSI5NZb7EweYIqF54gGAQBAk+owaHf4f5S41hQ9WNH9n2lNpnyXafKgL7bmomZQv0UvrwtDoQBYMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636331929; bh=APH+JX8/az+YLGEQMli6K4pzVbjiT97K09qSOi6fAho=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Zc8Q9fEJ1+eRc9g+l3QYJKELOUT5eCp+Pw/GknqcEvsTWb7RmnxGQqgk0855vV2f6XgruJwiPrGifqrQfQxwaOxNVu0XXD/94p1FpzDpSuGrD0bMOjq2Tl2CLK2IB8l1jrgOGUUJuuikGQNJoIoKB9rjYt73qHYpFNgHgYGNNsDvML1mx8jZmDim/oOqyf75unZSST1Qx3lN1oNZzpWMGmN3h6ISlxeXVr4H/rgdBGHAMCxzUPT70elwPx3fBMcUc09VaObxy3ytERHi1QQKAn4c4Xx9o73xaBtGJIonEbmG/9hgXi67HbMvoNPgMdwP5pT3JKnOs+/StPtUfnus5g== X-YMail-OSG: iD9ybfUVM1kBk0yn4zZs9pAvTiqExkLXoqNRsjuSCv3dSBHMQh9XNC6ysBefU4J EGw7xWOVNNCiZSY3xgBVg35E4GobtqpDJ_ddVTSiYvNkJ0jb.n8YXPaQvVADmrER_WQvNSxHAbLj m1kDkl3e00OoThplHEpOtQZhYeASwjPD4wQefHbY7wacYcBNKJBpyEomUBCoXRL3q50uB3kL2vNM BJVIAuFUnALKK80rhonpPusbB1vvF8YKfM8bR4UKlik_Va1rhbaDTYA0.xQRVENKh.lT8KUE2tNr ipHS9aO3ifAFWScvleUt9aMLP4yyG0.H6VvaoZ8ovmTv7n_QNA3y8NQt9sXd9hZ45smpFy_no62_ eeuWb6OKW6CkjE4.4Eo5w54FARcxdobbM7WIBrgxS5Ye9Yy0ybEaDCLCeQg3JH56UHdwBMD_AKeR cOe8Ce92W9JnzjWnJ6R2idVlzyQuRcJ_D_k1eubZWI1_L93jf5uA32ME37Sv46MapezyeJh_5ZhL AZYrLL0KQJ81i0ZvYED6hlPICpsdNufrRkuMrjsxvF_w.Z7mRiglVDv5oTDu80.CEWSICiThFYjs rAnMlFfHza2C413Fqal0QQ510qq0N40tH.UyCNfYwyGA_bTxNvpFE5zFvo9DVz44TJT.gqeYE0z_ psrNi92FCzXvlHchZ1NZdGEs6ZEB020V7_mDefLPc0NVtL61TWZyQfJ7CXI1ldyXzGc_T9f18ABo 1WcIGsu9EigKFBVfg6N6lf4KLW7JwXHEE61xsJILDV7myjDvJ3qFI6B8VUsR0HEdf3Ld0kUGSSh6 G7qLhwCBVch65s5yOdBWSa2cTeKpz_603j7paJ.hD8t5GlkQDGCShepx.87osMmN8QWQjgAHoNy5 SnqLrX6km.M_n78x8z14zibKaVaGalnC9G_3UbnCXRtk8jJLFm9rUJAxJVytG_U2BDNv36ZD9WIC nE0cFro6BbrFQ.Zu8drXEbf.a5vEA111R0jfD.2y1GuGxGww5NJ4MuFt9WHVWWBjWzNHG7e889UV Uw9P3wPLI3PD7DczVxyBieffiGYOd4HE9q1uHDJbbYEU9WqiPzaNzksD8cdleyD5kwH1UYWJDdKh Sc4.2UdItxR4.R6rFFgYl7CRDzpJDb_SFj6ZoJF45YrZ1aRRhr3xtSx8x78Fsz2mweD6pR8UaDou U5Ypw.hGOUTXsMzqK0vx2OaKiGClW_NEwmb3B1RkXH.0fpoDphP.284JItxDU_apCiZhs578LHje 4Afm2tJi_wx0cxCoelRnUAAzdbA3ADPtFPAtdBX3SRifELeoanw3C4d3iYmL0RntiMrcIrp2Qej_ U9qJyszFqhmXmiIYZRRomF_Xx7gL.mzt6kaT74HHW_Ri5Y9eQ8Cgmq_o6_kjYm3OKShwASICJfXa _v7Q7K3jjTOA5.zklL8Bd7ag1MFHcXKboUMo5Z56fG7PAnUO92o7UgTaEulUOkYZ.9ab_oUSJFrb ERd5NUxE5n7T5c8.DahwZ.x0XFmMpIZjfP7DvSg_mO9a_lZYnDQglak8jQCQQDZl7eVN8qofAufL WyffV8v_Gy_7ujNHX0_T3MCiUnQKdcezVx9.bm2K20.PDr37dwlvJXEZ1PCRMyQS7mE3dtshpBlE t8Okx7lGw66UAvwnraKgshnN7NZBj_1JGIgmsy6nlC4PovnnW.1UYCGDVOfSZ6aPX6h3OZTF1G8A Js6V7SamIqqPeTQpDzfBP09OKsqmAIwrBSyp4ymubraceP5TQ3nZTtQdgRSTQvkFBeE2Y4XMW421 4.U4nE7elkwvx0d5BEEh.LI_g5fs.X9XT779sFqFRi0QsZIMdR.jl1BxqiPM2WsH8rapIh8TN1K7 kMoK6Ci140We_VTnlqqH9ViCLOONzcDVk7RfnRttWd861fr_4VL4SFOKfBB.V6.PqhSOqJfrWnO4 4PFc038l6Bu5Bf7uSeasSk_.cgbLhkiZjveOS4TYMzNw8p06j15t8WQpkQgD7JGoryfCcVyeYrY6 HJbC2P6GcQyaiTLxTX6owx8t.R7L11ibbmfKp9xC741YOCPFLiuyqfEb7t5TshLDmGJm059v2CVH Dr4.Vmq8CjDnFfGN9I5EfQoVINJT3w0eencrOv51MMZtDWIbsdmVtu3RZPG8FmtmG0Ey8e0l1cw8 C8ygnHfZwzlfxUkljVomfmD5HcbO5IPuW3tUnHVIzuO35hQhgV_4YsA6d7IOez6MUDnmSmX0k9K1 .uS2iBSqIhi3G30hxBViSKiR9yquuzQ68Jxwv3AmwaZSAxa.9iHLmoKknzYLYSUc19aaMUFpv7nV LX8BgNj7h6qZ5CsUrxs6HAKRdl7aCoPGRXhtBGkD4RjvSAsTHwb5lCXwMlWE6Hg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ir2.yahoo.com with HTTP; Mon, 8 Nov 2021 00:38:49 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e7622f5ddd34c9f67a48412841ada680; Mon, 08 Nov 2021 00:38:43 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-05C66961-BAB0-4BA9-B259-B446E193BED1 Content-Transfer-Encoding: 7bit From: Lloyd W Mime-Version: 1.0 (1.0) Date: Mon, 8 Nov 2021 11:38:39 +1100 Message-Id: References: Cc: gendispatch@ietf.org In-Reply-To: To: Brian E Carpenter X-Mailer: iPad Mail (19B74) Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 00:38:58 -0000 --Apple-Mail-05C66961-BAB0-4BA9-B259-B446E193BED1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (offtopic) It's important to care about getting the stance of the document right, but i= mo not enough attention is paid to also getting the stanzas of the document r= ight. https://datatracker.ietf.org/doc/rfc2100/ https://datatracker.ietf.org/doc/html/rfc1605 https://datatracker.ietf.org/doc/html/rfc1121 https://bits.ashleyblewer.com/blog/2021/07/16/ietf-rfcs-that-are-actually-ju= st-poems/ etc. Antitrust! when you lose control and you got no soul it's antitrust! The verse... could be worse. Lloyd Wood lloyd.wood@yahoo.co.uk programming is the poetry of our time. > On 8 Nov 2021, at 07:58, Brian E Carpenter w= rote: >=20 > =EF=BB=BFHi, >=20 > Rather than arguing in the abstract, I've attached a set of proposed chang= es to the draft, which I hope will be found to be constructive.. I do believ= e that getting the stance of the document right before dispatching it is imp= ortant. --Apple-Mail-05C66961-BAB0-4BA9-B259-B446E193BED1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
(offtopic)

It's im= portant to care about getting the stance of the document right, but imo not e= nough attention is paid to also getting the stanzas of the document right.
etc.

Antitrust!
=
when you lose control and you got no soul
it's antitrust!

The verse... could be worse.

Lloyd Wood
lloyd.wood@yahoo.co.uk

programmi= ng is the poetry of our time.

On 8 Nov 2021, at 07:58, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:

=EF=BB=BFHi,

Rather th= an arguing in the abstract, I've attached a set of proposed changes to the d= raft, which I hope will be found to be constructive.. I do believe that gett= ing the stance of the document right before dispatching it is important.
= --Apple-Mail-05C66961-BAB0-4BA9-B259-B446E193BED1-- From nobody Mon Nov 8 05:28:34 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DB03A100F for ; Mon, 8 Nov 2021 05:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QAkx5QhTHCMz for ; Mon, 8 Nov 2021 05:28:27 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078093A0FF6 for ; Mon, 8 Nov 2021 05:28:27 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id v4so13568260qtw.8 for ; Mon, 08 Nov 2021 05:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=7MhsBAuN2eVmlzEgWRzmuH+6yELCVkaTUzELb2Ervys=; b=Am7NdNqReDwMIojtEimib46WlWn7LZWUdRfaryTsBq1B2/spbkw+EwwMmxogHQ6Gur cT5TjUfPX8vYUNwkjLFUiFJkC5flFBTujCfQ21UhxQaICH9oFYOXR2PBs9vwjy8XC59y PSQAWsa5kMPniiG6tpVLeBtIBO4K7sQangOaDnOwHygbq2q8tnKu5lxLY9PV0nPkpa1y 8sTeVPpzJumhLkfSD4WgzV1NoF7qrJdMn2TpRQu3/wByFHaWhYgB/JWjqclVUnj+zq/5 WA+rkucCsXI2tTiLeXn0qku23i2A8k7YjAyibzVN9gKeO/XwpjqYgkxb+8len3/5cUxi YZZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=7MhsBAuN2eVmlzEgWRzmuH+6yELCVkaTUzELb2Ervys=; b=LhqO4IcnEirNuH1AwfsUJh/l3GakNP89AKJQOCKtLHg4rx2fbR+AIYmjFJ24rvT6l2 1+wQ/ehsBjn6v2OjNRMr9dpt0Oe/iOswBYEX0hrZifbdIGwzgLkDofQ2qmu3MqQNlmoi 60ZHkTzcBdIhhqJ0kpEom7i9a/ckwaP0Tl6Pvnlnzd4/ftM+4t8Jzn62nZwt06ef9hnL PWZM3SVgMrIupuIZilgS062T7JDP2tY/5nvqTY61DXRHWk00AiCz14ySG2IugXJnesHr er0/id6cCq9avJrIPRGI8aKOvSeVY0/aRgiuzzR2wZYafA+TOUzIqD6ldCbtuivsEGgL uqcg== X-Gm-Message-State: AOAM5338xNQcNe2hf25syrsp4JjDbzYWnVBEkVH+64VN3mekXICYw3nt BKA5ClDv41YAX97tsctgjs1Sb8+xntU= X-Google-Smtp-Source: ABdhPJzKYv+Qs8fvvdWtPGAG91EOZ9UmbORKhYbjErvowdxRpSMay3SptmRidmIZJOzTgg1DbG+TOQ== X-Received: by 2002:a05:622a:56:: with SMTP id y22mr65421033qtw.364.1636378104901; Mon, 08 Nov 2021 05:28:24 -0800 (PST) Received: from [192.168.1.249] (pool-70-106-224-166.clppva.fios.verizon.net. [70.106.224.166]) by smtp.gmail.com with ESMTPSA id o5sm9500432qkl.50.2021.11.08.05.28.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 05:28:24 -0800 (PST) Content-Type: multipart/alternative; boundary="------------M9JNGCC7QvQYDS59ZKJVwWRZ" Message-ID: <95603310-d1eb-09ed-9c29-9c8960e16215@gmail.com> Date: Mon, 8 Nov 2021 08:28:23 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Phillip Hallam-Baker , "Joel M. Halpern" Cc: GENDISPATCH List References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> From: Tony Rutkowski In-Reply-To: Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 13:28:33 -0000 This is a multi-part message in MIME format. --------------M9JNGCC7QvQYDS59ZKJVwWRZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit The CA/B Forum Bylaws are in some ways broader.  See CA-Browser-Forum-Bylaws-v2.3.pdf (cabforum.org) .  The antitrust provisions are very prominent and reinforced at every meeting. Note that they are applied even to ancillary "interested parties" with directed enforcement requirements. They are also extremely attentive to transparency at every step of the vetting and adoption processes.  They also control a very narrow market segment, have rather few parties involved, and the risks are borne by the relatively small number of participating OS and browser vendors.  IMHO, they have also been very lucky - especially in today's environment where competition authorities worldwide are subjecting "tech industry" participants to considerable scrutiny and undertaking mega enforcement actions. On 07-Nov-21 2:13 PM, Phillip Hallam-Baker wrote: > CABForum has an anti-trust statement that is considerably narrower > than the one proposed and that has been subject to a lot of lawyering. > > The big concerns for anti-trust are price fixing and use (or > threatening use) of market power to prevent a product being offered. > > CABForum has in fact negotiated mandates to cease use of crypto > algorithms. In fact it is the only organization that can enforce a > mandate to stop use of an algorithm. > > Dropping SHA-1 did not pose a concern because the ultimate rights > owner was NIST and they were hardly likely to complain. Things might > have been a bit different if there were royalties involved. Which > probably makes it important to get the right to deprecate an algorithm > agreed before accepting any encumbered algorithm. > > > > > On Sun, Nov 7, 2021 at 11:23 AM Joel M. Halpern > wrote: > > Folks can act both as individuals and employees at the same time. > Even > in the same action. > > The point of these guidelines is to provide advice to participants > about > things which, if they do them, could create risk for them, their > fellow > participants, and the IETF as a whole. > > As far as I can tell, none of the policies you consider sufficient > are > clear about any of these behaviors.  (That is why as part of our > revision we went through and made sure we were not getting into > general > behavior, but only giving guidance on things related to antitrust.) > > I am not expecting rigid rules.  I don't think the community would > want > that.  I doubt they would serve us well.  And legal matters are > always > nuanced. > > Separately, I have many times watched competitors compromise. > While it > is always couched as :I can't live with that", it is clearly often > driven by product, plans, etc.  EKR even pointed to folks negotiating > when an interop test would make sense, and what features should be > tested.  This is driven by a lot more folks than the individuals > in the > room.  The example of folks speaking in ways that are grounded in > their > employer are myriad.  Most of them are fine, even though one could > argue > that they contravene the letter of the policy.  The guidelines are to > point out when it is not fine. > > It sure seems to me we need a venue to work out what we as a > community > can live with.  I would not be surprised if we discover that there > are > one or two things we do routinely that are actually bad ideas from an > antitrust perspective.  We will then have to decide what we as a > community want to recommend (not require) about that. > > It was suggested at one point that the Note Well advice could be just > "obey the law".  My problem with that is that it does not give people > any advice about widely agreed pitfalls that should be avoided. > > Yours, > Joel > > > On 11/6/2021 11:48 PM, Brian E Carpenter wrote: > > On 07-Nov-21 15:19, Joel M. Halpern wrote: > >> Brian, the fact that we say people participate as individuals > does not > >> suddenly make them no longer employees of their company.  And > if they > >> act in ways that are anti-competitive on behalf of those > employers, > > > > That is why our rules say what they say. The draft IMHO confuses > the issue. > > It talks about how participants might infringe competition law > *if* they > > break the IETF rules by not acting as individual contributors. > > > > Introduction, sentence 1, says "Standards development frequently > requires > > collaboration between competitors." That's simply not what the > IETF does. > > It would apply to SDOs that are membership organisations whose > members > > are competing companies. On reflection, the whole document is > written from > > the wrong premise. > > > > Section 5 starts "As the IETF is a standards development > environment where > > representatives from competitors are highly likely to be present..." > > Wrong. By definition, there are *no* representatatives present. > > > > [I believe the original legal advice came at least partly from > Geoff > > Stewart, > > and the IBM corporate standards people, who knew a lot about > antitrust > > because of the big antitrust suits against IBM, were also giving > advice > > in those days.] > > > > I think the whole draft needs a rewrite on the basis that anyone who > > acts for their employer in an IETF forum is in breach of the > IETF's rules. > > That should be the starting point, not the two sentences quoted > above. > > > > I do agree that WG Chairs and ADs should be advised to shut down > any such > > behaviour. And a description of what might be incorrect behaviour is > > useful. But the original sin here is acting as a company rep, in > direct > > violation of RFC 2026 and its predecessors. > > > > Regards > >      Brian > > > >> it > >> can place the IETF as a whole, and other participants in the > IETF, at > >> risk.  particularly if they are from a company that is > considered to > >> have a dominant position in the market. > >> > >> So I am looking for the IETF to give participants advice to > help avoid > >> these risks.  I do not know who wrote the advice 30 years ago, > or what > >> assumptions they made. > > > > > >> I know that about 15 years ago our lawyer > >> thought it would be helpful to clarify these things, but we > chose not to. > >> > >> Put differently, if we thought there was no effect from > employers on > >> people's actions here, we would not have the rules that each > company may > >> have no more than 2 members on the nomcom.  or the expectation > that when > >> there is more than one chair of a working group they will be from > >> different companies.  or that we expect that ADs in a given > area will > >> come from different companies.  Or that the nomcom almost never > appoints > >> more than two ADs to the IESG from the same company.   We do > understand > >> that affiliation affects thing. > >> > >> Yours, > >> Joel > >> > >> On 11/6/2021 9:53 PM, Brian E Carpenter wrote: > >>> Joel, > >>> On 07-Nov-21 14:30, Joel M. Halpern wrote: > >>>> Finding the right balance on the wording of this issue is > something I > >>>> expect the discussion once dispatched will need to do. > >>>> > >>>>    From what the lawyers tell me, I believe this kind of > discussion > >>>> does > >>>> head towards incurring significant risks.  So having > guidelines that > >>>> help us stay on the right side of that seems desirable to me. > >>> > >>> Help us understand. Since the IETF's motto is rough consensus and > >>> running code, and our participants are individuals not company > >>> representatives (and who therefore simply *cannot* make > agreements about > >>> companyy products), how can discussing and agreeing to > implement certain > >>> features and test interoperability *before* reaching rough > consensus > >>> conceivably breach competition law? > >>> > >>> That the IETF is not a venue for companies to make agreements > with each > >>> other has been established, if not since 1986, then certainly > since 1992 > >>> (RFC1310): "Participation is by individual technical contributors, > >>> rather than formal representatives of organizations." > >>> > >>> I do not understand why the legal advice given in 1992, 102 > years after > >>> the USA's Sherman Act, needs revisiting. > >>> > >>> The same goes for the other new doctrine that I queried in > >>> > https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/ > > >>> > >>> . > >>> > >>> I'm having second thoughts about whether this should be > dispatched at > >>> all. Since the formalisation of the standards process almost > 30 years > >>> ago was done with clear awareness of US and EU competition > law, I'm far > >>> from convinced that it's the IETF's job to give people advice > in this > >>> area. Participants who are employees should get such advice > from their > >>> employers. We certainly shouldn't be publishing advice that has a > >>> chilling effect on rough consensus and running code. > >>> > >>>      Brian > >>> > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 11/6/2021 9:07 PM, Eric Rescorla wrote: > >>>>> > >>>>> Hi Joel, > >>>>> > >>>>> This paragraph stood out to me in this document. > >>>>> > >>>>>       There should be no agreement among participants > > to implement or to > >>>>>       adhere to IETF standards, or any discussions as > > to when > >>> participants > >>>>>       will begin to offer products conforming to IETF > > standards. > >>>>> > >>>>> In groups I am in, WG participants pretty routinely discuss > shipping > >>>>> timelines and often try to coordinate changes so that they > happen > >>>>> at similar times (e.g., disabling SHA-1, rolling out new > code that > >>>>> can interop). > >>>>> > >>>>> -Ekr > >>>>> > >>>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern > >>>>> > wrote: > >>>>> > >>>>>       This is a significant revision of the draft on IETF > antitrust > >>>>>       guidelines.  We tried to address what > > we heard in the previous > >>>>>       feedback, > >>>>>       and tightened the language related to legal issues. > >>>>> > >>>>>       Chairs, if it is possible I would like to present this for > >>>>> dispatching > >>>>>       at the upcoming session. > >>>>> > >>>>>       Thank you, > >>>>>       Joel > >>>>> > >>>>> > >>>>>       -------- Forwarded Message -------- > >>>>>       Subject: I-D Action: > draft-halpern-gendispatch-antitrust-01.txt > >>>>>       Date: Wed, 03 Nov 2021 08:15:16 -0700 > >>>>>       From: internet-drafts@ietf.org > > >>>>>       Reply-To: internet-drafts@ietf.org > >>>>> > >>>>>       To: i-d-announce@ietf.org > >>>>> > >>>>> > >>>>>       A New Internet-Draft is available from the > > on-line Internet-Drafts > >>>>>       directories. > >>>>> > >>>>> > >>>>>                 Title > >>>      : Antitrust Guidelines for IETF Particiants > >>>>>                 Authors         : Joel M. Halpern > >>>>>                                   Brad Biddle > >>>>>                                   Jay Daley > >>>>>                Filename        : > >>>>> draft-halpern-gendispatch-antitrust-01.txt > >>>>>                Pages           : 8 > >>>>>                Date > >>>     : 2021-11-03 > >>>>> > >>>>>       Abstract: > >>>>>            This document provides > > guidance for IETF participants on > >>>>> compliance > >>>>>            with antitrust laws and how to reduce antitrust > risks in > >>>>> connection > >>>>>            with IETF activities. > >>>>> > >>>>> > >>>>>       The IETF datatracker status page for this draft is: > >>>>> > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > >>>>> > > > >>>>> > >>>>> > >>>>>       There is also an HTML version available at: > >>>>> > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > > >>>>> > >>>>> > >>>>> > > > >>>>> > >>>>> > >>>>> > >>>>>       A diff from the previous version is available at: > >>>>> > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > > >>>>> > >>>>> > > > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>       Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>       > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>>       I-D-Announce mailing list > >>>>> I-D-Announce@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>       > >>>>>       Internet-Draft directories: > http://www.ietf.org/shadow.html > >>>>>       > >>>>>       or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>       > >>>>> > >>>>>       -- > >>>>>       Gendispatch mailing list > >>>>> Gendispatch@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/gendispatch > >>>>>       > >>>>> > >>>> > >>> > > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > > --------------M9JNGCC7QvQYDS59ZKJVwWRZ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

The CA/B Forum Bylaws are in some ways broader.  See CA-Browser-Forum-Bylaws-v2.3.pdf (cabforum.org).  The antitrust provisions are very prominent and reinforced at every meeting. Note that they are applied even to ancillary "interested parties" with directed enforcement requirements. They are also extremely attentive to transparency at every step of the vetting and adoption processes.  They also control a very narrow market segment, have rather few parties involved, and the risks are borne by the relatively small number of participating OS and browser vendors.  IMHO, they have also been very lucky - especially in today's environment where competition authorities worldwide are subjecting "tech industry" participants to considerable scrutiny and undertaking mega enforcement actions.


On 07-Nov-21 2:13 PM, Phillip Hallam-Baker wrote:
CABForum has an anti-trust statement that is considerably narrower than the one proposed and that has been subject to a lot of lawyering.

The big concerns for anti-trust are price fixing and use (or threatening use) of market power to prevent a product being offered.

CABForum has in fact negotiated mandates to cease use of crypto algorithms. In fact it is the only organization that can enforce a mandate to stop use of an algorithm.

Dropping SHA-1 did not pose a concern because the ultimate rights owner was NIST and they were hardly likely to complain. Things might have been a bit different if there were royalties involved. Which probably makes it important to get the right to deprecate an algorithm agreed before accepting any encumbered algorithm.




On Sun, Nov 7, 2021 at 11:23 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Folks can act both as individuals and employees at the same time.  Even
in the same action.

The point of these guidelines is to provide advice to participants about
things which, if they do them, could create risk for them, their fellow
participants, and the IETF as a whole.

As far as I can tell, none of the policies you consider sufficient are
clear about any of these behaviors.  (That is why as part of our
revision we went through and made sure we were not getting into general
behavior, but only giving guidance on things related to antitrust.)

I am not expecting rigid rules.  I don't think the community would want
that.  I doubt they would serve us well.  And legal matters are always
nuanced.

Separately, I have many times watched competitors compromise.  While it
is always couched as :I can't live with that", it is clearly often
driven by product, plans, etc.  EKR even pointed to folks negotiating
when an interop test would make sense, and what features should be
tested.  This is driven by a lot more folks than the individuals in the
room.  The example of folks speaking in ways that are grounded in their
employer are myriad.  Most of them are fine, even though one could argue
that they contravene the letter of the policy.  The guidelines are to
point out when it is not fine.

It sure seems to me we need a venue to work out what we as a community
can live with.  I would not be surprised if we discover that there are
one or two things we do routinely that are actually bad ideas from an
antitrust perspective.  We will then have to decide what we as a
community want to recommend (not require) about that.

It was suggested at one point that the Note Well advice could be just
"obey the law".  My problem with that is that it does not give people
any advice about widely agreed pitfalls that should be avoided.

Yours,
Joel


On 11/6/2021 11:48 PM, Brian E Carpenter wrote:
> On 07-Nov-21 15:19, Joel M. Halpern wrote:
>> Brian, the fact that we say people participate as individuals does not
>> suddenly make them no longer employees of their company.  And if they
>> act in ways that are anti-competitive on behalf of those employers,
>
> That is why our rules say what they say. The draft IMHO confuses the issue.
> It talks about how participants might infringe competition law *if* they
> break the IETF rules by not acting as individual contributors.
>
> Introduction, sentence 1, says "Standards development frequently requires
> collaboration between competitors." That's simply not what the IETF does.
> It would apply to SDOs that are membership organisations whose members
> are competing companies. On reflection, the whole document is written from
> the wrong premise.
>
> Section 5 starts "As the IETF is a standards development environment where
> representatives from competitors are highly likely to be present..."
> Wrong. By definition, there are *no* representatatives present.
>
> [I believe the original legal advice came at least partly from Geoff
> Stewart,
> and the IBM corporate standards people, who knew a lot about antitrust
> because of the big antitrust suits against IBM, were also giving advice
> in those days.]
>
> I think the whole draft needs a rewrite on the basis that anyone who
> acts for their employer in an IETF forum is in breach of the IETF's rules.
> That should be the starting point, not the two sentences quoted above.
>
> I do agree that WG Chairs and ADs should be advised to shut down any such
> behaviour. And a description of what might be incorrect behaviour is
> useful. But the original sin here is acting as a company rep, in direct
> violation of RFC 2026 and its predecessors.
>
> Regards
>      Brian
>
>> it
>> can place the IETF as a whole, and other participants in the IETF, at
>> risk.  particularly if they are from a company that is considered to
>> have a dominant position in the market.
>>
>> So I am looking for the IETF to give participants advice to help avoid
>> these risks.  I do not know who wrote the advice 30 years ago, or what
>> assumptions they made.
>
>
>> I know that about 15 years ago our lawyer
>> thought it would be helpful to clarify these things, but we chose not to.
>>
>> Put differently, if we thought there was no effect from employers on
>> people's actions here, we would not have the rules that each company may
>> have no more than 2 members on the nomcom.  or the expectation that when
>> there is more than one chair of a working group they will be from
>> different companies.  or that we expect that ADs in a given area will
>> come from different companies.  Or that the nomcom almost never appoints
>> more than two ADs to the IESG from the same company.   We do understand
>> that affiliation affects thing.
>>
>> Yours,
>> Joel
>>
>> On 11/6/2021 9:53 PM, Brian E Carpenter wrote:
>>> Joel,
>>> On 07-Nov-21 14:30, Joel M. Halpern wrote:
>>>> Finding the right balance on the wording of this issue is something I
>>>> expect the discussion once dispatched will need to do.
>>>>
>>>>    From what the lawyers tell me, I believe this kind of discussion
>>>> does
>>>> head towards incurring significant risks.  So having guidelines that
>>>> help us stay on the right side of that seems desirable to me.
>>>
>>> Help us understand. Since the IETF's motto is rough consensus and
>>> running code, and our participants are individuals not company
>>> representatives (and who therefore simply *cannot* make agreements about
>>> companyy products), how can discussing and agreeing to implement certain
>>> features and test interoperability *before* reaching rough consensus
>>> conceivably breach competition law?
>>>
>>> That the IETF is not a venue for companies to make agreements with each
>>> other has been established, if not since 1986, then certainly since 1992
>>> (RFC1310): "Participation is by individual technical contributors,
>>> rather than formal representatives of organizations."
>>>
>>> I do not understand why the legal advice given in 1992, 102 years after
>>> the USA's Sherman Act, needs revisiting.
>>>
>>> The same goes for the other new doctrine that I queried in
>>> https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/
>>>
>>> .
>>>
>>> I'm having second thoughts about whether this should be dispatched at
>>> all. Since the formalisation of the standards process almost 30 years
>>> ago was done with clear awareness of US and EU competition law, I'm far
>>> from convinced that it's the IETF's job to give people advice in this
>>> area. Participants who are employees should get such advice from their
>>> employers. We certainly shouldn't be publishing advice that has a
>>> chilling effect on rough consensus and running code.
>>>
>>>      Brian
>>>
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 11/6/2021 9:07 PM, Eric Rescorla wrote:
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> This paragraph stood out to me in this document.
>>>>>
>>>>>       There should be no agreement among participants
> to implement or to
>>>>>       adhere to IETF standards, or any discussions as
> to when
>>> participants
>>>>>       will begin to offer products conforming to IETF
> standards.
>>>>>
>>>>> In groups I am in, WG participants pretty routinely discuss shipping
>>>>> timelines and often try to coordinate changes so that they happen
>>>>> at similar times (e.g., disabling SHA-1, rolling out new code that
>>>>> can interop).
>>>>>
>>>>> -Ekr
>>>>>
>>>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern <jmh@joelhalpern.com
>>>>> <mailto:jmh@joelhalpern.com>> wrote:
>>>>>
>>>>>       This is a significant revision of the draft on IETF antitrust
>>>>>       guidelines.  We tried to address what
> we heard in the previous
>>>>>       feedback,
>>>>>       and tightened the language related to legal issues.
>>>>>
>>>>>       Chairs, if it is possible I would like to present this for
>>>>> dispatching
>>>>>       at the upcoming session.
>>>>>
>>>>>       Thank you,
>>>>>       Joel
>>>>>
>>>>>
>>>>>       -------- Forwarded Message --------
>>>>>       Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt
>>>>>       Date: Wed, 03 Nov 2021 08:15:16 -0700
>>>>>       From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>>>>       Reply-To: internet-drafts@ietf.org
>>>>> <mailto:internet-drafts@ietf.org>
>>>>>       To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>>>>>
>>>>>
>>>>>       A New Internet-Draft is available from the
> on-line Internet-Drafts
>>>>>       directories.
>>>>>
>>>>>
>>>>>                 Title
>>>      : Antitrust Guidelines for IETF Particiants
>>>>>                 Authors         : Joel M. Halpern
>>>>>                                   Brad Biddle
>>>>>                                   Jay Daley
>>>>>                Filename        :
>>>>> draft-halpern-gendispatch-antitrust-01.txt
>>>>>                Pages           : 8
>>>>>                Date
>>>     : 2021-11-03
>>>>>
>>>>>       Abstract:
>>>>>            This document provides
> guidance for IETF participants on
>>>>> compliance
>>>>>            with antitrust laws and how to reduce antitrust risks in
>>>>> connection
>>>>>            with IETF activities.
>>>>>
>>>>>
>>>>>       The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/
>>>>> <https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/>
>>>>>
>>>>>
>>>>>       There is also an HTML version available at:
>>>>> https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html
>>>>>
>>>>>
>>>>> <https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html>
>>>>>
>>>>>
>>>>>
>>>>>       A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01
>>>>>
>>>>> <https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       Internet-Drafts are also available by anonymous FTP at:
>>>>>       ftp://ftp.ietf.org/internet-drafts/
>>>>>       <ftp://ftp.ietf.org/internet-drafts/>
>>>>>
>>>>>
>>>>>       _______________________________________________
>>>>>       I-D-Announce mailing list
>>>>>       I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>>>>>       https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>       <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>>>>       Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>>       <http://www.ietf.org/shadow.html>
>>>>>       or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>       <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>>>>
>>>>>       --
>>>>>       Gendispatch mailing list
>>>>>       Gendispatch@ietf.org <mailto:Gendispatch@ietf.org>
>>>>>       https://www.ietf.org/mailman/listinfo/gendispatch
>>>>>       <https://www.ietf.org/mailman/listinfo/gendispatch>
>>>>>
>>>>
>>>
>

--
Gendispatch mailing list
Gendispatch@ietf.org
https://www.ietf.org/mailman/listinfo/gendispatch

--------------M9JNGCC7QvQYDS59ZKJVwWRZ-- From nobody Thu Nov 11 04:53:05 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1A3A0F44; Thu, 11 Nov 2021 04:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 VEJoB5Kwu2Ik; Thu, 11 Nov 2021 04:53:03 -0800 (PST) Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 0138B3A0F3D; Thu, 11 Nov 2021 04:53:03 -0800 (PST) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 73973E0CDE; Thu, 11 Nov 2021 12:53:01 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 4CF5F20672; Thu, 11 Nov 2021 12:53:01 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" Reply-To: drafts-lastcall@iana.org In-Reply-To: <163465875889.13316.4185419870902825454@ietfa.amsl.com> References: <163465875889.13316.4185419870902825454@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1214337 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org CC: iesg@ietf.org, gendispatch@ietf.org, lars@eggert.org, rwilton@cisco.com Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 11 Nov 2021 12:53:01 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Gendispatch] [IANA #1214337] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2021 12:53:04 -0000 (BEGIN IANA COMMENTS) IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-eggert-bcp45bis-06, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Lead IANA Services Specialist (END IANA COMMENTS) From nobody Thu Nov 11 05:05:22 2021 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 592363A0FCD; Thu, 11 Nov 2021 05:05:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163663591927.16419.9560017428982201572@ietfa.amsl.com> Date: Thu, 11 Nov 2021 05:05:19 -0800 From: IETF Secretariat Archived-At: Subject: [Gendispatch] Datatracker State Update Notice: X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2021 13:05:19 -0000 IANA review state changed to "IANA OK - No Actions Needed" Datatracker URL: https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ From nobody Sat Nov 13 20:55:47 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2383A085B; Sat, 13 Nov 2021 20:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 q4skklUtp7lr; Sat, 13 Nov 2021 20:55:42 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE1B3A0857; Sat, 13 Nov 2021 20:55:36 -0800 (PST) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 21A63548019; Sun, 14 Nov 2021 05:55:27 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 07FEC4E9DA5; Sun, 14 Nov 2021 05:55:27 +0100 (CET) Date: Sun, 14 Nov 2021 05:55:27 +0100 From: Toerless Eckert To: "Joel M. Halpern" , draft-halpern-gendispatch-antitrust@ietf.org Cc: Brian E Carpenter , gendispatch@ietf.org Message-ID: References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 04:55:45 -0000 On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote: > I agree with some of your proposals, and disagree with others. > But I do not see any of the actual proposals as substantive enough to affect > the dispatching concern. They all seem things we can fairly discuss once > dispatching has taken place. Does that mean the authors will drop and forget input her from the list that is not marked as "unless this issue is resolve, i will not recommend for this document to be dispatched" ? To repeat here on the list what i said during the WG meeting: I do not recommend for this document to be dispatched until it is clearer written down agreed to, what actually the goal is. And i see two potentially even conflicting possible goals: a) To put into writing sufficient 'Cover My Behind' statements to protect the IETF from legal action in case participants partake in anti-trust behavior. This is not mentioned as a goal in the draft, but i have the strong believ that this must have played a role on writing this document. And i do support such a document, but it should explicitly state that purpose. b) A document that is really intended to help participants to understand how to not get into anti-trust law issues. This is what the document claims it wants to achieve, but quite frankly i do not even understand the most basic connection between this goal and being an "IETF participant". E.g.: what legal differences does it make for my compliance (or lack thereof) with anti-trust laws if my actions are performed at the IETF or at any other place ? Lets say when i am getting together "privately for dinner" at an evening of an IETF week with a bunch of folks i know who happen to also attend the IETF, and discuss exactly the same stuff there ? Unless there are really strange laws (which i would be curious to learn about), i'd say the only difference is (a), aka.: possible implication of the IETF into legal actions caused by its participants ("sponsoring anti-trust behavior"). I also think that for (a), we do not necessary need to add more explanatory text (however unfortunate i would think that is), but if the goal is (b), and someone like me is supposed to understand the guidance, then i'd certainly be asking for more explanatory text to be put into the document. So, i really can't see how we can dispatch a document without being clearer about this goal. And if it is just me being confused here, great, please unconfuse me. Cheers Toerless From nobody Sat Nov 13 22:39:47 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B339E3A0A1D; Sat, 13 Nov 2021 22:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 C4D3xQNu6KNz; Sat, 13 Nov 2021 22:39:40 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 467FB3A0A1E; Sat, 13 Nov 2021 22:39:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HsN3J0VM2z1ntwj; Sat, 13 Nov 2021 22:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1636871980; bh=zVmu7R+TMO+hoCiRvvDxhp4AeE00BPFFfSrbpUq5/tg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ArgdRxxhDkLcGfNHJnMybIQhqMuvXBqpn0+hQHFo7D08/fn9z3PADhZRzgbaLhHnW og4rGkqzEuEk2GmO+v9USUXI5x8E7YIz8DUIs/Gf2TM+m8rK9jF+M7k177KVK8WTF7 oRDifw2gdByqD+H0NQoDmT15RUcvNoQ77A6LSxX4= X-Quarantine-ID: <334O3At4iPF0> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4HsN3H2V6Vz1nv1n; Sat, 13 Nov 2021 22:39:38 -0800 (PST) Message-ID: <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> Date: Sun, 14 Nov 2021 01:39:37 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Toerless Eckert , draft-halpern-gendispatch-antitrust@ietf.org Cc: gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 06:39:45 -0000 Toerless, several reactions to this email. First, I (and my co-authors I am confident) do not intend to ignore any input. We may or may not agree with it, but it will not be ignored. With regard to your question, the answer, to a first approximation as far as my intentions go is both. Which we tried to say in the document. word-smithing suggestions are appreciated. The caveat is that it is hard enough to arrange useful advice in the IETF context. Generalizing and adding to it for other context is left to the reader, or the reader's lawyer. Beyond that, I am waiting to give the chairs time to figure out what they think the dispatch answer is. (As I said at the time, I did not expect an answer yet.) And to talk with my co-authors about what changes we think make sense for the issues we want to address even before dispatching. (After dispatching, the dispatching mechanism will help us determine what path to take. It will, I hope, become a community document with us responsible to abide by the rough consensus.) Yours, Joel On 11/13/2021 11:55 PM, Toerless Eckert wrote: > On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote: >> I agree with some of your proposals, and disagree with others. >> But I do not see any of the actual proposals as substantive enough to affect >> the dispatching concern. They all seem things we can fairly discuss once >> dispatching has taken place. > > Does that mean the authors will drop and forget input her from the list that > is not marked as "unless this issue is resolve, i will not recommend for this > document to be dispatched" ? > > To repeat here on the list what i said during the WG meeting: > > I do not recommend for this document to be dispatched until it is > clearer written down agreed to, what actually the goal is. And i see two potentially > even conflicting possible goals: > > a) To put into writing sufficient 'Cover My Behind' statements to protect > the IETF from legal action in case participants partake in anti-trust > behavior. This is not mentioned as a goal in the draft, but i have the > strong believ that this must have played a role on writing this document. > And i do support such a document, but it should explicitly state that > purpose. > > b) A document that is really intended to help participants to understand > how to not get into anti-trust law issues. This is what the document claims > it wants to achieve, but quite frankly i do not even understand the most > basic connection between this goal and being an "IETF participant". > > E.g.: what legal differences does it make for my compliance (or lack thereof) with > anti-trust laws if my actions are performed at the IETF or at any other > place ? Lets say when i am getting together "privately for dinner" at an evening > of an IETF week with a bunch of folks i know who happen to also attend the > IETF, and discuss exactly the same stuff there ? Unless there are really > strange laws (which i would be curious to learn about), i'd say the only > difference is (a), aka.: possible implication of the IETF into legal > actions caused by its participants ("sponsoring anti-trust behavior"). > > I also think that for (a), we do not necessary need to add more explanatory > text (however unfortunate i would think that is), but if the goal is (b), > and someone like me is supposed to understand the guidance, then i'd certainly > be asking for more explanatory text to be put into the document. > > So, i really can't see how we can dispatch a document without being clearer > about this goal. And if it is just me being confused here, great, please > unconfuse me. > > Cheers > Toerless > From nobody Sun Nov 14 10:14:26 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C48E3A0E14; Sun, 14 Nov 2021 10:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 W3BKjIcagSTv; Sun, 14 Nov 2021 10:14:19 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59713A0E13; Sun, 14 Nov 2021 10:14:15 -0800 (PST) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 3A656548019; Sun, 14 Nov 2021 19:14:09 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 207644E9DB3; Sun, 14 Nov 2021 19:14:09 +0100 (CET) Date: Sun, 14 Nov 2021 19:14:09 +0100 From: Toerless Eckert To: "Joel M. Halpern" Cc: draft-halpern-gendispatch-antitrust@ietf.org, gendispatch@ietf.org Message-ID: References: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 18:14:24 -0000 On Sun, Nov 14, 2021 at 01:39:37AM -0500, Joel M. Halpern wrote: > Toerless, several reactions to this email. > > First, I (and my co-authors I am confident) do not intend to ignore any > input. We may or may not agree with it, but it will not be ignored. > > With regard to your question, the answer, to a first approximation as far as > my intentions go is both. Which we tried to say in the document. > word-smithing suggestions are appreciated. Ok. i do not read that from the text. But before wordsmithing, i wonder if it is prudent or even possible to achieve both. The legal constraints for the institutions are different as those of every participant: The IETF does not have to care about a particular attendees home/citizenship country/countries legal concerns. Participants who are not US residents may not need/want to care about US law unless being on US soil. And we all, IETF and participants somehow need to figure out what we should specifically do about any other countries laws when we have an IETF there. For example think of a university researcher from a european country who actually has a collaboration with Huawei. Now this ressearcher is talking with his collaborator on the hallway of an IETF and explains a cool new technical, non-published idea she has. This would be fine in all places, except if this IETF was happening on US soil. In that case, that researcher has violated US EAR regulations, exporting dual-use weapons technology (.eg.: "anything with routers") to an EAR listed entity because by being on US soil, of course US laws/regulations apply to her. The reason for this example is that if we really want to help IETF participants, we probably cannot constrain ourselves to just anti-trust law. But back to what i would recommend: I for once would love to see really first an as short as possible "defense of IETF" version of the document from Bratt, e.g.: lawyer talk that ensures that IETF as an organization is as much as possible protected from legislation by the USA in case of IETF participant misbehavior. Does not have to be any easier to read by participants than any US law/regulation. Pretty much (IMHO) the same goal as the "Note Well" (which i understand to be protection of the IETF against, copyright/ownership/secrecy claim on anything that the IETF would want to record/publish). Aka: this is the behavior that IETF expects from you as as an IETF participant so that IETF can operate legally save as a US corporation. This starting document should have IMHO not only protection against anti-trust US laws, but also important other law like EAR. If IETF could be co-accused as an enabler of any US law, whether it is anti-trust, EAR or whatever i do not know about, just because IETF provided the venue for such a public or private conversation, then this should be part of this "IETF defense" version of the document. This version of the document IMHO does not need to have a lot of community input except from those who feel they have relevant US law input. Then that legal IETF defense version needs some good faith effort to go beyond US law for all the times IETF happens in person in a differnt country. This is likeyl hand-waiving, BUT: it could self-oblige IETF to publish in time before any "overseas" IETF some statement as a result of investigation of additional rules to comply to in that country. These likely could be just per-country summaries on www.ietf.org that would accumulate and then hopefully not need to be redone when we just go back to the same countries over and over again. In any case: IMHO it does not make sense to first focus on what we as participants think before we're code-complete as to what the IETF as an institution needs. The whole side-thread about how we are supposed to be individual contributors exists only because we may have different understandings of whether or not the IETF could protect itself being accused as a party in anti-trust behavior by just claiming all participants are individual contirbutors, when we currend do, and IMHO need to be able to create evidence to the contrary. So, i would primarily like to understand how each of the statements of the document protects the IETF from what legal risk. And maybe stash anything that doesn't serve this purpose away (appendix, whatever). Not because i don't think we should ultimately have more stringent expectations than what is legally necessary, but because i would like to have a clear distinction between (a) third party caused "legal/expectations" and (b) self-made "culture/rules", tht are not third-party caused (eg. not legally required). > The caveat is that it is hard enough to arrange useful advice in the IETF > context. Generalizing and adding to it for other context is left to the > reader, or the reader's lawyer. What i was trying to get to was the distinction between (a) and (b). For all intent and purpose, i could write "ACME" instead of IETF in all of (a), but would need to write IETF for (b). Given how we do not want to write "ACME", we need some way to distingish the two (a)/(b). > Beyond that, I am waiting to give the chairs time to figure out what they > think the dispatch answer is. (As I said at the time, I did not expect an > answer yet.) And to talk with my co-authors about what changes we think > make sense for the issues we want to address even before dispatching. > (After dispatching, the dispatching mechanism will help us determine what > path to take. It will, I hope, become a community document with us > responsible to abide by the rough consensus.) I am alway for community document, but of course (a) above is primarily a lawyer issue. Community input on that part would be around scope for example. E.g.: which legal requirements are in-scope. Why only anti-trust if something like EAR may be an even bigger risk to IETF (no idea if this is true of course, i am just guessting...). The other problem with community consensus is that normal IETF process IMHO only works for documents not impacting those not interested in them (very simplified statement). Aka: most technical documents. For community rules applicable to all, we should add elements to community consensus, such as questionaires to really poll a much larger part of the community. Given How you have "Mr Questionaire" (;-p) as one of the co-authors, i'd hope we could count on him doing one for this work, once it is in the best shape for such a quiestionare from the whole community. > Yours, > Joel > > On 11/13/2021 11:55 PM, Toerless Eckert wrote: > > On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote: > > > I agree with some of your proposals, and disagree with others. > > > But I do not see any of the actual proposals as substantive enough to affect > > > the dispatching concern. They all seem things we can fairly discuss once > > > dispatching has taken place. > > > > Does that mean the authors will drop and forget input her from the list that > > is not marked as "unless this issue is resolve, i will not recommend for this > > document to be dispatched" ? > > > > To repeat here on the list what i said during the WG meeting: > > > > I do not recommend for this document to be dispatched until it is > > clearer written down agreed to, what actually the goal is. And i see two potentially > > even conflicting possible goals: > > > > a) To put into writing sufficient 'Cover My Behind' statements to protect > > the IETF from legal action in case participants partake in anti-trust > > behavior. This is not mentioned as a goal in the draft, but i have the > > strong believ that this must have played a role on writing this document. > > And i do support such a document, but it should explicitly state that > > purpose. > > > > b) A document that is really intended to help participants to understand > > how to not get into anti-trust law issues. This is what the document claims > > it wants to achieve, but quite frankly i do not even understand the most > > basic connection between this goal and being an "IETF participant". > > > > E.g.: what legal differences does it make for my compliance (or lack thereof) with > > anti-trust laws if my actions are performed at the IETF or at any other > > place ? Lets say when i am getting together "privately for dinner" at an evening > > of an IETF week with a bunch of folks i know who happen to also attend the > > IETF, and discuss exactly the same stuff there ? Unless there are really > > strange laws (which i would be curious to learn about), i'd say the only > > difference is (a), aka.: possible implication of the IETF into legal > > actions caused by its participants ("sponsoring anti-trust behavior"). > > > > I also think that for (a), we do not necessary need to add more explanatory > > text (however unfortunate i would think that is), but if the goal is (b), > > and someone like me is supposed to understand the guidance, then i'd certainly > > be asking for more explanatory text to be put into the document. > > > > So, i really can't see how we can dispatch a document without being clearer > > about this goal. And if it is just me being confused here, great, please > > unconfuse me. > > > > Cheers > > Toerless > > -- --- tte@cs.fau.de From nobody Sun Nov 14 15:44:22 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CCA3A0B58; Sun, 14 Nov 2021 15:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 d_zNQVumNfvJ; Sun, 14 Nov 2021 15:44:16 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EB23A08F8; Sun, 14 Nov 2021 15:44:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 33B684112A50; Sun, 14 Nov 2021 15:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RGT9cqZWnYz; Sun, 14 Nov 2021 15:44:16 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id BEA764112A44; Sun, 14 Nov 2021 15:44:14 -0800 (PST) From: Jay Daley Message-Id: <9934DBC6-0F93-4B91-ADBB-6195C0EA81AB@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_3A306E52-C180-40AC-BA1C-F6BC49BAFE99" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Mon, 15 Nov 2021 12:44:09 +1300 In-Reply-To: Cc: "Joel M. Halpern" , draft-halpern-gendispatch-antitrust@ietf.org, gendispatch@ietf.org To: Toerless Eckert References: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 23:44:21 -0000 --Apple-Mail=_3A306E52-C180-40AC-BA1C-F6BC49BAFE99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (resending from my subscribed address) > On 15/11/2021, at 7:14 AM, Toerless Eckert wrote: >=20 > On Sun, Nov 14, 2021 at 01:39:37AM -0500, Joel M. Halpern wrote: >> Toerless, several reactions to this email. >>=20 >> First, I (and my co-authors I am confident) do not intend to ignore = any >> input. We may or may not agree with it, but it will not be ignored. >>=20 >> With regard to your question, the answer, to a first approximation as = far as >> my intentions go is both. Which we tried to say in the document. >> word-smithing suggestions are appreciated. >=20 > Ok. i do not read that from the text. But before wordsmithing, i = wonder > if it is prudent or even possible to achieve both. The legal = constraints > for the institutions are different as those of every participant: >=20 > The IETF does not have to care about a particular attendees = home/citizenship > country/countries legal concerns. Participants who are not US = residents > may not need/want to care about US law unless being on US soil. And we > all, IETF and participants somehow need to figure out what we should > specifically do about any other countries laws when we have an IETF = there. >=20 > For example think of a university researcher from a european > country who actually has a collaboration with Huawei. Now this = ressearcher > is talking with his collaborator on the hallway of an IETF and = explains > a cool new technical, non-published idea she has. This would be fine = in all > places, except if this IETF was happening on US soil. In that case, = that researcher > has violated US EAR regulations, exporting dual-use weapons technology > (.eg.: "anything with routers") to an EAR listed entity because by = being on US > soil, of course US laws/regulations apply to her. >=20 > The reason for this example is that if we really want to help IETF = participants, > we probably cannot constrain ourselves to just anti-trust law. >=20 > But back to what i would recommend: >=20 > I for once would love to see really first an as short as possible > "defense of IETF" version of the document from Bratt, e.g.: lawyer = talk that ensures > that IETF as an organization is as much as possible protected from = legislation > by the USA in case of IETF participant misbehavior. Does not have to = be > any easier to read by participants than any US law/regulation. Pretty > much (IMHO) the same goal as the "Note Well" (which i understand to be > protection of the IETF against, copyright/ownership/secrecy claim on > anything that the IETF would want to record/publish). Aka: this is the > behavior that IETF expects from you as as an IETF participant so that > IETF can operate legally save as a US corporation. >=20 > This starting document should have IMHO not only protection against = anti-trust > US laws, but also important other law like EAR. If IETF could be = co-accused > as an enabler of any US law, whether it is anti-trust, EAR or whatever = i do not > know about, just because IETF provided the venue for such a public or = private > conversation, then this should be part of this "IETF defense" version = of the document. >=20 > This version of the document IMHO does not need to have a lot of = community > input except from those who feel they have relevant US law input. >=20 > Then that legal IETF defense version needs some good faith effort to = go > beyond US law for all the times IETF happens in person in a differnt = country. > This is likeyl hand-waiving, BUT: it could self-oblige IETF to publish = in time > before any "overseas" IETF some statement as a result of investigation = of > additional rules to comply to in that country. These likely could be > just per-country summaries on www.ietf.org that = would accumulate and then > hopefully not need to be redone when we just go back to the same = countries > over and over again. >=20 > In any case: IMHO it does not make sense to first focus on what we > as participants think before we're code-complete as to what the IETF > as an institution needs. >=20 > The whole side-thread about how we are supposed to be individual = contributors > exists only because we may have different understandings of whether or > not the IETF could protect itself being accused as a party in = anti-trust > behavior by just claiming all participants are individual = contirbutors, > when we currend do, and IMHO need to be able to create evidence to the = contrary. >=20 > So, i would primarily like to understand how each of the statements of = the > document protects the IETF from what legal risk. And maybe stash = anything that > doesn't serve this purpose away (appendix, whatever). Not because i = don't think > we should ultimately have more stringent expectations than what is = legally > necessary, but because i would like to have a clear distinction = between > (a) third party caused "legal/expectations" and (b) self-made = "culture/rules", > tht are not third-party caused (eg. not legally required). >=20 >> The caveat is that it is hard enough to arrange useful advice in the = IETF >> context. Generalizing and adding to it for other context is left to = the >> reader, or the reader's lawyer. >=20 > What i was trying to get to was the distinction between (a) and (b). > For all intent and purpose, i could write "ACME" instead of IETF in = all of > (a), but would need to write IETF for (b). Given how we do not want to = write > "ACME", we need some way to distingish the two (a)/(b). >=20 >> Beyond that, I am waiting to give the chairs time to figure out what = they >> think the dispatch answer is. (As I said at the time, I did not = expect an >> answer yet.) And to talk with my co-authors about what changes we = think >> make sense for the issues we want to address even before dispatching. >> (After dispatching, the dispatching mechanism will help us determine = what >> path to take. It will, I hope, become a community document with us >> responsible to abide by the rough consensus.) >=20 > I am alway for community document, but of course (a) above is = primarily a > lawyer issue. Community input on that part would be around scope for = example. > E.g.: which legal requirements are in-scope. Why only anti-trust if = something > like EAR may be an even bigger risk to IETF (no idea if this is true = of course, i > am just guessting...). >=20 > The other problem with community consensus is that normal IETF > process IMHO only works for documents not impacting those not = interested > in them (very simplified statement). Aka: most technical documents. >=20 > For community rules applicable to all, we should add elements to=20 > community consensus, such as questionaires to really poll a much = larger > part of the community. Given How you have "Mr Questionaire" (;-p) as = one > of the co-authors, i'd hope we could count on him doing one for this > work, once it is in the best shape for such a quiestionare from the = whole > community. There=E2=80=99s a crucial point here that keeps getting missed - the = *only* way that the IETF can be put into a tricky legal position is by = the behaviour of participations and therefore the *only* ways that the = IETF can 'defend' itself are by distancing/disowning the behaviour of = participants, and/or by regulating the behaviour of participants. If we = assume for a moment that distancing/disowning is insufficient (noting = that some feel it is sufficient) then we cannot separate out your a) and = b) as you propose. I understand that you do not see the linkage between each behaviour the = draft recommends avoiding and antitrust law, but do you really think you = need to understand that or is it not sufficient that one or more lawyers = agree that these are the behaviours to be avoided? In other words, do = you need to be educated to the level of an antitrust lawyer by this = draft? Also, for the draft to explain this linkage it has to go into = the very same level of detail that you argue against elsewhere. =20 Rather than looking at this draft from the 'input' side where we get = into all the complexities of different laws in different regimes etc, = it=E2=80=99s likely more productive to look at it from 'output' side, = i.e. how does each of these recommendations affect participation in the = IETF? Jay >=20 >> Yours, >> Joel >>=20 >> On 11/13/2021 11:55 PM, Toerless Eckert wrote: >>> On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote: >>>> I agree with some of your proposals, and disagree with others. >>>> But I do not see any of the actual proposals as substantive enough = to affect >>>> the dispatching concern. They all seem things we can fairly = discuss once >>>> dispatching has taken place. >>>=20 >>> Does that mean the authors will drop and forget input her from the = list that >>> is not marked as "unless this issue is resolve, i will not recommend = for this >>> document to be dispatched" ? >>>=20 >>> To repeat here on the list what i said during the WG meeting: >>>=20 >>> I do not recommend for this document to be dispatched until it is >>> clearer written down agreed to, what actually the goal is. And i see = two potentially >>> even conflicting possible goals: >>>=20 >>> a) To put into writing sufficient 'Cover My Behind' statements to = protect >>> the IETF from legal action in case participants partake in = anti-trust >>> behavior. This is not mentioned as a goal in the draft, but i have = the >>> strong believ that this must have played a role on writing this = document. >>> And i do support such a document, but it should explicitly state = that >>> purpose. >>>=20 >>> b) A document that is really intended to help participants to = understand >>> how to not get into anti-trust law issues. This is what the document = claims >>> it wants to achieve, but quite frankly i do not even understand the = most >>> basic connection between this goal and being an "IETF participant". >>>=20 >>> E.g.: what legal differences does it make for my compliance (or lack = thereof) with >>> anti-trust laws if my actions are performed at the IETF or at any = other >>> place ? Lets say when i am getting together "privately for dinner" = at an evening >>> of an IETF week with a bunch of folks i know who happen to also = attend the >>> IETF, and discuss exactly the same stuff there ? Unless there are = really >>> strange laws (which i would be curious to learn about), i'd say the = only >>> difference is (a), aka.: possible implication of the IETF into legal >>> actions caused by its participants ("sponsoring anti-trust = behavior"). >>>=20 >>> I also think that for (a), we do not necessary need to add more = explanatory >>> text (however unfortunate i would think that is), but if the goal is = (b), >>> and someone like me is supposed to understand the guidance, then i'd = certainly >>> be asking for more explanatory text to be put into the document. >>>=20 >>> So, i really can't see how we can dispatch a document without being = clearer >>> about this goal. And if it is just me being confused here, great, = please >>> unconfuse me. >>>=20 >>> Cheers >>> Toerless >>>=20 >=20 > --=20 > --- > tte@cs.fau.de --=20 Jay Daley IETF Executive Director exec-director@ietf.org --Apple-Mail=_3A306E52-C180-40AC-BA1C-F6BC49BAFE99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (resending from my subscribed address)

On = 15/11/2021, at 7:14 AM, Toerless Eckert <tte@cs.fau.de> = wrote:

On Sun, Nov 14, 2021 at 01:39:37AM -0500, Joel M. Halpern = wrote:
Toerless, several reactions to this email.

First, I (and my co-authors I am confident) do not intend to = ignore any
input.  We may or may not agree with it, = but it will not be ignored.

With regard to = your question, the answer, to a first approximation as far as
my intentions go is both.  Which we tried to say in the = document.
word-smithing suggestions are appreciated.

Ok. i do not read that from the text. But before = wordsmithing, i wonder
if it is prudent or even possible to achieve both. The legal = constraints
for the = institutions are different as those of every participant:

The IETF does not have to care = about a particular attendees home/citizenship
country/countries legal = concerns. Participants who are not US residents
may not need/want to care about = US law unless being on US soil. And we
all, IETF and participants somehow need to figure out what we = should
specifically = do about any other countries laws when we have an IETF there.

For example think of a = university researcher from a european
country who actually has a collaboration with Huawei. Now = this ressearcher
is talking with his collaborator on the hallway of an IETF = and explains
a cool new = technical, non-published idea she has. This would be fine in = all
places, = except if this IETF was happening on US soil. In that case, that = researcher
has violated = US EAR regulations, exporting dual-use weapons technology
(.eg.: "anything with routers") = to an EAR listed entity because by being on US
soil, of course US = laws/regulations apply to her.

The reason for this example is that if we really want to help = IETF participants,
we probably cannot constrain ourselves to just anti-trust = law.

But back to = what i would recommend:

I for once would love to see really first an as short as = possible
"defense of = IETF" version of the document from Bratt, e.g.: lawyer talk that = ensures
that IETF as = an organization is as much as possible protected from = legislation
by the USA in = case of IETF participant misbehavior. Does not have to be
any easier to read by = participants than any US law/regulation. Pretty
much (IMHO) the same goal as the = "Note Well" (which i understand to be
protection of the IETF against, copyright/ownership/secrecy = claim on
anything that = the IETF would want to record/publish). Aka: this is the
behavior that IETF expects from = you as as an IETF participant so that
IETF can operate legally save as a US corporation.

This starting document should = have IMHO not only protection against anti-trust
US laws, but also important = other law like EAR. If IETF could be co-accused
as an enabler of any US law, = whether it is anti-trust, EAR or whatever i do not
know about, just because IETF = provided the venue for such a public or private
conversation, then this should = be part of this "IETF defense" version of the document.

This version of the document = IMHO does not need to have a lot of community
input except from those who feel = they have relevant US law input.

Then that legal IETF defense version needs some good faith = effort to go
beyond US law = for all the times IETF happens in person in a differnt = country.
This is = likeyl hand-waiving, BUT: it could self-oblige IETF to publish in = time
before any = "overseas" IETF some statement as a result of investigation of
additional rules to comply to in = that country. These likely could be
just per-country summaries on www.ietf.org that would accumulate and = then
hopefully not = need to be redone when we just go back to the same countries
over and over again.

In any case: IMHO it does not = make sense to first focus on what we
as participants think before we're code-complete as to what = the IETF
as an = institution needs.

The whole side-thread about how we are supposed to be = individual contributors
exists only because we may have different understandings of = whether or
not the IETF = could protect itself being accused as a party in anti-trust
behavior by just claiming all = participants are individual contirbutors,
when we currend do, and IMHO need to be able to create = evidence to the contrary.

So, i would primarily like to understand how each of the = statements of the
document protects the IETF from what legal risk. And maybe = stash anything that
doesn't serve this purpose away (appendix, whatever). Not = because i don't think
we should ultimately have more stringent expectations than = what is legally
necessary, but because i would like to have a clear = distinction between
(a) third party caused "legal/expectations" and (b) self-made = "culture/rules",
tht are not third-party caused (eg. not legally = required).

The = caveat is that it is hard enough to arrange useful advice in the IETF
context. Generalizing and adding to it for other context is = left to the
reader, or the reader's lawyer.

What i was trying to get to was the distinction between (a) = and (b).
For all = intent and purpose, i could write "ACME" instead of IETF in all = of
(a), but = would need to write IETF for (b). Given how we do not want to = write
"ACME", we = need some way to distingish the two (a)/(b).

Beyond = that, I am waiting to give the chairs time to figure out what they
think the dispatch answer is.  (As I said at the time, I = did not expect an
answer yet.)  And to talk with my = co-authors about what changes we think
make sense for the = issues we want to address even before dispatching.
(After = dispatching, the dispatching mechanism will help us determine what
path to take.  It will, I hope, become a community = document with us
responsible to abide by the rough = consensus.)

I am alway for community document, but of course (a) above is = primarily a
lawyer issue. = Community input on that part would be around scope for = example.
E.g.: which = legal requirements are in-scope. Why only anti-trust if = something
like EAR may = be an even bigger risk to IETF (no idea if this is true of course, = i
am just = guessting...).

The other problem with community consensus is that normal = IETF
process IMHO = only works for documents not impacting those not interested
in them (very simplified = statement). Aka: most technical documents.

For community rules applicable to all, we should add elements = to 
community consensus, such as = questionaires to really poll a much larger
part of the community. Given How you have "Mr Questionaire" = (;-p) as one
of the = co-authors, i'd hope we could count on him doing one for this
work, once it is in the best = shape for such a quiestionare from the whole
community.

There=E2=80=99s a crucial point here that keeps getting = missed - the *only* way that the IETF can be put into a tricky legal = position is by the behaviour of participations and therefore the *only* = ways that the IETF can 'defend' itself are by distancing/disowning the = behaviour of participants, and/or by regulating the behaviour of = participants.  If we assume for a moment that distancing/disowning = is insufficient (noting that some feel it is sufficient) then we cannot = separate out your a) and b) as you propose.

I understand that you do not see the = linkage between each behaviour the draft recommends avoiding and = antitrust law, but do you really think you need to understand that or is = it not sufficient that one or more lawyers agree that these are the = behaviours to be avoided?  In other words, do you need to be = educated to the level of an antitrust lawyer by this draft?  Also, = for the draft to explain this linkage it has to go into the very same = level of detail that you argue against elsewhere.  

Rather than looking at = this draft from the 'input' side where we get into all the complexities = of different laws in different regimes etc, it=E2=80=99s likely more = productive to look at it from 'output' side, i.e. how does each of these = recommendations affect participation in the IETF?
Jay

Yours,
Joel

On 11/13/2021 11:55 PM, Toerless Eckert = wrote:
On Sun, Nov = 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote:
I agree with some of = your proposals, and disagree with others.
But I do not see = any of the actual proposals as substantive enough to affect
the dispatching concern.  They all seem things we can = fairly discuss once
dispatching has taken place.

Does that mean the authors will = drop and forget input her from the list that
is not marked = as "unless this issue is resolve, i will not recommend for this
document to be dispatched" ?

To = repeat here on the list what i said during the WG meeting:

I do not recommend for this document to be = dispatched until it is
clearer written down agreed to, = what actually the goal is. And i see two potentially
 even conflicting possible goals:

a) To put into writing sufficient 'Cover My Behind' = statements to protect
the IETF from legal action in case = participants partake in anti-trust
behavior. This is not = mentioned as a goal in the draft, but i have the
strong = believ that this must have played a role on writing this document.
And i do support such a document, but it should explicitly = state that
purpose.

b) A = document that is really intended to help participants to understand
how to not get into anti-trust law issues. This is what the = document claims
it wants to achieve, but quite frankly i = do not even understand the most
basic connection between = this goal and being an "IETF participant".

E.g.: what legal differences does it make for my compliance = (or lack thereof) with
anti-trust laws if my actions are = performed at the IETF or at any other
place ? Lets say = when i am getting together "privately for dinner" at an evening
of an IETF week with a bunch of folks i know who happen to = also attend the
IETF, and discuss exactly the same stuff = there ? Unless there are really
strange laws (which i = would be curious to learn about), i'd say the only
difference is (a), aka.: possible implication of the IETF = into legal
actions caused by its participants ("sponsoring = anti-trust behavior").

I also think that = for (a), we do not necessary need to add more explanatory
text (however unfortunate i would think that is), but if the = goal is (b),
and someone like me is supposed to understand = the guidance, then i'd certainly
be asking for more = explanatory text to be put into the document.

So, i really can't see how we can dispatch a document without = being clearer
about this goal. And if it is just me being = confused here, great, please
unconfuse me.
Cheers
    Toerless


-- 
---
tte@cs.fau.de

-- 
Jay = Daley
IETF Executive Director
exec-director@ietf.org

= --Apple-Mail=_3A306E52-C180-40AC-BA1C-F6BC49BAFE99-- From nobody Sun Nov 14 15:57:33 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C464A3A0BCD; Sun, 14 Nov 2021 15:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5tn3n8rGzcwR; Sun, 14 Nov 2021 15:57:27 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ED13A0BCF; Sun, 14 Nov 2021 15:57:27 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id v23so18921924iom.12; Sun, 14 Nov 2021 15:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zH1L1ZzieOvKMVQdieCjrvzyrhtumpdVAtOvHtfKLAk=; b=k5jXxK+xidJwXHlxgwyZl8q3RFJPd+RWz95AqJyhp50jdfezEtLF46Ce1QDfRk3HnI Bz4+RAyoeXdrcrXe34T5zig6LJwBrN0oiC16f08qfUoRc6HKxnEHXxyFnKUDgH8lT9q5 j6OFv5q7JmWj7twrd9puoNKgL83stmCZKzNujjPaTkCfZlNxOxla7t0nb+SK9YxYOyWC 8N7VJnpCTIUAkb+vUJP9nDvuheaHNHhJWara+oVysoq87SOHZOcwgf9NdbfRsfOFl1AJ tvt+Z8VbIjh488JgFMzVg4DLCSUkKE9lEV3x7N3uM4awMwlOMhuz3TIEWuEsGtOqKUH2 h3Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zH1L1ZzieOvKMVQdieCjrvzyrhtumpdVAtOvHtfKLAk=; b=qc7yYpPYaYgVYzbckusuiHws261ptpo88fs6i5bFFK6B4iJLIdfTpQChwb+N5jlgwg EOmPdswSPgBpJZ/r3edWln/TgXCWap5Q8Tgb2AAImhvfQvzKEcWVPstVWPvmCyI1TN84 EDZIbQNABQ3eTFx0+ElzI/A4PmkVvS4yTwwMJdLjofGH1LT5+7+oZdxbB4lPAajZoAmA OrKPcLbGT4+7cnLd1q9ATRGzBN5gW3MdQ/P3Iq+Jk2DnPw29vmWahAkZxaicQ9XetySL sA5upXAn3NGP2Csdl9sc5LPCTZ3X7v6XzmeeX/ySo+wbOqz3+s3dC8o6Px/1FSkkywQf 1ZUw== X-Gm-Message-State: AOAM530bdkRls5aB6XKlh3aWkd0vTy+STP4mPRJjl8JBSzJLIp8xME2c lxRc8g10Lpzsvz9q9VeI+75WayPHg+PUO7OmYNBk5/YVYUQ= X-Google-Smtp-Source: ABdhPJzJSDzNU0LS1l5fS0hBmvvbIWHbCbI1PgTfjyAp+J85ksWmkUim1s543JgwZiInZy0cSb1VFPSaUtSgIw6XxpI= X-Received: by 2002:a05:6638:2186:: with SMTP id s6mr26274174jaj.96.1636934244804; Sun, 14 Nov 2021 15:57:24 -0800 (PST) MIME-Version: 1.0 References: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> <9934DBC6-0F93-4B91-ADBB-6195C0EA81AB@ietf.org> In-Reply-To: <9934DBC6-0F93-4B91-ADBB-6195C0EA81AB@ietf.org> From: Rob Sayre Date: Sun, 14 Nov 2021 15:57:13 -0800 Message-ID: To: Jay Daley Cc: Toerless Eckert , GENDISPATCH List , draft-halpern-gendispatch-antitrust@ietf.org Content-Type: multipart/alternative; boundary="0000000000002eaa9605d0c87404" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 23:57:32 -0000 --0000000000002eaa9605d0c87404 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 14, 2021 at 3:44 PM Jay Daley wrote: > > Rather than looking at this draft from the 'input' side where we get into > all the complexities of different laws in different regimes etc, it=E2=80= =99s > likely more productive to look at it from 'output' side, i.e. how does ea= ch > of these recommendations affect participation in the IETF? > I think this is the right approach. I understand that some people need a CYA draft here, but I don't think it will materially affect the negotiations around building the Internet. IMHO, optional participation by all is the key here. thanks, Rob --0000000000002eaa9605d0c87404 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 14, 2021 at 3:44 PM Jay Daley= <exec-director@ietf.org&g= t; wrote:
Rather than looking at this draft from the 'input' sid= e where we get into all the complexities of different laws in different reg= imes etc, it=E2=80=99s likely more productive to look at it from 'outpu= t' side, i.e. how does each of these recommendations affect participati= on in the IETF?

I think t= his is the right approach. I understand that some people need a CYA draft h= ere, but I don't think it will materially affect the negotiations aroun= d building the Internet. IMHO, optional participation by all is the key her= e.

thanks,
Rob

--0000000000002eaa9605d0c87404-- From nobody Sun Nov 14 18:53:14 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3CC3A0D32; Sun, 14 Nov 2021 18:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 gp9O1gywQRlo; Sun, 14 Nov 2021 18:53:08 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CC93A0D2A; Sun, 14 Nov 2021 18:53:06 -0800 (PST) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 381B6548019; Mon, 15 Nov 2021 03:53:01 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2F0664E9DBB; Mon, 15 Nov 2021 03:53:01 +0100 (CET) Date: Mon, 15 Nov 2021 03:53:01 +0100 From: Toerless Eckert To: Jay Daley Cc: "Joel M. Halpern" , draft-halpern-gendispatch-antitrust@ietf.org, gendispatch@ietf.org Message-ID: References: <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> <66BFD20A-7854-4938-8EEC-072DB6E15760@staff.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <66BFD20A-7854-4938-8EEC-072DB6E15760@staff.ietf.org> Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 02:53:13 -0000 On Mon, Nov 15, 2021 at 12:42:11PM +1300, Jay Daley wrote: > There’s a crucial point here that keeps getting missed - the *only* way that the IETF can be put into a tricky legal position is by the behaviour of participations and therefore the *only* ways that the IETF can 'defend' itself are by distancing/disowning the behaviour of participants, and/or by regulating the behaviour of participants. If we assume for a moment that distancing/disowning is insufficient (noting that some feel it is sufficient) then we cannot separate out your a) and b) as you propose. I was primarily thinking of "foreign country" lasws (aka: not USA and not host-country), applicable only to participants even when overseas. > I understand that you do not see the linkage between each behaviour the draft recommends avoiding and antitrust law, I don't think i said that. > but do you really think you need to understand that or is it not sufficient that one or more lawyers agree that these are the behaviours to be avoided? I do not need to understand these rules if our lawyers agree this is necessary and sufficient to indemnify IETF from actions of its participants. BUT: if we want to go beyond doing that and really help participant interpret how each of their actions does or does not meet the description, then more explicit examples/explanations would be helpful. For example and as i asked in another mail: Do i stop being an IETF participant for the purpose of indemnifying IETF when i go to dinner with other people who also happened to be at the IETF ? > In other words, do you need to be educated to the level of an antitrust lawyer by this draft? See above: no. > Also, for the draft to explain this linkage it has to go into the very same level of detail that you argue against elsewhere. Hopefully not. And as i said, the explanations may not need to be formal or in the same draft. > Rather than looking at this draft from the 'input' side where we get into all the complexities of different laws in different regimes etc, it’s likely more productive to look at it from 'output' side, i.e. how does each of these recommendations affect participation in the IETF? Of course. But to be sufficient for lawyers to be happy to protect the IETF, the draft will still be quite "abstract", e.g. no definition of exactly when i am or am not an IETF participant. I'd call this output explanation, but input explanation. Cheers Toerless > > Jay > > > > >> Yours, > >> Joel > >> > >> On 11/13/2021 11:55 PM, Toerless Eckert wrote: > >>> On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote: > >>>> I agree with some of your proposals, and disagree with others. > >>>> But I do not see any of the actual proposals as substantive enough to affect > >>>> the dispatching concern. They all seem things we can fairly discuss once > >>>> dispatching has taken place. > >>> > >>> Does that mean the authors will drop and forget input her from the list that > >>> is not marked as "unless this issue is resolve, i will not recommend for this > >>> document to be dispatched" ? > >>> > >>> To repeat here on the list what i said during the WG meeting: > >>> > >>> I do not recommend for this document to be dispatched until it is > >>> clearer written down agreed to, what actually the goal is. And i see two potentially > >>> even conflicting possible goals: > >>> > >>> a) To put into writing sufficient 'Cover My Behind' statements to protect > >>> the IETF from legal action in case participants partake in anti-trust > >>> behavior. This is not mentioned as a goal in the draft, but i have the > >>> strong believ that this must have played a role on writing this document. > >>> And i do support such a document, but it should explicitly state that > >>> purpose. > >>> > >>> b) A document that is really intended to help participants to understand > >>> how to not get into anti-trust law issues. This is what the document claims > >>> it wants to achieve, but quite frankly i do not even understand the most > >>> basic connection between this goal and being an "IETF participant". > >>> > >>> E.g.: what legal differences does it make for my compliance (or lack thereof) with > >>> anti-trust laws if my actions are performed at the IETF or at any other > >>> place ? Lets say when i am getting together "privately for dinner" at an evening > >>> of an IETF week with a bunch of folks i know who happen to also attend the > >>> IETF, and discuss exactly the same stuff there ? Unless there are really > >>> strange laws (which i would be curious to learn about), i'd say the only > >>> difference is (a), aka.: possible implication of the IETF into legal > >>> actions caused by its participants ("sponsoring anti-trust behavior"). > >>> > >>> I also think that for (a), we do not necessary need to add more explanatory > >>> text (however unfortunate i would think that is), but if the goal is (b), > >>> and someone like me is supposed to understand the guidance, then i'd certainly > >>> be asking for more explanatory text to be put into the document. > >>> > >>> So, i really can't see how we can dispatch a document without being clearer > >>> about this goal. And if it is just me being confused here, great, please > >>> unconfuse me. > >>> > >>> Cheers > >>> Toerless > >>> > > > > -- > > --- > > tte@cs.fau.de > -- > Jay Daley > IETF Executive Director > exec-director@ietf.org > -- --- tte@cs.fau.de From nobody Sun Nov 14 20:11:08 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B193A0DD9; Sun, 14 Nov 2021 20:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Dl6hKX3MkzzU; Sun, 14 Nov 2021 20:11:00 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A263A0DD8; Sun, 14 Nov 2021 20:11:00 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id u11so13378054plf.3; Sun, 14 Nov 2021 20:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QpNlIPRyZ5uB32ogATqqglBbhj1UIsnapHz+NYyl2HI=; b=Rpf8/BzQSG9GG3Dbp5mTyt8kSloovcD+a0gIBQMH/CAEPAbZnA5yTMmMkZLZfF9G/O euSB9qnueGgvK7nfUYD28G5bj+fGhrrzSotDAXp3zqfjtb41dH3sYJJbMJCIvo/keIpS jxY4tGAWisfqMQ1TMwawNCODxjrFoHXYQK8QxrciOQefblDW8Cllx5uIxCiXu88Q1M7s SK3CZBeQ+4SDIuqFKXgzsi9cEuVqZ1Ww8YBnHcwJAQ5cGZfk2Box25GVqmpqQ/eaPi6N LOqm0uzP+IvNPrCPtcwct50A5wIz6Qw79JTi6ldkTU9uZcpJeGEvMdWIdefk0DKMdzN1 9FlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QpNlIPRyZ5uB32ogATqqglBbhj1UIsnapHz+NYyl2HI=; b=qPAay+MtUaiqDAOCdQEVfk+J7IZzcj49/Sb67HayvO28dzq85HoXhwyk/2/hl6XD3T eTfUVZAUwSPlWD6YAMb39TD3YXylaGovBIE6W2+ZvJb9DXUcti7BWpItqWCAE9q0bHff uLtLoT6cJxSRz87XwsM1pFacq8RJQXA4JHorg6V8N+mG+EnemqmI4dYUE+n+zWJpuWz6 diypUD5rovLZsKPP9OXW8mWEvlkY2o1Ttey2BRA4UD2k5rXjFFdj/fNGJBIrH3BL/2ar eJw8QyYmHBoCTj9Jzlu23OpbkkXLnlcSELE9DJxB4h4raAHSPwAv6wNIpq8b1rtdsWr6 JBEA== X-Gm-Message-State: AOAM531CHW+7sShuey/4QZ5oya0hFiuEjpCLz3DDNU68MUIo64o06OAt aAaJE0h29o6bisHFVRdALyyggc7aDPbQnw== X-Google-Smtp-Source: ABdhPJwDUzFNGV32ET/llIu5lbIXFAoKeN6diyCAAvfTp2TQz2fkfO9dkS4azXGRqdhUorBQtVmYDA== X-Received: by 2002:a17:90b:1d82:: with SMTP id pf2mr17409155pjb.22.1636949458483; Sun, 14 Nov 2021 20:10:58 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id b9sm3199665pfm.127.2021.11.14.20.10.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Nov 2021 20:10:57 -0800 (PST) To: Jay Daley Cc: gendispatch@ietf.org, draft-halpern-gendispatch-antitrust@ietf.org References: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> <9934DBC6-0F93-4B91-ADBB-6195C0EA81AB@ietf.org> From: Brian E Carpenter Message-ID: Date: Mon, 15 Nov 2021 17:10:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <9934DBC6-0F93-4B91-ADBB-6195C0EA81AB@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 04:11:06 -0000 Jay, On 15-Nov-21 12:44, Jay Daley wrote: =2E.. > There=E2=80=99s a crucial point here that keeps getting missed - the *o= nly* way that the IETF can be put into a tricky legal position is by the = behaviour of participations and therefore the *only* ways that the IETF c= an 'defend' itself are by distancing/disowning the behaviour of participa= nts, and/or by regulating the behaviour of participants. =C2=A0If we assu= me for a moment that distancing/disowning is insufficient (noting that so= me feel it is sufficient) then we cannot separate out your a) and b) as y= ou propose. That is exactly the point that we need to understand. What is the legal t= heory that suggests that our current rules are insufficient to protect th= e IETF itself? How has this changed since the essence of our current rule= s was set in 1992 by RFC1310 and updated in full agreement with ISOC/IETF=20 counsel several times. Regards Brian From nobody Mon Nov 15 09:08:31 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8D13A0C7B; Sun, 14 Nov 2021 15:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 qjF5mhZ5vKnh; Sun, 14 Nov 2021 15:42:22 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EACE3A0C94; Sun, 14 Nov 2021 15:42:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 6F1A94112A50; Sun, 14 Nov 2021 15:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD-4dgQ1kGZd; Sun, 14 Nov 2021 15:42:18 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id 2C1904112A44; Sun, 14 Nov 2021 15:42:17 -0800 (PST) From: Jay Daley Message-Id: <66BFD20A-7854-4938-8EEC-072DB6E15760@staff.ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_CA7D9EA5-1008-47A3-AD7C-F5D0A260044B" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Mon, 15 Nov 2021 12:42:11 +1300 In-Reply-To: Cc: "Joel M. Halpern" , draft-halpern-gendispatch-antitrust@ietf.org, gendispatch@ietf.org To: Toerless Eckert References: <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: X-Mailman-Approved-At: Mon, 15 Nov 2021 09:08:30 -0800 Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 23:42:33 -0000 --Apple-Mail=_CA7D9EA5-1008-47A3-AD7C-F5D0A260044B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15/11/2021, at 7:14 AM, Toerless Eckert wrote: >=20 > On Sun, Nov 14, 2021 at 01:39:37AM -0500, Joel M. Halpern wrote: >> Toerless, several reactions to this email. >>=20 >> First, I (and my co-authors I am confident) do not intend to ignore = any >> input. We may or may not agree with it, but it will not be ignored. >>=20 >> With regard to your question, the answer, to a first approximation as = far as >> my intentions go is both. Which we tried to say in the document. >> word-smithing suggestions are appreciated. >=20 > Ok. i do not read that from the text. But before wordsmithing, i = wonder > if it is prudent or even possible to achieve both. The legal = constraints > for the institutions are different as those of every participant: >=20 > The IETF does not have to care about a particular attendees = home/citizenship > country/countries legal concerns. Participants who are not US = residents > may not need/want to care about US law unless being on US soil. And we > all, IETF and participants somehow need to figure out what we should > specifically do about any other countries laws when we have an IETF = there. >=20 > For example think of a university researcher from a european > country who actually has a collaboration with Huawei. Now this = ressearcher > is talking with his collaborator on the hallway of an IETF and = explains > a cool new technical, non-published idea she has. This would be fine = in all > places, except if this IETF was happening on US soil. In that case, = that researcher > has violated US EAR regulations, exporting dual-use weapons technology > (.eg.: "anything with routers") to an EAR listed entity because by = being on US > soil, of course US laws/regulations apply to her. >=20 > The reason for this example is that if we really want to help IETF = participants, > we probably cannot constrain ourselves to just anti-trust law. >=20 > But back to what i would recommend: >=20 > I for once would love to see really first an as short as possible > "defense of IETF" version of the document from Bratt, e.g.: lawyer = talk that ensures > that IETF as an organization is as much as possible protected from = legislation > by the USA in case of IETF participant misbehavior. Does not have to = be > any easier to read by participants than any US law/regulation. Pretty > much (IMHO) the same goal as the "Note Well" (which i understand to be > protection of the IETF against, copyright/ownership/secrecy claim on > anything that the IETF would want to record/publish). Aka: this is the > behavior that IETF expects from you as as an IETF participant so that > IETF can operate legally save as a US corporation. >=20 > This starting document should have IMHO not only protection against = anti-trust > US laws, but also important other law like EAR. If IETF could be = co-accused > as an enabler of any US law, whether it is anti-trust, EAR or whatever = i do not > know about, just because IETF provided the venue for such a public or = private > conversation, then this should be part of this "IETF defense" version = of the document. >=20 > This version of the document IMHO does not need to have a lot of = community > input except from those who feel they have relevant US law input. >=20 > Then that legal IETF defense version needs some good faith effort to = go > beyond US law for all the times IETF happens in person in a differnt = country. > This is likeyl hand-waiving, BUT: it could self-oblige IETF to publish = in time > before any "overseas" IETF some statement as a result of investigation = of > additional rules to comply to in that country. These likely could be > just per-country summaries on www.ietf.org that = would accumulate and then > hopefully not need to be redone when we just go back to the same = countries > over and over again. >=20 > In any case: IMHO it does not make sense to first focus on what we > as participants think before we're code-complete as to what the IETF > as an institution needs. >=20 > The whole side-thread about how we are supposed to be individual = contributors > exists only because we may have different understandings of whether or > not the IETF could protect itself being accused as a party in = anti-trust > behavior by just claiming all participants are individual = contirbutors, > when we currend do, and IMHO need to be able to create evidence to the = contrary. >=20 > So, i would primarily like to understand how each of the statements of = the > document protects the IETF from what legal risk. And maybe stash = anything that > doesn't serve this purpose away (appendix, whatever). Not because i = don't think > we should ultimately have more stringent expectations than what is = legally > necessary, but because i would like to have a clear distinction = between > (a) third party caused "legal/expectations" and (b) self-made = "culture/rules", > tht are not third-party caused (eg. not legally required). >=20 >> The caveat is that it is hard enough to arrange useful advice in the = IETF >> context. Generalizing and adding to it for other context is left to = the >> reader, or the reader's lawyer. >=20 > What i was trying to get to was the distinction between (a) and (b). > For all intent and purpose, i could write "ACME" instead of IETF in = all of > (a), but would need to write IETF for (b). Given how we do not want to = write > "ACME", we need some way to distingish the two (a)/(b). >=20 >> Beyond that, I am waiting to give the chairs time to figure out what = they >> think the dispatch answer is. (As I said at the time, I did not = expect an >> answer yet.) And to talk with my co-authors about what changes we = think >> make sense for the issues we want to address even before dispatching. >> (After dispatching, the dispatching mechanism will help us determine = what >> path to take. It will, I hope, become a community document with us >> responsible to abide by the rough consensus.) >=20 > I am alway for community document, but of course (a) above is = primarily a > lawyer issue. Community input on that part would be around scope for = example. > E.g.: which legal requirements are in-scope. Why only anti-trust if = something > like EAR may be an even bigger risk to IETF (no idea if this is true = of course, i > am just guessting...). >=20 > The other problem with community consensus is that normal IETF > process IMHO only works for documents not impacting those not = interested > in them (very simplified statement). Aka: most technical documents. >=20 > For community rules applicable to all, we should add elements to=20 > community consensus, such as questionaires to really poll a much = larger > part of the community. Given How you have "Mr Questionaire" (;-p) as = one > of the co-authors, i'd hope we could count on him doing one for this > work, once it is in the best shape for such a quiestionare from the = whole > community. There=E2=80=99s a crucial point here that keeps getting missed - the = *only* way that the IETF can be put into a tricky legal position is by = the behaviour of participations and therefore the *only* ways that the = IETF can 'defend' itself are by distancing/disowning the behaviour of = participants, and/or by regulating the behaviour of participants. If we = assume for a moment that distancing/disowning is insufficient (noting = that some feel it is sufficient) then we cannot separate out your a) and = b) as you propose. I understand that you do not see the linkage between each behaviour the = draft recommends avoiding and antitrust law, but do you really think you = need to understand that or is it not sufficient that one or more lawyers = agree that these are the behaviours to be avoided? In other words, do = you need to be educated to the level of an antitrust lawyer by this = draft? Also, for the draft to explain this linkage it has to go into = the very same level of detail that you argue against elsewhere. =20 Rather than looking at this draft from the 'input' side where we get = into all the complexities of different laws in different regimes etc, = it=E2=80=99s likely more productive to look at it from 'output' side, = i.e. how does each of these recommendations affect participation in the = IETF? Jay >=20 >> Yours, >> Joel >>=20 >> On 11/13/2021 11:55 PM, Toerless Eckert wrote: >>> On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote: >>>> I agree with some of your proposals, and disagree with others. >>>> But I do not see any of the actual proposals as substantive enough = to affect >>>> the dispatching concern. They all seem things we can fairly = discuss once >>>> dispatching has taken place. >>>=20 >>> Does that mean the authors will drop and forget input her from the = list that >>> is not marked as "unless this issue is resolve, i will not recommend = for this >>> document to be dispatched" ? >>>=20 >>> To repeat here on the list what i said during the WG meeting: >>>=20 >>> I do not recommend for this document to be dispatched until it is >>> clearer written down agreed to, what actually the goal is. And i see = two potentially >>> even conflicting possible goals: >>>=20 >>> a) To put into writing sufficient 'Cover My Behind' statements to = protect >>> the IETF from legal action in case participants partake in = anti-trust >>> behavior. This is not mentioned as a goal in the draft, but i have = the >>> strong believ that this must have played a role on writing this = document. >>> And i do support such a document, but it should explicitly state = that >>> purpose. >>>=20 >>> b) A document that is really intended to help participants to = understand >>> how to not get into anti-trust law issues. This is what the document = claims >>> it wants to achieve, but quite frankly i do not even understand the = most >>> basic connection between this goal and being an "IETF participant". >>>=20 >>> E.g.: what legal differences does it make for my compliance (or lack = thereof) with >>> anti-trust laws if my actions are performed at the IETF or at any = other >>> place ? Lets say when i am getting together "privately for dinner" = at an evening >>> of an IETF week with a bunch of folks i know who happen to also = attend the >>> IETF, and discuss exactly the same stuff there ? Unless there are = really >>> strange laws (which i would be curious to learn about), i'd say the = only >>> difference is (a), aka.: possible implication of the IETF into legal >>> actions caused by its participants ("sponsoring anti-trust = behavior"). >>>=20 >>> I also think that for (a), we do not necessary need to add more = explanatory >>> text (however unfortunate i would think that is), but if the goal is = (b), >>> and someone like me is supposed to understand the guidance, then i'd = certainly >>> be asking for more explanatory text to be put into the document. >>>=20 >>> So, i really can't see how we can dispatch a document without being = clearer >>> about this goal. And if it is just me being confused here, great, = please >>> unconfuse me. >>>=20 >>> Cheers >>> Toerless >>>=20 >=20 > --=20 > --- > tte@cs.fau.de --=20 Jay Daley IETF Executive Director exec-director@ietf.org --Apple-Mail=_CA7D9EA5-1008-47A3-AD7C-F5D0A260044B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 15/11/2021, at 7:14 AM, Toerless Eckert <tte@cs.fau.de> = wrote:

On Sun, Nov 14, 2021 at 01:39:37AM -0500, Joel M. Halpern = wrote:
Toerless, several reactions to this email.

First, I (and my co-authors I am confident) do not intend to = ignore any
input.  We may or may not agree with it, = but it will not be ignored.

With regard to = your question, the answer, to a first approximation as far as
my intentions go is both.  Which we tried to say in the = document.
word-smithing suggestions are appreciated.

Ok. i do not read that from the text. But before = wordsmithing, i wonder
if it is prudent or even possible to achieve both. The legal = constraints
for the = institutions are different as those of every participant:

The IETF does not have to care = about a particular attendees home/citizenship
country/countries legal = concerns. Participants who are not US residents
may not need/want to care about = US law unless being on US soil. And we
all, IETF and participants somehow need to figure out what we = should
specifically = do about any other countries laws when we have an IETF there.

For example think of a = university researcher from a european
country who actually has a collaboration with Huawei. Now = this ressearcher
is talking with his collaborator on the hallway of an IETF = and explains
a cool new = technical, non-published idea she has. This would be fine in = all
places, = except if this IETF was happening on US soil. In that case, that = researcher
has violated = US EAR regulations, exporting dual-use weapons technology
(.eg.: "anything with routers") = to an EAR listed entity because by being on US
soil, of course US = laws/regulations apply to her.

The reason for this example is that if we really want to help = IETF participants,
we probably cannot constrain ourselves to just anti-trust = law.

But back to = what i would recommend:

I for once would love to see really first an as short as = possible
"defense of = IETF" version of the document from Bratt, e.g.: lawyer talk that = ensures
that IETF as = an organization is as much as possible protected from = legislation
by the USA in = case of IETF participant misbehavior. Does not have to be
any easier to read by = participants than any US law/regulation. Pretty
much (IMHO) the same goal as the = "Note Well" (which i understand to be
protection of the IETF against, copyright/ownership/secrecy = claim on
anything that = the IETF would want to record/publish). Aka: this is the
behavior that IETF expects from = you as as an IETF participant so that
IETF can operate legally save as a US corporation.

This starting document should = have IMHO not only protection against anti-trust
US laws, but also important = other law like EAR. If IETF could be co-accused
as an enabler of any US law, = whether it is anti-trust, EAR or whatever i do not
know about, just because IETF = provided the venue for such a public or private
conversation, then this should = be part of this "IETF defense" version of the document.

This version of the document = IMHO does not need to have a lot of community
input except from those who feel = they have relevant US law input.

Then that legal IETF defense version needs some good faith = effort to go
beyond US law = for all the times IETF happens in person in a differnt = country.
This is = likeyl hand-waiving, BUT: it could self-oblige IETF to publish in = time
before any = "overseas" IETF some statement as a result of investigation of
additional rules to comply to in = that country. These likely could be
just per-country summaries on www.ietf.org that would accumulate and = then
hopefully not = need to be redone when we just go back to the same countries
over and over again.

In any case: IMHO it does not = make sense to first focus on what we
as participants think before we're code-complete as to what = the IETF
as an = institution needs.

The whole side-thread about how we are supposed to be = individual contributors
exists only because we may have different understandings of = whether or
not the IETF = could protect itself being accused as a party in anti-trust
behavior by just claiming all = participants are individual contirbutors,
when we currend do, and IMHO need to be able to create = evidence to the contrary.

So, i would primarily like to understand how each of the = statements of the
document protects the IETF from what legal risk. And maybe = stash anything that
doesn't serve this purpose away (appendix, whatever). Not = because i don't think
we should ultimately have more stringent expectations than = what is legally
necessary, but because i would like to have a clear = distinction between
(a) third party caused "legal/expectations" and (b) self-made = "culture/rules",
tht are not third-party caused (eg. not legally = required).

The = caveat is that it is hard enough to arrange useful advice in the IETF
context. Generalizing and adding to it for other context is = left to the
reader, or the reader's lawyer.

What i was trying to get to was the distinction between (a) = and (b).
For all = intent and purpose, i could write "ACME" instead of IETF in all = of
(a), but = would need to write IETF for (b). Given how we do not want to = write
"ACME", we = need some way to distingish the two (a)/(b).

Beyond = that, I am waiting to give the chairs time to figure out what they
think the dispatch answer is.  (As I said at the time, I = did not expect an
answer yet.)  And to talk with my = co-authors about what changes we think
make sense for the = issues we want to address even before dispatching.
(After = dispatching, the dispatching mechanism will help us determine what
path to take.  It will, I hope, become a community = document with us
responsible to abide by the rough = consensus.)

I am alway for community document, but of course (a) above is = primarily a
lawyer issue. = Community input on that part would be around scope for = example.
E.g.: which = legal requirements are in-scope. Why only anti-trust if = something
like EAR may = be an even bigger risk to IETF (no idea if this is true of course, = i
am just = guessting...).

The other problem with community consensus is that normal = IETF
process IMHO = only works for documents not impacting those not interested
in them (very simplified = statement). Aka: most technical documents.

For community rules applicable to all, we should add elements = to 
community consensus, such as = questionaires to really poll a much larger
part of the community. Given How you have "Mr Questionaire" = (;-p) as one
of the = co-authors, i'd hope we could count on him doing one for this
work, once it is in the best = shape for such a quiestionare from the whole
community.

There=E2=80=99= s a crucial point here that keeps getting missed - the *only* way that = the IETF can be put into a tricky legal position is by the behaviour of = participations and therefore the *only* ways that the IETF can 'defend' = itself are by distancing/disowning the behaviour of participants, and/or = by regulating the behaviour of participants.  If we assume for a = moment that distancing/disowning is insufficient (noting that some feel = it is sufficient) then we cannot separate out your a) and b) as you = propose.

I understand that you do = not see the linkage between each behaviour the draft recommends avoiding = and antitrust law, but do you really think you need to understand that = or is it not sufficient that one or more lawyers agree that these are = the behaviours to be avoided?  In other words, do you need to be = educated to the level of an antitrust lawyer by this draft?  Also, = for the draft to explain this linkage it has to go into the very same = level of detail that you argue against elsewhere.  

Rather than looking at this draft from the 'input' = side where we get into all the complexities of different laws in = different regimes etc, it=E2=80=99s likely more productive to look at it = from 'output' side, i.e. how does each of these recommendations affect = participation in the IETF?

Jay


Yours,
Joel

On = 11/13/2021 11:55 PM, Toerless Eckert wrote:
On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel = M. Halpern wrote:
I = agree with some of your proposals, and disagree with others.
But I do not see any of the actual proposals as substantive = enough to affect
the dispatching concern.  They all = seem things we can fairly discuss once
dispatching has = taken place.

Does that mean = the authors will drop and forget input her from the list that
is not marked as "unless this issue is resolve, i will not = recommend for this
document to be dispatched" ?

To repeat here on the list what i said during = the WG meeting:

I do not recommend for this = document to be dispatched until it is
clearer written down = agreed to, what actually the goal is. And i see two potentially
 even conflicting possible goals:

a) To put into writing sufficient 'Cover My Behind' = statements to protect
the IETF from legal action in case = participants partake in anti-trust
behavior. This is not = mentioned as a goal in the draft, but i have the
strong = believ that this must have played a role on writing this document.
And i do support such a document, but it should explicitly = state that
purpose.

b) A = document that is really intended to help participants to understand
how to not get into anti-trust law issues. This is what the = document claims
it wants to achieve, but quite frankly i = do not even understand the most
basic connection between = this goal and being an "IETF participant".

E.g.: what legal differences does it make for my compliance = (or lack thereof) with
anti-trust laws if my actions are = performed at the IETF or at any other
place ? Lets say = when i am getting together "privately for dinner" at an evening
of an IETF week with a bunch of folks i know who happen to = also attend the
IETF, and discuss exactly the same stuff = there ? Unless there are really
strange laws (which i = would be curious to learn about), i'd say the only
difference is (a), aka.: possible implication of the IETF = into legal
actions caused by its participants ("sponsoring = anti-trust behavior").

I also think that = for (a), we do not necessary need to add more explanatory
text (however unfortunate i would think that is), but if the = goal is (b),
and someone like me is supposed to understand = the guidance, then i'd certainly
be asking for more = explanatory text to be put into the document.

So, i really can't see how we can dispatch a document without = being clearer
about this goal. And if it is just me being = confused here, great, please
unconfuse me.
Cheers
    Toerless


-- 
---
tte@cs.fau.de

-- 
Jay = Daley
IETF Executive Director
exec-director@ietf.org

= --Apple-Mail=_CA7D9EA5-1008-47A3-AD7C-F5D0A260044B-- From nobody Mon Nov 15 09:08:35 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3403A0E2C; Sun, 14 Nov 2021 21:04:43 -0800 (PST) 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, 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 TTF7aK9gK9OW; Sun, 14 Nov 2021 21:04:38 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904DF3A0E28; Sun, 14 Nov 2021 21:04:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 63DBD4112A71; Sun, 14 Nov 2021 21:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QkqjxHUKETf; Sun, 14 Nov 2021 21:04:38 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id 2913D4112A70; Sun, 14 Nov 2021 21:04:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Mon, 15 Nov 2021 18:04:34 +1300 Message-Id: References: Cc: "Joel M. Halpern" , draft-halpern-gendispatch-antitrust@ietf.org, gendispatch@ietf.org In-Reply-To: To: Toerless Eckert X-Mailer: iPad Mail (19B74) Archived-At: X-Mailman-Approved-At: Mon, 15 Nov 2021 09:08:30 -0800 Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 05:04:43 -0000 > On 15/11/2021, at 3:53 PM, Toerless Eckert wrote: >=20 > =EF=BB=BFOn Mon, Nov 15, 2021 at 12:42:11PM +1300, Jay Daley wrote: >> There=E2=80=99s a crucial point here that keeps getting missed - the *onl= y* way that the IETF can be put into a tricky legal position is by the behav= iour of participations and therefore the *only* ways that the IETF can 'defe= nd' itself are by distancing/disowning the behaviour of participants, and/or= by regulating the behaviour of participants. If we assume for a moment tha= t distancing/disowning is insufficient (noting that some feel it is sufficie= nt) then we cannot separate out your a) and b) as you propose. >=20 > I was primarily thinking of "foreign country" lasws (aka: not USA and > not host-country), applicable only to participants even when overseas. >=20 >> I understand that you do not see the linkage between each behaviour the d= raft recommends avoiding and antitrust law,=20 >=20 > I don't think i said that. >=20 >> but do you really think you need to understand that or is it not sufficie= nt that one or more lawyers agree that these are the behaviours to be avoide= d? >=20 > I do not need to understand these rules if our lawyers agree this is neces= sary > and sufficient to indemnify IETF from actions of its participants. >=20 > BUT: if we want to go beyond doing that and really help participant interp= ret > how each of their actions does or does not meet the description, then more= > explicit examples/explanations would be helpful. >=20 > For example and as i asked in another mail: Do i stop being an IETF partic= ipant > for the purpose of indemnifying IETF when i go to dinner with other people= who also happened > to be at the IETF ?=20 >=20 >> In other words, do you need to be educated to the level of an antitrust l= awyer by this draft? >=20 > See above: no. >=20 >> Also, for the draft to explain this linkage it has to go into the very sa= me level of detail that you argue against elsewhere. =20 >=20 > Hopefully not. And as i said, the explanations may not need to be formal o= r > in the same draft. >=20 >> Rather than looking at this draft from the 'input' side where we get into= all the complexities of different laws in different regimes etc, it=E2=80=99= s likely more productive to look at it from 'output' side, i.e. how does eac= h of these recommendations affect participation in the IETF? >=20 > Of course. But to be sufficient for lawyers to be happy to protect the IET= F, > the draft will still be quite "abstract", e.g. no definition of exactly > when i am or am not an IETF participant. I'd call this output explanation,= > but input explanation. Thanks, I think I understand now. If we were to rephrase your a) and b) as a= ) minimal policy and b) expansive commentary/guidance then that makes sense t= o me.=20 --=20 Jay Daley IETF Executive Director=20 exec-director@ietf.org >=20 > Cheers > Toerless >>=20 >> Jay >>=20 >>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 11/13/2021 11:55 PM, Toerless Eckert wrote: >>>>>> On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote: >>>>>>> I agree with some of your proposals, and disagree with others. >>>>>>> But I do not see any of the actual proposals as substantive enough t= o affect >>>>>>> the dispatching concern. They all seem things we can fairly discuss= once >>>>>>> dispatching has taken place. >>>>>>=20 >>>>>> Does that mean the authors will drop and forget input her from the li= st that >>>>>> is not marked as "unless this issue is resolve, i will not recommend f= or this >>>>>> document to be dispatched" ? >>>>>>=20 >>>>>> To repeat here on the list what i said during the WG meeting: >>>>>>=20 >>>>>> I do not recommend for this document to be dispatched until it is >>>>>> clearer written down agreed to, what actually the goal is. And i see t= wo potentially >>>>>> even conflicting possible goals: >>>>>>=20 >>>>>> a) To put into writing sufficient 'Cover My Behind' statements to pro= tect >>>>>> the IETF from legal action in case participants partake in anti-trust= >>>>>> behavior. This is not mentioned as a goal in the draft, but i have th= e >>>>>> strong believ that this must have played a role on writing this docum= ent. >>>>>> And i do support such a document, but it should explicitly state that= >>>>>> purpose. >>>>>>=20 >>>>>> b) A document that is really intended to help participants to underst= and >>>>>> how to not get into anti-trust law issues. This is what the document c= laims >>>>>> it wants to achieve, but quite frankly i do not even understand the m= ost >>>>>> basic connection between this goal and being an "IETF participant". >>>>>>=20 >>>>>> E.g.: what legal differences does it make for my compliance (or lack t= hereof) with >>>>>> anti-trust laws if my actions are performed at the IETF or at any oth= er >>>>>> place ? Lets say when i am getting together "privately for dinner" at= an evening >>>>>> of an IETF week with a bunch of folks i know who happen to also atten= d the >>>>>> IETF, and discuss exactly the same stuff there ? Unless there are rea= lly >>>>>> strange laws (which i would be curious to learn about), i'd say the o= nly >>>>>> difference is (a), aka.: possible implication of the IETF into legal >>>>>> actions caused by its participants ("sponsoring anti-trust behavior")= . >>>>>>=20 >>>>>> I also think that for (a), we do not necessary need to add more expla= natory >>>>>> text (however unfortunate i would think that is), but if the goal is (= b), >>>>>> and someone like me is supposed to understand the guidance, then i'd c= ertainly >>>>>> be asking for more explanatory text to be put into the document. >>>>>>=20 >>>>>> So, i really can't see how we can dispatch a document without being c= learer >>>>>> about this goal. And if it is just me being confused here, great, ple= ase >>>>>> unconfuse me. >>>>>>=20 >>>>>> Cheers >>>>>> Toerless >>>>>>=20 >>>=20 >>> --=20 >>> --- >>> tte@cs.fau.de >> --=20 >> Jay Daley >> IETF Executive Director >> exec-director@ietf.org >>=20 >=20 > --=20 > --- > tte@cs.fau.de >=20 From nobody Mon Nov 15 20:48:00 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0073A0804 for ; Mon, 15 Nov 2021 20:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com 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 bjlcPUznU3ZT for ; Mon, 15 Nov 2021 20:47:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D2C3A0802 for ; Mon, 15 Nov 2021 20:47:53 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.193.60]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id 1AG4lIc1003264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Nov 2021 20:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1637038050; x=1637124450; i=@elandsys.com; bh=eekCzf5ACSWK3r3KSDQwymxXs6wChGlbs09m7kzFt7k=; h=Date:To:From:Subject:In-Reply-To:References; b=WVzZAg2OtXBwz5g4BAbFkzJ5kDQkeqsW7KXvBXZQqOMmeckSl3z0FHWRcCtnvtc02 133Z6bRW+Tmx059RU/5dmf8h72+Y8zYxad0TEbOEeuLJ7Oms6glXXQ5Vsrau0MIuAj 0PpkIAqhyZS4cWm6ZXzRrnGKioqVkjopx7J6un/k= Message-Id: <6.2.5.6.2.20211115202247.0ad123a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 15 Nov 2021 20:43:32 -0800 To: Toerless Eckert , gendispatch@ietf.org From: S Moonesamy In-Reply-To: References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 04:47:58 -0000 Hi Toreless, At 08:55 PM 13-11-2021, Toerless Eckert wrote: >To repeat here on the list what i said during the WG meeting: > >I do not recommend for this document to be dispatched until it is >clearer written down agreed to, what actually the goal is. And i see >two potentially > even conflicting possible goals: > >a) To put into writing sufficient 'Cover My Behind' statements to protect >the IETF from legal action in case participants partake in anti-trust >behavior. This is not mentioned as a goal in the draft, but i have the >strong believ that this must have played a role on writing this document. >And i do support such a document, but it should explicitly state that >purpose. > >b) A document that is really intended to help participants to understand >how to not get into anti-trust law issues. This is what the document claims >it wants to achieve, but quite frankly i do not even understand the most >basic connection between this goal and being an "IETF participant". I don't know what happened in the meeting. I'll comment on the above. The first goal is something internal to the LLC. The LLC was not expected to influence the Standards Process. However, it would be doing that through this draft. I agree that the draft does not help to understand the anti-trust issues. It is a bit like signing a document without understanding its potential consequences. Regards, S. Moonesamy From nobody Tue Nov 16 09:41:34 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267093A00C0 for ; Tue, 16 Nov 2021 09:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ISbDsAnL; dkim=pass (2048-bit key) header.d=taugh.com header.b=H/JxxSA2 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 mrNz00W_YtCH for ; Tue, 16 Nov 2021 09:41:25 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A1CEF3A0061 for ; Tue, 16 Nov 2021 09:41:25 -0800 (PST) Received: (qmail 52489 invoked from network); 16 Nov 2021 17:41:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=cd07.6193ed42.k2111; bh=wyU/KKqd0vrF/a2ZGRHK9ocmsErfVhoXCLetjU3lqCQ=; b=ISbDsAnLcfdRiMvjDiEYaOEkinQ64q/5jfpfgiF9nRlQHPuRXyTeOsmvJY35ef6dL1izmC/CGgr0/IKxAE6JTrDy9NCaafOTLYw/vNU1INKRCKXgA9T5AhBTsTOUICqADsu4KSARNY/jWt+dSAooKMhk0bwIVcXx4hfGGcHExvMR/IR0hemxKfyFQA5ZR4d7UyRi+D5HgDmAcpSMIxZzDl49kF1UzUPgtML07ZnhBTCHdXtpwbsbu5K8jy+QKXAlRiaTiMrXIFKmSt7x5R5Iq3Ep08mCj9KVM+TNGJk5w4o0/hseRkvenbi6Jk3k2oUc4L2LM4kwd7mHZbKB9ejNkA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=cd07.6193ed42.k2111; bh=wyU/KKqd0vrF/a2ZGRHK9ocmsErfVhoXCLetjU3lqCQ=; b=H/JxxSA2LHYFYytyZEJoslaZ13wrpUFI4S3xfDKXm1U6YC1ojKSSYWQsKqX+jVl6HUBssDqw3dsHvTjCi8QivDXYk3kX/UP0xv1MZuw0Ey/WTI+z3ij+fNKSun+gqnXgop7X/u8mNrn3ZAHk+HOrEtfteeT8UkriDFClVlrbpmxSbnaErHOuFF4y9eAPN4ybE8Pgfh0PSQmVBZ7FG8nBj7X6MBlap7BfyJjH1ROe7Mt8wC0HmBnAtev9DODRYICdVoKftUlb8X62vY7s+Q/7XQYz1kveWhmcrfgVTAtRhhlqm0UMv8GjtTRG3fyXswm0tmKGEMVAqIpvAxAiaHI+Zw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Nov 2021 17:41:22 -0000 Received: by ary.qy (Postfix, from userid 501) id C835C3003718; Tue, 16 Nov 2021 12:41:20 -0500 (EST) Date: 16 Nov 2021 12:41:20 -0500 Message-Id: <20211116174121.C835C3003718@ary.qy> From: "John Levine" To: gendispatch@ietf.org Cc: sm+ietf@elandsys.com In-Reply-To: <6.2.5.6.2.20211115202247.0ad123a8@elandnews.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 17:41:31 -0000 It appears that S Moonesamy said: >>a) To put into writing sufficient 'Cover My Behind' statements to protect >>the IETF from legal action in case participants partake in anti-trust >>behavior. ... >The first goal is something internal to the LLC. The LLC was not >expected to influence the Standards Process. However, it would be >doing that through this draft. It's not just the LLC. If we got into antitrust legal trouble the results might include fines, which would be the LLC's problem, but also restrictions on the way we operate which would be the entire IETF's problem. I do think the document could be clearer about what problems each part is trying to address or avoid. R's, John From nobody Thu Nov 18 12:46:23 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE603A0528 for ; Thu, 18 Nov 2021 12:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com 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 JD_GCa0coaQb for ; Thu, 18 Nov 2021 12:46:16 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5E3A040B for ; Thu, 18 Nov 2021 12:46:16 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.46.206]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id 1AIKjjlR027140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2021 12:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1637268373; x=1637354773; i=@elandsys.com; bh=e64PuzzscSvl9K580bNeW60ngGS8avf/r4Sb7CTmq00=; h=Date:To:From:Subject:In-Reply-To:References; b=prVxIgRo1aJ6PIjE8PPDF+0DvuhqoYf+bugAAtYTWu3mguqmVmKCfu9TgBEKS+4B+ zJD8igflWjDW+0xFoGF9eC2OEVySEoGbVpcHBKhRLm9kAORVAdyeIrJEZ7ShqP16U2 xybR1W8PWQxhecwJW0o1lO5o8N92hmILUl+4MeDk= Message-Id: <6.2.5.6.2.20211118121634.07f1c400@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 18 Nov 2021 12:45:12 -0800 To: John Levine , gendispatch@ietf.org From: S Moonesamy In-Reply-To: <20211116174121.C835C3003718@ary.qy> References: <6.2.5.6.2.20211115202247.0ad123a8@elandnews.com> <20211116174121.C835C3003718@ary.qy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 20:46:21 -0000 Hi John, At 09:41 AM 16-11-2021, John Levine wrote: >It's not just the LLC. If we got into antitrust legal trouble the results >might include fines, which would be the LLC's problem, but also >restrictions on the way we operate which would be the entire IETF's problem. The decision in 2018 was set the scope the of the LLC effort to matters related to the 4071 IASA only. It does not make sense to come and change that a few years later unless there is, for example, some potential legal trouble which was not foreseen at that time. I agree with the point you made about a LLC's problem becoming an IETF's problem. The "dispatch" approach is not well-suited for this type of problem. Furthermore, there was a concern about EAR. The topic keeps coming back. It is not a good idea to push the topic aside without giving any thought to it. Regards, S. Moonesamy From nobody Sun Nov 21 23:42:59 2021 Return-Path: X-Original-To: expand-draft-eggert-bcp45bis.all@virtual.ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8ACD43A0CFF; Sun, 21 Nov 2021 23:42:50 -0800 (PST) X-Original-To: draft-eggert-bcp45bis.all@ietf.org Delivered-To: xfilter-draft-eggert-bcp45bis.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65303A0CF7; Sun, 21 Nov 2021 23:42:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: draft-eggert-bcp45bis.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163756696977.16503.8399092079932602929@ietfa.amsl.com> Reply-To: Stefan Santesson Date: Sun, 21 Nov 2021 23:42:49 -0800 Resent-From: Resent-To: lars@eggert.org, gendispatch@ietf.org, rwilton@cisco.com Resent-Message-Id: <20211122074250.8ACD43A0CFF@ietfa.amsl.com> Resent-Date: Sun, 21 Nov 2021 23:42:50 -0800 (PST) Archived-At: Subject: [Gendispatch] Secdir last call review of draft-eggert-bcp45bis-06 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 07:42:51 -0000 Reviewer: Stefan Santesson Review result: Ready This draft does not have any security considerations text because there are no security issues to discuss relevant for this draft. I agree with this assessment. From nobody Mon Nov 22 07:28:53 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203613A0C05 for ; Mon, 22 Nov 2021 07:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=biddle-law.20210112.gappssmtp.com 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 Km2ir0HUDrdK for ; Mon, 22 Nov 2021 07:28:45 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48103A0C08 for ; Mon, 22 Nov 2021 07:28:45 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id x131so16435108pfc.12 for ; Mon, 22 Nov 2021 07:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=biddle-law.20210112.gappssmtp.com; s=20210112; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=LEE1k+QU88dCIsjv/xenc0MUdPn9HegR0U+LKwoZ11A=; b=yPUw8twwIFktJZGfkbSagg6LzxbS5WkLepW6pLGL3l84x3l9i6z7LLadyhCTOJato8 a7wvzX+j2U2IkhA+RK04Dxs0PzQVPeGP5QFZn5eDKHnfANClMF51UtUYrEQDzjisxfLc cKxA/rBgD+/nBcqCj1rJbZf5usVM3jOZLiVdhcVmOAgkUaVfDMsgWWkwI2oHWgI9Oqtu 8tB6dSL0Mi1mPj6spsudK11C6MYT4P+Tcocfnhfe70CbpqopiuxPRpvdhHez/wMi2Rcx Y0fnwX1uAlhyL2izqCL6kRpyvw8Nu19rZJ7SIMIKlwgZ2iXIpoJ3H3YL3J0A/Qrp86dS Vuig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=LEE1k+QU88dCIsjv/xenc0MUdPn9HegR0U+LKwoZ11A=; b=JMGgQW1klDMnzytdCggv5ceilpmXAT2md+1xnDO8CRqjMCb8XMfZRsuOkTaD+XxMK3 698KV3VzCWjHXo7ycpb9i57fxMuc+k2TBmYxU+9rDuFtLVvjNhczu9XzFvYsBq3pFsE6 Yl/MMoDI5IfLeUNHnURlpVwPTuH4Pk07/F02TaHr2oSJ42ggx+5MXm7EKnXyxa1zXV+J e7JhLU9TCFBEzsS6og0FDj9hlob/LDV8F/W8by1g1BzUMqwdVUFTMlhUybE3+05v1nim kzwav+RZUuJNyLBGMQHW+bBNq1Kgzi6AsNaspeDK8eJUzm5ZWted4MeXiidtb4ZHAZlp qXKQ== X-Gm-Message-State: AOAM5302X6R6u9061m+06JDmUEFE0L9HLgzj+oVUZZJnmE9xhSjQiI29 GogseoReD6cDXdEIufTuVCtByQ== X-Google-Smtp-Source: ABdhPJz+GXAMEX4QmYi+xdcRCQ7QdAqdF+fgMKmjlnrg5M/GiHcJz75VJI9kK2rKbO2uInvOh3IrxQ== X-Received: by 2002:a63:c00b:: with SMTP id h11mr27162578pgg.412.1637594924605; Mon, 22 Nov 2021 07:28:44 -0800 (PST) Received: from [10.1.10.188] ([2603:3004:301:fe00:9af:4619:ac4c:ffca]) by smtp.gmail.com with ESMTPSA id u32sm9683793pfg.220.2021.11.22.07.28.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Nov 2021 07:28:43 -0800 (PST) From: "Brad Biddle" To: "Joel M. Halpern" , gendispatch-chairs@ietf.org, gendispatch@ietf.org Date: Mon, 22 Nov 2021 07:28:32 -0800 X-Mailer: MailMate Trial (1.13.2r5673) Message-ID: In-Reply-To: <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 15:28:50 -0000 All -- for those who don't know me: I serve as legal counsel to the IETF. In the Gendispatch meeting held in connection with IETF 112 I was asked to provide my perspective on the need for the antitrust-related I-D that is currently under discussion. This message summarizes my thoughts. Risks related to antitrust law (or "competition" law, as it is known in many countries) inexorably arise in a standards development context. As a general rule, standards development requires cooperation between competitors. Antitrust law, which is designed to ensure robust marketplace competition, embodies a deep suspicion of competitor collaboration. While antitrust regulators understand the value of standards, they are wary of circumstances where the pro-competitive benefits of standardization could be outweighed by anti-competitive collusion or other behavior that harms market competition. Standardization forums are often the subject of investigation by antitrust regulators and the focus of antitrust-related disputes between private litigants. Standards development organizations (SDOs) manage these well-known risks in different ways. Many SDOs have explicit antitrust policies (although, interestingly, the content of these policies can differ considerably among SDOs). Many routinely remind their participants of the importance of antitrust compliance, for example by showing a reminder slide at the beginning of meetings. While these steps alone are neither necessary nor sufficient to achieve actual substantive compliance with applicable antitrust law, they are established best practices and are likely to be expected by antitrust regulators or others assessing the antitrust compliance practices of an SDO. The IETF currently has a robust approach to managing antitrust compliance. As discussed in an IETF LLC statement [1], the organizational structure and the processes and procedures of the IETF are particularly well-suited to mitigating antitrust risks. Further, we have a sophisticated body of participants who understand these risks and who readily raise concerns. IETF leadership monitors antitrust developments and has a well-established culture of compliance. Our current antitrust compliance strategy is solid. A critical part of what the US Department of Justice (a key antitrust enforcer) calls an antitrust compliance "program" is continuous monitoring and improving of our compliance strategy, however. Our current approach has the disadvantage of not mapping directly to the established best practices of having (1) an explicit statement about our antitrust compliance expectations, and (2) routine reminders for participants about the importance of antitrust compliance. I believe that it would serve us well to incorporate these practices into our compliance program, both because doing so would both in fact strengthen our antitrust compliance efforts and because the absence of these elements has caused misperceptions about IETF's commitment to antitrust compliance. Specifically, I recommend that that we develop an explicit statement that addresses antitrust compliance, and that we reference that statement in the Note Well text that is routinely shown to participants. The substance of our explicit statement can be straightforward, essentially just highlighting how our existing processes and procedures are designed to mitigate antitrust risks and setting our expectation that all participants will abide by applicable antitrust laws. We will circulate an updated I-D that embodies this simple model shortly. I understand that some in the IETF community would like practical, detailed guidance about how to comply with applicable antitrust law in particular circumstances. My suggestion is that we discuss this need separately and address it in educational materials that would exist separately from the antitrust-focused I-D. Please let me know if any additional clarification would be helpful. -Brad [1] https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/ Brad Biddle | brad@biddle.law | +1.503.502.1259 (mobile) | http://biddle.law On 3 Nov 2021, at 8:37, Joel M. Halpern wrote: > This is a significant revision of the draft on IETF antitrust > guidelines. We tried to address what we heard in the previous > feedback, and tightened the language related to legal issues. > > Chairs, if it is possible I would like to present this for dispatching > at the upcoming session. > > Thank you, > Joel > > > -------- Forwarded Message -------- > Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt > Date: Wed, 03 Nov 2021 08:15:16 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Antitrust Guidelines for IETF Particiants > Authors : Joel M. Halpern > Brad Biddle > Jay Daley > Filename : draft-halpern-gendispatch-antitrust-01.txt > Pages : 8 > Date : 2021-11-03 > > Abstract: > This document provides guidance for IETF participants on compliance > with antitrust laws and how to reduce antitrust risks in connection > with IETF activities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch From nobody Mon Nov 22 08:37:56 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D74F3A0C7C; Mon, 22 Nov 2021 08:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cs.tcd.ie 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 L5xtBUCJvomp; Mon, 22 Nov 2021 08:37:49 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::713]) (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 64E363A0C7B; Mon, 22 Nov 2021 08:37:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J+56pa7LNJ59NQNg8xq9PXnrtzNrjwWlOaSz5LduMFluND7+a/yPLxPx7Ag4MVuXHoMDTVpRPfiJE2esiIt2ka3iwEz/3C+iJ059NotyQrpfCxii1zWyDGm4nUm+aQsBkyqlB7CxTbK9Xgg8/6eEDyrCmUPVyEAEwKf736kHbYU6RGWNJ7OXogx32ZV6tap3y2W5Pz1ktGVK10NHB4DvrGHEpnvC7bGb8OkPZh1WFiWV8BpEMLvYXoVdRUbh1xguatJxBZZ2WmacFy1ULx9onZkh4Qk0HR0KnnBBMcctqLHGVUPYhQfsXgMCiE85YTJPOQP9oE05QK0vMkG3bFcYJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=glQAZ+g+4VlWLUr0OyPYetpmaVFFSTTzesFrCdcBGVc=; b=KLPXCI4DEU+SP4/utjv70juEOZPnChXv4RuY2c7MyeJRyvjobnpFpVWlmRTrTXNtx7Xh61Uf2Oyrt6lmXeVO8yj2u25zG/C1n0ofgo9XcOwzQ47WaFyswStsCbLBvELtZM+rOgi2o5uMeePJjmRaeU4gn69nxyq9NmdMi3b3gDAs62/RyR9+gnPbLJq2+lXzK1GjI0sRlbsGXamdjqSL5Ln04uI1xMets8FeKO45DF6754e5klAL+APhA8054YLfcNCLBMXPUPCQsoS6Ux1ZzX+jbxPavopAYUcN0LSwOaW7fiNxXDmm3vpaY3aVlhioGtP3OS33Yx95sC/uyIlwGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=glQAZ+g+4VlWLUr0OyPYetpmaVFFSTTzesFrCdcBGVc=; b=c6QuTS8lAmJl+jHtCgzimwn6S6oYc/D7SnWOkmOIS4dfd8leL3176Yxdyzbs66bzqdKbdyPQcao8DzP3vqRa2kEGxph37oPdcjwxFYS9AhxdzzHzrfGQf+7/qMUmO7AxdPgchIPHX/GHshAPi4pAVRoiR4PxYOUkiZaBdgKr0ELVfpQBur8jW0R8M2FAgo/+26W8koMdO+b/9xjphHzXxVsWCXl/PkdpbAnD6TGh9SF9rYPfq9zZtsaNLRPjTf23+KdlfnjWEY5terbwKmYotoUSl4MB/nRy0EeO3qEMxBNWtVNnGnxoehXupQZKBNYXajUDuH6p1d0PPvQyx4L5lQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB8PR02MB5642.eurprd02.prod.outlook.com (2603:10a6:10:ef::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.24; Mon, 22 Nov 2021 16:37:42 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4713.024; Mon, 22 Nov 2021 16:37:42 +0000 Message-ID: Date: Mon, 22 Nov 2021 16:37:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Brad Biddle , "Joel M. Halpern" , gendispatch-chairs@ietf.org, gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> From: Stephen Farrell In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------pEf1JDazK4jNBGlId77RC0WG" X-ClientProxiedBy: DB6PR0801CA0054.eurprd08.prod.outlook.com (2603:10a6:4:2b::22) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPV6:2001:bb6:5e5e:b458:7202:bc69:f7a7:9617] (2001:bb6:5e5e:b458:7202:bc69:f7a7:9617) by DB6PR0801CA0054.eurprd08.prod.outlook.com (2603:10a6:4:2b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19 via Frontend Transport; Mon, 22 Nov 2021 16:37:41 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a3ee96f2-19cf-4a32-72d6-08d9add66769 X-MS-TrafficTypeDiagnostic: DB8PR02MB5642: X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:2000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3Vh1B1qOhKx7m6IwAPuBg/I36nC/ebl6Bs6Dv9PSIhN6pIT1q5s3WLQEgyVj8TXUih5ie5cQBnuGo0DppeI3VKbJRxcGPGaYNeizNUI9o060+XGhwg02t92Wnd2v3G+bEYs6Popx08ocrbp/JvfiizaCaBNOltnhvZ9o4mKApivaX/Q8nJe/WS2tXDFO3K3YylQo5R+DU8wMkuboJt4epRJBEd4DXh8KHcmBCNDt/70bMRGW0vSh7b/6lLKbfgPysyuYZ1MAEwqezDzi/grZn2UD/wgap3R005tQEiQx1GV/iAjQqvACrCBRUMx0FHu756rELMAAQbJXz2DnfTJTqQ/v/Z2O7X+qeovZwPEq+nVs0w059JZQTqW5uefUa5ilK/J8mpIIuRLQ9lxP/05l2faBRoSuRcCkFRqWT2Tg+5S9URPor/1sDdirxzlBLcZ3q8rpOvrT9Li2eyjbvRKi1iEHv2TOrgUht6kwXKnygp4HV08RQ//MrEFtTDIxsLQntSTtsPiDZX17edbu26g64teClmXHUXKHTyB4ifCl4E9hjlR4BjECddXKDyAhbKpmOXxvrX1VFlVEVaYgWyhh5TLn6ig+D8GV/5Y3k6zUs56UaH2CIHEYbazYAJio832V8IjOYPf7U2eWaiyQeK/KyA0hK9jIh6mKXvRV6HdMXFETvAiFQ6ksNbEaETbjUFPdjOiG/UVJJQAMze51SY3C88iexECPI2G2fGgn6ZI7JU76jFDXzMRV7P4STI2Gsd1D X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(8936002)(86362001)(2616005)(44832011)(83380400001)(5660300002)(8676002)(38100700002)(235185007)(186003)(33964004)(508600001)(53546011)(21480400003)(31696002)(66946007)(36756003)(316002)(110136005)(66556008)(66476007)(786003)(31686004)(6486002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NnJSUXZmRjkycXU3L3BYaUN2U05jQWNVK0NubllGb1ZLa0VucHd1RGhibVhE?= =?utf-8?B?Zk0xNmVyVWp2MFdKanlRVTl4cTFMaWVaV0tLYnNybjZVTGZoVUVuUlN1VXpI?= =?utf-8?B?NjhEckVTZWF0WE5IZGd5NnJWREk3UHgzc0NBUlkvZWwzRTI4MXgzbWtBbUM1?= =?utf-8?B?Mm5mV2NYdUNhWVF3NHVERGtQMllBamFycVR2Z0RFUGVxQVFwcmJ1WXd0YTJT?= =?utf-8?B?ajhSWUxLT1JWZDF0b0ZVL1lZaWRrVUh3YUVrUFQrRGpVeHk5dUp6QWF4MUF2?= =?utf-8?B?T09HZFZXQlIzWnhSdUxRWWVzL1htMHp5U3NVS1lKdy9OTmhzbXVsUDNWK1k0?= =?utf-8?B?c1ltNERCZDZFTFRJVzgzSVN0YlNRWU1ZeENpL1owV2lhTy9ObXBsWDVBeTN5?= =?utf-8?B?d2JKbWk2RFJGc3JmQUNDOUQvR3BqR2dwcGcxaVFleVZHdWY5c0xUWGtuVUlp?= =?utf-8?B?RWJoZkZtWUVsWlVIWWdHdWxiNU41MTNud0h6TWdMSTF5KzFCN3VZaW0rZUha?= =?utf-8?B?LzVGU1FiRkZ0OWhPd1U0NU9uT3NCUTZWa2kySGt5ekQxRzZPbTdTYm53bkZZ?= =?utf-8?B?U2xCNlhKbjZQcXkrSXUxY3I1V0R4a1NTUVZJcCtOWTJCTHV2eU5Vb1lUNEdz?= =?utf-8?B?RDFVQ05hWmZpTndzYm1ZYTB3UzFuQ2t0N2NaRTJoL1dqcThuWWx0d3YxN3BE?= =?utf-8?B?bFFuVGhTRGRhL3RmRlE0dnNSV213TXZMNzV4VG05dVI1UTNkZUtMdDIybXQv?= =?utf-8?B?Nm5CZHd0aDR5c0prYml4c0I3UTdGRHhiUkkyL2dUbCtqbURlQTNGUnVqVGZP?= =?utf-8?B?dUFDRGJROC9JM2pPZUpuaHVNQjF1WkFBKy8yc3cyODYraURWMlpQRmY0REts?= =?utf-8?B?Yko3blMwZXpzTVdxVDh3aWU4RnZkOFpMY0t5ZC9WaXh6UVYraGdHaXFBNmNO?= =?utf-8?B?WEpaQm03a2FyYTJ1aXp4ZFVhNlBIbkltazdqZllUbDVEMGZHWEt1Rk5jWlRL?= =?utf-8?B?Y2Q4STRjcVYvb2RHRXY2UDVRWHVtdnV2d1pnZmt0enlxZmY4ODAzNmhQb2l2?= =?utf-8?B?REdHN2FEckpaK09MTjV5Q1JoczdmWmxJZ3hHd3o1Yk5wdnNzOTQyaWE4dzZX?= =?utf-8?B?d2FIRU1FTVNqYnU5N3lBZTl6cGlSWm5OdzVoNTlJdzlxTDl4bEJLVlpRcnE3?= =?utf-8?B?YW1KZ1lJRXM0b2lLbDkwdUpyVUZkZFM2cmo1dDJDSERnM3RSaXVsd1d0QVlG?= =?utf-8?B?cGs5RXFENGlnam9sU3Z3MHB2MkpsVCsyOEZ0bDFnQVdDNkVZR1FleHdDWDhu?= =?utf-8?B?Z0J2b1REb21NNkx4V1B6TS9xcGxjRk9Gd0Z0cXB6S2g5R1dnbzdSQjlrTXRX?= =?utf-8?B?YjNiRDluNWRiMzBjK3VKaHRvSGNYOGlQR3VOM1RtZzNvS085WmJ2bkxOTjV0?= =?utf-8?B?ZkFldEp4dEVuTk9PZHpUNmEwcUs4dHc1bDZkemtrbU9OanE3alBDSmM1Ym1G?= =?utf-8?B?WmsvZ1lmNHYydDhUQzJrMVFGMzVKYlhFTmFLQlJPQS9jYWxxVFZvZHlTVGtt?= =?utf-8?B?c0NTMGhTVks0M05zNUtCTHN3OGRDSm8wQm4yN3lCVnpKNVlEYzljTTY0L3JO?= =?utf-8?B?Wm04bmpFeEk0N0gzZUZ2YXZib2RmeVh6SzU4QjlaOW95ejkxUUxya0Evc1dE?= =?utf-8?B?RE55QTE4KzJYeG9XcXl3dm0rb3E2b0F0bWNteUNzTUdYT2QyR2xOS0JZUk54?= =?utf-8?B?TXhZMUptbWdHMTZXWnZ3ckkzOXkwTklwbHhNdE1IMkw5V2I0ZDhGNEhXSTlY?= =?utf-8?B?K2VSeVFZcTBzZzhLK0NaOXZuckVPNUhKd2Nsbkd4TGdhbHhJblp6czZHUVdB?= =?utf-8?B?LzNHa3NtZkpyWlRUeVhGVGVRVmEyaDBEc1h2QUw2SjNsaHFzOGtJcTZ2OExw?= =?utf-8?B?N3hpVHNhSWtONk1YTVZrZFZ0SmowUWJRSllhWStSSkY1dzhEN3JYcW1KZHl0?= =?utf-8?B?ODk4OHJZUW82ZlQ3cjY5YUNDTGdqQzZVakd2djlsamJtLzFRcENsMkZkYzBl?= =?utf-8?B?SVBFQmpNaTlaRzhGMTBPNEIyNUlTeEFyeFRIQlNYT0tTQ01LTDMvN2Z6eWky?= =?utf-8?B?OXh6VTVpTVZaMldwazBlV2tuUEp4YmduRjhidkU1Wit1RncwSjZEZ09ic0pG?= =?utf-8?Q?pUSFIzTwxCrjevivyV2AnVk=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: a3ee96f2-19cf-4a32-72d6-08d9add66769 X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2021 16:37:42.0565 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: uAFuBv8FosfsvTNzKMajhUCjjG3bVxbxOx6TvIEGhyIBJS9CRrEH7lo7bD8qUo9Q X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5642 Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 16:37:55 -0000 --------------pEf1JDazK4jNBGlId77RC0WG Content-Type: multipart/mixed; boundary="------------EVjjoT21NEW0H3YD9QTE0Q1P"; protected-headers="v1" From: Stephen Farrell To: Brad Biddle , "Joel M. Halpern" , gendispatch-chairs@ietf.org, gendispatch@ietf.org Message-ID: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> In-Reply-To: --------------EVjjoT21NEW0H3YD9QTE0Q1P Content-Type: multipart/mixed; boundary="------------qjMbz0shfGy6qUy70XTSL4GO" --------------qjMbz0shfGy6qUy70XTSL4GO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpIaSwNCg0KSSdtIG5vdCB0aGF0IGNvbnZpbmNlZCB3ZSBuZWVkIHRvIGRvIGFueXRoaW5n IGJ1dCBubw0KaGFybSBoYXZpbmcgdGhlIGRpc2N1c3Npb24sIHNvIHNlZW1zIHJlYXNvbmFi bGUgZm9yDQp5b3UgYW5kL29yIEpvZWwgdG8gbWFrZSBhIG1vZGlmaWVkIHByb3Bvc2FsLg0K DQpPbiAyMi8xMS8yMDIxIDE1OjI4LCBCcmFkIEJpZGRsZSB3cm90ZToNCj4gSSByZWNvbW1l bmQgdGhhdCB0aGF0IHdlIGRldmVsb3AgYW4gZXhwbGljaXQgc3RhdGVtZW50IHRoYXQgYWRk cmVzc2VzIA0KPiBhbnRpdHJ1c3QgY29tcGxpYW5jZSwgYW5kIHRoYXQgd2UgcmVmZXJlbmNl IHRoYXQgc3RhdGVtZW50IGluIHRoZSBOb3RlIA0KPiBXZWxsIHRleHQgdGhhdCBpcyByb3V0 aW5lbHkgc2hvd24gdG8gcGFydGljaXBhbnRzLg0KDQpJZiB5b3UgZG8gZG8gdGhlIGFib3Zl LCBwbGVhc2UgdGFrZSBpbnRvIGFjY291bnQgdGhhdA0KY29tcGV0aXRpb24gbGF3IGlzIG5v dCBhdCBhbGwgYSBkaXJlY3QgaXNzdWUgZm9yIGEgbG90DQpvZiBJRVRGIHBhcnRpY2lwYW50 cyBhbmQgd2UgZG9uJ3Qgd2FudCB0byBldmVyIGdpdmUgdGhlDQppbXByZXNzaW9uIHRoYXQg dGhvc2UgZm9yIHdob20gY29tcGV0aXRpb24gbGF3IGV0YyBpcw0KYSBkaXJlY3QgaXNzdWUg YXJlIG1vcmUgaW1wb3J0YW50IHBhcnRpY2lwYW50cy4gKEZvciBtZQ0KdGhhdCdzIGEgcmVh c29uIHRvIG5vdCBwdXQgdGhhdCBpbiB0aGUgTm90ZSBXZWxsIHRleHQNCndoaWNoIGlzIGFs cmVhZHkgZ2V0dGluZyB3YXkgdG9vIGN1bWJlcnNvbWUuKQ0KDQpDaGVlcnMsDQpTLg0K --------------qjMbz0shfGy6qUy70XTSL4GO Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------qjMbz0shfGy6qUy70XTSL4GO-- --------------EVjjoT21NEW0H3YD9QTE0Q1P-- --------------pEf1JDazK4jNBGlId77RC0WG Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmGbx1QFAwAAAAAACgkQWrL68XsXK+r2 sBAAiBMvjA4DN+1U051ividPbbU+F+VSCltVlawjogi0Bo/6EnjURGm2+tcgF+CPNjxioe8UZNZd LSztY4330IElL8Uj2praYc7uW+YUo1PhAiX9b4bAHMYiwaVROp3w7PIqQOOKgDFNMfgUh8bmmGyW u+0XUeac+M80g0jmwucpIkpBzWWbk6gLM3k5kr0Df9APguCV/dJp2VzUhoEleScYsHS7e2nQ4PEo XTEh08WZHOuCsYAuWRvT0T4I2kyPn8TQNyYU/bbjPDsikXFIPKXMSRdL62WMsPYSKw6TaGymqMqu NlVsRZXMUDYbfDFIg2p1FSBFfL0LILvuNhAYtMGaV+HhhumKg7qsDAmG9uZEYpMx3QsNnkecqwVU SG3/aHQdrI7oAVP8IRykWxZ1X2fPcUNm48xv/s9B+SP/ow1jjAS2JsTd71mOKfwgVXZ8PonkGqlz AWHslXgukAqNM2Hix8uE9gB5TlWvuQDlXnjDpqJ3a5PSkLXgbBCaK/zJRXAeGINGp9D9PPpSiOA7 krYSzjIL8ED/XAbU45HB4hEZ6Yf4DFTXnY5/BCCxWzTt9HpdosVcrOo2qeA2ZR/kHhFtPiYsL+rH Betcz1zsnOX+W3kc4vyqfoSRTpPOOatNH6FED7laD4kGk940eLvRvDbFTGx+7YJBjbOH9ODPpiPu VmY= =kTq3 -----END PGP SIGNATURE----- --------------pEf1JDazK4jNBGlId77RC0WG-- From nobody Mon Nov 22 08:45:34 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0C3A0C85 for ; Mon, 22 Nov 2021 08:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Ry1v3Fzo94f7 for ; Mon, 22 Nov 2021 08:44:43 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 D42A03A0C83 for ; Mon, 22 Nov 2021 08:44:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HyY5l3bSmz1nv1p; Mon, 22 Nov 2021 08:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1637599483; bh=BpyxjW4E4ONuu9ZmglOWVoTein58lJrES3IUPtUs8l4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=ELIxNmUeLDIu4ov+lNXq0cSWqCV9VwPfRasQ8hsHQed2TYq+DIWldBzDiN0U5JrGR 7jh4V6pX5T5m73hW3alMWPB0KP7RCyMWo7oSOdiGZrpQ/8Swpvz88y3+P4QSnrRIb+ NlezWXs/gZnV6hdMstkPsK2mnP6QWFLad8ZGh3+4= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4HyY5l09KVz1nsXf; Mon, 22 Nov 2021 08:44:42 -0800 (PST) Message-ID: Date: Mon, 22 Nov 2021 11:44:41 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Stephen Farrell , gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 16:44:49 -0000 While there are some participants for whom competition law is not an issue, there are many participants for whom it is an issue. The intended approach is a short statements that highlights a very few aspects of competition law that should be kept in mind by anyone to whom they apply. From where I sit, it is important to have the note well pointer as it is very difficult to claim we as a community have made an effort to inform people about the issue if we bury the results in an informational RFC no one ever hears about. We (the co-authors) are still trying to work out the wording for the much shorter approach. Yours, Joel On 11/22/2021 11:37 AM, Stephen Farrell wrote: > > Hi, > > I'm not that convinced we need to do anything but no > harm having the discussion, so seems reasonable for > you and/or Joel to make a modified proposal. > > On 22/11/2021 15:28, Brad Biddle wrote: >> I recommend that that we develop an explicit statement that addresses >> antitrust compliance, and that we reference that statement in the Note >> Well text that is routinely shown to participants. > > If you do do the above, please take into account that > competition law is not at all a direct issue for a lot > of IETF participants and we don't want to ever give the > impression that those for whom competition law etc is > a direct issue are more important participants. (For me > that's a reason to not put that in the Note Well text > which is already getting way too cumbersome.) > > Cheers, > S. From nobody Mon Nov 22 14:54:01 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5DA3A08B7 for ; Mon, 22 Nov 2021 14:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=kZ6hUJT6; dkim=pass (2048-bit key) header.d=taugh.com header.b=gU+jy5by 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 DYZv-IxGxTzl for ; Mon, 22 Nov 2021 14:53:54 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 938173A08B2 for ; Mon, 22 Nov 2021 14:53:54 -0800 (PST) Received: (qmail 99709 invoked from network); 22 Nov 2021 22:53:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1857b.619c1f7f.k2111; bh=9r5/BAMJIjEShutpnFUAIY+eAU8nyebKCuNphluswh8=; b=kZ6hUJT6SXF/Nz23L6CcCF+r/p2316aUlimQFYE19JZ+UG2srHnxxRzFaMb0kj2MhclvvdpsO6IqqxggS5hNb/8DKHIrOrwmnQT9BDvjUpsYFvsiPYHzHxL1SHxYQ+pqOYevOPvysONjWfSAeXRJiCpbJDZ7ANKlarcGaszheSKZk4ozfP5NTf1TzJnXWDEx2c93czvCflniWwXsXglaAboSCDx8kMYiylfWyLgiqjl8ouxDfNRQDoYXCQ9zKB5Sj/eHBuKRDiVIih3s+TWewjODAEBVupzNXV4NSnhtBUyzJu8KUAhSljMN0oLFhhPQb8MzDezTFRh+RY/ELUN8qw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1857b.619c1f7f.k2111; bh=9r5/BAMJIjEShutpnFUAIY+eAU8nyebKCuNphluswh8=; b=gU+jy5bySq6eeUZbHinpv9+wyjwHClQyxTjg359JyeOSBnQAIQcpQjk/y7IV7uhBwpnFlx7eV7GuWk6z2eHlNc+7+cer5FKVXSYOznANPE1Mn90ctBkv5p4o1ZB4JgleHD67CPFiv97TfeNKAo6DPCxog2GAuCx17FDk8Lrc3RALdTqtfiobQillnChGW2KJduHWgZVVjpxOM4wwKP2ljVP6Dc0KZF4Ao5ca2kZHGia2AkrorrGFYu/3EInOf059yMlUK0M1H0wLwrCywlrADLQtweKiNdraFXDm63Rhsqtf6G8/w2ZwEqUUsn6FmdCk3teZaBLy0TWG+u9nnvb0+A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 22 Nov 2021 22:53:50 -0000 Received: by ary.qy (Postfix, from userid 501) id 56F153072E9F; Mon, 22 Nov 2021 17:53:50 -0500 (EST) Date: 22 Nov 2021 17:53:50 -0500 Message-Id: <20211122225350.56F153072E9F@ary.qy> From: "John Levine" To: gendispatch@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 22:53:59 -0000 It appears that Joel M. Halpern said: >While there are some participants for whom competition law is not an >issue, there are many participants for whom it is an issue. Regardless of whether some individual IETFers think it's a problem, if we got into a situation where the US or EU were sending us subpoenas or asking detailed questions about our practices and looking for suspicious comments in the mailing lists, it would be a problem for everyone, no matter where you live or who you work for. I agree that a minor update to the Note Well seems like a reasonable approach. R's, John From nobody Mon Nov 22 15:19:37 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE83A0909; Mon, 22 Nov 2021 15:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nVSfTAqR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JQADkEDr 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 fgmmCGTl2r2d; Mon, 22 Nov 2021 15:19:31 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4559B3A0904; Mon, 22 Nov 2021 15:19:30 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 205473200A3E; Mon, 22 Nov 2021 18:19:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 22 Nov 2021 18:19:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=F W+9bBLuw0AMnFCFm9Cs5gZJ3t0w/oKXmGQiGzDBGlc=; b=nVSfTAqRe17bHHWid myK2ndQc3EAEse1PG1uXbkAE6wImwwbfpKTZZT6y4BaBWj1dxMYX2EJgDvJuu6To waYEOVXsDWlNBGi0NmqIdSl0K+qaTrAnzos+mBDxqFnYjhCx2xAhq6NEej3QXgm5 2S3RfVw4lsPIM0FO8Y2wtwEeXR2PCx2B7WApgqJIhoRbAGpQpsFntN5yUE6BdDuY Y+8laoBu2dX/C25yYgYVipcAQnRNRLSr4+Xd59Sh/K9zL/C0+vOrDARNzBitgTZq cB/yL8fyE1LQBGWjZQtrOlGqEq0ffDfauMOX8j5UVY4lyrqJMAljOY+pgDeILI/P QwVew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=FW+9bBLuw0AMnFCFm9Cs5gZJ3t0w/oKXmGQiGzDBG lc=; b=JQADkEDr5CewnA46TU6asji7qHPLVc0R5OMamztlCBpKTPbpCLwyVyC3f R3JduB5Nq/jUtClVH3hkTdPW9mX+yms36fjh9NTAtqkF+F5mJpdrpFBvcXuH0sOP s7yDaAVujYPdEvqnRIaK96TXepqf969InyCtlVxCQxYTgU0fexCneQAQDh1GYzSJ 85Joh3gOfdOKzh38naVBshJianLUj8LNX92QI6apiqz0IdQlR+rkxWSOep3ocy8x k53iDUoZo8r+YDwtJ26VmUJWyniUCYIT+7tiu4b1dI8h9k7fbVl0cl4rxREZ3h6i Ky/RY87EQIxSXJeBoJ07pPLifTnLw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrgeehgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepleeugedtvdelffdvfeekudethfegjedtvefgffevvdfhjeeiveekuddtueelkedt necuffhomhgrihhnpehivghtfhdrohhrghdpsghiuggulhgvrdhlrgifnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdr nhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 22 Nov 2021 18:19:24 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Mark Nottingham In-Reply-To: Date: Tue, 23 Nov 2021 10:19:22 +1100 Cc: "Joel M. Halpern" , gendispatch-chairs@ietf.org, gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> To: Brad Biddle X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 23:19:36 -0000 Thanks, Brad. I think this is the right framing, FWIW. Related but tangental question: Does the IETF have any particular reason = for not opting into protection under the Standards Developing = Organization Act of 2004 in the US? Last time I looked at the Federal = Register, we were nowhere to be seen... Cheers, > On 23 Nov 2021, at 2:28 am, Brad Biddle wrote: >=20 > All -- for those who don't know me: I serve as legal counsel to the = IETF. In the Gendispatch meeting held in connection with IETF 112 I was = asked to provide my perspective on the need for the antitrust-related = I-D that is currently under discussion. This message summarizes my = thoughts. >=20 > Risks related to antitrust law (or "competition" law, as it is known = in many countries) inexorably arise in a standards development context. = As a general rule, standards development requires cooperation between = competitors. Antitrust law, which is designed to ensure robust = marketplace competition, embodies a deep suspicion of competitor = collaboration. While antitrust regulators understand the value of = standards, they are wary of circumstances where the pro-competitive = benefits of standardization could be outweighed by anti-competitive = collusion or other behavior that harms market competition. = Standardization forums are often the subject of investigation by = antitrust regulators and the focus of antitrust-related disputes between = private litigants. >=20 > Standards development organizations (SDOs) manage these well-known = risks in different ways. Many SDOs have explicit antitrust policies = (although, interestingly, the content of these policies can differ = considerably among SDOs). Many routinely remind their participants of = the importance of antitrust compliance, for example by showing a = reminder slide at the beginning of meetings. While these steps alone are = neither necessary nor sufficient to achieve actual substantive = compliance with applicable antitrust law, they are established best = practices and are likely to be expected by antitrust regulators or = others assessing the antitrust compliance practices of an SDO. >=20 > The IETF currently has a robust approach to managing antitrust = compliance. As discussed in an IETF LLC statement [1], the = organizational structure and the processes and procedures of the IETF = are particularly well-suited to mitigating antitrust risks. Further, we = have a sophisticated body of participants who understand these risks and = who readily raise concerns. IETF leadership monitors antitrust = developments and has a well-established culture of compliance. Our = current antitrust compliance strategy is solid. >=20 > A critical part of what the US Department of Justice (a key antitrust = enforcer) calls an antitrust compliance "program" is continuous = monitoring and improving of our compliance strategy, however. Our = current approach has the disadvantage of not mapping directly to the = established best practices of having (1) an explicit statement about our = antitrust compliance expectations, and (2) routine reminders for = participants about the importance of antitrust compliance. I believe = that it would serve us well to incorporate these practices into our = compliance program, both because doing so would both in fact strengthen = our antitrust compliance efforts and because the absence of these = elements has caused misperceptions about IETF's commitment to antitrust = compliance. Specifically, I recommend that that we develop an explicit = statement that addresses antitrust compliance, and that we reference = that statement in the Note Well text that is routinely shown to = participants. >=20 > The substance of our explicit statement can be straightforward, = essentially just highlighting how our existing processes and procedures = are designed to mitigate antitrust risks and setting our expectation = that all participants will abide by applicable antitrust laws. We will = circulate an updated I-D that embodies this simple model shortly. >=20 > I understand that some in the IETF community would like practical, = detailed guidance about how to comply with applicable antitrust law in = particular circumstances. My suggestion is that we discuss this need = separately and address it in educational materials that would exist = separately from the antitrust-focused I-D. >=20 > Please let me know if any additional clarification would be helpful. >=20 > -Brad >=20 >=20 > [1] = https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/ >=20 >=20 > Brad Biddle | brad@biddle.law | +1.503.502.1259 (mobile) | = http://biddle.law >=20 > On 3 Nov 2021, at 8:37, Joel M. Halpern wrote: >=20 >> This is a significant revision of the draft on IETF antitrust = guidelines. We tried to address what we heard in the previous feedback, = and tightened the language related to legal issues. >>=20 >> Chairs, if it is possible I would like to present this for = dispatching at the upcoming session. >>=20 >> Thank you, >> Joel >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-halpern-gendispatch-antitrust-01.txt >> Date: Wed, 03 Nov 2021 08:15:16 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Antitrust Guidelines for IETF Particiants >> Authors : Joel M. Halpern >> Brad Biddle >> Jay Daley >> Filename : draft-halpern-gendispatch-antitrust-01.txt >> Pages : 8 >> Date : 2021-11-03 >>=20 >> Abstract: >> This document provides guidance for IETF participants on compliance >> with antitrust laws and how to reduce antitrust risks in connection >> with IETF activities. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ >>=20 >> There is also an HTML version available at: >> = https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.htm= l >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-halpern-gendispatch-antitrust-01= >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> --=20 >> Gendispatch mailing list >> Gendispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/gendispatch >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch -- Mark Nottingham https://www.mnot.net/ From nobody Mon Nov 22 15:30:35 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A743A095C for ; Mon, 22 Nov 2021 15:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NBDdBmkZ2oIo for ; Mon, 22 Nov 2021 15:30:30 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10903A094B for ; Mon, 22 Nov 2021 15:30:29 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id t19so41009334oij.1 for ; Mon, 22 Nov 2021 15:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1gTKcfrQzyZxLwXc/GS0YjeBrMnvGtJn/7CjaWnAk9A=; b=U13I6Whp3tgrwnycyRKz8BuxzSCucdBtnXOF7bVeEjIS50Qbqb3EDvM1msHOPl8MoY lo8+1h02Uai4+/113Mm4sEdYmXupD5BOrYnb9uCkq+ypM4sdWb7oqCy1Ow7BAoEqCGnd izmNEUn6bSGy+Mn9PBn63Hw3+KnYKMSI3uXy9dRDfv8kaOGyeAauTVkUx6aiThMcR2+u /KbNrBcZYXddQ60hMSBso+DVmdQnVkOTYYeqC/RBwJNkacqOQ/KIPy+MljgSmYcWt+MC lrTmifZAwDbhDYxsXDKzPfhSyxqGQj6ccrUedWFZEMKz0o8VU7YBYl1uErLiQ/kZn2oh 81YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1gTKcfrQzyZxLwXc/GS0YjeBrMnvGtJn/7CjaWnAk9A=; b=Z7s7BvCsVqvVyNkNbbf2s458aeDdRbL0gU8UFMjhOE9aLR6/XFro5vBX5NS0y+eC74 PV/QkAntk2zHiWuRj7AKrg6i3uFvf+MqV1KH4gToHOPrhqZYt4nG7tkJ/gRVqpoV0OP1 IbI7hWR6E2qJfbt7+fAMVnLp8CKOQ5zKSY2nH+W2wIogn4UZrwWDgSZ3Jedx0pcvI/Pi XAW3KD62NF6QKs6hLOejn7yzjXyT5EQTTN+FtKOZ1HgrnZsCCEDaV38tNbwFIzwqyWet hdjhZidhUvXC4NDjas5RRltaGuFtaiYCdPMoBubSZoDRYDnBrJ0as8IKeQUr1Dguo6Vu keVQ== X-Gm-Message-State: AOAM531WlDl5ZagjTbpmU50kWQiFNcWohTZxA1yFI+a5Oq1Mh2oGeRid jk1yDYNWFKYxs1wDGNYFugpemBw4zwDHpLP/ivU= X-Google-Smtp-Source: ABdhPJxcBRx+wXQyFZzsvq4dLjzKr+YcQpAvgOJz/8BSMx33dxZ03KrJdnX3BGgvAIW63X57lTazkW7b79TNICkItMw= X-Received: by 2002:a54:4104:: with SMTP id l4mr1087049oic.17.1637623828220; Mon, 22 Nov 2021 15:30:28 -0800 (PST) MIME-Version: 1.0 References: <20211122225350.56F153072E9F@ary.qy> In-Reply-To: <20211122225350.56F153072E9F@ary.qy> From: Tony Rutkowski Date: Mon, 22 Nov 2021 18:30:17 -0500 Message-ID: To: John Levine Cc: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000008e8d8505d1690251" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 23:30:35 -0000 --0000000000008e8d8505d1690251 Content-Type: text/plain; charset="UTF-8" The situation here oddly resembles vaccination. The legal professionals recommend a course of action to protect the organization and participants against antitrust "infection." The libertarian antitrust anti-vaxers question the need or object. Responsible behaviour should prevail. On Mon, Nov 22, 2021, 5:54 PM John Levine wrote: > It appears that Joel M. Halpern said: > >While there are some participants for whom competition law is not an > >issue, there are many participants for whom it is an issue. > > Regardless of whether some individual IETFers think it's a problem, > if we got into a situation where the US or EU were sending us subpoenas > or asking detailed questions about our practices and looking for > suspicious comments in the mailing lists, it would be a problem for > everyone, no matter where you live or who you work for. > > I agree that a minor update to the Note Well seems like a reasonable > approach. > > R's, > John > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --0000000000008e8d8505d1690251 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The situation here oddly resembles vaccination.=C2=A0 The= legal professionals recommend a course of action to protect the organizati= on and participants against antitrust "infection." The libertaria= n antitrust anti-vaxers question the need or object. Responsible behaviour = should prevail.

On Mon, Nov 22, 2021, 5:54 PM John Levine <johnl@taugh.com> wrote:
It appears that Joel M. Halpern=C2=A0 <jmh@joelhalper= n.com> said:
>While there are some participants for whom competition law is not an >issue, there are many participants for whom it is an issue.

Regardless of whether some individual IETFers think it's a problem,
if we got into a situation where the US or EU were sending us subpoenas
or asking detailed questions about our practices and looking for
suspicious comments in the mailing lists, it would be a problem for
everyone, no matter where you live or who you work for.

I agree that a minor update to the Note Well seems like a reasonable approa= ch.

R's,
John

--
Gendispatch mailing list
Gendispatch@ietf.org
https://www.ietf.org/mailman/listinfo/ge= ndispatch
--0000000000008e8d8505d1690251-- From nobody Mon Nov 22 17:30:24 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0346D3A0C17 for ; Mon, 22 Nov 2021 17:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ToA2arLb_nvX for ; Mon, 22 Nov 2021 17:30:20 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D2C3A0C12 for ; Mon, 22 Nov 2021 17:30:20 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id y8so15667389plg.1 for ; Mon, 22 Nov 2021 17:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZM+HLGD8A0aORnhNsOKnRl2Jx2cbpUpobNDEKRFiCZc=; b=MFM2LjrHRSN/fLPUFFp5CDZyV1VntyMgTkmeE+BfNtlCzPg0THUL3diRqjlIMVaQqJ 17DQAUL1+/o6gYFLfjKR153cTYEW6DzMJiwog9RwpsJnwC/4iKY0jfhNYspYiDnvFoW2 qwY4ptghSAAzqQOFzN8+ApAu+Yc+HUM0mlg1j92LA+nFKDdQgF+pgQiKvl1hnsuslzEi q18zw4JHC+f6Td3T20EJM84Zwo23i8d9UfsyDitVcP/BmX2rLS/fxFmm/0xI2+dGmkQO MVz5InzWRxkOOAJahhhfnW3oEywtzBvNx1KbXKVnjYWZge+oesIpf7YukhyLvggvItqb cxdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZM+HLGD8A0aORnhNsOKnRl2Jx2cbpUpobNDEKRFiCZc=; b=3YADK+yhe4CdWS3b7VW4onNT72t6EJfSA/wRIdeyfBetoO/QjDDLmOuBvJUZGU24rc L+rRqe6BdEu8Y+flyOXQzoBbg62dnEClFUsSPg4koB3lLdIFn5bHXPfAKMIUnhc1KRDt QnbxXjq1e7NYOA/xeFNWYxWY/p9QEsJ71nRXW8r06YWatIFGZE5y5/D1+nIrZX1d0Hzp z+I2Ft+ySsD9rx9NbHLZ1M3WKOvU+PzVScoEkKmfTXjWXNahclWrle+B12vbjhaEayI2 DklakjmL0uE2mvLZxCFHTGBVMRRz4947l9edNw9TQtnnQ77Q6G8agKIdhk9YnTw/v0/f P0NQ== X-Gm-Message-State: AOAM533AIM6WS97cymSVnRHcI2bxA0lwT9uwYQ7D7ccndtZDOzqq1voV 8xjUIZQUXI9ubAyU9DF1Zg3L21zhPKZb/g== X-Google-Smtp-Source: ABdhPJxGYz/W6UllWohTD9nMLe2awlfOKrKrplWtJE7kdKh6MsW3Tiz9It2JzspFYko6UqTllq1x5Q== X-Received: by 2002:a17:90a:cf85:: with SMTP id i5mr38804018pju.101.1637631018210; Mon, 22 Nov 2021 17:30:18 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id e11sm8597776pjl.20.2021.11.22.17.30.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Nov 2021 17:30:17 -0800 (PST) To: "Joel M. Halpern" , Stephen Farrell , gendispatch@ietf.org References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Tue, 23 Nov 2021 14:30:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 01:30:23 -0000 On 23-Nov-21 05:44, Joel M. Halpern wrote: > While there are some participants for whom competition law is not an > issue, there are many participants for whom it is an issue. I have always felt it was relevant to me, whether or not I worked for a large IT company. How can it *not* be relevant to anyone who is actively participating in discussions with multiple companies? Suppose somebody from company A asks you to tell somebody from company B about A's pricing policy? Surely, doing that would be illegal. > The intended approach is a short statements that highlights a very few > aspects of competition law that should be kept in mind by anyone to whom > they apply. Which is (I think) everybody, because of the above thought experiment. > From where I sit, it is important to have the note well pointer as it > is very difficult to claim we as a community have made an effort to > inform people about the issue if we bury the results in an informational > RFC no one ever hears about. I agree. The reason I think this should not be a BCP is because it is in no way a change to the IETF's rules. But there is a sound argument that a warning should be given. Brian > We (the co-authors) are still trying to work out the wording for the > much shorter approach. > > Yours, > Joel > > On 11/22/2021 11:37 AM, Stephen Farrell wrote: >> >> Hi, >> >> I'm not that convinced we need to do anything but no >> harm having the discussion, so seems reasonable for >> you and/or Joel to make a modified proposal. >> >> On 22/11/2021 15:28, Brad Biddle wrote: >>> I recommend that that we develop an explicit statement that addresses >>> antitrust compliance, and that we reference that statement in the Note >>> Well text that is routinely shown to participants. >> >> If you do do the above, please take into account that >> competition law is not at all a direct issue for a lot >> of IETF participants and we don't want to ever give the >> impression that those for whom competition law etc is >> a direct issue are more important participants. (For me >> that's a reason to not put that in the Note Well text >> which is already getting way too cumbersome.) >> >> Cheers, >> S. > From nobody Mon Nov 22 18:21:20 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FF33A0CAD for ; Mon, 22 Nov 2021 18:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 03FZrxw5CbWl for ; Mon, 22 Nov 2021 18:21:16 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBBB3A0CAC for ; Mon, 22 Nov 2021 18:21:15 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id v23so25959813iom.12 for ; Mon, 22 Nov 2021 18:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KoXb2Yt9FD0LvG0UA45wBeypLFoshCaOaLCMv/HaXmk=; b=CBSJUNsCc+2rZQ2AbBy+pjc/dHTqfj/CZDp9FUPwLhS08X17mohzGZj4gmNDGrw3e5 gSlzC4BT5Qknq5hvn1yDuyhA2oCJ9AqyFa6Is/u3OXzoBEcBPnu8tXPqHxh1YHS/QjR6 iz28LKw2RtzZecmCNa20qsQBXTgQgLP7gqLQI3Ttz7RsZ5OIYq5AkTsTiPJXj0ovcMZR zhVNWFe0V3BdDPlHhlYb43AoNV8RB+apE7RwqCEoqGZwSjcKvkgQ92t/Ndx/uO9Y8ErV GntCi3S7JYJQUc/V23wAoxLfEfzvdEEAPx11o4/9Pjgce/T6NrnqC5wYbFuyWu3TuVT1 cQmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KoXb2Yt9FD0LvG0UA45wBeypLFoshCaOaLCMv/HaXmk=; b=ghir2IHQaxKxnro2jZDvQornG2GWvDARAgl/PqMilh7AlV63iAznK+VQWImQzhZ4+m CyAorlUTm4F1ojF4+zU8uioWVZfX9QlRjmkAIWaX05t4Tmx2mIFkMxn/Ng3x16FFGOzS RYfqizy7tGoTHwcjnIGXGf32wZ8zLJdPRZCwKisjrEL+pGQqdTt0YkeYQYEABVMsb3zD cTjBGq2GR9bA/MMT9rDhv4dfLSsAVrIY3siVmffNs9/aNMVGXdMiMqYWLah2J1va/eX0 pLgcWgZ1mMivGQcrj8PWVKlV5TWpvbkaUJ1bEmvgJow+4aCekFnlBo0/l99YHtNCR4+B YYNA== X-Gm-Message-State: AOAM530cEiePBOVTi6xZoq+yDHa08WzjsCUb6bgFLqIfQIzA2PCFcNkP ndHv6Nvtt38Z0pyYXD2Dgmz1ax6zgFVc0rNThro= X-Google-Smtp-Source: ABdhPJwV8YCucJ9a+R8fTXZSC2ovN5VVqY0B/+uJkFj7e2SO+o7Ep8gGSZRn1UAY1Dwugacwckck6KitUp9aQKydn6M= X-Received: by 2002:a5d:9b0f:: with SMTP id y15mr1773388ion.5.1637634074206; Mon, 22 Nov 2021 18:21:14 -0800 (PST) MIME-Version: 1.0 References: <163595251682.11706.5053299985084837548@ietfa.amsl.com> <8854c3cc-694b-1a7f-ebc8-47bed9bb4e0f@joelhalpern.com> In-Reply-To: From: Rob Sayre Date: Mon, 22 Nov 2021 18:21:03 -0800 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , Stephen Farrell , GENDISPATCH List Content-Type: multipart/alternative; boundary="00000000000043e5ce05d16b65cc" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-halpern-gendispatch-antitrust-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 02:21:18 -0000 --00000000000043e5ce05d16b65cc Content-Type: text/plain; charset="UTF-8" On Mon, Nov 22, 2021 at 5:30 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 23-Nov-21 05:44, Joel M. Halpern wrote: > > While there are some participants for whom competition law is not an > > issue, there are many participants for whom it is an issue. > > > I have always felt it was relevant to me, whether or not I worked for > a large IT company. How can it *not* be relevant to anyone who is > actively participating in discussions with multiple companies? > Right. There have always been unstructured discussions about these issues, and IETF participants are pretty sharp about them (as Brad wrote). In fact, crossing the line on this front is a quick way to make sure everyone ignores you. I think a brief document to add to the Note Well is fine. I doubt the current approach would be easy to explain to a regulator as a "program", even though it is effective. thanks, Rob --00000000000043e5ce05d16b65cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 22, 2021 at 5:30 PM Brian E C= arpenter <brian.e.carpent= er@gmail.com> wrote:
On 23-Nov-21 05:44, Joel M. Halpern = wrote:
> While there are some participants for whom competition law is not an > issue, there are many participants for whom it is an issue.


I have always felt it was relevant to me, whether or not I worked for
a large IT company. How can it *not* be relevant to anyone who is
actively participating in discussions with multiple companies?=C2=A0

Right. There have always been unstructured di= scussions about these issues, and IETF participants are pretty sharp about = them (as Brad wrote).

In fact, crossing the line o= n this front is a quick way to make sure everyone ignores you.
I think a brief document to add to the Note Well is fine. I do= ubt the current approach would be easy to explain to a regulator as a "= ;program", even though it is effective.

thank= s,
Rob

--00000000000043e5ce05d16b65cc-- From nobody Tue Nov 23 00:33:49 2021 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F043A0989; Tue, 23 Nov 2021 00:33:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , Cc: iesg-secretary@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163765642754.25400.10288736560873536753@ietfa.amsl.com> Date: Tue, 23 Nov 2021 00:33:47 -0800 Archived-At: Subject: [Gendispatch] Last Call Expired: X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 08:33:48 -0000 Please DO NOT reply to this email. I-D: Datatracker URL: https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Tue Nov 23 02:59:23 2021 Return-Path: X-Original-To: expand-draft-eggert-bcp45bis.all@virtual.ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 39F083A0120; Tue, 23 Nov 2021 02:59:13 -0800 (PST) X-Original-To: draft-eggert-bcp45bis.all@ietf.org Delivered-To: xfilter-draft-eggert-bcp45bis.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8033A0064; Tue, 23 Nov 2021 02:59:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carsten Bormann via Datatracker To: Cc: draft-eggert-bcp45bis.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163766515258.2889.17947564397204893159@ietfa.amsl.com> Reply-To: Carsten Bormann Date: Tue, 23 Nov 2021 02:59:12 -0800 Resent-From: Resent-To: gendispatch@ietf.org, rwilton@cisco.com, lars@eggert.org Resent-Message-Id: <20211123105913.39F083A0120@ietfa.amsl.com> Resent-Date: Tue, 23 Nov 2021 02:59:13 -0800 (PST) Archived-At: Subject: [Gendispatch] Artart last call review of draft-eggert-bcp45bis-06 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 10:59:13 -0000 Reviewer: Carsten Bormann Review result: Ready with Issues * Review for draft-eggert-bcp45bis-06 * Reviewer: Carsten Bormann * Review result: Ready with Issues I am the requested ARTART reviewer for this document. The document adjusts RFC3005 for the present. It needs to be, and succeeds in being, succinct, with a few places where a little more clarity would still be desirable. ## Minor * Introduction, second paragraph The IETF Note Well [NOTE-WELL] applies to discussions on the IETF discussion list and all other IETF mailing lists, and requires conformance with the IETF Guidelines for Conduct [RFC7154] and the Anti-Harassment Policy [IETF-AHP], among others. This is a statement of fact, so it is not clear whether this is a normative statement. If it were normative, there would be a need to point out normative references to web pages are problematic. * 3. Moderation, third paragraph This section introduces the SAA, but doesn't quite make clear whether it is the normative statement about SAAs, or is more on the descriptive side (and maybe even should have a reference to a normative statement published elsewhere). Apart from appointing SAAs, the IETF Chair should stay away from the day-to-day operation and management of the SAA team. This has been in practice for a while, and the SAA team has independently maintained definitions of abuse patterns [SAA-UPC] and operating procedures [SAA-SOP] for them. The SAA team should reach out to the IETF Chair for any conflict resolution in a timely manner. In this paragraph it suddenly becomes clear that SAAs operate as a team. This has significant implications for their operation that need to be expanded upon a little. E.g., do members of the SAA team vote? Do they otherwise establish consensus among them before acting? ## Editorial * Abstract The abstract probably needs an editorial round: It might give the impression that ietf@ is a technology list and does not mention that there is a lot of process discussion and discussion about the evolution of IETF and its related organizations on this list. Specifically, "latitude" is meant with respect to the set of topics, but that is not explicitly said. Last sentence of first paragraph of intro needs to be copied to abstract: This document defines the charter for the IETF discussion list and explains its scope. * Introduction See comments on abstract. * 3. Moderation [...] SAAs [...] are empowered to restrict posting by a person, or of a thread, when [...] Can't quite parse "posting of a thread". Is "posting to a thread" meant? Is it then OK to open a new thread on the same topic? * 4. Security Considerations This document does not raise any security issues. (Any device that can be abused for censorship clearly does.) * 6.2. Informative References There are a number of "n.d." in the references. The RFC editor will probably want to delete them. Are any of these intended to point out that the reference is to a *live* document (as opposed to a static, undated document) and therefore should be kept (or expressed otherwise)?