Subject: [secdir] secdir review of draft-ietf-dime-overload-reqs-11

From: Carl Wallace <[email-masked]>
Date: Sun, 08 Sep 2013 14:46:00 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

This document describes the limitations of the existing Diameter overload
mechanisms and provides requirements for new overload management
mechanisms.  The document is very well written and clear.  I had just two
comments:

1) The last sentence of Requirement 13 is a bit hard to parse.

2) Requirement 31 requires indication of overload at specified
granularities (realm, application, node).  Should overload status
mechanisms have similar granularity requirements (see requirements 10 or
24)?

---

From: Eric McMurry <[email-masked]>
Date: Mon, 9 Sep 2013 19:41:52 -0500

Hi Carl,

Thanks for taking the time to look at this and provide comments.

For your first comment, we think it would be fine to drop the last sentence of requirement 13 to avoid confusion.  It is not necessary.

For your second, are you asking if the load levels in req 24 should have granularity requirements?  It may make sense for a load metric to have similar granularity to the overload information, but the thinking was that the load metric may be used in different ways and we did not want to constrain it.

I'm a bit lost on how requirement 10 would relate to this though.  Can you please elaborate a bit on the question?

Thanks!

Eric

---

From: Carl Wallace <[email-masked]>
Date: Mon, 09 Sep 2013 21:07:15 -0400

On 9/9/13 8:41 PM, "Eric McMurry" <[email-masked]> wrote:

>For your first comment, we think it would be fine to drop the last
>sentence of requirement 13 to avoid confusion.  It is not necessary.
>
>For your second, are you asking if the load levels in req 24 should have
>granularity requirements?  It may make sense for a load metric to have
>similar granularity to the overload information, but the thinking was
>that the load metric may be used in different ways and we did not want to
>constrain it.
>
>I'm a bit lost on how requirement 10 would relate to this though.  Can
>you please elaborate a bit on the question?

Requirement 31 states:

"The solution MUST allow Diameter nodes to indicate overload with
sufficient granularity to allow clients to take action based on the
overloaded resources without unreasonably forcing available capacity to go
unused.  The solution MUST support specification of overload information
with granularities of at least "Diameter node", "realm", and "Diameter
application", and MUST allow extensibility for others to be added in the
future."

Requirement 10 states:

"Consumers of overload information MUST be able to determine when the
overload condition improves or ends"

My question was, must consumers of overload information be able to
determine when the overload condition <for some specified granularity>
improves or ends?   Requirement 10 seems to be addressing a type of action
a client may take based on granular information provided under requirement
31.  

More or less the same question applied to 24 as well, maybe not as an
action following overload as in requirement 10 but perhaps as an action
with similar granular needs.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 09 Sep 2013 21:27:17 -0400

>
>
>
>The intent was that the overload condition has granularity. That is, the
>overloaded node indicates an overload condition with some granularity,
>and later ends it. The act of ending doesn't change the granularity. We
>don't have an explicit requirement to be able to change the granularity
>of an existing condition. (Although we do not prevent a solution from
>offering that ability--but I suspect if the solution did that, it would
>involve multiple concurrent overload conditions, or ending one condition
>and starting another.)

Got it.  Thanks.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Sep 2013 06:22:19 +0300

Folks,

So if I got it right, the last sentence of the Req13 will be removed and
the Req31 stays as it is now.

This would be fine with me.

- JOuni

---

From: Eric McMurry <[email-masked]>
Date: Mon, 9 Sep 2013 22:24:13 -0500

that matches what I came away with.  How would you like us to address that?

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Sep 2013 06:55:37 +0300

I would note down the change but implement/submit a revision after we get
the rest of the IESG comments (the doc is in next week's telechat). That's
because ADs (and others) are now reading the -11.

- Jouni

---

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Sep 2013 08:10:50 +0200

Actually, it might be better to quickly publish a new version (as 
opposed to me writing down a RFC editor note), because the IESG is still 
busy reading the document for this Thursday telechat.

Regards, Benoit

---

From: Eric McMurry <[email-masked]>
Date: Tue, 10 Sep 2013 08:25:47 -0500

okay Benoit.  I'll do that this morning.

Thanks,

Eric

On Sep 10, 2013, at 1:10 , Benoit Claise <[email-masked]> wrote:

> Actually, it might be better to quickly publish a new version (as opposed to me writing down a RFC editor note), because the IESG is still busy reading the document for this Thursday telechat.
> 
> Regards, Benoit

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Sep 2013 20:20:25 -0500

> On 9/9/13 8:41 PM, "Eric McMurry" <[email-masked]> wrote:

[...]

> a client may take based on granular information provided under requirement

The intent was that the overload condition has granularity. That is, the overloaded node indicates an overload condition with some granularity, and later ends it. The act of ending doesn't change the granularity. We don't have an explicit requirement to be able to change the granularity of an existing condition. (Although we do not prevent a solution from offering that ability--but I suspect if the solution did that, it would involve multiple concurrent overload conditions, or ending one condition and starting another.)

> with similar granular needs.

Since 24 talks of "load" rather than "overload", we assumed your question concerned whether "load" needed the same or similar granularities to "overload". Did you mean something different?

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Sep 2013 22:24:20 -0500

> This would be fine with me.

That is my understanding. Or more precisely, the last sentence of Req13 will be removed, and nothing else will change.