|
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 at domainA; sips:policy-doc at domainA; http:policy-doc at domainA;
https:policy-doc at domainA, sip:policy-doc at domainB;
sips:policy-doc at domainB; http:policy-doc at domainB;
https:policy-doc at 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
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-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip