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