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

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Tue, 21 September 2004 04:31 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24176; Tue, 21 Sep 2004 00:31:10 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9cPQ-0002Be-Eu; Tue, 21 Sep 2004 00:37:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9cG0-0006sl-9l; Tue, 21 Sep 2004 00:28:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9cDr-0006O7-C2; Tue, 21 Sep 2004 00:25:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24008; Tue, 21 Sep 2004 00:25:44 -0400 (EDT)
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9cK9-00026R-NN; Tue, 21 Sep 2004 00:32:18 -0400
Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i8L4PSpl009510; Tue, 21 Sep 2004 00:25:28 -0400 (EDT)
Message-ID: <414FAD21.80709@dynamicsoft.com>
Date: Tue, 21 Sep 2004 00:25:05 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
References: <0330B107-0B5A-11D9-99F9-000A95E35274@cisco.com> <10872.1095728584@marajade.sandelman.ottawa.on.ca>
In-Reply-To: <10872.1095728584@marajade.sandelman.ottawa.on.ca>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: Melinda Shore <mshore@cisco.com>, Bob Hinden <bob.hinden@nokia.com>, ietf@ietf.org, iesg@ietf.org
Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit

inline.

Michael Richardson wrote:


> I agree with Melinda.
> 
> I would very much like to be able to let the desk clerk at the hotel
> know that I won't be paying for their "Internet" service, because it
> wasn't RFCxxxx compliant. (I now wish that someone did get the trademark
> on that word, and would deny it to locations that offer only NATwork service)

Well, I suspect the hotel clerk won't understand and certainly won't 
care what an RFC is. But, their service provider does, and I'm more 
hopeful that the RFP's and RFI's they produce and send to their vendors 
includes a statement that their NATs need to be RFCxxxx compliant, 
because it increases the ability of their networks to support 
applications that are ultimately driving demand for those networks.

> 
> That's the only value I see in this situation.
> For the the vendors that have a clue, and will likely be involved in
> this process, they are likely already compliant. For those that aren't
> compliant, they won't be there. That's tough for them.

Actually, it's surprisingly more complicated than one might think to 
determine what the "right" thing is, in terms of NAT behavior and 
treatment of basic protocols such as UDP. Even clueful vendors appear to 
  have differing treatments even within the same product families [1]. 
For some of these behaviors, such as the UDP binding timeout interval, 
there is value in trying to shepherd everyone to arrive at a common 
minimal value (as in, the binding timeout MUST be greater than X). For 
that example, it's not an issue of clueful or clueless implementations, 
but rather, getting folks at a consistent value. That is exactly what 
standards are for.


Thanks,
Jonathan R.


[1] 
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-01.txt 


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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