[Gendispatch] Draft GENAREA minutes - please review

Lars Eggert <lars@eggert.org> Mon, 27 November 2023 11:38 UTC

Return-Path: <lars@eggert.org>
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 428AFC151081 for <gendispatch@ietfa.amsl.com>; Mon, 27 Nov 2023 03:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=eggert.org
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 u-aBUN3LmbMT for <gendispatch@ietfa.amsl.com>; Mon, 27 Nov 2023 03:37:57 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 020B7C15107A for <gendispatch@ietf.org>; Mon, 27 Nov 2023 03:37:56 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 2EFDE8031E for <gendispatch@ietf.org>; Mon, 27 Nov 2023 13:37:54 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eggert.org; s=dkim; t=1701085074; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding; bh=un3mR4zF/DV4UCNlSYEUzxmln1I4aeheQkRlB2ubilE=; b=WzoPBi4yjIS+za9jPERiLMCkXDGAZWO1VFbzTu+Pt2WRbjDBBuznB3GUQm/M+3icVA+4pC gCCDjb1j4RiI022GE0Q9B2/+H9OxHq7oxn9f4xakgEnjpHsSbOkk19LVt3tbmRaeVeRLBl WLRRcMazTqiLuKtBJ5+ZXSIN5U1mtpVQsvcLlOZ8xGZ9sI7C4eaFltW3GqpkRa6fYFswXU l6M3dxoTAu51Zi+7WjLbTx9xmN444XW+r4aiDl3B9RoYu703VaOmksWO0ezNAAZXR7gwRn g1u8xXRGm1LTzz0v9peeNZGAbpD+Hj+yK5E5PwkEkT7MDRwWykPymjJlhToEJw==
From: Lars Eggert <lars@eggert.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Message-Id: <E3AD10C9-C129-496C-A182-D1EF1483ACEB@eggert.org>
Date: Mon, 27 Nov 2023 13:37:53 +0200
To: gendispatch@ietf.org
X-Last-TLS-Session-Version: TLSv1.2
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/b8YJyrbo34-hBGQA697m1hp1P30>
Subject: [Gendispatch] Draft GENAREA minutes - please review
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 27 Nov 2023 11:38:01 -0000

Hi,

below are the minutes from the IETF 118 GENAREA session. Please review and send corrections where needed.

THANK YOU Emily Heron for saving my bacon by proactively taking minutes!

Lars

-- 

# GENAREA @ IETF 118 (Nov 8, 2023)

Note Taker: Emily Heron

## Topic 1: draft-daley-gendispatch-venue-requirements

### Presenting Background from IETF 116

I-D recommends a new policy to replace RFC 8719. Addressing concerns
that the current policy does not "distribute the pain" enough and
makes exploratory meetings too hard.

Hotels and facilities: proposal to clarify what "close proximity"
means. Will state that the hotel should be less than 10 min walk to
venue, and safe to walk am/pm. Room block will meet sufficient
demand. Overflow hotels is an optional feature.

Cullen Jennings: comment on making sure we don't get in a worst state
with "meet expected demand" 1/3 has always been insufficient. Don't
want to run into issues with people missing room block and stating
violation of rule.

Bob Hinden: issue with work - cannot get approval to attend meeting
until after reg opens, cannot book hotel until approval received,
misses room block.

Jay Daley: Problem is currently that we under sell, not that we run
out.

Ted Hardie: Ten minute walk is variable based on mobility issues.
Should state distance, rather than speed. Possible state of gradient.
Ease of movement as opposed to walking - i.e., tram.

Jay Daley: Will do this, current close proximity is loosely defined as
1 km walk, we are trying to narrow this. We will add in a firm
distance.

There will be accessible places for ad hoc meetings, for example, hire
furniture for lobby space. Could be lounge, ad hoc seating, etc.
There will be sufficient places for people to work online on their
own devices.

### Recommendation: Unfiltered Internet Access

Proposal: Neither the facility network, the IETF Hotels network, nor any
upstream providers may impose technical constraints that impact the
ability of meeting attendees to participate in the meeting or develop
Internet protocols.

Bob Hinden: Different countries have different rules for what is
acceptable.

Jay Daley: That is what we are attempting to define here.

Bob Hinden: How do we tell when we are deciding on a meeting in a
certain country what is acceptable filtering?

Jay Daley: In process - that is what this guidance is for.

Bob Hinden: The problem will happen when you arrive on site and
discover filtering constraints.

Jay Daley: The announcements will be made in advance

Mark Nottingham: Reasonable. We as IETF need to experience Internet in
all incarnations. We should announce to community in advance in order
to educate that the Internet works in different ways in different
places.

Pete Resnick: Unfiltered is not on the list of mandatory criteria.
This doc worries too much. This is a good thing, but we do not need
to worry about this as much. Strongly agree with adding more
information, but don't overthink.

David Schinazi: Echo what people have said, dropping this requirement
seems reasonable. This is a rabbithole.

Martin Duke: Like disclosure requirement. Define min. set of
connectivity. Define sensitive content or Netflix, news etc.

Jay Daley: Alternative way of looking: Some say that if you can get
away with doing things you shouldn't by using VPN, that is all that
matters. Many view that this is too complex. Please feel free to have
a go at defining minimum set of connectivity.

Martin Duke: Happy to work with Hackathon.

Cullen Jennings: Largely agree. do not think we should narrowly scope
to IETF/hotel network. This should be country-wide so we do not break
country laws in our own hotels etc. We should experience what it is
to be in that country.

Jay Daley: Current doc scopes it to this.

Bob Hinden: Can't tell from current doc if we would always have IPv6
on current network.

Jay Daley: This is a update, not a replacement.

Roman Danyliw: Does this capture the ability to communicate back to
corp sponsors? Personal VPN? Corp VPN? Love to capture ability to
connect back to corp resources.

Jay Daley: Existing doc already says that. This proposal is an update,
not a replacement.

Pete Resnick: 111 star criteria: over constrained. In regard to <interupted>

Jay Daley: That is being taken out.

Pete Resnick: Retracted

Offlist: Having LLC do this is not the right way around, community
should do it. Tried that at 116 - did not work. LLC is now doing it
again.

Next Steps: update of draft and discussion on mtgvenue@ietf.org
mailing list. At that point, Gen Chair can decide if we are ready for
working group last call.

## Topic 2: draft-halpern-gendispatch-antitrust-06

Background: concerns raised by ISOC in 2020 about IETF legal exposure
to antitrust issues.

Results of legal advice:

- Current policy set provides strong mitigation of antitrust.
- No requirement for new policy.
- Helpful to have an info doc that summarizes our position and
provides guidance No IETF doc can provide legal advice to
participants.

Current Status:

- Current policy has rough consensus
- Small/format changes to be made

Meta considerations: How these points might be weaponized by IETF participants

### Sticking points and proposed solutions

Current: Using *detailed* market data to evaluate ...implementation
costs of *two technical alternatives* to decide ...

Proposed: Using *unpublished*  market data... implementation costs
of *alternative technical proposals* ...

Martin Duke: If we consider market data as mailing list or minutes
doesn't that make it published?

Ted Hardie: Believe market data remains undefined, could mean
anything. Would prefer if we are going to use market data we should
define it clearly.

Jay Daley: Lawyers state that market data is the appropriate phrase to
use without citation.May be better to tackle this by being explicitly
clear that what you are talking about (internal processes) is not
market data.

General Point: Understand weaponization threat: using alternative
English.

Mark Nottingham: Engineers expect clear rules and guidelines, lawyers
see that this is complex and contextual. Best we can do is give
general guidelines. Mismatch may be leading to the discomfort here

Jay Daley: If we were to give policy stuff, the lawyers would want
that to be at a level of clarity Mark: Please avoid making a decision
about competition law.

Jay Daley: Yes, avoided.

### Sticking Points and Proposed Solutions (2)

4.2 Topics Requiring Caution

Current: Entering into group negotiations of IPR terms

Proposed: Entering into *private or potentially discriminatory*, group
negotiations of IPR terms.

Stephan Wenger: Main issue is that the IETF should not be in the
business if advising of things that happen outside of official IETF
meetings.

Jay Daley: Difficult in terms of differing views. Anti-trust law in
corridors. Understand point of view, will discuss with authors.

Lars Eggert (Chair): Is this a sticking point or can we carry forward
with the rest of the doc?

Stephan: I don't like to be in the rough but this is a sticking point.
Issue I have with this point is weaponization - it is very easy to
weaponize discussion. Organization that makes money out of patent
licensing considers discriminatory is different from what another org
may consider discriminatory.

Jay Daley: "Discriminatory" was meant to state who can be involved in
the conversation.

Cullen Jennings: Agree with Stephan - things that happen outside of of
IETF. That is not what private means here. There are many things that
happen in IETF that are not public. This refers to private IETF
meetings. The private here refers to meeting for discussions that are
within the IETF process but are not public.

Jay Daley: Something like a design team?

Cullen Jennings: Design team is a good example of this.

Stephan Wenger: OK with a definition like this.

Jay Daley: Like this and will go back and discuss with co-authors

Phillip Hallam-Baker: Raised specific IPR antitrust issues - two
separate issues. One is protecting IETF, 2nd is protecting the
process. "If you provide that service to other parties, we will
destroy you." Had to talk to management of company making threat.
Need to have statement somewhere that says threats like this cannot
be made in the first place against IETF.

