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

[00:00:19] **Pavel**: Alright.

[00:00:26] **Hans Erik**: Welcome, everybody. Thank you for choosing domain connect today. This, I think, is our third record meeting in person. This time, first time, both of your chairs are present in front of you, fortunately. Let's get started, probably. Alright. This is a known well. I guess, at this time of the week, typically, everybody of you is aware of it. If you're participating within the IETF, be aware there are certain rules and standards that the IETF follows, and that apply to you when visiting a meeting, a work group meeting, especially like this year. You see all information and links to these procedures again on the slide, but it's actually something you should even read in preparation of the meeting itself. In case you haven't yet, please make sure you're aware of all these, and especially also follow these rules. Everybody in the room, please also make sure you are registered in the data tracker as a participant of this session. I think that's basically what we have to say on this one. Yeah. Already said, please make sure you are are signed in. If you go to the mic, please shortly state your name before and, of course, get into the queue first by the tooling, either on your phone or the live tracker. If you're remote, please make sure your audio is correctly set up, ideally, or using a headset. Alright? So, this brings us, basically, the overall information you need to have in order to run tooling and the agenda. I think everybody's fine with that. So, we are your chairs, Peter and me. We also have actually a new area direct area director, Mahesh. Is he still here? He's he's there, hidden from me. So, yeah, welcome, Mitte, also because most of you will have noticed we also switched even area. So this was an art area working group, which has now decided to be moved to the ops area for organizational reasons and because it fits better. I think other than that, there shouldn't be any circumstances to that that make a difference for the group. The only thing might be if some participants encounter a conflict, because now it's a different area, probably the conflict scheduling will work out differently. If, for some reason, this is a problem for you, probably approach us, and we can try next time to arrange for that. Said that, I'm looking if somebody is volunteering as a notetaker or to support notetaking. Is there anybody who would like to assist us? Okay. Peter, thank you. You know, there is a meeting notepad linked in the data tracker also, so if somebody wants to assist Peter or make sure everything is recorded correctly, feel free to get into that. As all working groups in the ITFs, this working group has a mailing list, and the mailing list indeed is the actual main tooling and main engine of that work of each and every working group, so if you're not subscribed to that list, you should definitely do, and obviously also participate in discussions and so on. You can do that on that URL, which is basically the website of the working group. Alright. I probably won't go fully through this, because most of you will also be aware, so this is what dconn is about. Guess everybody knows roughly what we do overall. We have a quite clear scope, because there is existing rollout of decon in the world, and the main goal of the working group is basically to turn this into an RFC, and that's basically also the milestones and the charter of our working group, which doesn't mean, at some point, that we might add things to the chart or something like that, in case there is interest in adding things or other use cases for what we do here. Alright. This brings us to the agenda. We have just been to the administrative part. One thing that also happened in the meantime that was discussed in previous meetings is basically those of you who have read the draft. It's quite a massive document, and it was decided last time that this document will be split into two documents. Basically, those two which you see here is basically the split of the former document into two ones. There is also still the core draft, which we will have as a first presentation, and then there is the async flow extension, which has been split out of it, and which is a little bit of a lower priority, and probably won't be the main priority of the working group until next time, so we will have just a five minute information from Pavel, who will be the presenter of the box. This brings us to our first speaker. If there's no questions or nobody in the queue, here we go. Pavel, how do you want do you wanna run the slides by yourself, or you wanna Yeah.

[00:05:51] **Pavel**: I prefer to run for for myself.

[00:05:53] **Hans Erik**: Alright. So floor is yours.

[00:05:56] **Pavel**: Wait a second because something happened, and my wrong camera has been selected now. Even though in the test, it worked. It's unfortunate. Okay. I'll try to look at the my other screen, and it should shouldn't be that awkward. Alright. But the slides are not yet active. Right?

[00:06:19] **Hans Erik**: Okay. So I think that's on me. Wait a second. Here we go. Can you drive it already or need I need to set something? Yeah.

