Re: [dispatch] draft-avasarala-dispatch-comm-div-notification-05

["Elwell, John" <[e-mail]>]

Ranjit,

It would help if the requirements were contributed to the IETF in the usual manner. However, I managed to locate the section you referenced, and it seems that a specific SIP event package is not the only way that these requirements could be satisfied. The IETF needs to understand the requirements and determine what is the best solution, bearing in mind that others, not just 3GPP, may find a solution to these requirements of value.

John

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Avasarala 
> Ranjit-A20990
> Sent: 20 July 2010 11:40
> To: Avasarala Ranjit-A20990; Adam Roach
> Cc: DISPATCH
> Subject: Re: [dispatch] 
> draft-avasarala-dispatch-comm-div-notification-05
> 
> Hi all
> 
> Any comments?? 
> 
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Avasarala Ranjit-A20990
> Sent: Thursday, July 15, 2010 11:41 PM
> To: Adam Roach
> Cc: DISPATCH
> Subject: Re: [dispatch]
> draft-avasarala-dispatch-comm-div-notification-05
> 
> Hi Adam
> 
> No Adam we have not jumped into Stage 3 without stage 1 analysis. In
> Stage 1 spec 22.173 Section 8.2.7.2 Communication Diversion 
> Notification
> Enhancements talks of specific enhancements required for the
> Communication Diversion Notification and lists the parameters 
> that could
> be part of the notification information. It also further 
> talks about the
> trigger for initiating communication diversion notification 
> information
> messages towards the subscriber. It finally lists all the 
> elements that
> can be part of the Communication Diversion Notification Information.  
> 
> So the section 8.2.7.2 of 22.173 should qualify to mention 
> "what" we are
> trying to accomplish and the spec 24.604 describes the CDIVN 
> service in
> detail and also proposes the required XML schema for the CDIVN XML
> package. 
> 
> So as mentioned in section 8.2.7.1, the problem is a need for a
> mechanism for the subscribers to be notified of communication
> diversions. So in addition to the regular CFX services, as a service
> provider option, the subscribers are also provided with an option to
> subscribe to communication diversion notification service 
> that will help
> them to receive notifications of their call diversions.
> 
> Thanks
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]]
> Sent: Thursday, July 15, 2010 8:58 PM
> To: Avasarala Ranjit-A20990
> Cc: Mary Barnes; DISPATCH
> Subject: Re: [dispatch] FW: New Version
> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
> 
> 
>   On 7/15/10 5:36 AM, Avasarala Ranjit-A20990 wrote:
> > After further thought, we feel that since the CDIV service 
> is already
> standardized in 3GPP specifications 24.604 (Section 4.10.1.1) 
> and hence
> there is no need for explicitly stating the requirements of a CDIV
> service again in a separate I-D or document.
> 
> The problem is that section 4.10.1.1 of 24.604 isn't a statement of
> requirements. It's a high-level sketch of a solution to an 
> unstated set
> of requirements. And section 4.10.2 of that same document is
> presumptuous enough to even define an XML Schema for use in this
> solution.
> 
> In 3GPP language, you've jumped into stage 2 and stage 3 
> design without
> the stage 1 analysis.
> 
> In the past, what has worked well for extensions to IETF protocols is
> when 3GPP does the stage 1 work, and then collaborates with 
> the IETF to
> define a solution that satisfies both parties.
> 
> I agree with John, Paul, and Mary -- if this work is to proceed, it
> really needs to back up to base principles: *what* are you trying to
> accomplish, not *how* do you want to accomplish it? The distinction is
> that the answer is to "what are you trying to accomplish" is 
> phrased in
> terms of use cases ("a user receives real-time information about the
> calls he has missed"), not behavior ("the reason for diversion is
> delivered in a <diversion-reason-info/> element").
> 
> > Also regarding any existing mechanisms, we feel there is/are no 
> > existing mechansim(s) for getting notifications of a 
> particular call 
> > diversion service for a particular subscriber
> 
> I think you misread John's proposal. He didn't ask for you to consider
> other existing solutions -- he asked you to talk about the potential
> solution space. Some of the feedback you've already received 
> covers some
> of this space (e.g. information is published using HTTP, and users
> discover changes using draft-roach-sip-http-subscribe).
> 
> > Now as per 3GPP's directive, we need to formally 
> standardize the event
> package in IETF and hence the draft.
> 
> If you want people to help you work on your event package -- 
> as that is
> presumably why you're bringing it to DISPATCH -- then you 
> need to bring
> us a problem to work on, not a complete solution to publish.
> 
> > So please let us know how we can take this draft forward to a
> meaningful conclusion.
> 
> I think you've been told several times already. What I'm 
> inferring from
> your asking again is that you don't like the answer. I'm 
> afraid there's
> not much that can be done about that.
> 
> /a
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>