Draft: draft-ietf-sip-session-policy-framework-01
Reviewer: Shida Schubert
Review Date: 11 June 2007
Review Deadline: 11 June 2007
Status: WGLC
I apologize for submitting the review past deadline.
Summary: This draft is basically ready for publication, but has nits
and some clarification that should be fixed/added before publication.
Comments:
----------
I reviewed the diff for this document as compared to the version
I previously reviewed:
I believe all my previous concerns have been addressed. I also
re-read the document through which I found some areas that need some
clarifications and additional nits/editorials.
Clarifications needed:
------
C1) Section 4.4.1, 2nd para, 2nd last sentence.
- not receiving policy and not receiving any response the same thing?
> If not may want to clarify this.
C2) Section 4.4.1
The token is mentioned everywhere, but looking at the event packages
there is no token defined. Do you expect token to be something implicit
that administrator somehow configures the policy server and UA so they
implicitly know what token is and how to find it in the policy provided
by the policy server? I understand that token itself may have flexibility
in its value, but where to look for the token SHOULD be specified explicitly.
C3) Section 4.4.1
For existing dialog, what is the impact of policy channel failing?
> Would it affect the whole dialog or just the usage?
> Currently it reads like it would affect the dialog which may not
be desirable. (Section 4.4.6 reads "This means
that, the UA MUST cancel or reject a pending INVITE transaction for
the session or terminate the session if it is already in progress."
e.g) UAC tries to change the codec mid-dialog
> sends the new SDP to policy server
> Policy server is offline or returns global class error
> What happens now?
C4) Section 4.4.2
Proxy's behavior on policy-id and token is completely missing.
paragraph 2 notes how proxy MUST NOT reject the request if the
policy-id contains the associated policy server's URI but on section
4.4.1, there is enough text describing how some proxy may base their
pass-through on token, so I think text on proxy behavior surrounding
token in this section is an appropriate addition.
C5) Section 4.4.2
It may be appropriate to add some text on RR by proxy wanting to
ensure UA passes the same proxies/policy servers, rather than UA
maintaining a list of policy servers to contact mid-dialog. UA
always contacting the same policy servers contacted at the initial
session setup, even after the signaling path has changed seems
unreasonable and ineffective.
* I don't have a strong opinion on this, don't mind the current
spec but wondered if you considered this.
C6) Section 4.4.3
As UAS does not use the policy-Id, text SHOULD be added to
mention that if the list of policy server changes in mid-dialog that
it should contact the policy servers again. (Text can be added
instead in section 4.4.5 - last paragraph encouraging the re-visit
to the policy servers)
* This is not problematic with UAC as proxy would return 488 with
policy server URI, alerting the UAC that list of policy server
that need to be contacted have changed.
Nits/Editorials:
------
N1) Section 1, 1st para, 2nd sentence.
[page mode messaging is not divorced from the actual session]
OLD: However, proxies are divorced from the actual sessions -
audio, video, and messaging - that SIP establishes.
NEW: However, proxies are divorced from the actual sessions -
audio, video, and session mode messaging - that SIP establishes.
N2) Section 1, 1st para, last sentence.
Text on S/MIME plays no roles here, its context seems kind of odd.
I believe the text only causes confusion thus should be removed.
N3) Section 4.4.1, 4th - 6th para
Seems out of place. These paragraphs focus on policy-id usage and
its purpose, it should go into section 4.4.7.1.
N4) Section 4.4.1, 5th para 2nd sentence.
[proxies > proxy]
N5) Section 4.4.1, 5th para, last sentence.
[unnecessary "that"]
OLD: combination that has configured the associated
NEW: combination has configured the associated
N6) Section 4.4.2, 2nd para, 2nd sentence
[this policy server > associated policy server]
OLD: The proxy SHOULD remove the Policy-Id header value for
this policy server from the Policy-Id header field before
forwarding the request.
NEW: The proxy SHOULD remove the Policy-Id header value for
the assocaited policy server from the Policy-Id header
field before forwarding the request.
N7) Section 4.4.6, 1st para, 1st sentence
[add MUST before apply]
OLD: A UA compliant to this specification MUST contact the discovered
policy servers and apply session policies to an offer or answer
before using the offer or answer.
NEW: A UA compliant to this specification MUST contact the discovered
policy servers and MUST apply session policies to an offer or answer
before using the offer or answer.
N8) Section 4.4.6, last para
OLD: 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.
NEW: A UA MUST inform the policy server when a session is terminated via
the policy channel unless, a policy server
indicates via the policy channel that it does not need to be
contacted at the end of a session. This enables a policy server to free all
resources it may have allocated for this session.
_______________________________________________
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
