Narrative Minutes interim-2024-iesg-12: Thu 14:00
narrative-minutes-interim-2024-iesg-12-202405301400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-05-30 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
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
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
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Tommy Pauly (Apple) / IAB Chair
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
David Schinazi (Google) / IAB Liaison
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Applications and Real-Time Area
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Sabrina Tanamal (ICANN) / IANA Liaison

OBSERVERS
---------------------------------
Adrian Farrel
Bob Hinden
Justin Iurman
David Lawrence
Janfred Rieckers

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes from the May 16
teleconference being approved? I'm hearing no objection, so those are approved
and we'll get those posted.

Does anyone have an objection to the narrative  minutes from the May 16
teleconference being approved? I'm hearing no objection, so those are also
approved and we'll get those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Orie Steele to find designated experts for RFC 9553 (JSContact
       registries)[IANA #1364749]

Liz: Orie, this is a new one for you.

   * OPEN ACTION ITEMS

     o Roman Danyliw 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.

Roman: Warren, we're going to have to revisit this. I think this came out of
the last retreat and we're about to start the next retreat.

Warren: Maybe at the retreat we can sit down in a corner for 20 minutes and
bang it out.

Roman: Yeah. In progress, then.

     o Paul Wouters to open up an issue with the Tools Team asking for
       IANA to be notified about document state changes.

Paul: In progress.

     o Paul Wouters to write a proposal for handling IANA review
       mailing lists.

Paul: In progress.

     o All IESG to review Non-WG List Review spreadsheet and note
       which lists may be ready for closure and any needed AD Actions.

Liz: Are folks still working on this?

Éric V: I marked some lists assigned to me as closed; I sent a message and got
no reply, so they can be closed. Who is actually closing them; do I need to
open a support ticket for them?

Cindy: Yes; please send email to support@ietf.org with the lists you have that
are ready to close.

Éric V: And I will be sending a tombstone myself before?

Roman: I think I'm going to finesse that. The way we did it with the
spreadsheet is that we can probably do batch closures when ADs mark a list to
be closed on the spreadsheet.

Francesca: But that implies the Secretariat will have to keep track of that in
the sheet. I understood that we send a support ticket for what we want to close
and then the Secretariat takes care of closing it and updating the spreadsheet.
I had the same question last time.

Roman: Is that what we agreed to? I couldn't remember.

Cindy: My concern is that different ADs might be using those fields
differently. I'd like confirmation that the ones marked closed are actually in
a state to be closed, and not 'will be ready to close after I do x, y, z.'

Francesca: So we keep the spreadsheet for who has the action. For example, I
have a bunch that I've sent email to saying this will be closed in 4 weeks
unless I hear otherwise. Once the four weeks have passed, I don't go in and
change the state myself, I send a support ticket and ask them to close the
lists. The Secretariat will then close the list and go to the spreadsheet and
mark it closed. So if you just go to the spreadsheet and mark it closed,
nothing will happen.

Liz: Thanks, everyone.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-mpls-ri-rsvp-frr-18  - IETF stream
   Refresh-interval Independent FRR Facility Protection (Proposed
   Standard)
   Token: Jim Guichard

Liz: We have a couple of Discusses here; do we want to discuss these now?

Jim: I don't; I'm just waiting on the authors to give responses.

Liz: Great, so this one will be staying in IESG Evaluation, with a substate of
Revised I-D Needed.

 o draft-ietf-emu-rfc7170bis-17  - IETF stream
   Tunnel Extensible Authentication Protocol (TEAP) Version 1
   (Proposed Standard)
   Token: Paul Wouters

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

Paul: I don't think so.

Roman: Alan has already said he's going to merge the text change, so I think
we're good here.

Paul: Just put it in Revised I-D Needed.

Liz: So this one will stay in IESG Evaluation :: Revised I-D Needed.

 o draft-ietf-jmap-contacts-09  - IETF stream
   JMAP for Contacts (Proposed Standard)
   Token: Murray Kucherawy

Liz: We have a couple of Discusses here; do we want to discuss these now?

Murray: Not necessary unless Orie or Mahesh want to talk about something. I've
got no questions; I think the authors need to answer you.

Orie: Okay. Nothing from me, then.

Murray: Let's put this in AD Followup.

Liz: This one will stay in IESG Evaluation :: AD Followup.

 o draft-ietf-lamps-cert-binding-for-multi-auth-05  - IETF stream
   Related Certificates for Use in Multiple Authentications within a
   Protocol (Proposed Standard)
   Token: Roman Danyliw

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

Roman: I appreciate everyone's review. I don't need to discuss it.

Paul: I'm fine. I'm not sure if they responded to me, but they will.

Roman: Can we put this in Revised I-D Needed, please?

Liz: This one will stay in IESG Evaluation :: Revised I-D Needed.

 o draft-ietf-6man-hbh-processing-18  - IETF stream
   IPv6 Hop-by-Hop Options Processing Procedures (Proposed Standard)
   Token: Erik Kline

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

Erik K: I haven't caught up with everything that might have transpired
overnight, but I think Bob has been pretty responsive to everything coming in
so far. If you'd like to have a discussion we can, otherwise I see activity on
email. Bob is also here if you want to ask questions directly.

Warren: Not really questions, just noting that I've seen the response to my
Discuss and I think we can work through this.

Éric V: the same for me; Bob replied quickly to my previous Discuss.

WArren: And apologies for how late mine came in.

Erik K: Thanks for all of the reviews. I think we can probably put this in
Revised I-D Needed and move on.

Liz: This one will stay in IESG Evaluation :: Revised I-D Needed.

 o draft-ietf-mpls-egress-tlv-for-nil-fec-13  - IETF stream
   Egress Validation in Label Switched Path Ping and Traceroute
   Mechanisms (Proposed Standard)
   Token: Jim Guichard

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

Jim: Again, it's waiting on authors. Revised I-D needed on this one too, I
think.

Liz: This one will stay in IESG Evaluation :: Revised I-D Needed.

 o draft-ietf-mboned-multicast-telemetry-09  - IETF stream
   Multicast On-path Telemetry using IOAM (Proposed Standard)
   Token: Warren Kumari

Liz: We have a couple of Discusses here; do we want to discuss these now?

Warren: I don't know if we need to discuss them much, other than I believe the
authors have been responding to the Discusses and they're generally agreed on a
way forward, they just need to post a new version.

Éric V: At least the [crosstalk] bit will be fixed, but it's really unclear
about the v6 situation. They're still hand waving the reply. So I will wait
until the revised I-D before deciding.

Gunter: I'm in the same position.

Zahed: I didn't put in a Discuss but there was a TSV-ART review that was not
reflected on this one yet, so I'm relying on you to check that.

Warren: Okay. Once they publish a new version I'll ask you to check that that
concern was addressed.

Liz: Sounds like 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

 o status-change-mpls-rfc7506-to-historic-01  - IETF stream
   Move RFC 7506 to Historic (None)
   Token: Jim Guichard

Liz: The consensus here is set to Unknown, so we'll change that to Yes for you.
We broke the streak and there are no Discusses for this, so unless there's an
objection now, this status change is approved. Jim, is this ready to go as-is
or do you want to give it a final look?

Jim: It's ready, I already gave it a look.

Liz: So this one is Approved, Announcement to be Sent, and we'll get that
announcement sent.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-teas-pcecc-use-cases-16  - IETF stream
   Use Cases for a PCE as a Central Controller (PCECC) (Informational)
   Token: Jim Guichard

Liz: This one also has a Consensus Unknown, so we'll change that to Yes. We
also don't have any Discusses here; unless there's an objection now, this one
is approved.

Jim: Revised I-D needed, though. There are some comments and I didn't see any
responses so I just want to make sure those are addressed.

Liz: Sure, this will be Approved :: Revised I-D Needed and you can let us know
when that's ready.

 o draft-ietf-mops-ar-use-case-17  - IETF stream
   Media Operations Use Case for an Extended Reality Application on
   Edge Computing Infrastructure (Informational)
   Token: Éric Vyncke

Liz: We don't have any Discusses here; unless there's an objection now, this
one is approved.

Éric V: It's approved and thank you for the reviews, but there were some
comments. Put it in AD Followup so I can check if the comments are implemented.

Liz: Okay, this one is Approved :: AD Followup and you can let us know when
that's ready to go.

 o draft-ietf-bmwg-benchmarking-stateful-07  - IETF stream
   Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814
   Pseudorandom Port Numbers (Informational)
   Token: Warren Kumari

Liz: We have a couple of Discusses; do we want to discuss these now?

Murray: I feel like I might want to start up a more general thread on the use
of BCP 14 in documents like this, but I don't know if we need to talk about
this document.

Éric V: This was part of my comment as well.

Warren: I guess I'll need to re-read your comments.

Murray: I don't want to start the whole thing here, but to prime the seed in
your mind. What does it mean to say you SHOULD do something in a benchmark?

Warren: When you're running the benchmark, in order to be able to validly
report those results, this is the expectation.

Éric V: Yes, but it's informational.

Murray: I get what you're saying, Warren. I just …

Warren: I will point out that these benchmarking results often get put in four
color glossies for vendors. If you decide to run a benchmark and you don't
follow how it's outlined, you could just make up whatever numbers. There's no
actual way to enforce this, but if it says you MUST make sure you're using 64
byte packets, and you instead use 1500 byte packets, there's no protocol police
but it's fairly clear you're trying to fudge the numbers. If you just have
lowercase you might want to use small packets, that doesn't carry the same
level of weight.

Murray: I think maybe it's a purism thing on my part I just need to get over.
The whole thing about BCP 14 is interoperability. What are the two things that
are attempting to interoperate when you're describing a benchmark?  Is it the
person running the benchmark and the human that will consume it? That seems
like a stretch for how it was intended to be used. We've also stretched it into
saying you SHOULD log this when it happens, and we've accepted that as
operational advice. I get those, I guess I'm wondering if this is another weird
case we have to accept as another way BCP 14 gets used. Everything you said
could also be done by avoiding the use of BCP 14.

Warren: You could, but I think this is a purism thing on BCP 14. I guess I'll
call it 2119. People largely use uppercase words as when I'm scanning through
the document to make sure i'm doing everything right, let me look for the
important bits. These are the bits required for interoperability doesn't really
reflect how our documents are used in the real world. But that's a
philosophical thing and let's have a chat about it later.

Murray: Let me stop here before we go on. I'll take it to email.

Liz: So on this document, it's staying in IESG Evaluation; are we thinking
Revised I-D Needed or AD Followup?

Warren: It's going to need a revised I-D.

Liz: Okay, this one is staying in IESG Evaluation :: Revised I-D Needed.

 o draft-ietf-6man-comp-rtg-hdr-09  - IETF stream
   The IPv6 Compact Routing Header (CRH) (Experimental)
   Token: Erik Kline

Liz: We have a couple of Discusses; do we want to discuss these now?

Erik K: We can if people want to. Ron has been pretty good about responding to
people's comments on the mail list. Nothing looks particularly insurmountable
to me so I'm not terribly worried. Thank you for all the reviews.

John: One comment; I've been trying to track the mail on that. Am I right that
Eric had a Discuss that was like please don't talk about ICMPv6, it's out of
scope, and then Zahed had a Discuss that said please tell us how you're going
to rate limit ICMPv6? They sort of seem conflicting. You can take it offline
and discuss it with Ron but I just wanted to understand if I got that right or
if I'm confused about that detail.

Éric V: I need to reread Zahed's comment but basically my point was that
something in the document said do this and this, but RFC 4443 says exactly the
same thing. I don't like repeating the text. Ron removed it and put pointers.

Zahed: I think mine was a little different. My question was basically, there
was a discussion about whether to do rate limiting and I don't know if there's
a rate limit imposed by any ICMPv6 protocol.

Éric V: Yes, 4443 says this.

Zahed: So the question is, if it just says this is rate limited that's fine. I
just didn't want TSV-ART to think it was discarded for some other comments. It
doesn't take away the focus from the point that was made. If it's automatically
rate limited by ICMPv6 it should say so.

Eric K: I think it did at one point; that was a comment I asked for in my AD
eval. It's a standard bit of text for people who try to rely on ICMPv6
messages. 4443 is weirdly of multiple minds on this point. One paragraph says
rate limiting in forwarded ICMP messages is out of scope of this specification
and the next paragraph is literally that a recommended method for implementing
rate limiting function is the token bucket.

Zahed: So I could not make the point to convince me that this was all well
thought out, that's why I put Discuss. I think there's a valid point in the
TSV-ART review and there was a concern.

Erik K: Okay. It's a standard thing to protect the control plane CPU.
[crosstalk] Let's give Ron some time to catch up.

Éric V: Erik, if you can ask Ron to apply my comment about using dotted
decimals about a v6 thing, this is hurting my heart. In section 9, how to
express a compressed SID using an IPv4 notation. Which is okay, because router
IDs are dotted decimals, but you know, it hurts my heart. I don't have to look
at this every day.

Erik K: I'll see what he wants to do. Thank you.

Liz: Okay, so it sounds like this one is going to require a Revised I-D?

Erik K: Please.

Liz: This will stay in IESG Evaluation :: Revised I-D Needed.

 o draft-ietf-mpls-mna-requirements-15  - IETF stream
   Requirements for Solutions that Support MPLS Network Actions (MNA)
   (Informational)
   Token: Jim Guichard

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

Jim: Can you put this in AD Followup please? There are some comments I want to
make sure are addressed.

Liz: No problem. This one will go to Approved :: AD Followup, and you can let
us know when it's ready.

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 DNS Delegation (deleg)

Liz: This one is in the INT area with Warren as the AD, and we do have a couple
of blocking comments. Do we want to discuss these now?

Warren: Yes, that would be great. I believe there's been some ongoing
discussion with Roman and I don't remember if Murray's Discuss also had
discussion. For the possible bit, we can just drop that from the charter. I
wanted to discuss a bit more the reason for saying we should try to schedule
these on the same day. One of the big concerns from a bunch of people is making
sure there is very close coordination between DELEG and DNSOP. It was thought
that it would be very useful for them to both be on the same day so that topics
are fresh in everyone's mind and good overlap in people. If DELEG was on a
Monday and DNSOP was on a Friday it's not unlikely we'd miss a few people. Yes,
this could just be done in the scheduling tool, but we wanted to try and
encourage more interoperability and coordination between the groups. Like
ideally I think these could almost be joint meetings. But there's no possible
way it would all fit in a slot. We could remove this text. I still think it's
useful to keep it in there. It says ideally they meet on the same day, but, you
know, we can remove it. It's just keeping it around so when people swap in and
out we have the nudge.

Éric V: What about putting "Note:" before this statement, so it's not really
part of the charter? It's not really part of the charter, but I understand your
reasoning.

Warren: I thought "ideally" did that better. But we can also just drop it, it's
not the end of the world.

Paul: I would just drop it. It feels like special treatment. It feels somewhat
similar to "preferably not on Friday afternoon;" it just shouldn't be there.

Roman: We're going to create an arms race here if scheduling requests can be
made in charters. Charters are not made for the Secretariat and those who
process scheduling.

Francesca: It's enough to say already that it's related to other WGs.
Scheduling is then separate.

Warren: Okay.

Roman: So on my block, there was a bit of discussion and a proposal to do what
I think is the simplest answer, which is just to make the text just read the
working groups will specify extensions to the DNS period related to delegation
period. But then I saw a little bit of other traffic, no no, like we need this
EPP thing in scope. I don't know where that landed. And if EPP still stays in
scope, I think we gotta polish the text a little more.

Warren: We could always have something like the WG will work closely with
REGEXT to process any extensions, or something like that. We want to ensure
that if there is EPP work that needs to happen, that there is strong input from
the proposed DELEG working group to make sure that what is generated in REGEXT
meets the need.

Roman: I'm sure many of these terms are loaded in other people's understanding
of the scope. In my version, saying DNS related to delegation is a different
set of protocols than saying EPP for delegation. So I'm not sure whether we're
doing EPP modifications in this WG. If EPP was not listed there, I'd say that's
not what the scoping text says.

Warren: I think we can figure the last bits out by mail. It seems very likely
there will need to be some EPP extension. EPP is the way you configure this
information through the registry and registrar, and so it seems likely that
there's going to need to be some EPP extensions in order to allow you to signal
this information.

Paul: Not if you put it in the DNS record, which is one of the options.

Roman: I don't want to engineer the answer. My only input is that if EPP
extensions are in scope, you need the words around coordinate with REGEXT, but
I also think the program of work where you're listing the deliverables, that
also needs to be explicit.

Warren: Okay. We'll work on text.

Orie: To chime in on the EPP and RDAP potential overlap, the recent discussions
on the thread regarding that have led me to believe that it's unknown what the
specific solution would be here. It's somewhat premature to suggest that either
of those protocols would be used. I don't think it's necessarily helping the
charter to say if there's an impact on EPP or RDAP it will be coordinated with
the REGEXT WG and responsible AD, but I did offer that as a potential option
and so far the responses on the list have suggested that maybe that's obvious
and doesn't help the charter

Warren: Okay. I think we can figure the last bits out by email.

Éric V: And Warren, please ballot a Yes.

Warren: I thought I had. I guess I'm used to putting a document on which
automatically gets the Yes. Yes, I support the charter!

Liz: So it sounds like you have a bit of work to do on this one; we'll wait to
hear from you about when it will be ready to move on.

 o SRv6 Operations (srv6ops)

Liz: Does anyone have an objection to this being sent for external review?

Francesca: I don't have an objection, but I did abstain on this charter. I have
some concerns but because we have discussed this several times, it's not strong
enough to sustain a block. But I did want to say for the record that I think
the overlap with SPRING is a little worrying and I know Gunter had that in his
ballot as well. He suggested that SPRING recharter, which I understand is not
going to happen, but it says the chairs will talk with the responsible AD. It's
sort of worrying that we have two charters with topics that could go to either.
I'm not going to block, just wanted to mention it again for the record.

Jim: Just to clarify, SPRING are going to recharter. I've insisted with the
chairs that they do so. We didn't want to hold this up while we go through the
whole process. Because I'm AD for both groups I can make sure that happens.
Originally Gunter had the block and now he's a yes, and that's basically
because we had this side conversation to make sure that will happen.

Francesca: Thanks for the clarification; I'd missed that part.

Warren: I'll note that a bunch of us are concerned about similar things, but
there's a strong analogy with what's happening here and 6MAN / V6OPS, which
isn't necessarily a perfect example of how things go well but there's a
similarity. SPRING does the design work kind of like 6MAN does and then SRV6OPS
does the ops bit kind of like V6OPS does.

Francesca: I understand that. I was just a little bit wondering about a strong
enough motivation for this WG. but i'm not going to block and this can go to
external review so more people can say their opinion.

Roman: I was with you, Francesca. One thing that made me feel a little more
comfortable is that it says it only makes informational documents, which
narrows the scope. I also assume there's some big bow wave of work that's
motivating the need for this WG and I'll be watching for that when the
milestones are caught.

Liz: This one doesn't have any blocks, so it can go for external review now.
Jim, are we ready to send the announcements for external review? [Jim lost
audio but said in chat it was okay to go ahead.] All right, we will get that
external review announcement sent.

4.1.2 Proposed for approval

 o Secure Patterns for Internet CrEdentials (spice)

Liz: There are no blocking comments here. Does anyone have an objection to the
creation of SPICE?

Paul: Me, maybe. I'm confused about the process here. There were some comments
in the review but I haven't integrated those comments into a new version yet.
Is that what I'm supposed to do before it gets to this meeting? Or am I
supposed to do this after whatever we do right now?

Roman: You should integrate whatever changes you want to make to the text
before you say it's ready to be approved, because after that the text cannot be
changed without doing a full recharter.

Paul: So clearly I need to do that. How did this get scheduled on today's
telechat? I thought it was still just me and the SPICE people.

Liz: After external review, we automatically put it on the next telechat to
keep on schedule.

Warren: A lot of stuff around chartering is weird. If you change charter text,
the existing ballots disappear. It doesn't quite work the same as a draft.

Roman: It depends on which state you're in, whether you can rev the charter and
keep the ballots.

Paul: I'm glad to hear that it's not just me who is confused.

Roman: So the IESG just said we are good to go with the charter, but you still
have community things you need to put in there?

Paul: Possibly, yes. I need to read up on the community stuff. And then I will
likely make some changes.

Roman: Do you want to not approve this and keep this as an item for the next
formal?

Paul: For sure.

Liz: Great, we can do that. We'll take no action right now and we'll put this
back on the next formal telechat agenda to discuss approval again.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o EAP Method Update (emu)

Liz: This does not have any blocking comments either. Is this recharter ready
to be approved?

Paul: This one is ready. Let me read Francesca's comment; okay I'll make that
change. So I guess I'll do it during the meeting and we can come back to this?

Liz: Sure, or we can just leave this in the equivalent of AD Followup and you
can just let us know when you've made your change and it's ready to be
announced.

Paul: Okay, that's fine too.

5. IAB news we can use

Roman: The first thing to mention is the IAB is considering a new workshop
called New Eras of Network Management; this may be of particular interest to
OPS. There's discussion around the ISOC response to the FCC community call
around reporting on BGP risk mitigation. And the IAB is busy around various
liaison appointments. Tommy and David, what did I miss?

Tommy: One more potential workshop topic we'll be discussing next week, from
Mark Nottingham about AI opt-out and if there's something that needs to be done
around SDOs.

Éric V: What is meant by opt-out?

Tommy: If you're familiar with things like robots.txt on websites, equivalent
things. My understanding is that some places I believe in Europe are trying to
have regulations saying that you need to allow your content to be opted out of
AI, but there's no technical mechanisms really to do that. And so, there may
need to be some standards discussion and effort around if this is going to be
regulated, there needs to be a mechanism. Potentially the IETF could be a venue
for that but at this point it would be more like a short workshop in early fall
to get the players discussing it.

Warren: Just wondering if you have already had discussions with the author of
the robots.txt RFC who's got a draft that already does 99% of this. I can't
remember if he's posted it.

Tommy: I have not personally but I know Mark has been following that. What
we're going to be talking about next week is getting an introduction and
background to that topic. If you want to join or drop a line to this guy to let
him know to join, that would be great.

6. Management issues

6.1 [IANA #1364749] Designated experts for RFC 9553 (JSContact registries)

Liz: This is a new action item for Orie, so that's been assigned to him.

6.2 [IANA #1364807] renewing early allocation for
draft-ietf-bess-evpn-ipvpn-interworking

Liz: Gunter, this is for one of your documents; do you want to say anything
about this renewal?

Gunter: It should be renewed. There are about four working implementations out
there and this thing is nearly ready for being pushed to the IESG. So, yes.

Liz: Thanks, Gunter. Does anyone have any objections to renewing this early
allocation? Okay, we'll call this renewed and we'll get that official note sent
to IANA.

6.3 Executive Session: Second round of IETF 120 BOFs

6.4 Executive Session: IETF 126 Meeting Planning

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