Narrative Minutes interim-2025-iesg-08: Thu 14:00
narrative-minutes-interim-2025-iesg-08-202504171400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2025-04-17 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
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
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
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Jean Mahoney (AMS) / RFC Editor Liaison
Ketan Talaulikar (Cisco) / Routing Area

OBSERVERS
---------------------------------
Sandy Ginoza
Bob Hinden
Suresh Krishnan
Warren Kumari
Nathan Sherrard
Greg Wood

1.2 Bash the agenda

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

Roman: I think we wanted to talk about the interim meetings topic; can we add
an item for that?

Liz: Absolutely.

1.3 Approval of the minutes of past telechats
Liz: Does anyone have an objection to the minutes of the April 3 teleconference
being approved? Okay, I'm not hearing any objections, so those are approved,
and we will post those in the datatracker. Does anyone have an objection to the
narrative minutes of the April 3 teleconference being approved? I'm not hearing
any objection there either, so those are also approved, and we will also post
those in the datatracker.

1.4 List of remaining action items from last telechat

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

Erik K: In progress; the registry requires three so that there can be two out
of three for consensus. I think I have two people. I need one more.

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

Paul: In progress; I'm still waiting on one confirmation.

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

Mike: In progress.

  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: We have a management item at the end of the agenda to approve some names,
so this one is provisionally done.

   * OPEN ACTION ITEMS

  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.

Roman: These are both in progress. And to close on an action item [not listed
here], I sent the list we updated last week to the LLC on what you wanted to be
updated about. Thank you all for the input.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-netconf-netconf-client-server-38  - IETF stream
   NETCONF Client and Server Models (Proposed Standard)
   Token: Mahesh Jethanandani

Liz: There are no Discusses in the tracker. So unless there's an objection now,
this one is approved. I'm not hearing any objections, so this is approved.
Mahesh, what would you like to do with this one?

Mahesh: Could you put it in AD review?

Liz: Okay, great. So this one will be Approved, Announcement to be Sent::AD
Followup, and you can let us know when it's ready to go.

 o draft-ietf-netconf-restconf-client-server-42  - IETF stream
   RESTCONF Client and Server Models (Proposed Standard)
   Token: Mahesh Jethanandani

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

Eric V: Maybe, because I'm not sure whether my Discuss is really strong,
because I don't know Yang enough, but Yang Catalog is an error compiling the
module, and I think this should go either back into the Yang Catalog or back
into the document.

Mahesh: Eric, I can check if it can, but I believe he does validate the model
before publishing that. But if that's the only concern, I can certainly put
that as an action item for myself.

Eric V: Just tell me what you think about it, because I balloted this one or
two hours ago, mostly when you were sleeping. So bearing this error in the Yang
catalog and the max which is not defined, as I noted in the Discuss point. No
problem, right?

Mahesh: Okay, I'll check that to update the tool set so [audio broke up]

Roman: This is a good conversation to have. I want to ask the general version
of this question, which is, if the Yang catalog is throwing errors and we see a
datatracker page for a document on the ballot and it says error, is the tooling
good enough to directly imply we have an issue and we should create a gate,
even before it gets to the telechat if it has an error? Where is the state of
the play in the tooling?

Mahesh: It can sometimes run errors not because of the Yang module that is in
the draft, but a module that it's dependent on. So that's what I was saying. I
probably need to check where the error is coming from.

Roman: I see. So in the general case, there's too much local, like Yang
specific, on a particular document to know, and so we shouldn't necessarily
infer that there's an issue just because an error got thrown. That's good.
Okay, just checking. Thank you for that clarification.

Liz: Okay, so this one will stay in IESG evaluation, and for substate, which
would you like Mahesh; AD Followup, or revised I-D needed?

Mahesh: Could you put it in AD Followup?

Liz: Okay, great. So this one is in IESG evaluation::AD followup.

 o draft-ietf-suit-trust-domains-10  - IETF stream
   SUIT Manifest Extensions for Multiple Trust Domains (Proposed
   Standard)
   Token: Deb Cooley

Liz: We have a couple of Discusses in the tracker. Do we want to discuss this
document now?

Deb: No, not today. Thank you.

Liz: Okay, so this one's staying in IESG Evaluation. Would you like revised I-D
needed or AD Followup?

Deb: Revised I-D needed. Thank you.

 o draft-ietf-anima-brski-prm-20  - IETF stream
   BRSKI with Pledge in Responder Mode (BRSKI-PRM) (Proposed Standard)
   Token: Mahesh Jethanandani

Liz: We do have a couple of Discusses in the Datatracker. Do we want to discuss
this now?

Mike: I believe that conversation is ongoing between the two working groups, so
I think we just need to let that settle.

Gorry: I agree. I'm keen to try and get rid of my TLS Discuss question, because
I'm not a TLS expert. Is somebody else going to hold this? Whether it should
mention TLS 1.2 or 1.3 and how it does it?

Mike: I think that's the conversation that's happening right now.

Gorry: That's fine. I just feel that I could clear if they address the second
point, which I think they will do very soon, then I could just clear my Discuss
and leave it to other people.

Paul: I missed this document, but if it's mentioning TLS, then it should
definitely comply with the UTA type documents that say when and how to use TLS
version 1.2 or 1.3.

Mike: The situation here is that this is an extension to an existing protocol.
The existing protocol strongly recommends TLS 1.3 but makes 1.2 the mandatory
baseline. And now we're flipping the guidance. And the question is, what does
that mean for this extension? Do they only follow that guidance on the new
component they've added? Are they both applicable? And therefore you must
support 1.2 and 1.3 because they're not updating the original document. Which
is the issue? If they were updating, was it 8995 then I would say, Yeah. As
part of your updates, you have to flip to comply with the new guidance, but
they're not.

Paul: Does the extension use the same TLS connection, the main argument, or
separate some of them?

Mike: The base protocol has the pledge talking directly to the registrar. And
this is to support a case where there's not network connectivity continuously
between the two, so there's an agent that talks to the pledges, then talks to
the registrar over a separate connection or at a later time, and then goes back
to the pledges with the result.

Paul: I would say that it would be kind of weird to have conflicting
recommendations for these two things, and I would be more tempted to say, just
refer to TLS recommendations to the main document, and then at some point,
update the main document.

Mike: They're having conversations with UTA right now, so I expect that's where
they'll land. They can mandate it for the new component they've added, but at
this point, as long as that conversation happens, I'm content with whatever
they decide. I'm going to clear the Discuss regardless so long as they actually
do it.

Gorry: Yeah, that helps me. Thanks.

Mahesh: Liz, you can also put this in AD Followup.

Liz: Okay, great. So this one is staying in IESG evaluation::AD Followup.

 o draft-ietf-6man-zone-ui-08  - IETF stream
   Entering IPv6 Zone Identifiers in User Interfaces (Proposed
   Standard)
   Token: Erik Kline

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

Erik K: I still haven't finished. I'm getting caught up from being away for
several weeks, but I did see Roman that Brian had replied to you.

Roman: If he has, I have not read it.

Erik K: Happy to take it over email.

Roman: Okay,

Liz: So this one is staying in IESG evaluation, and was AD Followup?

Erik K: Yes, please.

Roman: Bob's on the call, do you want to say something or you want to summarize?

Bob Hinden: I just saw this this morning when I got up, so I haven't really
read it very closely, but I thought Brian's response was generally pretty good.

Roman: Okay, I'll take a look. Thanks.

 o draft-ietf-6man-addr-assign-02  - IETF stream
   Clarification of IPv6 Address Assignment Policy (Best Current
   Practice)
   Token: Erik Kline

Liz: We have a few Discusses. Do we want to discuss this one now?

Erik K: We could, I think, if people want to. I think the main concern, again,
I'm still not completely caught up, is the coordination with IANA during Last
Call. There was some stuff with IANA; I'm not really sure why everybody's upset
about stuff, but yeah, people want to talk about this.

Mike: I think one of the high level pieces is that they have an appendix that
draws attention to an issue, but doesn't actually direct IANA to do anything
about it.

Erik K: Yeah, there was a thread about that during the Last Call, which is on
the last call list, which is how it got marked as IANA OK. I provided my own
personal opinion on that thread. One of the difficulties is that there isn't
exactly parity between the IPv4 and IPv6 registries. The IPv6 registries are
kind of split.

Sabrina: Erik, just so you know, we are proposing that the appendix be removed,
and we'll contact them about renaming sometime next week. I think our
preference would be to remove 'registry' from the name, which is the direction
that we've taken with other registries. But we'll reach out next week to the
authors with suggestions.

Erik K: That sounds great to me. Does that satisfy everyone who was concerned
about that particular point?

Eric V: I don't know if you've seen Brian's response to my own Discuss; he
proposed text but hasn't uploaded the revised I-D yet, so I'm holding my
Discuss until the new version. It's basically clear, though.

Erik K: Sounds good. The IANA pieces can be handled on their own through
separate correspondence, right?

Roman: They could; sometimes we hold Discusses if they're breaking things that
IANA needs. Sabrina will tell us definitively.

Sabrina: I think we can handle this separately to make it consistent.

Mike: Once the appendix is removed?

Sabrina: Yes, that's what we're proposing to the authors.

Roman: But ADs can hold if they want, that's within their right.

Erik K: Sounds like there's an update required as well. I think this is Revised
I-D Needed.

Liz: Great; so this stays in IESG Evaluation::Revised I-D Needed.

Erik K: Thank you. Great.

 o draft-ietf-uta-require-tls13-12  - IETF stream
   New Protocols Using TLS Must Require TLS 1.3 (Best Current Practice)
   Token: Paul Wouters

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

Paul: Put this in AD Follow up, please.

Liz: Okay, great. So this one will be Approved, Announcement to be sent::AD
Followup, and Paul, you can let us know when it's ready.

 o draft-ietf-sipcore-callinfo-rcd-18  - IETF stream
   SIP Call-Info Parameters for Rich Call Data (Proposed Standard)
   Token: Andy Newton

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

Andy: Can we put this in AD Followup?

Liz: We sure can. This one will be Approved, Announcement to be sent::AD
Followup, and just a warning for you Andy; this document does have a downref,
so we are going to need to ask you if you want RFC 7903 to be added to the
downref registry.

Andy: Thank you. Okay.

 o draft-ietf-lsr-multi-tlv-16  - IETF stream
   Multi-Part TLVs in IS-IS (Proposed Standard)
   Token: Gunter Van de Velde

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

Gunter: I think Ketan is not here, but there has been a good discussion between
him and the authors of the draft. Things are progressing, and let's see where
it brings us during the next week.

Liz: Okay, great. So what substate would you like?

Gunter: I think for the moment AD Followup, because they haven't given a new
draft yet.

