**Session Date/Time:** 23 Jul 2026 14:30

[00:00:53] **Mahesh Jethanandani**: Alright. It's time. This is the ops area meeting. I wanna thank oh, sorry. I'm Mahesh, and with me, my co ED med. I wanted to thank, Thomas and Shafang for taking the minutes for this meeting. But please join them in especially if you're speaking at the mic, just make sure the notes that are captured there are reflected correctly. And this is the note 12. I'm gonna leave it up there for you to take a quick look at it if you have not seen it till now. Alright. Did I lose I think I need If you're here, make sure that you sign in to the MeetEco session via the data tracker. Of course, if you're in the room, you're recommended to use the MeetEco Lite client, especially to join the queue and show hands if a poll is ever taken. If you are using the full client, whether here or remotely, make sure that your audio and video is off. Because if you are remote, headset is highly recommended. Now it might be obvious to people that the queue should reflect the person who is actually speaking, but it's not a problem if you just state your name anyway so that we make sure it's the right person. With that, we have the agenda for today. Does anyone want to bash on this particular agenda?

[00:03:20] **Med Boucadair**: Yes. Thank you, Mahesh, I would say, for the introduction. So as may see in the agenda, what we privilege this time is the collaboration and the coordination with the various areas of EndoTex. There's a first one which will be related with the our report about our workshop which is done by the IAB and this is related to some of the work which is done in the OPSA working group about the geofeed and all of the extensions there. There is a bench of work which is related to the work with Quick, so this is mainly to coordinate with the transport people in the area. There is another bench of work which is related to the extensions of the ICMP. So this is also to coordinate with the work done in Internet area. And there is the coordination with the IRTF and the work which is done there and how we can help, I would say, the transfer of some of the work from RTF to the ATF. And then there is a discussion that will be led by Job about whether there is a need that we have a consistent policy on the implementation. So this is something we have done recently when we chartered SIDROPS. This is also something that we covered when we discussed the charting of IPPM. So this is to have your feedback, I would say, from the whole committee whether we need something consistent in the area. So with that, I think we can move to the next slide. News. We have appointed new chairs for the TDD. So thanks to me, thanks to the volunteers. We were obliged to, I would say, to discuss some of the candidates, but we have to make that choice there. Yes, so feel free to contact them and if you have any proposals, I just know how you want to that we'll run the TDD, so just let them know. This is something that we are currently considering to create a new directory for the RPKI. So this is a work which is spanning multiple working groups. And the hope is that we ensure some consistency in how we are doing these extensions and that work. There's already a call which is using the setups about the reviewers and also the comment on the scoping. Again, there's a link there. Please feel free to share any comments you have on that part. Yes, ops consideration matters. Will let yeah, you can the one you want. Come here, Joe.

[00:06:42] **Joe Clark**: Joe Clark talking about, RFC5706bis. This is an ops area working group document. We've been fortunate enough that MED has shopped this around a lot, and it has inspired several drafts even though this is still not even through working group last call. It has inspired several drafts to include an operational consideration section. We're very happy about that. But right now, and we realize that you're here, you're focused on IETF one twenty six, if you could take some time to review this draft and provide comments on the opsawg at IETF mailing list, We'd be very grateful. So far, Chin has gave us some comments. We're gonna work on those. And Paul Aiken has had his Claude bot look at this, and we've provided some fixes there. But we really want to see this move forward. We think this is going to make a lot of new protocols and protocol extensions highly implementable by operators. So thank you for your attention.

[00:07:41] **Med Boucadair**: Thank you, Joe. The next item that we wanted to provide some reminders and some pointers there. So as you know, there is a lot of discussion about the EI, a lot of side meetings, a lot of discussions, and so on. So there's already one mailing list that we have created for this purpose. It's one year right now. This is the, I would say, if you have a proposal or any discussion that you want to relate to that matter, yes, please use that mailing list. In the same time, we have another repository which is community driven in which, I would say, the committee is organising the material, the drafts, structuring them and all the initiatives that are related to the AI-NETOPS in general. Since in the last ATF meeting, dispatched from DNSOP the proposal for the discovery of the agents. So that has taken place this week. In the meantime, also this week, were many bots related to DEI. The ops part of it is really important. It's really important to see that focus on that part because if we don't have the understanding of the deployment model, it won't be difficult to specify protocols and the extensions there. During the week, if you have already attended multiple sessions there, the AI topics are present. For example, in ABPM, InMob, SRB6 and others. There is one wiki which is created by Mahesh. I will let him come up.

[00:09:21] **Mahesh Jethanandani**: Alright. So as Matt mentioned, tomorrow, 08:00, there is a side meeting on AI ops. Also, just clarify, AI ops and AI net ops is the same thing. Just a short of name for it. There is a Wiki page that I had just published for essentially providing a guidance and trying to determine what work should ITFP be working on, but that's just a guidance. So if you're interested in the topic, tomorrow, 08:00, side meeting. I think it's a smaller of the two side meeting rooms.

[00:09:59] **Med Boucadair**: Thank you. Thank you, Mahesh. Yes. We have new working groups in the ops area since last time we met. So we have the two working groups that that we that are that were used to be in the art area that we have now in the ops, so Deacon and and REGEXT. And we have a new working group that was chartered last time on SAN. We'll be having, I would say, a presentation from Deacon from Peter and from Jim. But all the updates from the other working groups and their records are available on the material that we provided in the proceedings. So, yeah, please look into those. And with that, I will be inviting Peter to come to the to the floor.

[00:10:48] **Peter Thomason**: Alright. Hello. Alright. Hi. I'm Peter Thomason. I'm co chair together with Hans Joerg Hapel for the DECON working group, which is sort of new. I think we had our third session today. And, yeah. So that stands for Domain Connect. I will tell you what Domain Connect is. It is an application level protocol that's from the charter that enables software service providers to request configuration of required DNS records in the customer zones in order to integrate their product. So for example, when you're an email operator or something else and a customer has their own domain, and in order for them to use your service, they have to put some sort of verification record or some whatever, host pointer or something into their customer zone. You can, of course, display that to the customer and tell them, please go and add this record in your DNS, or you can just use domain connect, which is an authorized way of having that done automatically by the service provider in the customer's DNS zone that's hosted with a different DNS provider. The technology has been existing for quite a while, actually. I don't know how long, maybe ten years, and it has notable adoption amongst both DNS and and software service providers. It was originally specified outside of the IETF. GoDaddy had a big role. I don't know if they started the effort, but, anyway, they have been involved for quite a long time now. Pavel from at the ENIC is quite active there. And the idea is now to bring this into the into the ITF to essentially give change control to ITF. And the idea is to not break the protocol, but make it more stable and don't change it too much. So we value stability and backward compatibility over perfection. The plan is to be done with this in DecemberMarch next year. There's two parts of it, asynchronous a and asynchronous. I will get to that. So that's why there's two milestones. So here's how it would work. So you have example.com. You go to your email service provider email three sixty five dot test, and they ask you to add some stuff, MX, SPF, DMARC, and all that stuff in your DNS. Instead of doing that manually, you can just log in to your email provider and start the setup flow, and then they will do a lookup of _domainconnect. The customer domain. It's a text record there, and that will point to the DNS provider's domain connect endpoint, essentially. And then you get directed there in your browser, and there is, like, a template query parameter or something that encodes whatever the service provider wants to provision in the DNS zone, but it's not arbitrary. It's a template based system that is preauthorized and vetted. There's a repository for that. And then you can log in to your DNS provider and approve those changes essentially, but you don't have to do them manually. There's two ways to do this. One is a one shot sort of thing when you set something up, and there's also things that might need continuous revalidation. So for that, you can issue a token or something. I mean, the user doesn't have to do that manually, but that in effect will then use OAuth, which is the async protocol I just mentioned. So here's stats. So I I estimated ten years. It looks like it's roughly ten years. Yes. This is the number of provisioning templates that has been published. It's about a thousand now, and there has been significant growth particularly this year. I don't know why it has so much traction now. Maybe AI. I don't know. Anyway, so it is what it is, and it's actually time to make this a proper protocol. This slide here is a similar one that says how many service providers support this sort of stuff. So that's roughly 500 now. Alright. Oh, that was it. Okay. I thought that was the overview slide. Other one is on

[00:14:34] **Med Boucadair**: the summary slide.

[00:14:35] **Peter Thomason**: Okay. Okay. I'm done.

[00:14:39] **Med Boucadair**: Yeah. If if there's any question to to to Peter before we move to to Jim.

[00:14:47] **James Galvin**: All right.

[00:14:48] **Andrey**: Thank

[00:14:48] **Med Boucadair**: Thank you, Peter.

