Hi All, (In capacity as a contributor and wearing no other hats)
At this point I cannot support progression of this document until the issues around the L4 Checksum have been resolved. It’s been clearly stated in other emails on the list that in certain circumstances the behavior described in this document break the L4 checksum as defined in RFC8200. This requires an update to RFC8200 to fix it – and I’m not sure that spring can update 8200 absent the consent of 6man, which I’m not sure has been asked for, nor am I sure that a spring document can update something like 8200 in an area so fundamental as the checksum without a -BIS, which would have to be done via 6man. The L4 checksum issue though is real – and it cannot simply be ignored. I also have deep concerns that the compression document creates something that (in a similar way to SRv6) creates something that is completely non-conformant with RFC4291. There are multiple references to this in draft-6man-sids, and should draft-6man-sids become an RFC I would argue that it should probably be a normative reference in this document – on the logic that this document relies on similar RFC4291 violations that srv6 itself does (and for the record, just because SRv6 itself violates RFC4291 as is clearly documented in draft-6man-sids – does not make it acceptable to do so in yet another draft without clear and unambiguously stating the deviations and ideally updating RFC4291 to allow for said deviations) I believe these two issues alone are sufficient that to pass this document would create still further tensions about the relationship between SRv6 and IPv6 and lead to confusion. As such – I believe these issues need to be adequately dealt with – and the solutions to them need to be approved by 6man as the working group that holds responsibility for ipv6 maintenance. Thanks Andrew Alston Internal All Employees
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
