draft-ietf-sip-session-policy-framework-02

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:
> 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-docdomainA;
sips:policy-docdomainA;
> 
>  http:policy-docdomainA; https:policy-docdomainA 
> <https://policy-docdomainA>,
> 
>  sip:policy-docdomainB; sips:policy-docdomainB;
> 
>  http:policy-docdomainB; https:policy-docdomainB 
> <https://policy-docdomainB>
> 
> 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/
> 
>  
> 
>
------------------------------------------------------------
---------
> 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 sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:volkerhbell-labs.com] 
Sent: Tuesday, March 11, 2008 4:05 PM
To: sipietf.org
Cc: Andrew Allen
Subject: Re: [Sip]
draft-ietf-sip-session-policy-framework-02

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:
> 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-docdomainA;
sips:policy-docdomainA;
> 
>  http:policy-docdomainA; https:policy-docdomainA 
> <https://policy-docdomainA>,
> 
>  sip:policy-docdomainB; sips:policy-docdomainB;
> 
>  http:policy-docdomainB; https:policy-docdomainB 
> <https://policy-docdomainB>
> 
> 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/
> 
>  
> 
>
------------------------------------------------------------
---------
> 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 
> sip-implementorscs.columbia.edu for questions on current
sip Use 
> sippingietf.org for new developments on the application of
sip

------------------------------------------------------------
---------
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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:
> 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:volkerhbell-labs.com] 
> Sent: Tuesday, March 11, 2008 4:05 PM
> To: sipietf.org
> Cc: Andrew Allen
> Subject: Re: [Sip]
draft-ietf-sip-session-policy-framework-02
> 
> 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:
>> 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-docdomainA;
sips:policy-docdomainA;
>>
>>  http:policy-docdomainA;
https:policy-docdomainA 
>> <https://policy-docdomainA>,
>>
>>  sip:policy-docdomainB;
sips:policy-docdomainB;
>>
>>  http:policy-docdomainB;
https:policy-docdomainB 
>> <https://policy-docdomainB>
>>
>> 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/
>>
>>  
>>
>>
------------------------------------------------------------
---------
>> 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 
>> sip-implementorscs.columbia.edu for
questions on current sip Use 
>> sippingietf.org for new developments on the
application of sip
> 
>
------------------------------------------------------------
---------
> 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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

(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

> -----Original Message-----
> From: sip-bouncesietf.org [mailto:sip-bouncesietf.org]
On 
> Behalf Of Volker Hilt
> Sent: Thursday, March 13, 2008 1:25 PM
> To: Andrew Allen
> Cc: sipietf.org
> Subject: Re: [Sip]
draft-ietf-sip-session-policy-framework-02
> 
> 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:
> > 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:volkerhbell-labs.com]
> > Sent: Tuesday, March 11, 2008 4:05 PM
> > To: sipietf.org
> > Cc: Andrew Allen
> > Subject: Re: [Sip]
draft-ietf-sip-session-policy-framework-02
> > 
> > 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:
> >> 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-docdomainA;
sips:policy-docdomainA;
> >>
> >>  http:policy-docdomainA;
https:policy-docdomainA 
> >> <https://policy-docdomainA>,
> >>
> >>  sip:policy-docdomainB;
sips:policy-docdomainB;
> >>
> >>  http:policy-docdomainB;
https:policy-docdomainB 
> >> <https://policy-docdomainB>
> >>
> >> 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/
> >>
> >>  
> >>
> >> 
>
------------------------------------------------------------
---------
> >> 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 
> >> sip-implementorscs.columbia.edu for
questions on current sip Use 
> >> sippingietf.org for new developments on the
application of sip
> > 
> > 
>
------------------------------------------------------------
---------
> > 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 
> sip-implementorscs.columbia.edu for questions on current
sip 
> Use sippingietf.org for new developments on the
application of sip
> 
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip