Draft: draft-ietf-sipping-session-policy-framework-01 Reviewer: Bob Penfield Review Date: August 22, 2006 Review Deadline: August 26, 2006 Status: Initial review Summary: This draft is on the right track but has open issues, described in the review. [ISSUE-1] Dependence on Config Framework documents On Page 6, Section 3.2: It says: A UA compliant to this specification MUST support the User Agent Profile Data Set for Media Policy [3] and the Schema for SIP User Agent Profile Data Sets [8]. This MUST makes [8] (draft-petrie-sipping-profile-datasets-03) a normative reference. That document is not (yet?) a working group document and has also expired. What is the plan for [8]? Also, I could not find a definition for "the MIME type of the Schema for SIP User Agent Profile Data Sets" in the other documents ([4] or [8]). [ISSUE-2] Normative text on disclosing answer to policy server On Page 14, Section 4.4.1. It says: A UA SHOULD generally disclose the offer and the answer to the policy server. However, the policy server may indicate on the policy channel (after receiving the offer) that the disclosure of the answer is not needed for this session. In this case, the UAC MAY skip the disclosure of the answer for this particular session. Why is the last sentence a MAY? If the policy server indicated it did not need/want to see the answer, the UA SHOULD NOT disclose the answer. Suggest rewording as follows: A UA SHOULD disclose the offer to the policy server. A UA SHOULD disclose the answer to the policy server, unless the policy server has indicated on the policy channel (when processing the offer) that the disclosure of the answer is not needed for this session. When disclosing the answer to the policy servers, the UA MUST contact the same policy servers it has contacted for the offer. Also, on Page 15, Section 4.4.3. It says: If the UAS receives an ACK containing an answer, it SHOULD contact the policy servers again with the answer. In this case, it MUST contact the same policy servers it has contacted for the offer. However, the policy server may have indicated in response to the offer that the disclosure of the answer is not needed for this session. In this case, the UAS MAY skip the disclosure of the answer for this particular session. Suggest: If the UAS receives an ACK containing an answer, it SHOULD contact the policy servers again with the answer, unless the policy server indicated in response to the offer that the disclosure of the answer is not needed for this session. When disclosing the answer to the policy servers, the UAS MUST contact the same policy servers it has contacted for the offer. [ISSUE-3] UA Behavior for PRACK needed In Section 4.4.1 (UAC Behavior) there should be procedures for an answer in a PRACK for a 1xx reliable provisional response which contained the offer. These would be similar to the procedures for ACK. This also applies to Section 4.4.3 (UAS Behavior). I wonder if it might be better to say "a request containing a session description", rather that specifying INVITE, UPDATE, ACK and PRACK as the only methods the procedures apply to (although ACK, PRACK, and INVITE responses still need special consideration). [ISSUE-4] Caching requirements for UAS Section 4.4.2 talks about UACs caching/storing the policy server URI. Shouldn't the UAS also cache/store the policy server URIs it learns from the Policy-Contact header(s) in an INVITE or UPDATE request for use in re-INVITE/UPDATE toward the calling party? [ISSUE-5] Header Definition and Syntax Since the policy server is always contacted using SUBSCRIBE/NOTIFY, the policy server URI should be a SIP or SIPS URI rather than an absoluteURI. Also, the header syntax should account for possible future header field parameters. [ISSUE-6] Security Considerations The Security Considerations section is a good start, but it needs work. It needs to be a bit more organized in identifying the specific treats using the terminology in RFC 3552. Also, normative requirements language needs to be used in the recommendations to mitigate the identified threats. [Editorial] Sections 4.4.1 thru 4.4.3 (UA Behavior) If caching applies to the UAS too, you may want to have a "User Agent Behavior" section that describes the general UA behavior and then UAC and UAS behavior sub-sections. Also, there is normative text in the UAC section that applies to UAs in general that should be in the general UA behavior section. [Editorial] Section 4.4.2: Caching of Policy Server URIs This section talks about "caching" policy server URIs and "storing" them in the session state. Readers might confuse these two. Suggest adding text which clarifies that "caching" means remembering the URIs across multiple sessions and that the URIs are "stored" in session state even when the "non-cacheable" parameter is present. [Editorial] On Page 4, Section 1, it says: Since these policies are not based on a specific session description, they can be created independent of an attempt to set up a session and only need to be conveyed to the user agent once (e.g. at the time the device is powered on). However, the UA is also informed when the policy changes. Suggest: ... and only need to be conveyed to the user agent when it initializes (e.g. at the time the device is powered on) and when the policies are changed. [Editorial] On Page 5, Section 3.1, it says: The local network may, for example, have policies that support the access network infrastructure (e.g. in a wireless network where bandwidth is scarce, a provider may restrict the bandwidth available to an individual user) Suggest the following text might read better: The local network may have policies that support the access network infrastructure. For example, in a wireless network where bandwidth is scarce, a provider may restrict the bandwidth available to an individual user. [Editorial] On Page 5, Section 3.1, it says: Thus, in most cases, a UA will receive session-independent policies from one or at most two policy servers. Suggest removal of "at most" as this implies that there will never be more than two policy servers. [Editorial] On Page 14, Section 4.4.2, there is a typo (s/is/it/) Change: The UAC SHOULD store the list of policy server URIs is has contacted To: The UAC SHOULD store the list of policy server URIs it has contacted [Editorial] On Page 18, Section 4.5, it says: If this update causes a change in the session description of a session, the UA may need to generate a re-INVITE or UPDATE message to re-negotiate the modified session description with its peer UA. You should probably mention that the re-INVITE/UPDATE message is generated in accordance with section 4.2 (i.e. it will contain a Policy-Id header with the policy server URI that sent the updated policy).