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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf