Re: discussion style and respect

[[e-mail]]

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 <[e-mail]> 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: [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
> >> 
> >> 
> >