ietf
[Top] [All Lists]

Re: discussion style and respect

2015-06-13 19:10:49
I think that requirements, use cases, one top test reports etc should be 
published as NWC

Noted Without Comment

They would go to WG last call but NOT ietf or Iesg

Not permitted to use standards language, or describe protocols or formats. 


Sent from my iPhone

On Jun 13, 2015, at 8:00 PM, jmh.direct 
<jmh(_dot_)direct(_at_)joelhalpern(_dot_)com> wrote:

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: hallam(_at_)gmail(_dot_)com 
Date: 06/13/2015 6:59 PM (GMT-05:00) 
To: "Joel M. Halpern" <jmh(_at_)joelhalpern(_dot_)com> 
Cc: Melinda Shore <melinda(_dot_)shore(_at_)gmail(_dot_)com>, Brian E 
Carpenter <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>, John C 
Klensin <john-ietf(_at_)jck(_dot_)com>, ietf(_at_)ietf(_dot_)org 
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 
<jmh(_at_)joelhalpern(_dot_)com> 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



<Prev in Thread] Current Thread [Next in Thread>