Dave, thanks for raising tough questions.
I am somewhat skeptical that IETF should place too much emphasis on its
estimation of the "market". I remember one working group that started
out saying "we're just going to standardize whatever <big company> does,
since they'll win anyway" (even though the resulting standard would
likely not have worked well for users of other companies' products).
Fortunately, they didn't end up doing that, and while what they produced
was bloated and baroque, and I'm not even sure that <big company>
supports it, the IETF standard was implemented in an open source
project, which was adopted by other vendors' products. And the
computing world has become larger and more diverse so that<big
company>'s products are not as relevant as they used to be.
And yet, the zombie projects you cite absolutely do exist in IETF, in
significant numbers.
I have rarely seen a WG vote to disband itself rather than take on new
work. Some WGs naturally wind down because their work was inherently
tightly scoped, so it's obvious when they're done. For others, at every
meeting more drafts with less overall relevance are adopted.
But somehow there's a belief that ADs should not be able to kill WGs.
There's a strong feeling that people who have invested in a WG should
not have it pulled out from under them like a rug.
Nobody likes a project that they've been working on to be terminated,
and I can't say that such decisions made in industry are generally
wise. But cancellations are nonetheless sometimes necessary. Some
WGs go off in the weeds and never correct themselves, and continue to
meet for many years, taking up precious meeting slots and AD and chair
and participant resources. Sometimes it turns out that the WG's
original idea just wasn't that good, or wasn't as easy to realize as it
initially seemed, or the participants simply aren't willing to reach any
kind of consensus. And sometimes a WG's work is overtaken by events.
Zombie WGs aren't just taking up resources for those who participate in
and manage them. They make IETF less interesting overall, and decrease
IETF's perceived relevance to its own participants and to the world.
I remember when you could get real work done in IETF meetings. The
meeting slots were long enough and you could often get two of them
scheduled within the week, so between the meetings you could get
together with the relevant people, hash out the necessary compromises,
and revise the I-D before the week ended. Meeting time was devoted to
discussion, presentations were rare, there was no PowerPoint. There
wasn't a microphone queue to slow everybody down, and the seating wasn't
squished together so tightly that most participants couldn't get up to
speak. There was no WiFi in the room, so the room wasn't full of
people glued to laptops doing other things and distracting from the
discussion. And the WGs didn't take on a lot of peripheral work, they
were tightly focused on a small number of drafts.
(and yeah, some of those things needed to change, but most of the
changes were made without much consideration of how they'd affect our
ability to do work)
These days it seems like you spend thousands of dollars to travel
halfway around the world to meet for 2 hours, or meet for longer in a
broadly-scoped WG that only has a few minutes to devote to the project
you're working on, and 90% of that time is devoted to staring at a
screen. And somehow this is supposed to facilitate progress.
What would IETF meetings be like if they were primarily set up to
facilitate production and testing of running code?
Keith
On 5/12/19 2:33 AM, Dave Taht wrote:
Zombie projects stagger through the hallways. Most orgs (of any sort)
do do a yearly review of their projects and kill a percentage of them
if they are not showing results. In my case I use very different
techniques to ensure good code and standards, among others, the game
of dealer,
( https://www.amazon.es/Dealers-Lightning-Xerox-Parc-Computer/dp/0887309895
), and focusing
(48 pt font) on running code and public deployment, more than rough
consensus (8pt font).
I can think of quite a few working groups within the ietf with
projects on their agenda that were long ago surpassed by market
forces, and the need for any further standards to appear, long since
vanished. The winners in the market stop going to ietf, the losers
plunk along trying to get their stuff standardized. To avoid howling
here I'll skip mentioning the dozens I have on my list, and just pick
on one that I was present at the founding of, homenet.
Market forces have completely shifted out from under that working
group. No serious vendor
support ever appeared. The vendors most affected, never showed up.
Specs exist, but code doesn't. There was a very good preso on all this
at homenet 104. The members of that working group hummed
overwhelmingly to recharter at ietf 104. After that, however, several
core members of the group expressed to me that it would be best to
shutter it entirely and attempt to move the core to an org that was
actually focused on running code, more than further specifications and
further wading through ietf processes, and thus, meet elsewhere,
entirely.
I feel a lot of working groups here could adopt the best of the ietf
processes, dump the rest,
and disband their ietf presence, meeting using better tools, cheaper
hotels, and leaner processes.
>From the bottom up, and the top down, it would be better to
periodically ask hard questions (is this tech going to work?), do a
market review (is this standard (still) needed?), and so on.
Asking each working group to justify its continued existence and need
for meeting space with a set of hard questions might be a start.
Identifying what questions to ask, a start to that start.
An ietf with 30% less working groups, and a larger percentage of the
remainder working on standards that might matter, would be a better
ietf.
It is always easier to add, rather than subtract.