Liz: Okay, great. So this one is staying in IESG Evaluation with AD Followup.

2.1.2 Returning items

 o draft-ietf-emailcore-rfc5321bis-42  - IETF stream
   Simple Mail Transfer Protocol (Internet Standard)
   Token: Andy Newton

Liz: This is the new re-ballot for this document which we discussed last time,
but there are no Discusses in the tracker, and there are enough positions.
Unless there's an objection now, this one is approved. [pause] Okay, this is
approved.

Andy: Can we put this in AD Followup? And I would like to thank the rest of the
IESG for going through a second ballot on this document. That was much
appreciated.

Liz: This one is Approved, Announcement to be sent:: AD Followup. Andy, again,
this one has two downrefs; so once it gets to the final approval, we will ask
you if you want 3463 and 3848 to be added to the downref registry.

Andy: All right, thank you. I appreciate it.

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-6man-eh-limits-19  - IETF stream
   Limits on Sending and Processing IPv6 Extension Headers
   (Informational)
   Token: Erik Kline

Liz: We have quite a few Discusses. Do we want to discuss this now?

Erik K: I haven't caught up on stuff. I don't know if Tom was replying, but we
could discuss here, if people want to. It might be that this ends up back at
the working group. I don't quite know yet.

Eric V: I would support your decision to send this back to the WG.

Gorry: Tom did give me a little feedback in an email last night but he wasn't
exactly proposing new text. I'll need to parse the whole thing again and send
him another email. It's very much ongoing; I don't see an immediate resolution
being offered.

Erik K: From Revised I-D Needed I could take it back to the WG anytime, right?

Roman: Correct.

Eric V: Do you think it can be fixed?

Erik K: That sounds like a question for the WG.

Eric V: Fair enough.

Gorry: This is a very extensive list of things you could pin down from stuff at
one edge to the other edge to the middle…that's a complex soup. I don't know
how you debug it. It'll be interesting to see what you could do to simplify
that.

Erik K: I'm sympathetic with the goal, which is trying to establish some
conceptual interrupt from a baseline, at least within an administrative domain,
or incorporating administrative domains so that you could buy a baseline of
networking equipment that would have some support and not no support. So I am
sensitive to throwing it all out, because it's not perfect could just mean that
we basically never get anything. It probably belongs with the working group to
decide how to address this volume of things. I need some more time to catch up
on this, and also maybe some rounds of discussion with Tom could produce
something. If nobody else has anything else, we could probably just put this
into Revised I-D Needed, please.

Roman: I would say, from my perspective, the narrow thing that I talked about.
If there was an applicability statement scoping where this would be used, that
would help.

Erik K: Understood. That makes sense. I'll bear that in mind.

Liz: Okay, great, so this one is staying in IESG Evaluation with a substate of
Revised I-D Needed.

 o draft-ietf-6man-vpn-dest-opt-05  - IETF stream
   The IPv6 VPN Service Destination Option (Experimental)
   Token: Erik Kline

Liz: We have a few Discusses. Do we want to discuss this now?

Erik K: I suppose, if some people do. At least Ketan has Discussed but he's not
on the call.

Paul: I wouldn't mind briefly discussing it. I honestly don't understand the
document. That might be some of my lack of knowledge of the layer that this is
happening. But for instance, the dimensioning of authentication header, which
is only about integrity and other encryption, combining that with talking about
VPNs, which is about encryption, and how does it relate to IP based VPNs and
other solutions is unclear to me. It seems it's setting an option to indicate
this is a VPN and leaves everything else out of scope. I'm not sure what the
goal of this is.

Erik K: Maybe routing people can correct me; I've seen the P in VPN does not
necessarily mean privacy or encryption. It just means traffic separation not
natively routed with the traffic that carries it.

Jim: Easiest way to think of it is they're essentially using an MPLS label; it
has nothing really to do with encryption at all. There are encrypted VPNs and
non-encrypted VPNs, and this one is just adding another option to the market. I
didn't ballot on this; I was going to abstain but it didn't need another ballot
so personally I don't see the point, but technically I couldn't see anything
wrong with it from a routing perspective.

Erik K: In this context, a VPN is not necessarily about security, you can
swap/replace it with the term tunnel.

Paul: It makes it somewhat clearer that they're talking about authentication
headers. Still a little confusing that they're using spies, but I'll get some
more comments from the authors to understand this. So sorry for any delays.

Erik K: There are many other delays. I'm a little bit, I understand some of
these arguments, I'm just not terribly sympathetic to the marginal cost of
adding an experimental RFC is so high that it must be blocked. That doesn't
seem like a sustainable position.

Gunter: From my end, it's like Jim mentioned; from a technical perspective I
don't see anything which won't work and I'm not proposing to block the
document. What I do want to see better is how this solution lies within the
other set of solutions out there. Just adding more context around the use space
for this particular technology going forward. If you look at my Discuss that's
what it boils down to, adding more context where this is used and what are the
other comparable solutions in the market.

Erik K: How comprehensive of a survey of the universe of tunneling solutions do
you want?

Gunter: It's not a pissing contest. This document was created back in 2018, and
seems to assume that all VPNs are running MPLS, which is not the case anymore,
and now we have v6 and those things are doing something similar than what this
solution is doing. I think maybe that should be, you know, placed upon a unit.
If you read the document now, it says whatever is out there is based upon MPLS,
and that is not really true.

