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

From: Volker Hilt <[email-masked]>
Date: Fri, 13 Oct 2006 23:41:14 -0400

Mary,

thanks for your comments and for reviewing the draft! Responses to
your comments are inline.
> 
> Section 4.4.2, 1st paragraph, last sentence.  It mentions that "The UAC
> SHOULD contact the cached local policy server URI when creating a new
> INVITE or UPDATE
> request, before they are sent."   I'm wondering if this shouldn't be a
> MUST or the conditions and consequences for when it would be okay to not
> contact the cached local policy should be stated. 
> 
I think it should remain a SHOULD since, e.g., a very simple UA could
decide not to cache these URI. The consequences are that the policy
server URI would have to be transmitted in a 488 response for each new
dialog, creating more signaling overhead. I've done a larger revision on
this section based on Bob's comments. The section now also explains
these consequences.

> Section 4.4.4, 3rd paragraph, last sentence.  Can that SHOULD be changed
> to a MUST?   Otherwise, the consequences of not removing that policy
> server URI should be described.
> 
I've added a sentence explaining the consequences of not removing the URI.

> Editorial nits:
> ---------------
> 
> General:  Add figure #s and appropriate figure references for the flows.
> 
Done.
>  
> Abstract:
> - I would suggest combining the 2nd and 3rd sentences into a more
> definitive statement about what the functionality in this document.
> 
> OLD:
>   However, there is currently no standard mechanism by which a proxy can
> define 
>   or influence policies on sessions such as the codecs or media types to
>   be used.  This document specifies a framework for SIP session
>   policies that provides this capability to proxies. 
> 
> NEW:
>   This document specifies a framework for SIP session
>   policies that provides a standard mechanism by which a proxy can
> define 
>   or influence policies on sessions, such as the codecs or media types
> to
>   be used. 
> 
Done.

> - It might also be useful to highlight the new protocolFrom [email-masked] Fri Oct 13 23:43:09 2006
Date: Fri, 13 Oct 2006 23:41:14 -0400
From: Volker Hilt <[email-masked]>
To: Mary Barnes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [Sipping] Re: Review of
	draft-ietf-sipping-session-policy-framework-01

Mary,

thanks for your comments and for reviewing the draft! Responses to
your comments are inline.
> 
> Section 4.4.2, 1st paragraph, last sentence.  It mentions that "The UAC
> SHOULD contact the cached local policy server URI when creating a new
> INVITE or UPDATE
> request, before they are sent."   I'm wondering if this shouldn't be a
> MUST or the conditions and consequences for when it would be okay to not
> contact the cached local policy should be stated. 
> 
I think it should remain a SHOULD since, e.g., a very simple UA could
decide not to cache these URI. The consequences are that the policy
server URI would have to be transmitted in a 488 response for each new
dialog, creating more signaling overhead. I've done a larger revision on
this section based on Bob's comments. The section now also explains
these consequences.

> Section 4.4.4, 3rd paragraph, last sentence.  Can that SHOULD be changed
> to a MUST?   Otherwise, the consequences of not removing that policy
> server URI should be described.
> 
I've added a sentence explaining the consequences of not removing the URI.

> Editorial nits:
> ---------------
> 
> General:  Add figure #s and appropriate figure references for the flows.
> 
Done.
>  
> Abstract:
> - I would suggest combining the 2nd and 3rd sentences into a more
> definitive statement about what the functionality in this document.
> 
> OLD:
>   However, there is currently no standard mechanism by which a proxy can
> define 
>   or influence policies on sessions such as the codecs or media types to
>   be used.  This document specifies a framework for SIP session
>   policies that provides this capability to proxies. 
> 
> NEW:
>   This document specifies a framework for SIP session
>   policies that provides a standard mechanism by which a proxy can
> define 
>   or influence policies on sessions, such as the codecs or media types
> to
>   be used. 
> 
Done.

> - It might also be useful to highlight the new protocol mechanisms in
> the abstract. 
> 
Done.

> Section 1:
> - 6th paragraph, 1st sentence: I would suggest adding "all" to qualify
> "the SIP sessions":
> 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.
> 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.
> 
Done.

> Section 3: 
> - 1st sentence: I would suggest adding "all" to qualify "the sessions":
> OLD:
>    Session-independent policies are policies that are created
>    independent of a session and generally apply to the sessions a user
>    agent is setting up. 
> 
> NEW:
>    Session-independent policies are policies that are created
>    independent of a session and generally apply to all the sessions a
> user
>    agent is setting up. 
> 
Done.

> - 2nd sentence: I would suggest changing "the sessions" to "any
> sessions":
> OLD:
>    They typically remain stable for a longer period of time and apply 
>    to the sessions set up while they are valid.
> NEW: 
>    They typically remain stable for a longer period of time and apply 
>    to any sessions set up while they are valid.
> 
Done.

> Section 3.2:
> - 2nd paragraph, 3rd sentence: the use of the semi-colon doesn't make
> sense.  Should that be replaced with "and"?  
> 
I've split this up into two sentences.

> Section 4.2:
> - 2nd paragraph, 3rd sentence: remove the text in parenthesis (2
> occurences) and
> insert commas:
> OLD: 
>    It enables the use of separate encryption mechanisms on the signaling
> path (to
>    secure the communication between endpoints) and on the policy channel
>    (to secure the communication between endpoint and policy server).
> NEW:
>    It enables the use of separate encryption mechanisms on the signaling
> path to
>    secure the communication between endpoints, and on the policy channel
>    to secure the communication between endpoint and policy server.   
> 
Done.

> Section 4.4.3:
> - 1st paragraph, 1st sentence: change lowercase "may" to uppercase "MAY"
> 
This may describes something that the UAS can receive in a message
therefore I would think it should not be normative here.

> Section 5, Security Considerations:
> - 4th paragraph, 1st sentence.  Suggest to change the lower case should
> to SHOULD. 
> 
Done.

> - 5th paragraph, 2nd sentence, insert "a" in the sentence.  
> OLD:
>    An attacker can use this mechanism to refer a UA to compromised
> policy server.
> NEW:
>    An attacker can use this mechanism to refer a UA to a compromised
> policy 
>    server.                             
> 
Done.

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, 13 Oct 2006 23:41:10 -0400

Bob,

> 
> [ISSUE-1] Dependence on Config Framework documents
> 
> On Page 6, Section 3.2: It says:
> 
>   A UA compliant to this specification MUST support the User Agent
>   Profile Data Set for Media Policy [3] and the Schema for SIP User
>   Agent Profile Data Sets [8].
> 
> This MUST makes [8] (draft-petrie-sipping-profile-datasets-03) a
> normative reference. That document is not (yet?) a working group
> document and has also expired. What is the plan for [8]?
> 
> Also, I could not find a definition for "the MIME type of the Schema
> for SIP User Agent Profile Data Sets" in the other documents ([4]
> or [8]).
> 
I've removed the reference to [8] and the document is now only referring
to [3] as the default format.

Generally, I think it would be useful for interoperability to have a
default format for session-independent policies. [3] is a WG item and
can serve as such a format. The downside is, of course, that this would
introduce a dependency on [3] which in turn depends on [8]. An
alternative could therefore be to not specify a default format (as done
in the config framework).

> [ISSUE-2] Normative text on disclosing answer to policy server
> 
> On Page 14, Section 4.4.1. It says:
> 
>   A UA SHOULD generally disclose the offer and the answer to the
>   policy server.  However, the policy server may indicate on the
>   policy channel (after receiving the offer) that the disclosure of
>   the answer is not needed for this session.  In this case, the UAC
>   MAY skip the disclosure of the answer for this particular session.
> 
> Why is the last sentence a MAY? If the policy server indicated it
> did not need/want to see the answer, the UA SHOULD NOT disclose
> the answer. Suggest rewording as follows:
> 
>   A UA SHOULD disclose the offer to the policy server. A UA SHOULD
>   disclose the answer to the policy server, unless the policy server
>   has indicated on the policy channel (when processing the offer)
>   that the disclosure of the answer is not needed for this
>   session. When disclosing the answer to the policy servers, the UA
>   MUST contact the same policy servers it has contacted for the
>   offer.
> 
I've changed the paragraph as proposed.

