Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering

From: Avshalom Houri <[email-masked]>
Date: Mon, 27 Feb 2006 09:33:31 +0200

If we look at SIP and compare it to TCP or other basic protocol, the main 
difference that I see that
the base protocol of SIP never got really stable. Some new features that 
we are working on
are features that have an effect into the protocol itself. Examples are 
GRUU and security.

Although the amount of attention and the amount of work that people will 
be doing will influence a lot
and hence the suggestions to restructure the group, I think that the main 
issue we have is if we can define
what will consist as the base protocol and we will not be extending the 
base protocol in the years to come
the same way we have a stability in TCP.

Maybe the key issue here is to define layers and SIP and make sure that 
base layers will be stable enough
so new extensions will not change them. I really wish to see SIP as a base 
protocol like TCP or HTTP and
have the ability to define extensions and usages in many unrelated groups. 
Imagine what would have happened
if we would have still defined TCP in the way we are doing now for SIP 
where new features influence the base
protocol and have dependency on each other.

Is there something inherent in SIP that will prevent us from freezing a 
base protocol while enabling the creation
of many extensions in an independent way? If this is the case then we will 
shortly reach a point where any new
extension to SIP will take years or have we reached that point?

Thanks
--Avshalom

Cullen Jennings <[email-masked]> 
27-02-06 08:18 AM

To
"[email-masked]" <[email-masked]>, sipping <[email-masked]>
cc
Jon Peterson <[email-masked]>, Allison Mankin <[email-masked]>
Subject
Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand 
Conquering

I have written replies to this thread several times - then deleted them 
:-)
It's a hard topic and certainly one that Jon, Allison and I were 
discussing
before this thread. We have talked about it in relation to this thread. We
will no doubt be talking about it for some time to come. Below are some
questions I have been asking myself. They are really a random stream of
conscious. I don't really want answers to them all but if they trigger 
some
thoughts on concrete ideas we can that will help. That is great. I am
clearly still in the stage of listening to ideas.

Are the chairs the bottleneck that limits the rate? Are the ADs? How can 
we
transfer responsibility from the ADs to chairs?

Is the bottleneck to do with the rate that authors update drafts? Is if 
the
bottleneck to do with the rate that comments are provided on the mailing
lists? Can having a directorate get this done faster?

Can we expand the amount of total work being done or can we only move it
around? Do we need more people writing the same number of documents? Can 
we
get new people? How much can we move work around from one topic to 
another?
Will people work on a document they don't care about? why?

I hear lots about what documents should be going faster but what documents
should be slowed down? Are there whole WGs or topics that we should slow
down to zero? There is a large amount of consensus on what document are
critical to get done soon. That's surprising. Why? Can we take advantage 
of
that somehow?

What's stopping you from getting your drafts done? Is it just time to work
on them? Do you need people to review them? Are they held up on other 
work?
What's stopping you from reviewing the drafts you think are important and
sending comments? What's stopping you from forcing the the drafts you want
finished to get done?

If you logically split some WG in two (trying to logical group related 
thing
in each halt), then scheduled them concurrently, would you get twice as 
much
work done or nothing done because everyone who was not there objected to 
any
decision made? 

The ADs for the RAI WGs right now are Jon and Allison but I've certainly
been doing a lot of thinking about this. Let me make a few observations:

I would want any change to have some reasonably good chance to make more
than a trivial impact.

Mostly people work on what they want work on -  they vote with their feet.
This is a feature not a bug and much better than the alternative. People
will work on stuff they don't care about but only to a limited degree.

Once things get past WGLC, perhaps Chairs and ADs could be faster but this
would not really accelerate things in a huge way. Still worth working on 
but
less clear it can make a huge impact.

Having Chairs carefully hound people to work on all the documents that few
people care about might only speed up that work at the expense of stuff 
that
is critical. I suspect that for the critical stuff, more hounding is good
but there may be a limit.

If we think that the sipping chairs are the bottleneck, well 
hypothetically,
we could add another 5 people to the chair list. It's an interesting 
thought
experiment to compare this to adding more groups. I can see several 
problems
with this. Many of the same problems happen by having more working groups.

Working groups could have an impact far greater than just more chairs. 
They
allow us to partition time to certain classes of problems - effectively 
one
class per working group - this might help or might not.  It might result 
in
a tool to speed up some classes of problems while slowing down others. I
think it is reasonably clear that XCON and SIMPLE forking from SIPPING was 
a
good thing. Selecting the right level of decomposition is always a 
balancing
act. 

