Subject: Re: [Sip] draft-ietf-resource-priority-01 draft

From: [email-masked]
Date: Mon, 4 Aug 2003 13:23:23 EDT

Comments as follows:

1. Number of priority values

There continues to be a problem with the possible number of priority values 
per namespace. Since the whole purpose of this header to provide priority for 
one call over another, there must be, at a minimum, two values registered per 
namespace.

The IANA considerations states that: "The registration MUST indicate the 
default level to be assumed in the absence of the priority value or if the 
implementation does not understand a level from the namespace." This necessitates the 
registration of a "normal" level (to be the default) in order to be able to 
assign an "elevated" level. A namespace can not contain only one value.

Section 3 states "Each namespace has at least one priority value." and "We 
require that even namespaces with only one priority value list that value to 
avoid problems ..."

If the change proposed above to require multiple levels is made, the above 
statement ("We require...") can be deleted.  Otherwise, it needs to be modified, 
since it isn't clear whether it is intended to refer to the IANA 
considerations or the contents of the Resource-Priority header. If the former, it should 
be moved to Section 12 and state that "Namespaces with only one priority value 
MUST register that value to avoid problems if additional priority values are 
added later". If the latter, it should state: "If a namespace only contains one 
priority value, that value SHOULD still be included in a Resource-Priority 
header to avoid problems if additional priority values are added later."

2. Number of headers

There is also a confusion about the number of R-P headers which may be 
included. While 4.5 correctly states that "The UAC MUST only include at most one 
Resource-Priority header field in the request.", Section 3 includes the statement 
that "There may be multiple resource values or, equivalently, multiple 
Resource-Priority header fields." (which is followed by the example of the US 
Wireless Priority System). It isn't clear how to interpret this example, since it 
refers to possible namespaces and priorities which aren't defined in this 
document. I suggest that these two paragraphs be deleted. Other text already 
indicates that an R-P header can contain multiple namespaces but not multiple values 
per namespace.

3. References to ETS

The reference to "Emergency Telecommunications Systems (ETS)" in 8.2 should 
be changed, since the headers defined in this document apply to more than what 
is commonly called "ETS". The three namespaces defined in Annex B are not a 
part of "ETS".

The first sentence further states that ETS "must be protected from intercept 
and alteration" (lower case "must"). It isn't clear whether this was intended 
as a normative "MUST", or simply a statement that confidentiality and 
integrity are good things to have. Since requirements for this are distinct from the 
requirements for the Resource-Priority header, this statement should be 
corrected to not imply that this is a requirement. (In some cases, a call using the 
R-P header is not required to have confidentiality.) I would suggest wording 
this first sentence as "Calls which use elevated priority levels provided by the 
Resource-Priority header are likely to be sensitive and often need to be 
protected ..."

Likewise, Section 8.4 should be reworded to "As noted, systems which use the 
Resource-Priority header are likely to be subject ..."

4. IANA Considerations

The final paragraph under IANA Consideration in Section 12 states:

"Namespaces MAY also impose particular authentication or authorization 
consideration that are stricter than the baseline described here."

This implies that this is a part of the IANA registration, that is, that it 
is specified when registering a namespace. Since this should be a local matter 
and not a part of registration, it should not be stated here but moved to the 
end of Section 8.1.

Mike Pierce

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Aug 2003 18:25:50 -0400

Mike,

thanks for your comments. 
http://www1.cs.columbia.edu/sip/drafts/draft-ietf-sip-resource-priority-02.txt 
reflects the resolution of these and the other recent list comments (I 
have not yet submitted this version).

A few clarifications in-line.

[email-masked] wrote:

> There continues to be a problem with the possible number of priority 
> values per namespace. Since the whole purpose of this header to provide 
> priority for one call over another, there must be, at a minimum, two 
> values registered per namespace.

Not really. This has always been confusing, due to the definition of 
default values. However, with the -01 clarification, the notion of 
default values actually makes little sense in general. I think it would 
be more precise to say that some namespaces happen to have a value that 
is equivalent to omitting the priority value altogether, but that is not 
required. This is independent of the number of priority values; for 
example, one could imagine a namespace with the labels

postal, important, house-on-fire

where postal indicates that the call should wait behind all regular 
(non-marked calls), while important and 'house-on-fire' calls get 
priority treatment. If you want the regular treatment, just don't 
include the header. (Something similar actually happens to be the only 
'QoS' measure being used in Internet2 - the scavenger service 
[http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt]

I have hopefully removed the remnants of text referring to default 
priority values.

> default level to be assumed in the absence of the priority value or if 
> the implementation does not understand a level from the namespace." This 
> necessitates the registration of a "normal" level (to be the default) in 
> order to be able to assign an "elevated" level. A namespace can not 
> contain only one value.

I removed the text.

> 
> Section 3 states "Each namespace has at least one priority value." and 
> "We require that even namespaces with only one priority value list that 
> value to avoid problems ..."

Removed.

> included. While 4.5 correctly states that "The UAC MUST only include at 
> most one Resource-Priority header field in the request.", Section 3 
> includes the statement that "There may be multiple resource values or, 
> equivalently, multiple Resource-Priority header fields." (which is 
> followed by the example of the US Wireless Priority System). It isn't 
> clear how to interpret this example, since it refers to possible 
> namespaces and priorities which aren't defined in this document. I 
> suggest that these two paragraphs be deleted. Other text already 
> indicates that an R-P header can contain multiple namespaces but not 
> multiple values per namespace.

As per the previous discussion, multiple namespace.priority values are 
permissible, obviously only with different namespaces. The contradictory 
text was yanked.

> 
> 3. References to ETS
> 
> The reference to "Emergency Telecommunications Systems (ETS)" in 8.2 
> should be changed, since the headers defined in this document apply to 
> more than what is commonly called "ETS". The three namespaces defined in 
> Annex B are not a part of "ETS".

All references to ETS have been reworded as suggested.

> This implies that this is a part of the IANA registration, that is, that 
> it is specified when registering a namespace. Since this should be a 
> local matter and not a part of registration, it should not be stated 
> here but moved to the end of Section 8.1.

Moved.

> 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