Draft:  draft-ietf-sipping-policy-package-01
Reviewer: Mary Barnes
Review Date: 25 Aug 2006
Review Deadline: 25 Aug 2006
Status: Initial review 

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

Section 1:
- 2nd paragraph, last sentence:  suggest to qualify "the SIP sessions" with "all"
OLD:
   Session-independent policies on the other hand are policies that are 
   created independent of a session and generally apply to the SIP sessions 
   set up by a user agent (see [6]).
NEW:
   Session-independent policies on the other hand are policies that are 
   created independent of a session and generally apply to all the SIP sessions 
   set up by a user agent (see [6]).

Section 3.3: 
- 1st paragraph, 3rd & 4th sentences. I found this a bit to confusing to read.   Suggest to precede the last sentence with "However," to link that to the previous sentence. 
OLD:
   In this event package, the Request-URI, the event
   package name and event parameters are not sufficient to determine the
   resource a subscription is for.  With the session description in the
   SUBSCRIBE body, the notifier can generate the requested policy
   decision and create policy events for this resource.
NEW:
   In this event package, the Request-URI, the event
   package name and event parameters are not sufficient to determine the
   resource a subscription is for.  However, with the session description in the
   SUBSCRIBE body, the notifier can generate the requested policy
   decision and create policy events for this resource.

- OPEN ISSUE: I like the idea of using XML (versus a copy of the SDP) and would be curious if anyone has any objections? 

Section 3.4:
- 1st paragraph, 1st sentence: suggest to remove the parenthetical statement and clarify and add the condition(s) under which a subscription MAY be terminated early or add an example.  The current wording of "of course" leaves alot for the reader. 

Section 3.5:
- 4th paragraph, last two sentences. I'm having difficulty seeing how these two sentences relate.  It first mentions that the notifier can't count on a user understanding other format extensions, which is reasonable.  But, I can't see how  that last statement on rationale explaining that a modified format is often returns justifies why the notifier can't count on a user understanding other format extensions.  It would seem to me that the last sentence would fit much better if it were moved after the first sentence. So, I'd propose a rewrite of that paragraph something like the following(keeping the first sentence the same), although, I'm not certain it entirely captures the points you wanted to make either:
OLD:
   If the notifier uses the same format in NOTIFY bodies that was used
   by the subscriber in the SUBSCRIBE body (e.g. "application/
   session-policy+xml"), the notifier can expect that the subscriber
   supports all format extensions that were used in the SUBSCRIBE body.
   However, the notifier cannot assume that the subscriber supports
   other extensions beyond that.  If the notifier uses other format
   extensions, it cannot count on the fact that they will be understood
   by the subscriber.  The rationale behind this is that the notifier
   will often return a modified version of the document that was
   submitted by the subscriber.
NEW:
   If the notifier uses the same format in NOTIFY bodies that was used
   by the subscriber in the SUBSCRIBE body (e.g. "application/
   session-policy+xml"), the notifier can expect that the subscriber
   supports all format extensions that were used in the SUBSCRIBE body.
   The notifier SHOULD NOT assume that the subscriber supports
   other extensions beyond that.  The notifier MAY return a modified 
   version of the document that was submitted by the subscriber. 
   However, if the notifier uses other format extensions, it SHOULD NOT 
   expect that they will be understood by the subscriber.  

Section 3.6:
- OPEN ISSUE: This is a really good and important question.  My initial reaction is yes, we should be able to define at least some basic default examples to justify and validate why this functionaltiy is even useful or needed.  There used to be a scenarios document and I'm wondering if it wouldn't be useful to revamp that.  Overall, I found this document to be extremely abstract and feel that there's a need for some more concrete examples in this document in general.  

Section 3.7: 
- 3rd paragraph, 1st sentence: "Responding timely..." -> "A timely response..."
- 3rd paragraph, last sentence: break out that parenthetical statement into its own sentence. 

Section 3.8:
- 1st paragraph, last sentence: Here's where a more concrete example would be really useful. 
- 3rd paragraph, 3rd sentence: How would the determination be made as to whether a notifier would "expect that the session can be admitted at a later point in time"?  

Section 3.9: 
- 3rd paragraph, 2nd sentence: Could that SHOULD be a MUST?  If not, there should be a statement about the consequences of the subscriber not applying the new policy decision to this session, or least an example of when a subscriber might not want to. 
- 3rd paragraph, 3rd sentence: It's not clear to me why a subscriber would ever need to terminate a session based upon an updated policy. Could you add an example here?  

Section 3.13:
- 1st paragraph, last sentence: insert "a" between "on" and "transport". 
- Example Flow.  It would be really informative to show the detailed XML in terms of understanding the changes that might happen between the SUBSCRIBE and NOTIFY. And also, example for the local and remote.  I know it's tedious, but despite not being normative, examples tend to be really useful for developers to really "get it".  You could borrow the example that is given in section 7 of the media policy dataset document and build from there.