[00:15:09] **James Galvin**: Hello. Thank you. I am James Galvin. I'm here with my two co chairs, Jorge Cano and Antoine Verschuren. So we're all here if you want to tag anybody and ask any questions to talk about registration extensions working group. So what's interesting for us is, yes, we had charter update, and I'll say more about that on the on the next slide. But more importantly, we are new to ops area, as Med said early on coming in. And so that was really a primary basis for us to be on the list of bringing an introduction as to who we are and what we do. We've always been part of ART. Our previous incarnation, which was EPP extensions, was also part of ART. So this is quite a difference for us. And as I said, our we have three co chairs, and we're all here in in the room. I will talk more about our achievements and and hot topics on future slides, so this is really the agenda overall. I chose this key paragraph out of our charter, which I'm not gonna read here. I'm presuming you've all read the slides here in advance. What I would say to describe it in one sentence is all things EPP and RDAP come to our working group. That's basically what's what's going on. EPP and RDAP are base protocols. They're already well defined. They were defined to be extensible, and there's a fair amount of extension options that are going on right now in the community. One thing that's useful to call out is the difference between GTLDs and CCTLDs. GTLDs, you know, comnetorg, that whole market of TLDs that are not country codes, we are all those TLDs are mandated by contract to support EPP and RDAP. We conduct our business with these two protocols. And another thing to know is that roughly speaking, CCTLDs and GTLDs each represent about 50% of the domain name provisioning market. So there's a huge installed base for EPP and RDAP in that respect. EPP is the provisioning protocol, so that's the way that registries and registrars communicate with each other to register domain names, set their DNS records, and other kinds of things. And RDAP is a fairly straightforward but full featured query response protocol for getting information. In this context, it is used to be a replacement to who is. Who is was quite simple. Give it a string, just dumped a bunch of text at you. RDAP is a very full featured query response protocol for asking for information, getting it back, and it's applicable to a good deal more than just domain name provisioning. And we'll see that in a moment. The other call out I wanna make is REGEXT is not the RESTful provisioning protocol. That's RPP. That's a relatively new working group, a little over a year or so. There's a fundamental technical difference, of course, in that EPP is XML based and RPP is JSON based. But other than that, RPP had always offered as a stated goal that they would provide a means for mapping back into EPP. For those who wanted to support RPP, they would provide a a gateway backwards for that level of support. But RPP is, in a sense, kind of a next generation provisioning protocol that's used today primarily by CCTLDs. GTLDs don't do this, again, in part because they're mandated to do the other. So there's a whole set of other work that has to go on in order to motivate using RPP, the GTLD market. I put up this list of publications. This is the set of things that we have published over the past three years. And I put it up here. The takeaway from this is to realize that RDAP in particular is not specific to just the domain names. In fact, if you look at the first thing up there, it points out that RIRs actually use RDAP. In fact, it was the RIRs that first proposed the creation of RDAP as a replacement for Who is. And RDAP has, you know, since grown to a number of different things. It provides geofeed data, provides various kinds of searching data. It also provides a redaction ability so that you can support redaction policies if that's important to whatever it is that you're trying to reply to the request that you're coming at. So there's a lot more going on there. Things that have extended EPP include things like our internationalized email addresses. For those who are deep in the email in provisioning for registration systems, EPP, in fact, limits the syntax of the email address. So in fact, it does not allow for the local part to be internationalized. And so this was an extension that's been added in order to to achieve that particular feature. So things like that come to us when we get along. Although we don't tend to have a lot on our milestone list, and we're a fairly calm and, in many ways, slow moving kind of working group, we do have a steady flow of documents. We have adopted two documents this year, and the other two were from last year, so we don't have, you know, a lot of new material coming in. But stuff that comes in typically has some level of importance, consideration to somebody. The top one up here that was most recently adopted, the domain variant support, For those who pay attention to IDNs, the important thing to keep in mind is IDNs, especially in the provisioning sense and in the EPP context, are singular objects. A name is a singular object. So EPP as a provisioning protocol deals with single objects. IDNs introduce variants where you have a set of names that are equivalent in some dimension in the script or the language in use. And EPP does not provide a way to manage the provisioning side of that. I wanna emphasize that's a provisioning side, not doing not having anything to do with what happens on the DNS side. That's a whole different thing. Those of you who've been around DNS for a while know that that's been its own issue over the years. So but this is some of the work that's in front of us. Because we are relatively slow moving, we have an operational practice of dealing with one document at a time. And so we actually have a list of pending documents waiting for some other things to move along on our docket, on our milestone list so that we can continue to move forward with some interesting documents. And then the last thing I wanna get to is some of our hot topics. These are the things that are going on right now that are kind of important. RDAP extensions is kind of a big deal. There are IANA registries for registering EPP and RDAP extensions. We have found via our operational experience some various ambiguities and missing features that are important to maintaining that registry. We already recently published the EPP registry update. And this RDAP extensions document, which is currently in progress, which we hope to get out the door soon, is getting into clarifying ambiguities and adding some additional requirements to the IANA registry so that we can better manage extensions, especially standardized ones, so we can make sure to cover interoperability and avoid duplicates and things like that. We do work on EPP extensions, transports, RPP. Well, only RPP in the sense that we we track what's going on there. Sometimes we have an influence there. They need to track what's going on with us. We recently had an EPP over QUIC document that came forward. This HTTP, There's an EPP over HTTP document going on. RIR interest remains strong, which I think is important. No. They were one of the original motivations for the creation of RDAP, and they are actively involved in our group, as I pointed out with some of the RFCs that are already there. And the same entity set, which was previously variant support set, is really kind of a big topic which has just opened up in the working group and a new thing. For those who pay attention to IDN domain names, the issue going on there is obviously registries would like to support and allow at the second level variant domain names. Right now, at least in the GTLD space, there's no support. There's no policies that allow variants. There are a few CCTLDs which have made their own solutions and done things. So this work is about standardizing and creating a standard, interoperable standard in EPP to ensure that we can manage same entity doc same entity objects, which would be domain names that all belong to the same owner. And that's what that means to be a same entity. And I think that's it. That's my last slide. So those are my topics.

[00:24:41] **Med Boucadair**: Any question to to Jim? If not, then thank you Jim for the clerk presentation.

[00:24:51] **James Galvin**: Thank you.

[00:24:54] **Med Boucadair**: So next, we have Tommy.

[00:25:27] **Tommy Pauly**: Alright. Is it working? Hello, everyone. I'm Tommy Pauly, and I'll be presenting a report from an IB workshop that happened. Some of you may have been there, but the wonderful chairs of this group asked that we could share this with this community since there's a lot of overlap with operations for this work. And I think as you listen to this, please keep in mind your thoughts about how your communities, etcetera, could engage here. Some of the stuff I wanna end on and get feedback on is what you think are some of the right next steps for engagement and what this community can do around this topic. So this was a workshop that the IB convened last December, and I I got to chair one of the sessions for this. This is a three day workshop that we had. It had a really good amount of interest and involvement. We had 67 people there on a virtual workshop, and we had three different days all trying to look at the state of IPG location both within standards and the industry and trying to look at what are the issues and where is it going. So we had the first day trying to understand how is IPG location currently being used. We had a second day to talk about all of the different gaps and wishes people have or the problems they saw, and then we spent the last day talking about what are the future directions we imagine in the space. So to give some background on why was the IAB discussing this, the IAB is the architecture board, And this is one particular piece, but it has a lot of architectural implications. It has a lot of deployment implications. It has a lot of operational implications. Overall, we had a lot of people who gave input to the workshop, and I think a lot of us agreed that fundamentally, an IP address is not necessarily designed or intended to carry a geographic meaning. That's not its purpose. It's not a physical address. But in the way that things have evolved, geolocating an IP address is extremely widespread as a practice. That level of relationship is baked into so many systems at a very deep level that it has become part of the architecture to some degree whether we like it or not, not unlike NATs. So we first looked at, you know, what are all the reasons that geolocation is used. We try to enumerate them. This is some of them. If you read the workshop report that is published and should soon be finalized in office RFC, you can see the full summary we had there. There are a number of use cases that are all about optimizations, cases where we either web servers or network elements are using an IP geolocation mapping to determine the language or regional settings that a user should see to identify relevant nearby content, the classic find a pizza shop near me thing, as well as doing things within CDN networks to pick the right DNS answers to optimize the network routes and server selection. But there are also a number of things that IP geolocation is used for that are more about strict requirements or enforcement. So a lot of use cases came up for legal requirements. Are a lot of things now being discussed for age verification, etcetera. There's a big relationship and overlap between those discussions. IPG location is used to ensure that contractual requirements are being followed, And it's also used for locating where users are for disaster release, law enforcement trying to track down where someone is. So there are many different implications that are all baked into trying to figure out what is the location of a user that's using particular IP address. And when we looked at the current mechanisms, so we do have some RFCs in the space. There is a independent submission stream document eighty eight zero five that defined the CSV geofeed format. There's RFC ninety six thirty two that adds more information about discovery and authentication for that. But there's really very little overall that's actually in standards, in ITF standards that talks about this compared to how widely it is used. And we were lucky to have great representation at the workshop from GeoIP providers. These are services and companies that offer their own mapping information, other databases. They aren't just using the GeoFeed formats. They're adding a lot of other metadata to IP mappings. They have notions of confidence in the location. They have notions of reputation or types of devices that are behind IP addresses. But overall, even with these proprietary mechanisms, we found that overall, the current mechanisms that we have both in standards and these GUIP provider services, they often don't really reflect the reality of how addresses are used, particularly the fact that a single IP address doesn't always map to a single location. It doesn't always map to a single user, that there's many many to many relationships going on here. And there are a lot of downsides of having assumptions about IP address mapping to a particular location. As the workshop step back, even just trying to understand what does IP geolocation really represent, we uncovered that there are multifaceted perspectives here. Sometimes the claim about IPG location is assuming that it's about a physical user location, about where your actual eyeballs are when you're on your laptop. It can imply the network egress location. It can imply the network infrastructure location that you're going through. It can also be something tied to your regulatory jurisdiction that you fall under. We we have these geo feeds, but we don't have a common interpretation of what those things mean. So going through our second day, we had a whole list of gaps and issues. You can read more in the report, and we have you can read all of the contributions that were made to the workshop. There are many privacy and security issues. This is stuff that has come up previously in the IETF. There's a g whole GeoPriv working group in the past. But, generally, when we bring up IP geolocation, issues with privacy and and security come up. This is an implicit signal that you are providing to anyone who is watching your traffic or receiving your traffic that is potentially indicating your location without any way to control consent of that information being shared. And so it's often used for targeting and tracking of users even though it's not always accurate. There are issues that people have with the GeoFeed format itself not being expressive enough, and there are a lot of desires to be able to extend the format that is in RFC eight eight eight zero five and make it more clear or more reflective of reality. There are deployment and ecosystem issues that came up. Oftentimes, if you are updating a geofeed, it takes a long time for that geofeed to be ingested by people who are using it or go through many of the chains of a geo IP service provider getting to the website, getting the updated version of the database such that it can take many months for a change in a geo feed to be reflected universally. And so that really slows down the ability to start using new IP spaces. And then there are some just inherent issues around the nature of location itself. How do you represent something when a user is crossing a border or near a border between different regulatory regions? In that case, a slight inaccuracy can have a really big effect on the meaning of that IP address and how the user's traffic is being treated. So, I guess a lot of downers there, but we are also looking at ways that things could change, ways that things could improve. And so wait. Why would people working on this space be incentivized to change? So we recognize there are some cases where just the geofeed formats, they have gaps that can be improved. There are a lot of other cases where we see new network deployments that are stretching the assumptions that people had about GIP mapping. Specifically, we discussed a lot about satellite networks and Starlink and how those IPs have different properties than more static ISP networks. We also have privacy proxy networks that are intentionally trying to reduce tracking while still representing a user's geolocation. Those pick particular interpretations of what GIP means. There are also regulatory requirements, particularly around age verification or making sure you're in a particular jurisdiction that are adding pressure to GIP systems to make sure that they have the right answer. And, also, I think just generally, we see an increased bar for security and privacy and expectations people have around that adding get more pressure to this system. So we talked about a couple directions for possible changes. Some of them are smaller, more pragmatic, a number of things that we could do to update and maybe fix some geofeed formats to enhance the details of metadata there. Probably worth doing. But we also discussed ways to build new mechanisms to replace static assumption about a geofeed with new signals that are generally going to be explicit. So in cases where people need to check what country you're in or what language should this website be represented in, that those could re start relying on more explicit signals and not just based on nonconsensual implicit signals based on what an IP address is seen as by a server. Overall, one of the big takeaways we had was that geolocation is not going away. It has been really deeply baked in to so how so much of the Internet works. But we do have the opportunity to work on some better designs for the ecosystem and try to come up with more explicit mechanisms to solve these problems rather than just hoping it will all work out. Okay. So what are the next steps? And this is where it'd be great to get some input and thoughts from you either here or later. We had a lot of engagement from many stakeholders in this workshop. They're not normally coming to the IETF meetings, but we think that in order to continue improving this area, we need that continuing engagement across the stakeholder groups. So we wanna have regular conversations in how to evolve that space. So I think there are open questions of what shape and what venue we should use for such discussions. And my question to you here is, you know, what can the ops community and the various venues that you are in do to help drive discussions or improvements in this area based on your perspective. So that's it for me.

[00:38:13] **Lucas Pardue**: Are there questions?

[00:38:23] **Mahesh Jethanandani**: Any particular working groups that have shown interest? Any particular working groups that have shown interest?

[00:38:31] **Tommy Pauly**: I don't think this is a thing where there's a clear working group home for

[00:38:35] **Job Snijders**: a lot of them.

[00:38:36] **Tommy Pauly**: Like, we no longer have GeoPriv or some of those other groups like that. And often, we've seen, like, the actual GeoFeed specs. They've been done somewhat outside of particular working groups. They were independent stream, etcetera. So part of this is a call for we need to have some venue where people are thinking about these issues and that there is a space where we can invite people people from outside the ITF community to engage with this

[00:39:03] **Eric Vyncke**: community. Eric. Hi, Tommy. Eric Vang, Cisco. And, also, responsibility for a group is called Tip Top. So at the planet, was there any mention of getting the same services, I mean, outside of the Earth? I know it's some awfully you know, mostly Friday. Right? So

[00:39:25] **Tommy Pauly**: Yeah. I mean, I that that I don't recall if it did come up at all, but I think, you know, the closest analogy is gonna be looking at how, the Starlink satellite networks, etcetera, are working. I think, overall, that is, yet further challenge to the status quo assumptions that are baked in. So I think it it is very much in keeping with, if not, you know, many further steps down the line of, yeah, we need a better approach for this if we're gonna have a reasonable look behavior for geolocation. Yeah. Thank you. Thank you.

[00:40:05] **Ondřej Surý**: Andre. Hey. Andre. Thank you for your presentation. I just wonder because I heard Starlink a few times, but I have much more, like, ground bound issue every time I visit different country with my mobile phone because the mobile data is tunneled to the home country and are from the same pool of addresses as the home users, apparently, at most carriers. So is there even, like, anything that can be done about this so I can visit local local resources while roaming abroad with my phone? Right.

[00:40:36] **Tommy Pauly**: Well, and, like, I mean, the as we discussed, the I, ITF, networks and how they interact. Like, right now, everything I'm getting is for Spain, and that's a whole year old. So, yeah, there was a lot of discussion beyond just satellite networks. I think satellite networks came up because they are more novel and challenging in the other extreme ways. But, yes, like, just traveling or changing location or having a network move its location or being doing roaming. Those are all things we've been living with for quite a while that show the fragility of the geolocation mappings and the services that are using them.

[00:41:19] **Mahesh Jethanandani**: Thank you.

[00:41:24] **John Scudder**: John. John Scudder, thank you for this. Yeah. You're sort of you the talk about kind of the nonconsensual nature of the information that I'm providing and then later sort of the, well, we don't really have a working group that's working on this stuff right now, has me thinking about at the IETF, we kind of try to spec mousetraps. I I it's not at all clear to me that we can spec a mousetrap that is better enough that it will cause the world to beat a path to our doorstep, which is probably why we're not working on it. Like, do do you have or did the workshop develop any insight into, like, what actually has to happen to motivate people to move to something better? Does everybody just have to turn on private relay and make geolocation completely useless?

[00:42:22] **Tommy Pauly**: You got it. No. I mean, that going back, you know, here, these are some of the things we discussed are, like, why do people care? Like, is why is it not just, like, a bit of an annoyance every time you travel? So I I do think there are cases where we see increased friction and increased motivation in that. Partly, it's Starling, partly private relay stuff. But I think also one of the things that may be a big motivation in the space is the regulatory aspect as there are many more laws coming up that are trying to require certain things that are very different across very different jurisdictions that it is higher stakes to get it right. And that's points to something that shouldn't be as implicit, as spoofable, as accidental as getting this from the IP address only without any other verification. So I think those are some of the pressures, but I think that is still there there is a onus upon this community to actually do something to present something there. Otherwise, there will likely be solutions that people come up with that are thought through in a different fashion.

[00:43:36] **Med Boucadair**: Thank thank you. Thank you for getting

[00:43:37] **Eric Vyncke**: Thank you.

[00:43:55] **Per Andersson**: So my name is Per Andersson, waiting for the slides. Presenting Foo over QUIC. So the operational considerations when using QUIC as a transport protocol. So we had maybe it's in the slides, actually. Next slide. I know. I know. Tried that joke before, but it actually didn't work.

[00:44:21] **Lucas Pardue**: Sorry. Sorry.

[00:44:24] **Mahesh Jethanandani**: Okay. It's yours.

[00:44:30] **Per Andersson**: Super. So introduction. Ahmed identified that several protocols do over quick transports, probe the interest for discussing operational considerations in the ops area. And we had two discussion calls that were announced running up to the this meeting. What's the range for this thing? So the presentation outline for this one, preamble requirements, operational considerations, examples of issues, some opportunities with QUIC, guidance, there should probably be a question mark there, and next steps. So our preamble. So there are several protocols that are standardized to run over QUIC. What opportunities do we have with QUIC that we don't get with TCP or UDP? And what are the operational considerations that is for us to think about? Benefits, difficulties, difference with the other protocols? Requirements that were discussed is that operational protocols have the must is ordered delivery. And other than that, integrity, confidentiality, authentication might be different depending on where you are in the stack. So it's a different different requirements between control plane, management plane, data plane, telemetry plane, and so on. So operational considerations. Might be easier to solve it with QUIC than bolting on stuff with TCP. For instance, authentication and encryption instead of running TLS, get we get that automatically with QUIC. One opportunity. So what other benefits do we get? What is common? What issues are there with using QUIC instead of something else? So it's not, as you probably know, not a drop in replacement for TCP. There are larger and more considerations for QUIC than there might be with other product lots of knobs that turn in tune. For instance, who initiates the con connection and so on, and some things are hidden by the protocol. So can we create a quick profile that makes this drop in replacement easy was the question that's raised. Congestion control is an operational consideration. So new Reno and Cubic is discussed in RFCs nine thousand and nine thousand and two. B r r BRR is also used. Might be interrupt issues with this. There are QUIC cubic is quite different from TCP cubic. I won't go into the details here. We can circle back to that if that's interesting. Quick interoperability is also something that is interesting. There is discussions in r c eighty nine ninety nine. It can be different between different quick stacks. And a great quote from one of the sessions is that interesting issues will arise from stack to stack interrupt. Another operational consideration or more is that need a simplified firewall story. QUIC might be able to solve some of that. Routers implement control plane policy. So how how do we allow traffic during a distributed DOS event? And some implementations peek into the traffic, which is not possible with Quich since it is encrypted. And some implementations require snooping and and transport injection again, similar to TCP dump with a key log file for TLS. More operational considerations. QUIC is a connection oriented reliable transport. Streams are reliable, but RFC ninety two twenty one defines QUIC datagrams, which are then unreliable datagrams over QUIC similar to UDP. They are congestion controlled but not flow controlled. Yes. So it was discussions about compatibility matrix. So the this connection oriented versus connection less, control plane versus management plane, data plane telemetry, and so on. I said this this before. There can be different settings per connection. So how is that manageable? Is that something that we need to take care of? Different peers can have different settings as well. There's the alternative service indication in HTTP and HTTP two. If you have this is something that was raised as well, rate limiting or policy and security mechanism. So what was typically needed to be done was to limit BGP ingress or limit the BGPPU sent to an implementation. How is that possible? Yeah. And the firewall and TTL story again. So we'll skip this one. Something that I've seen a lot is that for TLS, but also for QUIC, is that zero RTT connection in it is disabled because it has a weaker security profile, so you have to understand what your needs are and when you want to use it. So example of issues. We've heard this before, head of line blocking overhead for telemetry for TCP. My favorite slide. UDP, there's no guarantees for delivery or order. And there are several ways to solve TCP out of line blocking, sharding h e p two with streams and so on, but you still have the out of line blocking for TCP. And QUIC solves this by using streams. QUIC is always encrypted with TLS 1.3 integrated in the packet, and you need similar there are similar operational issues for a quick as for TLS when you're doing debugging and traffic introspection. In NetConf and RESTconf, can do call home. So, basically, you have a TLS socket that you open from one end, and then you do a TLS session on the other in the other direction. This is difficult with QUIC, and we haven't figured out how to solve this. There it was some work in there was a buff, I think, p t t h. I couldn't be there, but that might be interesting to look into. So the a bunch of random ideas about how you could solve it. Another thing, operational consideration with QUIC is that there's no standard API like the socket API. Each basically, each implementation has its own API. There is r f c ninety six twenty two, which has an abstract API for transport services. Is that something that can be used? And one quick stack is known to have implemented. Another issue is that it's not implemented in the kernel. That might be an opportunity as well because you can do faster deployments and can upgrade without rebooting the device and so on. On QUIC, you can run then several application protocols over one connection, but you need some kind of then accounting for the pro protocol stream mapping. For instance, if you're running h three and NetConf, you would need to know which stream goes where. Otherwise, you if you do a bad implementation of this, you might end up with head of line blocking anyway. Connection migration is something that could be an interesting opportunity where you move a connection but still keep it live. Have granular flow control both per connection and per stream. And I guess this is where it gets interesting instead of my boring reading of the slides. What are we going to do with this? Do we need some guidance for this? Should it be an informational RFC? Should it be a Wiki entry? There are there's already RFC ninety three zero eight. Is that enough or not? Should there be an assigned port? It's another thing. And it has been discussed in the RegEx TPP quick that if there is already a TCP port assigned for the service, before, I think, RFC sixty three thirty five, you also got assigned a UDP port. And if that's the case, just reuse the UDP port for for quick. So next steps. Should we do an interim? Should we create an informational RFC? I was at the WIT area and presented this not in 34 slides, but in one slide. And they had a similar discussion about should WIT area bring together some kind of guidelines or checklist when you do an in a protocol implementation over QUIC. These are going they are going to do that. So should we start something as well, or should we wait for them? I know that several of them are in the room. And before this meeting, Benoit and coauthors released this telemetry over QUIC with operational considerations for telemetry protocols over QUIC. I think that's a good starting point for discussion. Yeah. I think that's it. Questions or discussions?

[00:56:19] **Kent Watsen**: Hi. I'm Kent, author of r c eighty seventy one, which is the NetConf, ResConf call home document. The last couple of IETFs, I've been trying to figure out how to reverse the quick connection and have pretty much tapped out in terms of interacting with the QUIC community and enabling that a possibility. Partly, I mean, the protocol blends the transport and the security layers, which makes it very difficult, but also the willingness of the working group to take up the work. I think they're mostly interested in using QUIC for HTTP purposes. But I've been interacting with Lucas, who's one of the co chairs of QUIC, and he guided me to a couple item documents that turned out to not really provide much help. I then asked him, well, could I, you know, ask AI, you know, to suggest a solution? Because I'm not a quick expert. But if it suggested something that's plausible, and I presented it and it seemed okay, take it to the next level and and, you know, something. Actually, so I did that last night, and it gave me a pretty good answer that I think is plausible. The answer I got was one that I think is only feasible for if we were to do an eighty seventy one biz, so updating the NetConf, ResConf call home documents only. It wouldn't be generally reversing quick. It'll only be reversing quick for those two specific use cases. I think the question or the open item I have here is would that be sufficient? I think it is because my understanding of the use case is kind of the zero touch scenario. The device is deployed behind a firewall that only allows outbound traffic. That out that initial connection that's happening from the network element is the management connection, but then immediately after, the controller can push down credentials to the network element that would allow it to initiate outbound quick normal quick connections, for instance, telemetry. So I think just reversing that initial management connection is sufficient. And if so if that's seem seems like the right approach, I'll pursue it with the eighty seventy one biz.

[00:59:00] **Per Andersson**: That is interesting for that particular work. I think for this work, we need to find something bigger scope instead of going in detail. So maybe categorizing into control management data and telemetry planes and see what are the requirements that we have there. Yes, Benoit. I think

[00:59:25] **Benoit Claise**: so Benoit, so I attended also the the WITS open area meeting where Lucas and and you you presented, and I was happy with the the conclusion that they're going to provide maybe not a guideline document, but a wiki with a checklist, which is even better for us because whenever I see the numerous draft, which our management flew over QUIC, we all have the same questions because you're not QUIC expert. Is this like route initiated? What do I do about zero RTT, data streams, or etcetera? Now I was happy with that already to provide

[01:00:03] **Per Andersson**: Oh, okay. You moved place.

[01:00:05] **Benoit Claise**: So I was happy with that already. Now for network management, the last route that you mentioned there, we had the specific scope for that. It was push based telemetry, router initiated, UDP based. So for us, it was easy. Now if you look at the full guidelines for network management, we're not specifically special except with one criteria, which is the one you mentioned. It might be difference if it's data plane or management plane or control plane. In our call, we had this clear distinction because you are people are coming from different part even if it's ops. That's gonna be the main difference I see and the main guidelines, which is ops specific.

[01:00:51] **Per Andersson**: I think that's the level of guidance that people need as well to have, like, oh, I'm doing control plane protocol, then I need to think about these things. And there are UDP guidelines when you do these things, but there's nothing for QUIC yet. So looking forward to the WIT area.

[01:01:06] **Benoit Claise**: On top of the the Wiki done by WIT or at the same place, wherever. Yeah.

[01:01:16] **Lucas Pardue**: Hey, Lucas Pardue. Woah. That's loud. I was name checked twice, so I felt compelled to come up and say hello. I don't typically come to the Ops area, so I'm I'm glad to be here, and thanks to those folks who came to wit. The more we talk, the better things can be, I think, even though in, say, the quick working group, have expertise or we have experts. It doesn't mean we have expertise in these particular kinds of questions because they haven't been asked to us before. So it's really good. You know, we spent some time just having corridor conversations. If you speak to an individual, they might be like, oh, I don't know. I don't have to solve that problem for you. But we can get some pointers. And I think some of the complexity in those responses are even within the quick working group, we have people who are particularly fond of the application layer or the transport layer, like the congestion control stuff you talked about, or the security model. And it could be that if there's something around, say, like the reversing of of a property that's needed for a use case, if that was applicable to some other stuff, that becomes more attractive as an extension point to QUIC that would need coordination with the TLS working group to make sure it was satisfying those security properties. Sounds really complicated. It probably is to some extent, but it requires some people to talk. So I would encourage that to keep happening. But with regards to the applicability and like this telemetry draft, think is a good example of by trying to create a common thing, you now create a different problem of abstraction. And and you kind of touched on it as well with, oh, you could mix h three traffic with another thing. You you can't just do that. That's effectively a different application mapping, which would be h three and foo, which would need to address the primary thing of you've got these streams. You you really have to define how they're used, which ones get access to them. You're you're creating like another session layer within that, which is fine, but now you've got a new resource management problem that doesn't exist anywhere else because it's from self creation, and that's okay. But then there's new failure modes that can be created. I posted some of this feedback on the list. I think it's all tractable, And it's those kinds of things that I think are good if there is any venue, whether it's a wiki or mailing list discussion or document to capture because people are going to keep hitting these things. And it's not that it's hard to do. It's just hard to remember to do. So the more kind of checklist or whatever we can do to help people build stuff, the better. So, yep, thanks for this talk and

[01:03:48] **Per Andersson**: Thank you. And you see that so I'm not a quick expert either, so it's great to learn. Yeah. And I think I think having something like a wiki entry or something like that that's easier to edit and live it and have it living would be good because then you have, oh, we learned this thing now. We can't do whatever, or we had this assumption of how it works. That's not true. We'll update it there, that's the source of truth instead of documents and revisions and publication.

[01:04:17] **Med Boucadair**: Thank you. Thank you, Trevor. Yes, Gauri. Yeah.

[01:04:22] **James Galvin**: Gauri Wittad, who's going to make this wiki known to Med, who will distribute it to you.

[01:04:32] **Med Boucadair**: Ron?

[01:04:48] **Ron Bonica**: Thank you. Bring this down a little bit. Pick it up and hold it. Ron Bonica, Juniper. I'd like to pose a question for all of you folks to answer. And as soon as I pose the question, I'll leave the room so it's not my problem. And the question is, what is acceptable use for ICMP? Well, according to the original RFC, think seven ninety three, Internet nodes use ICMP to exchange control information. Now, the RFC doesn't say too much about what control information is. There's little definition of acceptable use beyond that. And between the time seven ninety three was written in 2007, there was very little work on ICMP. A few messages were defined, for the most part not used, deprecated, and they went away. Things changed in 2007. ICMP became extensible. There was this thing called the ICMP extension structure. It allowed you to add fields to an ICMP message so you could put more stuff on it. And it got used. The first time it was used was RFC forty nine fifty. It was a plate way to put an ICMP label stack on a packet. Was mostly for use in traceroute. So you could trace a packet and see what the label stop stack looked like at the point where the TTL expired. Next, there was RFC fifty eight thirty seven. Again, for use with traceroute. On a destination unreachable message, you could get things like, what interface did this packet come in on? What interface would it have left on had the TTL not expired? Some information about the layer two upon which it arrived. Then later on, we got RFC eighty three thirty five probe. Let's say for a moment that you wanted to ping a interface, but that interface was not reachable to you. You could send a ping to some other interface on the box, specify which interface you were asking about, and get an answer about the interface that is on the box but not reachable to you. All of this could be done with the ICMP extension header. Well, as we realized we could make ICMP messages extensible, we found more and more uses for them. We missed a slide here. Ah, yes. Slides are slightly out of order. We have an explosion of uses for the ICMP extension header now and ICMP messages. These are all Internet drafts that are on the table today asking all sorts of questions using ICMP. What's a node's ID? How much power does a link consume? You know, you name it. And now the question is, what kinds of things we'll go back a slide. What what kinds of oh, actually, I should talk about this slide. A few years back, r f c seventy two seventy nine did a first cut at an acceptable use policy for ICMP. Somebody tried to use ICMP as a routing protocol and we knew that that was not a good use for ICMP. So this was a good start, but it didn't anticipate all the use cases that we see in the ICMP explosion today. One thing we're seeing in the ICMP explosion today, draft XPM into area ICMP query. There are two messages, a generic query and a generic response. You can ask a question and get an answer. Whenever you want to ask a new question, you create a new object. So you can ask this question and get a response. So using just two ICMP messages, you can ask absolutely anything. You can ask about layer one attributes of the node, layer two attributes of the node, layer three attributes. You can ask how TCP is doing on the node. You can ask if it's got a web server. You can even ask for salacious rumors, although I recommend not doing that. You know, need an need a new piece of information just to find a new object. So there are some operational considerations here. ICMP is the appropriate transport for some kinds of information. But is it the appropriate transport for all kinds of information? The first question is, is there some boundary about around what kind of information is appropriate? Maybe just layer three information? Maybe layer three and below? Who knows? I'm asking the question. I don't know the answer. The next is what kind of transport does ICMP offer? And is that transport reasonable for all types of information? For instance, there are some types of information that are very very static. Maybe they should be registered on a server someplace. You go ask the server and not the node that the information is actually about. So, again, there's a question, what kinds of information should you use with should you use ICMP to retrieve? Yes. You can retrieve absolutely anything with ICMP. But just because you can doesn't mean you should. Also, we should think about what ICMP does. Is it reliable? Is it rate limited? Is it easily spoofed? Is it authenticated? Do you need access control? Is some information more or less secret? More questions about what kind of information ICMP should should give you. So what I'm gonna propose here is that a small group of people come together and write an acceptable use policy for ICMP. First, put a fence around what kind of information you should use ICMP to transport. And second, a fence about around what kind of transport is needed for that information. Do you need something we're not reliable? Do you need something with access control? Do you need, you know, various kinds of things? But, basically, come up with an acceptable use policy. So here, I'd ask this group to come up with a list of volunteers, not including me, and do something.

[01:12:39] **Mahesh Jethanandani**: We have a queue building.

[01:12:44] **Med Boucadair**: Nathan?

[01:12:46] **Tommy Pauly**: Hi. Nathan from Google. I would say that as part of the AUP, it might be helpful if we can also provide guidance on the types of things for which people have tried to use ICMP and maybe what the appropriate alternatives are that they should use, which may also mean guidance to other working groups for how they should be considering those sorts of use cases.

[01:13:09] **Ron Bonica**: Yeah. That would certainly be an input to the acceptable use policy. You learn what's acceptable by looking first at what we tried that isn't acceptable.

[01:13:20] **Peter van Dijk**: Excited.

[01:13:21] **Jen Linkova**: Hello, Jen Linkova. So you invented ex extensions, and now you're regretting it.

[01:13:29] **Ron Bonica**: No. No. No. That was my twin brother.

[01:13:30] **Med Boucadair**: He has on the right. So

[01:13:32] **Ron Bonica**: That was my twin brother. Okay.

[01:13:35] **Jen Linkova**: I'm also very excited that we finally can deprecate BGP and use ICMP for it. On a serious note, it looks like well, and you don't even mention how v six use ICMP for Slack, but I guess it's out of scope. Anyway, I it looks for me that substantial part of the list on your slide was about trying to use ICMP actually for management and monitoring instead of, like, reporting between nodes which are not in the same administrative domain. Yes. So it might be a good start probably to see if management should be kind of out of scope. Because if you're under the same control, you can use better protocols, and it probably needs to be, like, more restricted to Internet. But yeah. I I think it's a good idea, yeah, to start thinking about how we use it. But in general, I do like ICMP being extensible because I'm also waiting for a draft and interior to be done to use

[01:14:33] **Mahesh Jethanandani**: it.

[01:14:34] **Ron Bonica**: But you have a good point. One of the fences we should put around ICMP is who is the consumer? Is it a management station or is it just anybody in the network? If it's management information, ICMP is the wrong way to do it.

[01:14:48] **Andrey**: Yeah. Andrew Chunke. I guess I'm volunteering myself for helping with this work because I think the interesting bit is to understand why the given use cases are

[01:15:00] **Ron Bonica**: coming We have a contract at hand

[01:15:01] **Peter Thomason**: to him?

[01:15:02] **Med Boucadair**: Or they're recorded, Oh, so

[01:15:04] **Ron Bonica**: there's no getting out of it now.

[01:15:08] **Thierry**: To be a c v h tier, Veen, what what what I would also keep a bit more in mind is that for some cases, the extensions are not the purpose in itself, but it's an addition to something that needs to retain backward compatibility. So that kind of drifted out. And another thing that is poking my eye for quite some time is that several implementations do not follow the guidance on how to handle ICMP and how to respond with ICMP. So our most favorite one are the explicit exceptions from the rate limits for, I think, packet too big on Linux Mhmm. Which which can have really interesting interop effects between, like, Linux and OpenVSD, for example. So so maybe also looking at this, like, like, not what do we send, but also how much do we send.

[01:15:55] **Ron Bonica**: Good points, both. Have we got his name?

[01:15:57] **Med Boucadair**: He's Okay.

[01:15:59] **Mahesh Jethanandani**: He's a co author. Hey,

[01:16:02] **Eric Vyncke**: Eric. Eric Ving. Hi, Ron. I like your slide five because it show my future problem as a in Teddy. All of them, I'd like to make a review answer. Right? So me and all of us. Right? Because the ATF last call is just for the community anyway. Most seriously, what can this small group and thank you, Andrew, for stepping forward. Right? What kind of review will be there? You said the title and the abstract. I would really love that they go the same kind of review as done in Wiki Group last call. So seriously reading the text, it would be cool. And also that everyone in the group read all the draft, I'm sorry, to detect overlaps, redundancy, contradiction. I mean, AI is there. Right? So it can be helped for sure. But there's really a wish for me, and they appear like any review. No specific status or whatever. Right? So that's my wish list. And specifically with your new draft, still individual, but let's hope it will move forward.

[01:17:11] **Ron Bonica**: Oh, the XPM draft?

[01:17:12] **Eric Vyncke**: Yeah. We have How much of those can be replaced or reuse it? Mhmm. I think that that would be cool. Talking about your new draft in interior, I honestly am a little bit annoyed when I see ICMP used to make a probe rather than being UDP? Can use this probe,

[01:17:35] **Ron Bonica**: and then you said something I dismissed.

[01:17:37] **Eric Vyncke**: Yeah. So, basically, replacing using ICMP simply to query information rather than using a new protocol, very simple over UDP Mhmm. To probe anything. Mhmm. This could be a little bit better because ICMP sometimes are rate limited and or whether anyways.

[01:17:56] **Ron Bonica**: The question is, do you want the rate limit or not?

[01:17:59] **Eric Vyncke**: Yeah. Yeah. Yeah. So something like that. And then if you allow me to poke you gently.

[01:18:04] **Med Boucadair**: If you can just, let's say, short and Eric, this time.

[01:18:07] **Joe Clark**: Sure. Yeah. I am short.

[01:18:09] **Med Boucadair**: Thank you.

[01:18:11] **Eric Vyncke**: RFC8355Bis. Any news?

[01:18:14] **Ron Bonica**: Still waiting to hear from the other author.

[01:18:17] **Eric Vyncke**: Okay. Thank you. I'm going now. Yeah.

[01:18:22] **Ron Bonica**: Jin, you have this or no?

[01:18:24] **Mahesh Jethanandani**: Okay. Since I'm being rate limited on my comment, I'll just say thank you for offering to get the document started. If even if you don't wanna be the author, thank you for getting the work initiated.

[01:18:37] **Ron Bonica**: Hang on. Let me check and see how long till retirement. Sure. I'll start the scale.

[01:18:42] **Med Boucadair**: Thank you, Ron. Thank you. So next talk, Thomas, please.

[01:19:04] **Thomas Graf**: Hello, everyone. So it's about network management. We have NMOP and NMRG. And I really like this sentence in the NMRG charter, which says, The ITF operations and management area directors are members of the NMRG mailing list and invited to the NMRG meetings in order to ensure free flow of information in both directions and to avoid duplication of work with the various ITF working groups. I think that's right. Quite a hard mandate here to basically interact between the two working groups. And I was looking at the blue sheets of ITF-one hundred twenty five and compared how many community members are joining NMRG and NMOP roughly. It's 100 on each. And then I compared the names and see that only about 36 are actually participating in both working groups. And both working groups are working on network management. And if I go back a bit in time, let's say ten years ago, AI, digital twins, knowledge graphs, large language models, generative AIs. It appears to be topics only on the research side. But going back just to the ops area last in ITF-one hundred twenty five, We had three network operators here on the stage: China Unicom, China Telecom and China Mobile. And they showed us what they are doing in that area. So it's no longer research anymore. So I believe that basically the gap between research and actually operation and applied on this AI digital twin knowledge graph language model related topic has seriously been closed. Therefore, I reached out to the three mailing lists to NMRG, NMOP, and OPS AWG and asked three questions. First of all, are we agreeing that this gap actually has considerably closed? And everybody agreed. Yes. It has closed. The next question was also like, would it be interesting and helpful if the two communities who now obviously coming closer together, actually coming closer together and maybe reviewing each other's work, finding common interests and synergies, the answer was yes. And then when it went a bit particular into topics like what actually could be some things we we we could look into, the answers were manifold. So we had things from Brett like saying, Hey, the fundament of all these things is data. Then we had like other things saying basically, it's not only about, you know, making information models. Actually, we need also data models. It needs to be schema. It needs to be runtime data. It needs to be mappable. Then we had other feedback saying, hey. Why going too much into actually data modeling? It's all cognitive systems now. And then, like, Joe mentioning, like, yeah, digital twin, I think that's good for testing and reasoning in the AI area. And then Singh mentioned, for instance, about AI agent and network management, putting some guardrails into place. And Dan was mentioning, I think we should make sure in the ops area that we are anchoring the AI related things into the different working groups where Alex pointed out, hey. We have basically on the NMOP side, we have experiments, but we don't see experiments on the NMRG sides at the hackathons, so that would be a great way of actually collaborating and working together. Jin And was raising the point on why not having a joint session between NMRG and NMOP, similar as we did recently on also in on IPPM and BMWG. So looking on the whole entire threat between the two communities on the existing documents we have there, there seems to be interest in net network digital twins, in intent based intent based networking, CMAP, Yang related topics, network management, architectures, and knowledge graph related things. And then when we go, like, in specific topics which are currently not in the working group discuss, then we go into the areas we are all familiar and have basically listened to in the entire weeks. It's on AI agents, how AI agents interact with these topics with network digital twins, intent based networking, CMAP, and knowledge graphs. And then also, basically, what's the impact on AI network management in terms of network and service and data modeling. And last but not least, MCP appears to be something which is popping up all over the place and whether it's a suitable protocol for network management or not. Any thoughts on this? Is this something it resonates with you guys? So and I see Joe. Yeah. Go ahead. Yes. Please.

[01:25:15] **Joe Clark**: Joe Clark, Cisco. First, on the digital twin front, this seems to be something independent of AI that is probably ready to move from research to not probably ready. It is ready to move from research. I mean, we we should all be using this as a means to validate behavior. Yeah. Warn all of us. To validate behavior before we deploy in production. Mean, I this seems just like let's do this. Maybe I read this wrong. The MCP so I'm I'm using MCP today. I I I but not between IT I I guess what I'm using it for is a means to get network. So my agent asks for a tool out of MCP, and that tool, that function connects to a device and gets data that's modeled in IETF speak. I get is that what you mean by that? You're not talking about MCP replacing NetComm as an example.

[01:26:12] **Thomas Graf**: No. For me, like, I took just took MCP as an example. Like, MCP was not something we had now for years or decades on the radar on research. It suddenly popped up, right? Now the question is, how should we use it in context of network management? Do we have to do any changes on the network management side? I think that's basically what I've seen in these discussions.

[01:26:38] **Joe Clark**: My early opinion on that is no. It Exactly. We can just make use of the existing protocols, and MCP is just a nice means to interact. I haven't I haven't seen a need yet. Mhmm. Thanks.

[01:26:59] **Thomas Graf**: So there is discussion. I mean, we know there is interest from both sides, and the alternate is basically we just simply ignore it and do nothing. On the other hand, if we start trying to to do some effort in, what can we lose? Well, time, effort. It takes time to to set up a joint session, takes time to find out what's the the interested topics. What what we can gain is basically that we have increased discussions between the two communities. And potentially in the futures, that also documents are a bit better aligned. I mean, Job just mentioned before the digital twin. Right? I mean, we should already use that on the n m o p side, for instance, because it's been discussed on the n m g side since quite a while. And then all these new AI topics, MCP might be one of it, basically. What are the gaps on the ITF side? What do we need to do there to to to go one step more further? So question is, should we do a joint session, or what are the other means where we can basically bring research, but also apply it more closer together? Any thoughts, suggestions? Do you think it's worth a try? Thanks.

[01:28:55] **Med Boucadair**: Job, you have to recap now. Implementation.

