Longer or more meetings?

[Margaret Wasserman]

>It seems to me that part of the IETF theory is that
>protocol quality is key to deployment. In many cases, that quality
>is best injected by independent people with specific expertise.

Good point...

But, there are quite a few people who have pointed at the IEEE
(particularly IEEE 802) as a "successful" standards body that we
might want to emulate.  Many of their standards have achieved
great commercial success, they get them out faster than we do,
they usually already have implementations when the standards are
published, etc...  They also have a strong funding model for
their internal technology, infrastructure, etc.  Much of this
"success" can be linked to the fact that they have expensive
corporate memberships and lots of dedicated resources.

I actually _do_ believe that the open process of the IETF (if
it were actually used consistently) should produce higher quality
results, but it is certainly slower than a more closed, corporate-
sponsored process carried out by full-time standardizers...
And, at times, I think that we may be too focused on quality.
We have a three-step standards process and we can (and usually
do) cycle at each level, so it should be possible for us to
produce iteratively higher quality and more stable specifications.
It seems, though, that even the smallest detail can hold up a
specification at any level, even a specification that is _much_
better across the board than the current RFC version.  This
destroys our ability to successively iterate towards a strong
final product.

The perfect is the enemy of the good, and all that.

I'm still not quite sure what "relevance" means, but it seems to
combine some factors of quality, timeliness and commercial
success?

People keep saying that they want standards out faster, and that
our standards are often too late to be "relevant".  Well, we
all know that you can ship a product faster using a smaller,
team of dedicated people, but perhaps that leads to a lower
qualify result...  So, how do we want to balance these factors?

I guess what I am basically trying to say is that we need to know,
before we start making changes to try to "fix" the IETF, what
our goal state is along several axes.  Quality is good, but needs
to be balanced against the speed of the process.  Relevance is
good, but what are the trade-offs?

One trade-off in the area of "relevance" may be when we start
work in a particular area.  Do we drive innovation in technology
by starting problem-area-focused working groups and trying to
build solutions?  Or do we wait until the industry has built some
successful solutions in a particular space and become a forum
for the industry to migrate multiple, non-interoperable solutions
towards a standard?  What we need to optimize for along other
axes might be quite different in those two cases.

Margaret