Subject: [Sipping] Review of draft-ietf-sipping-session-policy-framework-01

From: "Mary Barnes" <[email-masked]>
Date: Fri, 25 Aug 2006 20:05:10 -0500

Draft:  draft-ietf-sipping-session-policy-framework-01
Reviewer: Mary Barnes
Review Date: 25 Aug 06
Review Deadline: 25 Aug 06
Status: Initial review 

Summary: This draft is almost ready for publication, but needs some
clarifications and has nits that should be fixed before publication.

The requested clarifications are listed first:

Section 4.4.2, 1st paragraph, last sentence.  It mentions that "The UAC
SHOULD contact the cached local policy server URI when creating a new
INVITE or UPDATE
request, before they are sent."   I'm wondering if this shouldn't be a
MUST or the conditions and consequences for when it would be okay to not
contact the cached local policy should be stated. 

Section 4.4.4, 3rd paragraph, last sentence.  Can that SHOULD be changed
to a MUST?   Otherwise, the consequences of not removing that policy
server URI should be described.

Editorial nits:
---------------

General:  Add figure #s and appropriate figure references for the flows.

Abstract:
- I would suggest combining the 2nd and 3rd sentences into a more
definitive statement about what the functionality in this document.

OLD:
  However, there is currently no standard mechanism by which a proxy can
define 
  or influence policies on sessions such as the codecs or media types to
  be used.  This document specifies a framework for SIP session
  policies that provides this capability to proxies. 

NEW:
  This document specifies a framework for SIP session
  policies that provides a standard mechanism by which a proxy can
define 
  or influence policies on sessions, such as the codecs or media types
to
  be used. 

- It might also be useful to highlight the new protocol mechanisms in
the abstract. 

Section 1:
- 6th paragraph, 1st sentence: I would suggest adding "all" to qualify
"the SIP sessions":
OLD:
   Session-independent policies on the other hand are policies that are
   created independent of a session and generally apply to the SIP
   sessions set up by a user agent.
NEW: 
   Session-independent policies on the other hand are policies that are
   created independent of a session and generally apply to all the SIP
   sessions set up by a user agent.

Section 3: 
- 1st sentence: I would suggest adding "all" to qualify "the sessions":
OLD:
   Session-independent policies are policies that are created
   independent of a session and generally apply to the sessions a user
   agent is setting up. 

NEW:
   Session-independent policies are policies that are created
   independent of a session and generally apply to all the sessions a
user
   agent is setting up. 

- 2nd sentence: I would suggest changing "the sessions" to "any
sessions":
OLD:
   They typically remain stable for a longer period of time and apply 
   to the sessions set up while they are valid.
NEW: 
   They typically remain stable for a longer period of time and apply 
   to any sessions set up while they are valid.

Section 3.2:
- 2nd paragraph, 3rd sentence: the use of the semi-colon doesn't make
sense.  Should that be replaced with "and"?  

Section 4.2:
- 2nd paragraph, 3rd sentence: remove the text in parenthesis (2
occurences) and
insert commas:
OLD: 
   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).
NEW:
   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.   

Section 4.4.3:
- 1st paragraph, 1st sentence: change lowercase "may" to uppercase "MAY"

Section 5, Security Considerations:
- 4th paragraph, 1st sentence.  Suggest to change the lower case should
to SHOULD. 

- 5th paragraph, 2nd sentence, insert "a" in the sentence.  
OLD:
   An attacker can use this mechanism to refer a UA to compromised
policy server.
NEW:
   An attacker can use this mechanism to refer a UA to a compromised
policy 
   server.                             

_______________________________________________
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