[00:06:39] **Pavel**: I have control. I see controls. Alright. So as mentioned, I will present both drafts. Actually, it's on the one slide slide deck. So, basically, we move from from one presentation to another continuously because this is the only agenda points we have. So I think that's that's okay. Cool. So first, about the call draft, let's say, short history. So we had the 2002 version, which was basically the the only change was the split of the of the drafts and using the notion of reserved data points or elements which were split off to the asynchronous draft. And then the zero free version, which was published shortly before this meeting. I won't go too deep into all of the changes, but I wanted to point out to few of them because there was quite a almost none feedback on the mailing list. So I I want to make sure that the working group is good to inform about these changes. Again, I think this this are relevant. I think we have enough of time to stop when there are some questions from people. So if you have the remarks or on any point, just put yourself in the queue, and I will interrupt to to take the question or or remarks. So so, basically, we don't don't wait till the end because it's quite a few slides. So the the one change that we discussed last time was about the how to deal with the record types and the extensibility. So the draft specifies the three definitions for the fully specified record types of the record types where all the properties are broken down into into specific properties. The computed record types are the ones where there is no corresponding DNS record type, but it's computed from what's the domain connect specifying. So one example is SPF where where it is used. And the generic record type were basically they are not broken down. Just the it is the our our data is represented in in the template definition, and it's put in the the record. So right now, the this proposed for the fully specified and computed record type for generic ones. There's no need to to have one. And as proposed last time from the from the working group, There was also a guidance to synchronize with DNS resource records registry. So, basically, the mnemonics which are appearing in this registry won't get in conflict with the with the others, so they will be kept in sync. The second change was the last step of removing related elements. So the only notion of the the the elements for for driving the the browser is basically by re reserving these keywords, which were, let's say, were present in the protocols. So it's if any let's say, anyone who would try to introduce them want to introduce them in in a compatible way, but they are not having any normative definition in the in the draft anymore. So but so, basically, the only notion of open as is the they have a presence as reserved. And there is also the added text, which which says to ignore any unknown elements of the settings response, which kind of complements this change. There are two additions to security considerations coming from the earlier mailing list discussions. So there is a new addition about domain connect to the security code, shall not be trusted. So it can has some possible risks related to to leading to resources which may not be secure and uses usage of underscored host names and host parameter, which may also lead to unexpected changes to the DNS or at least lead people to to consent changes that they don't meant to consent. So there is a special there's there's a text putting a stress for the DNS provider to give, let's say, enough of information during the consent. That's the let's say, in case such application is happening. And some other changes, the one fish phishing was deprecated and reserved as keywords as discussed last time. There's a clarification about handling when multiple domain connect 60 records appear in the response. Handling of identical resource records in the conflict detection. So, basically, if if two template applications produce exactly the same the same records versus discussion in the past, and the remaining list should it be a conflict or basically treated as in, let's say, the change on on the desired state. And right now, the text says that if the in identical records is produced, it shouldn't be a conflict. It's basically for templates and added content negotiation elements of the template query endpoints. So this is this right now added. So now I will go through through what is still open on the on the draft. So this where I would want to hear opinions, see whether the the the proposed changes are in the expected direction from the working group. So this list is, right now, the complete list of all open issues. So if we tackle all of them, actually, we should be you should be ready with the needed adjustment to the draft. Of course, there might be some new issues appearing from the reviews, but so far, these are all all of which are unknown to this to this draft. So one which I also put to the mailing list yesterday was the is the extensibility of template definition metadata. So this came from the earlier discussion about versioning and, basically, the template metadata is the basically, everything else in the template aside from the resource record definitions and write the let's say, the current text didn't have an or that doesn't have an indication what the clients and or the or both actually, the DNS providers and service providers should do if they face some unexpected properties or how the, say, for future extensibility should work if where we need to add new elements. So right now, the proposed text, though there's not it in the in the draft, but there's a text and it pull request on on GitHub to cover it with IANA registry similar to to other elements of such kinds so far. Whereas, they must ignore rule for both sides. However, we thought that the there should be some methods to assure that if appear appear some elements that the client or the recipient has to understand that there should be a a signal about it. So versus, let's say, special meaning creates for the property, which lists the must understand elements. So, basically, if if something appears on this list, the client should reject the template if if they don't understand this property. So I think this also the solution which is used in in Jot, so so probably it's good way to go. Also, the there's a notion of a special prefix for private properties. So if anyone would want to add properties which are not, let's say, part of the of the standard, they will have the a private namespace to do so. And, finally, there is a property telling about the version of the template specification. So right now, it's defined as one as a default if omitted. So this kind of covers all the templates which are in the actual deployment of there. But in in the future, if we ever need to rotate the version, then we can use this property that is defined already. Okay. The second one was about potential conflict of apply parameters. If there will be some future changes to the apply parameter list, where my might appear a conflict between new parameters and something that people maybe defined in their templates already. So templates, something that the protocol cannot control with what variables are are used in there. So the concern is is kind of valid. Cover the let's say, propose approach to namespace all the templates. Variables will be probably too too complicated for all the existing deployment because, let's say, all the templates would have to be rewritten and all the implementations moved. So the proposal is to do it differently. So to reserve a namespace of for all the future protocol parameters with this DC dot prefix. Also, reserve a prefix for private parameters if someone would want to to use such, and all the existing grandfathered parameters would remain without prefix. So, basically, the the future evolution will won't get in conflict ever, and the the current implementations don't have to to break. And, of the let's say, these prefixes are not part of the vocabulary for for variable definitions, so they won't ever appear in the in the templates, in fact. So this change is also drafted on on GitHub. So let's say, I'm I'm happy to see some reviews about about this.

