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

[Paul Kyzivat <[e-mail]>]

Ranjit,

I can't declare consensus for dispatch - I'm just a participant like 
everybody else. The chairs can declare consensus when they think it has 
been achieved. IMO there is as yet no consensus.

I agree with what John stated in his reply to you.

	Thanks,
	Paul

Avasarala Ranjit-A20990 wrote:
> 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
>>>>>
>