Re: discussion style and respect

["jmh.direct" <[e-mail]>]

If the WG has fallen into the trap of wanting to publish some the use cases as RFCs, then....Joel


Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------
From: [e-mail] 
Date: 06/13/2015  6:59 PM  (GMT-05:00) 
To: "Joel M. Halpern" <[e-mail]> 
Cc: Melinda Shore <[e-mail]>, Brian E Carpenter <[e-mail]>, John C Klensin <[e-mail]>, [e-mail] 
Subject: Re: discussion style and respect 

You should never spend time discussing whether to accept use cases. 

Use cases should only be prioritized. 

Sent from my iPhone

> On Jun 13, 2015, at 5:46 PM, Joel M. Halpern <[e-mail]> wrote:
> 
> I find myself in the middle on this.
> Spending a lot of time on use case documents, and deciding which use case documents you will adopt (the answer usually being all) is not productive.
> But not having agreement on the problem, or conversely having agreement on the solution whatever the problem really is, also produces veyr bad results.
> 
> We have, many times, managed to thread our way in between these various extremes.  From what I have seen, that usually works better.  (It also helps if there are actually enouhg people willing to do the work.)
> 
> Yours,
> Joel
> 
>> On 6/13/15 5:36 PM, Melinda Shore wrote:
>>> On 6/13/15 12:22 PM, Brian E Carpenter wrote:
>>>> On 14/06/2015 01:19, John C Klensin wrote:
>>>> ...   However, if a WG is
>>>> started with a "solution" and a group of people behind it, there
>>>> are some bad effects:
>>> Yes, and this is certainly a very real situation. I've personally
>>> experienced it in the past, and am currently experiencing it
>>> (without belligerence, fortunately).
>> 
>> I'm actually pretty ambivalent about this one.  I'd much
>> rather see things coming in that are relatively well-baked
>> than see proposals that are just problem descriptions.
>> It seems to me to be a more productive use of energy to
>> negotiate engineering differences than it is go try to
>> figure out whether or not a given problem statement reflects
>> an actual problem that somebody is really experiencing, or
>> if there's the ability to come up with a useful solution.
>> Yes, it can be heated and horrible (and I actually left the
>> IETF for several years in part because of my experience
>> along these lines in one particular working group), but
>> I think we're better off figuring out how to deal with
>> these situations than we are going with the problem statement/
>> use case/gap analysis model, which is really beginning to
>> annoy me as unproductive, slow, and unmoored to much that's
>> useful.
>> 
>> Melinda
>> 
>> 
>