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
<john.elwell@siemens-enterprise.com> 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:ranjit@motorola.com]
>> Sent: 21 May 2010 08:00
>> To: Paul Kyzivat; Elwell, John
>> Cc: dispatch@ietf.org; R.Jesske@telekom.de
>> 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:pkyzivat@cisco.com]
>> Sent: Thursday, May 20, 2010 9:49 PM
>> To: Elwell, John
>> Cc: Avasarala Ranjit-A20990; dispatch@ietf.org; R.Jesske@telekom.de
>> 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:pkyzivat@cisco.com]
>> >> Sent: 20 May 2010 16:33
>> >> To: Avasarala Ranjit-A20990
>> >> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de
>> >> 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:pkyzivat@cisco.com]
>> >>> Sent: Thursday, May 20, 2010 6:47 PM
>> >>> To: Avasarala Ranjit-A20990
>> >>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de
>> >>> 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:john.elwell@siemens-enterprise.com]
>> >>>> Sent: Thursday, May 20, 2010 12:15 PM
>> >>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org
>> >>>> Cc: R.Jesske@telekom.de
>> >>>> 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:ranjit@motorola.com]
>> >>>>> Sent: 20 May 2010 05:33
>> >>>>> To: Elwell, John; dispatch@ietf.org
>> >>>>> Cc: R.Jesske@telekom.de
>> >>>>> 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: dispatch-bounces@ietf.org
>> >> [mailto:dispatch-bounces@ietf.org] On
>> >>>>> Behalf Of Avasarala Ranjit-A20990
>> >>>>> Sent: Friday, May 14, 2010 11:49 AM
>> >>>>> To: Elwell, John; dispatch@ietf.org
>> >>>>> 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:john.elwell@siemens-enterprise.com]
>> >>>>> Sent: Thursday, May 13, 2010 6:25 PM
>> >>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org
>> >>>>> 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: dispatch-bounces@ietf.org
>> >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala
>> >>>>>> Ranjit-A20990
>> >>>>>> Sent: 13 May 2010 11:28
>> >>>>>> To: dispatch@ietf.org
>> >>>>>> 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:idsubmission@ietf.org]
>> >>>>>> Sent: Thursday, May 13, 2010 3:47 PM
>> >>>>>> To: Avasarala Ranjit-A20990
>> >>>>>> Cc: r.jesske@telekom.de
>> >>>>>> 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
>> >>>>>> dispatch@ietf.org
>> >>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> dispatch mailing list
>> >>>>> dispatch@ietf.org
>> >>>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>>
>> >>>> _______________________________________________
>> >>>> dispatch mailing list
>> >>>> dispatch@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>