Subject: [Sip] draft-ietf-sip-session-policy-framework-02

From: "Andrew Allen" <[email-masked]>
Date: Sat, 1 Mar 2008 12:35:27 -0500

Firstly I apologize for the very late comments on this draft which has
already completed WGLC.

I recently reviewed draft-ietf-sip-session-policy-framework-02 with a
view to its utilization in 3GPP IMS particularly with regard to its
application in mobile networks. After reading the draft I have some
concern that the Subscribe/Notify mechanism for the Policy channel is
too heavy for use in Cellular and other narrow band networks. The
session establishment times for cellular using SIP are already too long.
Adding an additional SUBSCRIBE, 200 OK, NOTIFY, 200 OK per UA to that to
go fetch the local session-specific policy will not be acceptable. It
seems there could be other more efficient means available in certain
networks to obtain the session-specific Policy.

While the Subscribe/Notify mechanism may be the best general purpose
mechanism it seems to me that the mechanism ought to be extensible to
allow additional Policy channel mechanisms to be defined in the future
which probably means extensibility to support URIs other than just
SIP/SIPS URIs in the Policy-Contact header.

The draft anticipates that non SIP means might be used to obtain the
session-independent policies so why not also anticipate the possibility
that non SIP means might in the future be used to obtain
session-specific policies?

I have had some discussion with Volker already on this issue and it
seems it would be possible to modify the Policy-Contact header to
optionally allow multiple URIs of different types for the same Policy
Document from the same domain with inclusion of a SIP or SIPS URI being
mandatory.

e.g

 Policy-Contact: sip:policy-doc@domainA; sips:policy-doc@domainA; 

 http:policy-doc@domainA; https:policy-doc@domainA
<https://policy-doc@domainA> , 

 sip:policy-doc@domainB; sips:policy-doc@domainB; 

 http:policy-doc@domainB; https:policy-doc@domainB
<https://policy-doc@domainB> 

Support of SIP or SIPS URI schemes and the Subscribe/Notify mechanism
for the Policy Channel would continue to be mandatory for
interoperability but the possibility to include additional URI schemes
for obtaining the session-specific policy document would be added.

This seems like a relatively straight forward change to make even though
it is a very late proposal.

Since one of the original primary drivers for the session policy work
originated from 3GPP requirements it would be a shame if the solution
wasn't sufficiently extensible to allow 3GPP in the future to use it.

Andrew Allen

Manager Standards

Research In Motion Ltd

Office +1 847-793-0861 x20824

BlackBerry Mobile +1 847 809 8636

http://www.rim.com/ <http://www.rim.com/> 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Volker Hilt <[email-masked]>
Date: Tue, 11 Mar 2008 16:05:18 -0400

The main request here is to allow different protocols on the policy 
channel, in addition to the SUB/NOT mechanism defined in the policy 
package. The discovery mechanism for policy servers defined in the 
framework draft would still be used but it would be possible to use 
other protocols for retrieving policies (e.g., HTTP).

This would require that UAs and proxies can come up with policy channel 
protocol both support.

A full blow negotiation mechanism seems overkill and is also difficult 
to do on the UAS side. The reason is that the UAS will receive a request 
that already contains the policy server URI and, thus, it is too late to 
negotiate a format for it.

An alternative could be to enable a domain to insert URIs with 
additional protocol schemes into the policy contact header (e.g. HTTP) 
in addition to SIP.

Yet another alternative is, of course, to keep things as they are and 
only allow the policy package for the policy channel.

Thanks,

Volker

Andrew Allen wrote:
> <https://policy-doc@domainA>,
> 
> wasn’t sufficiently extensible to allow 3GPP in the future to use it.
> 
> Andrew Allen
> 
> Manager Standards
> 
> Research In Motion Ltd
> 
> http://www.rim.com/
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other than 
> the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and delete 
> this information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Andrew Allen" <[email-masked]>
Date: Tue, 11 Mar 2008 17:14:52 -0400

I propose we go with the alternative that enables a domain to insert
URIs with additional protocol schemes into the policy contact header
(e.g. HTTP) in addition to SIP.

A negotiation mechanism could always be added later if it was determined
to be needed as an optiomization but is not needed now for sure. The
important thing is to have some flexibility for future additional
protocols on the Policy Channel.

-----Original Message-----
From: Volker Hilt [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2008 4:05 PM
To: [email-masked]
Cc: Andrew Allen
Subject: Re: [Sip] draft-ietf-sip-session-policy-framework-02

Thanks,

Volker

Andrew Allen wrote:
> Adding an additional SUBSCRIBE, 200 OK, NOTIFY, 200 OK per UA to that 
> to go fetch the local session-specific policy will not be acceptable. 
> It seems there could be other more efficient means available in 
> certain networks to obtain the session-specific Policy.
> 

> session-independent policies so why not also anticipate the 
> possibility that non SIP means might in the future be used to obtain 
> Document from the same domain with inclusion of a SIP or SIPS URI 
> being mandatory.
> 
> e.g

> This seems like a relatively straight forward change to make even 
> though it is a very late proposal.
> 

> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip

---

From: Volker Hilt <[email-masked]>
Date: Thu, 13 Mar 2008 09:24:35 -0400

I would propose to make sure that the policy framework allows an 
extension like the one proposed to be added in the future. This will 
allow a way forward without putting a header parameter in right now.

Thanks,

Volker

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 19 Mar 2008 10:53:52 +0100

(As SIP WG cochair)

Volker presented the following slide to the SIP WG on the session policy
framework.

------------------------------------------------------------------------
-------------
Open Issue
The session policy framework specifies SUBSCRIBE/NOTIFY and the session
policy package as the policy channel protocol. 
In some environments (e.g., wireless networks) it can be useful to allow
other policy channel protocols.
Requires that proxies and UAs can agree on a policy channel protocol.
Alternatives:
A1: no change. Only allow the use of the policy package.
A2: enable domains to add alternative policy server URIs (e.g., a HTTP
URI) as parameters to a Policy-Contact header. 
UA can choose to use the alternative URI if supported.
The policy package remains default policy channel protocol.
------------------------------------------------------------------------
-------------

Volker is proposing to modify the session policy framework draft to
allow an extension to be made in the future, but without making the
extension.

In the absence of other comments, we will assume that the direction
proposed by Volker is adopted solution. Your comments are therefore
welcome, particularly if you have different views on the direction
forward.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Volker Hilt
> Sent: Thursday, March 13, 2008 1:25 PM
> To: Andrew Allen
> Cc: [email-masked]
> I would propose to make sure that the policy framework allows 
> an extension like the one proposed to be added in the future. 
> This will allow a way forward without putting a header 
> parameter in right now.
> 
> Thanks,
> 
> Volker
> 
> 
> 
> 
> Andrew Allen wrote:
> > A negotiation mechanism could always be added later if it was 
> > determined to be needed as an optiomization but is not 
> needed now for 
> > sure. The important thing is to have some flexibility for future 
> > additional protocols on the Policy Channel.
> > 
> > 
> > 
> > This would require that UAs and proxies can come up with policy 
> > channel protocol both support.
> > 
> > to do on the UAS side. The reason is that the UAS will receive a 
> > request that already contains the policy server URI and, 
> thus, it is 
> > too late to negotiate a format for it.
> > 
> >> I recently reviewed 
> draft-ietf-sip-session-policy-framework-02 with a 
> >> -
> >> --
> > This transmission (including any attachments) may contain 
> confidential information, privileged material (including 
> material protected by the solicitor-client or other 
> applicable privileges), or constitute non-public information. 
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender 
> and delete this information from your system. Use, 
> dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and 
> may be unlawful.
> [email-masked] for questions on current sip