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

[00:01:12] **Carles Gomez**: Okay. Hello. Hello, everyone. Welcome to the meeting of the 6lo working group. Please make sure that you are in the right room. My name is. The other chair is. As you can see, we are both today remote. And we have our in person delegate, Alexander Belov, helping. Thank you so much. Thank you so much. And our responsible AD, Eric Vyncke, also in the room. And we have one minute taker. If I'm not mistaken, Christian, has volunteered to take minutes, so thank you so much as well. And, anyway, everyone, feel free to join the hedgehog session. You can find the link, at the end of the slide, and feel free to to contribute, make any additions, and so on. Okay. So there are a few tips for this meeting similar to the previous ITF meetings. For in person participants, please make sure that you sign into the session by using MeetEco. You may use, for instance, the on-site tool, which is available from the data tracker agenda. And, recall that you need to use MeetEco to join the queue because there's a single unified queue, which is managed directly from MeetEco. And then, blue sheets are also automatically generated from MeetEco. So, for those of you who are in the physical room, please make sure that you do join the session. Then for remote participants, just keep your audio and video off unless you are presenting. Okay. This is the note well. Recall that by participating in the ATF, you agree to follow ATF processes and policies, and the note well is a reminder of some of those policies which are on important topics such as guidelines for conduct, intellectual property rights, working group procedures, and so on. So if you haven't read the note well yet, please do so. There's a link to the text in the second line in this slide, and, also, there's the QR code that you can capture to have access to the text. So I will leave just a few seconds just in case. Okay. So then this is the agenda proposed for today. The first presentation is the usual chess introduction, which is currently in progress. This will be followed by Luigi who will present PASA and GAAO. Then I will present an update on the draft on transmission of I p v six. Sorry. She compressed packets over eight zero two dot 15 dot four networks, and that will be followed by Young one on the transmission of I p v six packets over short range optical wireless communication. And finally, Carrie Lynn will present a report on RFC 8163 bis. So this would lead to a total of forty five minutes of allocated agenda time. Is there any comment on the agenda? Okay. So if there is no point on the agenda, then this is the report of the working group documents status. We currently have five working group documents. The first two are the path aware semantic addressing, PASA for LLNs, and the generic address assignment option, GAAO for 6LoWPAN ND. For these two documents, publication has been requested, so they have been submitted to the ISG. And then our area director, Eric, has already provided the review for both documents. A result, the authors have also updated the drafts, and they are both these two documents are on the agenda, and it will be possible to discuss them later. Then there are other working documents, which are a little bit behind in the process. There is the transmission of SCHC-compressed packets over 15.4 networks, which has been updated since the last ITF. This will be presented later today. Also, there's transmission of I p v six packets over short range optical wireless communication, which, has also been updated since the last IETF and is also on the agenda. And finally, there's the transmission of I p v six over multidrop serial bus token passing MSTP networks, which is the RFC 8163 bis initiative. And this document has not been updated since the last ATF. However, the main author will provide a report on its status and related activities. So is there any comment? Any question?

[00:06:34] **Eric Vyncke**: So not really linked to the agenda or whatever, but I'm Eric Ling, the responsibility for the 6lo working group. And we need some time to rotate working group chairs. So I will after this meeting, I will select and we talk with the chair current chairs and, of course, with Laurent Toutain that Laurent Toutain will become the third chair of 6lo. So Laurent, I know that you are back home because you had to fly back home, but thank you for accepting this.

[00:07:10] **Laurent Toutain**: Thank you for for that.

[00:07:15] **Carles Gomez**: Thank you so much. Okay. So then I guess that we can proceed. If there are no other comments or questions, we can proceed to the next presentation, which will be by on the drafts, and.

[00:07:42] **Alexander Pelov**: Just a second. This is the right presentation.

[00:08:09] **Luigi Iannone**: Yeah. Okay. So a quick update first on the PASA document. Since last IETF, we spun out two revision. So the first one was as a to address an excellent review, actually, the that we received by email on the mailing list from. Okay? And later on, Eric also provided an excellent review, I have to say. So we have two updates. Concerning the the the first revision, Hong Yang review, Mostly, it was about clarification and several points. Let's say that for us, the the the the we had an idea of what it means or what is the application, so on and so forth. And, actually, when you are completely new to the document, it was not that clear. So we we did quite some modification to clarify. And the second revision, Eric's review, lots of improvement, typos, acronyms, references. We rewrote some paragraphs in also in order to improve the the clarity of the document. And the the we also we're more consistent in the use of the terminology and also on the twenty nine nineteen terminology, so to to give better directions to the implementers. Okay? So we also improved the the description of the algorithm. He also added a note about the security implication of the fact that we we use I c m p v six if there is an error. So we send back something. So security congress direction of RFC four four four three applies in this case, obviously. K? There are two things, let's say, three things that are pending. So we we submitted the last revision just when the the data tracker opened again, is IETf weeks. So, obviously, Eric was busy, so we need still to interact to finalize the the review later on. There are two points that are important, however. One is Eric said rightfully in a certain way, at the beginning of the document, we have a huge section about use cases. Is it really necessary to be so detailed and have such a huge huge sections? Yeah. It it came in a certain way historically there because at the beginning, we had another time to really clarify the application context. At this point in time, maybe we can consider move that big section as an appendix. And in the introduction, say, if you want details about the the applicability of PASA, go to the appendix. Could be an option to to in a certain way, we we'll make the document more lightweight. Only people really interested will go to the appendix. The other part is the intended status. Proposal set standard versus experimental. At At very, very, very beginning, this document was experimental. Then later on with different quarters adding and after discussion, we we changed the the intended status to proposed standard. And I have to admit every every review that we received from Eric, but also, pointed out, maybe this this kind of solution is a little bit too new to be proposed standard. And Eric pointed out the same the same point. So we have to decide whether to move back to experimental or keep it proposed standard. To be honest, I don't have a a strong feeling. If the working group agrees, we can move it back to experimental since the the the in a certain way, it is a little bit disruptive disruptive as a technology. So that's it. That's all I have to say on this document. Eric?

[00:12:32] **Eric Vyncke**: So, Eric, after my review, there is nothing bad being experimental. Not all of them are proposed standards, and it's we all agree it's kind of experimental. And I think it will go way better in the ITF last call and specifically at the IG evaluation if it's experimental. So I guess the chair we need to go or the authors we need to go on the mailing list to decide. We can make a poll here maybe. But, yeah, it must be decided by the working group. That's working group document. Right?

[00:13:08] **Luigi Iannone**: Yeah. Exactly.

[00:13:19] **Laurent Toutain**: Because, well, in changing this to experimental, this is not just changing one label. It also means that you need to describe the experiment.

[00:13:28] **Luigi Iannone**: So

[00:13:32] **Eric Vyncke**: Yeah. Oops. Indeed, when we define experimental, typically, need to define what the experiment is. Could be as simple as usually. Right? It's not always the case, but it's better if you define the experiment such as having one ex in one implementation or something like that.

[00:13:53] **Luigi Iannone**: Okay. Fair enough.

[00:13:56] **Laurent Toutain**: Yeah. I'm I'm saying that because that that is, of course, also an opportunity to indicate the way forward with this document. So if I'm reading this and and seeing how it's experimental, so what what what does that mean for me? And if you write what your experiment is, then you can explain what maybe the next

[00:14:16] **Luigi Iannone**: What the what is the intended outcome of the experiment?

[00:14:20] **Laurent Toutain**: Well, we don't know that. That's why No. The experiment.

[00:14:22] **Luigi Iannone**: That's why I say intended. Not that we I have it already, but Yeah. Where where we aim in a certain way with the experiment. Yeah.

[00:14:30] **Laurent Toutain**: I wouldn't yeah. It it depends. I I just want to say it's good to write something about how this or why and how this is experimental and what the next steps are going to be.

[00:14:43] **Luigi Iannone**: Okay. Fair enough. No problem. Good point.

[00:14:49] **Laurent Toutain**: It was a related question. Is there implementation of this solution?

[00:14:54] **Luigi Iannone**: Internally, it's ongoing. Too slowly for me, but but yes.

[00:15:01] **Laurent Toutain**: Okay.

[00:15:07] **Luigi Iannone**: Okay. So maybe we can switch to the next one. Okay. Good. Great. Oops. So for the the GAAO document, also two revisions. The first revision was to intend to add an appendix that has kind of a small comparison between GAAO and DHCP, version six, obviously. And the second one is, again, for the excellent review of Eric. Okay. As I said, we we added a small comparison as an appendix specifically tailored for six low PAN deployments because this is the context where you would use GAAO if you're interested. Okay? Everything else is is not GAAO, simply. Okay? So the context is the the algorithm. It can distribute the address assignment in 6LoWPAN. Okay? We we we look a little bit the constraints and limitation of the h t p v six in in this specific core deployments. And and then there is the the the proposal in stock. I mean, the we revised the the introduction trying to to focus on these three points and then add the the the appendix so that we give an idea what is the structure of the messages that are used in both cases, what is the configuration procedures or basically the exchange. Okay. And to issue synergy consumption in multicast, which is actually the the the main constraints in this kind of six low pan multicast is pretty inefficient, I would say. Okay? And we added all the relevant in the references and necessary necessary to support the claims or what what we say in the appendix. Okay? We because of the of the review of Eric, we switched to two subsection, was more logical in the order. Again, a lot of improvements between acronyms, the the references, type of success, etcetera, etcetera. We fixed the section was not not perfect, let's say. And also as a suggestion, good suggestion from Eric, we added the HCP v six rapid commit in the appendix, which is rightfully there because it's a it's a possibility. And, yeah, that's it on this document. Again, we submitted when the data take it open it again, so Eric did not have time to go back and see what we did to address this review. So this will come in the next week, I mean, as usual. Any comment of or question?

[00:18:25] **Laurent Toutain**: Lorenzo, think the comparison with the h p v six that's, like, close in the introduction, I think is, like, doesn't really reflect the improvements that have been made elsewhere. I think that needs to be sort of still because it says it's kind of inefficient, but I think the comparison at the end of the document shows that it's not really much more not really very inefficient. Right? Because it says, you know, it has more rake ups and so on. So I think we the the sort of the section at the end of the document shows that the shows that the DHCPv6 with rapid commit is kind of as efficient as this scheme as far as I can tell. The only difference is that it its messages traverse multiple links. But I feel that that is something that could be easily overcome by making sure that the packets to the d h p v six specific address were not forwarded. And it just went to the same node that would normally assign the address. So I think maybe we should say that that would have been an alternative and explain why it's not taken. You know? And then that would help ensure that we understood the trade offs. So

[00:19:40] **Luigi Iannone**: on the last point, we we we we I thought we clearly say that the efficiency depends a lot on the topology that we have. Fair enough. If it's not sufficiently clear, we can clarify even more. About the inefficiency of the HCP, we see it's it is inefficient. We we put the reference. If you go on the reference, that is proved especially about multicast, etcetera, Which were links. Again, it's it's topology dependent. Highly topology dependent. We can clarify this in the intro and in the appendix. So it's no problem. If you have specific sentence or the the place where to put that sentence, that suggestion will be very welcome, obviously.

[00:20:23] **Laurent Toutain**: So is it I guess I guess my question is, is there a reason why we can't have those DHCP v six packets go to the same place that the GAO packets go and not have them flood a bunch of links. Because I agree that's inefficient. Right? But in general, the network is rooting these packets. So maybe we just need a different multicast group that has a different scope.

[00:20:46] **Luigi Iannone**: The most multicast is is the problem in a certain way, first of all. Even on a single link, depending on the the the layer that you have underneath, the multicast is an issue. Then, obviously, we we can spend endless hours to say we can somehow adapt or or tweak

[00:21:05] **Alexander Pelov**: in

[00:21:05] **Luigi Iannone**: a certain way. We don't exclude at all the usage of DHCP v six. It's just a different way to use it. And we insist, and if you you believe we didn't, please let me know. We insist even more. This is really same to six low PAN deployments and very specific that use basically RFC six seven seven five stack, ND stack. That's all. If you have that product in ND stack, you can use Gao, and it is already there. If you have the ND stack and you want to use the HCP as an additional service with depending on on on your IoT, may or may not be a good choice. I mean, it's there is no there is no definite answer, I would say, whether or not one is better than the other. But, again, in the specific context, I mean, specific context of six loPA.

[00:22:05] **Laurent Toutain**: Concretely, I would suggest the following. Right? Maybe briefly doc I think the section at the beginning has not been updated with respect to because the section at the end has the discussion of rapid commit, and it's got the comparison. Right? And once you look at that, you you notice that the section sorry. One point the the one at the beginning, basically, that says it's inefficient. It's kind of like there's only one remaining inefficiency, which is that the packet has to be spread out. And I think, you know, it would be good to have a discussion somewhere in the draft saying, we could have designed it like this, which is what you're saying here. Right? We could have designed it like this. It would have been possible to extend six slow to make this packet not go very far, and the efficiency would be the same. But we decided, you know, not to do that, and I think that's that's fine. So if we so so, again, if we updated the first the section at the beginning saying that currently says it's inefficient, inefficient, which has not been updated. If we update that to reflect the fact that it's almost as efficient, and then we say, we could have made it in a even we could have made it the same efficiency by doing this.

[00:23:16] **Luigi Iannone**: Depending on the topology, we we could achieve the same level of efficiency. Yes.

[00:23:22] **Laurent Toutain**: Yeah. Maybe maybe I don't under perhaps perhaps I don't understand that in the sense that the node that emits the packet to get the address is sending a packet a request. Right? That request is routed by the network. That re the d h t v six request could be routed in the same way. Perhaps I misunderstand.

[00:23:39] **Alexander Pelov**: So just think it's a very interesting discussion. Yeah. I think we we have we have already gone a little bit over over this topic. So I I get the impression that there's this question about the topology and the specific topology and maybe some wording like inefficient, you you know, to to to choose the correct wording.

[00:23:57] **Luigi Iannone**: I'm the answer we can improve the introduction. Yes.

[00:24:00] **Alexander Pelov**: So I I think so. ESCO has maybe something to add to to to that discussion, but definitely, you know, you need to clarify this in in a public point way. So,

[00:24:11] **Esco Dijk**: ESCO? ESCODYKE. So this is indeed adding to the discussion a little bit. So I basically work on six slope on based mesh network topology that does not use six slope on ND. And a couple of years ago, it also defined DHCP v six operation, basically, as an optional thing, which was based on Unicast also because of the inefficiencies with multicast. So you basically get, yeah, an address by configuration in it. You get an address where you know where to go to for the DHCP v six server, and then that's it. But that's got never popular, never actually deployed because of Slack was already already there. But it was at least specified at some point. So so that's maybe something to compare against us as well. But, yeah, I don't wanna make a long discussion from it.

[00:25:04] **Luigi Iannone**: Yeah. Yeah. Yeah. Why not?

[00:25:05] **Esco Dijk**: It's good to good to keep in mind that it's also an alternative, and, yeah, that much might be considered. Yeah.

[00:25:10] **Luigi Iannone**: Can you send me a reference to to to this?

[00:25:13] **Esco Dijk**: Yeah. So I can send the reference. Yes.

[00:25:16] **Luigi Iannone**: Thank you very much. So

[00:25:23] **Alexander Pelov**: for the next steps of your document, do you have

[00:25:26] **Luigi Iannone**: Yeah. We will we have to rewrite little bit the introduction Yes. To to be in line with what is in the appendix and as as for the comment of Laurent, reference to Esco and the the previous effort on using for DHCP. And, yeah, Eric will come back with the

[00:25:48] **Alexander Pelov**: point about the Yes. May maybe if I if I can just ask a question. How many people here have read this document like the the latest revision here in the room or over over the Internet? I mean, no nobody is raising the the the hand at least one time. So so so so probably because I I get the impression

[00:26:15] **Luigi Iannone**: that too. Lorenzo and Dennis Yes. Yes. The thorough Yeah.

[00:26:19] **Alexander Pelov**: Yeah. And and the chairs and then those

[00:26:20] **Laurent Toutain**: Yeah. Yeah.

[00:26:21] **Alexander Pelov**: Yeah. I know that's all there. There are people that have read it. But I get the impression that it will be very useful to for this document if some more people read it and actually, you know, provide some feedback on this specific question of what kind of wording to be used Sure. And what to be included or not. Sure. Right. So, yes, if you are we'll we'll talk with the other chairs to to to be able

[00:26:47] **Luigi Iannone**: to to find something of yours.

