However, the PSP behavour doesn't even fit in that fictional interpretation of RFC8200.
What PSP does is that, given: ---- B ----- C routers, when B realizes, after processing the SRH and setting the Dest Addr to the last segment, SegmentsLeft==0, it removes the SRH. This case is not even covered by their fictional interpretation of RFC8200. RFC8200: Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. Isn't the word 'reaches' clear? A packet with the destination address owing to node B 'reaches' the node B. How can this be claimed again violation 8200 after 2 months? I remember that, Bob, Joel and many others had clarified this very clearly 2 months before, which led to the errata, saying 'clarifying' 8200. ----look at the errata---- Section 4 says: Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. It should say: Extension headers (except for the Hop-by-Hop Options header, or a Destination Options header preceding a Routing header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the final destination node (or each of the set of final destination nodes, in the case of multicast). So do you think the RFC8200 had made so big a mistake without awareness of the distinction of 'destination' and 'final destination' for 25 years since 1883 ? And the folks that had been participated in the meantime had been made the same mistake for 25 years since 1883? I can find the word 'reaches', 'destination' and 'final destination' in RFC1883 clearly, and I assume this distinction had been well aware of since 1883. Thanks Jingrong _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
