Subject: Re: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt

From: Adam Roach <[email-masked]>
Date: Mon, 29 Jul 2013 10:54:07 +0200

On 3/24/13 20:06, John-Luc Bakker wrote:
> The FSM is per subscriber's URI. So a subscriber with multiple URIs can have multiple FSMs.

I can't believe the number of times we've had to go over this, but 
that's quite simply not how RFC 3265/RFC 6665 works.

There's an underlying state, associated with the resource to which you 
are subscribing. Your subscription finds out about that state, as 
modified by any relevant filters. I can't fathom what's difficult about 
understanding this model.

I'll repeat the guidance that I provided as private feedback in February 
of 2010: "Another way to examine this problem might be to consider the 
state as being composed of the list of diverted callers. You can age 
entries out, and reset the list when diversion is shut off.... Note that 
this is conceptually similar to what the winfo event package template 
does with its 'waiting' state."

I'm frankly astonished at how thoroughly impervious to feedback this 
document has been. Beyond ignoring expert advice that clearly indicates 
that this is not consistent with the framework that it attempts to use 
(complete with specific suggestions about how to achieve the intended 
goals within that framework), it hasn't even adopted the common-sense 
suggestion that Gao Yang proposed back in late 2010 that we need to 
allow subscription forking. It was neither accepted as a comment nor 
explicitly rebutted.

The authors are accepting neither architectural changes to make the 
overall approach viable, nor minor (and obvious) changes necessary to 
address real-world use cases.

The reason event packages need to go through the IETF is to ensure that 
they receive review, with the implicit assumption that they will be 
shaped by that feedback. I don't see that happening here. I can't 
imagine why we would even consider publishing this document.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jul 2013 22:42:25 +0200

On 3/24/13 8:06 PM, John-Luc Bakker wrote:

> - Paul asked a FSM question: "Is it really the intent that the state machine is affected by the subscriber filter? That seems wrong. That means that a subscription refresh that changes the filter criteria could lose an event.

> Also, is the FSM associated with the subscriber, or with the subscription? (IOW, if the same subscriber has two concurrent subscriptions, does it have two FSMs or one?)"
> [response] The intended use of the event package is to notify a subscriber when a diversion occurs that matches a set of filters provided when subscribing. The FSM is per subscriber's URI. So a subscriber with multiple URIs can have multiple FSMs. Whenever a different (or first) set of rules is received, the FSM (re)starts in IDLE. Each transition in the FSM is caused by the detection of a diversion for the URI. The rules that cause a diversion to happen are different from the rules that cause a notification to happen. No notifications are missed, as long as the notified diversion matches a filter.

ISTM you didn't answer my concern. If the FSM is per subscriber's URI, 
then two subscriptions to the same URI can still result in confusion.

Perhaps you expect a deployment model where this isn't possible. But 
even if so, is it wise to count on that? Will you enforce that?

ISTM that the FSM should be per-subscription. As a result, two different 
subscribers might be notified of the same diversion, and possibly not at 
the same time.

	Thanks,
	Paul

>
> Kind regards,
>
> 	JL
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, March 24, 2013 12:32 PM
> To: John-Luc Bakker
> Cc: [email-masked]
> Subject: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt
>
>
> A new version of I-D, draft-avasarala-dispatch-comm-div-notification-11.txt
> has been successfully submitted by John Luc Bakker and posted to the IETF repository.
>
> Filename:	 draft-avasarala-dispatch-comm-div-notification
> Revision:	 11
> Title:		 A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service
> Creation date:	 2013-03-24
> Group:		 Individual Submission
> Number of pages: 15
> URL:             http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-notification-11.txt
> Status:          http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-div-notification
> Htmlized:        http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-11
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-avasarala-dispatch-comm-div-notification-11
>
> Abstract:
>     3GPP and TISPAN are defining the protocol specification for the
>     Communication Diversion (CDIV) service using IP Multimedia (IM) Core
>     Network (CN) subsystem (IMS) supplementary service.  As part of CDIV,
>     a SIP based event package is used for notifying users about
>     diversions (re-directions or forwarding) of requests for
>     communication sessions targetting the user.  This document defines
>     the SIP event package to support subscription and notification of
>     diversions.  The proposed event package is applicable to the CDIV
>     supplementary service in IMS and may not be applicable to the general
>     internet.
>
>
>
>
> The IETF Secretariat
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jul 2013 22:53:55 +0200

My prior reply was in the context of what the draft is trying to do - 
that even with its assumptions it has problems.

I agree with Adam that 3265/6665 intended that the FSM be associated 
with the resource being subscribed to. As Adam describes below, the FSM 
for that would be quite different.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 30 Jul 2013 14:43:14 -0400 (EDT)

> The intended use of the event package is to notify a
> subscriber when a diversion occurs that matches a set of filters
> provided when subscribing. The FSM is per subscriber's URI. So a
> subscriber with multiple URIs can have multiple FSMs. Whenever a
> different (or first) set of rules is received, the FSM (re)starts in
> IDLE. Each transition in the FSM is caused by the detection of a
> diversion for the URI. The rules that cause a diversion to happen
> are different from the rules that cause a notification to happen. No
> notifications are missed, as long as the notified diversion matches
> a filter.

First, you have to remember that the SIP event notification model does
not directly support "send a NOTIFY whenever X happens".  But I've
written about that before.

You say, "The FSM is per subscriber's URI."  This is treacherous
ground because of how it interacts with the case when a single entity
makes two subscriptions, with each subscription using the same From
address, that is, using the same subscriber's URI.  How do you want
that to work?  (And exactly what definition of equality for
"subscriber's URI" are you using?  For that matter, is the notifier
ensured of seeing the *actual* subscriber's URI in the From header, or
might it get rewritten by some B2BUA somewhere?)

It is considerably safer and closer to the SIP model to say, "The FSM
is per subscription."

Even so, there are probably complications you haven't considered.  For
example, when a diversion is done that does not match the filter, the
FSM may transition from DIVERSION NOTIFIED to DIVERSION NOT NOTIFIED.
But the state of the FSM is *part of the state that is visible to the
subscriber*, and since that changes, the notifier is obligated (RFC
6665) to sent a NOTIFY to inform the subscriber of that.

Dale