Draft: draft-ietf-sipping-policy-package-01
Reviewer: Bob Penfield
Review Date: August 26, 2006
Review Deadline: August 25, 2006
Status: Initial review

Summary: This draft is on the right track but has open issues,
         described in the review.

[Technical] Correlation of policy decision and INVITE request

 These are really a general comments on the whole set of session
 policy documents. The session-specific policy documents talk about
 including only session description information. However, I believe
 that additional information from the SIP signaling needs to be
 included in order for this to work. The existing framework and event
 package may support this, but there is no discussion of how it would
 work. There are a couple of reasons for this:

 1. In order to verify that the policy server was properly contacted
    and that the policy server did actually authorize the session, the
    proxy and policy server would need to share data in order to
    correlate the INVITE with the policy decision. Thus the policy
    server would need to receive the dialog identifying information,
    or the policy decision would need to include some sort of token
    that was included in the INVITE to correlate the request with
    policy decision.

 2. When a media intermediary needs to be included, the routing
    decision made by the proxy could affect which media intermediary
    is chosen. This would require that the request target be disclosed
    to the policy server, or that the proxy include some sort of token
    or cookie in a (non-cacheable) policy-server URI that it passes
    back to the UA.

[Technical] In Section 3.3, it says:

   A SUBSCRIBE for the session-specific policy package SHOULD contain a
   body that describes a SIP session.

 Should this be a MUST? Under what circumstances would it be valid to
 not include a body in the SUBSCRIBE?

[Technical] Open Issue in Section 3.3 on page 5

 Is this still an open issue? I think using XML is the right
 choice. Much of the text in the open issue should be retained since
 it provides the motivation for choosing XML over SDP.

[Technical] On page 5, section 3.3, it says:

   When the remote description becomes available, the subscriber
   SHOULD refresh the subscription by sending another SUBSCRIBE
   request, which then contains the local and the remote session
   description.  The subscriber MAY skip sending the remote session
   description to the notifier if it has received a NOTIFY with the
   "local-only" parameter.  A notifier will typically include this
   parameter in a NOTIFY when it has received the local session
   description and does not need to see the remote session
   description.

 Suggest the following wording since the remote session description
 should not be included if the notifier indicated that it is not
 needed:

   When the remote description becomes available, the subscriber
   SHOULD refresh the subscription by sending another SUBSCRIBE
   request, which then contains the local and the remote session
   description, unless the subscriber received a NOTIFY with the
   "local-only" parameter indicating that it does not need to see the
   remote session description.

 Alternatively, change "MAY skip sending" to "SHOULD NOT send"

[Technical] On page 9, section 3.9, it says:

   However, the subscriber MAY still keep up the subscription to
   session-specific policies for this session since the policy
   decision may change and the session may be admitted at a later
   time.

 Why would the subscription kept alive if the session cannon be
 initiated?  Does this mean that the subscriber might change the
 session description and try again? Wouldn't that be done more or less
 immediately? Shouldn't the subscriber terminate the subscription if
 it aborts the session initiation?

[Technical] On page 9, section 3.9, it says:

   If the subscriber receives a NOTIFY that contains the "local-only"
   event parameter, it MAY stop inserting the remote session
   description in SUBSCRIBE requests within this subscription.  It MAY
   skip refreshing the subscription in order to convey information
   about the remote session description to the notifier.

 Being consistent with my prior comments, the subscriber SHOULD NOT
 include the remote description when the notifier has indicated that
 it is not needed. Suggest changing to:

   If the subscriber receives a NOTIFY that contains the "local-only"
   event parameter, it SHOULD NOT include the remote session
   description in subsequent SUBSCRIBE requests within this
   subscription.

[Editorial] Introduction

 The Intro seems a bit wordy and repetitive. For example, there are at
 least three places where it talks about a user agent disclosing the
 session information to the policy server. I think it needs to be more
 concise.

[Editorial] on page 8, in section 3.7, it says:

   However, subscriptions may also be established by applications and
   automata (e.g. a conference server).

 I don't think that "and automata" adds anything to this sentence. How
 is it different than "applications"?

[Editorial] on page 8, in section 3.7, it says:

   Responding timely to a SUBSCRIBE request is crucial for this event
   package.

 Suggest "Responding in a timely manner to ..." or "Timely responses to ..."