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

From: Volker Hilt <[email-masked]>
Date: Thu, 02 Aug 2007 00:41:58 -0400

Keith,

thanks much for reviewing this document. Comments inline.
> 
> 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.
> 
I've split this up into two separate sentences.

> 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".
> 
I agree. I've added RFC 2119 language to make the implementation of the 
config-framework a MUST.

Another change is that a UA supporting session-independent policies MUST 
attempt to retrieve these policies from i) the local network and ii) the 
SIP service provider domain. This was SHOULD before.

> 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.
> 
I've expanded the table to include all current methods. I've changed the 
requirements for the presence of a header field from optional to 
conditional since the headers need to be used/understood under certain 
conditions.

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

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

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

I've added subsections "UAC Behavior" and "UAS Behavior" and moved the 
paragraphs to the respective subsections.

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

I've removed the RFC 2119 language from 4.4.7.x since it was already 
contained the procedures section above.

> D)	Can you explain why section 3.2 and section 4.5 are so widely
> separated?
> 
3.2 covers session-independent policies whereas section 4.5 covers 
session-specific policies.

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

> 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.
> 
I agree. However, in this particular case, I would prefer to keep it as 
it is. This draft is a framework and refers to other specifications, 
e.g., for the subscriptions to policies. For this reason, it seems 
appropriate to cover the security aspects in one place.

I've added a sentence to the protocol description that recommends the 
use of TLS to protect the Policy-Contact header (previously this was 
only in the security considerations).

> 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.
> 
I've updated the option tag registration accordingly.

> 10)	Can you put the appendixes at the end of the document, thereby
> bringing forward the references and author details.
> 
Done for references. rfc2xml seems to automatically place author details
at the end.

I've made the changes proposed in the NITS below.

Thanks much!

Volker

> 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

---

From: Volker Hilt <[email-masked]>
Date: Thu, 02 Aug 2007 00:41:58 -0400

Keith,

Done.

Done.

Done.

Thanks much!

Volker

>    Session-independent poFrom [email-masked] Thu Aug 02 09:08:08 2007
Date: Thu, 26 Jul 2007 18:09:00 +0530
From: "Shrinivas Shetti" <[email-masked]>
To: [email-masked]
Subject: [Sip] related to RFC3841 (caller prefs)

--===============0530734656==
Content-Type: multipart/alternative; 
	boundary="----=_Part_112519_27176631.1185453540701"

------=_Part_112519_27176631.1185453540701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have a dumb query.

Does this spec forbid SIP response carry accept/reject-contact headers?

Table in section 9 mentions its applicability to only requests. Does that
mean responses MUST NOT carry this header?

OR

It is OK to carry these headers in response?

There is no other statement I could find in spec related to this aspect.

Thanks in advance,
Shetti

------=_Part_112519_27176631.1185453540701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>I have a dumb query.</div>
<div>&nbsp;</div>
<div>Does this spec forbid SIP response carry accept/reject-contact headers?</div>
<div>&nbsp;</div>
<div>Table in section 9 mentions its applicability to only requests. Does that mean responses MUST NOT carry this header?</div>
<div>&nbsp;</div>
<div>OR</div>
<div>&nbsp;</div>
<div>It is OK to carry these headers in response?</div>
<div>&nbsp;</div>
<div>There is no other statement I could find in spec related to this aspect.</div>
<div>&nbsplicies are policies that are created
>    orthogonal a policy enforcement infrastruc;</div>
<div>Thanks in advance,</div>
<div>Shetti</div>

------=_Part_112519_27176631.1185453540701--

--===============0530734656==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0530734656==--

---

From: Volker Hilt <[email-masked]>
Date: Thu, 02 Aug 2007 00:41:58 -0400

Keith,

Another change is that a UA supporting sesture.  Their goal is to
>  sion-independent policies MUST 

Done.

Done.

Done.

Thanks much!

Volker

> Here) response" rather than any abbreviated   the most recent one received in a Policy-Contact header.
> 

_______________________________________________
Sip mailing lform on all occurrences.
>    Session-independent poist  https://www1.ietf.org/mailman/listinfo/sip