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

From: Atle Monrad <[email-masked]>
Date: Mon, 29 Jul 2013 08:11:17 +0000

All

This draft is a 3GPP dependency that has been around for long time.

I hope this version is acceptable and can go forward.

thanks
/atle

________________________________ 

Atle Monrad
3GPP CT Chairman

Group Function Technology – Standardization and Technical Regulation 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 13. juli 2013 01:40
To: John-Luc Bakker; Ranjit Avasarala; John-Luc Bakker
Subject: New Version Notification for draft-avasarala-dispatch-comm-div-notification-12.txt

A new version of I-D, draft-avasarala-dispatch-comm-div-notification-12.txt
has been successfully submitted by John Luc Bakker and posted to the IETF repository.

Filename:        draft-avasarala-dispatch-comm-div-notification
Revision:        12
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-07-13
Group:           Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-notification-12.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-12
Diff:            http://www.ietf.org/rfcdiff?url2=draft-avasarala-dispatch-comm-div-notification-12

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

---

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

I admit that I've not read this document thoroughly, but it does seem
that Adam's criticisms are relevant.  The document is also rough in a
number of places, but that can be addressed after the structural
problems are fixed.

In regard to what SIP events *are*, the key is to remember that they
are mis-named.  NOTIFYs do not tell the subscriber of *events* but of
changes in a *state value*.  Thus SIP events can only be used to
observe data which can be modeled as a state value (which pertains to
the "resource" to which the SUBSCRIBE was addressed).  Every
definition of a SIP event package has to make explicit what the state
value is.

What I've just said is vague and philosophical, but it can be made
concrete by asking this question:  What is the body of the NOTIFY that
is returned when a SUBSCRIBE is processed by the notifier?  That body
is the *current* state value at the moment that the SUBSCRIBE is
processed.  (Additionally, the notifier produces further NOTIFYs
whenever the state value changes.)

I note that this draft does not (as far as I could tell) answer the
question, What is the body of the NOTIFY that is returned when a
SUBSCRIBE is processed by the notifier?  Section 6.7 says, "A notifier
sends a NOTIFY request when a communication diversion is enacted on
behalf of the user."  But of course, receiving a SUBSCRIBE to create a
subscription, or a re-SUBSCRIBE to refresh a subscription, is not
"when a communication diversion is enacted".  Nonetheless, a NOTIFY
must be sent at those times (RFC 6665).

In regard to this draft, there are many ways this problem can be
fixed.  A simple one would be to have the state value be the
description of the *last* diversion done on behalf of subscribed-to
user.  You can see that that change would provide a definite state
value, and the state value would change every time a diversion was
done.

Constructing the state value in a way that suits your purposes might
require some work, but with some care, state values and filters can be
constructed that handle situations that do not at the outset seem to
fall within the SIP event framework.  (E.g., RFC 6910.)

I do not understand the purpose of section 6.11.  It describes a state
machine whose purpose is unclear.  Is this useful information for the
subscriber?  And it is mis-placed, as this FSM has nothing to do with
"state agents" in the sense of RFC 6665.

In regard to forking of SUBSCRIBE requests, more thought needs to be
applied.  It is very tempting to say "It would take extra work to
handle forked SUBSCRIBE requests and we don't need it."  But history
has shown that often forking of SUBSCRIBE requests must be supported
to make things work.  The draft should describe how to handle the
commonest cases:

- A SUBSCRIBE request is forked and two forks arrive at one notifier.
  Usually this is handled by rejecting all but one fork with 482 Loop
  Detected errors.

- A SUBSCRIBE request is forked and two forks arrive at different
  notifiers.  The subscriber receives two NOTIFYs from different
  notifiers, establishing two subscriptions.  In most cases, the
  subscriber needs to maintain both subscriptions and integrate the
  information received from them.  In some cases, it is certain that
  one subscription will provide all information that the subscriber
  needs, so it can terminate all but one subscription.  But if so,
  there should be a clear explanation of why this is acceptable.

- A subscriber establishes a subscription to the resource, and later
  sends a new SUBSCRIBE (different dialog) to the same resource.  This
  may happen because the subscriber has lost record of the first
  subscription (and it has not yet timed out at the notifier) or
  because the subscriber is executing a second operation that needs
  the same information.  Generally, two such subscriptions should be
  maintained independently, but in some cases that is undesirable.  In
  the latter case, the reasons it is undesirable need to be explained
  and the procedures for resolving the situation need to be
  described.  (RFC 6910 has an example of this.)

Dale