Narrative Minutes interim-2023-iesg-14 2023-06-22 14:00
narrative-minutes-interim-2023-iesg-14-202306221400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-06-22 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Suresh Krishnan (Cisco) / IAB Member
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Colin Perkins (University of Glasgow)/ IRTF Chair
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Lars Eggert (NetApp) / IETF Chair, General Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Tim Bray
Rakesh Gandhi
Shinji Sato
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: Any changes to today's agenda?

Andrew: Can we decide later on in the meeting if we want to have an executive
session?

Amy: If you want an executive session it will have to be after the conflict
resolution, which will happen last.

Murray: Did you get my email about choosing some designated experts? I sent it
about thirty minutes ago.

Amy: I don't think I did. We can add another management item for this.

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes of the June 8
teleconference? I'm hearing no objection, so those are approved. We also have
final narrative minutes from June 8; any objection to approving those? Hearing
no objection there either. Lastly, we have BOF coordination call minutes; any
objection to approving those? Hearing no objection.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

   * OPEN ACTION ITEMS

     o Robert Wilton and Warren Kumari to report back to the IESG on the
       impact of COVID-19 to the IETF in July 2023.

On hold.

     o Warren Kumari to follow up on a bis document for RFC 8126 regarding
       designated experts.

Warren: In progress.

     o Rob Wilton to draft a proposal to the tools team for what the
       requested information regarding mail statistics should look like.

Rob: I've handed this off to Greg so this can be marked done.

     o Lars Eggert to send email to the LLC about Letters of Invitation
       for Interim Meetings and Retreats

     o Lars Eggert and Martin Duke to rewrite IESG statement to give more
       guidance about issuing LOIs for interim meetings.

Martin: No movement while Lars has been out.

     o Éric Vyncke to follow up on updating the title from "IESG Note" to
       "Public IESG Note".

Amy: I'm going to mark this as done because this is being requested to be
removed altogether.

     o One AD from each area to diagram their Area topology and send it to
       Martin Duke for collation.

Martin: Nothing has happened here.

Roman: I want to revisit that action item to make sure it's worth the
investment. I thought we were going to use those maps as decision support to
reshuffle the areas. The vibe I got from the retreat was that there was an
appetite in individual ADs changing their workloads. If there isn't an appetite
to take on more work or do less work I'm not sure how the area reshuffle helps
us.

Martin: My interpretation of that meeting was that different ADs reacted
differently. I got the feeling RTG and SEC were happy with their little empires.

Roman: SEC is actively willing to let go of their empire.

Martin: Okay, I guess not. If I'm wrong, that's great. Certainly ART is open to
reimagining how that all works. After I wore Eric V down to the point where he
thought what I proposed was not a terrible idea.

Andrew: As I said at the meeting, from a routing perspective we went through WG
by WG and came to the conclusion that we couldn't see real benefit. It's my
fault you haven't got the diagram, though. If we want to go that way, we didn't
see any real advantage to it when we discussed it.

Martin: Okay. If someone really doesn't want to give up any WGs to other areas,
or doesn't think it's appropriate, there's no mechanism to force you to give me
a map. If all your WGs fit neatly into one of the core competencies you have as
ADs, I'm not going to second guess that nor would I support messing with that.
That's the point of the map, to show what are the things ADs are really
supposed to understand when they come in here and what's here just for reasons.
If your area's WGs all fit neatly, then it's okay. Does that make sense to
people?

Eric V: I think even five minutes on it could be useful. I'll try to do it.

Martin: If you want to do a spreadsheet or something, that's fine too. No need
to put it in art if you don't want to. I think we can move on.

     o Roman Danyliw to open a Datatracker issue suggesting a feature to
       better signal individual contributions.

Roman: I'm in progress on that. There's a more comprehensive effort Jay and
Greg are leading and I haven't synced with them to figure out whether our
little request should just be part of what they're doing or not. The plan Jay
and Greg have is better and more comprehensive than what we discussed at the
retreat.

Jay: This is something we're proposing to Lars, effectively. He has an action
item to look at re-doing the boilerplate. We're trying to look at the whole
issue around how people mis-perceive contributions so that would mean the
boilerplate, the presentation on the website, all those other things. We've put
some analysis together about this but ultimately Lars has to give us guidance
on what route we follow. It's not clear how much of this is community owned and
how appropriate it is for the LLC to be involved, all of those internal
political things. We'll pick that up come 117 and afterwards with Lars.

Roman: I think what we have is a very narrow thing, so why don't I make a
proposal of what the narrow thing would look like and then we can have a
discussion about whether that should go with a comprehensive change or whether
we should just do it.

Jay: Is there any interest in me circulating the stuff Greg and I are working
on?

Roman: I thought it was great.

Amy: So let's keep this in progress.

     o Martin Duke, Zahed Sarker, and John Scudder to work with Jay Daley
       and Brad Biddle to come up with canned IPR Disclosure text and
       possible proposals for other updates.

John: In progress. We're going to have a meeting on Monday.

     o Lars Eggert to ask the LLC to come up with a proposal on how we can
       support a pre-configured remote participation option in side
       meeting rooms.

Jay: We are looking at this one on Lars's behalf, so work is underway on this
one.

     o Lars Eggert to write an update to the Support Documents in IETF
       Working Groups statement.

     o Murray Kucherawy to respond to the email "RFC 1952: Any plan for a
       new extra field registry."

Murray: In progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pce-local-protection-enforcement-10  - IETF stream
   Local Protection Enforcement in PCEP (Proposed Standard)
   Token: John Scudder

Amy: I have a Discuss here; do we need to discuss that today?

John: No, the authors haven't had a chance to respond yet and I'm confident
they will.

Roman: I think it's an easy fix.

John: It is, they'll fix it.

Amy: That sounds like a Revised I-D Needed, so it will stay in IESG Evaluation.

 o draft-ietf-jsonpath-iregexp-07  - IETF stream
   I-Regexp: An Interoperable Regexp Format (Proposed Standard)
   Token: Murray Kucherawy

Amy: There are no Discusses in the tracker, so unless there's an objection, it
looks like this is approved.

Murray: You can approve it. To answer Eric and Roman who were asking about the
chartering question, yes I did approve them doing this as a separate document.
It would have been in JSONPATH itself, which is coming, but this would be
useful outside so they agreed to separate it. I neglected to say that in the
writeup.

Rob: You've seen my comments and I'm not going to Discuss on this, but I did
wonder whether having a reference to an implementation would be helpful. They
define a couple of languages but it's not comprehensive and I wasn't sure
whether that's worth following up. I'm not sure I care enough but it felt like
it would be better if that was covered.

Murray: Okay, then instead of Approved, can we put it in AD Followup and I'll
chase that down?

Rob: If they push back, it's fine.

Murray: I think it's worth asking the question, so I'll do the followup.

Amy: Okay, then this will stay in IESG Evaluation::AD Followup, and Murray, you
can let us know when it's ready to go.

 o draft-ietf-ippm-stamp-srpm-13  - IETF stream
   Simple TWAMP (STAMP) Extensions for Segment Routing Networks
   (Proposed Standard)
   Token: Martin Duke

Amy: We do have a Discuss here; do we need to discuss it?

Martin: Briefly. First of all, this will be Revised I-D Needed, because John's
Discuss was great. Murray, did you mean to ballot No Record?

Murray: I didn't finish with this one. If you're waiting for another ballot
from me, I'll get it done in the next day or two.

Martin: Well there's no rush since John's Discuss has to be resolved first.
According to my email a new revision dropped ten minutes ago, so we'll see what
that is. Warren, I'd encourage you to make your Abstain a Discuss. Inability to
interoperate is completely within the Discuss criteria.

Warren: Yeah, I went back and forth between Discuss and Abstain. I didn't just
want it to go around and around in circles.

Andrew: Martin, you'll notice I also have a No Record on there. I wanted this
call to happen before I decided whether or not to Abstain. You've got a
document here with six authors. One of those authors has not posted a mail into
the IETF since 2015 other than IPR disclosures and has been to one IETF more
than ten years ago. It feels like an abuse of process and something we ran into
in SPRING multiple times and I'm not comfortable with it. Since that's not
really a Discuss-able criteria, I haven't decided whether to Abstain or do No
Record, but I'm not comfortable with No Objection. There is meant to be
engagement with the community with authors and if authors are not participating
how is the community meant to engage them?

Paul: That makes two ADs who say they can't really talk to the authors; that's
worrying.

Martin: I don't know these authors at all. I'm concerned about all of this,
frankly.

Warren: During some of my previous interactions I was somewhat scared. This
wasn't just grumpiness but rose to a level that I didn't want to interact. I
think I am just going to change it from Abstain to Discuss. I chickened out
before.

Jim: I think we should discuss this privately.

Andrew: Let's have an executive session.

Martin: There's obviously an iceberg under the surface here that I'm oblivious
to, so let's put this in an executive session.

Amy: For now we'll keep this in IESG Evaluation and move on.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

4. Working Group actions
4.1 WG creation
4.1.1 Proposed for IETF review

 NONE

4.1.2 Proposed for approval

 o BPF/eBPF (bpf)

Amy: I have no blocking comments for this charter, so unless there's an
objection this new working group is approved.

Erik K: I have a new -05 with a tweak for Paul and Rob. I didn't know what
would happen if I uploaded it and if it would reset any ballots.

Amy: It shouldn't do that; feel free to post it when you like.

Erik K: I'll do that forthwith.

Amy: Once we have -05, we'll send the announcement.

 o Machine Learning for Audio Coding (mlcodec)

Amy: I have no blocking comments for this charter, but I didn't see chairs.

Murray: I have them, I just haven't put them in the tracker yet. I'll do that
when I get somewhere stable.

Amy: Then it looks like this is approved pending the addition of chairs, and
we'll send that new announcement once there are chairs.

 o Congestion Control Working Group (ccwg)

Amy: I have no blocking comments for this charter, but the milestones don't
have any dates so those need to be moved into the Datatracker as milestones
instead of in the charter.

Martin: As Zahed's proxy, I'll take care of that. A number of Transport groups
have moved away from dated milestones.

Amy: You have to either date them or say that no dates are necessary.

Martin: I can figure it out. I'll make this change today.

Amy: Then this is Approved, pending milestones.

 o Network Inventory YANG (ivy)

Amy: I have no blocking comments for this charter, so unless there's an
objection this new working group is approved.

Rob: I did have some minor comments from Benoit I want to discuss and some
minor tweaks so I think I'd like to get those in before approving.

Eric V: Is it mainly textual?

Rob: Yes, just a minor tweak to technology specific, just a trivial change to
clarify something.

Amy: This will go into Approved, pending minor edits. You can just let us know
when you're ready and we'll send the announcement.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Roman: We've talked about some of these already. The technical talks in
progress are on satellite communication and censorship.  Two in-flight things:
looking at the last ten years of IAB Workshops to make sure there are no missed
actions, and what to do next after the E-impact workshop. Lastly, a recharter
of DINRG is in progress.

Paul: The IAB decided not to respond to the NIST thing.

6. Management issues

6.1 To Minute: Request to Remove "IESG Note" field from the datatracker

Amy: This is to minute that removing the "IESG Note" field from the datatracker
has been decided and will be passed on to the Tools Team.

6.2 IANA #1272388] renewing early allocations for
draft-ietf-netmod-syslog-model (IANA)

Amy: This needs a renewal of its early allocation.

Rob: This is back in the WG right now but I think this is going to go sometime
this year, so I'd like this to be approved if possible.

Amy: Is there any objection to the approval of this early allocation renewal?
I'm hearing no objections, so that's approved and we'll send the note to IANA.

6.3 Clash List Review (Lars)

Amy: Lars had added this. Did anyone get a chance to take a look at this? Jay,
I think you were also named, is this something you reviewed as well?

Jay: We don't review this ever, basically. This is an opportunity for it to be
reviewed. There's a specific thing Greg can talk about as to why this was
triggered.

Greg: It came up in consideration of meetings we might reach out to or have
presence at. That just led into the realization that this hadn't been updated
for a long time and included some bodies that don't exist and did not include
others that probably ought to be there.

Andrew: You have AFRINIC on there which you won't be able to reach out to. You
could take that off. And AfNOG is neither here nor there and I'm not sure you'd
really want to have that on the list.

Jay: We don't actually contact anyone on this list. We set our dates further in
advance than everyone else, so everyone else generally works around us. If we
were to set a date and one of these people like NANOG scheduled on top of us,
we're unlikely to change our dates. There's no particular thing except when we
come to set the dates, we check that no one else has set dates around that time.

Jay: We have a couple of suggestions in Slack. The EBPF Foundation, does anyone
object to adding that to List B? Great, we'll add that. I think we'll leave it
at that for now and maybe we'll bring this back for you to review every year or
two.

6.4 Telechat Dates between IETF 117 and IETF 118 (Secretariat)

The schedule of telechats between IETF 117 and 118 will be as follows:

August 3 - No Meeting - week directly after IETF 117

August 10 - Formal telechat

August 17 - Informal telechat

August 24 - Formal telechat

August 31 - Informal telechat

September 7 - Formal telechat

September 14 - Informal telechat

September 21 - Formal telechat

September 28 - Informal telechat

October 5 - Formal telechat

October 12 - Informal telechat

October 19 - Formal telechat

October 26 - Formal telechat

November 2 - No Meeting - travel to IETF 118

