(Written for MAAWG, but it applies to many efforts. It should be noted that this is not anybody's official statement; it's just me blathering.)
"Make no little plans; they have no magic to stir men’s blood and probably themselves will not be realized. Make big plans; aim high in hope and work, remembering that a noble, logical diagram once recorded will never die, but long after we are gone will be a living thing, asserting itself with ever-growing insistency." -- Daniel Hudson Burnham
There are many different ways to develop a plan. Some -- including what we're attempting here -- involve defining the problem we're trying to solve, before we try to solve it. Crazy, I know, yet it tends to be fairly effective not only for the kinds of issues we're dealing with in MAAWG, but also for the kinds of minds common to this industry.
For this technique to succeed, we also need to understand some of the possible results of our effort.
MAAWG has no authority to enforce compliance -- not over our members (though they can be kicked out), and certainly not over the rest of the industry. We're not a formal standards-setting body like the IETF. To date, MAAWG has never officially taken a stance on an IETF standards process -- though it's conceivable that we could.
What MAAWG can do, and does do, is publish recommendations in the form of Best Current Practices. This may seem kinda weak to those of us who've been living and breathing these ideas for a long time; to us, everything MAAWG has recommended has been an unwritten best practice for so long that we don't even remember where it came from.
But that's just the point: none of that was ever formalized, we just know. Somebody new who comes along won't know. And that's exactly the problem MAAWG can solve. We can set down the de facto standard practice, so that it doesn't have to be re-argued over and over. We can describe the best, so others may emulate it.
The other thing MAAWG can do is publish what I've been calling a Best Emerging Practices document, where we detail new ideas that are emerging from our conversations. All of the complaints raised during this particular conversation are about the best-available current practices across the industry; by working together, perhaps new, better practices will emerge, more applicable to current reality.
We can't enforce 'em, but we can define and publish and lead by example. That's the
real standards setting process: not arguments over where to place the comma in an RFC, but real-world examples set by the leaders
of the industry.
So, enough with pointing fingers; that gets in the way of collaboration. Enough with complaining. An effective problem statement isn't a list of grievances tacked on the doors of every ISP who ever done you wrong. Rather than a protest borne of frustration and impotence, it should be an assertion of hope.
Sit back for a few minutes...breathe deeply...let go of whatever's frustrating you today. Think of the industry as a whole, of the conversation as a continuum. What do you hope we can solve?
That'll be the problem statement.
