On Fri, Oct 10, 2014 at 9:41 AM, John C Klensin <john-ietf@xxxxxxx> 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.