If you look at the other IETF directorates, they focus on a particular
problem (such as XML, or MIB doctor) and thus can have a handful or two of
people. What would we want a directorate here to do? Are we thinking of it
as people that could take on an particular draft and help it accelerate it
getting done? Would a directorate help this? I believe it might. Jon and I
have been talking about this. Could we achieve the same thing some other
ways? Would a directorate turn into a group that occasionally went for a
nice dinner but did not do much else? I sort of like the directorate idea
but I have just not figured out how to get one or more directorates 
focused
enough to help. 

I have toyed with the idea of asking everyone to periodically focus some
fraction of their energy on one key draft for a short period of time and 
try
and get it done. By scheduling these out in time a bit, we might be able 
to
deal with the complain of people not being able to schedule time for when
drafts they care about need work. Would this work or be useless? Would it
turn out being more or less the same thing as WGLC? Should we try and 
track
the expected schedule for WGLCs across RAI?

We have some problems where the solution must intrinsically be entangled
across several RAI WGs. Would spending meeting time in a cross RAI meeting
help with these? 

The energy barrier of new work is low. The energy barrier of finishing 
even
simple work is very high.

Some of the biggest things I can think of are already underway. The protos
makes it so that chairs can do much of what only ADs could do previously.
This is good. The formation of RAI allows the ADs to focus more.

Anyways, don't read too much into anything I said here other than I'm glad
to hear about ideas. In the end, the bulk of the work is done by 
volunteers
that read drafts, provide ideas and comments, and write the drafts - it 
the
people that count. 

Cullen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 27 Feb 2006 08:44:33 -0500

Avshalom,

I disagree that any of the work we're doing is changing the base 
protocol. Everything is an extension to SIP, not a change to it. Some of 
them are important (like sip-outbound) and some of them seem like 
commonly needed functions, but all add new functionality. The way to 
figure out whether something is really changing the base spec is if you 
have something that needs Require or Proxy-Require in every message sent 
by a client. draft-ietf-sip-guidelines recognizes that such extensions 
are effectively changes to sip.

Thanks,
Jonathan R.

Avshalom Houri wrote:
> 
> If we look at SIP and compare it to TCP or other basic protocol, the 
> main difference that I see that
> and hence the suggestions to restructure the group, I think that the 
> main issue we have is if we can define
> so new extensions will not change them. I really wish to see SIP as a 
> base protocol like TCP or HTTP and
> have the ability to define extensions and usages in many unrelated 
> groups. Imagine what would have happened
> of many extensions in an independent way? If this is the case then we 
> will shortly reach a point where any new
> *Cullen Jennings <[email-masked]>*
> 
> 27-02-06 08:18 AM
> 
> 	
> To
> I have written replies to this thread several times - then deleted them :-)
> It's a hard topic and certainly one that Jon, Allison and I were discussing
> conscious. I don't really want answers to them all but if they trigger some
> Are the chairs the bottleneck that limits the rate? Are the ADs? How can we
> Is the bottleneck to do with the rate that authors update drafts? Is if the
> around? Do we need more people writing the same number of documents? Can we
> get new people? How much can we move work around from one topic to another?
> critical to get done soon. That's surprising. Why? Can we take advantage of
> that somehow?
> 
> on them? Do you need people to review them? Are they held up on other work?
> If you logically split some WG in two (trying to logical group related thing
> in each halt), then scheduled them concurrently, would you get twice as much
> work done or nothing done because everyone who was not there objected to any
> decision made?
> 
> would not really accelerate things in a huge way. Still worth working on but
> people care about might only speed up that work at the expense of stuff that
> If we think that the sipping chairs are the bottleneck, well hypothetically,
> we could add another 5 people to the chair list. It's an interesting thought
> experiment to compare this to adding more groups. I can see several problems
> Working groups could have an impact far greater than just more chairs. They
> allow us to partition time to certain classes of problems - effectively one
> class per working group - this might help or might not.  It might result in
> think it is reasonably clear that XCON and SIMPLE forking from SIPPING was a
> good thing. Selecting the right level of decomposition is always a balancing
> act.
> 
> but I have just not figured out how to get one or more directorates focused
> enough to help.
> 
> fraction of their energy on one key draft for a short period of time and try
> and get it done. By scheduling these out in time a bit, we might be able to
> turn out being more or less the same thing as WGLC? Should we try and track
> The energy barrier of new work is low. The energy barrier of finishing even
> to hear about ideas. In the end, the bulk of the work is done by volunteers
> that read drafts, provide ideas and comments, and write the drafts - it the
> people that count.
> 
> Cullen
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for new developments of core SIP

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com