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:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8907F1A911F for <>; Mon, 4 Jan 2016 12:03:19 -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 x79eT9-Zd6qz for <>; Mon, 4 Jan 2016 12:03:17 -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 75D4B1A9105 for <>; Mon, 4 Jan 2016 12:03:17 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id u04K39jn058560 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 Jan 2016 14:03:10 -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:03:09 -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:03:19 -0000

Hi Harald,

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

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.



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.