Subject: [Sip] Comments on Resource Priority Header

From: [email-masked]
Date: Wed, 23 Jan 2002 17:19:03 EST

I have the following comments on draft-polk-sip-resource-01:

General: It is suggested that statements regarding the use of the header 
(i.e., definition of a service which uses the header) should be deleted from 
this draft. Some of these procedures may be different for various situations 
or services or depend on network policies, so this document should not state 
MUST or SHOULD NOT provisions for these procedures.

Section 3:

2nd paragraph: Is it necessary for the priority values to be assigned by 
IANA? After a namespace is registered, would it be sufficient for the "owner" 
of that namespace to assign priority values without IANA registration?

3rd paragraph: "As a response header ..." - It is unknown where this function 
would be used in the required procedures. Current requirements are that the 
priority level is specified by the caller and the called party has no option 
to change or reject the level. It is okay to identity that this header may 
optionally be included in the response, but it should not state its actual 
meaning (procedures). The following paragraph is suggested: "The resource 
priority header MAY be included in a response, either with the same or 
different value than the one contained in the request. The meaning of this 
response value depends on the application and details are beyond the scope of 
this document.."

4th paragraph: "If the header field is missing ..." should be deleted, since 
this relates to the procedures for use rather than the definition of the 
header itself. In some networks, this could be cause for rejecting the call 
rather than defaulting to a specific value.

5th paragraph: "The values are adopted from RFC 791 ..." and following 2 
paragraphs should be moved to go with the description of the specific levels 
for the "dsn". It would probably be useful to include all information 
regarding the values for the Defense Switched Network in an Annex, with a 
reference to it in the IANA considerations for the initial registration. (See 
final comment.)

8th paragraph "Proxies MAY downgrade ... SHOULD NOT reject requests..." - 
This should be deleted or changed since the procedures to be followed depend 
on the network policies and the service being provided. For example, in the 
equivalent ISDN standards today, the call is released (rejected) in this 
case. The following paragraph is suggested: "Proxies MAY downgrade the 
Resource-Priority of or reject unauthenticated requests. Details are specific 
to each administrative domain and beyond the scope of this document."

4. IANA

Why is a restriction needed that an existing list not be extended? If the dsn 
wishes to later add a new level below "Routine", it should be allowed to do 
so.

Other: Since one of the uses is "carrying information from one multi-level 
domain in the telephone network, e.g., using the facilities of Q.735.3, to 
another, without the SIP proxies themselves inspecting the header field", it 
would be useful and efficient to preassign a single standard "namespace" of 
something like "PSTN" with values of "0", "1", "2", "3", and "4" to directly 
carry the values defined in Q.735.3. Otherwise, various networks in different 
countries may define different namespaces and values to indicate their local 
meanings of the currently defined 5 levels (possibly in their local 
language). This would make interworking difficult.

If this is added, it is suggested that it also go in an Annex along with the 
description of the dsn values. That Annex would be as follows:

Annex A Initial Registration of Namespace and Priority Values
IANA is requested to register the following two namespaces and their 
associate priority values:

1. PSTN/ISDN equivalents

In order to support carrying information between Q.735.3 (or equivalent) 
PSTN/ISDN entities without intervening interpretation by SIP proxies and to 
avoid the necessity of the gateway performing unnecessary interpretation or 
interworking between different networks, the following common, standard 
definition is made:

Namespace = "pstn" (Public Switched Telephone Network)
Priority Values = "0", "1", "2", "3", and "4", where "0" is the highest, etc.

2. Defense Switched Network (US Military)

The Defense Switched Network (dsn) of the US military, as well as those of 
many other counties, uses a definition of priority levels that is a subset of 
those defined in RFC 791 [4]. In support of these applications, the following 
definition is made:

Namespace = "dsn" (Defense Switched Network)
Priority values = "critic-ecp", "flash-override", "flash", "immediate", 
"priority", "routine"

The values are prioritized in the order "critic-ecp" (highest), 
"flash-override", "flash", "immediate", "priority" and "routine" (lowest).

The value "critic-ecp" stands for "Critical and Emergency Call Processing" 
[4]. This value SHOULD only be used for authorized emergency communications, 
for example in the United States Government Emergency Telecommunications 
Service (GETS) [5], the United Kingdom Government Telephone Preference Scheme 
(GTPS) and similar government emergency preparedness or reactionary 
implementations elsewhere.

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