[00:19:39] **Hans Erik**: Pavel? Yes. So you've sent also, you have sent a pointer already on the list. So Yes. Shall we shall we ask for the room? Is there feedback now, or you wanna go through further open issues for the moment?

[00:19:50] **Pavel**: As I said, whoever has feedback at any moment, it's free to join the queue, so we can stop here and Yeah. Yeah. I

[00:19:58] **Hans Erik**: I was just asking because you were, like, just continuing the first open issues, and probably people felt shy on joining the queue or something like that. So, yeah, if I if everybody has has remarks to the open issues, president, please join join the queue. Yeah. Otherwise, we will proceed.

[00:20:19] **Pavel**: Yeah. So I I I heard it about time that silence is agreement. So if anyone disagrees, it's free to join the mic.

[00:20:28] **Hans Erik**: Yeah. I think we we still also have the the mail of the list, which, anyway, is our main thing. So also, of course, we can continue discussions there, but yeah.

[00:20:37] **Pavel**: Absolutely. Right. So there there was also a issue there's also issue open. People wanted that the settings endpoint should be aware of of locality of the of the clients. So if we decline that DNS provider can provide better suited endpoints. For example, some geographically better localized endpoints if the user is known. The current situations that most of the providers, this I talked to, would request mainly based on the domain name. So they know, for example, in which region the the customer is using the service based on the domain name within their account. And the setting endpoint can be also used server to server. So, basically, the the localities also have to be routed between the providers. So the most work what we can do is basically to recommend passing accept language header from the user engine agents through all the hops to the, say, DNS provider endpoint. I don't know if if it's too helpful and it's something that people can do anyway if they want. So my proposal would be to leave it undefined and and close this this issue.

[00:22:30] **Peter**: Hi. This is Peter. No heads. So this is about the locale that is displayed to the DNS provider customer. Correctly?

[00:22:40] **Pavel**: So the settings endpoint, you know, the settings endpoint, let's see, contains the definition of or contains the the URLs of endpoints where the authorization would happen. Right? And the the claim of the of the from the mailing list was, okay, if there is a known locality of of the client, the URL can be customized, for example, to to give the output in the right language or or something like this. Or it can

[00:23:20] **Peter**: So this is before login because I thought after login, the provider knows the customer anyway. Okay. Thanks.

[00:23:26] **Pavel**: Yeah. That's a little bit before login, and and it's at the the the implementation that I know is that based on domain name, DNS provider would know where this domain name is hosted with with in which region and they will route accordingly. And also by calling them the right side, the access language would be anyway provided by the user agent. So so I I see very little value from the protocol on this level to specify more of it. But I'm happy to hear other opinions if if there are any.

[00:24:10] **Hans Erik**: Are there any other opinions on that in the room? Doesn't look like that. Alright.

[00:24:21] **Pavel**: So this also related, I think it was from from you, Peter, about internationalization and how to how to deal it with with it, especially in the in the error messages. So right now, the protocol contains few places where kind of human readable texts are are present. So there's the error description and the apply error response. This is meant to be a text rather for the developers and for for, let's say, the the end user, but it is a human readable text. In the template definition, we have provider name, service name, and which are customer facing and description viable description, which are also meant for for developers. And we have also provided a name, service name on applied template as a query parameters. So the the proposal that we can do is that we because we we don't want to go too deep into, let's say, defining UX. We we just removed a lot of it from from the protocol. So we can also only do in the text about apply flow to give a hint that that the user agent preference should be should be used. And the in the templates, so the provider name service name in the templates is static. So if we want to go into really internal validation of this, we need a special structure like like this one proposal for these properties versus localization element, which provides different names. In my personal opinion, it's probably too much, and we can leave it out. So if any provider would like to, let's say, localize their provider name, service name, they can also deploy a second template with different naming if they have, like, different naming per per language. So so I I think this would be kind of a a feature over provisioning. It was never requested by anyone, let's say, from the from the implementers.

[00:27:04] **Hans Erik**: Any opinion on that? I don't see.

[00:27:13] **Pavel**: Mhmm. So I think it was on the ITF one two four session, but the use case was brought up about different person making service setup versus DNS changes. So, basically, the handover problem if you start the flow with the service provider, and the changes have to be done by by different person department or whoever. So right now, it's only possible with, like, kind of other brands. So you have the link, and you forward it to the person who has access to the DNS. And I think the DNS providers can cover for it already in the user interface, so they can can say, okay. If you don't have login, put this link. And, again, there's a lot of UX related stuff, so not much that we can do on the on the protocol to to support it. Or at least I I don't think it's an issue whether we we should be solving on the on the protocol level. So, also, here, my proposal is to just close this issue and and then let's say we got solving this particular problem or if solving it to the DNS providers if they think they they they need to solve it.

[00:28:50] **Hans Erik**: Anybody unhappy about leaving it out? Doesn't seem to be the case.

[00:29:02] **Pavel**: Good. This was also coming from SP. Alright.

[00:29:22] **Hans Erik**: We can't hear you right now, but we can see you again, Pablo.

[00:29:49] **Peter**: Okay.

[00:29:58] **Hans Erik**: I just sent you some audio issues.

[00:30:04] **Pavel**: Hope I'm back.

[00:30:06] **Hans Erik**: We can hear you again.

[00:30:08] **Pavel**: Yes. Thank you. Thank you. Very, very good. Because I I I I could see you. I but I the impression that you cannot hear me anymore.

[00:30:16] **Hans Erik**: Alright. So we we couldn't hear the past five to ten seconds, I guess, before

[00:30:20] **Pavel**: everything But we were already on on on this slide, I hope, on the slide six.

[00:30:28] **Hans Erik**: Okay. Yes.

[00:30:29] **Pavel**: Yeah. Yeah. So all the issue six. So the the next one was from the HTTP director review to evaluate link sets for applied templates URL flexibility. So, basically, the link sets should be in the in the settings endpoint. But after looking into where we could apply it, it it looks like that it will offer more flexibility, but at the same time, add complexity to the to the protocol. Not not only that, but we'll also be breaking for all the clients, which are not right now, let's say, expecting URL templates in there. And so far, none of the implementers ever rise this point as being an an issue. So the the proposal is also not to to follow-up on this review comment and just leave it as as it is now right now.

[00:31:43] **Hans Erik**: Alright. I also don't see anybody unhappy with that.

[00:31:46] **Pavel**: Alright. So the the next one is related to also versioning, and I think also coming from from Peter's review early in the the days of the of the draft. So the the ask us to anticipate what kind of versioning the protocol should foresee and what kind of measures. So one item I already mentioned before about the version, you know, the template specification. So so this is right now covered. The underscore domain connect takes the direct resource record doesn't have any structure to add version to it. So if we ever come to a second version of of underscore domain connect records, we could add version to it. And now and then it will be kind of different to to the current one and and easy to to distinguish or to process. And all the other endpoints are dependent actually with versioning element of segments. So my proposal is basically to add some clarifying text about usage of this top segment for for versioning, and I think in this in this respect, it would be good covered.

[00:33:25] **Hans Erik**: So sorry. This is Hans Erik speaking as a participant. So I would support definitely considering future versions of the protocol as well. And I have a question. So you say the TXT records don't have any structure for preparing on that. Do you see any issues with that for future revisions, or how could that work around that?

[00:33:51] **Pavel**: Yeah. So so so right now, the record is basically the fully qualified domain name and the path element. So, basically, this is how the clients are expected to pass this record and to recognize this record is is correct. I think the in the future revisions, it can be beneficial to to have a, let's say, key value structures similar to the mark, the human, and other kind this kind of resource records. But when it would start just with version two, and it would be, for the clients, pretty clear how to distinguish this version one without any key value structure and and version version two, which will have one. So I think at least the the what we have is enough of future proof, and I think it's right now, which, again, mean, I would say, for everyone who who already uses the current current version.

[00:34:58] **Hans Erik**: Alright. Thanks. Any other opinions on that? Nope. Oh, I see John Levine.

[00:35:12] **Pavel**: Alright.

[00:35:13] **Hans Erik**: Wait a second. Pablo Pablo, we have John in the or not in the queue, actually, but on the mic.

[00:35:19] **John Levine**: Yeah. I wouldn't work John, can you

[00:35:24] **Hans Erik**: still state you're not actually, not on the queue, and can you please state your

[00:35:27] **John Levine**: I'm sorry. I I am I I I'm still John Levine. I would not try unless you expect unless unless we know that the that the versions will be perfectly upwards or downwards compatible, they're trying to put basically, putting a we have long experiences as putting version numbers into stuff doesn't work because this the stuff that the stuff that doesn't understand the new version will somehow will will will fail on the stuff and the new stuff. Yeah. So I think you you can put it yeah. Mean, you you can try and put that in if you want. But my guess is if if you if you if you revise domain connect in a way that is not likely to work with the with the existing code, you're gonna end up with a different prefixes, you know, underscore domain connect too. So the new so the stuff that knows about the new version will know to look for it, the other stuff won't. So, I mean, I don't think this is terrible, but I don't I wouldn't I wouldn't have a lot of confidence that it will actually do what you think it will.

[00:36:23] **Peter**: So, initially, this was from my review from last year or something. I didn't mean that this necessarily needs some sort of mechanism to explicitly state a version. I more wanted to make sure that the point gets considered, especially when during the further development of the protocol as we're doing it now, maybe some compatibility issue would surface that a certain aspect today could not be addressed in the specification and would require a new specification that maybe would be on the horizon already. So in that case, we we would need versioning. I think no such aspect has so far surfaced, and we have some properties that can just be ignored if they're not understood. And I think it's also fine if the protocol is extensible like that by ignoring new stuff when you don't understand it. And that makes John Levine jump up again. Are you still John Levine?

[00:37:22] **John Levine**: Yes. Who are you by the I mean, I'm agreeing with that, and particularly the the the the the tag that says you have to understand this. I mean, I believe that that actually is a reasonable way to make to to extend stuff without without at least that means when you extend it that you know when you're breaking it.

[00:37:42] **Pavel**: Yeah. Right. Thank you. So there was also a request about, I think, a post also, let's say, on-site of tickets for apply sync flow. With the ask for or or if the concern were the bigger payloads and variables, like several taking keys may happen to exceed the maximum URL length. So as a matter of fact, no implementation reports such problems so far. Theoretically, they can appear, but at least the none is none up to date, the complexity of adding it, it would mean that every server would have a mass to support. Right? Because for the client, it can be an option to use this or or or that. But for the server, it would be a master support, and the GET has also a a benefit. So if you consider, okay, we shouldn't have two options. We should just have have posts. We'll lose opportunity of using get for for redirects, which is used for quite a lot. So it can be also added later and but other than the settings if someone thinks in the future that it's a good idea to add post. So I would just leave it over action, but John may say I'm I'm wrong.

[00:39:18] **John Levine**: You're mostly right. My comment was that HTTP just introduced a dandy new method called query, which has the syntax of post and the semantics of get, and this sounds like an application for it.

[00:39:31] **Pavel**: Right. But in this case, it will be still a future application that can be that can be used. Alright. So we are coming close to the end of this part of presentation. So the next steps which I, let's say, want to take is to close the remain remaining open issues till the next ITF session. So, basically, these are all these issues that you've seen so far. They might appear new ones, especially that the DNS director review was requested, so I expect there will be some some discussion with the mailing list on on those. And if this will be covered, I think this document will be will be pen and ready for working group last call.

[00:40:31] **Peter**: Cool. Let me add one thing to open issue five. So I wanted to add to that as a participant. So this is about when when the person setting up the mapping with the service is a different person than the one that is authorized to make DNS changes. And you're right. The DNS providers may offer better UX for that. Now the person that is making the service set up but doesn't have access to the DNS provider actually, like, when they go into this login flow, they cannot log in. So I so so I don't know how the DNS provider would offer better UX for that. Wouldn't it make more sense, for the service provider that, you know, I'm with whatever, some some email service, and then let's say I want to integrate with my DNS provider, then I usually get redirected into the domain connect flow with the login stuff. That service provider could offer me that I instead enter an email address, for example, where I want that login link to be sent. So that would be better UX by the service provider, not by the DNS provider. Did I get that wrong? And if I didn't, maybe would it make sense to add to the draft that the service provider may offer such a feature, for example?

[00:41:46] **Pavel**: I I think this could this could be solved on both sides, in fact. So so both sides can can solve it for DNS provider because, you know, you are redirected to DNS provider with a given context. So DNS provider can also offer on the login screen additional features saying you you don't have access forward to this link to an authorized person. And because, you know, this is not a normally login screen. It can it can be a cost contextualized login screen if you you are coming from the domain connect flow. But there's, you know, there are many ways to skin this cat, but it's all UX solutions. So I I I don't know how much we should invest time to give suggestions about UX solutions in the the draft.

[00:42:41] **Hans Erik**: Okay. Alright. Sounds good. Hey.

[00:42:44] **IANA Representative**: Yeah. I don't have an there's not an open issue about this, but I'm just looking at your IANA consideration section for the first time, and it's really complicated. Is there a reason why we're why it's so rigorous? Like, what are you what are we protecting here? Why can't we just say specification required?

[00:43:02] **Pavel**: To which which part are you referring to?

[00:43:05] **IANA Representative**: The entire section. The entire section. I have a for so let me let me lay out the three things I'm worried about. First of all, use you're you have a media type registration that says, see this other section for security considerations, but that doesn't answer all the stuff you need to do to make a media type registration. Mhmm. Like, one of the things that ex we or we insist you have is a statement about whether the payload of the media type is executable, and that's missing. So I think you you need to go back and look at what we expect in a registration before you send it to us because this would get blocked in its current form. The second thing is you've got a whole pile of shoulds and stuff in there. Like, you you should put this on the list for three weeks ahead of time, and and the subject field should be formatted a particular way. And IANA is not gonna do any of that stuff. So we need to think about what it is you're trying to bind here because if you if this gets up up for review again, people are gonna, like, what what who are you trying to bind with these rules that you're creating? So this and and thirdly, the just the complexity of in general makes it seem like you're really guarding something that's like a tiny little namespace or something like that. And I just wonder if we've thought all this through or like, I don't know where all that text came from. I went back to the archive just so so I didn't get up here and make a fool of myself, but I I can't I haven't figured that piece out yet.

[00:44:22] **Pavel**: Yeah. Yeah. So so to realize that that this Ayana text is quite quite new. I have to admit I there was mostly copy paste to work from some other Ayana. Oh, gosh. Ayana consideration. So it's it can be that's what I just took the wrong source.

[00:44:45] **IANA Representative**: Okay. I'm happy to work with you on it. I just wanted to make sure I had the context before. Thank you. Yeah. Yeah. Awesome. Awesome. Some comments to the list.

[00:44:52] **Pavel**: So I I'm happy to iterate on on this and to remove everything that is not needed. You know, looking at something that already existed as as prior art was, for me, as inexperienced in writing AI like a solution. Okay. That's fine.

[00:45:06] **IANA Representative**: Not all prior art here is awesome, so we'll I'll work with you on it.

[00:45:11] **Pavel**: Thank you. Alright. So it is now very short update about the asynchronous draft. So as as mentioned, right now, it is just a split off from the from the cold draft with small changes, which were added to to basically make it compatible with each other so that the asynchronous draft is right now built as an extension to the contract. And we have few open issues that you may have feedback on, so I I'm bringing them up here. So this one, we already discussed a bit last time. So if it if the asynchronous apply right now specifies that both query strings and JSON body can be used and what to do with both of these contain the same parameters. And maybe they are they are even, let's say, not with the same values. So there was a clear need that that we need to define the precedence, or we would have to drop one of them. So it it doesn't seem right to drop the JSON body for the post call. So the and the query string, at least, the feedback from the implementers is that it's it's because it's utility. It's useful because it makes things visible in the in the logs and and and so on. So the and the most of the existing implementations, is which a kind of new information, also use, in effect, the the query string parameters. So the revised proposal would be to to keep, let's say, this flexibility to allow for both ways, but define a clear prefer that precedence for query parameters and define maybe that if person, let's say, ambiguity between them with with the same values appear that that that the provider should not process the request. And so it's at least what I would propose to the working group, and I love to hear if any if there's any feedback on on this.

[00:47:51] **Hans Erik**: Any opinions here in the room? Yeah. Let's see.

[00:47:59] **Peter**: So I appreciate that. It's useful to have some stuff in the query string. And so the same stuff is also in the JSON, which could happen. Right? Here's a precedence rule. Would it perhaps make more sense to have an error when the JSON does say something else than the query string and only accept the query string parameter when the JSON doesn't say anything about that setting or property?

[00:48:31] **Pavel**: Yeah. So I I think there are the two two approaches. When you say that the one is always right or you you just demand, okay, they if they are appearing twice, they have to agree. And so to

[00:48:42] **Peter**: the I think there is opportunity for misunderstanding. If you have, for example, the domain name or something in the JSON, then somebody could think that it's constrained to that particular name, but it can be overwritten in the query string. So that could be confusing.

[00:49:01] **Pavel**: And so so so you mean so you mean that it's better to, let's say, make them always agree and and if, let's say, there is an overlap which is confusing, just, let's say, don't process the request at all.

[00:49:22] **Peter**: Yeah. So maybe allow it to be defined in either the query string or the JSON or both, but only when it's consistent.

