Subject: Re: Last Call: <draft-campbell-art-rfc5727-update-02.txt> (Improving the Organizational Flexibility of the SIP Change Process.) to Best Current Practice

From: "Ben Campbell" <[email-masked]>
Date: Mon, 04 Jan 2016 14:03:09 -0600

Hi Harald,

Thanks for your feedback. Do you have further comments to Mary's 
responses?

In any case, there's nothing (intentionally, anyway) in the draft that 
pushes for other areas to use the dispatch process unless they see a 
benefit in doing so.

Thanks!

Ben.

On 10 Dec 2015, at 11:53, Mary Barnes wrote:

> On Wed, Dec 9, 2015 at 3:05 AM, Harald Alvestrand 
> <[email-masked]>
> wrote:
>
>> Objection:
>>
>> I find the DISPATCH style of review to be a horribly broken idea.
>>
> [MB] For those of us that were involved in the RAI/TSV area before
> DISPATCH, the process solved a number of real problems such as work 
> group
> shopping, delays in getting work moved forward as well as the insanity 
> of
> the SIPPING WG.   Now, things have changed in terms of the volume of 
> new
> work, so perhaps we no longer need this type of process and we can go 
> back
> to the adhoc way in which things were handled previously.
>
>>
>> I also find the use of the term "working group", and the procedures 
>> of
>> working groups, for what is effectively a permanent review panel and 
>> a
>> standing BOF venue to be counterproductive and destructive of getting
>> work done.
>>
> [MB] Certainly, it doesn't fit a typical working group model and 
> really is
> more of an area working group, but it's not run as a permanent review 
> panel
> nor standing Bof.   All discussion happens on the work group mailing 
> list
> other than a single call with the ADs and DISPATCH WG chairs and the 
> output
> of that call is published on the WG mailing list for community 
> feedback.
> I'm just curious if you could provide at least one concrete example of 
> the
> counterproductive and destructive aspects of the process.  What work 
> didn't
> get done that you think ought to have gotten done because of the 
> process?
> [/MB]
>
>>
>> This document proposes recommending this method as a generic tool 
>> that
>> can be used in areas outside of the limited scope of SIP extensions -
>> something I think is taking a bad idea and making it even more 
>> harmful.
>> (RFC 5727 already said it would do that, but the RAI area has not
>> followed up on this particular bad idea from RFC 5727, letting
>> initiatives like WEBRTC flourish outside of the DISPATCH process, so 
>> the
>> damage done by DISPATCH has been limited.)
>>
> [MB] Actually, WebRTC still ran under the process in that it was quite
> clear from the get go that it was a large work item with a very broad 
> scope
> for which the entire community ought to be involved.  Honestly, if you
> could point out other work that we've dispatched without a Bof that 
> you
> think ought to have been Bofed, that would be great.  Now, my 
> experience
> with the process is clearly biased since I co-chaired the SIPPING WG 
> and
> have been a chair of DISPATCH since the WG was chartered and the 
> difference
> between how we handle new work has dramatically improved in timeliness 
> and
> getting the right people involved. Now, maybe I'm a lazy WG chair and 
> am
> just so happy that I don't have dozens of documents in process, but 
> rather
> a handful of AD sponsored documents to shepherd, that I'm missing some
> critical flaw. [/MB]
>
>>
>> I therefore object to this document being published as a BCP.
>>
>> Note: I would not object to publishing a document saying "the 
>> DISPATCH
>> working group is now part of the ART area". It would be useless, but 
>> not
>> harmful.
>>
> [MB] I certainly don't have the experience with other areas to know 
> whether
> it would be harmful if other areas adopted this model.  It would be 
> good to
> hear from other WG chairs on this topic. [/MB]
>
>>
>> Den 08. des. 2015 16:56, skrev The IESG:
>>>
>>> The IESG has received a request from an individual submitter to 
>>> consider
>>> the following document:
>>> - 'Improving the Organizational Flexibility of the SIP Change 
>>> Process.'
>>> <draft-campbell-art-rfc5727-update-02.txt> as Best Current Practice
>>>
>>> The IESG plans to make a decision in the next few weeks, and 
>>> solicits
>>> final comments on this action. Please send substantive comments to 
>>> the
>>> [email-masked] mailing lists by 2016-01-05. Exceptionally, comments 
>>> may
>> be
>>> sent to [email-masked] instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>  RFC 5727 defines several processes for the Real-time Applications 
>>> and
>>>  Infrastructure (RAI) area.  These processes include the evolution 
>>> of
>>>  the Session Initiation Protocol (SIP) and related protocols, as 
>>> well
>>>  as the operation of the DISPATCH and SIPCORE working groups.  This
>>>  document updates RFC 5727 to allow flexibility for the area and
>>>  working group structure, while preserving the SIP change processes.
>>>  It also generalizes the DISPATCH working group processes so that 
>>> they
>>>  can be easily adopted by other working groups.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-campbell-art-rfc5727-update/
>>>
>>> IESG discussion can be tracked via
>>>
>> https://datatracker.ietf.org/doc/draft-campbell-art-rfc5727-update/ballot/
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 4 Jan 2016 21:24:54 +0100

> Thanks for your feedback. Do you have further comments to Mary's

I've been mulling this over the holidays. It is clear that I need to
phrase things more carefully; it seems that my (rather harsh) words were
too easily interpreted as a challenge to either the integrity or the
competence of the people who led this process, while it was intended to
point out that their efforts had led us to a place I consider to be very
very wrong - and that applying the same pattern would likely have a
result that was no better.
> pushes for other areas to use the dispatch process unless they see a

The draft does explicitly state the intent to use a dispatch-like
process for the apps pieces of ART, though.
I think that's a Bad Idea.

>> On Wed, Dec 9, 2015 at 3:05 AM, Harald Alvestrand <[email-masked]>
>> wrote:
>>
>>> Objection:
>>>
>> shopping, delays in getting work moved forward as well as the
>> insanity of
>> the SIPPING WG.   Now, things have changed in terms of the volume of new
>>> I also find the use of the term "working group", and the procedures of
>>> working groups, for what is effectively a permanent review panel and a
>> of that call is published on the WG mailing list for community feedback.
>> I'm just curious if you could provide at least one concrete example
>> of the
>>> This document proposes recommending this method as a generic tool that
>>> something I think is taking a bad idea and making it even more harmful.
>> could point out other work that we've dispatched without a Bof that you
>> think ought to have been Bofed, that would be great.  Now, my experience
>> with the process is clearly biased since I co-chaired the SIPPING WG and
>> between how we handle new work has dramatically improved in
>> timeliness and
>> getting the right people involved. Now, maybe I'm a lazy WG chair and am
>>> Note: I would not object to publishing a document saying "the DISPATCH
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>> final comments on this action. Please send substantive comments to the
>>>> [email-masked] mailing lists by 2016-01-05. Exceptionally, comments may
>>> be
>>>>  RFC 5727 defines several processes for the Real-time Applications and
>>>>  Infrastructure (RAI) area.  These processes include the evolution of
>>>>  the Session Initiation Protocol (SIP) and related protocols, as well
>>>>  It also generalizes the DISPATCH working group processes so that they

-- 
Surveillance is pervasive. Go Dark.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 04 Jan 2016 14:54:27 -0600

> result that was no better.

Can you offer examples where the dispatch process led to poor results? 
Especially where non-dispatch approaches would be reasonably expected to 
offer different results?

> I think that's a Bad Idea.

Can you elaborate on why that is a Bad Idea?

I don't see this as being all that different from at least part of what 
the appsawg already did. The main point is to have the wg act as a 
triage point rather than as a place for work to happen. Nothing here 
prevents BoFs where people think they make sense. Where do you see 
things going wrong?

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 Jan 2016 17:31:35 -0600

Here's a summary of the last call feedback I've seen so far, and 
proposed actions:

*** Substantive comments: ***

- John Levine:
  -- Change title to something more relevant.
  -- Update contents to reflect that the ART merge has already happened.

Ben: Title changed to "DISPATCH-Style Working Groups and the SIP Change 
Process" in working copy. Updated language to indicate the merge has 
already occurred.

- Richard Shockey: The ART merge was not a good idea.

Ben: It's probably useful to discuss the success or failure of the ART 
merge, but I don't think it's in scope for this draft. The draft doesn't 
execute that merge, the update adapts to the it.

- Harald Alvestrand: The dispatch process has had poor results, and 
should not be propagated:

Ben: I thought dispatch had worked reasonably well for RAI. As it is, 
the authors do not have enough specifics to propose actions on this 
comment.

- Jon Mitchell (OPS-DIR review):
-- Clarify the responsibility for "judgement calls" in section 2:

Ben: I've made the following change in my working copy:

OLD
    Nothing in this list prevents existing working groups from directly
    adopting new work that reasonably fits their charters.  For
    borderline cases, the decision whether new work should start in a
    dispatch-style group, or in an existing group is a judgement call
    among the responsible Area Directors and chairs.  Likewise, in cases
    where an area has multiple dispatch-style groups for different
    purposes or technology clusters, the decision about which group will
    handle a particular proposal is a judgement call.
NEW
    Nothing in this list prevents existing working groups from directly
    adopting new work that reasonably fits their charters.  For
    borderline cases, the decision whether new work should start in a
    dispatch-style group or in an existing group is made by the
    responsible Area Directors and chairs.  Likewise, in cases
    where an area has multiple dispatch-style groups for different
    purposes or technology clusters, deciding which group will handle
    a particular proposal is up to the responsible Area Directors and
    relevant chairs.
END

-- The security considerations are not about security in a technical 
sense.

Ben: While this is not about protocol or network security, it is about 
the integrity of the standards process. In my opinion, that's reasonable 
content for the security considerations.

*** Editorial: ***

Fixed several reported misspellings and typos

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 Jan 2016 20:34:10 -0600

When I put the summary together, I failed to notice that Harald had sent 
a separate email with more specifics about his feedback. Mea Culpa, and 
the summary entry for Harald's feedback should say "Ongoing discussion".

Ben.

On 27 Jan 2016, at 17:31, Ben Campbell wrote:

> Ben: Title changed to "DISPATCH-Style Working Groups and the SIP 
> Change Process" in working copy. Updated language to indicate the 
> merge has already occurred.
>
> merge, but I don't think it's in scope for this draft. The draft 
> doesn't execute that merge, the update adapts to the it.
>
> the integrity of the standards process. In my opinion, that's 
> reasonable content for the security considerations.
>
> *** Editorial: ***
>
>> may be