At 3:56 PM +0200 4/5/02, avri wrote:
>RJ Atkinson wrote:
>
>>
>>>Several people have mentioned that restricting the requirements to something
>>>that is purely evolutionary just won't do, and have criticized the Group B
>>>requirements for requiring an evolutionary approach. I.e. they are critical
>>>of the requirement to evolve from today's network to tomorrow's network and
>>>argue that a revolutionary approach is necessary.
>>
>>
>> I must have missed the notes you mention.
>>
>
>
>These were in conversations I had with people.
>Though the criticism is also mentioned in Group A's
>discussion of Group B's requirements doc.
>
My two cents or Euro equivalent.
Absolute agreement there should be revolutionary architecture, and
probably more than one for the value of comparison and competition.
Now, read this carefully. Many[1] of the current requirements aren't
going to go away. We aren't going to have less routers, less demand
for availability, less need to find economic methods of
charging/peering/etc.
I can't see how these cannot be starting points for _requirements_
rather than architecture. There is no reason why many completely new
functionalities can't go into a new requirements specification, nor
to consciously remove conventional requirements that are believed
more appropriate for another layer. But I fail to see how we can
ignore current requirements AS BASELINEs.
We can conceive a single broad requirement that there cannot be a
flag day conversion, but leave the migration mechanisms to the
architectures.
To draw an analogy from the medical world, there's always going to be
a requirement to treat, for example, rheumatoid arthritis. The
treatments themselves are the equivalent of architecture.
First-generation treatments simply relieved pain. Second-generation
treatments went to a different paradigm: using fairly broad immune
suppressants. The recent third generation couldn't happen until the
molecular biologists identified the specific chemical (Tumor Necrosis
Factor alpha) that primarily causes the disease process, and only
THEN could specific genetically engineered treatments could be
developed to block TNF-a.
Even in the "third generation" treatment architecture, there are at
least two paths or -- dare I say -- alternative architectures? One
that goes after circulating TNF-a and the other that blocks cellular
TNF-a receptors?
One requirement, which certainly can contain revolutionary
functionality. Multiple architectures at the research level.
Choices among architecture at the engineering level, along with
protocol developent.
[1] Requirements should be for function. We must be very careful not to
express as a requirement something that is really a cleanup of a limitation
of BGP, and essentially have the requirement reflect a BGP paradigm.
-- Howard C. Berkowitz hcb@gettcomm.com 703-998-5819 Chief Technology Officer, GettLab/Gett CommunicationsUsual disclaimers -- on odd days I can't set policy and on even days I can. Or is it the other way around?
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT