> On Feb 17, 2017, at 9:12 AM, otroan@xxxxxxxxxxxxx wrote: > > Fernando, > > It is a simple logical consequence. > > Middleboxes do not exist in the IPv6 architecture. firewalls do not exist in IPv6???? load balancers do not exist in IPv6??? content redirectors do not exist in IPv6??? … Scott > There is no interpretation of 2460 that can lead to an implementor inserting headers other places than at the source. > Therefore, there is no interoperability issue in RFC2460 nor any ambiguity that needs to be resolved in RFC2460. > > We're not writing law, we're writing interoperable protocol. > > Ole > > >> On 17 Feb 2017, at 13:40, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: >> >> On 02/15/2017 07:18 AM, otroan@xxxxxxxxxxxxx wrote: >>> >>>>>> Ole, it is true that we write in English, and there is always room for >>>>>> "interpretation", sometimes reasoanble room, sometimes not. >>>>>> >>>>>> But in this case we have a demonstrated difference in how people >>>>>> understand the existing text. When we have such a demonstrated >>>>>> difference, we have an obligation to address it. >>>>> >>>>> This particular issue has caused no interoperability issue, >>>> >>>> May I ask what's the data that support this statement? >>> >>> From the shepherd's writeup: >>> IPv6 is implemented on most platforms (hosts, routers, servers, etc.), >>> including proprietary and open source. A list of products that have >>> received the IPV6 Ready logo can be found at: >>> >>> https://www.ipv6ready.org/db/index.php/public/?o=4 >> >> This has nothing to do wth the interoperability problems that may be >> caused by a middlebox that inserts EHs. >> >> >> >>>> You certainly have no way of knowing this, or whether interoperability >>>> issues may arise in the future. >>> >>> Yes, we do know if our protocols have interoperability issues. >>> Have you implemented RFC2460? I have. So have many others on this list. >>> In the context of implementing 2460 there just is no ambiguity and this issue will never arise. >> >> Huh? Yes, if you connect two IPv6 devices, without a middle-box >> inserting EHs in the middle, you will not experience the associated >> possible problems. What's the news here? >> >> >> >>> What you are talking about is something else. You are talking about the hypothetical "What if someone standardised something new in the future?" >> >> :-) >> >> C'mon, Ole. Take a look at the initial versions of the SR I-D -- and, EH >> insertion has reportedly been deployed as a result of the implementation >> of such initial versions of the I-D. >> >> >> You can clarify that EH insertion is banned, and move rfc2460bis to full >> stanard (since that's what's supposed to be mature) >> >> You can delay rfc2460->std, and work to update rfc2460. >> >> Now, moving rfc2460 to full std knowingly leaving a hole there such that >> after rfc2460 is std you completely change the architecture (e2e vs >> !e2e) with EH insertion doesn't seem a serious thing to do, IMO. >> >> Thanks, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@xxxxxxxxxxxxxxx >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >