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" <> Mon, 04 January 2016 20:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C32411A92F7 for <>; Mon, 4 Jan 2016 12:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9gMY4be0RmEF for <>; Mon, 4 Jan 2016 12:54:33 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE6141A92EF for <>; Mon, 4 Jan 2016 12:54:32 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id u04KsR75062870 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 Jan 2016 14:54:28 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: Harald Alvestrand <>
Subject: Re: Last Call: <draft-campbell-art-rfc5727-update-02.txt> (Improving the Organizational Flexibility of the SIP Change Process.) to Best Current Practice
Date: Mon, 04 Jan 2016 14:54:27 -0600
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <>
Cc: ietf <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jan 2016 20:54:35 -0000

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 
>>> <>
>>> 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 
>>>> 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
>>>>> mailing lists by 2016-01-05. Exceptionally, comments 
>>>>> may
>>>> be
>>>>> sent to 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
>>>>> IESG discussion can be tracked via
>>>>> No IPR declarations have been submitted directly on this I-D.
> -- 
> Surveillance is pervasive. Go Dark.