**Session Date/Time:** 19 Mar 2026 03:30

**Speaker 1:** All right. Hello, um, good morning, good evening, whatever everyone. It’s time. It’s 11:30 in China, and we will start our Domain Connect session. So, welcome, welcome to everybody who is joining. Um, as usual, this is the Note Well, which you’ve seen a few times. There’s a QR code for you to get all relevant information, and while you have a few seconds to scan that, I’ll tell you the gist, which is: please behave professionally and with courtesy. If you have any concerns, there’s the Ombuds team, or you can contact the chairs, and please consider the intellectual property rights rules around IETF. Also, as any session, this one is recorded as well. If you would like to say things, um, please state—sorry, please state your name at the mic and in any case, even if you don’t want to say things, to record your attendance, please sign into Meetecho. There is a QR code at the mics and at the door, and those who are online, I suppose, are already signed into Meetecho anyway. Um, all right. Here’s a few resources, and so this is our second working group session. In fact, the first one was at the last IETF. At the time, Hans Jörg was there and I wasn’t. This time, I’m here and he isn’t, although he’s remote at 4:30 in the morning, so kudos to that. Same to our um, key participant, Pavel, who’s also in Europe at 4:30. We have a new AD, Charles Eckel. So, thank you for being here and for going through the pain for the next few years with us, and um, yeah. Um, so um, that’s, I guess, most of the—Do you want to say a word? Okay, go ahead.

**Charles Eckel:** Yeah, um, Charles Eckel. So, thanks for that, that nice warm welcome, and yeah, excited to work with all of you, and definitely want to thank—and I’m sure all of you want to thank—your outgoing AD, Orie, who’s right here behind me. He’s obviously done a great job with all of you guys. He’s made my life a lot easier coming up to speed on what what you’re doing here. So, yeah, really appreciate all the work he’s done getting you guys this far, and I look forward to working with you.

**Speaker 1:** Indeed, thank you very much, Orie. All right. Um, here is our scope, which is mainly there for reference if you want to look it up later. It’s essentially the gist of our our charter. And with this, we’ll get into the agenda. We’ll mainly be discussing updates to the Domain Connect Protocol draft based on discussion on the list and on feedback from the last meeting. So, Pavel will do that, and we will then be able to take a—talk about anything else we want. Um, so I will change the slide deck to Pavel’s. Um, aha. I have to unshare first. How does that work? Um... Unshare. Good. All right, Pavel, this is your slides, and I’ve passed you control.

**Pavel:** Yeah, I have the control. So, good morning Shenzhen. Um, so, sorry not being there with you. So, um, it was a kind of a last minute change that I’m remote, so it’s really early in the morning here, so bear with me if sometimes I’m not up to speed yet, so probably not enough coffee yet. But let’s start with an update to the Domain Connect draft. So, basically, the—we renamed the draft because the draft was adopted by the working group since last IETF. And basically, the focus during this time was basically to get a better structure to the document, to gain on the clarity, to cover the gaps in the normative description of the protocol, remove all non-protocol-related aspects. I will come to that on the further slides. And also, what was an issue during the last session, basically to remove UI-related elements from the draft. So, I will cover this on the coming slides. Yeah, so, um, I think we have kind of plenty of time today compared to the content. So, whenever you think you have anything to add, please add yourself to the queue. I think we’ll cover it during the presentation. Um, it will be better to keep the the context that you don’t have to wait till the till the end with questions or or remarks. Yeah, so, um, this is the first part describing the what kind of structural changes were done. So, first the order of sections was revised in the in this version. This is now really awful to look at the diff between the 00 and 01 because the seismic shifts in the content, so basically both the parts of the content are updated, but also they shifted. So, basically, the tool doesn’t cope with this well anymore. But I think reading the final 01 version, you can you can follow it pretty good. So, basically, the—it starts with terminology, then is the overview of the flows which was there before. Then moved the section about objects and the templates to the front because this describes normative the elements which are defined. Then the discovery is described, the apply flow for synchronous and asynchronous flow, and there are two sections which describe the two processing elements that especially the server has to do: the variable resolution process and the template application process. The draft now has a distinct security considerations section, which is kind of expected to be there. It was there before, but it was somewhere buried in another section, which was probably not not that optimal for the for the general readability. And as it was requested, the trust model section is now kept but reduced, I think, to the to the essentials of it. Next one. 

Yeah, so, the—this is the part I mentioned before. Some sections were removed from the draft. Basically, by diligently reviewing the content, we figured out that some elements are just non-protocol elements and and they don’t belong to this draft at least. Maybe they can appear as a informational draft or by some other external specification. But first, the browser handling considerations, it was also related to UI handling elements, basically this removed because of the content of this. But the relevant parts about interactions in the request-response which were previously in this chapters are moved to the parts where they belong. And the whole browser handling part is is also gone. And also with the browser handling considerations, there was a lot of text about handling you know pop-ups, tabs, and what not in web browser. This was already feedback last time that it doesn’t belong there. So, we took a look into this and basically what is relevant for the for the protocol flow is now moved to apply interaction request-response sections, but the whole browser handling part is is also gone. And also the alternatives to SPF M, maybe it was operationally useful so some people but not really protocol-related because this was kind of stating how to use protocol in this in this context. But if anyone considers any of this sections really required, just raise your hand, go to the mic, or draw it to the attention of the mailing list because there is no content that cannot be recovered. 

So, this was—this is something that you will notice in this version very prominently. In the beginning, there is a now a huge section with ABNF grammars to all protocol elements, so basically protocol identifiers, domain name forms including IDN, it was not specified before, the fields of the templates parameters, signing artifacts, so just I think now everything is covered which is relevant. There was an interesting aspect to this because the templates describe, let’s say, have two states. So, one is the template itself and the fields, of course, they have particular expected syntax after this variable substitution is done. So, basically, in this points, basically there are two grammars defined because, you know, the only for example after substitution of variables, you can say that in TTL field, for example, it is a number because before it is a string with a variable definition, yeah. So, there are basically this concept is now implemented. Also in the parameter tables, all field definitions now refer to this terminology and grammar section in all the places. And by doing that, we realized that there is a lot of behavior description in this tables describing the the parameters and the properties of the template. So, this is something that was moved from this part to basically the part describing the processing of the server. So, basically, you have now a clear distinction what is the template, what are the fields, and what they are doing, and the processing part is now moved to the section about processing. I think this is much clearer to to follow this way. 

So, this is one of this sections that I mentioned before which is describing in detail how the variable processing and substitution is working. This section was there before, but it was not that detailed and structured as it is right now. So, there is a description about special built-in variables, the inputs to the processing, the processing itself with a special subsection about the SPF merging which is highly reduced compared to the previous draft because the previous draft was having a lot of prose including the history of SPF and why it is there, so basically this is all removed right now and it’s just saying how to process the SPFM record to produce a final SPF. 

The second section which described the processing right now is this template application. So, basically, it describes the algorithm that the server has to follow to apply the template, so basically starting with description about the two possible processing types if the server is tracking the applied templates and when the server is not tracking applied templates because some of the processing and properties are depending on that. And then the exactly describing these steps to apply, how to process the filtering by groups, how to detect and calculate conflicts, which basically have to be calculated before the authorization to present it to the end-user. And after the authorization, basically make the template application. And the user authorization itself is just described as a step, but it’s of course the interactive element which is not described in the protocol in detail. 

Also, the signing part previously was buried somewhere in the sync apply flow. Now it’s split into three distinct sections which are basically covering three aspects where signing comes into play because there is a distinct part where the service provider has to sign the request. So, there is now a section describing exactly how this processing looks like. There is a section where the server verifies the signature. So, this is also a separate section now. And for all this to happen, the service provider has to publish the public key, and this is also a distinct operation done when implementing Domain Connect which is also now described separately. 

So, as I mentioned before, the sync apply interaction was rewritten completely to remove all this browser handling, and now has a clear structure of how the request has to be done, how the server response has to be processed in both cases for successful flow and the error flow. The successful flow of course is reference to the processing that I mentioned before for the variable substitution and and template application, but basically this is now I think much easier to follow for the for the implementers. And there was already a section about verification of changes, but following the feedback on the mailing list, basically that was rewritten as a normative text which also includes information about expectation of—um... sorry, I lost my thought. Um, so, basically, um... about expectation when the changes are are applied. 

