Subject: [Sipping] comments on draft-schubert-sipping-wg-analyzed-00

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 16:36:45 -0500

Thanks for putting this together. Its always good to see real numbers to 
help understand a problem.

My main question is how these trends compare to other working groups in 
the IETF. I think that might tell us a lot.

You make an interesting observation here:

9.  Room for improvements?

    Although SIPPING was initially formed to filter work going into SIP
    WG for SIP WG to better address the drafts that are of interests of
    SIP WG, looking at the figures above it may be now SIP WG that needs
    to take back some of the task it delegated to SIPPING WG.  Here are
    some questions we may want to consider and its reasoning.

I would argue that the more logical conclusion is that the sipping WG 
needs to reject more work than it is right now. That is what will really 
make it a filtering function.

-Jonathan R.
-- 
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

_______________________________________________
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: "Shida" <[email-masked]>
Date: Wed, 1 Nov 2006 23:45:26 -0800

Hi Jonathan;

 Thanks for your review, my comments inline..

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 1:37 PM
> To: IETF Sipping List
> Subject: [Sipping] comments on draft-schubert-sipping-wg-analyzed-00
> 
[[Shida]] 
 Any suggestions? I was thinking of possibly comparing it to SIP WG to 
see if the suggestion I made below would be feasible and possibly 
SIMPLE WG, which span off from SIPPING/SIP that may show us the 
benefit of distributing the focus. 

> make it a filtering function.
[[Shida]] 
 Sure.. I don't disagree, but you do need to see that SIPPING focuses on 
very vast scope and with having people with different focuses and
expectations 
from the WG in the room, it's hard to reject work that some people think 
is uninterested while others in the room think its important. 

 Possible solution may be to take a step that SIP took when it span-off 
SIPPING, which is to narrow the focus so WG can work more efficiently (As 
Dean suggested before or at the IETF 65..). 
As far as I can see SIPPING currently looks at:

 1. Requirements for service, security and new functions that 
    results in new SIP extension.(RFC4484, RFC4245 etc.)
 2. Requirements form different SDOs.(OMA, 3GPP, TISPAN etc.)
 3. Guidelines trying to clarify issues that are arising in the 
    actual deployments. (dialogusage etc.).
 4. Guidelines on how SIP simply works.(RFC3665:basic-call-flows etc.)
 5. Frameworks.
     > There are two categories; 
      > framework which will contribute in helping new services emerge.
        - consent-fw / uri-list services
      > framework which tries to help SIP work flawlessly in the actually 
        deployment. 
        - config-fw / session-policies
 6. Interwork related items(RFC3398,RFC3372 etc.).
 7. Test spec(RFC4475 etc.)
 8. New event packages.(rtcp-summary, kpml etc.)
 9. BCP.(A bit different from 3 and 4 as BCP tries to lay out the 
    best way to accomplish a task among various way of accomplishing 
    the same tasks. > nat-scenario, v6-transition etc.
 10. Analysis of possible issues. (sbc-funcs etc.)
 11. Bug fixes.(loop-fix, max-breadth etc.)

 * There are probably more but what I have above are what comes to 
    my mind right now..

 Regards
  Shida