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

Toerless Eckert <tte@cs.fau.de> Sun, 14 November 2021 18:14 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C48E3A0E14; Sun, 14 Nov 2021 10:14:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3BKjIcagSTv; Sun, 14 Nov 2021 10:14:19 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59713A0E13; Sun, 14 Nov 2021 10:14:15 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 3A656548019; Sun, 14 Nov 2021 19:14:09 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 207644E9DB3; Sun, 14 Nov 2021 19:14:09 +0100 (CET)
Date: Sun, 14 Nov 2021 19:14:09 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: draft-halpern-gendispatch-antitrust@ietf.org, gendispatch@ietf.org
Message-ID: <YZFR8UOAbsoM0XvP@faui48e.informatik.uni-erlangen.de>
References: <CABcZeBOk7Y6vWeQ2gJ6Z1Z-FCpAdU4+awtcL=zEKrqyvtjDh5g@mail.gmail.com> <0be3bb7d-7387-22c4-844c-1e0fb707b0de@joelhalpern.com> <8b602637-b934-3713-3ce4-7da4e59ed69e@gmail.com> <c8cb28f5-f8b7-0471-ce07-7b33f724c2e6@joelhalpern.com> <745cb38e-5ca2-5f96-ebcd-c88517bb3b46@gmail.com> <c94229e2-a3d8-f25a-1a05-dc649949db34@joelhalpern.com> <bb584c94-0569-432e-e7c3-1439b4645eb7@gmail.com> <18f6b734-7227-4226-3e11-5cbd74ec229c@joelhalpern.com> <YZCWv/IL/gZY6dxu@faui48e.informatik.uni-erlangen.de> <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <69f0cd47-9b50-d4c7-5ffc-21abf1cce0ce@joelhalpern.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/v15Zg28NyhwTVacWdHl-w_MZWfg>
Subject: Re: [Gendispatch] Fwd: I-D Action: draft-halpern-gendispatch-antitrust-01.txt
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Nov 2021 18:14:24 -0000

On Sun, Nov 14, 2021 at 01:39:37AM -0500, Joel M. Halpern wrote:
> Toerless, several reactions to this email.
> 
> First, I (and my co-authors I am confident) do not intend to ignore any
> input.  We may or may not agree with it, but it will not be ignored.
> 
> With regard to your question, the answer, to a first approximation as far as
> my intentions go is both.  Which we tried to say in the document.
> word-smithing suggestions are appreciated.

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

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

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

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

But back to what i would recommend:

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

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

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

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

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

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

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

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

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

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

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

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

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

> Yours,
> Joel
> 
> On 11/13/2021 11:55 PM, Toerless Eckert wrote:
> > On Sun, Nov 07, 2021 at 04:40:13PM -0500, Joel M. Halpern wrote:
> > > I agree with some of your proposals, and disagree with others.
> > > But I do not see any of the actual proposals as substantive enough to affect
> > > the dispatching concern.  They all seem things we can fairly discuss once
> > > dispatching has taken place.
> > 
> > Does that mean the authors will drop and forget input her from the list that
> > is not marked as "unless this issue is resolve, i will not recommend for this
> > document to be dispatched" ?
> > 
> > To repeat here on the list what i said during the WG meeting:
> > 
> > I do not recommend for this document to be dispatched until it is
> > clearer written down agreed to, what actually the goal is. And i see two potentially
> >   even conflicting possible goals:
> > 
> > a) To put into writing sufficient 'Cover My Behind' statements to protect
> > the IETF from legal action in case participants partake in anti-trust
> > behavior. This is not mentioned as a goal in the draft, but i have the
> > strong believ that this must have played a role on writing this document.
> > And i do support such a document, but it should explicitly state that
> > purpose.
> > 
> > b) A document that is really intended to help participants to understand
> > how to not get into anti-trust law issues. This is what the document claims
> > it wants to achieve, but quite frankly i do not even understand the most
> > basic connection between this goal and being an "IETF participant".
> > 
> > E.g.: what legal differences does it make for my compliance (or lack thereof) with
> > anti-trust laws if my actions are performed at the IETF or at any other
> > place ? Lets say when i am getting together "privately for dinner" at an evening
> > of an IETF week with a bunch of folks i know who happen to also attend the
> > IETF, and discuss exactly the same stuff there ? Unless there are really
> > strange laws (which i would be curious to learn about), i'd say the only
> > difference is (a), aka.: possible implication of the IETF into legal
> > actions caused by its participants ("sponsoring anti-trust behavior").
> > 
> > I also think that for (a), we do not necessary need to add more explanatory
> > text (however unfortunate i would think that is), but if the goal is (b),
> > and someone like me is supposed to understand the guidance, then i'd certainly
> > be asking for more explanatory text to be put into the document.
> > 
> > So, i really can't see how we can dispatch a document without being clearer
> > about this goal. And if it is just me being confused here, great, please
> > unconfuse me.
> > 
> > Cheers
> >      Toerless
> > 

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