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

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 13 Jun 2007 17:05:56 +0200

COMMENTS:

1)	Section 4.4.7.2:

   A proxy MAY add the "non-
   cacheable" header field parameter to indicate that a UA MUST NOT
   cache this policy server URI.

You are either mixing a proxy requirement and a UA requirement in the
same sentence here, or we have one instance two many of RFC 2119
language. Either way, what we have is the wrong of writing it.

2)	For reference [4] config-framework, I am missing any RFC 2119
language round it. I think we are saying "provides the only way of"
rather than "provides one means of" therefore I would have expected a
"MUST implement".

3)	Section 4.4:

If we show the table of support in methods, I would prefer we show all
the current methods, and therefore show all the "-". There are other SIP
documents you can use as a template.

4)	Update reference [7] from RFC 2327 to RFC 4566. There does not
seem to be any need to reference the older version.

5)	With regard to reference [8] RFC 3264 the text:

   A UAC compliant to this specification MUST include a Supported header
   field with the option tag "policy" into all requests that can
   initiate an offer/answer exchange [8] (e.g.  INVITE, UPDATE and PRACK
   requests). 

Makes this a normative reference rather than an informative reference.

6)	One of the requirements of RFC 4485 (Guidelines to SIP authors)
is to clearly structure the requirements relating to each entity. 

A)	I see a mixture of requirements for UAC and policy server in
section 3.2, and some of the requirements apply to both. 
B)	In section 4.4.7.1 can you move the RFC 2119 requirement to the
appropriate procedures section. 
C)	The same applies for section 4.4.7.2. 
D)	Can you explain why section 3.2 and section 4.5 are so widely
separated?

7)	Section 3.2:

   The session-independent policies contained in a
   notification MUST represent a complete session-independent policy.
   Deltas to previous policies or partial policies are not supported. 

Seems to be primarily a sending requirement (i.e. for the policy
server). Please write "The policy server MUST..." and if there is a
separate receiver (UAC) requirement, then draft a separate statement.

8)	There are two ways of doing the requirements for security. One
is to put all the RFC 2119 language relating to security in the security
considerations section, which is apparently what this draft does. The
other is to integrate these requirements in the procedures and reflect
on the security support given by these requirements in the security
considerations section. I prefer the latter - it makes it harder for an
implementor to ignore the security requirements.

9)	I don't like the semantics of the option tag registration. I
would prefer to relate this to support of particular procedures, rather
than support of the headers. Support of headers is a bit nebulous - a
proxy supports it if it passes it on transparently. A UA supports it if
it renders the contents to a user.

10)	Can you put the appendixes at the end of the document, thereby
bringing forward the references and author details.

NITS:

1)	For all response code usage, use the form "488 (Not Acceptable
Here) response" rather than any abbreviated form on all occurrences.
	
2)	There seems to be a significant usage of "it" in statements with
RFC 2119 language, as in 
   
   It SHOULD store
   policy server URIs in this list even if they are marked as "non-
   cacheable"

Please use the name of entity even if it was included in the conditional
at the start of the sentence, or in a previous sentence.

3)	In all references made from the text, rather than statements of
the form

	(e.g. according to [6])

Can we use either:

	(e.g. according to RFC 3261 [6])

Or

	(e.g. according to [RFC3261])

To save having to refer to the list at the end of the document.

4)	Please deal with idnits as identified below:

--------------------------------------------------------------------

idnits 2.04.09 

tmp/draft-ietf-sip-session-policy-framework-01.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
 
------------------------------------------------------------------------
----

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
------------------------------------------------------------------------
----

     No issues found here.

  Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == Line 952 has weird spacing: '...  where   prox...'

  == The document seems to lack the recommended RFC 2119 boilerplate,
even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph
with
     a matching beginning. Boilerplate error?

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).

  Checking references for intended status: Proposed Standard
 
------------------------------------------------------------------------
----

     (See RFC 3967 for information about using normative references to
     lower-maturity documents in RFCs)
  -- Possible downref: Normative reference to a draft: ref. '2'  (No
intended
     status found in state file of draft-ietf-sipping-policy-package)

  == Outdated reference: A later version (-04) exists of
     draft-ietf-sipping-media-policy-dataset-02

  -- Possible downref: Normative reference to a draft: ref. '3'  (No
intended
     status found in state file of
draft-ietf-sipping-media-policy-dataset)

  == Outdated reference: A later version (-12) exists of
     draft-ietf-sipping-config-framework-10

  -- Obsolete informational reference (is this intentional?): RFC 2327
(ref.
     '7') (Obsoleted by RFC 4566)

------------------------------------------------------------------------
-----

5)	I suspect you will need to update the address for Jonathan
Rosenberg.

6)	Section 1:

   However, experience has shown that there is a need for SIP
   intermediaries to impact aspects of a session.  For example, SIP may
   be used in a wireless network, which has limited resources for media
   traffic.

Change "may" --> "can"

Also same paragraph:

   Similarly, a
   network provider may have a service level agreement with a user that
   defines the set of media types a user can use. 

Change "may" --> "can"

Also section 1:

   Domains often enforce the session policies they have in place.  For
   example, a domain might have a policy that disallows the use of video
   and may enforce this policy by dropping all packets that contain a
   video encoding. 

Change "may" --> "can"

And same paragraph

   This may
   lead to a malfunctioning of devices that is incomprehensible to the
   user.

Change "may" --> "can"

7)	Section 3:

   Session-independent policies are policies that are created
   independent of a session and generally apply to all sessions a user
   agent is setting up.  They typically remain stable for a longer
   period of time and apply to any session set up while they are valid.
   However, session-independent policies may also change over time. For
   example, a policy that defines a bandwidth limit for a user may
   change during the day, defining a lower limit during peak hours and
   allow more bandwidth off-peak.

Change "may" --> "can" twice.

8)	Section 3.1

   A SIP UA may receive session-independent policies from one or more
   policy servers.  In a typical configuration, a UA receives session-
   independent policies from a policy server in the access or local
   network domain (i.e. the domain from which the UA receives IP
   service) and possibly the home network domain (i.e. the domain the UA
   registers at).  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.  The home network may have policies
   that are needed to support services or policies that reflect the
   service level agreement with the user.  Thus, in most cases, a UA
   will receive session-independent policies from one or two policy
   servers.

Change "may" --> "can" three times.

   2.  The policy server selects the policies that apply to this user
       agent.  The policy server may have general policies that apply to
       all users or maintain separate policies for each individual user.
       The selected policies are returned to the user agent.
   3.  The policy server may update the policies, for example, when
       network conditions change.

Change "may" --> "can" twice.

9)	Section 3.2:

   A change in the policy may be triggered, for
   example, by a change in the network status, by the change in the time
   of day or by an update of the service level agreement with the
   customer.

Change "may" --> "can"

10)	Section 4:

   Session-specific policies are policies that are created specifically
   for one particular session of a UA.  Thus, session-specific policies
   will typically be different for different sessions.  The session-
   specific policies for a session may change during the course of the
   session.  For example, a user may run out of credit during a session,
   which will cause the network to disallow the transmission all media
   streams from this point on.

Change "may" --> "can" twice.

11)	Section 4.1:

   The policy server is a separate logical entity that may be physically
   co-located with the proxy.  The role of the policy server is to
   deliver session policies to UAs.  The policy server receives session
   information from the UA, uses this information to determine the
   policies that apply to the session and returns these policies to the
   UA.  The mechanism for generating policies (i.e. making policy
   decisions) is outside of the scope of this specification.  A policy
   server may, for example, query an external entity to get policies or
   it may directly incorporate a policy decision point and generate
   policies locally.

Change "may" --> "can" three times.

And in the same section:

   A UA receives the URI of a policy server from a proxy.  It uses this
   URI to contact the policy server.  It provides information about the
   current session to the policy server and receives session policies in
   response.  The UA may also receive policy updates from the policy
   server during the course of a session.

Change "may" --> "can"

   A network may have a policy enforcement infrastructure in place.
   However, this specification does not make any assumptions about the
   enforcement of session policies and the mechanisms defined here are
   orthogonal a policy enforcement infrastructure.  Their goal is to
   provide a mechanism to convey session information to a policy server
   and to return the policies that apply to a session to the UA.

Change "may" --> "can"

12)	Section 4.2:

   In many cases, the mechanism for session-specific policies will be
   used to disclose session information and return session policies.
   However, some scenarios may only involve the disclosure of session
   information to a network intermediary.  If an intermediary does not
   intend to return a policy, it can simply accept the session as it was
   proposed.  Similarly, some session-specific policies only apply to
   the offer (and therefore only require the disclosure of the offer)
   whereas others apply to offer and answer.  Both types of policies are
   supported by session-specific policy mechanism.

Change "may" --> "can"

13)	Section 4.4.1:

   A UAC may receive a 488 response that contains a Policy-Contact
   header field.

Change "may" --> "can"

   The token is an opaque
   string the UAC may have received from the policy server after
   contacting it.

