Session Date/Time: 21 Jul 2026 07:00
[00:00:14] Jim Galvin: We all ready? Yep. Yeah. Alright. Good morning, everybody. Welcome to Tuesday, day two of the IETf, if you don't count the hackathon. But it's all good. Yeah. So thank you all for coming, being here first thing in the morning on the first session of the day. I'm very glad to see all of you. You have all three of your co chairs up here today, which is also a good thing. Myself, I'm Jim Galvin, Jorge Cano, and Antoine Verschuren over on my left here on the end. So let's just get right to it. I'll always start with the note, well, Since it's already been one day past, everyone has seen some version of this. And please do take note and do your own reading and understanding of all of this. We do have a code of conduct and various other policies which define how the IETf works. And by being in this room and talking in this room, it is presumed that you have read and understand these things and that you are also agreeing to all of them. So this is something that you definitely wanna check for yourself. And as always, if anyone ever has any questions or problems, you can come to your working group chairs first, any one of us, or, of course, you can talk to any of the leadership in IETf. And we do have an ombuds team. If you have any other, you know, personal concerns, you can always go to a member of the ombuds team and speak with them too. Okay. This is our pro form a agenda. We've already done the note well, but our agenda stays pretty much the same. The details have been out on the data tracker for, the last, couple of weeks almost, I guess. So that was published on time. Anybody have any questions, concerns, updates to the agenda? Not seeing any hands, so we'll just keep moving right along here. Welcome to everyone. We will, for notes, do our usual thing. There are now built in tools for moving these kinds of things from the Notes app into the proceedings, and we will do all of that. Although Rick Wilhelm down here in front has agreed to capture actions as they happen in the room into the notepad. And please, everyone, you you can use your data tracker login to get into that right off the agenda page. Please do feel free to take notes there and add anything that you would like in there to make sure that it's in there. In addition to checking that your name has been spelled correctly whenever it's put in there. And as usual, we do try to pay particular attention to making sure we get shepherds in all of our documents that we have and do want to encourage people to be a shepherd for a document. It is a good way to get involved in IETF processes, especially for newcomers. So, you know, if you have a particular interest in the protocols in here or in any working group, you know, always volunteer to be a Document Shepherd. It's a great way to get started in being a part of how things work. So okay. Let's move on to published documents. Well, unfortunately, we haven't had any this time around, not since the last IETF. On the other hand, we have three documents which are already in the publication queue. They're all actually with the ISG at the moment, but I do know that our area director tends to stay on top of these things, so stuff is moving along. And as hopefully you will see soon enough, we expect to have quite a few more before the end of this year and up to the next IETF documents that move forward relatively quickly. So we just have a batch that are that are coming due. The RDAP extension for DNS time to live, I'll just say very briefly, you may recall we had the EPP extension for being able to manage the time to live value between registrars and registries. The extension registry for EPP, this was about providing some clarity and some additional rules with respect to how to manage the extension registry at IANA, the IANA extension registry for EPP. And you're going to see here, we'll have some discussion about the RDAP version of the extension registry as part of our discussions today. And we have another transport for EPP doing EPP over QUIC. We also still have on our docket EPP over HTTP. So that's a future work that will come around soon enough. Okay. I'm sorry? Med.
[00:04:57] Mohamad Boucadair: Oh, Med, please. Just on the on the on the previous slide. So, yeah, the the first document and the last one are currently with the RFC editor. So I think that's the the work is done so that we I think big thanks to the authors for engaging on, I would say, additional the other reviews. For the second one, there is still one pending discuss that we are, I would say, with with with Roman. This is basically about whether we we can maintain some duplicated text from the RFC 8126 in this document or not. So I'm expecting this to be, I would say, result result, I would say, in the coming weeks. So I would just to to thank the author for the the other documents.
[00:05:35] Jim Galvin: Thank you very much for that up to the minute update on the status of these documents. So very good. Okay. Moving on to administrative discussions. Very quickly, if you've been on the mailing list and certainly paying attention to the working group, you know that we have moved. We have always been part of the art area. Since our inception, EPP and Rdap were both part of the art area, and so our extension working group has always been there too. We're now part of the ops area. We have a new area director. You just met Med. I was gonna ask him to stand up, but he's already done that once now. So he is the area director for our working group. And, of course, we've had a discussion about a new charter, which you have also seen. There aren't any fundamental or significant changes to the charter, but as our movement into the ops area, they have a a new framing for how they manage these kinds of things. And Med actually had put forth this idea, which we ran through the working group, of course. And so our our charter was tightened up a bit, made a little more succinct, but we still have all of the same responsibilities that we have had before. So that's just sort of capturing for the record that all those changes took place since IETF 120. So moving forward, let's talk about three of our most interesting documents that we have on our docket. So from the mailing list, you will know that we have three documents which are related in the sense that they individually, whatever happens in these documents does impact all RDAP extensions. Normally, extensions we expect extensions to be, you know, isolated individual units. At least that's the way EPP extensions and RDAP extensions have been created and and used to date. But the RDAP extensions document is a document like the EPP extensions document that was that is in the publication queue, is intended to clarify and some ambiguities and and tighten up some of the rules around what it means to create an extension for RDAP and and to put that out there. The versioning document is exactly as the name seems to suggest. It's about proposing how to do versioning with extensions, and and it's a proposal for how to do that. And the x media type draft is about using whether or not to use query parameters or keep the extra information that you need in an extension inside the request itself. K? And just these are details about making them go. We have had quite some discussion about these three documents. There was a time a couple of years ago when we had intended for these three to come together and to be merged in some way. That didn't happen. So, also, about a year ago, we revisited that decision, and it was decided that the three documents would proceed independently and that the authors would, in front of the working group, of course, you know, make sure that they were aligned and could come together. You have seen, I'm sure, over the last couple of months, quite some extended conversation, mostly between the authors and their document shepherds on these three documents and what to do. Yesterday, chairs along with our area director, we had a small ad hoc meeting. Anyone was invited. There were a few other people there, but primarily, it was the document authors with the document shepherds. And we sat in the room really for almost two hours so that we could come to a conclusion as to what to do and how to move these things forward. We have a number of documents on our docket that are waiting for these three things to move forward and for a decision to be made. So we came to a consensus. I'm gonna verbally express what this is, but we will write something to the mailing list, write a summary. And then the working group will have a couple of weeks to see if there's any other comments or, additional insights or even an objection, for all of this that you can bring to the mailing list. And so, hopefully, we'll be able to move this along and focus on any technical remaining technical issues. So the consensus is that the RDAP extensions draft is expected to move forward pretty much as is. There's a little bit of language tightening that has to happen, but it is essentially a document which, in principle, should only be clarifying what is already document in STD 95. So since the original RDAP spec doesn't really have versioning, it seems okay to be able to move that forward as an independent document. Now it's likely that there will be a technical question about that when we start doing that and we say that that's what we're gonna do. But we'll be able to focus specifically on the technical question, and that'll come to the mailing list. The intent at the moment is that it should move forward. The versioning document clearly has a number of technical issues that need to be addressed, and those will be detailed on the mailing list going forward, but it will proceed independently. So there's a couple of important questions that have to be answered about it. Those questions will be brought out on the list. There'll be a number of technical issues that will also be brought out, but it will proceed. And, hopefully, it'll be a very specific path, and it can proceed as quickly as we can come to agreement on the technical questions that are out there. The media type draft is also in somewhat better shape. It's somewhere between extensions and versioning. It too really should just be ready to go, and it can move along independently. So we're going to assert that on the mailing list at some point. However, it is gonna wait for RDAP extensions to go first. So we will get RDAP extensions done, that document, hopefully get it out the door sooner rather than later, and then we will follow-up by moving along the media type draft. That's the way that we normally work anyway. We tend to move one document at a time through the working group last call or through an adoption process. So because we're a small working group, we typically don't have multiple things going on at the same time. But we believe that we have a plan for going forward to make these things come to closure. So any comments or questions about that? You'll certainly have plenty of time on the mailing list to dig into this. I know it's can be a lot to take in all at once. Not seeing any hands or comments. Co chairs wanna add anything? So is that enough for now?
[00:12:41] Jorge Cano: I think it's just Yeah?
[00:12:43] Jim Galvin: Okay. And so now we'll move to talking about the GitHub experiment, and Jorge here is gonna talk about that.
[00:12:51] Jorge Cano: Yeah. This is a quick announcement. We would like to offer the option to all the authors to have the ability to redact and discuss request for comments using the GitHub tools. We were working on creating a policy document in which we would like to define how we use all the tools that GitHub provides, how to take requests, how to make changes, how to ask for comments, and stuff like that. So we were working on that document. If anyone to participate in that document, please let us know. But when we have the first draft of this document, we share it on the mailing list. You can comment and request changes, and we can discuss the the final document there. And we will be using the same entity document as an experiment. This will be the first document using the GitHub tools. And so the idea here is to get it to gain experience using the the tools with these documents and come back and redefine some policy if we need to by the end of it. So if you have any comments, any questions, or would like to help to define this document, please let us know. Okay. And
[00:14:17] Jim Galvin: I think with that, I this this time. Oh, we have a question
[00:14:21] Rick Wilhelm: from the floor. This is Rick Wilhelm. Just just for clarity, there's a because it's it's not quite clear in the agenda. There's a document that's underway to to capture how to use GitHub, and it's being constructed while we work on the same entity document. So there's there's two documents. One that's did I just get that correct? So there's so there's a there's a GitHub there's a document that's gonna exist in GitHub.
[00:15:00] Jorge Cano: No. The the policy document will be in the mailing list only.
[00:15:03] Rick Wilhelm: Oh, okay. The the policy documents in the mailing list Mhmm. And the same entity documents in GitHub? It's in GitHub as it is for me. Okay. So there's okay. Got it. Okay.
[00:15:17] Antoine Verschuren: Let's see if I can get this over. Okay. So next thing on the agenda is the status of our existing work. There are no presentations for this.
[00:15:30] Jorge Cano: Oh,
[00:15:31] Antoine Verschuren: there's a question in queue. Oh, that's you, Rick.
[00:15:36] Rick Wilhelm: Oh,
[00:15:39] Antoine Verschuren: in the chat. So the expected timeline of the the three documents, in our queue, well, are actually on this part of the agenda too. So I will ask the authors if there's anything left to do during this section, Jim, and then see what they expect to be the the timeline for submitting a later version of what still needs to be done on the the document itself. Right? So please let's continue with with our existing work, and it will come up as we talk about them. So this is this is our existing work, all the documents that are in our queue. There are no presentations about this, but I will give each of the authors the opportunity for mostly two minutes to see if there are any status updates on the document itself. So the first document is JSContact. The JSContact document that's in our queue for a long time. Mario, do you want to say anything about the status? It's I think it's waiting for the extensions document as well. Right?
[00:16:54] Mario Loffredo: The most notable change since last meeting was that I added the operational consideration section as required by the new area of the working group. That's it.
[00:17:07] Antoine Verschuren: Is is there still anything to change as a result of the RDAP extensions for this? Or
[00:17:14] Mario Loffredo: But it it depends on the outcome of the discussion that we had yesterday. So Yeah. Apart from that, the document is ready to go for through the working group last call.
[00:17:28] Antoine Verschuren: Okay. Thank you, Mario. Then the next three documents we just discussed is the extensions and the versioning and the media type documents. We already discussed this yesterday for a long time. But just for clarity, is there any of the authors that want to express the status or what still needs to be done to these documents after the, discussion we had yesterday? James, I see you raising your hands.
[00:18:02] James Gould: Yeah. This is Chip Gould. For the versioning document, we posted the o six draft yesterday, and there were some additional features in there. So we're looking some for some feedback from the working group on those free features, but there is one compatibility issue that's stopping it from moving forward with the x media draft. And one recommendation at the meeting yesterday was to add a different x media parameter specific to the version draft. So
[00:18:37] Antoine Verschuren: this
[00:18:37] James Gould: is something for discussion on the list to allow this draft to be able to move forward and remove the dependency that we have to the Xmedia draft. Thanks.
[00:18:48] Antoine Verschuren: Okay. So as to Jim's earlier question, is there any expectation on what the what the timelines are for adjusting this? And probably this is not only for you, but it's mostly about the extensions draft, I think.
[00:19:07] James Gould: Yeah. I I we have those issues to address between the three. So as far as timing goes, if we're able to fix these compatibility issues, they should be able to go pretty quickly, I would
[00:19:20] Antoine Verschuren: Yep. I would expect. Thank you.
[00:19:28] Jim Galvin: Since Andy is not in the room because he's also an ISG member and so he has quite some responsibilities, let me speak a little bit to the extensions draft and the timeline issue. The intent really is to move that forward. The expected timeline is once we get the summary of the meeting from yesterday out to the list, and we'll, you know, that'll have a a two week timer on it. The intent is unless something comes up during that two week period when we're evaluating the, summary from the meeting yesterday, we will go, fairly quickly to working group last call on that document. So it'll move along quite smartly from there. The other documents have a little bit of work, so they will follow that document. So that's the expected timeline on that one and move that along. Thanks.
[00:20:16] Antoine Verschuren: Yeah. So just to clarify, yesterday, we we agreed a two week timeline to to comment on the the outcome of the meeting yesterday. And then at least the extension document is going into a working group last call. Next document up, balance mapping for EPP. Any status update on that change?
[00:20:45] James Gould: Sorry about that. I'm Jim Gold again. For the balance mapping, we posted the o one draft, which changed the equation. It's still compatible with the old one, but it uses the balance as the object as opposed to available credit. So I feel like it's a a good update. We're looking to make some additional updates to the definitions, and Werner's here, and he's helping to make those updates. And we got a posting from Jody. Thank you, Jody, by the way. With some feedback and answers to the questions that I'd raised in the list. So if there's any other review feedback, please post it to the list. But I believe we're making good progress, and, hopefully, we'll be able to get in into shape, very soon. Thank you.
[00:21:41] Antoine Verschuren: Thank you. Next documents. RDAP extensions for RPKI registration data. And he's not in the room, but I see has arrived finally.
[00:21:55] Jasdip Singh: Hi. It's Deep, Erin. So I think we are aiming to have the working group last call, hopefully, before the end of the year. We need to fill in the implementation status section and that we intend doing in next few months. So that's where we are.
[00:22:13] Antoine Verschuren: But So so do do you get enough support also from, you know, non not not RDAP participants to look at, you know, the RPKI part of the Yes.
[00:22:25] Jasdip Singh: Yep. So the RPKI community actually gave really good feedback. So my request to and we recently published the draft. It was more of a touch up. But to the regextt working group, because it's a specialized area, please, if you can look at it from regular RDAP constructs perspective, We also are trying to follow the RDAP extensions guidance, but that's where we
[00:22:54] Antoine Verschuren: are right now. Thanks. Okay. Thank you, Jasdip. Then the next document, explicit RDAP redirects. Is Gavin in the room? Yeah. Gavin oh,
[00:23:08] Rick Wilhelm: I am remote. Yeah.
[00:23:09] Gavin Brown: I'm remote. Yeah. Hello, everyone. So, yes, there's been some discussions on the mailing list following on from version four that was published a few weeks ago. We have a few extra issues that we need to address that we're tracking in GitHub as it happens because we use GitHub and Unite to to manage this document. And I suspect we'll need a few more versions to to resolve all of those issues, but I think everything else being equal, we should be ready for last call for this in know, by the end of the year, certainly.
[00:23:47] Antoine Verschuren: Okay.
[00:23:47] Gavin Brown: But no nothing else to add.
[00:23:51] Antoine Verschuren: Yep. Thanks, Kevin. Any any questions from the room about this document? If not, then we saw that the transport protocol over QUIC already proceeded to the IESG. The the a similar document was the transport protocol over HTTPS, and I see James Jim is already at the mic. So do you have any status on that?
[00:24:17] James Gould: Yeah. To provide an update, we met with Mark Nottingham at the last ITF to address his feedback, and we posted the o three draft that included an operational consideration section to address his feedback. We received responses to his recent review of the o three draft, and we're meeting with him later this morning. So the hope is that we'll be able to fully address Mark Nottingham's feedback to be able to move this document forward. Thank you.
[00:24:54] Antoine Verschuren: Okay. So that's proceeding along too. So I see you met in the q two. Do I have a question
[00:24:58] Mohamad Boucadair: over here? Just on this one. So I I'm hearing that the there's already engagement with them. So, Mark, about to address the comment from the HTTP director and so on. So that's something which is really great because in the new charter, if you didn't put attention on it, we committed to be compliant with the BCV-fifty six. So every specification coming from this working group has to make sure that we are aligned with that one. And there is another aspect which is relevant to the transport part is that before in order to send the document to the IG for, I would say, for publication for transport matters, we need to have at least commitment from one registrar and one registry for deployment. So I guess, for this case, we have we have at least one deployment in both cases. So, yeah, just make sure that we have that in in on the record before proceeding with the with the publication. So each time, please, when there is a specification related to the transport matters, make sure that we have alignment and adherence with these two part from the new charter, please. So thanks.
[00:25:59] Antoine Verschuren: Thank you on that one. Then moving over to the next one, domain registry grace period mapping for EPP, and I see Gavin remote in the queue already. Gavin, any update on this one?
[00:26:15] Gavin Brown: No updates to give. No.
[00:26:18] Antoine Verschuren: Okay. So it's moving along quite well, and I think it's it's still early in early in the process. Right?
[00:26:25] Gavin Brown: Yes. Quite early in the process. Yeah.
[00:26:27] Antoine Verschuren: Yeah. And then the last one, using JSContact in order JSON responses. Mario, do you want to do you have any status on that one? Is it it's your document. Right? It's the last one in the queue.
[00:26:47] Mario Loffredo: It's the last one.
[00:26:48] Jim Galvin: It's on the it's a duplicate.
[00:26:50] Rick Wilhelm: It's Oh,
[00:26:50] Antoine Verschuren: it's a duplicate. Ah. So so you did a chair slide, Jim. You you you confused me. Okay. Thank you. So those are all the documents in our queue without presentations. So we're moving along now to the next item item, which is the existing documents that have a presentation. I think we have only one, and I'll let George manage the re the the presentation parts.
[00:27:21] Jorge Cano: Alright. We only have one document from Jim. Let me share your slides.
[00:27:29] Jim Galvin: Okay. Thank you.
[00:27:31] Gavin Brown: No.
[00:27:33] Jim Galvin: You can change the slides. There's only two of them anyway.
[00:27:36] Jorge Cano: All
[00:27:36] Jim Galvin: right. But we can leave it on the title side for just a moment. Yeah. We we had quite some little bit of faux pas, little little hassles in in trying to get the a revised version of the document out. So it's a zero one out there, but it only got published on Friday, which was actually even after the deadline of the week ago Monday. But we were having some issues trying to get the the GitHub that it's in now to submit the document. Anyway, part of the thing here is we're all sort of novices with well, Jorge is not. That's why he gets the job of managing what the working group is gonna do with GitHub. But, even my auth my coauthor and I on this particular document, you know, we're sort of GitHub novices. So we're sort of working through the processes ourself and figuring out how to make it all work. The document does exist in the GitHub. We're going to move that, And I apologize for that. But I also since it was not published really early enough for this meeting, I have no expectation that anyone has really actually looked at it. So this is gonna be a very short presentation. Happy to take any questions that you have. But we just tried to move it along from the last IETF. So next slide, please. What we did was, as you know, we only just adopted this draft at the last IETF. So since then, it was actually adopted in May. And then we published a zero one draft, and this is the set of things that we've done. Most notably, it it sounds like it's a little thing, but it actually was a big deal to change the title. This used to be domain variant support in EPP, and we have generalized to supporting, same entities. Right? And this distinction here is important because it's intended to support not just variants, which have an obvious equivalence relationship, but also Latin diacritics, so domain names that use Latin diacritics. And it allows a registry policy to define equivalence between names, whatever or an equivalence between objects, actually. So even that is to be generalized in the document. Document currently has a focus on names, but it should work with any object. You can define a policy to define equivalence amongst those objects, and then you can use this protocol to support all of that. The obvious candidates for support are IDN domain names and domain names using Latin diacritic marks. So that was a big change, and there's a fairly large amount of editorial work throughout the document that went into making that change and have that change make sense and carrying that forward. We also added two new sections. You've certainly heard a couple of times prior to adopting this document about the architectural and technical principles that are guiding and are the anchor for the work that we're doing here in this document, in the proposal for the protocol. And so we added those sections to actually describe all of that. And so there's a fair amount of text that went into explaining the architectural and technical principles. So I encourage you to take a look at that and just confirm for yourselves that it matches what we've tried to say before and certainly matches what we really want to do going forward. There's a lot of, expanded text throughout. We certainly have had multiple conversations here in this group about what stuff means and and what it is. So we certainly have tried to respond to that and add a bunch of text in different places, to help expand on what we our proposal here for the baseline for how things are gonna work and what this means. And then, of course, we've had multiple requests and always our intention to include XML schema, so there is some in there. I don't think the XML schema is finished yet because one of the things that has to happen is so next slide, please. As we now move forward and look for completeness and ensure that we have covered everything and that operationally all the details are covered, And this is where we're really depending on the working group to dig in here. Certainly, Michael and I have we both run registries. We're both deep into the IDN and the Latin diacritic work that's going on in ICANN, so providing a protocol that's going to support those policies. We're relatively deep into that, but we need a broader view. So we need a much deeper view from different people. This is the right community to do that, especially CCTLDs, those that support multiple languages and scripts. We really need for more folks to take a deep look at whether or not the individual commands and transforms are complete. Then as Jorge was saying earlier, we will move this work to the IETf GitHub. One of the things we have managed to do was to get this working group assigned, in GitHub terms, an organization. So there's now a regext organization in the IETf GitHub so that we can migrate this document to it. Have Michael and I have volunteered to put our document there. This working group has never used GitHub. We're going to put our document there so that folks can see it. You all have ready access to it. We're going to figure out how to do it. We'll take advantage of the issue tracker there. We're keeping track of the document. And then, as Jorge said, he'll be leading and managing drafting procedures and policies for the working group going forward. So please do be gentle with us as we learn how to make GitHub work. We've clearly already had some issues, but we're going to get past all that. And then we'll see. It's either going to work for us in our document. It'll either work for the working group or not. But that'll be a separate thing that's happening in parallel is figuring out how we wanna use it. And then another major work item to happen here is if what new result codes new result codes new result codes, I can say it, really, codes we want to use as part of this new extension, because clearly there's some additional information that needs to be conveyed back and forth. So we'll be sorting all of that out. We kind of have a picture in our minds of what that's gonna look like, but we haven't written it down yet. And certainly, I'm sure there are folks here who will have opinions about all of that. So we'll want to move this forward under the working group. That really is all of my presentation. And, wow, we already have two people in the queue. I guess, Jim, you're up first.
[00:34:25] Jim Reid: Yeah. Thanks. Jim. First of all, I don't like the use of GitHub, but that's that's a separate issue completely. I I really think the IT is making a big mistake using GitHub. That's a
[00:34:37] Jim Galvin: good comment, though, you know, because we have to take that on board. If the working group doesn't wanna use GitHub, that's that's fine too.
[00:34:43] Jim Reid: Well, you know, I'll I'll just go with the flow. But I think it's a I think, fundamentally, it's the wrong thing to do. However, the point I was to ask is a question of clarification. You're talking about this work in the new variants, but the similar strings for the TLDs using diacritics and equivalents. Is there any pressure from ICANN for a timeline for this? Have they got an expectation that this work will be completed in this working group by a certain time frame? I'm thinking perhaps this may have something to do with the next round of GTLDs, for instance.
[00:35:18] Jim Galvin: So pressure from ICANN? No. But pressure from me as an individual and my employer, who certainly wants to use IDN variants and and GTL diacritics, that's where the pressure is coming from. Okay. I will offer that variance at the second level and Latin diacritics are actually not included in the next round that's coming right now that's in progress Because there's no the policy isn't done, and neither is this particular technical standard.
[00:35:52] Jim Reid: Okay, Jim. Thanks for that. I was just concerned there may have been something at some part of the ICAN machinery or discussions of community that they were having some expectations about when this work would be completed by the working group. And that's clearly not the case. Thanks.
[00:36:12] Jim Galvin: And Antoine, please.
[00:36:13] Antoine Verschuren: Antoine is here. As a working group participant, not as chair. Jim, we had quite some discussions on this document, the both of us, you know that. And we were talking about, are we missing any capacities in this working group, especially because the working group needs to realize that the most difficult thing about this draft is not the domain name or the variance part or the the EPP extensions part. The most problematic thing in this draft is the p of provisioning, where if you need to define a two two products that are represented into one that's a generic provisioning question. How do you handle things like when I want to cancel one of the domain names and not the other one? And how do I tie these? What's the unique identifier of that product? That is, in in my opinion, the the most difficult part of of of this draft. So I have two questions, basically. Do you envision that that part of the question will be in another document or do you intend to still cooperate that in one large document? And the second question would be a question to the room and say and ask perhaps even a show of hands of how many people are experienced in the generic provisioning area to understand what this means to a process. So first question to you, Jim. Do you envision that there will be a multiple documents, one doing the generic process thing and one for the support of, for example, variants? Or do you want to have that in one document?
[00:38:17] Jim Galvin: I think it's just going to be the expectation at the moment is there will be just one document that is going to, support any definition of equivalence that a registered policy wants to set. So the document is actually under the technical principles, you want to go back and and look at that, very clear about the restrictions that are important. So there has to be this notion of a primary object, the first thing in the same entity set. And this document talks about the requirements on the definition of equivalency. So you can talk about the status, and options about the objects, and the equivalence policy has to state what that is. Now we know what that's going to be. We know what was what would work for variants and what works for Latin diacritics as currently being defined for GTLDs and ICANN. So we're covering that. But the protocol is intended to be very generic. Yes. And that is our that is our goal to not be limited by that policy specification. It is to support that and whatever other policy, whatever other equivalence definition you want to make. So there are some guidelines about what that equivalence definition has to look like. But otherwise, it can be anything that you want. And that would be outside the scope of both this document, this working group, and, in fact, the IETf. It's intended to be a a policy statement. So it's not something that we would cover directly.
[00:39:55] Antoine Verschuren: Would you like me, Jim, to to ask the question in the room for a show of hands of how many people are comfortable with the generic provisioning question? Absolutely. So let's let's create a a question here. So how many people
[00:40:17] Jim Galvin: do Poly's typing the question, I should probably say. I wanna very clearly state that I am separating my responsibilities as chair to be a participant as part of this document is concerned. So Jorge and Antoine as chairs will be wholly responsible for managing this document's process and and movement forward. Do you want to take the question while you're typing?
[00:40:41] Antoine Verschuren: Yes. So so so the question is actually to the room, how many people in the room feel comfortable comfortable enough to have enough knowledge about generic provisioning question instead of just domain names and EPP, right?
[00:40:59] Jim Galvin: No. I mean, did you want to take the question at the mic? Or do you want to wait Yes. Until you do your
[00:41:03] Antoine Verschuren: Ulrik is in the Q2. I see that. So perhaps we'll let Ulrich start first and then put the question.
[00:41:10] Ulrich Wisser: Yeah. So this is Ulrich. Wissarf from my can, not speaking for my can, obviously. I just wanted to ask, there's a few registries that already have equivalencies. Have you talked to them? Yes. Because they're not all in the room. You know?
[00:41:28] Jim Galvin: Yes. And and we are trying to make a point of doing that. There's also a number of documents which talk about equivalency of names and stuff. One of the things that's important to separate, though, is we are focused on equivalence in the provisioning side, not equivalence on the DNS side, which is also something which has been tried many times. We know it's something which really can't happen and can't work. We're not addressing that at all. No. No. I I
[00:41:55] Ulrich Wisser: was just thinking it because there is registries that obviously offer this already so that it would be, you know, a good idea to make the extension also work for those. And, you know.
[00:42:07] Jim Galvin: And some of that is documented in in other RFCs. My coauthor actually has is one of those registries who, in fact, has done definition and and an implementation and has deployed the use of support for variants. And he is going to migrate his work to be what's in this draft. Whatever this draft becomes, he's going to move his implementation towards it. So one of the things that's on our list of next steps is an analysis of those other related documents and and related registries. So I know that they're not in the room. This working group suffers from that a fair amount sometimes with some of the stuff that we do. We do have to make an active effort to reach out to people and see if we can get some review of what we're doing, and we will do that. Of course, if you have pointers to anyone you wanna make sure we cover, please do let me know. You know how to find me. Let me know.
[00:43:01] Mohamad Boucadair: So
[00:43:03] Antoine Verschuren: I put the show of hands in the in the in the in the tool. So if you can please ask the question. If you feel comfortable enough, that will give me the opportunity to ask Jim the question of do you do we want to do you envision that we need to involve people outside the working group? Right? So that's the question you can prepare for. And then, I see Jody in the queue in the meantime.
[00:43:31] Ulrich Wisser: This is Jody. Can you can you define generic provisioning? I guess I'm getting wrapped up in the vocabulary here. I mean
[00:43:38] Antoine Verschuren: So this has nothing to do with domain names or EPP or Rdap or whatever. It's just the the the concept of how do you process a request in an automatic provisioning system, right? So I always give the example of salespeople often want to have a product like, sell you two iPhones for the price of one. Right? And then the question is, how do you register that product? Is it the serial number of the first iPhone? Is it the serial number of the second iPhone? Or is it a new unique identifier that identifies that product? Sure. Right? So it's it's that generic provisioning, area, where I think we often don't have enough expertise.
[00:44:32] Rick Wilhelm: Okay. I got it. Thanks.
[00:44:41] Antoine Verschuren: So I'll give, another ten seconds for you to answer. It seems like people are comfortable enough. First show of hands.
[00:44:56] Jim Galvin: Okay. So Of course, only half the people in the room responded to the poll. But But there is
[00:45:02] Antoine Verschuren: a clear, you know, consensus in consent. There there's a clear answer from the room that they feel comfortable enough to, to discuss this. So that also helps you, I think, to determine whether or not you need to seek, additional, expertise on this.
[00:45:19] Jim Galvin: Sounds good. Thank you.
[00:45:20] Antoine Verschuren: And then we have Martin. Martin in the queue.
[00:45:24] Martin: Yeah. Martin, I said it. I just wanna add in. I'm not sure if the question is being comfortable with generic provisioning. For me, it's more that this this draft describes a process that's pretty pretty different from normal EPP operations. That's why it falls out of the normal scope of things that we work on, and that makes my brain hurt. So so I'm not sure if the question is is the correct question. Thank you.
[00:45:58] Jim Galvin: No. I'll I'll acknowledge your point and just say, it's my brain hurt too. Trust me.
[00:46:02] Antoine Verschuren: So my answer to that would be, Martin, if you don't know what the question is about, you probably need to say no.
[00:46:09] Jim Galvin: Yeah. I mean, it is true. The thing to keep in mind is EPP is operates on individual objects. Fundamentally, at its core, that's what it does. It it provisions individual objects. And so this really is a a big change to the EPP sort of concept because now it's about sets of objects. And so that's a big deal, and it's a lot to think through. And trust me, we spent quite some time thinking through all of this before we actually wrote it down the first time. Doesn't mean we got it right, but at least we've given it some thought. And we now are asking for others to think about it too because it's a pretty big deal.
[00:46:49] Jim Reid: Jimmy, just another random bozo on the EPB bus. So a question of clarification, Jim. You're talking about perhaps engaging people from outside the working group. What sort of communities or organizations do you have in mind for that sort of additional support or input from? Are we talking about ICANN, the center community, our ITF working groups? Where do you see that help coming from?
[00:47:20] Jim Galvin: I'm just imagining talking to other domain registries, quite honestly. That's the first place that I'm looking to go. And I'm not starting from IETf or ICANN, just reaching out to registries directly.
[00:47:35] Jim Reid: Okay. Thanks.
[00:47:37] Jorge Cano: Yeah. Thank you, Jim.
[00:47:40] Jim Galvin: I'm certainly open for suggestions on on from anyone on on who you think we should talk to. You know? I mean, in in from the principle of wanting to ensure that we cover as many bases as possible, I'm just generically reaching out to people who wouldn't ordinarily pay attention. I'm not even asking that they change to what this specification is, Because if they're not using EPP or if they're using EPP but they're not really paying attention to the IETF, can't really obligate them to change. But it would be good to know if they think that their needs are covered by this or would be covered by this? That's really the question that I'm asking people. So I'm hoping to learn from that, but we'll see.
[00:48:28] Jorge Cano: Alright. Any more comments? Any questions? I don't see nobody in the queue. No. Okay. Thank you, Jim.
[00:48:37] Antoine Verschuren: Thank you, Jim.
[00:48:38] Jorge Cano: Alright. Moving along. Now we have new work presentation. The first one is Gavin. Let me share your slides.
[00:48:58] Gavin Brown: Okay. Okay. Do I have slide control,
[00:49:02] Jorge Cano: or should I just ask You should have control now.
[00:49:05] Gavin Brown: I've got it. Yeah. Thank you. Okay. So, yes, I'm presenting a new document. The title here is delegation maintenance automation status extension for EPP. So just to set the scene, there is a document that's very soon to be published as a best current practice called operational recommendations for DNSSEC delegation signer DS automation. And this is guidance to parent operators, I. E. TLDs and others, how to deploy scanning for CDS, CDNSKey, and Csync. Well, look, primarily CDS and CDNSKey scanning so that you can automate the maintenance of secure delegations. So the child publishes CDS, CDNS key records, and the parent pulls them, validates them, and depending on the outcome of that validation and provisions DS records in its zone in order to maintain that secure delegation. And then there is a separate document, IRC seven thousand four seventy seven, which describes C Sync, which is essentially the same thing, but for the NS records and Glue that's applicable for that zone. So, again, a child operator can publish a c sync record, and then that is a signal to the parent operator that they need to update the delegation information. So these are both ways of managing delegations and other provisioned objects in a registry or other, you know, parent entity that goes outside of the traditional registry, registrar, registrant model, where the DNS operator talks directly to the parent operator and maintains those records. There is a another document, r c nine eight five nine, it's called generalized DNS notifications, and that's an optimization on the traditional kind of whole zone scanning that registry operators do. So the registry operator publishes in the DNS the location of an endpoint where the the child operator can send a notify message, and the the protocol is designed such that there can be a single endpoint for that entire parent zone, or there can be individual endpoints for each delegation in that zone so that if, you know, registrars want to provide that endpoint, then they can do so. And that notify message triggers the scanning so that doesn't need to crawl their entire zone every with a bullet for frequency. They need to in order to make the system work efficiently. It will will do it just on the basis of receiving your message, and that that obviates the need for all that scanning. One of the things that the new RFC, which as Med has pointed out, is just about to be published as one double o two six. It says, when performed by the registry, automated DS maintenance must not be suspended based on a registry update lock alone. So that means that if the domain name has the server update rewritten status in EPP, maintenance should should continue unless there is a a reason otherwise. And there are a few different reasons why domain name may have this status code. Firstly, there can be simple sort of administrative administrative security. So when I was working at a registry, we we we added this status code to every nick. Domain in our system just to prevent foot gun situations where we break a TLD by performing an update on a domain name inside it. Domain names that have are subject to a dispute resolution process can also have this status code. And the third and probably the most common use of this status code is as part of a registry lock product that's being purchased for a high value domain name. Now the the wording of RC1OO26 does allow for a registry operator to suspend DS automation in accordance with his own operational needs or policy. So in cases one and two there, it's it's no but there's no I don't think there's any issue where a registry decides that they're not going to perform scanning in those situations. But for the third case where we have a registry lock, it's not necessarily clear whether a DS automation should happen. It depends very much on what the registrant is expecting to happen because many registrants purchase a registry lock expecting that their domain name to be frozen in ASPEC and never changed unless they give explicit approval by, you know, fax written in blood to to your and and, you know, signed by your firstborn, whatever. And there's a very high expectation that then nothing ever changes. Even sort of background automation should not happen for this domain name. And what we've also observed here is that many third party DNS operators publish CDS CDNS key and CC records. The register and the customer has no idea that this is happening. Registry of the DNS operator may may turn it on without telling its customers, and that may cause changes that the the customer was not expecting. So the conclusion that we come to from this is that, ultimately, it's the registrant that should decide whether or not DS automation and DNS automation in the case of C sync should actually happen when a domain name has a registry lock. So this is what we're proposing as a solution to this problem. Basically, the sponsoring client of a domain name should be able to specify whether the server should perform DSNS automation. And there are a couple of reasons why they may want to do that, partly because they maybe because they have a product, a registry lock product, isn't the way it's marketed and understood by the customer is something that prevents such things from happening. But also maybe because they want to do the scanning themselves, because they already have a scanning endpoint or a c sync endpoint or something, and so want to be able to turn off registry led scanning for that domain name. And the so so the idea would be that there would be an automation state applied to that object that would be independent of the lock statuses. And that's what my new document describes. So it is the the title here is, yeah, delegation automation extension. It adds two new elements to the domain mapping. And I should just quickly thank Peter Thomason for his early feedback, which prompted me to add two separate stages, one for NS automation and one for DS automation. These are included in info responses depending on whether the server implements those, the two different models. So server just implements one, then you only see one. And if the server implements both, then you see both. And then the document describes how you extend the create and update commands to to set those status flags. And document also describes new RDAP status values that can be published in RDAP responses. I don't know, Jim, if you want to ask a question now or yeah. Jim Gould?
[00:56:53] James Gould: Thanks, Gavin. Yeah. This is Jim Gould. You know, when I read this draft, the first thought that went in my head was, I thought the server could already do this. So, you know, when you read the RFC, it talks about who can manage the statuses, but it doesn't say who is prohibited from making a change. So when there's a server update prohibited status set on the domain name, that prohibits the client from making updates. But there are many updates that automatically occur on the server side that are not prohibited. So I'm not exactly sure whether or not this is needed, but I could be wrong. So thank you. Okay.
[00:57:39] Gavin Brown: Well, so so my feeling is that it is needed because, as I say, there isn't uniformity in the way that, for example, paid registry lock products are marketed to the customer and the way that they're understood by the customer. And so there is, I think, a need to provide a way for a sponsoring client of a domain name to to say to the registry, please don't scan this domain or please do scan this domain. So that that, for me, I think, addresses that concern. So here's an example of what an info command looks like. This is straightforward extension with two child elements with just a single enabled Boolean attribute, one for each type of automation. And very similar create command and update command, just setting the two values according to what's required for that object. For Rdap, define four new status codes. Jim Reid, I see you in the queue. Do wanna ask a question?
[00:58:48] Jim Reid: Thanks, thanks, Calvin. I'm sure you're aware of the work that's being on in DNS. There's a really nice idea from Johann Stensam about using session-signaling notifies to so that the child's children can inform the parent about a change in, for example, keys. And I wonder if you've given any thought to incorporating that into your draft. It looks to me as if that's a nicer solution and might do away with the whole need to do the c sync c sync scanning stuff.
[00:59:16] Gavin Brown: So there is with the with with with what what's been proposed in DNS op, there is the issue that the well, I mean, it's not an issue necessarily. A dynamic update could include changes both to the NS records and the DS records for delegation. And I guess this the mechanism that I'm outlining here could allow the could provide a way for the sponsoring client of a domain to control how the server processes those updates. So it may decide on the basis of one of these flags to decline an update that choose that that updates a DSRNS record for delegation, but except one that doesn't update. So if you if if a domain was set up so that it allowed DS automation but didn't allow NS automation, then an update that came came from a parent op a child operator that said, change the NS and the DS would be declined. But if it was just an update to the DS record, then it might be accepted. So this the the this the signals that that are exchanged between the the client server in this this proposal would be applicable in a scenario where a dynamic update is going from the child to the parent.
[01:00:38] Jim Reid: Yeah. Sorry to get to be generalized. Is that the proposal that's in this draft isn't involving dynamic update. It's a session-signaling notify. So the child speaks to the parent, hey. There's a new key. Come and get it.
[01:00:57] Gavin Brown: The I thought what was proposed in DNS was that there would actually be an update with the payload.
[01:01:01] Jim Reid: No. It's not an update.
[01:01:03] Antoine Verschuren: Okay. It's
[01:01:03] Jim Reid: a signal from the child to the parent to say, I've got a new key. Come and get it.
[01:01:09] Gavin Brown: Right. I see. Okay. I'll have to have a look at that then. Thank you, Jim. I'll I'll have another Thanks. Yeah, we have these new status codes that would map onto the to the the the Boolean values of the of the attributes. This is what it would look like in an RDAP response. Nice thing about this is because we're using status fields, we just need to register them in the JSON values registry. No need for an extension. They just appear straight in the status status array of the RDAP response. So in terms of next steps, I think I would benefit from a coauthor on this. If there's anyone in the working group who's interested in in helping me out, please get in touch. And at some point in the future, I'll be asking for working group adoption. So any further questions? Any more questions? Comments?
[01:02:08] Jim Galvin: There is one in the chat.
[01:02:09] Jorge Cano: There is one in the chat. So,
[01:02:13] Jim Galvin: Gavin, there is a a question in the chat which I wanted to read out asking how this would work when you were talking about the status, how this would work if the domain is transferred to another registrar. Does the setting following the follow the domain over to the new registrar? That's from Christian Orman, for the record.
[01:02:32] Gavin Brown: Yeah. I don't I don't know the answer to that question. I think I that there may be a policy there may be a policy thing. My feeling would be that it generally, with with with interregistered transfers, nothing changes about a domain name. So transfers in and of themselves don't change DS records or contact information or name servers or so on. Often, the registrar gaining registrar will make changes, but I don't think the the transfer itself should change things unless unless a policy says otherwise. And Ulrik?
[01:03:07] Ulrich Wisser: Ulrik? Hi. This is Ulrik from. Well, I would just wanted to say in DNS updates, both. There is sending a notify to be forgetting scanning, and there's also dynamic updates. So there's both versions in the DNS op. And then for the changing of registrars, I wanna say, usually, registry lock doesn't follow a registrar change because that's one of the things that registry lock is supposed to to stop happening. Right? So, usually, you have to remove the registry lock before you make a registrar change. And, obviously, then this doesn't make any sense this configuration doesn't make any sense any longer if you don't have registry lock. So
[01:03:53] Gavin Brown: I mean, one thing I want to say is that this extension is it tends to be orthogonal to a registry lock. So it wouldn't solely be used in the case where a domain has a registry lock, but it but it's probably more useful for domains that have registry lock. Thanks.
[01:04:08] Antoine Verschuren: Yeah. So you you basically already answered my my question, Gavin. So indeed, is this a more granular form of registry logs, but then specifying what you allow and don't allow. Right?
[01:04:24] Gavin Brown: Yeah. No. It's not it's not intended to do that at all.
[01:04:26] Antoine Verschuren: Okay. Any
[01:04:30] Jorge Cano: more questions? Okay. If you have any more questions or comments, please send it to the mailing list. Thank you, Kevin. Okay. The next one is from Alexander. Let me share your tech.
[01:05:01] Antoine Verschuren: Yeah.
[01:05:12] Jorge Cano: Alright. And the clicker is
[01:05:17] Silvano Romano: yeah. So this is not Alessandro. This is Silvano Romano. Actually, Alessandro is my co author. And since I was here at the ITF, he he was just seizing the opportunity of asking me to present on behalf of the two authors. So basically, this is an idea about a new extension for Rdap. Upfront, I would like to say that this is an experimental draft, an individual draft. This is not asking for any new working group item adoption today, neither, let's say, adoption from the working group. It is basically about requesting for some feedback from the community. And the idea is a very simple one. It is depicted in the right most part of the slide. It is about carrying some reliability scoring information inside an Rdap response, basically by associating this with either a domain object register entity. The idea is to carry the result of an assessment and not just the not also the methodology that brought to such a result. So it's really, let's say, clearly separated thing in terms of concerns. Actually, this comes from the rationale behind this dates back to some research that we have been conducted during the last few years in the security area. We have presented some results at deep sec last year here in Vienna. But the thing that I would like to surface here is that as part of our reasoning, after conducting such research, we thought that there was a need for somehow standardizing the way you can report about the the reliability of either a domain or let's say, a registrar. What we found out is that the typical issues that we discover are not associated with the ecosystem itself in terms of protocols that are used. So if we think of SPF, DKIM, DMARC, DNSSEC, and the like, these are all good. The issues that we find typically come from the way you configure and manage the entire ecosystem. So I'm reporting just for empirical motivation in the box in the right, some data that we have reported in our research about a a multitenant domain that was managing emails for customers and for which we were able to discover more than 70,000 spoofable cross tenant issues, which were, let's say, associated with even domains that that configured the the right policies in terms of securing the the email itself, but which were not managed in the right way. And so we're talking about, let's say, credential recovery procedures, identity verification, and email authentication as a whole. So this is not the subject of the draft that we are discussing, but this brought to that draft. Because we thought that there was a need for, let's say, a common machine readable way for exposing the results of an assessment about deployment of a domain or of a a registrar service. So basically, if you ever look at the draft, you would find that this is really about proposing this structured way of representing the results of an assessment. It standardizes how the results are transported and not how they are computed done at all. And it is associatable both to domains and to registrar entities. And we tried and made it a 100% compliant with the current spec of the RDAP protocol. So it is a 100% compliant with RDAP core. And the feeds that we have defined are individually optional. So basically, the data model is reported here. It's not a complete example. I have a backup slide with the complete example at the very end of the presentation if needed. But the idea is that we can carry a reliability scoring envelope inside an RDAP conformance object. The semantics of the reliability scoring envelope are defined in a further set of data, and in particular, in the score scheme that is a URI or a, let's say, a generic identifier of the methodology that has been used in order to arrive at the assessment itself. And it also defines the semantics. And so basically, what you find there is the value that has been computed. In case there is a max value for the score, you also find the max value, a date, who has issued the assessment, and an evidence URI that can point to more information about how the entire assessment ecosystem has been used and configured. Obviously, there is existing work. We identified at least three related areas of interaction. The very first one is the verified contacts draft from Mario Alfredo. We do believe that our proposal is 100% orthogonal to this one because, basically, we're trying to answer a different question that is about the, let's say, assessment of the security posture of the object that we are providing the answer for. There are other things that are of interest. There is the AIP initiative and the quality performance index initiative from PIR. Obviously, in this case, we're talking about an ecosystem. So a way for arriving at the the score, the assessment. So we're not at all, let's say, messing with this, but what we think is that we might carry the results of such an assessment in a way that is conformant and it which is, let's say, capable of being carried within an RDAP response. And once again, related to Rdap, the proposal is entirely compliant with the core of the protocol. We try to also stick to the latest requirements in terms of how you use underscores when you're allowed to do that. We are not you are not allowed to do that and so on and so forth. So basically, we are reusing the JSON format associated with the extensibility model. And that's basically there are no protocol changes. So it would be nice, first off, if some of you reads the draft. We try to make it as complete as possible. It is not the long draft. It just contains this set of information. We would like to know whether or not, first off, you believe that the the scope and fit are the right ones if rejects this right working group for discussing this. Then about the namespacing, what I was mentioning before, how we use the identifiers and define them, and if we were able to stick to all of the rules that have been defined for Rdap. Obviously, from our side, doc sorry, document status is experimental. And it is, as I was saying, really an individual effort as of now. About the trust model, we try to separate concerns as much as possible. So we clearly state that score issuer, score scheme, the ecosystem that brought to the assessment, they are 100% out of scope with respect to our proposal. But, obviously, we discussed some potential security and privacy issues in the draft, and we would like to know whether or not you believe that the discussion is complete enough. And so that's basically it, whether or not you think that there are superpositions and clashes with other documents that you discuss in this group. And I would say that's it. Let me just thank the people who got involved with Alessandro and with me. It was around ITF-one hundred twenty five. We also tried to somehow hijack the session and present our idea at the very end of the session itself, but we did not manage to do that. And so we started a more formal process, and that's why I'm here today. And yes. Thank you. That's it.
[01:15:01] Jorge Cano: Okay. Comments? Questions? Okay. We have two people in the queue. James, please.
[01:15:16] James Gould: Yeah. Do you see this as being supported by the registry RDAP servers, the registrar RDAP servers, and where do you see the scoring being done? Is this an independent agency that, you know I I I don't see where this would link in.
[01:15:35] Silvano Romano: Yeah. This is the tough question, actually. Yes. We believe that this might either be something that is carried autonomously by registry services or by domain owners. But as well, this might be a service that is offered by third party services and even if you want certification authorities in some cases. I do not want to go into, let's say, too much complicated areas like governance or the like. But all of that is feasible, doable. And the reason why we really want to keep entirely separated the way you transfer the information from the way you arrive at computing that score is associated also with that. But, yeah, it's complex.
[01:16:31] Jorge Cano: Right. Martin, you're next in the queue.
[01:16:33] Martin: Martin, I'm it's interesting, but I'm I'm missing because right these scores are probably always kinda a probability that there's trust or no trust in in in an object. So I I'm kinda missing the pro the reliability of the score result. And, also, what what about false positives? So if if if for some reason the score for an object is very low and what's our is it the main name holder up to do when when he feels, okay. This is not correct, but it's impacting my trustworthiness in some level, some way. So I think there also need to be a mechanism for to able to correct any any any false positives. Thank you.
[01:17:24] Silvano Romano: Yeah. Yeah. This is one more tough question. Actually okay. Just to give you an idea, this might be one filled in object. But inside the draft, one of the references is an informal report that we have produced when we did the presentation at deep sec last year. And many of the things that you are discussing, actually, we have been thinking quite a lot about them. How reliable is the reliability scoring? This is something that we should look at, and there are ways for somehow assessing the level of trust of the reliability scoring entity, something like this. And also attacks to that is something that you should look at. But once again, thanks for these in-depth, let's say investigations. But if you ever look at the document, you will see that we really tried hard not to mess too much with that part, but just stick to the formal part. So that's why I'm insisting on saying this is really with a clear separation of concerns. We just wanted to standardize how you can report that. Then how you arrive at that is a matter of a completely different discussion. But if you look at one of the references there, I think you will find some of the, not answers, some of our thoughts about things that you were saying. Yeah.
[01:18:55] Martin: So so sorry. So the the the thing that this thing would add is that, I I think for all the other RDAP stuff, it's just factual representation of stuff that's in the database. This actually adds, a a kind of a value judgment to the output. So this would be a change from from the other ex extensions that we have. Absolutely. Thank you.
[01:19:21] Rick Wilhelm: Richard. Thanks. Thanks, Simon, for this this work. This is actually pretty interesting. I would encourage people to not think of this as an extension for your registry or registrar, but think of this as a service that's being run by somebody else. And don't think of it as think of this as being instead of somebody running a web server or making up their own REST API to do domain queries for their domain scores that some somebody has come up with, they're just gonna run RDAP as opposed to making up their own stupid REST API. They're gonna use RDAP, which is something that that that Scott and us and we made, Scott and Andy. And then Simon and his buddy made an extension for. And and so don't think of it as this extension as something you're going to tack onto your registrar or registry e p p or RDAP server, but someone else is gonna run it. And someone else that is doing a scoring algorithm on some domains, a researcher at a uni or an institute or something else. But don't think of it as that. And so this is a little bit to Martin, whom I love. So let's think of it as that. And this is a very standardized way for people to get these scores out of it. And and so that's sort of how I approach it. And so I think that this is kinda great in a very standardized and good way. So kudos to you guys for kinda coming up with this. And I think that if if everybody in here kind of flips their head around and doesn't think of it as, oh, this is something that I'm gonna have to tack on to my registry or my registrar, and thinks that it's something else that someone's going to run, that then I can query their service and I have a standardized way that lowers the burden of engineering for my engineers to go get that data, then that's great. And so I think that people will be much more understanding of it in that way. So that's that's very good. And just FYI, just so you and everybody else knows, PIR, we've not done anything related to Rdap for our AIP or QPI stuff. And you probably know that, but everybody else here doesn't. Thank you.
[01:21:40] Silvano Romano: Oh, thanks so much for this comment because, actually, I totally agree with you that it's not about asking registries or registrars to implement some way of self assessing their reliability. But, yes, this might be a service. And this is also why we're stressing the point that this is not necessarily associated just with registrars or registries. It's associated with domains, for example. And indeed, it came in our case from how much stressed we felt ourselves about the fact that we had been disclosing issues with respect to an email service that we had been studying and nothing happened for six years, basically. So we were saying, damn, there must be a way for knowing whether or not I'm relying upon a service that is reliable enough in terms of trust that I can, give to the service itself. Yes, please. Werner.
[01:22:41] Werner Staub: Yeah. My name is Werner Staubin. I would really also like you for having done this work. This has been, you know, something that is not been discussed enough. And the the approach of you doing using Rdap for this is, of course, one of the avenues that is really necessary. I I would add to the to this that ring the domain name industry and domain names themselves using the DNS protocol are also capable of really good delivery of of such information that could possibly go side by side. And in terms of, you know, the very important remark that was made just a minute ago about, does it necessarily have to be the registry? No, of course not. And that's the whole idea. It should be a logic of increasingly a web of trust. You know, you have these sources and the other sources and people judge for themselves if they want to use that resource. But we do have in the context of a registry a role to play that has maybe been neglected for some time. And that is a registry is to go to place to see what's on the record. And there is another element that is being forgotten just because out of habit. That is the registry is about the only place who knows the history of a domain name. It behaves as if only the here and now existed. Yeah. But the history is important. And it is actually unfair to many people on the internet that only by payment to specialized organizations would some history information be available. So in some cases, it is actually really a question of, know, fit for purpose public service to have that sort of information on the record even if it is just quoting someone.
[01:24:39] Silvano Romano: Yeah. I could not agree more on that. Thank you.
[01:24:42] Jorge Cano: Okay. We only have five more minutes, so please be short.
[01:24:47] Jim Galvin: Thank you. Jim Galvin speaking as a participant. I just want to say that I'm generally supportive of this work. It is just an extension for passing information for use by whatever RDAP server has this information and would be willing to pass it on. And in that context, it's just a possible suggestion for a standardized way to pass this information along. And it really is, it's nothing more than that. As you said in the presentation, you say in the document, the extension itself is agnostic with respect to all the context. And that's what's important here. So I just wanted to make sure to say that out loud. So that's consistent with what Rick was saying. And it speaks to the question that Jim Gould and Martin in the back were asking. Those issues are kind of out of scope. That's not what the extension the extension is for whoever needs it and whatever purpose that it has. I will say and end with this particular comment, I do think in many ways it's kind of a solution in search of a problem at the moment, which I guess is why you're not asking for working group adoption at the moment. I think it's important to keep that in mind too. But otherwise, good thing. Thanks. And this
[01:25:59] Silvano Romano: is true too. You're totally right. Thank you.
[01:26:02] Jim Reid: Jim? Jim Reid. I think this is interesting work, I would like to see the working group take it on in some capacity, provided we get some indication that the significant support for it, particularly from the registries. If it's just going to be something that we do for the sake of an academic exercise, what's the point? I think it's also important there have been some comments made on the chats about some people saying we don't think this is appropriate for the working group. My to that is that where else should people go if they want to define and register our DAP extensions? That surely falls within the remit of this working group, and we probably don't want that work taking place elsewhere.
[01:26:48] Silvano Romano: Yeah. Thank you. I will go through chat comments offline and have a look at them.
[01:26:54] Mario Loffredo: Mario? Mario Alfredo, Registro dot IT. My main concern about this proposal is that it risks to be considered a rating instead of a secure score. So I think that this kind of information should be carefully treated, we should balance risk and benefits because the risk is to cause refundational damages to registrars, loss of of customers, legal disputes because this apart that this kind of risk risk score can change very, very quickly. So today, the the the the secure score is a a value, and tomorrow is can be a different value, higher or lower than the the the day before. And there are also implications due to the implementation of an NIS two directive because there is a clear recommendation by National Security Agency to not to spread the information that can be used by attacker to possible sorts of attacks exploiting vulnerabilities because we publish information about domain that have low security posture.
[01:28:44] Silvano Romano: Yeah. Actually, I I see your points. It is definitely true. Every time you use a metric in order to assess performance, you incur the risk of making the metric become a bad metric because it becomes the target rather than the the way you arrive at the target. And related to an IS two, it is definitely true. And obviously, the scoring that you carry in the envelope should not allow any malicious user to identify, let's say, ways or attack paths for attacking the entities or the domains that are the subject of that, sorry, of that assessment. So that's why I was saying this is a very delicate question, and you should somehow arrive at something that gives you an overall idea, a mediated idea about the reliability of that entity without allowing any malicious entity to derive specific information as of how you might attack the targeting question.
[01:29:56] Jorge Cano: Alright. We're running Amazon out of time. So any more comments, any more questions, please send them to Luis. Thank you, Simon.
[01:30:06] Silvano Romano: Thank you so much.
[01:30:08] Jorge Cano: All right. Any other business? I don't see nothing. Okay. Thank you very much. See you in San Francisco.
[01:30:54] Mohamad Boucadair: Yes. Oh,
[01:30:57] Antoine Verschuren: there's the chair meeting tomorrow. Is there the chair session tomorrow?