Subject: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps

From: Janet P Gunn <[email-masked]>
Date: Sat, 6 Nov 2004 00:25:23 -0500

One of the changes in the draft-ietf-sip-resource-priority-05 is the
definition of 3 modes, strict, semi-strict, and loose, and the assignment
of each defined namespaces to a particular mode.

The definition of the mode involves several distinct behaviors

1 RPH is mandatory vs RPH is optional.
(In strict mode, every relevant SIP message must have the RPH, with the
specific namespace.  In semi-strict and loose mode, some messages may have
the RPH, with the specific namespace, and other messages may have no RPH.)

2 Behavior of a SIP element when it receives an RPH with a namespace it
does not recognize.
(In strict and semi-strict mode, the SIP element returns a 417 error
message if it gets a SIP message with an RPH namespace it does recognize
(or a namespace it does recognize, but an invalid value).  In loose mode,
the SIP element simply ignores namespaces it doesn't recognize - treats it
as if the RPH were not present.  (In loose mode, it will return an error
message if it receives a known namespace with an unknown, or invalid,
value))

3 Content of the error message.
(In strict mode, if the error message contains the "Accept Resource
Priority" Header (which indicates the namespaces and values that WOULD be
accepted) that information is stripped off before it reaches the final
user.  In semi-strict mode and loose mode, it appears that  the information
is not stripped off.)

4  .Inclusion of authorization header (or equivalent functionality from
Trait-Based Authorization).
(In semi-strict mode, SIP messages that include the RPH must also include
the authorization header.  In strict and loose mode, there is no mention of
the authorization header)

5  Preemption vs precedence (i.e., queueing) behavior
(At an IP/PSTN gateway, with all PSTN -side circuits in use, in strict mode
one of the lower priority circuits would be freed using pre-emption.  In
semi strict mode, the SIP request  may be granted access to the next
available circuit based on the header's presence, regardless of how many
other "regular" requests are received at the gateway.  The pre-emption vs.
precedence behavior in loose mode is not described.)

6 Use of the "Require" header field
( in strict and semi-strict modes, a SIP message with the RPH also has the
"Require" header with the "Resource-Priority" option tag.  Loose mode does
no include the Require header)

Of the namespaces described in the document, dsn, drsn and q735 (all
variants of "MLPP") are defined as "strict".  ets and wps are defined as
"semi-strict".  None are defined as loose.

Unfortunately, this  (semi-strict) is NOT the behavior desired for the ets
and wps namespaces.

The behavior desired for the ets and wps namespaces are
1 RPH is optional (semi-strict and loose)
2 SIP element ignores a namespace it does not recognize (loose)
3 The content of the error message should not reveal (to the end user) the
valid values for that namespace (strict)
4 SIP messages that include the RPH with the ets or wps namespaces should
include the authorization header (or equivalent mechanism) (semi-strict)
5 Precedence (queueing) is generally the means of providing priority, but
exemption from network management controls, for instance  call admission
within an IP domain, when a "regular" call would not be admitted, is also
needed.  Pre-emption is not used.  (semi-strict "plus more")
6 There is no a priori requirement to use, or not use, the "Require"
header field.

So the desired behavior is a combination of what is defined for strict,
semi-strict, and loose modes.

It would be much better if one of the modes described the desired behavior
for the ets and wps namespaces.

Thanks,

Janet

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

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

_______________________________________________
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

---

From: "Ken Carlberg" <[email-masked]>
Date: Sat, 6 Nov 2004 09:26:35 -0500

> 2 SIP element ignores a namespace it does not recognize (loose)

I would prefer a strict or semi-strict mode because these provide feedback in
case: a) a misconfigured UA sends the wrong namespace.priority, and/or b)
initial selection of a server/proxy that does not support the desired
namespace.  The former is quite possible given an ability (and possibly,
necessity) of the user to configure their own device to support the given
namespace.value combination.

> valid values for that namespace (strict)

section 4.5 of the drafts states:

   If the UAS understands the resource value, but refuses to honor the
   request with elevated priority for this particular user, it returns
   the 403 (Forbidden) response code.  It MAY include the list of
   resource values that the user is allowed to use in the
   'Accept-Resource-Priority' response header field.

The "MAY" is the critical term.  My understanding would be that this decision
is a local policy issue.  Outside of that I personally don't see a problem with
providing "hints" of accepted values under the context that they can only acted
upon by authorized users.  Informing the user of the acceptable set of
priorities does not bypass or circumvent the need for proper authentication
credentials.

> needed.  Pre-emption is not used.  (semi-strict "plus more")

the "plus more" would seem to be a product of local policy

> 6 There is no a priori requirement to use, or not use, the "Require"

isn't this addressed in section 4.3.2 below?  or am I missing something?

   If the request includes a 'Require' header field with the 
   'Resource-Priority' option tag, a UAS MUST follow the strict or 
   semi-strict mode rules, otherwise UAS and proxies MUST operate in 
   loose mode.

-ken

---

From: Dean Willis <[email-masked]>
Date: Sat, 06 Nov 2004 19:12:37 -0600

> The definition of the mode involves several distinct behaviors

Would it be better to have each namespace definition fully define the 
behavior of that namesapce, rather than trying to have some "templates" 
that could be re-used by multiple namespaces?

--
Dean