Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00

[Adam Roach <[e-mail]>]

  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