[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