From nobody Sun Apr 2 23:04:56 2023 Return-Path: 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 A8982C151B05 for ; Sun, 2 Apr 2023 23:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b="eCXsx/4J"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="sXmIxsuW" 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 SzJMeLg_u2bh for ; Sun, 2 Apr 2023 23:04:49 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (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 8EA2FC14CE54 for ; Sun, 2 Apr 2023 23:04:49 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 28A533200979; Mon, 3 Apr 2023 02:04:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 03 Apr 2023 02:04:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1680501883; x=1680588283; bh=1jU41DcPOWdCZGHtXMyDGYrZjdo87BRDclR hIFcx9EA=; b=eCXsx/4J6l+6DrRXP3vvHUC9ZAyOchlqDFbE+mGbWCZAvIY7Trq DDAOBsLGMmxkumh6jKVdI13BPrNJLkazzwPKHipDKlGsqcjPsVhbcEfjqiawp2Iu hJ88lGKwuDSzk9b+mVHt/8Lnql6eBo77HuXZyR9rybja6T/FmTf28I9Rd/HKTI4j CQtuZUStaNBrdNPuuR7PbsOmQmrqNWDyzDOyiyOeiq5mwObSqqDTXFsvnHsQ4DPY MyE4j642qXZJFOLccK4m1AHS9XFHAfGIhKmh6dGoXGH51YWGqXX6RZmmAqwDGNUu Tk+liMd+Btp49KCgtvwgirht7ziNwld2pWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1680501883; x=1680588283; bh=1jU41DcPOWdCZGHtXMyDGYrZjdo87BRDclR hIFcx9EA=; b=sXmIxsuWtUj744yu0E9As4wSv8OIEvHd34+8ckJhFwPTaK7ZwJ1 s9AejtcwmdwbgvbODf5ve6hG1JCuxkNFEMbzsxh5XXoMf7Ecfakr61JAO7WVyBea YvN2C6hQ0zRHf846PpADSV9hU0x+l136rdtf5eHZfi7nBCrkA9xNZI+tohB5Y56T Ri6EBLHaRsAIrOCBhEbjFDLwxjrPYh9vZ/zL/Mt63Q6+XVRF1O+HBQHzQ51QP9RK 1u0ezpv1GB6Xek6tDqE02Jf5Zz4faU4YuZB9mQZOOiH5b6rK/PcpiCMoTQ3I3sod FpGkswkUqLa54BeyuI+UCb1MhykITQese9Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeiiedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffvefgkfhfvffose htqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohht sehmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepfefhhfelleejjeejieekhfejfe eiheetgeejgffhudegveeigeehgefftdetudetnecuffhomhgrihhnpehmnhhothdrnhgv thenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnh hothesmhhnohhtrdhnvght X-ME-Proxy: Feedback-ID: ie6694242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Apr 2023 02:04:42 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) From: Mark Nottingham In-Reply-To: <7591b812-c140-b752-09ac-153059543cb4@joelhalpern.com> Date: Mon, 3 Apr 2023 15:04:17 +0900 Cc: antitrust-policy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7591b812-c140-b752-09ac-153059543cb4@joelhalpern.com> To: Joel Halpern X-Mailer: Apple Mail (2.3731.400.51.1.1) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2023 06:04:54 -0000 Hi Joel, Responses below. > On 3 Apr 2023, at 1:29 pm, Joel Halpern wrote: >=20 > 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. >=20 > 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.) >=20 > 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 ... 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 >>=20 >> The purpose of competition law is, to put it mildly, contested. We = shouldn't unintentionally take a position; this section should be = removed. > 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. 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 >>=20 >> Given the positioning of this document, 'must not' (x2) is not = appropriate here, even in lowercase. >=20 > 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.=20 > 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. >=20 > 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. 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 >>=20 >>> =E2=80=A2 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: >>=20 >>> =E2=80=A2 Discussion or Negotiation of IPR licensing terms that are = (or could be perceived as) discriminating for or against a particular = group. >=20 > 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. >=20 >> 4.2 Topics Requiring Caution >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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). >>=20 >> So, we need a reminder; something like this under 4.2: >>=20 >>> =E2=80=A2 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. > >>=20 >> 4.4. Escalate Antitrust-Related Concerns >>=20 >> 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. >>=20 >> As a result, this section should probably be changed to something = like: >>=20 >>> 4.4 Inform the IETF of Antitrust-Related Issues >>>=20 >>> 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. > I rather like your wording, but will again defer to Brad. -- Mark Nottingham https://www.mnot.net/