Four 1hr meetings does not equal one four hour meeting. With the time it
takes for a prior group to clear a room and another group to enter,
achieve quorum, and cover clerical details, you have lost probably 20
minutes at a minimum. So your four one hour meetings provide
4*(60-20)=160 minutes of useful time. A four hour meeting has
4*60-20=220 minutes. You just lost an hour of working time.
Paul
Dean Willis wrote:
On Jun 23, 2008, at 11:20 AM, Hadriel Kaplan wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Dean Willis
The problem that I'm trying to solve is making the task space
manageable.
The first thing is to distribute the chair load.
Obviously splitting/spawning WG's will do that, but I thought there
was an AD resource contention issue - if we had more WG meeting slots
then neither of our AD's could be in some meeting or other. Is that
not one of the issues? It was the response I got when I and others
suggested SIP Security topics (Identity/Privacy/SIPS/Certs/etc.)
should be split into a separate WG a while back.
There was also some concern over not having any more RAI time slots
anyway, but I think that's a red herring and overlapping some RAI WG
meeting times is reasonable for certain topics.
We can have four new working groups that meet for an hour each, or we
can have one existing WG that meets for four hours. Same meeting time,
same AD conflicts, but four times as many chairs to do the management work.
What we can't have is four new working groups that meet for four hours
each. This means scope creep (and scope inflation) must be rigorously
controlled. Hence, each charter must be tightly constrained, and each WG
narrowly focused.
The fact is that our working groups are so big now that the chairs can't
devote enough time to thoroughly manage individual subjects. So the
chairs aren't offloading enough of the work from the ADs. Doubling the
number of chairs might not cut the ADs load in half, but it could
certainly reduce it, although this is true if and only if the focus of
each WG (and chair) is precise. I can't stay on top of the status of 38
work items that go on for many years. I could probably manage four work
items that last for no more than two years.
I think developing a SIP extension should be a Big Thing. If it's
important enough to develop a SIP extension for, it is probably
important enough to charter a working group to develop that extension.
It's a Really Bad Idea to have a standing working group that sits
around and develops SIP extensions. All that gets us is a whole lot of
extensions. It doesn't get us any closer to a draft standard.
I agree with you in principle, but I doubt it's possible in practice.
There's some fine line there, because if you don't address an
issue/need multiple people have, then they just go solve it in a
proprietary fashion independently and interop still sucks. One
problem is we don't have a single cohesive "group" view and use of
SIP, so we're left with the shotgun extensions approach, seeing which
ones will stick. I can't recall another successful protocol this
complicated that didn't have one or two dominant vendors, which is a
huge disadvantage in some ways. It's both a blessing and a curse.
I expect our "group mind" will continue to exist and evolve. But I'd
like t have our "Do we need this sort of extension" discussions done as
BOFs, with full cognizance of the fact that committing resources to a
new extension is a non-trivial thing. It's far too easy for an eternal
working group to just keep giving itself new tasks and never actually
finish.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
