Complex Problems

[Jari Arkko]

john.loughney at nokia.com wrote:

>>one problem is that these are not simple issues.  this is not a
>>simple space.  and they often do not have 'solutions', but rather
>>provide guidance and clues.  and, when that guidance does not fit
>>well with someone's plan or product, i guess it may indeed seem as
>>if they do not want to discuss architecture.
> 
> 
> That makes much sense as well.  I guess that might lead to the suggestion
> that architectural discussions / advice are best done as early as possible
> - it becomes much more difficult to re-architect things at the IESG
> review stage - but you know that.

Our process and documentation style may have something to do with that.
We usually produce RFCs in the "one shot" manner where the whole protocol
is in one document, and gets to the IESG as one fully completed piece
of work. There may be some architectural advice early on, but an e-mail
on the list is much easier to ignore than a refusal to publish an RFC.

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.

Jari