**Session Date/Time:** 23 Jun 2026 14:00

**Marion Dumay:** Hello everyone.

**Alexander Pelov:** Hello.

**Marion Dumay:** Hello everyone. Good afternoon.

Well, it's 5 minutes, 5 minutes past the hour, so I propose that we start.

**Alexander Pelov:** Okay. Go ahead, Marion. You want to do the intro?

**Marion Dumay:** Um, no, that's okay. Um, okay, so as usual, uh, this is an official meeting of the IETF, and the meeting is being recorded, and um, so by participating to this um, meeting, you agree to follow the IETF processes and policies, uh, so including about uh, conduct. Participants are expected to behave in a professional manner, and extend respect and courtesy to their colleagues at all times, and about uh, intellectual property, property rights. If you are aware then that any contribution is covered by patents or by patent applications that you, that are owned by you, your employer, or your sponsor, you must disclose the, the fact, or not participate in the discussion, okay? Uh, and so you are encouraged to read the, the source documents, uh, to which the Note Well refers, uh, and they can, they can be found in line, online by scanning the QR, the QR code. Um, if you have questions, don't hesitate to talk to, to the working group chairs, uh, or to the area director. Um, okay, let's move on to the agenda. Um, so as usual, we are going to go through um, the working group document status. Um, and after that, um, we will have two presentations. Uh, so the first one, uh, will be presented by Lorenzo Corneo. It's about uh, SCHC payload compression, and the second presentation uh, from Alexander will be on uh, SCHC Header Format, uh, and SCHC Shapes. Okay, and in the end, we, hopefully, we will have time to discuss any other business.

Alex, do you want to do the um, uh, document status?

**Alexander Pelov:** Um, yes, thank you very much, Marion. Um, so, uh, it's a little bit tiny, um, but we have quite a lot of documents. Um, so, the, the, the work is progressing well, um, I'm advancing pretty well with the shepherd write-up of the update of RFC 8824. Um, so, um, I've, all the authors confirmed by email, all the information that I, uh, that I needed, and uh, I got this information today, uh, I think I'm, I'm waiting also for Ivan to, to answer the last question, or I think he answered, I'm not sure. Uh, but anyway, I'm going to see this and uh, other than that, I think I'm ready for the write-up, and so, I, the document is ready to ship, um, and I've also requested, um, an early, um, review from the Yang Doctors, uh, for the Yang data model, and so, we'll see, you know, when that arrives. Um, so, uh, it's a little bit complicated to work during the day here, uh, with, you know, with all the, the, the management of, of the heating, of the heat wave, um, so, I'm not going to be, probably not going to be able to finalize that in the next 1 or 2 days, but definitely like in the beginning of next week. Um, yes, Marco.

**Marco Tiloca:** Alexander, uh, thanks a lot for the shepherding work and for your review, and your comments. Uh, you have a very extensive reply on the list and PR number 1. And then, I also sent another shorter mail to the list on the two small fixes that I described there, for which there is a separate PR number 2, that was about 1 week ago, so absent objections, in the next few days, I was planning to submit uh, the resulting merged version 9, and then, you can take it from there, but it's basically about those two PRs.

**Alexander Pelov:** Uh-huh. Uh, yes, thank you very much, Marco. Yes, I, I, I glanced through the PR request and, and, and yeah, it, I didn't write anything back, sorry. Sorry about this, but, uh, yes, it, it responds to the, uh, uh, to the, the things that I found and, and you, you, you found some other things as well. So, uh, uh, so yeah, I mean, the document is in, seems in, in really great shape. Um, and, uh, yeah, so I'm, I'm finalizing the, the shepherding write-up and I said I'm, I'm going to, uh, to, to end it by, yeah, beginning of next week, so it can go into, you know, it can leave the working group.

To confirm with you, do we need a presentation in Vienna? I mean, probably not.

**Marco Tiloca:** You tell me.

**Alexander Pelov:** Uh, that's a good point, uh, so we'll start, uh, uh, request for slots, um, uh, in beginning of next week for, for the IETF in Vienna, and, uh, hm, that's, that's a good point.

**Marco Tiloca:** Well, I, I wasn't thinking to, and even if we had one, it would be what I sent on the mailing list, basically.

**Alexander Pelov:** Yes. Um, so for the moment, uh, maybe not, I'm not, I'm, I'm not sure, uh, I, I'm not sure. No worries. I, I wouldn't, probably a short right, a, a short update of, of the things, if, if, if time permits, you know. Uh, because it's, it's, it's a wonderful work. So, um, so yeah, I, I...

**Marco Tiloca:** We can decide in the next few weeks, either works for me, anyway.

**Alexander Pelov:** Yes. Uh, okay, so, that's, that's, that's great. Thank you, Marco, for all the amazing work you did on, on this document, um, and, yeah, it, it's a really consequential work. Um, and, uh, uh, I, I, I think it's, yes, so that's, that's on this document. Um, on protocol numbers, I know that Laurent is, um, also, uh, advancing with his shepherding write-up, uh, but probably, you know, uh, we are also working on the SCHC Architecture, we want, we really want to ship it before the cut-off so that we have the full presentation, and uh, yes, we don't, we don't have this actually, uh, here, I forgot to, to mention it. So, uh, uh, we, we discussed with Marion, and uh, we'll be organizing a side meeting, uh, so, as you probably saw, uh, the SCHC working group meeting is on Friday afternoon, well, the first slot in the afternoon, so, um, yeah, it, it, it's not ideal, but, uh, it's, it's a good slot, uh, anyways. So, we'll be organizing a side meeting, uh, somewhere in the beginning of the week, so that we can, we can actually be working on the SCHC Architecture, uh, because, like, it's, it's, it's almost done, we've really did, uh, uh, a great progress, but it, it's good that we have some core cases that we would like to discuss with, with everyone so that we, uh, so that this, so that the work is really, um, finalized. So, we'll be organizing this.

Um, and, uh, yes, so, that's all for me. Um, I don't think we have any, I have any other points here. So, uh, Lorenzo. Lorenzo, um, the floor is yours, uh. Okay, Marion, you're, you're doing the... Go ahead, Marion.

**Lorenzo Corneo:** I think I need control.

**Marion Dumay:** Yeah, I just know how to do that yet. Um, Alexander, can you help, um?

**Alexander Pelov:** Yes, just, just did it. I'll show you first.

**Lorenzo Corneo:** Yeah, yeah, yeah, I think it works. Yeah. Thank you both.

Yeah, so, um, this is Lorenzo and, yeah, this is, um, an update on the work that we have been doing on the SCHC payload compression draft. Uh, so, the, the purpose of this meeting is that, uh, we have been internally working at some major uh, structural changes, uh, in, in the draft, uh, but of course, the, the scope of, of the work is, is the same, so, about, uh, reusing the SCHC framework for compressing also the payload. But, uh, before doing and, and submitting a new version, we wanted to discuss these changes with you and also, uh, getting your, your feedback.

So, uh, what we want to remove in, in the next version. So, we, we started the, the first two versions of this draft by having uh, two type of compression for the payload, one static approach and one dynamic approach. But then, uh, when we started thinking about implementers, then it was clear that, uh, the normative uh, aspects of the draft were kind of hidden, uh, in, in, in the methodologies for doing the compression. So, to do that, um, and to improve that, we thought that maybe we, we, we remove some of this, um, of this, uh, information and we highlight more the, the, the, the normative aspects. And, the rationale for reducing this part is that, uh, the dynamic approach, as well as also, you know, the static approach can be, uh, documented in a separate, uh, document, like, for example, informative, or even standard track depending on, on what is going to be, to be there.

Uh, and then, what are these normative aspects that we wanted to highlight more? So, uh, first of all, we would like to propose a new matching operator, which we just named `equal template` and, of course, if someone comes up with a better naming, we are happy to, to implement the change. But, the idea is that this new matching operator, uh, will be able to evaluate equality between field values and the templates that can be stored in the Target Value. Um, and, and then, yeah, the matching procedure is pretty similar to, um, to, to the standard one in SCHC, but of course, this should be adapted slightly to, to, to the use case of, of payload, and the procedure would be that we parse the template, and then we identify the fixed parts, and we discern them from the variable or functional parts. Uh, let me get there, uh, a bit, uh, later in this presentation.

But, the idea is that, uh, here you see this very simple, uh, JSON object that could be an example of payload, and then you clearly see that there is a fixed part, which is fixed in this case, and also, you know, the colon, and the, uh, curly brackets, and then we have this, uh, special character, uh, dollar sign, and variable, so, that would be the variable part, and all the rest would be the, um, the, the fixed part. And then, of course, we can perform bitwise uh, matching on, on the fixed portion, and we can remove from, from the matching all the variable parts that are delimited by this special character, or sequences of characters, we are open about that, we can discuss that at the end. And then, when all the fixed parts match, uh, then we have a match, so it's true, otherwise, uh, the matching doesn't happen and we can go to the next rule.

Um, then also, what we are planning to, to add to, to the new version of the draft is how we encode uh, the residue uh, for, for the payload. And here, um, before we had only, um, this special character and the position in, in, in the template, but now, we, we, we think that we should also add the length, so we will use this notation like special character `N` signaling the position within the payload, uh, or the template, and the length, um, and, and yeah, you, you, you can see an example, so, the first, uh, position in the template could be 10 bytes. Um, yeah, so, the values, um, are supposed to be shorter than, than, than the declared uh, length, so that you have some, some margin for, uh, for, for extending the, the length of, of what you want to encode in the payload, and of course, we can right-pad this, this, this values with zero, and, uh, and then, the, the compressor can strip out these trailing zero bytes, and, and then just fetch the, the payload, and the good thing is that both compressor and decompressor know the template, know the length, and therefore, this should be, uh, any issue in compressing and decompressing the payload once the template is matched. And, yeah, also, there should not be changes to the basic SCHC rule from, from the RFC.

And then, yeah, and then, so, this is where we, we said, okay, we kind of remove the dynamic payload approach, but this feature is what still enables to perform dynamic compression. So, here, we, we thought, okay, we can introduce a keyword, like, for example, `payload`, to be inserted in the Field Identifier. And, this keyword can work with a template or without a template. In the case of a template, it is like we, we have done before, so, we encode the template in, in, the Target Value, uh, and then, we do the matching with the equal matching. Otherwise, we do not need the matching oper- operator, but we can still specify um, payload compression, uh, without using the template. So, the idea is that we enrich the Field Identifier with the keyword, plus some semantic that can be used for doing compression and decompression. For example, one way to put it is that, hey, we, we just write `payload` as a Field Identifier, and then we add metadata like, uh, colon separated metadata, for example, we can add media type, the group, or the, the position in, in, in an object, and then, uh, the field, the name field. Uh, so, if we translate this into a concrete example, we can have `payload`, and then we can sign- signal that the object that we are trying to reconstruct is a, application JSON media type, uh, we can say that whatever is uh, matched and compressed or decompressed is part of the first object, so object number 1, in our payload, and the name of, of the field, uh, that we want to compress or decompress is ID, and this works very well with key-value based format, like, for example, JSON. Um, yeah, and then, um, yeah, thi- this is, is a way for which we can encode payload using both template, but also without template, for example, simpler cases. Um, so far, um, we have proposed this, uh, type of semantic encoding in the Field Identifier, but so far, we have not thought about the fact on whether it should be normative or not, so, this is also, uh, up to discussion, uh, at the end of this presentation. Yes, Alex, yeah.

**Alexander Pelov:** Um, yes, would you like to take questions as the presentation goes or, wait at the end, maybe?

**Lorenzo Corneo:** Yeah, yeah, it's fine, it's fine, sure.

**Alexander Pelov:** Yes, okay. Oh, yeah, um, just a question. So, um, yeah, I, I see, uh, I, I see here the dilemma, and, uh, I, I see also like the full structure in the, in the target values, so that's, that's really nice. I have to read the latest version of your draft to go a little bit more into detail about the semantic, um, uh, interpretation, the semantic version of, of the payload keyword. Um, I'm not sure if you have, if this is in any way related to the universal option draft, SCHC universal option, um, you know, where there are the two types of, like, the, there is this, um, uh, approach where, you know, you can have, uh, like a description of the, of the fields that you're going to be compressing. Uh, and it, so I, I think this, what you're specifying here, it's a little bit, how can I say, not larger, but it's, it's, it's adjacent, it's, it's somehow related to this, uh, universal option. Um, I'm not sure if the draft as it is right now, universal option can cover the case that you're treating here. I'm not really sure. Um, I see, I'm not sure, Lorenzo, if you have any, any opinion on this. Um,

**Lorenzo Corneo:** Yeah, yeah, so, um, I should check the, the document you are referring to, because, I, I, I'm not aware of that, so. Of course, if, if, it can be, um, you know, uh, if we can reuse something, of course, uh, it's, I think it's better if we, than, then creating something new, right? So, um,

**Alexander Pelov:** Maybe there will be, there will be need for adjustment. I, I don't think as, as, as it is right now, the universal option, you know, that it can encode this type of information as it is today. Um, uh, but, but that's a thing that...

**Lorenzo Corneo:** Something that, uh, it can be covered in the universal option and, and then we can borrow it.

**Alexander Pelov:** Yes, maybe. I, I mean, uh, uh, Laurent is here, but I, I'm not sure we need to, to check, like, just a, a thought, like, it's not something that has to be solved now. It's, it's, just like, okay, there is this other thing, uh, you know, from looks from far away, maybe there is something in common. Um, so, yeah.

**Lorenzo Corneo:** Oh yeah, makes a lot of sense. I, I will check the, the draft and, and, and, yeah, I guess Quentin can, can go ahead now.

Quentin, we, we don't hear you.

**Quentin Lampin:** Oh no no, I was waiting for the, for someone to, to let me talk. Um, yeah yeah, um, I'm just reacting, uh, just on first impression, but I believe that, uh, what you're introducing is, is targeting a different, uh, at least in terms of semantics, it's a different thing that what we are trying to achieve in universal option. Uh, just for reminder, the idea behind, uh, the universal option is that, uh, protocols are going to evolve and new, uh, well, protocol options are going to appear, and the question is how do we, how do we, uh, handle that kind of situation. Uh, say, for example, CoAP is introducing a new CoAP option, and, and, and therefore, uh, it means that in the data model of SCHC, we need to introduce a new name for that option, and, and so, so we have to track all of the, uh, new protocol options basically. And so, the idea was that, uh, could we somehow introduce the, the idea that each protocol has a scope, uh, and, uh, there is a naming within the protocol, uh, for example, the CoAP options has a kind of like a universal CoAP, CoAP option ID, uh, kind of like a, a unique number that identify each. And so, the idea was to reuse that, to reuse that ID from, uh, the, the protocol, uh, to, to build, uh, the, the rules. So, I, I think it's somewhat related. I believe that, uh, there's, there is a common idea, but, uh, clearly what you're introducing is, uh, is targeting a different, uh, a different thing. But that, that seems interesting. So, yeah.

**Lorenzo Corneo:** Yeah, okay, uh, thanks for the clarification. I, I guess we can perhaps discuss this also offline and, and see whether we can have it fit in, in your draft, or otherwise we can... Yeah, because here the dilemma is, uh, so, if we make it normative, then it has to be that way. Uh, if it's not normative, then it's up to implementation, right? So, it's flexible, and of course, it might lead to, you know, inconsistent implementations, etc. So, I, I think this is a bit early to, to decide, but it's something that I wanted to, to flag, because I, I, I see both...

**Alexander Pelov:** Yeah, absolutely, yeah, let's, let's discuss this. No, thanks.

**Lorenzo Corneo:** Super interesting, thank you. Thanks.

Um, yeah, then I move forward, uh, and so, yeah, as promised, uh, I, I will elaborate a bit more on variable and functions, uh, so, yeah, before we had this positional, uh, variables that, uh, tells you where in the payload, uh, the variable part is, right? And, and before it was only, uh, position, so it was an, an integer, so, 1 comes before 2. Very simple. And then we had this repetition when, for example, in SenML you have, uh, instances of record, so, you might have multiple, but then you can just have one in the template with a repeat, uh, function and then, that means that you might have multiple of these. Uh, the changes that we are proposing in this new draft, uh, is that we use also the length for, um, binding, uh, well, the length of, of the variable field. This has the drawback that you might not squeeze it up to the bit, right, if, if, if you have, uh, I don't know, 10 bytes, right. Uh, and in the repeat, uh, we also add, uh, a separator now, uh, because, uh, otherwise, the, the decompressor might not know how to separate the fields in, in the reconstructed payload. And, and also, um, in order to mark this repetitions, uh, we have to encode the length, uh, so far we are planning, uh, uint, unsigned int, uh, 1 byte basically, so, maximum is, maximum value is 255. Uh, that might not be enough, so, something to, to discuss as well.

Um, yeah, and, and here, uh, a very quick example, so, there is the payload, uh, on top of the slide, um, so, what we are doing here is that we, um, can have either, um, yeah, this is how it works, right, so, you get, uh, the, the payload, uh, keyword, and then, we specify, specify the template in the target value, then we say that we want to perform a matching operation using the equal template, newly introduced here, uh, and then, here, the template can be this repeat, and then we have the fixed part, which is ID, ABC123 and value, and then, we have the variable part, uh, with this positional, uh, variable, number 1, and then, we are saying that maximum this field is going to be 4 bytes, and our separator is a comma and a space. Right? And, and the residue is encoded, uh, as follows. So, we get the length, uh, which is 2, bytes, and then, we encode, uh, as a string, the value of the variable part, which was this -11, and then, yeah, there is the other 4 bytes for, for 13, minus 13, because that is the, the second, um, uh, variable, uh, which is repeated the second time. Yeah.

And, and this is an example without the template, so, we are achieving the same thing, but by using this, uh, decompression semantics, uh, instead of specifying a template, we specify 4 Field Identifiers, encoded as, uh, I showed earlier, and, and here, we can, well, here we are also encoding the, uh, ABC, right, so, here we specify also the, the ID, uh, and then, the value, we just send it uncompressed, and then again, we compress ID, uh, the second time with the same value, and then again, we send uncompressed value, the second time. Um, yeah, and only on the other side, the decompressor will, will know how to put together, uh, the initial payload, because, hey, it knows that, uh, it's payload, and it is application JSON media type, and then, uh, the first object is done by this ID and value, value for ID is ABC123 and then the value is in the residue. And the, the same thing for the second record. Yes, Quentin.

**Quentin Lampin:** Uh, yeah, thank you. Uh, I wonder if that positional, argument, the 1, 2 and etc., can be achieved in the same way using the position, uh, in the field descriptor of the rules. Uh, so basically, you would have a single FID, which would be in that case payload application JSON ID, and then the, the positional, uh, value 1, 2, uh, could be, I don't know, using the position, ID in the in the in the, sorry, the field descriptor. Uh, does it make sense?

**Lorenzo Corneo:** Absolutely, yeah. And, and this is why, you already see the problem, right, here, because, so, if we make this normative, then... Yeah, I mean, maybe we can still do it, but we still need to have this, uh, 1 and 2. Um, yeah, otherwise, we can just pretend, okay, there's no repetition here and I can encode it value by value, no problem. Um, so, um, yeah, very good point and I guess this is up to discussion, uh, within the working...

**Quentin Lampin:** Yeah, yeah, that, that, that would be a nice discussion because in the, I mean, the position, uh, value of the field descriptor, uh, you have the zero values that says pretty much wherever, but, uh, I believe that in most implementation, that means that this field happened only one, once. Uh, and then, you have the position value, which could be 1, 2, and 3, and 4, and etc., uh, which means that the, the value is going to be repeated a number of time, and then, therefore, the question that I might have is this: are you planning to kind of like introduce, a, a, a template to say this is a number of repetition, and that number is not specified in the rule. For example, you could say my payload is going to be a list of records, uh, I have no idea how many records, uh, that will be in the payload, but somehow with a template, uh, I can, I can just say the, the residues is going to be N times, uh, that specific template.

**Lorenzo Corneo:** Yeah, that, that's very good point. I, I think it's actually possible because, uh, we are encoding the, um, the, the length of the repetition. So, on the other side, you would be able to reconstruct that and also, if you put some logic in the compressor, you would be able also to infer the numbers of repetitions and then you just encode it and it should be fine.

**Quentin Lampin:** Okay. Well...

**Lorenzo Corneo:** Yeah, but, good point. Thanks for bringing this up. It...

**Quentin Lampin:** Yeah. Oh, yes, thank you.

**Lorenzo Corneo:** Yeah, this validates, yeah, thanks, this validates even more that, yeah, I, I'm not fully sure, uh, this semantics uh, should be normative, but, uh, yeah, let's, let's sleep on it. Um, yeah, and then also, uh, as part of the new version that we're planning to submit, uh, so, so far we we had this, uh, specified this, uh, N variable and repeat function, but of course, it would be cool that this set of, of tools would be extensible, uh, and therefore, we were thinking about IANA registry where, you know, uh, new uh, functions and variable can be added, uh, if, if there is a need. Uh, I think that would be great. Um, and, and yeah, so, this is just a summary of the proposed changes, uh, maybe we don't need to go through, through that one, but, yeah. So, some reshuffling in, in the text, but the content is going to be the same, uh, more highlight on the normative aspects, uh, introducing this equal template matching operator, uh, payload uh, keyword to signal, uh, that there is payload, uh, changes in how we encode the residue for the payload, and then, adding IANA registry for, uh, new template, uh, functions and variables.

And, yeah, here, I, I think we already went through, uh, this, um, at least the most, uh, sensitive parts of, of this question, so, during the presentation, uh, and and then, uh, one last thing perhaps that I wanted to throw the working group for, was, uh, about working group adoption, for, for this draft. And, yeah, thank you, I'm, I'm done with the presentation.

**Alexander Pelov:** Thank you very much, um, very interesting presentation and very interesting work. Um, uh, I, I have like a, two, uh, uh, oh, one just like a question. At some point, I was thinking of actually defining, a, a function in SCHC that does JSON to CBOR. This is the only thing that it does, like, JSON to CBOR, and CBOR to JSON is the CDA. Um, so basically, you can have that.

**Lorenzo Corneo:** No, yeah, uh, I was actually thinking about this, but you can even have two layers of compression, basically, because once you have the context in, in, in the way we are proposing, you can even, you know, uh, have another round with CBOR and make it even more efficient. So,

**Alexander Pelov:** Yes, it, it, it, it becomes super interesting. Um, um, yes, so, I, I find that work very interesting, um, and, yes, you already presented that, um, during the, um, during the, uh, like, uh, a couple of, of, of meetings ago. Um, so, uh, maybe one thing, and, yeah, I see that there is really interest and there is support, and you are working on it, and, um, uh, so, I, I see the clear application for SenML. Um, so, maybe there are more general applications for that payload, um, so, maybe I would try asking the people that are here in, in, in the room, so, uh, how do you feel about working group adoption? Ah, okay, let me, I will start, we have a tool for that, um, and, and, yeah, Alexander, can you send the link, please? Okay. I'm going to start directly the, the, the point, the, um, tst, tst, hm. No, it's not point, where is the point? All right, here. Show of hands. Do we adopt? So, here it is, um, like, just, uh, initial polling to see, uh, how, what, what are the feeling in the, in the room. We will start, um, an official, after, one after one, in the, on the mailing list, just so that we can, we can see like, um, what do you feel, do you do you feel that this is a work that needs to be done at the working group? Um, and, of course, there will be things to be improved, the things to be decided during the, the, you know, all the questions that you have here, but that's a normal working group, uh.

**Lorenzo Corneo:** Yeah, yeah, absolutely, I mean, yeah, we plan to work more on this and we are very open to taking feedback and improve the, the draft even more. Thank you all, really, for this.

**Alexander Pelov:** Yes. So, so, there are seven votes, seven yeses. Um, I, Marion, I think that we can take this one, okay, eight yeses, so, everyone is, um, everyone is... So, this removes all anonymity, but, uh, yes, so, everyone that is presented here, that is present, is for the adoption of the document. Um, so, of course, we'll confirm that on the mailing list, um, and, uh, I, I just would like to probably ask you a question is, would you like to keep the same name? Uh, because it's like `schc-payload-compression`, it, it corresponds to what it does today. Uh, it does seem to be, to have a very, very useful use case which is SenML. Um, so probably think about this, um, would you like to keep it like this, or maybe would you like to have it like `schc-senml-payload-compression` or `schc-json-payload-compression` or, like, something else? Or, you know, or we can keep it as it is.

**Lorenzo Corneo:** No, yeah, uh, it's a very good point. Uh, let me give it a thought. I'll discuss also with my, uh, co-authors, because, um, yeah, it's a very good point, let us think about it and and we can get back to you once we... But we're not, you know, that inflexible, we can even change the, the title.

**Alexander Pelov:** I, I, I think it can help, it can help your document, in the sense that people will, will see, oh, okay, this does compression for key-value JSON, something like JSON compression or key-value, uh, or, a, YAML, or, well, even, CSV, or, you know, something that you can, you have this similar structure.

**Lorenzo Corneo:** Yeah, it's a very good point, um, yeah, let us think about it and come back with a, maybe, new name, or if someone has, you know, just ping us and we, we will consider that.

**Alexander Pelov:** Okay, and we'll start the working group adoption on the mailing list. Uh, Alejandro, Javier.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, yes, yes, yes.

**Javier Fernandez:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Alexander Pelov:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, um, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the DTLS timeout to be, uh, you know, much larger than a DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, in the draft actually specifies this, and basically what, what it says is, well, this is the way to define a SCHC Header Format. Uh, there are three ways, at for the moment, there is a registry to be created at IANA, uh, so, for the moment, there are three uh, types of rule ID encoding that are defined. So, fixed, so, that's a fixed number of bits, uh, and that means that any entity in the, on the road of a SCHC packet can go and can look at this and can say, oh, okay, I see the, the rule ID's is a fixed number of bits, and this, this number of fixed number of bits is, let's say, 8 bits. So, I can go and and see this, right. So, that's a, one way to do it. Another way is to have it, like, self-limiting, uh, so, that, that means that, uh, we, we know how to interpret it, let's say, the first three bits give us the size of the rule ID, and, like, if it's, uh, three bits or, if it's 5 bits, then, like, the the whole rule ID is 5 bits, right, and it's encoded. So, that's another way. And, the third way which is, as it works today, well, it, it, it's defined entirely by the context. So, there, I mean, it's opaque, you need to have the full context in order to be able to actually understand this, so, this is the way, uh, uh, RFC 8724 works today.

So, uh, this is what is there today in the draft. Um, and then, there is a way to say, okay, well, uh, uh, okay, so, um, there is one registry that says, these are the ways to interpret rule IDs. Uh, these are the ways to inter- to interpret, to interpret what are the control headers are. So, zero, for the moment, for, for, for the moment, is none, so, we just have the SCHC data header, right. Uh, 1 is using VoSCHC, so, that's the proposal, uh, from Quentin, uh, so, that's like a, multiplexing and it can use, uh, integrity, uh, and it's of 1 byte. And, of course, there can be many others, right. And, the point here is that, like, you have a, a registry in which you have, this is the SCHC Header Format, my SCHC Header Format, the one that I'm using is, let's say, I have a fixed rule ID, then I have a control header, and that control header is VoSCHC, for example. Or, maybe, in other cases, it will be, I have VoSCHC as control header, and after that, I have the rule ID, and the rule ID is of 8 bits, and then I have the data control header. So, that's the, that's the, uh, yeah, I mean, the fact that it's 8 bits, it's in the shape, right.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Do you hear me properly, by the way?

**Alexander Pelov:** Yes, yes, yes, yes.

**Javier Fernandez:** Okay. Yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, um, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the DTLS timeout to be, uh, you know, much larger than a DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes.

**Javier Fernandez:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the DTLS timeout to be, uh, you know, much larger than a DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Do you hear me properly, by the way?

**Alexander Pelov:** Yes.

**Javier Fernandez:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the DTLS timeout to be, uh, you know, much larger than a DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Do you hear me properly, by the way?

**Alexander Pelov:** Yes.

**Javier Fernandez:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes.

**Javier Fernandez:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, my name is, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Alexander Pelov:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Alexander Pelov:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing with another presentation. Let me... Okay. So, I will try to... So, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. And the point is that it's a new work that comes actually from all the discussions that we have at the SCHC Architecture draft, but also an idea that I at some point had, and I had trouble actually finding how to solve it. So, it's a work in progress. So, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, you know, to contribute back, or to change, or to challenge, you're very much welcome. 

So, the motivation comes from the following thing: imagine that you have like a special link, a link over which typically we use SCHC. So, that could be like an LPWAN link, or it can be interplanetary link, like the ones that are in DTN working group, like in DTN, in IPN working group. But it can be just like any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes like typically when we develop a software for these kind of links, these kind of applications, like the servers, like the software already knows that, "Okay, I'm going to be communicating over a special link. I'm going to be communicating over LoRaWAN link, or over some other high RTT link." So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers of DTLS to be, you know, much larger than DTLS over normal normal communication. And the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like there are some changes of route, so unexpected traffic goes over this, you know, special links, or even just like we just didn't know that this happens. So, the point is how would the source of these packets know that something like this happened, and eventually maybe adjust this behavior? So, if it can, it can adjust the behavior, maybe. So, for example, in the DTN working group, they, yeah, they are working a lot on Quick, on Quick. And maybe the Quick behavior needs to be adjusted when it goes over this interplanetary links. And the idea is the following: so, you have the source of packets, and it goes, you know, to the destination. Whenever it goes over the router that is like the last router before this interplanetary link or before this LPWAN link, well, there is some way to see that, "Oh, this packet is marked. Yes, it is actually intended to go to this special link." So, you know, I do nothing. Or, "Oh, it was not marked at all. So, probably I should send a message back to the source to indicate that, 'Hey, you know, you are going to be crossing onto like interplanetary or onto an LPWAN domain.'" So, you know, just make sure you, you are adjusted, and maybe the things can be dropped. And so, there is a draft I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have like authenticated information about this sent to the source, so that the source knows that this information is actually is actually real.

And of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, "Okay, well, it's a little bit naive, but it solves, it can solve like some of the..." Yes, thank you, thank you, Marco. Thank you for being here. But, it can like, if this traffic class is set like this, then, you know, it is supposed to go through. That's okay. And the other point is actually to say, "Well, we can actually have a SCHC header that is within the traffic, and that specific SCHC header, it has a specific shape, and we can use this to say, 'Okay, we let the traffic go through.'" Right. And this is the idea is to say, "Well, how do we say that this specific SCHC header, how do we know the form, the shape of this SCHC header, so that we can actually understand what's what's in it?" Right.

And so, one of the problems is that intermediate nodes, which do not have the full SCHC contexts, don't want to only or cannot have the full SCHC context, like the endpoints. They know they have they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the point is that they cannot even look at the thing and say, "Okay, well, there is control header or there is rule ID, and the rule ID is of this size, and these are the rules." So, it cannot know. It cannot have any... It can be used for something, sometimes, for firewall, control access, or maybe even just like of for a tool, for as a WireShark, where, you know, we can see the traffic. So, we cannot really have this. And this is by design, like in SCHC, we don't have this, this way of standardizing. We don't, we didn't standardize in the way saying like, "The rule ID is always going to be 8 bits, and there is always going to be a control header behind with that many bits, and there is always going to be a data head, a data header." Like, it's entirely defined by the context. And if you don't have the context, everything is to be like opaque, right? And so, so, this is, this is, this is an issue, right.

So, the idea is to have a new way to describe this. It's a SCHC Header Format, and basically is to have a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description, we say, "Well, there is a rule ID. The rule ID is of that shape. For example, it's a fixed size, it's, we don't say how many bits, but we know that it's a fixed size. Or, it can be like a variable size, and we know how to interpret that variable size. And then, we have the rule ID, and then there is maybe a control header or not. So, maybe there is some control header, and the control header is before the rule ID or after the rule ID." Right. And there is a data header, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this like description of of what is there, and then we have the instantiation. It is like with, it takes the the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed-length rule ID and no control header, then, that's one one SCHC Header Format, and the shape, the specific SCHC shape is, we have the fixed-length rule ID with length of 8 bits. And that's like in RFC 9011, like, SCHC over LoRaWAN, where it, it is specified like this. And so, we can have like one header format, but many, kind of, SCHC shapes like this.

So, that's it. And, yes, as I said, so, there are like two very minimal IANA registries. One is for the the type of SCHC rule ID encodings, and the other is for SCHC control header types, and that's the whole mechanism, right.

And the point is that we can actually... So, the draft goes to a little bit further, and it says, "Okay, how we can actually encode this, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, for example, in the ICMPv6 message, or maybe in a different type of message, so that I can, I can know exactly how to interpret the the SCHC header." And so, there are two ways that are defined, one is out of band, so maybe there is like just, there is a, a local registry or like through some way you discover that, and then you can find out this. It can be a configuration, or we can, there is a very light encoding that is, that is written in the draft that basically describes, you know, there is 1 byte to give the the number of of the rule ID encoding, the the number of the control header encoding, and then if there are any parameters for that, and it's like 2 or 3 bytes. So, that can be working very nicely with, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the the SCHC shape tag. So, it's 1 octet for 1 byte for the control header type, 1 byte for the the rule encoding, and if there are any parameters, for example, the the size for, the fixed-length size for, for the rule ID encoding.

And, yes, so, that can be part of the VoSCHC header. So, the type of how how that could work for Ethernet, for example, is, I imagine that the way to go for this is to say, "Well, when we have an EtherType SCHC, then in the RFC, it can be written, 'Well, whenever it's EtherType SCHC, then inside there needs to be the, the, the SCHC Header Format must be this, and the SCHC Header Format must be using VoSCHC as control header, and then having like the rule ID of given size, plus the data header.'" Right. So, whenever you are using EtherType SCHC, you know how to multiplex things on top with VoSCHC, and you also know how to interpret the the whole header with it. And the same can work for UDP. If we have a UDP port, we can know that for this type of UDP port, then inside is VoSCHC plus the, the, the shape of the header.

Um, yes, so, there are some things that are not in the draft yet, and these can be fixed later on. So, there is no YANG model, and some of the things need to be, to be defined. But, yeah, that is probably a future work to be done.

So, my name is, I just wanted to present it for today. And my feeling is that this can be like a standalone document, and there can be a very light reference from that, from the SCHC Architecture, and this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. So, but the point is that in this way, we can, I think that we can solve this question, which is, you know, how can, in some cases, the, understand a little bit of the structure of the SCHC header, even though classically SCHC was like, "Okay, you need to have the full context."

So, thank you for your attention, and yes, we're almost at the top of the time, but if you have any questions, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, 's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay. Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, 's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, 's a nice discussion because in the, I mean, the position, uh, value of the field descriptor, uh, you have the zero values that says pretty much wherever, but, uh, I believe that in most implementation, that means that this field happened only one, once. Uh, and then, you have the position value, which could be 1, 2, and 3, and 4, and etc., uh, which means that the, the value is going to be repeated a number of time, and then, there- therefore, the question that I might have is this: are you planning to kind of like introduce, a, a, a template to say this is a number of repetition, and that number is not specified in the rule? For example, you could say my payload is going to be a list of records, uh, I have no idea how many records, uh, that will be in the payload, but somehow with a template, uh, I can, I can just say the, the residues is going to be N times, uh, that specific template.

**Lorenzo Corneo:** Yeah, that, that's very good point. I, I think it's actually possible because, uh, we are encoding the, um, the, the length of the repetition. So, on the other side, you would be able to reconstruct that and also, if you put some logic in the compressor, you would be able also to infer the numbers of repetitions and then you just encode it and it should be fine.

**Quentin Lampin:** Okay. Well...

**Lorenzo Corneo:** Yeah, but, good point. Thanks for bringing this up. It...

**Quentin Lampin:** Yeah. Oh, yes, thank you.

**Lorenzo Corneo:** Yeah, this validates, yeah, thanks, this validates even more that, yeah, I, I'm not fully sure, uh, this semantics uh, should be normative, but, uh, yeah, let's, let's sleep on it.

Um, yeah, and then also, uh, as part of the new version that we're planning to submit, uh, so, so far we we had this, uh, specified this, uh, N variable and repeat function, but of course, it would be cool that this set of, of tools would be extensible, uh, and therefore, we were thinking about IANA registry where, you know, uh, new uh, functions and variable can be added, uh, if, if there is a need. Uh, I think that would be great. Um, and, and yeah, so, this is just a summary of the proposed changes, uh, maybe we don't need to go through, through that one, but, yeah. So, some reshuffling in, in the text, but the content is going to be the same, uh, more highlight on the normative aspects, uh, introducing this equal template matching operator, uh, payload uh, keyword to signal, uh, that there is payload, uh, changes in how we encode the residue for the payload, and then, adding IANA registry for, uh, new template, uh, functions and variables.

And, yeah, here, I, I think we already went through, uh, this, um, at least the most, uh, sensitive parts of, of this question, so, during the presentation, uh, and and then, uh, one last thing perhaps that I wanted to throw the working group for, was, uh, about working group adoption, for, for this draft.

And, yeah, thank you, I'm, I'm done with the presentation.

**Alexander Pelov:** Thank you very much, um, very interesting presentation and very interesting work. Um, uh, I, I have like a, two, uh, uh, oh, one just like a question. At some point, I was thinking of actually defining, a, a function in SCHC that does JSON to CBOR. This is the only thing that it does, like, JSON to CBOR, and CBOR to JSON is the CDA. Um, so basically, you can have that.

**Lorenzo Corneo:** No, yeah, uh, I was actually thinking about this, but you can even have two layers of compression, basically, because once you have the context in, in, in the way we are proposing, you can even, you know, uh, have another round with CBOR and make it even more efficient. So,

**Alexander Pelov:** Yes, it, it, it, it becomes super interesting. Um, um, yes, so, I, I find that work very interesting, um, and, yes, you already presented that, um, during the, um, during the, uh, like, uh, a couple of, of, of meetings ago. Um, so, uh, maybe one thing, and, yeah, I see that there is really interest and there is support, and you are working on it, and, um, uh, so, I, I see the clear application for SenML. Um, so, maybe there are more general applications for that payload, um, so, maybe I would try asking the people that are here in, in, in the room, so, uh, how do you feel about working group adoption? Ah, okay, let me, I will start, we have a tool for that, um, and, and, yeah, Alexander, can you send the link, please? Okay. I'm going to start directly the, the, the point, the, um, tst, tst, hm. No, it's not point, where is the point? All right, here. Show of hands. Do we adopt? So, here it is, um, like, just, uh, initial polling to see, uh, how, what, what are the feeling in the, in the room. We will start, um, an official, after, one after one, in the, on the mailing list, just so that we can, we can see like, um, what do you feel, do you do you feel that this is a work that needs to be done at the working group? Um, and, of course, there will be things to be improved, the things to be decided during the, the, you know, all the questions that you have here, but that's a normal working group, uh.

**Lorenzo Corneo:** Yeah, yeah, absolutely, I mean, yeah, we plan to work more on this and we are very open to taking feedback and improve the, the draft even more. Thank you all, really, for this.

**Alexander Pelov:** Yes. So, so, there are seven votes, seven yeses. Um, I, Marion, I think that we can take this one, okay, eight yeses, so, everyone is, um, everyone is... So, this removes all anonymity, but, uh, yes, so, everyone that is presented here, that is present, is for the adoption of the document. Um, so, of course, we'll confirm that on the mailing list, um, and, uh, I, I just would like to probably ask you a question is, would you like to keep the same name? Uh, because it's like `schc-payload-compression`, it, it corresponds to what it does today. Uh, it does seem to be, to have a very, very useful use case which is SenML. Um, so probably think about this, um, would you like to keep it like this, or maybe would you like to have it like `schc-senml-payload-compression` or `schc-json-payload-compression` or, like, something else? Or, you know, or we can keep it as it is.

**Lorenzo Corneo:** No, yeah, uh, it's a very good point. Uh, let me give it a thought. I'll discuss also with my, uh, co-authors, because, um, yeah, it's a very good point, let us think about it and and we can get back to you once we... But we're not, you know, that inflexible, we can even change the, the title.

**Alexander Pelov:** I, I, I think it can help, it can help your document, in the sense that people will, will see, oh, okay, this does compression for key-value JSON, something like JSON compression or key-value, uh, or, a, YAML, or, well, even, CSV, or, you know, something that you can, you have this similar structure.

**Lorenzo Corneo:** Yeah, it's a very good point, um, yeah, let us think about it and come back with a, maybe, new name, or if someone has, you know, just ping us and we, we can consider that.

**Alexander Pelov:** Okay, and we'll start the working group adoption on the mailing list. Uh, Alejandro, Javier.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, yes, yes, yes.

**Javier Fernandez:** Okay.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Alexander Pelov:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, it's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a very simple and straightforward way of doing this is using, for example, traffic class. Say, okay, well, it's, 's a little bit naive, but it solves, it can solve, like, some of the... Yes, thank you, thank you, Marco. Thank you for being here. Um, but, it can like, if this traffic class is set like this, then, you know, it, it is supposed to, to go through. That's okay. And, the other point is actually to say, well, uh, we can actually have a, a SCHC header that is, uh, within the traffic, and that specific SCHC header is, it has a specific shape, and we can use this to, uh, to say, okay, we, we let the traffic go through, right. Um, and, this is the idea is to say, well, how do we say that this specific SCHC header, how do we know the, the form, the shape of this SCHC header, so that we can actually understand what's, what's in it, right?

And, so, one of the problems is that intermediate nodes, uh, which do not have the full SCHC contexts, don't want to only, or, or cannot have the full SCHC context, uh, like, the endpoints, they, they know, they have, they have the full SCHC context, they can do the compression, decompression, but the intermediate nodes, they do not know this. And so, the, the point is that they cannot even look at the thing and say, okay, well, there is control header or there is rule ID, and the rule ID's of this size and these are the rules. Um, so, it cannot know, it cannot have any, it can be used for something, sometimes, for firewall, control access, or maybe even just like, of for a tool, for as a WireShark, where, you know, we can see the, the traffic. So, we cannot really, uh, have this. And this is by design, like, in SCHC, we don't have this, this, uh, this way of standardizing, we don't, we didn't standardize, uh, in the way saying like, the rule ID's is always going to be 8 bits, and there is always going to be a control header behind with that many bits and there is always going to be a data head, a data header, like, it's entirely defined by the context. And if you don't have the context, everything is to be like, opaque, right. And so, uh, uh, so, this is, this is, this is an issue, right.

So, the idea is to have a, uh, a new way to describe this, it's a SCHC Header Format, and basically is to have a, a registry. It's to have a registry where we can say we can have a name, a description of a datagram framing. So, in that description we say, well, uh, there is a rule ID, the rule ID, if, is of that shape, for example, the, it's a fixed size, it's, uh, we don't say how many bits, but we know that it's a fixed size, or it can be like a variable size, and we know how to interpret that variable size. Um, and, then, we have the rule ID and then there is maybe a control header or not. So, maybe there is some control header and the control header is before the rule ID or after the rule ID, right. And, uh, there is a data header, uh, and the data header is at that place, and so on. So, that's the, that's the, the SCHC Header Format, which is this, like, um, description of of what is there, and then we have the instantiation. It is, like, uh, with, it takes the, the SCHC Header Format that is there and then actually fixes if there are any parameters. So, for example, if we have a fixed length rule ID and no control header, uh, then, that's one, one SCHC Header Format, and the shape, the specific SCHC shape is, uh, we have the fixed length, uh, rule ID with length of 8 bits. And, that's, like, in RFC 90, uh, uh, 9011, uh, like, uh, SCHC over LoRaWAN, where it, it is, uh, it is specified like this. Uh, and, so, we can have, like, one header format, but many, kind of, SCHC shapes, like this.

So, uh, that's it, and, uh, yes, as I said, so, there are, like, two, uh, very minimal IANA registries, one is for the, the type of SCHC rule ID encodings, and the other is for, uh, SCHC control header types, and, uh, that's the whole mechanism, right.

And, the point is that we can actually, so, the draft goes to a little bit further and it says, okay, how we can actually encode this, uh, uh, this, this SCHC shape of the thing, like, which actually can say that, okay, specifically, how can I signal that, uh, for example, in the ICMPv6 message, or, uh, maybe in a different type of message, so that, I can, I can know exactly how to interpret the, the SCHC header. And, so, there are two ways that are defined, one is out of band, so, uh, maybe there is, like, just, um, there is a, a local registry or, like, through some way you discover that, and then you can find out this, it can be a configuration, or we can, there is a very light, um, uh, encoding that is, uh, that is written in the, in the draft, that, uh, basically describes, uh, you know, there is 1 byte to give the, the number of, of the rule ID, uh, encoding, the, the number of the control header encoding, and then, if there are any parameters for that. And, it's like 2 or 3, uh, bytes. So, that can be working very nicely with, uh, for WireShark, for example. I have to write an example that is, that is more visible here. Yes, so, here you have the, the, the SCHC shape tag, uh, so, it's 1 octet for 1 byte for the control header type, 1 byte for the, uh, uh, for the rule encoding, and, if there are any parameters, for example, uh, the, the size for, the fixed length size for, for the rule ID encoding.

And, uh, yes, so, that can be part of the VoSCHC header. So, the, the type of how, how that could work for Ethernet, for example, is, um, I imagine that, the way to go for this is to say, well, uh, when we have an EtherType SCHC, then in the RFC, it can be written, well, whenever it's EtherType SCHC, then, inside, there needs to be, uh, the, the, the SCHC Header Format must be this, and the SCHC Header Format must be, uh, using VoSCHC as control header, and then, having, like, the rule ID of given size, plus the data header, right. So, whenever you are using, uh, EtherType SCHC, you know how to multiplex things on top with VoSCHC, and, you also know how to interpret the, the whole header, uh, with it. And, the same can work for, uh, UDP. If we have a UDP port, we can know that for this type of UDP port, then, um, uh, inside is VoSCHC, plus the, the, the, the shape of the, of the header.

Um, yes, so, there are some things that are not in the draft yet, and, these can be fixed, uh, later on. So, there is no YANG model, uh, and, some of the things need to be, to be defined. Um, but, uh, yeah, that is, uh, probably, uh, a future work to be done.

So, um, that's it, I just wanted to present it for today and, uh, my feeling is that this can be, like, a standalone document and there can be a very light, uh, reference from that, from the SCHC Architecture, uh, and, this separation, so, we need to see, if it's, if it stands the time, like, SCHC Header Format, SCHC shape, maybe it should be changed, the naming. Um, so, uh, but, the point is that in this way we can, I think that we can, um, solve this question, which is, uh, you know, how can in some cases, the, understand a little bit of the structure of the SCHC header, uh, even though classically SCHC was, like, okay, you need to have the, the full context.

So, thank you for your attention, and, uh, yes, we're almost at the top of the time, but if you have any questions, uh, you know, don't hesitate.

Okay, um, yes, Alejandro.

**Javier Fernandez:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Alexander Pelov:** Yes, just had a little opinion on, on renaming the draft. Uh, do you hear me properly, by the way?

**Javier Fernandez:** Yes, yes, yes, yes.

**Alexander Pelov:** Okay.

**Javier Fernandez:** Uh, yeah, so, not keeping it specifically for SenML or, uh, something else, because, uh, yeah, if we can apply to multiple, like, payload, uh, standard thingies, it could be good as well.

**Lorenzo Corneo:** Yeah, thanks for the feedback.

**Javier Fernandez:** Yes, that, that's a good point. If you find like, a, a way to, to say like, okay, like, it doesn't do binary compression, for example, stuff like this.

**Lorenzo Corneo:** I'm comfortable with key-value, uh, formats, JSON, okay, but then, yeah, give us some nights to, to think about it.

**Alexander Pelov:** Uh, yes. So, uh, probably, uh, so we'll start a working group adoption, and, uh, uh, then, I need to double-check how we did it in the past when we were changing slightly the names of the draft. Was it like, uh, before the working group adoption, when when you submit those 00 version, um, or, or is it after? I need to double-check this one. Um, I, I don't recall how it works.

**Lorenzo Corneo:** Oh well, let us know, and we, we can comply with the, with the process. But, yeah, thank you everyone for, for the great feedback, uh, really appreciate that.

**Alexander Pelov:** Yes, thank you. Thank you for, for the great work. Thank you, Lorenzo. Thank you, Edgar, for, uh, for being here and for presenting and for pushing the work, the work forward.

**Lorenzo Corneo:** Sure, thank you.

**Alexander Pelov:** Um, okay, so, with this, so, I'll, I'll be continuing, uh, with, with another presentation. Let me, okay. Uh, so, um, I will try to, so, I have around 15 minutes, and I will try to fit this presentation in 15 minutes. Um, and the point is, uh, that, uh, uh, it's, uh, a new work, uh, that comes actually from, um, uh, from, from all the discussions that we have at the, at the SCHC, uh, Architecture draft, but also, um, an idea that I at some, had at some point, and I was, I had trouble actually finding how to solve it. Uh, so, it's a working progress, so, it's like, you can take it as really the very first version, and if you have any feedback for that, anything that you would like to, um, you know, to, to contribute back, uh, or to, to change, or to challenge, uh, you're, you're very much welcome.

So, the motivation comes from the following thing. Um, imagine that you have, like, a special link, a link over which, uh, typically we use SCHC. So, that could be like an LPWAN link, uh, or, and can be, uh, interplanetary, uh, link, like, the ones that are, that are in DTN working group, like, in DTN, in IPN working group, uh, but it can be just like, any DTN or any other type of thing that really have some very special properties, and we use SCHC on that link. So, the point is that sometimes, like, typically, when we develop, uh, a software for these kind of, of links, these kind of applications, like, the servers, like, the software already knows that, okay, I'm going to be this communicating over a special link, I'm going to be communicating over a LoRaWAN link, or over some other high, um, uh, RTT link. So, I'm going to set up the timers accordingly. So, if I have a DTLS, for example, I'm going to set up the timers, uh, of DTLS to be, uh, you know, much larger than DTLS over normal, normal communication. And, the point is that sometimes, maybe there is some misconfiguration in the stack, or maybe the routing doesn't go as, like, there are some changes of route, so unexpected traffic goes over this, um, you know, special links, um, or even just like, we just didn't know that, that this happens. So, the point is how would the source of these packets know that something like this happened, um, and eventually, maybe adjust this behavior. So, if, if it can, it can adjust the behavior, maybe. Uh, so, for example, in the DTN working group, they, yeah, they are working a lot of Quick, on Quick, um, and, maybe the Quick behavior needs to be adjusted, when it goes over this, interplanetary links. And the idea is the following: so, you have the source of packets and it goes, you know, to the destination, whenever it goes over the, the router that is like, the last router before this interplanetary link or before this LPWAN link, well, there is some way to, to see that, oh, this packet is marked. Yes, it is actually intended to go to this special link, so, you know, I do nothing. Or, oh, it was not marked at all, so, probably I should send a message back to the source, to, to indicate that, hey, you know, this, you are going to be crossing onto, like, interplanetary or onto an LPWAN domain, so, you know, just make sure you, you are adjusted. And maybe the things can be dropped. And so, the, the, there is a draft, I, I worked on, like, it's like a new type of ICMP, ICMP message, where there is a little bit of security to have, like, authenticated information about this, sent to the source, so that the source knows that this information is actually, is actually real.

And, uh, of course, a_s it is very interesting. I just didn't really understand the, so I got the problem. And it's what happens when a SCHC packet encounters an optical that does not do SCHC. What you want is to be able to route it properly, like to send it through the right node, like this node that does not know SCHC must know where to send it anyway.

**Alexander Pelov:** Um, yes, I, I mean, um, so the very, oh yeah, actually here presented two things. The first thing is, why we, why we did it, and the second thing is the actual doing it here. Um, so the, the idea was, in the first was, yeah, if I have to simplify is to say, imagine that you have a router in the, in the middle, and there is some SCHC traffic that goes through the router. So let's say there is IP, UDP, and then inside, there is, in the UDP, there is like a reserved UDP port for SCHC. And, and then, you have like SCHC traffic. Um, because SCHC is, you need to have the, the context to be able to parse it, to be able to understand it, um, you don't know what is the size of the rule ID. You don't know what headers are inside. I mean, you don't know anything. It's just like zeros and ones. So, the intermediate router, they are only going to see like IP with UDP port, I don't know, if if we get allocated, let's say UDP port 2000. They're only, the only thing that they can see, the intermediate router can see. And so, if they cannot do anything with that, they can say, "Okay, well, I'm just going to be dropping this packet, this, this traffic," because like, maybe it's a security breach. Um, so, we need some way to be able to, to tell these intermediate nodes, to tell them, okay, the structure of of what's going through here is this. So, there is a control header, the control header is like multiplexing stream fields, and maybe there is a rule ID, and the rule ID is of that many bytes, of that many bits. Maybe there's some context ID. I don't know, like, there are parts of the information that you can go and, and that the intermediate router can go and can analyze. So that it can say, "Okay, well, I see what's happening here. So, it's a safe traffic, I can, I can let it through." Um, and and this SCHC Header Format is basically the way to say, to, to say through a public registry, to say, um, the first that many bits is this protocol, it's the control header, then, the next that many bits is, uh, the rule ID, and then, the less the rest is like the data header, plus the residue. Uh, so even if the intermediate node doesn't have the full context, it can at least go through some, uh, uh, security checks, or through some validation to see, okay, what's happening here is according to my, to my policy. And they don't have to do full decompression, like they can only go and see, "Ah, okay, well, this type of header, okay, understand. This type of rule ID, understand. That's okay. Uh, I allow rule, rule IDs from 1 to, to 20 for this type of traffic, so it's good for me." Okay, yes, so it's, it's a bit clearer. Uh, but, yeah, I'm not sure, I think I would have to check how routing is done in this case, like in these specific cases, because usually, like, usually, a node that does not do SCHC doesn't really care about the SCHC payload, it just forwards it, no? And the IP, like, the IP address and UDP port should be enough to like forward it. And then, if there are like, security rules or so, from certain traffic, then, I'm not sure this is up to SCHC. Well, it's, I mean, you're right, but the point is that, okay, let's say another example is, so I think that the security is the, the strongest one here, uh, because you, you still may want to write some firewall rules that, uh, go and and forbid some, okay, you know it's SCHC, but if you don't know anything more than this, you can say, "Okay, I forbid all traffic," because, uh, it can be used to tunnel, or to to do some nasty stuff, right. It is as in some cases, you have some, you know, some, uh, uh, firewall rules, they say, okay, we forbid UDP traffic, like, as in the past, like, we forbid all UDP traffic, because, you know, we cannot, uh, uh, it can be used for bad stuff, right. So, you can have stuff like this, okay, we forbid all SCHC traffic, because, uh, yeah, you know, it, it, it could be potentially, um, some kind of, uh, of like, it can be a malicious traffic. Um, in this way, you can actually go a little bit further, and you can tell the network, "Hey, well, okay, it's a SCHC, but also, this is the structure. So, you can ask, you can write more specific, uh, filtering rules on that." As I said, like, the, the rule IDs are on 3 bits, so, uh, like, you can enable, so, so that the administrators can say, "Okay, well, we allow all rule IDs that are from, from, that are of 3 bits, right, and if it, there, there's something that comes with rule IDs of 4 bits, like, it doesn't work. It, it's, uh, we need to filter that." Um, or, or we can have like, a, a WireShark module, where you have like the SCHC traffic, and the WireShark module cannot understand anything, it's just zeros and ones, right. With this mechanism, you can, the WireShark module can go and can, and understand that, "Ah, okay, well, I see, uh, uh, I see this, and I can go and I can, I can look inside the SCHC packet, and I can say, 'Okay, well, uh, there is a control header. The control header is with this protocol, let's say VoSCHC, and so forth, and so forth.'" Um, so, we are a little bit of, behind the time. I will send, uh, a probably, we'll be working a little bit more on the draft, and try to send a little bit more information on the mailing list, and probably we'll have another discussion, um, you know, before the IETF and hopefully at the IETF. Uh, thank you very much, Alejandro, for, for the question. So, for questions, and, um, yes, thank you, uh, Edgar, uh, uh, thank you, Quentin, thank you, Marion, for, for being here, for staying. Yeah, thank you, also, for participating to, uh, the meeting today, and, uh, don't hesitate to, to continue, uh, um, on the mailing list. Yes. Thank you, all. Bye. Bye-bye. Bye. Thank you.