-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> Yes, a path. Not necessarily a single proposal, but a clear plan. From the > charter: > > The group will produce ... a recommendation for a routing and addressing > architecture. > > It doesn't say "a set of possible architectures" or "some vague things that > we could do". > > Again, our job is to make a decision and that's what we're going to do. One thing that might be _nice_ is to have some idea of what the future of routing, in general, looks like under each proposal. In other words, does the proposal allow future changes in the routing system through incremental deployment of new ideas and techniques, or does it place us in the position of forcing "flag days?" As architectures become more complex on the machine side, they also tend to become more brittle in general. A second thing might be to address mobility. How does each proposal deal with host level mobility, since this is obviously a direction in the Internet at large (whether we like it or not, mobile phones and other such devices are going to rely increasingly on the Internet, which may--or may not--place a larger burden on the routing system). A third thing might be to address whether or not any of the solutions proposed actually resolves the problem seen in the field--IE, describing what the problem is and why it exists (I've mostly seen hand waving to this point about the size of the global table, and projections against the future size of that table, but nothing that says why the table is growing at this rate, other than the blanket statement of "dual homing," which doesn't really answer the question at all), and how each solution specifically resolves the problem. Since I don't tend to think the problem is "dual homing," since that problem is "solvable" in other ways that don't require a redesign of the entire Internet routing architecture. Don't know how far we'll go on these sorts of things, but it would certainly help increase the ability of folks to assess the work if we could consider them in some way. Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuUWZcACgkQER27sUhU9OTtCACfd9VDYUH+cDXYxEKNKD7JnY+T sfQAoMWBFQq5sAAL91yAzQFjrY5MicvT =w3Yl -----END PGP SIGNATURE----- _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
