[Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a few concerns that I think need some discussion. 

1) Priority between applications: The fact that agents can apply priority
for messages from multiple applications without knowledge of those
applications seems dangerous. Let's say application A is a critical
infrastructure application, and application B is not. But clients for
application B might set requests to have a higher priority than do
clients for application A.  Further, application B could become a DoS
vector for application A. One potential (and likely half-baked) way to
mitigate this would be to say that nodes that are not "application aware"
can only apply priority among messages for the same application.

2) Priority between clients of the same application: If you have multiple
clients for the same application, don't they need to use the same
prioritization strategy? How is this to be managed?

3) Out of order requests: The draft explicitly allows agents to re-route
and even explicitly re-order messages. Is it safe to have a
non-application aware node change the order of messages?

4) I am nervous about the idea that clients and servers would use a
generic message priority mechanism to manage the allocation of resources
that result from a requests and answers. It seems like that should be
based on application specific rules and information. (Now, if the point
is that these same AVPs might be used in an application according to
application specific rules, that might be okay--but then you might run
into issues where application-agnostic agents don't know the difference.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General: I approached this assuming prioritization would matter only in
overload scenarios. But I gather you envision using this in non-overload
scenarios? (This interacts with my discuss point about the use of DRMP to
prioritize resource allocation that result result from successful
diameter transactions.) Use case 5.3 is a bit worrisome in this context.


-6, list item 4: Are there really use cases for answer senders to set a
different priority on the answer than was on the request? That seems to
add quite a bit of complexity.

- 6, list item 8: I'm not sure what it means for a client to prioritize
answers to it's own requests.

-8,  "Diameter nodes SHOULD
   include Diameter routing message priority in the DRMP AVP in all
   Diameter request messages." : 
Does that apply to all nodes that touch a request, or just the request
originator?

-- "Diameter nodes MUST use the priority indicated in the DRMP AVP
carried in the answer message, if it exists."
The MUST seems odd, since paying attention to the priority in the initial
request was only SHOULD. 

-- "Another is to use the Proxy-Info
      mechanism defined in [RFC6733].":
That probably needs some elaboration.