Erik K: That's not how I read it. I read it as the MPLS heritage was explaining
the way it came from and not necessarily implying anything.

Eric V: Like you Erik, I don't mind too much if this thing is published. To
Gunter, a VPN ID is 20 bits if i'm not mistaken. …. It could be made more
generic, for instance. I don't mind the 20 bits but it could have been 32.

Jim: From my perspective the thing I was most concerned about was the way I
read the document, it implied the only way to use VPNs was to use MPLS, which
is obviously not true. There's a raft of different ways of doing it that have
nothing to do with MPLS. But technically it works, so I wasn't prepared to make
a big deal of it.

Erik K: I hadn't read it with that mindset. I had understood it as the
MPLSiness of it as being motivational. I'll have a look at that and give some
time for Ron to jump in as well. I haven't caught up as to whether or not Ron's
been replying. Unless there are other questions, I suppose this is Revised I-D
Needed.

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

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

 o Operations and Management Area Working Group (opsawg)

Liz: We don't have any blocking comments here. So any final objections? Is this
ready for external review?

Mahesh: Roman did bring up the question of milestones that are missing in the
charter. So maybe this is a larger discussion. I've heard from the chairs
saying they're good for the initial working group, but for re-chartering a
working group, they feel that these milestones really don't make sense in the
sense that often they are outdated. Nobody really looks at them, and they're
just exercising and updating the dates without really trying to make that as an
ultimate goal. I have asked them for milestones, and maybe I'll get some. But
I'm wondering if, as a practice, what do others feel about the need for having
milestones?

Roman: Procedurally, thank you for thinking through this issue. There is a
community vibe around having milestones and different flavors of milestones.
There's the dated kind, the undated kind, and an argument for not having any of
them. There is a mailing list, protocon, around resolving that in some
particular way. My concern here is that as written in 2026 we have to have
them. If we could just document what we think we're rechartering for in the
milestones, and then have the larger conversation about how they're maintained
and what makes sense on that mail list.

Mahesh: You're okay with milestones with no particular dates?

Roman: There are different flavors of milestones you can choose in the
Datatracker. There are sequenced milestones, this one first that one next, and
I think there are undated ones as well. Someone correct me.

Deb: You have 22 adopted drafts in that WG. Surely you can come up with a
couple of milestones.

Mahesh: The question is larger than just coming up with some milestones; it's
probably a larger discussion about when they make sense. Procedurally, for now
I can put in some milestones; but I've been getting a lot of pushback from
chairs saying they don't make sense.

Deb: Any adopted draft should have a plan, right?

Mahesh: It's not that there isn't a plan, it's the dates. As Roman suggested we
could go without dates. But if we start to put dates, most of the time we blow
past them and they're meaningless. Okay, so maybe for now, what I'll do is I'll
ask the chairs for some milestones, and once I get them, I'll put them in.

Liz: There's nothing blocking this from external review. Do you want us to wait
until you have those milestones in?

Mahesh: Yes.

Liz: Okay, so then we will leave this where it is, and why don't you let us
know when there are milestones in and it's ready to go?

Mahesh: Thank you.

 o Update to IANA Considerations (ianabis)

Liz: We do have a couple of blocking comments. Do we want to discuss this now?

Roman: Yeah, for sure. I just wanted to kind of tease out what makes most sense
with you, Mahesh and Med. I'm not tracking, and I'm not sure whether the
working group is tracking, the trajectory of that netmod document. It seems
like both of you indexed on part of that. So what is the aspiration?

Mahesh: So the idea was mainly to consolidate all these IANA guidelines into a
single document, if possible. And we have it currently in 8407bis, which is in
my AD queue already. I expect it to come onto a telechat in a short period of
time, so it'll get published soon enough. The question is, at that point,
should the document continue to maintain that IANA guideline, or should it then
maybe have the other document pick it up?

Roman: So you want to make sure that the 8407bis document is published because
it's already in your queue, you don't want to block that. So the idea is, get
that to RFC, then the question is if that's an RFC, there is this IANABIS
working group that already has a chartered set of things it's working on. You
want to make sure that the charter gets expanded to then capture the relevant
IANA procedural recommendations there in whatever is in the BCP that's captured
in that working group, right?

Mahesh: Yeah. That certainly would be the ultimate option for me, as far as I'm
concerned. [audio broken up] here's the guidelines you need to follow.

Mohamed: And I would say, just an example, that the point is whether in the
end, is really to have some guidance for future updaters of RFC 8126 whether we
need to provide some guidance on this or not. This is something that can be
happening. I don't think we need to spend a lot of cycles on this.  This
happens because I'm editor of this document, and Mahesh is the sponsor, so we
know about it. But what happens for other documents who are updating 8126? Just
having some guidance somewhere, or at least a discussion on how we would
proceed in the future. It is not something I think that's really a lot of work
to have in IANABIS as well.

Roman: I'm not sure whether this is exactly related, but the way I would frame
it is IANABIS was not created to be a long lived, long running place where
we're going to perpetually manage IANA stuff. What happened is we went into
Gendispatch two times ago and there was a groundswell of very specific things
folks wanted to work on. And IANA was working on 7020. This was, let's put
those together, and let's narrowly scope this WG. I don't know what the long
term answer is. From my perspective, I want a narrow focused IANABIS working
group, because I think opening up the box is not helpful. If we have a tangible
thing we want to fix we should surface that. But I also think we need to gut
check with the working group that they want to work on it. I'm a little bit
sensitive to pushing work into the working group from this review if there
isn't community appetite to do that.

Mohamed: That's fair, Roman.

Roman: So practically, what do you think we need to change in the charter? Or
do we need to keep talking about it? So like on [the netmod document] what do
you think are the right set of words? Do you have an intuition? Either of you?

Mahesh: I would say, maybe just to ask that when we do publish the IANA
document, that it just adds a reference, at least to begin with. As far as I'm
concerned, just a reference to 8407 section 4.30.

Roman: Understood.

Deb: Why 4.3?

Mahesh: Because that's the section in 8407 that deals with IANA maintain module.

Deb: Is that in the bis document?

Mahesh: That's in the 8407bis netmod document, yes.

Roman: The way I've internalized it is that other document has a bunch of
guidance. Some of that guidance is IANA specific. We want that document to be
published. We don't want to block it. Well, I don't want to presuppose how the
review would go. But let's proceed presupposing it's an RFC. Whatever the
IANABIS is working on is going to take a while, again, not presupposing exactly
how that's going to go, but it's going to take longer than to get the other one
to RFC. You're looking to see a reference in whatever is some future document
published by IANABIS to make reference to include in some approach that calls
out that netmod document, right?

Mahesh: Yes. That's good.

Roman: Fair enough. And then, Med, you were making a document engineering
observation about really prescribing which BCP things are added to, if the
working group decides to consolidate, right? You had a very specific intuition
about if the documents go into the same BCP, like, 26 is cited more, throw it
into 26, instead of potentially minting a new one just not to break reference.

Mohamed: Yeah, exactly. I think it's simple to address this one.

Roman: For sure. And Eric, you made a comment on procedurally how to exactly do
that. I know we'll figure out how to do that. I've also never done it.

Eric V: Oh yeah, sure. I was just curious.

Roman: Yeah, it's some status change something, if someone knows on the call
how you put things into BCPs? We can talk that through. Okay. I really
appreciate all that feedback. I didn't intuitively understand some of these
things, so thanks for the clarity. We'll get a rev on the charter that will
cover this. Thanks. This stays blocked.

Liz: Great; so this will stay where it is, and we will await further
instructions from Roman on how to proceed.

4.2.2 Proposed for approval

 o IOT Operations (iotops)

Liz: We have a block. Do we want to discuss this now?

Roman: I want to discuss it because I think we can absolutely clear it. So just
to be really clear, on that charter text, we took the old text which was about
talking about things, but we jammed it under the section that talks about
making documents. So really, what we're saying is we're going to talk and make
documents about that topic, right?

Mohamed: Right.

Roman: Okay. My recommendation editorially is maybe clean it up so it's a
little clearer, but I'll clear my block. Just checking.

Mohamed: Okay, thank you.

Liz: It sounds like we're maybe waiting for a couple of more things before this
is going to be ready to approve. So for now, we'll just leave this where it is
and Med, you can let us know when it's ready and can be announced.

Mohamed: Okay, thank you.

5. IAB news we can use

Deb: They had a business meeting yesterday. They are adopting workshop reports,
the nemops report and the AI control report, just to get the documents adopted.
There was some discussion from Mark Nottingham about age verification and the
sorts of things that he wants to do with that, basically doing a bit of a
survey to see what the state of affairs is currently. There's some discussion
between advocacy and architectural concepts where ISOC is probably doing
advocacy, and Mark wants to stick with architectural concepts in the IAB. They
talked about BOF chartering and who was assigned to what, and then they also
talked about appointments that were up in 2025. They also talked about WSIS+20
and the upcoming meetings. Most of that was Ryan Polk.

Tommy: The other thing I would bring up is we were planning out the work that
people are going to be doing before the upcoming retreat in June. There are a
couple different focus areas that some people are going to be looking at, like
geo IP topics. I think we discussed that with some of the IESG folks too. There
may be things that we can bring to joint discussion. I think there's also some
discussion we may want to bring up around just reviewing and refreshing the
NomCom job descriptions probably in both IAB and IESG, and since the IAB has to
approve the slates that are given to us, we just want to make sure that the
IESG job descriptions are clear and make sure that NomCom has the right
information to come up with a good slate. So as you are working on that, let us
know.

6. Management issues

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

Liz: We talked about last time, and Jim, you said you wanted a bit more time to
look into this.

Jim: Basically 8111 was an experimental RFC, and they've now got 8111bis that
they're working on in the working group to move this to standards track. So I'm
okay with the early allocation and I approved it through email. That's what was
happening with that one.

Paul: There are not any wire format changes in the bis document?

Jim: No. LISP has done this quite a bit. A lot of their documents were
experimental RFCs, and they've gone through a list of them to move them to
standards track from experimental. And this is just one of that group, so
there's no actual changes as such. It's just moving it from experimental to
standards track.

Eric V: Out of curiosity, does it mean that the experiment went fine?

Jim: It does, yeah, according to them.

Liz: So Jim is recommending approval of renewing this early allocation and I'm
not hearing any objections. So this renewal is approved, and we will send that
official note to IANA.

