Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches

From: [email-masked] (Noel Chiappa)
Date: Mon, 20 Feb 2006 19:22:42 -0500 (EST)

> From: Tony Li <[email-masked]>

    > To truly move forward, we first need to have consensus on the following:
    >   - We have a problem.
    >   - The current crop of solutions are unsatisfactory.
    >   - We are willing to make changes.
    > Until then, we have the status quo.

I've been pondering your message for a while now, trying to put together a
considered reponse. (I had some responses to individual points, but I'll send
them off separately.)

I guess my bottom line is that your goal is admirable, but also utterly
infeasible. The Internet community in general, and the IETF in particular,
(both groups which necessarily operate on rough consensus) are groups which
are simply utterly incapable of agreeing on a radical long-term vision -
which is what any substantial (i.e. worthwhile) change to the architecture
amounts to.

The reason is simple: the more radical the proposed change, the less likely
you are to get agreement on it, because: i) very few people have the depth of
understanding to truly appreciate the long-term benefits of such changes; ii)
now that the Internet is a very large going operation, people are unwilling
to take what they perceive as risky moves, such as a major change.

In short, the only thing people can agree to is the most modest of steps -
and by definition, one cannot do interesting architectural innovation in
miniscule steps.

A classic example of this is afforded by our own history, to wit, the IPv6
selection decision. IPv6 was proudly proclaimed by its 'architect' to be (and
I don't have time to search for his exact words, but this is the sense of
them) "the IPv4 architecture, which is just fine, re-engineered to be better
done". (I use the scare quotes around 'architect' advisedly, since the person
is question is really more of a principal engineer, as his own words
indicate.)

In other words, given the perfect opportunity to choose an improved path
architecturally, the IETF community decided on... the lowest common
denominator - and the status quo, to boot!

One does not create great new architecture in this way.

I see several possibilities for producing interesting new architecture (for
part or more of the stack), but none of them involve the IETF.

One possibility is that a consortium of large ISP's will get together and
decide to replace the ramshackle Destination-Vector IPvN routing architecture
we current have with something a little less Mesolithic. They will operate it
among themselves, and eventually it will spread.

Another possibility is that some closed community (one person suggested the
US DoD) will decide that they need mission-specific capabilities that IPvN
cannot be tweaked to prode, and they will go off to do so - but it's rather
uncertain that this will spread (just as basically all commercial jets are
not supersonic).

However, the only possibility I see of the entire world progressing to
something more advanced is for some revolutionary new technology (I have no
idea what - maybe tachyon quantum pipes, or something) to come along and blow
the exiting IPv4 Internet out of the water, just as IPv4 blew the telephone
system out of the water.

That the world will struggle along endlessly with embarassingly bad
technology, no matter than superior alternatives have long existed, is made
plain by our experience with Windows.

As a professional computer scientist, I am driven to the most profound shame
and embarassment by Windows. There's a quotation which crystallized this
feeling for me:

  "I guess it would be personally offensive to me to have the public at
  large think that my profession is so inept and so unaware that we would
  [create a monstrous disaster waiting to happen] without knowing what will
  happen." -- 'Condominium', John D. McDonald

We've had computer science technology since circa 1970 that would have
prevented the vast majority of virus and worm problems, problems which have
caused billions of dollars of lost time and money, have made a large share of
the PC's in the world havens for thieves, con-artists and villains of all
sorts, from the merely revolting to the truly deeply dangerous, and are
finally slowly undermining people's very willingness to use the network.

Yet an archaic design, one which was obviously prone to these problems, was
quite wittingly propogated for a variety of excuses (of which the "it will be
too complicated to configure" was the most specious, since not even *I* can
figure out how to configure the latest Microsoft bloatware for my friends,
when it fails to work for them). But I digress....

The important point for us that despite the documented existence of superior
stuff, still this stuff has a stranglehold on the world's computer-using
population, with no signs that it will be uprooted and discarded lock, stock
and barrel any time soon.

So too it is, and will be, with the rather crappy network we're now stuck
with. Because, sad to say, bad as we know it is, it's still much better than
even worse examples from other spheres, e.g. Windows.

A bunch of local addressing domains glued together with NAT may be ugly as
sin, brittle as hell operationally, etc, etc, but that's the future of
networking, until some mammals come along and do in this brontosaurus of a
network.