Change "may" --> "can"

      Note: it has been proposed to use the Policy-Id header to provide
      a hint for a proxy that the UAC has actually contacted the policy
      server.  This usage also requires the policy server to return a
      token to the UA.  In addition, the policy server needs to share
      valid tokens with the proxy.  After receiving a request with a
      Policy-Id header, the proxy can determine if the token in the
      Policy-Id header is valid.  If it is valid, the proxy knows that
      the UA has contacted the policy server for this session.  However,
      it is important to note that this token does not provide any proof
      that the UA has actually used the policies it has received from
      the policy server.  A malicious UA may simply contact the policy
      server, discard all policies it receives but still use the token
      in the Policy-Id header.

Change "may" --> "can"
Delete: "it is important to note that".

   In some cases, a request may traverse multiple domains with session-
   policies in place.  Each of these domains may return a 488 response
   containing a policy server URI.

Change "may" --> "can" twice.

   A UA may decide to change the session description of a session and to
   initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE
   or PRACK requests) to re-negotiate the session description. 

Change "may" --> "can"

14)	Section 4.4.2:

   If the local policy server URI is present in a Policy-Id header value
   of a request, then the proxy MUST NOT reject the request as described
   above (it may still reject the request for other reasons).

Change "may" --> "can"

15)	Section 4.4.3:

   A UAS may receive an INVITE, UPDATE or PRACK request (or another
   request that can initiate offer/answer exchanges), which contains a
   Policy-Contact header filed with a list of policy server URIs.

Change "may" --> "can"

   A UAS may receive a token from a policy server via the policy
   channel.  Since the UAS does not create a Policy-ID header, it can
   simply ignore this token.

Change "may" --> "can"

16)	Section 4.4.4:

   A UAC may frequently need to contact the policy server in the local
   domain before sending a request.  To avoid the retransmission of the
   local policy server URI for each new request, a UA SHOULD maintain a
   cache that contains the URI of the local policy server.  A UA may
   receive this URI in a Policy-Contact header of a request or a 488
   response.  The UA may also receive the local policy server URI
   through configuration, for example, via the configuration framework
   [4].  If a UA has received a local policy server URI through
   configuration and receives another local policy server URI in a
   Policy-Contact header, it SHOULD overwrite the configured URI with
   the most recent one received in a Policy-Contact header.

Change "may" --> "can" three times.

   The UA SHOULD NOT cache policy server URIs it has received from
   proxies outside of the local domain.  These policy servers may not be
   relevant for subsequent sessions, which may go to a different
   destination, traversing different domains.

Change "may not" to "need not"
Change "may" --> "can"

   The UA MUST NOT cache tokens it may receive from a policy server.  A
   token is only valid for one request.

Change "may" --> "can"

17)	Section 4.4.6:

      Note: this assumes that the policy server can always respond
      immediately to a policy request and does not require manual
      intervention to create a policy.  This will be the case for most
      policy servers.  If, however, a policy server cannot respond with
      a policy right away, it may return a policy that temporarily
      denies the session and update this policy as the actual policy
      decision becomes available.  A delay in the response from the
      policy server to the UA would delay the transmission of the ACK
      and could trigger retransmissions of the INVITE response (also see
      the recommendations for Flow I in [9]).

Change "may" --> "can"

   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.

Change "may have" --> "has"

18)	Section 4.4.7.1:

   The value of a Policy-Id header consists of a policy server URI.  A
   Policy-Id header value may have an optional token parameter.  The
   token parameter contains a token the UA may receive from the policy
   server.  

Change "may have" --> "can have"
Change "may receive" --> "received" 

19)	Section 4.5:

   If the policy update causes a change in the session
   description of a session, the UA may need to re-negotiate the
   modified session description with its peer UA, for example, using a
   re-INVITE or UPDATE request.

Change "may need" to "needs".

20	Section 5:

   Session policies can significantly change the behavior of a user
   agent and can be used by an attacker to compromise a user agent.  For
   example, session policies can be used to prevent a user agent from
   successfully establishing a session (e.g. by setting the available
   bandwidth to zero).  Such a policy can be submitted to the user agent
   during a session, which may cause the UA to terminate the session.

Change "may cause" to "causes".

   A user agent transmits session information to a policy server for
   session-specific policies.  This session information may contain
   sensitive data the user may not want an eavesdropper or an
   unauthorized policy server to see.  For example, the session
   information may contain the encryption keys for media streams.  Vice
   versa, session policies may also contain sensitive information about
   the network or service level agreements the service provider may not
   want to disclose to an eavesdropper or an unauthorized user agent.

Change "may contain" to "can contain" twice
Change "may not" to "does not" twice
Change "may also" to "can also"

   This would impede the rendezvous between UA and policy server and,
   since the UA would not contact the policy server, may prevent a UA
   from setting up a session.

Change "may" to "can"

   Policy servers SHOULD authenticate UAs to protect the information
   that is contained in a session policy.  However, a policy server may
   also frequently encounter UAs it cannot authenticate. 

Change "may" to "can"

_______________________________________________
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