Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)

Harald Tveit Alvestrand <> Mon, 20 September 2004 13:01 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA29380; Mon, 20 Sep 2004 09:01:37 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9Nte-0005Q4-Ij; Mon, 20 Sep 2004 09:08:01 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C9NkM-0000gQ-GU; Mon, 20 Sep 2004 08:58:22 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C9NYb-0007ZT-DY; Mon, 20 Sep 2004 08:46:13 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA27286; Mon, 20 Sep 2004 08:46:11 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9Nei-000581-72; Mon, 20 Sep 2004 08:52:35 -0400
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 5755061BA7; Mon, 20 Sep 2004 14:45:38 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 29636-06; Mon, 20 Sep 2004 14:45:36 +0200 (CEST)
Received: from (localhost.localdomain []) by (Postfix) with ESMTP id 5FCDA61AD4; Mon, 20 Sep 2004 14:45:35 +0200 (CEST)
Date: Mon, 20 Sep 2004 14:28:44 +0200
From: Harald Tveit Alvestrand <>
To: Brian E Carpenter <>, Pekka Savola <>
Message-ID: <239B699D32BD4A0F33F883AB@B50854F0A9192E8EC6CDA126>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/3.1.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit

--On 20. september 2004 14:03 +0200 Brian E Carpenter <> 

> I think the real point is that it's quite unrealistic at this
> stage in the history of NAT to imagine that we can make the mess
> (which was inevitable anyway) any better by codifying the
> least-bad form of NAT behaviour. The NAT codes are shipped, burnt
> into lots of devices, and the IETF can't do much about it.
> So I think this would be wasted effort.

My take (which is obviously biased) is that the number of NAT devices 2 
years from now is likely to be significantly larger than the number of NAT 
devices currently deployed.

And - here I am making a real leap of faith - if the IETF recommendations 
for NAT devices make manufacturers who listen to them create NAT devices 
that make their customers more happy, then many of these new NAT devices 
may  be conformant to IETF recommendations.

If we're really, really lucky - and reasonably fast - we could make the 
experience of people using the Internet better - "make the Internet work 
better" for those users.
And that's what the IETF is supposed to do, isn't it?

(Note - I sympathize with Pekka's touching faith in Teredo as the Big 
Solution.... I hope he's right. So the NAT recommendations may in that case 
boil down to a single sentence:

"Don't break Teredo"

If that's the case.... it's worth saying.)


Ietf mailing list