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
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 <
jmh@xxxxxxxxxxxxxxx> 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
>>
>>
>