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

From: Shida Schubert <[email-masked]>
Date: Tue, 12 Jun 2007 12:25:48 -0700

Draft:  draft-ietf-sip-session-policy-framework-01
Reviewer: Shida Schubert
Review Date: 11 June 2007
Review Deadline: 11 June 2007
Status: WGLC

I apologize for submitting the review past deadline.

Summary: This draft is basically ready for publication, but has nits 
and some clarification that should be fixed/added before publication. 

Comments:
----------
I reviewed the diff for this document as compared to the version 
I previously reviewed:

 I believe all my previous concerns have been addressed. I also 
re-read the document through which I found some areas that need some 
clarifications and additional nits/editorials.

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

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? 

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.

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

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.

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