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

Hi all

Any comments?? 

Regards
Ranjit

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] 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:adam@nostrum.com]
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
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch