Subject: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 3 Nov 2021 11:37:13 -0400

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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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
[email-masked]
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: Rob Sayre <[email-masked]>
Date: Wed, 3 Nov 2021 11:57:25 -0700

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 <[email-masked]> wrote:

> --
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Nov 2021 09:43:35 +1300

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:
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     From: [email-masked] <mailto:[email-masked]>
>     Reply-To: [email-masked] <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
> 
> 
>               Title        
   : Antitrust Guidelines for IETF Particiants
>               Authors        
 : Joel M. Halpern
>              Pages          
 : 8
>              Date          
  : 2021-11-03
>     https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ <https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/>
> 
>     https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html <https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html>
> 
>     https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01 <https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01>
> 
> 
>     ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/gendispatch <https://www.ietf.org/mailman/listinfo/gendispatch>
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Nov 2021 09:49:03 +1300

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, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> .

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 3 Nov 2021 17:02:31 -0400

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
> 
>> 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
>>
>>
>> <https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/>
>>
>> <https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html> 
>>
>>
>> <https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01> 
>>
>>
>>
>> <ftp://ftp.ietf.org/internet-drafts/>
>>
>>
>> <https://www.ietf.org/mailman/listinfo/i-d-announce>
>> <http://www.ietf.org/shadow.html>
>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>
>>     --     Gendispatch mailing list
>> <https://www.ietf.org/mailman/listinfo/gendispatch>
>>
>>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Nov 2021 18:07:16 -0700

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 6 Nov 2021 21:30:37 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Nov 2021 14:53:03 +1300

Joel,
> 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

  : 2021-11-03

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 6 Nov 2021 22:19:49 -0400

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:
> 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."
> 
> 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
>>
>>> <mailto:[email-masked]>
>>>               Filename        : 
>>> draft-halpern-gendispatch-antitrust-01.txt
>>>               Pages           : 8
>>>               Date 
>    : 2021-11-03
>>>
>>>      Abstract:

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2021 22:32:02 -0400

It appears that Brian E Carpenter  <[email-masked]> said:
>"Participation is by individual technical contributors, rather than formal representatives of organizations."
>

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.

>     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: Rob Sayre <[email-masked]>
Date: Sat, 6 Nov 2021 19:37:04 -0700

> help us stay on the right side of that seems desirable to me.

Not convinced this paragraph should be included, but I’d add that it 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

> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/ <
> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/>
> >
> >     <
> >     <
> https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01>
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Nov 2021 16:48:36 +1300

On 07-Nov-21 15:19, Joel M. Halpern wrote:
> 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
> assumptions they made.

> I know that about 15 years ago our lawyer
>>>>       adhere to IETF standards, or any discussions as 
to when
>> participants
>>>>       guidelines.  We tried to address what 
we heard in the previous
>>>>       feedback,
>>>>            This document provides 
guidance for IETF participants on
>>>> compliance

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 7 Nov 2021 11:23:05 -0500

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 7 Nov 2021 14:13:59 -0500

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 <[email-masked]> wrote:

> https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html>
>
> >>>>>
> >>>>>
> >>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 7 Nov 2021 15:40:18 -0500

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.
> 
> 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 
> On Sun, Nov 7, 2021 at 11:23 AM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >>>>    From what the lawyers tell me, I believe this kind of
>     discussion
>      >>>> does
>      >>> I do not understand why the legal advice given in 1992, 102
>     years after
>      >>> the USA's Sherman Act, needs revisiting.
>      >>>
>     <https://mailarchive.ietf.org/arch/msg/gendispatch/VTxH4Rx_NJPgBeY9FHphdYJZYAw/>
> 
>      >>>
>      >>> .
>      >>>
>      >>>>> On Wed, Nov 3, 2021 at 8:37 AM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      >>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>>>>
>      >>>>>       Subject: I-D Action:
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>>> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>>>
>      >>>>>
>      >>>>>            with antitrust laws and how to reduce antitrust
>     risks in
>      >>>>> connection
>      >>>>>            with IETF activities.
>      >>>>>
>      >>>>>
>     <https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/
>     <https://datatracker.ietf.org/doc/draft-halpern-gendispatch-antitrust/>>
> 
>      >>>>>
>      >>>>>
>     <https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html
>     <https://www.ietf.org/archive/id/draft-halpern-gendispatch-antitrust-01.html>>
> 
>      >>>>>
>      >>>>>
>      >>>>>
>     <https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01
>     <https://www.ietf.org/rfcdiff?url2=draft-halpern-gendispatch-antitrust-01>>
> 
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>       <ftp://ftp.ietf.org/internet-drafts/
>     <ftp://ftp.ietf.org/internet-drafts/>>
>      >>>>>
>      >>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >>>>>       <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>
>      >>>>>       <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html>>
>      >>>>>       <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>
>      >>>>>
>      >>>>>       --
>      >>>>>       Gendispatch mailing list
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >>>>>       <https://www.ietf.org/mailman/listinfo/gendispatch
>     <https://www.ietf.org/mailman/listinfo/gendispatch>>
>      >>>>>
>      >>>>
>      >>>
>      >
> 
>     -- 
>     Gendispatch mailing list

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Nov 2021 09:58:31 +1300

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: "Joel M. Halpern" <[email-masked]>
Date: Sun, 7 Nov 2021 16:40:13 -0500

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: Lloyd W <[email-masked]>
Date: Mon, 8 Nov 2021 11:38:39 +1100

