Christian Huitema wrote:
From: Noel Chiappa, Monday, July 02, 2007 6:08 AM
> From: itojun(_at_)itojun(_dot_)org (Jun-ichiro itojun Hagino)
> if NAT-PT is to be made historic due to the claims presented in
the
> draft, all of the NAT related documents have to be made historic
> ...
> and all of the NAT traversal documents .. has to be banned at
once.
> itojun(_at_)fahrenheit 911
The irony of that email address, appended to that message, is pretty
good.
Noel
:-)
:-) :-)
Firstly, let's be clear that there is a difference between NAT and
NAT-PT. The draft makes it clear that a major reason for not wanting
NAT-PT deployed is that it effectively ties many of the characteristics
of a developing IPv6 network to those of the existing IPv4 network.
Whether there would actually be real differences remains to be seen but
clamping IPv6 through a transition mechanism seems very short sighted,
whatever the technical shortcoming of NAT-PT (or NAT) might be, and the
draft tries to stop NAT-PT getting any further deployment because of this.
For better or for worse IPv4 NATs are here already and a.s. here to
stay. Trying to toss the specifications on the book bonfire is
pointless and counterproductive. Likewise trying to kill off the NAT
traversal industry would require a suitable Hydra-slaying superhero:
"Volunteers, two paces forward... wait for it!" Maybe IPv6 will do the
trick but even there we will require considerable vigilance.
However I have a good deal of sympathy for Christian's remarks below.
The NAT/traversal industry has many of the hallmarks of the 'new IETF'.
Maybe someone should pause and consider why the IETF publishes
specifications, or informational documents. Over the last 15 years, I
have seen a drift of attitude, basically from engineering to a policy
making.
In the old engineering attitude, working groups were created because
several like-minded engineers wanted to develop some function, or
protocol. It was important for them to get together, so they could
voluntarily agree on the details. If they did not, each would develop
their own version, and there will be no interoperability. The result was
documented in a set of RFC, so that whoever wanted to develop a
compatible product could. IANA registries are used to ensure that when
options arise, the options are numbered in an orderly manner.
In the policy making attitude, working groups are created to control
evolution of a particular function. The working group members are
concerned that someone else might be implementing something harmful to
the Internet. Their goal is not so much to develop products as to ensure
that non-conforming products do not get developed. IANA registries are
used to control extensibility of the resulting protocols, to make sure
that "bad" options never get a number.
In short, the IETF evolved from an informal gathering where engineers
will agree on how to do things, to a reactive body that mostly aims at
controlling evolution of the Internet. Is that really what we want?
-- Christian Huitema
I hope not, but I fear you are correct. IMO Much of this stems from the
ossification and 'lowest common denominator' nature of the deployed
network, Arguably, the network/protocol suite is senile and truly
novel, architecturally valid improvements are close to impossible
because the network cannot adapt to them. The IETF is trying to prevent
death rather than enhance life.
/Elwyn
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf