On Fri, Oct 10, 2014 at 9:41 AM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
It is probably not particularly important but moving to more
technical secretariat support does not require staff dedicated
to areas. Some organizations do that, some don't.
If we are going to consider organization changes then we should be
looking more at the OASIS model that seems to work rather than the ITU
model which we have never liked and is poised to demonstrate a rather
spectacular failure model.
What I like about the OASIS model is that it dispenses with hierarchy
almost completely. What I dislike is that there are no structures to
encourage coherence between proposals at all.
My experience of SAML was that I spent 18 months making more or less
weekly tweaks to a specification document that mostly reflected
changes in opinion about the way we should use XML. And then after 1.0
shipped these were completely revisited to produce 2.0.
So when IETF groups started using XML and we had the same debates I
was suggesting that we have one group make one set of decisions that
we apply to all protocols unless there is good reason to do otherwise.
But that was of course a mistake. The fact the discussions were
necessary was due to the fact that we were using a screwdriver on a
nail and what we really needed was to ditch XML for JSON.
I would like some technical coherence direction but I don't see the
IESG or the IAB as providing it or really having the accountability to
do so.
My broader point was that, as we start looking beyond seeing an
issue with Apps and start wanting to make some adjustments into
thinking about how our basic "steering" and management structure
should evolve with the times, things similar to Stewart's model
of AD-plus-assistants aren't the only alternative.
I agree. But returning to my earlier discussion on models. There is a
need for well defined interfaces at many different levels. The
transport area can do whatever it likes internally provided that it is
compatible with the laws of physics. But it can't change the interface
to applications or to the Internet layer without agreement on the
other side.
The approaches to standardization at the lower levels in the stack are
not necessarily optimal for the higher levels. It is really important
that the Internet area be 'stable' but what at the Applications level
we want to have as few constraints as possible. Applications level
'architecture' work is almost all digging ourselves out of holes
created by divergence.