Re: [RAM] Re: Renumbering impossibility: TSL/SSL certs, DNS delegation etc.

[JFC Morfin <jefsey at jefsey.com>]

At 16:36 08/08/2007, Thomas Narten wrote:
> JFC Morfin <jefsey at jefsey.com> writes:
>
> > 2) Thomas, I think there is something missing in your summary: a
> > calendar. Time to get a solution, and how long it is expected to
> > stay. This will say if what is looked for at this stage has to be a
> > patch or can be an architecture. We need to see that clarified first.
>
> I'm not sure it makes sense to ask whether a "patch" or an
> "architecture change" is the way to go.

Dear Thomas,
You talk of change. I do not. As you know I think the Internet can 
sustain the difficulty with the existing machines and architecture, 
but not in the way it is understood (paradigme) today by most of IETF 
participants, with their resulting solutions. Ex. the early XXth 
century did not build big high-ways to support huge cavalcades to 
transport an increasing number of people, they accomodated cars.

This is why things must be organised. Not only between the IETF 
refinement you propose to avoid IPvnat solutions. Also, a paradigme 
change must be studied in parallel for a part of the time we have. If 
there is no time table for that, you know this will not happen (this 
would have happened already). This study must be conceived as a 
possible solution path but also as a way to further the other 
solutions through a better knowledge of the real needs evolution, of 
the hidden capacities of the existing solutions.  At the end of the 
period there will be a decision: to drop the issue and to focus on 
the then consensual possibility or to pursue in the best way which 
will have been discovered.

Otherwise, the new paradigme (distributed vs. decentralised) will 
continue to develop by its own, in diverse places, and the day it is 
accepted by the market it may result into a dramatic investment waste 
if the solution IETF developped does not match its growth orientations.
jfc


_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram