Bruno, On 11/12/19 14:48, bruno.decra...@orange.com wrote: [....] >>>> If you think a document on tunnels rules how IPv6 operates, and its >>>> end-to-endianness, then you have a huge problem reading specs. >>>> >>>> So I will not enter that game, because it would be accepting to be >>>> mocked at. >>>> >>>> I'll wait for a few days for our INT AD's response (Suresh), a response >>>> from the spring chairs (if any), and a response from the RTG AD(s). >>> >>> I'm not sure what response to what question you expect from spring chairs. >> >> A number og wg participants are letting the chairs and ADs aware that a >> wg document contains an outright violation of an Internet Standard > > That point is noted. > But given that a number of wg participants are saying the opposite, we need > to go a bit deeper in the discussion. That's what I've tried to initiate and > I believe that we have made progress.
Filling an errata somehow warrants that a clarification on the topic is about to come (in the event it was ever needed). > > My understanding is that you are saying that > PSP and USP, as defined in [1] and more specifically "Pop the SRH" > contradict with [2] and more specifically > " Extension headers [...] are not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the node [...] identified in the > Destination Address field > of the IPv6 header." > > > More specifically, your point is that " the Destination Address field of the > IPv6 header" is to be understood as " final destination node" > https://mailarchive.ietf.org/arch/msg/ipv6/Ku-kKBE-vG5QGdT2DvqLxMQpRik My point is that according to RFC8200, which does not specify any routing header types, the destination cannot contain anything else other than the final destination of the packet. The spirit of what the text means is also well known to all of us 6man participants as we discussed the topic while working on what eventually became RFC8200. [...] >> that >> spring is not in a position of changing. > > 6man consensus is written in RFC 8200. I can read it as any other one. > Actually you are the one trying to modify that text. > But to your point, believe me, I'll be more than happy to give that ball to > someone else. E.g. to my AD then IESG and flagging that point in the shepherd > report. > I'll also monitor your above errata, to see if it's been accepted or > rejected. That will typically be a strong input in the balance. Agreed on this last item. -- that was part of the motivation of submitting it. > >> I deem that as a major issue, and I'm curious how you might possible >> ignore it, declare consensus, and ship and request publication of this >> document. > > Noted. > I'm not ignoring it. Quite the contrary I'm the one engaging the discussion > with you in order to understand the real technical point that you want to > make. The esensce of my technical point is that IPv6 does not support inserting headers or deleting them on the packets delivery path. And PSP requires exactly that, violating RFC8200. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
