El 17/2/17 a las 2:14 p.m., Scott O. Bradner escribió: >> 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??? > … I was about to ask the same question > 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