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

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

Bob,

thanks much for reviewing the draft!
> 
> [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. 

I agree. Conveying additional information about a session (e.g. the 
target URI or dialog-ID) to the policy server is useful and should not 
be a problem with XML-based subscribe bodies. This will require a couple 
of modifications to the XML policy format so that it can work this way.

> 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.
> 
I think it does not provide much value for a proxy to know that a UA has 
contacted the policy server. The reason is that there is no guarantee 
that a UA is actually using the policy received to set up a session or 
even the same session description it has sent to the policy server. A UA 
may contact the policy server, get a set of policies (e.g. no video) 
plus the admission token (since it is assumed the the UA would apply the 
policies before setting up the session). But then the UA can totally 
ignore the received policies and set up the session as is. Or the UA 
couldFrom [email-masked] Fri Oct 20 00:13:27 2006
Date: Fri, 20 Oct 2006 00:12:12 -0400
From: Volker Hilt <[email-masked]>
To: Bob Penfield <[email-masked]>
Cc: SIPPING <[email-masked]>, Mary Barnes <[email-masked]>,
	Gonzalo Camarillo <[email-masked]>
Subject: [Sipping] Re: Review of draft-ietf-sipping-policy-package-01

Bob,

thanks much for reviewing the draft!
> 
> [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. 

I agree. Conveying additional information about a session (e.g. the 
target URI or dialog-ID) to the policy server is useful and should not 
be a problem with XML-based subscribe bodies. This will require a couple 
of modifications to the XML policy format so that it can work this way.

> 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.
> 
I think it does not provide much value for a proxy to know that a UA has 
contacted the policy server. The reason is that there is no guarantee 
that a UA is actually using the policy received to set up a session or 
even the same session description it has sent to the policy server. A UA 
may contact the policy server, get a set of policies (e.g. no video) 
plus the admission token (since it is assumed the the UA would apply the 
policies before setting up the session). But then the UA can totally 
ignore the received policies and set up the session as is. Or the UA 
couldFrom [email-masked] Fri Oct 20 00:13:27 2006
Date: Fri, 20 Oct 2006 00:12:12 -0400
From: Volker Hilt <[email-masked]>
To: Bob Penfield <[email-masked]>
Cc: SIPPING <[email-masked]>, Mary Barnes <[email-masked]>,
	Gonzalo Camarillo <[email-masked]>
Subject: [Sipping] Re: Review of draft-ietf-sipping-policy-package-01

Bob,

thanks much for reviewing the draft!
> 
> [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. 

I agree. Conveying additional information about a session (e.g. the 
target URI or dialog-ID) to the policy server is useful and should not 
be a problem with XML-based subscribe bodies. This will require a couple 
of modifications to the XML policy format so that it can work this way.

> 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.
> 
I think it does not provide much value for a proxy to know that a UA has 
contacted the policy server. The reason is that there is no guarantee 
that a UA is actually using the policy received to set up a session or 
even the same session description it has sent to the policy server. A UA 
may contact the policy server, get a set of policies (e.g. no video) 
plus the admission token (since it is assumed the the UA would apply the 
policies before setting up the session). But then the UA can totally 
ignore the received policies and set up the session as is. Or the UA 
couldFrom [email-masked] Fri Oct 20 00:13:27 2006
Date: Fri, 20 Oct 2006 00:12:12 -0400
From: Volker Hilt <[email-masked]>
To: Bob Penfield <[email-masked]>
Cc: SIPPING <[email-masked]>, Mary Barnes <[email-masked]>,
	Gonzalo Camarillo <[email-masked]>
Subject: [Sipping] Re: Review of draft-ietf-sipping-policy-package-01

Bob,

thanks much for reviewing the draft!
> 
> [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. 

I agree. Conveying additional information about a session (e.g. the 
target URI or dialog-ID) to the policy server is useful and should not 
be a problem with XML-based subscribe bodies. This will require a couple 
of modifications to the XML policy format so that it can work this way.

> 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.
> 
I think it does not provide much value for a proxy to know that a UA has 
contacted the policy server. The reason is that there is no guarantee 
that a UA is actually using the policy received to set up a session or 
even the same session description it has sent to the policy server. A UA 
may contact the policy server, get a set of policies (e.g. no video) 
plus the admission token (since it is assumed the the UA would apply the 
policies before setting up the session). But then the UA can totally 
ignore the received policies and set up the session as is. Or the UA 
could send a "friendly" session description to the policy server, get 
the admission token and the set up the session with a totally different 
session description. Session policies enable a UA to learn about the 
policies in a network and set up sessions accordingly but they do not 
provide enforcement capabilities.

> 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.
> 
Yes, I think disclosing the request URI as part of the session 
information is very useful. I'll add this to the media data set format 
for subscribe bodies.

> [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?
> 
Yes, this needs to be changed to a MUST. With SDP bodies, it was 
possible that the UA did not have an offer when it was subscribing (e.g. 
when the UA initiated an empty INVITE request). However, with an XML
body format, a UA is able to submit a minimal policy document that
contains, e.g., at least the request URI.

> [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.
> 
I agree.

> [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"
> 
I've used the proposed text.

> [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?
> 
There may be cases in which the policy server declines the session
because of temporary constraints (e.g. a temporary shortage of
resources). In these cases, the policy server can keep the subscription
alive and inform the UA when it is possible to set up the session. For
these cases, the UA should also not terminate the subscription. However,
if the policy server has terminated the subscription, the UA should not
try to resubscribe.

I'll add text clarifying this.

> [Technical] On page 9, section 3.9, it says:
> 
>   If the subscriber receives a NOTIFY that contains the "local-only"
>   event parameter, it MAY sto send a "friendly" session description to the policy server, get 
the admission token and the set up the session with a totally different 
session description. Session policies enable a UA to learn about the 
policies in a network and set up sessions accordingly but they do not 
provide enforcement capabilities.

> 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.
> 
Yes, I think disclosing the request URI as part of the session 
information is very useful. I'll add this to the media data set format 
for subscribe bodies.

> [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?
> 
Yes, this needs to be changed to a MUST. With SDP bodies, it was 
possible that the UA did not have an offer when it was subscribing (e.g. 
when the UA initiated an empty INVITE request). However, with an XML
body format, a UA is able to submit a minimal policy document that
contains, e.g., at least the request URI.

> [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.
> 
I agree.

> [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"
> 
I've used the proposed text.

> [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?
> 
There may be cases in which the policy server declines the session
because of temporary constraints (e.g. a temporary shortage of
resources). In these cases, the policy server can keep the subscription
alive and inform the UA when it is possible to set up the session. For
these cases, the UA should also not terminate the subscription. However,
if the policy server has terminated the subscription, the UA should not
try to resubscribe.

I'll add text clarifying this.

> [Technical] On page 9, section 3.9, it says:
> 
>   If the subscriber receives a NOTIFY that contains the "local-only"
>   event parameter, it MAY sto send a "friendly" session description to the policy server, get 
the admission token and the set up the session with a totally different 
session description. Session policies enable a UA to learn about the 
policies in a network and set up sessions accordingly but they do not 
provide enforcement capabilities.

> 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.
> 
Yes, I think disclosing the request URI as part of the session 
information is very useful. I'll add this to the media data set format 
for subscribe bodies.

> [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?
> 
Yes, this needs to be changed to a MUST. With SDP bodies, it was 
possible that the UA did not have an offer when it was subscribing (e.g. 
when the UA initiated an empty INVITE request). However, with an XML
body format, a UA is able to submit a minimal policy document that
contains, e.g., at least the request URI.

> [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.
> 
I agree.

> [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"
> 
I've used the proposed text.

> [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?
> 
There may be cases in which the policy server declines the session
because of temporary constraints (e.g. a temporary shortage of
resources). In these cases, the policy server can keep the subscription
alive and inform the UA when it is possible to set up the session. For
these cases, the UA should also not terminate the subscription. However,
if the policy server has terminated the subscription, the UA should not
try to resubscribe.

I'll add text clarifying this.

> [Technical] On page 9, section 3.9, it says:
> 
>   If the subscriber receives a NOTIFY that contains the "local-only"
>   event parameter, it MAY sto send a "friendly" session description to the policy server, get 
the admission token and the set up the session with a totally different 
session description. Session policies enable a UA to learn about the 
policies in a network and set up sessions accordingly but they do not 
provide enforcement capabilities.

> 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.
> 
Yes, I think disclosing the request URI as part of the session 
information is very useful. I'll add this to the media data set format 
for subscribe bodies.

> [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?
> 
Yes, this needs to be changed to a MUST. With SDP bodies, it was 
possible that the UA did not have an offer when it was subscribing (e.g. 
when the UA initiated an empty INVITE request). However, with an XML
body format, a UA is able to submit a minimal policy document that
contains, e.g., at least the request URI.

> [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.
> 
I agree.

> [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"
> 
I've used the proposed text.

> [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?
> 
There may be cases in which the policy server declines the session
because of temporary constraints (e.g. a temporary shortage of
resources). In these cases, the policy server can keep the subscription
alive and inform the UA when it is possible to set up the session. For
these cases, the UA should also not terminate the subscription. However,
if the policy server has terminated the subscription, the UA should not
try to resubscribe.

I'll add text clarifying this.

> [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.
> 
I've used the proposed text.

> [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.
> 
I've streamlined the introduction.

> [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"?
> 
Removed automata.

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

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