> Also, on Page 15, Section 4.4.3. It says:
> 
>   If the UAS receives an ACK containing an answer, it SHOULD contact
>   the policy servers again with the answer.  In this case, it MUST
>   contact the same policy servers it has contacted for the offer.
>   However, the policy server may have indicated in response to the
>   offer that the disclosure of the answer is not needed for this
>   session.  In this case, the UAS MAY skip the disclosure of the
>   answer for this particular session.
> 
> Suggest:
> 
>   If the UAS receives an ACK containing an answer, it SHOULD contact
>   the policy servers again with the answer, unless the policy server
>   inll-labs.com>
To: Bob Penfield <[email-masked]>
Cc: SIPPING <[email-masked]>,
	Gonzalo Camarillo <[email-masked]>,
	Mary Barnes <[email-masked]>
Subject: [Sipping] Re: Review of
	draft-ietf-sipping-session-policy-framework-01

Bob,

> 
> [ISSUE-1] Dependence on Config Framework documents
> 
> On Page 6, Section 3.2: It says:
> 
>   A UA compliant to this specification MUST support the User Agent
>   Profile Data Set for Media Policy [3] and the Schema for SIP User
>   Agent Profile Data Sets [8].
> 
> This MUST makes [8] (draft-petrie-sipping-profile-datasets-03) a
> normative reference. That document is not (yet?) a working group
> document and has also expired. What is the plan for [8]?
> 
> Also, I could not find a definition for "the MIME type of the Schema
> for SIP User Agent Profile Data Sets" in the other documents ([4]
> or [8]).
> 
I've removed the reference to [8] and the document is now only referring
to [3] as the default format.

Generally, I think it would be useful for interoperability to have a
default format for session-independent policies. [3] is a WG item and
can serve as such a format. The downside is, of course, that this would
introduce a dependency on [3] which in turn depends on [8]. An
alternative could therefore be to not specify a default format (as done
in the config framework).

> [ISSUE-2] Normative text on disclosing answer to policy server
> 
> On Page 14, Section 4.4.1. It says:
> 
>   A UA SHOULD generally disclose the offer and the answer to the
>   policy server.  However, the policy server may indicate on the
>   policy channel (after receiving the offer) that the disclosure of
>   the answer is not needed for this session.  In this case, the UAC
>   MAY skip the disclosure of the answer for this particular session.
> 
> Why is the last sentence a MAY? If the policy server indicated it
> did not need/want to see the answer, the UA SHOULD NOT disclose
> the answer. Suggest rewording as follows:
> 
>   A UA SHOULD disclose the offer to the policy server. A UA SHOULD
>   disclose the answer to the policy server, unless the policy server
>   has indicated on the policy channel (when processing the offer)
>   that the disclosure of the answer is not needed for this
>   session. When disclosing the answer to the policy servers, the UA
>   MUST contact the same policy servers it has contacted for the
>   offer.
> 
I've changed the paragraph as proposed.

> Also, on Page 15, Section 4.4.3. It says:
> 
>   If the UAS receives an ACK containing an answer, it SHOULD contact
>   the policy servers again with the answer.  In this case, it MUST
>   contact the same policy servers it has contacted for the offer.
>   However, the policy server may have indicated in response to the
>   offer that the disclosure of the answer is not needed for this
>   session.  In this case, the UAS MAY skip the disclosure of the
>   answer for this particular session.
> 
> Suggest:
> 
>   If the UAS receives an ACK containing an answer, it SHOULD contact
>   the policy servers again with the answer, unless the policy server
>   indicated in response to the offer that the disclosure of the
>   answer is not needed for this session.  When disclosing the answer
>   to the policy servers, the UAS MUST contact the same policy servers
>   it has contacted for the offer.
> 
I've changed the paragraph as proposed.

