[dispatch] Preliminary version of Expert review of draft-avasarala-dispatch-comm-div-notification-03

[Paul Kyzivat <[e-mail]>]

I was requested to do an expert review of
draft-avasarala-dispatch-comm-div-notification-03.txt

Below I have reproduced the requirements from
http://tools.ietf.org/html/draft-peterson-rai-rfc3427bis-04#section-4.1
and the referenced requirements from RFC 3265, and interleaved my 
comments to them.

I did identify a number of issues - more than I expected to.
Most arose from carefully checking compliance to 3265.

I've tagged things that should specifically be fixed with ISSUE and NIT.

	Thanks,
	Paul

>    1.  A Designated Expert (as defined in RFC5226) must review the
>        proposal for applicability to SIP and conformance with these
>        guidelines.  The Designated Expert will send email to the IESG on
>        this determination.  The expert reviewer can cite one or more of
>        the guidelines that have not been followed in his/her opinion.

I'm doing that below.

>    2.  The proposed extension MUST NOT define an event template-package.

It does not.

>    3.  The function of the proposed package MUST NOT overlap with
>        current or planned chartered packages.

I am aware of no chartered work on this subject.
The draft itself has been debated at length on the dispatch wg mailing
list, but with a relatively small number of people actively involved.
Some, including me, have stated that a service resembling the one
proposed might be of general utility. But there have been no volunteers
to do the work of generalizing this. So I conclude that there are
currently no plans for chartered work on such a package.

>    4.  The event package MUST NOT redefine or contradict the normative
>        behavior of SIP events [RFC3265], SIP [RFC3261], or related
>        standards track extensions.  (See Section 4)

I did not identify any issues in this regard.

>    5.  The proposed package MUST NOT undermine SIP security in any
>        sense.  The Internet Draft proposing the new package MUST address
>        security issues in detail as if it were a Standards Track
>        document.  Security issues need to be discussed for arbitrary
>        usage scenarios (including the general Internet case).

The document identifies the specific security issues presented by this
package. It specifies that authentication and authorization must be
done, but leaves the means for authorization out of scope. While a bit
thin, this may be sufficient for the area of applicability.

>    6.  The proposed package MUST be clearly documented in an
>        (Individual) Informational RFC, and registered with IANA. 

The document under review will satisfy this requirement.

>        The package MUST document all the package considerations required
>        in Section 5 of SIP events [RFC3265].

