Subject: [Sip] Comments on Resource-Priority -07

From: [email-masked]
Date: Wed, 30 Mar 2005 16:49:14 -0500

I have the following comments on the -07 version of Resource-Priority header which was posted for review on March 16 to begin the normal 2 week Last Call.

1. Nits

Section 1, 7th paragraph (beginning "This document defines...") needs to be rewritten to refer to the two headers which this document defines.

Section 4.6.5 wording of 2nd sentence is incomplete.

Section 10.4 word "layer" should be "level" and the word "and" should be added after "priority".

2. Major problems

Section 4.2, rule 1 indicates that, if there is no resource shortage at the moment, the following steps are omitted. However, the following steps are the authorization/authentication steps which must always be done first. Since one of the results of requesting a priority level, even when there is no resource shortage known to the originating end, is to include the precedence level for use in the remainder of the call. For example, the level requested may prevent a later preemption after a shortage of resources occurs. Rule 1 should simply be the final sentence.

Section 4.7.3 refers to the use of "forking" with the resource-priority header. This is a major problem, since forking of a high precedence marked INVITE in a domain that performs preemption could result in preemption of multiple existing sessions when only one is needed to complete the call. Somehow, forking must be prevented.

Section 10.2 states in the last sentence that the DSN (incorrectly written as "DRSN") uses preemption. This is misleading, since it may use other preferential treatment procedures as well. It is unnecessary for this document to state the algorithms/procedures used in each domain.

Section 10.3 defines the operation of DRSN which uses six levels. The operation described, in which a Flash-Override-Override preempts another of the same level is not the desired operation. It appears that this may be based on the current operation of some circuit-switches because of implementation difficulties when the 6th level was added a few years ago. However, this bad operation should not be perpetuated. In any event, there is no need for this Resource-Priority header document to go into this type of detail about the inner operation of some network. This paragraph should be deleted.

Section 12.1 2nd paragraph forbids adding a new priority value to a namespace (MUST NOT). Previous versions of this draft allowed it (should not). There should be no reason why another value cannot be added to DSN later. If added, it is the responsibility of the operator of the DSN domain to figure out how to do it to avoid interoperability problems.

3. Other problems

Section 1, paragraph beginning "Since calls may traverse..." states that "it is important that all such domains and elements apply the same algorithms for the same namespace as otherwise the end-to-end experience of privileged users may be compromised." While this may be true for some combinations of preemption followed by queuing, it is not necessarily true for all combinations and for any algorithm that might be added later. Suggest that this sentence be reworded to say: "It is important that careful consideration be made before different algorithms are used at different places within a single call."

Section 4.7.1 2nd paragraph. A UAC should never attempt another request using a different resource value upon receipt of a 417. A human user may choose to do whatever they are authorized to do when trying a new call. No device can be allowed to do this automatically, since it would be violating the policies for the use of priority levels.

Although section 7 only gives "examples", the use of "DSN" causes confusion since it shows an operation which would not be used in the DSN domain. Specifically, the inclusion of the R-P header in the 180 and 200 in 7.1 and the list of accepted values in the 417 in 7.2 would not be used in the DSN. The example should use a domain that might use these techniques. Since there is none that is known to work this way, the examples should use "Foo" and "Bar" as in Section 8.2.

Section 8.1 causes confusion since it implies the existence of a relative order between different namespaces. It should instead say that there is no defined relationship between the values of different namespaces and that RP actors may apply whatever algorithms or procedures they wish when dealing with multiple namespaces, as long as the relative levels within each namespace are maintained.

Section 8.3
With a statement as given above, it is unnecessary to include this section on "examples of invalid orderings".

Section 11.3
The association of the requirement for confidentiality and integrity of the user's data with the Resource-Priority header leads to confusion. They are unrelated requirements. Standard policy dictates whether there is a need for confidentiality and integrity of the user's data independently from the need for precedence levels. The first paragraph should be deleted so that this section only addresses the security of the R-P header itself.

Section 11.4
No system that allows the use of the R-P header should allow anonymity. In any case, the use of anonymity is independent from the use of R-P header and should not be mentioned in this document.

Section 12.1 The purpose of IANA registration is to prevent conflicts in assignment of names and numbers, such as the namespace. There is no need to include the "operation" (preemption or preferential queuing) in the IANA registration. In fact, the DSN may use other techniques besides preemption, such as exemption from network management controls, as described in draft-pierce-tsvwg-pref-treat-example.

4. Unsubstantiated capabilities

The draft contains capabilities for which there has been no demonstrated requirement. While it is always desirable to include extra flexibility, it leads to some confusion. The requirements of the known applications only require the addition of the Resource-Priority header to the INVITE message. The receiver acts on this information if it can, and does not if it can not, in setting up the call. There is no identified requirement for the following:

- The Accept-Resource-Priority Header (3.2)
- Resource-Priority header in Ack, Prack, BYE (3.3)
- The resource-priority option tag (3.4)
- Use of Require Header (4.3)

Mike Pierce

_______________________________________________
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: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 31 Mar 2005 14:08:39 -0600

Mike,

This draft defines the SIP behavior, and not the procedures for a given call/session type. I believe your "problems" can be addressed in the DSN procedures document.

Cheers,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, March 30, 2005 4:49 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Sip] Comments on Resource-Priority -07

1. Nits

2. Major problems

3. Other problems

Section 8.3

Section 11.3

Section 11.4

Mike Pierce