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

From: Volker Hilt <[email-masked]>
Date: Wed, 08 Aug 2007 21:44:37 -0400

Shida,

thanks much for reviewing this document. Comments inline.
> 
> Clarifications needed:
> ------
> C1) Section 4.4.1, 2nd para, 2nd last sentence.
> - not receiving policy and not receiving any response the same thing?
>   > If not may want to clarify this.

Clarified that a UA MAY continue with a session if the policy server is
unreachable or returns a non-correctable error response.

>   C2) Section 4.4.1  The token is mentioned everywhere, but looking at 
> the event packages there is no token defined. Do you expect token to be 
> something implicit that administrator somehow configures the policy 
> server and UA so they implicitly know what token is and how to find it 
> in the policy provided by the policy server? I understand that token 
> itself may have flexibility in its value, but where to look for the 
> token SHOULD be specified explicitly.
> 
A token can be delivered as part of the media policy data set (I just
noticed that an element for the token is missing there!). I've added a
reference to the media policy data set.

> C3) Section 4.4.1
> For existing dialog, what is the impact of policy channel failing?
>  > Would it affect the whole dialog or just the usage?
>  > Currently it reads like it would affect the dialog which may not    
> be desirable. (Section 4.4.6 reads "This means
>   that, the UA MUST cancel or reject a pending INVITE transaction for
>   the session or terminate the session if it is already in progress."
> 
>     e.g) UAC tries to change the codec mid-dialog          > sends the 
> new SDP to policy server          > Policy server is offline or returns 
> global class error
>          > What happens now?

I've added a similar wording as in C1) to Section 4.4.6. A UA SHOULD
continue if the policy server is unreachable.

> C4) Section 4.4.2
> Proxy's behavior on policy-id and token is completely missing.
> paragraph 2 notes how proxy MUST NOT reject the request if the policy-id 
> contains the associated policy server's URI but on section 4.4.1, there 
> is enough text describing how some proxy may base their pass-through on 
> token, so I think text on proxy behavior surrounding token in this 
> section is an appropriate addition.
> 
I've moved most of the text describing the use of the policy-id header
in conjunction with tokens for routing from Section 4.4.1 to Section
4.4.2. This should also take care of nit N3.

> C5) Section 4.4.2
> It may be appropriate to add some text on RR by proxy wanting to ensure 
> UA passes the same proxies/policy servers, rather than UA maintaining a 
> list of policy servers to contact mid-dialog. 

Good point. I think a proxy should RR to ensure that the UA keeps
contacting its policy server for mid-dialog requests. I've added text
for this to 4.4.2

> UA always contacting the 
> same policy servers contacted at the initial session setup, even after 
> the signaling path has changed seems unreasonable and ineffective.
> 
> * I don't have a strong opinion on this, don't mind the current   spec 
> but wondered if you considered this.

I think the current draft does a poor job on explaining what a UA should
do with the discovered policy servers. There a two things: a UA needs to
set up the policy channel and disclose the current session description.
Whenever the session description changes, it needs to use the policy
channels (i.e. subscriptions) it has established to policy servers and
disclose the new session description. In addition, it may need to set up
a new policy channel if a new server URI is discovered.

I've reorganized the policy channel section to better address this and
moved sections 4.4.5 and 4.4.6 into this section.

> C6) Section 4.4.3 As UAS does not use the policy-Id, text SHOULD be 
> added to mention that if the list of policy server changes in mid-dialog 
> that it should contact the policy servers again. (Text can be added 
> instead in section 4.4.5 - last paragraph encouraging the re-visit to 
> the policy servers)
> 
> * This is not problematic with UAC as proxy would return 488 with   
> policy server URI, alerting the UAC that list of policy server   that 
> need to be contacted have changed.
> 
The UAS will learn about a changed list via the Policy-Contact header in
incoming requests. Section 4.4.3 says that a UAS must contact the policy
servers listed in the Policy-Contact header. Thus, if this list changes
mid-dialog, the UAS will automatically contact the new list of policy
servers.

I've made the changes described in the nits below.

Thanks much!

Volker

> 
> 
> 
> Nits/Editorials:
> ------
> N1) Section 1, 1st para, 2nd sentence.
> [page mode messaging is not divorced from the actual session]
> 
> OLD: However, proxies are divorced from the actual sessions -   audio, 
> video, and messaging - that SIP establishes.
> 
> NEW: However, proxies are divorced from the actual sessions -   audio, 
> video, and session mode messaging - that SIP establishes.
> 
> N2) Section 1, 1st para, last sentence.
> Text on S/MIME plays no roles here, its context seems kind of odd. I 
> believe the text only causes confusion thus should be removed.
> 
> N3) Section 4.4.1, 4th - 6th para
> Seems out of place. These paragraphs focus on policy-id usage and its 
> purpose, it should go into section 4.4.7.1.
> 
> N4) Section 4.4.1, 5th para 2nd sentence.
> [proxies > proxy]
> 
> N5) Section 4.4.1, 5th para, last sentence.
> [unnecessary "that"]
> 
> OLD: combination that has configured the associated
> NEW: combination has configured the associated
> 
> N6) Section 4.4.2, 2nd para, 2nd sentence
> [this policy server > associated policy server]
>  
> OLD: The proxy SHOULD remove the Policy-Id header value for   this 
> policy server from the Policy-Id header field before   forwarding the 
> request.
> NEW: The proxy SHOULD remove the Policy-Id header value for   the 
> assocaited policy server from the Policy-Id header   field before 
> forwarding the request.
> N7) Section 4.4.6, 1st para, 1st sentence
> [add MUST before apply]
> 
> OLD: A UA compliant to this specification MUST contact the discovered
>   policy servers and apply session policies to an offer or answer
>   before using the offer or answer.
> 
> NEW: A UA compliant to this specification MUST contact the discovered
>   policy servers and MUST apply session policies to an offer or answer
>   before using the offer or answer.
> 
> N8) Section 4.4.6, last para
> 
> OLD: A UA MUST inform the policy server when a session is terminated via
>   the policy channel.  This enables a policy server to free all
>   resources it may have allocated for this session.  A policy server
>   can indicate via the policy channel that it does not need to be
>   contacted at the end of a session.  In this case, the UA SHOULD NOT
>   inform the policy server about the termination of the session.
> 
> NEW: A UA MUST inform the policy server when a session is terminated via
>   the policy channel unless, a policy server
>   indicates via the policy channel that it does not need to be
>   contacted at the end of a session. This enables a policy server to 
> free all
>   resources it may have allocated for this session.
> 
> 
> 
> 
> _______________________________________________
> 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

-- 
Volker Hilt                      Bell Labs / Alcatel-Lucent
phone: +1 732 888 7206           791 Holmdel-Keyport Rd
email: [email-masked]     Holmdel, NJ 07733

_______________________________________________
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