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

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 15 Jul 2010 18:36:20 +0800

Hi Mary, John and Paul

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. 

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 other than subscribing to the Call Diversion Notification Information Event package which is already proposed in 3GPP spec 24.604.

Now as per 3GPP's directive, we need to formally standardize the event package in IETF and hence the draft.

So please let us know how we can take this draft forward to a meaningful conclusion.

Thanks

Regards
Ranjit

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, May 21, 2010 7:35 PM
To: Avasarala Ranjit-A20990
Cc: [email-masked]; [email-masked]; DISPATCH
Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00

Ranjit,

John's suggestion is the right approach - that's really the only way this work is going to get traction within DISPATCH.

Regards,
Mary
DISPATCH WG co-chair

On Fri, May 21, 2010 at 3:04 AM, Elwell, John <[email-masked]> wrote:
> Ranjit,
>
> What I would like to see are:
> - statement of requirements (for both barring and diversion);
> - survey of solution space, with pros and cons (e.g., event package(s) 
> as so far described versus other approaches);
> - in case of event package, pros and cons of combining diversion and barring into a single event package.
>
> Getting these fundamental principles established is more important than working on details of an event package.
>
> John
>
>> -----Original Message-----
>> From: Avasarala Ranjit-A20990 [mailto:[email-masked]]
>> Sent: 21 May 2010 08:00
>> To: Paul Kyzivat; Elwell, John
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: [dispatch] FW: New Version 
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>>
>> Hi Paul
>>
>> So what is the consensus? Come up with a requirements I-D and then 
>> continue on the event package?
>>
>> Thanks
>>
>>
>> Regards
>> Ranjit
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email-masked]]
>> Sent: Thursday, May 20, 2010 9:49 PM
>> To: Elwell, John
>> Cc: Avasarala Ranjit-A20990; [email-masked]; [email-masked]
>> Subject: Re: [dispatch] FW: New Version 
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>>
>>
>>
>> Elwell, John wrote:
>> > I too think this work is potentially interesting beyond
>> IMS, and would
>> find it more attractive to combine requirements and have a single 
>> event package.
>> >
>> > Of course, there are other ways of achieving this. There could be 
>> > an
>> HTTP resource that allows me to inspect recent calls that have been 
>> subject to automatic call handling, e.g., by being diverted or barred.
>> Then I could use
>> https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to 
>> be notified of changes to that resource. No SIP standardisation required.
>> It would be interesting to know whether this would solve requirements.
>>
>> I guess this is fundamentally about automatic call handling.
>> Seems like it might be in the scope of BLISS, except I gather BLISS 
>> is winding down.
>>
>>       Thanks,
>>       Paul
>>
>> > John
>> >
>> >> -----Original Message-----
>> >> From: Paul Kyzivat [mailto:[email-masked]]
>> >> Sent: 20 May 2010 16:33
>> >> To: Avasarala Ranjit-A20990
>> >> Cc: Elwell, John; [email-masked]; [email-masked]
>> >> Subject: Re: [dispatch] FW: New Version
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>
>> >>
>> >>
>> >> Avasarala Ranjit-A20990 wrote:
>> >>> Hi Paul
>> >>>
>> >>> No I am not asking for a new WG. I wanted directions to
>> >> take this I-D
>> >>> forward. Like should we merge it with CDIV one as John Elwell was 
>> >>> suggesting or keep this separate - which I think is better.
>> >> Well, with the new operating rules for RAI and DISPATCH,
>> if you want
>> >> this to be worked on by some WG, then we either have to
>> find one to
>> >> recharter to do the work, or else we have to spin up
>> another. I don't
>>
>> >> see any obvious existing one to take on the work.
>> >>
>> >> I *do* think this work is potentially interesting beyond IMS.
>> >> A new WG
>> >> is a *possibility* if the work can be framed in a way that people 
>> >> want to work on. IMO that will mean first defining the
>> requirements,
>> >> without presuming the mechanism. And combining the
>> requirements for
>> >> CDIV and barring would probably make it more attractive.
>> >>
>> >>    Thanks,
>> >>    Paul
>> >>
>> >>> Regards
>> >>> Ranjit
>> >>>
>> >>> -----Original Message-----
>> >>> From: Paul Kyzivat [mailto:[email-masked]]
>> >>> Sent: Thursday, May 20, 2010 6:47 PM
>> >>> To: Avasarala Ranjit-A20990
>> >>> Cc: Elwell, John; [email-masked]; [email-masked]
>> >>> Subject: Re: [dispatch] FW: New Version
>> >>>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>
>> >>>
>> >>>
>> >>> Avasarala Ranjit-A20990 wrote:
>> >>>> Hi
>> >>>>
>> >>>> So is the consensus to proceed forward?
>> >>> Proceed forward in what way? Are you asking for a new WG?
>> >>>
>> >>>   Thanks,
>> >>>   Paul
>> >>>
>> >>>> Regards
>> >>>> Ranjit
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Elwell, John [mailto:[email-masked]]
>> >>>> Sent: Thursday, May 20, 2010 12:15 PM
>> >>>> To: Avasarala Ranjit-A20990; [email-masked]
>> >>>> Cc: [email-masked]
>> >>>> Subject: RE: [dispatch] FW: New Version
>> >>>>
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>> Sorry, I thought I had already responded, but clearly not.
>> >>>>
>> >>>> I am still of the opinion that there is sufficient synergy
>> >> between the
>> >>>> two event packages that they can be combined into a single event 
>> >>>> package. This would have the benefit of being able to have
>> >> a single
>> >>>> subscription to get all information relating to automatic
>> >> handling of
>> >>>> incoming calls, rather than being forced to subscribe
>> >> twice. If you
>> >>>> only want information about diverted calls, or only
>> >> information about
>> >>>> barred calls, you could filter accordingly. If you want
>> different
>> >>>> filtering criteria, or different subscription times for
>> >> the two, there
>> >>>> is nothing to stop you having two separate subscriptions. But we 
>> >>>> should not penalise the simple case by forcing two
>> >> subscriptions where
>> >>>> one would do.
>> >>>>
>> >>>> John
>> >>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Avasarala Ranjit-A20990 [mailto:[email-masked]]
>> >>>>> Sent: 20 May 2010 05:33
>> >>>>> To: Elwell, John; [email-masked]
>> >>>>> Cc: [email-masked]
>> >>>>> Subject: RE: [dispatch] FW: New Version
>> >>>>>
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>>> Hi All
>> >>>>>
>> >>>>> Any further comments on this I-D and suggestions for next steps?
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>>
>> >>>>> Regards
>> >>>>> Ranjit
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: [email-masked]
>> >> [mailto:[email-masked]] On
>> >>>>> Behalf Of Avasarala Ranjit-A20990
>> >>>>> Sent: Friday, May 14, 2010 11:49 AM
>> >>>>> To: Elwell, John; [email-masked]
>> >>>>> Subject: Re: [dispatch] FW: New Version
>> >>>>>
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>>> Hi John
>> >>>>>
>> >>>>> This I-D on communication barring notification talks
>> >> about an event
>> >>>>> package for reporting the notification information of
>> >> communication
>> >>>>> barrings (call blocking) that happen in the network on
>> >> behalf of the
>> >>>>> users.
>> >>>>>
>> >>>>> For e.g if Alice sets a call blocking rule that all calls
>> >> from Bob
>> >>>>> need to be blocked, then the network blocks all calls from Bob 
>> >>>>> towards Alice.
>> >>>>> So here
>> >>>>> The notification information will include the details
>> of the call
>> >>>>> block
>> >>>>> - i.e (1) the identity of caller (Bob) (2) time of block
>> >> (2) reason
>> >>>>> for block, etc
>> >>>>>
>> >>>>> Yes I agree with you that there is synergy between this
>> >> I-D and the
>> >>>>> one on CDIV, since both of them deal with reporting of
>> >> events that
>> >>>>> occur in the network. While CDIV deals with communication
>> >> diversion,
>> >>>>> this one deals with ICB service. Though both the event
>> >> packages are
>> >>>>> similar in terms of subscriptions and format, their
>> execution and
>> >>>>> user preference may vary. So they need to be looked at
>> differently
>>
>> >>>>> and standardized seperately.
>> >>>>>
>> >>>>>
>> >>>>> Regards
>> >>>>> Ranjit
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Elwell, John [mailto:[email-masked]]
>> >>>>> Sent: Thursday, May 13, 2010 6:25 PM
>> >>>>> To: Avasarala Ranjit-A20990; [email-masked]
>> >>>>> Cc: T Satyanarayana-A12694
>> >>>>> Subject: RE: [dispatch] FW: New Version Notification 
>> >>>>> fordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>>>
>> >>>>> Ranjit,
>> >>>>>
>> >>>>> It is not entirely clear to me what the notifications
>> report. For
>> >>>>> example, in 6.7, it says "Typically, it will send
>> >>>>>    one when a communication barring is enacted on behalf of the
>> >>> user."
>> >>>>> What is meant by "enacted" here? Is it when some entity,
>> >> on behalf of
>> >>>>> the user, perhaps through some web page, establishes a
>> >> communication
>> >>>>> barring rule? Or is it when an inbound communication
>> >> arrives and is
>> >>>>> processed in accordance with some pre-existing
>> >> communication barring
>> >>>>> rule? I thought at first it was the former, but I am
>> >> tending towards
>> >>>>> thinking it is the latter. Some clarification would be useful.
>> >>>>>
>> >>>>> Assuming it is the latter, there is obviously some synergy with 
>> >>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with 
>> >>>>> reporting inbound communications that have been subject
>> >> to some rule,
>> >>>>> the rule being conditional on certain criteria such as
>> caller ID.
>> >>>>> Where the conditions are met for a given call to be
>> subject to a
>> >>>>> given
>> >>>>> rule, a notification in accordance with one or the other event 
>> >>>>> package will be triggered. I fail to see the reason for having
>> >> two separate
>> >>>>> event packages, since this means two separate
>> specifications, two
>> >>>>> different subscriptions, two different formats, etc..
>> >>>>>
>> >>>>> John
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: [email-masked] 
>> >>>>>> [mailto:[email-masked]] On Behalf Of Avasarala 
>> >>>>>> Ranjit-A20990
>> >>>>>> Sent: 13 May 2010 11:28
>> >>>>>> To: [email-masked]
>> >>>>>> Cc: T Satyanarayana-A12694
>> >>>>>> Subject: [dispatch] FW: New Version Notification for 
>> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00
>> >>>>>>
>> >>>>>> Hi all
>> >>>>>>
>> >>>>>> I have submitted a new I-D on communication barring
>> notification
>> >>>>>> information based on the following
>> >>>>>>
>> >>>>>> Section 8.2.10 Communication Barring - ICB enhancement
>> >> of dynamic
>> >>>>>> blocking of incoming communications of 3GPP TS 22.173
>> >>>>>>
>> >>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS
>> >> of 3GPP TS
>> >>>>>> 24.611
>> >>>>>>
>> >>>>>> The draft can be accessed from:
>> >>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n
>> >>>>>> otificatio
>> >>>>>> n-00.txt
>> >>>>>>
>> >>>>>> Please review and comment.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>>
>> >>>>>> Regards
>> >>>>>> Ranjit
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>> >>>>>> Sent: Thursday, May 13, 2010 3:47 PM
>> >>>>>> To: Avasarala Ranjit-A20990
>> >>>>>> Cc: [email-masked]
>> >>>>>> Subject: New Version Notification for 
>> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00
>> >>>>>>
>> >>>>>>
>> >>>>>> A new version of I-D,
>> >>>>>>
>> >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been
>> >>>>>> successfully submitted by Ranjit Avasarala and posted to
>> >> the IETF
>> >>>>>> repository.
>> >>>>>>
>> >>>>>> Filename:
>> >> draft-avasarala-dispatch-comm-barring-notification
>> >>>>>> Revision:       00
>> >>>>>> Title:          A Session Initiation Protocol (SIP) Event 
>> >>>>>> Package for Communication Barring Notification Information in
>> support of the
>> >>>>>> Dynamic Incoming Communication Barring (ICB)
>> Notification service
>> >>>>>> Creation_date:  2010-05-13
>> >>>>>> WG ID:          Independent Submission
>> >>>>>> Number_of_pages: 22
>> >>>>>>
>> >>>>>> Abstract:
>> >>>>>> 3GPP is defining the protocol specification for the
>> >> Communication
>> >>>>>> Barring (CB) service using IP Multimedia (IM) Core
>> Network (CN)
>> >>>>>> subsystem supplementary service and more particularly
>> >> the dynamic
>> >>>>>> incoming communication barring service.  As part of dynamic
>> >>>>> incoming
>> >>>>>> communication barring (ICB) service, a SIP based Event package 
>> >>>>>> framework is used for notifying users about
>> >> communication barrings
>> >>>>>> (dynamic and rule based) of their incoming communication
>> >> sessions.
>> >>>>>> This document proposes a new SIP event package for allowing
>> >>>>> users to
>> >>>>>> subscribe to and receive such notifications.  Users can
>> >>>>> further define
>> >>>>>
>> >>>>>> filters to control the rate and content of such notifications.
>> >>>>>> The proposed event package is applicable to the ICB
>> >> supplementary
>> >>>>>> service in IMS and may not be applicable to the
>> general internet.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> The IETF Secretariat.
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> dispatch mailing list
>> >>>>>> [email-masked]
>> >>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> dispatch mailing list
>> >>>>> [email-masked]
>> >>>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>>
>> >>>> _______________________________________________
>> >>>> dispatch mailing list
>> >>>> [email-masked]
>> >>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>
>>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Jul 2010 10:27:30 -0500

