Session Date/Time: 20 Mar 2026 03:30
Carles Gomez: Okay, so it seems like it's the time to get started. So, hello everyone. Welcome to the meeting of the 6lo Working Group. Please make sure that you are in the right room. My name is Carles Gomez. The other chair is Shweta Bhandari. As you can see, we are both remote today. And our in-person delegate is Luigi Iannone. Thank you very much, Luigi, for helping. And our responsible AD is Erik Kline, also on-site. And we would need to have someone help us minute taker. Is there anyone who would like to volunteer?
Luigi Iannone: I'm here, so when I'm not presenting, I can help.
Carles Gomez: Okay, thank you very much, Luigi. That would be very helpful. Um, so yeah, let's hope that we can also cover when you are presenting. And anyway, recall that we are using Hedgedoc as usual as the tool for taking minutes. So everyone feel free to join and contribute to the process of collaboratively taking minutes as well.
Okay, so these are a few tips for this meeting. For in-person participants, please make sure that you sign into the session by using Meetecho. You may, for instance, use the on-site tool which is available from the Data Tracker agenda. And recall that you need to use Meetecho to join the queue because there's a single unified queue which is handled directly from Meetecho. And also, blue sheets are automatically generated from Meetecho as well. So if you are in the physical room and haven't yet joined the Meetecho session, please do so. And for remote participants, just remember to keep your audio and video off unless you are presenting.
Okay, so this is the Note Well. Recall that by participating in the IETF, you agree to follow IETF processes and policies, and the Note Well is a reminder on some of those policies in topics such as the expected behavior for IETF participants, which should be respectful and professional, also on intellectual property rights, also on different kinds of procedures, process in the IETF, and if you haven't read yet the Note Well, please take your time to do so. There is a link on the second line of the slide and also there's the QR code which you may capture to access the whole content of the Note Well. So I'll keep this slide for a few seconds just in case.
Okay, so this is the proposed agenda proposed for today. And the first presentation would be the usual chairs' introduction which is currently in progress. This will be followed by a presentation by Luigi on the status of PASA and GAO. Then I will present an update of the draft on transmission of SCHC-compressed packets over IEEE 802.15.4 networks. And after that, Young-hwan will present the transmission of IPv6 packets over short-range optical wireless communications. And finally, Kerry will present the RFC 8163 update. This would lead to a total of 50 minutes of allocated time out of 60 minutes of total session time. Is there any comment on the agenda?
Okay, so if there is no comment, then let's proceed to the usual report on working group documents status. Since the last IETF, we have two new RFCs. Those are RFC 9926 on Prefix Registration for IPv6 Neighbor Discovery and RFC 9927 on Fixing the C Flag in the Extended Address Registration Option (EARO). Congratulations to the authors. Pascal is an author in both documents and then in the second one there is also Adnan. Congratulations and thanks to both for the efforts. And also thanks a lot to everyone who has contributed with reviews and comments in the process. By the way, the second RFC, you may recall that the initial version was created less than one year ago. This is a very short document and possibly this gives us something like the lower bound of the time it seems like a document can take to go through the whole process until publication. Again, thanks everyone who has contributed for this.
And we currently have five working group documents. The first two are quite advanced in the process as publication has been requested for these first two drafts, which are again PASA, which stands for Path-Aware Semantic Addressing for LLNs, and GAO, which is Generic Address Assignment Option for 6LoWPAN ND. And then the other documents are a little bit behind in different stages. Uh, there would be the transmission of SCHC-compressed packets over IEEE 802.15.4 networks, which has been updated and will be presented later today. Also transmission of IPv6 packets over short-range optical wireless communications has been updated and will be presented. And finally, you may recall that in December we have a new working group document adopted, which is the transmission of IPv6 over multidrop serial bus/token passing (MS/TP) networks, which is intended to obsolete RFC 8163. And it will also be presented later today. So is there any comment, any question on the status report? Yeah, Erik.
Erik Kline: Yeah, so very quickly for the first two drafts, the PASA and the GAO, it's—they're currently on my to-do list as I need to do the AD review, but as I agreed with Luigi, I mean, I had other things to do this week than doing the AD review. So expect the AD review end of next week and then we can progress to IETF Last Call and so on. So good progress, happy to see those two documents moving forward. Thank you.
Carles Gomez: Okay, thank you very much. Okay, any other comment or question? Otherwise, I guess we can proceed to the next presentation, which will be by Luigi on the status of PASA and GAO.
Luigi Iannone: Yeah, so that will be relatively quick. So as Erik said, the publication of the two documents has been requested. Um, Erik at some point will do the review as he usually does in a very thorough way and which I appreciate. Um, there was no real update actually on the PASA document because as you recall, PASA is just an application of GAO. And GAO we have an update, I will present in a couple of minutes, but no technical changes. So we didn't have to submit a new revision of this document, which is pretty stable. So thanks to everybody that gave inputs to this. And what to say, thanks Erik for taking care from now on. And that's it for this document. Unless there are comments, I just change the slide deck.
So for this one, for GAO, there was actually an update. As you know, rightfully the chairs asked a feedback from 6man. Okay, so Lorenzo was quite nice in sending an email stating his concerns. Okay, and we took a bit of time to address them, but finally we did it. Actually kudos to Adnan that managed this. So what—technically there is no change from a really technical point of view, but we revised completely basically the introduction so to clarify the scope of this small option, okay, in which case it might be useful, in which cases it might not be so useful. Okay.
So basically what we added is we discussed in which cases the DHCPv6 in the context of LLNs, okay, might not be that efficient as usually is, okay. Mainly because of broadcast, the centralized architecture, okay, which leads to having to deal with multiple paths. As you know, in 6LoWPAN we try to avoid this so that we manage everything without broadcast and in a single hop. Okay.
And also we clarified the algorithmic address assignment, okay, trying to really clarify in a clear way—the benefits of GAO. So this option is just a generic option that allows you to deploy any algorithm that allows you to allocate addresses, okay. PASA is an example. There are a couple of references in the document that suggest other algorithms that can be used but we don't actually—there are no specifications, okay, we have only PASA for now. Everything is one hop, okay, so we don't need the multihop infrastructure and is completely aligned with 8505, which is the main document about 6LoWPAN ND. Okay. We did reply a little with some delay to Lorenzo. We hope all the clarifications are good. So far we didn't have a reply. Um, so yeah, but open obviously. And that's it basically. So again, this document is as well in the hands of Erik now. And I see Lorenzo is in the queue.
Lorenzo Colitti: Yeah, so I—I'm not super convinced about the rationale here, right? Because I think the discussion statement in—that was added to the draft kind of boils down to DHCP with a central server is kind of expensive, right? That—that was one big reason why the draft states that DHCPv6 can't be used. Um, and I think the reason for that is that the in—in this current proposal, the prefix can be assigned locally, right? That's a big reason for that is that it can be assigned by the—to the—like the neighboring router, right? But like there's no reason why you can't use DHCPv6 to that neighboring router and like cut out all of the multicast noise and all of the expensive things that Section 1.1, right, basically says, "Well, you know, DHCP is very expensive because you end up kind of flooding the network," which ends up being—you have duty cycles and, you know, so on and so forth. But there's no reason to do that. You're defining a new protocol here which is a one-hop protocol. You could just as well use DHCPv6 as your one-hop protocol.
Luigi Iannone: So there are two things that I may reply. First of all, we don't say that you don't have to—you can't use DHCPv6. We never use that. We just claim that it might be less efficient, okay. And I think that the discussion is a little bit asymmetric in the sense that this GAO option is just an option in a bigger framework, okay, that already replaces DHCPv6. So—and as is proven has proven to be more efficient compared to DHCPv6 in the way it is deployed right now. So it's not a matter of GAO, it's more about the neighbor discovery how is done today. Now, if you tell me you can tweak DHCP to have an equivalent efficiency like the framework that we have today in 6LoWPAN, maybe, I don't know, maybe. But please go ahead, write a draft and state how you can tweak DHCPv6. I see no issue with that.
Lorenzo Colitti: It's not difficult, right? DHCPv6 is a one-packet exchange.
Luigi Iannone: Agree, it's not difficult. Please, yes, I'm not claiming it's difficult.
Lorenzo Colitti: My point is the bar to introducing a new protocol here—the point is the point I was trying to make, which is how we got to this text, was that we are adding a new protocol to do something that we already have an existing protocol for.
Luigi Iannone: No, that's not accurate. We are not adding a new protocol. We are adding the GAO is an option to an existing protocol if you wish, it's just a variant of the ND, okay.
Lorenzo Colitti: My bad. Mechanism. If you don't want—if you don't like protocol you can say mechanism. Option. We are adding a new configuration mechanism to configure to—to assign prefixes when we already have a configuration mechanism to assign prefixes that has been with us, it's stable, it's deployed everywhere. Anyway, so I'm not going to repeat my previous email, but the point was we have duplication of mechanisms and that is generally not a good thing. Now, the answer to that from the draft authors' point of view is like, "Well, the protocol that—sorry, the mechanism we have that is used elsewhere, DHCPv6, is inefficient in LLNs." And what I'm pointing out here is that that's actually not true. Um, it is a one-packet exchange. The DHCPv6 server does not need to be remote. You can just run it on the—on the same place that responds to the EARO. Because at the end of the day, the—any mechanism that we define, including this one, will have one packet that goes to some entity that decides what the prefix is, and one reply that tells the requesting node, "Here is the prefix that you asked for," right? And this is what DHCPv6 does. You have a client and you have a server. Yes, you can also have a relay. Yes, you can also do multicast. But there's nothing preventing you from just running this two-packet exchange on whatever network today. And and DHCPv6 servers are already widely available. There's probably like tiny ones that are like very cheap to implement. So anyway, and and the refresh timers are, you know, can be changed. Anyway, so I'm not going to repeat my previous discussion in terms of efficiency, but I think if we want to basically say we are going to come up with a different mechanism, we need to justify it a little bit better because the justification that's there is not convincing.
Luigi Iannone: For you. Okay.
Lorenzo Colitti: No, not for me. I've given you a concrete technical concern. The text here assumes that the server must be remote and that this is going to be expensive, and that's not true. You can run the server in the same place as the—I don't know what term to use, but whatever it is that assigns the prefix in this scheme, maybe the neighboring BR. That thing could just as well run the DHCPv6 server and the justification in Section 1.1 would not be true anymore.
Luigi Iannone: Can you prove that DHCPv6 is as efficient as the GAO option? It's the same thing it's both way Lorenzo in a certain way. But I don't want to repeat myself again. So, this is not a protocol, is an option. It's not a duplicate because it's not exactly the same use case. If you can prove that DHCP is efficient as GAO, that's fine with me, I have no problem.
Lorenzo Colitti: No, no, no. The burden—the burden should be on the—
Erik Kline: So, Lorenzo, Luigi, we are an IETF meeting. I understand both of you are passionate about what you are doing, but and you are coming from a country which is known for having exuberant language, which is quite and polite, so let's keep technical here, right? Clearly.
Lorenzo Colitti: Yeah, all I would say is that the—I would say that the if a working group is introducing a new mechanism, it should be on the people defining that new mechanism and proposing it to demonstrate that it's substantially better than the existing mechanism or that the existing mechanism can't be used. I'm making a statement here that the existing mechanism could be used and it is not any less efficient than what is being proposed here.
Luigi Iannone: Um, what we do here is interoperability documents. It's not required to prove anything to be better or worse than anything else. There is a discussion that is a different use case. It's a small option and the use case is actually not GAO. GAO is a little piece of the puzzle that is a bigger one. So, um, I don't have anything to add to that. The different mechanism to allocate addresses and prefixes is something that exists even before GAO. So, yeah.
Erik Kline: Uh, I was sitting here listening to this discussion getting a bit contentious and I think there's—there's miscommunication going on. Uh, I think the productive way to bring things to the IETF is to say, "There is this thing that we want to do." When it goes into, "And we have to do it this way," that's when the conversation gets stuck. I agree with what Lorenzo said is that when there is already a perfectly good way of doing this, then the presumption is let's reuse existing mechanisms. And I think there was some miscommunication about the word protocol. We use the term protocol in networking in the same way it's used in diplomacy about protocol in diplomacy is who does what when and who speaks first and who replies first. A protocol is a set of rules for how things work. If we are adding—we can call it a mechanism—if we are adding a new way of doing something, that is a new set of rules for what entities send messages, what entities receive messages and reply to them. And the—the burden on bringing proposals to the IETF is to convince other people that we need a new thing. Um, the burden is not on the IETF to—to come up with a counterargument. So, I think to move this discussion forward, we either say, "Yes, Lorenzo makes a good point, we can actually do this with existing mechanisms," or we come up with a really strong argument why we have to do something new. Um, so that's my suggestion.
Luigi Iannone: That's a very good point. Thank you. Um, just for for clarification, we never said that that we have to replace anything. We never said you can't use existing mechanism, it's just an alternative in a specific very scoped use case.
Erik Kline: Oh, this is not about replacing things. This reminds me of a comment that John Postel made 15 years ago, more. Uh, he said the earlier work of the IETF was to look at all of the many possible ways of doing something and to agree on the one way we're going to do it. And in recent years the work of the IETF has been filling in all the other ways of doing the same thing that we said no to the first time around. And having two ways of doing something is not a benefit. It's a downside. Our job here is to look at the menu of choices and pick the one we're going to do, not to say yes to all of them. Do you have any opinion 6man chair? Oh, sorry. Uh.
Lorenzo Colitti: I just wanted to ask a sort of process question. Sorry if I—I should probably know the answer already. Um, but I feel that this is a sort of legitimate technical concern in terms of duplication of protocols, right? I just want to know where to send that. Can I just send it to the working group mailing list or, you know, because this was part of the 6man review and yes, I apologize for not replying but—
Shweta Bhandari: Oh, hey yeah. 6man chair. Yeah, I am also have concerns about duplication and fragmenting the protocol and so on. So I think I'd like to talk to Bob about this and we may talk to 6lo chairs as well. Maybe with—and now we have the same responsible AD for this, right? So I guess it might be, yeah, a bit of administrative discussion. But yeah, I—but with no—no hats on, I—I do see some concerns, yeah, about creating 15th competing standard here, right? So maybe and yeah, I apologize to probably need to ping 6man again. I'll do it tonight to ask the working group for their opinion because I suspect substantial part of 6man are participants might not be paying enough attention to this working group and this document, yeah, and I'll do something to bring it to the attention.
Carles Gomez: Okay, perhaps chair hat off. I think another technical point to consider is that um, for devices in the environment that uh this draft is considering, the 6LoWPAN framework will already be in place, and uh perhaps it will be less costly to to use the mechanism uh introduced in—in this draft than uh using DHCPv6 that might be something to—to evaluate. And well, chair hat on, yeah, thanks uh for managing this. Also from 6man, uh it will be good to if—if some of feedback uh can be obtained. So I think we kept 6man uh in cc in the relevant messages uh updating like the—the state that there was new versions of this draft and the relevant responses from the authors to the concerns such as those by Lorenzo. And anyway, yeah, thanks for um managing this and trying to—to get some additional uh consideration on this document. So is there maybe any other comment? Lorenzo you're still in the queue.
Lorenzo Colitti: Okay, thank you.
Carles Gomez: Yeah, Shweta.
Shweta Bhandari: Um, Erik, question to AD. Should we add a section in the draft to justify uh how this builds on top of DHCPv6 and how is it different? What are the concerns? How an implementation of this would be better than or not be satisfied by existing DHCPv6 implementation?
Erik Kline: So I need to review, Erik as the responsible AD here. I need to read this section as I said my AD review is not yet done. It was something that was requested about one year or two years ago already to have justification because indeed duplication of effort is kind of stupid. If the section itself is not enough as it is, we may want to extend it. And I remember that even after working group Last Call there will be an IETF Last Call where if it's still not enough or the objection to those two draft and there may be valid objection of course can be done. And this will be a choking point, right? So we if there is strong objection and no consensus at the IETF Last Call to publish those two draft they won't be published clearly, right? So it's basically a non-answer I understand. Um, but getting justification of not doing DHCPv6 was already requested one year or two years ago and I know that the draft has been updated. I don't know whether the text is enough though. Does it answer somehow your question, Shweta?
Shweta Bhandari: Yeah, I think we can review that section and uh if there are uh if the justification isn't sufficient we can probably build on top of that.
Erik Kline: Indeed. Thank you.
Carles Gomez: Okay, thank you. So now we move to the next presentation. In this case, I will present the last update of the draft entitled Transmission of SCHC-compressed packets over IEEE 802.15.4 networks. My co-author is Ana Minaburo.
And first of all, a quick reminder on the main goal in this draft. On the left, you can see on the left in the slide the traditional IPv6-based protocol stack for devices that use 15.4 as the radio interface. This is possible thanks to 6LoWPAN as an adaptation layer which from some point of view could be seen as comprising two sublayers, on top 6LoWPAN Header Compression and below 6LoWPAN Fragmentation. On the right of the slide we can see the protocol stack that uh we want to enable, which is basically uh offering uh using SCHC as an alternative uh technique for header compression in these environments. And that's because there's the expectation that SCHC might offer uh greater header compression performance. SCHC is the main product of the LPWAN working group now SCHC working group. And uh SCHC exploits a priori knowledge of the header field values of the packets that will be transmitted.
Then on the status of the draft, it was adopted three years ago. And today I'm presenting version 12, which uh incorporates several improvements after Esco Dijk's comprehensive and thoughtful review. Many thanks, Esco. And the improvements are in several areas, including technical, editorial, and also presentation or format. And uh we also align some terms in this document with the part of the new terminology from the SCHC architecture draft, which is appears to be more stable as well.
On the table of contents the—the main structure remains stable, there is no new section, so structure remains the same as in the previous version of the draft.
And uh now let's go through the updates in this last revision. Uh, first of all, in Section 2.2, uh we had some text about the 6LoWPAN node term, 6LN. Uh, this was defined in RFC 6775 as any host or router participating in a LoWPAN. Uh, however, then there is uh another document, RFC 9008, which describes how RPL can be used in a number of scenarios that constrains the definition of 6LN to only the role of leaf node. And in this draft, we had adopted the—the same approach uh because of the text that we were using for the RPL-related content. You may recall that for uh multihop—well, for multihop communication we have three route-over modes, one of them is the RPL-based route-over. And uh however, we realized after comment from Esco that perhaps uh this definition of 6LN in 9008 is too constraining considering that uh node might act uh sometimes as a router but in some cases perhaps not and considering the whole document. So what we did was removing the paragraph in 2.2 that was constraining the use of 6LN to just the the leaf node.
Then uh we have some updates in the introductory part of Section 3.5 on multihop communication. So, uh, first of all, Esco explained that uh there exist solutions in commercial networks that combine features from both route-over and mesh-under. You may recall that uh in 3.5 for multihop communication, we define again a few modes for route-over and then mesh-under. And uh what we have explained is that uh such solutions that are hybrid may use the functionality defined in this document for multihop communication as appropriate. Then uh you may also recall that in this section there is a number of figures illustrating some example scenarios and we have some clarifications on those. Uh, one of them is that uh there are rules shown only meaning rules for compression/decompression, CD, shown only for IPv6 or IPv6 plus upper layers jointly uh compression/decompression. And uh additional SCHC strata can also be used, not only one as is uh currently uh shown in the figures. Uh, but of course if there are more strata then the corresponding rules will need to be stored as well. And the clarification is that uh the other strata and the other rules for the other strata are not shown in the figures for the sake of clarity.
And uh on the other hand, uh similar to what I was mentioning before, uh routers in the figures uh do not generate application layer messages in—in these examples. And however, in real scenarios, nodes acting as routers might at some time also act as hosts, for example, generating application layer messages. And again, this is not shown in the figures for the sake of clarity, but it doesn't mean it cannot happen. And uh we also add that such nodes will need to support also the functionality for hosts. And uh we also added here, again in the introduction part of 3.5, that routers may use SCHC CD also for the transmission of control plane or management plane messages. Uh, they will need to store the corresponding rules and they will need to use single-hop or multihop transmission procedures accordingly. One comment here also uh added to the draft is that, okay, SCHC can be used as long as there's some specification that defines how it can be used to compress/decompress uh the header of some particular protocol. So far on top of IPv6, uh SCHC CD has been defined for UDP, CoAP, ICMPv6, and there's also some initial work for QUIC.
Then uh we have also some updates in Section 4.3 on PRO, which is the pointer-based route-over mode. Uh, about the Destination Context Identifier, which is uh something you can use optionally. The idea is that uh as a suggestion by Esco as well, if there is a network that comprises nodes that only use SCHC for CD and nodes that use only traditional 6LoWPAN CD, and if uh we are using uh Destination Context Identifier, then the prefix context to be used for both types of nodes should be the same for simplicity. And also, uh Esco had a request or at least pointed out that uh in some cases, such as in Thread networks, routers are expected to have access to ECN bits to signal congestion, for instance. So, um, what we did was modify a little bit the definition of the Bit Pointer, so that PRO can also be used uh in a way that routers can access those ECN bits. And uh the new definition is uh written on the slide: the Bit Pointer gives the starting position of Traffic Class followed by the Hop Limit and the IPv6 Destination Address in the SCHC Residue of the SCHC-compressed IPv6 header in bits. So the new part is what is highlighted in red. And uh with this and now there are out of the three route-over modes, uh there are two which support ECN-capable routers: the straightforward route-over where routers have uh all the rules in use and also pointer-based route-over where uh nodes—the routers don't have uh the the rules used by other endpoints. But with this modification uh both modes can support ECN-capable routers operation.
Okay, and still in the same section, we have renamed the field called address length to address residue length, as it indicates the size of the IPv6 Destination Address Residue in bits. And Esco pointed out that, yeah, the possible values encoded by this field range from 0 to 127, which would not be enough to represent from 0 to 128, and uh tentatively and currently we have text saying that value 127 uh would be used when the IPv6 Destination Address Residue size is either 127 or 128 bits. And this uh could work well for uh the final endpoint and for all routers except for the last one where uh this last one might have to have access to the full destination address to be able to uh deliver the the packet to the final destination. And um, here uh this is still not fully solved. We uh may need to uh consider how to fix this. And uh one thought that recently came to the mind of the authors was that perhaps the address uh residue length field might uh cover just the IID part of the destination IPv6 address which would presume that the prefix is known, either because it's known by default, uh for example in intranetwork communication, or if uh we are using the DCI, the context that identifies a set of uh destination prefixes. So this is something that we need to uh sort out. And if you have thoughts on this, please let us know.
So uh finally, we have also as mentioned before aligned the draft with uh some of the new terms that come from the SCHC architecture draft, the ones that appear to be more stable, which would be the following: SCHC Stratum Header is now being called SCHC Control Header, SCHC Payload is now being called SCHC Data, and SCHC Packet is being called SCHC Datagram. And uh there is ongoing discussion on other SCHC architecture terms and concepts and a design team has been formed for this in the SCHC working group. So we'll need to continue monitoring the evolution of this effort.
So for next steps, as mentioned, we need to sort out the last details about PRO and continue monitoring the progress of the SCHC architecture draft. And uh otherwise we believe that the document is getting quite mature, quite stable. And uh we would welcome reviews and implementation feedback as perhaps we might be approaching some state where we might consider requesting Working Group Last Call. So of course, we are not doing so yet. We still have some couple of issues and maybe continue monitoring the SCHC architecture draft, but uh otherwise the document is getting stable. So any feedback that we can get will be very much appreciated. And that would be my last slide. Not sure if there may be any comment or question.
Okay, so if there is no comments, I guess we can proceed to the next presentation which will be by Young-hwan on the Transmission of IPv6 Packets over Short-Range Optical Wireless Communications.
Young-hwan Choi: Hello, do you hear my voice?
Luigi Iannone: We hear you.
Young-hwan Choi: Yeah, thank you. How can I control this?
Luigi Iannone: You should be able now.
Young-hwan Choi: Okay, I can do it. Hello, this is Young-hwan Choi from ETRI Korea. This is the Transmission of IPv6 packets over short-range optical wireless communications, the version number 6. So um just as the version number 6 just we previously meeting just we don't have any feedback and comment. So this time just for version number 6 mainly updated for the Section number 7 Security Considerations and no more changes outside the Section 7. This slide shows that the contents of the Section 7 Security Consideration for context contents. And the next one is the summarize. The first one is the retain the high-level risk the consideration such as signal leakage, unintentional reception, authentication and access control, the interference, the jamming, energy security tradeoff. And the next paragraph actually we added a brief reference to IEEE 802.15.7 the MAC security services like data confidentiality and the data authenticity and the replay protection. And the last one actually clarified that the some identify risk may be might be mitigate by the these MAC layer mechanism. That's all. And the actually we had one another one individual draft the draft the security consideration for IPv6 over OWC that the version was that number 3. Um, actually that one the new contributor Mun-hwan Choi from ETRI my colleague was invited for that one. And then the previous meeting just some of stable contents has been um from the that version and this IPv6 over OWC version number 6 incorporate these some content contents of that draft. And the that draft the security consideration for IPv6 over OWC the draft will is not being updated anymore. Yeah, that's all. Any feedback and comment from the from the floor? I think I think we don't have any comment and feedback from the floor anymore. That's all. Thank you.
Kerry Lynn: Good evening, everyone. Can you hear me okay?
Luigi Iannone: Yes.
Kerry Lynn: Great. Um, as Carles mentioned, um this is a uh proposal to uh obsolete RFC 8163, which is um MSTP IPv6 over MSTP, uh essentially a token-passing bus over twisted-pair RS-485. Um, it's been accepted as a working group item, uh so the change here uh in this version is basically going from draft-lynn to draft-ietf-6lo-rfc8163-bis. Next slide, please.
Luigi Iannone: You have control but I can if you prefer I I can move the slide.
Kerry Lynn: Okay.
Kerry Lynn: Um, okay great. So, um the the change to this uh draft from uh 8163 is mainly terminology to align with uh the main standard uh the main BACnet standard that defines MSTP. Uh, it's been changed several years ago to uh use more inclusive language. Um, there was one erratum that came up in 8163, so that's fixed uh in this draft. Um, several RFCs uh were updated, um they they there were RFCs in the references section that were obsoleted over the course uh of time. And uh I had uh other co-authors that were uh noted in the original draft or the original RFC and they've been moved to contributor section. And then finally, um at Michael's suggestion, I added a changes to the RFC session section. Um, and so if you want to see the changes, you can uh just diff the previous draft against this one.
So I think the only open item is uh whether the working group wants to add SCHC compression. I am not an expert here uh so I would, you know, need uh assistance, collaborators from the working group to add uh to add another section. And I'm assuming it would be optional that IPHC would still be the the must-implement. Um, the the sort of the background of all of this is that now that I'm a consultant again, which is to say unemployed, uh I wish to do a reference implementation. So, uh I sent out a request to the some knowledgeable SCHC implementers to ask what is the uh operating system that they would suggest that I work in uh to bring up a testbed. Um, I'm currently thinking of Zephyr but if anybody else has strong opinions, please let me know. And uh that that implementation would then be upstreamed but I would assume that that would be uh where we would do any SCHC support. So any questions here?
Carles Gomez: Okay, so um yeah about the optional SCHC compression, um I'm rather on the side of the internet draft itself. Maybe some help would be to well it would be helpful to look at the IPv6 over Optical Wireless Communications draft that was presented right before because it also uh uses by default and supports 6LoWPAN Header Compression, but uh there is also optional support of SCHC for compression. And uh perhaps the approach followed there could be an inspiration to incorporate optional SCHC compression also in uh in your document.
Kerry Lynn: Thanks for that. Um, any any suggestions about Zephyr versus a different OS? I actually think that uh Thomas Watteyne started um an MSTP implementation in RIOT uh some years ago but I'm not sure that that was ever uh upstreamed.
Carles Gomez: Yeah, so uh I don't have like a strong opinion myself on the side of the actual uh better possible implementation frameworks or platforms. Um, but yeah, Zephyr might sound as a interesting one and I guess that we can try to get maybe feedback from people who have been implementing SCHC uh in say starting from the LPWAN and now the SCHC working groups and maybe let's try to see if we can uh get some feedback from them.
Kerry Lynn: Very good. That's all I got. Thank you.
Carles Gomez: Okay, so thank you. Um, so yeah, I guess that well Kerry has some uh next steps like in the area of considering how or whether it might be interesting to include an optional SCHC compression in the draft. Okay, other than that, uh yeah if there is no other comment on Kerry's document.
Okay, then uh that was all the items we we were planning for the agenda for the session today. So is there maybe any other point, any other business? Okay, so if none, then the session ends here. Thanks everyone for all the comments, the feedback, discussions, contributions, and hope to see you all in Vienna. Thank you.
Luigi Iannone: Yeah, thanks everyone. See you next next time next meeting everyone. Bye bye.
Young-hwan Choi: Bye bye. Thank you.