Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

Benjamin Kaduk <kaduk@mit.edu> Wed, 24 July 2019 14:01 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9B120088; Wed, 24 Jul 2019 07:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYeYg0znoENI; Wed, 24 Jul 2019 07:01:07 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394AD12006F; Wed, 24 Jul 2019 07:01:07 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6OE12je011560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 10:01:05 -0400
Date: Wed, 24 Jul 2019 09:01:02 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: mohamed.boucadair@orange.com
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, Valery Smyslov <valery@smyslov.net>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Message-ID: <20190724140101.GI50840@kduck.mit.edu>
References: <DM5PR16MB17050AC5EABA8D76DDB42ACBEAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3433@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB1705DFCE2F9B379A36FD79AAEAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E34A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170553F3A8B1F3F1ED59D509EAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3792@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170505ABB7555E0ADCEC1BC6EAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3A41@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190724133415.GG50840@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B9330312E7566@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312E7566@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/NTZlKn1-vfqYW0Mm8AC3In_Sl0o>
Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 14:01:09 -0000

On Wed, Jul 24, 2019 at 01:49:40PM +0000, mohamed.boucadair@orange.com wrote:
> Hi Ben, 
> 
> IMO, this falls under this text:  
> 
>       A heartbeat-interval of 30 seconds may be considered as too chatty
>       in some deployments.  For such deployments, DOTS agents may
>       negotiate longer heartbeat-interval values to prevent any network
>       overload with too frequent keepalives.
> 
> Isn't it?

I think the document is quite clear that there are cases where 30 seconds
doesn't make sense.  My question is whether we want to be very explicit
about linking the "TCP is used" case as being one such case where 30
seconds doesn't make sense.  "No" is a fine answer, but I just wanted to
ask.

-Ben