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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 05 March 2019 13:14 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 276FC1310F1; Tue, 5 Mar 2019 05:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 PPXGDB6iWRsg; Tue, 5 Mar 2019 05:14:48 -0800 (PST)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 800D81310F0; Tue, 5 Mar 2019 05:14:46 -0800 (PST)
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=1551791511; h=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-microsoft-exchange-diagnostics:x-microsoft-antispam-prvs: 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-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=vtma14PbyWv4MtnvI8/MfFSLucSH4VNz5xWMGh wQya8=; b=Kov94HfhGexUjpMBm24K/RrZ14ZclfCE019RcuQe HtsyMbhQ2j0MPRqcDP1EC6y86+ZjnMeK+tfNPHOqK1gPpB1tqD qWkqDH3B/ge/GC/hcQVeLgPTNG3pw3jM0in0fOA3b6sfi6bsMY BJglnmnxamUnwHxad0mawAABXGbik8w=
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 5252_d3dd_d3a86f80_96d9_4bb9_a572_d7a61861dbea; Tue, 05 Mar 2019 06:11:51 -0700
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; Tue, 5 Mar 2019 06:14:36 -0700
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; Tue, 5 Mar 2019 06:14:37 -0700
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 06:14:35 -0700
Received: from DM6PR16MB2794.namprd16.prod.outlook.com (20.178.225.219) by DM6PR16MB3323.namprd16.prod.outlook.com (20.176.127.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Tue, 5 Mar 2019 13:14:35 +0000
Received: from DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::a948:401e:299e:4550]) by DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::a948:401e:299e:4550%6]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 13:14:35 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
CC: "dots@ietf.org" <dots@ietf.org>, "Teague, Nik" <nteague@Verisign.com>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "draft-ietf-dots-requirements@ietf.org" <draft-ietf-dots-requirements@ietf.org>
Thread-Topic: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
Thread-Index: AQHUyesDP1CNrYXQskG52S/8z8vxv6XqQ+wAgBK6aYCAABJGYA==
Date: Tue, 05 Mar 2019 13:14:35 +0000
Message-ID: <DM6PR16MB279468EF0A86282C9C8C4C0FEA720@DM6PR16MB2794.namprd16.prod.outlook.com>
References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> <5CE85A1F-16DC-485C-BA5F-278E0E8CFF3C@Verisign.com> <3089053C-CF9B-491A-ACB0-0BC053C50E88@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA232C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790CD35599D350A706FCD62EA7E0@BYAPR16MB2790.namprd16.prod.outlook.com> <E97DF3BB-6A6E-4137-81D7-F1D23DCAF4EB@kuehlewind.net> <BYAPR16MB279031D6757223953D3FFA04EA7E0@BYAPR16MB2790.namprd16.prod.outlook.com> <096F1055-0195-44E4-9259-4BA77F4E4669@kuehlewind.net>
In-Reply-To: <096F1055-0195-44E4-9259-4BA77F4E4669@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.201.107]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35da62f5-f4af-433c-dc26-08d6a16c83a1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR16MB3323;
x-ms-traffictypediagnostic: DM6PR16MB3323:
x-microsoft-exchange-diagnostics: 1;DM6PR16MB3323;23:6ruCpwNstxkgQfy+8bJNBhf1vSdjUrpHoNKaQ8/Vv+cr6VWx2LrYq36scWhOdZQQxuNP73M4ftCNj1cJDttS1O4BOttR+onB1DYSVEpvn1DqmfgWNJPHcQrSQ1Sw/tXpotSdEE+qYg1SQJSlbP240yHzvfOpqm8bF8cfG/3323MXek51xyBOOzVLYFhD7Aahtxu6BgNTpRgy+VwogiL73G+S6o9y48B+G10CEsKd4k4bDxRT7kiIoDwXbY5jjgDU0VlshLy2Uedz/hjht17rRb2l7ZmftVS1qUMQZTwSa5GbIv6nysJk8kNy9W178j/irXS2PD0m22PcuDB36jhbP9KY1RKOWWXmjW2kqjsTzTIr5LthjG4/GbAjIO59k6mlwrQ7b9EiWBi62QlH5hygIn4/kcW7HvpEQRHMLcXZ9TM6XWRYyYFRqIhxOda4gIB/T0hGjbKMdsTuxsuTxzxRZwreVqq2eg1TpgQtWfwNjaVSTGF533PAUHLhVYWepp2zgQx8gT0IACOKdeAnCA0zVZa5jR+e44J1VWYRdpUZMyHkEDNGy12WnLEsseiFQSQgMoQZlpSFelrO6OB/4QBM4Cejhf2q6gccDyTYtyjvnOuhkQJB6sli8JiDARJ1iCWHZZAmEJeFoGfLFE1YMovThY2B+RXhOOkWdtvP3+MFStrVcksNaea8hNSEnoPdM6zFYV2r7jLJAbDEgieJUM0bdxraYqUgBdpIUwHBZUrW+SuW+0ytqgcqSS87Lvqj8HnDHnO2BW469G3LwP0EG6dRAU6X6myx6QZcqyZdC9pKAydYo35ZOBnFqJ/by8vhsc4CM2zvI0Schcp5N6XSq3SZQ8IpNs25REkfszwA3TbohN7EXtj3dO4wc41ISuSLjDdqn8lb34W6CXwZ6wHzGuf5/FmD82i6JrGKuHUylY+2hNDNdofreu+K6am0jyYDGkM9rv0dENaSa6AlvVsEcTUWryjnzHLcEpcynLjxg8TG7SeqGWMeYzHveuZqVZrK/GIvCe598dmzwHKJ7JpDXmcpFrs221+IH7GwmQaa034LLgB65z5u2V+LjYTWyg5SITbyJRkc48X774u6VeTwq0/lwlCR9mVRtgeOvScItVRUOM+0u79eIvSyK11o8JGh/Gi/6AWLQRsYXQBD/iX3uTLnWulwkfreQ3Av+xHvXoSZoJpw3pspeLWYc20dwz4fs+LcirXOQ6xw1AOtSHUvXNdoxG8tATb7eVv4+tXLkyc28ZzA4QCOY371tN9eoSBCWarBAO6GsJm+yRHmuqLRNtjqDyWtCmGdYj3tka7WnigVIIdT+oCZ7YVN8299HaCvWOAtO71nmGdaFaG1jPF0OyzuEDu55YFUgk+4EaapY1ORE21pespwFHovvJWB3Jn67cUS0702xhPR9mNXY2+I6r5/aw==
x-microsoft-antispam-prvs: <DM6PR16MB3323B30E1C468807D151DEFBEA720@DM6PR16MB3323.namprd16.prod.outlook.com>
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(136003)(39860400002)(346002)(32952001)(13464003)(199004)(189003)(5660300002)(54906003)(224303003)(6246003)(7696005)(66574012)(80792005)(66066001)(186003)(26005)(81156014)(81166006)(105586002)(5024004)(305945005)(14444005)(316002)(76176011)(68736007)(11346002)(8936002)(106356001)(256004)(14454004)(93886005)(2906002)(86362001)(229853002)(446003)(52536013)(6116002)(33656002)(4326008)(6916009)(25786009)(53546011)(478600001)(99286004)(72206003)(71200400001)(71190400001)(3846002)(6506007)(102836004)(55016002)(486006)(74316002)(97736004)(53936002)(476003)(9686003)(6436002)(7736002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR16MB3323; H:DM6PR16MB2794.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: doevB+OEEryowUKKi+Xqbv2yhuB6Gfh04VZj+2jU15zyE2b9zFfaXUaGM9Sq7DSn/EfZXMv1f1RfBDY5z/OoAt1nFpLOWP3Wyw3TwouivGC/s03Hq4WDHlIX9A4a8yT/FFcEmTrPNo8G6U0CUF+5UkRPC8FAU9Nb8tb9cTrG0es3IakDolgVBdiF4l/zWjQ/DwUZk2wXHmfOJASSh6A0Bmh+RvPYUAVZfN79nYOWsA/vjksn2wqOrg1aZXydm5ZCw57Fr8q8aQ9BH17uiEEOtTY3QdePigMNf+hRBFfmlr7qOVARdIoigKIfY/PqTd4FFifpGhZ5Z4/MF6vexisgBn0lFENm4AYZCGN6VOi0xdxas3SEi72apmwhb5dX7IxGeN/Win4hYOPDUOZbjSx7/41e9mc20ZoT1B7ITJnKTLE=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 35da62f5-f4af-433c-dc26-08d6a16c83a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 13:14:35.5235 (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-Transport-CrossTenantHeadersStamped: DM6PR16MB3323
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.4
X-NAI-Spam-Version: 2.3.0.9418 : core <6496> : inlines <7025> : streams <1814825> : uri <2806982>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/U01rUzQyI2R3T1L1CG8A_L4vANw>
Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
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: Tue, 05 Mar 2019 13:14:52 -0000

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
> Sent: Tuesday, March 5, 2019 5:17 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> Cc: dots@ietf.org; Teague, Nik <nteague@Verisign.com>;
> frank.xialiang@huawei.com; The IESG <iesg@ietf.org>; dots-chairs@ietf.org;
> mohamed.boucadair@orange.com; draft-ietf-dots-requirements@ietf.org
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-
> 18: (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,
> 
> please see below.
> 
> > Am 21.02.2019 um 15:02 schrieb Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>:
> >
> >> -----Original Message-----
> >> From: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
> >> Sent: Thursday, February 21, 2019 7:10 PM
> >> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> >> Cc: mohamed.boucadair@orange.com; Teague, Nik
> <nteague@Verisign.com>;
> >> dots-chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; The
> >> IESG <iesg@ietf.org>; draft-ietf-dots-requirements@ietf.org
> >> Subject: Re: [Dots] Mirja Kühlewind's Discuss on
> >> draft-ietf-dots-requirements-
> >> 18: (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,
> >>
> >> please see below.
> >>
> >>> Am 21.02.2019 um 14:03 schrieb Konda, Tirumaleswar Reddy
> >> <TirumaleswarReddy_Konda@McAfee.com>:
> >>>
> >>>> -----Original Message-----
> >>>> From: mohamed.boucadair@orange.com
> >> <mohamed.boucadair@orange.com>
> >>>> Sent: Thursday, February 21, 2019 5:55 PM
> >>>> To: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>; Teague, Nik
> >>>> <nteague@Verisign.com>
> >>>> Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org;
> >>>> The IESG <iesg@ietf.org>; draft-ietf-dots-requirements@ietf.org
> >>>> Subject: RE: Re: [Dots] Mirja Kühlewind's Discuss on
> >>>> draft-ietf-dots-
> >>>> requirements-18: (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.
> >>>>
> >>>> Re-,
> >>>>
> >>>> Please see inline.
> >>>>
> >>>> Cheers,
> >>>> Med
> >>>>
> >>>>> -----Message d'origine-----
> >>>>> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] Envoyé :
> >>>>> jeudi 21 février 2019 12:42 À : Teague, Nik Cc : BOUCADAIR Mohamed
> >>>>> TGI/OLN; dots-chairs@ietf.org; frank.xialiang@huawei.com;
> >>>>> dots@ietf.org; The IESG; draft-ietf-dots- requirements@ietf.org
> >>>>> Objet
> >>>>> : Re: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-
> >>>>> requirements-18: (with DISCUSS and COMMENT)
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> please see below.
> >>>>>
> >>>>>> Am 21.02.2019 um 12:18 schrieb Teague, Nik <nteague@Verisign.com>:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>
> >>>>>> On 21 Feb 2019, at 10:58, Mirja Kuehlewind (IETF)
> >>>>>> <ietf@kuehlewind.net>
> >>>>> wrote:
> >>>>>>
> >>>>>>>>> 3) In SIG-006 you say:
> >>>>>>>>> "      Due to the higher likelihood of packet loss during a DDoS
> attack,
> >>>>>>>>>  DOTS servers MUST regularly send mitigation status to
> >>>>>>>>> authorized  DOTS clients which have requested and been granted
> >>>>>>>>> mitigation,  regardless of client requests for mitigation status."
> >>>>>>>>>
> >>>>>>>>> Please note that this is only true if a not-reliable transport is used.
> >>>>> If a
> >>>>>>>>> reliable transport is used, data is received at the
> >>>>>>>>> application level
> >>>>> without
> >>>>>>>>> loss (but maybe some delay) or the connection is terminated
> >>>>>>>>> (if loss is
> >>>>> too
> >>>>>>>>> high to retransmit successfully).
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> [Med] The requirement as worded is OK.
> >>>>>>>
> >>>>>>> I disagree, because as I said if a reliable transport is used
> >>>>>>> this is not
> >>>>> true. Maybe you can adapt this sentence slightly to clarify that
> >>>>> you probably had a scenario in mind where an unreliable transport
> >>>>> is used
> >>>>>>
> >>>>>> The key part here is ‘packet’ vs ‘data’ - packets will be lost on
> >>>>>> congested
> >>>>> links regardless of data integrity.  This may degrade connection
> >>>>> re- establishment with tcp and cause data loss in an unreliable transport.
> >>>>>
> >>>>> Yes, packet loss also occurs also with reliable transports and
> >>>>> might lead to connection failure. However, I don’t this how this
> >>>>> requirement is derived from that effect. If I use a reliable
> >>>>> transport and my connection does not fail, I can be sure that the
> >>>>> mitigation status information have been received correctly, so why
> >>>>> do I need to re-send
> >>>> frequently then?
> >>>>
> >>>> [Med] The text you quoted is not about "frequent retransmission"
> >>>> but about sending updates related to the status of a mitigation in
> >>>> progress. The server has to send regular notifications to update
> >>>> the client about the status of a mitigation.
> >>>
> >>> I have modified the text as follows to address the comment:
> >>>
> >>> DOTS server MUST regularly send mitigation status updates to
> >>> authorized
> >> DOTS clients which have requested and been granted mitigation. If
> >> unreliable transport is used for the signal channel protocol, due to
> >> the higher likelihood of packet loss during a DDoS attack, DOTS
> >> server MUST regularly retransmit mitigation status.
> >>
> >> Thanks! One wording comment, unless I misunderstood something, I
> >> don’t think there is any kind of acknowledgment mechanism when
> >> unreliable transport is used. There the use of the word „retransmit“
> >> seems irritating here. Do you maybe want to say something like this:
> >>
> >> "DOTS server MUST regularly send mitigation status updates to
> >> authorized DOTS clients which have requested and been granted
> >> mitigation. If unreliable transport is used for the signal channel
> >> protocol, due to the higher likelihood of packet loss during a DDoS
> >> attack, DOTS server SHOULD send mitigation status updates more
> >> frequently.“
> >
> > The updated mitigation status needs to be sent multiple times to increase the
> likeliness of the message reaching the client, and any specific reason for using
> SHOULD instead of MUST. I propose the following update:
> > DOTS server MUST regularly send mitigation status updates to authorized
> DOTS clients which have requested and been granted mitigation. If unreliable
> transport is used for the signal channel protocol, due to the higher likelihood of
> packet loss during a DDoS attack, DOTS server MUST send mitigation status
> multiple times at regular intervals following the data transmission guidelines
> discussed in Section 3.1.3 of [RFC8085].
> 
> I’m in general okay with this. The reason why I used SHOULD is because this
> requirement is quite „blurry“. You say " MUST send mitigation status multiple
> times at regular intervals“, however, how often is multiple time and which
> interval? If you say something like "MUST send mitigation status at least every
> 10 seconds for at least 3 minutes“ then a MUST would be appropriate, however,

The transmission behavior is discussed in detail in the signal channel draft, it follows the recommendations in RFC8085. 

> otherwise I would actually suggest to not use normative language in this
> sentence as all (as you already have a normative requirement in the first
> sentence and therefore this sentence is more additional explanation than a
> separate requirement). Please also note (again) that RFC8085 recommends to
> not send such messages more often than every 3 seconds as well as the
> implementation of exponential back-off.

I have already published revised draft using the above text. If you insist, I can update the draft to say:

DOTS server MUST regularly send mitigation status updates to authorized
DOTS clients which have requested and been granted mitigation. If unreliable
 transport is used for the signal channel protocol, due to the higher likelihood of
 packet loss during a DDoS attack, DOTS server needs to send mitigation status
 multiple times at regular intervals following the data transmission guidelines
 discussed in Section 3.1.3 of [RFC8085].

Cheers,
-Tiru

> 
> Mirja
> 
> 
> 
> >
> > -Tiru
> >
> >>
> >> ?
> >>
> >> Mirja
> >>
> >>
> >>
> >>>
> >>> -Tiru
> >>>
> >>>>
> >>>>>
> >>>>> Mirja
> >>>>>
> >>>>>
> >>>>>
> >>>
> >