And the DNS provider discovery section, the extensibility part was added to this section. So, basically, the top-level JSON keys of this response are now defined as a IANA registry, so the clients also here are structured to ignore unknown keys. And by doing that, basically the other browser-related elements can be also removed because there was still this width height hints to login screen in this in this part, but that if let’s say this IANA registry is covering that, basically it can be registered as a legacy properties but it may be removed from the from the draft. 

And there were also the security directorate review elements. So, basically, a few items were brought to the attention of this one. So, the automated deployment pipeline use case, let’s say this remains out of scope as per the charter, but if people think this is wrong, it’s of course up to discussion on the mailing list. But at least we are now following the charter in this respect. The synchronous flow and when the changes are applied, as I mentioned, this is already covered. Trust model to long is already covered. The informational user screen, as I mentioned, is removed and the needs are corrected. I don’t have to mention that too much. Yeah, so, before I go to open issues, if there are no comments, I will just move forward. 

Yeah, so, one of the open issues that was brought up already during the HTTP directorate review and was also now circling through the mailing list so last time we didn’t have too much information from the implementers about processing of asynchronous apply and what is the precedence of parameters from the JSON body versus query string, because the right now there is a post request where both are actually allowed. So, we had some feedback from the implementers over the mailing list confirming that this is a real problem and that we need a clarity. So, basically, the first idea was that the JSON body would be and just deprecating the use of query parameters would be a good fit, but people say now there is a utility of seeing domain name and host in the query string because of logs auditing debug. So, now the proposal is to basically keep the or let’s say have remove the duplication in the sense that the parameters which are standard protocol parameters like domain, host, groups, and the like are kept in the query string, but the rest, especially the key-value parameters from the template, will be then kept in the JSON body. So, this way we will remove the duplication, but this can be a breaking change for some clients. So, there is only a handful of asynchronous integrations out there in the wild, but if they are now only using query string parameters, they would have to to adjust to that. Is there any opinion in the room about this or any remark? It doesn’t look like that’s the case. All right, so, there is discussion on the list, so whenever you think this or the other path should be taken, please chip in on the mailing list. 

The second aspect which is being discussed is to remove the warn phishing template property. So, just to recap, the template is now kind of covering three states for the sync templates. So, basically, they are either signed, they are unsigned with a warn phishing property set, or unsigned without warn phishing property set. It has some historical reasons, I wouldn’t cover that today. But basically the claim from the mailing list conversation is now that the unsigned template should be considered insecure under any circumstances and basically the warn phishing flag is redundant or misleading because you have let’s say of this situation where you have unsigned template without this flag. So, some providers are known to use this logic, basically basing on the flag whether it’s signed or not to define whether the template is secure for them or not. So, there are two options how to how to deal with it. So, either to follow the proposal and the remove warn phishing, then the insecure is implicit by missing the signing property. The second possibility is to keep warn phishing but to make it obligatory for unsigned templates. So, basically, by saying normatively that either the public key for the signature has to be present or the warn phishing has to be present. Or the of course the alternative is sync block which would say that this the synchronous flow is not possible at all, which will also let’s say address this this issue. So, my my opinion is that basically keeping warn phishing is but let’s say binding it to other properties would have a benefit that providers relying now on this flag will still handle the insecure templates in the same way, because let’s say if it will just silently disappear, some implementation may just stop displaying the appropriate warning to the end user. But it is of course a bit of redundancy in the template definition. Any feedback or remarks to one of these two options? 

**Orie Steele:** Hi, Orie Steele, as an individual. Um, so, the remove warn phishing insecure is implicit. Um, if that approach is taken, wouldn't we say like right at the beginning of the document basically like all of these templates are insecure by default and then you wouldn't have to feed this parameter through all over the place? Um, it seems—which of—can you just restate which is the sort of recommended path forward between these options currently among the authors? I didn't I didn't get that part. 

**Pavel:** Yeah, so, I mentioned the option two is considered having the benefit of let’s say current implementers relying on this flag still handling the insecure templates in the same way. It has this redundancy aspect, but I think the benefit of of keeping it is higher in the option two. 

**Orie Steele:** So, the recommendation is keep option two. Um, and my comment is it seems sort of confusing and, you know, I kind of like the option one, um, but I'm not an implementer and I don't have a lot of awareness, so that's my comment. Thanks. 

**Speaker 1:** All right. Thank you, Orie. Next one is James. 

**James Galvin:** Thank you, James Galvin, for the record. Um, I actually prefer option one too. Um, and while I appreciate the intent of the sub-tag there of warn phishing, my concern is that opens the door for other kinds of sub-tags. And so now we’re suggesting that we are somehow going to grade security, okay, by putting a lot of different choices in there. I think this is all about DNSSEC, right? So, it’s all about whether it works or not. I mean, there’s really nothing in between. Um, and it—it—it seems to me that I think it’s confusing to put it in there in part because it opens the door for other options to be suggested and grow with time, and also because it should be the case that, you know, insecure is implicit, and it really doesn’t matter the reason, um, it’s either good or it’s bad, and that’s all we really care about in this, and we should have to make our own choices. Thanks. 

**Speaker 1:** All right. Thank you, Jim. 

**Gavin Brown:** This is Gavin Brown. So, my feeling would be I don't disagree with either Jim or Orie on what what they said, but I do appreciate that there may be implementations that currently expect this and if we want to keep it in in order to avoid breaking things that already exist, keep it in but say in the document that it has to be true. So it could only take true and say this is deprecated, it's it's needed for for backwards compatibility with previous implementations, but it's only can take the value true and as as was previously mentioned say no all templates that are not signed should be considered insecure. 

**Rick Wilhelm:** Uh, thanks, Rick Wilhelm. Um, I agree that either signed or unsigned and no ambiguity about whe—and ignore the flag because as an implementer, we wouldn't trust that the sender was being truthful one way or the other. Um, it's either going to be signed or not signed and then we'll deal with whether or not we like the signature. Thanks. 

**Speaker 1:** All right. Thank you too. So it seems like most people are in favor of splitting off. 

**Pavel:** Very good. Thank you for this for this feedback. So we’ll I guess follow this. If anyone has of course other opinion the mailing list discussion is still open I guess so. The last last one, so this is kind of a repeating aspect when working in this draft so this draft is still quite long so the 01 version is 82 pages even if let’s say deducted the whole appendixes and and change log and and all the likes. The actually the it grew to my surprise because there was a lot of reduction, but let’s say the the grammar definition and and all these elements which were rewritten or added actually added on in the pages. So the question to the working group is to let’s say whether further reductions of this size itself and the working group process should be should be considered. So from editor’s perspective, all elements which are now in the draft remaining are the kind of core elements of the protocol description in the original form. The only thing that is on the table we think is the asynchronous flow which is like 15 pages of description with OAuth flows in interactions and some specifics. So actually the async flow is pretty independent and as I mentioned it’s implemented right now by the few so the the real core of the core of the protocol is the sync flow. The extensibility in the settings endpoint as I mentioned also allows us to to let’s say delegate this flow to a different document and and basically move forward with the sync draft and all the whole core elements of the of the protocol maybe maybe faster. So the proposal is to focus on the sync flow first and the split away async flow as a second standard track document. But as let’s say it was not rediscussed on the list so far, I would love to hear from the working group whether there are opinions about this proposal. 

**Speaker 1:** Jim is running for the mic. 

**James Galvin:** So, James Galvin again, I'll just I'll just add because I like to hear myself talk, right? Um, I, you know, in general, I support the principle that less is more when it comes to standards, so I’m inclined to find things to take out and, you know, I don’t really have a strong opinion either way but I just figured I’d say, you know, supporting where you’re going with what you’re doing taking that out is good. If we can find other things that’s great too. But I don’t have a really strong bias. Thanks. 

**Speaker 1:** I suppose the question is whether you know if the async flow is described separately in a different document then it’s not less is more, it’s just two pieces instead of one. Do you think that would be an improvement? 

**James Galvin:** I don’t think it’s absolutely required in the core of core, so I think it’s an improvement in that respect. You know, and so if you want it then you you go to another document, but I really don’t feel strongly about it. I mean, keep them together um, so that’s all. You know, each document should have as little as possible in it, or the minimum amount that it needs, that’s where I’m coming from. 

**Speaker 1:** Thank you. Rick. 

**Rick Wilhelm:** Lordy to be up in front of the in the mic line in front of Orie, this the dangers of being remote. Um, so I'm generally in agreement with Jim. I'd seen this when I was reading the document in advance of the meeting even before I saw the slides I kind of thought that it might be a good this I thought wow the document's getting really long. I'm in support in favor of splitting it and I'm not sure whether it's core and sync versus async or core versus sync versus async and going into three documents but I'm just thinking of more of our quote unquote future selves when we find a minor change in one of these or an errata or I'm thinking that this might be a situation where we are um bissed to death um that I'm not I'm probably not the first person to say that in the IETF. But this is such a long document it's going to be very hard to get right and and stay perfect and so I think that the smaller documents we have generally the better and to just do a good job of separation of concerns and so that's my O2 and we'll kind of see what Orie says. Thanks. 

**Orie Steele:** Hi, Orie, I don’t need to say as an individual anymore, so it’s nice. Yeah, I am big fan of removing this if you’re considering removing it. Like the fact that you would even consider splitting it off, it’s like that to me feels like you should definitely split it off. The question that I have and I don’t know the implement implementer experience around it is if this moves out, how much of the interoperable implementations could survive completely ignoring all of the stuff that you pull out? Um, if there’s a lot of implementation and utility in what remains and this is the only document that you ever publish as this working group and it, you know, and there aren’t any bists, there’s no other documents but it still covers a lot of the use cases, that feels like a really good thing. If you split this off and then you discover that every implementer actually has this problem, uh, that would be concerning to me. So I just don’t know for this particular pieces that you’re considering pulling out if it’s that second case or the first case, but definitely remove it if there’s a chance for a huge amount of interoperability without ever reading any of this text, and maybe my advice is consider that you may never finish whatever you split off and be okay if that’s the case. Like, don’t move it off if you really need it. I just don’t know for this piece. Thanks. 

**Pavel:** Yeah, so this exactly why we’re thinking about this aspect because there are only handful of implementers of async flow and most of the implementers just implement the sync flow and they are pretty successful with it so it kind of proof that basically without async the protocol is let’s say fully implementable, usable, and has a utility and I think the remark from from Rick was very aligned with what we are thinking that the working group could proceed with the sync flow and the most value document in the different pace than then with the async flow which which is having more complexity and if it never gets standardized the async flow, I think this won’t change anything to the status quo today where the the protocol is described somewhere else. But at least people will could reference to the standardized part of of the core protocol and just have the the async flow described somewhere else, yeah. 

**Speaker 1:** Thank you. Arnt. 

**Arnt:** I think that the correct way to split is that the core document is enough for a weekend implementation and 72 pages or 82 pages is just too long. It scares people. Once people are in, once people have committed their code, merged their code, they might need to write some more code and read another draft, that’s okay, but it’s important to have a draft that is short enough that you think a weekend implementation is doable, and that should be the core. So just the—just that which is needed in order to get something up and running without async, without any other bits that might be necessary for compliance or interoperation but are not necessary to see your first interoperation with one implementation. That's not very IETF, but it is what I think. 

**Speaker 1:** All right. Thank you. So it seems like most people are in favor of splitting off. 

**Pavel:** Very good. Thank you for this for this feedback. 

**Pavel:** So, the next part is basically the Domain Connect is now kind of having two classes of record types in the template definition, so basically fully specified record types I would name them as are those which are explicitly mentioned in the draft and basically the RDATA element is broken down into dedicated template elements and there’s also the special SPFM virtual R type. All other types are now allowed by either the DNS resource record mnemonics or the RFC 3597 notation with the just data blob of of RDATA. What we realized by reviewing that that actually the draft lacks now extensibility in this respect, so basically if someone would come later with the idea that should be another fully specified R type, basically the this will have no back reference to the original draft and also when we removed right now the original part with extensions and it already defined some labels for for R types, either the DNS-related R types or virtuals ones like redirection for example. So, right now they are removed from the core because these were extensions originally already but the names are already defined and basically the proposal is to also define a IANA registry for this fully specified R types basically to have a interoperability reference about which these are and also the place to reserve at least the names which were already used in the original draft so that they won’t get redefined at any time time later. Any opinions about this approach? 