[00:49:29] **Pavel**: Yeah. Alright. It's good feeling. And there was also one remark from the sector review that we should consider another use case of automated deployment pipeline. So the response to that would be that already the async flow hours for this. So as soon as you have tokens, you can use it, let's say, in the automation. But I don't know if this use case is very useful as such at all because the changes are always constrained to what the template is defining. So your automation would be just constrained exactly by that. And, likely, the use case, what is asked is for more more, say, generic template less DNS updates, which could be added as a new flow if some in some future draft specifications, but I wouldn't tackle it or add it as an an, say, additional scope to to this draft.

[00:50:57] **Hans Erik**: Alright. Any opinions here? Oh, I see one.

[00:51:01] **Peter**: I have a question. So why do you say it requires a template less DNS update process? I mean, just because something is automated, it could still use templates.

[00:51:14] **Pavel**: It it could, but I said the the template has to exist. Yeah. So so as as as as long as you work within a template boundary, you can do it. So there are some applications of people doing dynamic DNS with it. So you have the template which allows for update of a record, and it it works. Yeah. But but if you have I don't know. I'm not an expert in, like, kind of this automation use cases, but I can imagine that this automation that they want just to define the DNS record they want and expect them to be to be applied. And this is where I I think that's to for this whole use case, probably the different solutions basement may need to be opened.

[00:52:01] **Peter**: So this issue is from this from the sector review. And to me, it sounds like what they're asking for is for automated deployments, a way of authentication that is not OAuth, but, for example, PKG certificates for for TLS client authentication. And Mhmm. So that's different from the template constraint.

[00:52:23] **Pavel**: I would have to take a look exactly again, but as far as I recall, the issue was like a comment saying that the protocol is useful, and it would be even more useful if it considers this use case as well.

[00:52:39] **Peter**: Okay. Fine. Yeah. I mean, I agree with the conclusion anyway. But

[00:52:46] **Pavel**: Alright. That's good. There are some other open open issues on on on GitHub, but I I said I don't put it the full focus on the async draft with more focus of on the on the sync one to be to be closed. And, also, on this one, I think that's very relevant to have the review from our working group, which was requested. And, hopefully, they will come out of the AD queue that they have now right now, and sometimes they they come to the the review, and and if we get that and the the issue sorted out, I think this this document is is also pretty in good shape. That's all that I have prepared as a transition.

[00:53:47] **Hans Erik**: Alright. Thank you, Pavel. Mhmm. I'll switch back slides, but okay. I think you need to release first.

[00:53:59] **Pavel**: Alright.

[00:54:07] **Hans Erik**: Yeah. Alright. I mean, you already have next steps on your slides, Pavel, so I would have one question here. We shortly discussed in front of this meeting about the milestones which are currently set in the data tracker. So for the moment, we agreed upon end of this year as a milestone for the core draft and March next year for the second draft. Do you think there's anything we need to change about that, or can we keep for the moment as it is? I was also thinking about, in the end, is it something we will anyhow send separately to the ISG, or do you rather think both should be sent in parallel? Or what's your opinion on that?

[00:54:48] **Pavel**: So in in the structure that the documents have right now, the call draft can be sent separately, and I think this this milestone should be fine. So following this this plan to 01/27, if we have this issue sorted out and in the shape ready for the working group last call and end of the year, I think it's pretty reasonable as as a milestone. Mhmm. Yeah. And, of course, the the more working group activity would be, then the the the better we will get. Alright.

[00:55:30] **Hans Erik**: Makes sense. Thank you. Okay. Is there any other business or any further comments on some presentations or the drafts from the group? Counting one, two, three. If not, this ends our dconn session. Thank everybody very much for participating, and I'm giving you another five minutes into the break. Thank you very much, and see some of you, I think, in San Francisco and on the list. And thanks, Pavel. Germany.

[00:56:10] **Pavel**: Thank you.

[00:56:15] **Hans Erik**: Yeah. Yeah. Okay. Alright. Party. But what's this in? Is this Nialla's one? It is like yeah. It is like as in case, a number to preference to the base, just pocket of the noise and we need