Subject: [Sip] Comments of Resource Priority header

From: [email-masked]
Date: Tue, 24 Jun 2003 13:00:33 EDT

To all,

Comments on draft-ietf-sip-resource-priority-00:

The abstract says "defines a new SIP header field ... called 
Resource-Priority", but the draft then defines two headers. If the second header is included 
(see comments below), references should be added in the abstract and throughout 
the Introduction.

In the statement in the abstract that this header "does not influence the 
forwarding behavior of IP routers", it needs to be made clear that, while there 
is no "direct" influence, it is certainly possible for such influence to exist, 
based on procedures and processes not described in this document. For 
example, the descriptions for "Assured Service" have always presumed that this 
Resource-Priority header in the session (call) setup signaling could be used to 
cause preferential treatment of media packet forwarding, including multiple drop 
precedences in an EF queue. I believe the sentence should read: "While it does 
not directly influence the forwarding behavior of IP routers, procedures for 
using this header to cause such influence may be defined in other documents."

3. The definition of the Resource-Priority header should not allow multiple 
resource values to be carried. I am unaware of any requirement for this. The 
use described always needs exactly one value within one namespace. Anything 
beyond this will bring on questions like "Which priority has priority?"

Note: REQ-13 says that "Some UAs will need to support multiple different 
priority schemes". It does not say that the indication (header) needs to support a 
"list of names".

3. Instead of defining a separate Accept header, it seems that there could be 
a single Resource-priority Header which is then included in specific messages 
(responses) to mean "accept". (I'm trying to find an existing example of a 
header that is used like this.)

The example of the originator requesting "q735.1, gets.enabled" and the 
response indicating which dsn values are supported is invalid. The dsn would not 
function this way. If it understands the value received based on interworking 
arrangements (e.g., gets.enabled), it may convert it to its equivalent dsn 
value, according to the interworking rules. Or if it is set up to understand and 
support multiple namespaces (e.g., gets and dsn), then it would respond to 
either and internally would know how to prioritize values from the two namespaces. 
Otherwise it simply processes the call setup attempt as if it didn't have a 
Resource-Priority header. (see 4.2 below).

When one defines the specific procedures for specific namespaces (not in this 
document), the only possible response to a request should be to indicate 
"accepted" priority values within the same namespace as the request. Otherwise, it 
seems to contradict the point of defining namespaces.

4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if and 
only if" seems strange. The "if and only if" appears to be indicating a "MUST" 
situation. The rest of the sentence is confusing, since it is saying that it 
depends on "if the request would ... experience treatment no different than a 
non-labeled request", but the whole point of the sentence is that it's treated 
"as if it had no priority indication", that is, is non-labeled. Also, it seems 
that there should be different treatment when the namespace is recognized but 
the priority value isn't. I believe the whole sentence should be replaced with: 
"If an element receives a request with a namespace that it does not 
recognize, it SHOULD serve the request as if it had no Resource-Priority header. If an 
element receives a request with a namespace it recognizes but a priority value 
that it does not recognize, it SHOULD serve the request as if it had the 
default value specified for that namespace." (Section 12 says what is in this last 
sentence.)

The 2nd paragraph (beginning "If an unknown resource ...") continue to be a 
problem, since it seems to mandate an impossible operation: the element must 
make a decision based on the operation that should have occurred for a namespace 
that it does not recognize. It must be assumed that the phrase "or would get 
a different treatment" intends to say "than if the namespace were recognized". 
This second paragraph should be deleted.

The 3rd paragraph gives the incorrect meanings for the response code 417. 
Section 11 defines it as "Unknown Resource-Priority". (Also wrong in 4.4 and 7.2.)
 
4.4 The text here limits the UAC to sending one Resource-Priority Header 
field. However, Section 3 contained the statement that "There may be multiple 
resource values or, equivalently, multiple Resource-Priority header fields." I 
believe Section 3 is incorrect.

The description in the 2nd paragraph would not be the allowed operation in 
any case that I am aware of. For any use of this Resource-Priority header, the 
user specifies the appropriate priority value for the call being attempted. 
Therefore, no device (UAC) is allowed to reattempt a failed call at a different 
(presumably higher) level. If the call is rejected due to the attempted 
unauthorized use of a level or if the call is blocked when attempted at a particular 
level, the only option is to notify the user of this fact. If the user decides 
to reattempt the call with a higher level, the UAC can not prevent this. But 
no UAC can be allowed to automatically use a higher level.

In any case, the rules for use of this Resource-Priority header should be 
left to documents describing specific uses (namespaces).

B.1 Reference to "critic-ecp" should be added before "flash-override" in the 
list. The reference to "critic-ecp" should be deleted from the 2nd paragraph 
since it was added to the 1st. A relative order needs to be explicitly 
specified as requires by Section 12. This should specify that "Routine" is the 
default. The following is suggested for the 1st paragraph:

This document defines the namespace "dsn". The namespace "dsn" (Defense 
Switched Network) contains the following priority values in the relative order 
listed: "critic-ecp", "flash-override", "flash", immediate", "priority", "and 
"routine", with "critic-ecp as the highest and "routine" as the lowest. The 
default is "routine".

B.3 and B.4
There is a confusion here since GETS and TDR are really the same thing. These 
can not be split into separate namespaces.
Since the IANA considerations states that "the registration must indicate the 
default", it is not possible to have a namespace with only one value. It is 
necessary to define a second value which can be designated as the default even 
if that value is never used in signaling.

B.4 The current defined value is incorrect. "Authorized_emergency" is not the 
same as 911 or 112 calls placed by the general public. "Authorized emergency" 
belongs with GETS. In the previous drafts, authorized emergency and 911 were 
intended as two distinct values within one namespace that covered GETS-type 
calls, 911-type calls, and normal calls (i.e., the regular "public network").

I believe the correct approach is to define a single namespace for the 
"public network" environment with the following values (at a minimum):
- Authorized emergency (GETS, etc.)
- Public emergency (911, 112, etc.)
- Normal
Of course, "normal" is the default. Further, I know that there are some who 
believe that multiple "Authorized emergency" levels are needed, similar to what 
is defined for the Wireless Priority System mentioned in Section 3.

If this issue of the definition of multiple values to support authorized 
emergency (GETS or TDR), public emergency calling (e.g., 911), and various other 
priority schemes that might reside in the same "public" network can't be 
quickly resolved, these should be removed from this draft, to be added later by IANA 
registration.

B.4 I'm not sure why the second paragraph under B.4 for the Defense Red 
Switched Network was added. (This should have been a new section number.) If kept, 
it also should specify that "Routine" is the default. We're looking into 
whether this new "FOO" precedence level is needed and whether it should simply be 
added to the existing dsn namespace.

Reference 11 needs to be updated to read RFC 3487.

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Jun 2003 23:35:28 -0400

[email-masked] wrote:

> 4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if 
> and only if" seems strange. The "if and only if" appears to be 
> indicating a "MUST" situation. The rest of the sentence is confusing, 
> since it is saying that it depends on "if the request would ... 
> experience treatment no different than a non-labeled request", but the 
> whole point of the sentence is that it's treated "as if it had no 
> priority indication", that is, is non-labeled. Also, it seems that there 

I rephrased it, but basically the intent was that if, at the time of 
arrival of the request, labeled and non-labeled requests are treated the 
same, there doesn't seem to be a point to say "sorry, don't know this 
(but it wouldn't make any difference in any event)". In other words, 
under normal, no-overload operations conditions, where all requests are 
served, there is no need to reject requests that have the wrong label.

I don't think treating unknown namespaces the same as no R-P is right if 
the treatment differs. Rather than being routed into some inferior 
corner of the network if I guessed the wrong namespace, I should be told 
that I should be using a different namespace.

> 
> The 2nd paragraph (beginning "If an unknown resource ...") continue to 
> be a problem, since it seems to mandate an impossible operation: the 
> element must make a decision based on the operation that should have 
> occurred for a namespace that it does not recognize. It must be assumed 
> that the phrase "or would get a different treatment" intends to say 
> "than if the namespace were recognized". This second paragraph should be 
> deleted.

I disagree. It simply says that if the treatment is different I ask for 
X, but you don't know X, and if the current treatment for some 
priorities is better than for default, I should be given a chance to 
apply for this better treatment rather than being silently sent into the 
long queue.

> The description in the 2nd paragraph would not be the allowed operation 
> in any case that I am aware of. For any use of this Resource-Priority 
> header, the user specifies the appropriate priority value for the call 
> being attempted. Therefore, no device (UAC) is allowed to reattempt a 
> failed call at a different (presumably higher) level. If the call is 
> rejected due to the attempted unauthorized use of a level or if the call 
> is blocked when attempted at a particular level, the only option is to 
> notify the user of this fact. If the user decides to reattempt the call 
> with a higher level, the UAC can not prevent this. But no UAC can be 
> allowed to automatically use a higher level.

While I can see that 'upgrading' priority is unlikely to be useful 
(although maybe human nature...), changing namespaces will be common.

> 
> In any case, the rules for use of this Resource-Priority header should 
> be left to documents describing specific uses (namespaces).

This is just a MAY and simply describes UAC behavior.

> 
> B.1 Reference to "critic-ecp" should be added before "flash-override" in 
> the list. The reference to "critic-ecp" should be deleted from the 2nd 
> paragraph since it was added to the 1st. A relative order needs to be 
> explicitly specified as requires by Section 12. This should specify that 
> "Routine" is the default. The following is suggested for the 1st paragraph:
> 
> Switched Network) contains the following priority values in the relative 
> order listed: "critic-ecp", "flash-override", "flash", immediate", 
> "priority", "and "routine", with "critic-ecp as the highest and 
> "routine" as the lowest. The default is "routine".

Maybe you and James can get together and figure out whether critic-ecp 
exists or not. He told me to remove it; I'm not familiar enough with the 
DSN to make the call.

> 
> B.3 and B.4
> There is a confusion here since GETS and TDR are really the same thing. 
> These can not be split into separate namespaces.

Again, please discuss with my co-author. He insisted on two.

> Since the IANA considerations states that "the registration must 
> indicate the default", it is not possible to have a namespace with only 
> one value. It is necessary to define a second value which can be 
> designated as the default even if that value is never used in signaling.

Noted.

> 
> B.4 The current defined value is incorrect. "Authorized_emergency" is 
> not the same as 911 or 112 calls placed by the general public. 
> "Authorized emergency" belongs with GETS. In the previous drafts, 
> authorized emergency and 911 were intended as two distinct values within 
> one namespace that covered GETS-type calls, 911-type calls, and normal 
> calls (i.e., the regular "public network").
> 
> Of course, "normal" is the default. Further, I know that there are some 
> who believe that multiple "Authorized emergency" levels are needed, 
> similar to what is defined for the Wireless Priority System mentioned in 
> Section 3.
> 
> emergency (GETS or TDR), public emergency calling (e.g., 911), and 
> various other priority schemes that might reside in the same "public" 
> network can't be quickly resolved, these should be removed from this 
> draft, to be added later by IANA registration.

Since this doesn't seem like a topic that is likely to be resolved soon, 
I would agree that punting on all of them seems the right thing. I don't 
want to further delay this while this is being hashed out by third parties.

> Switched Network was added. (This should have been a new section 
> number.) If kept, it also should specify that "Routine" is the default. 

Section heading was omitted by accident; added.

_______________________________________________
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