Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03]

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2010 15:45:50 -0500

inline...

Avasarala Ranjit-A20990 wrote:

> I'm still a little confused here.
> If phone is on and subscription is active, then in general notification
> should be possible, regardless of registration. I realize IMS doesn't
> permit that, but from a general standard perspective we shouldn't assume
> it. The manifestation in this case is that the NOTIFY would fail and the
> subscription would eventually be torn down.
> 
> So I think the cases are:
> - there is a subscription and notification works
> - there is a subscription but notification fails
> - there is no subscription.
> 
> <Ranjit-Feb26-2> Agreed. Actually instead of calling it as Notification
> fails, we can say - not sending notification due to (1) no match of
> filter criteria (2) phone not registered or outside coverage area due to
> which there is no connectivity and hence notification cannot be sent 
> Anyway if no subscription, no notification. 

Are you suggesting that you might have a subscription, and have the 
filter criteria met, and yet not attempt to send a NOTIFY because the 
phone is not registered or has no network connectivity???

That seems wrong. ISTM that either you would remove the subscription, or 
else you would try to send the NOTIFY and then discover that it fails.

OTOH, this probably ought not to be within scope of what is discussed in 
this draft.

>> [3] in the example u suggested where sip:[email-masked] with two
>> contacts: sip:[email-masked] and 
>> sip:[email-masked] and
>>     both the phones ring, then it would be a case of parallel forking.
>> Now say one or both the phones have set diversion rules, to divert the
> 
> In this case, what does it mean for "one or both phones have set
> diversion rules"? Does that somehow imply distinct rules for each phone?
> 
> I don't see how that could work. Aren't the diversion rules for the
> *AOR*?
> 
> <Ranjit-Feb26-2> Yes the diversion rules are for AoR. So when there is a
> diversion rule set for the AoR and when diversions occur, the
> notifications are
> Sent to the AoR.

Not sent to the AoR - sent to the remote contact of the dialog for each 
subscription to the AoR. Same point as below that you agreed with.

> I see they could be set/changed from either phone. But its a single set
> of rules isn't it? So I might set the rules from the office, and then
> cancel them from home.
> 
> <Ranjit-Feb26-2> yes single set and could be set from either of the
> phones. True.
> 
>> call to say 
>>     sip:[email-masked], then the notifications would get 
>> generated with respect to both the contacts.
> 
> Again I'm confused by the terminology you use, and how it relates
> operationally. The diversion happens on the AOR, and the subscriptions
> are on the AOR, and the notifications are sent to the subscribers. I
> don't see where the registered contacts enter into the picture at all.
> 
> <Ranjit-Feb26-2> Ya agree with you on this. Sorry for the confusion.
> 
> If you have something else in mind, I hope you can explain it better in
> the draft.
> 
>> [4] Yes the value of N is configurable and depends on how many 
>> diversions the subscribe wants to keep or could be dependent on server
> 
>> policy (some maximum
>>     number). If the server policy is to send notifications as and when
> 
>> they occur and not keep any divsersions information, then the value of
> 
>> last N
>>     diversions will be zero. But if the server chooses to retain the 
>> last diversion always, then the value of N will be 1 and so on.
> 
> All is straightforward for N>=1.
> 
> For N=0 things are messy. If we are modeling this as state, and
> notifications are about state changes, then the new diversion is added
> to the (previously empty) state and that triggers notifications to all
> current subscriptions. Then if you don't want to retain even this much
> state (because N=0) you immediately remove that version from the state. 
> But that is again a state change, so you end up with another
> notification of that state change.
> 
> <Ranjit-Feb26-2> True. Actually the notifications are for informing the
> subscriber of the call diversions that happen. The notifications are not
> for informing the subscriber of state changes in the notifier or the
> number of diversions that occurred. As I mentioned in the abstract as
> well as 24.604, the main intent of CDIVN service is to inform the
> subscribers of communication diversions that occur on their behalf in
> the network and this information will help them manage their rules
> better. 

I am not certain, but think we may still be talking past one another to 
some extent.

The state can be considered just a formalism for defining the service 
clearly, regardless of whether it has intrinsic value to the CDIV 
service. But it *is* a formalism. So if it is introduced, then its 
behavior can't be ignored when inconvenient. Defining the state with N=0 
leads to some undesired behavior. The simplest way around that is to 
insist that N be >=1.

If its important to you that no state be retained once a notification 
has been sent about the most recent diversion, then you will have to 
find some other way to specify the service, that still meets the 
expectations of 3265. I don't know if there is anything there that Adam 
would consider valid. We will have to get his opinion on that.

	Thanks,
	Paul

> <Ranjit-Feb26-2> But if we want to include the information related to
> how many diversions have happened till time (say from 12 AM ) till the
> time the notification is being sent, then as you say we can store the
> diversions. This would be useful when the subscriber specifies in the
> filter criteria to send notifications only during certain time like
> between 5 and 6 PM and not whenever a diversion occurs. Then N is grater
> than 1.

> I presume you don't want that behavior. If you can live with N>=1 then
> we don't have the problem at all. If you need to support N=0 and don't
> want the extra notify, then we have to figure out if there is some trick
> to how things are modeled to get the desired effect. I've suggested
> something previously, but Adam didn't like it.
> 
> This needs sorting out.
> 
> 	Thanks,
> 	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 01 Mar 2010 16:53:13 -0600

On 3/1/10 14:45, Mar 1, Paul Kyzivat wrote:
> That seems wrong.

It seems wrong because it is wrong. If the terminal cannot be reached, 
the subscription goes away.

/a

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 2 Mar 2010 12:39:21 +0800

Inline

<Ranjit-Mar2> 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2010 2:16 AM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review
ofdraft-avasarala-dispatch-comm-div-notification-03]

inline...

Avasarala Ranjit-A20990 wrote:

> If phone is on and subscription is active, then in general 
> notification should be possible, regardless of registration. I realize

> IMS doesn't permit that, but from a general standard perspective we 
> shouldn't assume it. The manifestation in this case is that the NOTIFY

> would fail and the subscription would eventually be torn down.
> 
> <Ranjit-Feb26-2> Agreed. Actually instead of calling it as 
> Notification fails, we can say - not sending notification due to (1) 
> no match of filter criteria (2) phone not registered or outside 
> coverage area due to which there is no connectivity and hence 
> notification cannot be sent Anyway if no subscription, no
notification.

<Ranjit-Mar2> yes the subscription could be removed when the device is
not reachable. 

<Ranjit-Mar2> yes true not within the scope of this draft.

> <Ranjit-Feb26-2> Yes the diversion rules are for AoR. So when there is

> a diversion rule set for the AoR and when diversions occur, the 
> notifications are Sent to the AoR.

<Ranjit-Mar2> Yes agree with u. 

> I see they could be set/changed from either phone. But its a single 
> set of rules isn't it? So I might set the rules from the office, and 
> then cancel them from home.
> 

> If you have something else in mind, I hope you can explain it better 
> in the draft.
> 

> <Ranjit-Feb26-2> True. Actually the notifications are for informing 
> the subscriber of the call diversions that happen. The notifications 
> are not for informing the subscriber of state changes in the notifier 
> or the number of diversions that occurred. As I mentioned in the 
> abstract as well as 24.604, the main intent of CDIVN service is to 
> inform the subscribers of communication diversions that occur on their

> behalf in the network and this information will help them manage their

> rules better.

<Ranjit-Mar2> Ok in that case we can say that value of N >=1 and the
notifier has always maintains history of last diversion at a minimu. It
can maintain more than 1 too depending on the policy. 

<Ranjit-Mar2> In that case I am OK maintaining the hostory of diversions
that occurred as part of state information and retaining that state even
after the notification for that diversion is sent - so that in case I do
not get a confirmation, I would be able to re-send the notification.
Also maintaining state of diversions would help when the notifications
need to sent only at a particular time (if fikter criteria mentions it).

	Thanks,
	Paul

> between 5 and 6 PM and not whenever a diversion occurs. Then N is 
> grater than 1.

> want the extra notify, then we have to figure out if there is some 
> trick to how things are modeled to get the desired effect. I've 
> suggested something previously, but Adam didn't like it.
> 
> This needs sorting out.
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 08:48:44 -0500

I think this all sounds good now.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 3 Mar 2010 00:55:56 +0800

Ok will incorporate all the comments we discussed so far in the updated
version (-04) 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2010 7:19 PM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

	Thanks,
	Paul

Avasarala Ranjit-A20990 wrote:
> That seems wrong. ISTM that either you would remove the subscription, 
> or else you would try to send the NOTIFY and then discover that it
fails.

> not reachable.
> 
> OTOH, this probably ought not to be within scope of what is discussed 
> in this draft.
> 
> Not sent to the AoR - sent to the remote contact of the dialog for 
> each subscription to the AoR. Same point as below that you agreed
with.
>>> diversions the subscribe wants to keep or could be dependent on 
>>> server policy (some maximum
>>>     number). If the server policy is to send notifications as and 
>>> when they occur and not keep any divsersions information, then the 
>>> value of last N

> I am not certain, but think we may still be talking past one another 
> to some extent.
> 
> behavior can't be ignored when inconvenient. Defining the state with 
> N=0 leads to some undesired behavior. The simplest way around that is 
> to insist that N be >=1.
> 
> notifier has always maintains history of last diversion at a minimu. 
> It can maintain more than 1 too depending on the policy.
> 
> expectations of 3265. I don't know if there is anything there that 
> Adam would consider valid. We will have to get his opinion on that.
> 
> <Ranjit-Mar2> In that case I am OK maintaining the hostory of 
> diversions that occurred as part of state information and retaining 
> that state even after the notification for that diversion is sent - so

> that in case I do not get a confirmation, I would be able to re-send
the notification.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 12 Mar 2010 02:10:42 +0800

Hi All

I am not able to upload the updated version (-04) of the I-D due to some
issue with the I-D submission tool - (Says I can submit I-D only on
2010-03-22).
Until then I am attaching a copy of the updated version (txt and html
formats).

Please review and comment.

Thanks

Note: Let me know if there is any other way to upload the I-D document
and will be happy to do it.

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2010 7:19 PM
To: Avasarala Ranjit-A20990
Cc: Anders Kristensen; Adam Roach; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

	Thanks,
	Paul

fails.

with.

the notification.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 16 Mar 2010 12:59:01 +0200

Hi Ranjit,

there is a blackout period before IETF meetings in which one cannot
submit drafts. Please, submit this version as soon as the blackout
period is over and have Paul have a look at it so that he can confirm he
is happy with it.

Thanks,

Gonzalo

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 23 Mar 2010 01:22:42 +0800

Hi Gonzalo, Paul 

I have uploaded the updated version of the I-D. 
It can be accessed from:
http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-04
.txt

Please review and comment

Thanks

Regards
Ranjit

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Tuesday, March 16, 2010 4:29 PM
To: Avasarala Ranjit-A20990
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

Hi Ranjit,

Thanks,

Gonzalo

On 11/03/2010 8:10 PM, Avasarala Ranjit-A20990 wrote:
> Hi All
> 
> I am not able to upload the updated version (-04) of the I-D due to 
> some issue with the I-D submission tool - (Says I can submit I-D only 
> on 2010-03-22).

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 30 Mar 2010 18:09:59 +0800

Hi All

Any update on this I-D?

Thanks 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Avasarala Ranjit-A20990
Sent: Monday, March 22, 2010 10:53 PM
To: Gonzalo Camarillo
Cc: [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminaryversion ofExpert review
ofdraft-avasarala-dispatch-comm-div-notification-03]

Hi Gonzalo, Paul 

Thanks

Regards
Ranjit

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Tuesday, March 16, 2010 4:29 PM
To: Avasarala Ranjit-A20990
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review

Hi Ranjit,

Thanks,

Gonzalo

>>> suggested something previously, but Adam didn't like it.

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Mar 2010 10:43:57 -0400

Ranjit,

Sorry! I was busy last week at ietf.
I will try to get to it this week.

	Paul