Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 04 May 2016 10:02:52 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-dime-drmp-05: No Objection

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/

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

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 May 2016 12:44:57 -0500

I will jump in on one point, since this is related to the discussion on 
whether nodes need a common approach to selecting/interpreting priority 
values:

> useless, and uniquely set by the operator.

I think there's a trusted network assumption here, which would include 
an assumption that trusted clients do not intentionally game the system. 
(in contrast with _accidentally_ gaming the system by using a different 
scheme to set priority values.)

However, I think that this sort of assumption should be explicitly 
mentioned. IIRC, DOIC included some guidance about crossing trust 
boundaries; perhaps DRMP should do the same.

(And I guess that does make it a bit like DSCP ;-)  )

Ben.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 May 2016 13:43:40 -0500

My comments inline.

Regards,

Steve

> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/
SRD> I'm ok with this change.
> useless, and uniquely set by the operator.
SRD> I think Ben answered this.

---

From: Benoit Claise <[email-masked]>
Date: Sun, 8 May 2016 14:09:51 +0200

Ben,
> I will jump in on one point, since this is related to the discussion 
> on whether nodes need a common approach to selecting/interpreting 
> priority values:
>
> an assumption that trusted clients do not intentionally game the 
> system. (in contrast with _accidentally_ gaming the system by using a 
> different scheme to set priority values.)
>
> mentioned. 
I believe so.
> IIRC, DOIC included some guidance about crossing trust boundaries; 
> perhaps DRMP should do the same.
Yes.
That makes me think. I wonder how the following two statements are 
interoperable?

    Diameter nodes MUST have a default priority to apply to transactions
    that do not have an explicit priority set in the DRMP AVP.

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

Shouldn't the last SHOULD be a MUST?

Let me explain: a Diameter node wants to send Diameter messages with 
priority above average, so PRIORITY = 12 (because his default is 10). 
Along the path (potentially crossing a boundary), a Diameter node 
doesn't support the DRMP AVP. The next node, which does, sets his 
default priority. The default priority on that node has been configured 
as 13. And now, my Diameter messages will be treated as below average.
Do I miss anything?

Regards, Benoit

> .

---

From: Steve Donovan <[email-masked]>
Date: Tue, 10 May 2016 16:16:18 -0500

Benoit,

Please see my comments inline.

Regards,

Steve

On 5/8/16 7:09 AM, Benoit Claise wrote:
>> I think there's a trusted network assumption here, which would 
>> include an assumption that trusted clients do not intentionally game 
>> the system. (in contrast with _accidentally_ gaming the system by 
>> using a different scheme to set priority values.)
>>
SRD> The reason it is a SHOULD is to allow for an operator to define a 
priority scheme with a different value, much as you outline below.
> default priority. The default priority on that node has been 
> configured as 13. And now, my Diameter messages will be treated as 
> below average.
> Do I miss anything?
SRD> Yes, as described, this would be an issue.  This is one of the 
reasons that the DISCUSS threads have focused on the need to emphasize 
that this mechanism only works if a consistent priority scheme is 
applied to all messages and that it only works within a trusted 
environment.  This implies that priority values received from other 
Diameter networks likely can't be trusted.

SRD> It may be necessary to add a requirement that the priority value 
MUST be the same for all nodes within the Diameter network using a 
defined priority scheme.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 May 2016 12:53:05 -0400

On 5/10/2016 5:16 PM, Steve Donovan wrote:
> environment. 
BC> This assumption should be spelled out.
> This implies that priority values received from other Diameter 
> networks likely can't be trusted.
>
BC> That would help yes.

regards, B.