Subject: [RRG] Forwarded message from the IESG...

From: Tony Li <[email-masked]>
Date: Thu, 17 May 2007 10:24:31 -0700

Note that this bounced because the 'from' address isn't subscribed to  
the list.

T

Begin forwarded message:

>
> To: RAM <[email-masked]>, Internet Area <[email-masked]>,
> 	RRG <[email-masked]>
> From: The IESG <[email-masked]>
> Subject: Bringing routing and addressing solutions to the IETF
> Date: Thu, 17 May 2007 12:48:47 -0400
>
> 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