Narrative Minutes interim-2023-iesg-24 2023-10-26 14:00
narrative-minutes-interim-2023-iesg-24-202310261400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-10-26 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Jenny Bui, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
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
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

Liz: Does anyone want to add anything new to today's agenda?

Andrew: I sent email earlier asking if we could add an executive session at the
end. If possible.

Liz: Yes, we got that. Any other changes to the agenda? Ok great.

1.3 Approval of the minutes of past telechats

Liz: We don't have any minutes to approve since we usually give 2 weeks, and we
just had another formal last week so nothing in minutes. And we can just move
straight to the list of remaining action items.

1.4 List of remaining action items from last telechat

 * DESIGNATED EXPERTS NEEDED

      o Rob Wilton to find designated experts for RFC 9445 (RADIUS
        Extensions for DHCP-Configured Services) [IANA #1279159]

Rob: I thought I sent an email to approve that.

Liz: I don't think we have that.

Rob: I'll have a chat, can we add as a management item? I'll put it in the chat.

      o Roman Danyliw to find designated experts for draft-yee-ssh-iana-
        requirements-03 (Key Exchange Method Names) [IANA #1281831].

Roman: I did not have a chance to button this up despite what I had promise
last time. Same with the ACME one. Although, I continue to think I have done
that.

Liz: Rob I just looked down and saw that we actually do that it as a management
item on the agenda. We'll cover it at the end.

      o Roman Danyliw to find designated experts for RFC 9447, ACME
        Authority Token Challenge Types" [IANA #1281679].

Roman: I have to button those up.

    * OPEN ACTION ITEMS

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

Liz: Warren is not with us so we'll leave in progress for him.

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

Roman: This is done.   We found consensus on the text. I talked to all of the
stream managers this week and they all said thumbs up on the text that we had
produced. Everyone wanted to chat a little bit, but realized the consensus that
it takes to make those words and there is a feature in Github requesting to
action that. Mark as done, please.

Liz: Great, we'll mark this as done.

Lars: I asked by Robert because what we showed them is what should go on the
metadata page for the document in the Datatracker. The question from Robert is
if we also want something on the htmlized page which has the metadata thing on
the right hand side. If you click on the htmlized thing on the Datatracker, it
will take you there. I think we do, but it also needs to be shorter. So we
might need to do it second spin on something we can put there. It can a short
thing that can pop up or something that has something longer, i.e. what we
already agreed on. But maybe we do that sort offline Slack.

Roman: Ok, sounds like a plan.

      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.

Andrew: That text I found in mail from Warren that ended up in the spam, so I
fixed that now. Lars, I saw your proposal, it's pretty far from 7322. The
question is, how far do we need to follow 7322 given that it's an informational
IAB document?

Lars: That's a good question.

Andrew: Your proposal also works, when I wrote the original proposal I tried to
stick as close to 7322 as possible.

Lars: I'm not married to my proposal, I can't even remember what it is just
illustrate how much i'm not married to it. I'm also wondering if this is
something for the RSWG because policy for the serious, at least for the RFCs it
would be. How many authors before you can argue it makes no sense to have more
authors on Internet Drafts than RFCs.

John: I love the idea of punting it to someone else.

Andrew: I also like the idea of punting, John. My only issue is that I rather
not see this take a year to get resolved because it's a question that's coming
up more and more frequently.

John: We can probably do both, right? We could try to wrap up our own
deliberations but also say dear RSWG, would you please come up with something
longer term policy on this?

Andrew: What I would propose based on the lack of congruence between Lars'
proposal and what I originally wrote is that unless there is serious issues, we
go with what I propose pending edits from anyone else who wants to add etc. We
do and put in there that this is interim while we are asking RSWG to do
something about it.

Eric: Isn't this forcing us to go flip flop in 6 months or so? If the proposal
is difference between yours and RSWG?

Andrew: It possible is, but who knows how long the RSWG is going to take to do
anything with it. As I said, rather not be sitting with this a year from now.

Eric: It's not particularly right so we don't need a short term answer in my
opinion.

Andrew: Any other thoughts? Lars? Thoughts?

Lars: Nope.

Sandy: Lars, I wonder if you think this is policy, if it, and there is,
something existing in the style guide, if it should be something that RSAB
looks at for an interim solution.

Lars: The RSAB would only interpret current policy, it couldn't change anything
about the current policy. I think the problem is lack of clarity to some degree.

Sandy: Right, I see.

Lars: I think that clarity needs to really come from the RSAB, otherwise, I
think the community will say that RSAB is overstating overstepping its mandate
and that should be discuss in the RSWG. But I have no problem with the RSWG
telling the RSAB to do this.

Sandy: Ok. Understood.

Andrews: Lars, do we just straight to RSWG or do we use this as an interim?

Lars: If we agree, we can just punt it over. I don't any reason to wait. We can
basically send an email to the RSWG mailing list and say the IESG
theoretically, has the mandate for ownership on Internet Drafts because they're
all input to the standards process. It makes no sense that it'll be different
for what's allowed on Internet Drafts than on RFCs, and that part is up to the
RSWG. We can explain that there's an issue with the current policy as defined
in the RFC and ask them to please clarify that. We can adopt whatever they come
up with also for the Internet Drafts, and if we don't like it then we don't
adopt it and we go in a circle.

Andrew: I'll send an email to RSWG and specify that there is some lack of
clarity that we like some clarity, and if they could provide some guidance.
I'll state in the email that we were working off 7322 but there were some
ambiguities and so if they could please give us a proposal. Anyone got any
issues with that? In which case, can we change that action item to "Andrew to
send email to RSWG"?

Liz: Sure, we can update this for you.

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

Lars: I think to mark as done because I tried and was told by the people of
that had the Netwon BoF that they did one time in GEN area and Mark Nottingham
won the ballot, follow-up is happening in GEN area.  So I think having
scheduled GEN area takes care of this management item. So done.

Liz: Ok, we'll mark this as done.

      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: In progress.

      o Erik Kline to follow up with authors of draft-ietf-6man-rfc6874bis
        to schedule a conversation about the document.

Erik: That conversation might happen in Prague so i'm okay leaving this
management item until after Prague. Otherwise, there's an email thread sort of
ongoing that seems to be a lot more information than previous discussions. If
Murray is okay, i'm ok removing this as a management item but could also leave
it on until the November 30th just to check back in one more time.

Murray: I think that's fine. I think we're on top to the extent as we can be. I
don't know if it needs an identification as a management item more than any
other document that we've been working.

Eric: If there's some intersection with other SDOs, I think that's why it's a
management item.

Erik: Post Prague is fine too, we can revisit it one more time.

Murray: Yeah, that's fine.

Liz: Ok, we'll just leave this as where it is for now.

      o Francesca Palombini to draft an update to the wiki page "Getting
        a Document on the Agenda."

Francesca: In progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

  o draft-ietf-alto-oam-yang-15  - IETF stream
    YANG Data Models for the Application-Layer Traffic Optimization
    (ALTO) Protocol (Proposed Standard)
    Token: Martin Duke

Liz: We have a couple of discusses, we do need to discuss this today?

Martin: Briefly. Thanks for comments everybody; they were good. As usual, i'm
reading these in the last 15 minutes because they happen overnight. Roman, your
discuss is great. The one thing I would say is doing it over plain http is part
of 8895 which is a YANG Model for, so maybe the residual risk of running over
http  is out of scope for this document.

Roman: Ok. I can buy that argument. Just to replay it, this is a YANG model for
previously published document, which specified in a certain class of behavior.
So if we specified it then we should be able YANGized it?

Martin: Yeah.

Roman: I have a similar discuss in the other YANG document where I continue to
understand for new services we need to have http.

Martin: In this day of age, i'm not convinced about that. Let's up this in
revised I-D needed. The author has been pretty responsive. Hopefully this could
be resolved pretty quickly.

Roman: One of the reasons i'm pushing on the TLS part representing in YANG is
my read of what 7285 is it actually made statements that you could use off TLS.
If it says that is the preferred mechanism, we should provide that support.

Martin: Yeah. Liz, revised I-D needed, please.

Liz: Ok, great. We'll leave this where it is with the substate of revised ID
needed.

  o draft-ietf-alto-new-transport-17  - IETF stream
    The ALTO Transport Information Publication Service (Proposed
    Standard)
    Token: Martin Duke

Liz: We also almost all the colors here with a few discusses, we do need to
discuss this now?

Martin: Good comments. This will definitely go to revised I-D needed. Is Zahed
on?

Zahed: I am, yes.

Martin: I didn't get your question about concurrent nonblocking update
transmission. HP2 is also that, it's true that there's not packet loss. The
idea is that resources are available at different times and they're using HP1
model where one is blocked by the other.

Zahed: I understand the concurrent and all they are talking about, but it does
not obviously in the context of this document because it talks about HTP3. It
basically doesn't have HTTP and TCP deadline block for HTP2. HTP3 solves that
one, and HTP2 has headline blocking on TCP level and HTP1 has some other level.
I feel like the authors also mentioned in concurrent means multiple
connections, which is not allowed in HTP2 or HTP3, so to say. I'm not exactly
sure I understand in this context what concurrence means. I expect to describe
it.

Martin: Ok. We can add some text, I guess. I don't have any objections to that,
I think just about everybody discuss this document when you count supports.

Eric: If we can get a reply for the INT DIR, it would be nice as well from the
authors.

Martin:  You wrote that?

Eric: The INT DIRs reviews was negative and not a single reply for one week. It
would be rude.

Martin: Yeah, i'll make sure all this stuff it followed up on.

Eric: Thank you.

Martin: Please move this to revised I-D needed.

Liz: We'll leave this in IESG evaluation with I-D needed.

  o draft-ietf-httpbis-alias-proxy-status-05  - IETF stream
    HTTP Proxy-Status Parameter for Next-Hop Aliases (Proposed Standard)
    Token: Francesca Palombini

Liz: I don't have any discusses here unless there's an objection, it looks like
this one is approved.

Francesca: I believe the authors are preparing an update so if you could add
the revised I-D needed tag to go. Thank you for the reviews, everybody.

Liz: Ok. I'll put this in approved announcement to be send, revised I-D needed.

  o draft-ietf-cbor-time-tag-11  - IETF stream
    Concise Binary Object Representation (CBOR) Tags for Time,
    Duration, and Period (Proposed Standard)
    Token: Francesca Palombini

Liz: We have a couple of discusses, we do need to discuss these today?

Francesca: I think the authors have replied to Murray's discuss point.

Murray: Yeah, Carsten got back to me and he needs to get back and post a
revision. He told me what the answer is, it just needs to be in the document.
So when we get a new version this will be all good to go.

Francesca: Ok, great. Revised I-D needed here too.

Liz: We'll leave this in IESG evaluation with revised I-D needed.

  o draft-ietf-cdni-delegation-acme-03  - IETF stream
    CDNI delegation using Automated Certificate Management Environment
    (Proposed Standard)
    Token: Francesca Palombini

Liz: We have no discusses on this one unless there's an objection, it looks
like this is approved.

Francesca: Thank you for the review. I would like AD follow-up on this because
I haven't followed the conversation, I don't know if there's an update to be
made.

Liz: Ok, perfect. We'll put this in approved announcement to be sent AD
follow-up. Francesca, you can let us know when that is ready.

2.1.2 Returning items

  o draft-ietf-core-sid-22  - IETF stream
    YANG Schema Item iDentifier (YANG SID) (Proposed Standard)
    Token: Francesca Palombini

Liz: We have a couple of discusses, do we need to discuss these today?

Francesca: I don't so, but Rob?

Rob: Sorry, I haven't had a chance to check the latest text. I get the feeling
that sort of Carsten and I getting to consensus of agreement so I think
everything is OK. Even though it isn't already resolved, it will be shortly. I
suspect.

Francesca: I think, Lars, your discuss is somewhat related to what Rob was
discussing with Carsten.

Lars: Sorry for the being late as I just dropped this like an hour ago because
I didn't have enough time to review some stuff so I just went through the
ballots and this one needed one more that's why I read it. My main concern, and
maybe this is something we can talk to Sabrina about which is whether IANA is
actually prepared to store all these zip files because i'm not aware of any
other registries where IANA was tasked with maintaining files associated with
registry entries. Maybe I don't remember, and maybe they're doing this for
somebody else. It seems kind of unusual and it seems kind of a heavy lift for
IANA so I wanted to make sure they're really OK with this.

Rob: I did discuss this with Sabrina and she's been copied into the
conversation i've been having with Carsten, so she knows what has been planned
here. I think they're OK with it. Another example, is arguably the YANG files
cause I think there's references to the files held in IANA as well. They are
also in the RFCs but I think that'd be a place that people might go to get
them. There's also other places you can get the YANG files as well.

Roman: One thing fascinating for me to cite the YANG file, why does the YANG
file stay into the RFC but the SID file does not?

Rob: I think for me, the SID file could more likely change over time maybe gets
corrected without necessarily needing a RFC to update it. I think it could
potentially change. Where YANG file could currently be a RFC. I think the real
answer to this is, I don't think the YANG file should be held in the RFC
either. I think they should be held somewhere else.

(crosstalk)

Lars: This is the old living document issues, and I don't think asking IANA to
be repository for this is super great.

Eric: I also wonder if you have 1 YANG which is stable and having multiple SID
for the same revision, it's inconsistency.

Rob: It wouldn't be the same revisions. You could have a SID file for a later
revision.

Eric: You could have YANG models with revisions in a RFC?

Rob: Not today, but the two in my mind, putting aside the process aspect of
this. I logically think the two is slightly separate. 1 is the YANG model gets
published at one point in time and SID files, I don't know what other reasons
they might evolve separately, but I don't think the file itself has to
necessarily be one at the same time. You would fix something and you SID
generation file or something like that fixed mistake, I can imagine a new
generation to SID files being generated and still relevant to the same YANG
file.

Eric: The issue which is one part of my comment is that specific SID ID is
unusable even if they change the model and I think it's frightening because
they can change the semantics with an identifier.

Rob: because the SID is tied to the path not semantics.

Eric: It's link to an identifier and to the YANG model specific revision, and
the same identifier revision could have a different type.

Rob: The binding to SIDS to paths is not to a particular revision, it uses that
path forever. If you have an interface name, it will always have a given SID
even if you change the type off semantics in a future revision, it still keep
the same SID.

Eric: But then the SID doesn't bear the revision? How can the receiving part
decode this interface in this syntax and interface in depth syntax. It's really
scary.

Rob: That's not what the problem the SID is solving. It's just giving a
numerical identifier as equivalent to the name as a short version of doing the
name.

Eric: It includes the revision of the YANG model, that's what scares me.

Rob: The revision in the SID file from what I remember, is just a reference.
It's just saying this is the version I built the latest SID file from. It's
just a reference rather than saying this SID file is from this particular
revision of the YANG model. You should be able to use an updated newer version
of that SID file against an old version of the YANG model which should be fine,
expect if things get removed or deleted over time. It's not guaranteed but
there's no false binding.

Eric: I can only repeat, i'm scared of the lack of integrity of the full
system, but okay.

Rob: Maybe the solution here, is to get Carsten to come to an informal and
explain how it works.

Francesca: I can try, if we don't resolve this This draft has been with me for
a very long time and then it was with Eric and now it's back with me. I think
it has improved a lot. Thanks for all the comments. I would like to get it
resolved and shipped, so if I suggest we continue discussion with mail. I think
Lars, I can give an attempt at responding to your discuss, but Carsten will
probably also do that. This is very similar to the points that Rob has brought
up as well. If we don't solve it after IETF 118, I can definitely bring it to
an informal and have Carsten discuss it.

Eric: But can we relate it somehow to experimental?

Lars: That doesn't really change anything for me. I'm basically discussing
whether IANA should be a file hosting or not.

Francesca: There is a precedent for it that we got an OK from IANA.

Lars: What's the precedent?

Francesca: I think it's YANG?

Sabrina: I think Roman had a similar question recently. There is precedent on
how the IANA table registries are currently handled where the expert generates
the xml for us, but they're not included in the RFC itself. In additional how
we're currently maintaining the YANG modules.

Roman: I think my question was around a difference precedent than what I think
Lars was saying.  Lars was talking about file hosting. My precedent was, I was
concerned that SID files are defined in the I-D, but then removed in the RFC.
And that seemed confusing to me, because YANG files are published in the RFC
and then published as a file.  I think the precedent was codes for the
international code points is what you told me, Sabrina?

Sabrina: That's correct.

Lars: That's a good point too, Roman. With YANG model, the model that is in the
RFC is the canonical one and if there's ever data corruption in IANA, the RFC,
but here, there's an archival copy would be maintained by IANA, and there's
really no way to later validate whether what IANA has on their website is what
was in the RFC. We have a draft available which would still have the SID file
in it, but it feels brittle and is also feels operationally heavy weight
potentially.

Rob: One other issue putting the SID files in the drafts, is that they want to
publish SID files publishing SID files to the existing 100 YANG models that the
item was published. I'm getting 100 RFC updates for that seems like a
heavyweight process to achieve that.

(crosstalk)

Andrew: How are you concerned about the load? Sorry Lars.

Lars: How would you get community reviews on whether the SID file is correct?

Rob: I think you have designated experts, I don't think you need community
reviews for SID files. It's basically generated by a script, and there are some
reasons where you want tweak them, if you are evolving it and you have got a
model with specifically constrained device.

Lars: Why is part of the ID? If they're basically just a script that you run
over the YANG model? Why do you need to also exclude them in the ID when you
write that?

Rob: So i've said two suggestions. You can embed them in the ID, if you want to
manually control them, for some of the YANG models. Like BGP might be an
example.  It may not have such a target for constrained devices. And hence, you
may not have the hassle of maintaining the SID files during the evolution of
the ID and only create it at the end.

Andrew: My concern with what you just said about a 100 RFCs that needs to be
updated. Is that it increases the workload for IANA for one thing, and i'm not
sure about this at all.

Rob: It's not updating 100 RFCs, we do that if we say we have to embed them
into the RFCs, but otherwise sending IANA 100 references to 100 links. I can't
imagine the load on IANA to upload 100 links to files is necessary.

Andrew: I do have to agree with Lars here that i' m a little bit worried about,
the fact, we have something that we refer back to that is kind of immutable
that will be lost in this process.

Francesca: Ok. Point taken I think we can continue with offline. I will let
Carsten to reply, and if we don't get solution then maybe we can talk about it
in person at 118 and try to resolve it. Try to convince this is the right thing
to do.

Lars: We can add this to the IESG agenda to 118, and we can figure out whether
we want to invite Carsten because IANA is going to be at 118 as well so we have
them there.

Francesca: Ok. When do you mean, exactly?

Lars: We're collecting already agenda items for the for the Sunday meetings,
and for the breakfast meetings if you put it on there then when Mirja and I
triage the list that various people people have come up with, i'll stick it
into one slot somewhere.

Francesca: Could I ask the Secretariat to add it? Or do I need to send an email?

Lars: You just put it in the wiki.

Francesca: Ok, got it. On the wiki.

Liz: Ok, for this document, i'm guessing we might need a revised ID?

Francesca: Yes.

2.2 Individual submissions
2.2.1 New items

o draft-freed-smtp-limits-07  - IETF stream
   The LIMITS SMTP Service Extension (Proposed Standard)
   Token: Murray Kucherawy

Liz: We don't have any discusses in the Datatracker unless there's an
objection, it looks like this is approved.

Paul: I  mean, obviously, it can be approved. I just find it a little weird
that the replied to our comments to at least Roman and my comments was like I 
don't want to change the text because of the previous deceased author. Which I
think is not a very good argument to use if the IESG has issues with the
document that needs to be fixed. Right? It's by the original author cannot do
that. Then it has to be by whoever is the current author of the document. I
will address this issue this time because all these issues are pretty minor and
especially mine are like more questions of why aren't we doing this and I got
answers of why we're not doing it. So that's fine. I found the reasoning not a
good precedent, and I would not like to see that as a precedent for the future
discussion.

Murray: I understand. We can approve this with AD follow-up and I do want to
ask him about that for all the reasons you gave. Approve it and AD follow up,
and i'll talk to him about that.

Liz: Ok, great. We'll put in the approved AD follow-up, and you can let us know.

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

  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

Liz: Roman, do you have any IAB news?

Roman: I'm quickly pivoting. I did not catch anything that I haven't already
previously reported on, which is in flight progress on statements. The most
important one that touches IETF is the RATS working group or select members of
the working group we're going to have a chance to go talk about the attestation
statement with the with the IAB. Otherwise, a number of the other kind of
charter things are in flight. We have the 3 working groups at the meetings, and
the IAB is going  to cover them like they usually do and they've done the
assignment there.

Dhruv: Roman, can I add something?

Roman: Absolutely, Dhruv, I'm sure I missed a few things.

Dhruv: One thing is the IAB is not going to continue with the identity program,
at least see the progress and then conclude whether we close down mailing list
that we have on the IAB as well. Based on the discussed that happened. We
thought the BoFs or anything happening, and maybe the program is not going to
lead to anything new that the IETF isn't already working on. We also approved
the IETF WC3 which was discussed with IESG earlier, and we got feedback and the
IAB approved, we will be sending out the notice.

6. Management issues

6.1 [IANA #1279159] Designated experts for RFC 9445 (RADIUS Extensions for
DHCP-Configured Services) (Rob Wilton)

Liz: Rob has identified Alan and Mohammed as the designated experts for this
registry, does anyone have any objections to naming these two as the designated
experts? Ok, hearing no objections. This is approved, and we will send the
official note to IANA. This will also close Rob's action item.

6.2 In-person IEEE/IETF leadership meeting at IETF-120 (Eric Vyncke)

Eric: It's in Vancouver. The IEEE meeting will be held..

Erik: Madrid, right?

Eric: I think it's in Madrid. It's not 120, right? It should be 121. Where they
are meeting right before, we're thinking of meeting together either Saturday or
Sunday with IEEE leadership and IETF leadership would be nice. Before they were
trying to colocate the meeting, not the same time, but the same city at least
for 3-4 years, but of course the pandemic breaks the cycle. I want to get the
approval of the IESG so we can try to colocate, and accept having a meeting
Saturday or Sunday with IEEE. I don't think there's any objections to it? For
me, it seems like a no brainer.

Paul: Sorry, when are we meeting in Madrid?

Erik: July 2025, I think.

(crosstalk)

Cindy: It's IETF 123; there was confusion because when Jon Rosdahl was talking
about this, he was saying 2024, but it's actually 2025.

Eric: It's in Madrid then. I think asking them actually is kind of sometimes
lagging us regarding setting the agenda and the location. So, they can follow
us and try to get a meeting with IEEE the week before the week after. So we
have an opportunity to meet over the weekend. This is, of course, pretty
important for Erik and myself in the INT area. But I think it's also important
for Ops, for instance, and other people and security, of course, to see what's
happening there. It's a mini social, to meet people rather than being on a call.

Lars: So I think it's fine. I don't expect anybody to still be on the IESG by
then. Let's schedule with the understanding that we're putting some future IESG
members on the hook. I'm guessing IAB is involved in this, so they know about
it.

Dhruv: That what I was going to ask. We would need IAB folks, basically the
people who are involved with the one issues.

Eric: I put IEE and IETF here because IETF, of course, includes IAB.

Paul: So this has nothing to do with something at IETF 120?

Eric: No, forget about the 120, it's 123.

Liz: Anymore discuss needed on this?

Eric: I don't think so, I will reply to the list and say yeah, we're looking
forward to those meetings.

6.3 IESG Meetings at 118 (Secretariat)

Liz: I just did this on here yesterday, because I was looking at the wiki for
topics, and it was looking pretty light. So I just did this on here as kind of
a reminder to put topics on, which now several people have done. So, I don't
know if you all want to spend a few minutes now, talking about the agenda, or
where to put things but it looks at this point there's nothing on the Monday
agenda, so I don't know you want to talk about whether or not to have a Monday
meeting or how many other topics might be coming on the wiki.

Lars: I  would wait for this a little bit and ask people to, like, think what
topics should be there because I've said it a couple times, but I don't think
very many people have put stuff there.

Francesca: I just added 3 topics.

Lars: You can add topics to the joint time with the IAB and Mirja and I will
figure out what goes where.

Francesca: Can I just mentioned the topics I've added so we see if they make
sense at all to to discuss. One is the Core SID, I didn't think we that could
discuss the draft, but if we can, why not. Second the timeline for the WIT
creation, we talked about that in the IESG mailing list. People have given
their opinion, but I thin it'll be good for people to discuss it, and if Robert
could be there for the Datatracker part, it would be good.

Zahed: Francesca, thank you for putting it out because I was just about to
write that because we need to discuss that and other stuff.

Francesca: Murray had one more working group that we haven't announced yet,
which might be good if we moved to WIT. I realized that I have one working
group, UTAH, which is a security related that maybe would be good if it went to
SEC, but at the same time, SEC is very busy. It could go to SEC and I could
still be the responsible AD so it wouldn't add more work to the SEC ADs.

Roman: As the first volley, i'm happy to source.

Paul: Weren't we doing it anyway? We took over some of your documents, right?

Francesca: Yes, you definitely took over some of my documents while I was gone.

Paul: So no extra load then?

Francesca: Because I already gave you some extra load.

Roman: We don't have to change chairs, most importantly, so we're good.

Francesca: I don't think we need to change chairs either way. There's a couple
of working groups that we missed when we sent out the announcement and it'll be
good to figure those out.

Martin: We should also talk about dispatch, the minimum questions is what is
the future of dispatch? That is the ART dispatch with the whole thing. That's
interesting conversation with Mark Nottingham and others about there's a weird
overlap between dispatch and SEC dispatch and should we merge into a super
dispatch? And maybe GEN dispatch is separate still. How would we schedule that?
I had some wild ideas about that by doing, like, Sunday night or Monday morning
or Friday night, or maybe replace some of the plenary with it or something
because obviously it conflicts with everything. But I think it'd be a great
topic for for, uh, Sunday.

Francesca: I actually added it.  actually had added a experiment merging
dispatch session at the 119. it was definitely like that discussion that you're
talking about. But we can start with, like, I don't know if we want to discuss
it more generally. Or do we want to, like, my idea was to have a proposal so
that we can have a decision at the end of that discussion.

Roman: I'd love to discuss that, and I would also like to chum the waters that
if we are combining ART and SEC, I want routing at the table as well because I,
I'm observing splitting between ART and SEC and routing in SEC.

John: We were just texting about that in the back channel. Yeah if we're going
to do this, then do it big.

Francesca: We just need one dispatch, and we just need one one chair from every
area in that dispatch.

(Crosstalk)

Liz: basically, this management and was just a point here to remind everyone to
come to this wiki ad topics. So, if you can think of any more, go ahead and add
them.

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

Eric: Regarding IETF 118, there was the play plenary meeting, I think the time
is wrong on the wiki page. If you look at their reservation.

Liz: The plenary is a half hour earlier than it was at the last meeting.

Eric: I just want to point it to you.

Liz: I'm not sure who's in charge of that, I did not put that on there. Whoever
is bringing the refreshments can change the time.

Cindy: Speaking of refreshments and meetings, this is just a reminder that
while we're in Prague the Sunday, Monday, and Wednesday meeting for IESG there
will coffee and beverages, but there will not be an actual breakfast because
breakfast is provided in the room rate at the Hilton.

Paul: In each individual room?

Liz: The money you paid includes the breakfast at the hotel restaurant. You can
just eat your breakfast there.

Lars: I guess it won't be super busy at the times we're meeting, but let's see
on the first day. Otherwise it might be, I don't know if we can, like, ask them
to reserve a couple of tables or something because I think people will want to
eat quickly. And then run to the meeting, but I can't remember I don't think it
was a problem in Prague. What's the breakfast wasn't in the lobby there?
Somewhere?

Liz: Restaurant right in the lobby there. I remember it's fairly decent size
and there will be coffee and I think maybe a couple of pastries in the meeting
room. So if you skip, you probably won't starve.

Lars: I want to remind you guys to give NOMCOM feedback in Prague. I like to do
it in person, but you can do it any way you want. You can put it in the
Datatracker, but if you do want to do it in person, maybe send them an email to
get some time from them.

6.4 Executive Session (Andrew Alston)

An executive session was held.