> [ISSUE-3] UA Behavior for PRACK needed
> 
> In Section 4.4.1 (UAC Behavior) there should be procedures for an
> answer in a PRACK for a 1xx reliable provisional response which
> contained the offer. These would be similar to the procedures for
> ACK. This also applies to Section 4.4.3 (UAS Behavior).
> 
> I wonder if it might be better to say "a request containing a session
> description", rather that specifying INVITE, UPDATE, ACK and PRACK as
> the only methods the procedures apply to (although ACK, PRACK, and
> INVITE responses still need special consideration).
> 
I've revised the respective sections and generalized them as much as
possible by removing references to specific methods.

> [ISSUE-4] Caching requirements for UAS
> 
> Section 4.4.2 talks about UACs caching/storing the policy server
> URI. Shouldn't the UAS also cache/store the policy server URIs it
> learns from the Policy-Contact header(s) in an INVITE or UPDATE
> request for use in re-INVITE/UPDATE toward the calling party?
> 
This would imply that the UA uses the same policy server for incoming
and outgoing requests (i.e. in the role as UAS and UAC) which is
probably a reasonable assumption to make. I'll add wording that a UA
should also store URIs it has received in the role of a UAS.

> [ISSUE-5] Header Definition and Syntax
> 
> Since the policy server is always contacted using SUBSCRIBE/NOTIFY,
> the policy server URI should be a SIP or SIPS URI rather than an
> absoluteURI. Also, the header syntax should account for possible
> future header field parameters.
> 
Done.

> [ISSUE-6] Security Considerations
> 
> The Security Considerations section is a good start, but it needs
> work. It needs to be a bit more organized in identifying the specific
> treats using the terminology in RFC 3552. Also, normative
> requirements language needs to be used in the recommendations to
> mitigate the identified threats.
> 
I've revised the security considerations section. Further comments,
suggestions are, of course, highly appreciated.

> [Editorial] Sections 4.4.1 thru 4.4.3 (UA Behavior)
> 
> If caching applies to the UAS too, you may want to have a "User Agent
> Behavior" section that describes the general UA behavior and then UAC
> and UAS behavior sub-sections. Also, there is normative text in the
> UAC section that applies to UAs in general that should be in the
> general UA behavior section.
> 
Caching only applies to the UAS in a sense that the UAS can learn policy
server URIs and store them. Only the UAC needs to use these URIs.

I've restructured the draft and moved general UA discussions out of the
UAC and UAS sections and into sections that apply to both roles.

> [Editorial] Section 4.4.2: Caching of Policy Server URIs
> 
> This section talks about "caching" policy server URIs and "storing"
> them in the session state. Readers might confuse these two. Suggest
> adding text which clarifies that "caching" means remembering the URIs
> across multiple sessions and that the URIs are "stored" in session
> state even when the "non-cacheable" parameter is present.
> 
Created two separate sections (one for "caching" the policy server URI
and one for "storing" the URIs during a dialog) which hopefully better
explain the difference of the two concepts.

> [Editorial] On Page 4, Section 1, it says:
>     Since these policies are not based on a specific session
>   description, they can be created independent of an attempt to set
>   up a session and only need to be conveyed to the user agent once
>   (e.g. at the time the device is powered on).
> 
> However, the UA is also informed when the policy changes. Suggest:
>        ... and only need to be conveyed to the user agent when it
>    initializes (e.g. at the time the device is powered on) and when
>    the policies are changed.
> dicated in response to the offer that the disclosure of the
>   answer is not needed for this session.  When disclosing the answer
>   to the policy servers, the UAS MUST contact the same policy servers
>   it has contacted for the offer.
> 
I've changed the paragraph as proposed.

> [ISSUE-3] UA Behavior for PRACK needed
> 
> In Section 4.4.1 (UAC Behavior) there should be procedures for an
> answer in a PRACK for a 1xx reliable provisional response which
> contained the offer. These would be similar to the procedures for
> ACK. This also applies to Section 4.4.3 (UAS Behavior).
> 
> I wonder if it might be better to say "a request containing a session
> description", rather that specifying INVITE, UPDATE, ACK and PRACK as
> the only methods the procedures apply to (although ACK, PRACK, and
> INVITE responses still need special consideration).
> 
I've revised the respective sections and generalized them as much as
possible by removing references to specific methods.

> [ISSUE-4] Caching requirements for UAS
> 
> Section 4.4.2 talks about UACs caching/storing the policy server
> URI. Shouldn't the UAS also cache/store the policy server URIs it
> learns from the Policy-Contact header(s) in an INVITE or UPDATE
> request for use in re-INVITE/UPDATE toward the calling party?
> 
This would imply that the UA uses the same policy server for incoming
and outgoing requests (i.e. in the role as UAS and UAC) which is
probably a reasonable assumption to make. I'll add wording that a UA
should also store URIs it has received in the role of a UAS.

> [ISSUE-5] Header Definition and Syntax
> 
> Since the policy server is always contacted using SUBSCRIBE/NOTIFY,
> the policy server URI should be a SIP or SIPS URI rather than an
> absoluteURI. Also, the header syntax should account for possible
> future header field parameters.
> 
Done.

> [ISSUE-6] Security Considerations
> 
> The Security Considerations section is a good start, but it needs
> work. It needs to be a bit more organized in identifying the specific
> treats using the terminology in RFC 3552. Also, normative
> requirements language needs to be used in the recommendations to
> mitigate the identified threats.
> 
I've revised the security considerations section. Further comments,
suggestions are, of course, highly appreciated.

> [Editorial] Sections 4.4.1 thru 4.4.3 (UA Behavior)
> 
> If caching applies to the UAS too, you may want to have a "User Agent
> Behavior" section that describes the general UA behavior and then UAC
> and UAS behavior sub-sections. Also, there is normative text in the
> UAC section that applies to UAs in general that should be in the
> general UA behavior section.
> 
Caching only applies to the UAS in a sense that the UAS can learn policy
server URIs and store them. Only the UAC needs to use these URIs.

I've restructured the draft and moved general UA discussions out of the
UAC and UAS sections and into sections that apply to both roles.

> [Editorial] Section 4.4.2: Caching of Policy Server URIs
> 
> This section talks about "caching" policy server URIs and "storing"
> them in the session state. Readers might confuse these two. Suggest
> adding text which clarifies that "caching" means remembering the URIs
> across multiple sessions and that the URIs are "stored" in session
> state even when the "non-cacheable" parameter is present.
> 
Created two separate sections (one for "caching" the policy server URI
and one for "storing" the URIs during a dialog) which hopefully better
explain the difference of the two concepts.

> [Editorial] On Page 4, Section 1, it says:
>     Since these policies are not based on a specific session
>   description, they can be created independent of an attempt to set
>   up a session and only need to be conveyed to the user agent once
>   (e.g. at the time the device is powered on).
> 
> However, the UA is also informed when the policy changes. Suggest:
>        ... and only need to be conveyed to the user agent when it
>    initializes (e.g. at the time the device is powered on) and when
>    the policies are changed.
> 
Done.

> [Editorial] On Page 5, Section 3.1, it says:
> 
>   The local network may, for example, have policies that support the
>   access network infrastructure (e.g. in a wireless network where
>   bandwidth is scarce, a provider may restrict the bandwidth
>   available to an individual user)
> 
> Suggest the following text might read better:
> 
>   The local network may have policies that support the access network
>   infrastructure. For example, in a wireless network where bandwidth
>   is scarce, a provider may restrict the bandwidth available to an
>   individual user.
> 
Done.

> [Editorial] On Page 5, Section 3.1, it says:
> 
>   Thus, in most cases, a UA will receive session-independent policies
>   from one or at most two policy servers.
> 
> Suggest removal of "at most" as this implies that there will never be
> more than two policy servers.
> 
Yes, at most is too strong. I've removed it.

> [Editorial] On Page 14, Section 4.4.2, there is a typo (s/is/it/)
> 
> Change:
>   The UAC SHOULD store the list of policy server URIs is has contacted
> To:
>   The UAC SHOULD store the list of policy server URIs it has contacted
> 
Done.

> [Editorial] On Page 18, Section 4.5, it says:
> 
>   If this update causes a change in the session description of a
>   session, the UA may need to generate a re-INVITE or UPDATE message
>   to re-negotiate the modified session description with its peer UA.
> 
> You should probably mention that the re-INVITE/UPDATE message is
> generated in accordance with section 4.2 (i.e. it will contain a
> Policy-Id header with the policy server URI that sent the updated
> policy).
> 
Done.

Volker

Done.

> [Editorial] On Page 5, Section 3.1, it says:
> 
>   The local network may, for example, have policies that support the
>   access network infrastructure (e.g. in a wireless network where
>   bandwidth is scarce, a provider may restrict the bandwidth
>   available to an individual user)
> 
> Suggest the following text might read better:
> 
>   The local network may have policies that support the access network
>   infrastructure. For example, in a wireless network where bandwidth
>   is scarce, a provider may restrict the bandwidth available to an
>   individual user.
> 
Done.

> [Editorial] On Page 5, Section 3.1, it says:
> 
>   Thus, in most cases, a UA will receive session-independent policies
>   from one or at most two policy servers.
> 
> Suggest removal of "at most" as this implies that there will never be
> more than two policy servers.
> 
Yes, at most is too strong. I've removed it.

> [Editorial] On Page 14, Section 4.4.2, there is a typo (s/is/it/)
> 
> Change:
>   The UAC SHOULD store the list of policy server URIs is has contacted
> To:
>   The UAC SHOULD store the list of policy server URIs it has contacted
> 
Done.

> [Editorial] On Page 18, Section 4.5, it says:
> 
>   If this update causes a change in the session description of a
>   session, the UA may need to generate a re-INVITE or UPDATE message
>   to re-negotiate the modified session description with its peer UA.
> 
> You should probably mention that the re-INVITE/UPDATE message is
> generated in accordance with section 4.2 (i.e. it will contain a
> Policy-Id header with the policy server URI that sent the updated
> policy).
> 
Done.

Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 13 Oct 2006 23:41:18 -0400

Shida,

>  
>  Section 1. 
>   - 4th paragraph, 3rd sentence mentions a user-interaction 
> for providing consent on the policy provided by the policy server 
> but there is no mentioning of this in section 4.x. Did you 
> mean user or UA here? I think this needs to be clarified.
> 
I actually meant the user here since in the end it is the user who
consents to the use of policies. However, the mechanism (or user
interface) for giving consent is outside the scope of the mechanism in
4.x. This mechanism will enable the UA to learn about the policies. It
can use whatever mechanism it wants to apply or reject them.

>  Section 4.4.1
>   Last sentence in the 4th paragraph, defines a normative 
> behavior for UAC where UAC SHOULD NOT change the order of 
> policy servers
> 
This is intended to be normative behavior (does this addresses your
comment?).

> Section 4.4.2 
>  - 2nd paragraph, last sentence: I think when non-cachable 
> is appended after the URI, recipient(UAC) is only supposed to 
> remove the URI from the cache that has the same value as the 
> one received with the "non-cacheable". If that's true, the last 
> sentence should say the following.
> 
> OLD:
> It SHOULD remove the current URI from the cache
>    when receiving a "non-cacheable" URI.
> 
> NEW:
> It SHOULD not store the URI in the cache when 
> receiving a "non-cacheable" URI and SHOULD remove 
> the URI if it was already cached.
> 
A new local policy server URI should replace the URI that is currently
in the cache. Thus, if there is a new URI that is marked as
"non-cacheable" it will "replace" the old URI by removing it. I've added
some text clarifying this and also made honoring the non-cacheable
parameter a MUST.

> Section 4.4.2
>  - 3rd paragraph and 4th paragraph contradicts one 
> another. 4th paragraph mentions that UAC SHOULD store 
> the list of policy server's URI it contacted but 
> 3rd paragraph states that UAC SHOULD only cache URI 
> for the local policy server. I think some coherence 
> is needed between the paragraph.
> 
I've revised this section to clarify that the UA i) caches a local
policy server URI to be used for new dialogs and ii) stores a list of
policy servers it is using in a dialog for mid-dialog requests. These
two different issues are now described in separate sections.

> Section 4.4.4
>  - There is no normative behavior for Policy server 
> when UAS is inquiring for the policy. I think if there 
> is nothing for policy server to do, then that should be 
> stated as well.
> 
I've added a section about Contacting the Policy Server that describes
behavior for the UAC and the UAS.

> 
> Editorial nits:
> --------------------------
> Section 1:
>  - 6th paragraph, last sentence: I would suggest the 
> following changes to clarify that session-independent 
> policy does change.
> 
> OLD:
> description, they can be created independent of an attempt to 
> set up a session and only need to be conveyed to the user 
> agent once (e.g. at the time the device is powered on). 
> 
> NEW:
> description, they can be created independent of an attempt to 
> set up a session and only need to be conveyed to the user 
> agent once (e.g. at the time the device is powered on) until 
> relevant policies change
> 
Done.

> Section 4.2:
>  - 1st paragraph, 4th sentence to the end of 2nd paragraph 
> explains the benefit of separate channel over piggy back model, 
> but do we still need this in the draft? I personally think this 
> can be removed. May be you can note the decision that was made 
> in the change-log.
> 
The question of piggyback vs. separate channel model keeps coming up.
For this reason, I'd prefer to have at least a small piece of discussion
in the draft.

> Section 4.4.1
>  - 2nd paragrah, last sentence: I would suggest the 
> following changes to clarify that request reflecting the 
> policies are to be sent to the same proxy where original 
> request was sent. Also behavior of UAC when no policies 
> were provided should be mentioned as well.
> 
> OLD: 
>  The UAC SHOULD apply the policies received and resend
>  the updated request.
> 
> NEW:
>  The UAC SHOULD apply the policies received and resend 
> the updated request to the same proxy it sent the original 
> request. If no policies were received it SHOULD resend the 
> request without changing its session parameters to the 
> same proxy it sent the original request.
> 
The request does not necessarily need to be sent to the same proxy. A
domain could, e.g., do load balancing and have a set of proxies that all
refer to the same policy server. Each proxy can still determine that the
UA has retrieve policies by looking at the Policy-Id header.

I'll add wording that defines behavior when no policies were provided.

Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 13 Oct 2006 23:41:05 -0400

Roni,

> 
> I have a question:
> 
> In the session specific policy call flows the UA that send the invite
> insert a header field (Policy-Id) indicating to the proxy that it
> contacted the Policy server. How does the proxy on the other side
> know that the UA contacted the policy server when it gets the 200
> with the answer.
> 
The proxy on the UAS does not know and does not need to know. The policy
server knows that it has been contacted by the UA. The proxy does not
need to know since it does not need to perform any operations on the
response. This is in contrast to the request (on the UAC side), which is
rejected to convey the policy server URI to the UAC if it is unknown.

> A nit
> 
> Introduction section - says "In contrast to other methods for
> inserting a media intermediary, the use of session policies does not
> require the inspection or modification of SIP message bodies".
> Looking at section 4.3.1 for example shows that at least the two
> proxies PA and PB will change the SIP message.  I also assume that
> policy enforcement will require inspection of the messages.
> 
Yes, but they will only modify headers, not bodies. Policy enforcement
may require the inspection of the message body but this is outside of
the scope for this draft (and not needed for the mechanism to convey
policies to the UA).

Volker