> 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 requirement…

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

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 16 Jul 2010 02:10:59 +0800

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:[email-masked]] 
Sent: Thursday, July 15, 2010 8:58 PM
To: Avasarala Ranjit-A20990
Cc: Mary Barnes; DISPATCH
Subject: Re: [dispatch] FW: New Version

  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.

> 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

/a

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 20 Jul 2010 18:39:47 +0800

Hi all

Any comments?? 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

Thanks

Regards
Ranjit

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Thursday, July 15, 2010 8:58 PM
To: Avasarala Ranjit-A20990
Cc: Mary Barnes; DISPATCH
Subject: Re: [dispatch] FW: New Version

/a

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Jul 2010 14:54:02 +0200

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

> Sent: 20 July 2010 11:40
> To: Avasarala Ranjit-A20990; Adam Roach
> Cc: DISPATCH
> Subject: Re: [dispatch] 
> > Now as per 3GPP's directive, we need to formally 
> standardize the event
> package in IETF and hence the draft.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jul 2010 09:03:48 -0400

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

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Jul 2010 09:25:29 -0500

The only comment I have at this point is that I encourage you to go 
back and read more than the first two paragraphs of my previous response.

/a

On 7/20/10 05:39, Jul 20, Avasarala Ranjit-A20990 wrote:
> delivered in a<diversion-reason-info/>  element").
>