> draft-iesg-discuss-criteria-00.txt talks about this. Even > within the IESG, we still have one or two points to resolve, > but we wanted to get this out before the cutoff date. This > isn't in any way intended to change any of the principles of > the standards process, but we'd welcome community comment. This is actually quite good. In particular I think that it does go a long way in returning to the original concept of the IETF rather than what it had been turning into. There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. This issue is not unique to the IETF, at one point there was a major issue in W3C when some members suspected that Semantic Web would be imposed in this manner. I believe that a similar dynamic played a major role in causing OSI to become what it became. There are some cases where this is a good idea, it is clearly important that every IETF standard protocol is capable of making the transition to IPv6. But there are other cases where this really comes down to second guessing the WG or worst of all promoting a pet project. For example when I submit a draft proposing a prefix for use with SRV I do not expect to have to explain my reasons for using a technology that is widely supported by existing infrastructure over NAPTR, a technology which is only partially supported, has yet to gain a major constituency of users and may well end up being superceeded before it is widely adopted. Now some might say that the role of the IESG should be precisely to do this sort of thing, to encourage the adoption of technology that deserves to be employed as a technology base. I disagree because this leads working groups to think that its not their job to promote their work product and drive its adoption, they can simply rely on the IESG to do their work for them by forcing other groups who have killer applications to do the heavy lifting for them. I spend a great deal of time working out how to get a protocol adopted, how to build the necessary coalitions of support to drive deployment. If I have a choice of technology platforms I am not going to necessarily pic the one that is the newest, brightest and shinyest. In the first place I have been caught out in the past several times following that route and finding that my spec is the only system built on the new platform. But more importantly the more infrastructure innovations a proposal requires the harder it is to build a coalition and the harder it is to keep it together. The most worrying version of this approach is when a group is told that in order to gain approval of the IESG it MUST take a particular technical approach. This is why I would like a very concrete statement in the DISCUSS document saying that a WG is free to choose an approach that uses deployed technology over another proposal without market traction. I know of two cases where a group has been essentially forced to significantly compromise their design in order to support BEEP. At this point it should be clear to anyone who follows the Web Services area that there is universal agreement amongst vendors and developers that the SOAP stack is the only one that will be used. This outcome has been clear to anyone who has followed this area for at least four years. I watched the SACRED group being bullied into adopting BEEP as a substrate. This makes even less sense when you know that SACRED was intended to be a compliment to XKMS which is defined to be a Web Service running over SOAP. The only argument I saw made at the meeting was that the IESG would expect BEEP to be supported so the WG better get in line. There is at this point a huge difference in the capabilities of BEEP and the capabilities of Web Services based on the SOAP, WSDL etc. It is a major imposition on a working group to require them to support BEEP because it then forces the group to re-invent the work that has gone into WS-Security. Developers are then required to implement the DIY security infrastructure developed by the group rather than use the existing libraries in the Web Services development environments. It would be much easier for me to get INCH/RID adopted as an incident notification protocol in the anti-phishing world in its original Web Services compliant form than in the current incarnation that was imposed on the group by an area director. If I am talking to Microsoft, IBM, Sun or any bank that uses their technology it is much easier to get them to buy into a protocol that they can build in an afternoon using standard toolkits than something that will require bespoke work. In summary, the DISCUSS draft is header in the right direction and the above is implicit in its text but it should be made explicit. Phill _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf