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

[Paul Kyzivat <[e-mail]>]

I've already said my piece more than once. I've nothing new to say.

	Thanks,
	Paul

Avasarala Ranjit-A20990 wrote:
> 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
>