Re: [antitrust-policy] Further feedback on draft-halpern-gendispatch-antitrust
Christian Huitema <huitema@huitema.net> Mon, 03 April 2023 14:59 UTC
Return-Path: <huitema@huitema.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 9FB5DC1524A3 for <antitrust-policy@ietfa.amsl.com>; Mon, 3 Apr 2023 07:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 VnzL96rXRPir for <antitrust-policy@ietfa.amsl.com>; Mon, 3 Apr 2023 07:59:25 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 96802C1522DB for <antitrust-policy@ietf.org>; Mon, 3 Apr 2023 07:59:18 -0700 (PDT)
Received: from xse202.mail2web.com ([66.113.196.202] helo=xse.mail2web.com) by mx197.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1pjLeE-0006Ja-5E for antitrust-policy@ietf.org; Mon, 03 Apr 2023 16:59:14 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4PqvDP2nLrz8lM for <antitrust-policy@ietf.org>; Mon, 3 Apr 2023 07:59:01 -0700 (PDT)
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1pjLe9-0002TT-6g for antitrust-policy@ietf.org; Mon, 03 Apr 2023 07:59:01 -0700
Received: (qmail 15293 invoked from network); 3 Apr 2023 14:59:00 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.128]) (envelope-sender <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <jmh@joelhalpern.com>; 3 Apr 2023 14:59:00 -0000
Message-ID: <3fe1404c-81d6-2d75-7572-676804ee1ebd@huitema.net>
Date: Mon, 03 Apr 2023 07:58:59 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1
Content-Language: en-US
To: Joel Halpern <jmh@joelhalpern.com>, Mark Nottingham <mnot@mnot.net>
Cc: antitrust-policy@ietf.org
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>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <5e1d99c9-dc14-e04f-68f3-72284c3f99fa@joelhalpern.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: 66.113.196.202
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.25)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT81cDRchm+C5cvDg4PMClEjPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5xco6vWRhHLFh/OWxoueVJ0wxIslC30f773RD9zIpu6FBPm p87GC1OZvsh7yKER8soPa0/7Mh6LNKCpnBdQFae8eb4o0/MLsfRXq2B6Bj1eqNGuQMdCm7vGsD2P e29rGQfMYJa2jLEh4MB7zklrVQoithHTuidhm7W8iFyVeRg6IjQW73fLcsR0fl5ZA/6itRqs7Y/J 7JGf0ZQvBCG12adjuwRgZ32e5A5ro4OSqy2+92StBDJn9z+dAI3/7SF9NBYtlM2TG+JLl+g+XhE5 hlLlDZg5/oQzlCR7TIA1Y02g3HY3L1i18SNUe1r0mqdaqSEXjkdTeVZ2qGWx/wHRpX689SKIcp7K A7p/sHfpQQwXaNclsf95ERnfa5/3utVu63cGgIqsnjgPIxt+QJb5OikLHc5n6zja5lqWudOmWn7s j3chPTk81t14jC9YfVei2d+g/NBxI/7nIEeBnXBUsTCe+MEYMo0NDeyXVO3tNSgVgckOnz0mswVX ZkpFVe5ZgGA0MLjqgL337Aba0izaNK+kIcs695hd4EvXBwAF2vx4nP25Kfa3z3P+kuoJ3rh1PW8C rqRnblrmpm1FcUA1FRKNkDzLsegeIf5jR5PNTlF6RWK3GhiRI4zdtwTHKolhfUj8Pfx7kd/HySO3 szGdGYXjHAvZhEyfejztGtIuuaSVkZJpH51cIHiZNRQGk2GheMiD79q2T6kbiI64w+dHme3vFeQT YyQQNjGnPYXLVBEanVscaQZCcEb9JwgQreRxk6Ny2DNwOgV373pfDhBQ21OdfR+0jMyraD5j5U5T XEnkiMtt5Ioa9rCTUxrWeesKgXKfnvhSRaxISKJtzTb63lpo9M4+rbozSFD+MjYM35bF+RYzpPqG BvR0ks1/IouSjkuJ+cv73CChOPjKA0/DVd83ExA3XU+HPc17z49/qO1Y7bWqmJ9yHsXP5w0EavZJ 9XowyGTHIAoNFX+jcW7DGmdE+iOkbSRSbQbOrYxN2Qisdw==
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/antitrust-policy/e2IZ6QThiWukx11W-8O5EoBuG7w>
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: Mon, 03 Apr 2023 14:59:28 -0000
On 4/3/2023 6:31 AM, Joel Halpern wrote: > Thank you for suggesting text. I can live with your suggested text in > section 2.3. (I have not spoken to my co-authors.) > > I do wonder if other folks who have concerns would also consider that an > improvement? Yes. Mark has obviously studied this way more than me, but I think he makes a set of very valid points. His concern about the spirit of competition laws is very well placed. For example, the fact that the US practice has evolved towards "protecting consumers" rather than the European view of "protecting competition" is well known. The current US practice results in a weakening of anti-monopoly rules in the US, and there is significant political pressure to change that -- and equally significant pressures to keep it as is. Of course, the IETF is bound by existing laws, not by our guesses of how the laws might evolve. But at a minimum we need to show that the approaches are different in different parts of the world. There are also lots of concerns about the abuse of intellectual property laws and regulations, variously reported as patent trolling or copyright in perpetuity. Again, the IETF as to deal with the laws and practices as they stand, although we could certainly make a point about abusing patents to prevent interoperability. In any case, we could remind participants that all public discussion of the technical topics in the IETF should be considered "prior art" just like scientific conferences and printed publications, and that patent applications are expected to disclose all the known prior art. Finally, I share Mark's concern that with published texts the author's intent matters way less than how readers will use this document. I share his concern that the text will be abused as supporting specific proposals such as trying to compel a group to incorporate proprietary technology in a standard. That's why I believe the best outcome would be to strike out section 4.2 in its entirety, and that the text should not include anything that looks like a recommendation -- NO must, should, or any of the classic keywords, even in lower case. -- Christian Huitema > On 4/3/2023 2:04 AM, Mark Nottingham wrote: >> Hi Joel, >> >> Responses below. >> >>> On 3 Apr 2023, at 1:29 pm, Joel Halpern <jmh@joelhalpern.com> wrote: >>> >>> Top lining what I find confusing in this (and several other emails I >>> have tried to respond to), and then in lining the rest of my responses. >>> >>> The primary concern if I am reading this right seems to be a claim >>> that because this gives advice, it is not strictly educational >>> material. I think we have all taken a LOT of training. It tends to >>> give examples and advice, as well as information about the policies >>> of whomever is providing the training. If this did not include >>> advice, I do not understand how it could be useful education. And I >>> do not see how providing advice that is explicitly marked as >>> non-binding and not IETF policy violates the goal that the document >>> is informational advice. (It is lay advice, as we all understand >>> that if you want legal advice you have to ask a lawyer with whom you >>> have a relationship.) >>> >>> Put a little differently, I do not understand how your suggested >>> rewording would help the concern. I am happy to make your first >>> suggested change, and does seem to strengthen the "not poliocy" >>> message. But I do not see how it address the comment from you and >>> others that it "isn't educational material." >> Speaking only for myself - the concern is not whether it is or is not >> 'educational material' -- the concern is that some will consider it >> authoritative, or will cite it as backing their position in a >> particular decision. If it is to be published (and I believe many >> think that this issue alone should sink it), it should be purged of >> any hint that could support these interpretations. >> >> >>> Further in line marked <jmh> ... </.jmh> because different mailers >>> mangle writer marking in different ways.. >> It is indeed a sad state of affairs. >> >> >>>> 2.2 Purpose of Antitrust or Competition Law >>>> >>>> The purpose of competition law is, to put it mildly, contested. We >>>> shouldn't unintentionally take a position; this section should be >>>> removed. >>> <jmh>The section is a quote from the US DoJ, and aligns with what >>> many otehr governments say on the subject. It does not claim this is >>> the IETF agreement on the purpose. It says this is waht someone else >>> says it is for. It seems to me very helpful, in understanding how we >>> interact with these laws, if we understand where the enforcement >>> authorities start from in looking at parties actions. </jmh> >> Even staying inside the US, you're likely to get a somewhat different >> view from the 'New Brandeisians', including the current chair of the >> FTC. The Europeans are also about more than just consumer welfare >> these days. >> >> The point is that alone, this quote is very narrow, and could age >> badly. If it's going to stay, it should be contextualised in time, and >> other sources (preferably at least one European) should be added. >> >> >>>> 2.3. Overlapping Areas of Concern >>>> >>>> Given the positioning of this document, 'must not' (x2) is not >>>> appropriate here, even in lowercase. >>> <jmh>Are you really asking that we say it might be sometimes okay for >>> IETF leadership / staff to engage in legally problematic activities? >>> I would hope not. Are you really asking that the IETF endorse >>> problematic activities by participants within the IETF? That would >>> subject the IETF itself to significant legal liabilities. I suppose >>> you could argue that we should say these things, but in some other >>> document that is actually a policy document. But the community does >>> not want a policy document. So we used lower case must to note that >>> this is an observation about external forces, not a statement of IETF >>> policy. >> Ignoring the rhetorical questions there, the lowercase 'must' has a >> history of being misinterpreted in the IETF -- we have a whole RFC >> clarifying it. 'must' -- even in lowercase -- implies that it's a >> requirement, which implies this is a policy document. >> >> >>> My fundamental concern is that if we can not even say this, we leave >>> the IETF at significant risk of violating antitrust expectations >>> governments have of SDOs. That has been demonstrated to result, even >>> with good intentions, in millions of dollars in cost and significant >>> disruption in operation for other SDOs. >>> >>> I suspect, but have not confirmed, that my co-authors do not consider >>> these to be policy-setting statements. But they can speak for >>> themselves.</jmh> >> Frankly, it doesn't matter what they think -- it matters what readers >> think. >> >> It's easy to restate these without an explicit requirement; e.g., >> >>> Most acutely, the IETF needs to avoid having anyone who is officially >>> representing the IETF -- in any capacity -- engaging in problematic >>> antitrust behavior and creating liability for the IETF. >> ('antitrust behaviour' is really weird here; it's screaming out to be >> 'anticompetitive behaviour') >> >> ... although even with this change, I suspect most readers will assume >> that this document has a policy flavour -- it's very difficult to say >> 'we've got to avoid this, and here are the things that are >> problematic' without people assuming that it's a policy. >> >>>> 4.2 Topics Requiring Caution >>>> >>>>> • Seeking clarifications about IPR disclosures, in a context >>>>> when any such clarifications could be reasonably perceived as >>>>> entering into group negotiations of IPR terms. >>>> This text's use of 'group negotiations', while appropriate in the >>>> context of competition law, can be read as 'open or public >>>> negotiations' in an IETF context. Because normal IPR discussions in >>>> the IETF are about non-discriminatory licensing, which poses no >>>> competitive risk by its nature, I suggest that something like this >>>> would be much more helpful to participants: >>>> >>>>> • Discussion or Negotiation of IPR licensing terms that are (or >>>>> could be perceived as) discriminating for or against a particular >>>>> group. >>> <jmh>As I understand it (and lawyers can clarify better), there are >>> more concerns than overt discrimination. The consistent advice we >>> have received from IETF lawyers for the last 35 years is to never >>> engage in negotiation of license terms (we are allowed to say no, we >>> won't work on thsi document because of terms). They have >>> consistently told us that engaging in such negotiation brings a >>> significant risk of governmental antitrust intervention. >> I'd love to dive into this -- could they give summaries, or ideally, >> citations? The most straightforward thing to do here is to add >> language that covers whatever these additional concerns are, but we >> need to know what they are first. >> >> Cheers, >> >> >>> I am looking for better wording to balance the importance of this >>> with the fact taht we are not trying to set IETF policy, and >>> therefore can not tell people what the MUST NOT do. We already moved >>> it to the caution section, and reworded it to moderate. We may not >>> have gotten far enough, and are looking at suggestions that have been >>> made (as well as happy to see any that will be made) to achieve this >>> balance. Given how important the lawyers have said this is, I am >>> loathe to remove the second bullet of 4.2 entirely. </jmh> >>> >>>> 4.2 Topics Requiring Caution >>>> >>>> Some activity at IETF116 made me think that we need to say more >>>> about abuse of dominance as it relates to our decision-making >>>> procedures. >>>> >>>> For example, if someone employed by an implementer that has >>>> overwhelming market share gets up to the mic and states that their >>>> implementation will not support a proposal under any condition, that >>>> could be perceived as an abuse of dominance by a regulator or judge. >>>> >>>> If the Working Group were to assign undue weight to such statements, >>>> or even the perception of a dominant undertaking's preferences, that >>>> could be seen as facilitating such abuse. >>>> >>>> Of course, our consensus procedures are a defence against this. >>>> However, Chairs and participants are also pragmatic -- if a party >>>> that controls 80% of the market (for example) doesn't want to do >>>> something, it's probably not going to fly. That *doesn't* mean that >>>> the WG should always give in, however; sometimes, you publish a >>>> document and see if it gets deployment when helped by other forces >>>> (e.g., customer demand). >>>> >>>> So, we need a reminder; something like this under 4.2: >>>> >>>>> • Statements that could be perceived as unduly using market share >>>>> to influence consensus outcomes, when made by participants who are >>>>> associated with companies that might be considered as dominant in a >>>>> relevant market. >>> <jmhThat seems an useful thing to add to section 4.2, but I will >>> defer to Brad on this.</jmh> >>>> 4.4. Escalate Antitrust-Related Concerns >>>> >>>> The title of this section implies that the legal counsel will 'do >>>> something' regarding the concern raised, and therefore takes >>>> responsibility. That likely isn't the case; counsel will assess >>>> whether there are any legal implications *for the IETF*, but not for >>>> the person who raised it. Absent regulator or court action, it's >>>> unlikely we'll actually do anything based upon a random complaint. >>>> >>>> As a result, this section should probably be changed to something like: >>>> >>>>> 4.4 Inform the IETF of Antitrust-Related Issues >>>>> >>>>> Participants can report potential antitrust issues in the context >>>>> of IETF activities by contacting IETF legal counsel >>>>> (legal@ietf.org) or via the IETF LLC whistleblower service. Note >>>>> that reports will only be assessed for their impact upon the IETF; >>>>> should you be directly impacted by a antitrust issue, you should >>>>> obtain specific legal advice. >>> <jmh>I rather like your wording, but will again defer to Brad.</jmh> >> -- >> Mark Nottingham https://www.mnot.net/ >> > > _______________________________________________ > antitrust-policy mailing list > antitrust-policy@ietf.org > https://www.ietf.org/mailman/listinfo/antitrust-policy
- [antitrust-policy] Further feedback on draft-halp… Mark Nottingham
- Re: [antitrust-policy] Further feedback on draft-… Joel Halpern
- Re: [antitrust-policy] Further feedback on draft-… Mark Nottingham
- Re: [antitrust-policy] Further feedback on draft-… Joel Halpern
- Re: [antitrust-policy] Further feedback on draft-… Christian Huitema
- Re: [antitrust-policy] Further feedback on draft-… Black, David
- Re: [antitrust-policy] Further feedback on draft-… Alissa Cooper
- Re: [antitrust-policy] Further feedback on draft-… Jay Daley
- Re: [antitrust-policy] Further feedback on draft-… Tony Rutkowski
- Re: [antitrust-policy] Further feedback on draft-… Joel Halpern
- Re: [antitrust-policy] Further feedback on draft-… Joel Halpern
- Re: [antitrust-policy] Further feedback on draft-… Tony Rutkowski
- Re: [antitrust-policy] Further feedback on draft-… Alissa Cooper
- Re: [antitrust-policy] Further feedback on draft-… Joel Halpern
- Re: [antitrust-policy] Further feedback on draft-… Tony Rutkowski
- Re: [antitrust-policy] Further feedback on draft-… Rigo Wenning
- Re: [antitrust-policy] Further feedback on draft-… Pete Resnick
- Re: [antitrust-policy] Further feedback on draft-… Rob Sayre