Re: draft-ietf-v6ops-natpt-to-historic-00.txt

Tony Li <tli@cisco.com> Thu, 05 July 2007 13:43 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Rcd-0000Xq-GS; Thu, 05 Jul 2007 09:43:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RU3-0003Lk-Kq for ietf@ietf.org; Mon, 02 Jul 2007 15:22:51 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RT1-0005Mk-2D for ietf@ietf.org; Mon, 02 Jul 2007 15:22:51 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2007 12:21:27 -0700
X-IronPort-AV: i="4.16,488,1175497200"; d="scan'208"; a="175678843:sNHT47263095"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l62JLRtO013567; Mon, 2 Jul 2007 12:21:27 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l62JLQmu027493; Mon, 2 Jul 2007 19:21:27 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 12:21:25 -0700
Received: from [192.168.0.101] ([10.21.115.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 12:21:25 -0700
In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06405073E98@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
References: <20070702130748.5E78986AEA@mercury.lcs.mit.edu> <70C6EFCDFC8AAD418EF7063CD132D06405073E98@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <05696DBA-550E-473B-8431-E81270D280D2@cisco.com>
Content-Transfer-Encoding: 7bit
From: Tony Li <tli@cisco.com>
Date: Mon, 02 Jul 2007 12:21:23 -0700
To: Christian Huitema <huitema@windows.microsoft.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 02 Jul 2007 19:21:25.0074 (UTC) FILETIME=[2E68F320:01C7BCDE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1940; t=1183404087; x=1184268087; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20<tli@cisco.com> |Subject:=20Re=3A=20draft-ietf-v6ops-natpt-to-historic-00.txt |Sender:=20; bh=O2MmzB71kk0zPM8ABtAjSJcih3R7UBI8AU923bnwumk=; b=JSB+Aj09jFTqMWZaqRhLv4VMf2VbvA5gHVC0eUOvBSX3y3ujgRPbfA+g9BJwDeRdbW3nyW+P M5yLYHpo9gR5bzj6iscdYBQxYiBU0vXOkoqGBLdfqqBebrDcOdYyNa0p;
Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
X-Mailman-Approved-At: Thu, 05 Jul 2007 09:42:51 -0400
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, ietf@ietf.org
Subject: Re: draft-ietf-v6ops-natpt-to-historic-00.txt
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>
Errors-To: ietf-bounces@ietf.org

On Jul 2, 2007, at 9:43 AM, Christian Huitema wrote:

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


Hi Christian,

I'm not sure that we have much of a choice.  If there is no control  
over how the technology is used, then forces that see an advantage in  
doing something harmful to the Internet will come into play.  A fine  
example of this already exists with address space.  We understand  
that address space, while large, is finite, and we've created policy  
(delegated to the RIRs) to ensure that address space requests are  
duly justified.

We have created the ultimate Commons, and it is up to us to create  
the policy to prevent the associated tragedy.

Regards,
Tony

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