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

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:20 -0400

Mary,

thanks much for reviewing the draft!
> 
> Section 1:
> - 2nd paragraph, last sentence:  suggest to qualify "the SIP sessions"
> e 
> within reasonable time frame. 
> 
I've added some wording that describes this to Section 3.6.

> Section 3.7
>  -1st paragraph, 2nd sentence: Because remote policy server 
> may be contacted, the techniques listed in the draft might 
> not suffice the authentication/authorization. Mentioning 
> of P-A-ID/AIB/SIP-Identity as a potential way to 
> authenticate a client(subscriber) may be good.
> 
I've completely revised the security section, which should now better
describe the mutual authentication/authorization.

> Section 4
> All the security consideration focuses on UA but 
> with policy server possibly providing policy information 
> of the domain to an outside entity, there is a security 
> consideration surrounding the domain's security as well.
> 
> If no proper security is set for providing policy information 
> to an entity outside of the domain, malicious user can gain 
> access on potential attacking point such as IP/port to use 
> etc. Currently all you need is policy server's URI to gain 
> access to this, as there is no correlation between the request 
> that caused 488 and the SUBSCRIBE request.
> 

The policy server can authenticate and authorize the user agent (as
mentioned, I've overhauled the Security Section). After authenticating a
UA a network provider can decide which policy it wants to send to which
UA. It can, for example, have a policy for known/trusted UAs and
a more restrictive policy to unknown UAs. I'm not sure how correlating
the SUBSCRIBE to a 488 would help in this case.

Thanks!

Volker

_______________________________________________
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

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:20 -0400

Mary,

Thanks!

Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:20 -0400

Mary,

Thanks!

Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:20 -0400

Mary,

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

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

> - OPEN ISSUE: I like the idea of using XML (versus a copy of the SDP)
> and would be curious if anyone has any objections? 
> 
I think there is at least rough consensus that the XML approach is the
right way forward.

> 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. 
> 
I've clarified this and added an example.

> 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.  
> 
I've rewritten this paragraph along the lines of what you've suggested.
The last sentence was an artefact of using SDP in the subscribe/notify
body. I've removed this sentenwith "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]).
> 
Done.

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

> - OPEN ISSUE: I like the idea of using XML (versus a copy of the SDP)
> and would be curious if anyone has any objections? 
> 
I think there is at least rough consensus that the XML approach is the
right way forward.

> 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. 
> 
I've clarified this and added an example.

> 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.  
> 
I've rewritten this paragraph along the lines of what you've suggested.
The last sentence was an artefact of using SDP in the subscribe/notify
body. I've removed this sentenwith "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]).
> 
Done.

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

> - OPEN ISSUE: I like the idea of using XML (versus a copy of the SDP)
> and would be curious if anyone has any objections? 
> 
I think there is at least rough consensus that the XML approach is the
right way forward.

> 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. 
> 
I've clarified this and added an example.

> 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.  
> 
I've rewritten this paragraph along the lines of what you've suggested.
The last sentence was an artefact of using SDP in the subscribe/notify
body. I've removed this sentenwith "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]).
> 
Done.

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

> - OPEN ISSUE: I like the idea of using XML (versus a copy of the SDP)
> and would be curious if anyone has any objections? 
> 
I think there is at least rough consensus that the XML approach is the
right way forward.

> 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. 
> 
I've clarified this and added an example.

> 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.  
> 
I've rewritten this paragraph along the lines of what you've suggested.
The last sentence was an artefact of using SDP in the subscribe/notify
body. I've removed this sentence.

> 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.  
> 
Yes, looking at the examples we had in the scenarios draft should be a
good start for determining which kind of information is needed in such a
document. I'll see if I can submit a revamped version of the scenarios 
draft for the next meeting.

In general, I think the general rule should be disclose what you have.
I.e. a UA should essentially encode what it has in the SDP announcement
and a few extra fields (e.g. request URI, session ID). I really would
not want a situation where policy server and UA start to negotiate what
should be disclosed and what not.

Regarding the more general comment having too few examples, I've added a
number of examples in various place of the draft. Hope this helps to
address this concern.

> Section 3.7: 
> - 3rd paragraph, 1st sentence: "Responding timely..." -> "A timely
> response..."
Done.

> - 3rd paragraph, last sentence: break out that parenthetical statement
> into its own sentence. 
> 
Done.

> Section 3.8:
> - 1st paragraph, last sentence: Here's where a more concrete example
> would be really useful. 

Added two specific examples.

> - 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"?  
> 
I've added an example for that.

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

It should be a MUST. I've also added some text clarifying this.

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

> Section 3.13:
> - 1st paragraph, last sentence: insert "a" between "on" and "transport".
> 
Done.

> - 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.   
> 
Yes, I agree. Since the XML format still needs some work to enable its 
use in SUBSCRIBE bodies, I probably won't be able to add an example for 
this revision but will put this on my to do list.

Thanks!

Volker