When one of the top universities in the world is doing routing research on...
(wait for it...) how to build overlay networks on top of the existing
packet-level routing, you're know you're totally hosed.

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Tony Li <[email-masked]>
Date: Mon, 20 Feb 2006 17:20:29 -0800

Noel,

> which is what any substantial (i.e. worthwhile) change to the architecture

Call me naive, but I'm still hopeful that some incarnation of the IAB
can exert enough leadership to drive this process.  I agree with you
completely, that without some form of leadership, getting wide consensus
is exceedingly unlikely and would require some crash-and-burn type of
catastrophe before the pain level would be high enough to motivate change.

However, in my Cleaver-based universe, it would still be possible for
the IAB to recognize the problems ahead, convene something like ROAD
again, and drive towards a better solution.

I suspect that you, and most others will probably view this as
absolutely Quixotic.  I accept that.  Until a better alternative process
becomes apparent, I'm far too stubborn to stop tilting at the windmills
in front of me.  From my perspective, the Internet is in serious
architectural trouble and it is our responsibility to do whatever we can
to articulate and address the issues.  Furthermore, to capitulate to the
status quo and support the plan du jour would simply be the height of
professional negligence and irresponsibility.

Thus, I am compelled remain the loyal opposition,
Tony

---

From: Venkata Pingali <[email-masked]>
Date: Mon, 20 Feb 2006 17:36:46 -0800

> catastrophe before the pain level would be high enough to motivate change.

There is atleast one ongoing large NSF-driven effort:
GENI (http://www.geni.net and http://www.nsf.gov/cise/geni/)
and FIND (http://find.isi.edu).  They both are in early
stages but they come close to the organization/consortium
driven model of change.

-Venkata

---

From: John Leslie <[email-masked]>
Date: Mon, 20 Feb 2006 22:37:24 -0500

>> From: Tony Li <[email-masked]>
)) Architectural proposals have been lofted.  They were specific, had clear
)) migration plans, and the discussion was shut down with the usual "v6 has
)) already shipped" dogma.  Specific topics were:
)) 
)) - GSE (more generally locator/identifier splits)
)) - locator agile transport protocols
)) 
)) Without these types of capabilities, the architecture is stuck
)) supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT
)) in the host), and various forms of tunneling.
)) 
> infeasible.

   I don't think Tony was expecting the entire IETF to reach consensus.

> The reason is simple: the more radical the proposed change, the less
> likely you are to get agreement on it, because:
>  i) very few people have the depth of understanding to truly appreciate
>     the long-term benefits of such changes;
> ii) now that the Internet is a very large going operation, people are
>     unwilling to take what they perceive as risky moves, such as a
>     major change.

   Um...

   We have quite a few people capable of the needed depth of understanding;
but they're rather busy, and very apt to lose focus.

   People aren't really all that risk-averse, but they recognize that
lumping too many changes together tends to exponentially increase the
inertia to stay with the known.

> minuscule steps.

   I almost agree. Modest steps are far more likely to see widespread
adoption.

   Interesting architectural innovation is more about looking at things
differently than about the size of each step taken.

   For example, there's nothing particularly wrong with IPv4 as a
transport mechanism for static endpoints over a stable infrastructure.
Where we get into trouble is thinking that IPv4 addresses can be the
one-size that fits-all.

   With 20/20 hindsight, it's obvious that TCP always deserved a separate
endpoint address space than IP. Unfortunately, there's no "modest" step
we can take to change that. :^(

   But in a world filled with NAT devices (which everybody expects to
replace anyway within five years), we could start thinking in terms of
decoupling the actual end-device address space from the IPv[46] address
space the NAT uses to talk to the "backbone". Five years is "really fast"
for adopting significant changes in the world of Internet.

> A classic example of this is afforded by our own history, to wit, the
> IPv6 selection decision...

   IPv6 had a perfect opportunity to decouple device addresses from
transport addresses (and has even made some steps in that direction).
Unfortunately, nobody sees this possibility as an incentive to adopt
IPv6.

> denominator - and the status quo, to boot!

   Hardly surprising. Unless folks could see IPv6 as a "drop-in"
replacement, they'd never consider it at all.

> One does not create great new architecture in this way.

   To tell truth, I'm not terribly interested in creating "great new
architecture" unless folks will use it.

   I see several large-economy-size messes looming:

1) Mobility will need a concept of physical location and a metric for
   "closer".

2) Congestion management needs an actual measure of congestion.

