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

["Ben Campbell" <[e-mail]>]

On 4 Jan 2016, at 14:24, Harald Alvestrand wrote:

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

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?

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

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?

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