Hi Greg, Thanks for bringing that question up. I already considered this aspect.
As described in https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-00.html#section-2, the compressed-SID container (C-SID container) is 128-bit long and contains a sequence of C-SIDs. Therefore the ipv6SRHSegmentList contains either a list of IPv6 SID's, a list of compressed-SID containers or both. They are not mutually exclusive. It probably makes sense to add an operational consideration section in draft-tgraf-opsawg-ipfix-srv6-srh to describe the use of C-SID containers and its context to ipv6SRHSegmentType. From what I understood, and here I would like to have feedback from the mailing list, it does not bring much added value to decompose the C-SID container into Compressed-SID (C-SID) in IPFIX. Best wishes Thomas From: Greg Mirsky <gregimir...@gmail.com> Sent: Sunday, February 13, 2022 10:04 PM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com> Cc: liu.ya...@zte.com.cn; spring <spring@ietf.org>; opsawg <ops...@ietf.org> Subject: Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, et al., what do you think of the new SPRING WG draft that introduces two methods of the compressed SRv6 SID list encoding in the SRH<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-spring-srv6-srh-compression-00&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488208938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kHsEVStOgei6tm0OgQ00UeakH%2F2ZfnGg3qn55Gma%2B84%3D&reserved=0>? Regards, Greg On Sat, Feb 12, 2022 at 12:10 AM <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> wrote: Dear Yao, Thanks a lot for the detailed description. Both understood, acknowledged and being merged to the -01 version. Feedback welcome. https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-01.txt<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgraf3net%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2Fmain%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgraf3net%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2Fmain%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-01.txt&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488208938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TDxmVS7VAaC5mIlkUk53I3enMpt%2F8%2BLpV9qrkpCAWKg%3D&reserved=0> I will publish -01 in the upcoming weeks before IETF 113. Best wishes Thomas -----Original Message----- From: liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn> <liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> Sent: Monday, February 7, 2022 10:42 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, Sorry for the late reply. Please see inline [Yao2]. > [Yao] Segments left is one of the elements to identify an SRH. For example, > (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) > (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also > useful when exporting SRv6 information. Would you agree that ipv6SRHSegmentList at node egress would be equal to Segments left? Or in other words segments left would only differ at ingress to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would you please describe me what kind of use case you have in mind. [Yao2] I mean without segment left, it's difficult to distinguish between packets of the same segment list in some cases. Below is one scenario I can think of. The corresponding segment list of path 1--A--2--3--1--A--4 is <SID-1,SID-A,SID-2,SID-3,SID-1,SID-A,SID-4>. 3 / \ / \ 1 2 \ / \ / A-----4 The flow passes node A twice. The first time, the packet is (SA,DA=SID-A)<SID-1,SID-A,SID-2,SID-3,SID-1,SID-A,SID-4; segment left=5>. The second time, the packet is (SA,DA=SID-A)<SID-1,SID-A,SID-2,SID-3,SID-1,SID-A,SID-4; segment left=1>. If one wants to collect the info of these two traffic separately, the segment left element is needed. But to be honest, I'm not sure whether this requirement is strong. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? You mean the entire SRH header without disassemble the dimensions into IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes a lot of sense and I consider this to the -01 version of the document. [Yao2] Yes, that's what I mean. Best Regards, Yao ------------------原始邮件------------------ 发件人：thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 收件人：刘尧00165286; 抄送人：spring@ietf.org<mailto:spring@ietf.org>; 日 期 ：2022年01月30日 14:17 主 题 ：Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Yao Thanks a lot for your input. > [Yao] Segments left is one of the elements to identify an SRH. For example, > (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) > (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also > useful when exporting SRv6 information. Would you agree that ipv6SRHSegmentList at node egress would be equal to Segments left? Or in other words segments left would only differ at ingress to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would you please describe me what kind of use case you have in mind. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? You mean the entire SRH header without disassemble the dimensions into IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes a lot of sense and I consider this to the -01 version of the document. Looking forward to your clarifications. Best wishes Thomas -----Original Message----- From: liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn> <liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> Sent: Tuesday, January 25, 2022 10:27 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, Please see inline [Yao]. Best Regards, Yao ------------------原始邮件------------------ 发件人：thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 收件人：刘尧00165286; 抄送人：spring@ietf.org<mailto:spring@ietf.org>; 日 期 ：2022年01月23日 01:16 主 题 ：Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Yao, Many thanks for the review and feedback. > 1) But this draft describes the routing protocol where the last SRv6 segment > has been learned from, instead of the SRv6 segment to be processed by the > current hop. I am going to rephrase the sentences to refer to the active segment. Which should make it less ambiguous. > 2) but in SRv6, segment list and segments left(currently not defined in the > draft) are both needed to provide the similar information. Could you elaborate the use case for segments left in this context. This document covers all dimensions being present in the SRv6 segment routing header described in section of RFC8754 (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8754%23section-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n6Y0xX3DT1BmusOLbuUXDZHb2CQ%2BiJlY%2FSOPxIcTr7c%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8754%23section-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488208938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=J4kP2W10U3leUPHOREQD9T38cRFLN2hpk%2B4JSP7L3Kg%3D&reserved=0>) with the exception of "Last Entry". [Yao] Segments left is one of the elements to identify an SRH. For example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also useful when exporting SRv6 information. > 3) Element for SRH TLV is not defined in the draft, what's the consideration > about that? Could you elaborate further please. The document refers to RFC 8754 where the SRH TLV is being described. [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined. What if the user want to export the SRH TLV info of the packets? Best wishes Thomas -----Original Message----- From: liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn> <liu.ya...@zte.com.cn<mailto:liu.ya...@zte.com.cn>> Sent: Thursday, January 20, 2022 10:23 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, I've read the draft and have some questions. 1) RFC 9160 introduces new protocol types for SR-MPLS top label. Considering that the MPLS top label is always the label to be processed, the user can know which protocol the SR-MPLS SID to be processed is learned from. But this draft describes the routing protocol where the last SRv6 segment has been learned from, instead of the SRv6 segment to be processed by the current hop. As for my understanding, the current draft is inconsistent with RFC 9160 in this aspect. 2) Related to point 1，in SR-MPLS, exporting the top label can provide the information of the segment to be processed, but in SRv6, segment list and segments left(currently not defined in the draft) are both needed to provide the similar information. 2) Element for SRH TLV is not defined in the draft, what's the consideration about that? Best Regards, Yao ------------------原始邮件------------------ 发件人：thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 收件人：spring@ietf.org<mailto:spring@ietf.org>; 日 期 ：2022年01月15日 17:27 主 题 ：[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Dear SPRING working group, Following up on just released RFC 9160 (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9160&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZRYzSkFXCDSSUYprLXjgHAdfQHPLFnTl6sA8xMW2Ur4%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9160&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488208938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=I0GnfozIeuSYFchVdB9Sdq5pJKJA%2BMjgf8KT%2B4v48N8%3D&reserved=0>), IPFIX code points for MPLS Segment Routing, https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488208938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c8ihx%2Bs9Grfg3yTi2ToH4EYb6atdfITghPN7HtQyx2A%3D&reserved=0> has been submitted for the SRV6 data-plane. The document aims to be on par with MPLS-SR. Describe the routing protocol or PCEP extension where the last SRv6 segment has been learned from, the SRv6 segment list and all other properties from the Segment Routing header. I would appreciate your document review and feedback. I aim to present at IETF 113 at OPSAWG and SPRING and request adoption at OPSAWG. Best wishes Thomas -----Original Message----- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Sent: Saturday, January 15, 2022 10:12 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-00.txt has been successfully submitted by Thomas Graf and posted to the IETF repository. Name: draft-tgraf-opsawg-ipfix-srv6-srh Revision: 00 Title: Export of Segment Routing IPv6 Information in IP Flow Information Export (IPFIX) Document date: 2022-01-15 Group: Individual Submission Pages: 9 URL: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-00.txt&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XSp7znVjIkQqPZLpCUx04tD1eaH9RoOHT6xJlX1cMq0%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-00.txt&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488365153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7gyRqfySbUmSFMNdZQ6%2FS9UXgsFg0Xd57YV2hfOWd%2FI%3D&reserved=0> Status: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=e80kd7Krk7V4yiw6jtjyh7O144HPwwAlJkUMNYcOzXc%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488365153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JUW%2BtvvAhDd964%2BeSpDdQeadj1filgdSoJiXwaVW4xE%3D&reserved=0> Htmlized: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488365153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OPg55%2FKDI8eeUInZVuvNZyXSEGIkCuIOZDPB1IJKpaY%3D&reserved=0> Abstract: This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded with which Segemnt Routing Header dimensions based on which SRv6 control plane protocol. The IETF Secretariat _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488365153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0wGhClqPrpptr4ky9mINYgdotf%2BjS9NqxDe7dBJ0bT4%3D&reserved=0> _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488365153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0wGhClqPrpptr4ky9mINYgdotf%2BjS9NqxDe7dBJ0bT4%3D&reserved=0> _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488365153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0wGhClqPrpptr4ky9mINYgdotf%2BjS9NqxDe7dBJ0bT4%3D&reserved=0> _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3874d50b47024e587a9e08d9ef345fee%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637803830488365153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0wGhClqPrpptr4ky9mINYgdotf%2BjS9NqxDe7dBJ0bT4%3D&reserved=0>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
