Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)

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

 



It is not an ad-hominem argument. And ad-hominem is only invalid as a form of logical argument, it is actually legitimate when considering facts and axioms.

Strictly speaking Ad-Hominem would be 'that idea must suck, X likes it'.

What was stated was 'your refusal to be reasonable on this issue is the reason why IPv6 is not deployed'. 

Which in this particular case happens to be the fact.


For the past fifteen years, the IPv6 deployment strategy has been based on features. Which is a bad strategy because applications want to have as few dependencies on the details of the underlying layers as is possible.

In particular there have been people who have argued against making NAT transparent in case it is a little too good and delays deployment of IPv6 further.

After fifteen years the market has rejected that approach. Carrier grade NAT has a much higher priority than IPv6 for the product managers of all the router layer companies who send people to IETF.



On Thu, Oct 7, 2010 at 1:04 AM, Richard L. Barnes <rbarnes@xxxxxxx> wrote:
NEW NON-IETF LIST ANNOUNCEMENT

IETF Ad Hominem Discussions

This group is dedicated to the discussion of the personal flaws of IETF participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies

<http://groups.google.com/group/ietf-ad-hominem>




On Oct 6, 2010, at 9:29 PM, Michel Py wrote:

Michel Py wrote:
Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?

Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.

They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.


Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.

I think you give me far more "credit" than I'm due.

Maybe, and I certainly deserve some "credit" myself; nevertheless some,
(rather large) amount of some flavor of NAT was unavoidable and I still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.



Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically
'IPv4
with a few more bits', instead of a fundamentally revised architecture
that would provided real benefits in the form of major new
capabilities
(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.

Problem is that IPv6 is much more than IPv4 with more bits. Please note
that this is not a "I told you so" post; I would certainly have opposed
what I will suggest below.

In the end though, we would be better off now if we had gone the road
"it's all the same just pad some extra zeroes" instead of this grandiose
solve-it-all almost-perfect protocol we all dreamed of.

As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.

Our collective failure is that we have launched a protocol with "to be
delivered soon" advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.

Now, what we have on our hands is a mess with a protocol in state of
"non-deployment" that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb "just more bits" upgrade.

Michel.

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



--
Website: http://hallambaker.com/

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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