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 <harald@xxxxxxxxxxxxx> >> 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 >>>> ietf@xxxxxxxx mailing lists by 2016-01-05. Exceptionally, comments may >>> be >>>> sent to iesg@xxxxxxxx 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.