Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 24 Feb 2006 11:19:58 -0500

Oh, this is starting to sound scary.
 
N SIP WGs x M IETF SIP-related groups x P non-IETF SIP-related groups =
Who's on First?  
(Abbott and Costello reference)
 
We will need a SIP WG just to manage the liaisons for each pair of
groups.
 
BTW, how do we clone Dean? :)
 
If this is really just an administrative issue.  Could not the WG just
have extra multiple secretaries to help manage each sub-category of
drafts?
 
Mike

________________________________

	From: Avshalom Houri [mailto:[email-masked]] 
	Sent: Friday, February 24, 2006 7:53 AM
	To: Dean Willis
	Cc: Cullen Jennings (fluffy); [email-masked] List; Sipping List;
Jon Peterson; Allison Mankin
	Subject: [Sipping] Re: [Sip] Thoughts on the Principle of
Dividing andConquering

	I do think that a step in this direction is very necessary. 
	We will have to finalize the details as: 
	
	* How this relates to SPEERMINT and to P2P-SIP? 
	
	* A lot of very SIP related work is done MIDCOM, MMUSIC, IPTEL,
ENUM, XCON, BEHAVE and 
	probably more groups. How the SIP related work will fit into the
new framework? 
	
	* The SIP work in the IETF has become so big and very connected
with other standard organizations 
	that we really need to think about all the issues and there may
be a need to a deeper change as 
	creating a sub organization in the IETF for SIP that will meet
in other dates (maybe collocated with other 
	organization meetings from time to time as 3GPP and OMA. This
way we may have much more time to deal 
	with the necessary issues. 
	
	Maybe we should have a BOF at the Dallas IETF for this? Although
I am not sure we will have 
	a big enough room or it will be easy to chair such a meeting. :)

	--Avshalom 
	
	Dean Willis <[email-masked]> wrote on 24-02-2006
02:30:44 AM:
	
	> I've been working on SIP and SIPPING and P2P-SIP agendas this
week,  
	> and that started me thinking.
	> 
	> We spun up SIPPING to take some of the load off of SIP, and in
doing  
	> so tried to more narrowly-define the charters of both SIP and
SIPPING  
	> relative to the previous SIP charter.
	> 
	> When we started talking about P2P-SIP, we thought about
bringing in  
	> the topic as part of SIPPING, but fairly quickly rejected that
idea  
	> because it was clearly partitionable.
	> 
	> This started me thinking -- could we further apply this
principle of  
	> partitioning?
	> 
	> Both SIP and SIPPING have grown into multi-year monsters, each
with  
	> large charters and the need for multiple long-sessions at each
IETF.  
	> They're tricky to chair, require lots of secretarial work, and
are  
	> chronically late on deliverables (in large part because the
chairs  
	> are acting like ADs instead of chairs). SPPING, once viewed as
the  
	> kidney of SIP, now needs its own dialysis.
	> 
	> Perhaps if we were to split these two working groups into
three or  
	> four working groups that have much more clearly defined
missions and  
	> scopes, we could cut them down to one meeting slot each. And
if we  
	> were to have separate management (chairs and secretaries) for
each  
	> working group, we could better manage the groups to timely
delivery.
	> 
	> So I'd like to toss out some ideas on how we might subdivide,
and see  
	> how you folks feel about this. I think the key to any success
here  
	> would be in scope management.
	> 
	> What if we had the following groups:
	> 
	> 1) SIPEM  -- SIP Extended Maintenance
	> 
	> 2) SIPNEW -- New major functionality for SIP
	> 
	> 3) SIPREQ -- Analysis of requirements raised by new
applications or  
	> SDO liaison
	> 
	> 4) SIPUSE -- Using SIP to meet specific application
requirements
	> 
	> 
	> 
	> Here's how we might divide the work:
	> 
	> 
	> SIPEM
	> -----
	> 
	> Scope: Maintenance of SIP 2.0 and development (as per RFC
3427) of  
	> backward-compatible extensions driven by applications with
near-term  
	> deployment scenarios.
	> 
	> Initial Milestone Tasks of SIPEM:
	> 
	> 1)  Developing a SIP Guidebook, roughly the equivalent of the
