As requested, My original email on this topic quoted below – but first some thoughts on how we could fix this.
1. We could mandate the imposition of an HBH and then state that the draft updates 8200 with adequate text and with 6man agreement – this would allow for correct checksumming 2. We could mandate SRH – though I think this would still require the document to note that it updates 8200 and contain text as to how 3. We could draft and propose a BIS in 6man to update 8200 to cater for this – and then make the BIS normative to this draft – meaning that they get clustered by the editor such that one does not move without the other. So I’ve given a lot of thought to the checksum issue – and here is where my thinking is currently sitting. ---- Quoted original email on this topic below ---- Firstly – RFC8200 does not mention the word middlebox or middleware anywhere. Nor does RFC8200 specify anywhere that the checksum should not be verifable in flight. Indeed, section 8.1 actually details how to handle extension headers as well – in order to make the checksum valid (Last paragraph page 27) Now, while there are specific uses cases for in flight validation of checksums which I’m not at liberty to discuss here, surfice to say that they exist and stem from the need to verify that packet changes aren’t occuring in flight – I believe that’s kinda besides the point. The point here is that as it stands, the draft violates RFC8200. This leaves two options in my view a.) Either update 8200 – with the agreement of 6man – or pass an RFC8200 BIS through 6man. Either way – if you are violating a standard held by another working group – and this does violate section 8.1 – you should be updating the standard that is being violated or alternatively BIS’ing it to avoid the violation. But both require that 6man is in full agreement, since SPRING is not chartered to make updates or violate standards put forward by another working group. Hence – my suggestion would be to take this to 6man and go through the process, though at minimum I fail to see how this cannot update RFC8200. In fact, let me be clear here – any attempt to pass this document WITHOUT correct review by 6man will result in an appeal. Thanks Andrew ---- End of quoted email ---- Thanks Andrew Internal All Employees From: Alvaro Retana <aretana.i...@gmail.com> Date: Wednesday, 3 April 2024 at 15:40 To: Andrew Alston - IETF <andrew-i...@liquid.tech>, SPRING WG List <spring@ietf.org> Cc: spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression) CAUTION: This email has originated from a free email service commonly used for personal email services, please be guided accordingly especially if this email is asking to click links or share information. On April 3, 2024 at 7:59:20 AM, Andrew Alston - IETF wrote: > Just a clarification – I believe my comments on section 6.5 have been well > documented in other threads – would you like them duplicated here for > clarity? Yes, we do. Thanks! Alvaro.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
