Session Date/Time: 20 Jul 2026 07:00
[00:00:45] Chris Box: Good morning. Welcome to DNSSD, and this is the first session of the week. So good to get started your I t f week having exploring some DNS service discovery. If you take us forward so as I mentioned, this is DNSSD. I am Chris Box, and here is my co chair, Florian. And here is the note well. So this is a reminder about the policies that that that you agree to follow when you participate in the IETF. It covers conduct, privacy, and intellectual property rights, so please read it carefully. You're encouraged to read the source documents to which the note well refers. The QR code will take you to read to those. If you have any questions, please talk to us afterwards. And if you're in the room, please make sure you sign in to the session in data tracker. Everyone, regardless of whether you are at home or or or in the room, you can use the Meetecho client to join the queue. And when you are speaking or before you start start speaking, state your name. So we have a a GitHub organization where we host our working group documents, but individual draft authors can also contact the chairs to get set up. So we have a number of documents and the this is the status of the adopted documents. Multiple queue types is currently being edited by the RFC editor. TSR and advertising proxy were recently updated, and we'll cover those. SRP replication is on hold, but will be returned to. We have a number of relevant individual documents. Infrastructure and six zero will be discussed today. Removal services, we will is not on the agenda, but we may come back to it. So this is our agenda that we plan to go through today. Is there any request to change this order? In that case, we can move on. So we have so the the existing charter for the group is relatively old, and we need to revise it. That link there hosts the proposed text, but I've got it on the next slides to to you know, so that you can have a sense of it if you haven't had a chance to to have a look at that. So the charter starts with the background just like the old one did. It it talks about SRP. It talks about discovery proxy and the ability to to discover services using Unicast DNS. So if you go back to the yeah. So we also now have we lead onto at the bottom there the the example deployment of of this technology, which is in the Thread border router, which implements a snack router, enabling bidirectional discovery between the Thread mesh network, which uses SRP, and Ethernet, which is using MDNS, and which is, of course, used by Matter. So that's one example of the deployment of this technology. So that's the background. If you go on to
[00:04:43] Esko Dijk: the next slide. So what we're proposing now for the for the charter for the working group,
[00:04:52] Chris Box: the part at the top is the same as before. The main items to work on so we've got four of them shown there. So defining how to publish SRP registered names in multicast DNS, defining mechanisms that improve the efficiency, availability, and effectiveness of DNSSD, and defining how to resolve conflicts between competing updates of the same name. And the last one there, describing how the different protocol components can be just combined to make a complete DNSSD service is equally accessible by mDNS and SRP clients. So if you have any thoughts on whether those are the right goals for the working group, please please join the queue. There's a there's a final section on the next slide. So we will consider the privacy and security requirements, collaborate with Snack and other DNS working groups as appropriate. We will not integrate with other zero configuration service and naming protocols, and we will not update general DNS protocols unless there's an exception. So if you go back to the previous one, does anyone have any thoughts on that charter?
[00:06:20] Ted Lemmon: So I Ted, I'm gonna apologize for not having read this as closely as I should have, but I don't see there the thing that I think we need to do for advertising proxy to make it less punchy on the network, which is some updates to MDNS to talk about how proxies cooperate, which I think I don't know if it don't think it necessarily requires a protocol update, but it's kind of a multicast DNS topic. So I don't know if that if this charter maybe the first bullet item covers that. I guess it does.
[00:06:57] Chris Box: Did did you does the second bullet cover it?
[00:07:03] Ted Lemmon: Yeah. Okay. As long as basically, the thing I'm trying to avoid is having a MDNS protocol changes, if necessary, be out of scope. I don't want that.
[00:07:14] Chris Box: Understood? Let's make yeah. Let's try and make that as clear as possible. That's good.
[00:07:21] Esko Dijk: That's correct. So I saw saw there was a part about not kind of interoperating with all our protocols. That was explicitly excluded part. So but, other working groups can basically do something that that integrates with DNSSD, I think. Right? That's, if it goes the other way around. So we're still thinking, like, in the future, there might be some mapping defined between, yeah, basically, the core working group link format discovery or resource directory and what DNSSD defines. So I think that could be in scope, but not in this working group, I guess, then it's but in others can still do it. Right? So that's
[00:08:05] Chris Box: We we are only defining what this would be.
[00:08:07] Esko Dijk: Indeed. Yeah. Yeah. So that's okay then. Okay. Thanks.
[00:08:11] Chris Box: Thank you.
[00:08:16] Frank Brockners: Frank Brockners. I have a bit of a stupid queue question. Is it like if we define new service types, say for agent discovery, for instance, on a local network, would they happen here or would they happen in Dawn? Maybe that's a question for Eric.
[00:08:42] Stuart Cheshire: Stuart Cheshire speaking for myself. To answer that question, I think it makes sense for this working group to be an area of expertise. So if other working groups have questions, Esco talks about the core working group. If they're writing up some draft that relates to this, then they can certainly circulate it on this mailing list to get expert review. And likewise, you were talking about I've been hearing discussions this week at the ITF about well, everything's about AI and how do you discover AI agents. Maybe that's no harder than discovering a printer, or maybe there is something different about an AI agent that's different to other bits of software. That is something certainly where we have the expertise in this room to have that conversation that doesn't make it a chartered work item for this working group, but we can act as consultants to other ITF working groups to advise them and guide them and brainstorm ideas.
[00:09:47] Éric Vyncke: So hearing link is a responsibility for DNSSD. And basically rephrasing what Joanna said. It's quite common that we extend we ask for expertise in other working groups. Right? It depends maybe here or maybe other part. So that's normal. And sometimes the the chair of other working group, we extend the working group last call to DNSSD, for instance. So if there was something to be done in the AI related working group, this AI rated working group will most probably the chair will ask forward the working group last call in their working group to DNSSD to provide inputs. And typically, the responsibility double check as well. And other points not related to this part, the charter is really a contract between the IETF community and this working group. So it's really important. So I really ask everyone in the room to read it because that's really important. And thanks for doing the job.
[00:10:48] Carsten Sperling: Yeah.
[00:10:52] Chris Box: If you go so in in the so this this charter is is hosted in in the GitHub. And there is one issue opened in there, which is I think, Esko, you you touched on this pre previously. So it's there is an open question whether we need to add something about this point. So this is about the timing of messages and trying to make that more Wi Fi compliant. And I it's a note it's just a point for you to consider. Does this this item of work, do you see that as fitting within the work items? So if we go back onto the not that one. That one. So, again, this this second bullet point here is define mechanisms that improve the efficiency, availability, and effectiveness of D and SSDs. So if we go forward to the open item again, please. So the this is clearly an efficiency point. However, if we wanted to, we could we could make it more explicit. So if you have any opinions, please come to the mic or join the queue.
[00:12:26] Ted Lemmon: Ted Lemon again. Just I think it would be like, you say DNSSD. And if we understand DNSSD to encompass MDNS, then that works. But if we don't understand it to encompass MDNS, then it kinda doesn't. And I think that's my concern. So that's why I'm saying, like, you know, you could say DNSSD including MDNS. Mhmm. And that would that would address my concern. Makes
[00:12:51] Esko Dijk: sense. That's correct. So, I think, I wanted to say exactly the same. So, it fits well within that bullet if we, yeah, include m d n s somewhere there for the efficiency part. Yep. Thanks.
[00:13:07] Chris Box: Thank you.
[00:13:11] Florian Obser: So we still do a show of rounds with, you know, saying we will clarify MDNS? Yes. Yeah.
[00:13:33] Éric Vyncke: This is
[00:13:33] Florian Obser: where we're getting to know. So
[00:13:37] Chris Box: we're slightly ahead of time. So I'm just gonna yeah. So just a show of hands. So the question is, you know, are you happy for this chartered text proceed assuming that, yeah, if we make the changes that have just been made, so we clarified the multicast DNS is in scope for the charter. It's this is not committing you to anything, but do you is is it your current feeling that this chartered text is is a reasonable one to proceed with? And it's perfectly valid to say no. And if if you think it's not quite ready and you haven't expressed why, then, yeah, we love to hear why because we wanna get this right. And this is also a cunning way to make sure that everyone signed in to meet. Okay?
[00:14:45] Florian Obser: See, Andre, still looking for keywords.
[00:14:53] Stuart Cheshire: Seems to be stabilizing.
[00:14:55] Esko Dijk: Okay. Last part failed.
[00:14:59] Chris Box: Yep. Just adding a few more. Okay. I think we can finish there. Thank you very much. So that concludes the next part. So we can move on to the next item. So if you wanna share those slides. So, Carsten, if you like to come on. Thank you.
[00:16:01] Carsten Sperling: Yes. Hello.
[00:16:02] Chris Box: Hello.
[00:16:03] Carsten Sperling: My name is Carsten Sperling. I'm I've recently come on board with Ted as a coauthor on the full service DNSSD or DNSSD and infrastructure draft. The name is a bit in in flux, I guess, still. And I apologies for not getting the the draft out before the before the blackout. It was held up a little bit on our internal legal wait states. So we unfortunately could
[00:16:28] Esko Dijk: only share
[00:16:29] Carsten Sperling: the the draft GitHub document to the to the meeting. So I I don't know if people have had a chance to read it or not. So I'm I'm gonna just sort of summarize briefly what the what the changes are that we've made and then probably open for any questions or or discussions. So so the first thing is that we've we've decided to give the thing a slightly more distinctive name DNSSD server. Sort of sounds a little bit ambiguous what exactly that means. So we we thought we we could call this thing unicast local discovery as a sort of makes a good acronym as well, ULD. So that's that's just a little side side. But can I change the slides myself, or do you have to move to the next slide from your end? Thanks. Yeah. So the so the for for those not familiar with the draft so far, the the goal is essentially to do link local discovery in in a way that involves no multicast or minimal multicast because especially on Wi Fi networks, multicast discovery has obviously, multicast has various issues around the lossiness of multicast packets and especially for power constrained clients that would really like to sleep for them being able to receive multicast and respond to their DNS multicast DNS requests means they have to essentially be awake for all the DTM beacons to to to do this. So we're looking for a way to to have a a central server act as an SRP registrar discovery proxy and advertising proxy and and the Unicast server. And for this server to essentially handle DNSSD discovery via Unicast on the link. And when when such a service is available, the the idea is that those those clients that understand this protocol can then just ignore m d n s traffic and don't have to themselves participate in m d n s, but they will still be discoverable in m d n s via the advertising proxy, and they can still discover m d n s services via the advertising sorry, discovery proxy and and advertising proxy. So the the changes from the draft version two, the the biggest changes that we say, wanna directly use the dot local domain for both the for the registration via SRP and and for the queries from from clients. This is because, essentially, we want to encourage that that ULD can be adopted at a sort of system or a DNSSD library level rather than having to be adopted by individual applications. So, ideally, we want to define this in a way that these libraries can implement this Unicast alternative to to MDNS and and then more or less transparently adopt this. So for that to work, we we want this zone that ULD uses to have the same semantics as dot local. Or or or put another way, we're interpreting dot local to be a semantic thing, meaning services on that link rather than a thing that specifically selects MDNS as a as a transport. So as a consequence, essentially, we sort of have to say we're updating RFC six seven six two to say dot local queries must be sent to either the ULD server or they must be sent to multicast, whereas currently, MDS mandates that they be sent to the multicast addresses. Record everything will remain kind of link local. Clients can connect the connect to the ULD server using a link local address, and that preserves the the link local scoping and off link queries for a dot local name are refused by the by the server. And then a sort of positive benefit of using dot dot local directory, it's also that the rewriting that advertising and discovery proxy would normally have to do other than no ops. Sorry. Some other changes are that we've refined a little bit how the how the ULD server itself gets discovered to to explicitly use, like, a normal DNSSD service, whereas previously, it was sort of defined to to just directly use specific SRV records. So we're suggesting a service type of maybe ULD or TCP that needs to be registered still, of course. And the text record carries a a server priority and a and a text key. And we want both infrastructure and ad hoc servers to be advertised in this way. And one of the benefits of this is that then ULD clients themselves can use ULD to do the three SSD query to to find a potentially better service. And we've added a tiebreaker that allows that makes it kind of unambiguous with which server is the most preferred. So the they get sorted by priority order, and when there's multiple with the same priority, then we choose the one with the lowest link local I p v six address. And that means clients, in general, will converge on the on all using the same server on on a particular link with the the infrastructure server being the most preferred server that has priority zero. The infrastructure server is also advertises itself via an RA option that's that's to be defined in detail. But the way this is currently envisaged is it just needs to be a flag that essentially says the router that's sending this router advertisement is the infrastructure ULD server. And one sort of side benefit of that scheme is that well, first of all, it provides a a sort of quicker way for for an I p v six client to discover the infrastructure server if one exists because it already receives RAs anyway. And the designation of the infrastructure server can also be protected by RA guard on on networks that that deploy it. Then there's some other smaller changes. We're discussing in more detail how how query results that are received over Unicast, how they get combined from the responses that come from the zone that have been registered via SRP or and and and both and from the discovery proxy, I. E, how how those results have have to be combined. We've also got a small thing there that allows a constraint client that doesn't support TLS to do unicast standard unicast DNS queries to to obtain shared records. So this discovery proxy, the way it's currently written sort of only envisages the use of standard queries for for unique records because the response is always it it just responds with the first with the first records that that come back, which may not be the complete answer. And then even if you query repeatedly, there's nothing that currently guarantees that that when you query again, you won't just get the first response again that but that you'll actually get eventually get to the full set of services. So we sort of have a little scheme defined for how the server just effectively has to treat it as if there's a short lived DNS push subscription, then that way a constrained client can perform a a short sequence of queries and get the full result set for a a a set of shared records. We've added some discussion of I p v four and dual stack support. Eventually, the preferred and required support is for I p v six. But the server must also participate in m d n s on v four so that discoverability of v four only services is possible over ULD. And the other way around that dual stack services continue to then also be discoverable by I p v four only MDNS clients. And then the the remaining changes we've we've discussed when a CEO auto should claim this infrastructure status. So infrastructure being the most preferred most preferred service that's that's expected to normally be deployed intentionally by on a managed network, it has to be deployed intentionally by by whoever manages the network. But in an unmanaged network, like a home network, we sort of have some suggestion for when the CE router should claim this infrastructure status by default. The remainder are mainly sort of editorial changes and and just focusing the text a bit on this link local use case. A number of we've got a few things that are sort of still open that maybe be good things to to discuss here. And obviously, we'll I'm happy to take other questions. One one question is that to encourage the sort of library level adoption, I think we need to provide a way for a DNSSD library to sort of preserve its existing API contract in in terms of how contracts on mDNS are handled. So obviously, we we can hand conflicts that happen within SRP are handled by a the y x domain response, and then the the the client can decide to rename how it how it chooses. But if the conflict exists only on, excuse me, exists only on MDNS, then there's currently no no feedback. So I think it would be useful if there was a minimal amount of feedback from the ULD server to the client about the fact that an MDNS conflict exists for any of the records within within the SRP request. But that's not in the current draft. That's sort of an open discussion item. Another open item is whether we should support ad hoc all service, including ad hoc service advertising themselves via the router route advertisement option. In that case, the option would need to carry more more information than just being a flag. Currently currently, it's for the infrastructure server, all the information is already essentially present just by knowing that that server is the is the infrastructure server. One other item is this what I mentioned about these using standard supporting standard queries for shared record queries. A different option would be to maybe allow link local DNS push to use TCP without d n without TLS, which is currently explicitly prohibited. So that could be an alternative and or additional option to supporting these repeated standard queries. And a a final question that's not at all touched on the draft currently is whether whether we should do anything about reverse address mapping request switching and MDS, of course, also get get handled. So should should we also support them or do we not care? But that's an open open question. So, yeah, these were my slides. I think happy to take questions. I don't know if Ted has anything to he would like to add specifically.
[00:28:47] Ted Lemmon: Sorry. I had to push the raise hand button. No. Eric's first, though.
[00:28:50] Éric Vyncke: No. No. No. Oh, so Eric Link is not a responsible lady this time. So, Carson, first, congratulation. Right? First draft, as far as I know, first presentation remote, which is not easy. Having said this, I read the part about the router advertisement part. I think that the the text should mean me as crisper and stricter. It's kind of ambiguous right now, which is no matter basically for for this at this stage. You also also really need to say, hey. I have no array with this flag. I got something I learned from MDNS, then I received the array, which is the winner. In this kind of the risk condition, I don't think they are yet in the in the text. Again, congratulation.
[00:29:35] Carsten Sperling: Thank you. Yeah. So on on the I think we've got some text, Carly, that says sort of the infrastructure server also advertises on on emptiness so that the emptiness should always be complete, but your your clients are required to check before they trust that something really is priority zero infrastructure server. They should they must also check the the route advertisements. That's what the text currently says. I guess it doesn't really specifically say what happens. Yeah. Like you said, if what if for some reason it's not in the m d n s list. I guess that's a case that normally shouldn't happen if the server does what it's meant to be doing. But I maybe we need to think about if we need to handle that somehow.
[00:30:14] Ted Lemmon: So I swear I I pressed the hand raise button, but it didn't seem to happen. So apologies. So regarding the router advertisement, I think we're maybe, like like, the of question of whether it should be advertised in ad hoc servers or not and whether it should be a like, is it harder to do a flag? I think the answer is it's just as easy to do an RA option as it is to do a flag. So if we think it's at all useful, and I actually personally do, to use router advertisement for ad hoc servers, then why don't we just make it an option that says that this is available in all cases? So in other words, the infrastructure server says, hi. I'm the infrastructure server. My priority is zero. And the ad hoc servers do the same thing except they put their the same priority that they put in their text record in the RA. Now you don't have to do the the MDNS query to find out what the priority is, and that saves you. I think sort of requiring the MDNS query is kind of not accomplishing the goal here. Like, we wanna minimize traffic. And so if we if we can avoid that query, that's that's a good thing. That was my motivation for doing it in the ad hoc servers as well when it's possible. So that's that. Totally agree with the the DNS pushover TCP. I think when we when we did that requirement originally, we didn't really have the the the constrained device use case in mind. And so we were thinking about user privacy, but a typical constrained device doesn't have a user privacy issue because it's a light bulb. So probably we don't care what domains it's looking up. And then on the topic of MDNS conflict stuff, I actually like, I was thinking about this because we had a big debate about this privately, a couple weeks ago. We don't see eye to eye on this if anybody was curious. And and I realized, actually, it kind of doesn't make sense to say and and that doesn't mean that you should shut up about it, but I'm just saying it doesn't make sense to say this in the ULD draft. This is actually an advertising proxy issue. And we have an advertising proxy draft, so we should really specify this in the advertising proxy draft because I don't think that it it ought to be different for ULD than for other advertising proxy use cases. I think other advertising proxy use cases are essentially the ULD use case without all of the nice handy extra ULD wrapping on them. So they're, like, they're basically they're ULD. They're the ULD use case, but we just didn't have ULD yet. So then we should just do this in advertising proxy. As for whether we should do the conflict stuff, I I will point out that the main motivation for doing the conflict stuff is to deal with nonconforming basically, clients that behave badly. Right? So part so we we decided we wanted to use the dot local domain instead of some other domain because that's what everybody does now. And there are people that are abusing the the MDNS APIs on Apple devices, probably on other devices too, but I happen to know the Apple case. They're abusing the API by providing a dot local domain when what they really mean is the default domain. So in other words, they're they're they're explicitly saying use dot local when what they really mean is use the default discovery domain. And because they're doing that, we have this problem that we sort of feel like we have to use dot local, and we have to suffer through all of the broken you know, necessary for MDNS, but broken for DNSSD collision detection stuff. Right? So I'll talk about this a little bit more in the advertising proxy presentation, but I think we should maybe think very carefully about how we wanna solve this. And and your approach may be correct, but but let's let's have a good, you know, solid working group debate about it.
[00:34:06] Carsten Sperling: I don't know. Am am I meant to raise my hand to to respond to any of these questions, or I don't I don't know what the what the topic is. I'm sorry. I think yeah. Thanks for those comments. I think, like, maybe one one point I wanted to make about I think, yes, it would be great to handle this as advertising proxy. I do think ULD is sort of slightly different from the generic advertising proxy use case, and that advertising proxy just to us is like, well, you're you've got some zone that's sort of different, and you're just mirroring it into into m d n s. Whereas here, we're more explicitly saying, actually, ultimately, we're trying to have the same zone visible on both protocols. So you've got interoperability both ways with m d n s devices and and device that support ULD. So so I think the the the promise of interoperability is slightly stronger, and there's I feel like there's less of a case of just saying, like, who who cares what happens on the MDNS side? I I feel like we have a slightly higher bar of of what we should, aim for there.
[00:35:09] Esko Dijk: K. Scott Eich. Yeah. There can be a lot of discussion on this slide alone. I think with just two quick questions. I think, for, the priority, item, it says in the text text records, I was just wondering, yeah, why not use the the numbers that are already in the SRF record there for priority and waiting?
[00:35:37] Carsten Sperling: I don't know. Maybe somebody else can answer that better than I can, but my understanding was that they are they are defined to be priorities for different servers within the same service and and therefore not applicable essentially in this kind of use case where you're distinguishing different service instances. But may I may be wrong.
[00:35:59] Ted Lemmon: Ted Lemmon here. I think that the reason that we do that is actually just because the API currently doesn't expose the priority, and so we would have to change the API in order to support it, which is kind of a bogus reason. But, nevertheless, that's the reason.
[00:36:16] Esko Dijk: Okay. I think I saw that kind of problem before in some cases in the past. So not sure what we should think about that. Okay. And that's But there's
[00:36:26] Carsten Sperling: a case we need to fix it.
[00:36:27] Esko Dijk: Yeah. Indeed. And the other question was I had was about the reverse address mapping. So was that a yeah. I'm not sure what the background was. That question, like, should the UOB server actually do this or implement that? Or I'm not sure what was the question there.
[00:36:47] Carsten Sperling: Yeah. I think it's actually the question. Like, MDNS says that that when you have a reverse mapping query for a for a linked local address, then they then it gets sent to to MDNS. So if we're sort saying, hey. ULD can kind of step in for for m d n s, does that mean we we should should they be directed to the ULD server and the ULD server should do something meaningful with it? And if so, how does it get all the How does it does it have all the mappings? I don't know. Haven't quite thought through that whether it could meaningfully respond to these in all cases, I guess.
[00:37:20] Esko Dijk: Yeah. Okay. Yeah. The question maybe at high level is show show handle it or ignore it, kind of. Okay.
[00:37:27] Carsten Sperling: Right.
[00:37:28] Esko Dijk: And yeah. Thanks.
[00:37:31] Ted Lemmon: Ted Lemmon again. So the way that works in MDNS currently, at least on Apple devices, is that if you do a reverse query for a subdomain of I p six dot ARPA that is locally resolved, or if you do a query for, you know, what is it, the one sixty nine to two dot two fifty four addresses, it will actually do the reverse lookup of that specific name using MDNS. So in other words, it's not doing dot local. It's doing in adder dot arpa, but just for that specific subdomain of in adder dot arpa that's locally that's always guaranteed to be locally resolved. So I think it does make sense to to in to include that behavior here as at least it should. It might not be a must because maybe you have a device that just doesn't have the resources to do the extra stuff, and maybe we don't want to consume that bandwidth. But it is beneficial. I use it I personally have have used it for debugging in the past. It is it is helpful for me. So speaking very self interestedly, I'd like to have that functionality just for that reason. But it's certainly worth just debating whether we really want that. So that's where I'm at.
[00:38:53] François Michel: Francois Michel. So small clarification question. Other for the the first bullet, actually, the second one, the first sub bullet. Other signals that we cannot right now already carry through return codes. I think for conflicts, there are already some return codes we could use. It's complicated. Complicated? In what sense?
[00:39:20] Donald Eastlake: Per is it the protocol level?
[00:39:25] Ted Lemmon: The issue is not at the API level. It's at the protocol level. Like, what do we do? Do we actually have SRP be able to signal back that we got an MDNS conflict or not? Yeah.
[00:39:38] François Michel: Okay. I I thought it was at the protocol level that we were discussing, but it's actually just at the API level? No. Okay. No. It's at the at protocol level. Right. Right.
[00:39:48] Ted Lemmon: Do that.
[00:39:48] François Michel: Right. I thought that was the actual question of the slide.
[00:39:54] Carsten Sperling: Maybe that's just my framing of the of the point. Essentially, the the point was that n d n s d n s s d APIs tend to provide a way I mean, most of them provide when they do auto renaming, they tell you what the final name was that you actually got. And many APIs also support telling you and letting like, telling the application and letting the application handle the name. At least at least some support that. And and and I think for, like, Avahi, for example, that's the only way it it handles it as far as I know. So, essentially, if these implementations want to keep supporting that behavior for MDS conflicts even though they're going via ULD, then we need that kind of feedback information in some sense. Because the the the other alternative that was previously an advertising proxy was that the advertising proxy itself rejects the whole SRP registration until until MDNS is kind of acquired. And and that was sort of rejected as as not not the way things should things should go that essentially the SRP itself should should accept the registration if there's no conflict within its zone. And so so that only reject for SRP conflicts and and not reject for MDNS conflicts. So the the proposal doesn't have to not not to relitigate that, but just just to add a little bit of extra information so that you can recover that extra bit of information on the client side to say, okay. The SAP registration was successful, but there is an m d n s conflict.
[00:41:27] François Michel: I see. I see. Thank you.
[00:41:38] Florian Obser: Actually, I have a
[00:41:39] Éric Vyncke: so what would you like to
[00:41:42] Florian Obser: do with the draft next? That's individual draft.
[00:41:47] François Michel: Can we adopt it?
[00:41:50] Florian Obser: We probably could, but then you're not in the queues.
[00:41:55] Esko Dijk: Okay.
[00:41:58] Éric Vyncke: We put us on the list.
[00:42:02] Chris Box: So I'm just gonna do a show of hands to get a sense of the room. So
[00:42:30] Stuart Cheshire: Actually, I just wanted to add a comment about this because I maybe Carson said it and I missed it. But I think it's worthwhile pointing out some of the background why people are interested in this. Matter is getting very successful these days. And if if you put a 100 devices on your WiFi network, that becomes a lot of multicast DNS traffic. Multicast DNS was great when you have a laptop and a phone and maybe half a dozen devices. But you put a 100 or 200 IoT devices, the multicast traffic is it becomes out of control. It doesn't scale well. So there's a lot of interest in matter about how to do more scalable, more efficient discovery. So that is the motivation for why there's interest in doing this right now. Oh, and I should add, it might not be obvious to everybody. With Thread, we already did this because we knew we didn't want to flood the Thread network with lots of multicast traffic. And that's worked very well for Thread. And seeing how that works for Thread, there's now an appetite for could we do the same thing on multicast as well? On on Wi Fi as well? It's a bit more of a challenge on Wi Fi. I I don't wanna make it sound like it's really hard. With Thread, we had the luxury that we had a greenfield development. So just starting from scratch, we said this is what we're going to do and everything works the same way. Now that we've got twenty five years of deployment history of multicast DNS on WiFi, we need a forwards, backwards compatibility migration story so that your your ten year old device doing multicast DNS continues to work. So there's a little bit more factors to consider on WiFi because we have that legacy, but conceptually, it's it's the same reason for doing it on Thread.
[00:44:47] Carsten Sperling: Thank you.
[00:44:48] Chris Box: So we had 11 people say yes. There were no noes and 11 and sorry. 18, no opinion. So we can now move on to the next section. Yep. TSR is up next.
[00:45:35] Esko Dijk: So Cool. Testing. Timer check. Hello, everyone. I'm Esco Dyke. I'm presenting the CSR draft here, multicast DNS conflict resolution using the time since received. It's not DNS option.
[00:45:51] Florian Obser: This works. Thank you. I tested it.
[00:45:57] Esko Dijk: So this is a kind of quick graphical recap of what CSR is doing in a specific deployment scenario. So I also showed this last time, so that would probably mean that I'm now going to go quicker over it, but it's good to to show it. So that basically shows a network topology where you have two so called snack routers. Those are devices defined in the snack working group. So it's sort of a ad hoc IP router that can, yeah, basically, as a router on behalf of six low pan network that's behind it or in other type type of network technology. So six low pan is in, for example, IoT mesh network, like, defined by Threat. And there, we do use, basically, SRP registrars and advertising proxies as defined by this working group. And now you can have basically device using a Unicast update in this mesh network to, register its records, and then those get advertised on the AIL, which is the Wi Fi or Ethernet link in the home. So there is a TSR option added. So at the moment of initial registration, the TSR is zero. So that's the time since received. So that shows that the records are fresh when they're advertised. Now there can be a change of situation, so that's shown in the next slide, that suddenly, for whatever reason, the device now has registered to another SRP registrar. So it can't reach the first one anymore or maybe that went down, whatever. It goes register its service at second one so that it's still findable in the home and can keep functioning. Now that one also advertises the same service, which would normally be a conflict. But now we have the TSR option included, says TSR zero, while the one on the left, which might still be advertising on the AIL, has a TSR, for example, 300. So it's, like, five minutes ago, I received the last update. And now that means with the t r TSR option that the newer registration basically wins, there's no conflict between the MDNS records, but rather the the old one, the stale one is removed automatically, and the new one wins. So it's also verified that this came from the same original requester, the green the green circle. So that's what it's about. And, yeah, next, I will be presenting just quickly the updates since last ITF. We talked about this and open issues that are currently there. So what are the updates? So there were quite some editorial updates, some more consistent use of terminology, applying SFP terms, clarifications. There's now also an informative references section, and there's at least double, yes, double the number of defined terms. Not sure if that's good, but at least this shows that we're more formal about it. So there's really more formal definitions for the things we use, and that that's good because it's makes it more specific, I think. And there's an option format that's shown on the slide here. So that's a graphic of the option instead of just describing it at as text. And there's one more of that slide. So there's some more details, mainly on the probing and the processing of TSR and also use cases, so when to use TSR. There were some sections added about suppression, so that's basically to specify when the MDNS messages what what cases they are not sent to make it more efficient on the wire. We have a section with details on how to handle multipacket and DNS advertisements. And there's an appendix added so that has an example showing a particular case in detail. So that's all about the updates, and that resolved some open issues as well. Yeah. Looking at the open issues in GitHub at this moment and in the document itself, this one came up. It's a bit of a scope question. So, that came from me, actually. So, while editing, I thought it was still unclear what is what is really the scope of section. Basically, that's 3.8 that talks about replication. Should should we be mentioning that at all in the draft? So the idea is that CSR can be used by a proxy type of device, and that proxy type of device could be replicating DNS records with other devices. So we have a draft for that in the working group, the SRP replication draft. So it goes through a quite detailed scenario there and also has some normative requirements. So it's mixed together. And I was a bit puzzled about that. So I think the proposal I had in my from my point of view is that we should actually specify the processing of TSR kind of independent of of what's the origin of the records. So that's the registrant basically supplies the records, and there's the registrar that advertises them. And, yeah, maybe we should have kind of generic rules for that processing of TSR regardless of where it came from. So that proposal here that I had is, like, we can still have a nice walk through about, well, what's what's happens in the replication case, but should not be mixed, I think, with normative requirements specifically for that case. And I see that that has something to comment on this. So go ahead.
[00:52:06] Ted Lemmon: Yeah. I just I think anything you see in the replication draft, it's an old draft. We haven't updated in a while, and it's probably gonna change a bit. So when we do finally update it. So you shouldn't worry too much about that. When it when it comes up, we can fix it.
[00:52:23] Esko Dijk: Oh, yeah. But it was in the current draft. And basically, TSR had the Yeah. Section about, well, in the replication cases, do x and y
[00:52:29] Ted Lemmon: Yeah. Basically. There is actually so so one of the things that that kind of came up, and Francois will be talking about this later, is we have the ability to tell whether the data is the same in two updates in SRP now. And, I mean, we always had it in theory, but now we actually have it in an implementation. And it occurred to me that we could actually flag that in the TSR option as well. Like, this is the this is the check sum of the data, basically. And then if we get because the problem is right now with replication, we have the issue of time stamps being slightly off because we don't have a we don't we don't rely on there being accurate clocks on on synchronizing devices. So that's really the issue. That's the reason why this gets talked about. And if we if we had that hash of the registered data as part of the TSR option, then we could use that as part of our process of disambiguating and just then determining whether data is stale. And so, basically, if the hash is the same but the timestamps are slightly different, we can just treat it as equal rather than trying to just determine a sort order. So that's why I wanted to talk about that. Okay. Because we don't we don't we like, this is the the TSR document, would say, is practically ready to go. And so I'm a little reluctant to add something to it at this late date, but that would actually be kind of a nice thing to add to it. So
[00:53:56] Esko Dijk: Yep. Well, here, was thinking about splitting something. So if if you have a specific, yeah, replication scenario, you can go through it. But, yeah, it should not cause specific processing because the registrar knows, like, hey. That that client of mine is replicating things, so I must treat it differently. Then I think that's not a good yeah. Okay. But that needs some tax proposals. And then maybe to consider the the idea you just had with the checksum, That's still open question then. Yeah. Alright. Then let's move on. Just wanted to go over the open issues here. So the other one was, yeah, came up also while editing. Why is there always a probe on updated records? And this figure here is a bit to explain the the context. So the actual problem is on the next slide. But to explain the context, you have this IP node there with an MDNS registrar, and that has two sort of storage compartments that we define. So there's the cache, and there's the local registration database. And, any one of them could have a specific set of records or both. It could be there, or they could be, there with yeah. Yeah. Different, different properties. But I think the idea there was that in the current draft, this basically says that if the the registrant, which is the process a here, basically, up just updates its records in the local registration database that were already in there, and now it just changes a small bit. So it's kind of a re refresher, basically, of its own records that are already there. Then there is probing done. So I'll move to the next slide to explain that. So that's basically text in the second bullet here. So the requested records are added to the local registration database and put in a probing state. And that also applies when the records were already in their local registration database. So it seems a bit weird to me. So we have a process that adds records that are new, that's pro probed, and then it updates the same records, and then probing is done again while the registrar was already authoritative for those records. So I thought that was probably not the intent, so might might need to look at how to reword that if that was not the intent. I see Ted at the mic, so go ahead if you wanna comment.
[00:56:38] Ted Lemmon: Yeah. So as you your I liked your diagram. Thanks for putting that up. I realized that so MDNS responder is does that. Right? That's that's probably maybe where that idea came from. Maybe not. I don't know. But it's interesting, like, to so we're basically doing the probe in order to update our local cache, but you could actually think about this as two different servers. One of them is the caching MDNS resolver. Sure.
[00:57:08] Stuart Cheshire: Okay. I I just wanna jump in here
[00:57:10] Donald Eastlake: Yeah.
[00:57:11] Stuart Cheshire: To make sure we're not akin to using the terminology because there is probing and there is announcing. And probing is, as the name suggests, I propose to use this name. I wanna check if someone else is using it. If you find that the name is available, then you announce that now you're using it and you give the data. And I believe, unless my memory is failing me, Ted was talking about the current behavior of the MNS responder code. When you update a record and there is an API to update a text record, it does not reprobe to see if the name is still available because you've already done that. It just announces the new data. So are we talking about probing or announcing here? I I worry we may be confusing the terminology.
[00:58:03] Ted Lemmon: So the problem with what you just said is that the API doesn't actually provide a way to update the record that works for us. You would think it would, but it doesn't. So what winds up happening is what what we were doing originally in the implementation this is the SRP implementation, not MDAN's responder, was we were registering the record. And then when it was updated, we would remove it and reregister it, which would cause a probe. We modified that behavior in a really hacky way, which is that now when we get an update, we update the record. Sorry. We we reregister the record. We don't do an update. We reregister the record, and then that causes the old record to be removed as stale. Right? So in other words, we have two registrations active at the same time, and the and the older registration is removed as a consequence of adding the the new registration. And that prevents the probe from going out. So the reason why we want to say this in the document is to make sure that it gets implemented in a way that preserves this behavior. And that clarification so I was gonna point out also that maybe we don't even need to send the announcement because, we the announcement is only useful if somebody is interested in that data. The reason we're sending the announcement is because if somebody were to do a query on the local MDNS cache, our locally registered record would not be in the cache because it hasn't been announced. Like, the stale old version would still be in the cache. So we need to do the announcement to to kick it out of the cache and put the correct stuff in the cache, which actually applies for other caches as well. So I think we really do need to announce it. So I think that answers that question.
[00:59:50] Esko Dijk: Okay. But still the the question why we say probing then maybe maybe you've already answered it. But
[00:59:57] Ted Lemmon: So I thought that we updated it to not to to to say that probing was not required for TSR updates. If I'm if I'm incorrect about that, we should definitely Yeah. Update it to say that because we shouldn't be doing probing if the only thing that changed was the TSR record. The only time we would wanna do probing or, actually, we shouldn't do probing on a name for which we've already probed and have a TSR record because the fact that we probed for that name means that we own that name, I think. Stuart, is that right? Like, if if there's a a new record that we don't have to probe for the new record because we already own the name.
[01:00:39] Esko Dijk: Yeah. That's the same I read in MDNS, basically. Yes.
[01:00:43] Stuart Cheshire: Okay. I wanna be very I'm gonna try to be precise with the terminology because records have a name and they have our data. So if you want to use a new name with multicast DNS, you have to check that the name is not in use. If you want to update the R data for an existing name, then if you've already verified that the name is unique, you're free to update the data as much as you like without reprobing because you've already claimed that name and you're defending it. So hopefully was that clear?
[01:01:19] Ted Lemmon: Yeah. That was clear. Great. Thanks. Thanks.
[01:01:24] Jenny Huang: Hi. Hi. Jenny here with AT and T. So so I just recently get the internist written this stuff, and then my question is not related to this proposal, but rather the the original any initial diagram you show there. So I saw that you got a no SnapRouter with the advertising proceed showing there. But based on my reading on the recent SnapRotter proposal, you said the SnapRotter is not going to have advertising proxy requirements. So there is no advertising proxy there.
[01:02:05] Esko Dijk: Well, it's it still has it, so it's base basically included in the current version of the Slack router documents. It's not simple. Yeah.
[01:02:15] Jenny Huang: It is there? Because because Yes. On my reading, it says, oh, this is because it's out of scope. There's no there's no advice advice policy. Yeah. Because that's what I trick in actually, saying, I mean, like, prepare to group mailing list.
[01:02:36] Esko Dijk: I think, yeah, there was some discussion about, well, should should we actually keep that in because the advertising document proxy document is very old and expired and can take very long to complete maybe. So that was the question, I think. But still and, yeah, in the current latest document, it's still in there. But
[01:02:58] Jenny Huang: Okay. So it's data?
[01:03:01] Esko Dijk: Okay. Yeah. Thank you. It's maybe more like a snack working group discussion. Yeah.
[01:03:04] Jenny Huang: No. That's
[01:03:05] Esko Dijk: all. But thanks for flagging that. Yeah. So I'll just assume it's still in here. Okay. So this was about that open issue, so we need to look at more carefully at the wording there. Let's see. Next steps. So, the plan is, of course, to resolve open issues, address TBD, and to do items in the text, which are also there besides the issues. So we have a few things to do. And another one I wanted to add was, yeah, looking at the review that that's happened with SnackRouter documents recently. SnackSimple. Yeah. There was a lot of discussion coming up about the shoot level requirements. So maybe it's good to for the working group to look at that now already instead of pushing that to the future. So to avoid any questions about that, like, why is it not a must? Why is it not a May? And yeah. What are the consequences of not meeting that requirement? So we should maybe do a pass through the text. So there are three items that are that are in that category. There was a quick count I did. So so if we want to keep them as shoots, then we should be complete and then mention also what are, for example, allowed exception cases or what are the consequences of not doing that requirements, or we could even convert it to a must in the cases where we think that's better. So that's for the next step, and I think this might be the last slide. So there's no more things to present. I don't see any really big issues for the draft at this moment. Thank you.
[01:04:59] Ted Lemmon: Thank
[01:05:01] Chris Box: you. So let's move on to advertising proxy.
[01:05:18] Carsten Sperling: Okay.
[01:05:22] Ted Lemmon: Okay. So this document has been languishing for a long time because we wanted to get TSR ready. And at this point, TSR is almost ready, so time to go. Thank you. So, basically, I just wanted to go over the remaining issues on the document. We did a an update of the document about two years ago that, changed the way the document works to make it more rather than being like, oh, you got an SRP update, and now we're gonna do some MDNS to make it be like, oh, you have a DNS zone. Here's how you replicate it in MDNS. So the current document basically is structured that way. And the idea there is just that it shouldn't really be dependent on SRP. We want the advertising proxy functionality to be possible regardless of what the back back end data store is. So the remaining issues there and and these are just the issues from the issue tracker mostly, although the last one is from an email I sent to the list. The question is, should we must there there's a question about whether we should or should not advertise link local addresses. I'll talk about all of these in later slides. There's an issue of overemphasis of MDNS conflicts. Like, there's a lot of text about MDNS conflicts, which isn't very clear. The there's discussion about SRP replication behavior that which is really about multi proxy behavior that I think needs to be clarified, and there's an issue on that. And then oh, right. Yeah. Yeah. Then the issue of of whether you you might have a client that's an SRP client initially does a registration with SRP and then later switches to using native MDNS because it doesn't wanna be sleepy or whatever. And how how does that handle? And I think we need to specify that. There's the question of whether we publish key records in the MDNS or not. And then there's the question of what TTLs to publish. And then just sort of, you know, my comment to the mailing list is about vague and normative vague normative device or lacking normative device for TSR and name conflicts. The the document is just sort of like, here's what could happen with name conflicts. Good luck. So I'll go into the detail now. So the issue is scoped addresses. And and the the issue on the tracker is basically about link local, but it's really a scoped dash address issue. And I sat down and thought about that a little bit last night. And sorry. This is really low. Oh, shoot. Multitasking with one hand. Yeah. So oh, here we go. Scoped addresses. Yeah. So what I realized is that there's actually, like, a couple of cases for scoped addresses, and and there's also a couple of cases for implementations. And I think that we can specify this. In the comment I have in the in the in on GitHub, I wrote some text that I think actually specifies this pretty clearly. Could use some wordsmithing, but basically, I think it's pretty clear. And basically, the idea is if you know that a that an address is routable on a particular link, then you should advertise it on that link. But you might not know. You might not be able to know. Right? So that's a thing to keep to bear in mind. So so this doesn't apply if you are not able to know that it's routable. If you know that the address is on link for a particular link, then you advertise it on that link. But you might not know what link it's on link on, in which case you don't do that. And then so if you don't know, then the only reason you if like, if you don't if you have a link local address and you don't know what link it's valid on and you have other addresses, then you don't advertise the link local address because there are other addresses, and we know that those addresses should work because they're routable, at least in principle. So better to use them. And then for all other addresses, if we don't know whether the address is valid on the link or not, if it's reachable on the link or not, then it's safe to assume that the stack does because the stack, we hope, implements the not yet published source address selection document or at least implements the old source address selection document, source and destination address selection. So therefore, we can just hand that address to the stack and expect it to say, oh, I can't do anything with that if it's not a good address. And so we don't have to we don't have to be responsible for that. So so, basically, the idea is if you have a super smart implementation that knows everything about routing, then it can be very careful and specific about what it does. But if you don't know that stuff, you don't have to do you you we have a clear set of requirements that we can specify for for the sort of, you know, dumb server that doesn't know about the routing table use case. So and, also, in addition to the routing table for for link local addresses, in order to know that a link local address is on a particular link, you have to have some kind of communication because that information obviously is not in the DNS zone. The DNS zone just lists the address. So and you can't look at the address and say, oh, this address is on link because of the prefix because it's link local. They're valid on every link. So that's why this this calculus here. So if we have some way to record that the address is link local and what link it's local to, then we publish it. Otherwise, we only publish it if it's the only address we have. So, MDS conflicts. So this is the the same discussion we were having with Karsten earlier. So the thing about MDS conflicts is bearing in mind that the advertising proxy is intended to replicate a DNS zone. If you can have the DNS zone have a name that is not the same name that's being used for regular MDNS, then there's no possibility of conflict between DNS and MDNS. And SRP already deals with conflicts within the DNS zone. So so therefore, we can assume that there aren't any conflicts in the DNS zone. And if we're able to advertise the the correct name if we're able to advertise the name as a subdomain of dot local rather than as dot local, then we don't have to worry about conflicts. Of course, that's not always gonna be the case. Well, I I should clarify. Right now, I am aware of a number of application implementations that I at least consider important that handle this incorrectly. The correct behavior should be that if you see a PTR record advertised on dot local, you use the the the host name that you find sorry. The you see a PTR record pointing to a service. And so there's a service instance name on the right hand side. You look up that service instance name. Right? The problem is some implementations don't look up that service instance name. They look up the first the the the the service instance name dot local. So if it's service instance name dot foo dot local, that fails. That's less of an issue on Apple platforms because there's a standard API in Apple platforms for doing that particular piece, but it can be an issue. The the next issue is once you do the SRV lookup to get the host name, it's not at all uncommon for the application to just fall over if the hostname is not something dot local. I don't know why that is, but it seems to be the case. We see that, for example, with Matter. And I think in in the case of Matter, it's just that it's expecting the hostname to be exactly a certain length that allocates exactly that buffer size. And if it's any longer than that, then it falls over. So there are some issues that need to be resolved in order to use subdomains of dot local. But I think the question is, do we want to preserve old bad behavior, or do we want to fix it? And personally, I feel like we should fix it. And if that's the case, then what we should do is try to come up with a solution to this problem that doesn't make our lives worse worse for in perpetuity. That is to say, we still need to make it work. Right? But let's make it work in a way that we can eventually turn off. And so so I I would like to have a little bit more of a conversation about this, and I don't see anybody jumping up to talk about this at the mic. So, you know, this is probably something we can have a conversation about on the mailing list. But I'd like to do some more research on this and figure this out. The problem with that wish is that we would also like to publish the advertising document advertising proxy document because we have other documents that are depending on it. I think I have a an idea for what to say here. So I'm gonna propose that idea and bring it up for discussion on the list. And I would like people I'm asking people to please participate in that discussion. Let's try to figure this out and get it resolved quickly. There's no reason, like, that it needs to take a year to figure this out. So that's that's my theory there. Oh, and another slide about that. Yeah. So so that's basically this slide is just talking about what I just talked about. And and so the approach that I was that I'm suggesting we should do is a hybrid approach where, you know, we if we see so normally, we won't see a conflict. Right? Like, you know, with matter devices, we generally don't see a conflict because the names are guaranteed unique when they're registered. With other devices, like printers, they usually use a random hexadecimal hash at the end of the name to avoid conflicts. So the likelihood of conflicts is relatively low. But if we get a conflict, then we can have a fallback. Right? So the fallback would be okay. We got a conflict. And and what it means to get a conflict is also complicated because, like, if we want it to be the case that we register the name in a subdomain of dot local, like so we're so we're the way that's gonna work, just to for folks that understand sort of the way that MDNS queries work, the PTR record would be in local because PTR records don't have to be unique. So you've got 15 services. All of those services are advertised under a service name with a PTR record. The PTR record points to the service instance name, which can be anywhere. Like, it could be in foo.com. It doesn't even have to be a subdomain of dot local at all, even though the PTR record is advertised in the local domain. So so then the question is, what do we put on the right hand side of the PTR record? What I'm suggesting is we put, we use a subdomain of dot local for m for the advertising proxy. And so the host name, for example, would be ted'slaptop dot the name of the of the dataset dot local, not ted'slaptop dot local. So in that case, we're never gonna get a conflict. But we may have some devices that will fail if the name if that's the name. So we may have to have a heuristic where for some period of time, we actually also advertise that name under dot local just to to deal with broken clients. So in other words, we have ted'slaptop.dataset ID dot local, plus we have ted'slaptop. Local. We advertise both of those records. And so and then it's possible we're we're never gonna get it hopefully, never gonna get in a conflict on Ted's laptop.dataset ID dot local, but we might get a conflict on Ted's laptop dot local. If we get a conflict on Ted's laptop dot local, then we need to have a strategy for dealing with that. And that kind of ties into some of the stuff that Carsten was talking about in his presentation. And, actually, being able to report back to the SRP clients that this happened, I think, is useful. It's a little challenging because the the advertising proxy draft disconnects SRP and m d n advertising proxy. So so SRP is updating a DNS zone, and advertising proxy is replicating the DNS zone in m d n s. And those two things don't have to be in sync in the advertising proxy document. So that means that we may not actually know there's a conflict when the SRP update happens. But if we do know that there's an update when the SRP if we do know that there's conflict at that time, we could report it back to the client. So that's useful. But the other thing we can do is we can do a ad hoc renaming so that we get some kind of domain name on .local that works even if the even if the the name the the client picked didn't. Pasco?
[01:18:31] Esko Dijk: Yeah. That's good. I just a question in between. So you talked about test lap laptop.local. So one idea could be that you kind of only switch to the longer name in case of a conflict Right. Popping up. So that's that's one idea. And there was another one that might be too simplistic. It's just, yeah, that advertising proxy Basically, stops advertising and reports the conflict back to the the process that requested it. And in which case, if it's an SRP registrar, then at the moment, I don't think it can do anything about it because it's Right. It doesn't have a way to tell the original client that information. Right? So Yeah. But It it say push the problem out away Yeah. From advertising proxy to the to the process that that's yeah.
[01:19:22] Ted Lemmon: Yeah. The the issue the issue is, like, that means that you have to have a heuristic on the client. The client know the client gets a report that there's some issue, and now the client has to do something. And that client is a light bulb. What is it gonna do? Yeah. There's nothing it's just not actionable. Right? So so I I think that it doesn't like, you know, there are cases where maybe there's something that's claiming a name that it wants to have, and we'd like to tell it that it didn't get the name. And so we should definitely have a path that makes that possible if we can. But I think that is a nice to have, not a requirement. I think the important thing is that it has to work. Like, you have to be able to discover the thing. So maybe that means that its host name isn't the host name that it chose, but at least the service name is correct or something. Right. That's the that's the thing we have to figure out. So Yep. Great. Yeah. So, basically, Maya and and by the way, the reason for having for always publishing the subdomain of dot local is that that's what I would like us to land on eventually. Like Okay. Think about this as, the old API and the new API. The old API is directly under dot local because some things break if they're not, we have to support them. But going forward, what we'd like is to have a protocol that never gets conflicts. Right? That's our goal, I would hope. And if our goal is to have that, then we have to support that from the from the get go. If we don't support that immediately, then clients that behave correctly in that situation can't behave correctly in that situation because we're not advertising the thing that they would look for. So I wanna make sure that those clients, the ones that are doing things the new way, work from day one. Okay. Alright. Thanks. Yeah. And by the way, I want that. The working group is welcome to to to debate with me about whether we should actually do that. Oh, we have Carsten.
[01:21:21] Carsten Sperling: Yeah. Hello. Carsten here. Yeah. So I think I think there's just fundamentally somewhat somewhat different use cases. And I think we've been sort of trying to cater to to different use cases, but maybe they need different solutions in some like, for example, you you mentioned Meta now. Meta sort of uses these unique by design service instance IDs, but it also expects that it can directly look up a service instance ID because they're constructed from these node IDs. So the they expect them to be able to directly a client directly look up the service instance ID and look it up without effect without going through the pointer record. So in that sense, the the solution of saying, hey. Let's let's just when you just put them into a into a subdomain, you're sort of saying, like, hey. Yeah. Great. We can't have conflicts because we're just gonna put all these records alongside each other into different into different subdomains. And then you're saying, and now it's up to the client to to find which one of these different records is the one that they actually wanted. So so I I don't know that that that doesn't directly work for matter as it's as it's as matter uses MDNS currently. Like, I think the the the
[01:22:34] Ted Lemmon: Yeah. That that's orthogonal, though. Right? So what you're talking about is that we have to advertise the thing that Matter is expecting to find until Matter gets fixed, which I think it should be. I think that's broken behavior.
[01:22:46] Carsten Sperling: I think that's a separate discussion maybe where that matter should be fixed. But I I think you're you're fundamentally taking a service. You're you're just sort of saying, like, hey, service names are just no longer unique because we're just gonna throw them into these into these subdomains. So you're fundamentally changing the the model.
[01:23:01] Ted Lemmon: You're not No. Yeah. Matter changed the model. This is not us changing the model. Stuart?
[01:23:07] Stuart Cheshire: Yeah. Let let me give some background here. So we have to be careful to remember there's two levels of names we're talking about. We're talking about service instance names, and we're talking about host names. Sometimes we care about the host name. If you're going to log on to your device on the command line using SSH, you want a short, convenient, memorable host name so you can log into my computer .local or whatever it's called. There are many cases where no human being ever sees the host name and it doesn't matter. The user interacts via the service level, service instance name. So when I wanna print something from my phone with AirPrint, I see the rich text name of the service with capital letters and spaces and everything. What host name it has, I don't see and I don't care. And that can be some random hexadecimal string or whatever. And it only exists as glue to link the SRP records to one or more address records maybe on multiple interfaces. Yep. Now in matter, they I wouldn't say they broke the model. That's why I wanna explain. Every device in matter has an ID which is unique. And when you wanna turn a light on, your device has a database that maps those user visible names to the actual identifier, which is a cryptographic key and part of security is based on unique private keys and public keys. That's the service name. So when your phone says turn the bedroom light on and it says, oh, this matter device ID is this 32 character hex string, it's looking at that as the service name, not the host name. Right. What host name it maps to doesn't matter. If there's a conflict there and it renames, matter shouldn't care. There may be bugs, but at least in principle in the design, the the service names are prescribed by matter, which they can do because they have their own service type. It's underscore matter DotUDP.
[01:25:31] Ted Lemmon: Right.
[01:25:31] Stuart Cheshire: And within that namespace, they are free to define the rules for their namespace, and they have. Yep. When it comes to host names, they don't own the namespace. But fortunately, it shouldn't matter because if there are conflicts and they get renamed, the SRV record will point to the right host name which you then look up. So I don't see any serious fundamental problem here. We may need to write some text explaining it. We may need to clarify some confusion, but but I don't think we have a catastrophic problem to be fixed.
[01:26:03] Ted Lemmon: Right. No. It's the issue is that right now, Matter doesn't do local browsing or legacy browsing domain discovery. And so it just says, oh, the legacy browsing domain is dot local. I'll just look there. It'll all be great. And that is a correct assumption. Some I mean, I
[01:26:17] Stuart Cheshire: think to be strict, Matt is not doing browsing at all. Right. It it knows the device Mhmm. ID that it wants to talk to, and it looks at that SRB record.
[01:26:30] Ted Lemmon: In a specific domain?
[01:26:31] Stuart Cheshire: It it is it is that device ID dot matter DotUDPDot local.
[01:26:37] Ted Lemmon: At TCP.
[01:26:38] Stuart Cheshire: Yes. Is it?
[01:26:40] Ted Lemmon: It is. Don't get me started.
[01:26:41] Carsten Sperling: Well, there there's there's
[01:26:42] Donald Eastlake: different
[01:26:42] Carsten Sperling: there's different use cases. Right? There there's there's commissionable device discovery, which works differently, which uses more what you would call proper browsing. And and for operational discovery, uses these node ID based
[01:26:55] Stuart Cheshire: Commission
[01:26:55] Carsten Sperling: you just turn the light on.
[01:26:57] Stuart Cheshire: Commissionable discovery is the more traditional kind of discovery that we'd think of in this group Mhmm. Which is there may or may not be new products I've unboxed waiting to be commissioned. So let's ask the network. Yep. Give me a list of things awaiting commissioning. Oh, there's three of them. Okay. Let me read the manual and find out how to do that. Mhmm. So that is definitely a browse, discover, connect flow. Once you have set things up, it is more and this is not unique to Matter. On my Mac, if I go into system settings and go to the printer section, when I click plus to add a new printer, it will browse the network saying, are there any new printers I don't know about? It'll show me a list and I can add one and configure a print queue for it.
[01:27:45] Ted Lemmon: Mhmm.
[01:27:46] Stuart Cheshire: Having done that, every time I hit command p to print, it doesn't browse the network saying, show me all the printers I don't care about. It's remembered the name of the printer, and that's the printer it looks up.
[01:27:59] Ted Lemmon: So it remembers FooDotUnderscoreIPPSDotUnderscoreTCP dot local specifically?
[01:28:06] Stuart Cheshire: I I know you're asking about the dot local. I I believe, I'm pretty sure, it remembers the string that it got back from doing the browse when you created the print queue. And it is worth pointing out that phones and computers, for historical reasons, are different here. On your Mac, you typically make a print queue as a one time operation, and then you reuse that many many times to print on that printer. Yep. With AirPrint on the phone, you don't make print queues. Every time you wanna print a photograph, you've gotta go through that browsing experience, and you may pick the same printer every single time, but it still makes you see the list and pick one every single time, and that was just a design decision that the relative respective HI teams made. But, yes, on the Mac, the browser make a print queue is a one time operation, and then subsequent uses of that do not browse again. They just look at the names that they remembered.
[01:29:03] Ted Lemmon: Yeah. I guess what I'm getting at is that there is a semantic issue here that that we haven't really we just kind of backed into without really thinking about it, which is that and and we we run into this with matter because, of course, matter works on thread. And, you need to be able to discover Matter devices through Thread. And those Matter devices, when you're discovering them on Thread, are not advertised in the .local domain. Right? They're advertised in the default .service.arpa domain. And so we actually have a specific hack in the matter code right now that says, look this thing up using .local and default.service.arpa, which I consider kind of ugly. And I think that it might be valid to say, give me a list of default legacy browsing domains and try to look this thing up in each of those legacy browsing domains. I think that would be not great. I'm not fond of that semantic, but it's sort of okay. What I would ideally like is that we first look for the PTR record and then use the name we see in the PTR record because that gives us a clear indication of where the thing is. It's not really a browse per se because we're looking for a specific thing, but it allows us to to get the correct current location of the thing rather than just assuming that it never changes, which is what the code currently does. So I I think I mean, this is actually I'm glad we're having this discussion because I think it's an important discussion to have. Like, do we how much do we care about the flexibility that Browse gives us? Yep. Absolutely. Yeah. Because, like, you know, think about, you know, printers here.
[01:30:40] Stuart Cheshire: I I see the timer. I think that means we're out of time. We're probably not gonna answer all of this right now. It is a good discussion to have. The one of the considerations is
[01:30:52] François Michel: and if we do
[01:30:53] Stuart Cheshire: the unicast local discovery, it maybe makes this more of a moot point. But with multicast discovery, if you have a 100 light switches and you wanna turn one of them on, sending out a multicast to get a 100 light switches to all answer, and then you ignore 99 of those responses and only use the one whose name you already knew before you did the query
[01:31:16] Ted Lemmon: Right.
[01:31:17] Stuart Cheshire: That is very wasteful in terms of multicast traffic. If you know the name of the thing you're talking to, just talk to that thing. Don't preflight that with a Yep. Hello, everybody. Now I'm gonna ignore you and carry on talking to the thing I knew in the first place. So that's the reason printing in particular has that flow, and we can debate if that still is the right thing to do.
[01:31:35] Ted Lemmon: Yeah. Yeah. I mean and and we could also try it first, and then if it fails, go back. So there's a lot of things we could do about this. The point is I'd like to solve the problem.
[01:31:43] Florian Obser: We have five minutes more slack in the in the agenda. So if you want to continue this discussion or run
[01:31:49] Ted Lemmon: some of slides Let me see if there's something we really need to talk about. I think we've already kinda talked about this in the TSR document. But, basically and we also talked about it in the in the the charter discussion that that we might want to do some tweaks to MDNS to optimize the behavior that it has when there's multiple proxies advertising the same stuff. And then we need to deal with the case where we might have a device that uses SRP and later advertises native MDNS. We don't want there to be an a spurious conflict there. So if we're using TSR, SRP is gonna gonna result in TSR getting used, then the native device has to use TSR. And we kind of don't talk like, we don't talk about that use case in the document currently. So I just wanna make sure the document, a, doesn't forbid that, and b, sort of talks about it. Kirsten?
[01:32:46] Carsten Sperling: Yeah. Just quickly wanted to say, this is actually a a use case in in ULD where you Yeah. If if you try to use it find the server, there isn't one so you do emptiness yourself, and then later you switch back to you switch to using the server, or you might switch back if the server goes away. So that's that's kind of I was thinking we might want to mandate TSR for ULD clients when they're falling back to m m d n s.
[01:33:09] Ted Lemmon: Yeah. I agree. I that's this is actually where this why this sort of came up. Okay. Key record publication. We don't really need to resolve this here, but just FYI, there's a question of whether we actually want to publish key records in MDNS. We need them for SRP in order to disambiguate, like, to to avoid conflicts that are real conflicts, but they're not actually necessarily useful in MDNS except that we do use them to hold the name that's registered. So if we don't use the key record, we have to use something else. And there are potentially privacy issues with the key record, so that's the reason not to do it not to publish the key record. And then there's the question of TTLs, and it's just like, you know, what TTL do we choose when we advertise MDNS? Because we're we're replicating what's in a DNS zone. Obviously, we don't wanna a TTL longer than what's in the DNS zone, but what if the TTL in the DNS zone is one second? We really don't wanna advertise a one second TTL in MDNS. So so we just need to specify that. And right now, it's I I don't know. I think we do talk about it, but I think we need to get more clear. I think that was an issue that Esco raised. And then the vague normative device, you know, I think we need to actually explicitly say how name conflicts are dealt with, and I think we need to inter introduce TSR a bit more clearly than we currently do. So right now, the the discussion of name conflicts basically says, here's the problem. And to solve it, you could do this, or you could do this, or you could do this. And what I'm saying is I think we really just need to say, here's the problem. Here's how you solve it. So that's all I had, and we would like to actually work on this document now that TSR is pretty much done. And so, yeah, that's where we are.
[01:34:59] Chris Box: Great. Alright. Thank you, Tid. So now we'll move on to s r. Sorry. 60. There we go. Donald. Oh. Do you want this so we have the slides on screen, but would you prefer to share from yours?
[01:35:28] Donald Eastlake: No. I I'd be happy to
[01:35:31] Chris Box: Okay.
[01:35:31] Donald Eastlake: Run the slides there. So I'm Donald Eastlake. I was the author of the original SIG(0) RFC twenty nine thirty one. And I'm gonna talk about that and its deficiencies, and this draft proposes an improved sig zero r r. So I typographically in this presentation, I use SIG(0) to refer to both of them. And sometimes to to distinguish them, I may have to pronounce the parentheses sometimes. But so six zero, like, a lot of people know, I'll try to go through these slides fairly quickly. It's a meta resource record, which is used for providing security on requests and transactions to the DNS based on public private key signatures. Because it's a meta RR, you can include it in messages, but it's not stored in zones. And the corresponding public key used to verify these signatures uses a key RR, which can be stored in zones, or it can also be included in messages as is done with SRP, as I understand it. So it's just what it looks like. So you can send a request. You include the request signature in with the request. Of course, it doesn't actually cover the signature itself, but it does cover some metadata for the signature. And for a transaction, in the response, you include a signature which covers not just the response, but also the request. So you can tell if you verify the signature that the request was not tampered with and that the response is a response to that request, and the response wasn't tampered with on the way back to the requester. So this is a little bit of a noisy slide, but here's sort of what's going on. The sync zero, it is used with DNS update messages. Is used with t keys, negotiate secret keys, other cases. And the service registration protocol uses SIG(0), and update. And there's also a new draft, well, lovely recent draft on managing DNS delegation, which is in DNS off on the bottom right here, which also uses sig zero. So just a little more about usage here. So the general DNS update, you basically sign it with something which indicates your authority to make that change. This is like you're you're changing the some entries or adding or deleting in an in a regular DNS zone somewhere. For the service registration protocol, FCFS, you basically claim a name by including the key in assigned request. And for DNS, the t key one, you would you'd usually use that to give some sort of signature indicating authority for the the host that's using t key to negotiate a a secret key. So these are different uses. Brief diversion. There is also t sig, which has you can tell because it has a RFC in the eight thousands. It's been updated much more recently than these other things which, like, sig open brand zero, close brand, which currently have RFCs in the two thousands. It's the same sort of meta RR, but it uses a shared secret key and key hash with them. It's more efficient and compact, but the problem is you have to have configured a bootstrap to this shared secret key. It's not used by service recovery. And, yes, it also has because it uses a shared secret key, the the server can impersonate the client, but that's usually not too much of a problem. I just thought I would mention that that exists. So what's the wrong what's problem with SIG(0)? It has no original ID field in it. So if you forward it, it's that's not obviously supported. And that's not a problem for a service recovery protocol because you don't use regular recursive DNS forwarders as I understand it. But it is a problem in other cases. These are
[01:39:47] Éric Vyncke: the
[01:39:47] Donald Eastlake: general DNS zone update messages. Forwarding should be avoided where you can can do that because every forwarding level is a place where you can have problems or with reliability or or otherwise. But sometimes if a client just wants to update something in a regular DNS zone with a DNS update message and doesn't know where everything is, it it just needs to use the regular forwarding mechanism. Bind does manage to support forwarding by using a sort of a clue using DNS and duplicating the ID space for that d that TCP connection. So current problem is that you cannot have more than one sig open paren zero close paren in a particular message. So this forwarding, here's a a a case where sort of shows something being forwarded. And I don't know what you'd say much about this. This is, say, not not applicable to SRP. This shows a shows a general DNS recursive server. And here's one where added also having two signatures. In this case, the hypothesis was that the requester wanted integrity to the forwarder and back. It was also a separate signature giving authority to the message which the server needed. So these are just examples. So there are actually more problems in SIG(0). And it doesn't have any extensibility. It hasn't it doesn't have any extended error field, and it has no way to indicate anything about the state of the keys. It's a separate draft draft- d internally a DNS app on key state, which says you might wanna indicate the state of the key. Here's some example states at the bottom. So that would be a useful thing to add in my opinion. So how do you solve these problems? Well, you there's three basic ways. You use a new new resource record. You could overload fields in the existing, say, open paren, zero close paren, like putting an error code and an original ID into the TTL field because TTL isn't used, or you could use ENS options. And what's the what are the characteristics of these solutions? Well, new RR is a is a complete clean solution, but the problem is, of course, there's a you have to use the new RR to get those benefits. Overloading the fields, it might be backward compatibility problems, not as bad. But it also will limit the extensibility because there's only so many fields that you can overload. And if you extend it with EDNS options, that's not too bad, but there's a problem that you have to link between the options and the particular SIG(0) if you ever allowed multiple sig zeros of that type, and it gets difficult to reliably link the particular EDS option, particular SIG(0) that they apply to. So this this draft, what thing does it have in it that are changes from the original sig zero? It specifies sort of fleshes out this new sig zero r r. And in the draft, that would be recommended and use of the SIG(0) version would not be recommended. It had sections on how to do forwarding and advocates that you have made it where you can. It makes a bunch of other minor changes like removing the statement in the original 2931 that option support for sig open paren zero close paren is optional. So here's the current state of the new sig zero r data. As you can see, it has a a time sign and a fudge amount of time. So it's basically it indicates that the signature is sort of valid for a small window with a fudge amount around that. The sig open paren zero close paren is based on is originally from DNSSEC. So it has a beginning and ending time because it's assumed to be a long lasting signature. But the new six zero recognizes that it's just for a particular request. So what what should be done? I'd be interested in any comments and things, any questions people have, and I'd like to resolve those. And if they can be resolved and there seems to be some sentiment in favor, we could perhaps go for working group adoption. This draft was moved from DNS op to DNS, my personal draft, from DNS up to DNS s d because of its applicability of the c service registration protocol. However, it seems now there's also this delegation management thing in DNS up. I'm not sure that choice is necessarily still the right thing.
[01:44:43] Ondřej Surý: Hi. This is with my implementer's hat. This doesn't make me really happy because we will have to support both. But I would like to contribute to the security section because it's important to remember that six zero, both of them, is ACL. And so you need to resolve the six zero validity and that's cryptography before you apply the ACLs. So if you if the six zero is the only ACL, it means there's a vec attack vector on any DNS software that accepts the packets with six zero, and there needs to be some plumbing around that to just not overwhelm any DNS server that any application that accepts the six zero as ACL. So I don't care where this ends. I think this is fine, but I would like to, you know, make sure that we don't end up with CV again.
[01:45:42] Donald Eastlake: Okay. I welcome additions for the security section or, you know, suggested additions for any other section.
[01:46:02] Chris Box: Thank you. If you have any other thoughts, please take them to the list, and we will move on to Francois.
[01:46:25] François Michel: Hi, everyone.
[01:46:26] Florian Obser: And can I get the Yeah? Yeah. Working on the speech.
[01:46:29] Chris Box: Thanks. There you go.
[01:46:31] François Michel: Alright. So earlier in this meeting, we discussed how we could use Unicast service discovery on Wi Fi to be more efficient in terms of the spectrum. And as Stuart said during that that part, we've already been doing that on overthread for some time exactly for those reasons. And so let's here take even one step further in the in the context of Thread to show to to explore a case where even SRP did not scale super well in some specific scenarios and what we can do about it. So I'm gonna present some ideas and some reasons that that we've been computing by running experiments. So in the scenario of thread, we can have a lot of different lot of accessories on the same mesh, and we can have sometimes some synchronization events when all the accessories will send the registration all at the same time. And in the context of matter, the registration could be several hundreds of bytes, and, that can basically cause congestion, on the mesh. So these events could be, let's say, the SRP registry that, that gets, a new version of the registry, or it could just reboot, and all the devices would have to reregister the services. So what we noticed is that, generally, the accessories registered the exact same service. So the registrar already knew that service. It was just disabled, but it was in in its cache, basically. And so we asked that question, could we just avoid sending the whole registration of 600 bytes if the server already knows most of it or all of it, actually. And so that's what we've been trying to do with SRP hints. Alright. So let's take a simple example. First first registration of an accessory. A threat device, it will send an SRP registration of 600 bytes. Everything goes well. It gets installed on the register, and it stores the the the SRP server will store the the whole query in its persistent storage. Then something happens. Maybe the the server reboots or the thread device reboots. And then instead of sending again the whole query, it will send what we call a hint, which is simply a small four bytes hash of the whole query, a transaction ID, and a key ID. And then the server can just look in its cache for for the hash. If it's present, it will republish the registration. And now we've been sending eight bytes instead of, 600. And so we've been running experiments about that to see if it actually helps our convergence events. So we've we've we have a test bed with 51 accessory, 51 devices. One of these is the boiler router, which is the SRP server, and then the 50 other devices are Matter devices of a thread that will register their 600 byte service. So in that experiment, we computed the we measured the SRP convergence time. It's the time between the first and the last successful registration among among the 50 accessories. And here are the results. First with hints disabled. I'm just showing with hints disabled where you could see that the convergence time could be even even two minutes just for 50 accessories to all register their service. And when we enable the hints, we got a way better result. On average, we reduced the average convergence time of more than thirty seconds, and the the variance is way lower as well. So the extreme cases are performing way better. So that's encouraging results. So we'd like to continue our work on that. But here's where I would like to have a discussion and have feedback from you too. Right now, the hints are running on port 53. The only way we are able to distinguish between the SRP hint and the DNS packet is the packet size. An SRP hint is eight bytes. A DNS packet has a 12 byte header. So if the packet is smaller, we assume it's an SRP hint. So, of course, maybe in the future, we'll use larger hashes and and stuff. And so it could be bigger than 12 bytes, then problems could occur. So, basically, what should we do? We could also prevent ourselves from having larger pack packets larger than eight bytes. I don't know if it's doable if if if it's really future proof. So there are other solutions that we could look at. We could use different ports. We could make hints as part of a DNS packet. It would increase the hint size, so we would have to measure the impact, but it would be DNS compatible. Yeah. So that's it for me. So if you have any feedback or question about that work and that results, just let me know.
[01:52:09] Chris Box: Mhmm.
[01:52:12] Esko Dijk: That's good. Question about the reboot scenario. So in in your implementation, the services are actually kept during the reboot, and then it it still knows the information. Was it kind of stored in, on a hard drive or in Flash? Or
[01:52:30] François Michel: Yeah. Yeah. It's all on a on a we have a persistent storage that survives across reboots, basically.
[01:52:38] Esko Dijk: Okay. So it's basically written Yeah. It's written on the only for a plan to reboot, or is it does it always work?
[01:52:44] François Michel: No. It's it's always written on the disk, basically. Okay. Registration. We cache them in persistent storage.
[01:52:50] Esko Dijk: So I think from many devices, it will just forget all the records in a reboot case. But if you are talking about, like, a version number increase that is used to trigger or request re registrations, for example, then the device could still have everything in RAM.
[01:53:07] François Michel: Yeah. Exactly. So if you don't write anything in the persistent storage, then the reboot case won't won't be solved by that. We actually write it in persistent storage. But as you said, if it's a version update, then it will still work with RAM only.
[01:53:21] Esko Dijk: Okay. And then back to your last slide, I think it was with solutions. So, yeah, having on the same port number, at least intuitively, sounds like a good idea if you could construct a minimal DNS message that only contains, for example, something like a special option and option says, like, okay. This is in SRP hint and includes the hash as well, then your packet does get longer, but you can kind of more easily blend it in, hopefully, with Yeah. The DNS SRP ecosystem. Yeah. That sounds like a possibility. Okay. Thanks.
[01:54:02] Éric Vyncke: Hi. In in in in the oil contributor on this one, honestly, using the same port for different protocols.
[01:54:11] Chris Box: Mhmm.
[01:54:11] Éric Vyncke: Yeah. Yeah. Whatever. I I don't think it will fly very far within the ATF. Getting another port is will be tricky, though, as well. Right? So just be aware of this. Just a questions now. If the the the can you go back on the first slide when you were the one you're talking with? The one we are talking with Cisco. Yeah. This one. This one. Yeah. So the registrar, how long does it keep the record? I mean, it need to be some garbage connection, right, at some point of time. Should it be part of the draft or not? I don't know.
[01:54:45] François Michel: So I think it could pretty much decide when it wants to flush it because if it's not in the cache anymore, we can just reregister. I think the cache needs to be long enough for the hints to be useful. So I guess I would say several days because the services in in the thread mesh at least don't change that much that much. Yeah. But if that has any opinion, don't hesitate to
[01:55:11] Éric Vyncke: I I I think it may need to be set somewhere. Alright. Even if it's left to the operator. Right?
[01:55:17] François Michel: Whatever. Sure.
[01:55:18] Frank Brockners: Yeah. Thanks.
[01:55:18] François Michel: Makes sense.
[01:55:20] Ted Lemmon: Yeah. I mean, you have to be careful. You don't just, like, consume storage without bound. Right. And that's to me, that's the main motivation. Like, it doesn't the time isn't so much the issue as the storage. And also, it is necessary to be strategic about what you store because, for example, some consumers of mDNS or of d nssd vary their text record repeatedly to signal things, which I think is actually should be forbidden. I think that's a really bad idea, but it is something that that is done. There are cases where it makes sense, but rarely. And so in that case, if you just keep caching those changes over time I mean, if it varies between two stable states, it's no problem. But if it's, like some hash changes or something, then you're just gonna have a bazillion packets from that client. So you kinda need to notice that and discard them. And one of the reasons for persisting things is for a longer time rather than just keeping them in RAM is that you may have, like, four or five different scenarios in which a registration happens. And if you can remember all five of those, then whichever hint you get, you use it instead of, like, oh, we just remember the last one. So there are good reasons to keep more data, but I just yeah. And I think, you know, we could also use a new r code or sorry, a new s r oh, sorry. A new DNS code, or we could just do a new port and have it be advertised. Because, like, in in Thread, for example, it's advertised in the network data, so it's really kinda Yeah.
[01:56:52] François Michel: Right. It makes it just slightly more complex, but not not that
[01:56:55] Ted Lemmon: I think I think that's probably the way to go because I think Eric is completely correct.
[01:56:59] Frank Brockners: Yeah. Not we're
[01:57:00] Ted Lemmon: not gonna get that through the ITF.
[01:57:01] François Michel: Yeah. Yeah. Definitely. Totally agree. Alright.
[01:57:09] Stuart Cheshire: Stuart, I'll make my point quickly because I think I'm echoing what Eric and Ted said. And then did you you you acknowledged in your slides that having this eight byte thing that's too small to be a legal DNS packet, I think we all agree that it just feels wrong. Multiplexing on the same ports, if we can have it start with some byte, I'd have to look at the DNS header format. But we may be able to do something that is unambiguously differentiated, that this is not a valid DNS message. And then and then you can have a reliable way of differentiating that. But I think just going off the length and for the reasons that you said, we might want longer hashes later. So I think you correctly identified that's a bit of an ugly hack, and we should do better.
[01:57:58] François Michel: It's good for experiments. That's it. Right? It was for the results.
[01:58:01] Carsten Sperling: So easy. Yeah.
[01:58:05] François Michel: Alright. Thank you, everyone, for the feedback.
[01:58:10] Carsten Sperling: Yeah. I had one quick question. Did you see this sort of being useful outside the context of thread, or is it really primarily an optimization for a Thread due to the extremely low bandwidth? I mean, it seems like on on, like, Wi Fi, even a a 600 byte packet isn't really that different from an eight byte packet, probably.
[01:58:28] François Michel: So the the goal here was especially targeted at Thread. However, at the beginning, we decided to do SRP and Unicast discovery for Thread because Thread is resource constrained, but now we are was trying to starting to think of it for Wi Fi. So maybe one day, if we have 10,000 of devices in the same network, we would use that on Wi Fi. For now, it's just really for thread for the thread case and threads bit rate, which is very, very low. Thanks. Thank you.
[01:59:10] Chris Box: Okay. Thank you for that. So the final item is just a presentation that's related to the dawn booth, which occurs tomorrow. So it's just for information for this for this working group to raise your awareness. It's not one that should be discussed within d nssd, but if if you want to discuss it, then, yeah, there is a dawn list. Okay. Go ahead, Frank.
[01:59:39] Frank Brockners: Yeah. I think I'm basically here to ask for a little bit of help. So we do have a set of customers that pretty much along the lines of what Stuart was saying, is discovering a printer similar to discovering an agent. Some people believe that. And they made us create a bit of running code to go and do that so that you can go and find a pick agent in a warehouse or that you can find a nursing agent that might be flown by a patient's room real quick. So there is use cases for that that smell very much like what you have in DNSSD with mdns. So local constrained environments, air gapped, non public. What we've done is we clearly say, well, we only want to go and figure out how to go and get an entity, the URL to then figure out more about that particular agent. Just the initial, how do you get to the URL with some maybe additional hints? Because not every agent necessarily has an agent card, like with ADA, but but there might be, like, agents that run speak MCP where you don't really have an agent card. So URL to more descriptive information and maybe a hint to the protocol that you want to go and use to go and do that. And everything else is kind of, well, kept out of scope because in certain environments, you don't want to go and do everything or anything else like Authz and Authz and whatever. And other scenarios might want to go and do that. And what we did is relatively quickly say, well, we have a service record and then we jam some information into a TXT record to go and help further. What we're not entirely sure about is is should we use an agent TCP as a kind of a catchall? Should we be more differentiated? Is this kind of two stage split of just kind of finding the URL of where to find the agent and then some additional hints maybe, is that the right split? Should we really do TXT records because that was inspired by customers and saying, Well, we don't really use service bindings throughout? If you look at the DNS-eight work, they're really saying, Well, let's go and standardize on service bindings records and then maybe have some other alternatives. We struggle with long strings. Is there a general way to go and solve that? And, yeah, well, do we need to go and put anything privacy into that document or not? Right? So there's a couple of questions. And if you can help us on the list for those questions, we would greatly appreciate those. So that's to Eric's point, which was asking earlier on. So if we could if you can help us, I very much appreciate that. Thank you. Sorry. I don't want to see the queue.
[02:02:35] Stuart Cheshire: Well, I will say we're happy to help. I think we're also out of time for this session, but we can continue this with some hallway conversations and discussion on the mailing list.
[02:02:48] Chris Box: Yep. Feel free to. So that brings us to the end of the session. So thank you for all your contributions. And, yes, we will follow-up on the DNSSD list. Enjoy the rest of the week.
[02:03:12] Florian Obser: Are you also happy with having lunch today?
[02:03:15] Donald Eastlake: Are you also happy with having
[02:03:16] Florian Obser: lunch today? I think everybody Monday is fine.
[02:03:24] Chris Box: Let me check.