ietf
[Top] [All Lists]

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

2012-12-01 17:22:10


On 12/01/2012 11:13 PM, Dave Crocker wrote:
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.)

IMO IETF culture has become too process-driven. And yes, I do
interpret your question (which is not unreasonable on its face)
to be saying that a justification is formally required.

My reluctance to get into this is based on an opinion that process
change proposals with more words attached tend to just not happen,
so fewer words is better. And I also think you and many others are
well placed to decide if you think this is a worthwhile change or
not, independent of any reasons for which I propose it. So I really
do think all the motivation text that'd be perfect fodder for
endless discussion is neither necessary nor useful here.

Cheers,
S.

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/