Subject: [Sipping] Session policies

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 28 Oct 2006 17:07:47 +0300

Hi,

a few comments on the session policies drafts. I send them all to
SIPPING because, even though the framework is now a SIP document, all
these drafts will be presented in SIPPING in San Diego.

draft-ietf-sip-session-policy-framework-00.txt

The document talks about how to get the URI of the local policy server
in a 488 response but does not seem to describe how to get such URI
using the configuration framework. Obtaining the local policy server's
URI at configuration time would decrease the session establishment delay
of the first session established by the UA.

The second paragraph of Section 4.3.2 states that steps 1 to 8 are the
same as the previous section. However, in steps 4 and 4 the UA cannot
disclose its offer, because it will not generate any offer. It will only
generate an answer on receiving the offer from the remote UA. That
section needs to describe steps 3, 4, 6, and 7 in more detail.

At the end of the same paragraph (and also at the end of page 17) the
document talks about Flow I and the need to get a quick answer from the
policy server. The document should also describe what to do in case the
policy server takes time to answer. The description should be similar to
the one in the 3pcc regarding the different alternative flows.

Section 4.4.3: s/filed/field/

Also in Section 4.4.3, the document recommends to contact policy servers
in the order they appear in the policy-contact header field. Why do they
need to be contacted in order? Why cannot the UA contact them in
parallel and then merge their policy decisions?

Second paragraph of Section 4.4.6: remove 'UA' from:

A UA that contacts a policy server UA SHOULD ...
                                    ^^
Bullet number 2 in the Security Considerations Section recommends mutual
authentication between UAs and policy servers. Many UA will not have a
client TLS certificate and will not share any secret with the policy
server (unless it is a local policy server). Therefore, we need to
rethink that. If we want to recommend client authentication, the proxy
could include a token in its policy-contact header field to be used to
access the policy server, for instance.

draft-ietf-sipping-policy-package-02.txt

The second sentence of the Introduction starts with "This draft". Using
"this" is confusing, because it could be understood as the event package
itself, not the framework. Besides, we should use RFC, specification, or
document, but not draft (it will eventually be approved and will not be
a draft any longer).

Regarding the open issue on how much info should the UA disclose, the
simplest solution would be for UAs to disclose all info that can be
encoded in the XML schema. UAs that support extensions to that schema
would also use those elements to disclose further information.

draft-ietf-sipping-media-policy-dataset-02.txt

At the end of Section 6.6, we should think about possible interactions
with ICE.

Do we really need ip-in-ip and ip-loose intermediaries? I would guess
very few people (if any) would use them.

On the other hand, I would include bandwidth related elements such as
max session bandwidth and max bandwidth per stream, which the current
document rules out of scope in Section 6.11.

In Section 7.2.1 (an in the other examples), it seems superfluous to
have a <media-types> element listing all the media types used in the
session, and then individual <media-type> elements providing the same
information per stream. Can we remove the global <media-types> element
from this type of document?

I may have missed it, but we need to specify how a policy server
indicates that it does not need to see the answer.

Cheers,

Gonzalo

_______________________________________________
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

---

From: Volker Hilt <[email-masked]>
Date: Mon, 30 Oct 2006 23:26:41 -0500

Hi Gonzalo,

thanks for the feedback!! Comments inline.
> of the first session established by the UA.
The draft mentions that a UA can get the local policy server URI through 
configuration and that this URI is used in the same way as a URI 
received in a 488 (i.e. it is stored in the local policy serve URI cache 
and used for subsequent requests). Maybe this needs to be stated more 
clearly in the draft. Also a reference the config framework needs to be 
added here.

The dataset drafs do not yet provide an element that can carry the local 
policy server URI. This should probably go into the media data set 
(since this draft is dealing with policies) or the core UA profile data set.

> section needs to describe steps 3, 4, 6, and 7 in more detail.
True. I'll correct the description in the next rev.

> the one in the 3pcc regarding the different alternative flows.
I think it is a requirement that the policy server responds with a 
policy right away. In most cases, a policy server will probably be able 
to admit/reject a session right away (I can't imagine that the policy 
server will ask an administrator for approval). If it really can't make 
this decision immediately, it can reject a session in the first response 
and send a subsequent response accepting the session (the policy event 
package supports this). Thus, the policy server can respond right away 
in any case.

The main point of the reference to Flow I in the 3PCC spec was that both 
flows follow the same pattern and require that the policy server (or 
3PCC peer) responds right away. Maybe this needs to be clarified in the 
draft.

> parallel and then merge their policy decisions?
The sequential contacting of the policy server is needed for some 
policies. However, right now, only the <configured-intermediary> element 
(inside the <media-intermediary> element) actually needs this. Policy 
servers that use the configured-intermediary element need to know the 
address/ports used in the previous domain so that they can configure the 
correct forwarding in their media intermediaries. The unmodified SDP 
description wouldn't help since it contains the address/ports of the UA. 
So, in fact, the sequential contacting is only needed for chaining 
configured-intermediaries.

A simple way to fix this would be to say that we don't allowed chaining 
of intermediaries (or at least intermediaries using the 
<configured-intermediary> element). However, this would be a significant 
change/limitation.

> access the policy server, for instance.
I think that it is important for a UA to authenticate the policy server 
since policies impact the sessions a UA sets up. I'm not sure what the 
best way of doing this would be. With the token, would the policy server 
return a token that has to match the one that was in the policy-contact 
header?

> would also use those elements to disclose further information.
I agree.

> At the end of Section 6.6, we should think about possible interactions
Yes, there is some text in the note at the beginning of section 6.6 but
this is very rudimentary needs to be expanded.

A possible way of interacting could be that a UA learns STUN/TURN server 
addresses (or other intermediary addresses??) in a domain through 
policies and uses them when gathering ICE candidate addresses and 
performing connectivity checks. A somewhat different view would be that 
these intermediaries are the intermediaries a UA has use.

> document rules out of scope in Section 6.11.
I think the general idea is that we should only have a minimal set of 
policy elements in this format and everything else should be done via
extensions.

Regarding ip-in-ip and ip-loose, they are probably not a requirement for 
a minimal format and can probably be removed. I can imagine that a max 
session bandwidth (and maybe a max sessions) makes sense in certain 
scenarios. However, the most important parameter with respect to 
bandwidth seems to be the overall bandwidth available to a UA (which is 
already defined).

> from this type of document?
This would be possible for documents that encode a session description 
(i.e. are enclosed by the <session-info> element). Also, the same could 
also be done for the <codecs> element. Here, each individual <stream> 
element would list all codecs that were proposed for this stream instead 
of listing the codecs globally in a <codecs> element.

In particular for session-independent policies, the global elements are 
still needed since there are no known individual streams for 
session-independent policies. For session-specific policies, it would be 
possible to list media types and codecs either on a per stream basis 
inside the <streams> element or generally in a <media-types> and 
<codecs> element.

> indicates that it does not need to see the answer.
The policy server can indicate this in an event parameter for NOTIFY
requests. This is defined in the policy event package draft.

Thanks,

Volker