Subject: RE: [Sipping] Thoughts on the Principle of Dividing and Conquering

From: "Even, Roni" <[email-masked]>
Date: Fri, 24 Feb 2006 09:43:06 +0200

Dean,

I support this principal and think that in general the idea is good. I
see the point of enabling WG chairs to focus on more specific topics and
helping progress the work between the IETF meetings. Currently it looks
to me that there is no lack of subjects to work (number of active
drafts) but lack of time to cover and progress all of them. 
I am not sure about the split you mentioned but at least a SIPUSE
working group makes sense. 
I think that we also need SIP applications WG (some of the topics are in
the SIPUSE list you gave) like we have today in XCON and SIMPLE.

Roni Even 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 2:31 AM
To: [email-masked] List; Sipping List
Cc: Cullen Jennings; Jon Peterson; Allison Mankin
Subject: [Sipping] Thoughts on the Principle of Dividing and Conquering

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

_______________________________________________
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

_______________________________________________
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: "Michael Slavitch" <[email-masked]>
Date: Fri, 24 Feb 2006 09:36:01 -0500

Given the growth of SIP, a look at how the W3 has grown and matured may
well be a good idea.

It is amazing what you can accomplish if you do not care who gets the
credit. 
 
- Harry S Truman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: February 24, 2006 5:37 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] Thoughts on the Principle of Dividing and Conquering

Dean,

(It seems we are creating the SIP Engineering Task Force (SPTF)... We
already know that the S in SIP certainly does not stand for "Simple",
but perhaps we should consider replacing "Session" with "Standards":
"SIP is a mechnism that allows people to initiate and manage Working
Groups and oher Standardization efforts mainly in the IETF, but also in
other organizations such as but not limited to OMA, 3GPP, 3GPP2, ETSI,
ATIS and MSF" :-) 

Seriously speaking, I support your idea in general. Here are some more
specific points:
- The most important improvent from my point of view would be the
separation of "major new work" from "small extensions and maintenance".
Currently, getting small, sometimes niche, extensions through the
process seems to be taking too long, and that is creating some
frustration. ("Implementing this takes two days, but getting this
standardized in the IETF will take 2 years".) Of course, it is still
important to review that the new things won't break the existing ones
etc.
- Having more time in the meetings is always good, although it seems we
already have at the IETF something related to SIP at every slot... 
- With a lot of people having worked with SIP in the IETF for many years
(forewver?), there should be many quite capable WG chairs available.
- With the RAI area established, we have the higher level structure
already in place for this type of move.

Markus

> From: ext Dean Willis [mailto:[email-masked]]
> Sent: 24 February, 2006 02:31
> Subject: [Sip] Thoughts on the Principle of Dividing and Conquering
> 
> 
> 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.
> 
> requirements and (as per RFC 3427) extensions without requirements for

> backward compatibility.
> 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 new developments on the application of sip
> 

_______________________________________________
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

-- 

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Feb 2006 11:56:16 -0600

On Feb 24, 2006, at 7:25 AM, Henry Sinnreich wrote:

> Dean,
>
> This is good initiative, but where would you put P2P SIP?
>

In its own working group, as it is a reasonably encapsulated aspect  
of SIP, just as SIMPLE and XCON and ECRIT are.

I would suggest doing the same for other large but reasonably  
encapsulated aspects as they become foci of attention.

--
Dean