**Orie Steele:** So, Orie in the chat that he likes the idea of a spec-required registry for extensions. 

**James Galvin:** confirmed that and Rick. 

**Rick Wilhelm:** Oh Lordy to be up in front of the in the mic line in front of Orie, this the dangers of being remote. Um, so I'm generally in agreement with Jim. I'd seen this bit there at the bottom of either eight or nine I I thought that we were kind of getting locked in there. Um, one thing though that there is already an IANA registry for RR types I think, my my DNS OP brain is a little bit rusty. So, I think that we would have to somehow be careful with the way that this is documented to make sure that it doesn't both conflict with that it works in harmony with that right I mean because we only want RR types in this that are allowed to go into that that make sense. So, I I agree that a registry makes sense, we need to have this extensible because otherwise we'll be updating this thing forever. We just probably need to be really careful about how that works. So, that's sort of my thought. Thanks. 

**Pavel:** Yeah, this was also how we’re thinking about it to bind it to the other registry, so it’s already making the reference about the let’s say all others so this not fully specified resource record types basically it refers to this registry of DNS resource record types and we have to make sure that we don’t redefine the names which are already there, so this absolutely absolutely true. All right. Thank you for this feedback. 

**Speaker 1:** And Pavel, I also have a question as an individual. Yeah. Um, so in the previous slide, um, there's the virtual type SPFM and then potentially also um the extension ones that are not assigned mnemonic names in the IANA DNS record types registry but they could potentially in the future, maybe the um DNS folks come up with the SPFM type at some point. So, um, do folks think that the record type names that are used here which are not regular names should be somehow um reserved in the DNS space so that they don't get accidentally allocated later? I don't know, any opinion? 

**Pavel:** I think so for my personal opinion it could be useful, but I’m pretty sure that this hard dependency can be difficult for for some people to find consensus about why the why the DNS protocol should be limited by by this one, yeah. But we are aware of this of this risk, the question whether we want to to build this hard dependency or let’s say have kind of eventual consistency of these two registries. 

**Speaker 2:** Uh, just a short note, Pavel, Orie was relaying in the chat some pointers to examples where in other cases two different registries had procedures to align them. I also put that in the notes of the session. 

**Pavel:** All right. Thank you, that’s helpful. 

**Pavel:** And there are some other let’s say open issues on GitHub let’s say this the just a screenshot of of the list and the link if you if you wish, most of them I covered in this presentation some of them are basically just things to implement in the spec but where we haven’t arrived to those yet. So the next steps which we see as a the editor team right now is to close the remaining open issues till the till the next IETF. So, I think with the feedback from the working group from this session, we have a good material to do that. I think the after having this version is is there, I think the we can do it through the chairs if I'm not mistaken to request the early review for DNS directorate. I think that makes a lot of sense. And then we can see if the document is is already in the shape for working group last call or is there any other issues open and remaining. 

**Speaker 2:** Pavel, on the question of the review, if I’m not mistaken, we had after the last IETF this early review from the Security Directorate which we requested and which was also received. Can you say maybe two or three words in how far this affected the resolved issues or the pending open issues that you mentioned? 

**Pavel:** I covered it on on the slide, I guess. If you have any more specific questions... 

**Speaker 2:** Ah, sorry, then I probably missed it then. Sorry. Ah, yeah, okay. Sorry. My mistake. Okay. It’s also middle of the night for you, yeah. Yes, so if there are no other remarks from the room, this this is it from from my side, a bit a bit longer than than I actually originally planned, but I think we are good in time for the for the session so. It was very good feedback from our perspective we can work further on the on the draft. 

**Speaker 1:** All right. Thank you, Pavel, very much for doing all the editing and the hard work. Thank you everybody else for giving feedback. Is there any other comments people would like to make or um it doesn’t look like that’s the case. So, I guess we’ll close the session here. Thank you everybody for attending. Thank you for folks remote and go back to sleep, Pavel and Hans. All right. See you all in Vienna. See you in Vienna and on the mailing list. Thank you.