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

From: "Bob Penfield" <[email-masked]>
Date: Tue, 22 Aug 2006 14:00:48 -0400

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

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

_______________________________________________
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