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

["Elwell, John" <[e-mail]>]

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:[e-mail]] 
> Sent: 21 May 2010 08:00
> To: Paul Kyzivat; Elwell, John
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]] 
> Sent: Thursday, May 20, 2010 9:49 PM
> To: Elwell, John
> Cc: Avasarala Ranjit-A20990; [e-mail]; [e-mail]
> 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:[e-mail]]
> >> Sent: 20 May 2010 16:33
> >> To: Avasarala Ranjit-A20990
> >> Cc: Elwell, John; [e-mail]; [e-mail]
> >> 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:[e-mail]]
> >>> Sent: Thursday, May 20, 2010 6:47 PM
> >>> To: Avasarala Ranjit-A20990
> >>> Cc: Elwell, John; [e-mail]; [e-mail]
> >>> 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:[e-mail]]
> >>>> Sent: Thursday, May 20, 2010 12:15 PM
> >>>> To: Avasarala Ranjit-A20990; [e-mail]
> >>>> Cc: [e-mail]
> >>>> 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:[e-mail]]
> >>>>> Sent: 20 May 2010 05:33
> >>>>> To: Elwell, John; [e-mail]
> >>>>> Cc: [e-mail]
> >>>>> 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: [e-mail]
> >> [mailto:[e-mail]] On
> >>>>> Behalf Of Avasarala Ranjit-A20990
> >>>>> Sent: Friday, May 14, 2010 11:49 AM
> >>>>> To: Elwell, John; [e-mail]
> >>>>> 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:[e-mail]]
> >>>>> Sent: Thursday, May 13, 2010 6:25 PM
> >>>>> To: Avasarala Ranjit-A20990; [e-mail]
> >>>>> 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: [e-mail]
> >>>>>> [mailto:[e-mail]] On Behalf Of Avasarala 
> >>>>>> Ranjit-A20990
> >>>>>> Sent: 13 May 2010 11:28
> >>>>>> To: [e-mail]
> >>>>>> 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:[e-mail]]
> >>>>>> Sent: Thursday, May 13, 2010 3:47 PM
> >>>>>> To: Avasarala Ranjit-A20990
> >>>>>> Cc: [e-mail]
> >>>>>> 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
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> >>>>>>
> >>>>> _______________________________________________
> >>>>> dispatch mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/dispatch
> >>>>>
> >>>> _______________________________________________
> >>>> dispatch mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/dispatch
> >>>>
>