TCP  
	> Roadmap, that defines what's "in" SIP and how the pieces fit
together.
	> 
	> 2)  GRUU
	> 
	> 3)  Outbound
	> 
	> 4)  Target-Dialog
	> 
	> 5)  Certificate Usage
	> 
	> 6)  Location Transport
	> 
	> 7)  Loop Error Correction
	> 
	> 8)  Connected Party Identity
	> 
	> 9)  Hop Limit Diagnostics
	> 
	> 10) TLS Usage
	> 
	> 11) Answering Modes
	> 
	> 12) Connection Reuse
	> 
	> 13) Rejection of Anonymous Requests
	> 
	> 14) Consent Mechanism
	> 
	> 
	> 
	> SIPNEW
	> ------
	> 
	> Scope: Enhancement and evolution of SIP including
architectural-level  
	> requirements and (as per RFC 3427) extensions without
requirements  
	> for backward compatibility.
	> 
	> 
	> Initial milestone tasks of SIPNEW
	> 
	> 1)  Developing a "future roadmap" for the evolution of SIP
	> 
	> 2)  Solving the RFC 3261 Routing Problem
	> 
	> 3)  Use of SAML with SIP
	> 
	> 4)  Response Identity
	> 
	> 5)  Response Authentication
	> 
	> 6)  End to Middle Requests
	> 
	> 
	> 
	> SIPREQ
	> ------
	> 
	> Scope: Analysis of requirements raised by new applications of
SIP in  
	> IETF or in external SDOs (as per RFC 3427). Development of  
	> requirements for changes to SIP or for usage guides in
response to  
	> applications requirements. Another way of wording this would
be  
	> "problem definition".
	> 
	> Initial milestones and tasks of SIPREQ:
	> 
	> 1)  Session Policy Requirements
	> 
	> 
	> 
	> SIPUSE
	> ------
	> 
	> Scope: Guidance on how to use existing SIP specifications and

	> mechanisms including examples, call flows, test cases, error  
	> avoidance, and so on. Review (as per RFC 3427) of SIP Event
Packages.
	> 
	> 
	> Initial milestones and tasks for SIPUSE:
	> 
	> 1)  Service Examples
	> 
	> 2)  Security Examples
	> 
	> 3)  Race Condition Examples
	> 
	> 4)  Session media policy mechanism
	> 
	> 5)  Session policy package mechanism
	> 
	> 6)  Service quality reporting mechanism
	> 
	> 7)  URI List mechanism
	> 
	> 8)  Subscriptions to Ad-Hoc Resource Lists mechanism
	> 
	> 9)  Multiple REFER mechanism
	> 
	> 10) Ad-Hoc Conferencing using URI lists mechanism
	> 
	> 11) Call Control Transfer mechanism
	> 
	> 12) Configuration Delivery mechanism
	> 
	> 13) Emergency Calling using SIP (SOS) mechanism
	> 
	> 
	> 
	> 
	> Note that I'm not entirely happy with the division of SIPPING
into  
	> SIPUSE and SIPREQ. While it seems like we spend a lot of time
in  
	> SIPPING debating requirements, there are currently a lot of  
	> deliverables in this category.
	> 
	> 
	> --
	> Dean
	> 
	> _______________________________________________
	> 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

_______________________________________________
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 questions on current sip
Use [email-masked] for new developments of core SIP

---

From: <[email-masked]>
Date: Fri, 24 Feb 2006 17:56:59 +0100

*       Could not the WG just have extra multiple secretaries to help manage
each sub-category of drafts? 

If we take a look at the huge volume of output recorded at
http://rfc3261.net/, we could also come to the contrarian alternative: 

Take a break for a couple of years, so the industry can catch up with all
the SIP standards work and that the reality in deployment should separate
the generally useful standards from those that are more limited in scope.

Hint: Finalize only ICE and P2P SIP before taking the break.

Thanks, Henry 

  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 5:20 PM
To: Avshalom Houri; Dean Willis
Cc: Cullen Jennings (fluffy); [email-masked]; Sipping List; Jon Peterson;
Allison Mankin
Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of
DividingandConquering

We will need a SIP WG just to manage the liaisons for each pair of groups.

If this is really just an administrative issue.  Could not the WG just have
extra multiple secretaries to help manage each sub-category of drafts?

Mike

  _____  

From: Avshalom Houri [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 7:53 AM
To: Dean Willis
Cc: Cullen Jennings (fluffy); [email-masked] List; Sipping List; Jon Peterson;
Allison Mankin
Subject: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing
andConquering

* A lot of very SIP related work is done MIDCOM, MMUSIC, IPTEL, ENUM, XCON,
BEHAVE and 
probably more groups. How the SIP related work will fit into the new
framework? 

* The SIP work in the IETF has become so big and very connected with other
standard organizations 
that we really need to think about all the issues and there may be a need to
a deeper change as 
creating a sub organization in the IETF for SIP that will meet in other
dates (maybe collocated with other 
organization meetings from time to time as 3GPP and OMA. This way we may
have much more time to deal 
with the necessary issues. 

Maybe we should have a BOF at the Dallas IETF for this? Although I am not
sure we will have 
a big enough room or it will be easy to chair such a meeting. :) 

--Avshalom 

Dean Willis <[email-masked]> wrote on 24-02-2006 02:30:44 AM:

> I've been working on SIP and SIPPING and P2P-SIP agendas this week,  
> We spun up SIPPING to take some of the load off of SIP, and in doing  
> so tried to more narrowly-define the charters of both SIP and SIPPING  
> When we started talking about P2P-SIP, we thought about bringing in  
> the topic as part of SIPPING, but fairly quickly rejected that idea  
> This started me thinking -- could we further apply this principle of  
> partitioning?
> 
> Both SIP and SIPPING have grown into multi-year monsters, each with  
> large charters and the need for multiple long-sessions at each IETF.  
> They're tricky to chair, require lots of secretarial work, and are  
> chronically late on deliverables (in large part because the chairs  
> are acting like ADs instead of chairs). SPPING, once viewed as the  
> Perhaps if we were to split these two working groups into three or  
> four working groups that have much more clearly defined missions and  
> scopes, we could cut them down to one meeting slot each. And if we  
> were to have separate management (chairs and secretaries) for each  
> working group, we could better manage the groups to timely delivery.
> 
> So I'd like to toss out some ideas on how we might subdivide, and see  
> how you folks feel about this. I think the key to any success here  
> 3) SIPREQ -- Analysis of requirements raised by new applications or  
> SDO liaison
> 
> 4) SIPUSE -- Using SIP to meet specific application requirements
> 
> 
> 
> Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of  
> backward-compatible extensions driven by applications with near-term  
> deployment scenarios.
> 
> 1)  Developing a SIP Guidebook, roughly the equivalent of the TCP  
> Roadmap, that defines what's "in" SIP and how the pieces fit together.
> 
> 2)  GRUU
> 
> 3)  Outbound
> 
> 4)  Target-Dialog
> 
> 5)  Certificate Usage
> 
> 6)  Location Transport
> 
> 7)  Loop Error Correction
> 
> Scope: Enhancement and evolution of SIP including architectural-level  
> requirements and (as per RFC 3427) extensions without requirements  
> Scope: Analysis of requirements raised by new applications of SIP in  
> requirements for changes to SIP or for usage guides in response to  
> applications requirements. Another way of wording this would be  
> "problem definition".
> 
> avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages.
> 
> 
> Note that I'm not entirely happy with the division of SIPPING into  
> SIPUSE and SIPREQ. While it seems like we spend a lot of time in  
> Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Feb 2006 12:12:27 -0600

On Feb 24, 2006, at 10:19 AM, Michael Hammer ((mhammer)) wrote:

>
> If this is really just an administrative issue.  Could not the WG  
> just have extra multiple secretaries to help manage each sub- 
> category of drafts?
>

Of course, a couple of uber-chairs with a bunch of under-chairs is in  
IETF speak called an "area", which has "area directors" for oversight  
and "working groups chairs" and "working groups" for each sub- 
category of draft.

The main challenge is cleanly defined sub-categories, which is a  
large part of what I'm trying to figure out here.

--
Dean