Longer or more meetings?

[Eric Rescorla]

Margaret Wasserman <mrw@windriver.com> writes:

> At 10:16 AM 12/7/2002 -0500, Henning Schulzrinne wrote:
> > Other SDOs, such as W3C, rely much more heavily on teleconferences,
> > typically weekly. With modern web-based meeting support tools
> > (shared whiteboard, shared slide viewing, text chat for questions,
> > etc.), these can be fairly effective. They also avoid the "selection
> > by travel budget" problem that you do not mention below.
> 
> 
> One heretical thought on the selection by travel budget "problem":  Why
> is it a problem?
> 
> We've concerned about the lack of "relevance" of our standards, right?
> And how do we measure "relevance"?  It seems that we measure it, mainly,
> by the commercial success and wide deployment of our protocols.
> 
> If a person/company doesn't have the budget to travel to meetings to
> work on a protocol, what is the chance that they have the resources to
> implement the protocol and/or make it a commercial success?

This sort of assumes a view of IETF as a place for vendors to
collaborate on deciding what a standard should be. Naturally, in such
a venue, your participation is important to the extent to which you
can bring implementors and product to the party.
 
However, the IETF has a tradition of not accepting this model, in
favor of one in which we are all attempting to collaborate to do the
Right Thing. In such an environment, what's relevant isn't the market
throw weight of the participant but the value of their ideas. Even if
one has a model where the IETF exists primarily for the benefit of
vendor collaboration, one might wish to have disinterested third
parties do much of the work as a form of facilitating that
collaboration. (The third parties do the work for reasons of their own
which we don't need to get into).

I agree that in practice we often behave as if market power is very
mportant, but that doesn't mean that we should necessarily wish to
bias the process even further in that direction than it naturally is.

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/