Skip to main content

Narrative Minutes interim-2023-iesg-18 2023-08-24 14:00
narrative-minutes-interim-2023-iesg-18-202308241400-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2023-08-24 14:00
Title Narrative Minutes interim-2023-iesg-18 2023-08-24 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2023-iesg-18-202308241400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-08-24 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
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General 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
Murray Kucherawy (Meta) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Roman Danyliw (CERT/SEI) / Security Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Paul Wouters (Aiven) /  Security Area

OBSERVERS
---------------------------------
Oooonduke
Lee-Berkeley Shaw

1.2 Bash the agenda

Amy: Anything new to add or any other changes?

Rob: I don't know if you saw my email about adding designated experts for my
first action item.

Amy: I did not, thank you. We will add that.

Lars: The support documents thing, we revised it and looked at it in the
informal and I was wondering if we could ship it. Let's put that as a
management item later.

Zahed: We pushed one document discussion on DTN.

Amy: Yes, that's on the agenda today.

Éric V: About the Friday in Prague, finishing at 16:30 or 17:00; did we make a
decision there?

Amy: There was email about this recently; I think the option ending at 17:00
was better.

Éric V: Let's put that on the agenda and minute the decision, then.

Amy: Okay, three new management items.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from August 10 being approved?

Éric V: I just sent you an email a few minutes ago with a minor change to the
narrative minutes.

Amy: I'm hearing no objection to the official minutes and we have one small
change to the narrative minutes, and we'll make that change before posting.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Rob Wilton to find designated experts for RFC 9390 (Diameter Group
       Signaling) [IANA #1275381].

Amy: This is now on the agenda as a new management item.

     o Roman Danyliw to find designated experts for RFC 9393 on Concise
       Software Identification Tags [IANA #1275658].

Amy: Roman couldn't be here today.

     o Paul Wouters to find designated experts for RFC 9420 on Messaging
       Layer Security (MLS) [IANA #1276814]

Amy: Paul sent names for designated experts, so we will get to that in
management items.

     o Murray Kucherawy to find designated experts for RFC 9457 on Problem
       Details for HTTP APIs [IANA #1277796]

Murray: I put out a call and nobody answered, so this is still in progress. If
this remains dead for too long I'm not sure what to do.

   * OPEN ACTION ITEMS

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

Amy: This seems like it morphed into one of the other action items for you and
Lars. Is this separate?

Warren: It is separate. This is a document Barry says he's working on because
he was the original author of 8126. I reached out a few days ago and asked if I
could help push it along and haven't heard back yet. This is in progress.

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

Amy: Roman couldn't be here today.

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

Amy: This is on the agenda now as a new management item so we can mark this as
done.

     o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John Scudder,
       and Jim Guichard to draft text regarding document authorship/editorship
       with regards to the number of authors listed.

Warren: I should mention we have six people on a thing saying we should not
have more than five people on documents.

Andrew: I'm planning on sending out something by the end of the week. John did
send out some stuff. My current view is we need to reiterate the current text
in the documents.

     o Lars Eggert to facilitate a community discussion on priorities for IESG
       processes.

Lars: That's in progress. I forwarded what Adrian and Rich sent for a BOF
proposal. I'm a little worried there's an assumption that ADs are fine with
recording all kinds of data about how we do our jobs. I want to understand what
they think we should do. I find time tracking to be quite a bit of overhead.
Maybe it's something that can be automated in some way. At least the direction
of the BOF proposal seems to be something that can be useful.

Zahed: What's the history of this?

Lars: We had a presentation about this in GENDISPATCH. There seems to be a
belief that there aren't enough candidates for Nomcom because there's a
perception that it's too much work or that it is too much work. So there's a
proposal to gather some data. There isn't much of a proposal other than that.

Zahed: So the current intention of collecting the data is to facilitate that
discussion.

Lars: The BOF is about what specific data they can gather from us and how it
should be analyzed so that afterwards the community has some sort of insight
into what the job of AD is like. The background is that Rich seems to believe
one reason there aren't enough candidates is because the job is too much work.
I was going to propose a different experiment which is to ask everyone who was
nominated but didn't accept. The two can be done in parallel.

Warren: I don't know how having a bunch of toil wouldn't make the job harder
and more work.

Lars: That's also my concern. I tried doing it and it's overhead. That's
basically what's going on with facilitating this thing. We can discuss it more
later.

     o Lars Eggert to draft a response to the appeal on the current
       guidance on interim meetings.

Lars: We have an executive session at the end to discuss the response to
John's. I confirmed with Ted that his appeal has been addressed. I would claim
this as done.

     o IESG to decide how to use the experimental Friday afternoon
       sessions at IETF 118.

Amy: We've been talking about the schedule and you can also discuss how to
allocate sessions, like which ones will be relegated to Friday; will they be
overflow sessions or regular sessions? That's what this item is about.

     o Lars Eggert and Warren Kumari to 1) draft a revision of RFC 4858, 2)
     draft
       a revised IESG Statement on Document Shepherds (original statement
       October 2010), and 3) update the WG Chairs wiki to point to the new IESG
       Statement.

Lars: This is in progress.

     o Mirja Kühlewind to draft a proposal to the tools team regarding removing
     the
       requirement of needing an author email for deceased authors.

Mirja: I didn't draft a proposal, I shared it with Robert and made a different
proposal. Apparently Robert looked a little deeper into it; it needs tool
changes but it's still not clear to me how much change is needed. I can follow
up with Robert again or we can wait for him to come back to us.

Amy: Did you want to keep the action item in progress?

Mirja: Maybe we can just give this to the Tools liaison and they can follow up.
Who's the tools liaison?

Amy: The liaisons are Éric V and Warren.

Warren: I'm still a bit unclear as to how we think it's supposed to work. There
are many places where it would need to change.

Mirja: There is a long term plan to rework this dependency on email lists and
have things more closely connected to Datatracker accounts, but that's a bigger
project that's already going to happen. The interim solution was just to take
the account and set all the email addresses to inactive and make sure no email
would be sent out based on our internal processing.

Éric V: The email address is mostly used as a key in the database. If we remove
the key we'll have some constraint there.

Mirja: In this interim proposal, the key will not be removed. The email address
is still needed when you submit the draft but you don't need it in the draft.
We want to make sure none of the emails the Datatracker produces are sent to
this email address.

Warren: Oh, okay. Now I understand much more.

Mirja: The initial idea was that if you set all email addresses of this account
to inactive, it won't send any mail, but apparently that wasn't enough. So
there's some amount of work to be done but I'm not sure what it is.

Amy: So we'll move this action item from Mirja to Warren and change it to
follow up.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-lake-edhoc-20  - IETF stream
   Ephemeral Diffie-Hellman Over COSE (EDHOC) (Proposed Standard)
   Token: Paul Wouters

Amy: Paul couldn't be with us today. I have a couple of Discusses; do we need
to discuss those today? Or Lars, as the Discuss-holder present, do you have a
feeling if this will require a revised I-D?

Lars: It's going to require a Revised I-D but my Discuss can be resolved with
what they put in email. I'm not sure about Roman's. But definitely a Revised
I-D.

 o draft-ietf-jsonpath-base-19  - IETF stream
   JSONPath: Query expressions for JSON (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Murray: I don't think so. I'm just seeing it for the first time because I was
on vacation. I can follow up with the authors. Put this in AD Followup.

Amy: Okay, thanks.

 o draft-ietf-regext-rdap-reverse-search-24  - IETF stream
   Registration Data Access Protocol (RDAP) Reverse Search (Proposed
   Standard)
   Token: Murray Kucherawy

Amy: I have a couple of Discusses; do we need to discuss those today?

Murray: The only one I want to chat about is the one where Lars is asking if
it's within charter. I believe it is because the upper part of the charter
talks about standards and does not enumerate which ones they'll work on. I
agree it's kind of open ended but that's what the charter seems to allow.

Lars: My reading was that the bullets on the bottom restricted what's in the
top, but if that's not the case, I will clear.

Murray: That's not how I've been interpreting it. I think I will go back to the
WG and say that Lars had a point and it is rather open ended. To be fair to
them, though, they have been very diligent about updating milestones which I
approve as they go through.

Warren: It is very open ended but I don't know where else this sort of work
could happen. I didn't ballot on this because I wasn't quite sure how. A lot of
the questions raised, especially from the opsdir review, is that it's very
unclear how this and ICANN policy stuff interact. A lot of the questions around
privacy and security were related to how to figure out if someone is authorized
or not. All of that is still gated on ICANN figuring out what they're doing
with the updated selective availability to something something available. It
feels as though some of this is walking into ICANN policy territory but ICANN
needs this so I don't know what to do. The opsdir review specifically asked a
bunch of those things.

Murray: I don't think it's unreasonable to ask those questions and the WG
should be prepared to deal with them. It has come up before that there's a lot
of stuff that's kind of ICANN magic in these places. One person has said why
are we doing standards work that only applies to a tiny audience, that is the
registrars and registries. You'd be within your rights to bring up some of
these questions, whether as comments or a Discuss, and see what the WG says.

Warren: I think it's perfectly fine for them to do this. Hopefully the WG is
coordinating with ICANN because we don't want the IETF to accidentally create
ICANN process.

Murray: I invite you to ask that question.

Mirja: Do we need any kind of formal communication with ICANN?

Murray: I don't think that's necessary, unless the answer to Warren's question
surprises us.

Amy: This will go into Revised I-D Needed to address those Discusses.

2.1.2 Returning items

 o draft-ietf-shmoo-remote-fee-08  - IETF stream
   Open Participation Principle regarding Remote Registration Fee
   (Best Current Practice)
   Token: Lars Eggert

Amy: I have no Discusses for this document, so unless there's an objection now,
it looks like this one is approved.

Lars: I think there's a new revision coming.

Mirja: It's mostly small nits, but a new revision is good.

Lars: Revised I-D Needed, then. I'll close SHMOO once this is done.

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

 o draft-ietf-teas-ietf-network-slices-23  - IETF stream
   A Framework for IETF Network Slices (Informational)
   Token: John Scudder

Amy: I have a couple of Discusses; do we need to discuss those today?

John: Yes please. I don't want to talk about Roman's, which is technical stuff
and I think the authors will take care of it. I do want to talk about Paul's
which is a discuss-DISCUSS. It's just not a point that we can or should hold a
document up on but I think the discussion has surfaced a number of useful
things. A bunch of people feel icky about using the letters "IETF" in the title
and would be happier if the WG came up with something else. The answers that
came back from the WG were yeah, we felt icky about it too but we haven't come
up with anything else. On that basis, my feeling is that Paul should probably
clear his Discuss and I should work with the authors to see if we can come up
with something better. There are two other things. One is that the authors have
already indicated they'd be happy to change the title in some way that makes it
even clearer that the document isn't trying to poach any other SDO's toys; one
proposal being a framework for network slices in networks built from IETF
technologies. That partially mitigates the concerns I've heard and equally
changing the abstract to say something like general principles of network
slicing in an IETF context. That's potentially helpful. It leaves the question
of if we can use the adjective "IETF" in describing their network slices and I
think the answer is probably yes. Final point, Erik raised with me this
morning, are we really sure we've checked in with 3GPP and made sure they won't
throw a wobbly? I'll take a token to make sure that's been done before we
advance the document. Again, I don't think we should continue holding a Discuss
on that basis.

Zahed: On the 3GPP thing, I think we have enough authors and other people
involved and they haven't complained so I don't think 3GPP will say something
different. If you want to send an LS or some coordination I think that's fine,
but I don't think that will be a problem. My other comment is that we should
just say the network slices are based on IETF technology and write that in the
abstract and maybe we can just put that in the terminology section.

John: At one point I specifically put that suggestion to Adrian to just clearly
define what you're talking about in the definition and say network slice. His
answer was essentially that they're not doing it because reasons. The bit that
sticks in my head is that the proposal was made, the authors and WG thought
about it, and decided not to do it.

Martin: Why are we taking a term that was made by someone else and just adding
IETF to it? Why not just use a different word other than slice? Allocation,
assignment…..any synonym of piece.

John: I have two answers to that. One is I don't know, and the other is that
this is a classic bikeshed conversation. We don't like the color they painted
their bike shed but they have a pretty clear preference and ran it through a
long WG process.

Martin: I'd certainly not Discuss it if they decided to name it Fred, but
there's a specific brand management and authority grabbing issue here. This
IETF has cared a lot about that perception. I think it's a little different
from a standard bikeshed. If they named it something completely arbitrary and
random I'd say it's not our business.

John: I thought Reza's reply to the email thread a day or two ago spoke to that
reasonably well. He laid out some other options that were considered. They
thought about calling it transport, but another group of people in the IETF
already use that word for something else.

Martin: If someone in the ART area decided to have some concept they called
congestion control that was completely different from what TCP does, that seems
an unnecessary collision. But I don't care enough to keep talking about this.

Lars: I want to agree with Martin. If this thing was called 'an IETF framework
for network slices', and cited a document to talk about the IETF architecture,
and maybe even call it in another document an IETF network slice to distinguish
it from your own. But using that term inside the document is weird. That said,
I didn't Discuss because I can hold my nose and pass it and it's already very
late in the game to make that change.

Mirja: I don't think it's a bikeshed and it's not for a WG to decide if they
can define something for the whole IETF. The weird thing is that there is
something like a 5G network, but there's no IETF network. The only IETF network
we have is the wifi at meetings. By defining this term 'IETF network,' you're
defining something that doesn't exist and that's a branding problem.

John: I think you're misconstruing what the adjective "IETF" is modifying. I
think it's modifying "network slice," not "network."

Mirja: It's a slice on a certain network so it's also defining the network.
This has a much bigger impact than something a WG should decide.

John: I still think it's a bikeshed, personally. I've heard from several people
now that it's just this one WG, but it went through IETF Last Call and people
had the opportunity to speak up. I got a comment that IETF Last Call is
meaningless. Whether we think that or not in our private brains, that's our
process. These documents have IETF consensus, not just WG consensus. If we
think that's not working, we need to change our process.

Mirja: Then you don't need IESG review anymore because as soon as it's through
Last Call, there are no comments or anything the IESG can do if something is
wrong. It's the authority of the IESG to flag if something is harmful to the
whole organization.

John: I take your point. The question is, how much to insist on that.

Zahed: I didn't read this as IETF network slice. If I removed the prefix "IETF"
every time it was mentioned, it didn't change the framework. You can just
remove the IETF part. You can say this is our concept of how we see things in
the IETF but anyone can take this and show the requirements to the network and
the network will use whatever technology. This is about IETF technology but in
the rest of the document it says you can tell the network operator what kind of
slice you want and they are allowed to do whatever. I didn't want to go into
that in my ballot but we can talk about that if you want. That is part of the
job of the IESG and I support Mirja.

John: If that's what I said, I didn't mean to say that. What I did mean to say
was that there actually is an IETF consensus, whatever that means, that that
term was okay. I would stick by that. If you look at the Discuss criteria,
they're essentially all technical. You can't have an IETF consensus that pushes
a document through for something that will cause congestion collapse of the
Internet; it's the IESG's job to stop that. There's a proposal here that maybe
it's also the IESG's job to defend the IETF brand. That's kind of inventing a
new role and I don't know if that's appropriate.

Zahed: I don't think this is classical bikeshedding. We can't even decide if
it's a bikeshed or not, if it's a branding thing. It's important for the IESG
to understand what we're doing here. It's not clear to me right now.

Warren: I was one of the people who was really freaked out about them trying to
oversell network slicing. I do think it's within the IESG's remit to help
protect the brand and make sure people aren't claiming more consensus than
there is. However, the AD reached out to the authors and WG, who showed they
had considered a less market-y way of saying things, they made a sincere effort
to find a way to rephrase it, and they couldn't. My concern has been withdrawn.
I think they tried hard and legitimately so this is okay. It's not saying the
IETF thinks network slicing is the best thing ever, it's a way to differentiate
their use of the term from others. I raised a concern. I think people have
tried to address it, and I'm happy they've come up with a reasonable set of
possibilities.

John: Thanks Warren. That jibes with my own impression of how the process has
gone.

Rob: I've already commented on this on email and I already said I wouldn't
Discuss this. I somewhat agree with you, John, in the sense that I don't think
this is Discussable. I do have some concerns about using "IETF" mainly that it
opens the door to other people using "IETF" in front of protocols. I don't
think it actually looks that good. Having said that, they talked about changing
the title which would be great. IWithin the document it feels clunky that they
refer to IETF network slicing. I think they should use something else or they
define IETF network slicing and then abbreviate it to INS or something like
that. If other documents refer to it as IETF network slicing I think that's
fine. I wont' block on this but I wish we could do something better here.

John: One thing we could do is if anyone thinks this situation could be
improved by sticking an IESG statement on the front of the document. It would
be interesting to see what paragraph you would draft for that document and that
at least creates a framework for the authors to see what you want or to say go
ahead and put the statement on. If anyone wants to volunteer to draft that.

Éric V: This kind of statement would say that we, the steering group, are
unable to change the text because the WG refused. It would really appear like a
conflict.

Mirja: I have a different proposal. It seems like there is no good term because
the WG thought hard. Why do we need a term at all? I understand that it's
useful to have this notion while you have a  WG discussion, so it's easy to
distinguish what you're talking about, but in the document you can easily say
this is an IETF framework for network slicing in the title, adda  sentence or
two in the introduction that says this document only talks about slices that
are related to IETF technology and it doesn't refer to, say, 5G, and we only
use network slicing in this document.

John: I did try that exact tack with the authors and they didn't bite. I think
Zahed also mentioned that when reviewing the document he said what if I just
remove the IETF and it doesn't work as well. Was that right?

Zahed: My thinking was if I remove the "IETF" from the description and
framework, it still works. It doesn't need the terminology there. It's still a
terminology that everybody uses. If this is the case, the  IETF has WGs trying
to determine their own version of network slices, let's do it. I'm trying to
figure out what else is going on. It says this is only for IETF technology but
it also says you can use this framework to get anything you want, so 5G slices
are fine.

John: Your point is that you can use this to instantiate the transport portion
of a 5G network slice. But part of their point is we're not trying to claim the
entire 5G network slice, which involves layers we're not involved with. But the
5G network slice requires a transport portion and we think you can instantiate
that using an IETF network slice.

Zahed: That's my understanding.

John: I see lots of Slack messages and I will look at them after the meeting. I
don't know if we should continue talking about this. Paul's not here. I'm kind
of ending up where I began, which is that I would really like PAul to remove
his Discuss, I'd like the freedom to go back and negotiate with the authors and
WG, knowing that we may end up with something like the modified title I
suggested, and I'll take one more swing at getting them to take the IETF
adjective out. It seems like in the end, if they want to publish it that way,
we've now used enough of everyone's time and the Internet is not going to
collapse if we let them do that.

Éric V: But we may have an issue with 3GPP.

John: I did also commit to….Zahed is right that we have a lot of 3GPP people
who have already been in the room so we probably won't have an issue, but I do
agree that it's important to double and triple check when we're dealing with
other SDOs. I think with that, we can move on.

Amy: Thank you for the discussion. It sounds like this will stay in IESG
Evaluation; do you want Revised I-D or AD Followup?

John: Let's do AD Followup.

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

 o conflict-review-nottingham-avoiding-internet-centralization-00
   IETF conflict review for
   draft-nottingham-avoiding-internet-centralization
     draft-nottingham-avoiding-internet-centralization-12
     Centralization, Decentralization, and Internet Standards (ISE:
   Informational)
   Token: Erik Kline

Amy: I have no Discusses, so it looks like this document can go back to the
ISE. This is ready to go and we'll put this into Approved, Announcement to be
Sent.

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

 NONE

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

Lars: We had a call yesterday and a lot of it was spent on the
draft-knodel-terminology. There's some discussion whether the ISE wants to or
should publish it. There's also this identity program starting. And another
program E-Impact, which is being finalized.

Mirja: The E-impact program will be announced very soon. It's not clear yet if
we'll have an identity program but we'll keep discussing it for four weeks. And
we officially have an Outreach Coordinator, Dhruv. That was announced this
morning.

6. Management issues

6.1 DTN Registry Statement (Erik Kline and Zahed Sarker)

Zahed: As background, DTN is trying to update a registry. Previously I told the
IESG there might be a discussion with DTN and the IESG about this. Right now
they are proposing some number to be within the range where they want to have
the new registry functional. They want to put a suspension on allowing any
number of registration requests to IANA right now.

Erik K: They're basically taking a 64 bit space and splitting it up into a high
portion and a low portion. The document there describes how they intend to do
that and why they think it is safe. Basically during some sidebar chats in San
Francisco they thought maybe we should make sure nobody tries to do a land
grab. In order to get up to the 2 billion range, they're currently at 286,000,
so there would have to be 10,000 more allocations. I wouldn't put it beyond
someone to try something so in discussion with the chairs they thought maybe
they should just request that if you happen to allocate 10,000 more of these
things and end up in the 2 billion range, maybe you should pause or deny
allocations in that range. It's going to take an awful lot for this registry to
get to that state, but I never put it past the Internet.

Warren: Challenge accepted!

Erik K: Exactly. That's basically what this is about.

Zahed: I think the ask is if the IESG is fine with this. I promised them I'd
also bring a concern that maybe we're doing a process violation. Is it okay to
tell IANA to do this suspension without having a document? My personal opinion
is fine, we're not telling IANA to change anything, we're just asking them to
suspend a certain range of this registry while the WG decides what to do. But
it's a concern to think about.

Warren: Couldn't we say that the IESG requests that IANA lets us know if it's
getting close to that, and then we could quickly publish a document?

Erik K: This email process was recommended by talking to IANA folks in San
Francisco. They said if the IESG sends an email, they can do it.

Warren: They're not the ones who would get appealed if someone got bent out of
shape. I don't think it's an issue, just mentioning it.

Zahed: I think your idea makes sense and we could write something like that, if
they get up to that number and the DTN WG hasn't produced a document with what
to do, they can come to us. And this is temporary; when things are more clear
in the WG we can revert the decision and take off the suspension.

Erik K: We could change this to ask that IANA temporarily decline registration
requests and something if the update document times out.

Éric V: Do you expect some people to complain about it, besides the process?

Erik K: There has been a thread on DTN about it and one concern was we are
requesting IANA to do something without having an IETF consensus document yet.

Éric V: That's the process. But a technical argument we don't have any, right?

Erik K: No.

Zahed: Only one person raised this and was not sure.

Warren: Let's just send the email. The worst that happens is that someone
appeals it and then we just say, we thought this was reasonable and seemed to
fit within our remit, we won't do it again. Looks good to me.

Lars: I agree, let's do this.

Zahed: Cool. Then I think we can minute that we approved this.

Erik K: I can make the edits and ping you when it's updated.

Zahed: What's the process, that we send this to IANA?

Lars: What's the timeline for this document to be completed? Can we prioritize
this?

Zahed: We're prioritizing this. Most of the work in DTN is revolving around
this discussion. I told them to publish the updated draft and run this through
the WG.

Lars: When do you think this document will be approved so we can unfreeze the
registry?

Zahed: I think the WGLC will be done within weeks. We're not talking years here.

Lars: Thanks.

Amy: Sabrina, do you need an official note from the IESG or is an email coming
from Erik and Zahed good enough?

Sabrina: I think we just need the email.

Amy: Great, thank you.

6.2 Ephemeral Diffie-Hellman Over COSE (EDHOC) Designated Experts (Paul Wouters)

Amy: Paul has identified John Mattsson, Göran Selander, and Mališa Vučinić as
designated experts for this registry. Any objection to approving them? I'm
hearing no objection, so we'll send the official note to IANA.

6.3 [IANA #1276814] RFC 9420 MLS Designed Experts (Paul Wouters)

Amy: Paul has identified Sean Turner, Raphael Robert, and Richard Barnes as
designated experts for these registries. Any objection to approving them? I'm
hearing no objection, so we'll send the official note to IANA.

6.4 [IANA #1276364] Designated Experts draft-ietf-emu-aka-pfs (Paul Wouters)

Amy: Paul has identified Jari Arkko and Alan deKok as designated experts for
these registries. Any objection to approving them? I'm hearing no objection, so
we'll send the official note to IANA.

6.6 Designated experts for RFC 9390 (Diameter Group Signaling) [IANA #1275381]
(Rob Wilton)

Amy: Rob has identified Lionel Morand and Jouni Korhonen as designated experts
for this registry. Any objection to approving them? Hearing no objection, so
we'll send the official note to IANA.

6.7 Support Documents (Lars Eggert)

Lars: If people agree, I'll remove the old text. I rewrote the whole thing.
Last time we discussed this, people weren't clear what the original text was,
so I reverted it, but you can't see a useful diff. This is supposed to roll
back some of the strong suggestions in the current statements that says WGs
shouldn't be doing these. Some people on the current IESG seem to believe there
can be a use for them, so we wanted to allow WGs to publish these if they want
to or if their charter requires them to. Looking at the comments I think we're
in the wordsmithing phase.

[some live wordsmithing of the text]

Lars: Okay, thank you for the group editing. I will send a message to Greg to
update this.

6.8 Friday at 118 (Secretariat)

Liz: I think almost everybody who weighed in said they preferred Option 1,
which is the 5 pm ending, so unless anyone has an objection now I think that's
what we should use. And if something changes and we wind up ending a little
early, I don't think people will complain. It doesn't seem like anyone has any
more thoughts, so we can go ahead and do it. Thanks.

Mirja: What does 'doing it' actually mean? Are we announcing this widely?

Liz: I'm not sure. I think it's helpful to at least know the end time, since I
know people will be asking. We don't normally announce the details of the
schedule ahead of time since we don't normally have the details of the schedule
this early, but I don't think there's any harm in saying sessions are projected
to end at 5 pm.

Mirja: We've gotten a couple of questions so we should definitely tell those
people. I think it would be important to maybe send an announcement email and
also make this visible on all the webpages.

Amy: The registration opening email already says that sessions will extend
later than usual, so there is text out there. I don't know if you want to make
a specific message just for this, if the IESG would like to really point this
out to the community, or if you just want to send it to the WG chairs.

Mirja: I missed it in that email.

Amy: That's a good point, people may not read it, so it might be useful to send
a specific message that sessions are projected to end at 17:00.

Mirja: Maybe it's unnecessary but I'd rather do it than not do it.

Éric V: Let's err on the safe side and send it again, very clearly, all
meetings will end at 5 pm.

Mirja: We should also put it somewhere on the 118 page, I'm not sure.

Liz: We'll take this back to the team and we'll figure out all the different
places we can put it on the website so it's clear. For this announcement email,
would you like that to come from the Secretariat or someone on the IESG?

Lars: Secretariat is fine. You can just say that the IESG decided.

Liz: Great, thanks.

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

Dhruv: What's the thinking on the IAB/IESG joint wrapup meeting?

Lars: The IESG has discussed doing it during lunch on Friday, before all
sessions have happened. ISOC has a thing on Friday evening that the IAB is
invited to.

Martin: So to clarify, the IESG is done at 5 on Friday?

Mirja: I think we should confirm with the IAB. The only two proposals on the
table are the lunch break or between 5 and 7 pm.

Lars: That overlaps with the ISOC thing for you guys, right?

Mirja: We can decide when we want to start. It's not the normal ISOC thing,
it's a working dinner with ISOC and the IAB.

Lars: Okay. I'd still suggest doing it at lunch.

Mirja: Let's take it on the next IAB call and provide some feedback to you guys.

Lars: Can we just do it by email?

Dhruv: I can include it with my IAB news, no problem.

6.5 Executive Session: Appeal Response (Lars Eggert)