[Sip] -resource-priority-05.txt: Comments and Recommendations

["Corey W. Alexander" <[e-mail]>]

This should spur some discussion...  I'd rather send this directly to 
the authors, but to keep everything out in the open...

I spoke briefly with Mr. Polk following the IEPREP session on Tuesday. 
I had three general questions.  I'm paraphrasing the responses, and so 
invite James to correct me if I'm misrepresenting him here.

1. Why support multiple namespace/priority (n-p) values in a single 
message, in one or more R-P headers?  And if supported, should not the 
n-p values in the message equate to the same priority level (for 
example, dsn.flash and q735.1 would be equal)?  Would it not be better 
to support only one n-p value per message, and recommend that a 
proxy/gateway between networks supporting two different namespaces 
handle mapping n-p values?
---- There may be/are networks which would support multiple levels.  The 
draft is not dictating that there must be multiple levels.
---- As for having the n-p levels be "equal", James cited a GETS call 
with a specific precedence which becomes a Routine call on the DSN.
---- Having a proxy/gateway mapped between namespaces is an viable 
alternative.

2. Is it wise or valid to explicitly allow a proxy to "upgrade" or 
"downgrade" the  n-p values in a message?
---- I'm coming at this from the DSN perspective, but wps and/or ets may 
allow this kind of thing.  While the DSN/DSRN/(Q735) would not, that 
does not invalidate the concept.

3. With "preferential treatment" of messages based on R-P content, 
should not scenarios be considered and listed in which a lower priority 
message  would need to be handled before a higher priority message?  My 
example: it would be wise to handle a BYE message with dsn.routine 
before an INVITE with dsn.flash-override...  At least in certain 
situations, say when the BYE is sent as a result of a preemption event 
(which the Reason header should likely indicate).
---- Certainly something to consider, especially for DSN.


Having witnessed the majority of the discussion on this draft in the 
final SIP session, and stepping back from the questions I had, it occurs 
to me that, while the information presented is not invalid, it is 
certainly confusing, to a varying degree.  In my opinion, the confusion 
comes from trying to define (describe/outline, whatever) the behavior of 
the various namespaces, while at the same time intending to keep draft 
general, and the use of the R-P header open to those who implement it.

Right before the comments on this draft were brought to a close, the 
thread was leading to there ultimately being independent documents which 
would describe the overall behavior of networks which implement one or 
more of these namespaces.

RECOMMENDATION:  Any namespace-specific behaviors should be relegated to 
documents specific to the namespaces themselves.  For instance, there 
are currently a number of documents, and certainly other to come, 
dealing with the requirements/architecture/implementation of Assured 
Service (MLPP in IP):
draft-baker-tsvwg-mlpp-that-works-02.txt
draft-pierce-tsvwg-assured-service-req-01.txt
draft-pierce-tsvwg-assured-service-arch-01.txt
draft-pierce-tsvwg-pref-treat-examples-01.txt

It is in documents like these - more specifically, documents specific to 
expected behaviors - where the use of the R-P header should ultimately 
be laid out.

I would like to see the R-P draft limited to
- a general description of what the header is: What is a namespace? 
What is the priority values mean?  Why is it needed?  Basically, 
background and definitions, but NOT explicit behaviors.
- the format of the Resource-Priority header
- 417 response code
- error conditions
--- If the R-P header is not supported: 420
--- If the n-p value is not supported or unknown: 417
*** This document does not have to define those circumstances in which 
each defined namespace considers the n-p value unsupported.
- A MINIMUM number of namespaces.
*** I would recommend providing only a single generic namespace, with 5, 
6, whatever, priority values, and leave the actual namespace definitions 
(dsn, dsrn, ets, wps; and q735, if necessary) to documents specific to 
those namespaces/architectures.

This would remove all of the confusion.  No need to describe the 
behaviors expected with the current namespaces, let applications 
specific to the namespaces to that.

Further, the document could then keep the strict, semi-strict, and loose 
mode concepts intact (or with modification) without interfering with 
existing behaviors in the current namespaces.  New namespaces, when 
defined, can align themselves with these modes, or define their own 
behaviors.

Finally, since preferential treatment of messages would likely find 
greater use outside of a private network than preemption, I would also 
recommend one more thing.  If the suggestion of a single generic 
namespace in this draft is taken, behaviors surrounding the concept of 
preferential treatment should be included for this namespace.

Digest and comment.

-- 
Corey W. Alexander

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip