the problem with a "NAT working group" is that it attracts NAT
developers far more than it does the people whose interests
are harmed by NATs - which is to say, Internet users in general.
so by its very nature a "focused" NAT working group will produce
misleading results.
This bias holds for any working group, be it IPSEC, header
compression, or anything else. Why pick on NAT?
good question.
Most IETF working groups are working on things that are
more-or-less harmless, in that their effects are likely
to be isolated to those who choose to use them. Their greatest
potential for harm is that they will displace something better
that might crop up in the same space. The fact that such a WG
is biased toward its own problem space isn't of much consequence
because their solution isn't likely to affect people trying to
solve different problems.
NATs (and interception proxies) have much higher risk - they attempt
to address certain real problems but they do so at the expense of
flexibility, generality, predictability, and reliability of the
network. They also violate long-established conventions about
the separation of functions between network layers, and in doing so,
break higher level applications that (quite reasonably) assume
that the lower layers of the network are working within their
design constraints.
Within the current IP architecture, the notion of a "technically
sound NAT" is an oxymoron - NATs inhernetly violate fundamental
design constraints of the architecture. The technically sound
way to solve the problems that NATs attempt to address is not to
alter the behavior of NATs but to provide alternatives outside
of the NAT space. But a group that's NAT-centric is inherently
focused inside that space, and thus has a very limited ability to
promote technical soundness.
(and there are those who think that the Internet architecture
should be changed to incorporate NATs and that all of those applications
which don't work in the presence of NATs should be deemed obsolete.
but the effect of such a change is so widespread that it is far beyond the
ability of the NAT working group - or any single working group - to evaluate)
Keith