[00:26:49] **Alexander Pelov**: Okay. Thank you very much. Thank you. Thank you. So, Carlos, just a second for me to get Sure. Through the 18 clicks as Carsten said the other day. And, yes, the floor is yours.

[00:27:19] **Carles Gomez**: Okay. Thank you. Okay. So I'm going to present the last updates of the draft entitled transmission of sheet compressed packets over ieee802.15.4 networks. My co author is Ana Minaburo. So first of all, a quick reminder on the motivation for this draft. On this slide on the left, you can see the traditional I p v six based protocol stack for devices that use 15 dot four as the radio interface, which is possible thanks to 6LoWPAN as the adaptation layer, which could be seen as comprising two sublayers from this point of view. The one on top dealing with header compression, the one below dealing with fragmentation and reassembly. And what we want to do in this document is to allow the opportunity of having the protocol stack on the right where you can see that there would be another method for header compression, which is based on using Sheik. SCHC is the main product of the l p one working group, now called SCHC working group, and there is the expectation that can provide a greater header compression performance than traditional 6LoWPAN header compression, and that's because SCHC exploits a priority knowledge of the header field values of the packets that will be transmitted. So on the status of the draft, it was adopted in January 2023. And today, I'm presenting version 13, where, basically, we have added a solution to the last pending point, something that was not yet solved from all the comments that were received from ESCO dyke's comprehensive review. Again, many thanks, ESCO. And from the point of view of the table of contents, we have added appendix c, which, as you will see, is part of the solution we have provided to the problem described. By the way, the problem is related with the pointer based route over mode, the pro mode. And, otherwise, the table of contents is stable. Okay. So let's see the updates in the draft, which are basically in section for the three, which describes the pro frame format along with appendix c. And what we can see on the screen is the so called pro header, which would be prepended to the sheet compressed packet. And this header contains a bit pointer and information of destination address, the residue length, and this is intended to allow an entity that receives a sheet compressed packet that perhaps doesn't have the rules needed to decompress the the compressed header. But with a bit pointer and the address residue length fields, it will be possible for this entity, say, a router to determine which is the destination address and therefore carry out the task it has to do, like, who is the next hop for that packet. So we already had the problem in the previous format, the old format mentioned here, with the address residue length field, which, used to have a size of seven bits. And the problem is that we need to represent, values for address residue length between zero and one hundred twenty eight. So if we encode the address residual length directly, then, it's not enough with seven bits. And what we need as solution here was actually not adding one more bit, but instead reducing couple of bits here, And the new field, has a address residual length of only five bits. And, the point is that now what we're doing is that the address residual length is indicated indirectly. So, our approach is as follows. What you can see on the slide is part of the table in appendix c, which, provides the, meaning of the all possible bit combinations for the address residue length field. So, for example, the first row, address residue length of all zeros, this means that the known destination prefix has a size of zero bits, which then means that the address residual length is 128 bits. Then the second row, address residual length of zero zero zero zero one means that the non destination prefix has a size of 16 bits, and that's the part that has been highlighted. Therefore, the address residue length is 128 minus 16, 112 bits. For the third row, it would be a resolution to length of zero zero zero one zero, means the non restriction prefix size is 32 bits and so on. So, by the way, recall that the prefix that is known is assumed to be known either because it's sort of preconfigured, for example, if there is only one prefix used in that scenario, or it can be known through the DCI field, which is optional in the previous pro header format we have seen here. Okay. So then if we go down in the table, what we can see is that in the end, we get better granularity in terms of the address residue length that we may want to indicate. And, also, we assume that it would be more typical to be handling these cases where we have the better granularity. So it is possible to indicate an address resident of 0123, and so on. Okay. So this is the the solution that we are proposing, for the previous problem. I don't know if there's any point, any comment on this.

[00:33:30] **Eric Vyncke**: Eric, strongly suggest to move the table, which is normative in the main body even if it's boring to read. Appendix are considered by default non normative. You need to put a text. Okay.

[00:33:43] **Younghwan Choi**: Thank you.

[00:33:50] **Alexander Pelov**: So I'm not going to go there, speaking as an individual. I like I don't know what happened. But I like this new approach. You reduced the number of bits and it covers all the top I mean, the reasonable prefixes. So I find it's expressive enough. So good work there. Thank you.

