RE: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing &Addressing workshop

["Bound, Jim" <Jim.Bound@hp.com>]

I think Noel makes good sense here but suggest one caveat.

When and if identifiers and naming appears as imperative to any
architecture we have to take time to delve into them not just put them
on hold and that will take us away from just routing a bit but only for
routing not transport and I fear if we don't do that we may not see bug
in the routing architecture of future analysis and development in RAM.

/jim 

> -----Original Message-----
> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] 
> Sent: Thursday, December 07, 2006 3:10 PM
> To: architecture-discuss@ietf.org; ram@iab.org; 
> routingworkshop@lists.i1b.org; v6ops@ops.ietf.org
> Cc: iab@ietf.org; iesg@ietf.org; jnc@mercury.lcs.mit.edu
> Subject: [RAM] Re: [arch-d] mailing lists and follow-ons to 
> the IAB Routing &Addressing workshop
> 
>     > From: David Meyer <dmm@1-4-5.net>
> 
>     > discussion of what the follow-on's to the workshop 
> might be on various
>     > lists. What I'm hoping we can do is consolidate that 
> discussion on
>     > ram@iab.org.
> 
> I would take a slightly different view, and think there is 
> (non-overlapping) role for both (and I hope the various I* 
> bodies won't take offense at me for differing a bit with this 
> plan; I really do have everyone's best interests at heart here.)
> 
> 
> First, this is a big problem, and there are a number of 
> different technical areas; with a single forum, it might get 
> kind of Babel-like. Second, and more important I think, I 
> find that in any wide-ranging discussion like this, the 
> routing stuff (which is usually the hardest problem) gets the 
> short end of the stick. (I have my opinions on why that 
> happens, but I'll leave them be for now.) And, I hope I don't 
> need to point out, it was coming problems with the routing 
> which have led to this.
> 
> IMNSHO, it's really unacceptable to work on this problem and 
> not give a key role to consideration of how the routing is 
> going to work. And to make sure the routing is going to work, 
> we have to dive into the muck and tackle the routing 
> technical issues in some detail, to make sure it all really 
> works. So we have to drive pretty quickly to considering the 
> technical details of how the routing is going to work, I 
> think. And that's something the people who seem to have 
> energy available to discuss things have been fairly loathe to 
> do, despite some not-so-subtle prods from me.
> 
> 
> So I think keeping the RAM list focused on just the routing 
> stuff is really pretty critical; it's clear that that's a 
> really substantial discussion.
> Discussion of other related topics there (e.g. separation of 
> location and
> identity) would just distract from that, and that's where A-D 
> list would be useful.
> 
> I feel that discussion of such issues as end-end naming, 
> whether we have to use the "jack-up" model (in which 
> end-hosts remain totally unmodified), etc, etc, really ought 
> to be kept on A-D, to keep RAM clear for these routing issues.
> 
> To keep this from getting too long, I'll send out a separate 
> message in a couple of hours (just on RAM) giving a little 
> more detail on the points I think RAM needs to work on, and 
> how I think it can best make progress on them.
> 
> 	Noel
> 
> _______________________________________________
> RAM mailing list
> RAM@iab.org
> https://www1.ietf.org/mailman/listinfo/ram
>