[Int-area] Bringing routing and addressing solutions to the IETF
The IESG <iesg@ietf.org> Thu, 17 May 2007 22:33 UTC
Return-path: <int-area-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HooXl-0003NZ-4w; Thu, 17 May 2007 18:33:57 -0400
Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1Hoj9j-0004qE-Ue for int-area-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 12:48:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj9j-0004q1-Kh for int-area@ietf.org; Thu, 17 May 2007 12:48:47 -0400
Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoj9j-0001Fz-D2 for int-area@ietf.org; Thu, 17 May 2007 12:48:47 -0400
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 5BB6B3293C; Thu, 17 May 2007 16:48:47 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43) id 1Hoj9j-0008Io-9I; Thu, 17 May 2007 12:48:47 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: RAM <ram@iab.org>, Internet Area <int-area@ietf.org>, RRG <rrg@psg.com>
From: The IESG <iesg@ietf.org>
Message-Id: <E1Hoj9j-0008Io-9I@ietf.org>
Date: Thu, 17 May 2007 12:48:47 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
X-Mailman-Approved-At: Thu, 17 May 2007 18:33:56 -0400
Cc:
Subject: [Int-area] Bringing routing and addressing solutions to the IETF
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org
Two weeks ago the Internet Area Directors sent a note on where to work on identifier-locator separation designs for routing scalability purposes (http://www1.ietf.org/mail-archive/web/ram/current/msg01322.html). As promised in that note, we are sending this note to follow-up. The IESG is inviting proposals as soon as designs are ready to start the IETF consensus process. As you know, work enters the IETF when there is a sufficient constituency and when the problem is sufficiently well defined for tractable engineering. Today, a number of groups are exploring potential solutions the routing and addressing problem. The IESG encourages anyone with ideas or time to dedicate to this effort to join any one of these groups. The Routing and Addressing Directorate will be reporting on the activities in the various venues around the greater IETF community. Among other tasks, this directorate is charged with helping to make sure various efforts are aware of each others' progress. Please make sure the directorate is informed of any efforts in which you participate. One or more of these efforts will eventually propose a new routing and addressing architecture for the Internet. The IETF consensus process will be used to determine if that proposal is acceptable to the whole community as a starting point for the solution. Developing a proposal that will achieve consensus when it reaches the IETF is a very challenging goal. When the proposal does reach the IETF it is almost certain that the set of people interested in the work will increase, or at the very least differ. People not involved in the development of the proposal will be unfamiliar with decisions that were made in the creation of the proposal, so it will be very important for a successful proposal to provide rationale, probably including reasons for discarding alternatives that were considered. It is important to consider the balance between time spent refining a proposal before bringing it to the IETF against time spent building support and within the IETF. Revisiting key decisions will be a critical part of building consensus; attempting to avoid it will drive people away and may result in failure of an effort to reach consensus at all. Very broad consensus is needed to achieve widespread deployment. The IESG hopes that one or more proposals will soon be ready for IETF consideration. As appropriate, Area Directors will hold BOFs, consider revising charters of existing Working Groups, consider establishing new Working Groups, and consider sponsoring individual submissions. The IESG will consider whether the work is actually ready for engineering, how it fits in with other proposals and existing work, and so on. The IESG _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area