[00:34:09] **Carles Gomez**: Thank you. Thank you very much for the comments. Okay. So then after we submitted the draft, we noticed that a bit later, there was the submission of an important document for us, which is the architecture draft version zero six. And we noticed that there are some updates in in that document, which will have some impact on this draft that I'm presenting today. So some of the updates relate with terminology and few concepts, such as, SCHC control header is now just called control header. SCHC instance used to be defined as a session, but now there's a separation of the term called instance and another term called session. Also, SCHC data, which in the past used to be SCHC payload, is now not defined. User payload is not defined either. So it is perhaps a bit unclear whether the SCHC architecture document will remain, like, currently stable as is or not. But as you know, we've been doing our best effort to try to always monitor and align with the progress of the architecture draft, and this is something we plan to continue doing. So, okay. Pending this point, at this moment, the authors are not aware of any outstanding issues, with the draft. So we would like to ask whether it would be a good moment for considering working group last call.

[00:35:45] **Alexander Pelov**: Thank you very much, Carlos. And so just one point about the SCHC architecture. Of course, your document is one of the top priority for the SCHC architecture because it is one of the interesting cases. The SCHC payload, that was I mean, we forgot to include it, but all the missings, they will be added. That's no problem there. And yes, other than that, we as I said, we did an automated overview. So most of the concepts can be directly mapped. And if they are not mapped, they will be in the sheet architecture. And there is, of course, the question about the control header, which, you know, it needs to be normatively defined in a standard document as yours is. So I think nothing radically will change. And we'll be very happy to work with you and with Anna in order to make sure that everything goes as smoothly as possible. And in terms of working group last call, I would be very happy if you can also share this working group last call in the SCHC working group as well so that we can do review, which of course can be done right after we change like all the terms. Normally, most of them should be just search and replace. But thanks for the excellent work, and and thank you for persisting through the through the changes of terminology.

[00:37:14] **Carles Gomez**: Okay. Thank you. Thank you very much. And thanks for all the efforts the architecture document, which is not trivial. So thank you very much. Okay. Any comments or questions?

[00:37:34] **Eric Vyncke**: Okay. So

[00:37:37] **Alexander Pelov**: in terms of working with PlusCo, I think that like the moment that we do the sort of like we replace the terminology, then you can start it. If you only can start it, I mean, you're the chairs right with Laurent. You can start working with last call, but probably just say, well, you know, some of the terminology will be changed. So I I think it maybe it's wiser to wait to to to do that change before. Right?

[00:38:03] **Carles Gomez**: Thank you very much. Okay. So then I I guess if there's no more comments or questions about this draft, we can proceed to the next presentation, which I believe is, Young one.

[00:38:24] **Younghwan Choi**: Hello. This is Young Wan Choi from Metry, Korea.

[00:38:31] **Laurent Toutain**: Yeah. Yes.

[00:38:33] **Younghwan Choi**: Yeah. Thank you. Yeah. This is this slide is the status of the IPv6 over OWC. Actually, this is the seventh, the revision for this IPv6 over OWC. Actually, the revision is regarding to the section five, the Internet connectivity scenario. So the motivation, actually, there's no any feedback and comment technical comment during that the ITF, the twelve five, the previous meeting. So I made some I got some medication about some the unique the characteristic of the OWC were not fully reflected in the figure number seven and eight. So I just actually, the previous figure was actually based on the the conventional RF network. So I just focus update for the section five one and two regarding that one and no changes out of outside of the section five. The first update is that the section 5.1, actually, as you can see that one, the previous the figure number seven is just based on the con conventional, the RF natural, just linked, like, between the two node, the line within the line. But I just would sort of change it like this one. Actually, the I also put the some explanation, some kind of the OTP, like the one. The communication, you know, o OWC, actually, between the neighboring node is established only when they are located inside and within the the optical transmission, the range in the stands for the o t o t o o t r. So this one reflected to the the directional propagation characteristic of the optical white wireless signals. So I just put kind of the So this is the opt OTR. So the ins inside that OTR, the old node and the device can communicate each other or something. And this is the one of the scenario for the connected to the Internet. And the other one is the the kind of the the virtual network. Nearly same previous the figure number seven, but the eight is different than one. The there was a one six error. Six error also have one another, the the propagation range, though they can they pour some signal to the other, the node, something like that. So I just put kind of the figure and the location. So that's all the the changes and the just with this revision, just clarify the Internet connectivity scenarios and the in introduced the OTR as well and improved some top approach illustrations, better reflect that the eight zero two dot 15 dot seven characteristics, I think. Next task, I I guess, I will correct the implementation feedback with some review from the flow and reserve the remaining the actuarial and technical comments. And I'm going to prepare for the working from last call with the target, I think, to next year. Yeah. Yeah. That's all. Thank you. Any feedback and comment on day one?

