Subject: RE: [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 23:47:49 -0500

comments in line

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

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.
----------------------------------------------------------------------------------------

                      "Ken Carlberg"                                                                                           
                      <carlberg                To:      Janet P Gunn/FED/CSC@CSC, <[email-masked]>, <[email-masked]>           
                      @g11.org.uk>             cc:      <[email-masked]>, Darren E Pado/FED/CSC@CSC, Saud Negash/FED/CSC@CSC, 
                                               <[email-masked]>, Richard F Kaczmarek/FED/SC/CSC@CSC, <[email-masked]>,      
                      11/06/2004 09:26         <[email-masked]>, <[email-masked]>, <[email-masked]>, Dennis Q   
                      AM                       Berg/FED/CSC@CSC                                                                
                                               Subject: RE: [Sip] Strict,Semi-Strict and Loose mode in RPH - not a good fit    
                                               for ets and wps                                                                 

> 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)

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.

[JG] Before posting this, I checked with Dr. Fonash (head of NCS, which
"owns" GETS and WPS).  He was very clear about wanting "If the SIP element
does not recognize the namespace (wps or ets) it should pass it on without
acting on it, rather than rejecting it."

> 3 The content of the error message should not reveal (to the end user)
the
> 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.

[JG]I am not as concerned about this case (valid namespace.valid value -
just not authorized).  I am more concerned about the  error message when
the namespace, or value are not recognized.  But if ets and wps operate
with the behavior "SIP element ignores a namespace it does not recognize",
half of that goes away.

[JG]I am still not entirely sure about the desired behavior for the other
half- (valid namespace.invalid value).  But I suspect that it would be
better to
a) Reject the message
b) NOT return the list of valid values.

[JG] I do not think that the full loose mode as defined (if the SIP element
gets (valid namespace.invalid value) it processes the message as if it had
no RPH) is the right approach.  I think these messages should be rejected,
and get an error message.

[JG]But I am open to other approaches.

> 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")

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

[JG] Agree.  While it doesn't explicitly state it, the document leads you
to believe that queueing is the only behavior permitted in semi-strict
mode.

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

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.

[JG]I guess I wasn't clear.   I simply meant that there wasn't a concern
about the "require" header itself, independent of the
strict/semi-strict/loose mode.  Once that is "right", the approach to the
"require" header will follow

-ken

_______________________________________________
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: Sun, 7 Nov 2004 09:16:32 -0500

> I would prefer a strict or semi-strict mode because these provide feedback in

ok.  Dr Fonash now has additional input on the subject given my previous email;
if there is no feedback, then the sender hopes everything is working fine.
further, it will continue to use an R-P capable proxy with no feedback from the
INVITE indicating that it does not support that particular namespace/value.  

Keep in mind that as it states earlier in the draft, the R-P header is ignored
(assuming proper implementation) by those proxies (eg, the installed base) that
do not support the new R-P header.  As a sidenote, our current implementation
of the R-P header follows the MAY portion of the draft and does not send back
hints of what are acceptable priorities.

Also, when you say the NCS "owns" GETS and WPS, are you refering to the systems
or the namespace?  If its both, then I have my doubts about the latter.  I see
no association of the NCS with WPS or GETS in the draft and it would seem that
initial "ownership" of those namespaces, as well as the others like ETS, lies
with the authors of the draft.  (I'll be happy to be corrected on that
assumption).

-ken