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

Carl Wallace <carl@redhoundsoftware.com> Tue, 10 September 2013 01:07 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C91C21E8115 for <secdir@ietfa.amsl.com>; Mon, 9 Sep 2013 18:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level:
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-mLAdw93s0v for <secdir@ietfa.amsl.com>; Mon, 9 Sep 2013 18:07:23 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6602121E8107 for <secdir@ietf.org>; Mon, 9 Sep 2013 18:07:23 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id ii20so37480qab.5 for <secdir@ietf.org>; Mon, 09 Sep 2013 18:07:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=DB3+YBIO7vcfKtVAeW9bNCvmdXquzxtE0bNKaYgdOvQ=; b=J8MxQkOyjNagkx1COjp8WX7P7wQh7syz1JTCz/8WcS0C1Vij2Qb/VowL0Y2DVJNERr hYuwF7GqODZKglXz75szAWh+z3bpH99UjaRU/R3jD25HjcI7aj97iF70F3qmVZWckfOV hBFEmyNOskJFHPlm+NqHoi2xp9S2hVSitBIcuJb9Z7Cptvb8bm08VGQ9iqiymhCFZJOV CXKYpM2+62PuQN6qJl7TPWpgeiMdM7o53a2318HtKdCU+U8YXrNHB8Xr3tSr4Bt/MrLI qvx2iwZoWBKIS9tPWEHwf61WrK6c8EvTykAGNpnJkzJh6uMmOoApDzsCO/AruNABLdEf 2gBg==
X-Gm-Message-State: ALoCoQk/DCMg2S2/IhFNGgnh7+noz2DdtXpRLLR4XjfKMmZatiKvydIPFTe6nmRqAJo8tWy9EIcV
X-Received: by 10.49.1.166 with SMTP id 6mr14674370qen.65.1378775242525; Mon, 09 Sep 2013 18:07:22 -0700 (PDT)
Received: from [192.168.2.3] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id h6sm29701778qej.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Sep 2013 18:07:22 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Mon, 09 Sep 2013 21:07:15 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Eric McMurry <emcmurry@computer.org>
Message-ID: <CE53E4E1.1C81%carl@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-dime-overload-reqs-11
In-Reply-To: <B259C343-A289-422B-95EE-DCB46D818736@computer.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Ben Allen Campbell <ben@nostrum.com>, secdir@ietf.org, draft-ietf-dime-overload-reqs.all@tools.ietf.org, jouni.nospam@gmail.com, "lionel.morand@orange.com Morand" <lionel.morand@orange.com>, iesg@ietf.org, "bclaise@cisco.com Claise" <bclaise@cisco.com>
Subject: Re: [secdir] secdir review of draft-ietf-dime-overload-reqs-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 01:07:41 -0000

On 9/9/13 8:41 PM, "Eric McMurry" <emcmurry@computer.org> wrote:

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

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.


>
>Thanks!
>
>Eric
>
>
>On Sep 8, 2013, at 13:46 , Carl Wallace <carl@redhoundsoftware.com> wrote:
>
>> 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)?
>> 
>> 
>