Session Date/Time: 26 Mar 2026 17:00
Sure! Here's a verbatim transcript of the entire recording:
Chris Box: Hello and welcome to our second interim meeting. Hope everyone's okay. So, let's see. So, going through, I'll just, while people are joining, I'll start the meeting. So, this is covered by the Note Well. So, by participating, you should be aware of these things. So, if you haven't read them, please take a note. This meeting is being recorded, of course, and will be available later. Hopefully you're familiar with how to use Meetecho. As this is a relatively small meeting, if you have any difficulty, just let me know. So, I am Chris Box. Florian is also online.
Florian Obser: Hello.
Chris Box: Hi Florian. So, these are for reference, really, but links to our GitHub where the documents are maintained. And as we discussed in the last meeting, the last interim meeting, this is our document status. So, the green ones have left the working group, the white ones we are working on. And last time we discussed TSR. This time, we have on the agenda as well as replication, we have infrastructure, removing old services, and Sig0. Now, in terms of the order we want to cover that, that's what we've proposed. Do you have any thoughts about the order in which we should tackle this? Just let me know.
Ted Lemon: It's okay by me.
Chris Box: Okay. Florian, did you want to mention anything else before we get started?
Florian Obser: Uh, no, I'm good.
Chris Box: Okay. All right. So, let's move on to infrastructure then. So, I haven't got any slides to share, but we can talk about it, or you can share from your screen. It's up to you.
Ted Lemon: I have no slides either. I can give an update. Basically, so, I actually didn't look at the agenda before the meeting, so I spent a whole bunch of time working on the drafts we discussed two weeks ago and didn't actually prepare any slides for the stuff you've got on the agenda for today. So, I'm afraid that you're just going to have to listen to my voice when I talk about stuff, but hopefully that's useful.
Chris Box: That's fine, and that usually is useful, Ted. So, before we come onto this then, is there anything you want to mention about what you have been working on? You know, just to update the working group.
Ted Lemon: Well, so, a couple of things. One is I mentioned two weeks ago that I kind of needed to do an implementation of the current version of the advertising proxy draft. And I did that. And actually learned some useful things in the process. So, I haven't actually done any updates to the advertising proxy draft based on that, but they're in the, they're coming. So, that was a really useful effort. The other thing is, so, I mentioned two weeks ago...
Chris Box: Oh, just on that then. So, do you want to have more deployment experience of that implementation before we have, before we, for example, go through those issues and possibly some other ones?
Ted Lemon: So, I don't know that that's strictly necessary. The problem with getting deployment experience on that is that the soonest that that could land in a product would be not very soon. And it doesn't have, like, at this point we have a very stable implementation that's not the one that I just did. And so, it would be a little scary to replace the stable implementation with the new implementation. So, getting deployment experience with it, I don't actually know how that's going to happen. I definitely, in the long run, I want to switch to the new implementation, because one of the nice things about the new implementation is I was able to chop out about, like, you know, a thousand lines of code. I mean, it made it a lot smaller. And I think it's better in the long run. It's just that, you know, waiting for deployment experience before updating probably is going to result in a, like, two-year delay or something like that, which I don't know, I don't see any particular reason to do that. I think the lessons that we learned already are good and useful. And so, we could release 1.0 version of the advertising proxy. And then if we learn something really important and decide to update it, we can just do this. One other thing that I feel like we've been sort of not doing here, which is actually IETF best practice and I think is a better practice than what we've been doing, is document what we think is correct and and that we like have enough experience with it that we're not just like blowing smoke, right? And then as we learn more, then do updates to the document.
Chris Box: Oh sure, yeah. But it sounds like you've got experience of doing the implementation, i.e., writing the code based on the, on the draft. So, that's useful input certainly. Tells us whether the draft is correctly written or needs to be improved. I'm just wondering about, yeah, should we think about doing interop? How do we get that, your lab implementation some more experience so that we can inform the draft, or is that completely off the table?
Ted Lemon: I don't know that that's, so, basically the motivation for wanting to do that was just that, so, there were some things proposed in the advertising proxy document that seemed like they were useful improvements, but they were speculative. And so, I'd never actually tried them and I didn't even know if they worked. And so, part of the goal of doing the implementation was just to see if those suggestions were stupid or not. And one of the things I discovered is, so, one of the suggestions was, you know, we have this issue with with name conflicts where, like, you might have a name registered using just plain old mDNS by a regular old device on infrastructure, like on your WiFi or whatever. And then you also have an SRP registration with the same name from a different device. Now, SRP guarantees that names are, like, whoever owns a particular name really owns it. We use crypto to make sure that they can prove that they are the same guy, right? So, so we have a kind of name collision rejection mechanism that's reliable and secure. But with mDNS, there is no such thing. And it's one of the perennial problems with mDNS. You know, we, we get name conflicts and we don't have a way to resolve them. We don't have a way to say, oh no, this is the same guy, it just came from a different place or whatever. And so, part of the idea was let's change the advertising proxy implementation so that, or the, the way the advertising proxy works so that we use a subdomain of .local for advertising proxy registrations that are being replicated out of an SRP database that we, where we already have good, you know, collision detection and everything works. So, I did that. What I found out was that clients of mDNS do not handle that well. So, in practice, it's not deployable. It was a great idea and I'm not convinced that it was a wrong idea, but if we wanted to make that happen, it would be a long process. So, unfortunately, I think one of the changes that has to happen to the document is to sort of say, well, this is cool, but it won't work. Or words to that effect. So, that was really my goal in, in doing the implementation. It wasn't that we were going to discover some like amazing new thing. I mean, we have like at this point six years of experience with advertising proxies. So, I don't think that we would, and most of the stuff that's, that we're, the changes that were done to the, to the advertising proxy document were basically simplifications that made it cleaner and more readable. And then, you know, the changes that that we would make based on an interop, I don't even know what those would be. I think, I think we're in actually in pretty good shape in terms of what we know at this point. And so, it's just a matter of getting the document to be synchronized reasonably closely with what we know.
Chris Box: Okay. Anyone else on the call have any views on how to approach advertising proxy? Esko.
Esko Dijk: Yes. So, what I had in my mind was at least we should also yeah maybe first do the TSR draft basically in terms of the document and then try to make it kind of decoupled from advertising proxy. And there was one suggestion I made today, so we can make advertising proxy an informative reference, because the TSR option itself can be used also by other types of proxies potentially, and the current advertising proxy is one example of that. Maybe it will be the only one, but at least conceptually it's kind of separate right now. And for the advertising proxy document, I think yeah there's also sometimes a matter of updating the document to make it more readable or understandable for, for yeah, people who have not been following this so to get it ready for the IESG review let's say. I suspect that will also take a few edits here and there.
Chris Box: Yeah. So, I'm just, you know, thinking aloud here. Is, how does it work timing-wise if we, if we, if we wait till the Vienna meeting to, before we discuss advertising proxy again, or is there an appetite to have a third interim where we could discuss it in more detail?
Ted Lemon: Vienna might be too long, because that's, I don't know when that is, but I assume you actually meant Madrid.
Chris Box: Sorry, I did, yeah. Wrong year. Yeah.
Ted Lemon: So, yeah, I don't, I don't think there's any harm in waiting for that.
Tim Wicinski: So, I'm going to sort of list this input here, because I know Florian and Chris... Madrid's too long, I agree with Ted. But what would also help is if we can pump out newer drafts, newer versions, so we can go through the diffs and then get through the data tracker and sort of, you know, do the edits that we think we need. Is that being too cranky?
Ted Lemon: So, I think that's exactly right. We should just do our normal online process and get the work done. And then basically what we should be prepared to do in Madrid, not Vienna, is declare victory, hopefully.
Tim Wicinski: And I don't mind like a, like the last interim was pretty good because it was a good working group session and this one I apologize like I dragged in some work crap and I couldn't go through the TSR stuff as much, but I will, Ted and others. But another work session may be good as well.
Ted Lemon: Yeah, I don't know. I mean, we did a whole bunch of work on TSR and at this point I think we have almost all of the issues covered by pull requests. There are three or four more issues that I think are significant that still need pull requests for TSR, but we're in actually really good shape with TSR I think right now.
Tim Wicinski: Okay. And those are the ones you marked discuss, right?
Ted Lemon: What's that?
Tim Wicinski: There's a bunch in the issue tracker you have marked discuss.
Ted Lemon: Uh, yeah. So, so we didn't update the, the markings. So, it's not at this point I think some of those markings are probably completely stale. What I would look at more is like which ones are have are closed by pull requests and then look at the pull requests and see how you feel about the pull request. Because we at this point we have a significant, I think we've got four pull requests maybe five open and there's still a fairly significant change that right now Esko has and you know he and I can can talk about whether he's going to do it or whether he should pass it on to me. But either way we're in I think we're in very good shape and so the main question is just going to be like you know what what should our process be for approving these pull requests. I will say that that Esko did a bunch of pull requests which I looked at and they were trivial enough that I felt comfortable merging them. So I hope that was okay. But I mean normally our process historically was we we do a bunch of work to the document we publish the document everybody looks at the diffs and then they decide whether or not they're okay with the diffs.
Tim Wicinski: Yeah.
Ted Lemon: And so that if if you're okay with that level of granularity then I think we're in really good shape. If you would like to be more involved then please take a look at what's what's out there and and you know if you see an issue with any of the pull requests that I merged you can still see them and and so you can you can still add an issue on that.
Tim Wicinski: Oh yeah. There's six pull requests, all of them fail merging checks, so you may want to sort of take a look at that.
Esko Dijk: Yeah, I did.
Tim Wicinski: Okay.
Esko Dijk: That's not a, not our issue actually, basically that the template has a has a bug in it. Oh yeah. Because locally it does work, but on remotely it doesn't build anymore because of an SVG yeah label mistake somewhere.
Tim Wicinski: And I because I tried and I failed also locally, which is why I was sort of like if if we get it to a a reasonable state even if it's half done to sort of push out a new version into the data tracker, that is a good way to also maybe help some of us get moving.
Ted Lemon: Yeah, definitely.
Tim Wicinski: Okay. And I'm not being cranky, Ted. I like a lot of these edits that are coming through, so.
Ted Lemon: Yeah, no, it's totally reasonable. I mean, I think personally I find it much more easy to review the draft like as a change set as opposed to like going through the the pull requests anyway.
Esko Dijk: Yeah, just one one to comment on that. So I think normally it's like yeah indeed like one or two or maybe three people do the pull requests and then it leads to a new revision and that's basically brought to the working group and if that's okay then we can just continue that process.
Chris Box: Yep, I'm happy with that. Florian, do you have a view?
Florian Obser: No, I agree with this.
Chris Box: Yeah, okay. All right. So, that was effectively item zero on the agenda. Should we move on to infrastructure? Sounds like resounding unanimous sure.
Ted Lemon: So should I go?
Chris Box: Yeah, sorry go ahead.
Ted Lemon: Yeah. So, we talked about this in Madrid. I don't know if we, did we have it on the, well we didn't have a meeting last time but we did we talk about it in Montreal? I can't remember. It's not important. Anyway, the what's going on with this now is that so the person my co-author unfortunately decided that he wanted to get into animal husbandry and is no longer doing computer stuff, for which I congratulate him. And so I sort of think I might have talked to Esko about coming on as a co-author and there's also someone very interested at Apple who would like to be a co-author and we've been actually having some discussions about this privately, which it'd be nice if they sort of surfaced as as public, but since this hasn't been adopted yet it's not it's not a working group document. But the bottom line is that I think and oh and by the way I don't know if I mentioned this previously but I've done an implementation of this. And learned some stuff from the implementation, so the implementation is different than what's in the spec. The bottom line is that there's a fair amount of work to be done to update the document and we have somebody who's keen to do that and so I expect to see a document update fairly soon. My personal wish is that if the working group is willing to take on this work, I mean this is like kind of almost the Holy Grail of the DNSSD working group, right? Like we've been wanting to be able to have support for DNSSD and infrastructure for a long time. So I would really like to to propose adopting this once we get a new version out.
Chris Box: Ted, are you able to see the chat? So Tim's suggesting...
Ted Lemon: Sorry. In theory, yes. Yeah. Yeah, I mean, call for adoption. So, the point of the implementation is just to, you know, update it based on what what was learned so so that we so that we're not confusing. We could do a call for adoption now if everybody's okay with that. And then we would just the new version would be submitted as a draft-ietf-dnssd instead of draft-tlk.
Chris Box: I suppose my question is what's what's the likely extent of the changes that are going to go into that next version?
Ted Lemon: Well, so what's been nice about this, so the person that I'm working with is like somebody from, he lives in New Zealand and he's in a totally different group at Apple so there's like no sort of, you know, shared head space on it and he's been giving me kind of a hard time about various issues there. So the document based on the conversations that we've been having would probably wind up a fair bit different than what we have now. Hopefully in good ways. So...
Chris Box: So that would tend to lead me, sorry to interrupt, but it just on that point it tends to lead me towards saying okay let's see that different document before we then call for adoption.
Ted Lemon: Yeah, sounds great.
Florian Obser: Yes, that was also my recollection from the from the last meeting. I also can't recall if this was Montreal or or Madrid where we had this on the agenda, but what I recall from and what my notes say is that the working group was in favor of adopting this once there is a new version out and we have a co-author.
Ted Lemon: Yeah. So the original presentation was actually in Madrid and the former co-author was there for that one. And yeah, there was definitely interest in the working group in adopting it. But, you know, just I think Chris is right that it would be good to just rev the document with the changes that we're discussing so that we have a reasonably clear thing for people to read and discuss. Because I think, you know, the first version of the document has a lot of sort of speculative stuff in it and I would rather clean it up a little bit so that when you read the document you're just like oh yeah this makes sense or you know yeah this is a good idea but I want to change it and so let's work on it.
Chris Box: Okay. Anyone else have anything to say on the infrastructure document? Okay, so let's move on to removal services now. We this was presented in 124 and it was seen as valuable at the time. Francois, what would you like to say on this topic?
François Michel: Yeah, so can you hear me first?
Chris Box: I can.
François Michel: Oh, thank you. So I think right now the focus is to have actual results that it shows that it improves what we want to improve, meaning the the time it takes to register a service when there is a lot of congestion in a constrained network. And we're currently doing that, so we have an implementation of that draft in a client and in a server and we're building up a testbed with a lot of devices where we can see and evaluate whether it it's valuable or not and from that we'll make an update. I don't have an update to make right now because we're still in the testing process.
Chris Box: So when would you expect to have some data from that?
François Michel: Oh pretty soon, so honestly definitely for the next Vienna IETF.
Chris Box: Cool. So, yes. So that's clearly then a good topic to discuss in Vienna and I think yeah it'll be good to see what the working group makes of those results and then we can consider yeah how to move forward I suppose.
François Michel: Hmm.
Chris Box: So, let's move on to replication then. So this is, this is an expired draft that we had some list discussion on this in the later part of last year with respect to meshes. What do you... yeah please come to the mic if you've got some thoughts on how we should proceed there.
Ted Lemon: So this is something that we still want to see standardized but we have not done a second implementation. So there was a, there was an initial second implementation done in open thread but we never, we never did a full interop and we never got to interoperability. And of course that was two and a half years ago and we've learned a lot since then. So, so I still think this is relevant, I'd like to work on it, but it's kind of been back-burner because we have so many other things to work on right now. So I, I would hate to see it like go off of the the list of milestones but it's definitely not going to get finished this week.
Chris Box: Yeah. Go ahead, Tim.
Tim Wicinski: Ted, do you I I would think SRP replication would be below infrastructure but I'm willing you know if you're going to if you're going to sort of order them.
Ted Lemon: Yeah, yeah I mean replication is already adopted so the issue is just like you know it's been sitting around for a while and hasn't made any progress and so that's kind of embarrassing. But yeah I mean the thing about replication is it actually would be pretty useful to have it available for the infrastructure use case and the infrastructure document certainly references it just as an informative reference. But yeah I agree with you that infrastructure is more important than SRP replication in terms of what we should work on first, because nothing that we would be doing in SRP replication would change what we're doing in infrastructure.
Tim Wicinski: And since it's been adopted, why not just pump a version out to keep it the data tracker you know de-Zion sort of lined up and maybe that's me being OCD so I apologize.
Ted Lemon: Yeah because none of the rest of us are OCD.
Esko Dijk: So Ted, maybe a quick question on that. So I understood from infrastructure that we will have a kind of a central place where devices can register with SRP and in that case do you still need the replication or how do you see that?
Ted Lemon: Yeah, I mean that's a really good question to which I don't have a like solid answer. I mean I think I think certainly you can argue that the infrastructure device is going to have stable storage and so we'll just store, you know, the information that was registered in the stable storage and if it reboots that's fine because it'll still have the data and so that won't cause a problem. The the counterpoint to that is that we don't know how long that's going to take to roll out and so, you know, one of the things that infraDNSSD talks about is okay great infraDNSSD is a great idea what if you don't have it and in that case you kind of do want replication. So and the other thing is replication also provides a nice way to transition between servers if you when you're doing a migration. So yeah it you could argue that replication just becomes moot if if infraDNSSD winds up in every home router with good solid support. I think that would be premature but it would be great if a day came when that were the case and and you know I would that would make me very happy I just don't think it's going to happen in like very soon.
Esko Dijk: Okay, yeah and then in case you still want some let's say yeah sort of a backup feature if you have two of these infrastructure devices they could actually use the replication then to stay in sync.
Ted Lemon: Exactly. Yeah.
Esko Dijk: I think one yeah one comment to make about the replication it's usually in my experience has been for a couple of decades a very kind of relatively complex problem with lots of yeah issues popping up so where it goes wrong let's say that's at least my experience with replication so the more parties you would add to replicate the more things can go wrong if you just have two parties then yeah I would say it's still doable in that case so maybe don't replicate over too many elements because that's becoming yeah intractable and also scales badly.
Ted Lemon: Yeah I mean one other argument you made about replication is okay great you know replication is neat but why not just use DNS zone transfers why not just have the you know a primary and some secondaries. We don't do that with with a thread border router because there isn't an obvious primary but if you've got if you've got a home device that's like a CE router that's really infrastructure then having a primary and a secondary is very straightforward so.
Esko Dijk: Yeah and that would use an existing or the existing protocol for that you think?
Ted Lemon: Yep.
Esko Dijk: Okay, thanks.
Chris Box: Tim?
Tim Wicinski: I was going to talk about Sig0 if that's the next topic.
Chris Box: So before we do that any other thoughts on replication or any thoughts from my co-chair?
Ted Lemon: One thing I will say about replication is that we've actually done a bunch of work recently, you know some of this is what what Francois was talking about with the remove all thing but just things to make SRP more efficient in constrained environments and one of them was actually something that I'm referring to as SRP caching. And what that does is actually cache information stable storage and use very lightweight hints from the client to indicate whether anything's changed. And that sort of implicates SRP replication in the sense that the hash that we're using could be used at SRP replication and it would make SRP replication a lot better I think. So anyway you know I don't think there's much more to say about it than that but I think there there's some interesting work being done there and I will probably be able to talk more about it in virtual Madrid which is actually Vienna. Yes.
Tim Wicinski: Thanks. If I can speak Chris. I was the DNSSD chair that kind of pushed this onto DNSSD because and Ray can sort of talk about this it sort of merged in with the QType greater than 1 and it was actually very relevant for what's going on in some of this service SRP stuff. And I do think it's something if if they're still needing that I think it is something that the working group should sort of dig into. And that's just my opinion. But Ray may have other stuff to say he's much smarter than me so. Oh he never mind he oh he was on Zulip only so.
Chris Box: Yeah yeah Ray's not in the call.
Tim Wicinski: Okay, sorry about that.
Chris Box: We don't have Donald either. So I suspect I mean yeah so I'm not sure we can actually meaningfully discuss that here.
Tim Wicinski: I think you are right without Ray or Donald.
Ted Lemon: Weirdly I just saw some email from Donald but so not sure what happened.
Chris Box: Right. What does he say?
Florian Obser: So Donald recently updated the the draft I haven't got a look at it but like I think this year so I guess he's still interested in it.
Chris Box: Oh yeah I believe so, yes.
Ted Lemon: Yeah what I meant by recent email from Donald was that he sent some he did a just did a sector review like literally it went out at 12 past the hour. So I just don't like did he know that we were meeting today?
Chris Box: So yeah we've I've not discussed it separately with him.
Ted Lemon: Okay maybe he just missed the the that this was on the agenda because like I also missed that it was on the agenda.
Esko Dijk: Yeah I'm not even sure was there an agenda sent out because or a mail because I don't think I saw any mail announcement of this meeting.
Tim Wicinski: It was mentioned in the last interim but that's just me so. But you're right.
Chris Box: And it was included in the announcement of this interim but that was a while ago. So I admit I could have been speaking louder but...
Esko Dijk: Yeah it works well to yeah works well to send it typically like a day before or one or two days before then including a link to the agenda or the actual items on the agenda that also works quite well.
Chris Box: Okay. So so that brings us to the end of that. The other I will also say that we are working on a charter update so there is some new text that is that is with Eric to review so once we have his thoughts then well once we have some text that Eric is okay with then yeah I'll publish that to the list and yeah seek seek your input on that charter. And that's all we needed to cover so essentially this the remaining time is is up to you if there's something you would like to progress regarding DNSSD work then then we can cover that otherwise we can we can finish.
Ted Lemon: I will say I feel like this meeting served one valid purpose which was to to push me to get a couple things done that I've been waiting on so so we've already we already have success in in that sense and I'm okay with stopping now.
Chris Box: Okay. Florian?
Florian Obser: Yeah I'm also good with stopping.
Chris Box: Yeah okay. All right let's let's close it here then. Thank you for for your updates Esko.
Esko Dijk: Okay thanks.
Chris Box: All right okay thank you everyone.
Ted Lemon: Bye everyone.
Chris Box: Bye bye see you next time.