Jay Daley: Already covered in existing set.

Ted Hardie: Agree with Stephan and Cullen: Doc should state that this
behavior must be avoided to avoid antitrust issues. What is not
clear - when IETF provides a facility that is then used for something
that does not follow these rules. Side meeting rooms. What is the
risk to us? Remind people that the use of IETF facilities does not
mean that IETF endorses activities.

Jay Daley: All side meetings and rooms made available must be public.
Risk to us as facilitator is sufficiently close to zero that we do
not need to worry.

Simon Hicks: No IPR discussions connected with meetings in his work.
This limits litigation potential. Should consider stating that no IPR
discussions should take place at IETF.

Jay Daley: These discussions are a necessary part of IETF. Lawyers
looked at these specific cases, not a concern. Cannot go back to undo
IPR rules.

Mark Nottingham: Should start thinking about our role in non IPR abuse
of dominance.

Jay Daley: Cannot do that through this process. That would have to
relate to current safeguards in place to prevent capture.

Stephan Wenger: Recent decision on European committee not to pursue
particular cases does not mean they will not in the future... We
should address this point here first before we go into something
broader ad more difficult.

Mark: Misunderstood what I said, not important.

Lars Eggert (Chair): We are close but we will get a revision based on
discussion - will take discussion to antitrust policy list at
antitrust-policy@ietf.org. Get agreement on where we should take to
next call.

# Topic 3: bofreq-nottingham-ballot

Balloting and DISCUSS Criteria

BOF not approved, using this time.

RFC 2026 Section 6.1.2

Important terms to note: Technical, Quality, Clarity

RFC 2026 Section 4.1.1

IESG Ballot procedures not specified in 2026.

What does "discuss" mean?

*Showed DISCUSS criteria and non-criteria - did not go through it*

What does "Abstain" mean - I feel very strongly and will block OR
non-blocking abstain.

Martin Duke: Third reason for abstain - dislike but no reason.

Briefly reviewed guidance for saying No to a document.

RFC 2026 vs Balloting Criteria
-Objective and Subjective
"Good Conscience" "Believes"

DISCUSS criteria treated as authoritative doc, but created by IESG not
community. As a result, work is subject to criteria outside
communities control

Cullen Jennings: Everybody would agree that if something was done as a
DISCUSS criteria but did not meet 2026 you could appeal. DISUCSS was
meant to limit power of IESG. IESG is willing to be bound by DISCUSS
criteria. Do we agree on this?

Mark Nottingham: You can make appeal, but it does not happen. Most
people are not aware that they can appeal based on 2026. This process
is not well exercised.

Cullen Jennings: Agrees not well known. Would love to see list of docs
that had discusses but should not under 2026.

Option One: Status Quo

- Benefits: IESG remains in control
- Potential Downsides: Conflict between 2026 and DISCUSS criteria.

Option Two: Community Consultation
Requires IESG to consult with community

Lars Eggert (Chair): Clarification: Slides talk about internal
processes. Can you clarify?

Mark Nottingham: Specifically balloting procedures.

Option Three: Bring Balloting into the Process

-Create a WG with Balloting and DISCUSS criteria as input documents
-Publish as process RFCs

Output might be a copy of input

Benefits: Owned by the community. Enhanced legitimacy and
accountability. Clearer guidance.

Downsides: Lack of flexibility. More process RFCs.

Martin Duke: Do you think current DISCUSS criteria are appealable?

Mark Nottingham: No

Discuss

Lars Eggert (Chair): Would love to see data on violations of 2026.

Mark Nottingham: There were things that raised eyebrows.

Barry Leiba: This is addressing a problem we don't have. Need to make
people aware of appeals process. Would not like to have discuss
criteria codified in RFC. Already two mechanisms in place to remove a
discuss - neither of them used. This is generally resolved
internally. Any decision IESG makes is appealable.

Mark Nottingham: Issues that need to be built out. There are things
that are common knowledge to IESG but not to wider community. There
is a power imbalance.

Barry Leiba: Awareness should be raised.

Warren Kumari: Would not be surprised if 2026 violations were made - I
do it. Difference between comment and discuss.

Mark Nottingham: More concerned with abstains than the discusses.

Jon Peterson: Involved with created in DISCUSS criteria. Non-DISCUSS
criteria more important. Should poke at this. Having something like a
WG would be a good thing. Community as a whole should decide these
things, not IESG.

Pete Resnick: There is a problem here. Had discussion with senior
members of community: DISCUSS on doc that is problem but does not
want to appeal. Shocked that chair does not think there is a problem.
People use DISCUSS in inappropriate way. People use abstains in
inappropriate way. Believe problem with current use of 2026. Use of
DISCUSS in this way is exposed to the community as blocking
positions. Whether or not that is how they are intended.