6.2 [IANA #1357864] Designated expert replacement for Graham Klyne (Orie Steele)

Liz: Orie has named Mark Baker as the primary and Murray as the backup
designated experts for these registries. Any objection to approving these
folks? I'm not hearing any objections, so they are approved and we will get
that official note sent to IANA and that action item closed.

6.3 [IANA #1417100] Approve media type application/texinfoF(IANA)

Liz: Has anyone had a chance to look at this?

Orie: I've been following the discussion regarding this. To summarize for folks
who are maybe not familiar with the work: essentially, there's texinfo, and
it's been widely used. We've searched open source repositories and found many
instances of it. This registration sort of cleans up the fact that this thing
has been floating around in the wild for some time.

Paul: Is texinfo a typo, or is that textinfo?

Orie: I'm not sure about the query string if you're referring to that. I think
it's intentional in its current construction.

Roman: Thanks for that background Orie. I looked at it. This feels consistent
with the application of the grandfathering rule that comes from Appendix A, so
I'm fine approving it.

Eric V: It's application/texinfo, rather than text/texinfo. But I guess people
have discussed it.

Orie: You should review the list discussion for that, there's a good
conversation there around the history

Eric V: Thanks. I may not review it, though. I trust you.

Liz: I'm not hearing any objections so it looks like this is approved, and we
will get that official note sent to IANA, spelled as requested.

Cindy: To clarify, the F is a typo. The tex versus text is not.

Liz: The F must have been a copy paste error when it was put on the agenda. So
sorry about that.

6.4 [IANA #1417154] RADIUS Types Specification Required registries without
experts (IANA)

Liz: It looks like there are two registries that do not have experts, but are
related to some others, so IANA is suggesting adding Alan and Mohit as the
experts for these two as well. Any objections to these experts?

Mike: I assume that the experts have been asked?

Paul: Yeah, they were part of the email exchange with IANA.

Liz: Okay, I'm not hearing any objections, so they are approved and we will get
that official note sent to IANA.

6.5 Interim Meetings

Mike: Just to refresh people from last week, the AIPREF working group has a
fairly aggressive schedule, and they've requested an interim meeting
immediately before the next IETF.

Paul: A virtual or a physical one?

Mike: A physical [hybrid] one. They have a virtual one planned in a couple
weeks, and they've already had a hybrid one. They want to have another hybrid
one before IETF. Based on our feedback from last week, they sent out a survey
to the working group asking for preferences on dates and locations. And there
does seem to be a pretty strong preference in the working group to do it
immediately before the IETF. So the schedule that had been proposed was
Thursday, Friday, interim; hackathon over the weekend, WG session on Monday,
and then the people who are not participating in other IETF stuff can go home
on Monday night. So we concluded last week that we don't object particularly to
the idea of giving them an exception, although certainly that can be reopened.
But our IESG statement guidance on in person and online interim meetings,
depending exactly how you read it, can be interpreted as saying that's a hard
no, and there's no flexibility for ADs to approve exceptions. So we have kind
of the parallel facts of, does the working group want to do this? And that's
happened with the survey. But then also, if we were to do that, do we need to
update the IESG statement?

Gorry: I'm new here, but I'm not that keen on updating the IESG statement. It's
just extending the IETF week if we had a couple of days before. And people have
in the past complained to me when I was chairing things that they weren't able
to fit this in their travel schedule. Therefore, some people met just prior to
the IETF and decided something. Then they had the working group meeting in the
IETF, and doing this concurrently they found awkward. I guess it really depends
on whether the people at that meeting would attend, or other people would like
to see that and participate, rather than just that small group of people who
are meeting. You know, is it just that working group? I'm curious about this.
It rings a sort of alarm bell.

Roman: I came to the queue to talk about what was mentioned before. If we
approve the exception, I don't feel like we can approve this without also
changing the statement. I don't want to be in a position where we are violating
the thing we said, or the structural balance of things. And then, to me, if we
decide to make the statement, we should think about what approach we would
take? Would we think about community stuff, or just blanket make that change?

Eric V: Last week, I basically said I supported the interim, because the
participants are not IETF people anyway, so they will be coming just for this,
and they will not be blocked by preparing for the IETF week; except Mike and
the chairs, of course. Now I am with Roman, it's a hard no in the IESG
statement. And I'm with Gorry: I don't want to change the IESG statement. So
basically, at first I was supportive, Mike, and I'm now not supportive thanks
to the two others.

Paul: I have similar feelings. For instance, the IPSEC people also meet in
what's not a formal IETF meeting, sometimes a few days before IETF. So on
Thursday, Friday, they will also be meeting for an IPSEC workshop, but it's
clearly not an IETF meeting. I also find it a little weird that we could have a
physical meeting the days before that happens during the document blackout,
where we cannot have updates to documents, but we can have an entire working
group meeting, and it feels a bit conflicting to me as well. So I understand
and sympathize with them, but I think they should maybe just have a more
informal meeting beforehand, and not a formal working group meeting.

Mike: For the informal one, the statement does address that. It says it applies
to all hybrid meetings to which a substantial part of the working group is
invited in person, even if labeled as informal, which feels kind of circular,
because we're saying you can't have a meeting like that, therefore you call it
informal, but you still can't have a meeting like that. I think if we were
going to revise it, the main thing that I would change, it already says that as
a list of considerations, and that there's always trade offs, and the chairs
manage the trade offs with AD approval and just pulling the guidelines further
down as also being part of those trade offs, I think a reasonable way to
approach it, if we can do it. I think I understand the concern about touching
the statement. I think it would be unfortunate to tell people they need to fly
to Europe twice a week apart, because of our vault.

Roman:  I just want to respond to the idea of IETF participants and non IETF
participants. There's no such thing as a non IETF participant if you're showing
up. So this idea that we're catering a meeting to non IETF participants is to
me a non-starter argument, because there's no such thing. If you're coming to
the IETF, you're now part of the community.

Eric V: You're fully correct. I was oversimplifying the point; most of the
people in this WG are not regular IETF participants. They only attend IETF just
for this WG.

Roman: There are a lot of working groups that are one shot working groups as
well. So I'm just unpersuaded by that.

Tommy: I had originally gotten in queue to mention something similar to Paul.
I've seen that work for other groups; that has happened the week after the
meeting. Some topics are related to the WG, some aren't, but it's a place that
can still foster stuff. I'd lean toward recommending they hold this as a
workshop for the willing and maybe that leads to stuff that happens in the
week. I do think there is a benefit to having it be right before; I agree of
course there are no non-IETF participants, but if there are people who would
only be going for this and we said you have to hold the meeting a week or two
before, they'd only show up for that and not the plenary IETF meeting. There
could be a benefit of having those folks be able to be there on a Monday and
interact with the rest of the community that will only be showing up to the
IETF week version of the AIPREF meeting. That interaction seems to be important
to foster and let's figure out a way to let things happen that work well for
the policy that focuses on good technical outcomes and interactions between
people.

Deb: As I recall this interim meeting was supposed to be in London?

Mike: We have a venue offer in London, a potential venue 45 minutes outside of
Madrid. Given the distance from the IETF venue, we don't know that having it in
Madrid is all that helpful.

Deb: As opposed to flying or training from London? That's not 45 minutes.

Mike: Right, but you still can't necessarily book one hotel for the whole time
in either case. Part of the survey that went out was also if you prefer London
or Madrid; participants seemed to be largely split between the two.

Deb: There are many WGs that have proponents that only come for that one WG. We
could list them and it's at least in double digits; this is not a new thing.
The new part is they want to do hybrid interims as opposed to virtual. Many WGs
do virtual interims every 2 weeks and make that work. I'm opposed to updating
the statement. If it were Boy Scouts and we were going to laser tag, we'd have
to say we were going as friends, not Boy Scouts, for example.

Roman: From my perspective, I'm not against having some flexibility to allow
that. I'm reticent to approve this happening without having the statement to
back it because it violates our process. I think we should be in the position
to allow under extraordinary circumstances to meet right before or after the
plenary meeting; I'm not sure we are meeting the bar for extraordinary
circumstances.

Mike: The circumstances here are the WG is trying to complete this on a rather
aggressive schedule because there's regulation happening in parallel and
they're meeting frequently, both in person and virtually. Whether that meets
the bar of sufficiently extraordinary, I'm not sure.

Roman: If there was an aggressive deadline it might meet those circumstances.
I'm just cautioning us that we're setting precedent here; the bar for
extraordinary here is now the bar for everyone else. If we wanted to make a
change to the statement, I put some words in the chat for how we could change
it.

Erik K: That change looks good to me. Mike indicated they're also going to meet
during the IETF week so there is no issue about cannibalizing attendance.

Mike: We did talk about the possibility of having multiple sessions throughout
the week; I understand that we somewhat informally have a policy that multiple
sessions are spread out through the whole week.

Roman: I don't know whether that's true.

Eric V: We were trying to put the second session on Friday, though. That's what
we did multiple times.

Roman: To me, if we have extraordinary circumstances and we can satisfy this
during the meeting week, what are the constraints desired for the meeting week?
Is it two sessions? Two sessions close to each other? Is it three sessions?
Like, what? This is a different angle I hadn't heard.

Erik K: That sounds like something we could resolve during the two scheduling
calls, and they just need to put that in their session request.

Mike: So that could be another answer, asking them to request lots of sessions?

Deb: One two hour session with two two hour sessions is going to make them
happy? That's not exactly the same as two days of informal meetings plus a
session. You're not going to get two days.

Mike: It might be a fallback position.

Roman: Would it be helpful for you, Mike, to get an informal poll in Slack
about whether we would support this right now with the little we know?

Mike: Yeah, I think that would be useful feedback.

Gorry: I was just trying to figure out whether these people actually needed a
working group session. Do they need to make decisions on the document as a
working group, or do they need to talk about things, develop text, and work on
methods? To me, these are very different. If it's just talking, you need time,
if it's making decisions, then that is the bit I had the problem with just
prior to an IETF where other people might be traveling and we don't get
visibility etc. So do they need time to prepare documents and work on them, or
do they need to make decisions to do that?

Mike: I feel like that's kind of an amorphous line, because they have the
documents out there. We're working with documents already submitted. They
discussed the documents at their first hybrid interim, there's a call for
adoption ongoing right now, and there's going to be ongoing work on the
documents. Now, when do you move from working on documents to making decisions
about what's in the documents, and all decisions have to be on the mailing list
anyway. What do we ever do at the plenary meetings?

Roman: This feels like the really great line on us managing side meetings. Is
this working group run, or is this an independent document team? And we can
save that for the retreat. I don't know what to make of the poll the way it's
looking. Maybe it's not updating. Three people responded and those three people
responded yes, no one said no. And I think that means nine people didn't say
something. Mike, can this be serviced by some creative scheduling constraints
during the meeting week? Does that get us most of the way? Do you want to talk
to the chairs about whether that's helpful? What helps you?

Mike: I think I still consider that to be a fallback position. If the IESG says
they cannot hold an interim meeting, then we talked about some amount of
workshop time plus, plus meeting times during the week. I share your confusion
about how to interpret this poll.

Roman: We just got a bunch more responses. It looks like it's half and half
right now, yes and no.

Erik K: I was gonna comment about your update to the IESG statement. In
general, I'm in favor of always having leeway. Categorical policies are seldom
sustainable. Obviously they must not during the meeting, I think is fairly
defensible. But giving ourselves the option to approve for exigent
circumstances that's a power we should attain.

Roman: That's my position. And in terms of the words, that's why I included a
new set of words, which was to schedule during that time that would take the
whole IESG, the same way we're doing it, to provide a little more bounds on
this.

Paul: I have a clarifying question. This is not really an interim meeting of
like an hour, right? This is a whole day or something?

Mike: Yeah What we did in Brussels was two full days and one half day. The
proposal here is two full days Thursday and Friday.

Paul: I think that rules we kind of set out for meetings in these weeks,
they're sort of more aimed at a one hour meeting, and now you're preempting the
IETF working group meeting. I don't think we really meant to exclude things
like people getting together for two days and hacking on things. Maybe we
should look into that angle a bit more to see that this is something different.
This could be just a bunch of enthusiastic people getting together and working
for a couple of days.

Mike: Moderated by the chairs.

Paul: Well, you could not do that.

Roman: Again, what I'm seeing is the IESG is split on whether to approve that.
And I think, based on my interpretation of how we run things, that means that
this is not going to get approved. And what I heard was a bunch of suggestions,
how can we squint at this? And that might be a redefinition of what is a
meeting, which is what you just said Paul, to workshop, which I didn't fully
understand, and a couple of other things.

Paul: For instance, the IPsec workshop that happens the two days beforehand is
a lot of people getting together, and there's no note well or anything, and we
might work on things we just like. Obviously don't do things that aren't
allowed, or that would be strictly IETF activity. So I think that that sort of
solution could work fine for others too.

Erik K: I wanted to ask a clarifying question on the poll. I interpreted that
to have a parenthetical in this particular case for the specific thing, not in
the general case. I don't know what Mike meant when he put the poll together,
and I don't know if that colors people's responses, whether they think they're
answering in the general case or answering in the specific case.

Mike: I'm approaching it that if we had a leeway that said a vote of the IESG
can approve under exceptional circumstances, would that vote pass? If it
wouldn't, there's no particular urgency about giving ourselves that leeway. If
it would, there's a procedural question of how we would open that up.

Erik K: I don't know if that changes anyone's answers. Thank you.

Roman: I'm short on ideas of how to recalibrate this; we're at an impasse.
We're about half and half; half of the IESG appears to feel uncomfortable
approving this with the constraints we have. Alternatives I heard were try to
re-scope this as something slightly different, or redefine the categories of
what's allowed based on different definitions of how the meeting would occur.
Like how Paul said, we weren't talking about long running, multiple day
meetings when we wrote that.

Paul: I'm also wondering if it's an official IETF activity the Friday before
the meeting, you would get conflicts with people who would want to go but who
are on an airplane towards IETF and cannot attend, which is exactly why we
don't do this. I think that leans toward it being not an official IETF activity
if it's that close to the IETF.

Roman: We've gotten very specific feedback about the exclusivity you create
when you have a meeting cadence which does not allow people who would normally
come to the session to follow along. Anything else to talk about on this?

Andy: This may have been said already; are there meeting logistics they need
like Meetecho? Is the plan to run it like a WG session? In the chat it was said
this could be a hackathon, and Deb said they could just meet at the [IETF]
hackathon. I'm curious if that would solve the problem?

Mike: I don't think by itself. The plan was to run it like a WG session;
discussion of issues and with adopted documents. We did have a lot of good
discussion from the meeting last week; we were using Meetecho. What does the
workshop look like if we schedule over Webex? There are ways around that, so we
don't necessarily need to have the infrastructure, it just feels weird to say
you need to get your own infrastructure.

Andy: They are going to be doing IETF things then, like trying to approve
documents for adoption?

Mike: Or work on documents that have been adopted, yes.

Andy: I feel like work on documents that have been accepted is different than
calling for adoption. In my opinion if the chair is running the session and
acting like it's a WG, it's a WG session. If it's just a bunch of people in a
hallway working on documents, that's different. Does that make sense?

Mike: Kind of? It wouldn't be a hallway, but if it's a bunch of folks in a room
moderating a discussion, who's moderating?

Andy: I don't know if that was a helpful set of questions, but if a chair is
going to be making decisions or announcing things, there's no way around it;
that's an IETF meeting. If there's not, then we have some wiggle room. That's
my opinion.

Mike: Formally, things the chair decides have to happen on a list, so nothing
that happens in a room is [official].

Roman: The closest analog I can think of is side meetings, where we used to
have a problem with some WGs convening side meetings for additional meeting
time and the chairs run this side meeting about documents. We've previously
said that's a no-go. I'm sensitive to time and we still have an exec session,
so we still need to think about how to help the WG.

Mike: Thank you for the input.

Liz: We have some executive session topics; does anyone have any other business
before we move into executive session? [Silence]

6.6 Executive Session: RSWG Chair Appointment Process

This topic was discussed in an executive session with IESG, Secretariat, and
the IAB Liaison.

6.7 Executive Session on BCP 83

This topic was discussed in an executive session with IESG, Secretariat, and
the IAB Liaison.

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