On 2017-02-17 Joel M. Halpern wrote: > I disagree with your interpretation of the bar the document must meet. > I believe I have clearly stated my concern. > I will leave that judgment to the relevant ADs and IESG when they > review the last call results. Thank you for saying this. I am glad to see that someone who was not involved in the WG discussion has chosen to speak out in support of that position. During the WG discussion, I said: "If I were on the IESG and a spec came to me with a known ambiguity, I would vote to send it back to the WG with instructions to resubmit it after the ambiguity was fixed." I would base that on the following language from RFC 2127, Section 3.1 (which replaces similar language in RFC 2026, Section 4.1.1): A Proposed Standard will have no known technical omissions with respect to the requirements placed upon it. The relevant ADs and IESG may see this differently, but in my view, language that has been shown to admit conflicting interpretations, either by implementors or by authors of subsequent specifications, constitutes a "known technical omission," and if that's not good enough for PS, it's clearly not good enough for IS, either. There is ample evidence in the record that the language in both 2460 and now in 2460bis has led to conflicting interpretations regarding the admissibility of insertion of extension headers by any node other than the one originating the packet. The main discussion in 6man focused on the segment routing header, where versions of draft-previdi-6man-segment-routing-header up through 07 called for insertion of that header by a border router, and according to https://www.ietf.org/mail-archive/web/ipv6/current/msg20892.html and https://www.ietf.org/mail-archive/web/ipv6/current/msg24145.html, that behavior was actually implemented (for further evidence, see also https://lwn.net/Articles/698841/). That behavior was removed in favor of encapsulation in the -08 version of the draft and also in the version adopted by 6man (draft-ietf-6man-segment-routing-header), but the older implementations apparently linger on. The early SRH drafts, however, are not the only examples of conflicting interpretations of the language in 2460. RFC 6621 Section 6.1.3 says: If a digest collision is detected at an SMF ingress point, the H-DPD option header is constructed with a randomly generated HAV. An HAV is recalculated as needed to produce a non-colliding hash value prior to forwarding. The multicast packet is then forwarded with the added IPv6 SMF_DPD option header. By contrast, RFC 4782 (Quick Start) and RFC 6971 (Depth-First Forwarding) were careful to specify that the HBH options defined therein were either inserted by the source node or that encapsulation was used if inserted by a non-originating node. I couldn't find any discussion of 6621 or 6971 in the 6man archive. I did see 4782 mentioned as problematic, but I didn't get that from reading the RFC, which carefully discussed compatibility with AH. On 2017-02-17, Ole Troan wrote: > Do we agree that you can see this at two different angles? > > 1) Are there any interoperability issue or ambiguity in the protocol > specification of 2460 and how implementors of 2460 have interpreted > that? > > 2) Is 2460 "future-ambiguous", i.e it is unclear if 2460 permits a > future extension? Like ECMP, Header insertion NAT... Question #1 is incomplete, as it fails to ask if there is an ambiguity that has tripped up authors of specifications extending IPv6. That is demonstrably the case. And it is equally clear from the discussion on record that insertion of extension headers by intermediate nodes breaks fundamental assumptions of IPv6 and causes some of the core specifications to fail. Question #2 is also incomplete, as it fails to acknowledge the difference between extensions that break parts of the core specifications and those that do not. > I'm trying out the argument of declaring the whole question of > ambiguity out of scope. To see if there is better consensus for > that. And I am hoping that the community and the IESG do not buy this. Best regards, Mike Heard