Narrative Minutes interim-2025-iesg-06: Thu 14:00
narrative-minutes-interim-2025-iesg-06-202504031400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2025-04-03 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Amanda Baber (ICANN) / IANA Liaison
Matthew Bocci (Nokia) / IAB Liaison
Mohamed Boucadair (Orange) / Operations and Management Area
Deb Cooley (DHS CISA) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Gorry Fairhurst (Univ. of Aberdeen) / Web and Internet Transport Area
Liz Flynn (AMS) / IETF Secretariat
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Jean Mahoney (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Andy Newton (ICANN) / Applications and Real-Time Area
Orie Steele (mesur.io) / Applications and Real-Time Area
Ketan Talaulikar (Cisco) / Routing Area
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area

REGRETS
---------------------------------
Mike Bishop (Akamai) / Web and Internet Transport Area
Jay Daley / IETF Executive Director
Erik Kline (Aalyria Technologies) / Internet Area
Tommy Pauly (Apple) / IAB Chair
Sabrina Tanamal (ICANN) / IANA Liaison
Paul Wouters (Aiven) /  Security Area

OBSERVERS
---------------------------------
Sandy Ginoza
Greg Wood

1.2 Bash the agenda

Liz: Does anyone have anything new to add to today's agenda? Roman, we have
your new executive session item.

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes from the March 6
teleconference being approved? I'm hearing no objections, so those are approved
and will be posted. Does anyone have an objection to the narrative minutes from
the March 6 teleconference being approved? I'm hearing no objections, so those
are also approved and will be posted. We also had the IETF 122 BOF Coordination
Call minutes that were sent around a couple of weeks before the IETF meeting;
any objections to approving those as well? Hearing no objections, so those are
also approved and will be posted.

1.4 List of remaining action items from last telechat

* DESIGNATED EXPERTS NEEDED

  o Erik Kline to find designated experts for RFC-ietf-ntp-update-
        Registries (Updating the NTP Registries)[IANA #1412130].

Liz: Erik isn't on the call today, so we'll mark this as in progress for him.

  o Mahesh Jethanandani to find designated experts for RFC 9740 [IANA
        #1414246]

Mahesh: I thought I sent two names? I'll check to see if it actually went out.
Let me confirm that.

Liz: Okay; if you can get us the names before the end of the telechat, we can
add an item at the end to approve them.

  o Paul Wouters to find designated experts for RFC 9678 (Forward
    Secrecy Extension to the Improved Extensible Authentication
    Protocol Method for Authentication and Key Agreement (EAP-AKA' FS))
    [IANA #1414422].
  o Mike Bishop to find designated experts for RFC 9725 (WebRTC-HTTP
    Ingestion Protocol (WHIP)) [IANA #1415864].
  o Orie Steele to find designated experts to replace Graham Klyne in
    the Uniform Resource Identifier (URI) Schemes and Permanent Message
    Header Field Names, Provisional Message Header Field Names
    registries [IANA #1357864].

Liz: These three are all brand new items for Paul, Mike, and Orie.

* OPEN ACTION ITEMS

  o Murray Kucherawy and Éric Vyncke to create a draft IESG statement
    about using 2119 language.

Liz: I know this one is done, so we'll mark this completed.

  o Roman Danyliw to work on adding a checkbox to the meeting
    registration system asking people to identify they are willing to
    serve as WG chair.
  o Roman Danyliw to take a look at Datatracker documentation of
    document states and update as needed.
  o IESG to decide whether we are going to collectively agree to opt in
    to the RPC auth 48 Github experiment if authors are part of the
    github experiment.

Roman: These are all mine. The first two are in progress, and I'd like to
remove the one about the Github experiment pending discussions at the RPC
retreat next week. We'll figure out whether there's an action for us.

  o Murray Kucherawy and Roman Danyliw to find another chair
    for the IANABIS WG.

Roman: This one is also done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pce-segment-routing-policy-cp-26  - IETF stream
   Path Computation Element Communication Protocol (PCEP) Extensions
   for Segment Routing (SR) Policy Candidate Paths (Proposed Standard)
   Token: Roman Danyliw

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this document is approved. I'm not hearing any objection. Roman, what substate
would you like for it?

Roman: First I'd like to thank everyone for your detailed reviews and Éric and
Ketan for your timely re-reviews to clear previous positions. Can we put this
in AD Followup? I was tracking all the Discusse but not the resolution of the
comments, and I want to check that.

Ketan: Revised I-D might be better; there were a couple of things they missed
in the updated text.

Roman: That sounds fine;  I want to re-review as well.

Éric V: Is it usual to use the term LSP for an SRv6 path?

Ketan: This is because PCEP started with LSPs. The very base object, the
protocol is an LSP. That was reused or repurposed for SRv6. That's what we are
stuck with.

Éric V: That's really sad. Then we're stuck with the wrong term forever.

Ketan: This was done when RFC 9603 was approved, so before this document.

Éric V: Thank you.

Liz: This document is Approved, Announcement to be Sent, Revised I-D Needed.

 o draft-ietf-netmod-acl-extensions-16  - IETF stream
   Extensions to the Access Control Lists (ACLs) YANG Model (Proposed
   Standard)
   Token: Mahesh Jethanandani

Liz: There are a couple of Discusses here; do we want to discuss these today?

Roman: I'd like to ask some questions, if that's okay. Med as author, thanks
for the responses on this. I sent something in the last half hour. My point is
that script needs to be normative if you need to invoke it, and the other
discussion point I wanted to have with IANA on the phone, can we talk about
whether IANA is comfortable with downloading the script off of a random place
on Github and executing it? Is this okay?

Amanda: I just saw your message a few minutes ago. We did not catch that;
because the results of the code are also in the appendices, so we were thinking
we could use that. Of course if we update the registries and those things no
longer match at the time of publication, someone's going to have to run that
code.

Roman: I assume that would be you?

Amanda: Yes. I think that's the intention and I think we're not comfortable
with that.

Mahesh: Would it be more comfortable to have the [code] be included in the
document?

Roman: That would satisfy me.

Mahesh: If the resolution is that we might have to include the XSL sheet, is
that something we can take care of, Med?

Med: I think so, we just need to remind that this is an example of implementing
and the IANA guidance is what's normative. I provided for an example the DNS
Yang model in which we have the exact same procedure. And the same XL sheet
that's been used in the past. The discussion I had with the editor of 9108 is
that they just use it manually and once we have the initial version of the IANA
model, it doesn't matter. I don't think it's that important to put this as
normative. If IANA wants something more direct in terms of guidance, I can put
it there, but I think what we have there is sufficient.

Mahesh: I think the question is a stable reference. I know you said that past
publication you think you'll never use the sheet, but I think to satisfy
concerns we might just have to.

Roman: The difference in 9108 is that it did inline the XSLT.

Amanda: I was going to point that out. We did run that in the past and we were
able to grab that directly from the document, we didn't have to go to Github
for anything.

Mahesh: Okay. Med, I know this may have been done differently before, but if
IANA isn't comfortable going to Github, let's talk offline about how to satisfy
that.

Med: Sure.

Mahesh: Okay, so we'll leave it at that.

Liz: This document is going to stay in IESG Evaluation; do you want it in AD
Followup or Revised I-D Needed?

Mahesh: AD Followup, please.

 o draft-ietf-tls-tls12-frozen-07  - IETF stream
   TLS 1.2 is in Feature Freeze (Proposed Standard)
   Token: Paul Wouters

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this document is approved. Okay, this is approved. Since Paul is not on the
telechat, let's put it in AD Followup for him so he can let us know what he
wants to do.

Med: I'd say there are modifications still pending for this one, and the
authors have agreed to make the changes. Just to record that.

 o draft-ietf-lsr-ospf-prefix-extended-flags-06  - IETF stream
   Prefix Flag Extension for OSPFv2 and OSPFv3 (Proposed Standard)
   Token: Gunter Van de Velde

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this document is approved. Okay, not hearing any objections, so this is
approved.

Gunter: AD Followup, please. I want to double check all the comments.

Ketan: I think this is revised I-D needed, the version has not been posted yet.
One of the coauthors is working on the updates.

Gunter: Okay, then revised I-D needed, please.

Mahesh: I have a few comments I want to make sure are addressed as well.

Liz: Great; then this one is Approved, Announcement to be Sent, Revised I-D
Needed.

 o draft-ietf-lamps-automation-keyusages-06  - IETF stream
   X.509 Certificate Extended Key Usage (EKU) for Automation (Proposed
   Standard)
   Token: Deb Cooley

Liz: There are a couple of Discusses here; do we want to discuss these today?

Deb: Authors have reached out to Med, but I don't believe Med has replied.
Paul's comments were new; they also replied to Paul.

Med: I will follow up on the list with the authors. The first reply I received
was not I would say a final one; they said they would be working on it. I
checked the latest version and I'm still puzzled by some of the statements. The
main concern I have is on scoping; whether we are covering something really
generic or focusing on one specific usage. The intent should be really clear.
Some work needs to be done to clarify. I'll follow up with the authors.

Deb: Please do that; there is some urgency here. We've gotten an early
allocation from IANA so I really would like to get this tied up quickly.

Liz: It sounds like this one might need a revised I-D?

Deb: Can you put it in AD Followup, please?

Liz: Sure. So this one is staying in IESG Evaluation::AD Followup, and Deb, you
can take it from there.

 o draft-ietf-ospf-sr-yang-41  - IETF stream
   A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane
   (Proposed Standard)
   Token: Gunter Van de Velde

Liz: We have a Discuss in the tracker; do we want to discuss this now?

Med: The authors are really reactive in handling comments. I will follow up and
read the full revision. Also, we need to tie this one to the next document,
because there are some consistencies to be taken into account. Both documents
should be progressing in parallel. I think we'll wait until we have a new
version for the ISIS part.

Éric V: Since we're doing the two documents together, we should look at this
one "segment routing OVER the…data plane" and the next one "segment routing FOR
the…data plane." We should align those.

Gunter: I agree, that would make sense.

Liz: This one is staying in IESG Evaluation::Revised I-D Needed.

 o draft-ietf-isis-sr-yang-26  - IETF stream
   A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane
   (Proposed Standard)
   Token: Gunter Van de Velde

Liz: We have a Discuss in the tracker; anything more to discuss on this?

Gunter: I think Med already spoke about this one. Unless he wants to add some
additional context,  I think we know what to do with this one. We'll be looking
at the naming of this one as Eric suggests.

Liz: This one is staying in IESG Evaluation::Revised I-D Needed.

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

 o draft-ietf-raw-technologies-16  - IETF stream
   Reliable and Available Wireless (RAW) Technologies (Informational)
   Token: Roman Danyliw

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this one is approved.

Roman: Thank you everyone for your detailed review. I want to do one more final
sweep; can we do AD Followup, please?

Liz: We sure can. This one is Approved, Announcement to be Sent::AD Followup.

 o draft-ietf-teas-5g-ns-ip-mpls-18  - IETF stream
   A Realization of Network Slices for 5G Networks Using Current
   IP/MPLS Technologies (Informational)
   Token: Jim Guichard

Liz: The consensus here was set to unknown, so we'll change that to Yes for
you. There are no Discusses in the tracker, so unless there's an objection now,
this one is approved.

Jim: Thanks everybody, especially Ketan and Med who worked furiously this
morning to sort out the Discuss from Ketan. Roman, to reiterate, I've taken the
action to recharter the TEAS group based on your comments.

Roman: Thank you so much, to you and the chairs.

Jim: This one is ready to go, no substate required.

Liz: Okay, this one is Approved, Announcement to be Sent.

 o draft-ietf-lamps-rfc9579bis-05  - IETF stream
   Use of Password-Based Message Authentication Code 1 (PBMAC1) in
   PKCS #12 Syntax (Informational)
   Token: Deb Cooley

Liz: We do have a Discuss for this document; do we want to discuss this now?

Deb: I don't think so. Can you please put it in Revised I-D Needed?

Éric V: I was really surprised why they'd make a bis for just changing the
format of a string. Rather than an erratum.

Deb: If you make a bis, then it's clear. If you make an erratum, it can be
missed by not pulling the errata.

Éric V: If we make a bis for each and every errata….anyway, I don't have an
objection, I was just wondering if there was something else beyond this fix.

Deb: No.

Ketan: Not related to this document, but I've heard that concern several times
throughout the years, of the default rendering of RFCs not including errata.
I'm not sure if anything can be done about it, but maybe it's a question for
some discussion at some point.

Roman: If you want to pull that thread, we've sometimes revisited that, and
that would be a good retreat topic. We're going to try to start pulling an
agenda together relatively soon.

Liz: Great, so this document is staying in IESG Evaluation::Revised I-D Needed.

3.1.2 Returning items

 o draft-ietf-pim-mofrr-tilfa-12  - IETF stream
   Multicast-only Fast Reroute Based on Topology Independent Loop-free
   Alternate (TI-LFA) Fast Reroute (Informational)
   Token: Gunter Van de Velde

There are no Discusses in the tracker, so unless there's an objection, this one
is approved. I'm not hearing any objections. Gunter, is this ready to go?

Gunter: Please put it in AD Followup. I want to thank everybody for looking at
this a second time. The first time it was approved, just before I was going to
send it to the RFC Editor, an error was found by Toerless, which caused it to
go through the whole cycle again. Thank you for all your patience and my
sympathies for the incoming ADs who also had to read the document now. Thank
you for your efforts.

Liz: Okay, this one will be Approved, Announcement to be Sent, 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

 NONE

3.4.2 Returning items

 o conflict-review-irtf-nmrg-green-ps-02
   IETF conflict review for draft-irtf-nmrg-green-ps
     draft-irtf-nmrg-green-ps-06
     Challenges and Opportunities in Management for Green Networking
   (IRTF: Informational)
   Token: Mahesh Jethanandani

Liz: This document is version -06 and the conflict review is version -02. We
have no blocking comments in the tracker, so are there any final objections to
this no problem message being sent back to the IRTF?

Mahesh: Apologies for forgetting to ballot yes.

Liz: I'm not hearing any objections or comments, so we will go ahead and send
this message back to the IRTF.

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

 o IOT Operations (iotops)

Liz: We do have a blocking comment on this charter; do we want to discuss this
now?

Med: I already replied to Paul to clarify the purpose of the rechartering, I
don't have anything else to add. Let's wait for that discussion with Paul.

Liz: Okay, so we will leave this where it is for now until Paul can resolve his
block. Anything else anyone wants to say about this? Okay, let's move on.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Liz: I don't think the IAB has met since we were all together, but is there any
IAB news?

Deb: It met at IETF. I don't know if there's any other news other than
scheduling stuff. Maybe Matthew has comments.

Matthew: We're just trying to organize our responsibilities a bit more clearly
so there's some scheduling stuff around changing the IAB meetings to be 2
hours. Probably nothing that's significant to the IESG at this stage.

6. Management issues

6.1 [IANA #1414422] Designated experts for RFC 9678 (Forward Secrecy Extension
to the Improved Extensible Authentication Protocol Method for Authentication
and Key Agreement (EAP-AKA' FS)) (IANA)

Liz: This is a brand new action item for Paul, which we reviewed at the top of
the list.

6.2 Replace designated expert for RDAP protocol registries (IANA)

Liz: We'd like to replace Andy Newton with Jasdip Singh <jasdips@arin.net> as
the designated expert for RDAP protocol registries. Any objections to making
that change? Not hearing any objections, so that's approved and we will send an
official note to IANA.

6.3 [IANA #1414925] Designated Expert replacement for Bernard Aboba (Paul
Wouters)

Liz: We need to do another replacement, from Bernard Aboba to Alan DeKok
<aland@deployingradius.com> and Margaret Cullen
<margaret@painless-security.com> as designated experts for RADIUS-related
registries. Any objection to this change? Not hearing any objections, so that's
approved and we will send an official note to IANA.

6.4 [IANA #1414693] renewing early allocation for RFC 8111 (IANA)

Liz: This is one of Jim's groups. Jim, do you want to let us know about this
one?

Jim: I hadn't seen this one, actually. I need to take a look at this. My
initial reaction is that I have no objection, but can we revisit this? I must
have missed it.

Liz: It looks like it expires on the 19th and we do have another telechat
before that on the 17th, so we can put this on the agenda for next time.

Éric V: It looks like this is for an experimental RFC, so this should be
renewed or there would be an RFC without a code point, right?

Roman: I'd like to understand how we're seven years later on early allocation
and we don't have permanent.

Jim: A lot of their documents were experimental which they slowly moved toward
Standards, but yeah, good question.

Roman: Thanks for doing the research for us.

Jim: I'll take a look and let's come back to this on the next telechat.

Liz: Okay, we'll put this back on the next agenda.

6.5 [IANA #1414695] renewing early allocations for draft-ietf-pce-multipath
(IANA)

Liz: We have another early allocation; this one is for one of Ketan's groups.

Ketan: The authors are working to finish this document and there's just one
outstanding issue they promise to work on in an expeditious manner.

Liz: Okay, any objections to renewing this early allocation? Not hearing any,
so that's approved and we'll send the official note to IANA.

6.6 [IANA #1415864] Designated experts for RFC 9725 (WebRTC-HTTP Ingestion
Protocol (WHIP)) (IANA)

Liz: This is just a new action item for Mike.

6.7 [IANA #1357864] Designated expert replacement for Graham Klyne (IANA)

Liz: This is a new item for Orie.

6.9 [IANA #1414246] Designated experts for RFC 9740 (New IPFIX Information
Elements for TCP Options and IPv6 Extension Headers) (Mahesh Jethanandani)

Liz: Mahesh has identified Paul Aitken and Jen Linkova as the designated
experts for RFC 9740. Any objection to approving them? I'm not hearing any
objections, so they are approved and we will send the official note to IANA and
close this action item for Mahesh.

6.6 IESG-focused Datatracker Feature Requests (Roman Danyliw)

Roman: The history here is that on an annual basis, the tools team gets
together for a retreat. One of the things we care about that they do there is
they update and review the roadmap that's the plan for the coming quarters on
what features they're going to work on in the Datatracker. The IESG is an
important customer of the tools team and we have a whole basket of different
requests we've made. They're all piled in to Github. One of the things I do in
preparation for that meeting is extract what we consider the priority requests
that we feel are required for the Datatracker, based on what we ourselves have
asked for or that the community has asked for. This is a practice I started
last year when I started attending the tools team retreat. All I'm really
asking for is a review of what's there; unless someone objects, we'll keep all
the open requests that were made last year and have not been satisfied yet, and
this is a call for additional feature requests to add for prioritization. Any
comments, questions? The way you can help is if you think there's something on
there marked as active that you think shouldn't be, please say so. If you have
other requests in Github already, please move it to the parking lot. If you
aspire for a feature but have not yet filed a request, please file the request
and then add it to the list. We want to have a Github issue for each item. This
has some urgency in the sense that the tools retreat is convening next Thursday
and Friday.

Mahesh: Is there a link to this?

Roman: Yes, it's in Slack. I'll also re-send it now.

Deb: Is there a similar list for mailman3?

Roman: I have not started such a list, but we could absolutely do that. We can
repurpose some of the titling on this and you can add them in the parking lot.
We don't need to necessarily scope this just to the Datatracker.

Deb: Is there a similar github thing for mailman?

Roman: That's a good question. I don't know; does anyone?

[Jean found the link].

Roman: If we could have this buttoned up by next Wednesday, that would be great.

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

Liz: That was our last item before executive session; does anyone else have
anything before we move into exec session?

Roman: Yes. I wanted to quickly explain what I put on the informal agenda next
week. I put 2 review items. One is the IETF LLC board wants to make sure the
IESG has what they need to execute their oversight of the standards process, so
they asked me to ask the IESG what is the additional information or what are
the class of updates the LLC can provide to the IESG? I started a Google
document to capture that and if we need to we can talk about it at the
telechat. The other thing I put on the informal is the last time we updated the
balloting procedures was in 2014, which is a really long time ago; I see a
little daylight between how we do it now and how it's written down, so I took
the liberty of taking that text and bringing it up to date. Please take a look
and see what you think.

Deb: During the meeting week, we had a request to do a short-lived WG to update
some very boring crypto work called HPKE. We're going to charter that into a WG
and keep it very tightly bound. I've put a draft charter up already and as soon
as I get a mailing list I'll put it on the IESG agenda for internal review. The
plan is to get it done and dusted; they want it by Madrid but that's sort of
ambitious. I should think we'd have it done by Montreal, just to do some quick
updates to a protocol that's boring. We've consulted multiple times with the
CFRG chairs and in general I think it's pretty straightforward. It may mean we
consult more regularly with the CFRG chairs, which is a good thing.

Andy: I have something too. DMARC got closed and there was a normative dangling
reference to one of the documents they just put in the RFC Editor queue. I've
offered them a really quick charter to get it done, to reconstitute it with a
very specific charter to get that reference finalized. That's probably going to
show up soon.

8. Executive Session (Roman Danyliw)

A management issue was discussed in an executive session of IESG, IAB Liaison,
and Secretariat.