[01:29:20] **Job Snijders**: Alright. My name is Job Snyder. For the next fifteen minutes, we, we can focus on running code, which sometimes feels like an underappreciated aspect in the ITF process. In this presentation, I I want to argue in favor of producing running code as part of the standardization process. Because ultimately, what are we even doing here at IETF? Is it resume padding? Is it fame and glory? Or is it trying to produce text that results in interoperable systems?

[01:30:06] **Per Andersson**: Why not both?

[01:30:11] **Job Snijders**: Let's first focus a little bit on what it is we mean with independent implementation. In my mind, independent implementation means that separate distinct groups of people or distinct developers produced a software package based on a singular specification, so a single Internet draft or a single RFC, and that those software packages can interoperate with each other, that they are compatible. So this does in the case of RPKI, this often means that there is two signer implementations that produce a cryptographically signed object and two furifiers and that there is cross compatibility across the four projects. Why I bring up this particular example is to emphasize that with an implementation of a specification, it often is the case that a specification spans multiple aspects of the ecosystem. Like, often, there is a server side and a client side. So if you have just one server at one client, that's a great step towards having multiple implementations, but it's better if a single client can interact with multiple servers and or or a single server is able to interoperate with multiple clients. So when we talk about multiple implementations, we we have to take into consideration that there's maybe multiple roles and that for each role, there has to be some diversity in implementation. So can't you cheat your way out of this and just, you know, use AI, single human, using a single prompt and copy pasting it into multiple models and being like, ta da, we have, independent implementation. I would say that that is not what I'm after. And and we have to be, a little bit careful here because the goal of this philosophy is not to bend the rules. Like, the the principle here is that we produce high quality specifications that are of such quality that even an AI could take the Internet draft and produce an interoperable implementation with what humans produced. My friend, Bob Beck, I I was talking with him the other night, and and I asked him, you know, like, you know, this AI thing, what is your stance in in relationship to to to specifications? And he brought up the example, like, hey. AI is a tool, and it obviously doesn't count if I use the VI editor and then separately the Emacs editor and claim its two implementations. And I think in a similar vein, a single person driving towards an outcome with whatever tools they deem necessary to come at that outcome, it's still a single person. And what I'd like to see is that multiple groups of people or at least multiple people produce implementations that work in Concord. So we'll get into some more details in later slides. But why go through this tremendous effort of producing running code? Isn't it enough to just, you know, look at my glorious idea, and we'll pick up the pieces later? It it is my conclusion after some years of IETF engagements that, if running code is available earlier on in the process, it saves time. And this may feel a little bit counterintuitive, but I've seen quite a few times that that an idea that sounded great was put down on paper, gets published as RC, and then later on, implementers try and implement the RC and they discover shortcomings in in the specification or under specification is a very common theme. Because if you're not implementing alongside writing the spec, chances are you're missing the questions that implementers ask because they are not sitting next to you while you write spec. And this often results in a BIS document with clarifications of the thing that originally seems a great idea. Now writing a BIS doc so an RFC publication process is anywhere between two and four years ish. So appending a BIS document effort to that two to four year period of time means that in reality, you're you're looking at four to eight years to arrive at a stable quality specification. And that's that's a lot of years. These BIS documents are not free. They take up valuable resources from the working groups. They take up space in the RC editor queue. So if you're waiting for your spec to be published as RC and you you're like, why is it taking six months in the RC editor queue? That is because there are other working groups that do not demand running code as part of their publication process, and they're polluting the RC editor queue. It's my theory. I might be wrong. I really think if you have that feedback loop between, an implementer asking questions that implementers ask, like, oh, you're saying this thing. Do you mean left or right? Because you said take a corner, but which which direction? You you get better quality specifications, and better quality specs means better interoperability, less ambiguity, and it saves time and money in the implementation process because the spec is readable. So there's two dynamics that result from from this. You pre RRC publication, you you will develop a feeling of confidence in the to be published as RC spec because you have running point to point at and be like, hey. Look. We we got a few implementers to sign off on this story. We think this is ready for RC publication. And post publication, if additional vendors sign up and they're like, alright. This foo over quick shit that you came up with looks great. And we're gonna implement it because we know that other competing projects or competing vendors managed to implement it. Because once one sheep is across the the bridge, many can follow. Right? It's it's a dynamic like that. The upfront investment of having running code as requirements, you you get confirmation that the spec is understandable and readable by other people other than you. You can read your spec. I know I can read my specs. They are, you know, literary masterpieces that that are you know, I can see the diamonds in in my specs. And then other people read it, and I'm like, oh, oh, I guess I could use different words, better sentences. And as I mentioned before, if if if somebody uses AI as part of their development process, by all means, participate. This is not an AI versus human discussion. This is a discussion of how do we arrive at specs that are of such quality that you don't require BIS documents and that's all the project projects that attempt to implement it arrive at similar compatible results. Now catching bugs and design flaws that a single implementation might miss or hide is one I've I've seen happen a few times. In the RPKI ecosystem, there there's a a certain protocol. And it it it it made it quite far in the in the publication process and quite or phrased differently, quite late, implementers took a look at the proposed specification. And it was discovered that there was a a bug in the in the version negotiation. So it turned out like, hey. If you implement it according to spec, you end up with machinery that does not interact with each other as designs. And the only way to discover this was by producing multiple implementations and and testing the spec as written. So that that draft got pulled back to the working group, and the box got got fixed. Thank goodness. No BIS document needed there, but I was like, oh, that was a close one. And another cool dynamic that comes into existence, like, you have a great idea. You you write it down as Internet draft, but you you alone or I alone, we don't know everything. And if if your talent is in the theoretical realm, awesome. We need those people. But we also need people that give feedback on what it what implementers need to hear or what operators want to read in a spec to be able to operate the machinery that's described in specification. So I think that a running code requirement, at first, it might sound a bit, like, awkward. Like, it forces protocol designers and implementers to to work together to to collaborate and produce running codes. But at the end of the day, it produces specs that are better for the ecosystem because they take into consideration more stakeholders. If you have a spec that is only written by a designer without implementer feedback, it's it's just not gonna be as good as one that was written by a diverse set of offers from different breadcrumbs. So I think this bringing people together aspect and creating a diverse set of offers on on Internet drafts is is very powerful, very valuable. And last but not least, not all ideas need to become RFCs for one reason or another. And having a running code implementation requirements is a natural way of gatekeeping. It it may may act as a gatekeeper because the, you know, the spec is unimplementable. That's that's good feedback to have. It maybe means the spec is undesirable to implement. Like, there are some unintended consequences or who knows? But it it's not always easy to say no. It's much easier to make an honest effort to try and implement something. And if that fails to succeed, it's too expensive, too complicated, undesirable, not safe. I don't know. It it doesn't really matter why. But if at the end of the day, at at you don't have running codes before working group last call, then it it means something. It is a signal to the community, to the ISG, to to the working group itself.

[01:42:08] **Med Boucadair**: And job because we have we have a long list of sales in in the queue, and we have one more presentation if you can just, yeah,

[01:42:14] **Mahesh Jethanandani**: wrap Okay.

[01:42:16] **Job Snijders**: I will not filibuster for the other presentation. So some working groups have this. This is an example from the IDR charter. They require at least two independent implementations prior to publication. SSHM, the Secure Shell Maintenance Group, has two demonstrably interoperable implementations. Look. The tie I'm losing the time in the clicker. It's not my fault. SIDROPS requires at least two implementations because they consider routing security very important. And, plants, relatively young, working group also requires two interoperable in implementations. So there is some some precedence in the IETF to make this part of your chartered requirements. Advantage being that it helps participants understand upfront what the rules are of the working group. So this is where I advise people like, hey. Take a look at your charter and maybe, you know, propose some updates to your charter.

[01:43:26] **Med Boucadair**: Do do you want to take some questions?

[01:43:28] **Job Snijders**: Yeah. Let's let's take some questions.

[01:43:29] **Med Boucadair**: We have only one minute. So, yeah, please, we can keep just one or two. But please

[01:43:36] **Job Snijders**: Yeah. This was my last slide.

[01:43:38] **Med Boucadair**: Thank you, John.

[01:43:39] **Thierry**: Yeah. Thierry Siebisch, Thierry Siebisch, one point about independence. Even if the authors of the document don't talk to each other, they shouldn't count as independent, I would say. And the second one, if the RFC process is so long, basically your top point there, maybe we just need to become more quick there.

[01:43:57] **Job Snijders**: Sorry. What was the last thing you said?

[01:43:59] **Thierry**: Maybe we have to become more quick with experimental documents first.

[01:44:06] **Job Snijders**: How does being fast help? I I think I missed Oh, yeah. There was some packet loss.

[01:44:13] **Thierry**: I think that's offline then. Okay.

[01:44:15] **Med Boucadair**: Thanks a bit. And,

[01:44:18] **Andrey**: Lucienko, thank you for the presentation. I wanted to share that building the code that runs with AI, it's not only possible, but it's also relatively cheap. So I did just this experiment a few months ago where I told to the agent, download everything that contains SSH in it and implement. After twenty four hours, I had something that interoperate with itself.

[01:44:44] **Job Snijders**: Fantastic. After forty eight production.

[01:44:46] **Andrey**: After forty eight hours, I had something that interoperated with the open SSH Cisco boxes. It's by no means standards compliant, and that's also interesting thing to see which shortcuts it takes as well because there's plenty of corner cases in the RSCs that float on surface with this kind of implementations because then you can see it much better.

[01:45:07] **Med Boucadair**: Yeah. Thank you.

[01:45:09] **Stefan**: One more? Stefan Lebing, SRDN. Thank for the presentation. I can agree with you because I have a draft and I have had feedback from implementers to see, okay. I'm missing this part. I'm missing this part. I have to describe this, but people are able to implement and that is good to see, and I know where I have to do more work. Thank you for this.

[01:45:35] **Job Snijders**: Cheers.

[01:45:36] **Peter van Dijk**: Hello. Peter van Dijk, PowerDNS. I'm one of the implementers Stefan mentioned. I have seen many drafts that needed implementations. I've often asked on working group mailing lists, can there be implementations? And people are often receptive. Also, sometimes they see it as an offer, which it is not. We have some RFCs out there that are in unimplementable because nobody tried. So I I love this initiative. Thank you.

[01:46:05] **Job Snijders**: Thank you. Yeah. And to clarify, this is not about providing a product to the markets. That is not the requirement. The requirement is that we have some confidence. Specification is implementable as proof of concept, you know, on your development branch. This is not about having a, you know, formal release that that you can buy. You you may never sell your code. That's fine. So

[01:46:31] **Med Boucadair**: And, Marie, sorry sorry to interrupt. But thank thank you. Thank you again, I would say,

[01:46:34] **Job Snijders**: for In summary, we're gonna do requirements for implementation in the whole ops area.

[01:46:39] **Med Boucadair**: I I see. Yes. But let's see what the committee wants.

[01:46:41] **Job Snijders**: I think everybody agrees. Yeah.

[01:46:45] **James Galvin**: Thank you.

[01:46:45] **Med Boucadair**: I'll take

[01:46:45] **Mahesh Jethanandani**: it again,

[01:46:46] **Med Boucadair**: Thank you. Yeah. So next, we'll be having Ritesh. So he'll be talking about RPKI and BNP. So, Ritesh.

[01:46:55] **Ritesh Mukherjee**: Hi. I'm Ritesh Mukherjee from Nokia. This is a perfect segue to the next to my presentation because it's actually an implementation we have done. Just wanted to share what the implementation is and, of course, talk about some things we learned along the process. Raven, it correlates live BGP routes with RPKI validation state, so origin validation and ASPA, into a single signal. So it's a single go binary BSD three clause free to use on GitHub. And, of course, there are contributions from some operators also on to the code, I'm not the only one who's the author currently. Just a quick note, I originally wanted to show this as a demo and run it live on my laptop, but I had to switch laptops due to a last minute switch. So I wouldn't be won't be showing a a lab, but, I'll talk through it. But everything on slides is real. It's just I can't do it interactively, show it to you. And it might be a good thing because I'm the last one between you guys and beer, so it might be a good way to sort of cut this quickly. Why we are here? BMP collectors today see routes but don't validate them. RPKI validators validate, but they are not seeing live routes. So there's nothing correlating the two into one signal. And there are drafts already, the grow BMP RPKI monitoring requirements, which says this explicitly. And that option numbers also show why it matters. Today, it's around 1% of global liaison space that has opt ASPA objects today despite, of course, Adam and Wright both shipping object creation in the last few months. That's a tooling gap, not a a protocol gap. So what does Raven do? What we have built? It sits between your routers and your validator. So it pulls routes over BMP, pulls VRPs, and ASPA data over RTR version two and annotates every route with a combined posture in real time. So no external dependencies, no dependency on any vendor or any implementation, just one binary talking to routingator and a topology. So every route gets one posture from combining origin validation and ASPR. And when it if both are secured, obviously, everything looks green. If it's origin only, when origin validation passes, but there is no ASPA coverage, which is most of the Internet today, so you'll only see origin origin valid only today. A path suspect when origin validation passes but ASPA fails. And that's the interesting case because, obviously, origin origin validation alone would call this clean, but you see path suspect today for ASPA objects. And origin invalid when origin validation itself fails. And I'll walk through some examples of all these three, and, of course, come to some conclusion on some improvements we can do. So the laptop all GM, I'm going to try it on and show you. I'm not running it live. Like I said, I had to switch machines so I can't do it live. But it's basically five FRR containers plus routingator. A s 65000 is upstream. A s sixty five zero zero one is the edge router where Raven's BMP session terminates. And a S 64496, it plays the attacker. So I'm gonna introduce some attacks and sort of show you leaks and hijacks and so on. And routingator is feeding Raven real RPKI data. It's getting that data from from RNN Ripe, and it's just under a million VRPs today, 958 k today. So this isn't this is a real validation it's doing. So this is a capture I have taken from the tool, and it's showing output of RavenWatch. So A S64666, it originates 192DashDot0Dot2Slash24, but the covering origin authorization authorizes a S1335. So origin validation fails immediately. A posture flips to origin invalid, and it's got from the two BMP peers independently since Raven is watching both the edge and the upstream router at once. And this is a serious straightforward implementation of RFC sixty eight eleven. The floor, everyone in the room only has and knows. The differentiator is the next one. So this is what I wanted to show. This is a capture out from again, from RavenWatch, but it's showing path suspect. So a S1199 has a fully valid origin authorization for this prefix, and origin validation alone would call this route completely keep clean. But as per obviously disagrees, a S1190Nine's declared provider set is exactly one ESN, a S1103, and the path we observed shows a S65000 as the next hop. So it's not in the authorized set, and that's a leak. Legitimate origin, unauthorized path, rove origin validation structurally cannot catch this because, of course, it's only looking at the origin. But, of course, you can see it here. You can also do what if scenarios.

[01:53:05] **Per Andersson**: Sorry.

[01:53:10] **Ritesh Mukherjee**: So this gives this tells you per hop reasoning directly, a customer unauthorized provider routes affected. The detail lives in a separate command, but it's a unified view. And this tells you the question, what actually blocks deployment isn't origin validation. It's what breaks if it turn on reject invalid. So the answer is here captured in our lab, two, three, four, one of just under 1,000,000 routes would be rejected. And the same query unchanged would run against a live production table. It'll tell you what would drop, what wouldn't drop, and so on if you turned on reject invalid today. A quick update on what we learned sort of or what is relevant to this room specifically. One, ES set handling as per verification is sort of underspecified in the draft because it doesn't define ordering inside an unordered set. So we default to un unverified with the configurable best effort mode that validates the AS sequence around it. But, obviously, every implementer has to make that call independently, and it doesn't really say what to do. Second, the RTR version two as per PDU negotiation against Routingator, according to the draft, was clean, no friction. So if you're evaluating validator readiness today, that path is production usable today. Third, BMP route error logging. It seems like a natural next extension. Today, we validate on RTR serial changes computed internally. That's visible on the wire since and our RTI only change doesn't touch adjacent ribbon, so there's no existing BMP event for it. Route event logging would, of course, provide that straight transition. We signal directly instead of every downstream consumer needing to own RTR sessions to reconstruct it. And if anyone else is interested, we can help the prototyping or I can or we can call or collaborate on it. Everything's open source. BSD three clause on GitHub today. Docs and ContainerLab is included. They're asking for feedback on the AS set stands. Anyone prototyping BMP route error logging, and, of course, the scarcest thing. If anyone's willing to run Raven against real ASPA-covered paths for longitudinal data beyond the lab, there are some operators trying it in the lab already. But if anyone's trying it and wants to do it, then, of course, we'll be really interested in getting that feedback and getting learning experiences from that. That's all I had for the update. Any questions? I'm sorry. Thanks for bearing with me. I wasn't able to show the live demo thanks to some changes in in my computer, but you can try it live in in GitHub.

[01:56:31] **Mahesh Jethanandani**: Alright. John?

[01:56:38] **John Scudder**: This was very John Scutter, this was very cool. Thank you. Thank you for not showing a live demo. They're always better in theory than in practice. So you asked for feedback about AS And even though Warren is sitting right in front of me, I'm the one who jumped up to say, just don't worry about AS set because it's deprecated. There are very few of them in the wild anyway, and we should stamp out the remaining ones with, you know, great prejudice.

[01:57:10] **Ritesh Mukherjee**: Agreed. That's that's good feedback. Thanks.

[01:57:17] **Mahesh Jethanandani**: Alright. Any more? I don't see anyone in the queue, so thank you, Ritesh. And with that, see you all in San Francisco.