This gives us 6 or seven formal telechats before IETF 118.

6.5 RSWG Chair Appointment (Secretariat)

Amy: This is to look at the timeline for this appointment. If this looks good
to everyone, I'll send the call for nominations for the chair today to end on
20 July.

Eric V: The intent is to do some interview/discussion during IETF, then?

Amy: I believe so. If that is the most convenient for folks who are interested
that would be the target. Okay, we'll get that message sent out as listed here
today.

6.7 Open Roaming (Eric Vyncke)

Eric V: I'm not an expert in open roaming but I had a discussion with the NOC
team and I think I got a good idea of what's happening there. There's a draft
describing the set of protocols which is basically eduroam plus plus. The trick
is that they are using specific wifi beacons so you don't need to associate
with open roaming SSID, any SSID can be associated with it. The goal would be
to prepare consensus among us and say to Lars if we see a problem or not.

Roman: I don't know enough about this. What is the IETF technology we're
exercising that we don't understand? I understand at the back end there is a
bunch of authentication that happens, but I thought that stuff was proven.
What's the experiment?

Eric V: The experiment is to show to the madinas people what can be done. Like
a proof of concept that it works.

Roman: Maybe I'm confused about the charter of madinas. I thought they weren't
supposed to make any new spec, but document what's happening in the wild. They
can't document what's happening in the wild without running this experiment?
I'm confused.

Eric V: They won't develop any protocols, to be clear. One suggestion in one
current BCP draft is that open roaming or similar can address the fact that you
can keep your session even if the MAC address is changing.

Roman: I guess I'm not deep enough into it. It seems like a stretch to me to
madinas.

Eric V: I do agree with you on that. I think it's more like a proof of concept.

Roman: So what IETF thing are we helping by doing this? I'm not against doing
science and research but what's the decision support this is enabling for IETF
work?

Eric V: I don't think whether this works or not will change anything for IETF
protocols. In the longer term, and it's really up to us to do it, it could
facilitate people joining the IETF if they already have the credentials. As
soon as we can make the datatracker as an IDP, which is far away, then with
your datatracker credentials you can associate to other places if you want to.
That's very far away.

Roman: I'm kind of stuck with not having a clear link for existing work to the
IETF, and if we were doing just generic science, we don't have a good
experiment set up.

Warren: I'll drop a link in the chat which the proponents had sent around. This
provides a little more information on the experiment. Maybe that will help
support doing this or not.

Eric V: I forwarded it just before the call as well.

Warren: That provides some justification. As a note, I think this document
needs way more description about the privacy implications of doing this. But it
has some experimental objectives. I'll note for the first one, we know the
level of complexity. At the very end of Yokohama, it was enabled in the NOC and
the complexity is not difficult.

Roman: I promise to give this more attention. In my superficial glance I still
don't understand, not saying it's a bad thing. IT seems like we're talking
about a technology that isn't the IETF's and we're going to run an experiment
to understand properties about this thing that isn't ours. So we're a test bit
of convenience. If that's the argument, that's a different push and that's
okay. Who are we servicing with this?

Eric V: At least we'll have some sharp privacy eyes on it. It's not doing a
service to the IETF, it's the IETF doing a service to WBA in this case.

Paul: I'm not sure if people will spot privacy issues when they're using the
IETF to work during the week.

Warren: I think WBA already knows if it works, since according to Open Roaming
there are a million access points with this enabled. I think the utility here
is A) the proponents have been asking for a long time, and to be honest they've
been jerked around a little, and B) having IETF people look at the privacy
implications when they're written up might be helpful, although I don't know
how much that's going to change things.

Roman: So the IETF is going to do a free security eval for a set of
technologies it doesn't have change control and isn't going to work on with no
structured process?

Paul: During the busiest week of the year.

Warren: Another thing which was pointed out was a lot of devices are shipping
with open roaming enabled by default. Potentially what would be useful for IETF
participants to discover, although I don't know if they really would, did you
know your vendor has opted you into this solution? That's handwavy as an
experiment description.

Eric V: So how do we proceed now? I still see Roman is not completely convinced.

Roman: Maybe this is the research question. The concerns we have around
privacy, do we need an experiment to document them or can we just list them
right now based on the design? What do we think gets surfaced from this data
collection? Is it awareness? Is it a technical analysis? I heard both just now.
All of that is not documented in the experimental setup.

Eric V: Like Warren said, we know whether your own device is opt in by default.
I can ask Juan Carlso to document further.

Roman: So we don't understand on the population of mobile devices how deeply
penetrated this is? I guess it's a firmware build issue, a carrier
configuration build issue and that's what we're trying to surface? I don't get
that.

Eric V: There is a link with madinas. It's little but it's still a link. And
you will notice the draft from Bruno Tomas is not a madinas draft, it's
independent stream.

Roman: So now we're doing security analysis of the independent stream
documents, which we religiously avoid in a lot of other contexts.

Warren: Another way to look at this is that this isn't really an experiment,
it's a service we are trialing for the IETF users to see if they enjoy it.
Maybe some set of users will arrive at the meeting and will be thrilled to
discover their devices connect to the network without them doing anything. From
the NOC side, it's fairly easy to do.

Eric V: It's mostly risk free, is my understanding.

Warren: It should be relatively risk free on the NOC side because we can
configure it. We don't know how reliable it will be that users connect. We have
very little visibility for debugging but we can tell people to use the IETF
SSID instead. There's a slight risk that non-IETF people will also join the
network but that happens already anyway.

Roman: If we want to bill this as a usability new feature for the IETF, that's
great. Then the proposal should give us the after survey of how to elicit
feedback. We just have to choose a path that motivates this and then we can
make the assessment of whether it's worth doing.

Warren: One of the things that's still required is it needs a very very clear
writeup of the privacy implications for the user and for the IETF and what
information gets exposed to and collected by whom. Some of this is that it gets
privacy focused people looking at it and maybe they provide feedback, although
this is so widely deployed I don't think there's anything the IETF could say
that would adjust the privacy implications.

Roman: Right, so if that's the case, I would revisit why we do this if the
input doesn't matter.

Eric V: You're splitting hairs, Roman.

Roman: If we need crispness, based on the little information I have, my current
position is no we shouldn't do this. I'll read the documents but I'm a no right
now.

Eric V: Thanks for making it clear. I guess we'll close the topic now. I'll ask
Juan Carlos to update the google documents.

Roman: Thanks for the effort to write it up.

Warren: The NOC is working toward the assumption that this will be approved so
we have all our ducks in a row. If it's approved we flip the knob and if it's
not approved we don't. We'll attempt to be prepared either way.

6.8 Disabling 802.1X / enabling WPA3 (Warren Kumari)

Warren: I'd like to quickly present a few slides. This is a proposal by the NOC
to make a change. Basically we are proposing we turn off 802.1X and instead
turn on WPA2 and 3 on the IETF SSID. We want to do this because 802.1X makes us
sad. We need some additional infrastructure; every time a user joins the SSID
there's a lot of RADIUS infrastructure that goes back and forth. This doesn't
mean we'd turn off RADIUS completely because we'd still need it for EduRoam,
but it's not in the critical path for the "ietf" SSID. There's also a
noticeable amount of additional help desk tickets. Renewing the 802.1X
certificate should be easy to replace but there are a bunch of reasons it's not
actually easy to replace. It's not massive work but it's annoying. Much more
importantly, 802.1X still seems to cause issues for users like with managed
machines; lots of managed machines won't allow adding a certificate to the
trust store. There's also a weird user experience because every year the
certificate changes. Everyone just blindly trusts this new certificate and
there's no easy way to connect the certificate to the name. We do post the cert
fingerprint on the meeting page, but no one uses it. We know this because for
at least one meeting, the certificate was wrong, and no one noticed. We get a
couple of help desk tickets a day about this and because .1X is hard to
configure on many OS, a bunch of people just use the legacy SSIDs.

We started doing this back in the WEP days, but now we have WPA2 and WPA3 which
are good enough and good. We believe the deployment of encryption across the
Internet has reached the stage where the risk with WPA is acceptable. Tons of
people use "ietf-hotel" which isn't encrypted. We have more backup material as
well. Before proposing this to the community I wanted to see what you all
thought.

Roman: Based on the evidence based approach you have about how things have been
used, I think there's a very clear cut case for WPA2.

Warren: I'm going to present this to the community and just wanted to run it
past you first in case you said it was dumb.

Martin: We should do this. I just gave up and use ietf-legacy. Now I know why.

Warren: Thanks very much.

6.9 Designated Experts for IANA CoRE Parameters registry group (Murray)

Amy: Murray, you sent email on this today. We have two people to add to these
registries, Bilhanan Silverajan and Esko Dijk. Is there any objection to
revising these lists of designated experts? I'm hearing no objection, so we
will send that official note to IANA.

7. Any Other Business (WG News, New Proposals, etc.)

No other business.

6.6 Agenda Conflict Resolution for IETF 117 (Secretariat)

The IETF 117 draft preliminary agenda was discussed.