Complex Problems

[john.loughney at nokia.com]

Hi Jari,

> If we want to emphasize the need for early architectural advice we may
> want to think about splitting our documents into "Architecture for X"
> and "The X Protocol" documents, and get them approved separately. The
> architecture document would be done early of course, and would contain
> the major design decisions such as what the protocol entities are, on
> top of which protocol are we running, do we use hbh or e2e security,
> etc. But all the protocol details such as message formats and 
> behaviour rules would be in another document.
> 
> Such an approach may not fit all situations. It certainly looks
> like an overkill for simple protocol RFCs. But I know some
> cases where it would have been useful, say in AAA or in Mobile IP,
> probably also in SIP. We did a framework document in AAA, but we
> didn't use it to the full extent, e.g. I don't think we had it
> approved by the IESG early on. If we did, we might have avoided
> some of the discussion with vendor extension capabilities etc.

In new WGs approaching a problem space, this may be the correct first
steps.  It takes a lot of time getting a new WG into shape, getting
us to understand the problem space and accept the charter.  Working 
through some architectural assumptions could help.  At IETF 55, Melinda
Shore had a good point - whenever a new WG is formed, a bunch of homesteaders
appear with a land-rush mentality.  They may not be trying to solve the
same problem that is outlined in a charter, they just think that the new
WG may be home to their pet project / protocol.  At least by working
on some architecture, we can already start sifting the good ideas from
the bad.

John