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

[<[e-mail]>]

Hi Alissa,

Thank you for your review.
Please find below some clarifications, waiting for authors feeback.

Regards,

Lionel

Envoyé depuis Surface

De : Alissa Cooper<mailto:[e-mail]>
Envoyé : ‎mardi‎ ‎3‎ ‎mai‎ ‎2016 ‎23‎:‎31
À : [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>, Lionel MORAND<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, Lionel MORAND<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>

Alissa Cooper 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:
----------------------------------------------------------------------

(1) Given the two key security threats identified in Section 11 -- that
authorized nodes can issue requests with artificially high priority in
order to get better treatment, and that unauthorized intermediaries can
modify the priorities that senders set -- I don't see how it is
legitimate to claim that either 5.1 or 5.2 are appropriate use cases for
DRMP. The spec seems to assume that this mechanism will only be used in
scenarios where nodes and agents have some out-of-band trust relationship
established with each other (the shepherd write-up talks about a "trusted
environment"), but that is certainly not the case in many disaster and
emergency scenarios. If that really is a limitation on the scope of
applicability of this mechanism, that should be stated in the document,
and those use cases should either be removed or modified to explain the
limitations on their applicability.

[LM] I think that what is missing is that Diameter is mainly (if not only) used in mobile operator networks. The text makes reference to the RFC7683 where the overoload contgrol mechanism is introduced to solve overload situations in telco networks. This additional mechanism is seen as a complement of this overload control mechanism. Now, if it is understood that it is a mechanism defined for “trusted environment” i.e. mobile networks, the use of priority indications in emergency and disaster scenarios seems legitimate.

(2) Section 6 says:

    "The mechanism for how the agent determines which requests are
       throttled is implementation dependent and is outside the scope of
       this document."

How is a node supposed to determine how to set its priorities if each
agent makes implementation-specific decisions about what those priorities
mean? I understood the document to be saying that Diameter applications
would have to define what he priority levels mean within their own
contexts, but then I would have expected the interpretation of priorities
amongst all nodes and agents implementing the same application to be the
same.

[LM] I understand. I think that the text should say “The mechanism for how the agent determines which requests are c(candidates) to be throttled”. And, when there are requests to throttle, the priority indication is used to determine “which requests to route first, which requests to throttle and where the request is routed.  For instance, requests with higher  priority might have a lower probability of being throttled. ”.

(3) Section 8 says:

 "Diameter nodes SHOULD use the PRIORITY_10 priority as this default
value."

If the determination of the priority schemes are all
application-specific, how is it appropriate for this spec to define what
the default priority should be for all applications? Shouldn't
applications specify their own defaults?

[LM] it is needed to take into account that the use of priority indication in Diameter will be optional and that legacy implementation will not include any priority indication in Diameter requests. After discussion, it was decided that requests without priority should be handled as with a priority set to 10. This makes the difference with requests with an explicit lower priorities and other with higher priorities. 10 is used as “average” priority, with the possibility of specific operator policies to use another value.

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

Section 11 says: "DRMP gives Diameter nodes the ability to influence
which requests are throttled during overload scenarios." But the
information is not limited to use during overload scenarios, and the spec
specifically allows its use for prioritized routing in absence of
overload. This should be stated here too.

[LM] right.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.