Re: Idea for a process experiment to reward running code...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stephen,

On 12/1/2012 2:56 PM, Stephen Farrell wrote:
At a minimum, any proposal for change should be expected to justify the
specific problem it is claiming to solve --

Disagree. RFC 3933 says:

"A statement of the problem expected to be resolved is
       desirable but not required..."

The IETF has become a curious place. This is twice in two days I've cited pragmatics and been taken for citing formal requirements. Believe it or not "should be expected" is pretty lousy language to invoke for citing formal organizational requirements.

IMO a proposal that does not justify itself with a clear statement of the problem, the seriousness of the problem, and a basis for believing that the proposed solution will matter is frankly not a very serious proposal. It has done none of the hard work of distinguishing itself from myriad other, appealing proposals that might randomly be generated.

I do realize that IETF culture has come to enjoy making and pursuing proposals that satisfy none of these criteria. That's why I've taken to noting that we use the word "experiment" to justify a failure to do adequate homework or be accountable for the outcome. (Or even be able to measure the outcome.)


There's a reason for that IMO - all proposed process changes seem
to generate *lots* of comment that there's a better problem to
solve elsewhere.

Stephen, what you seem to be saying is that it isn't reasonable to expect serious analysis in the formulation of a proposal, when it is put forward, because other folk might/will prefer a different -- and equally ill-formulated proposal?

It certainly is a pain to have to provide meaningful justification.

On the other hand, it's pretty irresponsible not to.


that is, to establish the
context that makes clear the problem is real and serious -- and that the
proposed solution is also likely to have meaningful benefit.

I share the frustration about lengthy standardization, and particularly
with delays at the end.  And certainly there is nothing wrong with
adding parallelism where it makes sense.

However absent a consideration of the lifecycle, the current proposal is
a random point change, quite possibly an example of looking for lost
keys under a lamppost because that's where it's easiest to see.

You may be right, I don't make any claim that this is going to
be super-good. OTOH maybe this is worth trying to see if we like
it or not.

Maybe more cookies at breaks will produce better IETF work.

Maybe a posting limit of one message per day will produce better IETF work.

Maybe...

There's an infinite number of stray proposals any of us could formulate. But they aren't free to pursue.

And relying on the whim of popular fashion -- oh, let's all follow today's pretty flashing proposal -- is mostly distracting from finding and fixing real, strategic issues.

d/

--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]