Session Date/Time: 12 May 2026 14:00
Alexander Pelov: Hello everyone. Nice to see you here.
Quentin Lampin: Hello hello.
Quentin Lampin: Alex, we've just sent the slides to you.
Alexander Pelov: Okay, thank you. I'm... I'm reassured. No no, I knew that they... they'll be there on time. So thank you...
Quentin Lampin: No, no, thank you.
Alexander Pelov: No no no, thank you for working hard until the last moment. Uh, yes and we... we'll start as usual five minutes past the hour.
Alexander Pelov: Okay. So um... it is five minutes past the hour. Um and uh... as usual we will start our session. So thank you very much for... for participating here today under even under a short... short notice. So this is um... this is an official meeting of the... of the IETF and uh so you know the Note Well well so by participating in the IETF you agree to follow the IETF process and policies. The Note Well applies and of course so we have all the points here. Uh I think uh all of the participants here know them by heart and um so I'll just move on with uh with this part. So for today we have one main point. So we have an update on some of the documents and then a presentation of the fundamental concepts that uh we have. Endpoint, instance, stratum and so forth. And uh so yeah this is the state of the working group documents. I'm not going to... so it hasn't changed a lot since the last time. Um so I... I was always uh so a little bit of an... of an update. So um Quentin, I... I'm not sure I received your answer uh and I prepared the slides waiting for your answer so you will excuse me if you want more time about this. So I put you... I proposed you as a shepherd to the draft-ietf-schc-protocol-numbers document. Is this okay for you?
Quentin Lampin: Yes, it's okay.
Alexander Pelov: Okay. Fait accompli. So I... sorry I didn't want to to... to ask the question here uh in the working group but um yeah it just remained in my uh in my slide. Um and on the SCHC update of the 8824 document, so the draft-ietf-schc-8824-update... so the shepherd... I'm going to be the shepherd in the document and Marco uh I didn't finish my... my review. I'm going to be finishing it um until the next IETF... until our next IETF meeting and I also it will be my shepherd write-up for it. So normally I think we can uh end the working group call uh in next... in the next meeting. Yes, yes thank you and thank you very much Marco for... for all your patience and uh and um yes sorry for the time it it takes. Uh yes so with this this is the very very uh yes and and we still need to... yes of course. Um so I'm going to update I'm going to update the data tracker with the new shepherds of these documents um the draft-ietf-schc-protocol-numbers and the draft-ietf-schc-8824-update. And uh now we have uh so two working two documents in uh we will start working group last call so I spoke to Alejandro who has some update he has some news on the evaluation of the performance of FEC so that's going to be um he's going to present that next time and I hope that we'll also get SCHC ICMPv6 compression also an updated version for next time. So with this I think we can switch to the architecture advancement and uh so thank you very much Marion and Quentin for preparing the slides. Um Marco I think you are a very precious participant today uh because uh I think you and and Carsten in the the chat on Zulip uh I think that it will be really interesting like the the definitions and to see the the progress how it how it is and any reaction anything that you would like to share uh it would be really precious here. So don't hesitate to just like um open the open the mic and ask questions if it's okay for you. Um okay so yes Quentin do I give you the pointer or to Marion?
Quentin Lampin: I think we'll do like a two-heads presentation but I'll I'll start talking.
Alexander Pelov: Okay, so I'm passing uh okay I'm passing you the control so you can change the slides.
Quentin Lampin: Yep and here we go. Alright. Um so the objectives for today uh are this. Uh we want to just remind what the objective of the design team is and then get to the definitions that we currently have in the document. Uh most of them are uh the fruit of a very long discussions uh on each of the definitions. Uh don't hesitate to challenge them. Uh we know that it's not always easy to to find something that would accommodate all of the use cases all of the corner cases that uh we have discussed so far. So again, don't hesitate to uh to interrupt and to ask questions. And uh we provide two simple use cases uh that we used to illustrate how those definition fit into the big puzzle of of this architecture. And then we have a focus point uh we think that uh we need your uh advice on this part uh which we'll discuss later. Uh this is on routing datagrams to instances. And then obviously uh we want to collect your feedback your questions so we can do a better iteration next time we present it to you. Alright, so coming back to the very very simple definition: what is SCHC? So um I think there is not much discussion about it but yeah really this is something that performs compression and decompression and optionally fragmentation and reassembly operations and we use a static context shared between well the different endpoints the the parts that will perform those actions on devices. So we need to introduce uh some new definition, some definition that we've already discussed before but just to provide the the whole picture. So the endpoint is a logical entity that provides SCHC functionality and that basically will be hosting uh the actual running code that will do SCHC on a device. And uh what we want to say is that there is a a distinction between the supporting hardware and the logical entity that will live on the hardware. Uh obviously in the case where we only have LPWAN IoT devices this makes no sense to to make this separation because obviously we're going to have a simple C firmware and everything is going to be bolted uh in the firmware but since we want to extend beyond that beyond the simple LPWAN use cases we have to account for the fact that this could be hosted somewhere in a cloud uh in a container or virtual machine somewhere. Uh inside the endpoint we are going to have instances so an instance is well it's just a logical component that will perform the actual SCHC operation. And obviously since we've already discussed that with the endpoint we can have multiple instances that will coexist on the same endpoint and sharing for example the same network stack. What we want to emphasize is that we state that the instances is acting independently of the other instances that will be on the same hardware. And for that it will have its own context and configuration. Uh again, basic uh stuff for for you guys. Uh what is a rule? Well uh you know that this is the description on how SCHC is going to process a packet according to what's inside the the rule. And what is a set of rules? Well it's a collection of such rules. Um something that we wanted to introduce quite early in the discussion: the stratum. Because we believe it's very helpful for explaining rules. So a stratum is what we call a background concept. It's it's used to actually explain it's it's not something that will be implemented um and the best definition we have so far is that this is a portion of the network protocol stack that will be targeting by SCHC by an instance. And uh currently we only have the case where uh this this part of the network stack is contiguous layers. Uh we haven't seen a use case for having different protocols that would be separated apart the network stack. But again, if you have something in mind don't hesitate. Alright, what is a context? Um a context is primarily a set of rules but uh we think that we need more than just a set of rules we also need metadata. Uh for example we might need at some point in time to refer to a data model to say uh how to interpret the context or to define a parser that would be compatible with the rule format that we've chosen. Uh we introduced something a bit new uh which is the instance configuration. Um what is the instance configuration? This is configuration that would be specific to an instance and that would define how SCHC operations are performed within that instance. So that might seems a bit vague so just to provide a a very simple example. Uh when we have two instances uh that exchange well SCHC datagrams we need to say which one is the uplink or the uh let's let's call it the device or the gateway for example. So which one is up which one is down. And we believe this this is part of the instance configuration. And also this could extend to for example defining the matching policy: do we pick the first rule that matches or do we pick the one that maximizes the compression for example. Alright, a few more definitions before we provide an example. Uh a session. So a session is a communication session between two instances and uh really what defines this session is a common context. And lastly the datagram. So the datagram is the unit exchange between SCHC instances. So when we decided for SCHC datagram uh we had to review what we said before. So we have in I believe in 8724 we've introduced the notions of SCHC packets for uh the result of compression and decompression and fragments for obviously fragmentation and reassembly. So datagram is just a generic name for those two cases. And obviously the datagram also includes the rule identifier that defines which sets of operation have been applied to the uh to the packet and also optionally the payload if there is any left after the operations are are processed. Alright, so moving to the scenario number one a simple LPWAN case and and seeing how all of those notions all of those definitions fits into this very simple use case. So this is really 8724 as you already know it. So we have two endpoints. On each of the endpoint we have a single instance. Um those two instances they have their own instance configuration which is bolt-on uh one is hardcoded to act as a device and the other one for example is hardcoded to behave as a gateway. And they share the exact same context which define how packets for example are compressed or fragment. And obviously those two instances they share a session and within that session they send datagrams (sorry for the typo) over the L2 and then the the physical layer and etc. So really in this case um we have really a single instance that runs on each endpoint. Uh the rules are defined in the instance configuration but there is nothing transmitted this is this is just code that is written in the firmware and pretty much everything else is implicit there is no signaling required or anything else. And obviously don't hesitate to interrupt if there's questions. So we're moving to definitions that we believe fits outside of the the use cases of LPWAN so really that's what we address today in in SCHC the SCHC working group. So we introduced the the notion of the domain uh which we define as a logical grouping of instances that share a common set of context. So there's a plural there because we believe that might be interesting to have several sets of concept contexts within a domain but for now we only have illustrations for the case where we have only a single context. And within that domain we introduce a logical component that manages the the domain and that includes context synchronization between the different instances that are within the same domain and also configuration distribution. And that domain manager serves three functions: the one which is the endpoint manager basically this is where you would register the endpoints. It can be done by the endpoint or it could be done outside of the equipment kind of like a provisioning API. It's of the purpose of managing the context so knowing which context is deployed where. And it also have an instance configuration manager for example for telling to devices which role they should assume. Um on the endpoint side this we've also introduced what we call the instance manager because as we described before an endpoint could be the host of multiple instances and we need something that will manage the life cycle of those instances and their configuration. So basically any kind of like life cycle maintenance and configuration would be handled by this part. And we since we may have multiple instances on a single endpoint we need an entity that we call the dispatcher which is a component that will route route the packets to the appropriate instances based on predefined admission rules. So really the idea is that if we have multiple instances how do we route one packet to instance one or instance two for example. This is really the function of this dispatcher. Um oh and obviously we also need something that the dispatcher will use to do this routing dispatch between different instances and obviously we define the discriminator which is what we call an info optional information element that can be something that would be added to the SCHC datagram but that could also be something that is not in the packet itself. It could be for example a network interface ID provided by the network stack for example all of the packets coming from this network interface is going to be routed to this instance and etc. It could also make use of some transport protocol or some multiplexing protocol that would be already present such as MPLS for example a label from MPLS or it could reuse a port number for example a UDP port number and etc. Okay, so with this new definitions expanded definitions we wanted to explain why we need for example domain managers and and such and the the simplest use case we found to to explain that is is this very simple scenario where we have one gateway that will serve two IoT devices with different contexts and those two context contexts are going to be managed by different tenants. So this could be for example the case where you have a network operator that provides a an LPWAN network and each of the customers will be able to provide their own sets of context and they will operate them independently. So in this case you have three endpoints A and C are the IoT devices and B is the gateway and you have two domains that live in endpoint B because there is one per IoT devices. And in this very simple case the discriminator itself is supposed to be provided by the L2 for example (the DevEUI if you use a LoRa). Okay, so again if there is any question don't hesitate. Um so now a focus on on a current discussion that we are having in the design team. This is the the case where we need to route datagrams to different instances. So really the the core problem that we're trying to solve is this: the network stack is receiving SCHC datagrams or packets and the questions that we need to solve is to which of the instances can we route the packet or the datagram. And obviously you would say well that's the role of the discriminator but then how do we solve this if there is no explicit or easy discriminator that we could use. For example there is no MPLS label, there is not an ethertype that would indicate which instance to use, there is no UDP port that we can use to do that. Obviously in the solutions there we could introduce what we call a SCHC control header so that was already introduced in the previous architecture document that would provide a quick and easy fix for that. Or and that would be part of the question we could also use a standard protocol as well. We could say for example if we have multiple instances we could reuse some kind of multiplexing protocol that already exists within the specification of the IETF. Um during our discussions this is not the single I mean there's also there are also different challenges or needs that we've identified beyond just routing datagrams but that we feel are somewhat related which is the protection for example a checksum that for example could not be provided by some kind of underlying layers. There's also the question and that's something that really is linked to the draft-ietf-schc-protocol-numbers document: how do we save or back up information that would be replace or changed by SCHC operation. So for example if we change the ethertype value to that of SCHC it means that we've lost the initial ethertype that was present. So how do we restore that? So this is a proposal one of the idea could be to just provide all of those information in a specific control header that we could call the SCHC control header. Really what we want to emphasize is that this this needs to be a standard format, this needs to be a protocol that is standardized by the IETF otherwise this if it's provided by every implementation then we're pretty sure that this is not going to be interoperable. So yeah so the pending issues where we at at the moment in our discussions we've discussed those three points: routing to and from instances we've discussed that already. There's also the question of how do we integrate integrity checks what we call a SCHC checksum when there is none available that we can rely on and how do we pass metadata such that for example we can reconstruct content that would be modified by SCHC and in this case the ethertype. And so we have questions open questions for for you guys and that we will replicate on the mailing list. Do we want to specify a SCHC control header for those cases? Do we want to reuse an existing transport or multiplexing protocol especially for example for routing dispatching messages to instances. To us it looks a bit like a UDP Lite that we would need especially when we introduce also the need to have checksums for example. Or do we want to define this so if is there any existing transport protocol that would fit the bill or do we need to define a minimal transport protocol for SCHC? Yes, those are the the open questions that we have so far. Um again to be discussed on the mailing list and again thank you for your attention and just to remind that this design team is not closed it's actually open to the new participants. So if you want to join if you want to discuss all of those topics don't hesitate. Well thank you. This is this was the presentation.
Alexander Pelov: Thank you very much. Thank you Quentin. And thank you for all the work and all the examples that you have provided. Uh and I know that with Marion you did a you worked a lot even even today to to make this presentation possible so thank you both for that work. Especially also Marco that provided some discussion for all of this...
Quentin Lampin: Alex, sorry um something is cutting. I'm not sure if it's on my side.
Alexander Pelov: Oh, sorry.
Quentin Lampin: No I was just saying and also Alexander Pelov for providing all on insights and all the super interesting discussion that led to this document.
Alexander Pelov: No. Thank you. Thank you Quentin. Um so Marco it's like a strange day in May with a lot of holidays all around Europe and I think I sent quite late the the announcement for for today's meeting. So today you're the main public. Um we're are i- do you have any any input that you would like to to provide like at at this time?
Marco Tiloca: Yes, and thanks for the good work Quentin and Marion. This is great. And I haven't taken part in the design team meeting so the few questions comments I have can be obvious but just bear with me. It's mostly in the first part. I was wondering on how you can identify a few things. I noticed out of the whole set endpoint instance and stratum. Do you have canonical ways to identify those by an ID a tuple whatever?
Alexander Pelov: Uh sorry, yes Marco. Uh yes, so there is a is there a canonical way to to identify them? If I...
Marco Tiloca: Yes, endpoint instance and stratum I notice. I mean the rule for example has its own rule ID. Do we have equivalent concepts to identify some of those definitions?
Alexander Pelov: Hm, that's a good question. So uh go ahead Quentin. Yes.
Quentin Lampin: Yes, excellent question and actually one of the discussions also focus on how do we route datagrams (packets) to instances and part of... Quentin, I- just Marco, is it just a question? I hear Quentin cut. Is it on my side or is it... No it's breaking up for me too. It's breaking. Yes, it's breaking. Quentin, you're... we're hearing you you're breaking up like we hear like every every second every other word. Which is strange because during the presentation everything was perfect you know so... It's just my microphone that has been exhausted for me talking. I'll change the configuration. Sorry. I'll let you answer.
Alexander Pelov: Okay. So while Quentin is changing the configuration maybe uh we can provide some um Marion, yes?
Marion Dumay: Yeah. Hello everyone. Uh while Quentin is is fixing the mic. Um yes of course some uh of the components uh may need to have an id an identifier sorry. Um such as when you have um for example an endpoint with... it's what okay it's I wanted to go to the slide where there are the domain managers and the three endpoints two devices and one gateway you know. And when you have like several instances below the belonging to different domains uh you might need to identify maybe the sessions with session IDs and also instances and endpoint uh might need to have also IDs uh for example for uh management purpose.
Alexander Pelov: Right. So some kind of ID that is just well understood. Alexander, I think yeah there's some kind of an echo maybe. Oh, sorry excuse me I forgot my mic turned on I was typing. Sorry.
Quentin Lampin: Uh I'll try speaking again. Is is this better now?
Alexander Pelov: It works. Yes.
Quentin Lampin: Okay. Um yes so you're right and Marion mentioned the the need uh to have session IDs for example. Um but basically this this is the issue that we are also having uh when we're discussing the focus on routing to instances we need somehow a way to uh to tell uh the other end of the communication which instance uh should uh do the job. So this could be a session ID. Uh this could be part of the rule ID for example a prefix to the rule ID that would be targeting a specific uh instance. But uh definitely this is the problem that we have we have in mind. Um one solution could be to introduce kind of like a a small label that uh would be uh configured uh with the context and telling all of the uh endpoints sharing the same context this is this is the label that you should add uh such that the the datagrams are routed correctly.
Marco Tiloca: Thanks and for stratum by the way I think it's actually easier. You just list the layers composing the stratum and there you are you identify it.
Quentin Lampin: Yeah, totally.
Alexander Pelov: Yeah. Except in the case where you have for example IP in IP or stuff like that where you could have weird effects. But yeah in most cases this is right.
Marco Tiloca: Thanks. And another question when you introduced the concept of stratum I think I read uh it's about contiguous layers. Uh so that can mean different things. Uh I suppose you mean you name you identify a stratum listing the layers that compose it in the order they appear in the stack but that doesn't exclude the case where you have in the stack additional layers that are just not operating SCHC right?
Alexander Pelov: Marco do you have an example of such a use case?
Marco Tiloca: For example think of UDP IP 15.4. Uh say that you want SCHC at UDP and 15.4 but not IP. What's your stratum here? UDP and 15.4?
Marion Dumay: And yes and also I think it does not appear in the in the definitions but the um there is a correspondence between the stratum and the the rules the structure of the rules. Um for example if you want to if SCHC operates on the UDP and and 15.4 layers you will have in your in your rules the field descriptions of those headers only and it it corresponds to the stratum uh which is um on which the SCHC processing is applied right? Is there's a correspondence...
Alexander Pelov: Yes. So basically the two layers are still continuous but they don't have to be adjacent like UDP and 15.4 there's IP in between that you are not using but that's still fine because UDP and 15.4 are not adjacent but they are still contiguous.
Marion Dumay: Um yeah I believe that the fields the headers yeah I don't know the go ahead Quentin.
Alexander Pelov: I I have a short question. Sorry uh Marco uh when you say UDP and 15.4 how does you mean UDP running directly on 15.4 without IP?
Marco Tiloca: With IP but you don't do SCHC compression at the IP level.
Alexander Pelov: Ah but then just one question wouldn't that be two strata two strata so one stratum that is the compression on 15.4 and one stratum that's on UDP?
Marco Tiloca: Oh, that's an interpretation. I thought I had one stratum of two consecutive but not adjacent layers.
Alexander Pelov: Uh because if it's so just and bear with me and and I'll leave the word to Quentin and Marion wouldn't that mean if if you have one instance that compresses like the whole the whole thing so it compresses 15.4 and UDP basically it works it works on the UDP the IP and so it works on the 15.4 the IP and the UDP layer part all the three but it keeps IP uncompressed.
Marco Tiloca: Mm-hmm.
Alexander Pelov: So basically the stratum would be 15.4 IP UDP.
Marco Tiloca: Yeah, that was my question. Uh how many strata do we have there one or two?
Alexander Pelov: So... okay so go ahead Marion. Yes.
Marion Dumay: Short answer I'd say two. Um yeah I think it's in relation with how you build the rules. Uh you might have two set of rules for this use case I think one for compressing the 15.4 and another one for the UDP and so they are two separate SCHC operations and they belong to different stratums strata in my mind. But maybe Quentin has another answer I don't know.
Quentin Lampin: No, it I believe this is one of the two options that you have actually. You could also define a sets of rules that would have 15.4 headers fields that would be listed and then IP and then UDP and you would just use ignore not ignore value-sent for all of the IP fields. This would be a valid a valid rule that would be a single stratum and that would address the whole 15.4 IP UDP protocols and yet only do compression on on the parts you want. So but my understanding is that defining a rule that would not mention IP in between 15.4 fields and UDP I'm not sure that this would be admissible as a SCHC rule a valid SCHC rule because the the matching policy is that all of the fields presented by the parser should be present in the rule as well. If that makes sense.
Marco Tiloca: It makes sense but then in that definition of stratum I think the layers have to be not only contiguous but also adjacent to be part of a single thing that you call stratum as a collection. So you cannot have holes that you skip in the stack.
Quentin Lampin: So what you say is that when when I described it I said I we don't have a use case where we would like to do that and you just provided a counter example. So great. Let's discuss. But then it's consistent with the examples we were doing because either you cover all those three layers and you have one stratum covering those and they are contiguous and adjacent or if you decide to exclude IP well then you are forced to go for two different strata one with UDP and one with 15.4.
Quentin Lampin: Yes. Yeah you're right. So it's contiguous and adjacent layers.
Marco Tiloca: Yeah, exactly.
Quentin Lampin: Great.
Marco Tiloca: Great. Uh yeah I noticed another little thing in the definition of session. Uh I guess also in the interest of the examples it mentions um with two instances uh so is that limit intentional or is it just the simple case for the sake of examples? Because I think of group communication uh where you may have well more than two instances one at each endpoint say and you want to yeah form a group.
Quentin Lampin: So I'm I would probably say uh it's a copy-paste error um in the previous definitions we had we had between two instances or more. Oh no that's no no you can have sessions with more than two instances.
Alexander Pelov: Or am I misunderstanding the question? No. No no I think the English is a little bit the wording in English is awkward you know because when you say between two instances the brain I also thought this the brain says okay two instances only but then it's or more so it should be two or more instances.
Quentin Lampin: Alright. Pardon my French.
Alexander Pelov: I I mean I understood Marco's question because I also I also saw the slides that wait we did not say that it's only two instances and then I see oh yes there was that thing. Um yeah.
Quentin Lampin: Okay, duly noted. We need to update that text.
Marco Tiloca: Um yeah the last point I have at least for today was a general consideration on the final open points. Uh I don't know the full offer from the IETF about possible protocols to reuse or to take inspiration from. So I would say if a SCHC control header would work fine uh possibly taking the old one from the architecture document as a starting point why not trying with that? And only if that happens to be limited well let's open for a whole protocol. If a header is enough I think it's preferable.
Marion Dumay: Well thank you for your opinion. Um we might keep both. We have not decided yet. Um we believe that some kind of transport protocol would be better uh for the integrity uh needs. Uh yeah you might want to to add only maybe the instance ID or something to do a very small to add a very small discriminator but the yeah it's it's kind of dirty. Um yeah I'm sorry. Uh so the document yeah we could we could say in the document maybe if some kind of control structure is needed it can be it can use a specific custom structure called the control header and it might be better to use either an existing standard protocol and another one another proposal was also to design in the working group uh this lightweight transport protocol and to refer to it in the architecture document. And we we believe it's something that could be written quite fast in in a short document.
Marco Tiloca: Mm-hmm.
Quentin Lampin: Yeah, additionally um the reasoning behind the idea that transport might be interesting to to consider uh if we want to to keep kind of like a if we want to to keep compatibility with 8724 devices then somehow the only place where we could add this new information is is either before the the rule ID or after at the end of the packet but that would be strange um and then prepending something to the existing SCHC datagram uh opens the door to just like define it as a very simple even minimal transport protocol. Also this would make the architecture a bit simpler because we could just remove that discussion from the architecture altogether and say we suppose that we have some way of multiplexing of tunneling uh the traffic between instances. It's either provided by an underlying layer if it exists already or it could use such a protocol that we want to define or we use uh if we need to introduce one. Um so this is this is the rational that explains the the answer that we provided with Marion. Uh also the question is and that's something else um what is the full extent of the requirements for this small control header. What do we want to introduce? So far we've identified three requirements: the one that is just a label a switch to to tell which instance uh should process the packet further, there is the checksum, there is the metadata or some kind of information that we might need alongside the SCHC datagram to reconstruct the original uh packet or data. But we might want to to think about what else we would need because we're not sure that this is the complete picture.
Marco Tiloca: Mm-hmm.
Marco Tiloca: And and with that in mind about reusing an existing transport protocol have you already identified any possible candidate or this is just a very open question?
Quentin Lampin: Uh right now this is a very open question but what what was really striking at least to me is that with some I mean this this session ID it to me it looks like a UDP port and and since we've also identified the need to have an integrity check really that's a checksum so two of the four fields of a UDP are already present so there's one port and there is a checksum and somehow if we need to also add a length somewhere then we're getting very very very close to what UDP for example is doing so I don't know. I'll let Alexander provide personal his opinion.
Alexander Pelov: Yes. Thank you. Yes Marco I mean I I would be a little bit you know I I think that we need to be pragmatic you know and I understand of course the point is like if the underlying protocols can support some of these features then you know we should not redevelop them um but we also need you know to to answer to like if someone needs this functionality and there is the 18.2.15.4 SCHC that needs some of this functionality so we need to find a way to provide it. Um so you know and it maybe goes to have some kind of a some piece of information like the SCHC control header or something. Um I had an idea that came to my mind and I'm just sharing it with you three uh when I was looking at the presentation: how about we specify a container so it is the part that we call today the the SCHC control header and in the architecture we simply say well if you need to provide like an additional protocol information or or additional data such as the three things that are here well um you you put that information in this container like let's say after the rule ID uh like in the that container is defined in this way. I mean that many bits it can be in the rule ID or anything. And then we leave that open we can provide examples. So that container can be like UDP lite uh it can be UDP lite compressed with SCHC you can it can be anything. It can be some very advanced protocol that is that is put in in that container like so basically you're piggybacking no you're not only piggybacking yeah but it's really the SCHC control header the control header container I don't know. Uh and then we leave it like it is as it is and then we can have like a separate document that actually says well you know uh in in that the document will be because we have in in our working group charter we have draft-ietf-schc-schclet we have an working group item to produce a SCHC header so we can do that for let's say for eth- we can have one document for Ethernet and that says well for Ethernet that works like this and is is that many bits and uh things happen like this and it's a very specific SCHClet. Um Marco I'm not sure if it makes sense to you uh Marion...
Quentin Lampin: No, it totally makes sense and actually having kind of like a placeholder that says uh if in need of such features then this is where we should prepend uh this information and then say well how this is going to be implemented is somewhere that goes beyond the the SCHC architecture and then discuss uh what or how we populate this container. I mean to me it makes complete sense. Just my opinion yeah. I really like the idea.
Alexander Pelov: Yes and okay so Marco he says like can be a SCHClet. Um yes that can be a SCHC- exactly. Oh yes thank you Marco I understood what you're saying yes. Uh yes that could be a SCHClet. So the SCHC so that the information that that is that goes in this container it can be a SCHClet. Yes you don't need of like a full SCHC there. Um so basically what it means is that in the architecture we need to provide a a way to like we say okay there is a placeholder here and you need to know that there is a container there and you need to know your the size of that container so how many bits is it and how to process it. And then and then there's a separate document that actually says well you know uh in in that in then the document will be because we have in the in our working group charter we have a SCHC header we have an working group item to produce a SCHC header so we can do that for let's say for eth- we can have one document for Ethernet and that says well for Ethernet that works like this and is that many bits and uh things happen like this and it's a very specific SCHClet. Um Marco I'm not sure if it makes sense to you uh Marion...
Marion Dumay: Um it needs more discussion okay.
Alexander Pelov: Yeah. It definitely we'll continue to discuss maybe on the mailing list but um yeah I think the architecture the document uh maybe should not specify this specific format of the control header or whatever but rather define the the functional requirements and then and then to points to point to the specific documents for the specific use cases or protocols. Um because I mean you know there is okay uh it is no it's not what you had in mind? Yes yes yes no but I was think so yeah it's we're soon at the hour so I'm not maybe it's not a good time to start a huge discussion about this. It's the point I wanted to say is that we I think that in the architecture what we need to ensure is you see the question from Marco was when he said okay is there like an instance ID. So how how we identify to which instance a SCHC datagram should be routed and we say okay well that's the discriminator but uh you know if let's say that your SCHC endp- like you you're listening on Ethernet you receive a an Ethernet packet with ethertype SCHC so that gets sent to SCHC and how does and there are several instances running. One instance is compressing IPv6 one is inst- instance is compressing IPv4 uh and one instance like something else right? So how do you know to which instance to route that information. So typically I put that in the SCHC in what we call today like in the past architecture the SCHC control header. Uh yeah yeah yeah I see you what you what you mean but okay we definitely need to to discuss this more. Yeah I mean we need to put something there right to uh... okay yeah. So uh Marco thank you very much for taking all the notes um and huge thanks for for the input and for the discussion um and if you have any ideas or any questions or you know or if you want to participate in the discussions at the design team you are more than welcome. Um yes and I I think that we are adva- like we have the major questions that are behind us with these definitions and with this uh like with this baseline so we'll be able to produce a much more advanced version of the architecture soon at least before IETF 126 that's for sure. So yes thank you all for for your participation today thank you Marion Dumay and Quentin Lampin for all your work on the presentation and on the document of course until now um and see you in two weeks time. Thank you. Bye-bye. Bye-bye everyone. Bye bye.
Alexander Pelov: Bye.