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
