Re: [antitrust-policy] Further feedback on draft-halpern-gendispatch-antitrust

Pete Resnick <resnick@episteme.net> Fri, 07 April 2023 22:21 UTC

Return-Path: <resnick@episteme.net>
X-Original-To: antitrust-policy@ietfa.amsl.com
Delivered-To: antitrust-policy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC70C151B32 for <antitrust-policy@ietfa.amsl.com>; Fri, 7 Apr 2023 15:21:27 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSn3S4E5h7Y7 for <antitrust-policy@ietfa.amsl.com>; Fri, 7 Apr 2023 15:21:22 -0700 (PDT)
Received: from mail.episteme.net (episteme.net [216.169.5.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232DCC15154E for <antitrust-policy@ietf.org>; Fri, 7 Apr 2023 15:21:21 -0700 (PDT)
Received: from [172.16.1.200] (unknown [172.16.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.episteme.net (Postfix) with ESMTPSA id B715A111B27; Fri, 7 Apr 2023 17:21:19 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=episteme.net; s=mail; t=1680906080; bh=OfTDBWKJ1Ia6cbFDSY9uOPSgdnEiZsgHF3DsVDd3FAU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=n2paPBvR6yTtjaCuBlee4KPbfhSh7NlvvcHkhiTXM3hUDWMyHMZ94iErNrTaUo9D2 4zczhUNYAIZWwqEXluxl7oFIbFZWASlhGISVZT8umjAJLNg/wUCnHwGzPpm3Ra+KXn Db2HX6tdUVy7l73J4S8mokMlUvFv4vc/FCkkNxCQ=
From: Pete Resnick <resnick@episteme.net>
To: trutkowski@netmagic.com
Cc: Alissa Cooper <alissa@cooperw.in>, Christian Huitema <huitema@huitema.net>, Mark Nottingham <mnot@mnot.net>, antitrust-policy@ietf.org
Date: Fri, 07 Apr 2023 17:21:18 -0500
Message-ID: <2E8ED444-46D0-44D0-B3CA-6AB82BED923F@episteme.net>
In-Reply-To: <75f8993a-8c25-c6a2-1e4d-45e7cf70be92@netmagic.com>
References: <F73DEA3A-65B6-4624-9099-B9936B938203@mnot.net> <7591b812-c140-b752-09ac-153059543cb4@joelhalpern.com> <DBDF64B1-D036-408C-8F06-9CEE67940CAA@mnot.net> <5e1d99c9-dc14-e04f-68f3-72284c3f99fa@joelhalpern.com> <3fe1404c-81d6-2d75-7572-676804ee1ebd@huitema.net> <0BE7DC65-E23B-40BC-A2DF-CAE83E9F1F8B@cooperw.in> <724857eb-c996-2b6f-2421-391905e18116@netmagic.com> <7F288089-3CFE-42C0-967B-7CF4205294E3@cooperw.in> <75f8993a-8c25-c6a2-1e4d-45e7cf70be92@netmagic.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"; markup="markdown"
Content-Transfer-Encoding: 8bit
X-Synology-Spam-Status: score=-0.101, required 6, TO_DN_SOME 0, __THREADED 0, RCPT_COUNT_FIVE 0, RCVD_COUNT_ZERO 0, FROM_EQ_ENVFROM 0, MIME_TRACE 0, __NOT_SPOOFED 0, __BODY_URI_ONLY 0, MID_RHS_MATCH_FROM 0, NO_RECEIVED -0.001, ARC_NA 0, FROM_HAS_DN 0, TO_MATCH_ENVRCPT_ALL 0, MIME_GOOD -0.1, __HDRS_LCASE_KNOWN 0
X-Synology-Spam-Flag: no
Archived-At: <https://mailarchive.ietf.org/arch/msg/antitrust-policy/PMblf4a5SDfino0sVEr1po9jTsw>
Subject: Re: [antitrust-policy] Further feedback on draft-halpern-gendispatch-antitrust
X-BeenThere: antitrust-policy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discuss the need for an antitrust or competition policy for the IETF." <antitrust-policy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/antitrust-policy>, <mailto:antitrust-policy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/antitrust-policy/>
List-Post: <mailto:antitrust-policy@ietf.org>
List-Help: <mailto:antitrust-policy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/antitrust-policy>, <mailto:antitrust-policy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2023 22:21:27 -0000

On 5 Apr 2023, at 13:40, Tony Rutkowski wrote:

> Understood.  However, as someone who participates in many different 
> bodies, that problem is fairly universal.  The reality, however, is 
> that the concerns are almost never raised - even when the antitrust 
> implications are obvious or where Google Patent Search reveals the 
> participant submitting some technique for which it holds multiple 
> patents but provides no notice.  Count yourself lucky if someone 
> actually ever says anything. :-)

I guess we can count ourselves lucky. In fact, it was multiple reports 
of such misbehavior at the time that caused us to publish RFC 6701 
<https://www.rfc-editor.org/info/rfc6701>.

But in fact I don't think we were just lucky. I think your experiences 
in other SDOs are not likely to be representative of the IETF because 
the issues turn out not to be all that universal.

Two of the key features of many other SDOs (I'm thinking of 3GPP in 
particular as an example, since you mentioned it earlier) are (a) that 
they are membership organizations with companies as members and (b) 
companies often participate in those organizations precisely to push 
their IP into the standards produced. With regard to (a), of course we 
understand that many IETF participants are employees of companies with 
IP interests, which is why some educational material to make the 
participants aware of the dragons is probably useful, but there is at 
least a default stance that a particular business interests are not to 
be advanced, and many of our other procedures do insulate some of our 
standards activities from the problems (as has been stated). But more 
importantly, with regard to (b), it would be almost unheard of for any 
technical group in those other sorts of standards organizations to 
decide to engineer around or simply dismiss a particular (even superior) 
technology solely on the basis that it implicated someone's IP and would 
make deployability more difficult. In the IETF, a WG can decide (on 
technical and deployability bases) that a technology should or should 
not be included in a standard because of its IP implications. We require 
participants to disclose IP, but we don't require any particular 
licensing (FRAND or otherwise) and don't promise to include any IP-laden 
technology on any particular licensing assurances.

I don't know that the IETF is unique in this respect, but it is 
different enough from most SDOs, such that your experience with them may 
not be particularly relevant.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best