Session Date/Time: 29 Sep 2026 13:00
[00:01:40] Alexander Pelov: Hello, everyone. Very glad to see you here. So we'll be starting, in at, five minutes past the hour as usual. You.
[00:04:02] Éric Vyncke: Audio check, and good afternoon, everyone.
[00:04:06] Alexander Pelov: Hello, Harry. Good afternoon. Nice to see you here. Yes. Thank you very much, Marco, for for for pointing to the notes and for taking the notes. Yes. So, Mariam cannot join today. She had a a full day that she could not abstain from. She was absolutely absolutely required. And that's the good thing to have two chairs because we can have our meetings. So with this, it's five minutes past the hour, and, we can start. So this is an interim meeting of the SCHC working group. Okay. And, yes, as, such meeting, the note well applies. So please do read the note well and do read all the RFCs and BCPs that are cited here. So by participating in the IETF, you agree to follow IETF policies and processes. And this is just a reminder. The full link is in the QR code. IETF participants are expected to behave in a professional manner and extend respect and courtesy to their colleagues at all times. And, of course, if you have any concerns, please contact the team the team. If you're aware that any I IETf contribution is covered by patents or patent applications that are owned or controlled by you, your employer, or your sponsor, you must disclose that fact or not participate in the discussion. And you have the the list of all the RFCs that are that need that you need to consult. And if you have any questions, of course, you can come to the chairs or to to our aide. So for today, we have two men two main agenda items. So we'll be discussing I T F, what else 127, and we have a document presentation by Laurent on RFC ninety three sixty three bis and another presentation on a related document that I think is is relevant to the work of this working group, I c m p v six sec for. And we hope to end a little bit ahead of schedule or, yes, a little bit ahead of time. So is there any any agenda bashing? No. So before we actually go to the presentations themselves, there is, of course, the first point, which is an overview of the working group documents. So we have a fair amount of actually expired working group documents. So I'll one of one of the first one is I'm going to publish is the the draft, which is going to be published right after this this meeting. I I have a new version which just bumps it up to so that it's not expired. And I really think that we we have to take care that the drafts that are that we care about, that they they remain active. Right? So I'm very happy to see Ana and Laurent here, and Marco, of course, who are coauthors of some of these, drafts. So I just wanted to see if it will be possible for you to, upload an it can be just a a minor version or so that the drafts remain active. Like, there is the universal option, the I c m p v six, and, eventually, the access control document. And all the documents that so we had this discussion at IETf-one hundred and twenty six, and we said that some of them probably are not going to to continue living. I mean, at least the authors have reached some some point in which they they do not will to to contribute anymore. So if you don't bump up a document, we'll need to take a decision as a working group if we drop them or if we look for other contributors that are going to that are willing to take the the the work to to the end of to this completion. Yes, Laurent?
[00:09:45] Laurent Toutain: Yes. Just just some point we present it after, but I think universal option is finished. And and we can revive I c m p v six compression. It will depend of what we present just after.
[00:10:01] Alexander Pelov: Mhmm. Yes. Well, I c m p v six compression, actually, we're ready to to start the working group last call. We only wanted for for it not to be expired, right, because it does not look as good. So that that's that's good news. There are two documents that are ready for almost ready for King Group adoption. So that for King Group last call. So great. Yes, Marco?
[00:10:25] Marco Tiloca: Hi, everyone. Yeah. About 8824-update, it's not going to expire. But in July after the Vienna session, I submitted right after version 10. I think it's addressing all the pending points presented in Vienna, and I sent out the summary on the mailing list, I think, on July 26. As far as I know, there are no pinpoints left. So I I confirm that I believe version 10 is ready to be sent to the ISG. Yes.
[00:10:54] Alexander Pelov: Thank you, Marco. That was actually one of the questions I wanted to ask you because I was not I so I I I did the review, and then I was like, okay. I went and checked and I said, okay. July 26, was there anything remaining compared to the the discussion we had or not? So I just wanted to to make sure that there is not. So the so it's good. I'm going to to ship it to the to press the button. Or I I mean, publish the the the shepherding of our document, the shepherding write write up and and post the button. So Sounds good. Yes. Thanks. Thank you, Marco. So with this so and and to Laurent, so two one question, the SCHC Access Control. So what do you think that it's something that can that you are willing to continue working or not in in which case, probably, we will either drop it or we'll look for other contributors?
[00:11:59] Laurent Toutain: So I think of a first that Ana is the first author, so she she can she can answer. And it can be very useful with the work Samar is doing on management.
[00:12:14] Alexander Pelov: Okay. Yes, Ana. I mean, if if you're willing to be working on that and, Ana, that that's great. Just bump up on your version. Yes, Ana. Hello. So, yes, I think that access control, we have to update what we have inside because there are some parts that maybe be obsolete because of the YANG data model. But there are many parts that are very useful for the rule creations and so forth. So we need to work in a new version for access controls. I well, I I am in. Okay. That's that's that's great. That's great. So just please push on your version. It there doesn't need to be any difference in the text. Just the new dash o one or o two or three so that they're not expired. And because I mean, we we said that we'll we'll do a cleanup before the end of the year, and, like, we'll be cleaning up expired drafts. Okay. Yes. Right. And if it's not expired, that means that you're working on it, and that's great. Thank you. Sure. With this so a short overview of all the related work. So there is very interesting and and, like, work that is that is happening in our working group and and outside. So, of course, that's really, really interesting and really great to see. And we'll, of course, we some of these documents are probably going to become someday worker group items, but that depends, of course, on the authors and the fact that they have their continuing contribution and that's active in in in in the working group. And we will, of course, continue to to see how we can help working group drafts that are that are in in the in other working groups. So for the next IETf, so I'm I'm going to be physically present there. Marion, she I'm not sure if she's going to be physically present or or on remote. So I think that it's it's really interesting and important to have this meeting so that we we we open it more also to people that are not only based in Europe that are coming to all the ITFs here. So we had a one hour one hour and thirty scheduled for the past meeting, and and also for the all the previous meetings, actually. I think it's a it's a it's a good, it's a good format. We're almost we're almost always a little bit short, but, you know, I I feel that it's it also gives a good a good rhythm. So how how do you think do you think any more time is necessary, or we keep it one hour thirty? Okay. So let's keep it one hour thirty. And the conflicts, so we're going to narrow them down a little bit because there were otherwise, we'll get scheduled definitely on Friday, and I definitely have to leave on Friday in the afternoon. So we'll go we're going to keep the yes. Thank you, Eric. So one hour thirty seems okay with all the interim meetings. So we'll keep it narrowed down to to the core working groups that that are here. So in in case you so because all the people that are here are are important to this working group, if you see any other group that needs to be added, please say so. But I I will be requesting this time that we have a meeting until Thursday, right, included. So with all these things out of the kinda all these things viewed. So, Laurent, he was the one that was put as presenter. We said twenty five minutes. So, yes, the floor is yours.
[00:16:35] Laurent Toutain: Okay. Thank you. So I will present also this new draft that has been published last week. So it's a huge one, so I don't know if you you have the time to to read it. So the title is 200 f c ninety three sixty three bis. Is because it's not really the bis of 9363. The goal is more to start the discussion on the new item or new things or changes that we can apply to the existing YANG data model of SCHC, When we will agree on on the result, then we will update 9363. Otherwise, it will be a very boring document that explain all the structure of young extra. So we prefer to to focus really on the hot topic and the the change to the data model because there is a lot of things that have been modified and implemented and and tested. So
[00:17:40] Alexander Pelov: Eric, Laurent? Just just do you take Eric wants to ask a question. I'm not sure if you'd like to take questions
[00:17:46] Laurent Toutain: during Yeah. But I didn't say it. But Right.
[00:17:50] Éric Vyncke: So, basically, Laurent, as soon as you have a RFC blah blah biz in the file name, data tracker is a regex, and we tag it as a revise. So Okay. Next revision, right, change the title and don't use RFC ninety three sixty three biz in the the file name.
[00:18:07] Laurent Toutain: Okay. That's strange. That's why Marco put updates, I think. Okay. So okay. So this document so we what we have included in this document, it's all the discussion we had before in the in the working group. So, of course, there is one very big and very important topic about universal options. So it was a lot of discussion about how to represent, options that are not really named or as a position, but are, optional as option r. We also include the young data model for the '28, '24 updates because, the updates doesn't have a young data model. That was the young doctor review. It was to to put it in another document because the original one doesn't have a young data model. So it includes also IP ICMP v six. And, in fact, here, there is there is a discussion because there is something that was written in ICMP v six that maybe is not the best way to to proceed, so we can discuss. So maybe to change it or to include both. Of course, is include also. I will not go into much detail because it's just taking the young data model from these and add them on some goodies that also are present in in in the document. So to to summarize where what is what is the main change, so it's universal option. So here you have the structure of the of the compression rule defined by r s c ninety three sixty three. And we can see that we have an entry, and this entry is indexed by with three fields. So fill ID, fill position, and direction indicator. So that was what we had at the origin. And then we had the discussions from universal option. And the question is, for example, if we have a new co op option that appears, do we have to divul define a new field ID for this? And it looks like it's not very easy because it will take time. And so the best idea was to make a universal option, which means that we create a new entry, and we put here a space ID, for example, co op. And here, after that, we put the option number that has been defined. So each way each time we have a protocol that define options, we take the numbering from this protocol so we don't have any interpretive problem. But the main problem was that we have now two type two types of keys, one for the regular entry and one for the universal options. And it's what we propose in the in the draft option. The problem with that is that we don't keep the option in the order that appear into the header because we have first all the regular values, and after that, we have the options. We may have a trick maybe the young, the data star or the representation, the serialization, but it will very be very, very suboptimal. So that's not a very good approach to to do that way. And so we propose in this document to review totally the compression entry and include directly the universal option in it. So it's what we we have here. So on the right hand part of the the documents, so we have a new entry that is your entry universal and as a simple, very simple index that is entry index, which means that this time, we'll this way, we will number all the entry we have in the rule, which keep the order and is very easy to index. And it's very important, for example, for management. And this way, we have only one byte to say, okay, this is this this entry instead of three indicator or three value that takes that that have a very long representation. So that's the main change is to number the entry and keep it as an index. And if we have this, so, the field ID of the obs universal option are no more indexes, so we have more flexibility. And so here we have a choice. It can be ever a field ID or a space ID plus its universal value. And so that's the main change we we have. So there is other changes, but I will detail them in in the future. So here we have a new representation. For example, AI tech, rule a for OSCORE that is defined for in in in the document. So we skip I p v six UDP. Here, we have only the the option. So we see that we have the field ID that are defined, and we we have, for example, in in green, we have the the universal option for score that can be used in downlink. So we have this this flexibility. So but if you see that we still have some co op option that appears in this in this rule for uplink graphic. And in fact, it's that we what we propose first is to deprecate all the co op option we have in the original r s c ninety three sixty three. And so we have no more co op option except when we want to go deeper in the option. And that's the case with OSCORE for the OSCORE values and OSCORE subfields and also the subfields that are being introduced by KUDOS. So here, there is no more it's no more a question of universality because here we go deeper. So we we have to to know what we are doing. And for that, so we define the option for coaption of score, and we can go even deeper in the flag. We can define it in flag and and flag bits. So that's what we propose. And so we from the document, we deprecate the coaption, and we introduce the one the subfields for OSCORE and Carlos. So that's main thing. So I I say that we deprecate. So we we are both version are compatible and can be used right now. Second thing that we do, since now we have a very small entry index, we can also change or generalize what we have with the length. And usually for the the token, we are we have a function that is called field length, token length. And here, we continue to use it, but we introduced two more generic function. One is a field length length bytes and an entry index. And so it says, for example, if you would look at rule, nine, that the co op option of score PIV has a length that is defined in byte by the entry number eight. So you look at this one and you know the length. And if the unit is in bits, then we have the other function, fill length bits. So this way, we can have something, very generic that can be applied to a lot of protocol where you carry your lens and you want to to use it. And so we don't So, Laurent? Yeah.
[00:26:57] Alexander Pelov: Just one point. I mean, it it's related it's a it's a global observation and a global question because, like, this this document, as I said, it it's quite big. So I took some time to to skim over it. And it seems that actually what it's doing is it's taking a lot of the standard track documents that we have today. Like universal option, it has a standard track documents. I see m p v six, it has a standard track documents. So I think it will be more appropriate to actually have these different things in the different standard track documents.
[00:27:38] Laurent Toutain: If you want to lose one year, yes, because it means that we have to to spare spare it in in different places. For me, it's it's more on an evolution of the architecture. For example, Finland byte is not defined anywhere. So do we create another document to do that? We wait for the RLC approval, and then we we define the data model data model. Okay. But it's it's next time. So I I think it's better to centralize things.
[00:28:12] Éric Vyncke: So, Laurent, I I don't know how you translate going pro proposed standards to one more year. Can you be more explicit on this?
[00:28:22] Laurent Toutain: It means that we have to rewrite documents that are not so active right now. So it means that we I think we we have more time. It will take more times to to do it. And here, we have a centralized evolution of the of the data model.
[00:28:40] Éric Vyncke: Because you normative reference to other draft.
[00:28:45] Laurent Toutain: Yes and no. For, here, we so first, universal option is no more accurate regarding this. So that's the first problem. The second program, field length bytes are not defined in any other document.
[00:29:06] Alexander Pelov: Yeah. I mean, I mean, the the point is, of course, you are author of the universal option. So it it takes you away from the other draft to work on this one. But, I mean, for me, at least the way I'm seeing things is that, like, the data model like, the the point of the data model is is to describe how things are like, to describe a working mechanism. So we still need a place to describe the working mechanism. And it seems that if you keep a very, very big document so there are pro there are pros, of course. Like, you have a one big thing that revises everything in one go. But the cons are that we actually need to to get the whole document done instead of having each of the individual pieces getting standardized. And in any case, you need to describe all these behaviors.
[00:29:58] Laurent Toutain: Yeah. But if we when we create a YANG data model, it's a very huge process. We have to go through the young doctor. We have to go through a lot of process, then we have to do the seed allocation. And so it's a lot of things to do. So if we delay if we have several documents, the longest one will block everything.
[00:30:25] Alexander Pelov: So No. But but the way the way I see it, this is the way if you have one monolithic one. Because if you have several one, each of them can advance on their speed. Right? And when and they have their own they have their own
[00:30:38] Laurent Toutain: scope. First year scope. First, here, as I say, is toward RFC ninety three sixty three. It's not RFC 93 bis. So the goal of this document is to present all the evolutions. So we can discuss this here. If we want to cut it in 10 pieces, yes. But why?
[00:31:02] Éric Vyncke: So, Laurent, may I again, right, I have not followed the the discussion completely. But does it mean that this document is basically will never be published per se? It's more like a preparation for discussion?
[00:31:14] Laurent Toutain: Yeah. Yeah.
[00:31:15] Éric Vyncke: Okay. That is clear. Thank you.
[00:31:21] Alexander Pelov: Yes. And and so, yeah, thank you. That that's that's that's clearer now. And there is one more point on on the previous point, Laurent, because I actually wanted to to to to address the thing that we deprecate the whole way we present the rules today in order to introduce a new way. So I I think there is a thing to discuss there. And, actually, that was one of the points that was has pointed out a couple of years ago or a couple of, yeah, couple of years ago when he said that there may be some ambiguity in the way the rules order is treated. The field orders are are treated in in in in in the way the Yako presentation works. So RFC eighty seven twenty four is clear. There is no problem there.
[00:32:09] Laurent Toutain: No. On how that yeah. Oh, yes. 24 is
[00:32:13] Alexander Pelov: The point is the point yeah. The point is that, yeah, RFC the the Yang model, actually, there is some ambiguity. So I think that this needs to be solved in any case. So one one of the points that I think should be done already is to mark it as an error in errata in ninety three sixty three and to say so there is actually, a a clause in in YANG that's called order by user.
[00:32:41] Laurent Toutain: It's in this document.
[00:32:42] Alexander Pelov: Yes. So the point is to say, anyway, that's something that is, I mean, this is the intended behavior. It's just that we did not put that in RFC ninety ninety three sixty three. So I think that's a good thing to already market it as errata in 9363. And then, of course, we need to we need to to to to to work towards something else, which can be, of course, revising the whole thing or can be just, like, a smaller scope of working. But I think it's it's it's a way for anyway to indicate that to implementers.
[00:33:21] Laurent Toutain: You are the chair. So yes. So to to go back, we we have this so in this document, we we put the order. It can be an errata, but I don't think we can put an errata on a YANG data model. So it would be just in the text. And so that's one point. And second thing is that it's a depression, not an it's not obsolete. So it means that the both model are still valid and all the values are still valid for a period of time that we we have to decide. And the RFC, I think, say minimum one year. Okay. So now what we we have so the document also open a discussion on ICMP v six and compression. And so we we have two ways to do the compression. So on the left hand side, you have the one that is done by, currently, I c m p v six. And so you have all the I c m p, I p v six header that are defined. Then you have the ICMP message. And, you have normally, the the RFC introduced two MOCDA, but it's reverse whole match. And if it's it's true, if there is a rule that matches the payload. And then a reverse compressed sand that is that is used to apply this compression and the residue is put on the pellet. So the the document I'm presenting right now makes an analysis of the residue, And the residue is not that good because we we have to send a lot of things and padding in in this. So another solution to to to do the compression is to say, in fact, when I receive the error message from a device, the error message is composed of four layers. So you have the I p v six header, the ICMP header, and the payload, in fact, include the message that generate the error. So we can continue the description and do the and do the compression also of this part. And also so here, we have an example with a UDP that generate error, and we can carry it. And that's something very important. For example, in the implementation I have, it's very important to to have the port number that generate the error because it's in informed that the the client is no more active. So here we have two two two way to do it. For me, the second one is more easy to implement and because you have only one compression. The only trick is that when you call a device a device, an application, an application, the parser when it cross ICMP and go to the the package that provoked the error has to invest the meaning because the device is not located at the same position, and the application address is not located at the same position. So that's a little trick, but any program can can do it. So it's something I would like to to to have a discussion on that. And as I said, the document ICMP document maybe it's not so ready for last call, and we have to to update it. Two goodies that are present also in the document. The first one is unused. So it was not present in the original I I I c m p v six document because it was presented as, unused, doesn't appear in the parsing. But it appears that when you have your your actual parsing, it's good to have some unused field and says keep that. So unused is defined. It's not linked to an ICMPv6 protocol, and it can this field can be used on any protocol if needed. And same thing, you have a new entry that is payload, and payloads with the remaining bytes of after the the compression. So this payload can be used, and Magnus present things last time for payload compression. And so this way, you can link to a specific CDA to to do the the compression. Another entry is also Finland. It's called remaining. So it's like variable, but so you don't care of the length, but you don't put the length on on the serialization. And, for example, if you have payload remaining and CDO is ignore and CDA is value sent, you have the no logical the regular behavior of of sheets, which means that we send the payload after the other residues. But here, for example, it's a way also to remove the the payload from from the the answer. So that's the different things. And one thing so we also add is action. So action was presented in the old AOM document and has been removed for the AOM document. Be the and the argument was because it was a bottom of my approach, and we give an example and say, oh, it's good for ICMP. And so we generalized it. And the discussion was, is it really useful, and do we need it? And and what is impact on the upper layer. So now what we do is a data model, we have a top down approach. So it's the time to to reinstall it. And Magnus, last time when he presented his his proposals, was very close to something that looks like action. So action is very useful for ACM p v six, but can be also useful for other things. Alex?
[00:40:32] Alexander Pelov: Yes. So I so thank you. I I think that that's actually pretty interesting because, I mean, it's basically you described the way I c m p v six document should evolve, and that's great. I remember that we had a lot of discussions about the action, and the working group decided not to include it. So I think that before including it, you need to like, there needs to be a discussion in the working group. Right? May maybe indeed things changed and and the the opinions evolved. And and just the last time, we said, okay. Well, this is out of scope for the moment.
[00:41:13] Laurent Toutain: Okay. But so that's the goal of this document. So to start the discussion, so it's welcome. So last thing is about management. So we are very, very light on management in this document. We just say that we have a new rule nature that is nature nature management. And this nature management has the same behavior as compression, but doesn't compress the same things with the same address space, etcetera. So it's written in the document. But regarding the young data model is just that now universal compression can be triggered by compression or management. Management also so in the document management document, there is also an introduction of the guard period during, which you cannot reuse the same rule for management. It's due to propagation delay. For example, if you are doing something on mass, you you have to wait to be certain that the thing is deleted before using it. So that's the gap period. And so it's a context for management. And right now, so we we introduce also this management context and with the gap period with the way we represent time in the chic data model. So that's all. We don't specify any management rules. We just give the framework, and then we will have more over document over document that can do more complex or more accurate management or more efficient management, for example, as using RPCs. And we think it's a better way because you will have different kind of management. You will not manage an high speed network the same way you manage connection to Mars or a constraint network. So you you we can have different kind of traffic pattern. And so RPCs can apply to these different patterns. And so it's better to define these RPCs or other things that can be invented in other document using their old seeds to or or their own young data model to represent these RPCs. So the here, we just have the support for management. So here so we talk a little bit about SID allocation, but it's something that has will have to be discussed in more details when we will have a more ready to document about the young data model. So what we recommend is to use manual allocation and or not automatic allocation because the positions of value has an importance in the performances. And, also, there is this document on private translation that has been proposed to the core working group. And if we use it, the close so the the small value or the value that are close to the first SIDs have a better are smaller than the other one. So it's better for, for example, things we find in the rule like equal not send. So things that are very, very common and can be very, very well compressed. And this document shows 23% of compression when we use it. So that's what we propose. So it's a work in progress. So it's now for discussion to have over proposal to to discuss them. So all these things have been also tested in the Ashik implementation. And when we will be from my my point of view, when we will be ready on this to work document, then we can easily write l f c 93 based document. And that's all. Are you sleeping?
[00:46:04] Alexander Pelov: Okay. Thank you, Laurent. Yeah. As I said, I think that there are a lot of interesting things here that are very specific to the different drafts. So maybe you can go ahead and already implement them in the individual drafts, which are already working group items, right, and are already standard draft documents.
[00:46:26] Laurent Toutain: As I said, the only one is ICMPv6.
[00:46:30] Alexander Pelov: And universal and universal option as well.
[00:46:33] Laurent Toutain: But we have to change it totally.
[00:46:36] Alexander Pelov: Okay.
[00:46:40] Laurent Toutain: So I can copy past to this one, but I don't see the interest. But I can do it. I c m p v six is a discussion.
[00:46:52] Alexander Pelov: It is I mean, it's it's I mean, from from from working point of view, I think it's it's the way forward to actually push the like, implementing the in in the ongoing working group items documents. And then if there is a new working group item that that is to be proposed, you know, we need to validate that. We need to vote for it to to to accept it as working group item and and see that which parts are in the scope and so forth. So I think it's go it's actually going to be much faster to to go with the individual individual drafts. But as I said, like, you you one of the ideas that you said here, they're applicable. So I think it's it's important to have these discussions on the technical part.
[00:47:37] Laurent Toutain: I would prefer discussion on technical part than just editing version.
[00:47:43] Alexander Pelov: Yes. Okay. Thank you. So if there are any not any other questions. So then we have for a little bit less than fifteen minutes. Let me take that. So, yes, excellent work, Laurent, Marco, Samar. That really gives new perspectives of what remains to be done. So one thing I wanted to to present is a work I've presented also on the tip top working group. And there was, of course, it was suggested that I really need to present that in Shihc also. So I'm taking the opportunity to talk to talk about the I c m p v six sec for Shihc. Also, another thing that prompted this presentation was the mail from Martini on on on the mailing list where she was actually speaking about DTLS and and the different types of adaptations. And, actually, the the interesting part about this is that we've been working on on such problems even before, and and I think it's it's a it's important thing to to think about. So this is just an example. It's not the only one it's not the only case in which ICNPV six sec is is is applicable. So here we have an I p v six host talking to an I p v six network through a shape gateway as we go. And then behind, we have an l p one segment. And we have the an endpoint, an I p v six endpoint. So the point is that, like, the example is, of course, GTLS, and that was the the the case that Martin is working on, is that, of course, in if we take an example for one specific l p one technology, but many of them are are like this, Uplinks can be triggered so downlinks can be triggered by uplink. Sorry. So in order for the network to be able to contact the device, the device needs to send some some information. Right? So let's say that the I p v six host on the left hand side actually tries to open a DTLS connection. And, well, it times out. It it it goes to the Shake gateway. Right? But the Shake device is is sleeping. So, again, the initial handshake timer ex expires, so it sends a new handshake timer and then a new handshake timer. And then at some point, the device, like, twenty minutes from that, wakes sends a message, right, on the blink message. So the SheetQuake gateway can actually, send one of its, one of its, packets to the device, like, that was scheduled. So that's actually the the risk the first client, hello. And it gets to the device, and the device says, oh, yeah. Hello. So it answers. That gets to the initial IPv six host, but, like like, too late. Timers are expired now. And it actually is going to proceed in sending all the client hello messages, and, like, that's a huge waste of of, bandwidth and, of everything. And it actually may render impossible the the use of GTLS in some cases. Right? So the way we'd handle this in the past was actually to fix the DTLS timers by hand. So, basically, this whole the the like, the the the DTLS client knows that it's talking to a DTLS server all over an network that has a huge delay, and this is fixed. And as you can I mean, I find that particularly not gracious? So one of the ways actually is to say, hey. Why don't we introduce a mechanism for the for the, actually, the gateway to be able to signal to the to the host that, hey. Well, on the other hand side, you have an l p one segment that is, like, with a with a with a huge delay compared to normal networking protocols. So this is where actually I p I c m p v six sec comes. So it's in I c m p v v six message with which actually contains a COSE signed segment descriptor. And in in with it, there is some information. So, like, which is the prefix? What's the validity? And and some metadata that that can be, of course, defined. Like, say, like, okay, the RTT, the expected RTT can be fifteen minutes or four days or or whatever depending on your device. So now the host so here we of course, there needs to be some mechanism. It can authenticate that this message is indeed valid. Right? That is it was not forced by by anyone. There needs to be a mechanism for it to trust, of course, the this the the the entity that signed that that that message. But then it can say it can say, okay. Now I'm going to wait. My I'm going to adjust my timers. And when the Sheet Gateway has the opportunity to send the message actually to the device, which can be, like, twenty minutes later, one hour later, the device can send the response back. It can go back to the I p v six host, and the timers will not have expired. So that's actually true for the DTLS part, but it's also true for the applicative part, for the application part. Because if the application is sending a lot of keep alives or stuff like this, you know, it can overrun the whole thing. Now the format is, of course, very simple. Like, it's it's it's a simple informational message. There are two code points that we're introducing the draft, like, treatment is required or was was rejected. So in some cases, the gateway can actually reject some packets, and in other cases, it can it can graciously, like, just inform but not reject it. And yeah. So there is, a COSE sign tag with a sigma descriptor, and these are things that need to be, of course, defined exactly. They could be extensible. The information that is going within that within that information that's signed. Now that's what's interesting here is that the whole part that is signed is static. So it's valid for a period of time, let's say, one day. So there can be, one auto authentication or or issuing entity that produces this signed COSE object. And then the sheet gateway or any kind of router, by the way, can just include that in their I c m p v six message I c m p v six message. So it's not something that you need to sign and regenerate on every packet. And, yes, so this is an example of why without I c m p v six sec doesn't that doesn't work because you can have an attacker that that can wait make you wait for for long time. Regarding shake, that that can have interesting perspective, which is, of course, like, optional. Right? So this this is just opening the the chakras. And the idea is that maybe, in some cases, the sheet gateway can actually identify can can tell to the to the sender, hey. This this is my these are my this is my sheet context. Right? Oh, sorry. That's yeah. I I changed that later. So, yes, so you have, like, a random source port port opening a co op connection, but that doesn't compress very well very well. So there is a rule compressing this, but there's actually a specific rule that says, well, if the source port is 30,500, then, you know, I'll compress that as well. So in any case, the ship gateway is sending this information ahead of time, and so the host could potentially say, hey. Well, you know what? My port my UDP port thirty five five hundred, I can use that. So it can start using that that port, which then will compress better on the l p one segment. And that, of course, can be used for for other users. And what's interesting is, of course, that you can use that for for quick to to adapt the the initial RTT policy and timers, so which is mostly use case for for Tip Top. You can use for co op, for time outs, and and other lifetime another lifetime considerations. So, yes, I I Not I'm not going to. So that's that's all. I think that can be a useful addition to the to the chic to the chic working group at some point. And if you have any questions, I'll be happy to answer them. Yes, Laurent?
[00:56:31] Laurent Toutain: Yes. Two point. First, I think this drawing is misleading because from the IPv6 host, there is no shit gateway. For the ICMP IPv6 host, it's a router. And this router has a specific interface that is doing SCHC. So it means that if you know you cannot know this device. In the Internet, all router are unknown. Yes. The only so when you say I have I authenticate something, I don't know how you can prove that you you go through this router. So I think it's a very big change in the Internet model where you have routers that are just forwarding from time to time a packet. So here, you you change it a lot. And my my other question is that it's not in the scope of the of the group to do that. So do you want to to change the charter? Or because it's more something for I p v six ops. Or
[00:57:36] Alexander Pelov: Yes. Yes. I mean so second point, of course, it's not in the scope of Schcke, and and the idea is to go through Interior or I p v six ops. I mean, whichever is is most appropriate. And on the first point, actually, that was initially defined for for a setup that was not only l p one. Right? So the shared gateway here is residing on a on a router. So the I p v six host that is opening the connection, it actually contacts direct it it sends a package directly to the endpoint so that the packet is destination the destination is the I p v six address of the Shake device. So so that happens that in an l p one, it will always go through a Cheek gateway. And that Cheek gateway, which is a router, at that point, will send unsolicited I c m p v six sec message to the I p v six host that send the initial packet and saying, hey. You know, you you are think you know you're thinking about communicating with some random I p v six device, but, actually, there is an l p one segment here. And that l p one I mean, there is a high RTT segment here. And that high RTT segment, like, will answer you in forty hours or the RTT is one day or seven days. Right? So the IPv6 host that initially send the packet, they can, of course, ignore that and say I mean, they can be unaware of any of that. But they can also if they are aware of ICMPv6-SEC, they can take that back and say, oh, okay. So I I I see what's happening. So and I have the capacity to adapt. Right? So I'll do that. So it works for any router, for any for any topology, and it's exactly the way it it's intended to to work. So thank you very much. I I I think this this draft opens interesting perspectives. Of course, as Laurent said, it's it's not our it's not going to become working on item on this working group. But I think it's thank you. Thank you, Eric. I I think really that there can be some other uses of that of that of that particular draft, knowing also that, like, there is no processing there is no signature in real time. Right? The router is is it's it's it's a static thing that can that's updated. So thank you very much. Thank you all. We're at the top of the hour. So next interim is in two weeks time. And, yeah, if you have any items to discuss until then, I'll be very happy. We'll just send them to the to the mailing list. Thank you all, and have a nice day. Bye. And oh, yes. Yes. The security considerate. Yes. Yes, Eric?
[01:00:41] Éric Vyncke: Just want to say thank you, and bye bye. Yeah. We're just closing. That's all.
[01:00:47] Alexander Pelov: Yes. Yes. And the security considerations, yes, they they have to be and and very close. And thank you very much, Marco, for for taking the minutes again this this time. Thank you all.