Skip to main content

Diameter Routing Message Priority
RFC 7944

Yes

(Stephen Farrell)

No Objection

(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)
(Terry Manderson)

Abstain


Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana Abstain

Comment (2016-05-04 for -05)
After reading the document and the threads related to the DISCUSSes, I'm ABSTAINing because I can't see how this mechanism can reliably work (even in "trusted environments") as described here.

(Stephen Farrell; former steering group member) Yes

Yes (for -05)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (2016-05-05 for -05)
I disagree with Mirja's DISCUSS point.

In Section 6: excuse my ignorance, but how can priority information be conveyed to non-supporting endpoints (in 2 places)? And what is the point,as they don't support the extension?

In 9.1: it would be better to just have a table, instead of copying and modifying lots of text.

It would be good to have a short sentence saying how this extension affects non upgraded agents.

(Alia Atlas; former steering group member) No Objection

No Objection (2016-05-04 for -05)
I agree with Mirja's and Alissa's discusses.

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2016-05-31 for -06)
Thank you for resolving the issues I raised.

(Ben Campbell; former steering group member) (was Discuss) No Objection

No Objection (2016-05-10 for -05)
Thanks for engaging on my previous DISCUSS points and comments.

(Benoît Claise; former steering group member) No Objection

No Objection (2016-05-04 for -05)
- OLD:

   This also recognizes that more
   work has already taken place for established sessions and, as a
   result, it might be more harmful if the session update and session
   ending requests were to be throttled.


NEW:
   This also recognizes that more
   work has already taken place for established sessions and, as a
   result, it might be more harmful from a signaling point of view 
   if the session update and session ending requests were to be throttled.

-

 1.  Request sender - The sender of a request, be it a Diameter Client
       or a Diameter Server, determines the relative priority of the
       request and includes that priority information in the request.

Question: what is the risk of DMRP ending up as the DSCP, i.e. 
Every end point changes the value to best service, and in the end, it's useless, and uniquely set by the operator.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -05)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -05)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -05)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-05-04 for -05)
I'd like to see text clarifying the responses to Ben & Alissa's discuss points.

(Mirja Kühlewind; former steering group member) (was Discuss) No Objection

No Objection (2016-05-11 for -05)
I still think this part needs further clarification mostly regarding applicability and maybe a warning as it could lead to starvation of requests that do not define a priority, e.g. because there are not supporting it (yet) while effectively having a higher priortiy than the requests that they get starved by:
"When using DRMP priority information, Diameter nodes MUST use the
   default priority for transactions that do not have priority specified
   in a DRMP AVP."

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -05)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -05)