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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
