Subject: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-barring-notification-00

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 13 May 2010 18:27:45 +0800

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-notificatio
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.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 May 2010 14:54:41 +0200

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 

> 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 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 14 May 2010 14:19:12 +0800

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 

> Communication Barring Notification Information in support of the 
> Dynamic Incoming Communication Barring (ICB) Notification service
> 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.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 20 May 2010 12:32:52 +0800

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

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

Ranjit,

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 May 2010 08:44:31 +0200

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

> From: Avasarala Ranjit-A20990 [mailto:[email-masked]] 
> Sent: 20 May 2010 05:33
> Cc: [email-masked]
> Subject: RE: [dispatch] FW: New Version

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 20 May 2010 16:25:18 +0800

Hi

So is the consensus to proceed forward? 

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

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

> 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.
> - 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
> 
> 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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 08:59:10 -0400

Ranjit,

I just now got the time to look at this draft for the first time.
There is indeed a great deal of similarity between this and the CDIV 
draft in terms of mechanisms, formats, and concepts.

I'm neutral on whether these should be one event package or two. 
(Certainly it *could* be one - perhaps reporting on each incoming call 
together with its outcome, with filters to select the sorts of calls or 
outcomes of interest.)

But because of the similarity, I see most of the same issues with this 
draft as with the CDIV draft.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 09:16:49 -0400

> So is the consensus to proceed forward? 

Proceed forward in what way? Are you asking for a new WG?

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 20 May 2010 22:26:53 +0800

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. 

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

	Thanks,
	Paul

> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 11:33:19 -0400

> 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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 May 2010 18:09:12 +0200

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.

John

> Sent: 20 May 2010 16:33
> [mailto:[email-masked]] On
> > 
> >>>> Filename:	 
> draft-avasarala-dispatch-comm-barring-notification
> >>>> Revision:	 00

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 May 2010 12:19:18 -0400

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

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

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 21 May 2010 15:00:18 +0800

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

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.

	Thanks,
	Paul

>> 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
>>>
>>>>> need to be blocked, then the network blocks all calls from Bob 
>>>>> towards Alice.
>>>>> So here
>>>>> 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
>>>>>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 May 2010 10:04:10 +0200

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 

> Sent: 21 May 2010 08:00
> To: Paul Kyzivat; Elwell, John
> Cc: [email-masked]; [email-masked]
> >>>>> The notification information will include the details 
> of the call 
> >>>>> block
> >>>>> Where the conditions are met for a given call to be 
> subject to a 
> >>>>> given

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 May 2010 08:51:55 -0400

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

---

From: Mary Barnes <[email-masked]>
Date: Fri, 21 May 2010 09:05:11 -0500

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