Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]