Re: [midcom] More on new work item

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Mon, 26 April 2004 21:45 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26064 for <midcom-archive@odin.ietf.org>; Mon, 26 Apr 2004 17:45:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDg6-0002gf-PN for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:30:14 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLUEvA010324 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:30:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYV-0000lr-Sj; Mon, 26 Apr 2004 17:22:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDG7-0003cU-Px for midcom@optimus.ietf.org; Mon, 26 Apr 2004 17:03:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21965 for <midcom@ietf.org>; Mon, 26 Apr 2004 17:03:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDG5-000314-LY for midcom@ietf.org; Mon, 26 Apr 2004 17:03:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID9s-0001uX-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:56:58 -0400
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BID11-0000EU-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:47:47 -0400
Received: from dynamicsoft.com ([63.113.46.158]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3QKlQus018816; Mon, 26 Apr 2004 16:47:26 -0400 (EDT)
Message-ID: <408D754C.5080708@dynamicsoft.com>
Date: Mon, 26 Apr 2004 16:47:08 -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: Melinda Shore <mshore@cisco.com>
CC: midcom@ietf.org
Subject: Re: [midcom] More on new work item
References: <5A236B7C-9779-11D8-9F75-000A95E35274@cisco.com>
In-Reply-To: <5A236B7C-9779-11D8-9F75-000A95E35274@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I'm not sure we should take on these work items. My concerns are mostly 
practical.

I think we agree that DHCP applicability is only in very, very limited 
topologies - only in simple stub networks where an end user client would 
normally directly talk to a nat. This would really be limited to 
consumers with home nats, or to enterprises. I think its unlikely that 
an enterprise would actually allow end clients to control the nat, due 
to the serious potential for abuse (imagine a virus infecting a PC, 
causing it to ask the middlebox to open all ports to all addresses). As 
such, I dont think this is workable in enterprise.

That leaves home NAT. However, do we think that manufacturers of such 
devices are likely to support midcom? I'd like to hear from one on this 
list. If not, this work item would be useful only in theory. Even if 
they did, how would we expect the clients to be configured with the 
security credentials needed to exercise midcom control over their nat? 
If such information is manually configured into the client, why can't 
you manually configure the IP of the home NAT as well?

Thanks,
Jonathan R.

Melinda Shore wrote:

> There's been no feedback on the proposed charter change, which concerns
> me.  I hope that people will speak up regardless of whether they think
> the proposed work item is a good idea or a bad idea.
> 
> I don't think getting the work done would be an issue - there are
> always people willing to author documents.  However, getting people
> to *review* documents is far more difficult, and I don't think we can
> allow work to go forward if we don't have a reasonable expectation
> that people with subject area expertise - in this case, the midcom
> working group - are willing to take the time to provide expert review
> as the document is progressed.  I don't want to make any assumptions
> about what the lack of feedback means, so even a simple "yes" or "no"
> on the proposed work item would be much appreciated.
> 
> Thanks,
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
> 

-- 
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

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