Shida,
thanks much for reviewing this document. Comments inline.
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.
Clarified that a UA MAY continue with a session if the policy server is
unreachable or returns a non-correctable error response.
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.
A token can be delivered as part of the media policy data set (I just
noticed that an element for the token is missing there!). I've added a
reference to the media policy data set.
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?
I've added a similar wording as in C1) to Section 4.4.6. A UA SHOULD
continue if the policy server is unreachable.
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.
I've moved most of the text describing the use of the policy-id header
in conjunction with tokens for routing from Section 4.4.1 to Section
4.4.2. This should also take care of nit N3.
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.
Good point. I think a proxy should RR to ensure that the UA keeps
contacting its policy server for mid-dialog requests. I've added text
for this to 4.4.2
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.
I think the current draft does a poor job on explaining what a UA should
do with the discovered policy servers. There a two things: a UA needs to
set up the policy channel and disclose the current session description.
Whenever the session description changes, it needs to use the policy
channels (i.e. subscriptions) it has established to policy servers and
disclose the new session description. In addition, it may need to set up
a new policy channel if a new server URI is discovered.
I've reorganized the policy channel section to better address this and
moved sections 4.4.5 and 4.4.6 into this section.
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.
The UAS will learn about a changed list via the Policy-Contact header in
incoming requests. Section 4.4.3 says that a UAS must contact the policy
servers listed in the Policy-Contact header. Thus, if this list changes
mid-dialog, the UAS will automatically contact the new list of policy
servers.
I've made the changes described in the nits below.
Thanks much!
Volker
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
--
Volker Hilt Bell Labs / Alcatel-Lucent
phone: +1 732 888 7206 791 Holmdel-Keyport Rd
email: [EMAIL PROTECTED] Holmdel, NJ 07733
_______________________________________________
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