3) A wide range of Identity assurance options need widespread deployment.
   (This does not mean all traffic needs Identity assurance!)

> I see several possibilities for producing interesting new architecture
> (for part or more of the stack), but none of them involve the IETF.
> 
> One possibility is that a consortium of large ISP's will get together
> and decide to replace the ramshackle Destination-Vector IPvN routing
> architecture we current have with something a little less Mesolithic.
> They will operate it among themselves, and eventually it will spread.

   This seems unlikely. Large ISPs are far more interested in stealing
each others' customers than in cooperating to improve the customer
experience.

> Another possibility is that some closed community (one person suggested
> the US DoD) will decide that they need mission-specific capabilities
> that IPvN cannot be tweaked to prode, and they will go off to do so -
> but it's rather uncertain that this will spread (just as basically all
> commercial jets are not supersonic).

   This will indeed happen. So far, it seems unlikely to spread much.

> something more advanced is for some revolutionary new technology (I
> have no idea what - maybe tachyon quantum pipes, or something) to
> come along and blow the exiting IPv4 Internet out of the water, just
> as IPv4 blew the telephone system out of the water.

   It is possible to imagine congestion-free infrastructure, which would
improve many things; but still leave us limited to the speed of light.
Alas, the economics don't seem to be rewarding congestion-free...

> technology, no matter than superior alternatives have long existed,
> is made plain by our experience with Windows.

   I won't descend into Windows-bashing. I do, however, think we're making
real progress towards free Operating Systems which could run on a sufficient
variety of hardware. Anyone want to bet what changes will follow the
dissemination of Negroponte's $100 laptops?

> So too it is, and will be, with the rather crappy network we're now
> stuck with...

   A lot of the crappiness comes from poor congestion management and
inappropriate aggregation. These could be fixed without discarding
IPv4.

   Crappiness also comes from the nearly total lack of assurance of
identity. This could be fixed at the TCP level, and implemented in
the free Operating Systems at least -- I believe browser companies
like Mozilla and Opera would be delighted to make use of it.

> A bunch of local addressing domains glued together with NAT may be
> ugly as sin, brittle as hell operationally, etc, etc, but that's the
> future of networking, until some mammals come along and do in this
> brontosaurus of a network.

   Please don't forget that the value of a network increases at least
in proportion to the square of the number of nodes. However painful
it may be to co-exist with Internet-as-we-know-it, it will be to our
benefit to do so.

--
John Leslie <[email-masked]>

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 21 Feb 2006 15:23:50 +0100

>it may be to co-exist with Internet-as-we-know-it, it will be to our

Dear John,
I read with interest your comment. However you consider the proper 
approach and how people can work on it, you come back to some 
specifics of the current ill shaped architecture. The explanation 
might be the paragraph I quote. I think this is a fondemental 
architectural error. As a network catalyst and analyst my formula is 
sigma(n.log(n)-µ.n^2) (franglish http://jefsey.com/netvalue.pdf). It 
induces a totally different and pragmatic vision of the digital 
ecosystem networking architectures and economical value. The 
architecture must permit to enlarge the sigma area and decrease the µ.
jfc

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Feb 2006 10:50:14 +0200

> As a network catalyst and analyst my formula is sigma(n.log(n)- 
> µ.n^2) (franglish http://jefsey.com/netvalue.pdf). It induces a  
> totally different and pragmatic vision of the digital ecosystem  
> networking architectures and economical value. The architecture  
> must permit to enlarge the sigma area and decrease the µ.

Nice observation.  Looking at the graph in 3D tells quite a lot.  A  
reasonable value for µ, given the size of the Internet, seems to be  
in the order of 10^-5 ... 10^-6 or so.

However, I think that formula misses the fact that the negative  
effects are usually caused by a small minority of network users, and  
I don't think their number grows linearly with the size of the  
network, at least no longer.  Hence, to me it feels like µ.n^2 is  
wrong, and should have much smaller exponent than 2, maybe almost as  
small as 1.  Or some other growth factor, maybe combinding linear  
growth and an S-curve.  Then the picture becomes totally different.

Anyway, I appreciate the basic idea of dividing the network value  
into a positive networking effect and a negative networking effect,  
depending in different ways on the size of the network.  That also  
manages to partially explain why closed networks (aka white listing)  
are so effective.

Now, if you managed to tie this into the natural human trust  
behaviour (cf. e.g. Axelrod or, in less quantitative terms, Robin  
Dunbar), that might be really something fundamental.

--Pekka

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Feb 2006 08:18:22 -0500

Tony,

> can exert enough leadership to drive this process.

Actually, I don't think the IAB is the right place for this to happen,
at least not to get it going.

The first step is to get a small design team together that can
articulate the problem, explain why the existing approaches (e.g.,
shim6) don't meet the requirements and articulate a rough outline of
an alternate approach that addresses the stated requirements. Once
there is some sort of consensus within the team, do expanding scope
consensus building in which more people are drawn in, their input
accepted, etc. Over time, if the process is working, you start
building critical mass support for an approach. One of the keys here
though is drawing in people from a broad cross-section of the
community (not just more of those that already "believe"), since the
others are the people that will bring alternate perspectives (e.g.,
from transport, applications, etc.) and will also be critical (in the
end) in terms of getting broader community concensus for an approach. 

The reason I am not advocating having the IAB drive this is that
ultimately, these efforts are most successful when driven by those who
see the need and have an interest. Sure, at some point the IAB should
get involved, but having it drive the effort initially is not
necessarily the best approach in practice (and smacks of a too-common
IETF problem of "we need to fix this, but somebody else is responsible
for doing the actual work").

> 	- We are willing to make changes.

The first place to start is with items 1 & 2 above. I believe folk are
willing to make changes (and I am certainly willing to consider them),
provided there is agreement on 1 & 2.

Oh, and there is one more item above that shouldn't be forgotten:

  - there is a critical mass of people willing to do the work of
    developing a solution

Thomas

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Feb 2006 16:02:07 +0200

Tony,

> at least not to get it going.

Seeing the situation from inside, I agree with Thomas.  I have been  
trying to get _something_ like this going for some time now in the  
IAB, and while many people are _very_ positive, I don't see any  
practical way of getting the IAB to lead this.   At least not the  
present one; the situation may well change as people get circulated.   
On the other hand, the IAB might well oversee or "sponsor" such  
activity, but that would be an IAB decision, not mine.  And there are  
certainly people in the IAB who might be willing to participate,  
either in the beginning or at some later phase.

> an alternate approach that addresses the stated requirements.

This is almost exactly the same advice that I have heard.  However,  
my problem here is that I have no idea who would be the right people  
to start with.  I am just too loosely connected to the people in the  
IETF.  Due to human group dynamics, the initial team should have no  
more than at most 7 members.  A larger group works differently, and  
no so efficiently, especially in the beginning.

I might otherwise be willing to lead such a team, but people have  
told me so many times that my ability to actually lead groups is  
dismal.  Apparently, I have even difficulties to work in groups that  
are based on strong consensus. Hence, I would sincerely favour  
someone else taking the lead.

--Pekka Nikander

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Feb 2006 16:05:52 +0100

I read somewhere an excellent paragraph from David Clark, explaining 
exactly that. Architecture innovation can only result from a team 
with a leader and a few partners. I would like to find this paragraph 
back I just perused. I felt the experience in it was very important. 
This is this kind of contributions which are fundamental to a debate 
like this one.

I am not sure the IAB is good for that. I am certain the IETF is not. 
But this is not a reason why they could not help and foster the 
debate. And they should become very useful later on to permit 
interoperability (even if sometimes it is worse to obtain 
interoperability than to develop a new concept :-))
jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Feb 2006 15:59:36 +0100

Nice observations too. You are correct. My approach is purely 
mechanic. It results from the observation that the historic evolution 
of societal networking is related to human density. The target was to 
understand the rules of the digital ecosystem (hardware/software, 
communication and information). If you add the usage of the digital 
ecosystem (what I said I am interested in on this list), i.e. the 
services to the users (the brainware), you are right. But I am not a 
mathematician enough to get into this.

What I know is that we then switch from externets (external networks 
look alike, defined by their external features) to what I name SETS 
(spaces of exchanges, trust and services) defined by their internal 
features (referents) and extended by the users trust I quantify 
through the share of their personal context (their personalisation of 
the common referent). This is what I am interested in when I battle 
against RFC 3066 Bis, by nature the first feature of a human 
relational space is the language and its common attributes. 
Constraing their support (and what they do for languages will 
affect/lead what they do with all the other externets and SETS 
characteristics) will block the development of the whole architecture.

>in the order of 10^-5 ... 10^-6 or so.

What is interesting is to see how the global value may increase 
through externet/sets number and become less dependant from µ. Giving 
operators and innovation more flexibility, keeping obsoleting 
architectures of interest and permitting harmonious introduction of 
new technologies. An error for example is to consider that a new 
technology MUST support all the services.

>growth and an S-curve.  Then the picture becomes totally different.

Accepted. But may be it is more than 2. 2 is normal mechanical 
polylogue impact (without considering attenuation). What when you 
have a Google black hole (retaining people on its site), ad-spam (the 
banners are real spam).

>Dunbar), that might be really something fundamental.

I am just a network users consultant trying to get the best from what 
I find. If you have knowledge in that areas, may be could you point a 
good URL to get to know them?
Thank you.
jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Feb 2006 16:05:52 +0100

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Feb 2006 15:59:36 +0100

---

From: Vince Fuller <[email-masked]>
Date: Wed, 22 Feb 2006 12:15:35 -0800

> Thus, I am compelled remain the loyal opposition,

I'd be happy if the IAB/IESG would just not actively oppose or discourage
work along these lines. And I'd be ecstatic if they'd lend some degree of
sponsorship, perhaps in the context of a workshop or an experiment. No
time-consuming, proactive leadership is really needed, just acknowledgement
and a little bit of cooperation; I'm guessing that we, the curmudgeons of
the community, could rustle up support for such work from at least equipment
vendors and service providers if there were some assurance that it wouldn't
all be wasted motion.

>        - We are willing to make changes.

There has certainly been vociferous support for statements #1 and #2 among
the operational community, with the implication that #3 is unavoidable if we
really want a scalable solution. Sadly, some with egos heavily invested in
the "current crop of solutions" don't want to hear of it. #3 tends to be met
with outright hostility, particularly when the discussion strays toward the
heresy of changing enshrined packet formats or protocol semantics...

	--Sancho
	(but I think I'm a bit taller and don't speak much Spanish... ;-)

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Feb 2006 23:25:47 +0100

Dear Vince,
very refreshing. 100% with you on this. Just a question: why would 
this mailing list not be the IETF/IAB sponsoring you wait for? In my 
area (user layers convergence) I do not need any ego's OK (I just 
need to prevent them to harm me, what is not that easy) but I 
certainly need to exchanges, ideas, suggestions, etc. I miss that 
because as you say, there is no "WG-Curmud".

