Session Date/Time: 30 Apr 2026 13:00
Esko Dijk: Okay, I think we had no official agenda for today, right? So.
Darren Dukes: Yeah, we had no official agenda. Thought if we could make, meet to make more progress on anything that's open. If we can contribute to that, we will. If we get some non-authors attending, we'll remind them that the reviews are greatly appreciated and timely reviews are even more appreciated.
Darren Dukes: How was the conference last week?
Esko Dijk: Yeah, that was pretty busy, but I think it was good.
Darren Dukes: Excellent.
Esko Dijk: Also visited Vienna.
Darren Dukes: Pardon me?
Esko Dijk: Yeah, we also went to Vienna last week, so.
Darren Dukes: Oh, nice.
Esko Dijk: Coming back in July again.
Jonathan Hui: Yeah, we're going to try the night train this time. See how it goes.
Darren Dukes: Nice. How long is that trip on that train?
Jonathan Hui: Uh, you get on at like 6:00 p.m. and you get off at about 9:00 a.m.
Darren Dukes: Okay, yeah. My daughter took that last year, last summer. She was out that way.
Jonathan Hui: It's challenging when you're doing it by yourself, because then you find yourself sleeping in the same room with other people that you don't know, but.
Esko Dijk: Five other people, sometimes.
Darren Dukes: Yeah, she had a whole group of Swiftie friends that she was traveling with.
Jonathan Hui: Oh, nice.
Darren Dukes: All right, so let's, let's get started. I will flash up the correct Note Well here. So we all remember policies and, give me just a moment.
Darren Dukes: Oh, what happened there?
Esko Dijk: Yeah, no more audio, it seems, from Darren, and no screen.
Darren Dukes: Back on my other side. Sorry, I'm having to work from home today and there's a gentleman showed up to do an energy audit, so. Okay, um, let's get back to this. Share the Note Well and that's now part of official IETF record.
Jonathan Hui: This is extremely uninformative. All I'm seeing is "A screen share is being started."
Darren Dukes: I think it's started now. Share entire screen. Yes. And we'll go here. Yes. Okay, Note Well. Here we go. Anything we talk about is recorded, and we will be respectful and aware of our contributions. Anything covered by patent or applications, which reminds me of a topic that was in the last call request for any authors, contributors to divulge any patents, any patents around the area of this particular specification. That includes you two gentlemen. So we should make sure that we get that handled if there's anything to be divulged. And these audio and video recordings will be made public. Okay.
Jonathan Hui: I'll have to, I'll actually have to look at that. I don't think there's anything, but it's worth checking.
Darren Dukes: Yes, absolutely. Stop the screen share. Yes, and it's of course anything that we are aware of we must divulge. Okay, now with that out of the way, we've got Jonathan, Esko, Ted, myself here. Do we want to, how would you guys like to run this? We're all here. Do we want to knock off some issues? Do some work that way?
Jonathan Hui: If we can, that seems like a good use of time. I think there are, so I haven't, I, it's all a blur to me now. I seem to recall that I did a bunch of work on the train to Vienna, and then Esko did a bunch of work too. We were kind of tag-teaming, and then Esko published, and then on the way back, I think I was doing work on other things, and this past week I haven't had time to do any more. So if we can catch up on some issues, that would be great. But there are still a few open issues there that I think are probably like if they're going to get closed, I need to sit down by myself and do some typing to close them. So, so those we probably can't do on the call.
Darren Dukes: Okay. And would one of you guys like to drive? Would you like me to?
Jonathan Hui: I think it works well if you drive.
Darren Dukes: Okay, I can.
Esko Dijk: Yeah, I just wanted to say something about the work being done, so. I still have a PR upcoming with editorial improvements. So that's, I think, all purely editorial. But still, things that it would be nice to fix basically. And that could be as part of the post-working group last call processing, I think. Or during, even.
Jonathan Hui: Yeah, I mean, anything that we, any changes that we make to the document at this point, we should, you know, those should be cycled in as part of the last call.
Esko Dijk: Yes, that's good.
Jonathan Hui: And I don't know, does the whole working group get the GitHub discussion, or is that, do you have to have subscribed to the thing?
Darren Dukes: Uh, I believe that the working group, oh, GitHub discussions. Um, we see the issues, we see what's closed. I'd have to go look in the mail and see what's actually dumped under the discussions in those issues.
Jonathan Hui: Yeah, the reason I ask is because at this point, any discussions that we have on the Data Tracker, sorry, on GitHub, probably ought to just occur on the mailing list.
Esko Dijk: Yes, they're not copied to the mailing list, sorry. The only thing you will get is the summary email, so who created what and who updated what. It's a weekly summary.
Jonathan Hui: Yeah, then maybe we should try to have the issue discussions on the mailing list just so that we don't shut people out, because at this point we kind of want there to be activity on the mailing list so that people are paying attention.
Esko Dijk: Yeah, okay. It's good.
Darren Dukes: Okay, I'm just closing down some windows so that I keep things sane here before I start sharing. Be a moment. Hope I don't close down our window. All right, now I think you guys can see the issue list. Is that correct?
Jonathan Hui: All right.
Darren Dukes: I'm going to kind of work from the bottom up here. Skeletons. So we're going to leave the state machine. Our document plus one. Selection of the best DHCPD. All right, shall I just go through one at a time?
Jonathan Hui: Sure. Um, I will say that's a bit illegible. It might be good to make the screen a little bigger, or the font a little bigger.
Darren Dukes: Yep, I could do that. How are we now?
Jonathan Hui: Slightly better. Yeah, it's like really blurry.
Darren Dukes: Oh. I'm not sure if it's just the way that your screen is being captured, or what. Maybe it will clarify itself momentarily.
Esko Dijk: Yeah, now it's getting more clear, yeah. If you don't scroll.
Darren Dukes: Yeah, it, okay, that is this tool, unfortunately. Doesn't do good with movement. Let's open up a few of these. Okay, Selection of best DHCPv6-PD prefix. Is that legible?
Jonathan Hui: No, it looks like I'm not wearing my right glasses.
Esko Dijk: Yeah, it's blurry, man. Maybe just need to do a local open of the issue.
Darren Dukes: Okay, this is issue number 99.
Esko Dijk: Yeah, maybe just add to that that there is text in the current draft for the selection of the prefix, so there's even a preference indicated. So if the stub network supports multiple prefixes, then basically two are requested, so one GUA and one ULA. And then both are basically used on the network. And if there needs to be selection, then there are some selection rules like the one that's valid for the longest time is selected. I think Ted did have a comment there. It seems like we are not fully done with the topic yet.
Jonathan Hui: Yeah, so. I'd have to look at the text. Let's see. For some reason I keep losing the issue. I don't know why that's happening, but. Okay, so. Right. Okay, so. So I see what, so I'm looking at my comment here. I don't know what the text currently is. Let's see.
Esko Dijk: Yeah, just to add, there is also text now that basically forbids operation under multi-AIL. So I added that in the last minute. So that means the stub network technology needs to have a way to detect that multi-AIL, and if if there's already one AIL in use, then the snack router is not supposed to add a second one or must not add a second one.
Jonathan Hui: That seems like detecting it's easy, right? Sorry, you just look at, you look at the RA from the stub router that's already advertising and see what routes it's advertising. And if they don't match what you see on your AIL, then obviously it's on a different AIL.
Esko Dijk: Well, don't think it's that easy, because yeah, that could be a different per technology. If you have a mesh network, it could be multiple mesh hops away for the other AIL, so you need something more clever, I think. Like in the thread case, for example, it's not looking at RAs, but at the thread network data, for example.
Jonathan Hui: Right. So, so in the thread case, that kind of lands in our usual like we can't, if you're using a non-RA technology, that's out of scope. Right. In the thread case, yeah, the thread spec has to say how to solve this problem. We can't explain how to do that in the snack document. But for the RA case...
Esko Dijk: In any case, I did add the requirement there that we need to basically exclude multi-AIL from the scope. So I'm not sure if that has influence on this item that we are discussing now, because I see there that you have an example of, okay, one snack router connects to a very good AIL, and the other one connects to let's say a bad AIL and can't get the prefix delegation. Don't think we need to consider that. This is more like suppose we have two snack routers and one manages to get the GUA and the other one only manages to get a ULA basically. I think you said that the GUA one has the preference.
Jonathan Hui: Yeah. Yeah, so basically if you see a ULA advertised, then it makes sense to do DHCPv6-PD and if you get a GUA, then you should advertise it as the OSR prefix and then the ULA would be withdrawn. If you just get another ULA, then you probably just release it and don't do anything.
Esko Dijk: Well, you don't need to release it, I think, because you can beforehand, I think, you can see the prefix and then also the type of prefix before making the actual delegation request.
Jonathan Hui: Oh, so right, you do a discover, sorry, a solicit, and you get back an offer, and then you can see that the offer is not going to help, and so you stop at that point.
Esko Dijk: Right, yeah, that's how we've written now, so that you basically select before doing the actual delegation.
Jonathan Hui: Right. Yeah. I mean, right now the API that I'm using to do DHCP on tvOS doesn't actually allow you to do this. You basically just say give me an address, and it gives you an address, and you can then release it, but you can't, but you're right. I mean, in principle, and we don't need to get specific about that. The main point is just like if you get a ULA prefix, that's not better, so don't publish it.
Jonathan Hui: Yeah.
Jonathan Hui: I thought the situation was more about when you have multiple border routers and you don't want them all requesting a GUA, you know, a different GUA, right? Because you don't want to exhaust the infrastructure pool.
Jonathan Hui: Yeah.
Jonathan Hui: So the current text, let's see. The current text I'm looking at, doesn't talk about that at all, I don't think.
Jonathan Hui: Yeah, so. DHCP prefix delegation is available, then snack must attempt to acquire prefix provided by infrastructure, so. Okay, so that's just the GUA plus ULA versus GUA only thing.
Jonathan Hui: Yeah. So we already have text in here that talks about looking at the advertise message. So yeah, I think that we just need to add a paragraph and I can maybe propose one that talks about this case.
Esko Dijk: Yeah, that's, that would be a new functionality in a way, because right now, I think when there is already a, let's say, an OSR prefix, then the snack router would not even try to do prefix delegation, I think, right?
Jonathan Hui: Mm-hmm.
Esko Dijk: So that would be new, sort of a new behavior, that you look like, oh, I can get something better, so let's do that.
Ted Lemon: Well, so, so we start off by saying if the DHCPv6 prefix delegation and IPv6 servers are both available, snack router must attempt to acquire a prefix. Using a prefix provided by infrastructure DHCP means routing works, etc. By contrast, must request 64 bits. Let's see. 64. Okay. Then there's the multiple ones, then there's the timeout lifetime, no, so we don't actually say anything about what to do if there's already a prefix advertised. Or if there's multiple being advertised, right?
Jonathan Hui: Yeah. Well, I mean, the only reason that we would. Oh, right, so yeah, we actually need more text than this. So also, when a GUA is present, is already being advertised on the stub network, any stub router that is not the one advertising it must not attempt DHCPv6 prefix delegation or if it had already acquired a delegated prefix before seeing the other GUA prefix advertised, must release the prefix it acquired. Uh, let's see what else needs to be said here. If two GUAs are being advertised at the same time because of a timing race, the GUA prefix that is numerically lower should be withdrawn by sending a new RA with a valid and preferred lifetime of zero for that prefix. Um, for stub network technologies that do not use router advertisements, the way that this is handled is specific to that technology and out of scope for this document. So I just added a comment with those three additional paragraphs. So I don't know, does anybody see any gaps remaining there?
Esko Dijk: Yeah, maybe it will come, but I need to have a look at it. I think you said numerically something with lower or higher and there was already text basically for the ULAs. It's basically the numerically lower one is the winning one. In section, let me see, 6.1.2.4. Has that? So that's numerically lower wins. And also indeed the last appendix. It's also the numerically, the final paragraph of the whole text says numerically lowest wins.
Jonathan Hui: I think we went with lower because that means GUAs naturally win over ULAs.
Ted Lemon: Oh, good point. Yeah, so. So I just changed the text, so now it says if two GUAs are, two or more, let's say two or more, GUAs are being advertised at the same time because of a timing race, any such GUA prefix other than the one that is numerically lower, lowest, should be withdrawn by sending a new RA with a valid and preferred lifetime of zero for that prefix. Does that solve it?
Esko Dijk: Um, yeah, I'm not sure what what exactly your, it's difficult to visualize what you exactly have, but there can be multiple OSR prefixes, right? So you shouldn't just withdraw if something is lower. It's allowed to have multiple if the stub network supports that.
Jonathan Hui: So what's the use case where we would want to advertise two prefixes?
Esko Dijk: Yeah, we did have the use case of having one GUA and one ULA, that's explicitly supported now.
Jonathan Hui: Okay, that's valid.
Esko Dijk: And that's done, at the moment that's done by a single snack router who basically sees like, hey, there are two available, so it will basically publish two prefixes then if both work.
Jonathan Hui: Right, so this, the only problem with that approach is that what that means is that now if we have a stub router that comes along and gets a GUA prefix but there's already a ULA prefix advertised, then now we have to have the stub router that's advertising the ULA prefix withdraw its prefix to replace it with a different prefix that would be advertised by the router that's got the GUA prefix. So I don't know if we really want to do that. Maybe we should just treat them as independent. Like if there's already, well. Yeah, so. All right, actually, so, so here's some more complexity. Suppose that we have multiple links, multiple AILs. Not because they're supported, but that's just what happened. One of the AILs has IPv4 only, the other AIL has IPv6. So the first router that showed up was the one attached to the IPv4 AIL. So what it's going to publish is a ULA prefix that it generated, which is not routable. Now the other snack router comes along and it's got, it gets an IPv6 prefix that is routable, a GUA prefix and a ULA prefix that is routable. So here we actually do want the prefix that was being advertised to be withdrawn, or the alternative is we say, okay, we already have a working network, so like there's already a working AIL, so we shouldn't break that, and therefore this other information on the AIL with IPv6 can't be published at all. So those are kind of our two choices, I think.
Esko Dijk: Yep, so yeah, the last one is what I added in in the last minute about, it was just because it was the simplest thing, of course, for the multi-AIL problem, so that's kind of the simplest solution.
Jonathan Hui: Yeah. Yeah, I think you're right. It would be nice to be able to make it so that we never thrash the network, but. So for the case, I guess, I guess for the case where a router is publishing only a ULA and it sees a GUA, it doesn't really have to flash renumber. It could just say, look, you know, you can keep using this ULA but there's that other ULA, and so in other words, basically just not renew it, not not extend it.
Darren Dukes: Yeah, is this even within the scope of this document, though? Like.
Jonathan Hui: So, we don't have any control over what the user does, right? Like, the user, when we say that multiple AILs aren't supported, what we mean is we don't solve that problem, not, not you can't accidentally do that or intentionally do that. So then the question is when multiple AILs show up, we don't, we don't have a way to support two AILs at once. And now we could just say, you know what, if you connect to two AILs then you made a mistake and you're on your own.
Darren Dukes: Ted, I'm just going to interrupt.
Ted Lemon: Yeah.
Darren Dukes: I'll just say for the purpose of this specification, we do not need to solve all of the problems at this point, and we can leave other problems to be solved in other documents. Um, so, you know, if if we can if we can't come to a conclusion on what should be done in this scenario, um, should we should we consider, um, you know, leaving it for future work? Right.
Jonathan Hui: So what what I'm getting at is there's actually two different ways to approach this. One is to say if the user does this, connects to two AILs, it's not supported and it's broken and and the and they've just broken their network and it stops working. That's one option. The other option is we detect that that occurred, we don't have a way to make both AILs work, so we try to only connect we only support a single AIL and the other one just is just out in the weeds. Um, so those are our two choices. And the question is do we want to do the small I think small amount of extra work to just have one AIL that's working and the other one is out in the weeds, or is that a sufficiently broken scenario anyway? Is that sufficiently violating the user's expectations that we're actually not really making things better by doing that?
Esko Dijk: Well, I thought it was good to at least have the detection, so if there's already an AIL there, it's detected, then don't do the second one and the third one and no matter how bad the first one is, so the first one just wins. And that's kind of the simplest thing you can do.
Jonathan Hui: Yeah.
Esko Dijk: And that's better than I thought it was better than not doing anything at all, which is if you don't do anything at all it you get a half-working, yeah, half-working discoverability and reachability and sometimes it's not working, sometimes half. And that that's even worse than I think, but okay, that's my opinion.
Jonathan Hui: Yeah, so the reason that we get the the half-working discoverability is because we can only have basic we don't want to have two SRP servers on two different AILs, each of which has half of the information.
Esko Dijk: Yeah, and the client doesn't doesn't know where to query also, so yeah, that's extremely complex. Won't work. But I think this discussion is anyway completely separate from from this issue. So suppose you have a single AIL and you have a device that already has a ULA OSR prefix happily announced and then somebody discovers, "Hey, I can get a GUA with prefix delegation." So we actually we do not currently foresee that case. So we only foresee the case where a single device detects, "Hey, I can get ULA and a GUA," and then makes a decision.
Jonathan Hui: Yeah. So, so as you explain this, I'm kind of leaning towards the point that Darren was making, which is, actually, if we already have an OSR prefix on, and and this is this is like just like this is a "should" behavior, right? It's okay if somebody does better than this. Like right now I think on Thread we would do better than this, but but sort of the basic functionality here is if we already have an OSR prefix, then nobody should be trying to override that that existing prefix. Right?
Esko Dijk: Yes, that's kind of the basic behavior, I think what we want.
Jonathan Hui: Yeah. Now the other thing though, yeah, is that the SRP server and the router that's advertising the OSR prefix really should be the same really should be connected to the same AIL. So, yeah, if we want to solve the multi-AIL problem at all, it's hard and there's no getting around that. And so, I mean, I'm somewhat inclined to say that it's just like you know, you know, I'm starting to really agree with Darren here that it's just out of scope. Like we just can't really specify that. Like we know how to do it in Thread because Thread is a sort of a special little flower, but this is um, this is a more general document and I don't think we have a general solution to this problem. So I think we should just not try to specify. Basically, if you if you connect to multiple multiple AILs you just lose and and we aren't really going to be able to ameliorate that. There we might be able to try, but it's probably not going to help. Like you just you just can't make that work. I mean, what we could do is we could say, "You should detect that this has happened and warn the user," because that would be nice for the user. "Oh, yeah, I shouldn't connect two AILs," but I think that's the best we can do.
Darren Dukes: Yeah. But remember we're not writing a user, we're not writing a a user's guide or product specification, right? We're simply saying what we what we need to spec.
Jonathan Hui: Sure. Yeah, I mean we could just, we could just point out like somewhere in the document like um, it doesn't really work to connect multiple snack routers to different AILs under this specification, and if you do that the user is probably going to experience weird behaviors, so you might want to think about how you're going to tell the user about this.
Darren Dukes: Yeah, or or just say it's undefined in this, you know, not defined in this specification, it's out of scope.
Jonathan Hui: Yeah. But I think it's I think it's worth giving implementers some advice about what to do here. Like don't just don't just say, "Yeah, it doesn't work," because, you know, yeah, it doesn't work, but but I think it's worth saying, "If you can, surface this somehow."
Darren Dukes: Okay. You know, so the the reason, so thinking about what happens later on, if you say more, if you say it's out of scope, then it's out of scope, don't talk about it. Talk about it in another document. If you say it's out of scope and then you go and talk about it, you have to do a bis of this document to remove the things that you talked about because the other document's going to going to conflict with it, and so why are we talking about things that we're saying are out of scope? So that's just from a just from a process point of view, let's let's keep that in mind as you're writing the text. Okay.
Jonathan Hui: I hear you. But what I'm saying is you can say this document, if you if you if you have a configuration as defined in this document, and you have multiple snack routers connected to multiple AILs, this document doesn't support that. That's out of scope for this document. If all you implement is this document, then you might want to tell the user that this situation has occurred so that they can do something about it. However, if another document comes along and says how to solve the problem, then we don't have that issue. Comply with that one. Um. But, yeah. So we just need to say it in such a way that we're not imposing requirements on the bis document, basically, or on the on the snack complex document. Right.
Esko Dijk: Okay, um, maybe I did have one thing that comes out of this issue that was one small detail basically. So currently the document says that the snack router must do the DHCPv6 delegation and only the title of the section says "to provide addressability," so why it's doing that. But the text itself doesn't say that it's conditional. It only says you must do DHCPv6 period. So even if you have no use for the prefix, still must do it. I think that's maybe the thing to be fixed. So only if it's needed to provide this OSR prefix, you have to do it and otherwise you could just totally skip it, right? So don't delegate anything. At least that's how I see it. Um, at least you can do it if you want, but it's not not mandatory at least to to pre-fetch the prefixes with PD.
Jonathan Hui: Well, it's actually probably you probably shouldn't because it'll waste...
Esko Dijk: Yeah, maybe not. Like if there are 20 snack routers, then that's a high load on the prefix space, of course. Yeah. So maybe that's just something to clarify and then that would resolve it. But yeah, in you could say the simplest form of selection we already have in the draft now, and it seems okay to leave leave it at that. Um. Although then maybe clarifying the delegation part, that you don't delegate a prefix if you don't need it.
Ted Lemon: Yeah.
Esko Dijk: Okay, I see Éric also joined meanwhile, so maybe he has something to say about the details.
Éric Vyncke: I think this is a good outcome for this issue, so maybe we can move to the next. And Esko just, yeah, I'm just joined about 10 minutes ago and I'll be leaving in 20 minutes. Um, yeah, and to come back on the previous point, let's keep it simple, right? So that's the only way to move forward, even if we need to do a bis later. Yep.
Darren Dukes: Okay. Okay. So you have moved on to clarify intro add motivation. And by the way, on this specific point, I don't know the text in the draft itself, but when I introduce what I'm doing with snack as an AD, I typically say a 15.4 a either 64-bit or 16-bit addresses, so you cannot bridge into the 48-bit MAC addresses of the typical Wi-Fi. And for me, this is one of the killing arguments. So it's very simple to understand. So maybe it's already in the text, I don't know, but this is, I think, really key.
Jonathan Hui: Yeah, so we list incompatible speed, incompatible media, so we do talk about these things. I think incompatible media is the one that you were talking about, Éric. So that's bullet point two based on the MAC address.
Éric Vyncke: Yeah, but the point that the point is that think of incompatible media, you can bridge, right? Between some incompatible MAC layers, you can bridge, like for instance Wi-Fi and Ethernet, right? So you can bridge. Right, but they're not incompatible. I mean, they they have the same the same. Yeah, the incompatible in the case of layer 2 IEEE layer 2 is fuzzy, right? Yeah.
Jonathan Hui: So the thing that that I think we called out here is that, which is not in the currently in the introduction, is that when we talk about connecting the networks together, what we really mean is bridging them together. Oh well, no, so we do say cannot be easily bridged to a Wi-Fi network. Wow. Okay, so I'm actually looking at the second item here, incompatible media, for example, a constrained 802.15.4 network connected as a stub network to the Wi-Fi or Ethernet infrastructure network. In this, in the case of an 802.15.4 network, it is quite possible that the devices used to link the infrastructure network to the stub network will not be conceived by the end user as routers. Consequently, one cannot assume that these devices will be on all the time. A solution for this use case will require some sort of commissioning process for stub routers and can't assume that any particular stub router will always be available. Rather, any stub router that is available must be able to adapt to the current conditions. Yeah, that's very wordy. I mean, it actually does make sense, but it's actually not the point that you were making, Éric. Correct. Yep. It's in fact this this paragraph is a little incoherent. It's actually making two points. It starts off making the point you were making, Éric, and then it wanders off in a completely different direction. This "consequently" bit is I think ought to be... yeah. Yeah, so I think there's actually, yeah, that needs to be split into two different bullet points. Hang on a second. Let's see.
Esko Dijk: Yeah, I think the main point of the review was, well, we have the internet, which is already connecting multiple link types and multiple speeds and it does the job great, so why do we need this new thing to do the same?
Darren Dukes: Right, so what's your point?
Jonathan Hui: Okay, so um, I'm going to just do a quick pull request for this because I think that it's fairly obvious what to do here. That sounds good. Okay, so the second the third bullet item will now be "inconsistent availability of individual routers" and then basically that text that I just quoted will now be the rest of that and so "incompatible media" in this situation, it's not possible to use sorry, in this situation the bridging between the two media is not possible because the layer two framing and addressing is incompatible. So that makes this much more understandable and I think addresses the point here. So let's call this intro bridging clarification.
Darren Dukes: Okay. And what was the issue? Was this number 99? 101. 101. Okay, so I just created a pull request, so. Great. Yep, so that should address that issue. Um, we can either review that and approve it now or move on as you as you prefer. Yep, so this discussion will go to the list anyway, so um, you know, you're welcome, we can you can definitely approve it now and get the commit in and um, you know, if there's any discussion on the list that changes it, it can change, but otherwise it can remain as it's committed. Okay.
Jonathan Hui: All right, does somebody else want to do that or?
Darren Dukes: Yeah, I'll I'll hit the approve button.
Jonathan Hui: Okay. I just had one nit. Instead of the period, it's a to be consistent with the rest of the list items, colon. Oh! Just minor. Oh, yeah, yeah, you're right. Hang on a sec, I'll fix that. Have you have you already committed it? You can click his "commit suggestion" on the if you refresh your pull request view. Oh, you you added a suggestion? Jonathan did, yes. Uh-huh. Apply suggestion. All right. It is done.
Darren Dukes: Okay. That's 101 closed.
Jonathan Hui: All right, did you merge it?
Darren Dukes: Uh, you being who? Ted?
Jonathan Hui: Oh, I was talking to you.
Darren Dukes: Yeah, just approved.
Jonathan Hui: Okay. I'll do the I'll squash and merge. Might as well hit the merge. Yep. Okay. Great. So that should mean that 101 goes away. It is. Excellent. All right. What's next? 107. Okay. Router unreachability detection. Okay, so for each snack suitable route, the snack router must monitor the state of dot dot dot. Must monitor the state of reachability to the routers that advertised it as described blah blah blah. So, yeah, I guess I don't understand the comment. It's asking where is it recorded? Well, in the question is is it recorded in the way as is discussed in this RFC and the draft?
Éric Vyncke: Is it still a Fernando point in the draft or does it move forward?
Jonathan Hui: I don't remember what happened with this one. Let's see. So there's an 01. I'll see it in the video, I guess, right? Yeah, it's still individual. Okay, so I guess um, this doesn't really seem like it's actually a good question. I was about to say the same thing. Ignore. Yeah. Yeah, no consensus on the IPv6 ops draft, right? Yeah. Will be addressed later. Yeah, I mean, I think, you know, is the expectation that you record information as discussed in 8028? I mean, you know, people have done implementations of ND already and they record the information however they choose to record it and it's not really our place to tell them. So I would say no. Agree. Yeah. Yep.
Darren Dukes: Yeah, I was just reading the draft. I think the the draft was basically saying, "Record the state per router and do things like source address selection based on the next-hop router." Yeah, which, you know, I mean, that's the way I implemented it, personally. I don't know how it's implemented in OpenThread, but um, it doesn't seem like we have to specify this. Just find a nice way to close the the issue. I mean, nice wording that closed the issue and do nothing basically.
Esko Dijk: Okay, then can move to the next one, I think.
Jonathan Hui: Okay, so I just wrote "This doesn't seem necessary to specify this much detail. The implementation will have to do something and what is said in the reference document, being nice, is in fact what my implementation does, but it doesn't have to be done that way." Yeah, even the later part you can remove it, but it's up to you. Yeah. Okay. I'm just going to close it with that comment then. All right. So router, okay. What's next? 109. Actually, I think I read this here, but sorry, I read that it's already specified that it joins these both addresses, but the comment might be that it also has to do it on the other interface, so I think it has it for the AIL interface already specified. I'm not sure if the what this comment was about which which section, which, yeah, interface on the AIL. It says here, okay. Yeah. So I think it already was specified, right? So for the AIL we have the addresses listed, like or maybe that's another all routers is already there, I think somewhere.
Éric Vyncke: But Esko, I like the comment you put there, are referring purely to router behavior, because if we need to refine in snack-simple what a router needs to do, we are never finished, right?
Ted Lemon: Yeah, so the title The title of the section is "Maintenance of addressability on AIL and stub network links." As part and the paragraph says, "As part of the standard IPv6 router behavior on the AIL interface, the snack router must join, etc., etc." Right. Um. So, yeah, we should definitely say um, we should just add some text here that says if let's see. Uh. So the text should say um, so must join uh. Period. If um, neighbor discovery including router advertisements is being used on the stub network, uh, a snack router must similarly join these two multicast groups on the stub network interface as well. So that's my proposal. Oh wait. Okay. I see Darren is currently sharing. Yep. Okay. Gentlemen, I need to leave to go to my IESG telechat. Um, as you know, right, the working group last call is ongoing, so Darren, if you can ask on the list for more feedback once this I mean, all the PR are merged and are um, I mean, the discussion of today are done and PR merged and submitted. Um, so we can. Okay, I mean yes, so thing thing good. I'll I'll ask for feedback on based on the current document and um, these pull requests um need to go into the list as kind of additional feedback, right? with with some description to the list so people know that they're coming in, they're changes that are going to be made to the document they're currently reviewing um and the the reason why. All right, so that's how we'll move these forward.
Éric Vyncke: Yeah, the only thing I wonder, I mean, besides Michael Richardson, right? who is fluent in Git and go will go through all the PR rather than reading a document, because what we need right now in the working group last call is acceptance or comment on the complete document, not really on the change in the PR. Exactly. Yep. Exactly. Yep. Uh, I I would prefer a merged document and submitted document. Uh, let's say we still have until the 15th of May, right? So okay.
Darren Dukes: So so is your suggestion that we just do that we just release a dash 10 with whatever changes we come up with and ask people to review those changes?
Éric Vyncke: Yeah, I mean, as long as the three authors, right? and and Darren who's also quite involved into the discussion agree with all the proposed PR, merge everything and submit. Because I mean, people will read the complete draft. I mean, for reading a PR alone, right? you need to be an author. Yeah. Yeah. Okay. Okay, and thanks for your time and thanks for organization and thanks for waking up so early, Jonathan. Bye-bye. Bye. Bye.
Ted Lemon: Yeah, that's right, Darren, your energy auditor's up early too.
Darren Dukes: Pardon me? Sorry.
Jonathan Hui: Oh, no, you're not on the you're not on the west coast, so you didn't wake up at Jonathan. Jonathan is our early bird here. Yeah.
Jonathan Hui: Okay, well, much appreciated. Okay, so I added a um, a new pull request which uh makes the change that we that seems necessary here. Um, however, I have to say that that document that whole section probably needs to be um looked at with the same idea in mind. So this this only solves that one issue. Um, but um when I originally wrote that text, um, I was really only thinking about the AIL and so the text is somewhat AIL-specific and it actually applies just as well to the stub network if the stub network is using router advertisements.
Esko Dijk: Okay, that seems good to add.
Jonathan Hui: All right. Do you want to merge it, Esko, if you like it okay?
Esko Dijk: Yeah, can do that. Okay, it's now busy merging, it seems. Great. That's done.
Jonathan Hui: All right, so. So I was just looking at issue 110, "leverage the slack spec for existing requirements." Um. And, uh, the point there is that um we're actually using that list to determine something other than what routers are available. So it kind of does make sense to actually be explicit about it even though I think the point that you were making there, Esko, is completely valid. I don't think it does any harm to be explicit and we're not actually doing slack, so we're not actually superseding what the slack spec says.
Esko Dijk: Yeah, that was not my comment by the way.
Jonathan Hui: Oh, was it not? Oh, this was from uh Panomo. Oh, okay. Yeah. All right, so.
Esko Dijk: Yeah, maybe just now we are looking at this specific piece of text, so this is about RAs to be excluded. I was reviewing the whole document now and I wanted to add another exclusion thing there, so that's basically the RAs that are stale also need to be excluded. It doesn't say that yet.
Jonathan Hui: RAs that are stale.
Esko Dijk: Yeah, so that were longer than the stale RA stale lifetime that we defined to be 10 minutes in system.
Jonathan Hui: Right. Yeah. Oh, okay. So this is this is for choosing the the suitable prefix, right?
Esko Dijk: Uh well it was about recent RA was about choosing the flag bit values for the M flag and the O flag. My idea was if you haven't seen or you haven't seen that router for for 10 minutes then you don't copy their M and O flag values anymore.
Jonathan Hui: Right. Sure. I mean, didn't I sort of vaguely thought that we had concluded that there wasn't really a good solution to the M and O bits and that that implementations don't actually assume that they're all going to be the same anyway, so maybe we don't have to do this?
Esko Dijk: Yeah, I think the the end result was in the text was that we had a sort of simple fallback, so that you just copy it from the most recent non-snack router that you seen, but uh after a certain age you basically will forget that again, so if if they're not recent then you ignore it.
Jonathan Hui: Right. Yeah, the reason that I'm now pushing back on this is that that actually seems like it's not necessarily a great approach. Like we could say use whatever bits we most recently saw in an RA as long as that RA has not expired.
Esko Dijk: Yeah, but that's basically what the text tries to say now, right?
Jonathan Hui: Correct. And the reason that that that that makes sense is because what we're doing here is just a stupid hack anyway. Like it would it would be equally valid to say just set them to zero always. And I might prefer that. But if we're going to set them to something, um, then what it makes the most sense to set them to is the most recently heard RA and it probably doesn't um like the thing about the M and O bits is suppose we set the M and the O bits and there's no DHCP server. The effect of that is that there's going to be some additional multicast traffic that's useless. So it's good not to set the bits if we don't have to. But to some extent, like if we see the M and the O bits set at some point on the link, then it's reasonable to say that for the duration of the lifetime of that advertisement it's okay to continue to set the M and the O bits because, you know, those bits were set because the thing that advertised that thought there was a DHCPv6 server reachable and that it was able to do these functions. So then it doesn't really like being finicky about like whether it's stale or not doesn't actually make sense because this is not really about that. This is not we're not talking about a suitable prefix here, we're talking about just what value to basically whether we should try and override what the network said. And I think the answer is no, we shouldn't. Like if we're if we're trying as hard as we are here to um to represent in our M and O bits what the infrastructure is setting the M and O bits to, then it doesn't make sense let's say that the stale lifetime is 10 minutes. It doesn't make sense that before 10 minutes we set them one way and after 10 minutes we set them the other. It's like that's just kind of not our business. We should just set them to whatever we last saw. Does that I mean.
Esko Dijk: Yeah, case. Sorry, I think some audio dropped out. Ted dropped out. I don't hear anyone.
Darren Dukes: I'm here.
Esko Dijk: Oh, you're here.
Darren Dukes: Yeah, Ted just disappeared. Looks like he's back.
Ted Lemon: So while I was monologuing, my connection went away, so I don't know what you guys heard.
Esko Dijk: No, nothing basically. Yeah, you were kind of cut off. You were thinking going to ask does it make sense...
Jonathan Hui: And if you're talking, I can't hear you.
Esko Dijk: Oh, okay. Oops. Well, I'm talking now, but. We should just open the chat window just to monitor. Let's say... audio is unidirectional. Right. Interesting. Okay, all right.
Ted Lemon: Okay, I can hear you again, Darren.
Darren Dukes: Great.
Ted Lemon: Yeah. Sorry about that. I just had to reload the window. So hopefully it won't glitch out again. But anyway, so so what was the do you guys disagree horribly with what I was getting at there, or are we okay?
Esko Dijk: No, well, I think I got the main message. So the 10 minutes that that I was thinking about is maybe not not a good idea because...
Jonathan Hui: Yeah, it's just not related to to the use that we're making of the bits here.
Esko Dijk: Yeah, the the only thing was the current text does say that at some point, I didn't look at exactly how that is formulated, it looks a bit complex, but at some point it needs to time out. So it's not like an eternal repetition of the last setting.
Jonathan Hui: Right. Yeah, so I mean, I think uh if I remember correctly. Let's see. Uh. So this is in 5.1.2.3. No, wait. 6.1.2.3 now? Yeah, just basically the bullet point in 6.1.2.3. So we have uh based on the router lifetime in the RA header. So that this is something that's only for default routers. Yeah. Okay. So in this state, snack router generates its own prefix, blah, blah, blah, the snack must uh be set to the RA the snack router flag bits the values of the M and O bits must be copied from the respective of the most recent RA received from a non-snack router. Um. For the selection of the most recent RA, the following RAs must be excluded: any RA received from a router longer ago than the router lifetime period indicated in the RA header. Yeah. So this is basically uh yeah, it only excludes routers, default routers that have expired their role as a default router. Right. So basically what it's saying is keep using whatever the most recent RA you got was until either you get a newer one or it times out because the lifetime expired. Yeah, which is yeah, I think is correct. Good enough, okay.
Esko Dijk: Yeah, now I think the other the remark that we were discussing, the review remark was something like isn't that already defined uh as part of slack, I think? Slack.
Ted Lemon: Yeah. It's defined as part of part of the neighbor discovery document, but what we're talking about here is specific behavior that's not described in the neighbor discovery document, so I think it pays to be specific. Because otherwise, like if we just said the most recently received router advertisement, that might have been received three days ago. It might have expired two days ago. So so we need to not just keep using it forever. And and so and the fact that the slack document or the fact that the neighbor discovery document uh says that it's expired doesn't actually clarify that unless we say so explicitly. So I think we do need to say it explicitly here.
Esko Dijk: Yeah, so the copying is our unique behavior basically for the snack router, so we'd better define it define it there. Yeah, okay.
Jonathan Hui: Okay, so I'm just going to add a comment here and close it. This section is describing specific behavior not covered by slack. If we did not say this here, um it could be valid read as requiring M and O bits from expired RAs to be copied into the M and O bits of the snack router RA. Okay, so we can close that one. Yay! All right. So router, okay. What's next? 109. Actually I think I read this here, but sorry, I read that it's already specified that it joins these both addresses, but the comment might be that it also has to do it on the other interface, so I think it has it for the AIL interface already specified. Mm-hmm. I'm not sure if the what this comment was about which which section, which, yeah, interface on the AIL. It says here, okay. Yeah. I think it already was specified, right? So for the AIL we have the addresses listed, like or maybe that's another all routers is already there, I think somewhere.
Éric Vyncke: But Esko, I like the comment you put there are referring purely to router behavior, because if we need to refine in snack-simple what a router needs to do, we are never finished, right?
Jonathan Hui: Yeah, so the title of the section is "Maintenance of addressability on AIL and stub network links." As part and the paragraph says, "As part of the standard IPv6 router behavior on the AIL interface, the snack router must join, etc., etc." Right. Um. So, yeah, we should definitely say um, we should just add some text here that says if let's see. Uh. So the text should say um, so must join uh. Period. If um, neighbor discovery including router advertisements is being used on the stub network, uh, a snack router must similarly join these two multicast groups on the stub network interface as well. So that's my proposal. Oh wait. Okay. I see Darren is currently sharing. Yep. Okay. Gentlemen, I need to leave to go to my IESG telechat. Um, as you know, right, the working group last call is ongoing, so Darren, if you can ask on the list for more feedback once this I mean, all the PR are merged and are um, I mean, the discussion of today are done and PR merged and submitted. Um, so we can. Okay, I mean yes, so thing thing good. I'll I'll ask for feedback on based on the current document and um, these pull requests um need to go into the list as kind of additional feedback, right? with with some description to the list so people know that they're coming in, they're changes that are going to be made to the document they're currently reviewing um and the the reason why. All right, so that's how we'll move these forward.
Éric Vyncke: Yeah, the only thing I wonder, I mean, besides Michael Richardson, right? who is fluent in Git and go will go through all the PR rather than reading a document, because what we need right now in the working group last call is acceptance or comment on the complete document, not really on the change in the PR. Exactly. Yep. Exactly. Yep. Uh, I I would prefer a merged document and submitted document. Uh, let's say we still have until the 15th of May, right? So okay.
Darren Dukes: Okay, and thanks for your time and thanks for organization and thanks for waking up so early, Jonathan. Bye-bye. Bye. Bye.
Ted Lemon: Yeah, that's right, Darren, your energy auditor's up early too.
Darren Dukes: Pardon me? Sorry.
Jonathan Hui: Oh, no, you're not on the you're not on the west coast, so you didn't wake up at Jonathan. Jonathan is our early bird here. Yeah. Okay, well, much appreciated. Okay, so I added a um, a new pull request which uh makes the change that we that seems necessary here. Um, however, I have to say that that document that whole section probably needs to be um looked at with the same idea in mind. So this this only solves that one issue. Um, but um when I originally wrote that text, um, I was really only thinking about the AIL and so the text is somewhat AIL-specific and it actually applies just as well to the stub network if the stub network is using router advertisements.
Esko Dijk: Okay, that seems good to add.
Ted Lemon: All right. Do you want to merge it, Esko, if you like it okay?
Esko Dijk: Yeah, can do that. Okay, it's now busy merging, it seems. Great. That's done.
Ted Lemon: All right. So, well, we definitely made this list smaller, so that's really good. Um, let's see. So there's this "multiple AILs as default routes" thing that's open and we had a long discussion about it, but we ultimately concluded that we aren't doing multiple AILs. So, well, that was a really long discussion.
Esko Dijk: Well, that was the issue like even if we really don't want to do multi-AILs, you still need to do a minimal something, let's say low-hanging fruit, let's say, to to avoid the solution kind of crashing in that case.
Ted Lemon: So I think what we just discussed though was in fact even that is like really actually quite hard and and wouldn't accomplish much.
Esko Dijk: Well, I don't think it's hard in a way, but um in any case, maybe a reminder again that I've added a new text paragraph exactly on this. So basically a "must" requirement to prevent multi-AIL from occurring in the first place, and it's basically a requirement pushed upon the stub network technology basically to figure out how to do that, how to enforce that. Um. So it could be Wi-Fi, Ethernet or Thread needs to figure out how to do that, how to enforce that. Um, yeah, we we could go two ways, so we say, "Oh, this is too complex or we don't know exactly how to do that, or we just make it fully out of scope." That that's also okay, but then it needs to be converted to a warning and yeah, my preference was to to still have the requirement um under the assumption that it's easy to do, maybe that needs some some evidence that it is in fact easy to do like for the Thread case or the Wi-Fi case.
Jonathan Hui: So where is the text that you're talking about? I can't find it with search.
Esko Dijk: Yeah, it's in section 5, I can maybe just look it up and then tell you where. So it's in section 5, now I have to see where in section 5 that now is. Oh, yeah, that's not 5.1 but just um before just above 5.1, so it's in section 5.0 basically. So it basically...
Ted Lemon: Yeah, so I see there's a paragraph, the last paragraph of section 5. Yep. Uh talks about this. Um, so yeah, I think that what you said in that paragraph is actually not um like we can't I there isn't a super easy way to specify that even for the um RA use case and of course it's out of scope for other things. So I think what we should we should just have a warning paragraph here that says it's possible to connect two stub routers supporting two snack routers supporting the same stub network to different AILs, that configuration is out of scope for this document and probably won't work correctly. Um. If a stub router is able to detect this situation, um it may worth it may warn the user that this situation is occurring. But if it can warn the user, couldn't it warn and disable snack router functionality just by default? That would be more clear at least and at least you don't break existing setup in that case. If you can detect it, then you might as well act on it, right? Uh. That presumes that there is a correct action to take that we could specify, and that's the problem.
Esko Dijk: Yeah, that assumes the correct action is to basically not enable itself, so. And thereby not breaking what's already there.
Ted Lemon: Yeah, but but the assumption so it wouldn't necessarily break what's already there, um because it's not going to advertise a new SRP server and it's not going to advertise um an OSR prefix. We should make sure that it's not going to. Right. Oh well I think it has to um wouldn't it basically yeah kind of operate for example the DNS resolver plus the discovery proxy uh necessarily? or do you think that's not that's not going to do that? I mean, that's the problem. Right. Like we this is this is a big can of worms. It's really easy to talk about it as if it's simple, but it's not simple. Um. So your point uh about disabling just not acting as a stub router I think is or not acting as a snack router I think is valid. Um. Assuming that the snack router is able to accurately detect that the situation is occurring, which isn't necessarily a valid assumption. Um. And so I guess I feel like it's um either either we should actually specify how to detect this situation or we should just say this can occur um and it's not supported and it's out of scope for this document. And that's about all we can really do.
Esko Dijk: Okay, yeah, the last one is definitely easier, I mean, because we probably don't want to go into details about, okay, if you are on this network, this is exactly how you detect it.
Ted Lemon: Mm-hmm. So that was the attention to avoid the that, so then it's maybe better to just have the warning part and that means it's fully out of scope what to do, so whether to shut down, warn the user. You can I think hint at "Hey, this is a great moment to warn the user," or a great moment not to do anything. Yeah, I think, yeah, I think the out-of-scope thing pretty much covers it. Like we don't actually really necessarily have the wherewithal to even suggest that they warn the user because first they would have to figure out the solution to this problem, which we haven't figured out. Yep, okay.
Jonathan Hui: Yeah, that's good. I think um but then we need some new text for this basically this section 5 paragraph um as as part of this PR we were talking about, so that's the multi-AIL PR. So that that should be the resolution then to kind of convert that into a warning, let's say, and not have the normative text for that, because it was a bit of a problem that the "must" is not really enforceable if you don't say exactly how to do it safely. Exactly. Yeah, exactly.
Ted Lemon: Okay. Now I have to interject at this point that I need a bio break. Um, and the question is Ted, actually Ted, I've I I'm sorry guys to tell you this late, but I just realized I'm going to have to sign off early in like six minutes. So um I don't think we can continue without me. Okay. All right. Let's let's call it done and I think we got a bunch of good stuff done and we'll keep at it. Great. All right, guys. Good work. All right. Bye. See you later. Thanks. Thank you. Okay. Bye, Jonathan. Thanks, Esko. Yeah, terminating meeting. Bye. Bye.