**Session Date/Time:** 16 Apr 2026 13:00

**Jonathan Hui:** All right, 9:00 has started. David, I believe you’ve got the kind of kickoff slide here.

**David Lou:** Yeah. Yep. Weza. You can see my screen, right?

**Jonathan Hui:** Yep.

**David Lou:** Okay. Okay, so thanks for joining the interim meeting for the SNAC. So anyone would like me to read out the Note Well? If not, just one note: we don’t see the Note Well. We see your browser with the Meetecho screen. 

**David Lou:** Ah, really? 

**Jonathan Hui:** Yeah, so it might be sharing the wrong screen. 

**David Lou:** Is the screen I’m sharing is this one or Meetecho... let me try it again. Share screen... yes. This one. So now it should be correct.

**Jonathan Hui:** Okay, there it is. 

**David Lou:** Now it’s correct, right? 

**Jonathan Hui:** Yeah. 

**Darren Dukes:** Yes. Great.

**David Lou:** Okay, great. Let’s skip through the Note Well. I assume I don’t need to read it out. And then this is the agenda we discussed between Darren and myself. So we try to review the open issues on the SNAC Simple and then discuss on how could we move on to the Working Group Last Call in case you have any other business we can discuss as well. So any issues or questions about this agenda?

**Ted Lemon:** So one thing that I want to come out of this meeting with is an agreement on exactly what our goals are for state machines because we kind of got jammed on the whole state machine thing. And that, to some extent, I would say is entirely my fault. But I was never actually on board with the state machine stuff, and that’s partly why it’s my fault. So I’d like to get clarity on exactly what the state machines are for. I think we know the answer to that, so I don’t think there’s actually a huge amount of discussion that has to happen, but I just want to make sure that my current understanding is the correct understanding. And once we have that then nailed down, then we can proceed. So that should also be on the agenda, maybe as item three?

**David Lou:** Right, right, right. So I think, thanks for opening that up. I think there’s a lot of issues I list here. The first two actually is related to the email exchange. I think largely resolved like multiple AIL interfaces and also the change the reference. There are still open issues on the GitHub, but I think you are right, a lot of them actually relate to the state machine. So I was wondering whether we should go through those open issues one by one or we first tackle, try to answer, yeah, what you just mentioned, our requirements on the state machine. Maybe we have several options. Either we take it out or we try to enhance it a little bit and make it informative and then we directly move to the Last Call. Or there’s maybe some other suggestions how should we do that? So maybe we can discuss about the state machine because most of the open issues will be resolved if we can have a good conclusion how the state machine will look like. 

**Ted Lemon:** So I think you might be being slightly optimistic there, but that’s okay. Sorry. No worries. No. But yeah, I think if we can resolve the state machine thing first, that will help us when we go through the issue list, which I think we should also do, you know. Basically, our goal here should be to get to the bottom of the issue list, make sure that somebody’s going to solve each of the issues, make sure there aren’t any new issues, and then execute on that and publish and Last Call.

**David Lou:** Right, right. I agree with that. 

**Jonathan Hui:** Okay, so shall we start with the first item on the agenda?

**Esko Dijk:** Yeah, I was just going to say that I think doing the state machines discussion early because I’m not fully up to date with their current status on that, so it should be somewhere early in the agenda, high up, I think. 

**Jonathan Hui:** Okay, so then let’s make item number zero then state machine closure since that’s the biggest point of discussion. 

**David Lou:** Yeah, state machine discussion.

**Jonathan Hui:** Okay, and if that’s our first one, Ted, you had said you had some feelings about the state machine description in the document that has perhaps led to that delay in getting it in or the lack of its documentation. What were your opinions around that?

**Ted Lemon:** Yeah, so we talked about this a bit. I don’t know that we necessarily came to consensus, and that’s basically what I wanted to get to. So last time we talked about this, I think that the general conclusion we came to... so maybe I’ll back up just a step. The issue is making state machines normative is really hard. And it’s kind of a known issue. Like, we actually did this in the DHCP state machine ages ago and it was a disaster because the normative text and the state machine didn’t match, and people were following the state machine instead of the normative text, or vice versa, and there were interop issues. So, but the motivation as I understand it for having the state machines is that it gives implementers some guidance as to how to actually implement this stuff, which I think is not a bad thing. So I think the... my recollection is that where we landed last time was kind of that we were thinking, okay, let’s have normative text in the document that describes everything and then we will have state machines that describe the things that seem complicated, which will be in appendices and explicitly not normative. So if you find a contradiction between what’s in the state machine, or if it seems like there’s a contradiction between what’s in the state machine and what’s in the normative text, the normative text is always correct. And that I think kind of clarifies it, and it also makes my life a little bit easier because when I was trying to write the state machines I was really getting wrapped around the getting-it-perfect axle, and that was not good. And I think that’s one of the big reasons why we kind of got stuck on that. So I’d really like to get unstuck on that because we’ve been stuck on that for kind of a long time. 

**Jonathan Hui:** Okay, and I believe we have a couple of people in the queue, but to continue that discussion, maybe we’ll go to Éric.

**Éric Vyncke:** Yeah, I was about to say regarding the queue management... we have six in the call, right? So I think we can completely bypass the queue management and simply talk when we want to talk and feel free to leave or do not leave your video on this one. And I agree with Ted. I mean, if we can move the state machine in the appendix and clearly mark it as non-normative, it’s the easier, the simpler. I mean, as you can imagine, right, we need to get a closing on this. Thank you.

**Jonathan Hui:** Anyone else on that topic? I just posted in the chat, agreeing with Ted. Okay. Then the question that now stands is, and I’m going to say that’s, you know, of the people here, that is a clear consensus that it will be informative, not normative. Is there sufficient description in the document now where the informative or informational state machine content, as nice as it might be, if it’s not going to get produced, do we leave it for some other document if someone wishes to write that, and we simply proceed with the normative text that exists right now?

**Ted Lemon:** So I haven’t done an explicit review to make sure that that’s the case. I mean, certainly when I originally wrote the text, my goal was that the normative text would cover everything, but I think it’s worth doing another pass over to make sure that we haven’t... because we’ve learned so much since we actually started this work that it would be worth doing another pass over just to make sure that there isn’t something missing. But yeah, I think that’s, you know... and you know, I should say, like, I have code for... I mean, code... I have text for the state machines, so we should definitely put them in. But I just... the place that I was stuck was just like getting clarity on what the goal of the state machines was, and I think we maybe now have that. I mean, obviously, we should announce what we decided on the mailing list and let people argue with that if they... because I don’t even remember who originally brought up the whole state machine thing. It might be somebody who’s on the call and it might not. Éric, you’re muted.

**Éric Vyncke:** Which is a good interest of getting your video on because then people can notice. So as you can guess, right, my hope is really to get the Working Group Last Call done early, so I don’t think we need for any points that you make today, right, including the state machine. You upload something like an N+1 and we go to the Working Group Last Call. It gives the time for people going into comments. So I would not go asking and then...

**Jonathan Hui:** Yeah, and I’m thinking that if the content that’s there now... if you say, well, it’d be a good idea to get one last look at it and make sure it’s right, that’s exactly what the Last Call’s for. So that would be, you know... as far as state machine goes then, I am convinced that for the normative text that we are ready for... there’s nothing in the state machine description that holds us up from going to Last Call at this moment, given that the state machine will be informative, informational.

**Esko Dijk:** I do have a few questions on this. So maybe it’s important to know because I wanted to do some more PRs, and I was actually waiting with some of them until the state machine stuff got in, so it’s kind of important to know what it is because I didn’t want to disrupt that ongoing work. If we say it’s in appendix, then maybe I don’t need to worry. But there’s also a existing state machine, at least one, in the main text. So do we leave that one in? Is that the idea?

**Ted Lemon:** Oh, well see, yeah, that’s why I’m not sure that we can just immediately do a Last Call, because if we do... like, the problem with Last Call is if you do a Last Call and everybody reviews the document and then you make a bunch of changes to the document and ask everybody to review again, it’s not... well, we can do another one, but let’s be a little bit more mindful of people’s time. So I think it’s worth like if there’s stuff that we think we know we want to do now, like we’re going to go over the issue list, there’ll be some stuff that falls out of that that we know we want to do. Esko, you have some things you know you want to do. I think it’s fair to say that the changes will be that the state machines will go into the appendix, and so the state machine that currently exists in the main text is going to be moved to the appendix, and that means that we need to make sure that we have the right normative language in the main text after that state machine is pulled out. And I don’t think we should do a Last Call until that’s been done because otherwise we may find ourselves basically asking people to review almost a completely new document—I mean, hopefully not, but you see what I mean. It’s like, it’s a big ask. 

**Éric Vyncke:** It’s a bit ask, right? But if again, we can talk about Working Group Last Call at the end, and it’s better to put it at the end, but we need to get moving. That’s basically what I can guess, right? 

**Jonathan Hui:** Okay, so I think we’re closed on the normative versus informational on the state machine. There is normative text in the document right now that describes the missing one. So let’s move past item zero. 

**David Lou:** Yep. So in that case, I mean, for the next mostly is about the 21 open issues. So I don’t know whether Ted or Esko, you would like to share the screen and then probably we can review those open issues, right?

**Esko Dijk:** I think we had another thing on the agenda also, like what’s now become number two. Ah, the... yeah, I can share again. Because I believe most of them already resolved, but nevertheless I can show the screen again. So you see, in item two, the first two item was something has been exchanged via the email intensively for the past days or weeks. One of the thing is whether we need to handle multiple AIL interfaces, right? I think we reached certain consensus via the email that it should go to SNAC Complex or whatever, but it’s out of scope of SNAC Simple. I just list here to make a record what happened. And then the second part is the change of reference to SNAC Simple from normative to informative but in the RFC document, which has been done by Jonathan, right? So I think we can directly probably jump to the 21 open issues. 

**Jonathan Hui:** Okay.

**David Lou:** Esko, you want to share the screen, or Ted?

**Esko Dijk:** Yeah, I can have a look if I have something... first need to make a screen. Okay, I’m now requesting screen share. Okay, this seems to work. Make it a little bit bigger. So how’s this? 

**David Lou:** Readable for me. 

**Jonathan Hui:** Yeah, readable. Yeah.

**Esko Dijk:** Okay, so we have the open issues here. There’s also the PRs, so I’m not sure if you would like to have a look first at the PRs just to see how that’s being done. So I think the bottom two are about state machine and they I think are old, right Ted? So not the most current ones. 

**Ted Lemon:** Sorry, the problem with switching back and forth, I can’t enable my microphone. Yeah, so I think we can skip the second two pull requests unless people just want to see where we’re at, but I get the sense that if the state machines are kind of like, you know, not normative, then we don’t really need to go into detail on that right now unless somebody wants to.

**Esko Dijk:** Yeah, so that needs to be updated and I think you will make then a new state machine PR basically that will send this content to the appendix. I think that’s the idea. 

**Ted Lemon:** Yep. 

**Esko Dijk:** Okay, let’s see. I had another one here that we could take a look at. So I see Ted did a review on that. Yeah, so this is basically I think looking at ULA link prefixes and how that is maintained across reboots. I think just let me see what the change is here. Yeah, so the change is basically here that the idea is that the prefix for the... let’s see, I think it’s ULA link prefix, yeah. So it’s the ULA AIL link prefix should remain stable. I think that’s the idea, but if there is a new kind of new network detected then it should allocate a different prefix. I think that’s the idea. 

**Éric Vyncke:** And by the way, on this one, right, the IESG is currently very inflexible regarding the use of ‘should’. If you put a ‘should’, which is okay, you need to provide guidance on when the ‘should’ can be bypassed. For instance, for the first part, right, ‘should be maintained across reboot and should remain stable’, provide there is stable memory or something like that. 

**Esko Dijk:** Yeah, exactly. Yeah. So there have also for each of these there would need to be exception cases then. 

**Éric Vyncke:** Or you replace it by a ‘must’. 

**Esko Dijk:** Or it’s a ‘must’. Yeah, it’s also doable, right? So yeah. 

**Ted Lemon:** And do we have a document we can refer to that describes this stuff? Because like I know that, you know, like Apple and Google phones do this kind of anonymization already. And it would be nice if there’s a doc... I don’t know if there’s an IETF document that describes that, or if that’s just something that they decided to do. But if there is, it would be good to refer to that because it’s a little bit more nuanced than what we say here. I don’t think we want to go and define it in detail here, but it would be good if there was something we could refer to.

**Éric Vyncke:** You may want to have a look at the MADINAS. There are two RFCs where they were talking about MAC address changing and maybe in some radius change of authorization where they also need to change and update. But it’s a huge amount of thing to look for, though.

**Ted Lemon:** Yeah, right. Okay, I see these two RFCs: 9797 and 9724. Okay, so let’s just make it a to-do... we can make this a new issue, that... and I’ll add the issue... that we’re going to look at RFC 9727 and RFC 9724 and see if we can reference them. And if we can’t, we can’t, but if we can, great. 

**Esko Dijk:** Yeah, so at least the exceptions are here for the last ‘should’. And what’s basically explicitly added here is that the prefix is based on some properties of the stub network. And I think that was done to cover the thread case where we basically take some information from the thread network and use that to generate the prefix. So in that case, you can have multiple SNAC routers and they... if they operate for the same stub network, they will independently arrive at the same prefix to publish, which is kind of good for the stability of that prefix. So that’s basically an exception case here. So if it’s based on the SNAC... yeah, the stub network properties, the number, then yeah, you can use that. So I think that’s the main change here. And there’s another one exception for configuration basically, so... 

**Ted Lemon:** Yeah, and the reason why I asked you to explicitly say user or operator is because otherwise somebody might read that as it’s perfectly fine to ship a router that’s configured differently than this, which is not the case. 

**Esko Dijk:** Yeah, yeah, that needs to be by the user, operator, or administrator or whatever. Yeah, that’s correct. Yeah. Okay, that’s fine then. So if there are no further comments, we can maybe look at the next one. So this gave some discussion on the mailing list as well. So the idea was just to have added references for NAT64 and DNS64, and the discussion was I think focusing on DNS64, which was recommended for the Wi-Fi stub network case. So do we even want it? Do we even need it? I think that was the idea. 

**Ted Lemon:** Yeah. Well, so this document’s been around a while, and when we originally wrote it, we didn’t have an implementation and hadn’t really discussed it in much depth, and that’s where that text came from. When we were discussing this pursuant to thread spec, we concluded that even an IoT device is capable of doing synthesis. Like, maybe it’s not going to do DNSSEC validation, but synthesis is just not that hard. And so... and you know, in the thread case, of course, it’s a greenfield, so we can make requirements that maybe wouldn’t be viable for the more general SNAC use case. But having gone through that whole process, I feel like that was a successful thing and also as time has progressed with the IPv6 Mostly work that V6OPS has been doing, I think we’re at a point now where most devices can do local synthesis and will use the PREF64 option if they see it in a router advertisement. And so actually, I think that we should just go with that here, like we shouldn’t require DNS64 synthesis on the SNAC router because it’s reasonable to expect end devices to do that. 

**Éric Vyncke:** And I agree, Ted, that’s basically what CLAT, the part of IPv6 Mostly or 464XLAT, is doing, right? Local synthesis. And interestingly enough to add pressure on Jonathan and this array flag, there is a CLAT document, right? In V6OPS that relies on a document that relies on the array flag, right? Yeah, we’re in the circle. So basically, yes, remove all reference to DNS64. I think that’s better. And Jonathan, thanks again, right, for updating the array flag stuff. 

**Jonathan Hui:** Yeah, of course. 

**Esko Dijk:** Yeah, okay. That sounds like a good solution. Maybe we can update this PR here to include that, then. Let’s see, I can... yeah, maybe keep doing that, so I’ve created it, so... Great. Yeah, and then for NAT64, the requirement... adding the requirement should be okay, right? Yeah. Then that’s the one here. Okay, then let’s see. One more to go here. Yeah, this was for the change for the multiple AIL interfaces to support the single one. I did notice indeed there was in most of the text there was already a single assumed for a SNAC router and in a few places it was assuming multiple. And I think Ted said he agreed with it and there were a few things to... to do, so this... this one I’ve already updated, reworded. And one particular thing is I also have reworded the requirement that was posed on multiple SNAC routers, so that’s kind of the plural form of ‘must’. It’s like ‘SNAC routers must do this’, like as if they do it together. But I’ve rephrased that to singular now because I think that’s more clear. 

**Ted Lemon:** Yep. 

**Esko Dijk:** Okay, and this was a to-be-done I think. Yeah, we simplified it already a bit and there’s only one to-be-done for my name. I think it was the name of the DNS zone that is kind of used for, yeah, storing the SRP registrations and... also something you can query basically. 

**Ted Lemon:** It’s a bit complicated. So the... let me just... I mean, actually, the last comment that I made sort of summarizes, but basically the issue here is that we have the SNAC router connecting to an infrastructure, an AIL. The AIL may or may not have DNSSD discovery enabled on the... in the DNS resolver. And, you know, most of the time nowadays it doesn’t, but in principle it could, and RFC 6763 requires us to support that, essentially. So there’s actually... and there’s that creates one problem, which is we need to make sure that we don’t block the DNSSD unicast discovery provided by the infrastructure network if it’s present. And the second issue is that the discovery proxy, we need to be able to do queries against the discovery proxy and we need to decide what domain to query for those. And so... you know, our option... we have options, right? One of them is we could actually just say do your DNS queries in the .local domain and you’re sending them to discovery proxy. The discovery proxy knows to do discovery in .local, but .local is ambiguous, it could mean the AIL, it could mean the stub network. So we probably don’t want to do that. And so... but we do need to provide some domain name that the SNAC router implementer is going to use, because if we don’t, they’re going to make one up and it will probably be one that we would rather they hadn’t made up. Like for example, if you download OpenWrt, it uses .lan I think as a domain. And that’s not a domain that’s like been allocated for that use, it’s just a domain that somebody made up years ago and nobody’s ever changed. So if we’re going to require that there be a discovery proxy and understanding that this is not an infrastructure device, so we can’t expect the infrastructure to provide a delegated domain for us to use, then we need to make up a domain. And so that means we need to say what it is. And this is actually kind of a separate issue, but I just noticed it here because you made that change to the text. So anyway, I think we do actually need to say what the answer to that question is. And we have like the service.arpa domain that we could put other things in. Thread currently uses default.service.arpa for this. We could just do what Thread does. I think there’s a case to be made... I mean, the reason we did that was because it was super easy and it was a domain that was already allocated. If we’re going to have it actually officially have that use, we should say so here and we should document that and we should actually ask the IANA to update the IANA registry to mention this use. Because right now we only use it for registration, we don’t use it for queries. Like, the IANA registry doesn’t say anything about using it for queries. But I think it’s valid to use it for queries, that’s why we did it. So... yeah, and the thing I explicitly want to avoid here is that we’re doing work in the DNSSD working group, I hope, to finally solve the problem of infrastructure DNSSD that really works for non-managed infrastructures. And we want to make sure that what we say here doesn’t contradict what we’re going to say later there. And I think what I just suggested would work, would be okay. 

**Esko Dijk:** Yeah, okay. And yeah, one thought I had for this PR, we could just leave the TBD in because that’s kind of the open issue you mentioned. So it’s not fundamentally changed here by the PR, so I decided to leave the open issue itself just in as a TBD. 

**Ted Lemon:** Yeah, but we should just make that an issue and maybe I should just make that an issue. Hang on a second. 

**Esko Dijk:** Yeah, you can make it an issue, that gives it a little bit more visibility maybe. Of course, before you send things to Last Call, you should always do a find on TBD first and on to-do. That’s just general advice for everyone here. But okay, I did see one thing about the name is that yeah, often if you’re connected to an ISP it will kind of delegate a certain domain, like my provider it’s called ziggo.nl, so it will delegate that, so you can get a local name assigned that has something.ziggo.nl in it. 

**Ted Lemon:** Really? 

**Esko Dijk:** Yeah, I’ve seen that work in I think in Windows and Linux. Not sure how exactly that works, but that sometimes comes up. So in that case, the domain could also be something that is based on that, yeah, delegation. I’m not sure how that works even, or that the local machine just makes up a subdomain of ziggo.nl, or based on the subscriber number or whatever, I don’t know. So I thought it could be a name that is basically just based on something from the upstream ISP. 

**Ted Lemon:** Yeah, so we’re now dipping our toes into Homenet territory and that is an unsolved problem in Homenet and I think if we try to solve that problem here, we aren’t going to get to Last Call before July. So... yeah, I think we should punt on that. I think, you know, yes, that’s a thing that it would be nice to solve, but that’s really out of scope for SNAC. Like, that’s not a SNAC issue. Like, that’s actually... I mean, you could call that a V6OPS issue in the sense that it’s really something that we would need to specify in a CE router document. It’s definitely not something that we should be specifying here. And because we don’t have a spec to consume, I think we’d have to leave it open. What I think we can do is we can say, if you need to make up a domain, you must not just make up some random domain, the domain must be a subdomain of default.service.arpa or something like that. And that way we avoid having vendors just use .lan or whatever. Like, we just don’t want that.

**Esko Dijk:** Yeah, so I also heard you say Ted that default.service.arpa is a candidate name because it’s already there and used for the registration, can also be used for the querying. 

**Ted Lemon:** Yeah, I mean, that’s the simplest thing to do is just say, okay, use default.service.arpa. Like, we’re not trying to like invent rocket science here. This does not have to be like... this does not have to be the all-singing, all-dancing solution to every problem, and maybe default.service.arpa is good enough and we don’t need to go any farther than that. 

**Esko Dijk:** Something with SNAC, I think you said also, snac.arpa or... 

**Ted Lemon:** Yeah, snac.arpa, I think... you know, so not snac.arpa, snac.service.arpa. Basically when we allocated service.arpa, the idea was that it would probably be something that would be used in general by DNSSD specs. And so if we want to do something... 

**Éric Vyncke:** I agree with Ted, we should not put SNAC into whatever domain name we use because it’s much more generic than SNAC. 

**Ted Lemon:** Well, so the only thing is we definitely don’t want it to be just a subdomain of service.arpa because if we do that, then we’re in trouble, like we’re eventually going to be having like unexpected clashes of domains that are allocated. So we could say... you could sub-delegate or you could have subdomains of default.service.arpa, and I think that would... like if you don’t want to use SNAC, I think that’s the easiest thing. Home.arpa is a different use case and I don’t think we can use it for SNAC, but we certainly could use it for CE router because that’s actually what it was intended for. I don’t think that the current CE router spec talks about that, though. 

**Esko Dijk:** No. Okay, I’ll just make a comment here then capture a bit of the discussion. So you would make separate issue for that. 

**Ted Lemon:** Yeah, so I created a new issue for that, yeah. 

**Esko Dijk:** Yeah, and this TBD is already updated to refer to the name only, so I think it should be okay then to also merge that. 

**Ted Lemon:** Did you take out the explicit reference to .local? 

**Esko Dijk:** I called it now differently, let’s see. Yeah, .local... yeah, I call it now ‘the local domain on the AIL’, that’s maybe still too specific. But this was about discovery proxy. 

**Ted Lemon:** Yeah, I would just delete that whole sentence because... well, yeah, so the SNAC router must provide a discovery proxy that allows devices on the stub network to discover devices on the AIL. Rather... because what you’re saying here is basically almost like you’re summarizing RFC 8766, and we shouldn’t really do that because that can create interop issues. 

**Esko Dijk:** Yeah, I think that’s also a way to say it, so just discovery proxy does specify... actually uses .local. I don’t see any other thing here, so it must be there. Yeah, but that’s a good point, so maybe I’ll just update that. Look at it later in detail and then... okay, the rest should be okay then. So I think we have done now all the PRs now. Some time left to move to the issues. Ah, okay, there are two new ones. ‘Discovery default subdomain’... this was for the name thing, right? Okay. 

**Ted Lemon:** Yeah, I mean, you can assign that one to me if you want. I think that would make the most sense. I don’t know how you feel about the MADINAS one. If you feel enthused about that, then assign it to yourself, if you don’t, then let me know. 

**Esko Dijk:** Oh, okay. I’ll take a look. Yeah, okay. I did see that work before sometimes pop up. So... yeah, I mean, I honestly don’t know if we can constructively refer to those documents, but if we can, I think it would be better because that way people have more to go on than than just some vague hand-waving that we put in our document. Yeah, okay. I can at least take a look. Let’s see. This was the discussion that we I think concluded, so that need the PR to go in. Yeah, that’s already mentioned there, so that’s good. Ah, this was one we have just been discussing before the meeting, also. A good just to point it out for the other people. So the idea was like if you have a SNAC router, it could offer secure DNS querying that could be, for example, over TLS. There’s also the HTTPS variant. And there’s a whole thing of discovering that, the secure options for DNS, so there’s a whole infrastructure already in place there. But so you could get a secure link to basically over the stub network to the SNAC router. But from that point onwards, the SNAC router could actually fall back to completely unsecure DNS because there’s nothing else on the upstream server. Um, yeah, this might be at the ISP, for example, or in the CE router if it takes that role. Or somewhere else, but it might not have the secure options. So then the question is, okay, is there anything we need to do to make that secure, but that would require DNSSEC probably, so it’s still not private, but it’s at least protected in other ways. 

**Ted Lemon:** So yeah... I mean, I wrote a summary of this, but basically I’ll just kind of summarize what I think is the case here. So what we’re providing with DNS over TLS, because we don’t have a valid cert that can be validated, so that means that all you’re getting is that your connection to the server is encrypted. And that means that an attacker that’s on-link can also offer a server and potentially snoop on your traffic. And so you’re... what you’re getting is not security. What you’re getting is maybe some protection against snooping and that’s it. And if you get that, then what happens upstream is that all of the queries coming from the SNAC network are aggregated, and so in principle that might protect your privacy a little bit because you can’t tell who asked the question, just that someone on the SNAC network asked the question. And that’s actually the only... really all the security that you get out of DOT anyway. So if you really want to have true anonymity, you have to do the double-blind proxy. I can’t remember what it’s called, but it’s something that’s been worked on in I think in DEPRIVE. And that’s something that’s done on hosts, so we’re not involved with that work at all. And so we don’t... therefore we don’t need to worry about it. So I think we actually just don’t need to worry about this. We don’t need to do anything fancy, we don’t need to make any requirements... 

**Éric Vyncke:** Yes, let’s not boil the ocean, right, basically. 

**Esko Dijk:** Right. Yeah, no, but it was just I thought it would be good to add maybe just a security considerations sentence that points this out. 

**Ted Lemon:** I mean, is there one in the CE router doc? 

**Esko Dijk:** Yeah, the CE router doesn’t have DNS server at all, there’s no requirement on that. So it’s nothing about that topic, so logically, right? It doesn’t have that problem because it’s not providing a DNS server. So... yeah, I’ll just think about that, but that means we can probably close that one discussion is done. Just move that flag. Let’s see. Next topic here. Yeah, so this is basically the handling of what’s called significant change on the AIL. And this comes from the... at the time it was at least still the draft RFC 8415bis. So there’s the handling of significant change on the AIL if you’re DHCP client. And for example if you have a prefix delegation ongoing for the stub network prefix. So there’s a whole bunch of requirements there and all of this is a ‘should’ level requirement, so you could read it as recommended but not really mandatory. So what if someone makes a SNAC router that doesn’t do any of that because it’s not mandatory? Do we allow that, or do we basically not worry about it, just leave it as recommended, or do we tighten it, let’s say we require this behavior for the SNAC router just to ensure that it actually works. 

