Session Date/Time: 17 Mar 2026 08:00
Antoine: Good morning, Jorge, can you hear me?
Jorge: Good morning, Antoine. How are you?
Antoine: I just made it. Had some connectivity and audio issues, but I think it's all right now.
Jorge: Well, we're waiting for Jim to arrive.
Antoine: Oh, Jim's late. That's not, that's not Jim.
Jim: Just start without me? Well, good afternoon, everyone. Let's get started. Sorry for the little delay. Welcome to the REGEXT Working Group. This is the Note Well. Please keep in mind that just by participating in the IETF, you are accepting this Note Well. This is the agenda for today. We had the Note Well that you just saw. We have an a welcome and introduction. Do you want to start that, bring the control slides?
Jorge: I'll go ahead and take it over.
Jim: Okay. Do we have a notes scribe?
Jorge: Uh, no, we don't. We should.
Jim: Is there anyone willing to participate as a notes scribe? Okay, thank you, Gavin. Okay, uh, for the shepherds. We're still looking for a volunteers for document shepherds for all the documents we are producing. Uh, we have many people that have volunteered in the past and they've done a great job as a shepherd, but it's always a great opportunity to work as a shepherd and get forward in making sure the documents get published. Publication documents: we only have one in this category, Registration Data Access Protocol for regional internet registry search. Submitted to the IESG: we have the draft-ietf-regext-rdap-ttl-extension for RDAP. Um, documents in the Working Group Last Call. This last call just ended a couple of weeks, a couple of days ago. So, Scott already has published a new document with all the feedback incorporated. So, I think we're ready for let the document checker do the write up and proceed with the document. Existing working group, existing work with a presentation. Uh, the first document is the JSContact for RDAP and JSON responses from Mario.
Mario: Can you hear me?
Jorge: Yes, Mario.
Mario: Okay. I have very little to say about this draft. Following the working group consensus on making the draft standard track again, I removed the experiment section and changed the draft category accordingly. Um, the document is now ready for the working group last call, except for the nit recently discovered by Martin that will be fixed in the next version, along with possible changing addressing the feedback from last call. That's it.
Jorge: Thank you, Mario. draft-ietf-regext-epp-quic, James Gould.
James Gould: Uh, yes. So, um, the 04 draft was just posted which includes feedback from Martin Thompson from the QUIC working group. Um, so we have addressed both feedback from two individuals from the QUIC working group, um, and I believe that uh, there's no remaining work for this draft. So, um, unless there's any additional feedback from the mailing list, this draft is ready for working group last call.
Jim: So I think the question, um, Jim, is we've always been treating this document as a pair with HTTPS. So, are we still doing that?
James Gould: We can. Um, actually I have some more positive news on the draft-ietf-regext-epp-https draft. Um, they can go separately. The advantage of having them go together is that they are very similar in their content. Um, so it would make review of both of them easier. Um, but they could go separate. Um, I'm not sure if we want to hold off on the draft-ietf-regext-epp-quic draft if the draft-ietf-regext-epp-https is going to take longer. Like I'm not sure how much longer, but I'm not sure if you're going to hold it off, that's all.
Jim: So I think what we're going to need to do, since we've been in the working group, we have been treating them as a pair, um, we're going to have to ask on the list and make sure that no one has any other concerns about splitting them. Um, so we'll certainly take here your request to think about moving it to working group last call. But, um, as as with Mario and the JSContact draft, um, you need to ask on the mailing list and I would say that you need to ask on the mailing list to to add to your question to explicitly separate it from HTTPS. We just need to make sure that no one has any objections or concerns about that. Okay?
James Gould: Fair enough. Yeah, no problem. I can do that.
Jim: Okay, thank you. Um, next up is the versioning in RDAP, and that is also going to you, Jim.
James Gould: Yeah, so I'm going to be setting up a meeting, hopefully next week if I can coordinate that with the co-editors of the versioning, the media type, and the extensions draft, because there are what I see as incompatibilities between those three drafts that we need to work out. Um, so I'm hoping to have a positive working session with those co-editors between the three drafts so that we can make them compatible with with each other.
Jim: Um, okay, so who are you talking about being in that meeting? You, I assume Andy, Jasdip, Mario?
James Gould: Andy, Jasdip, and uh, Tom. I think it's Tom as well.
Jim: Uh, Tom why why Tom?
James Gould: Harrison. Is it Harrison? I think he is on— which one is he on? I think it's the extension draft. Okay.
Jim: That's correct. Andy just offered that up in the in the room, I'm sorry. We just don't have his name on the slide, so thank you. Yeah. Okay. Um, so I think from a chair's perspective, the important point here, one of the questions that I had about these is we had originally we were talking about the three of these documents being together, three being the extensions document which we're going to get to in the next section, versioning, and the X media type document. They were at one time all considered together, we separated them, but these two, versioning and the X media type, would wait for the extensions draft to move forward. Um, and we did come to that conclusion in the working group. Uh, is is there any reason to change that or we still, even though you're going to be talking about editing these documents, is there any reason why that would change?
James Gould: No. No, I just, uh, we just need to make sure that the extensions draft doesn't have any overlap or incompatibilities for what exists in those other drafts.
Jim: Okay, thank you. Ah, now I can even hear my voice in the room. I got closer to the mic, it probably didn't change remotely, but uh, it's made a big difference in the room. Okay. Um, thank you for that. So, uh, the action here, have you have you spoken about the X media type then or did you want to add anything with respect to that document?
James Gould: Uh, am I on that? I'm not, I shouldn't be on that one.
Jim: Um, okay.
Andy Newton: I can speak to it.
Jim: You can speak to it, please, Andy.
Andy Newton: Yeah, so Jasdip and I have I think we submitted a version a couple of months ago, but we're kind of holding until the extensions draft. We're putting more of our energy on the extensions draft at the moment because as you just said that's supposed to go first. So, and that's the status for the extensions draft too.
Jim: Okay, uh, thank you for that. Um, okay, so just to summarize here, just to make sure that chairs are clear, um, you Jim Gould are working a you're going to set up a little separate meeting among the editors here to make sure that all your documents are aligned, all three of the documents meaning extensions, versioning, and X media type, um, and then we'll be waiting for extensions to move along before these two move along. Is that fair?
James Gould: Yes. Absolutely.
Jim: Okay, thank you. And I now see Gavin at the mic, please.
Gavin Brown: Just briefly talk about um the RDAP referrals. Um, we had um our review from HTTP Directorate, um with some changes that uh were suggested. I think we're going to make them. Um, we've had very little in the way of um working group input, um, so uh but we kind of feel like it's kind of done, so um you know we're we're yeah, sorry, it's a bit low. Um, so I think a I kind of feel like it's getting ready for last call as well, but would like some feedback from the working group first because we haven't had much. Um, and it's quite a you know quite a meaty change. So, it's worth having a bit of a bit of a look at it first before we um go to last call.
Jim: A meaty change recently to which one?
Gavin Brown: Just in the referrals changes the way that RDAP clients interact with RDAP servers quite a bit. Um, and and if it's um going to get any deployment it's going to have quite a big impact on certain kind of um RDAP service ecosystems. Um, and and so I think it's worth having a we think it's right, I think it works, we think it um solves a big problem, so um but we're only we've only got so many eyeballs between me and Andy. Um, and so we we kind of would like a few more, please. Thank you.
Jim: Okay, I'm sorry, before you before you leave the mic, I think I missed something there at the beginning. Were you talking about these two documents, versioning between—?
Gavin Brown: No, I'm sorry, I was talking to RDAP referrals, sorry, I was moving on to my— okay.
Jim: So you jumped to the bottom and talked about the redirects. Okay. Yeah. Um, that's fine. And just so I understand, you're also suggesting that the referrals document, or I guess it's called redirects now, has an impact on these other—?
Gavin Brown: No, no, sorry, I was not very clear when I when I came up to the mic, probably because you couldn't hear me. Um, so I was just giving my update on on the RDAP referrals draft rather than any comment on the other three. Apologies.
Jim: Um, and I am aware that you've you've done an HTTP uh review there and uh yes we should wait for that to to conclude, um, and then you can ask and and seek working group last call on that document um at that time. Um, and I assume you're going to be talking to the editors not just Andy but the others here about the other documents and make sure that they're aligned and the impact is addressed.
Gavin Brown: Yes.
Jim: Okay, just trying to capture actions. Thank you. Okay. Um, you also made the comment that I I do want to repeat in general which is um it's always useful, people should read the documents and I and I know that we have a limited set of people who tend to care about particular documents. But it's always helpful, even if you just say no objection, it really is good to hear from people that you have looked at the document. I mean, at a minimum, if you can say something like no objection, we very much appreciate that, um as opposed to waiting for last call to read it which we uh seem to get a lot in this working group, but a little advance notice is always nice. So, makes last call go a little a little more smoothly. Thanks for that. Okay, next up is balance mapping, so back to you Jim.
James Gould: Uh, yeah, um there is a right now uh I've asked uh Werner Staub to be a co-editor uh with the chairs and I believe uh the chairs you've agreed to that add them as a co-editor. I didn't hear any concerns on it. Um, but that we uh we met and there are some changes that we're proposing to make the draft that I posted to the list, so any review of those proposed changes uh would be uh welcome. Um, and those changes will be incorporated in the 01 draft. Um, and then I did want one draft that's not on this list is the draft-ietf-regext-epp-https and I wanted to—
Jim: That has a presentation in the next section.
James Gould: Oh, okay, forget it. I got— well, I don't think Mario knows this. I just want to point out, uh we had a very productive meeting with Mark Nottingham uh earlier today and uh I sent him the latest version of the draft and um he understands what it is that we're attempting to accomplish and it seemed like he was receptive uh to it. So, with that I'll let Mario handle the rest.
Jim: Okay, thank you. Sure. Um, and then with RDAP extensions, Andy already commented on that, so we're already caught up. Uh, you have some things you're going to do there and potentially there'll be another version and then you'll be asking for working group last call, and thank you Gavin, we've already covered RDAP referrals. Okay. In spite of the fact that I was late which I apologize for. I had set in my mind this meeting was at 4:30. And even though Jorge told me earlier today, no Jim, it's at 4:00, I still managed to miss it. But we are now only uh two minutes behind. So, uh, thank you for that. And moving on, that takes us to existing work of the presentations and I believe first up is the RPKI document. Um, is uh Jasdip doing that? Is he online?
Jasdip Singh: Hey, can you guys hear me?
Jim: Yes, we can, loud and clear.
Jasdip Singh: Wonderful. So, can somebody run the slides for me, please?
Jim: Would you like the uh control, the clicker control?
Jasdip Singh: No, thanks. Hey, um, so yeah this is early here on the east coast of the United States. So, pardon me if uh I'm not thinking that clearly at times and if I don't, I'll get back to uh any questions. Um, so yeah, this is an update on the RDAP extension for RPKI registration data. If I recall, last we talked about it was almost a year ago, so it's a good thing to uh um uh see where we are. Um, Andy and myself, we are the co-authors. Next slide, please. Um, so we are I think on version 03, and I just wanted to walk through quickly what are the changes which have been made to uh um this extension. Number one is, essentially this extension, just a quick um sort of uh um brief uh background, it talks about three different types of RPKI profiles: ROA, ASPA, and and resource certificate. Um, ASPA which is um this work is getting done in the SIDROPS working group, um we we keep up with how um those changes are being made. So, um we have renamed the autnum member as customerAutnum in the ASPA RDAP object class because it was renamed uh in in that profile. Um, next one, based on the feedback from RPKI community, um we now include message digests that entirely cover an RPKI object and there are two of them, SHA-256 and 512. Um, and uh um the reason for that is that this gives uh um an exact um sort of uh reference to the underlying RPKI object. Uh, and that's useful when you're doing analysis, research, and or debugging. Um, so that's the reason for that. Um, then there was a very interesting problem and this helps grow the RDAP ecosystem. Not there are three types of RPKI configurations: um, obviously hosted which most registries do um on the number resources side, but there's also other two called delegated and hybrid. Without getting into details of that, but we now have a methodology uh to um be able to have RDAP services on those um types of configurations also, and in the process we introduced a new um relation type in web links called rdap-help. Um, so yeah please check that out. Um, the next one, deconflict lookup path segments: so as this uh draft was getting prototyped, which I'll talk about in the next slide, we realized couple of places where our path segments were not right. For example, for ROA, um you can look up by handle or by a natural identifier like IP address. So, that has been deconflicted. Uh, we included more useful reverse searches um and uh in the process we also found out a way to rather more elegantly include RPKI related reverse search links in entity, IP network, and autonomous system number objects. And the reason for that is that will make the responses uh um not grow too big. Um, and uh so that that was taken care of. And finally, um we we observed that now that we have lookup by handle, we did not want to introduce search by handle. So, that was uh removed. Um, so these are the changes which have been made. Next slide, please. So, what have been the activities in that time I mentioned? So, there have been two. One is um ARIN, um we at ARIN have prototyped the salient lookup and search paths. I believe there are close to 35 plus different lookup and search paths, and when I say search paths, I also include reverse search paths. So, at this point, we have done, just like drawing a Picasso, the more salient ones to uh um to to do a proof of concept of this. So, that was done. Um, and then also, um uh it was uh that prototype was demoed to uh our peer RIRs, um mainly to solicit further feedback and there were a couple of more feedbacks on that um and and we met earlier this year, um so that will be taken care of. Next slide, please. So as next steps, um we're going to add an implementation status section. And the reason, though the prototype is there, uh we need to make sure it's publicly available and the benefit of that is this is that ethos of uh rough consensus and running code. Um, so we want to make sure it's available during working group last call and or uh IESG review later on. Um, next as I mentioned, there is a little bit more feedback to incorporate from the prototype demo. To be precise, it is about the signing time attribute. I believe it's the RFC 9589. Um, so that's something which uh um I think it was Tim Bruijnzeels who suggested from RIPE. He's like, um I think it'll be helpful to include that. Um, and then yes, as I mentioned, um we'll at that point, um now that we are a little more confident about uh the the correctness of the content in the draft, uh especially after implementing the prototype, um I think we'll be requesting the working group last call. Um, so don't want to put any particular timeline on it, but hopefully uh this all happens uh this year. Um, next slide, please. Yeah, so these are a couple of references if you're interested. We have been tracking the issues um in GitHub. Um, obviously the draft everyone knows. So, thank you, thanks. That's I believe the last slide.
Jim: Thank you, Jasdip. Um, any questions or comments from the floor? Not seeing any hands going up. Um, so I'll just comment, um thank you.
Jorge: I'm sorry, Jasdip, someone's coming up on the mic.
Jim: Am I missing it? I'm not seeing a queue. Why is the queue not showing for me? If it— oh, Richard. Please, go ahead Rick.
Rick Wilhelm: Thanks. Thanks Jim. I just have to get into the swing of things here, I'm— more coffee for Jim, can you hear me okay? Seriously, go ahead Rick, I'm sorry. Very good, thank you. Um, uh thank you Jasdip for the uh for the presentation. Just a real quick question, um when I was reading this one of the things and you highlighted it on presentation was the the the new rdap-help I guess link or reference or I'm not quite exactly sure what you call it. Do we, do you or do we does anybody else think that that might be more generally useful? I was interested in reading this to come across it and I'm wondering if it's something that we might gain utility in other spots. You know, it's coming up here in this RPKI sense and I'm wondering if it's something that like we've discovered here— I'll say "we" as a community, I mean you and and Andy kind of bumped into this as a solution to a problem, and I'm wondering if we might generalize it to other spots where and it might kind of serve to untangle some things or smooth some things out that we might have previously left tangled or gnarly, and that's not really a technical term. Uh, your or anyone's thoughts on that. Thank you.
Jasdip Singh: So I think, uh, I'll start and then Andy can help. I think the the inspiration was how in RIR search, you know we introduced um uh new relation types rdap-up, rdap-down, rdap-up, um uh and and a couple of others. And the idea is that when you're defining— and obviously our media type is application/rdap+json, Rick— and and the idea is that it helps the clients because it's all trying to think uh from client-centric perspective, um not just that servers don't matter, uh server-side. But you're right, that this is something um and in fact this was Mark Nottingham who said that, hey why don't you guys start using if you're going to introduce new relation types, um prefix them with rdap-. So that's a pattern we are using and in fact I think if I'm— Andy can correct me— we even mentioned that in extensions draft now. Um, so yeah I think you're spot on, this can be useful. For for us it was very useful because clients can now identify this web link quickly and then use it vis-a-vis uh the RDAP RPKI um and and yes, so I would say yes, it it will be useful.
Jim: Okay, thank you. Um, we've locked the queue at this point. We are actually over time, but Andy, please go ahead. We'll let one more question go.
Andy Newton: Uh, yeah, I just want to respond to what Rick said. Yes, so I think if it we we should look to see if it's more generally useful. The rdap-up, rdap-down stuff in the in the RIR draft, um RIR reverse search draft, sorry, it's early for me too, the uh um is also useful in other places so we can look for that. And I I just kind of want to know if Rick what Rick meant by gnarly was like surfer dude gnarly or if it was some other connotation. All right, thanks.
Jim: Okay, so you were not expecting an answer. That was a comment. Oh, okay. All right, thank you. Um, so uh just a general comment about this document. It's it's good to work as it's progressing, um and we're going to add it to the long list of documents which are really on their way out the door in our group. We've had quite a few documents that have been hanging there and it's really just just delightful from a chair's point of view to see these things coming to closure. So next up we have Mario is going to talk to us about draft-ietf-regext-epp-https. So Mario, please go ahead.
Mario: Yes, can you run the slide for me, please?
Jim: Yes, we will.
Mario: Yeah. This is a short update on the status of EPP over HTTPS draft. It briefly covers recent revisions, architecture issues arise, and potential next steps for the working group in light of the talk of James with Mark Nottingham. Please James, chime in anytime if you want to add something or skip some contents. Next slide, please. Last September, James Gould requested feedback from HTTPBIS working group. We received comments from the authors of RFC 6265bis. Those comments were addressed in the draft. Uh, we subsequently requested the review from the HTTP Directorate. This review raised concerns about the relationship between the draft and BCP 56. In particular, the review suggested that either EPP semantics should be mapped more directly to HTTP or that the CONNECT method should be used. Next slide, please. Our interpretation of BCP 56 is that it primarily applies to the design of new HTTP application protocols. In other words, it is mainly about cases where HTTP is being used as the application model. But this draft does not define a new application protocol using HTTP. Instead, it defines a transport mapping for an existing protocol. So the real question then is whether HTTP native design is the right framework for evaluating this draft. Next slide, please. To make this point clearer, it may help to compare EPP over HTTPS with similar IETF work, namely DNS over HTTPS and oblivious HTTP. In all three cases, HTTP carries messages from another protocol rather than designing a new HTTP native application model. Another similarity is that HTTP status codes are not used to represent the application level result. Instead, the result is conveyed inside the protocol payload. So the pattern of using HTTP as a transport substrate already exists in other IETF protocols. Next slide, please. This is another can be considered another point of friction. BCP 56 encourages protocols using HTTP to be stateless and to rely on HTTP semantics. But RFC 5730 explicitly defines EPP as a stateful protocol and requires that any transport mapping preserve the stateful behavior. So when defining EPP over HTTPS, we must keep the EPP session model intact. Next slide, please. Regarding the suggestion from the HTTP Directorate, one was to map EPP commands more directly to HTTP methods. However, that would effectively redefine EPP as a new HTTP native protocol. RFC 5730 assumes a clear separation between EPP semantics and the transport layer. If we try to map EPP operations directly to HTTP methods and resources, we would have to invent a new resource model for EPP objects. Uh, also the HTTP status codes and EPP result codes serve different purposes. HTTP status codes indicate whether the HTTP exchange itself was successful, while EPP result codes tell you what happened at the registry protocol level. And finally, EPP relies on an explicit login-logout session model. Next slide, please. The other suggestion was to use CONNECT, but while CONNECT works for generic tunnels, it may not be practical in many deployments because load balancers, reverse proxies, and security policies often expect normal HTTP request semantics. So even if CONNECT is conceptually possible, it may not be operationally viable for actual registry environments. Next and last slide, please. So, all that has been said, the authors see two possible ways forward. One position is for the working group to confirm that BCP 56 does not apply to this transport mapping. Another option is to clarify the architecture choice in the document itself. So we on I don't know, in light of the the talk between James and Mark Nottingham if these proposed next steps should be verified should be changed or not. Please, James, have your say on it.
James Gould: Yeah, to fill fill the working group in on the discussion with Mark, he does not support uh use of HTTP as a general transport mechanism. But apparently the editors for DOH met um with Mark and um and in the case of EOH, we met to describe what is attempting to be solved and it seemed like he was receptive um for EOH that goes along with his being receptive to DOH as well. So it's not a general case, uh but the ability to be able to leverage HTTP as a transport for an existing application protocol which may have um some specific requirements like in the case of EPP being stateful, uh is seemed to be acceptable. But we'll see based on his more recent review.
Jim: Thank you, Jim, and thank you, Mario. Uh, please folks, we have less than two minutes um left and we have quite a queue which we've now closed the queue. Pavel, you're next.
Pavel: Yes, thank you. Um, I have a one question to the to the editors of this draft, um because uh I think on the over the mailing list there were contradictory let's say approaches to this BCP 56 discussion. On the one end there were statements that this draft is fully compliant with BCP 56 and on the other end there were statements saying it does not apply. Uh, if you know if it's fully compliant then there is no problem of it let's say to apply or not, and I I wanted to have clarity what's the the position of editors on on this one.
Jim: Okay, thank you Pavel. Um, before you respond Mario, let me just see are did the others want to speak to the BCP 56 issue? Andy or Martin? No, Martin no? No? Okay. Um, let me just um say with respect to that um as chair having talked to our area director about this too, um I I don't have a preference as to which one of these two choices we go to here. I think the important part of the process to call out is that it is incumbent on the document shepherd, which would be Gavin in this case, okay, to call out this particular issue um and and explain that we had this Directorate review uh and they had a point of view and the working group chose a different point of view. Um, so that has to be captured and documented in the shepherd write up. There is a question in there for that. So um if if we're going to do something which it seems like we are that is different from the way the Directorate approached it, we need to get in front of that when it goes to the IESG so that they have all of that information and then they can make the decision that they want to make. Um, we're not obligated to do exactly what they say, but if we do something different, we do have to explain it and rationalize it. So I I think that would be the answer to you Pavel for right now. Um, on the mailing list here, we'll have to ask this question Mario as to which way to go in terms of the next steps on on that issue and see what consensus we can get. And with that, Andy you're up next.
Andy Newton: Yes, Andy Newton. Um, as an individual, the I I think it would be great if we had some registrars show up and say they want this, because they're the ones who bear the burden of multiple transports, not the registries. So um I think before we go forward with any EPP transports, we need to have the registrars say they want this.
Jim: Okay, um, we'll that that should be included in the implementation status I would say, right, if there is such a thing?
Andy Newton: No, having a registry come up with an EPP SDK with the transport is different than the registrars wanting it.
Jim: Okay, so you are you suggesting the document should be held up until at least one registrar—?
James Gould: Can I can I speak to this? Um, I'm a little bit concerned about setting a hurdle for a like a multi-stakeholder model at the IETF. The fact that we need to have registrars come in and vote on whether or not they have a need for this um seems against what uh what we do at the IETF.
Andy Newton: No, it's not uncommon for the IETF to ask for multiple people for for it to be useful to all to all parties. That's not uncommon. And normally I don't really I don't personally care about a lot of things that you know we can just do that aren't that harmful. But in this particular case, it is registrars who bear the the majority of the burden not the registries. And so we need registrars to show up and say they want this.
Jim: Mario, are you aware of any registrars who have done this?
Mario: Oh, we I can speak uh as far as our experience at .it is concerned. So we we have been running this implementation since 2009. So I I um I can assure that the burden for the and we have a lot of small registrars at .it, I can assure that the burden of uh required to implement this approach is not so um big. So uh so I I really don't understand the uh concern about implemented this. Because um as I said, as I wrote in in some posts on the mailing list uh implementers are more uh used to um submit HTTP request and and and and handle and handle HTTP request rather than TCP sockets in my in my opinion. So—
Jim: So Mario, if I may, just in the interest of time. I think what you're saying is there are registrars who have implemented this and um and you would be able to to gather some implementation data about that to to include in the implementation status. Is—? Okay.
Mario: Yeah.
Andy Newton: As was stated on the list, there is a difference between them wanting it and having to do it, okay? A lot of the registrars had to do it to speak to certain registries. Didn't mean they liked it, okay? So we need the registrars to show up and say they want this.
Jim: I we'll have to take this offline and discuss it further. I I honestly this is an optional thing to start with, so given that there are registrars that have done it, registries get to make this choice. It's it's just the way to do it if you do it this way. And and I don't I don't believe we can hold this document up uh based on requiring that registrars say they want it. It's just a documentation on how to do something which is optional. But I will I'm willing to let this conversation continue on the list and we'll take that further. Uh, please Martin.
Martin: Martin, SIDN. Uh, thank you Mario for this update. Um, I I do like uh having this option for EPP. I think it will help uh for deployment of EPP in more modern environments, for deployment and also tooling that's available. Um, I do have kind of an issue with the the table you presented in slide, I forgot the slide number but where you compare uh EOH with DOH and OH... oh HTTPS. I think the that's kind of comparing apples and oranges where because where DOH and O-HTTPS are inherently stateless and EOH is a stateful protocol over HTTP, there's a clear difference there, so I'm not sure if this is a fair comparison. Um, and also and also I talked to co-author Jim Gould about this already. I for me reading the the draft, it's it's not always clear what the relationship is between HTTP connections/sessions and EPP connections/sessions, how they relate to each other, how they map to each other, and I I think if you can write that down a little bit more clearly, then that for at least for me that would help a lot. Thank you.
Jim: So Martin, have you asked this question on the list or—?
Martin: Well, I gave a bunch of feedback on the list and uh I think this was also one of those, yeah.
Jim: Okay. So Mario, just in the interest of time if you could take that question on board and um let's bring that to the list uh in order to move this along. Okay?
Mario: Okay. Thank you too.
Jim: And we have now used up the 10 minutes that we actually had left over in our agenda earlier, but let's see if we can get some back. Um, Mario you are up next to tell us about verified contacts.
Pavel: Actually it's me.
Jim: Oh, Pavel!
Pavel: Yes. Can I get control of the slides, please? Okay, it just stayed. Yeah. No, it appeared. Sorry. Yeah. So, I know it's confusing. I should have been on site before I was uh going to present this this topic even though Mario's name is on the on the on the draft, but as co-author I think it's okay. So I do it remotely. Um, so uh just a recap what this draft is about. It's about putting the information about verification status of of contact data uh in RDAP, uh which is let's say uh appearing more and more a demand coming from from regulations and uh and compliance in in some um some countries. So basically we want to to have it standardized to avoid fragmentation uh if let's say uh people will start implementing it. Um, so right now we published the 03 which actually implements uh the changes that Mario announced already uh previously in the IETF session. Uh, so basically we aligned the uh data structure with uh OIDC verified claims specifications because this was let's say uh already prior work in this area and uh let's say um defining much better the the space. So, uh what we um changed is that verification may refer now to one or more claims, so previously it was only one. Um, right now the method is broken down into two fields, it's method and evidence. I will come to back that in more detail on the next slides. Um, we added trust framework identifier. Uh, we added an extension element. Uh, basically it's empty in this base specification, but it's it's there uh to allow extensibility because we see that people may want to add elements to to this this output in the latest stages. Um, and we have uh the elements which which were mentioned here actually now right now um in the JSON values registry uh with initial set of registered values uh and extensible as as possibility. And we also added a remarks element basically to have a possibility to add any textual additional info. So this is how it how it looks right now. As you see uh the claims is now an an array. Uh, the whole structure is an array, so we may have uh multiple uh verification uh objects which may refer to to different claims or these claims may overlap. So we don't put any limits on this— limits on this, and uh there are the properties which describe the verification done. There is the verifier ID, verification ID, which was already there uh before. And the remarks as I mentioned that all elements are actually more or less optional, so the implementer can choose which elements they want to implement or they want to publish or they must publish. So, the claims as I've mentioned it describes which data, data element, so basically this is the initial list. Uh, the names of the properties are derived from from OpenID. Uh, we decided just to replace underscore with with spaces to align better with with RDAP conventions, but other than that they are basically taken over as is. Uh, there is a trust framework right now we have just two uh in the in the proposal so the eIDAS which is known and the the private one which is basically saying that the verification is is done by the policy of the of the server, but uh um it may be some additional universal frameworks entered to to the to the JSON data value registry. Um, so evidence is actually the the new thing that the breakdown. So evidence is actually saying what was verified, so it can be something obvious like like ID card, but it can be can be other forms of documentation like birth certificate, utility statements, or it can be even some database lookups, so so basically the initial set of values is uh pretty pretty long, also here derived from from prior work in in OpenID. Um, the second element is the the method element which basically describes how it was done, so just here two examples saying for example there was a physical uh verification of the of the evidence or maybe a remote uh verification of the of the evidence. So why why we did it? Because now we can combine the two. So previously it was one field, so basically every combination would have to be one distinct field, and now we can combine. So as two examples here we have ID card which can be verified in person or it can be also verified remotely, and the same about the verification method that can be applied to different evidences same way. Not every combination of it makes sense of course, but we leave it open to to the people actually doing the the verification to lay down the policies, this just an output, so so basically we we don't restrict any combinations here. And uh one uh item I wanted to to bring up, um so basically right now uh this draft defines five new uh JSON value types uh say um into the registry and IANA um gave us a feedback or or the the question to the working group to the working group to consider if the JSON values repository or registry should be maybe broken down by the type. So basically uh the each section with a distinct type may have let's say reference to its originating document and maybe different registration procedures if uh the document so requires or different DEs. Uh, or at least to have a kind of additional uh registry of the types itself uh which which would have to be this references. So this was discussion that came up from from IANA and uh would be good to have uh some opinions from the working group and also whether let's say redefining the this registry belongs to to this draft because it's let's say let's say causing the issue or if it's uh rather um better suited to have a separate draft let's say making the organization of the registry. I I don't know which track draft it would be to reorganize registry, here I have personally no experience but any opinions are welcome. Thank you. Uh yeah, I I I had just one one more slide, so basically from from authors perspective this document is right now ready in the sense that uh if people think that the adoption of the working group would be possible, we would like to to ask it so on the or the putting the question reverse, uh we would like to hear if anyone sees an issue of adopting this document. Thank you.
Jim: Thank you, Pavel. Gavin.
Gavin Brown: Thank you. Yeah, I'll be I'll be very quick. Firstly, I think this is a good piece of work. I can think of at least one large ccTLD operator that already publishes this sort of thing in their Whois, so being able to do it in RDAP seems like a very useful thing. Secondly, um splitting out the JSON values into sub-registries might not be a bad idea but definitely not in this document, it needs to be something separate. Uh thirdly, I'm really worried about this "extensible extension" so you can have an extension that can be extended. Um, I think that sounds hairy and from speaking as a client I would not want to go anywhere near that. Unless you've got a direct need for something, don't do it. Just make just make something extend it some way that's extensible using the the syntax we've got already, so remarks or JSON values or something, but don't don't allow you know arbitrary JSON objects inside your object inside an object because it's a it's a rabbit hole that we'll never get out of.
Pavel: It it was not not meant like this. So so there is basically one element which is linked to a JSON JSON types registry, so basically you can add elements to it. So they are they are not let's say random objects that you can put inside it, just that people have a a clear reference from from IANA registry if they appear to see this this element.
Gavin Brown: I mean, the draft as it as it reads now doesn't really doesn't really talk about that as far as I can see, maybe I missed it. But if if you're going to if you're going to keep it in there then I think it probably needs its own separate section to discuss all of that because it didn't seem visible to me. Thanks.
Jim: Right. So, um yeah. So, Pavel do you accept that those are questions that we can bring to the list to address the three questions that Gavin— I believe I distinctly heard three different things, only two? One comment, two questions. Okay, fair enough. Um, we can take those to the list. I think the important question from the chair's point of view is whether there are any objections to adopting this document. And I'm not seeing any hands in the room that suggest that. Um, so uh Pavel, I think then the question then is to take it to the list. We're going to need to ask on the list if there's any objections to adopting it and if they're not, then we'll put it on our list of documents uh for consideration. Okay?
Pavel: Yeah. We'll we'll make a request over the over the list as usual. Yeah, thank you.
Jim: Okay, thank you. Um, next up, we have the extended key usage and mutual TLS in EPP. Um, Zaid, you're online? Do you want to speak to this? And I'm looking and he's not online. Is there anyone else who's prepared to speak to this on Zaid's behalf? No? Okay. Then um I think we will skip over that for right now, um and we'll take that to the list, the question as to to what to do with that. Um, Gavin, you're up next for your presentation. And I want to warn folks in advance, please be ready, Gavin has prepared a show of hands that he would like to execute as part of his presentation. So be ready for that when we get there. All right, Gavin, over to you. Would you like the clicker?
Gavin Brown: Please, thank you. Yeah, so um this is just um my initial thoughts on the issue that was found in RFC 9803. Um, so uh and I should I um uh say thank you in advance to the person who reported this. They came to me privately and said, I think I've found a problem here, obviously trying to you know maintain my uh dignity for making such an obvious mistake, but uh in the interest of transparency it should go to the erratum. Um, so we have this now, so we know we now know that we need to fix it. So the XML schema has an error in that uh it only allows a single custom resource record uh to be shown in info responses and in create and update commands and that's a mistake because it should allow multiple customs. Um, and uh we need to do something about that. Um, so uh when I was told about the the the the error I did some noodling in my in my Git repository for the original draft and very quickly came up with uh the the fix, and you can see it there in in green. Apologies to those who are color blind, but it's green it's the one that says @custom. Um, adding that in uh makes the selector, the unique selector, work on both attributes rather than just the four attribute, it works on four and if present, custom. Um, so to fix this, we need to publish uh an update to 9803. Um, the the new document would have the the corrected XML schema in its formal syntax section. Um, and the question I want to ask people about is should the namespace URI be updated? Should we go from ttl-1.0 to ttl-1.1? I think it should, but I want to hear from you first. Um, and here's my rationale for explaining why. Um, because it's an interoperability issue, because if a client and a server both think they're they're implementing the same version of the extension but they actually aren't, then you're going to end up in a situation where either a client sends something to a server that the server can't can't process, you get an unexpected error, or and which is probably a worse scenario, the server sends something to the client that the client can't validate, so suddenly that domain name or that object or whatever it is just becomes dark to that client because they don't know they can't validate it, they can't see it, it doesn't that's a that's a problem. So, um contradiction is this is a very small change to the actual specification for this um extension, uh but uh it is actually significant because if we don't change the namespace URI, you get this interoperability problem. So, I uh want to have a show of hands. I can see Jim's hand is up, but can we do the show of hands first and then go to Jim? Um, oh.
Jim: Yeah, I think Jim's just doing it now, there we go. And there is the show of hands poll, if folks would please take a moment, if you haven't already, please log into the room in the meeting tool, client-side, and of course all the remote attendees. Okay, so looking at the number climb a bit, yeah, yeah. So we've got what 12, 13, 18 out of 44, so a couple more please and then we get to 50%. Okay, so we've got a third. We have we have one person who says no. Um, I'm going to guess that that's Jim Gould whose hand is now down, or is he just I'm just hidden in the hidden on the screen. Jim Gould, do you want to um to offer your thoughts?
James Gould: Yeah, I I am the one that said no. Yes, you got me. Um, yeah, the reason why was I I actually mentioned this on the list that um I believe this was a true mistake. I I can't imagine that anybody would have done it the way that it was described, um and so I wouldn't I wouldn't really consider this to be a material change to the interface itself. Um, that's the reason why.
Jim: Okay. Does anyone, yeah, I mean does anyone change that had their mind changed? Anyone else has something to comment? And Jim Reed is in the queue as well.
Jim Reid: Thanks Gavin. Um, I really don't know. Uh so I'm one of the ones that's sitting on the fence right now. But my question is do we need to do this right now? Could it wait until the deleg stuff is a little bit in a better shape than it is right now? Is there any pressing need to fix it immediately?
Gavin Brown: There actually isn't and I there was a slide in this deck that I removed because actually the yeah it's questionable whether this is something we really need to prioritize right now. My presentation is really short because I don't want to waste our our time on this because I mean it the erratum is recent, so I thought it was worth talking about it now whilst it's still warm in everyone's head. But so this this issue won't affect deleg, it'll affect the thing that comes after deleg. And it took us how many what 50 years to get from zero to deleg, so who knows when the next thing thing after deleg is going to come. So this is not a I don't think this is a pressing issue but I just wanted to establish um you know what the what we think we should do and then when the appropriate time has come we don't have to have this debate again.
Jim Reid: Yeah, I mean I think from my point of view I think this is a theoretical problem and maybe there are other more pressing priorities for the working group to fix right now.
Gavin Brown: I would I would agree. Yeah.
Jim: Thank you. Rick Wilhelm.
Rick Wilhelm: Uh, thanks Jim. Rick Wilhelm. Um, one Jim Reed stole one of my questions. The other uh question that I would ask is have we had a similar situation in and before where we've had a minor glitch, minor error and what have we done previously? Have we rolled uh and tweaked the schema or have we just let it let it slide and colloquially changed it silently?
Gavin Brown: So, the the thing that's closest to this one is the issue with RFC 3915 and it was the other way around: so the schema in the XML, sorry, the XML schema in the RFC was correct but the text that described it was wrong. There was a separate issue which was the XML that was published by IANA was also wrong because it came from a previous version. Um, and IANA were able to fix the XML schema that was published on their website because that's you know in it correctly represented what was in the RFC. The issue we have is that the XML schema that's in the RFC is wrong. And I don't believe there's anything comparable to that. The only uh the other uh possible comparison is the change to RFC— the change that became RFC 5910 but actually the just the DNSSEC extension for those who don't memorize RFCs. Um, but that was quite a big change from RFC from the original 4310, I think it was. Um, and so uh you know it's not a direct comparison because the difference between 4310 and 5910 was quite big, it was a change to the schema, significant change to the schema, um and you know it was I think it was clear cut case there that you needed to change the namespace URI. Um, this is a small but it's still you know big enough I think to justify a namespace URI change. So um yeah.
Jim: Okay, thank you. Pavel.
Pavel: Uh, can you hear me? Because I have some error. Yes, we can hear you. Yeah, okay. Thank you. Um, so to the timing issue, I'm it sounds like very straightforward fix, so we should have a pretty quick turnaround on on this in the working group, I believe. So it can be pretty quick to the the the working group last call, this at least my impression about it. Um, and when doing so I would rather do it now than later before people let's say really start implementing this, because then the the burden on the implementers will be higher. I strongly believe that there are handful implementers right now about this extension because it's pretty fresh.
Gavin Brown: Yeah. No, this is the kind of the corollary to the to the um the timing question. If we do it now the the operational pain of having to migrate between two versions is much smaller because there's fewer implementations and the code is fresher. Um, it would be good to hear from people who are implementing this um or have plans to you know what their feeling about when we should do this, actually. Yeah. And actually our effort is like we bury the cost of this error not the implementers, right? Yeah.
Jim: Yeah, I I mean I have to say I'm not aware of of too many implementations of this.
Gavin Brown: So, no, two. Yeah. On the server side, on the client side, only my own.
Jim: Right. Um, so one question I would ask is are you prepared to produce the document when all of that happens? Um, I think I'm inclined unless anyone objects, I I think the answer is, you know take your comment and advice too about we don't have to do anything about this right now, but let's keep it on our list and um you should uh when it's convenient for you, I would say produce a bis document so that we have that ready, uh maybe we might think of adopting it just to have it in the queue and it's visible and it's there. Yeah. Um, and I leave that to your timing. I don't think there's any urgency. I'm not hearing any on our side for it, but at least let's get it listed and on the docket so we're aware of the issue. Yeah.
Gavin Brown: That would be good. Okay, thank you. No more.
Jim: Okay. Thanks very much. Thank you everyone. And with that, I believe I get the last presentation and I'm going to turn the mic over to Jorge.
Jorge: Okay. Go ahead Jim, please.
Jim: Um, I'm going to stand up here at the microphone just emphasize that I'm doing this as a participant and uh co-chairs Antoine and Jorge will be shepherding this document as as chairs. So this it represents the second official time we're going to ask for working group adoption coming at the end. Um, we got some uh excellent comments, um I want to give Pavel credit notably to him who sort of raised the larger question of of the narrative and what things look like. I I got a just a very short number of slides here. I'm going to go through them probably a little bit quickly, I hope. Um, and the important thing here is we have not changed our intent was not to change anything in the document. So, uh all of the technical uh details are intended to be the same, but we certainly have done some radical work on the narrative. Um, so and that was to be responsive to uh working group comments. They really wanted it in a a better uh a better narrative, um before considering adopting it. So I I hope that this uh meets the request of the group from last time. So, um very quickly, summary the changes: most notably it really is about terminology. Going back to 5730 and 3375, um we kind of did a careful look at that and we moved forward on um adopting you know terminology from uh those two documents. In terms of how we represented things. So we moved away from the way we were talking about things, we talk about a central shared central repository, um registries as defined in that document. Um, the document is intended to be based on objects generally, but in fairness we kind of left it as really focusing using the phrase domain objects. Um, there is a sentence in the document that says we use it generically, um but there's probably if we really wanted to generalize and and make this generally applicable so that other kinds of things that might use EPP could use it, um we're certainly open to that. Uh but we focused on the domain case because that's really what we've been most attentive to, um and hope it's generally applicable. We added a definition for the same entity principle. And in particular, we made that uh a registry has to define what equivalence means. Um, this is so that we're no longer talking about variants, it's just about uh an equivalent set. So we also adopted the terminology and phrasing from the last meeting. This is now called uh the same entity set, um so we're no longer talking about a variant set. Um, you know, in large part this is because we also realized it was important to have a general term because we do want this to be useful even for Latin diacritics, which are not generally regarded as variants. Variants are very particular thing which is associated with IDNs. So we really wanted a registry in an out of scope way to define a policy that declares equivalence and that's what's stated in the document. And then with that, registries and registrars can interact. We do have some new terms which we've added and defined. I do want to be clear that we uh did try to refer specifically to what's required in that registry policy. Um, they it is outside of scope of the document, but there are certain things that have to be in it in order for things to work. Um, and of course it has to be shared between the registry and registrar when both of those parties exist, then they also have to both have knowledge of what's in it and that too is outside of scope how that's shared. The assumption here is that both parties know what's going on. The important thing is the policy has to define equivalence and where appropriate it has to specify um things called options. We give examples of options and the example we give is because they are applicable to variant. Um, so when you're using this same entity thing for variant, these particular um options are useful, um and they are talked about uh a bit in some of the document as part of the example, but it's important that to understand these are just examples. Options are neither required nor limiting, so you can create more or you can have none, um but uh we will include a mechanism uh in the XML so that options where appropriate uh can be included. Um, and here's just a description of three. There's more words in the document about those three. There's a whole bunch of terms that we have now uh more clearly defined and uh tried to make generic. Um, so I'm not really going to walk down these at the moment, I I guess the important ones here are migrating to same entity principle and same entity set. Uh the rest are terms that come out in are necessary in order to use a set and the elements of the set. More details in the document. Um, I assume folks can read that. And so the important thing that we're looking for here is requesting working group adoption. Um, we have tried to be responsive to comments from before. And so the critical question from me at the moment is have we responded to the concerns that were uh offered up uh at the last meeting and if so, and without any issues, then we will ask on the list for uh working group adoption of this particular version. So that's it for the presentation.
Jorge: Okay. Thank you Jim. James, are you in the list, please?
James Gould: Yeah, I think I made this comment at the last IETF that uh I think uh there's a need to include the XML schema and a concrete set of examples for each of the commands. Um, is there a reason why that's not included at this point, Jim?
Jim: Why example XML is not there? Uh just because we didn't get to it, I'm sorry. They certainly would be added.
James Gould: Yeah, I I would look to have you add that, that way you have a concrete idea of how this is supposed to work. Thanks.
Jim: Yes, absolutely.
Jorge: Antoine?
Antoine: Yeah, hi Jim. Um, I think I've asked this question before, um but is there any guidance in the document what a registry should do when policy changes? Uh in other words, you know I've mentioned this many times, you know it's when you have two for the price of one, what happens when you cancel one of the— one of the objects? Is there an object status that that defines what you know a policy change will have for impact?
Jim: No, um the policy itself and how it's distributed and managed is outside the scope of the specification, we don't get into that.
Antoine: Okay so there's there's no status uh for for an object to say you know this is um this is an equivalent?
Jim: So if I understand your question, are you suggesting that we might want to maybe have a version number associated with the policy that's in force? I'm just making stuff up.
Antoine: Yeah, it's it's more that you know when you query for a name for example that is that is an equivalent, right? You will see that, right?
Jim: Yes, that would be the expectation.
Antoine: So what happens to that status when the policy changes?
Jim: It's not included in the document and we had not considered including that in the document up to this point because the policy and its management is currently considered out of scope, but if you think that we should explore that, I'm not opposed, but I want to think that through a little more.
Antoine: Yeah, me too. So so I guess I will be reviewing that when when the document is adopted.
Jim: Okay, that's fair. Thank you. Yeah.
Jorge: Thank you Antoine. Pavel?
Pavel: Um, yeah. So I I reviewed the new version of the document and I see uh a lot of things that I have been rising last time have been addressed, so thank you thank you for that. Uh there are still few points that I I think can be still considered too much into the policy but there are I would say rather minor things so so I think it's going definitely into the good direction. Um, I think there are some formatting issues in the document itself, like technical matter, there is a lot of HTML encoded examples which kind of make it impossible to read but I think this is a technicality. Um, yeah so this is the comment.
Jim: Okay, thank you. Um, are can I ask you just for clarity, so are you saying that you do have issues and that's fair, um but you don't object to adopting? There's nothing as a showstopper to adoption?
Pavel: I think the document is now in this in the shape that uh let's say it can be worked on by the working group, yes.
Jim: Okay, thank you and uh very happy to take on board any any questions or concerns that you have and deal with that and sorry about any formatting issues.
Jorge: Thank you Pavel. Edmund?
Edmund: Yeah, Edmund here. Uh haven't looked into it deeply, I took a look quickly uh earlier this week. Um just a couple questions. Uh one is uh I'm understanding that that these variants uh are are essentially domain objects and all the other things that you do with domain objects you can actually do, like adding DNSSEC, like creating child hosts and all those kind of things. That's a correct understanding, right? Okay. Um the the one thing that I did want to ask is right now it seems like the uh primary domain is the one that is created and it stays that way. Uh is there a way to change that or does the current sys— if it doesn't it's okay for me but uh could an extension to could it prevent an extension to allow changing uh of a primary domain?
Jim: Well I I don't know how to prevent an extension of any sort, so can't really uh speak to that. For the purposes of this extension the primary is is uh not allowed to change. Once it comes into existence then it defines the set and if you try to change it then you there's no change, you basically have to delete it and and recreate it and recreate the set with a different primary. Um and that's because we're allowing for the policy for the primary domain to set options. One of the option types in the uh that we allow for is what's called prescribed, and that's where when the primary domain is created, that primary um decides uh what certain options might be, so there's that in the policy requirements. We talk about the policy having prescribed options, um and with that you really can't change it because that changes the set.
Edmund: Right, so— but the policy I think talks about potentially changing the primary but but the answer to that is essentially delete it and recreate it, right? So that's essentially what um we are saying here.
Jim: Yeah, that would be different work from our point of view. It's it's not part of this document.
Edmund: Okay. Lastly is, uh I what Antoine brought up I think is kind of interesting, I'd like to take a little bit look at the the status part of whether there needs to be additional status things for grandfathered stuff as well. I haven't thought through it, I don't know whether you have thought through it?
Jim: Um, I have actually, a lot, but it's not in this document because I think that that's a policy issue, so it's out outside of all of this. Um, but we we believe that we have a protocol specification that will that will handle that and handle exempt is the new official term, not grandfathered, um and uh trying to be neutral about these kinds of things. But uh, yeah, I know that on the ICANN side for gTLDs, I mean all of that is there and this actually is supports all of that. Um, and Michael has done this implementation, so um, you know we know that it it works, at least in his implementation. So be interesting to see if others others do that and how that gets handled.
Jorge: Thank you, Edmund. Uh, we running out of time, but Gavin really quick.
Gavin Brown: Yeah, I put myself in the queue with no expectation that I would be allowed to speak, so I appreciate that. Thank you. Um, I just wanted to say you um you said that the primary of a set can't be changed because the policy says the primary set of a set can't be changed. That sounds like policy going into the protocol. What if you have an EPP repository where the policy says that the primary can be changed? That means they can't use this, they'll have to come up with something else. Um, I know this is opening a huge can of worms but I just thought it's worth— it may be that something you just have to reflect as a limitation, a known or an accepted limitation or something, um but you know there there will be ccTLD operators who, you know, for whatever reason have a policy that says you can change the primary um of a of a set, um so uh and they'll look at this and they'll be sad.
Jim: Fair enough. Um, you know, having been driven by by IDN variant, you know, the changing of the primary label is a deeply fundamental cornerstone issue, as I know you well understand. Um, happy to think this through some more. You know, I mean we certainly uh well you and I haven't interacted, but uh certainly have interacted with others. I mean, it just based on drawing from IDN variant, this seemed like a, you know, an obvious restriction that had to be there um and from a technical level in support of IDNs. But it's a fair comment that if you want to be able to support other things besides IDNs, maybe you don't want that restriction. I'm happy to think that through some more. Um, you know, maybe we can do something a little different or as you say, maybe that's just a limitation to this protocol and that's that's what we have to do.
Gavin Brown: It may be that allowing for that just makes the thing whole thing so complicated that it becomes impossible to define or implement or enclose within a useful scope and you just have to say this is just what we're we're working on as a as an as an axiom.
Jim: Well, that's kind of where we landed when we did what we did, um, but uh I'm happy to let that discussion happen if we can come up with something that works, I I'm all for it. I'm not opposed to uh good features that are concise, so cool. All right, thank you.
Jorge: Okay, so please uh send the request for the document adoption to the mailing list and and see what happens there.
Jim: Okay, we'll do. I think they're going to want you closer to the mic.
Jorge: Oh, okay, sorry. Uh, any other business? Nope. Pavel, are you by any chance going to say anything or that was your chance.
Pavel: Uh, me? What? Sorry?
Jim: Did you— the the issue that you brought to the attention of the chairs earlier today, did you want to say anything about that or or not?
Pavel: Uh, I was just facilitating the communication but I have no stakes or or any insights into the issue, so if the person who was about to speak to it is not here, I'm afraid I cannot help.
Jim: Okay, no, that's fine, then we'll redirect to take it to the list. Sorry to call you out.
Jorge: All right, so thank you very much, let's wrap it up. See you in Vienna. Bye-bye.