Subject: [Sipping] Review of draft-ietf-sipping-policy-package-01

From: "Mary Barnes" <[email-masked]>
Date: Fri, 25 Aug 2006 21:02:25 -0500

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.   

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP