Subject: [dispatch] Expert review of draft-avasarala-dispatch-comm-div-notification-04

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Apr 2010 16:29:18 -0400

I was asked to be expert reviewer for this document.
I earlier reviewed version -03, and this is an updated review of -04.
Some of the issues I raised previously have been resolved, but not all.

RFC 5727 calls for me to judge it just like a standards track document, 
and doing so leads to most of the remaining issues. I don't think I have 
raised any fundamentally new issues since the previous pass, though I 
have tried to restate the remaining ones in context of the new document 
and the intermediate discussions we have had.

I continue to think this is mostly a matter of getting the text right, 
rather than altering the fundamental aspects of the proposed package. 
Mostly this is a matter of insufficient text, leaving many ambiguities.

	Thanks,
	Paul

==========================================================================

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

>    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 4 of SIP events [RFC3265].

I will comment on the individual parts of section 4 below:

> 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

This version of the document is improved - it now discusses the 
retention of state about some number of past diversions. But it does not 
discuss *what* state information is captured from a diversion. This is 
*implied* by the specification of the xml document that conveys this 
information in NOTIFY requests.

This is tenuous. There should be an explicit specification of the
state maintained, and how it is mapped onto the notification body.

There is no normative requirement to include this information in the 
document, so I can't insist on it. But without this, it will be 
difficult to adequately address Notifier generation of NOTIFY requests.

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

OK.

> 4.4.2. Event Package Parameters

OK.

> 4.4.3. SUBSCRIBE Bodies

ISSUE: The schema for the body type allows parts of types 
<comm-div-subs-info> and <comm-div-ntfy-info>. It appears that only 
<comm-div-subs-info> should appear in a SUBSCRIBE request, but this is 
not specified.

There should either be text specifying that this part must not be 
present, or else text explaining what is to happen if it is present.

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

OK.

> 4.4.5. NOTIFY Bodies

ISSUE: The schema for the body type allows parts of types 
<comm-div-subs-info> and <comm-div-ntfy-info>. It appears that only 
<comm-div-ntfy-info> should appear in a NOTIFY request, but this is not 
specified.

There should either be text specifying that this part must not be 
present, or else text explaining its significance in a NOTIFY.

> 4.4.6. Notifier processing of SUBSCRIBE requests

ISSUE: There is no text stating that the notifier must retain the 
information from the body of the subscribe for use in generation of 
NOTIFY requests. Since that is certainly required, it should be stated.

ISSUE: There is no specification of what to do if the subscribe body 
contains <comm-div-ntfy-info>. If that's valid, then the behavior should 
be specified. If its not valid, that should have been specified in 4.4.3.

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

ISSUE: the triggers for sending NOTIFY are imprecisely specified.
This is *partially* covered, in that it it states that a NOTIFY will 
"typically" be sent when "a communication diversion is enacted on behalf 
of the user", but the atypical situation is not discussed.  There is 
also "A notifier MAY send a NOTIFY at any time", which appears to be 
inappropriate - apparently the only other time to send such a 
notification is immediately following a SUBSCRIBE request.

ISSUE: There is no discussion of how the body from the SUBSCRIBE request 
affects the decision about when to send NOTIFY requests.

This is too under-specified to be considered complete.

What I would expect to see here is, roughly:

- when a new (or refresh) SUBSCRIBE is received, compute the state
   information in the notify (see below), and send regardless of
   whether it is empty or not.

- when a communication diversion occurs, selected attributes (TBS) of
   the diverted message and the diversion itself are captured and
   saved as new diversion state.

- the addition of this new state may (or may not) result in discarding
   some old state. (Details TBS, related to the value N.)

- for each subscriber, compute the state information in the notify
   (see below). If the resulting body is non-empty, send the NOTIFY.
   If empty, do not send the notify.

>    how to compute the state information in the NOTIFY,

ISSUE: I don't find this information anywhere. While an implementor may 
attempt to infer it from the descriptions of the subscribe and notify 
bodies, that doesn't constitute a specification.

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

I would expect to see a description of how the content of the subscribe 
body is applied to the saved diversion state to format a notify body. 
Also, how to construct the notify body if there is no subscribe body.
Also, the representation of an "empty" body when there is no saved 
diversion state or the subscribe body results in all of the saved 
information being withheld from the subscriber.

>    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: This is not discussed.

AFAICT, there is no need for fake information - this can simply be 
stated. Neutral information is presumably what is sent in a NOTIFY when 
there is no saved diversion state, or all saved state is filtered out by 
the subscribe body. Apparently the intent in that case is for a NOTIFY 
with no body. That should be made clear.

> 4.4.8. Subscriber processing of NOTIFY requests

This section is very thin - it specifies nothing.

But if you want to leave this undefined I won't object, because there 
appear to be no normative requirements.

> 4.4.9. Handling of forked requests

OK, not permitted.

> 4.4.10.  Rate of notifications

OK - specified.

> 4.4.11.  State Agents

Its my understanding that this event package is not intended to employ 
state agents (as that term is defined in RFC 3265). Hence this section 
should simply state that state agents are not used.

> 4.4.12.  Examples

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. Specifically, this document would be improved if it included 
examples of at least:

- initial subscribe when there have been no diversions

- the occurrence of a diversion and the resulting notification
   to existing subscribers.

- another subscription by another subscriber while there is
   retained state from a prior diversion, and the resulting
   notification(s).

- another diversion occurrence, its impact on saved state,
   and on what the existing subscribers receive as notifications.

- a subscription with a filter that screens out some but not all
   of the diversions in the saved state.

Having such examples might have shortened the discussion of this draft 
significantly. But this is not mandatory according to 3265, so I cannot 
require that you provide it.

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 suggest you rename the 
section to be more clear.

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

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 13 Apr 2010 13:42:13 +0800

Hi Paul

My comments <Ranjit>. 

Updated -05 version:
http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-05
.txt

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Tuesday, April 06, 2010 1:59 AM
To: Mary Barnes; Cullen Jennings
Cc: [email-masked]
Subject: [dispatch] Expert review
ofdraft-avasarala-dispatch-comm-div-notification-04

	Thanks,
	Paul

========================================================================
==

I'm doing that below.

It does not.

> 4.1. Appropriateness of Usage

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

This is tenuous. There should be an explicit specification of the state
maintained, and how it is mapped onto the notification body.

<Ranjit>. I have added 2 attributes (1) Number of communication
diversions that occurred till time - N (2) Number of communication
diversion notifications sent to the user till time - M. Both these
attributes would be maintained as part of state information and would be
updated whenever a diversion occurs and a notification is sent. These
attributes get computed every time a diversion occurs and before sending
the notification information. 

OK.

OK.

<Ranjit>. Updated the section in -05 version.

OK.

<Ranjit>. Updated in -05 version of the document.

ISSUE: There is no specification of what to do if the subscribe body
contains <comm-div-ntfy-info>. If that's valid, then the behavior should
be specified. If its not valid, that should have been specified in
4.4.3.

<Ranjit>. Updated the information in -05 version.

<Ranjit>. Updated in -05 version.

<Ranjit>. Updated in -05 version

OK, not permitted.

OK - specified.

<Ranjit>. Updated in -05 version

OK - not used.

>        general use of SIP in the Internet.

The Applicability Statement in the document adequately documents the
scope.

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