(I believe this guideline has an incorrect reference, and should
reference section *4* of 3265. I'm treating it that way.)

> 4.1. Appropriateness of Usage

In my opinion this is an entirely appropriate use of sip and event packages.

> 4.2. Event Template-packages

N/A - template package not defined.

> 4.3. Amount of State to be Conveyed

> 4.3.1. Complete State Information
> 4.3.2. State Deltas

ISSUE: The document details the notification body, and some inferences
can be drawn about the state from the syntax of the notification body.
But this is tenuous. There should be an explicit specification of the
state maintained, and how it is mapped onto the notification body.

> 4.4. Event Package Responsibilities
> 4.4.1. Event Package Name

OK.

> 4.4.2. Event Package Parameters

ISSUE: There is a section for this, but it repeats the description of
the event package name rather than specifying the (lack of) event
parameters.

This seems to be a simple oversight/typo, but needs to be corrected.

> 4.4.3. SUBSCRIBE Bodies

The document specifies that a body MAY be present.
It then documents the semantics when such body is of type
"application/comm-div-info+xml".


ISSUE: The subscribe body is intended to be used as a filter on which
events/state are reported. The subscribe body contains data to be used
in the filtering process, but the decision process for filtering is not
specified. For instance, both a User-name and a User-URI may be
provided. It is implied, rather than stated, that the User-name field is
matched against the user portion of some URI, whereas the User-URI field
is matched against a complete URI. Also, there are a variety of field
types, and no indication how matches of multiple fields are combined.
(I.e. AND or OR.)

Its possible that all of that is defined by the CDIV service in some IMS
document. If so, rather than a generic reference, there should be
explicit references to that to define where this sort of semantic is
defined.

ISSUE: The document is a bit confusing because the same MIME-type and
XML syntax are used for the subscribe body and the notify body. Yet
there are specific portions of this syntax specific to subscriber bodies
and notify bodies. For instance it isn't clear if the filter information
given in a subscribe body is to be replayed in the notification body.
Nor is there any specification of what should happen if notifier
information is present in the subscribe body.

ISSUE?: Semantics not specified if a body of some other type is present.
This provides an unspecified extensibility hook that could be employed
without any revision to the documented behavior of the package. I'm
uncertain if this is appropriate or not.

> 4.4.4. Subscription Duration
> 
>    It is RECOMMENDED that event packages give a suggested range of times
>    considered reasonable for the duration of a subscription.  Such
>    packages MUST also define a default "Expires" value to be used if
>    none is specified.

No suggested or default value is given, nor is any reason given for not
suggesting a value. Text puts this to the discretion of the subscriber.

ISSUE: The document needs to be revised to provide a default value.

ISSUE: It also needs to either:
- provide a suggested value, or
- give a rationale for why a suggested value is not given

> 4.4.5. NOTIFY Bodies

Syntax is well specified.

Semantics is barely specified.

NIT: diversion-time-info does not specify a time zone, nor does it state
that it is in some specific zone such as UTC. This makes it difficult
for the subscriber to interpret. Perhaps not important if the
notification is delivered when the diversion occurs. But if an initial
subscribe can report a diversion that occurred in the past it could be a
problem. (Perhaps this is a typo - earlier specifications of time
include the zone. But the example shows usage without a zone.)

DISCLAIMER: I'm not qualified to verify the correctness of the XML
schema definition or the XML example.

> 4.4.6. Notifier processing of SUBSCRIBE requests

Nominal but perhaps sufficient.

> 4.4.7. Notifier generation of NOTIFY requests
>
>    This section of an event package describes the process by which the
>    notifier generates and sends a NOTIFY request.  This includes
>    detailed information about what events cause a NOTIFY to be sent,

This is covered.

>    how to compute the state information in the NOTIFY,

ISSUE: The sending of events is not tied directly to the state of the
resource.

ISSUE: Questionable. Document says that the NOTIFY *MAY* contain a body.
But doesn't specify when it does and when it doesn't.

>    how to generate
>    neutral or fake state information to hide authorization delays and
>    decisions from users, and whether state information is complete or
>    deltas for notifications; see section 4.3.  Such a section is
>    required.

ISSUE: The distinction between complete and delta state information is
not addressed, and is ambiguous. Its unclear whether a history of prior
diversions is retained and delivered, or if the state consists solely of
a diversion as it is happening, that then immediately disappears from
state after the notification.

> 4.4.8. Subscriber processing of NOTIFY requests

ISSUE: This section is very thin - it specifies nothing.
Perhaps there are no requirements in this regard.

If the state were better specified, then this section would probably
specify how the state is reconstructed based on the notifications.

> 4.4.9. Handling of forked requests

OK, not permitted.

> 4.4.10.  Rate of notifications

OK - specified.

> 4.4.11.  State Agents

OK - not required or expected.

> 4.4.12.  Examples

ISSUE: The only provided example is a sample of a notification body.
Flow diagrams and message detail, as called out in 3265, would be very
useful.

NIT: Section 8.2 is entitled "Sample Notification Body", but it contains
subsections entitled "Instance of communication diversion subscription
document" and "Instance of communication diversion notification
document". While the latter would be a notification body, the former
would presumably be a subscription body.

I'll observe that the examples suggest that comm-div-subs-info from the
subscribe body is *not* replayed in the notify body. But there is no
normative information about that.

> 4.4.13.  Use of URIs to Retrieve State

OK - not used.

>    7.  If determined by the Designated Expert or the chairs or ADs of
>        the DISPATCH WG, an applicability statement in the Informational
>        RFC MUST clearly document the useful scope of the proposal, and
>        explain its limitations and why it is not suitable for the
>        general use of SIP in the Internet.

The Applicability Statement in the document adequately documents the scope.

ISSUE?: It doesn't explain the limitations, or why the package hasn't
been designed for more general use.