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

[Dave Crocker <[e-mail]>]

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