architectures and evolution

[Harrington, David]

Hi,

I strongly support the idea of having architecture(s), but ...

Be careful not to tie WGs into a corner. At the point that an architecture document is written, prior to development of the protocol, the problem may not be as well understood as needed. It is easier in many ways to develop a theoretical model than it is to produce a protocol that can actually provide the desired functionality and work properly  over time in constantly changing real-world environments.

I am a strong believer that the standards process operates within an environment that mirrors evolution. It is important to have many mutations developed in the marketplace, and to have the marketplace serve as the primary culling mechanism to eliminate approaches that are not able to meet the demands of the environment. The market narrows the options to those that are viable. i.e., it produces running code.

The standards process is effectively a breeding program. It identifies the desirable traits and how they could or should be combined to produce a superior strain, or a society composed of multiple superior strains designed to work together.

In my view, the architecture should be the breeding program plan, and it should include plans for how to identify desirable traits in new mutations, how to identify the desirable traits in existing mutations, which strains might be combined to produce desirable results, and which are considered high priority. I believe having a plan is important to help focus limited resources (e.g. IESG review commitments, rfc-editor time, etc.) on the high priority items.

Then teams of engineers (WGs) can ask the program coordinators to allocate some of the limited shared resources to support their team, while the team develops a desired strain as part of the overall program.

The architecture should NOT be a program based on some theoretical purity approach, based on conjecture rather than facts about viability, that tries to eliminate all non-compliant mutations. The non-compliant mutations should be permitted to die off naturally in the marketplace through normal breeding selection, as less desirable "edge" cases have difficulty attracting mates. This is important because, if the environment changes suddenly, the edge cases may prove more viable than the "superior" strain. Constantly having many mutations in the gene pool is critical to the success of a healthy evolutionary process.

I believe this evolution is what "rough consensus and running code" is all about.

dbh
---
David Harrington            
dbh at enterasys.com           
co-chair, IETF SNMPv3 WG


> -----Original Message-----
> From: Natale, Robert C (Bob) [mailto:bnatale at lucent.com]
> Sent: Friday, January 10, 2003 2:37 AM
> To: saq66 at umkc.edu
> Cc: problem-statement at alvestrand.no
> Subject: RE: Complex Problems
> 
> 
> Hi,
> 
> "Ayyasamy, Senthilkumar (UMKC-Student)" <saq66 at umkc.edu>
> > else, have something like *architectural considerations*
> > in addition to *security considerations* ;)
> 
> I don't think that's a bad idea at all.  Indeed, I would
> suggest having such a section in the WG's *charter* for
> proactive guidance at the outset and consistency checks
> along the way (as documents are produced and milestones
> possibly changed).
> 
> Cheers,
> 
> BobN
>