Subject: [Ieprep] Resource priority header

From: [email-masked]
Date: Tue, 21 May 2002 19:57:56 EDT

To all,

Following the discussion in the interim meeting, I would offer the following 
ideas for the Resource-priority header:

As Fred suggested, the values for some namespace may be used for something 
that is not actually an ordered set of priorities, but I would propose 
leaving the header named "Resource-priority" since that is the intended use. 
The actual contents could be left as "namespace.priority" or changed to  
"namespace.value" to indicate this more general use.

3. After the third paragraph, the following should be added before the table 
entry:

   The following is an extension of Table 3 in [2543bis] for the
   new header field defined here:
   Header field             where     proxy ACK BYE CAN INV OPT REG
   ________________________________________________________________
   Resource-Priority         c          ar   -   -   -   O   -   - 

4. If allowed to be something other than an ordered list, then the IANA 
Considerations would need to to reworded a bit to say "Within each namespace, 
the registration MUST indicate if the values represent an ordered set and, if 
so, the relative precedence levels expressed as an ordered list." Further, I 
would presume that, if an unordered set were created for some namespace, that 
there would be no restrictions to adding values.

5. Security Considerations

While it is true that use of this header can give someone more or better 
access and allow them to consume resources easier or faster, I think the 
point should still be made that the Resource-priority header does not 
introduce any unique requirement for security procedures. The procedures 
required are the same as those required to authenticate/authorize the use of 
many other headers and capabilities.

The question of default values (when the header is not present or the 
namespace or value is unknown) is a problem.

For dsn, the practice might be to default to the lowest if the header is not 
present. I suppose if the value is unknown, it should default to the lowest 
also, but I think it really represents a bigger problem (data corruption?) 
and the practice may be to reject the session setup. Unknown namespace is 
another issue. If a device is supposed to handle multiple namespaces, then it 
can not default to one of them if it doesn't understand the received 
namespace. Further, in a network (like dsn) which is set up to handle exactly 
one namespace, getting one that is does not understand indicates a bigger 
problem (a call crossed some boundary it shouldn't have). The policy would 
more likely be to reject the call. I would suggest not saying much about 
defaults, especially since it really doesn't affect the definition of the 
header itself. If something must be said, I suggest text in Annex A similar 
to the following:

When the Resource-priority header is missing or is present but contains an 
unknown priority value and the receiver is only expected to support a single 
namespace, any procedures applied SHOULD be the same as would be applied when 
the lowest defined value (Routine) is specified. When the Resource-priority 
header is missing and the receiver is expected to support more than one 
namespace, it MUST NOT apply any procedures related to priority and SHOULD 
pass the request on with the same Resource-priority header (or lack thereof). 
When the Resource-priority header contains an unknown namespace and the 
receiver is expected to support more than one namespace, it SHOULD reject the 
request in which the Resource-priority header was included.

(I know the last sentence causes some people trouble, since it is saying to 
reject a session setup based on the contents of an optional header. Is this a 
no-no?)

Don't forget to add "critic-ecp" to the text in the first paragraph of Annex 
A. With the addition of a new namespace for IPREP, it seems that the 
reference to using "critic-ecp" for GETS is incorrect. I'm sure that a GETS 
call can't take precedence over a "Flash-Override call in the dsn. I suggest 
replacing the final paragraph of Annex A with something like the following:

The value "critic-ecp" stands for "Critical and Emergency Call Processing" 
and is generally used only to support those activities related to restoration 
of communications. Its use is extremely limited and is not specified here.

For the namespace q735, the defaults are another issue. The intention was to 
supported interworking with PSTN in which a SIP portion provides the link 
between 2 PSTN parts. This header then just provides the place to put the 
equivalent information from the ISUP messages. In this case, there would not 
be a default. It simply carries what it gets. At the end, when mapping back 
to ISUP, undefined values can not be mapped so may be defaulted to the 
lowest, but I don't see that this needs to be specified here. Perhaps a 
paragraph added to say something like:

Since the intention of this namespace is to provide interworking between 
Q.735.3 entities without interpretation by the SIP proxies, no default in the 
case of no header or a header with an unknown priority value is required. 
Each MUST carry the header (or lack thereof) exactly as received. The mapping 
back to Q.735.3 requires that the namespace be correct and that unknown 
priority values be discarded or changed to the lowest defined.

(Remember to change the definition so that "0" is the highest and "4" is the 
lowest.)

For IEPREP, the job is to add the definition of the namespace. I believe 
that, while the namespace would be added to support the specific requirements 
of IEPREP, it is something that exists in a broader context - the public 
network. Within that network, the new value(s) for IEPREP are in addition to 
the case of "normal" calls, even if the normal calls never use the 
Resource-priority header. It seems necessary to actually define a "Normal" 
priority value, simply to be able to say that something defaults to it.

Also, the idea has been raised before about the desire to have several values 
of priority for authorized emergency. (I mean ascending levels of priority, 
not labels that have no specific meaning.)

Also, while 911 emergency type calls may be indicated by another means 
("SOS"), it seems that there still is a need to include a priority level in 
this set for it. Otherwise, it is not straightforward to specify relative 
priority handling.

Therefore, I would propose to add an Annex C as follows (where the actual 
name of the namespace is open for discussion):

------------------------------------------------------------------------------

----------------------------------------------
C Namespace public_network

The namespace "public_network" is registered here to be used by those public 
networks which support the emergency services defined in [IEPS/SOS/911/etc]. 
The namespace contains the following five priority values in ascending order:

Normal  (Although all normal calls are expected to not contain this header, 
the value is defined for completeness and to allow the specification of the 
default.)
Emergency_public    (Although public emergency calls may be indicated by 
other means, e.g., "SOS", this value is defined for completeness and to allow 
sufficient definition of its relationship to the higher priority levels.)
Emergency_auth_1    (The assignment and use of this priority level is the 
responsibility of the network operator/telecommunications agency in the 
country, etc.
Emergency_auth_2    "
Emergency_auth_3    "

Within a network which is expected to support only this one namespace, when 
the Resource-priority header is missing or is present but contains an unknown 
priority value, any procedures applied SHOULD be the same as if the lowest 
value (Normal) had been specified. When the Resource-priority header contains 
an unknown namespace, the receiver SHOULD reject the request in which the 
Resource-priority header was included.
-----------------------------(End of proposed Annex C) 
------------------------------------------------

An alternative to the above Annex is to recognize that the definition of this 
is unique to each country and let each one register with IANA for their 
namespace, including procedures. This would allow a choice of the number of 
levels.

There was some discussion of interworking with GSM which, according to 
various descriptions has 7 or 15 priority levels. I understand from recent 
e-mails, that it has 7, as I included in my presentation. The 15 levels also 
referred to are not priority levels as Janet Gunn explained., but rather 
access classes which can be turned on or off by the service provider to allow 
certain groups of handsets to get service. As such, they are not "priority 
levels" and they do not need to be passed anywhere for interworking. The 
Resource-priority header would only need to deal with the actual 7 priority 
levels. Do we know what they are called and what interworking might be 
required?

Mike Pierce

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 May 2002 09:48:36 -0400

On Tuesday, May 21, 2002, at 07:57 , [email-masked] wrote:

> To all,
>
> Following the discussion in the interim meeting, I would offer the 
> following ideas for the Resource-priority header:

While protocol design can be amusing to some, I don't think that is
within the charter for IEprep.  Of course the chair can correct me
if he thinks I'm confused...

Ran

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 22 May 2002 09:30:47 -0500

>if he thinks I'm confused...

But this SIP Header Extension was a fair portion of the discussion Monday
and several ID's from within this group had taken the view that this R-P
Header was more of a given (done deal) than Allison thought upon her review
during the meeting. Several people were and now are motivated to ensure
this piece of signaling is in place to have as a mechanism for the IEPREP
group to utilize.

I believe this is where Mike is coming from.

>Ran

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

James M. Polk
Senior 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

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 May 2002 10:34:42 -0400

On Wednesday, May 22, 2002, at 10:30 , James M. Polk wrote:

> during the meeting.

Sounds like the interim meeting strayed from the WG's charter,
which is unfortunate if true.  Thanks for the clarification.

> Several people were and now are motivated to ensure

That is all fine well and good -- but work relating to SIP extensions
needs to be done *inside the WG chartered for SIP* -- and on that WG's
mailing list rather than here.  This WG is NOT chartered to create
extensions to SIP, so any such works needs to move over to the right WG.

So my original comment stands, but perhaps is a bit more clear now.

Ran
[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 22 May 2002 10:32:47 -0500

>>> On Tuesday, May 21, 2002, at 07:57 , [email-masked] wrote:

<snip>

>which is unfortunate if true.  Thanks for the clarification.

Not quite a clear as you might believe in only reading this here. With many
IEPREP ID's (Framework, Sec Req, IEPREP Req, RP Req into IEPREP) mentioning
the use of signaling within SIP for this potential deferential treatment of
a IEPREP communications, there became a need to discuss its status that was
not as advanced as was thought based on Allison's concerns. The discussion
didn't go into any detail of creating the SIP Header - and little into
modifying it --  just how it can be used under IEPREP conditions.

>mailing list rather than here.  

Fair comment -- but its form should be discussed here since this list is
referring to it often, and the R-P Header is in several IEPREP ID's. I
believe that makes it more on topic than would normally be the case. Fred
also asked that more requirements for it be specifically included in IEPREP
ID's during the meeting.

>This WG is NOT chartered to create

If this WG has a specific requirement for the usage of this Header,
shouldn't it have a voice in some of the specifics of it? Not everyone on
this list is a member (?) of the SIP of SIPPING list

James M. Polk

Cisco Systems

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 May 2002 13:08:03 -0400

> also asked that more requirements for it be specifically included in 

Someone mentioning an out-of-scope topic in an I-D does not change or
override the charter's language which makes that topic out of scope.
In the case you outline, the I-Ds should be edited to remove the out
of scope material XOR moved to the appropriate WG.

> shouldn't it have a voice in some of the specifics of it?

No.  Absolutely not.

This WG explicitly SHOULD NOT be used to drive requirements onto
other WGs.  That would violate IETF practices.  Individuals who have
such proposals to change SIP should be making those proposals in
the proper WG -- which is NOT here.

> Not everyone on this list is a member (?) of the SIP of SIPPING list

SIPPING list is free and open.  Anyone not on it that cares about SIP
or this conceptual extension should join that list and MOVE THE 
DISCUSSION
over there.  That is where the SIP expertise lives and that is where
the IETF WG charters says SIP extension proposals/ideas should be worked
on -- NOT HERE.

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Wed, 22 May 2002 19:20:01 -0400 (EDT)

> other WGs.

this WG was asked by the ADs to provide requirements for a RP header
at the last IETF meeting - this was mentioned in both the sipping and ieprep
sessions

Scott