Subject: RE: When to DISCUSS?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 8 Jul 2005 09:18:34 -0700

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jul 2005 15:42:14 +0200

Phill,

Just picking out the nub of your message:

> 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

---

From: Scott W Brim <[email-masked]>
Date: Mon, 11 Jul 2005 11:02:18 -0400

> If we agree on this, some wordsmithing may be needed.

There are occasions when limiting the number of deployed solutions is
very good for the future of the Internet, and in those cases, pushing
for Foo even when Bar is just as good is quite legitimate.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 11 Jul 2005 08:21:57 -0700

Scott,

> for Foo even when Bar is just as good is quite legitimate.

Limiting the number of deployed solutions should be done based
on the operational experience/market forces, and not by ADs/IESG
pushing for a particular solution.

Yakov.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 11 Jul 2005 11:38:24 -0400

> for Foo even when Bar is just as good is quite legitimate.

Sure, but I think some of these things ("good", "legitimate")
are unknowable.  In midcom we agreed to reuse an existing
protocol, went through the process of identifying objective
criteria to evaluate existing protocols against, did the
evaluation, and ended up with a protocol that's nearly
universally unpopular.  It's left us with a midcom standard
that's unlikely to be deployed and leaving open the door
for a raft of alternative midcom protocols which may be
deployed by their inventors but are unlikely to be standardized
by the IETF because we've already got a midcom standard.

Intentions can be the best and methodology can be rigorous
(or a reasonable facsimile thereof) and still produce results
that are less-than-useful.  My preference would be to put
more trust in working groups for this kind of decision, since
it's the people working on the stuff who will best understand
the tradeoffs between the inefficiencies in creating more
protocols to support and the inefficiencies in making protocols
do things they were not designed to do.  The kind of decision
you're talking about is an economic one as much as (or more
than) a technical one, and I don't think the IESG is the
right place to put the locus of that kind of decision-making
even while I do agree they need to guide it.

Melinda

---

From: Scott W Brim <[email-masked]>
Date: Mon, 11 Jul 2005 11:55:50 -0400

> pushing for a particular solution.

So you would have blessed IPv8?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Jul 2005 12:00:33 -0400

Yakov,

Ultimately the marketplace will decide, but when a WG provides 
multiple solutions to the same problem it has the potential to 
confuse the marketplace, retard adoption of any solution, interfere 
with interoperability, etc.

Standards ought to avoid confusion, not contribute to it.

Steve

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 12 Jul 2005 01:09:27 -0500

Dear Scott (Brim),

> for Foo even when Bar is just as good is quite legitimate.

Yeah, I agree completely with the sentiment. I just wish there was a 
tighter linkage between what we standardize and what got deployed 
(hint, I am NOT reading this e-mail via IMAP4 carried on IPv6 via 
MIPv6) :-(

Now, if you had said, "limiting the number of STANDARDIZED 
solutions"... But, since the linkage is inexact, are we sure we are 
doing the right thing by shunting Bar implementers off the standards 
track because we are quite excited about Foo?

More to the point, are the people who use our standards sure we are 
doing the right thing (a more interesting question)?

Spencer