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

From: <[email-masked]>
Date: Thu, 2 Nov 2006 01:15:59 -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
> 
> 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.
[[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. 

> 
> 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.
[[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 
 
> 
> -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

_______________________________________________
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