What prevent us to use the hosting of this mailing list to organise it?
Look at the current exchanges, it looks like most are gone, but your 
"curmudgeons" (Il like the term :-))
Is that not what in a way Leslie expected?
jfc

---

From: Tony Li <[email-masked]>
Date: Wed, 22 Feb 2006 17:17:53 -0800

Thomas,

> at least not to get it going.

Just to be crystal clear: I am *not* suggesting that the IAB actually be
the work force for this.  I *am* asking that the IAB clearly articulate
its openness to accept and standardize architectural changes to v6 at
this point.

> The first step is to get a small design team together ...

Before that can happen, the design team members need to know that their
work can possibly succeed.  Right now, no one is willing to invest in
this because the outcome seems preordained.  Only the IAB is really in a
position to reverse this.

Tony

---

From: John Leslie <[email-masked]>
Date: Wed, 22 Feb 2006 21:55:47 -0500

> its openness to accept and standardize architectural changes to v6 at

   This is a bit much to ask.

   I think it entirely reasonable to ask IAB to endorse a statement of
the problem (which BTW we don't have yet, IMHO).

   It is not reasonable to ask IAB to diddle with the specifications
of IPv6.

   In fact, I'd say it's premature to assume that a solution _can_ be
found within the framework of IPv6.

>> The first step is to get a small design team together ...

   I don't agree. I think we need a statement of the problem first.

   Given a statement of the problem, next should come a statement of
design goals. (IMHO.)

   Then it would be appropriate to have one or more design teams.

> work can possibly succeed. 

   I don't think we can guarantee much there...

> Right now, no one is willing to invest in this because the outcome
> seems preordained. 

   With respect to IPv6, that may be true.

> Only the IAB is really in a position to reverse this.

   I can't speak for them, but were I an IAB member I wouldn't feel
as if the IAB was "in a position to reverse" much of anything about
IPv6. They can raise architectural questions; to a very limited degree
they can hear appeals and send issues back to IESG for reconsideration.
They _cannot_ take any management role with an existing IETF WG.

   If we come up with a good architectural solution, the existing
IPv6 WG might choose to incorporate it. Or they might not. IMHO, IPv6
is seeing a slow enough rate of adoption that it's quite possible that
a brand-new IPv7 could overtake it.

   ;^)

