Subject: [Sipping] Combining Proxy + Policy servers

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 19 Apr 2006 11:56:16 -0400

To the authors of draft-ietf-sipping-session-policy-framework-00.txt:

Excellent work and very timely!  I would like to understand better the
overall operation:

   The protocol defined in this specification clearly separates SIP
   signaling and the exchange of policy information.  SIP signaling is
   only used to rendezvous the UA with the policy server.  From this
   point on, UA and policy server communicate directly with each other
   over a separate policy channel.  This is opposed to a piggyback
   model, where the exchange of policy information between endpoint and
   a policy server in the network is piggybacked onto the SIP signaling
   messages that are exchanged between endpoints.

I am approaching this line of questioning from an inter-domain message
flow point of view.  Why not more emphasis of the policy server as a
function that can be implemented on the proxy, instead of a separate
device/channel, more so device.  By mandating the delineation between
the proxy server and the policy server, the number of transactions
required to determine route or path selection seems greater than would
be required in the "piggyback model".  There's some session routing that
an inter-domain proxy will be required to perform regardless of policy
referral.  Using the Subscribe/Notify function between two edge proxies
across domains is an excellent idea to exchange policy information.
Caching that policy information would help speed up the route-decision
making process.  I am approaching this thinking that the policy exchange
mechanisms would be more static in nature meaning done at inception of
relationship with changes periodic, than dynamic, therefore the overhead
on the proxy doesn't warrant offloading to a separate element
altogether.  

As the draft defends the rationale 

   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). 

I am thinking that TLS for all signaling communications would handle
this.

   Policies can be submitted directly from the policy
   server to the endpoint and never travel along the signaling path,
   possibly crossing many domains.

Not sure why this is an advantage. The signaling path is already there,
why not use it?  

   Endpoints set up a separate policy
   channel to each policy server and can specifically decide which
   information they want to disclose to which policy server.

Couldn't this be achieved also in the signaling path as well?

   Finally,
   policy servers do not need to rely on a SIP signaling message flowing
   by to send policies or policy updates to the endpoint.

Why exchange policies if there is no requirement for SIP signaling?

I ask these questions in the most humble way knowing that the authors
have a tremendous amount of experience in the SIP world.

Adam Uzelac

_______________________________________________
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