[00:42:36] **Carles Gomez**: Yeah.

[00:42:38] **Alexander Pelov**: Thank you very much. Yes. I I mean, it's a fairly small and straightforward document. I think it's around around 18 pages and pretty clearly written. So, yes, there is the shepherd. Everything is there. So maybe a couple of of reviews from the working group will be will be nice. Yeah. Yeah. Thank you. Yes.

[00:43:06] **Younghwan Choi**: Good work. Yeah. Thank you so much.

[00:43:23] **Carles Gomez**: Okay. So I understand the next presentation is Kerry on the MSTP update.

[00:43:49] **Alexander Pelov**: He oh, yes. He's not online. Maybe some connectivity issue. She was not to he was not online today.

[00:44:19] **Carles Gomez**: Okay. So he he sent the slides earlier this morning. So, yeah, perhaps he may have had some connectivity or another issue of another kind.

[00:44:33] **Eric Vyncke**: So he did not register for the meeting. So he's unable to join the the the meeting. Oh, okay. Should have used a fee waiver, right, for removal.

[00:44:42] **Carles Gomez**: Okay. Yeah. Yeah. Yeah. Okay. So I think if I can maybe give some input here. I think it was a short presentation. I see three slides, and I believe that this document has not been updated since the last ATF. But we know that Carrie has been working trying to to port the IPv6 over MSTP, which is also called 6lo- back since MSTP is a technology for BACnet, which is for building automation. He is trying to to work on this, implementation on a test set, and, he announced that the next revision of the draft will contain an implementation status section, and his test bed is based on Nordic devices with Riot operating system and then Linux host. And one point where he has been asking for help is with the SCHC header compression part. Because, actually, Chic was not not like in the original RFC that's being updated, but now we are considering in some of the six low documents to add Sheik as an optional header compression technique, and he has been asking for help in in this regard, in particular, about the the part of implementing SCHC. Because I think that from the point of view of adding SCHC in the draft, maybe he can look at how this is done in the I p v six over optical wireless communication draft, where Chic is also optionally added or optionally supported. And that may be one point, but then I guess he's also interested in the implementation part of Sheik. So, Alex?

[00:46:57] **Alexander Pelov**: Yes. That's, that's excellent. I mean, probably, I don't know if it's if it's going to be the the role of the chairs or even the authors to send an email to the chic working group list and just say, hey, we're interested in, like, looking some eyeballs here or or some help. And and I I know that there are many people that would be interested in in in jumping in. Right?

[00:47:21] **Carles Gomez**: Okay. That would be great.

[00:47:28] **Laurent Toutain**: So just with my professor at, maybe we can also look at some student at the Atlantic to to study that and try to make an implementation. Yes.

[00:47:49] **Alexander Pelov**: And thank you, Eric, for the clarification. So as it is on on the chat, as it's not a working group document, it should be the author to send this email. Yes. It should be. Yes. But it's a fairly very interesting topic at least personally. So that that's great.

[00:48:08] **Carles Gomez**: I believe it is already a oh, it is all a working group document.

[00:48:12] **Younghwan Choi**: Oh, by the way.

[00:48:13] **Luigi Iannone**: Yeah. Okay.

[00:48:16] **Alexander Pelov**: Yeah. Okay. So in any case, it's an interesting topic. And as Laurent said, yes, there will be implementers that will be interested in doing that. So with this, I think that we have covered all the agenda. Any other business? No? So thank you all for being here. Welcome to the new chair, and thank you all for doing the good work here. Thank you, Christian, for for taking the note the minutes once once again. And

[00:48:58] **Luigi Iannone**: see you.

[00:49:00] **Carles Gomez**: Thank you so much.