-----Original Message-----
From: Brian E Carpenter [mailto:brc(_at_)zurich(_dot_)ibm(_dot_)com]
Sent: Monday, July 11, 2005 9:42 AM
To: Hallam-Baker, Phillip
Cc: IETF Discussion
Subject: Re: When to DISCUSS?
Phill,
Just picking out the nub of your message:
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.
I think the last phrase is unfair - if the IETF is putting a
lot of effort into technology Foo, then it's a legitimate
question to ask "Why aren't you re-using Foo?" But we do have
as a non-criterion:
o Disagreement with informed WG decisions that do not exhibit
problems outlined in Section 3.1. In other words,
disagreement in
preferences among technically sound approaches.
As I read this, it would be legitimate for an AD to ask
Did the WG consider Foo, and if so, have good reasons for
rejecting it in favour of Bar?
and illegitimate to say
I like Foo more than Bar, so I'm blocking this.
If we agree on this, some wordsmithing may be needed.
Brian
Hallam-Baker, Phillip wrote:
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