> It's not about "not liking". I'm very happy about contributions, > including (of course) yours. It's about making sure that code we merge > into the kernel GTP driver will actually be usable to create a > standards-compliant GTP application or not. > Harald,
Do you believe that these patches are not at all on the right track, that they can't be built upon to get to a standards-compliant implementation, and that we are going to have to throw all of this and start from scratch to provide IPv6 support? > There's no use in merging an IPv6 support patch if already by code > review it can be shown that it's impossible to create a spec-compliant > implementation using that patch. To me, that would be "merging IPv6 > support so we can check off a box on a management form or marketing > sheet", but not for any practical value. > To be clear, these patches are not done because to be a bullet point on a marketing sheet. IPv6 is becoming _the_ Internet protocol. It continues to exhibit exponential growth (~20% of Internet, per Google stats), I believe least two of the largest datacenter operators are running everything over IPv6, and there are already proposals to start official deprecation of IPv4. In the mobile space IPv6 is going to be a critical enabler of IoT and security in technologies like 5G. If we want Linux to be at the forefront of the next technology wave then we need to focus on IPv6 now! We should be far past the days of vendors only providing IPv4 in the kernel support because "that's what our customers use" and they'll get to IPv6 support at their leisure. IMO, davem has every right to unilaterally NAK patches that only support IPv4 or only test IPv4 with not even a path or timeline for IPv6 support. Thanks, Tom
