Subject: [Sip] Resource-Priority Header

From: [email-masked]
Date: Mon, 19 Nov 2001 22:24:22 EST

To all,

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

The approach described in this draft will provide the functionality needed to 
support the requirements spelled out in 
draft-pierce-sipping-assured-service-00.

Nits: Section 4 gives example of 'e.g., "between urgent and normal".' This 
should reference some of the values defined in Section 3.

Definition of values: Although the specific tokens defined in Section 3 are 
the ones required for the US military application (and may be usable in other 
such environments), it would appear to be advisable to define the token 
values in a more generic way within the standard. This would facilitate the 
use of the resource-priority header in other networks that may use other 
words to describe the levels. For example, a network could choose to use 
three levels and call them "important", "regular", and "not-so-important".

The current draft indicates that a network wishing to use such new values 
would be required to register them with IANA, and indicate their relationship 
with the already defined values (and presumably with every other value 
previously registered with IANA). This could be an administrative nightmare 
and potentially impossible to do. IANA could not negotiate differences of 
opinion on the relative assignments of values to be used in different or 
combined networks.  For two different networks, one could not say whether 
"important" in one should be above or below "flash" in the other, nor should 
one need to define this. Also, this registration process would need to allow 
a new value to be defined to be the same as an existing value, for example, 
if the French language equivalent of the tokens defined in Section 3 were 
desired.

It is essential that a network using a different set of values be able to do 
so without relating their meanings and relative precedence level with those 
of another network, when it is not intended that the two sets be used 
together. The stipulation that unknown values should be treated as "routine" 
might solve the problem of values "leaking" from another domain into the one 
using the definitions in Section 3. It would have to be part of the 
definition for each network to specify what "default" is used for unknown 
values. It may not always be the lowest. In addition, every network defining 
new values would have to use a completely different set.

However, since it would not be under the control of the user of a network 
whether or not intermediate routers, etc. "know" the meaning of other values 
defined for other networks, the user might be unaware of the network's 
actions resulting from its knowledge of the values defined for other networks 
(in case of "leakage"). For example, given the current definitions in Section 
3, if another network defined a set of five values of (lowest to highest) of 
"flash", "more-than-flash", "flash-plus1", super-flash", and 
"extremely-high-flash", then one of its lowest precedence calls (flash) 
"leaking" over into the other network would be treated as a relatively high 
precedence call in that other network.

In fact, all SIP applications, not just this one, must be defined on the 
presumption that "leakage" between network segments or domains can not occur. 
If it could, capabilities must be provided to detect such an error and block 
misrouted calls. Such "leakage" would be a serious problem for more things 
than just this resource-priority value interpretation.

Since one of the applications involves interworking with the ITU-T defined 
protocols (e.g., Q.735.3), it should be noted that those ITU-T protocols 
carry a numeric value 0-4 (with 5-15 reserved). Although Q.735.3 describes a 
meaning for each of those 5 values, the actual words used to identify each is 
different in various translations of the Recommendation and nothing prevents 
a network from using totally different textual meanings. Only the order is 
required.

The statement in Section 3 that states "As a response header, the value 
indicates the actual priority selected by the recipient" needs to be examined 
with respect to the services which might use this field. For the support of 
the service as defined in Q.735.3, the recipient has no say in the choice of 
priority. The originator selects the value to be used for the setup of a call 
and there would be no need for a response value. It is unknown what service, 
if any, would require this in a response.

Mike Pierce
Artel

_______________________________________________
Sip mailing list  http://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: "James M. Polk" <[email-masked]>
Date: Tue, 20 Nov 2001 12:10:37 -0600

>should reference some of the values defined in Section 3.

This is a generic example that most can understand -- that's why it was used.

>three levels and call them "important", "regular", and "not-so-important".

We chose what was originally defined in RFC791 "Internet Protocol", nothing
more, nothing less (other than not including the non-UA priority levels defined
in 791 for inter-network node communications)

>For two different networks, one could not say whether 
>one need to define this. 

This would and must be solved with an SLA if this header's effect is to
propagate past domain boundaries. As for comparing two network's treatment
levels, the Resource Header is stated as not an absolute but a relative
ordering

>together. 

This header is not mandatory. Your  second network doesn't have to adhere to it
at all.

>The stipulation that unknown values should be treated as "routine" 
>using the definitions in Section 3. 

See above

>It would have to be part of the 
>values. It may not always be the lowest. 

That's a implementation issue.

>In addition, every network defining 

Not true

>precedence call in that other network.

This would only be true if they also called their SIP Header Resource-Priority,
which this group should not allow. If they still do, this is a proprietary
implementation -- and they will likely reap the benefits of not being Standard.

>presumption that "leakage" between network segments or domains can not occur. 

You are referring to Leakage, this header is optional to the UA, and in and of
itself, doesn't cause anything to happen in the network itself.

Most of what you say would be true if the header Standardized within the SIP
Protocol and were Mandatory, but it is neither yet, so no problems. If it
becomes a part of SIP with its current spirit of language (meaning only  little
things are changed), then it is up to each domain to implement and react to
what this header means within this domain.

>carry a numeric value 0-4 (with 5-15 reserved). 

SIP is text based.

>Although Q.735.3 describes a 
>a network from using totally different textual meanings.

This header prevents it -- that why these were defined in a written order of
relative priority (let's not forget the CRITIC/ECP level)

>priority. 

This is a optional header. If Q735.3 were solely intended with our submission,
we would have made the language such that this header is mandatory and a
"Requires" header. Making it a Request/Response makes this header more open to
other interpretations and uses, say, like only using a subset of the 6 listed
levels within a certain network. That domain just couldn't use the values out
of order as defined here. Hospital emergency facilities shouldn't need 5 levels
-- I'm told suggestions are for only 3 levels. Financial institutions only want
2 (maybe 3) levels as well. This is an open header, and optional.

>The originator selects the value to be used for the setup of a call 
>and there would be no need for a response value.

True in your one example -- but not the sole intent here by any means.

>It is unknown what service, 

See above, and I know of many other (services and) customers that want this.

>Artel

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com