You are assuming things about knowledge in the community that is only
available to current and former IESG members. Formalizing RFC is
wrong approach. Change culture of challenging IESG. Should be
mechanism in IESG to differentiate importance of comments. Current
state of affairs is damaging culturally.

Mark Nottingham: Happy with that outcome.

Ted Hardie: Recently did appeal. Point out that someone who had
document more than a year after submitted it IES prior to DISCUSS -
RFC 3258 - this is an enormous step forward. Question should be what
is the next step forward. Suggestion to add to the discuss
information about how to appeal and contact your WG chair. Don't need
to do anything to change the source of legitimacy. Not necessary to
move to community control. This is part if the community appointed
IESG function. Continue to make improvements, little flags, but core
question is from role IESG has, does not need to shift.

David Schinazi: Ind contributor. There is a real problem here. Written
RFCs, gone through IESG review, gone through DISCUSS. What happens
after DISCUSS has not been cleared? Appeal. That is not possible -
this is clearly defined in 2026. Can define IESG decisions - cannot
appeal DISCUSS that has not been cleared. Newcomers cannot possibly
navigate this system.

Lars Eggert (Chair): Problem is ability of IESG to block documents.

David Schinazi: DISCUSS was based on ADs personal opinion. DISCUSS
criteria says this is OK. Problem is that AD can block document on
something not supported by 2026.

Lars Eggert (Chair): Not possible

Martin Duke: Open to any and all suggestions to demystify process. The
only way to do this is through mentorship, not a doc no one reads.
Opinion that you can appeal. Would support RFC that clarifies. Please
bring if you feel necessary. Options: need to fix balloting
procedures. Need another conversation about abstains - take offline

Murray Kucherawy: Appeals - have been holding DISCUSS for a year. One
side said if you let go will appeal, other side said if you don't let
go will appeal. Nomcom selection is a personality test, not technical
competence test.

Mark Nottingham: Agreement in community would solve these problems.

Cullen Jennings: Two things. One: We keep discussing appeals - there
are three mechanisms for clearing discuss. second is far less known.
2026 does not limit recall process. Two: Abstain position:
functionalist approach - need to make it easy for ADs to be able to
move forward and get doc published. Two types of abstains - that is a
feature, not a bug. We want to publish the doc. This is about the
easiest way to publish a doc - we should retain that. Can be improved
but this is feature not bug. Objective metric is my doc gets
published.

Lars Eggert (Chair): Abstain is useful. However docs sometimes get so
many abstains that doc does not get enough votes.

Cullen Jennings: Many ways to say no. DISCUSS criteria is there for a reason.

Colin Perkins: Individual. Authors and IESG. Third party is WG chairs.
Debate between authors and IESG, WG chairs need to have conversation
with IESG - we should look into how we appoint and educate WG
chairs.

Alexey Melnikov: IESG created DISCUSS criteria - IESG changes every
year. Decision to codify was made by a different set of people.
DISCUSS criteria has not changed. Disagrees that we should codify.
Should analyze differences between 2026 and DISCUSS criteria.

Alissa Cooper: Intrigued by abstain comment. Should not be discussed
separately. Dictionary states that abstain is no action. Abstainer is
then drawn in to further discussion. Abstain is valuable tool to not
have to engage with someone who objects to your document. Abstain is
misunderstood and under utilized. Not enough balance issue - IESG is
not incentivized to work as a team. IESG does not own decisions
collectively.

Lars Eggert (Chair): Data tracker shows as an AD.

Does it work?

Lars Eggert (Chair): Too soon to tell.

Mark Nottingham: What are we designing this for is important
question.

Dashboard for community would be helpful.

Paul Wouters: Doc is stuck with AD - solution you are proposing will
make things worse not better.

Mark Nottingham: You are misunderstanding. Looking for alignment
between AD and community.

Lars Eggert (Chair): Agreement on explaining current process and
tweaks. Lead to BoF proposal.

Venue to continue discussion?

Gendispatch

Can we create mailing list?

Gendispatch for now.

David Schinazi: Make sure that there is a path forward.

Lars Eggert (Chair): What is the role of the IESG? 2026 is pretty
clear.

Mark Nottingham: Ask that IESG be very conscious of gatekeeper
function. If BOF is denied, ask that denial reasons are better than
before.

Lars Eggert (Chair): BOF call was very short - this was the reason.

Mark Nottingham: That's not what the notes said.

Lars Eggert (Chair): Way over time

Martin Duke: Happy to work on demystifying process - not changing process.

Cullen Jennings: Thanking everyone for useful discussion.