I agree that issue #4 can be closed. Thanks.
Xinxin Yi China Unicom 发件人： Joel Halpern<mailto:j...@joelhalpern.com> 发送时间： 2023-08-08 23:00 收件人： SPRING WG List<mailto:spring@ietf.org> 主题： [警惕！外部邮件][spring]Confimring resolution of issue #4https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ Issue #4 reads: In some cases it is possible that the SR policy can be expressed purely with C-SIDs without requiring an SRH. In this case, to allow the SR domain to fail closed, some form of filtering based on the LOC part of the SRv6 SID is required as relying purely on the presence of an SRH will not be sufficient. I would also like to note upfront that it is already possible based on RFC8754 to send packets without an SRH (e.g. one segment encapsulated into outer header) but having C-SIDs makes it applicable to a wider set of use cases. The response from the editors reads: Added text in revision -01 (Sec. 12<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-05#section-12>) indicating that the SRv6 security model (Sec. 5.1 of RFC 8754<https://www.rfc-editor.org/rfc/rfc8754.html#section-5.1>) also applies to the SIDs defined in draft-ietf-spring-srv6-srh-compression. The SRv6 security model uses IP address filtering (SRv6 SID block) and does not rely on the presence of an SRH. Please indicate to the list whether you consider this resolution sufficient to close the issue, or have further concerns that should be addressed. If you have concerns, clarity about them is appreciated. This call is open for two weeks, through August 22. 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
