Narrative Minutes interim-2025-iesg-10: Thu 14:00
narrative-minutes-interim-2025-iesg-10-202505081400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2025-05-08 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Mike Bishop (Akamai) / Web and Internet Transport Area
Matthew Bocci (Nokia) / IAB Liaison
Deb Cooley (DHS CISA) / Security Area
Liz Flynn (AMS) / IETF Secretariat
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Cindy Morgan (AMS) / IETF Secretariat
Andy Newton (ICANN) / Applications and Real-Time Area
Tommy Pauly (Apple) / IAB Chair
Orie Steele (mesur.io) / Applications and Real-Time Area
Ketan Talaulikar (Cisco) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Mohamed Boucadair (Orange) / Operations and Management Area
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Gorry Fairhurst (Univ. of Aberdeen) / Web and Internet Transport Area
Jean Mahoney (AMS) / RFC Editor Liaison

OBSERVERS
---------------------------------
Sandy Ginoza
Bob Hinden
Tommy Jensen
Felix Linker
Francesca Palombini
Eric Rescorla
Stefan Santesson
Ben Schwartz
Greg Wood

1.2 Bash the agenda

Liz: Does anyone have anything new to add to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Liz: We have four sets of minutes to approve today. Does anyone have an
objection to the minutes of the April 17, 2025 Teleconference being approved?
I'm hearing no objection, so those are approved.

Liz: Does anyone have an objection to the narrative minutes of the April 17,
2025 Teleconference being approved? I'm hearing no objection, so those are
approved.

Liz: Does anyone have an objection to the minutes of the April 24, 2025
Teleconference being approved? I'm hearing no objection, so those are approved.

Liz: Does anyone have an objection to the narrative minutes of the April 24,
2025 Teleconference being approved? I'm hearing no objection, so those are
approved. We'll post all of those in the Datatracker.

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].

Erik K: In progress.

      o Mike Bishop to find designated experts for RFC 9725 (WebRTC-HTTP
         Ingestion Protocol (WHIP)) [IANA #1415864].

Mike: We have one person who's agreed and a potential second, so I expect to
have this done at the next telechat.

      o Jim Guichard to find designated experts for RFC 9692 (Routing in
         Fat Trees (RIFT) registries) [IANA #1416539].

Liz: We have an item on today's agenda to approve a couple of names for this,
so we'll mark this as provisionally done.

      o Mahesh Jethanandani and Paul Wouters to find designated experts
         for RFC 9761 (Manufacturer Usage Description (MUD) for TLS and
         DTLS Profiles for Internet of Things (IoT) Devices) [IANA #1417446].

Mahesh: I have one person, still trying to work on a second.

Paul: I was not aware my name was added there, so I guess I'll talk to Mahesh.

Liz: Mahesh asked us to add you; between the two of you we just need a couple
of names.

Liz: The next three are all brand new action items to find designated experts;
two for Deb and one for Orie, to make sure you have those on your to-do-lists.

      o Deb Cooley for find designated experts for RFC 9728 (OAuth 2.0
         Protected Resource Metadata) [IANA #1417718].
      o Orie Steele to find designated experts for RFC 5774 (PIDF-LO
         Civic Address Considerations Registry) [IANA #1418282].
      o Deb Cooley to find designated experts for RFC 9711 (The Entity
         Attestation Token (EAT)) [IANA #1418116].

    * OPEN ACTION ITEMS

      o Roman Danyliw to take a look at Datatracker documentation of
        document states and update as needed.

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

      o Cindy Morgan, Andy Newton, Ketan Talaulikar, and Paul Wouters
        to work on a proposal for submitting appeals via the Datatracker.

Cindy: This is in progress; nothing is written down but I'm going to send Andy,
Ketan, and Paul an email last week. I also chatted about it with Robert so he's
aware it's coming.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

  o draft-ietf-stir-servprovider-oob-07  - IETF stream
    Out-of-Band STIR for Service Providers (Proposed Standard)
    Token: Orie Steele

Liz: There are no Discusses in the Datatracker, so unless there's an objection
now, this document is approved. [pause] Then we'll call this approved.

Orie: Thank you for all the comments. There's probably one more pass of
editorial cleanup, so Revised I-D Needed.

Liz: We also have a downref for this draft, so we will need to know soon if you
want to add 8816 to the downref registry.

Orie: Thank you; I'll take a look at that and confirm shortly.

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

  o draft-ietf-stir-rfc4916-update-06  - IETF stream
    Connected Identity for STIR (Proposed Standard)
    Token: Orie Steele

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

Orie: Unless other folks want to. I've seen some back and forth already about
the top part, regarding the shepherd writeup, but I haven't seen anything on
the bottom part of the Discuss yet so I'll wait for them to reply.

Ketan: Just one thing about this; it's just a comment, about the clarification
of whether this should or should not update 4196. Med has that in his Discuss
comments; I missed if there was something on that.

Orie: I'll have to take a look. Can I interpret your comment as supporting a
part of his Discuss?

Ketan: That's correct.

Orie: Thank you.

Liz: This one is staying in IESG Evaluation; do you want Revised I-D Needed or
AD Followup?

Orie: Let's go with Revised I-D Needed.

Liz: This document also has a downref, so we'll be asking you if you want to
add 3375 to the downref registry.

  o draft-ietf-tls-esni-24  - IETF stream
    TLS Encrypted Client Hello (Proposed Standard)
    Token: Paul Wouters

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

Paul: We would, but Med isn't here. So there isn't much we can discuss. Some of
the Discuss items are a bit lightweight and might be more like comments; I see
that EKR is here. EKR, did you want to add something? I think you already
answered most of his things and will do minor changes.

EKR: I responded to his message in detail. There are some minor changes
indicated for some of his comments but not his Discuss comments. I believe the
Discuss comments are incorrect.

Paul: I think you're right but unfortunately we can't discuss it right now
because he's not here. I will ping him to see if he can clear his Discuss in a
reasonably fast manner. Let's put it in Revised I-D Needed because you will end
up putting out a revised I-D with some changes.

EKR: That's correct.

Paul: Okay. I'll hunt down Med and get this resolved.

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

  o draft-ietf-tls-svcb-ech-07  - IETF stream
    Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
    (Proposed Standard)
    Token: Paul Wouters

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

Paul: Same situation here, where a number of comments don't seem to reach the
level of Discuss. Again, I'll take this up with Med in the next couple of days.
EKR or Mike, anything to add on this document?

Mike: As you said, I probably don't have changes for most of these, but we'll
talk about it.

EKR: Ben Schwartz sent detailed comments, so I believe Med has what he needs to
come to a conclusion.

Mahesh: I have a question. I'm not a DNS expert. [audio cutting out]

Paul: It's hard to understand you, but when you pick up the ECH from DNS, and
it's the wrong one or you're missing it, there's a correction mechanism where
the server you're connecting to will give you an updated ECH if you've got the
wrong key. I think that mostly mitigates the concerns you have about deployment.

Mike: That also addresses on the previous draft the difference between SHOULD
make sure all the servers have the right keys, MUST make sure they either have
the right keys  or are authoritative for the name, because if they're
authoritative for the name they can give you new keys.

Mahesh: Okay. So there is a chance you will not have the right set of keys, in
which case would you need to log or [audio cutting out]

Paul: How or when you should log is mostly out of scope. People are very
sensitive about logging TLS details, so this has mostly happened in another
discussion about another draft that will come to the IESG soon. They're trying
to make sure logging is only enabled when needed for debugging reasons, and
also make sure you're not logging any long term things for pervasive monitoring
purposes.

Mahesh: [audio cutting out]

Paul: Can we put this in AD Followup? I'm not sure yet if we will need a
revised I-D.

Liz: We sure can; this will stay in IESG Evaluation::AD Followup and you can
let us know when it's ready.

  o draft-ietf-dhc-rfc8415bis-10  - IETF stream
    Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Internet
    Standard)
    Token: Eric Vyncke

Liz: We have a Discuss here from Med; do we want to discuss this now or wait
for Med?

Eric V: I'd like to wait for Med. I want to thank all the people who have
reviewed this draft. Some comments of Med's have been addressed as far as I
know. Ketan, you had a couple of comments about whether we still need to keep
this document from the previous RFC. I agree it should be removed, so I'm
talking with the authors about that.

Ketan: Thanks for that; I have no Discusses but that was a point I wanted to
discuss here. It would really help from my point of view for someone new
looking at it afresh, since it's going to be an Internet Standard. They'll get
a nice clean self sufficient document.

Eric V: I said to the authors and WG whether they want to remove it or move it
into a non-normative part of the appendix.

Ketan: there are cases where the authors want to reference a particular section
in 8415; they could do the same. There are also a few places where some of
those obsoleted RFCs are still used as normative references. This was okay for
8415 because it was just obsoleting that, but now we are two degrees apart and
I've given some suggestions where they could point to places in this document
itself to reference. I'm happy to keep talking with the authors.

Eric V: When you want to move a PS to IS, you need to do minimum changes;
that's mine and the authors' understanding.

Ketan: My reading was the same but I interpreted it as not doing any technical
changes. All of these are non-technical.

Eric V: So we'll need a Revised I-D.

Liz: This one is staying in IESG Evaluation::Revised I-D Needed. And I'll just
note for the record that we were all a little confused about the downrefs this
morning, so Eric and I chatted about it. Since this document is an Internet
Standard, it popped out five downrefs to Proposed Standard and Draft Standards
which are all technically downrefs, but we're not going to add any of them to
the downref registry because they are Standards Track.

  o draft-ietf-jose-fully-specified-algorithms-12  - IETF stream
    Fully-Specified Algorithms for JOSE and COSE (Proposed Standard)
    Token: Deb Cooley

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

Deb: Not really.

Paul: I talked to Mike Jones about it. He'll do an update.

Deb: So Revised I-D Needed, then. I wanted to say that both Mike Jones and Orie
are super responsive to comments, so it's been fun to watch.

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

  o draft-ietf-cose-tsa-tst-header-parameter-05  - IETF stream
    COSE Header parameter for RFC 3161 Time-Stamp Tokens (Proposed
    Standard)
    Token: Paul Wouters

Liz: We have a couple of Discusses in the Datatracker; do we want to discuss
this today?

Paul: We should briefly talk about the charter one, because that's the big one.
I tried to find some email and I think I had a warning that this might be out
of charter, but I'm not sure if it was this one or another one. We need to fix
this. I might have to take this document back until the charter has been
updated. That's the main one. I guess we have time for the other ones to get
resolved because of that.

Deb: And just to say, while Stefan's on the call anyway, the authors have
already reached out to me and I've promised to go back and re-review Stefan's
SECDIR review more carefully. Stefan, if you want to send me more details about
why you think this is important, happy to take those or loop you into the
conversation. I think the authors are a little confused about why you were
concerned. We have time to straighten that out because of the charter thing. Is
that okay?

Stefan: That's absolutely okay. I'll drop you an email and you can take it from
there.

Deb: Perfect, thank you very much.

Paul: I'm not sure if this should stay in IESG Evaluation since it has to be
rechartered.

Eric V: It sounds logical.

Paul: Okay, so I'll pull it back to the WG. Or the Secretariat can do it?

Cindy: We can send it back to the WG; this has changed recently so it might
take me a minute to remember how to do it, but yes we can.

Liz: Okay, then this document is going back to the WG and we'll figure out
which buttons to push.

  o draft-ietf-calext-ical-tasks-13  - IETF stream
    Task Extensions to iCalendar (Proposed Standard)
    Token: Orie Steele

Liz: We have a few Discusses in the Datatracker; do we want to discuss this
today?

Orie: I'd like to talk briefly about it. Ketan, thank you for pointing out the
issue with the IANA considerations; I should have caught that. I've had some
back and forth with the authors and I'm waiting for a reply from them. I think
this is definitely going to need a Revised I-D. And for everyone, the original
guidance they provided in the IANA considerations for these registries predates
8126, so it's just a little bit confusing how to integrate that old registry
guidance with our new registry policies. I'm hoping we can improve the clarity
around that.

Ketan: Amanda and Sabrina, please do help us out here.

Sabrina: I think Amanda has responded; I'm not sure if we're understanding this
correctly, but I think section 8.5 is just creating an expert review registry
rather than adding registrations to an expert review registry that's being
created by another document. If it is just creating an expert review registry
we have no issue with that. If it's adding a registration to one being created
by another I-D, that would be a little messy.

Orie: I have issues with it because they're citing 5545 as the guidance for
this group, and that has other challenges that interact unpleasantly with 8126.

Ketan: I provided more detailed comments; on that specific one, there are a
couple of ways we could go about it. I've shared one example with Amanda about
how it was done for a routing draft. We can continue the discussion and try to
provide help to the authors. The main thing is what Orie said, the authors have
just picked up from 5545 and probably need to start doing things based on 8126.

Sabrina: Sounds good. We can continue that discussion.

Orie: Thank you.

Liz: So this document is staying in IESG Evaluation::Revised I-D Needed.

  o draft-ietf-regext-epp-eai-24  - IETF stream
    Additional Email Address Extension for the Extensible Provisioning
    Protocol (EPP) (Proposed Standard)
    Token: Orie Steele

Liz: We have a Discuss in the Datatracker from Roman, who's not here today; do
we want to discuss this now?

Orie: No, I don't think so. It's pretty straightforward. I thought I saw Scott
had replied to Roman already, so we're just waiting for all the comments to
come in before hopefully seeing a revision.

Liz: So this document is staying in IESG Evaluation::Revised I-D Needed.

  o draft-ietf-lamps-rfc7030-csrattrs-21  - IETF stream
    Clarification and enhancement of RFC7030 CSR Attributes definition
    (Proposed Standard)
    Token: Deb Cooley

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

Deb: I don't think we want to talk about this now.

Liz: So this one will stay in IESG Evaluation; do you want Revised I-D Needed
or AD Followup?

Deb: Revised I-D Needed, please.

  o draft-ietf-bess-bgp-srv6-args-09  - IETF stream
    Segment Routing over IPv6 Argument Signaling for BGP Services
    (Proposed Standard)
    Token: Gunter Van de Velde

Liz: There are no Discusses in the Datatracker, so unless there's an objection
now, this document is approved. Okay, this is approved; Gunter, is it ready to
be announced?

Gunter: It may be ready to go. There's one open item which Eric is discussing
with Ketan. I think he's okay for the document to move onwards but we may want
to do a few small edits to make it clearer?

Eric V: We're talking with Ketan; whatever I have is just for improving the
document, not for fixing bugs. The first sentence in the abstract I think is
kind of useless. But honestly I'll leave it to you and the authors.

Ketan: We're having that discussion; let's continue that. I'm happy to discuss
and we'll see how it goes.

Gunter: Okay, so let's have another revision.

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

  o draft-ietf-httpbis-cache-groups-05  - IETF stream
    HTTP Cache Groups (Proposed Standard)
    Token: Mike Bishop

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

Mike: I believe some of the Discusses were cleared based on a promise to update
the document, but I don't think I've actually seen that version yet, so let's
make it Revised I-D Needed.

Liz: Okay great, so this is Approved, Announcement to be Sent::Revised I-D
Needed and you can let us know when it's ready to go.

  o draft-ietf-core-cf-reg-update-08  - IETF stream
    Update to the IANA CoAP Content-Formats Registration Procedures
    (Proposed Standard)
    Token: Mike Bishop

Liz: We have a couple of Discusses in the Datatracker; do we want to discuss
this today?

Mike: I think the shepherd writeup attempts to address the structure of the
document question, which seems to be central to Discusses. I think I saw Eric
noted that in his review. I think the question is if we want to hash that out
now or …

Paul: I already saw the proposal where they changed it, and they updated it so
it is mostly within the IANA considerations section. With that, my issue is
resolved.

Ketan: Same for me. I saw the PR and it looks all good; as soon as that version
is posted I think my Discuss clears as well.

Mike: Okay, so let's set that to Revised I-D Needed and we can approve it at
the next telechat? Do we need to bring it back to actually approve it?

Liz: No, it only needs to be discussed on one telechat, so if you don't need
any more input from the IESG you can just let us know when it's ready to go and
all the Discusses have been cleared.

Ketan: Thomas has been very good and very prompt, so I don't think we'll need
another one.

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

  o draft-ietf-sipcore-siprec-fix-mediatype-06  - IETF stream
    Updates to SIPREC correcting Metadata Media Type (Proposed Standard)
    Token: Andy Newton

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

Andy: Can we put this in Revised I-D Needed?

Liz: We sure can; so this one is Approved, Announcement to be Sent::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

  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

  o Domain-based Message Authentication, Reporting & Conformance (dmarc)

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

Andy: I think I understand Eric's comments, he wants the references, and I saw
the response on the mailing list. I need to revise this charter and address
some of the other comments. I think we're good, unless there's something else
I'm missing?

Eric V: No, you're perfectly correct. I was hoping to get a message fixing the
charter before the call; but as soon as there is an update I'll clear my block.

Andy: All right. Thank you.

Liz: So this will stay where it is for now, and Andy, you can let us know when
it's ready to move on.

  o Digital Emblems (diem)

Liz: There are no blocking comments in the tracker; is this charter ready for
external review? [pause] I'm not hearing any objections, so it looks like this
is ready to go. We'll send out that announcement today and place it back on the
next telechat.

Eric V: Thank you very much Orie, for clearing all this.

Orie: Thanks for all the comments on it. I think Roman was holding a Discuss on
the previous version, and I see some back and forth about clarification on
certain points. I just wanted to confirm if we make those kinds of changes
during the external review period, is there anything I should be aware of? Or
should I wait until the end of the external review period before I apply any of
those changes? In Roman's comment he said he'd like to see them during the
external review period, which is why I ask.

Eric V: As long as you make the change on the charter or in a PR and you keep
the list aware, I think we are all set.

Orie. Okay. Just to be extra clear, should the Datatracker version of the
charter stay unchanged during the review period, or is it okay to push an -05
addressing some of the comments?

Deb: I think you want to push the changes. When it comes back to us after
external review, it's approved and the charter is done.

Jim: I've done two or three of these now and I've updated them as comments are
addressed.

Orie: I'll push it through to the Datatracker as we refine the clarifying text.
Thanks.

Liz: Orie, do you want us to delay the external review announcement until you
make some of those changes, or do you want us to go ahead and send it now?

Orie: I think you can send the announcement now. They're mostly minor text
changes. I'll treat the lack of a block as truly not a block.

Liz: All right, so we will send those external review announcements today.

4.1.2 Proposed for approval

  o HPKE Publication, Kept Efficient (hpke)

Liz: There are no blocking comments in the Datatracker; are there any final
objections to the creation of this WG? Okay, this WG is approved. We can go
ahead and send the WG action announcement today, unless there are any final
tweaks you want to make?

Deb: I do not. Send it.

Liz: Great, then we'll send those approval announcements today.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

  NONE

4.2.2 Proposed for approval

  o Global Routing Operations (grow)

Liz: There are no blocking comments in the Datatracker, so it looks like this
one is ready to go. However, since Med isn't on the call, we will check with
him first before sending the announcement just in case he wants to change
anything.

Ketan: There's at least one thing that I know is pending, to put some context
related to BGP.

Deb: He did push a new version that does mention BGP. He has a version 06.

Ketan: Okay. So Deb, are you good with this?

Deb: I am. I think there were some other comments too, right?

Ketan: Yes, I think there are two more.

Mahesh: I have just one comment. You and Med are clear on what Yang models are
being developed in GROW vs the routing area?

Ketan: These are more operational. The current proposal is mostly related to
BMP, which is entirely in GROW, so we don't have any conflict. Most of them are
operational so I think we are okay. Should something come up, we'll collaborate
with GROW and IDR.

Mahesh: Okay, I just wanted to be sure.

Liz: Unless there's a reason this needs to be rushed out today, we'll double
check with Med first that it's ready before we send out any announcements.

  o Operations and Management Area Working Group (opsawg)

Liz: There are no blocking comments in the Datatracker; are there any final
objections to the rechartering of this WG?

Mahesh: I think this should be ready to go.

Liz: Great, then this one is approved and we'll send those recharter
announcements today.

  o Update to IANA Considerations (ianabis)

Liz: There are no blocking comments in the Datatracker, so it looks like this
one can be approved, but we'll check with Roman before sending out any
announcements. Is there anything anyone wants to say on this one? [pause] Okay,
then this one is approved pending a check with Roman.

5. IAB news we can use

Deb: I did attend a liaison managers meeting where they get all the liaison
managers together fairly infrequently to talk about various issues. One thing
they talked about is the IAB is updating both 4052 and 4053; if you want to
take a look at those and comment, I'm sure they'd be happy to do that. They
also talked about who was responsible for recording incoming liaison statements
and who's responsible for replying to them. Replies can be done by ADs, liaison
managers, and WG chairs. It was a pretty interesting meeting and I hadn't met
most of those liaison managers. They also had a meeting yesterday which I did
not attend on EDM so I don't have any readout on that.

Tommy: EDM is one of our programs and we're going to be kicking off some
discussions about deployability and incentives, what makes people actually
deploy protocols and how are we taking that into consideration when designing
things. There may be some asks we'll come to the IESG about there.

Deb: That's it.

6. Management issues

6.1 [IANA #1416539] Designated experts for RFC 9692 (RIFT: Routing in Fat
Trees) (Jim Guichard)

Liz: Jim has identified Pascal Thubert <pascal.thubert@gmail.com> and Tony
Przygienda <tonysietf@gmail.com> as the designated experts for this registry.
Any objections to approving these two?

Liz: I'm not hearing any objections, so Pascal and Tony are approved and we
will send that official note to IANA.

6.2 [IANA #1417718] Designated Experts for RFC 9728 (OAuth 2.0 Protected
Resource Metadata) (IANA)

Liz: This is just to officially assign that new action item to Deb.

6.3 Additional Designated Expert for SCIM Registries (Deb Cooley)

Liz: Deb would like to add Paulo Jorge N. Correia to the SCIM registries. Any
objections to adding Paulo?

Liz: I'm not hearing any objections, so Paulo is approved as an additional DE
and we will send that official note to IANA.

6.4 Request for Prioritization of C482 in the RFC Editor Queue (Andy Newton)

Andy: It's actually 2 documents; one from STIR and one from SIPCORE. The
sipcore one we recently approved. ATIS has approved a publication and they're
holding on publishing it so they can get RFC numbers. The process as I
understand it is that the RFC Editor won't assign RFC numbers until these
documents get into AUTH48, but we can request that they be expedited so they
get there faster. That's what we're asking here for the IESG to approve that
and the RFC Editor to expedite them.

Sandy: Are you saying they're holding publication, so the goal is to get these
out ASAP; not a particular goal date?

Andy: That's correct. tHey didn't give me a date, they said they've already
approved their documents but have held publication because right now they're
using placeholders. They'd like to reference RFC numbers.

Mike: Do they just need the numbers allocated?

Andy: I believe so.

Mike: Is it possible to do that first even though it's not the normal process?

Sandy: Part of the reason we don't do that is because there's old history where
we'd hold a number and then there were issues with that document that it never
got published, so there are gaps in the series. In this case, I expect it
should be fine. The only thing is, you don't want just the number out there
because if people are looking for the reference they won't find it.

Mike: So they might still want to hold publication until there's something at
that RFC number?

Sandy: I would imagine that's the case. That would be ideal in my opinion.

Andy: I'm supportive of this process of just asking to prioritize and waiting
for them to get into AUTH48. I don't think there's much to do on these
documents, but it incentivizes the authors to get their side of it done. The
sooner the authors reply to the RFC Editor, the sooner they get their numbers,
and I think that's the right incentive.

Mahesh: Sandy, does that mean when they do get into AUTH48, there is a publicly
accessible reference to the document?

Sandy: The RFC number will be assigned and the RFCs are available temporarily
in the authors' repository. It is publicly accessible, but it's not in its
permanent spot until it officially gets announced.

Liz: Are there any objections to asking for this expedited processing? Not
hearing any, so this is approved and we will send an official note to the RFC
Editor requesting this prioritization.

6.5 [IANA #1418282] Designated experts for PIDF-LO Civic Address Considerations
Registry (IANA)

Liz: This is just to officially assign that new action item to Orie.

Andy: I know this has Orie's name on it, but I'm looking into it; can we put my
name on it?

Orie: You're welcome to have it.

Liz: No problem, we'll change this name from Orie to Andy on the action item.

6.6 [IANA #1418116] Designated experts for RFC 9711 (The Entity Attestation
Token (EAT)) (IANA)

Liz: This is to officially assign that other new action item to Deb.

6.7 RSWG Chair Appointment (Secretariat)

Liz: This is here to officially minute the decision made at last week's
informal telechat to reappoint Russ Housley to the RSWG. An official
announcement will follow today.

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

Paul: I'd like to go into a quick executive session.

[Executive session topic discussed with Secretariat, IAB liaisons, RFC Ed and
IANA liaisons.]