**Ted Lemon:** But that would be true of any device that’s doing prefix delegation. If it... if it doesn’t follow the ‘should’, then it might not work. And presumably, given the fact that this went through the IESG fairly recently, they’ve probably fixed the lack of clarity about the ‘should’. And so I think... I think this is not our problem, right? Like, it’s always tempting to fix some other spec that we’re referencing, but really RFC 8415bis is the spec. And... yeah. 

**Esko Dijk:** So we should re-check that and I think the consensus would be not to change all those fix other specs, basically. 

**Ted Lemon:** I mean, I think this goes to the boil-the-ocean observation that Éric made a moment ago. 

**Esko Dijk:** Yeah, so like in other clients that are not SNAC routers, it would be the same. Yes. Okay, I’ll just do a quick check and close it. And for the new reference would be handy to have I think in the document, right, for the PD part because this is now the main reference, right, for the prefix delegation which we require. 

**Ted Lemon:** By the way, the ‘should’ doesn’t have any clarification. 

**Esko Dijk:** No, I was looking at it as well. Oh, really? Okay. 

**Ted Lemon:** But that’s okay, this is not our problem. And I mean, you know, vendors... I mean, the way this goes is like if it’s important to the vendor that this thing work, then they may look at that ‘should’ and say, well, okay, what do I need to do here? But like I’ll say in my case, I’m a consumer of the DHCP prefix delegation client. I didn’t write that code. And so I don’t actually know what it does. I assume that it follows the spec, but that’s all I know. And I think that’s a likely thing. So... you know, I suppose we could try to make people investigate, but the reality is if it’s a problem we’ll find out about it when we get bug reports. I realize that’s a little bit of a... that’s a little bit of a punt, but... 

**Esko Dijk:** Yeah, so we will still boil the ocean but one drop at a time, let’s say. 

**Ted Lemon:** Yeah. 

**Esko Dijk:** Yeah. Okay, I’m moving to the next one. One of the things that I realize I have a tendency to do when I’m writing documents in the IETF is try to get it perfect the first time, and best is the enemy of good enough. And right now I’m not concerned about this. I don’t have any worries. I don’t think we’re going to have a problem here. We may learn otherwise. If we do, then there’s always the ‘bis’ version of this document. 

**Esko Dijk:** Okay, yep. Meanwhile, I’ve shown on screen the next item, so I put in the ‘waiting’ state with the label because it was kind of depending on state machine work, but maybe I can now have a look again at this. Yeah, I think the point was basically that you could have a power outage scenario like in a home or shop where all the SNAC routers reboot simultaneously. And in that case, they come up to this initial behavior that was already discussed a bit. So there was a kind of let’s say broken randomization in that case. So instead of picking a small random value, the spec said first pick a big random value and then cap it to 16 seconds. So that means that most of the devices will end up at the 16 second exactly where they will do the same action coordinated, which is not nice in case if you have many of these SNAC routers. 

**Éric Vyncke:** You know, Esko, the good is the perfect of the whatever, right, always. It’s an issue with 4861, it’s not an issue really for SNAC. So I think if you say, ‘Hey, we need to follow RFC 4861’, then we are all set. 

**Ted Lemon:** But the problem is still there, right? But our problem right now is to ship the document. 

**Esko Dijk:** Yeah, that does relate a bit to the state machine, so if we don’t describe a detailed state machine then we might not hit that problem. Indeed, it came about because we had a quite detailed state machine. And then you start wondering about startup behavior and things like that, so... but okay, I think the SNAC router does a few things differently than specified, but okay, that’s... so you can actually say some things that need to be different from the previous specifications, like for RA sending, I think we have specific timing requirements that are at least we had in the beginning that were not exactly the same as from the older specs for that. But Ted, you wanted to add something? 

**Ted Lemon:** Oh, no, I mean I’ve been thinking about this conversation and I think Éric’s point about not updating RFC 4861 is certainly a valid point. Basically, I think... so, I mean, one thing to say about this, Éric, I don’t know how aware you are of the way this stuff is deployed currently, but a lot of times these stub routers are actually... these SNAC routers are sitting in devices that aren’t routers that you buy because you want a speaker. And so one of the issues that we deal with is scalability. If you only buy two speakers, then you’re not going to have a scalability issue, right? Who cares if both devices wind up sending RAs at the same time? But we are aware of installations where somebody might have a lot of speakers. You know, like 10 speakers in a home is... it’s a lot, but I mean, these things don’t cost much, so it’s not that uncommon for there to be 10. And now you’ve got 10 devices that maybe are all going to broadcast at exactly the same time, multicast at exactly the same time. Maybe it’s actually worth going a little bit over and above what 4861 does because of that. Because 4861 was really anticipating that there would probably just be one router on a typical link and maybe there would be three or four routers on a more complicated link, and now we’re talking about 10 or, you know, I know of cases of 60, right? Which is crazy, but there it is. So that’s why... that’s why I think it may be worth being a little bit more particular here than 4861 is. 

**Éric Vyncke:** I understand the problem, right? And 4861 was there was no Wi-Fi at that point of time, right? It was a big thick yellow cable, if anybody remembers this. Oh yeah. But again, right, if we are waiting to be perfect, it will be too late. And this kind of detail can be addressed by specific products as well. I know I’m not satisfied with what I’m saying, but we need to move. 

**Ted Lemon:** I mean, we know about this issue and I think Esko’s point is valid and there’s... it’s easy enough to just add some text that says what to do here. So like do we really want to not do that even though we know what to do? 

**Éric Vyncke:** If Esko can write a sentence in one second, then merge it, right? 

**Esko Dijk:** It’s not one second, but I can... you get the point, right? It’s 43 seconds precisely. Why not 42? That’s already taken. Okay. Yeah, let’s not do something complicated then, maybe I’ll just have a look into this. It’s not waiting, this was ready to close now, was already done. Let’s see here. This one had a PR, so we already went over that. Yeah, there are a couple of items I think we have five minutes left, but a couple of items that were kind of assigned to Ted to do together with the state machine. I think that’s most of these that follow now. Except this one, G. 

**Ted Lemon:** Yeah, I would say if you see something there that we ought to discuss, that would be great. I feel like we’ve had the things that I really wanted to discuss, we’ve discussed, so I feel satisfied already, but that doesn’t mean we can’t discuss more stuff. 

**David Lou:** Okay. So, I’m sorry to interrupt. I only book one hour for today. So although the rest of the items or issues, I think a lot of them I saw related to the state machine, but I don’t see we can close everything today. So given that, how about have another interim next week, for instance? Similar time. 

**Ted Lemon:** So you need two weeks’ notice, but I think... and by the way, next week is the Thread group meeting so I won’t be available. So that all works out really nicely. Two weeks from now I think would be good if that’s okay. I mean, unfortunately that puts us a little bit past the end of April. So we may be in trouble with our AD. 

**Jonathan Hui:** We can do that. However, I’d like to just schedule... I’d like to put it out there to the working group that we’re ready for Last Call. So five things have been merged and we got through those today, or can be merged now. There’s a number of remaining issues, but I mean, there’s nothing like a Last Call to get the last bits closed, right? I think we should move forward with it. 

**Ted Lemon:** Let me make a suggestion. I have about 10 hours of train rides coming up in the next couple of days. So basically, that ends Monday evening. So I should be able to spend some serious time on this between now and Monday evening. How about we do a Last Call once the new version of the document has been published after that work, which maybe Esko could do on Tuesday, or actually Esko and I are both going to be super busy on Tuesday. Shit. Hmm. Well, so sometime on Monday. 

**Jonathan Hui:** Okay, so in the minutes of this meeting that we’ll send out, we’ll state that we’ll enter a Last Call on Monday with the updated document so people have time to read it. 

**Esko Dijk:** Yeah, I think the remaining issues can also be worked on during the Last Call time. I think that’s the idea. 

**Ted Lemon:** Sure. Yeah, and David, so David, you need to sign us up for the next meeting because the soonest it could be would be two Thursdays from now if you send the request in today. 

**David Lou:** Okay, so in two weeks we meet back, right? 

**Ted Lemon:** Yeah, and this was an okay time for me. I don’t know how the California folks feel about it. 

**Jonathan Hui:** I am not here, so... 

**Ted Lemon:** Oh. You’re in Cannes? No. 

**Jonathan Hui:** I’m in Cannes, yes. But we can run it without you, Jonathan, if that’s okay with you. Oh, Jonathan, though. 

**Jonathan Hui:** It’s okay for me. Okay, all right. 

**David Lou:** Thanks. Your sacrifice is much appreciated. Okay. Maybe from my side one more things from my side. Because I saw a lot of contribution, significant contribution from Esko. I was wondering whether we can add Esko into the authors list. Is that okay for everyone? 

**Ted Lemon:** Yes, please! 

**Darren Dukes:** Yeah. 

**Éric Vyncke:** Well deserved indeed, yeah. 

**David Lou:** Yeah. Okay. Great. 

**Jonathan Hui:** Okay, we’ll be kicked out of this room in less than a minute. Yes. 

**Éric Vyncke:** Yes, that’s right. Thank you for the last minute drive and run. We are close, right? We are feeling the end of the journey. 

**Ted Lemon:** Yes. Okay, thank you. Thank you for the minutes, Éric. Yeah. Bye-bye. 

**David Lou:** Bye. Bye. 

**Éric Vyncke:** Bye everyone. See you. Thank you, Ted.