(offtopic)

It's important to care about getting the stance of the document right, but imo not enough attention is paid to also getting the stanzas of the document right.

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-just-poems/
etc.

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

The verse... could be worse.

Lloyd Wood
[email-masked]

programming is the poetry of our time.

> On 8 Nov 2021, at 07:58, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
>

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 8 Nov 2021 08:28:23 -0500

The CA/B Forum Bylaws are in some ways broader.  See 
CA-Browser-Forum-Bylaws-v2.3.pdf (cabforum.org) 
<https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v2.3.pdf>.  
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.
>
> 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.
>
>
>
>
>     > [I believe the original legal advice came at least partly from
>     Geoff
>     > Stewart,
>     <[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 14 Nov 2021 05:55:27 +0100

On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote:
> 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: "Joel M. Halpern" <[email-masked]>
Date: Sun, 14 Nov 2021 01:39:37 -0500

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

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 14 Nov 2021 19:14:09 +0100

On Sun, Nov 14, 2021 at 01:39:37AM -0500, Joel M. Halpern wrote:
> 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.

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.

-- 
---
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Mon, 15 Nov 2021 12:44:09 +1300

(resending from my subscribed address)

> On 15/11/2021, at 7:14 AM, Toerless Eckert <[email-masked]> wrote:
> 
> just per-country summaries on www.ietf.org <http://www.ietf.org/> that would accumulate and then

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 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’s likely more productive to look at it from 'output' side, i.e. how does each of these recommendations affect participation in the IETF?

Jay
> [email-masked] <mailto:[email-masked]>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Sun, 14 Nov 2021 15:57:13 -0800

On Sun, Nov 14, 2021 at 3:44 PM Jay Daley <[email-masked]> 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’s
> likely more productive to look at it from 'output' side, i.e. how does each
> 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

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 15 Nov 2021 03:53:01 +0100

> 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 tha…

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' si…

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

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Nov 2021 17:10:53 +1300

Jay,

On 15-Nov-21 12:44, 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 tha…

That is exactly the point that we need to understand. What is the legal theory that suggests that our current rules are insufficient to protect the IETF itself? How has this changed since the essence of our current rules was set in 1992 by RFC1310 and updated in full agreement with ISOC/IETF 
counsel several times.

Regards
     Brian

---

From: Jay Daley <[email-masked]>
Date: Mon, 15 Nov 2021 12:42:11 +1300

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Mon, 15 Nov 2021 18:04:34 +1300

> On 15/11/2021, at 3:53 PM, Toerless Eckert <[email-masked]> wrote:
> 

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 to me. 

-- 
Jay Daley
IETF Executive Director 
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Nov 2021 20:43:32 -0800

Hi Toreless,
>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: "John Levine" <[email-masked]>
Date: 16 Nov 2021 12:41:20 -0500

It appears that S Moonesamy  <[email-masked]> said:
>>behavior. ...

>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: S Moonesamy <[email-masked]>
Date: Thu, 18 Nov 2021 12:45:12 -0800

Hi John,
>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: "Brad Biddle" <[email-masked]>
Date: Mon, 22 Nov 2021 07:28:32 -0800

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 | [email-masked] | +1.503.502.1259 (mobile) | 
http://biddle.law

On 3 Nov 2021, at 8:37, Joel M. Halpern wrote:

> guidelines.  We tried to address what we heard in the previous 
> feedback, and tightened the language related to legal issues.
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Nov 2021 16:37:40 +0000

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: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Nov 2021 11:44:41 -0500

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

---

From: "John Levine" <[email-masked]>
Date: 22 Nov 2021 17:53:50 -0500

>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: Mark Nottingham <[email-masked]>
Date: Tue, 23 Nov 2021 10:19:22 +1100

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 <[email-masked]> wrote:
> 
> 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.
> 
> Brad Biddle | [email-masked] | +1.503.502.1259 (mobile) | http://biddle.law
> 
>> 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
>> 
>> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 22 Nov 2021 18:30:17 -0500

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Nov 2021 14:30:14 +1300

> 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.
  
> aspects of competition law that should be kept in mind by anyone to whom

Which is (I think) everybody, because of the above thought experiment.

> 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

---

From: Rob Sayre <[email-masked]>
Date: Mon, 22 Nov 2021 18:21:03 -0800

On Mon, Nov 22, 2021 at 5:30 PM Brian E Carpenter <
[email-masked]> wrote:

> 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