Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Mon, 15 July 2019 12:38 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
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 6E147120112 for <dots@ietfa.amsl.com>; Mon, 15 Jul 2019 05:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.com
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 N67sFgC9h3dJ for <dots@ietfa.amsl.com>; Mon, 15 Jul 2019 05:38:01 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963951200F4 for <dots@ietf.org>; Mon, 15 Jul 2019 05:38:01 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563193522; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=raIA7W08iLM957C/RM6kDpgIKSUm4uE6NhkpOq eRg8s=; b=Y55N5odQZmEBwLqBy3JOYiKuUETzoxTW1zZTMRsA 4jJO9w7Ciq7JCw4maZ6PVYms0qD2IAVeMJZPhoEcIdqiAUWBt3 +p7ipRK/3+AFlSpId7dyddfPUwhS9OEmHa5AOLBT/5UNKh4B4j 7NFshLycnLfhqJszwZi+50rKXw0NoSQ=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-314-NDYuuFaGPgySiscf7dNrhg-1; Mon, 15 Jul 2019 08:36:10 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6804_fcb2_d2c25e77_a655_45f3_a3f8_a8f36ab7ddba; Mon, 15 Jul 2019 06:25:22 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 06:36:07 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 15 Jul 2019 06:36:07 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jul 2019 06:36:05 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K7PbhdcIhDf4jZsVG3u0/TwiIu2dX5pwmw90fJEbnvrFkKbhLR1c4uwUOtcEAUiOK6KFAMlyk4LKyGUuDdLQ7Ba9LYEYmcRJIMnRnLogW3xczTxwxJLeRQChf/4hKWXV5MZgv34eFvaIZVxWvsfU7XWKJ/zHYBnHsumWnj7gKz6W2CD/cgooQYssgHY5nlhh85KQF3wO0zHJdyqdsa20LdzsFzE8kEYwdhDpfEDEfFfW4/q+CRWH0x997T0hVG2ylp3luF5+T2LA1LkD+/BcR4dWQojAPDjfZz4u2gVn3eCPYzW6VtF17fEdFY5m0cVLR7hB3J9+3vk9GurOQ7Bu4w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=raIA7W08iLM957C/RM6kDpgIKSUm4uE6NhkpOqeRg8s=; b=P5oJXkzrnrQqFq6fPw1sBSc/AWzoZJF4EwqARmqEbRMQvVvI9pLIY/eqKS/VYPaT3RrB6+sdJSJ7YhAqHhTpCoErZbqGRMWkM4ArKCSNygTwRIF6jYh1fmrKRAKdmsIXMZkZLh44C8xeF8KB6sRNWowNlNIpBT6GGDJtbktyKbWZelaPw/b0Ht6Wv6eaxq8anWYyo+kRXyWC04dHItxenF7SgQsMOsTMygc6glvTiRsXXospgaSLUA7j1pVLMCsiGOJD9G9CxwoSUxmz2MyUr2Yzl3/3vl5z4REABWIyk0A8SwiTqSLfPh7B2lRmVsJLMHVwLrN8r601XoxhBzKEIw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1369.namprd16.prod.outlook.com (10.173.211.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 12:36:04 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 12:36:04 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Mirja Kuehlewind" <ietf@kuehlewind.net>
CC: Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "draft-ietf-dots-data-channel@ietf.org" <draft-ietf-dots-data-channel@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Thread-Topic: =?utf-8?B?W0RvdHNdICBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI4OiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?=
Thread-Index: AQHVAN3ugjmuTslNjEWiBUcliI6afaa2ROeAgAAN3QCAAQGxAIAAaHOAgAABS2CAAButAIABDrLggACR7gCAABOmgIASg4sA
Date: Mon, 15 Jul 2019 12:36:04 +0000
Message-ID: <DM5PR16MB17054F2FB032B9ABB5199DE9EACF0@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <155679628494.24951.9145538661531263463.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68C8B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190701154032.GB13810@kduck.mit.edu> <A4BD2109-EC58-4FED-A8B0-2EE5AC47A69C@kuehlewind.net> <DM5PR16MB1705BED0F42996593B0C0A70EAF80@DM5PR16MB1705.namprd16.prod.outlook.com> <24FFE7CE-B91A-4CF4-BB85-D6108ACE0043@kuehlewind.net> <DM5PR16MB170529399AC19B88B321A35DEAF80@DM5PR16MB1705.namprd16.prod.outlook.com> <642531B0-3E3A-4A5C-BD20-C74AA3698936@kuehlewind.net> <DM5PR16MB170519F8C328B05B9ED61EECEAFB0@DM5PR16MB1705.namprd16.prod.outlook.com> <AD83F907-35D8-4F44-9DEC-8ABB8E27A6EF@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB345F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAB345F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a97f9e76-fe8b-4ebe-58bf-08d70921009f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1369;
x-ms-traffictypediagnostic: DM5PR16MB1369:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DM5PR16MB136941CB44C100DDA349DCA6EACF0@DM5PR16MB1369.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00997889E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(376002)(346002)(136003)(32952001)(199004)(189003)(13464003)(14454004)(68736007)(25786009)(478600001)(4326008)(33656002)(9686003)(3846002)(6116002)(966005)(71200400001)(2906002)(53936002)(2501003)(6246003)(229853002)(80792005)(6306002)(6436002)(55016002)(11346002)(446003)(476003)(316002)(5024004)(224303003)(14444005)(66066001)(26005)(53546011)(54906003)(110136005)(66446008)(74316002)(305945005)(8936002)(66556008)(64756008)(81166006)(66476007)(66946007)(76116006)(5660300002)(66574012)(86362001)(81156014)(6506007)(186003)(52536014)(7736002)(76176011)(102836004)(486006)(71190400001)(99286004)(7696005)(256004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1369; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: remscmOGVSvHxeTRS+dO0D39pr7hggt/iBP3ZeQymmqyC2fhzn/mGHyZoyFQdzS2eJrp7UNPuQ7CaiSi3vNEmpicc1Luh1QNwyrHLTQ9LP0QeWzYWpE40nchuikG36N0Tw+Bvv4CQ+1l0bdd2CXRja71EZtOTExEc6hgfa8u1eqlxdtZN7oG1U2Kwrlo36UE9iw4K6fQ/43OvFxfyPQwQOKymoxWiMXUy8ZNTKCeHwCcnjrlKxhR1hgUE1TYmOY0xthx+Cpbkg7p+88UapWYbk2UweS++XrwZyLAUHR3hjgTsJwDczMpTUpqk9XsZqtq40uoPYNqmbqMBZ6vYd0phj7fREbjkoqJf02f36S9Pc7rQULD/lOFNNNUoNik8Fvt67d28f37KsyOYQWvQ3HMnqpR0hFs1GkqocRboBAl0qw=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a97f9e76-fe8b-4ebe-58bf-08d70921009f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 12:36:04.3897 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1369
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.2
X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7119> : streams <1827423> : uri <2867825>
X-MC-Unique: NDYuuFaGPgySiscf7dNrhg-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/pCfe-RjVG14TQ6JgPMbwpfJ-Kuk>
Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-data-channel-28=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Mon, 15 Jul 2019 12:38:03 -0000

Hi Mirja,

We have updated the draft to address your Discuss (please see https://tools.ietf.org/html/draft-ietf-dots-data-channel-30) and Med responded to your comments. 
Please have a look and approve the draft.

Best Regards,
-Tiru

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>;
> Sent: Wednesday, July 3, 2019 11:21 PM
> To: Mirja Kuehlewind <ietf@kuehlewind.net>;; Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;
> Cc: Roman Danyliw <rdd@cert.org>;; dots@ietf.org; The IESG <iesg@ietf.org>;;
> dots-chairs@ietf.org; draft-ietf-dots-data-channel@ietf.org; Benjamin Kaduk
> <kaduk@mit.edu>;
> Subject: RE: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
> channel-28: (with DISCUSS and COMMENT)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net] Envoyé : mercredi 3
> > juillet 2019 18:41 À : Konda, Tirumaleswar Reddy Cc : Roman Danyliw;
> > dots@ietf.org; The IESG; dots-chairs@ietf.org; draft-
> > ietf-dots-data-channel@ietf.org; BOUCADAIR Mohamed TGI/OLN;
> Benjamin
> > Kaduk Objet : Re: [Dots] Mirja Kühlewind's Discuss on
> > draft-ietf-dots-data-
> > channel-28: (with DISCUSS and COMMENT)
> >
> > Hi Tiru, hi Med,
> >
> > Please see below.
> >
> > > On 3. Jul 2019, at 10:00, Konda, Tirumaleswar Reddy
> > <TirumaleswarReddy_Konda@McAfee.com>; wrote:
> > >
> > > Hi Mirja,
> > >
> > > Please see inline
> > >
> > >> -----Original Message-----
> > >> From: Mirja Kuehlewind <ietf@kuehlewind.net>;
> > >> Sent: Tuesday, July 2, 2019 9:20 PM
> > >> To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;
> > >> Cc: Benjamin Kaduk <kaduk@mit.edu>;; Roman Danyliw <rdd@cert.org>;;
> > >> dots@ietf.org; The IESG <iesg@ietf.org>;; dots-chairs@ietf.org;
> > >> mohamed.boucadair@orange.com; draft-ietf-dots-data-
> channel@ietf.org
> > >> Subject: Re: [Dots] Mirja Kühlewind's Discuss on
> > >> draft-ietf-dots-data-
> > >> channel-28: (with DISCUSS and COMMENT)
> > >>
> > >> This email originated from outside of the organization. Do not
> > >> click
> > links or
> > >> open attachments unless you recognize the sender and know the
> > >> content
> > is
> > >> safe.
> > >>
> > >> Hi Tiru,
> > >>
> > >> Below...
> > >>
> > >>> On 2. Jul 2019, at 16:22, Konda, Tirumaleswar Reddy
> > >> <TirumaleswarReddy_Konda@McAfee.com>; wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Mirja Kuehlewind <ietf@kuehlewind.net>;
> > >>>> Sent: Tuesday, July 2, 2019 7:36 PM
> > >>>> To: Konda, Tirumaleswar Reddy
> > >> <TirumaleswarReddy_Konda@McAfee.com>;
> > >>>> Cc: Benjamin Kaduk <kaduk@mit.edu>;; Roman Danyliw
> <rdd@cert.org>;;
> > >>>> dots@ietf.org; The IESG <iesg@ietf.org>;; dots-chairs@ietf.org;
> > >>>> mohamed.boucadair@orange.com;
> > >>>> draft-ietf-dots-data-channel@ietf.org
> > >>>> Subject: Re: [Dots] Mirja Kühlewind's Discuss on
> > >>>> draft-ietf-dots-data-
> > >>>> channel-28: (with DISCUSS and COMMENT)
> > >>>>
> > >>>>
> > >>>>
> > >>>> Hi Tiru,
> > >>>>
> > >>>> Please see below.
> > >>>>
> > >>>>> On 2. Jul 2019, at 09:55, Konda, Tirumaleswar Reddy
> > >>>> <TirumaleswarReddy_Konda@McAfee.com>; wrote:
> > >>>>>
> > >>>>>>>>> I would also quickly like to discuss the use of keep-alives
> > >>>>>>>>> as described in Section 3.1: "While the communication to the
> > >>>>>>>>> DOTS server is  quiescent, the DOTS client MAY probe the
> > >>>>>>>>> server to ensure it has  maintained cryptographic state.
> > >>>>>>>>> Such probes can also keep alive  firewall and/or NAT
> > >>>>>>>>> bindings.  A TLS heartbeat [RFC6520] verifies  that the DOTS
> > >>>>>>>>> server still has TLS state by returning
> > >>>> a TLS message."
> > >>>>>>>>> I understood that multiple requests can and should be send
> > >>>>>>>>> in the same connection, however, I would expect that those
> > >>>>>>>>> requests are send basically right after each other, such as
> > >>>>>>>>> a look-up and then change of the config. I don't see a need
> > >>>>>>>>> to keep up the connection for a
> > >>>>>> long time otherwise.
> > >>>>>>>>> Especially any action performed are (other than in the
> > >>>>>>>>> signal channel case) not time critical. Therefore I would
> > >>>>>>>>> rather recommend to close and reopen connections and not
> > >>>>>>>>> recommend
> > >> to
> > >>>> use
> > >>>>>>>>> keep-alives at all.
> > >>>>>>>>
> > >>>>>>>> [Med] The activity of the DOTS client may be used to
> > >>>>>>>> track/detect stale
> > >>>>>> entries:
> > >>>>>>>>
> > >>>>>>>> Also, DOTS servers
> > >>>>>>>> may track the inactivity timeout of DOTS clients to detect
> > >>>>>>>> stale entries.
> > >>>>>>>>
> > >>>>>> My understanding is that this is orthogonal. You can also see
> > >>>>>> that a client is inactive when it didn’t open a new connection
> > >>>>>> for a
> > certain
> > >> time…?
> > >>>>>
> > >>>>> The drop-list rules could be frequently updated by the DOTS
> > >>>>> client based on the tests used by the DOTS client domain (e.g.
> > >>>>> cryptographic
> > >>>>> challenge) to detect whether the IP address is for legitimate
> > >>>>> use or not, or based on threat intelligence feeds from security
> > >>>>> vendors providing the botnet/malicious IP addresses feed.
> > >>>>> Further, persistent DOTS data channel is required to handle
> > >>>>> updates to target resources (e.g. CDN hosting a domain, and it
> > >>>>> needs DDoS protection) and target IP/prefix may also change
> > >>>>> frequently (mobile branch office, prefix re-numbering etc.)
> > >>>>
> > >>>> This still doesn’t sounds like it is desirable to keep the TCP
> > connection
> > >> open.
> > >>>> Also if you can bear the time to reconnect (1-2 RTT for the
> > >>>> handshake) that is usually the better and easier options. I don’t
> > >>>> think the information we talk about here are that time-critical,
> > >>>> is it? When you say frequent what time frame do you mean, Hours,
> > minutes,
> > >> seconds, milliseconds?
> > >>>
> > >>> The frequency of updates to drop-list rules can be few milliseconds.
> > For
> > >> example, CAPTCHA and cryptographic puzzles can be used by DOTS
> > >> client domain to determine whether the IP address is used for
> > >> legitimate
> > purpose
> > >> or not, and can configure the drop-list rules.
> > >>> Further, the specification does not mandate the connection to be
> > >> persistent, but when needed, the probe mechanism applies.
> > >>
> > >> Then it really seems to me that the document would need to provide
> > further
> > >> guidance when a persistent connection is useful or when it is
> > >> recommend
> > to
> > >> close the connection (and reopen if needed).
> > >
> > > Sure, will add the following text:
> > >
> > >   A DOTS client can either maintain a persistent connection or periodic
> > >   connections with its DOTS server(s).  If the DOTS client needs to
> > >   frequently update the drop-list or accept-list filtering rules or
> > >   aliases, it maintains a persistent connection with the DOTS server.
> > >   For example, CAPTCHA and cryptographic puzzles can be used by the
> > >   mitigation service in the DOTS client domain to determine whether the
> > >   IP address is used for legitimate purpose or not, and the DOTS client
> > >   can frequently update the drop-list filtering rules.  A persistent
> > >   connection is also useful if the DOTS client subscribes to event
> > >   notifications (Section 6.3 of [RFC8040]).
> > >
> > > - Tiru and Med
> >
> > Thanks!
> >
> > Two more small comments:
> >
> > At least to me the term “periodic" is not clear. I guess mean
> > something like short-lived connections, where you have a request, you
> > open a connection, send it, get a reply, and close the connection
> > immediately or after a short idle period. Or is there actually any
> > kind of periodicity in the dots protocol in general? Can you pleas clarify.
> 
> [Med] We are trying to reuse the same terminology as RESTCONF (draft-ietf-
> netconf-restconf-client-server).
> 
> For the DOTS case, the DOTS client is required to register and send requests
> to refresh the registration in regular intervals (otherwise, the DOTS client
> won't be able to created filters). Likewise, cycles will be observed because
> the client will need to maintains the aliases and ACLs it created. The client
> may use these cycles for any planned activity (create new aliases, create a
> new filter, etc.) or not.
> 
> >
> > Also if a persistent connection is used, I think it would (again) be
> > good to clarify what should be done if the connection fails. I think
> > the right advise in this case, is to not reconnect immediately but
> > only if you have another request to send, right?
> >
> 
> [Med] draft-ietf-netconf-restconf-client-server voices for the following:
> 
>    Maintain a persistent connection to the
>    RESTCONF server. If the connection goes down,
>    immediately start trying to reconnect to the
>    RESTCONF server, using the reconnection strategy.
> 
> Which is the right approach, IMO.
> 
> We didn't touched on connection management because we are relying on
> RESTCONF. DOTS will use whatever strategy adopted for RESTCONF.
> 
> I don't think it is a good idea to add specific behavior into our spec.
> 
> 
> 
> > Mirja
> >
> >
> > >
> > >>
> > >> Mirja
> > >>
> > >>
> > >>>
> > >>> -Tiru
> > >>>
> > >>>>
> > >>>> Mirja
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> Further, we are not mandating the connection to be persistent,
> > >>>>> but when
> > >>>> needed, the probe mechanism applies. Please note
> > >>>> https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-ser
> > >>>> ver-
> > >>>> 13 discusses persistent-connection and it’s a client preference
> > >>>> on how the connection is maintained (persistent or periodic).
> > >>>
> > >