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

[Harald Alvestrand <[e-mail]>]

On 01/04/2016 09:03 PM, Ben Campbell wrote:
> Hi Harald,
>
> Thanks for your feedback. Do you have further comments to Mary's
> responses?

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.
>
> 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.

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.

>
> Thanks!
>
> Ben.
>
> On 10 Dec 2015, at 11:53, Mary Barnes wrote:
>
>> On Wed, Dec 9, 2015 at 3:05 AM, Harald Alvestrand <[e-mail]>
>> 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
>>>> [e-mail] mailing lists by 2016-01-05. Exceptionally, comments may
>>> be
>>>> sent to [e-mail] 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.
>>>>
>>>>
>>>
>>>


-- 
Surveillance is pervasive. Go Dark.