---

From: Tim Shepard <[email-masked]>
Date: Mon, 27 Feb 2006 17:00:15 -0500

(I'm behind on e-mail reading, and I'm responding to a message from 5
days ago.)

> its openness to accept and standardize architectural changes to v6 at

I think that is asking for *way* too much.  Whether or not any
architectural changes are going to be accepted and standardized
depends on what those changes are and what the consequences would be.
If/when any such changes are proposed, the community will evaluate
them and decide.  The IAB is merely part of that community.

The problem is that figuring out what is going to be the right thing
to do is (at this point, at least) a matter of research.  And opinions
will vary.

There's nothing stopping anyone from investigating new architectures,
writing protocol specifications, writing papers discussing the ideas,
building prototype implementations, and teaching others about their work.

The IAB holds no veto over what research can happen in network
architecture, design, and implementation.

And if the IAB or IESG were to make any statement that some particular
proposal will not proceed within the IETF process, that is not an
irreversible decision.

For example, the folk working on HIP were told at the London IETF
that HIP could not proceed within the IETF as its advocates wished.
They kept on working on it anyway (and IMHO have made a valuable
contribution to the field of network architecture).

I wish HIP were not the only such example in the last 5 years.  It
would be nice if there were a number of architected, designed,
implemented, and (experementally) deployed worked examples
demonstrating alternative ways of doing things.  Running code that
can be read alongside protocol specifications and architecture
documents is very valuable.

> position to reverse this.

I disagree.  Anybody can reverse this if they are willing to invest
effort into seeing an idea along.

HIP got to where it is today through slow recruitment (over 7 years)
into an expanding community of fans through hallway conversations at
IETF meetings and other venues.  The IAB has, AFAIK, no power to
regulate what people talk about in the hallways of IETF meetings,
nor in the larger networking research community.

If you want to move an idea within the IETF community, I suggest (1)
write it down as clearly as you can (anyone can publish an internet
draft on anything), and (2) recruit fans of the idea, and (3) to
your hallway conversations at IETF meetings (and to the larger
networking research community), bring open-source prototype
implementations that you can demo and let other people read and test
drive.

The IAB and IESG are in charge of the IETF process.  They do not
control the fate of ideas.  The community does.

I hope this is helpful.

			-Tim Shepard
			 [email-masked]

---

From: Tony Li <[email-masked]>
Date: Mon, 27 Feb 2006 15:53:58 -0800

> them and decide.  The IAB is merely part of that community.

Clearly, I'm failing badly at being crystal clear.  ;-)

I certainly have no expectation that any future technology would
circumvent the usual development of rough consensus.  Again, what I
asked for is 'openness' -- the opportunity to be heard, to do the work
and have it considered without bias and prejudice.  As Ran has already
detailed, previous efforts have run aground on the reef of partisan
animosity before and foundered long before they were allowed to even
germinate, much less blossom.

Without some indication that the process is now open to renewed efforts,
the assumption by many in the community seems to be that similar efforts
will meet with a similar fate.  To remedy this, the IAB could issue a
relatively simple document that clearly articulates

	- that there are continued concerns about the v6 architecture
	  in the areas of mobility, multihoming, renumbering and routing
	- that the IAB would like to see further investigation into the 		
issues and possible architectural improvements
	- that any such improvements that met with rough consensus could
	  be incorporated into v6 and be fully endorsed
	  by the IAB as first-class components of the architecture

Tony

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Feb 2006 06:54:27 +0100

Tony,

speaking not on behalf of the the IAB, but as an IAB-member, I don't see
why we can't start discussing changes to the IPv6 architecture. As I see
it I think that the IAB is very open to that type of discussion. It
might be that the IAB has not shown the type of leadership needed here
but there is no reason that it can't happen. Especially considering that
you and others have pretty clearly pointed out some of the architectural
problems.

In fact IAB has pointed at three major areas where we need focus, IPv6,
Internet architecture and "bad traffic". What you are proposing aligns
very well at least with the first two. I agree that IAB needs to
articulate its position on this.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]