Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering

From: "Mary Barnes" <[email-masked]>
Date: Fri, 24 Feb 2006 11:28:40 -0600

Although, I'd love that break, it frightens me to think what would
happen with all the other SDOs that are using SIP and continually
proposing enhancements (that they need right now, by the way).   I would
be very concerned that the industry would be even more fragmented in
those 2 years than it is today. 
 
The reality is that there's a boatload of work to do and there's going
to continue to be a boatload of new requirements coming in regularly for
quite some time.   So, we need an effective way to manage that.   I
think the categorization of the work, regardless of which WG handles it,
is useful, as it does provide a reasonable way for logically dividing up
the work. Another option would be prioritize the existing work based on
WG input (without other SDOs demands that they need it to complete their
written specs having higher priority than folks that need to solve
current real problems).   And, I'll say it again, that some sort of
directorate or adjunct group of folks to help lessen the burden of the
existing WG chairs would be a good thing.  As to another suggestion that
dividing the work into separate WGs lessens the burden for some folks in
terms of not having to attend all the sessions, there are some of us for
whom the expectation is that we follow all the work (despite the fact
that it's a virtually impossible task). 
 
Mary 
Note: I did snip the receiver list a bit as it was getting long. 

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: Friday, February 24, 2006 10:57 AM
	To: 'Michael Hammer (mhammer)'; '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
ofDividingandConquering

	*       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

	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