Subject: [Sip] Re: Review of draft-ietf-sip-session-policy-framework-01

From: Volker Hilt <[email-masked]>
Date: Tue, 31 Jul 2007 19:35:56 -0400

Roni,

thanks much for reviewing this document. Comments inline.

> 1. The draft explains describes two mechanisms the session 
> independent and the session dependent policies. I did not see what
> the relationship between them if any is. I think that at least the
> draft should say that they can be implemented independently if there
> are no other recommendations.
> 
I've added two sentences to the end of the introduction clarifying this. 
If also added a sentence to the end of the Session-independent policy 
section clarifying what to do when both mechanisms are used.

> 2. Section 3.2 describes how a UA discovers the policy servers for
> session independent policies based on the configuration framework
> ua-profile.
> 
> "ua-profile" event package [4] provides a mechanism to discover
>    policy servers in the local network and the home domain.  The "local-
>    network" profile-type enables a UA to discover a policy server in the
>    local domain.  The "user" profile type enables the discovery of a
>    policy server in the home domain.  A UA compliant to this
>    specification SHOULD attempt to discover and subscribe to the policy
>    servers in these two domains"
> 
> The configuration framework does not specify the profile data which
> is out of scope.

The profile type is not the profile data itself. The profile type 
effectively defines how the UA subscribes to the policy server in a 
given domain (e.g. in the local or home domain).

> So what is the meaning of this section - is this one way to find the 
> policy server 

Yes.

> or do you suggest that if you want to have session 
> independent policies you should have the policy servers defined in
> the profile data but then how does a UA identify it in the profile
> data, is it by name?
>
No. The idea is that the UA uses the procedures defined in the config
framework to construct the URI of these servers.

> I think this needs more clarification.
> 
I've revised the above paragraph to make this more clear.

> 3. In section 4.2
> " 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"
> How does this work with the trust model between the UA and the proxy.
> The UA claimed that it got the policy from the proxy but from this 
> sentence you can assume that the UA got the policy only to what it 
> asked. I think that the UA need to include in document sent to the
> proxy all the information it can map from SDP.
> 
True. The UA can disclose what is requested by a specific policy server 
(e.g. offer only or offer/answer). I'll change this sentence accordingly.

> 4. In section 4.4.2 what will be the proxy behavior if it sends the
> Invite with the policy server URI to an endpoint who do not support
> session policy. The EP can ignore the request and respond 200 that will
> not include the support for the session policy. What will the proxy do
> or is it left to local implementation.
> 
The task of the proxy is to convey the policy server URI to the UAS. The 
enforcement that the UAS actually uses the URI is outside the scope here 
and could happen in the proxy or on the network level (i.e. it is left 
to local implementation).

Nevertheless, I think a proxy should be able to know whether the policy 
server URI was understood by the UAS (e.g. because it may want to do SDP 
modification if it was not understood). To enable this, the UAS now 
includes a Supported header into responses that contained a 
Policy-Contact header.

> 5. In section 4.4.6 in the note
> 
> " If, however, a policy server cannot respond with
>       a policy right away, it may return a policy that temporarily
>       denies the session and update this policy as the actual policy
>       decision becomes available"
> 
> I am not sure how does that work, what will the UA do in this case.
> Will it continue with the call without any media sessions?
> 
No, I don't think that would be terribly useful. If the policy server 
does not return the admittance decision right away, a UA can decide to 
wait, maybe informing the user with something like "All resources are 
current busy - Retrying". Alternatively, it could terminate the call 
attempt (maybe after a short time).
> 
> In section 4.4.3 third line should be field and not filed 
> 
Fixed.

Thanks much!

Volker

_______________________________________________
Sip mailing list  https://www1.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