From nobody Mon Feb 4 00:31:35 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17606124D68; Mon, 4 Feb 2019 00:31:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <154926909405.22807.13943127721450769873@ietfa.amsl.com> Date: Mon, 04 Feb 2019 00:31:34 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-18.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 08:31:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Tirumaleswar Reddy Robert Moskowitz Filename : draft-ietf-dots-requirements-18.txt Pages : 21 Date : 2019-02-04 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-18 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 4 00:43:14 2019 Return-Path: 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 2EF1D1294FA for ; Mon, 4 Feb 2019 00:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 9ZB0QlYFAeMJ for ; Mon, 4 Feb 2019 00:43:10 -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 DC0C8124BF6 for ; Mon, 4 Feb 2019 00:43:09 -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=1549269712; 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-microsoft-exchange-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=3 YoTckL/qCPrK6r87SKddt98RtgC2vjv3rb455PswV Q=; b=bxuNdpTl3/K7DB559DsZArDYz3XBrw4R311iQ55m6rlO FXQUTVEROdJ+bnCXYuosqO39/2udYhj6/wWisfifrWi9Zg/4IX IVa/Hbs+uH8CByihV1DU1aP4nQdrHZZB2LbLiHjBwZ/mdeAGrF 58xQJnfiL0JseoxjjMyLgz8y/gE= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 7d9e_3872_47a65444_8dbf_406a_86a6_39f6ba568d11; Mon, 04 Feb 2019 01:41:51 -0700 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 4 Feb 2019 01:42:21 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 4 Feb 2019 01:42:20 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 4 Feb 2019 01:42:19 -0700 Received: from NAM03-BY2-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, 4 Feb 2019 01:42:19 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2486.namprd16.prod.outlook.com (20.177.224.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.20; Mon, 4 Feb 2019 08:42:19 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1580.019; Mon, 4 Feb 2019 08:42:19 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" CC: Benjamin Kaduk , "bew@cisco.com" , "rjsparks@nostrum.com" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-18.txt Thread-Index: AQHUvGQbZ4hDVxeoJ0GYmSjmqhyLCKXPT5Zg Date: Mon, 4 Feb 2019 08:42:19 +0000 Message-ID: References: <154926909405.22807.13943127721450769873@ietfa.amsl.com> In-Reply-To: <154926909405.22807.13943127721450769873@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR16MB2486; 6:1kAVsB5bGshW+cqwG50s0aFBXzsIKw0GgWbhxeNyMeL6EuZd9SWUZ8XbYUojcWXtU1A1zdgmKs8IcIWlPBtopnpdJQA8vjuhIKPeEqWLw5ExWDVAwGtBE1YXcpy3rjNdnBZiRbnXZc5tFda4YH0vIBqPmCmPMdVNsWfRqAsReEcQxjTD9ke7k8PaxbI1fC5lD7P0L4BWLjkmpmfhIY55pLQ7WHX8JWP47D2EcBLm8tzgUgzeU8X46rmgkAeXxeuIXZ0/D7l4Zcw2UhX8sSYwxDwBKKH0sdO6cXtJ/JXcU2qgHuTxqPr59NwNJhkav0z9Ba2RAAHftGy6VyJ6Fe/5Z/HYwZJE7f5Q0U2v24mYrIKRvyOZ1L4QdQmYsxYYSjOhcFyBx7BgFnW2yID2oyufyQBVkqeRy4Cr4wLzKRAAZa2c1Wz+aBMAP+Vqh+ygkR7YEp2kWoocogwKFBaqGHfMRQ==; 5:ONFHgK+X7S7FAdv8UmAywXwZVSgkN2QMqCflLBui+ajxuUW5EJTMkt41PHvSOOYr1HviujIdjpy9gJWWstA1Hw1KZB9Ip6yaSOf6R2gOeiSVbECtf38LYAdRn/0PVJnerYgKzkTfsWCtmBaOa9tDtft3RmoMXALqvvNZ6Q6vrFMee9ha3r0CMQGIJ7DSQq8W+HGWk2TsMZPd5tx4ItohnA==; 7:TMQYpYd0pMfNcFLRHwnXWW91GyX08F2H2Z7K1Q7FUG9UgJmqm+30WSrTSRCQyywcf2gepVVGNIGpQgjIrIG7Of+GuPzdoFINdPko6lpzCxrY4aJZmQosBrrvwxgkqz1jkNvDtzuGfe91/J3AV/CzCw== x-ms-office365-filtering-correlation-id: 33e5c681-35d8-4f5d-7fcb-08d68a7cac6b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2486; x-ms-traffictypediagnostic: BYAPR16MB2486: x-microsoft-antispam-prvs: x-forefront-prvs: 0938781D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(366004)(39860400002)(376002)(13464003)(32952001)(189003)(199004)(3846002)(6116002)(54906003)(72206003)(105586002)(11346002)(5640700003)(14454004)(478600001)(9686003)(26005)(486006)(966005)(6916009)(476003)(446003)(229853002)(71190400001)(81166006)(81156014)(71200400001)(1730700003)(2906002)(7696005)(86362001)(186003)(76176011)(74316002)(8936002)(99286004)(305945005)(8676002)(7736002)(316002)(68736007)(33656002)(5024004)(256004)(80792005)(25786009)(97736004)(66066001)(2501003)(6246003)(55016002)(53936002)(102836004)(53546011)(6436002)(6306002)(6506007)(106356001)(4326008)(2351001)(66574012)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2486; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: qTQXS2XzGTSXr/jmKOLlo1b9XZhciyEVShHqhHgixlIj3Qx3s4VgB0ey3aNBlquFynMg4qWvU/mJAPNjJx4R2Bnlix3AOxi5XcT9b3uuCmFueyq45g/A7kcin23SxMQabLWBp+wmnNrS9ZVLPX/z9IAAhFhrlpqX1NumaXCkb1gEJZr+ToKDl8JXDO1zqkDGrGjij7QVnp7Yu5ySyHvSXVu23hVBPs+wxJ0DqIwi0qnl891ZCX+D/pQI0uGCgyvrE5jNfxdcTJzavRawF1X6qljaSfogFXGdfYb4beTceKDLwmQJdZG4rFk9pSI6RIBgZ9WMOT960Ghp1gNe7EH8VMtDMIC1l4D6wjAzYrWAwoJOmfjYDGlZB3Du2udI1WuxxSYJL43wtClGOVOWJwKbMiaCsEhOt7esTxjcfP5eS2g= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 33e5c681-35d8-4f5d-7fcb-08d68a7cac6b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2019 08:42:19.1376 (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: BYAPR16MB2486 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6474> : inlines <7010> : streams <1812043> : uri <2790564> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-18.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 08:43:12 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-requirements-18 a= ddresses comments from Robert (Genart review) and Brian (Secdir review). Cheers, -Tiru > -----Original Message----- > From: Dots On Behalf Of internet-drafts@ietf.org > Sent: Monday, February 4, 2019 2:02 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-requirements-18.txt >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is = safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial of Service (DDoS) Open Threa= t Signaling > Requirements > Authors : Andrew Mortensen > Tirumaleswar Reddy > Robert Moskowitz > Filename : draft-ietf-dots-requirements-18.txt > Pages : 21 > Date : 2019-02-04 >=20 > Abstract: > This document defines the requirements for the Distributed Denial of > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > coordinated response to DDoS attacks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-requirements-18 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-18 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-requirements-18 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Feb 4 11:04:09 2019 Return-Path: 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 10EA3130EE6 for ; Mon, 4 Feb 2019 11:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 J8VOW8eWfUSZ for ; Mon, 4 Feb 2019 11:04:04 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 19E6C130EEC for ; Mon, 4 Feb 2019 11:04:01 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x14J40Zs038332 for ; Mon, 4 Feb 2019 14:04:00 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x14J40Zs038332 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1549307040; bh=GktmpV3Oeco7S+1YB4KJ7qiFCs0F0Qkqa67tmtlPOvs=; h=From:To:Subject:Date:From; b=CCNvII4R7VMnK2AHu3ehlrKBodvqkVIXLA1flLRsTmwKF7Oqn+iSnCaF8+MccT/dd TVXlhIabrEV7VRy2xAhOJmUpE1OUiE3y7OaWXYEqmpsKQkZuACex6dRpThttZF+iZy STzv9F69emE79Wmu5ecy1+7+yvldc9EIyKttRxYA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x14J3roP008049 for ; Mon, 4 Feb 2019 14:03:53 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Mon, 4 Feb 2019 14:03:53 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Items from shepherd review of draft-ietf-dots-architecture Thread-Index: AdS8u2RatjXyeujWSNi2qQvwlChSXQ== Date: Mon, 4 Feb 2019 19:03:52 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857A7D95@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Items from shepherd review of draft-ietf-dots-architecture 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:04:07 -0000 Hello! I found a few issues using idnits when completing my shepherd write-up of d= raft-ietf-dots-architecture. Could these please be fixed and a -11 publish= ed. (1) No IANA Considerations section. While there is no action for IANA, the= next needs to explicitly say something to that effect. See Section2.2 of = https://www.ietf.org/id-info/checklist (2) A few of the references need to be updates. From IDnits: --[ snip ]-- =3D=3D Outdated reference: A later version (-18) exists of draft-ietf-dots-requirements-16 =3D=3D Outdated reference: A later version (-17) exists of draft-ietf-dots-use-cases-16 =3D=3D Outdated reference: draft-ietf-opsawg-nat-yang has been published = as RFC 8512 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) --[snip]-- Thanks, Roman From nobody Mon Feb 4 11:12:02 2019 Return-Path: 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 E403C130EF1 for ; Mon, 4 Feb 2019 11:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 F0HwcJbSxLJH for ; Mon, 4 Feb 2019 11:11:59 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 59359130EEF for ; Mon, 4 Feb 2019 11:11:59 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x14JBvuS000381 for ; Mon, 4 Feb 2019 14:11:57 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x14JBvuS000381 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1549307517; bh=enA4Y1PPNpAElJhT8KTAoowWRTimVTERnAwTINE/c90=; h=From:To:Subject:Date:From; b=dIpPiPTzxdhrf/IWRmzkskeiVFP5Aixevdc/2c22qxHN17WM7jrbEO68v1E3d2YGN umvwGu04K9VjU8EPWGjxN3pWf14hX3UDjZoD4NKAxoh4kvikIEy75AR7XkRl720SjY BLrFoJ3yOQ39V2TVrg6txws7728rJ+x0WTTSOlu4= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x14JBvVc041733 for ; Mon, 4 Feb 2019 14:11:57 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Mon, 4 Feb 2019 14:11:56 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: IPR Check for draft-ietf-dots-architecture Thread-Index: AdS8vVBm9+46RTmSQ/2+GkgDbrEsUw== Date: Mon, 4 Feb 2019 19:11:56 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857A7DC9@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] IPR Check for draft-ietf-dots-architecture 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:12:01 -0000 Hello! In order to help preparing the shepherd write-up for draft-ietf-dots-archit= ecture, can you please answer the following question on list: =3D=3D=3D=3D=3D (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? =3D=3D=3D=3D=3D Thanks, Roman From nobody Mon Feb 4 11:13:48 2019 Return-Path: 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 84213130EED for ; Mon, 4 Feb 2019 11:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 azmJor-4OS0o for ; Mon, 4 Feb 2019 11:13:45 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 0E36B130EE6 for ; Mon, 4 Feb 2019 11:13:44 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x14JDfhQ000549; Mon, 4 Feb 2019 14:13:41 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x14JDfhQ000549 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1549307621; bh=i3QSzkbzmBFJsirCmf2S7uKwv+u0JeVCUJKnGqShwwA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=sAFzI1fLh8XGvT4+cf4bpmwZd8NPhX/beLFHEf444bG9lz+gPIZzZraRCQr0I9crE eFevJMsh9AnSZ9RrrfeFurkt5oY5xkQsj0ZyEaOAQ7G585pL1Bw416rJ0xOceW4vym +QvPa8mZhcyVV2CxF7qYa2ystuw+2Wa4r2wJg4ko= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x14JDelI010544; Mon, 4 Feb 2019 14:13:40 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Mon, 4 Feb 2019 14:13:40 -0500 From: Roman Danyliw To: "dots@ietf.org" CC: "nteague@verisign.com" , "rgm@labs.htt-consult.com" , "stefan.fouant@copperriverit.com" Thread-Topic: Publication of draft-ietf-dots-use-cases requires IPR conformance check Thread-Index: AdRvqmd7N9ly1zhyRTeZI8TDkhu8jQ4mEeHwBR6/c4A= Date: Mon, 4 Feb 2019 19:13:39 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857A7DDF@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0184C73340@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0184C73340@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Publication of draft-ietf-dots-use-cases requires IPR conformance check 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:13:48 -0000 Hello! I'm checking in again. Thanks, Roman > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Wednesday, January 09, 2019 12:55 PM > To: dots@ietf.org > Cc: nteague@verisign.com; rgm@labs.htt-consult.com; > stefan.fouant@copperriverit.com > Subject: Re: [Dots] Publication of draft-ietf-dots-use-cases requires IPR > conformance check >=20 > Hello! >=20 > I'm inquiring again on the IPR check as document shepherd. >=20 > Nik/Bob/Stefan: Could you please reply to the IPR check thread started at= : >=20 > https://www.ietf.org/mail-archive/web/dots/current/msg02711.html >=20 > All authors: this draft is about to expire. Could it please be resubmitt= ed as - > 17 before that happens. >=20 > Thanks, > Roman >=20 > > -----Original Message----- > > From: Roman Danyliw > > Sent: Monday, October 29, 2018 1:12 PM > > To: dots@ietf.org > > Cc: 'nteague@verisign.com' ; 'rgm@labs.htt- > > consult.com' ; > > 'stefan.fouant@copperriverit.com' > > Subject: Publication of draft-ietf-dots-use-cases requires IPR > > conformance check > > > > Hello! > > > > The use case draft (draft-ietf-dots-use-cases-16) is ready for > > publication but is awaiting a shepherd write-up. As the document > > shepherd, I need help from this draft's authors to complete the write-u= p as > was noted in [1]. > > Specifically, I need to assert that that the IPR issues per BCP 78/79 > > have been filed. > > > > Daniel helpfully started a thread of public assertions on IPR from the > authors: > > ** Daniel Migault: https://www.ietf.org/mail- > > archive/web/dots/current/msg02707.html > > ** Frank Xialiang: https://www.ietf.org/mail- > > archive/web/dots/current/msg02708.html > > ** Roland Dobbins: https://www.ietf.org/mail- > > archive/web/dots/current/msg02710.html > > ** Kaname Nishizuka: https://www.ietf.org/mail- > > archive/web/dots/current/msg02711.html > > > > A response is still needed from Stefan Fouant, Nik Teague and Robert > > Moskowitz. > > > > Stefan/Nik/Bob: can you please respond to Daniel's thread on IPR. > > > > Thanks, > > Roman > > > > [1] https://www.ietf.org/mail-archive/web/dots/current/msg02715.html >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Feb 4 14:25:13 2019 Return-Path: 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 1FE6312867A for ; Mon, 4 Feb 2019 14:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.053 X-Spam-Level: X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 voaP7U4Thg0C for ; Mon, 4 Feb 2019 14:25:10 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B8C127598 for ; Mon, 4 Feb 2019 14:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2175; q=dns/txt; s=iport; t=1549319110; x=1550528710; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=WVgogOaoZEk32P6om0bYcJ3rx0s/E0yNwOP3c4bxUXc=; b=VmPQ3mj2saBkVdTKBF3euSpONMS9x/Ndzz18LiOeUWUYIZRPMoS/o0R5 t1NdhVEGaIn1rEm+oByQ5ws4HK59m5KiR92izryEcQKE5kSffb0sYFmRu v7iK/4WfpyWtxeQnJkbfNpz/K2AegkLsC40Z4agkPMEraK9CSzVGYzp/K w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAABgulhc/5RdJa0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFlAoICZ4EDJ4QDlA+BYC2JNYhrh2oNGAEKhEkCgyAiOBI?= =?us-ascii?q?BAwEBAgEBAm0cDIVLAQEBAwEBIUsbCwQBCQQGKgICJyIOBgEMBgIBAYMeAYF?= =?us-ascii?q?0DQ+NPZ16gS8fhSWEbgWMQReBQD+BOIJrgx4BAYRqglcCkHY6hWKLYAmLE4c?= =?us-ascii?q?hBhmBbIVBgxeIAIojkVyBXSGBVk0jFTuCbIsehV0hAzCOdwEB?= X-IronPort-AV: E=Sophos;i="5.56,560,1539648000"; d="scan'208,217";a="235097968" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2019 22:25:09 +0000 Received: from [10.118.10.18] (rtp-fandreas-2-881-ap.cisco.com [10.118.10.18]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTP id x14MP84N032576; Mon, 4 Feb 2019 22:25:08 GMT To: Roman Danyliw , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC01857A7DC9@marathon> From: Flemming Andreasen Message-ID: <57f63ebd-fdc9-ec79-5bf3-487a520dbf80@cisco.com> Date: Mon, 4 Feb 2019 17:25:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01857A7DC9@marathon> Content-Type: multipart/alternative; boundary="------------DFD0D1295355915908FFFC32" Content-Language: en-US X-Outbound-SMTP-Client: 10.118.10.18, rtp-fandreas-2-881-ap.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Dots] IPR Check for draft-ietf-dots-architecture 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 22:25:12 -0000 This is a multi-part message in MIME format. --------------DFD0D1295355915908FFFC32 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Confirmed on my part. Thanks -- Flemming On 2/4/19 2:11 PM, Roman Danyliw wrote: > Hello! > > In order to help preparing the shepherd write-up for draft-ietf-dots-architecture, can you please answer the following question on list: > > ===== > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why? > ===== > > Thanks, > Roman > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > . > --------------DFD0D1295355915908FFFC32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Confirmed on my part.

Thanks

-- Flemming

On 2/4/19 2:11 PM, Roman Danyliw wrote:
Hello!

In order to help preparing the shepherd write-up for draft-ietf-dots-architecture, can you please answer the following question on list:

=====
(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?
=====

Thanks,
Roman

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
.

--------------DFD0D1295355915908FFFC32-- From nobody Tue Feb 5 21:28:32 2019 Return-Path: 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 6020F12426E for ; Tue, 5 Feb 2019 21:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.843 X-Spam-Level: X-Spam-Status: No, score=-8.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 syD2Di58lKNV for ; Tue, 5 Feb 2019 21:28:26 -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 659EE126F72 for ; Tue, 5 Feb 2019 21:28:26 -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=1549430832; h=From: To: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-microsoft-exchange-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=m 16lP1Fk/tKTedALPjfgMDNDwaCoB4D+r6gB7VRxny I=; b=TSIm+qMHZOwHUjAoH7QPZT39miIc0s6HxDDAgDk3jIFE uQpCvFBuGfkL8NSt51fCjgrYLH5I/okyW+y6jmjT/UtLT4fLug fs4eeuTA4a91QXjEWwWUWBcb78SqaJ//FDZjfED5CRnWpGPZt2 kJCxjAiO9cQa3u3RJjFWnsEEfm4= 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 5285_529e_0c4778cd_f297_44a5_948c_8d21627f2a88; Tue, 05 Feb 2019 22:27:11 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Feb 2019 22:28:18 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 5 Feb 2019 22:28:19 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Feb 2019 22:28:18 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2517.namprd16.prod.outlook.com (20.177.224.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.20; Wed, 6 Feb 2019 05:28:17 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1601.016; Wed, 6 Feb 2019 05:28:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Flemming Andreasen , Roman Danyliw , "dots@ietf.org" Thread-Topic: [Dots] IPR Check for draft-ietf-dots-architecture Thread-Index: AdS8vVBm9+46RTmSQ/2+GkgDbrEsUwAGyuYAAEELYqA= Date: Wed, 6 Feb 2019 05:28:17 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01857A7DC9@marathon> <57f63ebd-fdc9-ec79-5bf3-487a520dbf80@cisco.com> In-Reply-To: <57f63ebd-fdc9-ec79-5bf3-487a520dbf80@cisco.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR16MB2517; 6:NFeES7gMhpTRPC0CtgekOeb94KOXuSbjzDNiEnjr7z8BVOKfVE09PBcWbNIn9VqfEChxta1KXlQt/sAbeQJb0u6a+/0l+KNc87NT8SdW5Jg8TdkScwnFa3a3PwyfItqj3yjIMiL87mXvtxFt0Viu4MAKLNCH1ueX3VHCn248x8gGC10rbhpBwR3aStBM+g/od5qLyVAlYLctw62r8/USdFR3GnaHVlgaaJcwDE9WXOoDpVU/dqJ9w3IaMnjSFR++mVt1l2jX/qDNHlJjBtU/kAbAm0d43hWDUUEqyUtWiFbdWc8L96v2a/JahH8u1/D0OXzVU7pR0iuEZFzxNRj2bPCmnW0rphyckwQ2RvjGhX1Mw6nllCD/eFR1euV8osdwPvy643fHTQt9E2S7I5fheVp9x3Xz9ltyzltcng+Xj2UzkRMpU56q9Qr+oF+Xg1lOjEjDJSExhSii4sCWs47rSQ==; 5:NJxE0VpTK2pIXe7fWenoSea3H3Wk+1QWdZRSFwH75zMZtB1jQdsK2sZTd5oTy91mv/5VOyCtKgY+fsMPyehGDxeWqJvWiR+Dp7dWNji1bgZwKG8zSkLUT/UpzHDNLMzqUXHWmopb8L+caE8XGVv5XXuREVoDjJha+HqMg9reBGMVwbZpvQLq7mxbLuUt2RyCRuOb8BxM+605s94WyiFGKw==; 7:SBiADe68dtjq+J3HHU+zzD4iz83SXiVa1JVnmZMIFAMLSa+bwmR72nDGK90vnZiRIBwVKNHC1tiFxQzVnaU+FqBrbLBerupcsz5gv63GgEwFNfAUOYyy99NKLhq1TZjzDKytwVj1V4ZM5mgJNotRFQ== x-ms-office365-filtering-correlation-id: 1c242fb7-f491-404f-7d0e-08d68bf3e600 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2517; x-ms-traffictypediagnostic: BYAPR16MB2517: x-microsoft-antispam-prvs: x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(396003)(366004)(346002)(32952001)(189003)(199004)(186003)(478600001)(72206003)(81166006)(476003)(11346002)(446003)(25786009)(8676002)(966005)(81156014)(14454004)(7736002)(53936002)(6246003)(26005)(102836004)(53546011)(8936002)(6506007)(80792005)(97736004)(105586002)(74316002)(106356001)(7696005)(33656002)(71200400001)(68736007)(71190400001)(86362001)(99286004)(9686003)(316002)(6436002)(5024004)(256004)(6306002)(14444005)(76176011)(606006)(229853002)(66066001)(54896002)(2501003)(3846002)(6116002)(486006)(790700001)(4744005)(236005)(110136005)(55016002)(2906002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2517; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: JXosg2jXO1pz/gvfugoKsLJOoS6r24zSfywJ4ZTlcPToOquDd18wvwNs2+qh0dgbn14h6/UnA7SDBSRuIOENWy9ubHhv+n7K43hG/o0f70yqT1jUwWH22wo+8nOA3xS2x998igcnrE+PiMRu4t9O/tvFI0n0XvOXRJa+InKFdkwMz2R2NzO5m53sAfehhWZYrDhMLxAhrWNB/PogkraC01JzIaAMsUJShXgvu70OZoDNTBOUMz4YIyuZLUHTnKndFozS7bp/6dicDeq6ILahH0ryfZC2kyXalXVPo5IdJDEW1yTezPYx5m3cl8TNvM3m9zdmhyarUkJ7F6Er7FEx5IC2/X1ovOyBKk5Vddo3/jRwsAZwNka20GCqCMH2JMoZQBOPoqvmtpcc+rcUtyBc8vsWqkV9R6tPCOYug1047fw= Content-Type: multipart/alternative; boundary="_000_BYAPR16MB2790BE091D625200F48BAC27EA6F0BYAPR16MB2790namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1c242fb7-f491-404f-7d0e-08d68bf3e600 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 05:28:17.0658 (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: BYAPR16MB2517 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6476> : inlines <7011> : streams <1812220> : uri <2791635> Archived-At: Subject: Re: [Dots] IPR Check for draft-ietf-dots-architecture 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 05:28:30 -0000 --_000_BYAPR16MB2790BE091D625200F48BAC27EA6F0BYAPR16MB2790namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBob2xkIG5vIElQUiBmb3IgdGhpcyBkcmFmdC4NCg0KDQoNCi1UaXJ1DQoNCg0KRnJvbTogRG90 cyA8ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRmxlbW1pbmcgQW5kcmVhc2Vu DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA1LCAyMDE5IDM6NTUgQU0NClRvOiBSb21hbiBEYW55 bGl3IDxyZGRAY2VydC5vcmc+OyBkb3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RvdHNdIElQ UiBDaGVjayBmb3IgZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVyZQ0KDQoNCkNBVVRJT046IEV4 dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxl c3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUu DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNvbmZpcm1lZCBvbiBteSBw YXJ0Lg0KDQpUaGFua3MNCg0KLS0gRmxlbW1pbmcNCk9uIDIvNC8xOSAyOjExIFBNLCBSb21hbiBE YW55bGl3IHdyb3RlOg0KDQpIZWxsbyENCg0KDQoNCkluIG9yZGVyIHRvIGhlbHAgcHJlcGFyaW5n IHRoZSBzaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVyZSwg Y2FuIHlvdSBwbGVhc2UgYW5zd2VyIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gb24gbGlzdDoNCg0K DQoNCj09PT09DQoNCig3KSBIYXMgZWFjaCBhdXRob3IgY29uZmlybWVkIHRoYXQgYW55IGFuZCBh bGwgYXBwcm9wcmlhdGUgSVBSIGRpc2Nsb3N1cmVzDQoNCnJlcXVpcmVkIGZvciBmdWxsIGNvbmZv cm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2ZQ0KDQph bHJlYWR5IGJlZW4gZmlsZWQuIElmIG5vdCwgZXhwbGFpbiB3aHk/DQoNCj09PT09DQoNCg0KDQpU aGFua3MsDQoNClJvbWFuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpEb3RzIG1haWxpbmcgbGlzdA0KDQpEb3RzQGlldGYub3JnPG1haWx0 bzpEb3RzQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCg0KLi4NCg0KDQoNCg== --_000_BYAPR16MB2790BE091D625200F48BAC27EA6F0BYAPR16MB2790namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNv bGFzIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBob2xkIG5vIElQUiBmb3IgdGhpcyBk cmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LVRpcnU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gRG90cyAmbHQ7ZG90cy1i b3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5GbGVtbWluZyBBbmRyZWFz ZW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgNSwgMjAxOSAzOjU1IEFNPGJy Pg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3ICZsdDtyZGRAY2VydC5vcmcmZ3Q7OyBkb3RzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRG90c10gSVBSIENoZWNrIGZvciBkcmFm dC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHBhZGRpbmc9IjAi IHN0eWxlPSJiYWNrZ3JvdW5kOiNGM0ZGMzM7Ym9yZGVyOnNvbGlkICM5QjlBODcgMS41cHQiPg0K PHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij4NCjxwPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzlCOEIzRSI+Q0FVVElPTjwvc3Bhbj48L3N0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojOUI4QjNFIj46PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4gRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBjbGljayBsaW5r cyBvciBvcGVuIGF0dGFjaG1lbnRzDQogdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBh bmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9 IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Q29uZmlybWVkIG9uIG15IHBhcnQuIDxi cj4NCjxicj4NClRoYW5rcyA8YnI+DQo8YnI+DQotLSBGbGVtbWluZyA8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzQvMTkgMjoxMSBQTSwgUm9tYW4gRGFu eWxpdyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhlbGxvITxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkluIG9yZGVyIHRv IGhlbHAgcHJlcGFyaW5nIHRoZSBzaGVwaGVyZCB3cml0ZS11cCBmb3IgZHJhZnQtaWV0Zi1kb3Rz LWFyY2hpdGVjdHVyZSwgY2FuIHlvdSBwbGVhc2UgYW5zd2VyIHRoZSBmb2xsb3dpbmcgcXVlc3Rp b24gb24gbGlzdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT49PT09PTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPig3KSBIYXMgZWFjaCBhdXRob3Ig Y29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlhdGUgSVBSIGRpc2Nsb3N1cmVzPG86 cD48L286cD48L3ByZT4NCjxwcmU+cmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0 aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OSBoYXZlPG86cD48L286cD48L3ByZT4N CjxwcmU+YWxyZWFkeSBiZWVuIGZpbGVkLiBJZiBub3QsIGV4cGxhaW4gd2h5PzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPj09PT09PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+VGhhbmtzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJvbWFuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5Eb3RzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1h aWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPi4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR16MB2790BE091D625200F48BAC27EA6F0BYAPR16MB2790namp_-- From nobody Wed Feb 6 00:42:00 2019 Return-Path: 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 BA59C12426E for ; Wed, 6 Feb 2019 00:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 c-y8fiALQoeg for ; Wed, 6 Feb 2019 00:41:56 -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 999FD128D0C for ; Wed, 6 Feb 2019 00:41:56 -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=1549442441; h=From: To: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-microsoft-exchange-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-ms-exchange-purlcount: 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=6QWXgP8ZFNpicDsNWQohPs2L9UzR0Hz0ISlKCO pZ1iw=; b=aQXbDRKMhGMOQgOMSXFd2huAjziRhpRpAkgaVaHG 596gZb4GfEV91h9IAC8g35db874Ml+CrrLcATpA9f+Z5ge6PD4 aWTzji+j3KoW6sL5Ghws9yEBiQfuRF9FvXgBSjovTIdQpJai7w IBF6Mq0QxqCNLci0eI8evzquVpGKCsU= 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 79d8_0dbc_772b3d22_9e5a_475e_bb5b_e9b7dc85fc43; Wed, 06 Feb 2019 01:40:40 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 6 Feb 2019 01:41:18 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 6 Feb 2019 01:41:18 -0700 Received: from NAM05-DM3-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; Wed, 6 Feb 2019 01:41:18 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2518.namprd16.prod.outlook.com (20.177.224.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.20; Wed, 6 Feb 2019 08:41:17 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1601.016; Wed, 6 Feb 2019 08:41:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Roman Danyliw , "dots@ietf.org" Thread-Topic: Items from shepherd review of draft-ietf-dots-architecture Thread-Index: AdS8u2RatjXyeujWSNi2qQvwlChSXQBO5xBw Date: Wed, 6 Feb 2019 08:41:16 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01857A7D95@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01857A7D95@marathon> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR16MB2518; 6:9ePEIsukNPDrAclqlvUTTuce0zizyKqxEURwI5EegIQYqq9TrY7TA+MQ/6lxQnn/iC9lZoCdtRmpQEC0Li0YJNMmHQrCPIRrio4vq7mA1ffZ8g1MbOsGNTnULywErUi7NNuV/0q+QdgsmXf3NU6PoHisUgQFXUIw5w4wD/2vFy0ljQdfEjaFKHs0EDhIaEVzGUCbMhWOzJh+pyAb6o1/hcuHdh/ZEPAU5bS9SEmhHxpHow+8BIY8DDNtnAWGdnZd3Jzpk0Way2YttyecWosfskTnC1L71dMg62uBJ8ZpHiLro3LtJsPc8Prewgdgo5hZJjyECo7kQqfgZ6TwzvlTy0a+ew+CuwLWlMKow+8DYeTHnQG+X1HM12hl+zssteANcMlXV17R0J5nEVtHh2HatDN8omu5cJu1hacrFoOGqWdz3jCVoVLbYVC832FJtPgjEiW5hF2Wm56GS48F1ga5cg==; 5:FNyYpFVrI/zqXxbSxiLTmxAAI3swCzDCHJbG4zX9mhMA0AecLqxIZaKI0h6vqvds4dmxj+3R4d0dy4rveyR5TfLuGxP6tMDkWIv6quvnRtSpmvq6ia3B/SLbal0Nkgtj446jtBcq+P7pG2esx5m79ukOXfdLABH1QpagjGuURugCEB4p1+6mm9UmRfQJXaFLOXfaAsnR2JVVRk8KY3IYaw==; 7:o9eZRxFuNx9otoCpQW0P1J2W3aB7pU5tgCAMefnZHnDcnWUTXxqXtpVCiafJKlnXrbxfgvp03AnYw90MsWlv+QKuGC+DzOHzB7vWf8KNZPpCfaB7JsFAIJfM6WGg3ugXcfj7kuzMjVipS2KcRtCWXQ== x-ms-office365-filtering-correlation-id: abbbf9a7-6d15-4d37-e2bc-08d68c0edc5a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2518; x-ms-traffictypediagnostic: BYAPR16MB2518: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(136003)(366004)(13464003)(32952001)(199004)(189003)(71200400001)(25786009)(305945005)(71190400001)(7736002)(316002)(99286004)(6306002)(55016002)(2906002)(229853002)(486006)(81166006)(8936002)(186003)(966005)(9686003)(2501003)(6436002)(478600001)(106356001)(110136005)(105586002)(81156014)(72206003)(7696005)(76176011)(53546011)(8676002)(6506007)(11346002)(74316002)(26005)(256004)(3846002)(6116002)(476003)(53936002)(102836004)(86362001)(80792005)(97736004)(66066001)(33656002)(14454004)(6246003)(446003)(68736007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2518; H:BYAPR16MB2790.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: vZ9oPuij3keTkepCOYDQpoNsrDXyorYLqLOGFQZFIhkRcQpd2ab56iyvWrrDfytrRHohxyYSgi8250skWPP4bWIHNd86gw70xAR8EONgSaCRENtWCnzBDiF+CUkNWGNZLgZdAT1zUvjEzQg7V/jOqzaTulfESZPHKb6fztIQFh+aRgkBysLowrhaAqOLSFJ0eil4X4utnSprWNjC8QfXZRj50eVfpol2F+n2qz+ycnt5H0HgZD8iMFJWFVJieuaqsqcXDXo7QiKGtp+yFMS6UGN5nE9QQhRPWKZ5KPww6e7qXYIggb7vocGD0lQ1VBqrnaUURW64EjHP+rXwOx6O09indcOvrc/PEIO7liDI2nB5XL7xTs56oFHs9gNdt4gTyyUqUbtGWMlbueqhHScjrUma32oy6x/LWpDJINjIH5Q= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: abbbf9a7-6d15-4d37-e2bc-08d68c0edc5a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 08:41:17.1406 (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: BYAPR16MB2518 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 <6476> : inlines <7011> : streams <1812233> : uri <2791713> Archived-At: Subject: Re: [Dots] Items from shepherd review of draft-ietf-dots-architecture 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 08:41:59 -0000 Hi Roman, Please see inline > -----Original Message----- > From: Dots On Behalf Of Roman Danyliw > Sent: Tuesday, February 5, 2019 12:34 AM > To: dots@ietf.org > Subject: [Dots] Items from shepherd review of draft-ietf-dots-architectur= e >=20 >=20 >=20 > Hello! >=20 > I found a few issues using idnits when completing my shepherd write-up of > draft-ietf-dots-architecture. Could these please be fixed and a -11 publ= ished. >=20 > (1) No IANA Considerations section. While there is no action for IANA, t= he next > needs to explicitly say something to that effect. See Section2.2 of > https://www.ietf.org/id-info/checklist Fixed. >=20 > (2) A few of the references need to be updates. From IDnits: >=20 > --[ snip ]-- > =3D=3D Outdated reference: A later version (-18) exists of > draft-ietf-dots-requirements-16 >=20 > =3D=3D Outdated reference: A later version (-17) exists of > draft-ietf-dots-use-cases-16 >=20 > =3D=3D Outdated reference: draft-ietf-opsawg-nat-yang has been publishe= d as RFC > 8512 Updated >=20 > -- Obsolete informational reference (is this intentional?): RFC 5246 > (Obsoleted by RFC 8446) We discussed reference to RFC5246 in DOTS signal channel draft with Benjami= n, see https://mailarchive.ietf.org/arch/msg/dots/n6UQxjvffL4i7hxk0o6D3eRjV= 20 I have updated the text as follows: This challenge might in part be mitigated by use of resumption via a PSK in TLS 1.3 [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]) Cheers, -Tiru > --[snip]-- >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 7 01:31:44 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE30512F19D; Thu, 7 Feb 2019 01:31:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <154953190290.23535.14800762266297691276@ietfa.amsl.com> Date: Thu, 07 Feb 2019 01:31:42 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 09:31:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Authors : Andrew Mortensen Flemming Andreasen Tirumaleswar Reddy Nik Teague Rich Compton Christopher Gray Filename : draft-ietf-dots-architecture-11.txt Pages : 34 Date : 2019-02-07 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-11 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 7 01:34:53 2019 Return-Path: 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 D69D5131132 for ; Thu, 7 Feb 2019 01:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 VMua597t4Kr0 for ; Thu, 7 Feb 2019 01:34: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 15E5D13113D for ; Thu, 7 Feb 2019 01:34:47 -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=1549532014; h=From: To: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-microsoft-exchange-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=5 R3Mlj7CxLVCuXz0Qp+r2RKsM2mBvD/xMEC9pWrate Y=; b=fZx08dYIm4T7KcZcOgJ2yd2jn+7FsusVx+VdCEqSeDO1 McOnMVx20cQ3PmQM3alNnN+wSASQISOIduwfB558lF5PQig6MW 36wJYK+enrOEX4yHuy0tt7A7TAqVmgMFgzdjyp1xbWwB5HIzvG 4UTdznxyqOn/WSN/LUNgiFu7GHA= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3deb_5323_e212ed15_38f6_476f_b755_5429ab867321; Thu, 07 Feb 2019 02:33:34 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 7 Feb 2019 02:34:37 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 7 Feb 2019 02:34:37 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 7 Feb 2019 02:34:36 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2664.namprd16.prod.outlook.com (20.177.224.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Thu, 7 Feb 2019 09:34:35 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1601.016; Thu, 7 Feb 2019 09:34:35 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-architecture-11.txt Thread-Index: AQHUvsgRFdr23PokBUqND9F5EcyNYaXUEwwQ Date: Thu, 7 Feb 2019 09:34:35 +0000 Message-ID: References: <154953190290.23535.14800762266297691276@ietfa.amsl.com> In-Reply-To: <154953190290.23535.14800762266297691276@ietfa.amsl.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR16MB2664; 6:tcYN8/cY8Zu73HoaydfOYahKpY3WCVn0f4eiAWue4iGMYTDYnWMRPj/Cu9hSaKYtNA9qbisu8WvB6bgdLk9JBIaQsocF/pwsoTogBlRoodqeOIuX9d88V1MWYbgWe0chnJs6qgVu+PDi6Ry+oOEqg9MLfqqUmCw5ho8WEQ3iPp4NFdbDPhwJJB1REDNpsFaOeiFc9nOR79SxozWl4XbftE5qtqdtiIa1qXIMCHImyD0gn2qXhG2fZzoaHHRYx5fWY1UV7uj1RrYA8zcoe+6k+rnCSJjdMiPLSj+ntu7ZsyMQeVajLVNQDVv9Bc0xvh4dgaSJVR5x6UnfQ2FrrGWkhQkY+ObAUOLA+x5il3kGHnFDJqJVktOHtkYIqgyvIElOWlMFS07M1Fl3r2AzKW3fCgrdAEpFo1DC7v689fP48n4w8THvqDHaXv000YdlvNlzabYOKCb57FxWxEK0T65Veg==; 5:AZVK/++/pVZ0LI19vrHjZbdPRlo11oCqDM62mbx03n2+B9zQdHzHaZZvcdgNUixlch3QQrykRIXIYMro3ofhgGUiOsOFzA/vORpX/zkEgCFb6QgpvbHZndr3ADfU3Po0MUUaA3jRcsVj7bXNCv35dR9nhMKdhvNNVD6M4Vjd3wVP+0tmPeYwiVm2mvOLkMspsREvCZT7vzH1eojD3hWSJg==; 7:jzLk2rLN5df5OM/r6im9jJ4BfDoi84ZYQRFZTtd1Yd8SROAgYVrZZ6gyxm1p47muQaENKpLdnSd5OVDDVgJFK90mlC3wM1kt+AR1p6BTTRfQIv73GkzzoA1N7FDLVj6y+fiXsfpPnJzLYX0bsKck4g== x-ms-office365-filtering-correlation-id: 13c18601-61b5-4952-07ec-08d68cdf7926 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2664; x-ms-traffictypediagnostic: BYAPR16MB2664: x-microsoft-antispam-prvs: x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(396003)(346002)(376002)(189003)(32952001)(199004)(13464003)(9686003)(5640700003)(316002)(6116002)(6436002)(3846002)(106356001)(80792005)(68736007)(97736004)(2351001)(86362001)(305945005)(55016002)(2906002)(99286004)(6246003)(6916009)(256004)(105586002)(8676002)(229853002)(6306002)(74316002)(81166006)(1730700003)(2501003)(81156014)(476003)(14454004)(966005)(7696005)(66574012)(26005)(76176011)(6506007)(486006)(186003)(8936002)(53546011)(478600001)(72206003)(53936002)(7736002)(11346002)(66066001)(33656002)(25786009)(71200400001)(71190400001)(102836004)(446003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2664; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: XpZEBVSEYl0qZ6OF0esfYqP5bRoyyk/UcX4rSseGqB9lPGJSepT1yRPP68LEHgnYPaPiOUr1lZtq37ivXywNhMRV4VBgtQBcN1aB24c9XaOGra7340dtiuICZ0uyllhfBrvX74+uPdGwA1MT9NUPW0jmPhKTczGXjxEf+tcw2Xv90iTfY3UNrANSUgpnqEHZgCwsPTRSWjMKd1AD6ONsljI/g5nalKErDn8gvftR8zMNRLfxu80W3hXX7jbD+O4oi2pcOqOKFoPm7rt8HrA4Xa5JG2lWzIDWbcsskQs38tac2octDOH+gxDRC87nS8NvK7BBtkFSj0JqO+ZYL0dP9b3muHRn8tq9/3P//tMICwQG6udPx/SwS5rFt1DejZYwWA0z2M7+FwYH5x4O0rELWR9B8Fh2u504P7d3yuE0U6U= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 13c18601-61b5-4952-07ec-08d68cdf7926 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 09:34:35.6734 (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: BYAPR16MB2664 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6477> : inlines <7011> : streams <1812332> : uri <2792293> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-architecture-11.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 09:34:51 -0000 This revision addresses comments from Roman (Shepherd review). -Tiru > -----Original Message----- > From: Dots On Behalf Of internet-drafts@ietf.org > Sent: Thursday, February 7, 2019 3:02 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-architecture-11.txt >=20 >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed-Denial-of-Service Open Threat Signa= ling (DOTS) > Architecture > Authors : Andrew Mortensen > Flemming Andreasen > Tirumaleswar Reddy > Nik Teague > Rich Compton > Christopher Gray > Filename : draft-ietf-dots-architecture-11.txt > Pages : 34 > Date : 2019-02-07 >=20 > Abstract: > This document describes an architecture for establishing and > maintaining Distributed Denial of Service (DDoS) Open Threat > Signaling (DOTS) within and between domains. The document does not > specify protocols or protocol extensions, instead focusing on > defining architectural relationships, components and concepts used in > a DOTS deployment. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-architecture-11 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 7 07:17:57 2019 Return-Path: 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 77A6F124C04 for ; Thu, 7 Feb 2019 07:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cert.org 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 IOXT5XlUzINw for ; Thu, 7 Feb 2019 07:17:53 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 B8D8E1228B7 for ; Thu, 7 Feb 2019 07:17:53 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x17FHqBr016801; Thu, 7 Feb 2019 10:17:52 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x17FHqBr016801 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1549552672; bh=UYJb8StnY6H2wLFnmajpLhygpMWavhy3sf5IJh6mSFM=; h=From:To:Subject:Date:References:In-Reply-To:From; b=DaHogsETsVMiNPwxh0P8WmDOxonzd6nBFeeP86MUW9q1uWeOtWii0BJ8FMt8HTx+V h6thXePnBZJVd+dXS8eqptCWKQCGgPyp40lQKtKpv+YIjhMXwQLeFIl/0uyv29kiBH NX6Rwzad1Lvs2xV71rsuTvw572Esvbr6d4vV0cBE= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x17FHqL6026523; Thu, 7 Feb 2019 10:17:52 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Thu, 7 Feb 2019 10:17:52 -0500 From: Roman Danyliw To: "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: Items from shepherd review of draft-ietf-dots-architecture Thread-Index: AdS8u2RatjXyeujWSNi2qQvwlChSXQBO5xBwAEBIdYA= Date: Thu, 7 Feb 2019 15:17:51 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857B7C62@marathon> References: <359EC4B99E040048A7131E0F4E113AFC01857A7D95@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Items from shepherd review of draft-ietf-dots-architecture 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:17:55 -0000 Hi Tiru! Thanks for these changes. I'm now just waiting on the IPR statements to pr= ogress the document. Roman > -----Original Message----- > From: Konda, Tirumaleswar Reddy > [mailto:TirumaleswarReddy_Konda@mcafee.com] > Sent: Wednesday, February 06, 2019 3:41 AM > To: Roman Danyliw ; dots@ietf.org > Subject: RE: Items from shepherd review of draft-ietf-dots-architecture >=20 > Hi Roman, >=20 > Please see inline >=20 > > -----Original Message----- > > From: Dots On Behalf Of Roman Danyliw > > Sent: Tuesday, February 5, 2019 12:34 AM > > To: dots@ietf.org > > Subject: [Dots] Items from shepherd review of > > draft-ietf-dots-architecture > > > > > > > > Hello! > > > > I found a few issues using idnits when completing my shepherd write-up > > of draft-ietf-dots-architecture. Could these please be fixed and a -11 > published. > > > > (1) No IANA Considerations section. While there is no action for > > IANA, the next needs to explicitly say something to that effect. See > > Section2.2 of https://www.ietf.org/id-info/checklist >=20 > Fixed. >=20 > > > > (2) A few of the references need to be updates. From IDnits: > > > > --[ snip ]-- > > =3D=3D Outdated reference: A later version (-18) exists of > > draft-ietf-dots-requirements-16 > > > > =3D=3D Outdated reference: A later version (-17) exists of > > draft-ietf-dots-use-cases-16 > > > > =3D=3D Outdated reference: draft-ietf-opsawg-nat-yang has been publis= hed > as RFC > > 8512 >=20 > Updated >=20 > > > > -- Obsolete informational reference (is this intentional?): RFC 5246 > > (Obsoleted by RFC 8446) >=20 > We discussed reference to RFC5246 in DOTS signal channel draft with > Benjamin, see > https://mailarchive.ietf.org/arch/msg/dots/n6UQxjvffL4i7hxk0o6D3eRjV20 > I have updated the text as follows: >=20 > This challenge might > in part be mitigated by use of resumption via a PSK in TLS 1.3 [RFC8446] = and > DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in TLS 1.2 [RFC5246] a= nd > DTLS 1.2 [RFC6347]) >=20 > Cheers, > -Tiru >=20 > > --[snip]-- > > > > Thanks, > > Roman > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 7 14:03:16 2019 Return-Path: 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 2725612D4E8 for ; Thu, 7 Feb 2019 14:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 12d0RqMyqzNy for ; Thu, 7 Feb 2019 14:03:12 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A719127AC2 for ; Thu, 7 Feb 2019 14:03:12 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id d11so3957654itf.2 for ; Thu, 07 Feb 2019 14:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ipy05NWo53ZeKyRl8EfmUB1uTZkpVj1NN6aHKPjZc8=; b=e55yq7SkY4u8F+pDugJBWa31V+MuBLvICmLAR5C0cfkONUGH90cUp1guLNTdOGZoCm X106RtcCEEPlJ7TOc6gbAUwOAoc4NoR7H8JQt+zmdRhO2CmoKCKmDvXRDej4/yDhocNt 7MxCutSoBjYWzCVsBOLdNMpZ8VQyiDnB6iREBXTY8XWG3QEKI6FriWBwBcqumoq9vFV7 dKRn2swHpUqErH8zdf5H0F+IUQ83e2FReBpUsvQIIUuywsoxghIZ+kuyo98m5fyuFdNI DL3fCORgxMwOXNMkNzU/eM02lyF4iB90rxuyZwDPv4TEe7fI7DOpoifzg+f1T7VvMXsy WHqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ipy05NWo53ZeKyRl8EfmUB1uTZkpVj1NN6aHKPjZc8=; b=Ku74uo9mZU52ORfIPaWb5uDqvAhv5FRR5qr/GPMNkaEt5GvPSQUnzB1UDOHA/QvKIy /iMeLUeqGf1+yf6P5YuSlO5bti87bDCZkB5J0pzUbXamalwj8A/8jdBFpUN6UN6Cq0nx Wvf/Jg1ysCOXyrZiE/6zfgSEwUvigoxBp4/jpwkyKzZ34yiE9jJZeUnIvYkkh8NKIMiz g4jMkrteZCPLQiTKRsrrs9LOSS/cWc5gXTFaLtupmO2bLUtIHpviDi8/Accn0tmLPgnV T4IlZ696/R1BaBAM5jGeUiLOEbtE0aFKZ10nRYZE7CBo7ff01YVvFoSzvx2XV76zvnXo /NsA== X-Gm-Message-State: AHQUAuYJPAM66wVu7TgdbR4WYIfhYfZ9FQOZPfq3bApA2aOeNM5MirzZ F1tR+zzMvG4FHnlu90/fsyU= X-Google-Smtp-Source: AHgI3Iba4/ADTe6CIvn4uhXkm++NM17PYW3oE2aHP0IYL2//AYiyqEnZD/VQAuhxDQuSqFWul9BUNw== X-Received: by 2002:a24:604:: with SMTP id 4mr5693400itv.129.1549576991089; Thu, 07 Feb 2019 14:03:11 -0800 (PST) Received: from exitmusic.hsd1.mi.comcast.net (c-73-145-178-129.hsd1.mi.comcast.net. [73.145.178.129]) by smtp.gmail.com with ESMTPSA id m37sm290897iti.6.2019.02.07.14.03.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 14:03:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Andrew Mortensen In-Reply-To: Date: Thu, 7 Feb 2019 17:03:08 -0500 Cc: Flemming Andreasen , Roman Danyliw , "dots@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC01857A7DC9@marathon> <57f63ebd-fdc9-ec79-5bf3-487a520dbf80@cisco.com> To: "Konda, Tirumaleswar Reddy" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Dots] IPR Check for draft-ietf-dots-architecture 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 22:03:14 -0000 I hold no IPR for this draft. andrew > On Feb 6, 2019, at 12:28 AM, Konda, Tirumaleswar Reddy = wrote: >=20 > I hold no IPR for this draft. > =20 > -Tiru > =20 > =20 > From: Dots On Behalf Of Flemming Andreasen > Sent: Tuesday, February 5, 2019 3:55 AM > To: Roman Danyliw ; dots@ietf.org > Subject: Re: [Dots] IPR Check for draft-ietf-dots-architecture > =20 > CAUTION: External email. Do not click links or open attachments unless = you recognize the sender and know the content is safe. >=20 > Confirmed on my part.=20 >=20 > Thanks=20 >=20 > -- Flemming=20 >=20 > On 2/4/19 2:11 PM, Roman Danyliw wrote: > Hello! > =20 > In order to help preparing the shepherd write-up for = draft-ietf-dots-architecture, can you please answer the following = question on list: > =20 > =3D=3D=3D=3D=3D > (7) Has each author confirmed that any and all appropriate IPR = disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 = have > already been filed. If not, explain why? > =3D=3D=3D=3D=3D > =20 > Thanks, > Roman > =20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > .. > =20 > =20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Feb 9 23:30:47 2019 Return-Path: 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 F1B4A128AFB for ; Sat, 9 Feb 2019 23:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.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 u8fjF2IEadJk for ; Sat, 9 Feb 2019 23:30:42 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AE5130E11 for ; Sat, 9 Feb 2019 23:30:42 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id h1so921018pfo.7 for ; Sat, 09 Feb 2019 23:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=rhwabr8/Feb11Fqrj4uezpd7GQH7jQMwHbM7Qh9GF3A=; b=1LAkHRdg//+meBX0JNjmT2w+nJ0YYfuHh1QomZ0pd49VzJN4qN9mapL8kew7O7Ph/C IERPxiYm2K54ril8t11AiuKx6jT07sRSlMPb+B4dX0FIr4mzQ/nB382HRR5iwpdXimMO p+iPCI4cl/h/mtCohXHf71ztQflWH1fwwvoomvLZubI51lv4ZAiOQv3BFGkPwWeYXhEx mKoKu6DlgZfMMRRLJ8eDlOOmTOrIRCsJJbYcoItga10rDslCUuBQEMb+XYmeLTbPF72X o/Z0TkyZh/VOir0ph1abPPh3z7HHAZfU5DE2U03sZpZ+6H+8iL+2UvOcMPHS/iCcrzUs 2caA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=rhwabr8/Feb11Fqrj4uezpd7GQH7jQMwHbM7Qh9GF3A=; b=uckc3qmhgQ3AQCWtt1zv7CzJChl0aIdasK1hEpwwmBw4XfqmF0ZnFPWt26WlNnDHFr CvH+KYhnkG9oPq7ILvMTafHpxH9parUsqzHX4mZ9byWb0HWQ2eamR2cuuQwHXOoqv0d3 sooFeZOFhlNZdGw5hirRxZ30hV/ZMejfwDPKavGieV6myvHFuwPyP/fwRd3NXksGZbDh LWOKbVmK/Qf7wJ7lPC1nGzi+OsZ0ycqtmSzpqQln/AinZDknndlwf9FajtsO2V9X+fgI BuKJt6uA1ce4s52rHkxX14m7bXOU7klDXAaCj19kSY7QMnaPBfnWK+SY0H1mRwSSQflJ VSKw== X-Gm-Message-State: AHQUAuaJw/mUDNgKBmjLiiWio1wc7ABtpk7ZBfRoVih2/TLQjG/q7BsD hCbiMBHQM7N4cbVwEVV02y/mox85xBE= X-Google-Smtp-Source: AHgI3IY3HlwNjpOsSTtMDvNhsrsSliQXJYgXKVhdACuexu0ueI7jbJf1ocz5AB7/nsuGH4yod0Zuyg== X-Received: by 2002:a63:f91c:: with SMTP id h28mr4047978pgi.14.1549783841286; Sat, 09 Feb 2019 23:30:41 -0800 (PST) Received: from [192.168.10.106] (softbank126225096048.bbtec.net. [126.225.96.48]) by smtp.gmail.com with ESMTPSA id f8sm8245496pga.24.2019.02.09.23.30.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 23:30:40 -0800 (PST) To: dots@ietf.org From: Takahiko Nagata Message-ID: <1842c1bf-96b2-8757-f8b1-8a8efd84a491@lepidum.co.jp> Date: Sun, 10 Feb 2019 16:30:36 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dots] Question: SignalChannel Mitigation using Mitigator with asynchronous 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 07:30:46 -0000 Hi all, I confirmed latest(-28 version) SignalChannel and I have questions. I would like to use Mitigator with asynchronous request/response. In success case is OK: 1. DOTS Server recieve Mitigation request. 2. DOTS Server response with status=1 (Attack mitigation setup is in progress) 3. Call Mitigator with asynchronous 4. If success mitigation, DOTS Server response(via observe) with status=2 (2: Attack is being successfully mitigated) But in failure case: 1. DOTS Server recieve Mitigation request. 2. DOTS Server response with status=1 (Attack mitigation setup is in progress) 3. Call Mitigator with asynchronous 4. If failure mitigation, DOTS Server response(via observe) with status=7? (7: Attack mitigation is withdrawn (by the DOTS server)) (Question1) status=7(withdrawn) is correct in this case? (Question2) How to notify reason of withdrawn to DOTS client? Best Regards, Takahiko Nagata From nobody Sat Feb 9 23:52:23 2019 Return-Path: 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 16960130E7D for ; Sat, 9 Feb 2019 23:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.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 MPjSJU_wyUxt for ; Sat, 9 Feb 2019 23:52:19 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EF8130E6F for ; Sat, 9 Feb 2019 23:52:19 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id p4so3765448plq.11 for ; Sat, 09 Feb 2019 23:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ogPcLR/eQGOtejsDUP7KJKRdtB+rtXfW0NuB/UlMJCw=; b=o0D/EDAdUys44WH/HroqhQnNC+eB5E66PKLyQUQJSe5USF5ai7Q11k3UTwMn44xT2e zcTgI1741QQJGf77t/aqUB4sEU+deyMPqt9mzjH6fO+OWKRTju7s+0WMrgVTbJqexBLa BwpupyU2ER1OvkW1V6AYjAxrdwWmtpb1i1rP/fKyEKBYu5+Dsl8Fh0eLJG5I5Ad4R2OQ pbMvj4P0rIkyPczSYY4K1mFYT6nak2jESm2VIGo7C7e8UvRl0Izq0pTc8yQ8xOP8ODM1 CSsQbxSCwUutXey27kwsoII3pVbB13Lemkr5PLsTdnM+HLQg6gG7fLxRD2RxllhJ/vGo pdIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ogPcLR/eQGOtejsDUP7KJKRdtB+rtXfW0NuB/UlMJCw=; b=SIdLY0G26U3xY61hS2Bmuj+6O6cfIpmz5jBAQ4EAYgO2q4loFy7/W2gqsE3m5PezdO QmS6D/BaAZoJt0Audybv5ljZKQTajd9nrP9bqjQmq7uQMCA365j5jVIWo/uViPEEbZKP sDJkbjkEga4PW+Kzniy+YMtyQ3S8Zz2rNeEm6K82zxul7xNKyCLqcK0e4eXWHTHWC8e4 Pi6Stcu+cG/YUyWjX0bQ2bVZzluEGPrEl1o4YSFxG16Bk2SJipE82prBCr5moxkR4c8N YEBs3fIKw2Pfvh8ZgYqyMT9O2l3b5RXaZLEyaLjVuoXvG2x94Q7tHBsXGltfxA+JLZcF eosA== X-Gm-Message-State: AHQUAuZWrhjygvj3jFXPyITEx2xtzsgfS4kkq1rGEQ5jdWOkjpvlEe8T +9mMmWMvPQGDsZwGI1RPyl5Q4kjv3Ss= X-Google-Smtp-Source: AHgI3IatoAJHwEzH+Cad1THICQm+kc+Tec1Rsn7XBgkCKcYN+andOkDn3+lbZUdrzMWLY+T9W90LvA== X-Received: by 2002:a17:902:2c83:: with SMTP id n3mr32079567plb.104.1549785138429; Sat, 09 Feb 2019 23:52:18 -0800 (PST) Received: from [192.168.10.106] (softbank126225096048.bbtec.net. [126.225.96.48]) by smtp.gmail.com with ESMTPSA id 15sm10604282pfs.113.2019.02.09.23.52.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 23:52:17 -0800 (PST) To: "dots@ietf.org" References: <154808047532.8261.13887766521569519982.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA0AFE4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Takahiko Nagata Message-ID: <9a6d0548-1b2d-3837-a5d4-12490aa46e99@lepidum.co.jp> Date: Sun, 10 Feb 2019 16:52:14 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0AFE4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-control-filtering-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 07:52:22 -0000 Hi Med, all, Thank you for updated draft. I have a question for usecase of this draft -03 specification. (Question) Would we allow using Mitigation request with only control-filtering attributes? This mean, PUT SignalChannel Mitigation request with only acl-list (without any target-xxx). Usecase: Only update status of DataChannel ACL during a DDoS attack. (If DataChannel ACL is enough for protection. ) Best Regards, Takahiko Nagata On 2019/01/21 23:25, mohamed.boucadair@orange.com wrote: > Hi Takahiko, > > I updated the draft to take into account your comments: > > * Make sure that by default, the data channel is used for ACL-related operations. > * No update is required to efficacy update, get, and delete. > > Please let us know if the changes addresses your comments. > > Don't hesitate to share any further comment you may have. Thanks. > > Cheers, > Med > >> -----Message d'origine----- >> De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Envoyé : lundi 21 janvier 2019 15:21 >> À : Takahiko Nagata; Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN; Reddy K; >> Kaname Nishizuka >> Objet : New Version Notification for draft-nishizuka-dots-signal-control- >> filtering-02.txt >> >> >> A new version of I-D, draft-nishizuka-dots-signal-control-filtering-02.txt >> has been successfully submitted by Mohamed Boucadair and posted to the >> IETF repository. >> >> Name: draft-nishizuka-dots-signal-control-filtering >> Revision: 02 >> Title: Controlling Filtering Rules Using DOTS Signal Channel >> Document date: 2019-01-21 >> Group: Individual Submission >> Pages: 15 >> URL: https://www.ietf.org/internet-drafts/draft-nishizuka-dots- >> signal-control-filtering-02.txt >> Status: https://datatracker.ietf.org/doc/draft-nishizuka-dots-signal- >> control-filtering/ >> Htmlized: https://tools.ietf.org/html/draft-nishizuka-dots-signal- >> control-filtering-02 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-nishizuka-dots- >> signal-control-filtering >> Diff: https://www.ietf.org/rfcdiff?url2=draft-nishizuka-dots- >> signal-control-filtering-02 >> >> Abstract: >> This document specifies an extension to the DOTS signal channel to >> control the filtering rules when an attack mitigation is active. >> >> Particularly, this extension allows a DOTS client to activate or de- >> activate filtering rules during a DDoS attack. The characterization >> of these filtering rules is supposed to be conveyed by a DOTS client >> during peace time by means of DOTS data channel. >> >> Editorial Note (To be removed by RFC Editor) >> >> Please update these statements within the document with the RFC >> number to be assigned to this document: >> >> o "This version of this YANG module is part of RFC XXXX;" >> >> o "RFC XXXX: Controlling Filtering Rules Using DOTS Signal Channel"; >> >> o reference: RFC XXXX >> >> o [RFCXXXX] >> >> Please update these statements with the RFC number to be assigned to >> the following documents: >> >> o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Signal Channel Specification" (used to be >> [I-D.ietf-dots-signal-channel]) >> >> o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Data Channel Specification" (used to be >> [I-D.ietf-dots-data-channel]) >> >> Please update the "revision" date of the YANG module. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > -- ============================= æ ªå¼ä¼šç¤¾ãƒ¬ãƒ”ダム 永田　貴彦 Mail: nagata@lepidum.co.jp Tel: 03-6276-5103 〒151-0071 æ±äº¬éƒ½æ¸‹è°·åŒºæœ¬ç”º3-12-1　ä½å‹ä¸å‹•ç”£è¥¿æ–°å®¿ãƒ“ル6å·é¤¨ ============================= From nobody Sun Feb 10 23:39:58 2019 Return-Path: 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 1DA88130EA3 for ; Sun, 10 Feb 2019 23:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 OFIM3njZJnsF for ; Sun, 10 Feb 2019 23:39:53 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E669130E63 for ; Sun, 10 Feb 2019 23:39:53 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 43yd3W2pZGz5w6L; Mon, 11 Feb 2019 08:39:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 43yd3W24ySz1xpT; Mon, 11 Feb 2019 08:39:51 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup (10.114.13.29) by OPEXCLILM7E.corporate.adroot.infra.ftgroup (10.114.31.61) with Microsoft SMTP Server (TLS) id 14.3.435.0; Mon, 11 Feb 2019 08:39:51 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905%18]) with mapi id 14.03.0435.000; Mon, 11 Feb 2019 08:39:50 +0100 From: To: Takahiko Nagata , "dots@ietf.org" Thread-Topic: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-control-filtering-02.txt Thread-Index: AQHUsZSTGMTSbdBqkk2xGa77+OXjFKW5xiYAgB7w/wCAAZ29EA== Date: Mon, 11 Feb 2019 07:39:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1D1CA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154808047532.8261.13887766521569519982.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA0AFE4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9a6d0548-1b2d-3837-a5d4-12490aa46e99@lepidum.co.jp> In-Reply-To: <9a6d0548-1b2d-3837-a5d4-12490aa46e99@lepidum.co.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-control-filtering-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 07:39:56 -0000 SGkgVGFrYWhpa28sIA0KDQpUaGUgcGFyYW1ldGVycyB1c2VkIGluIHRoZSBpbml0aWFsIHJlcXVl c3QgbXVzdCBiZSByZXBlYXRlZCBpbiB0aGUgcmVmcmVzaCByZXF1ZXN0IHRvIG1vZGlmeSB0aGUg Y29udHJvbCBmaWx0ZXJpbmcuDQoNClBsZWFzZSBub3RlIHRoYXQgc2VuZGluZyBvbmx5IGFjbC1s aXN0IGF0dHJpYnV0ZXMgaW4gYSBQVVQgd2lsbCBmYWlsIGJlY2F1c2Ugb2YgdGhlIGNoZWNrcyBh Z2FpbnN0IG1hbmRhdG9yeSBhdHRyaWJ1dGVzOg0KDQogICBJbiB0aGUgUFVUIHJlcXVlc3QgYXQg bGVhc3Qgb25lIG9mIHRoZSBhdHRyaWJ1dGVzICd0YXJnZXQtcHJlZml4JywNCiAgICd0YXJnZXQt ZnFkbicsJ3RhcmdldC11cmknLCBvciAnYWxpYXMtbmFtZScgTVVTVCBiZSBwcmVzZW50Lg0KDQog ICAuLi4NCg0KICAgSWYgdGhlIHJlcXVlc3QgaXMgbWlzc2luZyBhIG1hbmRhdG9yeSBhdHRyaWJ1 dGUsIGRvZXMgbm90IGluY2x1ZGUNCiAgICdjdWlkJyBvciAnbWlkJyBVcmktUGF0aCBvcHRpb25z LCBpbmNsdWRlcyBtdWx0aXBsZSAnc2NvcGUnDQogICBwYXJhbWV0ZXJzLCBvciBjb250YWlucyBp bnZhbGlkIG9yIHVua25vd24gcGFyYW1ldGVycywgdGhlIERPVFMNCiAgIHNlcnZlciBNVVNUIHJl cGx5IHdpdGggNC4wMCAoQmFkIFJlcXVlc3QpLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0Bp ZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBUYWthaGlrbyBOYWdhdGENCj4gRW52b3nDqcKgOiBkaW1h bmNoZSAxMCBmw6l2cmllciAyMDE5IDA4OjUyDQo+IMOAwqA6IGRvdHNAaWV0Zi5vcmcNCj4gT2Jq ZXTCoDogUmU6IFtEb3RzXSBUUjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1u aXNoaXp1a2EtZG90cy0NCj4gc2lnbmFsLWNvbnRyb2wtZmlsdGVyaW5nLTAyLnR4dA0KPiANCj4g SGkgTWVkLCBhbGwsDQo+IA0KPiBUaGFuayB5b3UgZm9yIHVwZGF0ZWQgZHJhZnQuDQo+IA0KPiBJ IGhhdmUgYSBxdWVzdGlvbiBmb3IgdXNlY2FzZSBvZiB0aGlzIGRyYWZ0IC0wMyBzcGVjaWZpY2F0 aW9uLg0KPiANCj4gKFF1ZXN0aW9uKSBXb3VsZCB3ZSBhbGxvdyB1c2luZyBNaXRpZ2F0aW9uIHJl cXVlc3Qgd2l0aA0KPiAgICBvbmx5IGNvbnRyb2wtZmlsdGVyaW5nIGF0dHJpYnV0ZXM/DQo+IA0K PiBUaGlzIG1lYW4sIFBVVCBTaWduYWxDaGFubmVsIE1pdGlnYXRpb24gcmVxdWVzdCB3aXRoDQo+ IG9ubHkgYWNsLWxpc3QgKHdpdGhvdXQgYW55IHRhcmdldC14eHgpLg0KPiANCj4gVXNlY2FzZToN Cj4gICAgT25seSB1cGRhdGUgc3RhdHVzIG9mIERhdGFDaGFubmVsIEFDTCBkdXJpbmcgYSBERG9T IGF0dGFjay4NCj4gICAgKElmIERhdGFDaGFubmVsIEFDTCBpcyBlbm91Z2ggZm9yIHByb3RlY3Rp b24uICkNCj4gDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IFRha2FoaWtvIE5hZ2F0YQ0KPiANCj4g T24gMjAxOS8wMS8yMSAyMzoyNSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN Cj4gPiBIaSBUYWthaGlrbywNCj4gPg0KPiA+IEkgdXBkYXRlZCB0aGUgZHJhZnQgdG8gdGFrZSBp bnRvIGFjY291bnQgeW91ciBjb21tZW50czoNCj4gPg0KPiA+ICogTWFrZSBzdXJlIHRoYXQgYnkg ZGVmYXVsdCwgdGhlIGRhdGEgY2hhbm5lbCBpcyB1c2VkIGZvciBBQ0wtcmVsYXRlZA0KPiBvcGVy YXRpb25zLg0KPiA+ICogTm8gdXBkYXRlIGlzIHJlcXVpcmVkIHRvIGVmZmljYWN5IHVwZGF0ZSwg Z2V0LCBhbmQgZGVsZXRlLg0KPiA+DQo+ID4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZSBjaGFu Z2VzIGFkZHJlc3NlcyB5b3VyIGNvbW1lbnRzLg0KPiA+DQo+ID4gRG9uJ3QgaGVzaXRhdGUgdG8g c2hhcmUgYW55IGZ1cnRoZXIgY29tbWVudCB5b3UgbWF5IGhhdmUuIFRoYW5rcy4NCj4gPg0KPiA+ IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gPj4gRGXCoDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXQ0KPiA+PiBFbnZvecOpwqA6IGx1bmRpIDIxIGphbnZpZXIgMjAxOSAxNToy MQ0KPiA+PiDDgMKgOiBUYWthaGlrbyBOYWdhdGE7IFRpcnVtYWxlc3dhciBSZWRkeTsgQk9VQ0FE QUlSIE1vaGFtZWQgVEdJL09MTjsgUmVkZHkNCj4gSzsNCj4gPj4gS2FuYW1lIE5pc2hpenVrYQ0K PiA+PiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW5pc2hpenVr YS1kb3RzLXNpZ25hbC1jb250cm9sLQ0KPiA+PiBmaWx0ZXJpbmctMDIudHh0DQo+ID4+DQo+ID4+ DQo+ID4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1uaXNoaXp1a2EtZG90cy1zaWduYWwt Y29udHJvbC1maWx0ZXJpbmctMDIudHh0DQo+ID4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUNCj4gPj4gSUVURiBy ZXBvc2l0b3J5Lg0KPiA+Pg0KPiA+PiBOYW1lOgkJZHJhZnQtbmlzaGl6dWthLWRvdHMtc2lnbmFs LWNvbnRyb2wtZmlsdGVyaW5nDQo+ID4+IFJldmlzaW9uOgkwMg0KPiA+PiBUaXRsZToJCUNvbnRy b2xsaW5nIEZpbHRlcmluZyBSdWxlcyBVc2luZyBET1RTIFNpZ25hbCBDaGFubmVsDQo+ID4+IERv Y3VtZW50IGRhdGU6CTIwMTktMDEtMjENCj4gPj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4gPj4gUGFnZXM6CQkxNQ0KPiA+PiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5pc2hpenVrYS1kb3RzLQ0KPiA+PiBzaWduYWwt Y29udHJvbC1maWx0ZXJpbmctMDIudHh0DQo+ID4+IFN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1uaXNoaXp1a2EtZG90cy0NCj4gc2lnbmFsLQ0K PiA+PiBjb250cm9sLWZpbHRlcmluZy8NCj4gPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uaXNoaXp1a2EtZG90cy1zaWduYWwtDQo+ID4+IGNvbnRy b2wtZmlsdGVyaW5nLTAyDQo+ID4+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW5pc2hpenVrYS0NCj4gZG90cy0NCj4gPj4gc2lnbmFs LWNvbnRyb2wtZmlsdGVyaW5nDQo+ID4+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbmlzaGl6dWthLWRvdHMtDQo+ID4+IHNpZ25hbC1jb250 cm9sLWZpbHRlcmluZy0wMg0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGFuIGV4dGVuc2lvbiB0byB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCB0 bw0KPiA+PiAgICAgY29udHJvbCB0aGUgZmlsdGVyaW5nIHJ1bGVzIHdoZW4gYW4gYXR0YWNrIG1p dGlnYXRpb24gaXMgYWN0aXZlLg0KPiA+Pg0KPiA+PiAgICAgUGFydGljdWxhcmx5LCB0aGlzIGV4 dGVuc2lvbiBhbGxvd3MgYSBET1RTIGNsaWVudCB0byBhY3RpdmF0ZSBvciBkZS0NCj4gPj4gICAg IGFjdGl2YXRlIGZpbHRlcmluZyBydWxlcyBkdXJpbmcgYSBERG9TIGF0dGFjay4gIFRoZSBjaGFy YWN0ZXJpemF0aW9uDQo+ID4+ICAgICBvZiB0aGVzZSBmaWx0ZXJpbmcgcnVsZXMgaXMgc3VwcG9z ZWQgdG8gYmUgY29udmV5ZWQgYnkgYSBET1RTIGNsaWVudA0KPiA+PiAgICAgZHVyaW5nIHBlYWNl IHRpbWUgYnkgbWVhbnMgb2YgRE9UUyBkYXRhIGNoYW5uZWwuDQo+ID4+DQo+ID4+IEVkaXRvcmlh bCBOb3RlIChUbyBiZSByZW1vdmVkIGJ5IFJGQyBFZGl0b3IpDQo+ID4+DQo+ID4+ICAgICBQbGVh c2UgdXBkYXRlIHRoZXNlIHN0YXRlbWVudHMgd2l0aGluIHRoZSBkb2N1bWVudCB3aXRoIHRoZSBS RkMNCj4gPj4gICAgIG51bWJlciB0byBiZSBhc3NpZ25lZCB0byB0aGlzIGRvY3VtZW50Og0KPiA+ Pg0KPiA+PiAgICAgbyAgIlRoaXMgdmVyc2lvbiBvZiB0aGlzIFlBTkcgbW9kdWxlIGlzIHBhcnQg b2YgUkZDIFhYWFg7Ig0KPiA+Pg0KPiA+PiAgICAgbyAgIlJGQyBYWFhYOiBDb250cm9sbGluZyBG aWx0ZXJpbmcgUnVsZXMgVXNpbmcgRE9UUyBTaWduYWwgQ2hhbm5lbCI7DQo+ID4+DQo+ID4+ICAg ICBvICByZWZlcmVuY2U6IFJGQyBYWFhYDQo+ID4+DQo+ID4+ICAgICBvICBbUkZDWFhYWF0NCj4g Pj4NCj4gPj4gICAgIFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50cyB3aXRoIHRoZSBSRkMg bnVtYmVyIHRvIGJlIGFzc2lnbmVkIHRvDQo+ID4+ICAgICB0aGUgZm9sbG93aW5nIGRvY3VtZW50 czoNCj4gPj4NCj4gPj4gICAgIG8gICJSRkMgU1NTUzogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNl cnZpY2UgT3BlbiBUaHJlYXQgU2lnbmFsaW5nDQo+ID4+ICAgICAgICAoRE9UUykgU2lnbmFsIENo YW5uZWwgU3BlY2lmaWNhdGlvbiIgKHVzZWQgdG8gYmUNCj4gPj4gICAgICAgIFtJLUQuaWV0Zi1k b3RzLXNpZ25hbC1jaGFubmVsXSkNCj4gPj4NCj4gPj4gICAgIG8gICJSRkMgRERERDogRGlzdHJp YnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQgU2lnbmFsaW5nDQo+ID4+ICAgICAg ICAoRE9UUykgRGF0YSBDaGFubmVsIFNwZWNpZmljYXRpb24iICh1c2VkIHRvIGJlDQo+ID4+ICAg ICAgICBbSS1ELmlldGYtZG90cy1kYXRhLWNoYW5uZWxdKQ0KPiA+Pg0KPiA+PiAgICAgUGxlYXNl IHVwZGF0ZSB0aGUgInJldmlzaW9uIiBkYXRlIG9mIHRoZSBZQU5HIG1vZHVsZS4NCj4gPj4NCj4g Pj4NCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiA+PiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+DQo+IA0KPiAtLQ0KPiA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiDmoKrlvI/kvJrnpL7jg6zjg5Tjg4Djg6AN Cj4g5rC455Sw44CA6LK05b2mDQo+IA0KPiBNYWlsOiBuYWdhdGFAbGVwaWR1bS5jby5qcA0KPiBU ZWw6ICAgMDMtNjI3Ni01MTAzDQo+IA0KPiDjgJIxNTEtMDA3MQ0KPiDmnbHkuqzpg73muIvosLfl jLrmnKznlLozLTEyLTHjgIDkvY/lj4vkuI3li5XnlKPopb/mlrDlrr/jg5Pjg6s25Y+36aSoDQo+ ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3Rz QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Mon Feb 11 00:07:52 2019 Return-Path: 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 786EA131023 for ; Mon, 11 Feb 2019 00:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LBGe2YQSbsPb for ; Mon, 11 Feb 2019 00:07:49 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD39128BCC for ; Mon, 11 Feb 2019 00:07:49 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 43ydgl4QJkzFq7Z; Mon, 11 Feb 2019 09:07:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 43ydgl3kBGzCqkq; Mon, 11 Feb 2019 09:07:47 +0100 (CET) Received: from OPEXCAUBMA1.corporate.adroot.infra.ftgroup (10.114.13.20) by OPEXCLILM41.corporate.adroot.infra.ftgroup (10.114.31.42) with Microsoft SMTP Server (TLS) id 14.3.435.0; Mon, 11 Feb 2019 09:07:47 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0435.000; Mon, 11 Feb 2019 09:07:47 +0100 From: To: Takahiko Nagata , "dots@ietf.org" Thread-Topic: [Dots] Question: SignalChannel Mitigation using Mitigator with asynchronous Thread-Index: AQHUwRKOsXPmo84zYU+SgC7IhR2h1aXaOoGA Date: Mon, 11 Feb 2019 08:07:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1D1ED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <1842c1bf-96b2-8757-f8b1-8a8efd84a491@lepidum.co.jp> In-Reply-To: <1842c1bf-96b2-8757-f8b1-8a8efd84a491@lepidum.co.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Question: SignalChannel Mitigation using Mitigator with asynchronous 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 08:07:52 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Takahiko Nagata > Envoy=E9=A0: dimanche 10 f=E9vrier 2019 08:31 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] Question: SignalChannel Mitigation using Mitigator with > asynchronous >=20 > Hi all, >=20 > I confirmed latest(-28 version) SignalChannel and I have questions. > I would like to use Mitigator with asynchronous request/response. >=20 > In success case is OK: > 1. DOTS Server recieve Mitigation request. > 2. DOTS Server response with status=3D1 > (Attack mitigation setup is in progress) > 3. Call Mitigator with asynchronous > 4. If success mitigation, DOTS Server response(via observe) > with status=3D2 > (2: Attack is being successfully mitigated) >=20 > But in failure case: > 1. DOTS Server recieve Mitigation request. > 2. DOTS Server response with status=3D1 > (Attack mitigation setup is in progress) > 3. Call Mitigator with asynchronous > 4. If failure mitigation, DOTS Server response(via observe) > with status=3D7? > (7: Attack mitigation is withdrawn (by the DOTS server)) >=20 >=20 > (Question1) status=3D7(withdrawn) is correct in this case? [Med] If the failure is not due to an exceed capacity (which supposes likel= y a status transition to 2 and then 4), returning 7 is correct here. =20 > (Question2) How to notify reason of withdrawn to DOTS client? [Med] Transitioning from 1 to 7 is clear enough that the problem is related= to the completion of the mitigation setup. Isn't it? We have defined the signal channel model so that it can be fed automaticall= y with new values that can be registered in the "Status Codes Sub-Registry"= .=20 >=20 >=20 > Best Regards, > Takahiko Nagata >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 13 07:17:11 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C62F1130E27; Wed, 13 Feb 2019 07:16:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-dots-requirements.all@ietf.org, ietf@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155007101476.9655.11486107409890423462@ietfa.amsl.com> Date: Wed, 13 Feb 2019 07:16:54 -0800 Archived-At: Subject: [Dots] Genart telechat review of draft-ietf-dots-requirements-18 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:16:55 -0000 Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dots-requirements-18 Reviewer: Robert Sparks Review Date: 2019-02-13 IETF LC End Date: 2018-11-23 IESG Telechat date: 2019-02-21 Summary: Ready, but with a process issue for the shepherd and AD to consider. This version addressed all of my comments on version -16. Thank you. However, the diff shows that a large number of SHOULDs were changed to MUSTs. I'm guessing that was in response to a comment in the TSVART review of -16. This large scale substitution makes me worry - are they really the right adjustments? Has the group reviewed and agreed to these normative changes? As a nit, I'll note that the additional description of heartbeating creeps into specifying protocol rather than requirements. From nobody Wed Feb 13 08:46:36 2019 Return-Path: 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 591341200ED; Wed, 13 Feb 2019 08:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=mit.edu 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 fbPwTSK6VhdO; Wed, 13 Feb 2019 08:46:30 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700119.outbound.protection.outlook.com [40.107.70.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7151200B3; Wed, 13 Feb 2019 08:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gN5VpsXD7iIpCFnvjyqj4P10V/Z/uPI9xy1bWgSJWFM=; b=JPtF+SNwCt6fLCpN/O82HejWmoUM8ScV5v3zFANHRNWw4hNGSD+WFlhytCqSA7aswoV0FD9WZUeENLgYir1LS+er+TGDmOml2ck1aD1PQqORuSeUH9xkum0M9mt1Ki34JtJUVewLVkT3WgHbezsilmFrHrDDdgAPWwrsLsI/BwA= Received: from DM5PR0101CA0034.prod.exchangelabs.com (2603:10b6:4:28::47) by MWHPR01MB3213.prod.exchangelabs.com (2603:10b6:300:fa::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Wed, 13 Feb 2019 16:46:27 +0000 Received: from DM3NAM03FT065.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::208) by DM5PR0101CA0034.outlook.office365.com (2603:10b6:4:28::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Wed, 13 Feb 2019 16:46:27 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT065.mail.protection.outlook.com (10.152.82.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Wed, 13 Feb 2019 16:46:26 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1DGkNIV006418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 11:46:25 -0500 Date: Wed, 13 Feb 2019 10:46:23 -0600 From: Benjamin Kaduk To: CC: Message-ID: <20190213164622.GX56447@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(136003)(2980300002)(199004)(189003)(51444003)(2351001)(106002)(316002)(186003)(75432002)(47776003)(786003)(58126008)(36906005)(26826003)(16586007)(478600001)(23726003)(126002)(486006)(8676002)(46406003)(476003)(8936002)(956004)(50466002)(4326008)(246002)(33656002)(26005)(336012)(356004)(106466001)(426003)(6916009)(14444005)(305945005)(104016004)(55016002)(88552002)(97756001)(1076003)(450100002)(2906002)(7696005)(30864003)(53416004)(86362001)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR01MB3213; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT065; 1:So49SHgmO41EKqPQXA5s8ElEcXF5O+SpJyw+4wJa5UNCtiAXUGc/zIfSCzW0TsqJfzkgzzTTmlu1PSDMVNObImBTLtMkQ/+JYYg2lD4BG9vh4955DVetbKzSXlc5UIlPSOE7af50dTV1QN436XLh0g== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 857d762a-28ef-4711-7b4e-08d691d2cbee X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:MWHPR01MB3213; X-MS-TrafficTypeDiagnostic: MWHPR01MB3213: X-Microsoft-Exchange-Diagnostics: 1; MWHPR01MB3213; 20:Vhcv0hHMp3B2nkITBdbi3UhpG5H13oJaSZrEVCUejd67asnCWph2YTJIJ5jp9JVF2fko24SQG5vWd0NLDndMR+4ZGuT3d1HZZo6DctJVRVXyIgsf3+kJtI4PKfU+ycyP7fSMCOfCtbDsz6KhJldmb5j1ueHRKUq5STEQ0wb6w1aZMYrIMXC0uM8XWnIM4jODRAmhmw9JZ2HQOLPwcsFngvL7Wroew91ha74kbbgCvks2YX7DGJt9MKwyhPkjKiA0k8Z8I9OcC2E/PnqQo4CLUwR2z46elBfsLErWjQan1xut/Y0dBH7t/viIOPUmLjF384nK35Yn/jly7uY78ze81ofqmrFh2qaIPu07T+iJlHAUPeAUU15Wqz3ry4JtPUwsbFrocQDAT/h8w7baxH6trDqzUDkwabn0qmq8/Ios89f4fIpZGbthdbPpH0+PaOLUraH/oJPc/qpbAsAUjyLNT+2oFFwn7AUX46La5JGOczRjhcAp714Zd1y70mFuxlhUQB+FaUR/6IF4kFeGbnblg0PMN9qqtsr4i9r9cspkCNCVsu4ng+deQ+/7bWF8MyAU/oz30ptlMbqIiFbiZMAcKj9R8kV+luaP8p0UsX8wWkg= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 094700CA91 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR01MB3213; 23:FLPimXXmMYBXubfkZT7rX4fyYhofVznfXjxGVV/Mq?= =?us-ascii?Q?GE870e56EXRBpUQNA+K1ngTTGwYdnWlaK5y0feAOS3/Si0SBL0k6enxdprq1?= =?us-ascii?Q?jC2wa+F+/L8cFa4HZ61GpTysti+WhRDaHvqWaWm0oujhARnp1+MuPgjeAYz6?= =?us-ascii?Q?zDlBvVpEbwMM++XrodI/EVeiuvjTg491/iiEV3VJC7a9hGHrqAkrMRaeS1tV?= =?us-ascii?Q?DXY//l0CQz4nImSn75e5rm3nZWRBbjDhQbMgQi398CGKLAdPakPy12OsSCgy?= =?us-ascii?Q?NkKzIo/QigJaAtFFRmFSBA+BfT7d9Aw/vheqAppNCL7Vjbx+HOp6AzoX1hj4?= =?us-ascii?Q?Bae0N+VNVXr/e9DhQ3TLAT1wbfHAX/DYjg66gpf1Lu2dpQIdl0PxaLZnp8Rp?= =?us-ascii?Q?ApZjQfRd/nJmpHRcLpvV8uW5ddOWg+L6hEFtjwsmNXXtpXC9jZpPLG114kQQ?= =?us-ascii?Q?FkstY42Up4kK1sOUw+1Lc5sqDZoV7TY4XmqHvI9aqGoX7t1xmMWS0ZmxR/0L?= =?us-ascii?Q?op6Uo8GcG7XZOYxpmswJx1MzfNNLyorXL1tFA+/aUnRVZdd1IaKOgGEpQQLj?= =?us-ascii?Q?Jns8fijHpVgsRc4pyTK56VoV6oo35Rafzb0S+V2cHqMbCnc1qSRHEIjtoBlP?= =?us-ascii?Q?BCIVPf/bHcfV2uTPNwCjDvS5MJ8Ks63M5E4EqqLK5/gi9RiAaM9VK7lDtUGe?= =?us-ascii?Q?CI9kK2+hmQ53dlo4LM9K2D44eu8Y/U/p6tR4gG3yw3b9Ex+ULazto+fpryYt?= =?us-ascii?Q?dArtnc0wsi1ViVxdTcwrLzflX/FTjlwPCyw10D0uqPnbe8j03L2VP5XsU8aV?= =?us-ascii?Q?0QIMLSCILAiLqKUlhDkMq+X7Qef37OZrzqnRa5I2zf8EYpz7eXyVLV32cpyh?= =?us-ascii?Q?B8K/dWCun4/uLf06viivFbaDC/M10oZKvinH1UPiJof1gwJvSjUIvEEgZscC?= =?us-ascii?Q?PboAJKkHq1NG5khTPQ+ndfkIFHObuaVfQA5r4B3XMgk9a+vh81f07TJxrJcS?= =?us-ascii?Q?QPNRWBUnQVBbuNAf3hrryPPB4ZqFXRWuIqK3IFjWoxJWuiUJB1giGC6DfEUL?= =?us-ascii?Q?s0kcd15p7n84HOATC1ToDDPWwFx+d+ytcUL/3ma84822eugqShfZ10LEF3sy?= =?us-ascii?Q?+H/cVHJlKVgRiXYxsNHVUDJp7okHVAL/ebnWEp8c25y2CM+zpn7gA=3D=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 65CZH7CtISXZm5oAjbJ7joVeKjVKWE7NTA4pPaRH7oorP2JZQUVT1fRLtcg1aWurPlKLRh2ySp/sDB6XicT2tZPE5dl5pyULU57vuTMsOgQuRCV0xd+wjfnllxuanE4f7t8DrYsYrFnyttfAGikE3tdSLb7F4BNMkUJWJJo2pvF6jljzjEkNkFU2NwfuIjpZFvIoB5pX9DUgMLnQTKoSoNXdWn5SrytH2Bz/7iQkeSZw0ynX/WSkfoBC4XLXuB9Dr1KaiH7eO4us6OxZydgaVYDKvBQ2unXEe3pwr93pz7G3AW4NzG4m4vXYRsgvVn7gkwTJfX9L9wptvkWkXvhyseFBB8yeYCXO/qh8SQGv6mKgj7ax/lEydwlWjiRqeodTNQMOjQZl3lcT2+AY0AAQ0RbqmLs1XKAEcuZJq+qQhIw= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2019 16:46:26.7475 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 857d762a-28ef-4711-7b4e-08d691d2cbee X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB3213 Archived-At: Subject: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 16:46:34 -0000 This is my AD review of the -25 I see that Med made a commit on github that preemptively addressed at least one of these comments, but will trust the authors to do to the right thing with anything in here that's stale. A handful of generic and/or high-level comments before the section-by-section nitty-gritty stuff. The author count is large (7); RFC 7322 notes that the stream approver (i.e., the IESG) will ask questions if the count is more than five. What should I tell people when they ask? (The authors are listed also in the YANG module itself, if changes are made.) Can someone (the shepherd?) confirm that an automated syntax checker has run over the JSON in examples? The concept of "DOTS client domain" is being used for actual protocol purposes here (most notably as a bound on the prefix(es) that a client can request mitigation for, but I don't remember seeing a formal definition for how any DOTS actor would know the specific bounds of such a client domain. Is there text somewhere that I missed that we can point to, or will we need to add some? We don't say much about what validation the server does on input data, and we probably should. For example, does the server need to validate 'cuid' and/or 'cdid' in dots-client-creation requests? What about validating that the (e.g.) ACL name in the PUT URL matching the name in the body of the request? There are probably others as well. The examples all use "Host: {host}:{port}" which is not really an example but rather a template. Since they are supposed to be examples, we should pick a concrete hostname (and port) to use. There is, shall we say, a "high degree of overlap" between Sections 5/6/7 and the YANG model field descriptions. I mostly assume that the WG considered letting the YANG model (and the core RESTCONF spec) stand alone without the additional examples/specification of the use of RESTCONF to manage clients, aliases, and filter rules, so I won't suggest that we revisit the question. But I do think that it would be good to have some explicit text acknowledging the overlap and stating which one is authoritative. There seems to be some mismatch between whether the IPv6 ACL subtree uses "ttl" or "hoplimit" -- Figure 7 has "ttl" but the rest of the document seems to (properly) use "hoplimit". Someone else should double-check the relevant places, though, as I'm not sure I was looking at all of them with this issue in mind. I'm also a bit curious about the use of an explicit "capabilities" tree for fine-grained feature detection, as opposed to native YANG "feature"s. The latter would allow the relevant nodes to just not exist when unsupported, as opposed to the explicit-capabilities formulation where they exist but are (presumably) ignored. (I don't remember us explictily saying that they're ignored in this case, either; might be worth adding some text.) In a similar vein, we include 'capabilities' nodes for a few matching features that are listed as "mandatory fields" for ACL matching in Table 1, and thus whose value would always be "true". Why do we need the capability leaves in such a case? idnits notes a few references that can be updated along with the other changes; it also flags a "reference in abstract" for the RFC Editor note which we could probably ignore (but could probably also just remove the brackets around the text in question). I also looked at the references (especially the normative/informative split) and have a few suggestions: - the IEEE.754.1985 reference is not needed; we don't use the binary floating-point encoding but rather a string one for YANG decimal64 - I think that RFC 8499 (dnsop-terminology-bis) can wholly supersede our usage of RFC 1983, so the 1983 cite can be dropped as well - draft-ietf-dots-requirements (for terminology), RFC 7950, and RFC 8259 should probably all move to the normative section Section 1 The sub-bullet point about "If a network resource ... informs its servicing DOTS gateway of all suspect IP addresses that need to be drop- or accept-listed ..." made me wonder if that was more of a signal-channel activity or a data-channel one. Perhaps this is just a matter of the text not being as clear as it could be. (I also wonder if we should say "further investigation" since we don't really have an automated way to indicate that yet.) Section 2 When we talk about tree diagrams, should we also say something like "Note that the full module's tree has been split across several figures to aid the exposition of the various sub-trees"? Section 3.1 When we talk about using GET to retrieve running configuration, do we want to note that since the data channel can fail during attack time, it's expected to be common to perform such a GET before attempting to make modifications to configuration? A DOTS client registers itself to its DOTS server(s) in order to set up DOTS data channel-related configuration data and receive state data (i.e., non-configuration data) from the DOTS server(s) (Section 5). Mutual authentication and coupling of signal and data channels are specified in [I-D.ietf-dots-signal-channel]. I think we should split the "mutual authentication" and "coupling of signal and data channels" into their own sentence, and flesh them out slightly more. So, section references to Sections 8 and 4.4.1, respectively, the usage of TLS client certificates, the coupling of channels via the client's identity ('cuid' and 'cdid'), etc. A TLS heartbeat [RFC6520] verifies that the DOTS server still has TLS state by returning a TLS message. I expect this will get some pointed comments during IETF LC, given the recent-ish IETF-wide discussions about heartbeats/keepalives in general. Is there perhaps a RESTCONF-level probe message that could be used to check liveliness; a capabilities query perhaps? A DOTS server may detect conflicting filtering requests from distinct DOTS clients which belong to the same domain. For example, a DOTS client could request to drop-list a prefix by specifying the source prefix, while another DOTS client could request to accept-list that same source prefix, but both having the same destination prefix. It is out of scope of this specification to recommend the behavior to follow for handling conflicting requests (e.g., reject all, reject the new request, notify an administrator for validation). DOTS servers SHOULD support a configuration parameter to indicate the behavior to follow when a conflict is detected. Section 7.2 specifies the behavior when no instruction is supplied to a DOTS server. I'm a bit confused by the "out of scope of this specification to recommend the behavior to follow for handling conflicting requests", since not only does the last sentence of the paragraph give a pointer to a specified behavior in case of conflicts, but we also mention it in a couple other places (e.g., the bottom of page 43). Also in that paragraph, it's unclear that a 2119 SHOULD is appropriate for "support a configuration parameter"; there's no interoperability considerations for having or not having such a configuration knob. Section 3.3 NAT Considerations have "high overlap" with the text at the end of the signal-channel's "Design Overview". At a minimum we should diff them and enforce convergence, but do we want to consider just having one refer to the other? Section 3.5 I had to read up on RESTCONF and NETCONF while reviewing this, but from what I've seen so far, the "error-severity" field is only present in NETCONF and not RESTCONF. If so, then we shouldn't need to talk about it here, since we use RESTCONF exclusively. I also couldn't find whether there's a registry that we should add the "loop-detected" error-tag to. Can anyone here help me out? Section 4.2 Is there any plan/expectation for filtering/match rules for QUIC? It is probably premature to put anything in this document specifically, but still worth thinking about. The order in which the leaves appear in the "capabilities/ipv6" and "capabilities/tcp" subtrees do not match the order they appear in the ACL subtree itself; it would be good to keep the order consistent. We don't really say much about what the semantis of the "port-range" capabilities are; is that supposed to indicate any port-matching ability at all, or specifically the low-to-high range matching, or also the "operator" options? Section 4.3 We define an "operator" typedef that is rather different from that from netmod-acl-model. Do we want to use a different name to aid disambiguation? ("bitmask-operator" comes to mind as an option.) typedef fragment-type { type bits { bit df { position 0; description "Don't fragment bit for IPv4. This bit must be set to 0 for IPv6."; Set to zero by whom? What should the receiver do if it is set otherwise? What are the semantics if (either or both of target-fqdn and target-uri) and target-prefix are specified? (I suppose maybe this could be covered in Section 6.1 when we say that at least one is required in ACL-creation requests.) The units for the "rate-limit" node should be specified in the YANG module and not in the description of how to install filtering rules. list dots-client { key "cuid"; description "List of DOTS clients."; leaf cuid { type string; description "A unique identifier that is randomly generated by a DOTS client to prevent request collisions."; I don't think "randomly generated" is really correct here. The "capabilities/icmp/rest-of-header" description should be more clear that (per draft-ietf-netmod-acl-model) it is supposed to match both the ICMP four-byte field and the ICMPv6 message body. Section 5.1 It may be worth reiterating that (per the signal-channel doc) gateways may rewrite the 'cuid'. When POST is used to create a dots-client resource, how does the client know the path of the created resource (to be used for subsequent RESTCONF requests)? (I assume it is supposed to just use the submitted 'cuid', but we need to explicitly say this. This also seems to render much of the distinction between POST and PUT moot, for our usage, though I do not propose any change to the text.) The DOTS gateway, that inserted a 'cdid' in a PUT request, MUST strip the 'cdid' parameter in the corresponding response before forwarding the response to the DOTS client. Why does this apply only to PUT and not POST? Section 6.1 DOTS clients within the same domain can create different aliases for the same resource. My reading of this text is that client A can create alias "foo" for IP prefix 128.0.1.5/31 and clinet B can create alias "bar" for the same IP prefix, and that DOTS supports that process. (Just to confirm that the text is saying what it's intended to.) I do wonder if we want to say something about whether alias names need only be unique per 'cuid' or in some more global fashion. (Having a global uniqueness property is perhaps convenient in order to interface with non-DOTS mechanisms for querying aliases, or for the DOTS server to interact with network filtering appliances.) Figure 16 puts double-quotes around "string" in the pseudo-schema, which feels weird to me. target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An FQDN is the full name of a resource, rather than just its hostname. For example, "venera" is a hostname, and "venera.isi.edu" is an FQDN [RFC1983]. Refer to [I-D.ietf-dnsop-terminology-bis] for more details. I don't think this text is particularly well-aligned with RFC 8499 and would suggest trimming it substantially and just pointing to that RFC. If the request is missing a mandatory attribute or its contains an invalid or unknown parameter, "400 Bad Request" status-line MUST be returned by the DOTS server. The error-tag is set to "missing- attribute", "invalid-value", or "unknown-element" as a function of the encountered error. This text seems to preclude any future extension that adds new error tags; is this intended? Section 7.1 A DOTS client which issued a GET request to retrieve the filtering capabilities supported by its DOTS server, SHOULD NOT request for filtering actions that are not supported by that DOTS server. What is the server behavior if the client ignores this SHOULD NOT? Figure 23 shows an example of a response received from a DOTS server which only supports the mandatory filtering criteria listed in Section 4.1. This seems inaccurate, as the mandatory filtering criteria exlude the rate-limit among others. Section 7.2 activation-type: Indicates whether an ACL has to be activated (immediately or during mitigation time) or instantiated without being activated (deactivated). Deactivated ACLs can be activated using a variety of means such as manual configuration on a DOTS server or using the DOTS data channel. Is this done by the data channel or the signal channel? If this attribute is not provided, the DOTS server MUST use 'activate-when-mitigating' as default value. Why do we specify default values here instead of in the YANG module? Filters that are activated only when a mitigation is in progress MUST be bound to the DOTS client which created the filtering rule. Other filters do not need to be bound to the DOTS client that created them? Wouldn't we still want to remove them when the dots-client resource in question is deleted? destination-ipv4-network: The destination IPv4 prefix. DOTS servers [...] This is a mandatory attribute in requests with an 'activation- type' set to 'immediate'. I somehow thought there were YANG attributes that could indicate this conditional requirement in the module itself, though I am hardly a YANG expert. The error-tag is set to "missing-attribute", "invalid-value", or "unknown-element" as a function of the encountered error. Same comment as above about (non-)extensibility. Section 7.3 I see that the "test-acl-*" and "test-ace-*" acl and ace objects in these examples do in fact use different names for the semantically different objects, but perhaps we could help the reader's eye and use strings with a larger Hamming distance? (I thought they were all the same on my first read.) (I also am a little confused at why the "ace" "name" field is considered a non-config field, in Figure 31, but this seems more likely to be my confusion than an error in the document.) Section 8 o DOTS server MUST NOT enable both DOTS data channel and direct configuration to avoid race conditions and inconsistent configurations arising from simultaneous updates from multiple sources. o DOTS agents SHOULD enable DOTS data channel to configure aliases and ACLs, and only use direct configuration as a stop-gap mechanism to test DOTS signal channel with aliases and ACLs. Further, direct configuration SHOULD only be used when the on-path DOTS agents are within the same domain. Doesn't all this discussion of "direct configuration" conflict with the "MUST NOT" in the first bullet point? Section 10 Generally with the security considerations template for YANG modules, we need to list out all the nodes considered sensitive and the consequences of writing(/reading) each one in turn. From nobody Wed Feb 13 09:35:22 2019 Return-Path: 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 7C8F3130F65; Wed, 13 Feb 2019 09:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cert.org 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 1tQ5BMYVtLRZ; Wed, 13 Feb 2019 09:35:10 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 33FB1130ED0; Wed, 13 Feb 2019 09:35:10 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1DHZ8LL011343; Wed, 13 Feb 2019 12:35:08 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x1DHZ8LL011343 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1550079308; bh=1J7BWKWyTaI/N6PZfEFI8JUYQrFFsA4nAqRO3Mp2SqM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ft/fpOkiqn8ro+kFwWLM6tFkXEzIKmppaKXyLz3Hl+5s7rKFneS9OYP5/wPvNQ3Cf WheDjDx4n+e/Z5kKMZlyhLYU/KM5ilXFuQs6go2GdCpyQQO/6hXwGJDDFl95M1zjo+ MIuxfI7IkMXPzDuENgk9BdQj69qsFhlitVKVp6ko= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1DHZ2G1018979; Wed, 13 Feb 2019 12:35:02 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Wed, 13 Feb 2019 12:35:02 -0500 From: Roman Danyliw To: Benjamin Kaduk , "draft-ietf-dots-data-channel@ietf.org" CC: "dots@ietf.org" Thread-Topic: [Dots] AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUw7uxZs45zX8IakO+sq0/OtQQsKXd96Qg Date: Wed, 13 Feb 2019 17:35:01 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857C1DEB@marathon> References: <20190213164622.GX56447@kduck.mit.edu> In-Reply-To: <20190213164622.GX56447@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 17:35:21 -0000 Hi Ben and Data Channel Authors! > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Benjamin Kaduk > Sent: Wednesday, February 13, 2019 11:46 AM > To: draft-ietf-dots-data-channel@ietf.org > Cc: dots@ietf.org > Subject: [Dots] AD review of draft-ietf-dots-data-channel-25 > This is my AD review of the -25 [snip] =20 > Can someone (the shepherd?) confirm that an automated syntax checker > has run over the JSON in examples? I'm the shepherd. I validated the YANG in Section 4.3, but forgot to do th= e JSON. I just ran the JSON in Figures 11, 12, 13, 14, 16, 17, 19, 23, 24,= 25, 27, 29, and 31 through https://jsonlint.com/. All but Figure 16 came = back fine. =20 Per Figure 16, the following edit is necessary (i.e., add a quote around in= teger, s/integer/"integer"/) OLD "target-port-range": [ { "lower-port": integer, "upper-port": integer } ], "target-protocol": [ integer ], NEW "target-port-range": [ { "lower-port": "integer", "upper-port": "integer" } ], "target-protocol": [ "integer" ], =20 Roman From nobody Wed Feb 13 09:53:22 2019 Return-Path: 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 72EF9128766; Wed, 13 Feb 2019 09:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mit.edu 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 ToDAjLTGvQzJ; Wed, 13 Feb 2019 09:53:18 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734EE128D52; Wed, 13 Feb 2019 09:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lIdTkeL/1tuRlyE+Re5kCcF4eHgnBe1omHhtJRTwGZY=; b=ShN0tmqeY9fDl7OKwWeOacgdGmsXihiwriv+ZsBFnZDTaYR4vWwnQ0oOPtXOQulx3ah17oiplux25MfuF/YFEPkb9yNy68HWLXjQSKOjtvJIC8TWGlA1JaAoRLe83b7fbl5wLvha0ybEW9xMqp70xzTUZ53sn2A77STjnMT/cJ4= Received: from CY4PR0101CA0022.prod.exchangelabs.com (2603:10b6:910:3c::35) by SN6PR01MB4992.prod.exchangelabs.com (2603:10b6:805:c8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Wed, 13 Feb 2019 17:53:17 +0000 Received: from BY2NAM03FT053.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::204) by CY4PR0101CA0022.outlook.office365.com (2603:10b6:910:3c::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Wed, 13 Feb 2019 17:53:16 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT053.mail.protection.outlook.com (10.152.84.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Wed, 13 Feb 2019 17:53:16 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1DHr9vd016893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 12:53:14 -0500 Date: Wed, 13 Feb 2019 11:53:09 -0600 From: Benjamin Kaduk To: Roman Danyliw CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190213175309.GA56447@kduck.mit.edu> References: <20190213164622.GX56447@kduck.mit.edu> <359EC4B99E040048A7131E0F4E113AFC01857C1DEB@marathon> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01857C1DEB@marathon> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(376002)(396003)(2980300002)(13464003)(199004)(189003)(6246003)(316002)(86362001)(16586007)(246002)(33656002)(14444005)(4326008)(229853002)(53416004)(478600001)(106466001)(58126008)(186003)(1076003)(53546011)(305945005)(966005)(36906005)(8676002)(26826003)(76176011)(26005)(786003)(47776003)(336012)(106002)(97756001)(126002)(8936002)(486006)(75432002)(956004)(356004)(50466002)(6666004)(11346002)(55016002)(6306002)(23726003)(7696005)(6916009)(426003)(54906003)(88552002)(46406003)(2906002)(104016004)(476003)(446003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4992; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT053; 1:Kik3Kg5wnc9ojXQRoKCTRc4o80Cigb0rmE5W0oN8gmD6JZNV03HYvbdtAUirw50Gq6UiiRmyCUEPsG2DyKHPsoVssV80oBLyBDrXAg3p8ryMPGEw5GyUotVN/PWrbivF+0jhQ6GXRsiyRUo5o5241Q== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0206c395-fad0-4c59-cc05-08d691dc21e4 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB4992; X-MS-TrafficTypeDiagnostic: SN6PR01MB4992: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4992; 20:euzK0wnAgfKt2gYyjvqXYTBWG1uBkhx2i/iRdSmdNDWMVLh+xiMl6HASCGZuIl8VMdNV3r+bFJxqL/+r6CP9DlIsIaAXaqGORbKqCaLqoRqO6kPzKrWBbyEtb1FK13l3UCAC6np2GIoCsuBoPdHMLHvn9XD9tgyDp0b8Tl6GCCYl0S4VRRbbz39d07TfwJySVeNLAp0zPt5AuoX0hnO6apkfzFkizInhRYbKf02lZ/F65LrsUDDCeGagTZOYa9+saAMydwvbx9nc1RYrlGz6jRRF7aC6wLy0LeEhrUSKcHyneOFtcuX327XQZIUAAkRsVWK0kHXGQEJNFm3re1LsHrpHBHPcTOMVcSpApYc292ID+hDDI39fnptwSD1gvUIcSc2nWAWumxR6UhsrSM43ghGjM4wr8Vd7WbhZYY1VLj2baY2WAJyZOwI6ZMHoWYIFFkc6odCSwkpu83tCNS3wbY5jFG+ok/3Azpdt60Eo4Rbc+h9kk/mwOQlEzIA4dAc2nj+cyAQV5Gp6fuVUPvzQVx7F7o7jp77khL0CZXjm41RNJylTXUxztKj7DDwJgtlqJ41GNjJaHRJYtJCZa4qeTi6thsBXxlqNNSX6OAyIQdc= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 094700CA91 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB4992; 23:SDH+noQpwLa+w5jp2Q9sh10QmZZpKNnBPS1bUl6z/?= =?us-ascii?Q?kp/6FAUBitC9pKLJJlBV0xnoqN69mScQ2H4acqKrCqG0NDIAxlYtZy0EKfgW?= =?us-ascii?Q?OUw6Le2N+IcyYc4iKkCIBZeWELBwDAdYPb83agp4cxNvZTzuEP+o4rzSEuQ4?= =?us-ascii?Q?3rg6KUL3RXzzIDx27u8e/crpEb7r2QVA+mdJhNwTntqWEte+OF9UbsZHogZn?= =?us-ascii?Q?caTzizylVwn/4yNEd7qpoaYqIokdLgXw9Pg81AmcR26jRs46V8xnyi51LG9b?= =?us-ascii?Q?1kMqXTzTqQIdMd/gHyVyyUhuKuFm7nhidPIy32SPvYZd43VvvUkipQvzIGB3?= =?us-ascii?Q?eSTKtJaaYaHY29OEWed7ZePP//lBgrICbt+7EtgU3BqIL54V/CXpJg2yhmMk?= =?us-ascii?Q?94if7qm85oLEwwkNRJ33V0qTGmZ15nGpTbEb1qWZQFJjs3qlzMmj/FJGPBEs?= =?us-ascii?Q?voJvAoq0jjiXfRrNwhL+eiZ8ze+tZwvQjxwgzJ6fYIavhBU6Pu+fXqIZkQqD?= =?us-ascii?Q?Cljd1XgiZE+Gbcw0lJBkPHV9Vo6c+cAbMTYYHGJxU4yXHT2ZBTQuZdFNvL9u?= =?us-ascii?Q?AxJo5lYhF7pGaTdumcmmq829mZFCzV00bHb3a+0IX7ZE8IdUKmZz8SU9ySjG?= =?us-ascii?Q?90bSO6heSbiIQPO9XmXpOJjI8YAV/9MItIEPFAzXfFM7iu2YgIyjw39LYpX1?= =?us-ascii?Q?0Jsyy54uwuriioXEZ8u9xcbChgHcdXOv2KhzxpqfWeXwAfgIxDzYt42muXQN?= =?us-ascii?Q?OwW4cMWG4QZIM+KfhqqheBh0wU09m331tyC4bDDSVqhTaZ3pMGraQPpv+56Y?= =?us-ascii?Q?HU1PO4nlHRLWP73OAUsIyFj/d+JDngM/3QmrmiRmf1BBWnfXL9qMFuLwD9WH?= =?us-ascii?Q?ilr5meSjHFvrzATSzPaoaF5B5FrHhdTSk+v3sDAdypJuwwgPujeE0LLyM3US?= =?us-ascii?Q?9i03yLyY8UWSAIztDelJDombjlxtwVlrNJnhpJ2qjIbEHMK1nIA5eTyJqD0F?= =?us-ascii?Q?ltUqIbGdWbr0rZN8G2o1Ig3tDz+yD6TTm8ppSC0IBC65RR4DGJ+uABU/8wXR?= =?us-ascii?Q?8AqDKRMeaYEvLjIKJYbC/Mz8YbOWj5b46dyOhOR+8tc5tJN7nUld6EO6hfCf?= =?us-ascii?Q?ucVxGIoBLn35Cy8e4QA4KqFbRfBgDSQ/oQIfj4Ebg/7NHg+UlSpA8b0N5amR?= =?us-ascii?Q?275DeManSBVy+gE5bg4qq7BCUcnrxDjCpr2gWUIAMmtPrLw2V0kW5aY1RXPy?= =?us-ascii?Q?rYuOyHcNGsOVoStQPO9jbfS6OYjkBfTYtNjpG1AeVfKMrHRTWtjzyCp/oHmY?= =?us-ascii?B?dz09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: FWPKqfOLeut40wTT/11avUPS+D6m/k07rhea6pwrJs6bJJYNmJO7450ka9aF/DwYa58KuEnv8Lb+XiQX4mxvRmGVdQmXU3hPvxLbjI4LBN96RcG7KA64HJIa1dnSewEIgnfgLOjaJLgju90MJ20b2+BqmkVboIb9Yr7EpL9Xf/tuzPgzEyObx4C05G6Iw9KqkHtQrGX+5eDuRI1QZ7HCxzE/O8+f/Ida1t2+LWz2256B3nbWCV/h1QEAEkZtiLpSj3jj5qFYW16QZLn4+oI/6vgSxzMKLhEHRiHiL8do4lgLy4TnLTZubrplaGMVm345t6jJaYsNVQfvMkiRVSnzAQskR0ty3gnQg98Uoztq7OyoJBWxLmXXSx78NYIfkxEB2sgCbi3ue2QPbazuwCUkL6WU0RKo39z/NObsetpCwgc= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2019 17:53:16.3646 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0206c395-fad0-4c59-cc05-08d691dc21e4 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4992 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 17:53:20 -0000 On Wed, Feb 13, 2019 at 05:35:01PM +0000, Roman Danyliw wrote: > Hi Ben and Data Channel Authors! > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Benjamin Kaduk > > Sent: Wednesday, February 13, 2019 11:46 AM > > To: draft-ietf-dots-data-channel@ietf.org > > Cc: dots@ietf.org > > Subject: [Dots] AD review of draft-ietf-dots-data-channel-25 > > > This is my AD review of the -25 > > [snip] > > > Can someone (the shepherd?) confirm that an automated syntax checker > > has run over the JSON in examples? > > I'm the shepherd. I validated the YANG in Section 4.3, but forgot to do the JSON. I just ran the JSON in Figures 11, 12, 13, 14, 16, 17, 19, 23, 24, 25, 27, 29, and 31 through https://jsonlint.com/. All but Figure 16 came back fine. > > Per Figure 16, the following edit is necessary (i.e., add a quote around integer, s/integer/"integer"/) Hmm, that one is I think supposed to be more schema-like than example-like, so I actually was arguing to remove the quotes around "string" [and thus make the validator complain even more]. Thanks for checking! -Ben > OLD > "target-port-range": [ > { > "lower-port": integer, > "upper-port": integer > } > ], > "target-protocol": [ > integer > ], > NEW > "target-port-range": [ > { > "lower-port": "integer", > "upper-port": "integer" > } > ], > "target-protocol": [ > "integer" > ], > > Roman From nobody Wed Feb 13 22:08:39 2019 Return-Path: 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 BA977130E7E; Wed, 13 Feb 2019 22:08:38 -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 X4OgbBGi-GMi; Wed, 13 Feb 2019 22:08:36 -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 635CF131128; Wed, 13 Feb 2019 22:08:32 -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=1550124399; 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-ms-exchange-purlcount: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=bXyQzLix82xnSHcEPt9jYMzv+KMsR/9XG+AMig iWPO4=; b=pE2KYLjs2Moyp6oY/AKuocxrju0eo/wM3tBrazOP m3R95nF431BQyzRBTnQFo5iSo2mcFAWNC/TMk6LD0OXW8pV5D0 00D9Xw4s3abxkTb2daHVz2b/dP0fC00Jraw51xoZG4QY+D7mdO 2U4vOHRDjkoysAmlI0RW++JSmanbZdQ= 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 31dc_1ba3_e8aad5cb_bb3a_4ecb_9c8d_4104fba45a9f; Wed, 13 Feb 2019 23:06:38 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 23:08:15 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 13 Feb 2019 23:08:15 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 23:08:15 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2582.namprd16.prod.outlook.com (20.177.226.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Thu, 14 Feb 2019 06:08:13 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1622.016; Thu, 14 Feb 2019 06:08:13 +0000 From: "Konda, Tirumaleswar Reddy" To: Robert Sparks , "gen-art@ietf.org" CC: "draft-ietf-dots-requirements.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Genart telechat review of draft-ietf-dots-requirements-18 Thread-Index: AQHUw6841HY2UN6Vl02RqNBnhDntT6Xetd5Q Date: Thu, 14 Feb 2019 06:08:13 +0000 Message-ID: References: <155007101476.9655.11486107409890423462@ietfa.amsl.com> In-Reply-To: <155007101476.9655.11486107409890423462@ietfa.amsl.com> 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: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ff46bd5-726a-4bd8-0544-08d69242cdd6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2582; x-ms-traffictypediagnostic: BYAPR16MB2582: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNTgyOzIzOlhNcENhNmZ5OWQ3c0N2NWdUK252Y0ZwT3dw?= =?utf-8?B?RGpoUnRKUUs1NVZQUHd5NjJIYUljTzNlUC9lY3U4VGZscHRGWVF2dUo0RGRw?= =?utf-8?B?OWViU0oyQ1NBMFU0a2pvbVZ6ZzUrSXA3NGt1bjBUWTBkdjFETmloUFJEenJk?= =?utf-8?B?YTVPdzQvOTc0U2YzSXk1M1hQek1pS0lSZmRvaUpHZGRCZ2srSWZJeE1FSE92?= =?utf-8?B?WExRbExzbU94OTZXRVBobGF0aVN1eHB0T2w1c0IzcjIydWNEVjM3VXlEY1lO?= =?utf-8?B?UGtuQURLZmk4bXBWNUc0VGkvN1hobkV5NW9DdTdQMFVDd0xzU2dsay9BVlp2?= =?utf-8?B?Sm95bVM1RW5wbmZqTmZzWVg1eGdZMWZyU1lNSFAzYXlSaHorL25mQ0l1UEVn?= =?utf-8?B?M0t6R09EMDdNdGg0b1lyaVk5WmxyTmRCQlBLUnNkOVRPRTAwWVBSblFhNTdx?= =?utf-8?B?K05jalhpSWJWREJ2aFNid0NBU2sySy94UCt3eUcrSmsybmRRcFhCdG9Pc3ZR?= =?utf-8?B?elFXcmhNdExmQWp2RSs5RkRvcDJMV1JGNmJJeHUrUmtERzVZQm1FRGphUWlK?= =?utf-8?B?OXlqOUM0cGxYZ2pyWjkzUjB0aGg4d2x1ODRjaUhrNUVYTEROU2tJbCtJTnFh?= =?utf-8?B?TUhjcHB2bGQ3d1pXT0U0eGhUSGpsT0lpcWZjc29meUtkbGdobStJL0Y3MzFn?= =?utf-8?B?QUoxMkk3aDkvQklOVGNVWkV5L0FHNXE2QWZKS1pmYytJQUcrZlFUTE03SjAy?= =?utf-8?B?TEw3a1NGeE5VN2VkZWRZNG8zQUlUdVRMRnpiMlpza3lPYnU5Y0dWQ21peEFZ?= =?utf-8?B?MzkrWjQ3aE9tdlgyU0l5ck56a1ZBVHF2d3dodzZMR2Nuc3lzZkJCcnRvT0Vl?= =?utf-8?B?K3VSZmNWTzRZaVd1VG1ZcHNlaGJQQ1BOd2FFV2dxLzZIZXFaWFRPZmVTdXY1?= =?utf-8?B?ajJkRWt6QUkycmJVY3ZLMDBsRmQ1ck5Rdks1OGl0a0tJVENuVk5wYi9namhn?= =?utf-8?B?Uk1qRGZJUStjT1lIbG9UVlBVNTZFQTFwNGNFTzJpRzVySVI1VDJMVDFURElK?= =?utf-8?B?cmZBVkowZVNrUzRrQytSdzI5NUN2b3FMZ25DOFlCbi9tRXRBM1pTSzVzcjV5?= =?utf-8?B?ZnE2ZmxZRE9GWDZuNE54UFBIVHdyTWtLd2Jpd1BHaG1LdlkvcnA5dUp6Q2hs?= =?utf-8?B?c3ZSZEQzNnkyeHNoaDlISUpjTDdhdERtNWFQWkF4Tnk4YWR2ZmJuYWhDT3lx?= =?utf-8?B?L012bklZUGp3REtkOWxpRG1laTc4OXQ4WUxFU1J0UmVvVG9MQVEybTFaVDBI?= =?utf-8?B?QmQ3YjdMRnY5QnBEb1JpS0UzdlRJVkxlL2hITUkyV2xmWk1MeXJIaDRsL05F?= =?utf-8?B?eUFSNWYrazYrMk5seUtIUTdhdEZzVis4SmtwdG5YMzVDNnNueGFRN0lnUVBI?= =?utf-8?B?U1EwaDBRb2JwWnVlRDV0WTIrWGFyNGhCT3JIZWUzbC9BTVBaWjkyODg2T0o4?= =?utf-8?B?VjczUmlsVzVCV1hYZ3k4WVZEZHp0Zi9QYlhNTUpvbEN2SC9OdDI2SGxhcjFW?= =?utf-8?B?YVlud1FzQWJPbVZWaVU5T09oTmcrMFRBV25PTzl0S0RHSlpvME5OcmhHVkph?= =?utf-8?B?MW5MUFpqRGZpUk9JbnJycEdFVDhEU2FIM2JDVmFKUjhCQ3d2S3FhVTNVSVMz?= =?utf-8?B?V3o4andNTXZNeVhvbzdOREU4MjNVQ1pjTk1GTjNrYWFpYU8vdC9FbmprSm4y?= =?utf-8?B?SFdFMGU2V01kaTE5dWx4Mm9ZQ0VUcm5FclBnTTRRZjU3L21mVWYrYzFTays5?= =?utf-8?B?WXZaSVJTZlRMbGRwSHhDSDZrTXRQN0VaT2FsU0JCVUN5SndlMm40TVg3aW5B?= =?utf-8?Q?Ao85D5S5Ln4=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(376002)(396003)(366004)(199004)(189003)(32952001)(13464003)(71190400001)(68736007)(11346002)(81156014)(71200400001)(446003)(4001150100001)(55016002)(4326008)(8676002)(486006)(2906002)(81166006)(478600001)(105586002)(9686003)(80792005)(97736004)(2501003)(106356001)(6306002)(6436002)(229853002)(476003)(5024004)(6116002)(53546011)(186003)(99286004)(86362001)(6506007)(66066001)(102836004)(33656002)(110136005)(25786009)(7736002)(26005)(3846002)(316002)(8936002)(76176011)(14454004)(74316002)(305945005)(53936002)(54906003)(72206003)(256004)(6246003)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2582; H:BYAPR16MB2790.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: W1jOSeuN6O+YzebRJ0whXo5eoI0LBNzdPEO7nrMf5kzi00WSqH2s9x8DDMII0RR80eo+zPrrzcuwN3bOMVkmaUwlRRCrAVH+8U6poY6t98E8wLSHtHwIlMedOEPACc32uGR42LQkQqLyLkk6DNKxYa5C2ZtQEBYO96mEajiTxqIeg58U+zL5C4EJE5AupENRMPI6mCUwuMX98Xo3Ys5NutqawH+526QnEappbA/qzQHaqBvFpzOUHa95rHBY4HC03mCZgZMuBMbw1+8xdxGFFU53eCJmF6x9ctvPKxZ7LZjPC4WBhG0b9o2FZkMp2cErW+e4II2XA7v5VH2vc2Ctz0AQQjzIOK8vQ19gdJjshAQ2jERoSynFmTlRep1mf9J7le0eBig+mXaVlT/E3e8234W1hwF+g6s7L620KTSR/to= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3ff46bd5-726a-4bd8-0544-08d69242cdd6 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 06:08:13.7155 (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: BYAPR16MB2582 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.5 X-NAI-Spam-Version: 2.3.0.9418 : core <6482> : inlines <7017> : streams <1812986> : uri <2796044> Archived-At: Subject: Re: [Dots] Genart telechat review of draft-ietf-dots-requirements-18 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 06:08:39 -0000 SGkgUm9iZXJ0LA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFJvYmVydCBTcGFya3MgPHJqc3BhcmtzQG5vc3RydW0uY29tPg0KPiBT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE5IDg6NDcgUE0NCj4gVG86IGdlbi1hcnRA aWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMuYWxsQGlldGYub3Jn OyBpZXRmQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IEdlbmFydCB0ZWxlY2hh dCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOA0KPiANCj4gVGhpcyBl bWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3Qg Y2xpY2sgbGlua3Mgb3INCj4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0 aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0KPiBSZXZpZXdlcjog Um9iZXJ0IFNwYXJrcw0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KPiANCj4g SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdl bmVyYWwgQXJlYSBSZXZpZXcNCj4gVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1 bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHIGZvcg0KPiB0aGUgSUVURiBDaGFpci4g UGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3Ig QUQNCj4gYmVmb3JlIHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiBG b3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQo+IA0KPiA8aHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4NCj4gDQo+IERvY3VtZW50 OiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE4DQo+IFJldmlld2VyOiBSb2JlcnQgU3Bh cmtzDQo+IFJldmlldyBEYXRlOiAyMDE5LTAyLTEzDQo+IElFVEYgTEMgRW5kIERhdGU6IDIwMTgt MTEtMjMNCj4gSUVTRyBUZWxlY2hhdCBkYXRlOiAyMDE5LTAyLTIxDQo+IA0KPiBTdW1tYXJ5OiBS ZWFkeSwgYnV0IHdpdGggYSBwcm9jZXNzIGlzc3VlIGZvciB0aGUgc2hlcGhlcmQgYW5kIEFEIHRv IGNvbnNpZGVyLg0KPiANCj4gVGhpcyB2ZXJzaW9uIGFkZHJlc3NlZCBhbGwgb2YgbXkgY29tbWVu dHMgb24gdmVyc2lvbiAtMTYuIFRoYW5rIHlvdS4NCj4gDQo+IEhvd2V2ZXIsIHRoZSBkaWZmIHNo b3dzIHRoYXQgYSBsYXJnZSBudW1iZXIgb2YgU0hPVUxEcyB3ZXJlIGNoYW5nZWQgdG8NCj4gTVVT VHMuDQo+IEknbSBndWVzc2luZyB0aGF0IHdhcyBpbiByZXNwb25zZSB0byBhIGNvbW1lbnQgaW4g dGhlIFRTVkFSVCByZXZpZXcgb2YgLTE2Lg0KDQpZdXAuDQoNCj4gVGhpcyBsYXJnZSBzY2FsZSBz dWJzdGl0dXRpb24gbWFrZXMgbWUgd29ycnkgLSBhcmUgdGhleSByZWFsbHkgdGhlIHJpZ2h0DQo+ IGFkanVzdG1lbnRzPyBIYXMgdGhlIGdyb3VwIHJldmlld2VkIGFuZCBhZ3JlZWQgdG8gdGhlc2Ug bm9ybWF0aXZlIGNoYW5nZXM/DQoNClRoZSBXRyBoYXMgbm90IGlkZW50aWZpZWQgYW55IHF1YWxp ZnlpbmcgZXhjZXB0aW9uYWwgY29uZGl0aW9ucyBmb3IgdGhlc2UgcmVxdWlyZW1lbnRzIHdoZW4g dGhlIGRpc2N1c3NpbmcgdGhlIERPVFMgcHJvdG9jb2wgYW5kIHJlcXVpcmVtZW50cyBkcmFmdHMs IGhlbmNlIEkgdXBkYXRlZCANCnRoZXNlIHJlcXVpcmVtZW50cyB0byB1c2UgTVVTVC4NCg0KPiAN Cj4gQXMgYSBuaXQsIEknbGwgbm90ZSB0aGF0IHRoZSBhZGRpdGlvbmFsIGRlc2NyaXB0aW9uIG9m IGhlYXJ0YmVhdGluZyBjcmVlcHMgaW50bw0KPiBzcGVjaWZ5aW5nIHByb3RvY29sIHJhdGhlciB0 aGFuIHJlcXVpcmVtZW50cy4NCg0KVGhlIGFkZGl0aW9uYWwgdGV4dCBpbiBTSUctMDA0IGlzIGFk ZGVkIHRvIGp1c3RpZnkgdGhlIHJlYXNvbiBmb3IgdXNpbmcgIlNIT1VMRCIuDQoNCkNoZWVycywN Ci1UaXJ1IA0KDQo+IA0KDQo= From nobody Thu Feb 14 06:31:36 2019 Return-Path: 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 BFCC6130D7A; Thu, 14 Feb 2019 06:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 UoB5Y_y54yPR; Thu, 14 Feb 2019 06:31:29 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E223130F0E; Thu, 14 Feb 2019 06:31:29 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 440f334F7Fz10Mv; Thu, 14 Feb 2019 15:31:27 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 440f332wMNz8sYk; Thu, 14 Feb 2019 15:31:27 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([fe80::54f9:a664:e400:452a%21]) with mapi id 14.03.0435.000; Thu, 14 Feb 2019 15:31:27 +0100 From: To: Benjamin Kaduk , "draft-ietf-dots-data-channel@ietf.org" CC: "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUw7uwS7WKAanZdU6TcY0cXL4tAqXez8Yg Date: Thu, 14 Feb 2019 14:31:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> In-Reply-To: <20190213164622.GX56447@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 14:31:34 -0000 Hi Ben,=20 Thank you for the review.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 13 f=E9vrier 2019 17:46 > =C0=A0: draft-ietf-dots-data-channel@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: AD review of draft-ietf-dots-data-channel-25 >=20 > This is my AD review of the -25 >=20 > I see that Med made a commit on github that preemptively addressed at lea= st > one of these comments, but will trust the authors to do to the right thin= g > with anything in here that's stale. >=20 > A handful of generic and/or high-level comments before the > section-by-section nitty-gritty stuff. >=20 > The author count is large (7); RFC 7322 notes that the stream approver > (i.e., the IESG) will ask questions if the count is more than five. What > should I tell people when they ask? (The authors are listed also in the > YANG module itself, if changes are made.) [Med] Actually, the set of co-authors of the YANG module is not exactly the= same. Anyway, in order to comply with the rules and avoid spending extra cycles o= n this, we added a new section called "Contributing Authors". Nevertheless,= the set of authors is not modified in the YANG module. =20 >=20 > Can someone (the shepherd?) confirm that an automated syntax checker has > run over the JSON in examples? >=20 > The concept of "DOTS client domain" is being used for actual protocol > purposes here (most notably as a bound on the prefix(es) that a client ca= n > request mitigation for, but I don't remember seeing a formal definition f= or > how any DOTS actor would know the specific bounds of such a client domain= . > Is there text somewhere that I missed that we can point to, or will we ne= ed > to add some? [Med] Both "DOTS client domain" and "DOTS server domain" are used in the ar= chitecture draft. "DOTS client's domain" and "DOTS server's domain" are als= o used in the architecture and requirements I-D. If a formal definition is needed, I prefer this to be done in the architect= ure or the requirements I-D. >=20 > We don't say much about what validation the server does on input data, an= d > we probably should. For example, does the server need to validate 'cuid' [Med] We avoided to be redundant here. This is covered by this text:=20 "This attribute has the same meaning, syntax, and processing rules as the 'cuid' attribute defined in [I-D.ietf-dots-signal-channel]." > and/or 'cdid' in dots-client-creation requests? [Med] This is covered by this text:=20 "This attribute has the same meaning, syntax, and processing rules as the 'cdid' attribute defined in [I-D.ietf-dots-signal-channel]" And other parts in the text such as: If the request is received via a server-domain DOTS gateway, but the DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' is expected to be supplied, the DOTS server MUST reply with "403 Forbidden" status-line and the error-tag "access-denied". Upon receipt of this message, the DOTS client MUST register (Section 5). What about validating that > the (e.g.) ACL name in the PUT URL matching the name in the body of the > request? [Med] Those are supposed to be covered following RESTCONF base spec. =20 There are probably others as well. >=20 > The examples all use "Host: {host}:{port}" which is not really an example > but rather a template. Since they are supposed to be examples, we should > pick a concrete hostname (and port) to use. [Med] I will change some figures to "example.com" but will leave it for sch= ema-like figures.=20 >=20 > There is, shall we say, a "high degree of overlap" between Sections 5/6/7 > and the YANG model field descriptions. I mostly assume that the WG > considered letting the YANG model (and the core RESTCONF spec) stand alon= e > without the additional examples/specification of the use of RESTCONF to > manage clients, aliases, and filter rules, so I won't suggest that we > revisit the question. But I do think that it would be good to have some > explicit text acknowledging the overlap and stating which one is > authoritative. [Med] Fixed.=20 >=20 > There seems to be some mismatch between whether the IPv6 ACL subtree uses > "ttl" or "hoplimit" -- Figure 7 has "ttl" but the rest of the document > seems to (properly) use "hoplimit". Someone else should double-check the > relevant places, though, as I'm not sure I was looking at all of them wit= h > this issue in mind. [Med] Both are correct.=20 Figure 7 reuses draft-ietf-netmod-acl-model which defines TTL as :=20 leaf ttl { type uint8; description "This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be dropped. In IPv6, this field is known as the Hop Limit."; reference "RFC 791: Internet Protocol, RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; } For the other figures, the fields are defined in the data-channel draft. =20 >=20 > I'm also a bit curious about the use of an explicit "capabilities" tree f= or > fine-grained feature detection, as opposed to native YANG "feature"s. [Med] These are not serving the same purpose. Features are about parts of a= module which are conditional, if you will. Our "capabilities" branch is me= ant to retrieve the filtering match capabilities are supported/enabled by a= DOTS server. That information is used by a client to tweak its requests. The > latter would allow the relevant nodes to just not exist when unsupported, [Med] A filtering capability may be supported but not enabled. The server i= s free to include an explicit field with the appropriate status or not. Thi= s is implementation-specific.=20 > as opposed to the explicit-capabilities formulation where they exist but > are (presumably) ignored. (I don't remember us explictily saying that > they're ignored in this case, either; might be worth adding some text.) >=20 > In a similar vein, we include 'capabilities' nodes for a few matching > features that are listed as "mandatory fields" for ACL matching in Table = 1, > and thus whose value would always be "true". Why do we need the capabili= ty > leaves in such a case? [Med] I guess you are referring to Figure 23 which says the following: Figure 23 shows an example of a response received from a DOTS server which only supports the mandatory filtering criteria listed in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 4.1. The module allows to return other capabilities than those listed in table 1= .=20 >=20 > idnits notes a few references that can be updated along with the other > changes; it also flags a "reference in abstract" for the RFC Editor note > which we could probably ignore (but could probably also just remove the > brackets around the text in question). [Med] idnits confuses the note to the RFC editor with the abstract. Fixed, = anyway. >=20 > I also looked at the references (especially the normative/informative > split) and have a few suggestions: >=20 > - the IEEE.754.1985 reference is not needed; [Med] Agree, but it is not harmful to cite it either :-)=20 The reference is quoted to justify why we went with decimal64, not uint64 f= or example + why that unit is chosen. This allows to ease grafting DOTS wit= h BGP Flowspec for instance, which cites IEEE.754.1985 too.=20 we don't use the binary > floating-point encoding but rather a string one for YANG decimal64 > - I think that RFC 8499 (dnsop-terminology-bis) can wholly supersede our > usage of RFC 1983, so the 1983 cite can be dropped as well [Med] Done.=20 > - draft-ietf-dots-requirements (for terminology), [Med] For this one, we are following the same approach as for other termino= logy documents (e.g., RFC8340) that are listed as informative. I prefer to = leave it as informative for now. =20 RFC 7950, and RFC 8259 [Med] OK for these two.=20 > should probably all move to the normative section >=20 > Section 1 >=20 > The sub-bullet point about "If a network resource ... informs its servici= ng > DOTS gateway of all suspect IP addresses that need to be drop- or > accept-listed ..." made me wonder if that was more of a signal-channel > activity or a data-channel one. Perhaps this is just a matter of the tex= t > not being as clear as it could be.=20 [Med] The point is that a client is not sure that an attack is active and t= argeting the client domain but it wants to enforce some preventive actions = during an investigation period. For example, this can be triggered by an ad= ministrator who is informed that an attack is currently targeting other net= works, but its network is likely to be subject to that attack too. Other pr= eventive actions which require further investigation may be considered. =20 I changed the text as follows:=20 OLD: detects a potential DDoS attack from NEW is informed about a potential DDoS attack from=20 (I also wonder if we should say > "further investigation" since we don't really have an automated way to > indicate that yet.) >=20 > Section 2 >=20 > When we talk about tree diagrams, should we also say something like "Note > that the full module's tree has been split across several figures to aid > the exposition of the various sub-trees"? [Med] Done. Thanks.=20 >=20 > Section 3.1 >=20 > When we talk about using GET to retrieve running configuration, do we wan= t > to note that since the data channel can fail during attack time, it's > expected to be common to perform such a GET before attempting to make > modifications to configuration? [Med] The data channel is supposed to be invoked when no attack is ongoing.= Normal RESTCONF operations are therefore followed. I don't see the need to= add a note.=20 >=20 > A DOTS client registers itself to its DOTS server(s) in order to set > up DOTS data channel-related configuration data and receive state > data (i.e., non-configuration data) from the DOTS server(s) > (Section 5). Mutual authentication and coupling of signal and data > channels are specified in [I-D.ietf-dots-signal-channel]. >=20 > I think we should split the "mutual authentication" and "coupling of sign= al > and data channels" into their own sentence, and flesh them out slightly > more. So, section references to Sections 8 and 4.4.1, respectively, the > usage of TLS client certificates, the coupling of channels via the client= 's > identity ('cuid' and 'cdid'), etc. [Med] Done.=20 >=20 > A TLS heartbeat [RFC6520] verifies > that the DOTS server still has TLS state by returning a TLS message. >=20 > I expect this will get some pointed comments during IETF LC, given the > recent-ish IETF-wide discussions about heartbeats/keepalives in general. > Is there perhaps a RESTCONF-level probe message that could be used to che= ck > liveliness; a capabilities query perhaps? [Med] There is no such mechanism. The approach in the data channel draft is= aligned with RFC8071 for keepalives. >=20 > A DOTS server may detect conflicting filtering requests from distinct > DOTS clients which belong to the same domain. For example, a DOTS > client could request to drop-list a prefix by specifying the source > prefix, while another DOTS client could request to accept-list that > same source prefix, but both having the same destination prefix. It > is out of scope of this specification to recommend the behavior to > follow for handling conflicting requests (e.g., reject all, reject > the new request, notify an administrator for validation). DOTS > servers SHOULD support a configuration parameter to indicate the > behavior to follow when a conflict is detected. Section 7.2 > specifies the behavior when no instruction is supplied to a DOTS > server. >=20 > I'm a bit confused by the "out of scope of this specification to recommen= d > the behavior to follow for handling conflicting requests", since not only > does the last sentence of the paragraph give a pointer to a specified > behavior in case of conflicts, but we also mention it in a couple other > places (e.g., the bottom of page 43). [Med] The specified behavior is a default behavior, not a recommended one. I update this text:=20 If the request is conflicting with an existing filtering installed by another DOTS client of the domain, and absent any local policy, the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =20 DOTS server returns "409 Conflict" status-line to the requesting DOTS client. The error-tag "resource-denied" is used in this case. >=20 > Also in that paragraph, it's unclear that a 2119 SHOULD is appropriate fo= r > "support a configuration parameter"; there's no interoperability > considerations for having or not having such a configuration knob. [Med] This is important for interoperability (or at least for ensuring a de= terministic behavior). E.g., during service subscription a technical clause= may be negotiated out of band how to deal with conflicts from clients of t= he same domain.=20 >=20 > Section 3.3 NAT Considerations have "high overlap" with the > text at the end of the signal-channel's "Design Overview". At a minimum = we > should diff them and enforce convergence, but do we want to consider just > having one refer to the other? [Med] Makes sense. Section 3.3 is now deleted and replaced with this NEW te= xt: NAT considerations for the DOTS data channel are similar to those discussed in Section 3 of [I-D.ietf-dots-signal-channel]. >=20 > Section 3.5 >=20 > I had to read up on RESTCONF and NETCONF while reviewing this, but from > what I've seen so far, the "error-severity" field is only present in > NETCONF and not RESTCONF. If so, then we shouldn't need to talk about it > here, since we use RESTCONF exclusively. I also couldn't find whether > there's a registry that we should add the "loop-detected" error-tag to. > Can anyone here help me out? >=20 [Med] We used the template in https://tools.ietf.org/html/rfc6241#appendix-= A because the errors in 8040 are the ones imported from there.=20 There is no registry for the errors; only a YANG module which is not mainta= ined by IANA. This is why no action is included in the IANA section.=20 > Section 4.2 >=20 > Is there any plan/expectation for filtering/match rules for QUIC? It is > probably premature to put anything in this document specifically, but sti= ll > worth thinking about. [Med] Some of the existing fields can be already reused for QUIC (UDP, port= number). There are few fields in the QUIC public header that are available= (public flags, CID, version). A match on the first N bytes of the UDP payl= oad can be considered but I do think this is not mature enough.=20 The key point is that our module is extensible.=20 >=20 > The order in which the leaves appear in the "capabilities/ipv6" and > "capabilities/tcp" subtrees do not match the order they appear in the ACL > subtree itself; it would be good to keep the order consistent. [Med] Fixed.=20 FWIW, the order in capabilities/* follows the order of the fields as they a= ppear in the header. We don't have a control on the ACL order because we ar= e reusing an external module. =20 >=20 > We don't really say much about what the semantis of the "port-range" > capabilities are; is that supposed to indicate any port-matching ability = at > all, or specifically the low-to-high range matching, or also the "operato= r" > options? [Med] Updated as follows:=20 OLD: "Support of filtering based on a port range."; NEW: "Support of filtering based on a port range. This includes filtering based on a source port range, destination port range, or both. All operators (i.e, less than or equal, greater than or equal, equal to, and not equal to) are supported."; >=20 > Section 4.3 >=20 > We define an "operator" typedef that is rather different from that from > netmod-acl-model. Do we want to use a different name to aid > disambiguation? ("bitmask-operator" comes to mind as an option.) [Med] It is not recommended in yang to use prefixes to disambiguate nodes. = The disambiguation is ensured by the context/position in the tree. For exam= ple, this is why we are using name and not acl-name or ace-name, etc. I wil= l leave the text as it is.=20 >=20 > typedef fragment-type { > type bits { > bit df { > position 0; > description > "Don't fragment bit for IPv4. > This bit must be set to 0 for IPv6."; >=20 > Set to zero by whom? What should the receiver do if it is set otherwise? >=20 [Med] In IPv6, fragmentation is only done by the source. Hence, this value = for IPv6. A fragment-type with the first bit set will be discarded by the s= erver. =20 > What are the semantics if (either or both of target-fqdn and target-uri) > and target-prefix are specified? (I suppose maybe this could be covered = in > Section 6.1 when we say that at least one is required in ACL-creation > requests.) [Med] The resulting IP prefixes/addresses will be bound to the alias. Added= the following in Section 6.1: If more target-* clauses (e.g., 'target-prefix' and 'target-fqdn') are included in a POST or PUT request, the DOTS server binds all resulting IP addresses/prefixes to the same resource. >=20 > The units for the "rate-limit" node should be specified in the YANG modul= e > and not in the description of how to install filtering rules. [Med] Added "units" to the YANG module. >=20 > list dots-client { > key "cuid"; > description > "List of DOTS clients."; > leaf cuid { > type string; > description > "A unique identifier that is randomly generated by > a DOTS client to prevent request collisions."; >=20 > I don't think "randomly generated" is really correct here. [Med] Changed to:=20 "A unique identifier that is generated by a DOTS client to prevent request collisions."; >=20 > The "capabilities/icmp/rest-of-header" description should be more clear > that (per draft-ietf-netmod-acl-model) it is supposed to match both the > ICMP four-byte field and the ICMPv6 message body. [Med] OK. >=20 > Section 5.1 >=20 > It may be worth reiterating that (per the signal-channel doc) gateways ma= y > rewrite the 'cuid'. [Med] OK:=20 As a reminder, DOTS gateways may rewrite the 'cuid' used by peer DOTS clients (Section 4.4.1 of [I-D.ietf-dots-signal-channel]). >=20 > When POST is used to create a dots-client resource, how does the client > know the path of the created resource (to be used for subsequent RESTCONF > requests)? (I assume it is supposed to just use the submitted 'cuid', bu= t > we need to explicitly say this. This also seems to render much of the > distinction between POST and PUT moot, for our usage, though I do not > propose any change to the text.) [Med] The procedure to determine the root path is recalled in Section 3.1, = then normal RESTCONF operation is followed. >=20 > The DOTS gateway, that inserted a 'cdid' in a PUT request, MUST strip > the 'cdid' parameter in the corresponding response before forwarding > the response to the DOTS client. >=20 > Why does this apply only to PUT and not POST? [Med] Because RFC8040 says the following:=20 If the POST method succeeds, a "201 Created" status-line is returned and there is no response message-body. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20 >=20 > Section 6.1 >=20 > DOTS clients within the same domain can create different aliases for > the same resource. >=20 > My reading of this text is that client A can create alias "foo" for IP > prefix 128.0.1.5/31 and clinet B can create alias "bar" for the same IP > prefix, and that DOTS supports that process. (Just to confirm that the > text is saying what it's intended to.) [Med] Yes. I do wonder if we want to say > something about whether alias names need only be unique per 'cuid' or in > some more global fashion. (Having a global uniqueness property is perhap= s > convenient in order to interface with non-DOTS mechanisms for querying > aliases, or for the DOTS server to interact with network filtering > appliances.) [Med] The specification does require uniqueness per cuid:=20 | +--rw aliases | | +--rw alias* [name] | | +--rw name string We don't have a requirement for uniqueness per domain or globally.=20 If such requirement arise, the semantic/logic for creating those aliases ca= n be handled out of band.=20 >=20 > Figure 16 puts double-quotes around "string" in the pseudo-schema, which > feels weird to me. [Med] This is also what we have done for other figures , e.g., 11. The inte= nt is to use a scheme-like message body while trying to preserve JSON compl= iance. =20 >=20 > target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An > FQDN is the full name of a resource, rather than just its > hostname. For example, "venera" is a hostname, and > "venera.isi.edu" is an FQDN [RFC1983]. Refer to > [I-D.ietf-dnsop-terminology-bis] for more details. >=20 > I don't think this text is particularly well-aligned with RFC 8499 and > would suggest trimming it substantially and just pointing to that RFC. [Med] Done.=20 >=20 > If the request is missing a mandatory attribute or its contains an > invalid or unknown parameter, "400 Bad Request" status-line MUST be > returned by the DOTS server. The error-tag is set to "missing- > attribute", "invalid-value", or "unknown-element" as a function of > the encountered error. >=20 > This text seems to preclude any future extension that adds new error tags= ; > is this intended? [Med] Those errors are only about the tree failure cases called in the firs= t sentence.=20 >=20 > Section 7.1 >=20 > A DOTS client which issued a GET request to retrieve the filtering > capabilities supported by its DOTS server, SHOULD NOT request for > filtering actions that are not supported by that DOTS server. >=20 > What is the server behavior if the client ignores this SHOULD NOT? [Med] This is covered by this text:=20 If the request is missing a mandatory attribute or contains an invalid or unknown parameter (e.g., a match field not supported by the DOTS server), "400 Bad Request" status-line MUST be returned by the DOTS server in the response.=20 >=20 > Figure 23 shows an example of a response received from a DOTS server > which only supports the mandatory filtering criteria listed in > Section 4.1. >=20 > This seems inaccurate, as the mandatory filtering criteria exlude the > rate-limit among others. [Med] rate-limit is an action, not a filtering criteria.=20 >=20 > Section 7.2 >=20 > activation-type: Indicates whether an ACL has to be activated > (immediately or during mitigation time) or instantiated without > being activated (deactivated). Deactivated ACLs can be activated > using a variety of means such as manual configuration on a DOTS > server or using the DOTS data channel. >=20 > Is this done by the data channel or the signal channel? [Med] Yes, but this is not supported in the base signal-channel spec. This = is the done using the filtering control feature (draft-nishizuka-dots-signa= l-control-filtering). This is why signal channel is not listed after "such = as".=20 >=20 > If this attribute is not provided, the DOTS server MUST use > 'activate-when-mitigating' as default value. >=20 > Why do we specify default values here instead of in the YANG module? [Med] There is no default statement for enumeration. To solve this, a new t= ype is defined in the module (activation-type). This type is then used for = the activation-type leaf with a default value set to activate-when-mitigati= ng.=20 The change in tree diagram is (no need to insert the code here): OLD: | +--rw activation-type? Enumeration NEW: | +--rw activation-type? activation-type >=20 > Filters that are activated only when a mitigation is in progress > MUST be bound to the DOTS client which created the filtering rule. >=20 > Other filters do not need to be bound to the DOTS client that created the= m? [Med] They are...but those filters are already enforced because they are im= mediate.=20 > Wouldn't we still want to remove them when the dots-client resource in > question is deleted? [Med] This is supposed to be done by the client itself. For amnesiac client= s, we do have the following:=20 In order to avoid stale entries, a lifetime is associated with alias and filtering entries created by DOTS clients. Also, DOTS servers may track the inactivity timeout of DOTS clients to detect stale entries. >=20 > destination-ipv4-network: The destination IPv4 prefix. DOTS servers > [...] > This is a mandatory attribute in requests with an 'activation- > type' set to 'immediate'. >=20 > I somehow thought there were YANG attributes that could indicate this > conditional requirement in the module itself, though I am hardly a YANG > expert. [Med] We are reusing fields from ietf-netmod-acl, it is not easy to manipul= ate the fields as we would want. >=20 > The error-tag is set to > "missing-attribute", "invalid-value", or "unknown-element" as a > function of the encountered error. >=20 > Same comment as above about (non-)extensibility. [Med] Idem as above. >=20 > Section 7.3 >=20 > I see that the "test-acl-*" and "test-ace-*" acl and ace objects in these > examples do in fact use different names for the semantically different > objects, but perhaps we could help the reader's eye and use strings with = a > larger Hamming distance? (I thought they were all the same on my first > read.) [Med] Fixed.=20 >=20 > (I also am a little confused at why the "ace" "name" field is considered = a > non-config field, in Figure 31, but this seems more likely to be my > confusion than an error in the document.) [Med] This is because the name is the key of the ace list.=20 RFC8040 says the following:=20 To retrieve only the non-configuration child resources, the "content" parameter is set to "nonconfig". Note that configuration ancestors (if any) and list key leafs (if any) are also returned. >=20 > Section 8 >=20 > o DOTS server MUST NOT enable both DOTS data channel and direct > configuration to avoid race conditions and inconsistent > configurations arising from simultaneous updates from multiple > sources. >=20 > o DOTS agents SHOULD enable DOTS data channel to configure aliases > and ACLs, and only use direct configuration as a stop-gap > mechanism to test DOTS signal channel with aliases and ACLs. > Further, direct configuration SHOULD only be used when the on-path > DOTS agents are within the same domain. >=20 > Doesn't all this discussion of "direct configuration" conflict with the > "MUST NOT" in the first bullet point? [Med] The second bullet is about controlled testing of the *signal channel*= with aliases/acls communicated by the data channel. >=20 > Section 10 >=20 > Generally with the security considerations template for YANG modules, we > need to list out all the nodes considered sensitive and the consequences = of > writing(/reading) each one in turn. >=20 [Med] The text does already call out those that are specific to this docume= nt. For other nodes, we do have this text:=20 "YANG ACL-specific security considerations are discussed in [I-D.ietf-netmod-acl-model]." I think we are OK.=20 From nobody Thu Feb 14 06:37:02 2019 Return-Path: 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 D089B130F0E; Thu, 14 Feb 2019 06:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7OzZIvCej6DI; Thu, 14 Feb 2019 06:36:57 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BC7130D7A; Thu, 14 Feb 2019 06:36:57 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 440f9N0tq2z2y22; Thu, 14 Feb 2019 15:36:56 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 440f9M711NzBrLs; Thu, 14 Feb 2019 15:36:55 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([fe80::393d:418c:3f1d:991d%21]) with mapi id 14.03.0435.000; Thu, 14 Feb 2019 15:36:55 +0100 From: To: Benjamin Kaduk , Roman Danyliw CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUw8UDWHs4kATxxUerfdSNDWB7qqXfXJwg Date: Thu, 14 Feb 2019 14:36:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1F061@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <359EC4B99E040048A7131E0F4E113AFC01857C1DEB@marathon> <20190213175309.GA56447@kduck.mit.edu> In-Reply-To: <20190213175309.GA56447@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 14:37:00 -0000 Hi Roman, all,=20 The use of integer (not "integer") and "string" (not string) is on purpose = because these examples are depicting the schema. I update the text to clearly indicate schema examples.=20 Hope this is OK. Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 13 f=E9vrier 2019 18:53 > =C0=A0: Roman Danyliw > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > Objet=A0: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 >=20 > On Wed, Feb 13, 2019 at 05:35:01PM +0000, Roman Danyliw wrote: > > Hi Ben and Data Channel Authors! > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Benjamin Kaduk > > > Sent: Wednesday, February 13, 2019 11:46 AM > > > To: draft-ietf-dots-data-channel@ietf.org > > > Cc: dots@ietf.org > > > Subject: [Dots] AD review of draft-ietf-dots-data-channel-25 > > > > > This is my AD review of the -25 > > > > [snip] > > > > > Can someone (the shepherd?) confirm that an automated syntax checker > > > has run over the JSON in examples? > > > > I'm the shepherd. I validated the YANG in Section 4.3, but forgot to d= o > the JSON. I just ran the JSON in Figures 11, 12, 13, 14, 16, 17, 19, 23,= 24, > 25, 27, 29, and 31 through https://jsonlint.com/. All but Figure 16 came > back fine. > > > > Per Figure 16, the following edit is necessary (i.e., add a quote aroun= d > integer, s/integer/"integer"/) >=20 > Hmm, that one is I think supposed to be more schema-like than example-lik= e, > so I actually was arguing to remove the quotes around "string" [and thus > make the validator complain even more]. >=20 > Thanks for checking! >=20 > -Ben >=20 > > OLD > > "target-port-range": [ > > { > > "lower-port": integer, > > "upper-port": integer > > } > > ], > > "target-protocol": [ > > integer > > ], > > NEW > > "target-port-range": [ > > { > > "lower-port": "integer", > > "upper-port": "integer" > > } > > ], > > "target-protocol": [ > > "integer" > > ], > > > > Roman From nobody Thu Feb 14 11:17:20 2019 Return-Path: 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 9389D1200ED; Thu, 14 Feb 2019 11:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 T-AkeEv6N5T5; Thu, 14 Feb 2019 11:17:15 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760139.outbound.protection.outlook.com [40.107.76.139]) (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 1E7511289FA; Thu, 14 Feb 2019 11:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uu/AM9HH6UV+gJG3qi5gYUQAm6+fSz+G6PRHW/1clS8=; b=K28c+SJwXsx7XArITIYP0p7wyWbRG6t6cTXxQC3lh9t/kRKcrwm+wCw60QpyxMlj1EJr4V9EoQ6YiwR8IfmqdncYLMmZ7KvCNCbutmT3tw/wf+nEqbEb7XrMhpD/9KC0wHaZk5jofSHBzFs8BMeVs2wGjUdtL7k+JiJRp4Rpp4g= Received: from SN2PR01CA0009.prod.exchangelabs.com (2603:10b6:804:2::19) by BL0PR01MB4852.prod.exchangelabs.com (2603:10b6:208:7e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 19:17:12 +0000 Received: from BY2NAM03FT004.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::203) by SN2PR01CA0009.outlook.office365.com (2603:10b6:804:2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Thu, 14 Feb 2019 19:17:12 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT004.mail.protection.outlook.com (10.152.84.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Thu, 14 Feb 2019 19:17:11 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1EJH76t012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Feb 2019 14:17:10 -0500 Date: Thu, 14 Feb 2019 13:17:07 -0600 From: Benjamin Kaduk To: CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190214191707.GM56447@kduck.mit.edu> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(396003)(346002)(2980300002)(199004)(189003)(51444003)(51914003)(52314003)(55784004)(47776003)(478600001)(6916009)(50466002)(6666004)(356004)(8676002)(104016004)(4326008)(8936002)(229853002)(14444005)(86362001)(26826003)(6246003)(966005)(30864003)(486006)(53416004)(186003)(2870700001)(75432002)(33656002)(88552002)(23756003)(246002)(476003)(106466001)(7696005)(956004)(305945005)(126002)(55016002)(11346002)(6306002)(2351001)(76176011)(336012)(66574012)(1076003)(36906005)(58126008)(786003)(316002)(426003)(2906002)(26005)(53946003)(446003)(106002)(54906003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4852; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT004; 1:VVNV/60YQ0B8TZSONFvlH2df0S0712r7T6hcPBaSbQO2+fGdzJ8WWvjiybi99UvV4t/1WWpwCC6lm/Wsy9PK/aOBmQFPawjFiw1NW8MC2/dVcFrjQagoY0LyPAAufqJX9q0rs8cLSmts/uJZb8Dtrp97s/L5ALagws+aXygOyiQ= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d9339e44-f840-4010-ac75-08d692b105cf X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:BL0PR01MB4852; X-MS-TrafficTypeDiagnostic: BL0PR01MB4852: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4852; 20:umwnIGxtfv3Ytd0e9Zz4zy7aMGJ4k0z5dzEvP89fFk+UXpclWSnXPfiAs1BTdnncxNHmH3PNoar1O7VA2u+D2tQtYZrXocsyc5CHtpXD8B+qHXuinDwr0QqFxvRpxQ6btFkYh3LfiBHbux0uMDtpdR1ZmcMK7/uEZl8g5rBYSv6IZ3u5qIlrZfXSNA24eo0Xe3etA+eGsIeJQpJDRWQ+YDIA6RhfDkiMBD1FXa7KjfSR9qsgXJi6LFzPdp+qF/OM8i5UQ7RL9R24/kfOjghw2m7o9v9KWfD1ehbto5fjmFxrZehhiXmYCPHuQjrGZ0QlK2giK4z9LOf1kVbeVlIFxEpuH4XsMGppFFm/gP4FV7q/IqOEqC2X0u971FwuzGzNO1dq8hk3tIFTHsN4UtHYxAUX0CTrROGiqQqOntM0veZjy/7/evGMTrcOs31HMNfARlFCKwrS6YWseYU6gYh6qmRgGIbX8C88ZDAbTHXddjxNvFJ7XAXCqXTBvS34BxwEyavJvahMoLfVaokgcyINhp3pXpR8v61IsBMG2lyXAnF5CdGff3KBXGsIK92ltIKlIN7O1NS1lXG0XVqnP2cwnap6JBdTTo6Wtk/kxUAW5t4= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09480768F8 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BL0PR01MB4852; 23:jzdv/04aRxk95qsxLPrc8WNWh5gG5tt5iTgv0Uc?= =?iso-8859-1?Q?7Sf8sHqt1zA0jTKrgSX14QKIqamBj5DO5snaGBAjFpsfQ3aAYNVBCbajkr?= =?iso-8859-1?Q?jjhB3pVs/A/JlQ7mkqLSfpQvTySq90pGtWs9uW3nSmDyWgE7EQbSfsPza1?= =?iso-8859-1?Q?YBJk5CXzyi0GJ9vxXEVDPKNNZB8n1ZTo2z6Tek1nR2FP7x+PvH16nwInPo?= =?iso-8859-1?Q?wSGoMrjKvmDTYFoeT6aLYLlms527vsSQgQk9PnrOE8KIcpO0EfZWGTKNiL?= =?iso-8859-1?Q?oGzNFYRp3UD0Bn/nSLwmDqpYEwLb0K588VsfCGeJarwvrCkyjYdxTYT7Rv?= =?iso-8859-1?Q?K55yPUL9Qoy4hLBc5VlDD8C5Vklwb63lXKHumOGjutbt0s0ZDNQ2odDVlk?= =?iso-8859-1?Q?+Sxf8K2x0SFwttGeJ0HT/T4S9Fi7f/qP8Y4qR+PhdkLE2tX8AAVfen8+0f?= =?iso-8859-1?Q?EfYbzL7wNgkl4RDMGnIS0MRQ6A9pptwx0IDFyzZZwEqdQplJVsUvPPlcfa?= =?iso-8859-1?Q?2B0FVoG+5mDTfq72LZQk+Zmj4GPChG0kYK7M94FeQUtFFhZVpnO1Rm7DNC?= =?iso-8859-1?Q?8BQ4z9lg5/WjMg8YCVmiTIdzZf20gYd/PT1yunPxikPxZ5+wpd2GyPXBM3?= =?iso-8859-1?Q?ZnmJUSI5DaZByYh/sKwVrZwuj4dDGl0/vOozJA3NTFLJdiIK5OIM067Ydh?= =?iso-8859-1?Q?eBxufd5Vb9ZO5gncFoNRW0aAc7lmSshVJgZlXxOonQP39KLsYL5OAhgJbg?= =?iso-8859-1?Q?gr31uOsRRfmKvGrOCJqp1NhS/SKUvgKxwGKPWsbon+Tk03edhJIHLjSq6q?= =?iso-8859-1?Q?USRTFPLLMNk3IuEwyaOZEJyxlbXUQHDmt1yhWtQusyaE+73MF2GFfGUOVL?= =?iso-8859-1?Q?xPpeIpR+Bbwl4o70B5MDaBe1jF/1fbLC8PBijFEwnKQ9kwT9RVkYqzG2Cp?= =?iso-8859-1?Q?V69HW38lhqc/VeVOjEWo3zirD7SBe2+h8jLmhHGfOevXNyx7RTMeDSd2Po?= =?iso-8859-1?Q?oJ10Q7pIZKy6hK3TLxFek2l8aY4EfCyEjcm7PQR7ciwp9hFeywrXZH32ZM?= =?iso-8859-1?Q?npnRBQKZn/6/7/ymV/BvzOLADqaBnENCdksJH3P50/MIV4IszeK7gFGP0i?= =?iso-8859-1?Q?VWaqhVdmqWCKMjUMUFHHdwIF8ICkAa7HG76yJNRzVi4KnBojNKvVVabHty?= =?iso-8859-1?Q?gzIKxGTJCDXebK6L8IvC5n/uMqbqF4VXrs72pA78G94C82UPGvO7UEWw3w?= =?iso-8859-1?Q?AiOz16HUaWG+GmngPcs5/w7sPhRjSpEvTUwfcGexkZGa2TV2+4GeOwotHP?= =?iso-8859-1?Q?0ipDBPoudz72C4pLdP+2s/RAn/yVdfTPNfSlfyiR7D2oIglzW0pVAEh7LU?= =?iso-8859-1?Q?gao6UG8F1cOVsezJYghR7A2XoOQeZ44Xk1m8ecbR4uNhKoP4eI4BHSQHo2?= =?iso-8859-1?Q?yl1EKJL07tuua0=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: kcbhH6JKFqTS95NLVzwzi5bKouemKHHuJRm2gPiuHMIPuahZHtW6N2bhVkGr1Yy8opcCpZyi1rQeKRsyPMakiEds3Q5L8mKoHKZIpldT7sDml9uneg/b0x4PLBn4U/h86Ogb+I830XHQJken85E3mGntbM/VWps1IzwCh3akUB4ubg4drW9UzaYpUrK3LWE2o2wHCkM+S80S6GNIV0xVjPSVSvHxjBNBEZE9CVl+GL/5tNfZdYrDbqtQrW+SrZWNWlDAwbcxjwMwAzhIsLyPCgfzK3SWM05t76BmuEafTM8gw+rykiWWCfUNLovbBlLW/VLPJhKUsgUkZHsCoUGP4UK91CMeonHXWnXOBwCtW8Ca/dgnMB/mK3plmvUIzJNympVMPdOAlaSOliYXHI6JFGYfdcD7MdAoCk8RXY+6jLY= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2019 19:17:11.8502 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d9339e44-f840-4010-ac75-08d692b105cf X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4852 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:17:20 -0000 Hi Med, On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : mercredi 13 février 2019 17:46 > > À : draft-ietf-dots-data-channel@ietf.org > > Cc : dots@ietf.org > > Objet : AD review of draft-ietf-dots-data-channel-25 > > > > This is my AD review of the -25 > > > > I see that Med made a commit on github that preemptively addressed at least > > one of these comments, but will trust the authors to do to the right thing > > with anything in here that's stale. > > > > A handful of generic and/or high-level comments before the > > section-by-section nitty-gritty stuff. > > > > The author count is large (7); RFC 7322 notes that the stream approver > > (i.e., the IESG) will ask questions if the count is more than five. What > > should I tell people when they ask? (The authors are listed also in the > > YANG module itself, if changes are made.) > > [Med] Actually, the set of co-authors of the YANG module is not exactly the same. Whoops, my bad for not checking. > Anyway, in order to comply with the rules and avoid spending extra cycles on this, we added a new section called "Contributing Authors". Nevertheless, the set of authors is not modified in the YANG module. Thanks. (To be clear, I'm happy to go to bat for everyone with the IESG for this sort of thing, I just need an argument to present that's not me making things up.) I don't know of a specific policy for YANG module authorship, so that part should be okay as far as I know. > > > > Can someone (the shepherd?) confirm that an automated syntax checker has > > run over the JSON in examples? > > > > The concept of "DOTS client domain" is being used for actual protocol > > purposes here (most notably as a bound on the prefix(es) that a client can > > request mitigation for, but I don't remember seeing a formal definition for > > how any DOTS actor would know the specific bounds of such a client domain. > > Is there text somewhere that I missed that we can point to, or will we need > > to add some? > > [Med] Both "DOTS client domain" and "DOTS server domain" are used in the architecture draft. "DOTS client's domain" and "DOTS server's domain" are also used in the architecture and requirements I-D. > > If a formal definition is needed, I prefer this to be done in the architecture or the requirements I-D. I think it would be a somewhat better fit in the architecture document, just to note that the "domain" is something that can concretely be demarcated by IP addresses/prefixes (as opposed to a more nebulous concept to aid conceptual understanding). > > > > We don't say much about what validation the server does on input data, and > > we probably should. For example, does the server need to validate 'cuid' > > [Med] We avoided to be redundant here. This is covered by this text: > > "This attribute has the same > meaning, syntax, and processing rules as the 'cuid' attribute > defined in [I-D.ietf-dots-signal-channel]." > > > and/or 'cdid' in dots-client-creation requests? > > [Med] This is covered by this text: > > "This attribute has the same meaning, syntax, and processing > rules as the 'cdid' attribute defined in > [I-D.ietf-dots-signal-channel]" I guess I'm mostly just concerned about if there's anything that doesn't translate directly, since the CoAP and HTTP constructs would have to describe the formal validation in somewhat different terms (i.e., for consistency between URL paths and message bodies). But in general I'm happy to avoid redundancy as you desire. > And other parts in the text such as: > > If the request is received via a server-domain DOTS gateway, but the > DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' > is expected to be supplied, the DOTS server MUST reply with "403 > Forbidden" status-line and the error-tag "access-denied". Upon > receipt of this message, the DOTS client MUST register (Section 5). > > > What about validating that > > the (e.g.) ACL name in the PUT URL matching the name in the body of the > > request? > > [Med] Those are supposed to be covered following RESTCONF base spec. Is this supposed to be RFC 8040 Section 3.5.3? I am not sure that I'm reading that as covering the property I want (and will double-check if you confirm that's what you have in mind). > There are probably others as well. > > > > The examples all use "Host: {host}:{port}" which is not really an example > > but rather a template. Since they are supposed to be examples, we should > > pick a concrete hostname (and port) to use. > > [Med] I will change some figures to "example.com" but will leave it for schema-like figures. Of course. > > > > There is, shall we say, a "high degree of overlap" between Sections 5/6/7 > > and the YANG model field descriptions. I mostly assume that the WG > > considered letting the YANG model (and the core RESTCONF spec) stand alone > > without the additional examples/specification of the use of RESTCONF to > > manage clients, aliases, and filter rules, so I won't suggest that we > > revisit the question. But I do think that it would be good to have some > > explicit text acknowledging the overlap and stating which one is > > authoritative. > > [Med] Fixed. > > > > > There seems to be some mismatch between whether the IPv6 ACL subtree uses > > "ttl" or "hoplimit" -- Figure 7 has "ttl" but the rest of the document > > seems to (properly) use "hoplimit". Someone else should double-check the > > relevant places, though, as I'm not sure I was looking at all of them with > > this issue in mind. > > [Med] Both are correct. > > Figure 7 reuses draft-ietf-netmod-acl-model which defines TTL as : > > leaf ttl { > type uint8; > description > "This field indicates the maximum time the datagram is allowed > to remain in the internet system. If this field contains the > value zero, then the datagram must be dropped. > > In IPv6, this field is known as the Hop Limit."; > reference > "RFC 791: Internet Protocol, > RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; > } > > For the other figures, the fields are defined in the data-channel draft. Ah, thanks for the pointer. > > > > I'm also a bit curious about the use of an explicit "capabilities" tree for > > fine-grained feature detection, as opposed to native YANG "feature"s. > > [Med] These are not serving the same purpose. Features are about parts of a module which are conditional, if you will. Our "capabilities" branch is meant to retrieve the filtering match capabilities are supported/enabled by a DOTS server. That information is used by a client to tweak its requests. > > The > > latter would allow the relevant nodes to just not exist when unsupported, > > [Med] A filtering capability may be supported but not enabled. The server is free to include an explicit field with the appropriate status or not. This is implementation-specific. Thanks for the explanation. > > as opposed to the explicit-capabilities formulation where they exist but > > are (presumably) ignored. (I don't remember us explictily saying that > > they're ignored in this case, either; might be worth adding some text.) > > > > In a similar vein, we include 'capabilities' nodes for a few matching > > features that are listed as "mandatory fields" for ACL matching in Table 1, > > and thus whose value would always be "true". Why do we need the capability > > leaves in such a case? > > [Med] I guess you are referring to Figure 23 which says the following: > > Figure 23 shows an example of a response received from a DOTS server > which only supports the mandatory filtering criteria listed in > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Section 4.1. Correct. > The module allows to return other capabilities than those listed in table 1. Yes. But the figure should not claim to be an example that *only* supports the mandatory parts, when it shows an example that supports additional capabilities than the mandatory ones. > > > > idnits notes a few references that can be updated along with the other > > changes; it also flags a "reference in abstract" for the RFC Editor note > > which we could probably ignore (but could probably also just remove the > > brackets around the text in question). > > [Med] idnits confuses the note to the RFC editor with the abstract. Fixed, anyway. > > > > > I also looked at the references (especially the normative/informative > > split) and have a few suggestions: > > > > - the IEEE.754.1985 reference is not needed; > > [Med] Agree, but it is not harmful to cite it either :-) My personal opinion is that it *is* harmful, since we are not using a floating-point wire encoding; we're using a string encoding. > The reference is quoted to justify why we went with decimal64, not uint64 for example + why that unit is chosen. This allows to ease grafting DOTS with BGP Flowspec for instance, which cites IEEE.754.1985 too. (RFC 5575 seems to claim to be using the actual binary floating-point encoding.) > we don't use the binary > > floating-point encoding but rather a string one for YANG decimal64 > > - I think that RFC 8499 (dnsop-terminology-bis) can wholly supersede our > > usage of RFC 1983, so the 1983 cite can be dropped as well > > [Med] Done. > > > - draft-ietf-dots-requirements (for terminology), > > [Med] For this one, we are following the same approach as for other terminology documents (e.g., RFC8340) that are listed as informative. I prefer to leave it as informative for now. Okay, we can see if anyone else complains. > RFC 7950, and RFC 8259 > > [Med] OK for these two. > > > should probably all move to the normative section > > > > Section 1 > > > > The sub-bullet point about "If a network resource ... informs its servicing > > DOTS gateway of all suspect IP addresses that need to be drop- or > > accept-listed ..." made me wonder if that was more of a signal-channel > > activity or a data-channel one. Perhaps this is just a matter of the text > > not being as clear as it could be. > > [Med] The point is that a client is not sure that an attack is active and targeting the client domain but it wants to enforce some preventive actions during an investigation period. For example, this can be triggered by an administrator who is informed that an attack is currently targeting other networks, but its network is likely to be subject to that attack too. Other preventive actions which require further investigation may be considered. > > I changed the text as follows: > > OLD: > detects a potential DDoS attack from > > NEW > is informed about a potential DDoS attack from > > (I also wonder if we should say > > "further investigation" since we don't really have an automated way to > > indicate that yet.) On further reflection, would "further manual investigation" be appropriate? > > Section 2 > > > > When we talk about tree diagrams, should we also say something like "Note > > that the full module's tree has been split across several figures to aid > > the exposition of the various sub-trees"? > > [Med] Done. Thanks. > > > > > Section 3.1 > > > > When we talk about using GET to retrieve running configuration, do we want > > to note that since the data channel can fail during attack time, it's > > expected to be common to perform such a GET before attempting to make > > modifications to configuration? > > [Med] The data channel is supposed to be invoked when no attack is ongoing. Normal RESTCONF operations are therefore followed. I don't see the need to add a note. I always have to consider edge cases in my IESG reviews -- what happens if an attack starts after the request is sent but before the response is received? > > > > A DOTS client registers itself to its DOTS server(s) in order to set > > up DOTS data channel-related configuration data and receive state > > data (i.e., non-configuration data) from the DOTS server(s) > > (Section 5). Mutual authentication and coupling of signal and data > > channels are specified in [I-D.ietf-dots-signal-channel]. > > > > I think we should split the "mutual authentication" and "coupling of signal > > and data channels" into their own sentence, and flesh them out slightly > > more. So, section references to Sections 8 and 4.4.1, respectively, the > > usage of TLS client certificates, the coupling of channels via the client's > > identity ('cuid' and 'cdid'), etc. > > [Med] Done. > > > > > A TLS heartbeat [RFC6520] verifies > > that the DOTS server still has TLS state by returning a TLS message. > > > > I expect this will get some pointed comments during IETF LC, given the > > recent-ish IETF-wide discussions about heartbeats/keepalives in general. > > Is there perhaps a RESTCONF-level probe message that could be used to check > > liveliness; a capabilities query perhaps? > > [Med] There is no such mechanism. The approach in the data channel draft is aligned with RFC8071 for keepalives. I guess we'll just have to wait to see what kind of comments we get, then. (Thanks for the pointer to 8071.) > > > > A DOTS server may detect conflicting filtering requests from distinct > > DOTS clients which belong to the same domain. For example, a DOTS > > client could request to drop-list a prefix by specifying the source > > prefix, while another DOTS client could request to accept-list that > > same source prefix, but both having the same destination prefix. It > > is out of scope of this specification to recommend the behavior to > > follow for handling conflicting requests (e.g., reject all, reject > > the new request, notify an administrator for validation). DOTS > > servers SHOULD support a configuration parameter to indicate the > > behavior to follow when a conflict is detected. Section 7.2 > > specifies the behavior when no instruction is supplied to a DOTS > > server. > > > > I'm a bit confused by the "out of scope of this specification to recommend > > the behavior to follow for handling conflicting requests", since not only > > does the last sentence of the paragraph give a pointer to a specified > > behavior in case of conflicts, but we also mention it in a couple other > > places (e.g., the bottom of page 43). > > [Med] The specified behavior is a default behavior, not a recommended one. In effect a default is a recommendation, though -- a recommendation for what to do if you don't know any better. Perhaps "it is out of scope of this specification to provide guidance on how conflicting requests may be safely handled, with the default behavior being to reject such requests"? > I update this text: > > If the request is conflicting with an existing filtering installed by > another DOTS client of the domain, and absent any local policy, the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That helps (maybe the "and" is not even needed?). Do you want to do a sweep for other places where the text talks about 409 responses? > DOTS server returns "409 Conflict" status-line to the requesting DOTS > client. The error-tag "resource-denied" is used in this case. > > > > > Also in that paragraph, it's unclear that a 2119 SHOULD is appropriate for > > "support a configuration parameter"; there's no interoperability > > considerations for having or not having such a configuration knob. > > [Med] This is important for interoperability (or at least for ensuring a deterministic behavior). E.g., during service subscription a technical clause may be negotiated out of band how to deal with conflicts from clients of the same domain. It seems that the default behavior of disallowing conflicts would always be interoperable, but I'm happy to leave this as-is for now. > > > > Section 3.3 NAT Considerations have "high overlap" with the > > text at the end of the signal-channel's "Design Overview". At a minimum we > > should diff them and enforce convergence, but do we want to consider just > > having one refer to the other? > > [Med] Makes sense. Section 3.3 is now deleted and replaced with this NEW text: > > NAT considerations for the DOTS data channel are similar to those > discussed in Section 3 of [I-D.ietf-dots-signal-channel]. Cool, thanks. > > > > Section 3.5 > > > > I had to read up on RESTCONF and NETCONF while reviewing this, but from > > what I've seen so far, the "error-severity" field is only present in > > NETCONF and not RESTCONF. If so, then we shouldn't need to talk about it > > here, since we use RESTCONF exclusively. I also couldn't find whether > > there's a registry that we should add the "loop-detected" error-tag to. > > Can anyone here help me out? > > > > [Med] We used the template in https://tools.ietf.org/html/rfc6241#appendix-A because the errors in 8040 are the ones imported from there. Thanks for the pointer. It sounds like I'll need to ask around about this one. > There is no registry for the errors; only a YANG module which is not maintained by IANA. This is why no action is included in the IANA section. > > > Section 4.2 > > > > Is there any plan/expectation for filtering/match rules for QUIC? It is > > probably premature to put anything in this document specifically, but still > > worth thinking about. > > [Med] Some of the existing fields can be already reused for QUIC (UDP, port number). There are few fields in the QUIC public header that are available (public flags, CID, version). A match on the first N bytes of the UDP payload can be considered but I do think this is not mature enough. > > The key point is that our module is extensible. Indeed. > > > > The order in which the leaves appear in the "capabilities/ipv6" and > > "capabilities/tcp" subtrees do not match the order they appear in the ACL > > subtree itself; it would be good to keep the order consistent. > > [Med] Fixed. > > FWIW, the order in capabilities/* follows the order of the fields as they appear in the header. We don't have a control on the ACL order because we are reusing an external module. Ah, good to know. > > > > We don't really say much about what the semantis of the "port-range" > > capabilities are; is that supposed to indicate any port-matching ability at > > all, or specifically the low-to-high range matching, or also the "operator" > > options? > > [Med] Updated as follows: > > OLD: > "Support of filtering based on a port range."; > > NEW: > > "Support of filtering based on a port range. > > This includes filtering based on a source port range, > destination port range, or both. All operators > (i.e, less than or equal, greater than or equal, equal to, > and not equal to) are supported."; Thanks! > > > > Section 4.3 > > > > We define an "operator" typedef that is rather different from that from > > netmod-acl-model. Do we want to use a different name to aid > > disambiguation? ("bitmask-operator" comes to mind as an option.) > > [Med] It is not recommended in yang to use prefixes to disambiguate nodes. The disambiguation is ensured by the context/position in the tree. For example, this is why we are using name and not acl-name or ace-name, etc. I will leave the text as it is. For names this makes natural sense to me, but this question is about a typedef. I have less clear of a picture for how typedefs are or are not namespaced (is it just per-module?). > > > > typedef fragment-type { > > type bits { > > bit df { > > position 0; > > description > > "Don't fragment bit for IPv4. > > This bit must be set to 0 for IPv6."; > > > > Set to zero by whom? What should the receiver do if it is set otherwise? > > > > [Med] In IPv6, fragmentation is only done by the source. Hence, this value for IPv6. A fragment-type with the first bit set will be discarded by the server. I was looking for a few more words in the text, like "must be set to 0 when it appears in an IPv6 filter". > > What are the semantics if (either or both of target-fqdn and target-uri) > > and target-prefix are specified? (I suppose maybe this could be covered in > > Section 6.1 when we say that at least one is required in ACL-creation > > requests.) > > [Med] The resulting IP prefixes/addresses will be bound to the alias. Added the following in Section 6.1: > > If more target-* clauses (e.g., 'target-prefix' and 'target-fqdn') > are included in a POST or PUT request, the DOTS server binds all > resulting IP addresses/prefixes to the same resource. > > > > > The units for the "rate-limit" node should be specified in the YANG module > > and not in the description of how to install filtering rules. > > [Med] Added "units" to the YANG module. > > > > > list dots-client { > > key "cuid"; > > description > > "List of DOTS clients."; > > leaf cuid { > > type string; > > description > > "A unique identifier that is randomly generated by > > a DOTS client to prevent request collisions."; > > > > I don't think "randomly generated" is really correct here. > > [Med] Changed to: > > "A unique identifier that is generated by a DOTS client > to prevent request collisions."; > > > > > The "capabilities/icmp/rest-of-header" description should be more clear > > that (per draft-ietf-netmod-acl-model) it is supposed to match both the > > ICMP four-byte field and the ICMPv6 message body. > > [Med] OK. > > > > > Section 5.1 > > > > It may be worth reiterating that (per the signal-channel doc) gateways may > > rewrite the 'cuid'. > > [Med] OK: > > As a reminder, DOTS gateways may rewrite the 'cuid' used by peer DOTS > clients (Section 4.4.1 of [I-D.ietf-dots-signal-channel]). > > > > > When POST is used to create a dots-client resource, how does the client > > know the path of the created resource (to be used for subsequent RESTCONF > > requests)? (I assume it is supposed to just use the submitted 'cuid', but > > we need to explicitly say this. This also seems to render much of the > > distinction between POST and PUT moot, for our usage, though I do not > > propose any change to the text.) > > [Med] The procedure to determine the root path is recalled in Section 3.1, then normal RESTCONF operation is followed. > > > > > The DOTS gateway, that inserted a 'cdid' in a PUT request, MUST strip > > the 'cdid' parameter in the corresponding response before forwarding > > the response to the DOTS client. > > > > Why does this apply only to PUT and not POST? > > [Med] Because RFC8040 says the following: > > If the POST method succeeds, a "201 Created" status-line is returned > and there is no response message-body. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Whoops, I clearly missed that part. Thanks for calling it out. > > > > Section 6.1 > > > > DOTS clients within the same domain can create different aliases for > > the same resource. > > > > My reading of this text is that client A can create alias "foo" for IP > > prefix 128.0.1.5/31 and clinet B can create alias "bar" for the same IP > > prefix, and that DOTS supports that process. (Just to confirm that the > > text is saying what it's intended to.) > > [Med] Yes. > > I do wonder if we want to say > > something about whether alias names need only be unique per 'cuid' or in > > some more global fashion. (Having a global uniqueness property is perhaps > > convenient in order to interface with non-DOTS mechanisms for querying > > aliases, or for the DOTS server to interact with network filtering > > appliances.) > > [Med] The specification does require uniqueness per cuid: > > | +--rw aliases > | | +--rw alias* [name] > | | +--rw name string > > We don't have a requirement for uniqueness per domain or globally. > > If such requirement arise, the semantic/logic for creating those aliases can be handled out of band. Ok. > > > > Figure 16 puts double-quotes around "string" in the pseudo-schema, which > > feels weird to me. > > [Med] This is also what we have done for other figures , e.g., 11. The intent is to use a scheme-like message body while trying to preserve JSON compliance. > > > > > target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An > > FQDN is the full name of a resource, rather than just its > > hostname. For example, "venera" is a hostname, and > > "venera.isi.edu" is an FQDN [RFC1983]. Refer to > > [I-D.ietf-dnsop-terminology-bis] for more details. > > > > I don't think this text is particularly well-aligned with RFC 8499 and > > would suggest trimming it substantially and just pointing to that RFC. > > [Med] Done. > > > > > If the request is missing a mandatory attribute or its contains an > > invalid or unknown parameter, "400 Bad Request" status-line MUST be > > returned by the DOTS server. The error-tag is set to "missing- > > attribute", "invalid-value", or "unknown-element" as a function of > > the encountered error. > > > > This text seems to preclude any future extension that adds new error tags; > > is this intended? > > [Med] Those errors are only about the tree failure cases called in the first sentence. > > > > > Section 7.1 > > > > A DOTS client which issued a GET request to retrieve the filtering > > capabilities supported by its DOTS server, SHOULD NOT request for > > filtering actions that are not supported by that DOTS server. > > > > What is the server behavior if the client ignores this SHOULD NOT? > > [Med] This is covered by this text: > > If the request is missing a mandatory attribute or > contains an invalid or unknown parameter (e.g., a match field not > supported by the DOTS server), "400 Bad Request" status-line MUST be > returned by the DOTS server in the response. sounds good. > > > > Figure 23 shows an example of a response received from a DOTS server > > which only supports the mandatory filtering criteria listed in > > Section 4.1. > > > > This seems inaccurate, as the mandatory filtering criteria exlude the > > rate-limit among others. > > [Med] rate-limit is an action, not a filtering criteria. > > > > > Section 7.2 > > > > activation-type: Indicates whether an ACL has to be activated > > (immediately or during mitigation time) or instantiated without > > being activated (deactivated). Deactivated ACLs can be activated > > using a variety of means such as manual configuration on a DOTS > > server or using the DOTS data channel. > > > > Is this done by the data channel or the signal channel? > > [Med] Yes, but this is not supported in the base signal-channel spec. This is the done using the filtering control feature (draft-nishizuka-dots-signal-control-filtering). This is why signal channel is not listed after "such as". Okay. (I was literally just wondering if this was a typo.) > > > > If this attribute is not provided, the DOTS server MUST use > > 'activate-when-mitigating' as default value. > > > > Why do we specify default values here instead of in the YANG module? > > [Med] There is no default statement for enumeration. To solve this, a new type is defined in the module (activation-type). This type is then used for the activation-type leaf with a default value set to activate-when-mitigating. That's a clever workaround! > The change in tree diagram is (no need to insert the code here): > > OLD: > | +--rw activation-type? Enumeration > > NEW: > | +--rw activation-type? activation-type > > > > > > Filters that are activated only when a mitigation is in progress > > MUST be bound to the DOTS client which created the filtering rule. > > > > Other filters do not need to be bound to the DOTS client that created them? > > [Med] They are...but those filters are already enforced because they are immediate. The wording here is still weird, though -- by calling out the delayed-activation filters it implies that immediate-activation filters are excluded from the statement, but we know that immediate-activation filters also have the same property. So I'm not entirely sure exactly what information this sentence is intended to call out. > > Wouldn't we still want to remove them when the dots-client resource in > > question is deleted? > > [Med] This is supposed to be done by the client itself. For amnesiac clients, we do have the following: Oh. I think I was remembering Section 5.2's "resources bound to this DOTS client will be deleted by the DOTS server" and assuming it applies to the filters associated with that client. > In order to avoid stale entries, a lifetime is associated with alias > and filtering entries created by DOTS clients. Also, DOTS servers > may track the inactivity timeout of DOTS clients to detect stale > entries. This is probably enough to ensure safe operation without the above, though, hmm... > > > > destination-ipv4-network: The destination IPv4 prefix. DOTS servers > > [...] > > This is a mandatory attribute in requests with an 'activation- > > type' set to 'immediate'. > > > > I somehow thought there were YANG attributes that could indicate this > > conditional requirement in the module itself, though I am hardly a YANG > > expert. > > [Med] We are reusing fields from ietf-netmod-acl, it is not easy to manipulate the fields as we would want. Okay. > > > > The error-tag is set to > > "missing-attribute", "invalid-value", or "unknown-element" as a > > function of the encountered error. > > > > Same comment as above about (non-)extensibility. > > [Med] Idem as above. > > > > > Section 7.3 > > > > I see that the "test-acl-*" and "test-ace-*" acl and ace objects in these > > examples do in fact use different names for the semantically different > > objects, but perhaps we could help the reader's eye and use strings with a > > larger Hamming distance? (I thought they were all the same on my first > > read.) > > [Med] Fixed. > > > > > (I also am a little confused at why the "ace" "name" field is considered a > > non-config field, in Figure 31, but this seems more likely to be my > > confusion than an error in the document.) > > [Med] This is because the name is the key of the ace list. > > RFC8040 says the following: > > To retrieve only the non-configuration child resources, the "content" > parameter is set to "nonconfig". Note that configuration ancestors > (if any) and list key leafs (if any) are also returned. Thanks for the pointer. > > > > Section 8 > > > > o DOTS server MUST NOT enable both DOTS data channel and direct > > configuration to avoid race conditions and inconsistent > > configurations arising from simultaneous updates from multiple > > sources. > > > > o DOTS agents SHOULD enable DOTS data channel to configure aliases > > and ACLs, and only use direct configuration as a stop-gap > > mechanism to test DOTS signal channel with aliases and ACLs. > > Further, direct configuration SHOULD only be used when the on-path > > DOTS agents are within the same domain. > > > > Doesn't all this discussion of "direct configuration" conflict with the > > "MUST NOT" in the first bullet point? > > [Med] The second bullet is about controlled testing of the *signal channel* with aliases/acls communicated by the data channel. Whoops, my misread. > > > > Section 10 > > > > Generally with the security considerations template for YANG modules, we > > need to list out all the nodes considered sensitive and the consequences of > > writing(/reading) each one in turn. > > > > [Med] The text does already call out those that are specific to this document. For other nodes, we do have this text: > > "YANG ACL-specific security > considerations are discussed in [I-D.ietf-netmod-acl-model]." > > I think we are OK. I would suggest adding a new sentence in the "All data nodes defined" paragraph about "This module reuses YANG structures from [I-D.ietf-netmod-acl-model], and the security considerations for those nodes continue to apply for this usage.", since that text is at the other end of the section and it's otherwise hard to make a linkage between them. Thanks, Ben From nobody Thu Feb 14 23:42:15 2019 Return-Path: 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 87910128B14 for ; Thu, 14 Feb 2019 23:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 lipaPK6h1T2e for ; Thu, 14 Feb 2019 23:42:10 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268351200B3 for ; Thu, 14 Feb 2019 23:42:10 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4414wJ45gxzCrGM; Fri, 15 Feb 2019 08:42:08 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4414wJ3cWTzFpWj; Fri, 15 Feb 2019 08:42:08 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([fe80::81c9:5f:b9c5:1241%21]) with mapi id 14.03.0435.000; Fri, 15 Feb 2019 08:42:08 +0100 From: To: Takahiko Nagata , "dots@ietf.org" Thread-Topic: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-control-filtering-02.txt Thread-Index: AQHUsZSTGMTSbdBqkk2xGa77+OXjFKW5xiYAgB7w/wCAAZ29EIAGS5cA Date: Fri, 15 Feb 2019 07:42:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1FB62@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154808047532.8261.13887766521569519982.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA0AFE4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9a6d0548-1b2d-3837-a5d4-12490aa46e99@lepidum.co.jp> <787AE7BB302AE849A7480A190F8B93302EA1D1CA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA1D1CA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-control-filtering-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 07:42:13 -0000 SGkgVGFrYWhpa28sIA0KDQpUaGUgZHJhZnQgaXMgdXBkYXRlZCB0byBtYWtlIHRoaXMgbW9yZSBj bGVhci4gUGxlYXNlIGNoZWNrIC0wNC4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBFbnZv ecOpwqA6IGx1bmRpIDExIGbDqXZyaWVyIDIwMTkgMDg6NDANCj4gw4DCoDogVGFrYWhpa28gTmFn YXRhOyBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbRG90c10gVFI6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbmlzaGl6dWthLWRvdHMtDQo+IHNpZ25hbC1jb250cm9s LWZpbHRlcmluZy0wMi50eHQNCj4gDQo+IEhpIFRha2FoaWtvLA0KPiANCj4gVGhlIHBhcmFtZXRl cnMgdXNlZCBpbiB0aGUgaW5pdGlhbCByZXF1ZXN0IG11c3QgYmUgcmVwZWF0ZWQgaW4gdGhlIHJl ZnJlc2gNCj4gcmVxdWVzdCB0byBtb2RpZnkgdGhlIGNvbnRyb2wgZmlsdGVyaW5nLg0KPiANCj4g UGxlYXNlIG5vdGUgdGhhdCBzZW5kaW5nIG9ubHkgYWNsLWxpc3QgYXR0cmlidXRlcyBpbiBhIFBV VCB3aWxsIGZhaWwgYmVjYXVzZQ0KPiBvZiB0aGUgY2hlY2tzIGFnYWluc3QgbWFuZGF0b3J5IGF0 dHJpYnV0ZXM6DQo+IA0KPiAgICBJbiB0aGUgUFVUIHJlcXVlc3QgYXQgbGVhc3Qgb25lIG9mIHRo ZSBhdHRyaWJ1dGVzICd0YXJnZXQtcHJlZml4JywNCj4gICAgJ3RhcmdldC1mcWRuJywndGFyZ2V0 LXVyaScsIG9yICdhbGlhcy1uYW1lJyBNVVNUIGJlIHByZXNlbnQuDQo+IA0KPiAgICAuLi4NCj4g DQo+ICAgIElmIHRoZSByZXF1ZXN0IGlzIG1pc3NpbmcgYSBtYW5kYXRvcnkgYXR0cmlidXRlLCBk b2VzIG5vdCBpbmNsdWRlDQo+ICAgICdjdWlkJyBvciAnbWlkJyBVcmktUGF0aCBvcHRpb25zLCBp bmNsdWRlcyBtdWx0aXBsZSAnc2NvcGUnDQo+ICAgIHBhcmFtZXRlcnMsIG9yIGNvbnRhaW5zIGlu dmFsaWQgb3IgdW5rbm93biBwYXJhbWV0ZXJzLCB0aGUgRE9UUw0KPiAgICBzZXJ2ZXIgTVVTVCBy ZXBseSB3aXRoIDQuMDAgKEJhZCBSZXF1ZXN0KS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0K PiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6IERvdHMgW21haWx0bzpk b3RzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgVGFrYWhpa28gTmFnYXRhDQo+ID4g RW52b3nDqcKgOiBkaW1hbmNoZSAxMCBmw6l2cmllciAyMDE5IDA4OjUyDQo+ID4gw4DCoDogZG90 c0BpZXRmLm9yZw0KPiA+IE9iamV0wqA6IFJlOiBbRG90c10gVFI6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbmlzaGl6dWthLWRvdHMtDQo+ID4gc2lnbmFsLWNvbnRyb2wtZmls dGVyaW5nLTAyLnR4dA0KPiA+DQo+ID4gSGkgTWVkLCBhbGwsDQo+ID4NCj4gPiBUaGFuayB5b3Ug Zm9yIHVwZGF0ZWQgZHJhZnQuDQo+ID4NCj4gPiBJIGhhdmUgYSBxdWVzdGlvbiBmb3IgdXNlY2Fz ZSBvZiB0aGlzIGRyYWZ0IC0wMyBzcGVjaWZpY2F0aW9uLg0KPiA+DQo+ID4gKFF1ZXN0aW9uKSBX b3VsZCB3ZSBhbGxvdyB1c2luZyBNaXRpZ2F0aW9uIHJlcXVlc3Qgd2l0aA0KPiA+ICAgIG9ubHkg Y29udHJvbC1maWx0ZXJpbmcgYXR0cmlidXRlcz8NCj4gPg0KPiA+IFRoaXMgbWVhbiwgUFVUIFNp Z25hbENoYW5uZWwgTWl0aWdhdGlvbiByZXF1ZXN0IHdpdGgNCj4gPiBvbmx5IGFjbC1saXN0ICh3 aXRob3V0IGFueSB0YXJnZXQteHh4KS4NCj4gPg0KPiA+IFVzZWNhc2U6DQo+ID4gICAgT25seSB1 cGRhdGUgc3RhdHVzIG9mIERhdGFDaGFubmVsIEFDTCBkdXJpbmcgYSBERG9TIGF0dGFjay4NCj4g PiAgICAoSWYgRGF0YUNoYW5uZWwgQUNMIGlzIGVub3VnaCBmb3IgcHJvdGVjdGlvbi4gKQ0KPiA+ DQo+ID4NCj4gPiBCZXN0IFJlZ2FyZHMsDQo+ID4gVGFrYWhpa28gTmFnYXRhDQo+ID4NCj4gPiBP biAyMDE5LzAxLzIxIDIzOjI1LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0K PiA+ID4gSGkgVGFrYWhpa28sDQo+ID4gPg0KPiA+ID4gSSB1cGRhdGVkIHRoZSBkcmFmdCB0byB0 YWtlIGludG8gYWNjb3VudCB5b3VyIGNvbW1lbnRzOg0KPiA+ID4NCj4gPiA+ICogTWFrZSBzdXJl IHRoYXQgYnkgZGVmYXVsdCwgdGhlIGRhdGEgY2hhbm5lbCBpcyB1c2VkIGZvciBBQ0wtcmVsYXRl ZA0KPiA+IG9wZXJhdGlvbnMuDQo+ID4gPiAqIE5vIHVwZGF0ZSBpcyByZXF1aXJlZCB0byBlZmZp Y2FjeSB1cGRhdGUsIGdldCwgYW5kIGRlbGV0ZS4NCj4gPiA+DQo+ID4gPiBQbGVhc2UgbGV0IHVz IGtub3cgaWYgdGhlIGNoYW5nZXMgYWRkcmVzc2VzIHlvdXIgY29tbWVudHMuDQo+ID4gPg0KPiA+ ID4gRG9uJ3QgaGVzaXRhdGUgdG8gc2hhcmUgYW55IGZ1cnRoZXIgY29tbWVudCB5b3UgbWF5IGhh dmUuIFRoYW5rcy4NCj4gPiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiBNZWQNCj4gPiA+DQo+ID4g Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPj4gRGXCoDogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+ID4+IEVu dm95w6nCoDogbHVuZGkgMjEgamFudmllciAyMDE5IDE1OjIxDQo+ID4gPj4gw4DCoDogVGFrYWhp a28gTmFnYXRhOyBUaXJ1bWFsZXN3YXIgUmVkZHk7IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47 DQo+IFJlZGR5DQo+ID4gSzsNCj4gPiA+PiBLYW5hbWUgTmlzaGl6dWthDQo+ID4gPj4gT2JqZXTC oDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1uaXNoaXp1a2EtZG90cy1zaWdu YWwtDQo+IGNvbnRyb2wtDQo+ID4gPj4gZmlsdGVyaW5nLTAyLnR4dA0KPiA+ID4+DQo+ID4gPj4N Cj4gPiA+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbmlzaGl6dWthLWRvdHMtc2lnbmFs LWNvbnRyb2wtZmlsdGVyaW5nLQ0KPiAwMi50eHQNCj4gPiA+PiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1vaGFtZWQgQm91Y2FkYWlyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4g Pj4gSUVURiByZXBvc2l0b3J5Lg0KPiA+ID4+DQo+ID4gPj4gTmFtZToJCWRyYWZ0LW5pc2hpenVr YS1kb3RzLXNpZ25hbC1jb250cm9sLWZpbHRlcmluZw0KPiA+ID4+IFJldmlzaW9uOgkwMg0KPiA+ ID4+IFRpdGxlOgkJQ29udHJvbGxpbmcgRmlsdGVyaW5nIFJ1bGVzIFVzaW5nIERPVFMgU2lnbmFs IENoYW5uZWwNCj4gPiA+PiBEb2N1bWVudCBkYXRlOgkyMDE5LTAxLTIxDQo+ID4gPj4gR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiA+PiBQYWdlczoJCTE1DQo+ID4gPj4gVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXNo aXp1a2EtDQo+IGRvdHMtDQo+ID4gPj4gc2lnbmFsLWNvbnRyb2wtZmlsdGVyaW5nLTAyLnR4dA0K PiA+ID4+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1uaXNoaXp1a2EtZG90cy0NCj4gPiBzaWduYWwtDQo+ID4gPj4gY29udHJvbC1maWx0ZXJp bmcvDQo+ID4gPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1uaXNoaXp1a2EtZG90cy1zaWduYWwtDQo+ID4gPj4gY29udHJvbC1maWx0ZXJpbmctMDIN Cj4gPiA+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1uaXNoaXp1a2EtDQo+ID4gZG90cy0NCj4gPiA+PiBzaWduYWwtY29udHJvbC1m aWx0ZXJpbmcNCj4gPiA+PiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LW5pc2hpenVrYS1kb3RzLQ0KPiA+ID4+IHNpZ25hbC1jb250cm9sLWZp bHRlcmluZy0wMg0KPiA+ID4+DQo+ID4gPj4gQWJzdHJhY3Q6DQo+ID4gPj4gICAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGFuIGV4dGVuc2lvbiB0byB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCB0 bw0KPiA+ID4+ICAgICBjb250cm9sIHRoZSBmaWx0ZXJpbmcgcnVsZXMgd2hlbiBhbiBhdHRhY2sg bWl0aWdhdGlvbiBpcyBhY3RpdmUuDQo+ID4gPj4NCj4gPiA+PiAgICAgUGFydGljdWxhcmx5LCB0 aGlzIGV4dGVuc2lvbiBhbGxvd3MgYSBET1RTIGNsaWVudCB0byBhY3RpdmF0ZSBvciBkZS0NCj4g PiA+PiAgICAgYWN0aXZhdGUgZmlsdGVyaW5nIHJ1bGVzIGR1cmluZyBhIEREb1MgYXR0YWNrLiAg VGhlIGNoYXJhY3Rlcml6YXRpb24NCj4gPiA+PiAgICAgb2YgdGhlc2UgZmlsdGVyaW5nIHJ1bGVz IGlzIHN1cHBvc2VkIHRvIGJlIGNvbnZleWVkIGJ5IGEgRE9UUyBjbGllbnQNCj4gPiA+PiAgICAg ZHVyaW5nIHBlYWNlIHRpbWUgYnkgbWVhbnMgb2YgRE9UUyBkYXRhIGNoYW5uZWwuDQo+ID4gPj4N Cj4gPiA+PiBFZGl0b3JpYWwgTm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKQ0KPiA+ ID4+DQo+ID4gPj4gICAgIFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50cyB3aXRoaW4gdGhl IGRvY3VtZW50IHdpdGggdGhlIFJGQw0KPiA+ID4+ICAgICBudW1iZXIgdG8gYmUgYXNzaWduZWQg dG8gdGhpcyBkb2N1bWVudDoNCj4gPiA+Pg0KPiA+ID4+ICAgICBvICAiVGhpcyB2ZXJzaW9uIG9m IHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWDsiDQo+ID4gPj4NCj4gPiA+PiAg ICAgbyAgIlJGQyBYWFhYOiBDb250cm9sbGluZyBGaWx0ZXJpbmcgUnVsZXMgVXNpbmcgRE9UUyBT aWduYWwNCj4gQ2hhbm5lbCI7DQo+ID4gPj4NCj4gPiA+PiAgICAgbyAgcmVmZXJlbmNlOiBSRkMg WFhYWA0KPiA+ID4+DQo+ID4gPj4gICAgIG8gIFtSRkNYWFhYXQ0KPiA+ID4+DQo+ID4gPj4gICAg IFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50cyB3aXRoIHRoZSBSRkMgbnVtYmVyIHRvIGJl IGFzc2lnbmVkIHRvDQo+ID4gPj4gICAgIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzOg0KPiA+ID4+ DQo+ID4gPj4gICAgIG8gICJSRkMgU1NTUzogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2Ug T3BlbiBUaHJlYXQgU2lnbmFsaW5nDQo+ID4gPj4gICAgICAgIChET1RTKSBTaWduYWwgQ2hhbm5l bCBTcGVjaWZpY2F0aW9uIiAodXNlZCB0byBiZQ0KPiA+ID4+ICAgICAgICBbSS1ELmlldGYtZG90 cy1zaWduYWwtY2hhbm5lbF0pDQo+ID4gPj4NCj4gPiA+PiAgICAgbyAgIlJGQyBEREREOiBEaXN0 cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcNCj4gPiA+PiAg ICAgICAgKERPVFMpIERhdGEgQ2hhbm5lbCBTcGVjaWZpY2F0aW9uIiAodXNlZCB0byBiZQ0KPiA+ ID4+ICAgICAgICBbSS1ELmlldGYtZG90cy1kYXRhLWNoYW5uZWxdKQ0KPiA+ID4+DQo+ID4gPj4g ICAgIFBsZWFzZSB1cGRhdGUgdGhlICJyZXZpc2lvbiIgZGF0ZSBvZiB0aGUgWUFORyBtb2R1bGUu DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+IHN1 Ym1pc3Npb24NCj4gPiA+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+ID4+DQo+ID4gPj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCj4gPiA+DQo+ID4NCj4gPiAtLQ0KPiA+ID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQo+ID4g5qCq5byP5Lya56S+44Os44OU44OA44OgDQo+ID4g5rC455Sw44CA6LK05b2m DQo+ID4NCj4gPiBNYWlsOiBuYWdhdGFAbGVwaWR1bS5jby5qcA0KPiA+IFRlbDogICAwMy02Mjc2 LTUxMDMNCj4gPg0KPiA+IOOAkjE1MS0wMDcxDQo+ID4g5p2x5Lqs6YO95riL6LC35Yy65pys55S6 My0xMi0x44CA5L2P5Y+L5LiN5YuV55Sj6KW/5paw5a6/44OT44OrNuWPt+mkqA0KPiA+ID09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gRG90 c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 cw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBE b3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Fri Feb 15 01:36:33 2019 Return-Path: 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 5135A130F8E; Fri, 15 Feb 2019 01:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9YKMfXu_5nKU; Fri, 15 Feb 2019 01:36:28 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BF3130F82; Fri, 15 Feb 2019 01:36:28 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4417SB33Yyz5vww; Fri, 15 Feb 2019 10:36:26 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4417SB25zMz1xpX; Fri, 15 Feb 2019 10:36:26 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b%21]) with mapi id 14.03.0435.000; Fri, 15 Feb 2019 10:36:26 +0100 From: To: Benjamin Kaduk CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxJngxeBzH579tUeqIgtYPD9bE6XgYyLQ Date: Fri, 15 Feb 2019 09:36:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> In-Reply-To: <20190214191707.GM56447@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 09:36:32 -0000 Hi Ben,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: jeudi 14 f=E9vrier 2019 20:17 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > Objet=A0: Re: AD review of draft-ietf-dots-data-channel-25 >=20 > Hi Med, >=20 > On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Ben, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoy=E9=A0: mercredi 13 f=E9vrier 2019 17:46 > > > =C0=A0: draft-ietf-dots-data-channel@ietf.org > > > Cc=A0: dots@ietf.org > > > Objet=A0: AD review of draft-ietf-dots-data-channel-25 > > > > > > This is my AD review of the -25 > > > > > > I see that Med made a commit on github that preemptively addressed at > least > > > one of these comments, but will trust the authors to do to the right > thing > > > with anything in here that's stale. > > > > > > A handful of generic and/or high-level comments before the > > > section-by-section nitty-gritty stuff. > > > > > > The author count is large (7); RFC 7322 notes that the stream approve= r > > > (i.e., the IESG) will ask questions if the count is more than five. = What > > > should I tell people when they ask? (The authors are listed also in = the > > > YANG module itself, if changes are made.) > > > > [Med] Actually, the set of co-authors of the YANG module is not exactly= the > same. >=20 > Whoops, my bad for not checking. >=20 > > Anyway, in order to comply with the rules and avoid spending extra cycl= es > on this, we added a new section called "Contributing Authors". Neverthele= ss, > the set of authors is not modified in the YANG module. >=20 > Thanks. (To be clear, I'm happy to go to bat for everyone with the IESG > for this sort of thing, I just need an argument to present that's not me > making things up.) >=20 > I don't know of a specific policy for YANG module authorship, so that par= t > should be okay as far as I know. >=20 > > > > > > Can someone (the shepherd?) confirm that an automated syntax checker = has > > > run over the JSON in examples? > > > > > > The concept of "DOTS client domain" is being used for actual protocol > > > purposes here (most notably as a bound on the prefix(es) that a clien= t > can > > > request mitigation for, but I don't remember seeing a formal definiti= on > for > > > how any DOTS actor would know the specific bounds of such a client > domain. > > > Is there text somewhere that I missed that we can point to, or will w= e > need > > > to add some? > > > > [Med] Both "DOTS client domain" and "DOTS server domain" are used in th= e > architecture draft. "DOTS client's domain" and "DOTS server's domain" are > also used in the architecture and requirements I-D. > > > > If a formal definition is needed, I prefer this to be done in the > architecture or the requirements I-D. >=20 > I think it would be a somewhat better fit in the architecture document, > just to note that the "domain" is something that can concretely be > demarcated by IP addresses/prefixes (as opposed to a more nebulous concep= t > to aid conceptual understanding). >=20 [Med] Let's add that text into the architecture I-D. > > > > > > We don't say much about what validation the server does on input data= , > and > > > we probably should. For example, does the server need to validate 'c= uid' > > > > [Med] We avoided to be redundant here. This is covered by this text: > > > > "This attribute has the same > > meaning, syntax, and processing rules as the 'cuid' attribute > > defined in [I-D.ietf-dots-signal-channel]." > > > > > and/or 'cdid' in dots-client-creation requests? > > > > [Med] This is covered by this text: > > > > "This attribute has the same meaning, syntax, and processing > > rules as the 'cdid' attribute defined in > > [I-D.ietf-dots-signal-channel]" >=20 > I guess I'm mostly just concerned about if there's anything that doesn't > translate directly, since the CoAP and HTTP constructs would have to > describe the formal validation in somewhat different terms (i.e., for > consistency between URL paths and message bodies). But in general I'm > happy to avoid redundancy as you desire. >=20 > > And other parts in the text such as: > > > > If the request is received via a server-domain DOTS gateway, but the > > DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid= ' > > is expected to be supplied, the DOTS server MUST reply with "403 > > Forbidden" status-line and the error-tag "access-denied". Upon > > receipt of this message, the DOTS client MUST register (Section 5). > > > > > > What about validating that > > > the (e.g.) ACL name in the PUT URL matching the name in the body of t= he > > > request? > > > > [Med] Those are supposed to be covered following RESTCONF base spec. >=20 > Is this supposed to be RFC 8040 Section 3.5.3? I am not sure that I'm > reading that as covering the property I want (and will double-check if yo= u > confirm that's what you have in mind). >=20 [Med] In addition to 3.5.3, Section 4.5 specifies the rules for PUT.=20 The main point is that the validation you mentioned is not specific to DOTS= but are governed by RESTCONF procedures. > > There are probably others as well. > > > > > > The examples all use "Host: {host}:{port}" which is not really an exa= mple > > > but rather a template. Since they are supposed to be examples, we sh= ould > > > pick a concrete hostname (and port) to use. > > > > [Med] I will change some figures to "example.com" but will leave it for > schema-like figures. >=20 > Of course. >=20 > > > > > > There is, shall we say, a "high degree of overlap" between Sections 5= /6/7 > > > and the YANG model field descriptions. I mostly assume that the WG > > > considered letting the YANG model (and the core RESTCONF spec) stand > alone > > > without the additional examples/specification of the use of RESTCONF = to > > > manage clients, aliases, and filter rules, so I won't suggest that we > > > revisit the question. But I do think that it would be good to have s= ome > > > explicit text acknowledging the overlap and stating which one is > > > authoritative. > > > > [Med] Fixed. > > > > > > > > There seems to be some mismatch between whether the IPv6 ACL subtree = uses > > > "ttl" or "hoplimit" -- Figure 7 has "ttl" but the rest of the documen= t > > > seems to (properly) use "hoplimit". Someone else should double-check= the > > > relevant places, though, as I'm not sure I was looking at all of them > with > > > this issue in mind. > > > > [Med] Both are correct. > > > > Figure 7 reuses draft-ietf-netmod-acl-model which defines TTL as : > > > > leaf ttl { > > type uint8; > > description > > "This field indicates the maximum time the datagram is allowed > > to remain in the internet system. If this field contains the > > value zero, then the datagram must be dropped. > > > > In IPv6, this field is known as the Hop Limit."; > > reference > > "RFC 791: Internet Protocol, > > RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; > > } > > > > For the other figures, the fields are defined in the data-channel draft= . >=20 > Ah, thanks for the pointer. >=20 > > > > > > I'm also a bit curious about the use of an explicit "capabilities" tr= ee > for > > > fine-grained feature detection, as opposed to native YANG "feature"s. > > > > [Med] These are not serving the same purpose. Features are about parts = of a > module which are conditional, if you will. Our "capabilities" branch is m= eant > to retrieve the filtering match capabilities are supported/enabled by a D= OTS > server. That information is used by a client to tweak its requests. > > > > The > > > latter would allow the relevant nodes to just not exist when unsuppor= ted, > > > > [Med] A filtering capability may be supported but not enabled. The serv= er > is free to include an explicit field with the appropriate status or not. = This > is implementation-specific. >=20 > Thanks for the explanation. >=20 > > > as opposed to the explicit-capabilities formulation where they exist = but > > > are (presumably) ignored. (I don't remember us explictily saying tha= t > > > they're ignored in this case, either; might be worth adding some text= .) > > > > > > In a similar vein, we include 'capabilities' nodes for a few matching > > > features that are listed as "mandatory fields" for ACL matching in Ta= ble > 1, > > > and thus whose value would always be "true". Why do we need the > capability > > > leaves in such a case? > > > > [Med] I guess you are referring to Figure 23 which says the following: > > > > Figure 23 shows an example of a response received from a DOTS server > > which only supports the mandatory filtering criteria listed in > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Section 4.1. >=20 > Correct. >=20 > > The module allows to return other capabilities than those listed in tab= le > 1. >=20 > Yes. But the figure should not claim to be an example that *only* suppor= ts > the mandatory parts, when it shows an example that supports additional > capabilities than the mandatory ones. >=20 [Med] Which "additional capabilities" are you referring to? =20 > > > > > > idnits notes a few references that can be updated along with the othe= r > > > changes; it also flags a "reference in abstract" for the RFC Editor n= ote > > > which we could probably ignore (but could probably also just remove t= he > > > brackets around the text in question). > > > > [Med] idnits confuses the note to the RFC editor with the abstract. Fix= ed, > anyway. > > > > > > > > I also looked at the references (especially the normative/informative > > > split) and have a few suggestions: > > > > > > - the IEEE.754.1985 reference is not needed; > > > > [Med] Agree, but it is not harmful to cite it either :-) >=20 > My personal opinion is that it *is* harmful, since we are not using a > floating-point wire encoding; we're using a string encoding. [Med] I removed the ref, but added a sentence to justify the unit we are us= ing: mainly to align with traffic-rate in 5575. >=20 > > The reference is quoted to justify why we went with decimal64, not uint= 64 > for example + why that unit is chosen. This allows to ease grafting DOTS = with > BGP Flowspec for instance, which cites IEEE.754.1985 too. >=20 > (RFC 5575 seems to claim to be using the actual binary floating-point > encoding.) >=20 > > we don't use the binary > > > floating-point encoding but rather a string one for YANG decimal64 > > > - I think that RFC 8499 (dnsop-terminology-bis) can wholly supersede = our > > > usage of RFC 1983, so the 1983 cite can be dropped as well > > > > [Med] Done. > > > > > - draft-ietf-dots-requirements (for terminology), > > > > [Med] For this one, we are following the same approach as for other > terminology documents (e.g., RFC8340) that are listed as informative. I > prefer to leave it as informative for now. >=20 > Okay, we can see if anyone else complains. >=20 > > RFC 7950, and RFC 8259 > > > > [Med] OK for these two. > > > > > should probably all move to the normative section > > > > > > Section 1 > > > > > > The sub-bullet point about "If a network resource ... informs its > servicing > > > DOTS gateway of all suspect IP addresses that need to be drop- or > > > accept-listed ..." made me wonder if that was more of a signal-channe= l > > > activity or a data-channel one. Perhaps this is just a matter of the > text > > > not being as clear as it could be. > > > > [Med] The point is that a client is not sure that an attack is active a= nd > targeting the client domain but it wants to enforce some preventive actio= ns > during an investigation period. For example, this can be triggered by an > administrator who is informed that an attack is currently targeting other > networks, but its network is likely to be subject to that attack too. Oth= er > preventive actions which require further investigation may be considered. > > > > I changed the text as follows: > > > > OLD: > > detects a potential DDoS attack from > > > > NEW > > is informed about a potential DDoS attack from > > > > (I also wonder if we should say > > > "further investigation" since we don't really have an automated way t= o > > > indicate that yet.) >=20 > On further reflection, would "further manual investigation" be appropriat= e? [Med] No assumption is made how that investigation is made. I prefer to lea= ve the text as it.=20 >=20 > > > Section 2 > > > > > > When we talk about tree diagrams, should we also say something like "= Note > > > that the full module's tree has been split across several figures to = aid > > > the exposition of the various sub-trees"? > > > > [Med] Done. Thanks. > > > > > > > > Section 3.1 > > > > > > When we talk about using GET to retrieve running configuration, do we > want > > > to note that since the data channel can fail during attack time, it's > > > expected to be common to perform such a GET before attempting to make > > > modifications to configuration? > > > > [Med] The data channel is supposed to be invoked when no attack is ongo= ing. > Normal RESTCONF operations are therefore followed. I don't see the need t= o > add a note. >=20 > I always have to consider edge cases in my IESG reviews -- what happens i= f > an attack starts after the request is sent but before the response is > received? [Med] The dots client will know if its request is successfully delivered. W= hen an attack is ongoing, the dots client should not use it data channel be= cause it is likely to be perturbed. =20 >=20 > > > > > > A DOTS client registers itself to its DOTS server(s) in order to s= et > > > up DOTS data channel-related configuration data and receive state > > > data (i.e., non-configuration data) from the DOTS server(s) > > > (Section 5). Mutual authentication and coupling of signal and dat= a > > > channels are specified in [I-D.ietf-dots-signal-channel]. > > > > > > I think we should split the "mutual authentication" and "coupling of > signal > > > and data channels" into their own sentence, and flesh them out slight= ly > > > more. So, section references to Sections 8 and 4.4.1, respectively, = the > > > usage of TLS client certificates, the coupling of channels via the > client's > > > identity ('cuid' and 'cdid'), etc. > > > > [Med] Done. > > > > > > > > A TLS heartbeat [RFC6520] verifies > > > that the DOTS server still has TLS state by returning a TLS messag= e. > > > > > > I expect this will get some pointed comments during IETF LC, given th= e > > > recent-ish IETF-wide discussions about heartbeats/keepalives in gener= al. > > > Is there perhaps a RESTCONF-level probe message that could be used to > check > > > liveliness; a capabilities query perhaps? > > > > [Med] There is no such mechanism. The approach in the data channel draf= t is > aligned with RFC8071 for keepalives. >=20 > I guess we'll just have to wait to see what kind of comments we get, then= . > (Thanks for the pointer to 8071.) >=20 > > > > > > A DOTS server may detect conflicting filtering requests from disti= nct > > > DOTS clients which belong to the same domain. For example, a DOTS > > > client could request to drop-list a prefix by specifying the sourc= e > > > prefix, while another DOTS client could request to accept-list tha= t > > > same source prefix, but both having the same destination prefix. = It > > > is out of scope of this specification to recommend the behavior to > > > follow for handling conflicting requests (e.g., reject all, reject > > > the new request, notify an administrator for validation). DOTS > > > servers SHOULD support a configuration parameter to indicate the > > > behavior to follow when a conflict is detected. Section 7.2 > > > specifies the behavior when no instruction is supplied to a DOTS > > > server. > > > > > > I'm a bit confused by the "out of scope of this specification to > recommend > > > the behavior to follow for handling conflicting requests", since not = only > > > does the last sentence of the paragraph give a pointer to a specified > > > behavior in case of conflicts, but we also mention it in a couple oth= er > > > places (e.g., the bottom of page 43). > > > > [Med] The specified behavior is a default behavior, not a recommended o= ne. >=20 > In effect a default is a recommendation, though -- a recommendation for > what to do if you don't know any better. Perhaps "it is out of scope of > this specification to provide guidance on how conflicting requests may be > safely handled, with the default behavior being to reject such requests"? [Med] I went for this updated text: =20 DOTS servers SHOULD support a configuration parameter to indicate the behavior to follow when a conflict is detected (e.g., reject all, reject the new request, notify an administrator for validation). Section 7.2 specifies a default behavior when no instruction is supplied to a DOTS server. >=20 > > I update this text: > > > > If the request is conflicting with an existing filtering installed b= y > > another DOTS client of the domain, and absent any local policy, the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > That helps (maybe the "and" is not even needed?). Do you want to do a > sweep for other places where the text talks about 409 responses? [Med] OK. >=20 > > DOTS server returns "409 Conflict" status-line to the requesting DOT= S > > client. The error-tag "resource-denied" is used in this case. > > > > > > > > Also in that paragraph, it's unclear that a 2119 SHOULD is appropriat= e > for > > > "support a configuration parameter"; there's no interoperability > > > considerations for having or not having such a configuration knob. > > > > [Med] This is important for interoperability (or at least for ensuring = a > deterministic behavior). E.g., during service subscription a technical cl= ause > may be negotiated out of band how to deal with conflicts from clients of = the > same domain. >=20 > It seems that the default behavior of disallowing conflicts would always = be > interoperable, but I'm happy to leave this as-is for now. >=20 > > > > > > Section 3.3 NAT Considerations have "high overlap" with the > > > text at the end of the signal-channel's "Design Overview". At a mini= mum > we > > > should diff them and enforce convergence, but do we want to consider = just > > > having one refer to the other? > > > > [Med] Makes sense. Section 3.3 is now deleted and replaced with this NE= W > text: > > > > NAT considerations for the DOTS data channel are similar to those > > discussed in Section 3 of [I-D.ietf-dots-signal-channel]. >=20 > Cool, thanks. >=20 > > > > > > Section 3.5 > > > > > > I had to read up on RESTCONF and NETCONF while reviewing this, but fr= om > > > what I've seen so far, the "error-severity" field is only present in > > > NETCONF and not RESTCONF. If so, then we shouldn't need to talk abou= t it > > > here, since we use RESTCONF exclusively. I also couldn't find whethe= r > > > there's a registry that we should add the "loop-detected" error-tag t= o. > > > Can anyone here help me out? > > > > > > > [Med] We used the template in https://tools.ietf.org/html/rfc6241#appen= dix- > A because the errors in 8040 are the ones imported from there. >=20 > Thanks for the pointer. It sounds like I'll need to ask around about th= is > one. [Med] I checked this with Martin Bjorklund. He confirmed that the error lis= t in 6241 is fixed in the protocol version. He recommended to go with app-t= ags. Our error will look like the following: OLD: error-tag: loop-detected error-type: transport, application error-severity: error error-info: : A copy of the Via header when the loop was detected. Description: An infinite loop has been detected when forwarding a requests via a proxy. NEW: error-app-tag: loop-detected error-tag: operation-failed error-type: transport, application error-severity: error error-info: : A copy of the Via header when the loop was detected. Description: An infinite loop has been detected when forwarding a requests via a proxy.=20 >=20 > > There is no registry for the errors; only a YANG module which is not > maintained by IANA. This is why no action is included in the IANA section= . > > > > > Section 4.2 > > > > > > Is there any plan/expectation for filtering/match rules for QUIC? It= is > > > probably premature to put anything in this document specifically, but > still > > > worth thinking about. > > > > [Med] Some of the existing fields can be already reused for QUIC (UDP, = port > number). There are few fields in the QUIC public header that are availabl= e > (public flags, CID, version). A match on the first N bytes of the UDP pay= load > can be considered but I do think this is not mature enough. > > > > The key point is that our module is extensible. >=20 > Indeed. >=20 > > > > > > The order in which the leaves appear in the "capabilities/ipv6" and > > > "capabilities/tcp" subtrees do not match the order they appear in the= ACL > > > subtree itself; it would be good to keep the order consistent. > > > > [Med] Fixed. > > > > FWIW, the order in capabilities/* follows the order of the fields as th= ey > appear in the header. We don't have a control on the ACL order because we= are > reusing an external module. >=20 > Ah, good to know. >=20 > > > > > > We don't really say much about what the semantis of the "port-range" > > > capabilities are; is that supposed to indicate any port-matching abil= ity > at > > > all, or specifically the low-to-high range matching, or also the > "operator" > > > options? > > > > [Med] Updated as follows: > > > > OLD: > > "Support of filtering based on a port range."; > > > > NEW: > > > > "Support of filtering based on a port range. > > > > This includes filtering based on a source port range, > > destination port range, or both. All operators > > (i.e, less than or equal, greater than or equal, equal to= , > > and not equal to) are supported."; >=20 > Thanks! >=20 > > > > > > Section 4.3 > > > > > > We define an "operator" typedef that is rather different from that fr= om > > > netmod-acl-model. Do we want to use a different name to aid > > > disambiguation? ("bitmask-operator" comes to mind as an option.) > > > > [Med] It is not recommended in yang to use prefixes to disambiguate nod= es. > The disambiguation is ensured by the context/position in the tree. For > example, this is why we are using name and not acl-name or ace-name, etc.= I > will leave the text as it is. >=20 > For names this makes natural sense to me, but this question is about a > typedef. I have less clear of a picture for how typedefs are or are not > namespaced (is it just per-module?). >=20 [Med] They are namespaced. For example:=20 type operator; is about the operator defined in the module itself. But, if we use:=20 type packet-fields:operator; this means the operator is the one imported from ietf-packet-fields. > > > > > > typedef fragment-type { > > > type bits { > > > bit df { > > > position 0; > > > description > > > "Don't fragment bit for IPv4. > > > This bit must be set to 0 for IPv6."; > > > > > > Set to zero by whom? What should the receiver do if it is set otherw= ise? > > > > > > > [Med] In IPv6, fragmentation is only done by the source. Hence, this va= lue > for IPv6. A fragment-type with the first bit set will be discarded by the > server. >=20 > I was looking for a few more words in the text, like "must be set to 0 wh= en > it appears in an IPv6 filter". [Med] OK. >=20 > > > What are the semantics if (either or both of target-fqdn and target-u= ri) > > > and target-prefix are specified? (I suppose maybe this could be cove= red > in > > > Section 6.1 when we say that at least one is required in ACL-creation > > > requests.) > > > > [Med] The resulting IP prefixes/addresses will be bound to the alias. A= dded > the following in Section 6.1: > > > > If more target-* clauses (e.g., 'target-prefix' and 'target-fqdn') > > are included in a POST or PUT request, the DOTS server binds all > > resulting IP addresses/prefixes to the same resource. > > > > > > > > The units for the "rate-limit" node should be specified in the YANG > module > > > and not in the description of how to install filtering rules. > > > > [Med] Added "units" to the YANG module. > > > > > > > > list dots-client { > > > key "cuid"; > > > description > > > "List of DOTS clients."; > > > leaf cuid { > > > type string; > > > description > > > "A unique identifier that is randomly generated by > > > a DOTS client to prevent request collisions."; > > > > > > I don't think "randomly generated" is really correct here. > > > > [Med] Changed to: > > > > "A unique identifier that is generated by a DOTS client > > to prevent request collisions."; > > > > > > > > The "capabilities/icmp/rest-of-header" description should be more cle= ar > > > that (per draft-ietf-netmod-acl-model) it is supposed to match both t= he > > > ICMP four-byte field and the ICMPv6 message body. > > > > [Med] OK. > > > > > > > > Section 5.1 > > > > > > It may be worth reiterating that (per the signal-channel doc) gateway= s > may > > > rewrite the 'cuid'. > > > > [Med] OK: > > > > As a reminder, DOTS gateways may rewrite the 'cuid' used by peer DOT= S > > clients (Section 4.4.1 of [I-D.ietf-dots-signal-channel]). > > > > > > > > When POST is used to create a dots-client resource, how does the clie= nt > > > know the path of the created resource (to be used for subsequent REST= CONF > > > requests)? (I assume it is supposed to just use the submitted 'cuid'= , > but > > > we need to explicitly say this. This also seems to render much of th= e > > > distinction between POST and PUT moot, for our usage, though I do not > > > propose any change to the text.) > > > > [Med] The procedure to determine the root path is recalled in Section 3= .1, > then normal RESTCONF operation is followed. > > > > > > > > The DOTS gateway, that inserted a 'cdid' in a PUT request, MUST st= rip > > > the 'cdid' parameter in the corresponding response before forwardi= ng > > > the response to the DOTS client. > > > > > > Why does this apply only to PUT and not POST? > > > > [Med] Because RFC8040 says the following: > > > > If the POST method succeeds, a "201 Created" status-line is returned > > and there is no response message-body. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > Whoops, I clearly missed that part. Thanks for calling it out. >=20 > > > > > > Section 6.1 > > > > > > DOTS clients within the same domain can create different aliases f= or > > > the same resource. > > > > > > My reading of this text is that client A can create alias "foo" for I= P > > > prefix 128.0.1.5/31 and clinet B can create alias "bar" for the same = IP > > > prefix, and that DOTS supports that process. (Just to confirm that t= he > > > text is saying what it's intended to.) > > > > [Med] Yes. > > > > I do wonder if we want to say > > > something about whether alias names need only be unique per 'cuid' or= in > > > some more global fashion. (Having a global uniqueness property is > perhaps > > > convenient in order to interface with non-DOTS mechanisms for queryin= g > > > aliases, or for the DOTS server to interact with network filtering > > > appliances.) > > > > [Med] The specification does require uniqueness per cuid: > > > > | +--rw aliases > > | | +--rw alias* [name] > > | | +--rw name string > > > > We don't have a requirement for uniqueness per domain or globally. > > > > If such requirement arise, the semantic/logic for creating those aliase= s > can be handled out of band. >=20 > Ok. >=20 > > > > > > Figure 16 puts double-quotes around "string" in the pseudo-schema, wh= ich > > > feels weird to me. > > > > [Med] This is also what we have done for other figures , e.g., 11. The > intent is to use a scheme-like message body while trying to preserve JSON > compliance. > > > > > > > > target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An > > > FQDN is the full name of a resource, rather than just its > > > hostname. For example, "venera" is a hostname, and > > > "venera.isi.edu" is an FQDN [RFC1983]. Refer to > > > [I-D.ietf-dnsop-terminology-bis] for more details. > > > > > > I don't think this text is particularly well-aligned with RFC 8499 an= d > > > would suggest trimming it substantially and just pointing to that RFC= . > > > > [Med] Done. > > > > > > > > If the request is missing a mandatory attribute or its contains an > > > invalid or unknown parameter, "400 Bad Request" status-line MUST b= e > > > returned by the DOTS server. The error-tag is set to "missing- > > > attribute", "invalid-value", or "unknown-element" as a function of > > > the encountered error. > > > > > > This text seems to preclude any future extension that adds new error > tags; > > > is this intended? > > > > [Med] Those errors are only about the tree failure cases called in the > first sentence. > > > > > > > > Section 7.1 > > > > > > A DOTS client which issued a GET request to retrieve the filtering > > > capabilities supported by its DOTS server, SHOULD NOT request for > > > filtering actions that are not supported by that DOTS server. > > > > > > What is the server behavior if the client ignores this SHOULD NOT? > > > > [Med] This is covered by this text: > > > > If the request is missing a mandatory attribute or > > contains an invalid or unknown parameter (e.g., a match field not > > supported by the DOTS server), "400 Bad Request" status-line MUST be > > returned by the DOTS server in the response. >=20 > sounds good. >=20 > > > > > > Figure 23 shows an example of a response received from a DOTS serv= er > > > which only supports the mandatory filtering criteria listed in > > > Section 4.1. > > > > > > This seems inaccurate, as the mandatory filtering criteria exlude the > > > rate-limit among others. > > > > [Med] rate-limit is an action, not a filtering criteria. > > > > > > > > Section 7.2 > > > > > > activation-type: Indicates whether an ACL has to be activated > > > (immediately or during mitigation time) or instantiated without > > > being activated (deactivated). Deactivated ACLs can be activat= ed > > > using a variety of means such as manual configuration on a DOTS > > > server or using the DOTS data channel. > > > > > > Is this done by the data channel or the signal channel? > > > > [Med] Yes, but this is not supported in the base signal-channel spec. T= his > is the done using the filtering control feature (draft-nishizuka-dots-sig= nal- > control-filtering). This is why signal channel is not listed after "such = as". >=20 > Okay. (I was literally just wondering if this was a typo.) >=20 > > > > > > If this attribute is not provided, the DOTS server MUST use > > > 'activate-when-mitigating' as default value. > > > > > > Why do we specify default values here instead of in the YANG module? > > > > [Med] There is no default statement for enumeration. To solve this, a n= ew > type is defined in the module (activation-type). This type is then used f= or > the activation-type leaf with a default value set to activate-when- > mitigating. >=20 > That's a clever workaround! >=20 > > The change in tree diagram is (no need to insert the code here): > > > > OLD: > > | +--rw activation-type? Enumeration > > > > NEW: > > | +--rw activation-type? activation-type > > > > > > > > > > Filters that are activated only when a mitigation is in progres= s > > > MUST be bound to the DOTS client which created the filtering ru= le. > > > > > > Other filters do not need to be bound to the DOTS client that created > them? > > > > [Med] They are...but those filters are already enforced because they ar= e > immediate. >=20 > The wording here is still weird, though -- by calling out the > delayed-activation filters it implies that immediate-activation filters a= re > excluded from the statement, but we know that immediate-activation filter= s > also have the same property. So I'm not entirely sure exactly what > information this sentence is intended to call out. [Med] When a mitigation is in progress, only the filters bound to the clien= t which triggered the mitigation have to be activated. 'activate-when-mitig= ating' filters of other clients of the same domain should not be activated:= =20 I changed the text as follows: OLD: Filters that are activated only when a mitigation is in progress MUST be bound to the DOTS client which created the filtering rule. NEW: When a mitigation is in progress, the DOTS server MUST only activate 'activate-when-mitigating' filters that are bound to the DOTS client which triggered the mitigation. >=20 > > > Wouldn't we still want to remove them when the dots-client resource i= n > > > question is deleted? > > > > [Med] This is supposed to be done by the client itself. For amnesiac > clients, we do have the following: >=20 > Oh. I think I was remembering Section 5.2's "resources bound to this DOT= S > client will be deleted by the DOTS server" and assuming it applies to the > filters associated with that client. >=20 > > In order to avoid stale entries, a lifetime is associated with alias > > and filtering entries created by DOTS clients. Also, DOTS servers > > may track the inactivity timeout of DOTS clients to detect stale > > entries. >=20 > This is probably enough to ensure safe operation without the above, thoug= h, > hmm... >=20 > > > > > > destination-ipv4-network: The destination IPv4 prefix. DOTS serv= ers > > > [...] > > > This is a mandatory attribute in requests with an 'activation- > > > type' set to 'immediate'. > > > > > > I somehow thought there were YANG attributes that could indicate this > > > conditional requirement in the module itself, though I am hardly a YA= NG > > > expert. > > > > [Med] We are reusing fields from ietf-netmod-acl, it is not easy to > manipulate the fields as we would want. >=20 > Okay. >=20 > > > > > > The error-tag is set= to > > > "missing-attribute", "invalid-value", or "unknown-element" as a > > > function of the encountered error. > > > > > > Same comment as above about (non-)extensibility. > > > > [Med] Idem as above. > > > > > > > > Section 7.3 > > > > > > I see that the "test-acl-*" and "test-ace-*" acl and ace objects in t= hese > > > examples do in fact use different names for the semantically differen= t > > > objects, but perhaps we could help the reader's eye and use strings w= ith > a > > > larger Hamming distance? (I thought they were all the same on my fir= st > > > read.) > > > > [Med] Fixed. > > > > > > > > (I also am a little confused at why the "ace" "name" field is conside= red > a > > > non-config field, in Figure 31, but this seems more likely to be my > > > confusion than an error in the document.) > > > > [Med] This is because the name is the key of the ace list. > > > > RFC8040 says the following: > > > > To retrieve only the non-configuration child resources, the "content= " > > parameter is set to "nonconfig". Note that configuration ancestors > > (if any) and list key leafs (if any) are also returned. >=20 > Thanks for the pointer. >=20 > > > > > > Section 8 > > > > > > o DOTS server MUST NOT enable both DOTS data channel and direct > > > configuration to avoid race conditions and inconsistent > > > configurations arising from simultaneous updates from multiple > > > sources. > > > > > > o DOTS agents SHOULD enable DOTS data channel to configure aliase= s > > > and ACLs, and only use direct configuration as a stop-gap > > > mechanism to test DOTS signal channel with aliases and ACLs. > > > Further, direct configuration SHOULD only be used when the on-p= ath > > > DOTS agents are within the same domain. > > > > > > Doesn't all this discussion of "direct configuration" conflict with t= he > > > "MUST NOT" in the first bullet point? > > > > [Med] The second bullet is about controlled testing of the *signal chan= nel* > with aliases/acls communicated by the data channel. >=20 > Whoops, my misread. >=20 > > > > > > Section 10 > > > > > > Generally with the security considerations template for YANG modules,= we > > > need to list out all the nodes considered sensitive and the consequen= ces > of > > > writing(/reading) each one in turn. > > > > > > > [Med] The text does already call out those that are specific to this > document. For other nodes, we do have this text: > > > > "YANG ACL-specific security > > considerations are discussed in [I-D.ietf-netmod-acl-model]." > > > > I think we are OK. >=20 > I would suggest adding a new sentence in the "All data nodes defined" > paragraph about "This module reuses YANG structures from > [I-D.ietf-netmod-acl-model], and the security considerations for those > nodes continue to apply for this usage.", since that text is at the other > end of the section and it's otherwise hard to make a linkage between them= . >=20 [Med] OK. > Thanks, >=20 > Ben From nobody Fri Feb 15 02:22:32 2019 Return-Path: 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 4F04C130F82; Fri, 15 Feb 2019 02:22:30 -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 oeMwq4NskrQ9; Fri, 15 Feb 2019 02:22:25 -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 A26DB12D7F8; Fri, 15 Feb 2019 02:22:24 -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=1550226032; 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-ms-exchange-purlcount: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=M 0TpSxN39qcpdTg4R1yC8caAN3Cea5kDgO/oiDZ7/t s=; b=JAfvmJZpLAMpql6dwcH69Pzc2uyDIPAfwvemLQUHhxza dDFvF1kCUq3UUFrbpPf3xDYA1IompSo2jEWfqTeeOYAQrCkrRU jwr6zWxpRomV9A0uC0dXhTnvKYqc7DhpXCofXJfqhUFQyrzw1c YPkGGNiPOVpZzUG7PwZLqum/Ek0= 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 530a_9d30_109d5c50_9a0d_4a43_be03_3c8bd185b0f1; Fri, 15 Feb 2019 03:20:31 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Feb 2019 03:22:09 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 15 Feb 2019 03:22:09 -0700 Received: from NAM05-DM3-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; Fri, 15 Feb 2019 03:22:08 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2887.namprd16.prod.outlook.com (20.178.234.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Fri, 15 Feb 2019 10:22:06 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1622.016; Fri, 15 Feb 2019 10:22:06 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , "mohamed.boucadair@orange.com" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: [Dots] AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxHIQxeBzH579tUeqIgtYPD9bE6XfqtyAgADaR+A= Date: Fri, 15 Feb 2019 10:22:05 +0000 Message-ID: References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> In-Reply-To: <20190214191707.GM56447@kduck.mit.edu> 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: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4dc8e2c-eade-4510-1e8f-08d6932f6f5a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2887; x-ms-traffictypediagnostic: BYAPR16MB2887: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyODg3OzIzOlc4cW9OK1pZaC9uenlxd3lvbUV1blc2dWhU?= =?utf-8?B?M2FBU2lEVHNVMGNOUGordWNxZUpMTGFQNUZDbzJFNzJBS1JGbnFaQndjeXF0?= =?utf-8?B?RWl6UVhZUHNMR1c0VTVybGRMQklKK3UrY3pTRDkvU0kyYWJuMTJQaU45M0NP?= =?utf-8?B?UW8zK3ZGTnVrSUFxajFhVW1NWjZGaTdQcUlMOGh5bTBXU0l5S29Gam5qdkFU?= =?utf-8?B?cWJEMGtlVE9ydkY1WG5BUmJ2NzBsTU9venJWMXZMQVV2cjltTmJidWRtcVZn?= =?utf-8?B?Z1BBZURUdFMyVmo5RmRIbUNiN3hmb2dabVo2elRqTEFNL2hIMFVWYVJsdEFC?= =?utf-8?B?NnBtNXhmN0ZWMmttNkhBMmV5eER5bDhEcGlPSEk5Yzg0RGovblErK01hYWY2?= =?utf-8?B?R2dGRDVwdXptdFdaU2Q4UVFaUW1OZTFEZ29TMlQrWWlrNWVaMDBmWjdTOXRK?= =?utf-8?B?UkRjbDdSZGxPRHpOWTBWUjFURExaSFM1VTJwSEVPS1ZjaGU5SE1pM3Nlcm5V?= =?utf-8?B?SU1NbE10K1Zpa2xzMHBQV3NucTBOUDhwMldnaEpSZWFUUnIra3BRaWNWVWxj?= =?utf-8?B?NGtYNVBkOWN0R1B4dnZKTGpvRjl3RkcxNk5YK1duRzYxZ0dFb3dGSUs2cnZV?= =?utf-8?B?cHNUWVhmVks5UHVnSExjei9zRkxlNUdpaXRDU3N3R1BOK2VIUjVsRkRPRG9Z?= =?utf-8?B?RWxlRWx4WXZ6aWg5bCtWNGRVZU1VUkRyS1RRcGlPY1I4ZlJDYnJjLzE5UlJR?= =?utf-8?B?TjJRSWlja2JncE9GYWpsd1VQZGxaZlVmc09SS3RjenE1TTBBMWszQXRsU01n?= =?utf-8?B?b2FCRUJ6VFZwdlVzTFdsZ2xBL3ZVVjgreThKZE14ZGdCdGRkV3Jub3g1cnBE?= =?utf-8?B?ZTR5eEdGZWJMWmgvZzNVR0hIa3hXdGpIcjFrM0kwQ1g0Q3VLSU1ubGdYU1Yv?= =?utf-8?B?SDRSTU1DUjNoU3FsRUN0VFBYOHdpdTNxbmJpQkV2ZWt2UXQ0djd1bDlqektu?= =?utf-8?B?NjY1bVRNU3FlTXZvWmVWWlZWcWFWYVhLdVg4aU44TTdWT1NhMXBOeWcxdXlp?= =?utf-8?B?Y0FGM1ZaUVBkMjNoT1ZmQUtDRmgyZ0VQMTBFZzBzMWNUVmNVemdEc1ZMMThz?= =?utf-8?B?alJyZVQwcTVmWTYzdUxRakRwMVF4MEpnaEpSQ0l0dlhvbUMrWXpuM2VpY0Zt?= =?utf-8?B?SElhZzUzWGZpZzR6UWpNSE50d1hBV3RLZEsxZ21ZSUI5OUo3UUhpR0NQVWt4?= =?utf-8?B?azNHYWFnMXVmYmRLVGhHV1puUnA3Y05WMzJvQkp4RHpSWnpsdkt4UGJKYzBM?= =?utf-8?B?djJnMnpqSXU5dGhDWFJvOWlON1NkU1BjdDRseWV6TkhxaERQSUVxa25BUzJC?= =?utf-8?B?OU54SmpicTM2b0V0QUVWTXFxV0phWGJyWE9rYkVRYkw3SkJzdWU5NG9MVjBs?= =?utf-8?B?cUtmcHNHUTdrS2N0VDBoYkRXN2RTcDE3ZmZCOTI4dkl4bWZXV0RDVlRhMHYz?= =?utf-8?B?cEQ1cjJPaTljTUJpU0ZnMXVkK3dHOHp1Mzd4b1NJZ3I4WktlN2c0YUxsNFI0?= =?utf-8?B?ajJsci9zUnhOUDNSb08wVTRtb1U5d2M3SmtmUzlmNWpIdDBKUU9HN3ZNUzZi?= =?utf-8?B?QVJOa0RYMTRzV0FkYzNFZ1ZLc1JhY0RYNHhoWUFyVEExemFvNC8vOEprS3Rl?= =?utf-8?B?b3ZaaGFDZEJEazQ4Y2FsRWhYdWM4QWM5SlJCays1d3lqSTZWR0RGaVVUNUtZ?= =?utf-8?B?M0VJeTF1U1M2bjNsMXlTdk1Vc2o4ZjN3UVlDNFlpdXRGclk1a3Q0dU5HaVhY?= =?utf-8?B?Z0FYVEFvM3U5eUxiY1dRVENydTR4TnE1ZXJpNW1TazRjV1pWbTd0YjM2QnVB?= =?utf-8?B?MGtIaElvWmo2Vk93Ym1NYkZmV0hCcGVWUUliRVZQQU1FNit0SE1zTkZFTXph?= =?utf-8?B?bWNVblUzeGE4V0tFdDV5OUlWcHJOL1pmV0xVZFVIa29TZmVOU08rc2EwODUy?= =?utf-8?B?UEdqMm5tV0h4TGlUTnpYV2dqOFkzbCtJWnV4QmdkMXBPeEVtT2ZqUVZBQUdq?= =?utf-8?B?cnhCQ1F1SnlUN25tNnpmSS8wQmZTdUt3K2M4czU3SHZDS2tYOFBVMVRKR0I3?= =?utf-8?Q?7OiTp047lPxO9onUXLxM91PJNR4Y7DEbjwvyqlhn/qSI?= x-microsoft-antispam-prvs: x-forefront-prvs: 09497C15EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39850400004)(346002)(136003)(376002)(32952001)(13464003)(55784004)(51444003)(52314003)(51914003)(199004)(189003)(80792005)(6246003)(6506007)(53546011)(97736004)(6116002)(25786009)(33656002)(4326008)(6436002)(81156014)(81166006)(66066001)(2171002)(53936002)(2906002)(55016002)(229853002)(8936002)(105586002)(106356001)(8676002)(966005)(53946003)(6306002)(3846002)(316002)(54906003)(11346002)(486006)(305945005)(478600001)(74316002)(71190400001)(110136005)(7736002)(7696005)(446003)(26005)(76176011)(102836004)(5024004)(256004)(99286004)(86362001)(71200400001)(66574012)(9686003)(186003)(68736007)(2501003)(30864003)(14454004)(476003)(72206003)(14444005)(85282002)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2887; H:BYAPR16MB2790.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: nViedVwyTLvbsYXCB9p+ifba54Ts/8QwkHwATwm5tOAZ2OY0+9MbtBEhZGCnRMugWZD/4KrSpYz5IM90gGZoOyA150z6603cGD+Nn8j2hD7YrEQLKSd1FCIFABZXwT5SI0phpHzRzVxVBRa4PR25GT5hJkahPxUfcz9r3WTfugeVvpy5xIz1XuXuag5wYOMPiEXSTkS7EJwD5Hj5O8ltqxrNKreTQH+doC61VUpPEf11i6xKcHDIZeakMO/Ws++zTZpFIzuiIpM080FAR4sNJ7jjBpXQQhyE63wRg++mPe/8DczOfyl3akMgmNQf5kjReIJwhNZ8UN35MXdlqBuGT0IeNeGEQo4cmDsFUGkiLgPLW1sE0+zcaHUQRM/uKo31aPCFlKkdBp1jXIganKKOYzsfjI180ckLGONkVwLsCxE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f4dc8e2c-eade-4510-1e8f-08d6932f6f5a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 10:22:05.8335 (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: BYAPR16MB2887 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6483> : inlines <7018> : streams <1813098> : uri <2796685> Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 10:22:31 -0000 UGxlYXNlIHNlZSBpbmxpbmUgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogRG90cyA8ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQmVuamFtaW4gS2Fk dWsNCj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNSwgMjAxOSAxMjo0NyBBTQ0KPiBUbzogbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBDYzogZG90c0BpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1kb3RzLWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RvdHNdIEFEIHJl dmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI1DQo+IA0KPiBUaGlzIGVtYWls IG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGlj ayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBz ZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEhpIE1lZCwNCj4gDQo+ IE9uIFRodSwgRmViIDE0LCAyMDE5IGF0IDAyOjMxOjI2UE0gKzAwMDAsIG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20NCj4gd3JvdGU6DQo+ID4gSGkgQmVuLA0KPiA+DQo+ID4gVGhhbmsgeW91 IGZvciB0aGUgcmV2aWV3Lg0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiBD aGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiA+ID4gRGXCoDogQmVuamFtaW4gS2FkdWsgW21haWx0bzprYWR1a0BtaXQuZWR1XSBFbnZvecOp wqA6IG1lcmNyZWRpIDEzDQo+ID4gPiBmw6l2cmllciAyMDE5IDE3OjQ2IMOAwqA6IGRyYWZ0LWll dGYtZG90cy1kYXRhLWNoYW5uZWxAaWV0Zi5vcmcNCj4gPiA+IENjwqA6IGRvdHNAaWV0Zi5vcmcN Cj4gPiA+IE9iamV0wqA6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVs LTI1DQo+ID4gPg0KPiA+ID4gVGhpcyBpcyBteSBBRCByZXZpZXcgb2YgdGhlIC0yNQ0KPiA+ID4N Cj4gPiA+IEkgc2VlIHRoYXQgTWVkIG1hZGUgYSBjb21taXQgb24gZ2l0aHViIHRoYXQgcHJlZW1w dGl2ZWx5IGFkZHJlc3NlZA0KPiA+ID4gYXQgbGVhc3Qgb25lIG9mIHRoZXNlIGNvbW1lbnRzLCBi dXQgd2lsbCB0cnVzdCB0aGUgYXV0aG9ycyB0byBkbyB0bw0KPiA+ID4gdGhlIHJpZ2h0IHRoaW5n IHdpdGggYW55dGhpbmcgaW4gaGVyZSB0aGF0J3Mgc3RhbGUuDQo+ID4gPg0KPiA+ID4gQSBoYW5k ZnVsIG9mIGdlbmVyaWMgYW5kL29yIGhpZ2gtbGV2ZWwgY29tbWVudHMgYmVmb3JlIHRoZQ0KPiA+ ID4gc2VjdGlvbi1ieS1zZWN0aW9uIG5pdHR5LWdyaXR0eSBzdHVmZi4NCj4gPiA+DQo+ID4gPiBU aGUgYXV0aG9yIGNvdW50IGlzIGxhcmdlICg3KTsgUkZDIDczMjIgbm90ZXMgdGhhdCB0aGUgc3Ry ZWFtDQo+ID4gPiBhcHByb3ZlciAoaS5lLiwgdGhlIElFU0cpIHdpbGwgYXNrIHF1ZXN0aW9ucyBp ZiB0aGUgY291bnQgaXMgbW9yZQ0KPiA+ID4gdGhhbiBmaXZlLiAgV2hhdCBzaG91bGQgSSB0ZWxs IHBlb3BsZSB3aGVuIHRoZXkgYXNrPyAgKFRoZSBhdXRob3JzDQo+ID4gPiBhcmUgbGlzdGVkIGFs c28gaW4gdGhlIFlBTkcgbW9kdWxlIGl0c2VsZiwgaWYgY2hhbmdlcyBhcmUgbWFkZS4pDQo+ID4N Cj4gPiBbTWVkXSBBY3R1YWxseSwgdGhlIHNldCBvZiBjby1hdXRob3JzIG9mIHRoZSBZQU5HIG1v ZHVsZSBpcyBub3QgZXhhY3RseSB0aGUNCj4gc2FtZS4NCj4gDQo+IFdob29wcywgbXkgYmFkIGZv ciBub3QgY2hlY2tpbmcuDQo+IA0KPiA+IEFueXdheSwgaW4gb3JkZXIgdG8gY29tcGx5IHdpdGgg dGhlIHJ1bGVzIGFuZCBhdm9pZCBzcGVuZGluZyBleHRyYSBjeWNsZXMgb24NCj4gdGhpcywgd2Ug YWRkZWQgYSBuZXcgc2VjdGlvbiBjYWxsZWQgIkNvbnRyaWJ1dGluZyBBdXRob3JzIi4gTmV2ZXJ0 aGVsZXNzLCB0aGUNCj4gc2V0IG9mIGF1dGhvcnMgaXMgbm90IG1vZGlmaWVkIGluIHRoZSBZQU5H IG1vZHVsZS4NCj4gDQo+IFRoYW5rcy4gIChUbyBiZSBjbGVhciwgSSdtIGhhcHB5IHRvIGdvIHRv IGJhdCBmb3IgZXZlcnlvbmUgd2l0aCB0aGUgSUVTRyBmb3IgdGhpcw0KPiBzb3J0IG9mIHRoaW5n LCBJIGp1c3QgbmVlZCBhbiBhcmd1bWVudCB0byBwcmVzZW50IHRoYXQncyBub3QgbWUgbWFraW5n IHRoaW5ncw0KPiB1cC4pDQo+IA0KPiBJIGRvbid0IGtub3cgb2YgYSBzcGVjaWZpYyBwb2xpY3kg Zm9yIFlBTkcgbW9kdWxlIGF1dGhvcnNoaXAsIHNvIHRoYXQgcGFydA0KPiBzaG91bGQgYmUgb2th eSBhcyBmYXIgYXMgSSBrbm93Lg0KPiANCj4gPiA+DQo+ID4gPiBDYW4gc29tZW9uZSAodGhlIHNo ZXBoZXJkPykgY29uZmlybSB0aGF0IGFuIGF1dG9tYXRlZCBzeW50YXggY2hlY2tlcg0KPiA+ID4g aGFzIHJ1biBvdmVyIHRoZSBKU09OIGluIGV4YW1wbGVzPw0KPiA+ID4NCj4gPiA+IFRoZSBjb25j ZXB0IG9mICJET1RTIGNsaWVudCBkb21haW4iIGlzIGJlaW5nIHVzZWQgZm9yIGFjdHVhbA0KPiA+ ID4gcHJvdG9jb2wgcHVycG9zZXMgaGVyZSAobW9zdCBub3RhYmx5IGFzIGEgYm91bmQgb24gdGhl IHByZWZpeChlcykNCj4gPiA+IHRoYXQgYSBjbGllbnQgY2FuIHJlcXVlc3QgbWl0aWdhdGlvbiBm b3IsIGJ1dCBJIGRvbid0IHJlbWVtYmVyDQo+ID4gPiBzZWVpbmcgYSBmb3JtYWwgZGVmaW5pdGlv biBmb3IgaG93IGFueSBET1RTIGFjdG9yIHdvdWxkIGtub3cgdGhlIHNwZWNpZmljDQo+IGJvdW5k cyBvZiBzdWNoIGEgY2xpZW50IGRvbWFpbi4NCj4gPiA+IElzIHRoZXJlIHRleHQgc29tZXdoZXJl IHRoYXQgSSBtaXNzZWQgdGhhdCB3ZSBjYW4gcG9pbnQgdG8sIG9yIHdpbGwNCj4gPiA+IHdlIG5l ZWQgdG8gYWRkIHNvbWU/DQo+ID4NCj4gPiBbTWVkXSBCb3RoICJET1RTIGNsaWVudCBkb21haW4i IGFuZCAiRE9UUyBzZXJ2ZXIgZG9tYWluIiBhcmUgdXNlZCBpbiB0aGUNCj4gYXJjaGl0ZWN0dXJl IGRyYWZ0LiAiRE9UUyBjbGllbnQncyBkb21haW4iIGFuZCAiRE9UUyBzZXJ2ZXIncyBkb21haW4i IGFyZSBhbHNvDQo+IHVzZWQgaW4gdGhlIGFyY2hpdGVjdHVyZSBhbmQgcmVxdWlyZW1lbnRzIEkt RC4NCj4gPg0KPiA+IElmIGEgZm9ybWFsIGRlZmluaXRpb24gaXMgbmVlZGVkLCBJIHByZWZlciB0 aGlzIHRvIGJlIGRvbmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBvcg0KPiB0aGUgcmVxdWlyZW1lbnRz IEktRC4NCj4gDQo+IEkgdGhpbmsgaXQgd291bGQgYmUgYSBzb21ld2hhdCBiZXR0ZXIgZml0IGlu IHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQsIGp1c3QgdG8NCj4gbm90ZSB0aGF0IHRoZSAiZG9t YWluIiBpcyBzb21ldGhpbmcgdGhhdCBjYW4gY29uY3JldGVseSBiZSBkZW1hcmNhdGVkIGJ5IElQ DQo+IGFkZHJlc3Nlcy9wcmVmaXhlcyAoYXMgb3Bwb3NlZCB0byBhIG1vcmUgbmVidWxvdXMgY29u Y2VwdCB0byBhaWQgY29uY2VwdHVhbA0KPiB1bmRlcnN0YW5kaW5nKS4NCg0KRE9UUyBjbGllbnQg ZG9tYWluIGlzIGFscmVhZHkgZXhwbGFpbmVkIGluIFNlY3Rpb24gMi4yLjIgb2YgdGhlIGFyY2hp dGVjdHVyZSBkcmFmdCBhcyBmb2xsb3dzOg0KDQo8c25pcD4NCiAgIFRoZSBET1RTIHNlcnZlciBl bmZvcmNlcyBhdXRob3JpemF0aW9uIG9mIERPVFMgY2xpZW50cycgc2lnbmFscyBmb3INCiAgIG1p dGlnYXRpb24uICBUaGUgbWVjaGFuaXNtIG9mIGVuZm9yY2VtZW50IGlzIG5vdCBpbiBzY29wZSBm b3IgdGhpcw0KICAgZG9jdW1lbnQsIGJ1dCBpcyBleHBlY3RlZCB0byByZXN0cmljdCByZXF1ZXN0 ZWQgbWl0aWdhdGlvbiBzY29wZSB0bw0KICAgYWRkcmVzc2VzLCBwcmVmaXhlcywgYW5kL29yIHNl cnZpY2VzIG93bmVkIGJ5IHRoZSBET1RTIGNsaWVudCdzDQogICBhZG1pbmlzdHJhdGl2ZSBkb21h aW4sIHN1Y2ggdGhhdCBhIERPVFMgY2xpZW50IGZyb20gb25lIGRvbWFpbiBpcyBub3QNCiAgIGFi bGUgdG8gaW5mbHVlbmNlIHRoZSBuZXR3b3JrIHBhdGggdG8gYW5vdGhlciBkb21haW4uDQo8L3Nu aXA+DQoNCldlIGNhbiBhZGQgdGhlIGZvbGxvd2luZyBsaW5lIHRvIGV4cGxhaW4gaG93IHRoZSBE T1RTIHNlcnZlciBpZGVudGlmaWVzIHRoZSBET1RTIGNsaWVudCBkb21haW4gYXQgYSBwcm90b2Nv bCBsZXZlbDoNCg0KRE9UUyBzZXJ2ZXIgY2FuIGlkZW50aWZ5IHRoZSBET1RTIGNsaWVudCBkb21h aW4gZWl0aGVyIHVzaW5nIHRoZSAnY2RpZCcNCnBhcmFtZXRlciBvciB0aGUgY2xpZW50J3MgRE5T IG5hbWUgc3BlY2lmaWVkIGluIHRoZSBTdWJqZWN0IA0KQWx0ZXJuYXRpdmUgTmFtZSBleHRlbnNp b24ncyBkTlNOYW1lIHR5cGUgb3IgU1JWLUlEIGluIHRoZSBjbGllbnQNCmNlcnRpZmljYXRlLg0K DQpDaGVlcnMsDQotVGlydQ0KDQo+IA0KPiA+ID4NCj4gPiA+IFdlIGRvbid0IHNheSBtdWNoIGFi b3V0IHdoYXQgdmFsaWRhdGlvbiB0aGUgc2VydmVyIGRvZXMgb24gaW5wdXQNCj4gPiA+IGRhdGEs IGFuZCB3ZSBwcm9iYWJseSBzaG91bGQuICBGb3IgZXhhbXBsZSwgZG9lcyB0aGUgc2VydmVyIG5l ZWQgdG8NCj4gdmFsaWRhdGUgJ2N1aWQnDQo+ID4NCj4gPiBbTWVkXSBXZSBhdm9pZGVkIHRvIGJl IHJlZHVuZGFudCBoZXJlLiBUaGlzIGlzIGNvdmVyZWQgYnkgdGhpcyB0ZXh0Og0KPiA+DQo+ID4g IlRoaXMgYXR0cmlidXRlIGhhcyB0aGUgc2FtZQ0KPiA+ICAgICAgIG1lYW5pbmcsIHN5bnRheCwg YW5kIHByb2Nlc3NpbmcgcnVsZXMgYXMgdGhlICdjdWlkJyBhdHRyaWJ1dGUNCj4gPiAgICAgICBk ZWZpbmVkIGluIFtJLUQuaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsXS4iDQo+ID4NCj4gPiA+IGFu ZC9vciAnY2RpZCcgaW4gZG90cy1jbGllbnQtY3JlYXRpb24gcmVxdWVzdHM/DQo+ID4NCj4gPiBb TWVkXSBUaGlzIGlzIGNvdmVyZWQgYnkgdGhpcyB0ZXh0Og0KPiA+DQo+ID4gIlRoaXMgYXR0cmli dXRlIGhhcyB0aGUgc2FtZSBtZWFuaW5nLCBzeW50YXgsIGFuZCBwcm9jZXNzaW5nDQo+ID4gICAg ICAgcnVsZXMgYXMgdGhlICdjZGlkJyBhdHRyaWJ1dGUgZGVmaW5lZCBpbg0KPiA+ICAgICAgIFtJ LUQuaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsXSINCj4gDQo+IEkgZ3Vlc3MgSSdtIG1vc3RseSBq dXN0IGNvbmNlcm5lZCBhYm91dCBpZiB0aGVyZSdzIGFueXRoaW5nIHRoYXQgZG9lc24ndA0KPiB0 cmFuc2xhdGUgZGlyZWN0bHksIHNpbmNlIHRoZSBDb0FQIGFuZCBIVFRQIGNvbnN0cnVjdHMgd291 bGQgaGF2ZSB0byBkZXNjcmliZQ0KPiB0aGUgZm9ybWFsIHZhbGlkYXRpb24gaW4gc29tZXdoYXQg ZGlmZmVyZW50IHRlcm1zIChpLmUuLCBmb3IgY29uc2lzdGVuY3kNCj4gYmV0d2VlbiBVUkwgcGF0 aHMgYW5kIG1lc3NhZ2UgYm9kaWVzKS4gIEJ1dCBpbiBnZW5lcmFsIEknbSBoYXBweSB0byBhdm9p ZA0KPiByZWR1bmRhbmN5IGFzIHlvdSBkZXNpcmUuDQo+IA0KPiA+IEFuZCBvdGhlciBwYXJ0cyBp biB0aGUgdGV4dCBzdWNoIGFzOg0KPiA+DQo+ID4gICAgSWYgdGhlIHJlcXVlc3QgaXMgcmVjZWl2 ZWQgdmlhIGEgc2VydmVyLWRvbWFpbiBET1RTIGdhdGV3YXksIGJ1dCB0aGUNCj4gPiAgICBET1RT IHNlcnZlciBkb2VzIG5vdCBtYWludGFpbiBhICdjZGlkJyBmb3IgdGhpcyAnY3VpZCcgd2hpbGUg YSAnY2RpZCcNCj4gPiAgICBpcyBleHBlY3RlZCB0byBiZSBzdXBwbGllZCwgdGhlIERPVFMgc2Vy dmVyIE1VU1QgcmVwbHkgd2l0aCAiNDAzDQo+ID4gICAgRm9yYmlkZGVuIiBzdGF0dXMtbGluZSBh bmQgdGhlIGVycm9yLXRhZyAiYWNjZXNzLWRlbmllZCIuICBVcG9uDQo+ID4gICAgcmVjZWlwdCBv ZiB0aGlzIG1lc3NhZ2UsIHRoZSBET1RTIGNsaWVudCBNVVNUIHJlZ2lzdGVyIChTZWN0aW9uIDUp Lg0KPiA+DQo+ID4NCj4gPiAgIFdoYXQgYWJvdXQgdmFsaWRhdGluZyB0aGF0DQo+ID4gPiB0aGUg KGUuZy4pIEFDTCBuYW1lIGluIHRoZSBQVVQgVVJMIG1hdGNoaW5nIHRoZSBuYW1lIGluIHRoZSBi b2R5IG9mDQo+ID4gPiB0aGUgcmVxdWVzdD8NCj4gPg0KPiA+IFtNZWRdIFRob3NlIGFyZSBzdXBw b3NlZCB0byBiZSBjb3ZlcmVkIGZvbGxvd2luZyBSRVNUQ09ORiBiYXNlIHNwZWMuDQo+IA0KPiBJ cyB0aGlzIHN1cHBvc2VkIHRvIGJlIFJGQyA4MDQwIFNlY3Rpb24gMy41LjM/ICBJIGFtIG5vdCBz dXJlIHRoYXQgSSdtIHJlYWRpbmcNCj4gdGhhdCBhcyBjb3ZlcmluZyB0aGUgcHJvcGVydHkgSSB3 YW50IChhbmQgd2lsbCBkb3VibGUtY2hlY2sgaWYgeW91IGNvbmZpcm0gdGhhdCdzDQo+IHdoYXQg eW91IGhhdmUgaW4gbWluZCkuDQo+IA0KPiA+ICAgVGhlcmUgYXJlIHByb2JhYmx5IG90aGVycyBh cyB3ZWxsLg0KPiA+ID4NCj4gPiA+IFRoZSBleGFtcGxlcyBhbGwgdXNlICJIb3N0OiB7aG9zdH06 e3BvcnR9IiB3aGljaCBpcyBub3QgcmVhbGx5IGFuDQo+ID4gPiBleGFtcGxlIGJ1dCByYXRoZXIg YSB0ZW1wbGF0ZS4gIFNpbmNlIHRoZXkgYXJlIHN1cHBvc2VkIHRvIGJlDQo+ID4gPiBleGFtcGxl cywgd2Ugc2hvdWxkIHBpY2sgYSBjb25jcmV0ZSBob3N0bmFtZSAoYW5kIHBvcnQpIHRvIHVzZS4N Cj4gPg0KPiA+IFtNZWRdIEkgd2lsbCBjaGFuZ2Ugc29tZSBmaWd1cmVzIHRvICJleGFtcGxlLmNv bSIgYnV0IHdpbGwgbGVhdmUgaXQgZm9yDQo+IHNjaGVtYS1saWtlIGZpZ3VyZXMuDQo+IA0KPiBP ZiBjb3Vyc2UuDQo+IA0KPiA+ID4NCj4gPiA+IFRoZXJlIGlzLCBzaGFsbCB3ZSBzYXksIGEgImhp Z2ggZGVncmVlIG9mIG92ZXJsYXAiIGJldHdlZW4gU2VjdGlvbnMNCj4gPiA+IDUvNi83IGFuZCB0 aGUgWUFORyBtb2RlbCBmaWVsZCBkZXNjcmlwdGlvbnMuICBJIG1vc3RseSBhc3N1bWUgdGhhdA0K PiA+ID4gdGhlIFdHIGNvbnNpZGVyZWQgbGV0dGluZyB0aGUgWUFORyBtb2RlbCAoYW5kIHRoZSBj b3JlIFJFU1RDT05GDQo+ID4gPiBzcGVjKSBzdGFuZCBhbG9uZSB3aXRob3V0IHRoZSBhZGRpdGlv bmFsIGV4YW1wbGVzL3NwZWNpZmljYXRpb24gb2YNCj4gPiA+IHRoZSB1c2Ugb2YgUkVTVENPTkYg dG8gbWFuYWdlIGNsaWVudHMsIGFsaWFzZXMsIGFuZCBmaWx0ZXIgcnVsZXMsIHNvDQo+ID4gPiBJ IHdvbid0IHN1Z2dlc3QgdGhhdCB3ZSByZXZpc2l0IHRoZSBxdWVzdGlvbi4gIEJ1dCBJIGRvIHRo aW5rIHRoYXQNCj4gPiA+IGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21lIGV4cGxpY2l0IHRl eHQgYWNrbm93bGVkZ2luZyB0aGUNCj4gPiA+IG92ZXJsYXAgYW5kIHN0YXRpbmcgd2hpY2ggb25l IGlzIGF1dGhvcml0YXRpdmUuDQo+ID4NCj4gPiBbTWVkXSBGaXhlZC4NCj4gPg0KPiA+ID4NCj4g PiA+IFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgbWlzbWF0Y2ggYmV0d2VlbiB3aGV0aGVyIHRoZSBJ UHY2IEFDTCBzdWJ0cmVlDQo+ID4gPiB1c2VzICJ0dGwiIG9yICJob3BsaW1pdCIgLS0gRmlndXJl IDcgaGFzICJ0dGwiIGJ1dCB0aGUgcmVzdCBvZiB0aGUNCj4gPiA+IGRvY3VtZW50IHNlZW1zIHRv IChwcm9wZXJseSkgdXNlICJob3BsaW1pdCIuICBTb21lb25lIGVsc2Ugc2hvdWxkDQo+ID4gPiBk b3VibGUtY2hlY2sgdGhlIHJlbGV2YW50IHBsYWNlcywgdGhvdWdoLCBhcyBJJ20gbm90IHN1cmUg SSB3YXMNCj4gPiA+IGxvb2tpbmcgYXQgYWxsIG9mIHRoZW0gd2l0aCB0aGlzIGlzc3VlIGluIG1p bmQuDQo+ID4NCj4gPiBbTWVkXSBCb3RoIGFyZSBjb3JyZWN0Lg0KPiA+DQo+ID4gRmlndXJlIDcg cmV1c2VzIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbCB3aGljaCBkZWZpbmVzIFRUTCBhcyA6 DQo+ID4NCj4gPiAgICAgbGVhZiB0dGwgew0KPiA+ICAgICAgIHR5cGUgdWludDg7DQo+ID4gICAg ICAgZGVzY3JpcHRpb24NCj4gPiAgICAgICAgICJUaGlzIGZpZWxkIGluZGljYXRlcyB0aGUgbWF4 aW11bSB0aW1lIHRoZSBkYXRhZ3JhbSBpcyBhbGxvd2VkDQo+ID4gICAgICAgICAgdG8gcmVtYWlu IGluIHRoZSBpbnRlcm5ldCBzeXN0ZW0uICBJZiB0aGlzIGZpZWxkIGNvbnRhaW5zIHRoZQ0KPiA+ ICAgICAgICAgIHZhbHVlIHplcm8sIHRoZW4gdGhlIGRhdGFncmFtIG11c3QgYmUgZHJvcHBlZC4N Cj4gPg0KPiA+ICAgICAgICAgIEluIElQdjYsIHRoaXMgZmllbGQgaXMga25vd24gYXMgdGhlIEhv cCBMaW1pdC4iOw0KPiA+ICAgICAgIHJlZmVyZW5jZQ0KPiA+ICAgICAgICAgIlJGQyA3OTE6IElu dGVybmV0IFByb3RvY29sLA0KPiA+ICAgICAgICAgIFJGQyA4MjAwOiBJbnRlcm5ldCBQcm90b2Nv bCwgVmVyc2lvbiA2IChJUHY2KSBTcGVjaWZpY2F0aW9uLiI7DQo+ID4gICAgIH0NCj4gPg0KPiA+ IEZvciB0aGUgb3RoZXIgZmlndXJlcywgdGhlIGZpZWxkcyBhcmUgZGVmaW5lZCBpbiB0aGUgZGF0 YS1jaGFubmVsIGRyYWZ0Lg0KPiANCj4gQWgsIHRoYW5rcyBmb3IgdGhlIHBvaW50ZXIuDQo+IA0K PiA+ID4NCj4gPiA+IEknbSBhbHNvIGEgYml0IGN1cmlvdXMgYWJvdXQgdGhlIHVzZSBvZiBhbiBl eHBsaWNpdCAiY2FwYWJpbGl0aWVzIg0KPiA+ID4gdHJlZSBmb3IgZmluZS1ncmFpbmVkIGZlYXR1 cmUgZGV0ZWN0aW9uLCBhcyBvcHBvc2VkIHRvIG5hdGl2ZSBZQU5HDQo+ICJmZWF0dXJlInMuDQo+ ID4NCj4gPiBbTWVkXSBUaGVzZSBhcmUgbm90IHNlcnZpbmcgdGhlIHNhbWUgcHVycG9zZS4gRmVh dHVyZXMgYXJlIGFib3V0IHBhcnRzIG9mIGENCj4gbW9kdWxlIHdoaWNoIGFyZSBjb25kaXRpb25h bCwgaWYgeW91IHdpbGwuIE91ciAiY2FwYWJpbGl0aWVzIiBicmFuY2ggaXMgbWVhbnQgdG8NCj4g cmV0cmlldmUgdGhlIGZpbHRlcmluZyBtYXRjaCBjYXBhYmlsaXRpZXMgYXJlIHN1cHBvcnRlZC9l bmFibGVkIGJ5IGEgRE9UUw0KPiBzZXJ2ZXIuIFRoYXQgaW5mb3JtYXRpb24gaXMgdXNlZCBieSBh IGNsaWVudCB0byB0d2VhayBpdHMgcmVxdWVzdHMuDQo+ID4NCj4gPiAgIFRoZQ0KPiA+ID4gbGF0 dGVyIHdvdWxkIGFsbG93IHRoZSByZWxldmFudCBub2RlcyB0byBqdXN0IG5vdCBleGlzdCB3aGVu DQo+ID4gPiB1bnN1cHBvcnRlZCwNCj4gPg0KPiA+IFtNZWRdIEEgZmlsdGVyaW5nIGNhcGFiaWxp dHkgbWF5IGJlIHN1cHBvcnRlZCBidXQgbm90IGVuYWJsZWQuIFRoZSBzZXJ2ZXIgaXMNCj4gZnJl ZSB0byBpbmNsdWRlIGFuIGV4cGxpY2l0IGZpZWxkIHdpdGggdGhlIGFwcHJvcHJpYXRlIHN0YXR1 cyBvciBub3QuIFRoaXMgaXMNCj4gaW1wbGVtZW50YXRpb24tc3BlY2lmaWMuDQo+IA0KPiBUaGFu a3MgZm9yIHRoZSBleHBsYW5hdGlvbi4NCj4gDQo+ID4gPiBhcyBvcHBvc2VkIHRvIHRoZSBleHBs aWNpdC1jYXBhYmlsaXRpZXMgZm9ybXVsYXRpb24gd2hlcmUgdGhleSBleGlzdA0KPiA+ID4gYnV0 IGFyZSAocHJlc3VtYWJseSkgaWdub3JlZC4gIChJIGRvbid0IHJlbWVtYmVyIHVzIGV4cGxpY3Rp bHkNCj4gPiA+IHNheWluZyB0aGF0IHRoZXkncmUgaWdub3JlZCBpbiB0aGlzIGNhc2UsIGVpdGhl cjsgbWlnaHQgYmUgd29ydGgNCj4gPiA+IGFkZGluZyBzb21lIHRleHQuKQ0KPiA+ID4NCj4gPiA+ IEluIGEgc2ltaWxhciB2ZWluLCB3ZSBpbmNsdWRlICdjYXBhYmlsaXRpZXMnIG5vZGVzIGZvciBh IGZldw0KPiA+ID4gbWF0Y2hpbmcgZmVhdHVyZXMgdGhhdCBhcmUgbGlzdGVkIGFzICJtYW5kYXRv cnkgZmllbGRzIiBmb3IgQUNMDQo+ID4gPiBtYXRjaGluZyBpbiBUYWJsZSAxLCBhbmQgdGh1cyB3 aG9zZSB2YWx1ZSB3b3VsZCBhbHdheXMgYmUgInRydWUiLg0KPiA+ID4gV2h5IGRvIHdlIG5lZWQg dGhlIGNhcGFiaWxpdHkgbGVhdmVzIGluIHN1Y2ggYSBjYXNlPw0KPiA+DQo+ID4gW01lZF0gSSBn dWVzcyB5b3UgYXJlIHJlZmVycmluZyB0byBGaWd1cmUgMjMgd2hpY2ggc2F5cyB0aGUgZm9sbG93 aW5nOg0KPiA+DQo+ID4gICAgRmlndXJlIDIzIHNob3dzIGFuIGV4YW1wbGUgb2YgYSByZXNwb25z ZSByZWNlaXZlZCBmcm9tIGEgRE9UUyBzZXJ2ZXINCj4gPiAgICB3aGljaCBvbmx5IHN1cHBvcnRz IHRoZSBtYW5kYXRvcnkgZmlsdGVyaW5nIGNyaXRlcmlhIGxpc3RlZCBpbg0KPiA+DQo+IF5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e DQo+ID4gICAgU2VjdGlvbiA0LjEuDQo+IA0KPiBDb3JyZWN0Lg0KPiANCj4gPiBUaGUgbW9kdWxl IGFsbG93cyB0byByZXR1cm4gb3RoZXIgY2FwYWJpbGl0aWVzIHRoYW4gdGhvc2UgbGlzdGVkIGlu IHRhYmxlIDEuDQo+IA0KPiBZZXMuICBCdXQgdGhlIGZpZ3VyZSBzaG91bGQgbm90IGNsYWltIHRv IGJlIGFuIGV4YW1wbGUgdGhhdCAqb25seSogc3VwcG9ydHMgdGhlDQo+IG1hbmRhdG9yeSBwYXJ0 cywgd2hlbiBpdCBzaG93cyBhbiBleGFtcGxlIHRoYXQgc3VwcG9ydHMgYWRkaXRpb25hbA0KPiBj YXBhYmlsaXRpZXMgdGhhbiB0aGUgbWFuZGF0b3J5IG9uZXMuDQo+IA0KPiA+ID4NCj4gPiA+IGlk bml0cyBub3RlcyBhIGZldyByZWZlcmVuY2VzIHRoYXQgY2FuIGJlIHVwZGF0ZWQgYWxvbmcgd2l0 aCB0aGUNCj4gPiA+IG90aGVyIGNoYW5nZXM7IGl0IGFsc28gZmxhZ3MgYSAicmVmZXJlbmNlIGlu IGFic3RyYWN0IiBmb3IgdGhlIFJGQw0KPiA+ID4gRWRpdG9yIG5vdGUgd2hpY2ggd2UgY291bGQg cHJvYmFibHkgaWdub3JlIChidXQgY291bGQgcHJvYmFibHkgYWxzbw0KPiA+ID4ganVzdCByZW1v dmUgdGhlIGJyYWNrZXRzIGFyb3VuZCB0aGUgdGV4dCBpbiBxdWVzdGlvbikuDQo+ID4NCj4gPiBb TWVkXSBpZG5pdHMgY29uZnVzZXMgdGhlIG5vdGUgdG8gdGhlIFJGQyBlZGl0b3Igd2l0aCB0aGUg YWJzdHJhY3QuIEZpeGVkLA0KPiBhbnl3YXkuDQo+ID4NCj4gPiA+DQo+ID4gPiBJIGFsc28gbG9v a2VkIGF0IHRoZSByZWZlcmVuY2VzIChlc3BlY2lhbGx5IHRoZQ0KPiA+ID4gbm9ybWF0aXZlL2lu Zm9ybWF0aXZlDQo+ID4gPiBzcGxpdCkgYW5kIGhhdmUgYSBmZXcgc3VnZ2VzdGlvbnM6DQo+ID4g Pg0KPiA+ID4gLSB0aGUgSUVFRS43NTQuMTk4NSByZWZlcmVuY2UgaXMgbm90IG5lZWRlZDsNCj4g Pg0KPiA+IFtNZWRdIEFncmVlLCBidXQgaXQgaXMgbm90IGhhcm1mdWwgdG8gY2l0ZSBpdCBlaXRo ZXIgOi0pDQo+IA0KPiBNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgaXQgKmlzKiBoYXJtZnVs LCBzaW5jZSB3ZSBhcmUgbm90IHVzaW5nIGEgZmxvYXRpbmctDQo+IHBvaW50IHdpcmUgZW5jb2Rp bmc7IHdlJ3JlIHVzaW5nIGEgc3RyaW5nIGVuY29kaW5nLg0KPiANCj4gPiBUaGUgcmVmZXJlbmNl IGlzIHF1b3RlZCB0byBqdXN0aWZ5IHdoeSB3ZSB3ZW50IHdpdGggZGVjaW1hbDY0LCBub3QgdWlu dDY0IGZvcg0KPiBleGFtcGxlICsgd2h5IHRoYXQgdW5pdCBpcyBjaG9zZW4uIFRoaXMgYWxsb3dz IHRvIGVhc2UgZ3JhZnRpbmcgRE9UUyB3aXRoIEJHUA0KPiBGbG93c3BlYyBmb3IgaW5zdGFuY2Us IHdoaWNoIGNpdGVzIElFRUUuNzU0LjE5ODUgdG9vLg0KPiANCj4gKFJGQyA1NTc1IHNlZW1zIHRv IGNsYWltIHRvIGJlIHVzaW5nIHRoZSBhY3R1YWwgYmluYXJ5IGZsb2F0aW5nLXBvaW50DQo+IGVu Y29kaW5nLikNCj4gDQo+ID4gIHdlIGRvbid0IHVzZSB0aGUgYmluYXJ5DQo+ID4gPiAgIGZsb2F0 aW5nLXBvaW50IGVuY29kaW5nIGJ1dCByYXRoZXIgYSBzdHJpbmcgb25lIGZvciBZQU5HIGRlY2lt YWw2NA0KPiA+ID4gLSBJIHRoaW5rIHRoYXQgUkZDIDg0OTkgKGRuc29wLXRlcm1pbm9sb2d5LWJp cykgY2FuIHdob2xseSBzdXBlcnNlZGUgb3VyDQo+ID4gPiAgIHVzYWdlIG9mIFJGQyAxOTgzLCBz byB0aGUgMTk4MyBjaXRlIGNhbiBiZSBkcm9wcGVkIGFzIHdlbGwNCj4gPg0KPiA+IFtNZWRdIERv bmUuDQo+ID4NCj4gPiA+IC0gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cyAoZm9yIHRlcm1p bm9sb2d5KSwNCj4gPg0KPiA+IFtNZWRdIEZvciB0aGlzIG9uZSwgd2UgYXJlIGZvbGxvd2luZyB0 aGUgc2FtZSBhcHByb2FjaCBhcyBmb3Igb3RoZXINCj4gdGVybWlub2xvZ3kgZG9jdW1lbnRzIChl LmcuLCBSRkM4MzQwKSB0aGF0IGFyZSBsaXN0ZWQgYXMgaW5mb3JtYXRpdmUuIEkgcHJlZmVyDQo+ IHRvIGxlYXZlIGl0IGFzIGluZm9ybWF0aXZlIGZvciBub3cuDQo+IA0KPiBPa2F5LCB3ZSBjYW4g c2VlIGlmIGFueW9uZSBlbHNlIGNvbXBsYWlucy4NCj4gDQo+ID4gIFJGQyA3OTUwLCBhbmQgUkZD IDgyNTkNCj4gPg0KPiA+IFtNZWRdIE9LIGZvciB0aGVzZSB0d28uDQo+ID4NCj4gPiA+ICAgc2hv dWxkIHByb2JhYmx5IGFsbCBtb3ZlIHRvIHRoZSBub3JtYXRpdmUgc2VjdGlvbg0KPiA+ID4NCj4g PiA+IFNlY3Rpb24gMQ0KPiA+ID4NCj4gPiA+IFRoZSBzdWItYnVsbGV0IHBvaW50IGFib3V0ICJJ ZiBhIG5ldHdvcmsgcmVzb3VyY2UgLi4uIGluZm9ybXMgaXRzDQo+ID4gPiBzZXJ2aWNpbmcgRE9U UyBnYXRld2F5IG9mIGFsbCBzdXNwZWN0IElQIGFkZHJlc3NlcyB0aGF0IG5lZWQgdG8gYmUNCj4g PiA+IGRyb3AtIG9yIGFjY2VwdC1saXN0ZWQgLi4uIiBtYWRlIG1lIHdvbmRlciBpZiB0aGF0IHdh cyBtb3JlIG9mIGENCj4gPiA+IHNpZ25hbC1jaGFubmVsIGFjdGl2aXR5IG9yIGEgZGF0YS1jaGFu bmVsIG9uZS4gIFBlcmhhcHMgdGhpcyBpcyBqdXN0DQo+ID4gPiBhIG1hdHRlciBvZiB0aGUgdGV4 dCBub3QgYmVpbmcgYXMgY2xlYXIgYXMgaXQgY291bGQgYmUuDQo+ID4NCj4gPiBbTWVkXSBUaGUg cG9pbnQgaXMgdGhhdCBhIGNsaWVudCBpcyBub3Qgc3VyZSB0aGF0IGFuIGF0dGFjayBpcyBhY3Rp dmUgYW5kDQo+IHRhcmdldGluZyB0aGUgY2xpZW50IGRvbWFpbiBidXQgaXQgd2FudHMgdG8gZW5m b3JjZSBzb21lIHByZXZlbnRpdmUgYWN0aW9ucw0KPiBkdXJpbmcgYW4gaW52ZXN0aWdhdGlvbiBw ZXJpb2QuIEZvciBleGFtcGxlLCB0aGlzIGNhbiBiZSB0cmlnZ2VyZWQgYnkgYW4NCj4gYWRtaW5p c3RyYXRvciB3aG8gaXMgaW5mb3JtZWQgdGhhdCBhbiBhdHRhY2sgaXMgY3VycmVudGx5IHRhcmdl dGluZyBvdGhlcg0KPiBuZXR3b3JrcywgYnV0IGl0cyBuZXR3b3JrIGlzIGxpa2VseSB0byBiZSBz dWJqZWN0IHRvIHRoYXQgYXR0YWNrIHRvby4gT3RoZXINCj4gcHJldmVudGl2ZSBhY3Rpb25zIHdo aWNoIHJlcXVpcmUgZnVydGhlciBpbnZlc3RpZ2F0aW9uIG1heSBiZSBjb25zaWRlcmVkLg0KPiA+ DQo+ID4gSSBjaGFuZ2VkIHRoZSB0ZXh0IGFzIGZvbGxvd3M6DQo+ID4NCj4gPiBPTEQ6DQo+ID4g ICBkZXRlY3RzIGEgcG90ZW50aWFsIEREb1MgYXR0YWNrIGZyb20NCj4gPg0KPiA+IE5FVw0KPiA+ ICAgIGlzIGluZm9ybWVkIGFib3V0IGEgcG90ZW50aWFsIEREb1MgYXR0YWNrIGZyb20NCj4gPg0K PiA+ICAoSSBhbHNvIHdvbmRlciBpZiB3ZSBzaG91bGQgc2F5DQo+ID4gPiAiZnVydGhlciBpbnZl c3RpZ2F0aW9uIiBzaW5jZSB3ZSBkb24ndCByZWFsbHkgaGF2ZSBhbiBhdXRvbWF0ZWQgd2F5DQo+ ID4gPiB0byBpbmRpY2F0ZSB0aGF0IHlldC4pDQo+IA0KPiBPbiBmdXJ0aGVyIHJlZmxlY3Rpb24s IHdvdWxkICJmdXJ0aGVyIG1hbnVhbCBpbnZlc3RpZ2F0aW9uIiBiZSBhcHByb3ByaWF0ZT8NCj4g DQo+ID4gPiBTZWN0aW9uIDINCj4gPiA+DQo+ID4gPiBXaGVuIHdlIHRhbGsgYWJvdXQgdHJlZSBk aWFncmFtcywgc2hvdWxkIHdlIGFsc28gc2F5IHNvbWV0aGluZyBsaWtlDQo+ID4gPiAiTm90ZSB0 aGF0IHRoZSBmdWxsIG1vZHVsZSdzIHRyZWUgaGFzIGJlZW4gc3BsaXQgYWNyb3NzIHNldmVyYWwN Cj4gPiA+IGZpZ3VyZXMgdG8gYWlkIHRoZSBleHBvc2l0aW9uIG9mIHRoZSB2YXJpb3VzIHN1Yi10 cmVlcyI/DQo+ID4NCj4gPiBbTWVkXSBEb25lLiBUaGFua3MuDQo+ID4NCj4gPiA+DQo+ID4gPiBT ZWN0aW9uIDMuMQ0KPiA+ID4NCj4gPiA+IFdoZW4gd2UgdGFsayBhYm91dCB1c2luZyBHRVQgdG8g cmV0cmlldmUgcnVubmluZyBjb25maWd1cmF0aW9uLCBkbw0KPiA+ID4gd2Ugd2FudCB0byBub3Rl IHRoYXQgc2luY2UgdGhlIGRhdGEgY2hhbm5lbCBjYW4gZmFpbCBkdXJpbmcgYXR0YWNrDQo+ID4g PiB0aW1lLCBpdCdzIGV4cGVjdGVkIHRvIGJlIGNvbW1vbiB0byBwZXJmb3JtIHN1Y2ggYSBHRVQg YmVmb3JlDQo+ID4gPiBhdHRlbXB0aW5nIHRvIG1ha2UgbW9kaWZpY2F0aW9ucyB0byBjb25maWd1 cmF0aW9uPw0KPiA+DQo+ID4gW01lZF0gVGhlIGRhdGEgY2hhbm5lbCBpcyBzdXBwb3NlZCB0byBi ZSBpbnZva2VkIHdoZW4gbm8gYXR0YWNrIGlzIG9uZ29pbmcuDQo+IE5vcm1hbCBSRVNUQ09ORiBv cGVyYXRpb25zIGFyZSB0aGVyZWZvcmUgZm9sbG93ZWQuIEkgZG9uJ3Qgc2VlIHRoZSBuZWVkIHRv DQo+IGFkZCBhIG5vdGUuDQo+IA0KPiBJIGFsd2F5cyBoYXZlIHRvIGNvbnNpZGVyIGVkZ2UgY2Fz ZXMgaW4gbXkgSUVTRyByZXZpZXdzIC0tIHdoYXQgaGFwcGVucyBpZiBhbg0KPiBhdHRhY2sgc3Rh cnRzIGFmdGVyIHRoZSByZXF1ZXN0IGlzIHNlbnQgYnV0IGJlZm9yZSB0aGUgcmVzcG9uc2UgaXMg cmVjZWl2ZWQ/DQo+IA0KPiA+ID4NCj4gPiA+ICAgIEEgRE9UUyBjbGllbnQgcmVnaXN0ZXJzIGl0 c2VsZiB0byBpdHMgRE9UUyBzZXJ2ZXIocykgaW4gb3JkZXIgdG8gc2V0DQo+ID4gPiAgICB1cCBE T1RTIGRhdGEgY2hhbm5lbC1yZWxhdGVkIGNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgcmVjZWl2ZSBz dGF0ZQ0KPiA+ID4gICAgZGF0YSAoaS5lLiwgbm9uLWNvbmZpZ3VyYXRpb24gZGF0YSkgZnJvbSB0 aGUgRE9UUyBzZXJ2ZXIocykNCj4gPiA+ICAgIChTZWN0aW9uIDUpLiAgTXV0dWFsIGF1dGhlbnRp Y2F0aW9uIGFuZCBjb3VwbGluZyBvZiBzaWduYWwgYW5kIGRhdGENCj4gPiA+ICAgIGNoYW5uZWxz IGFyZSBzcGVjaWZpZWQgaW4gW0ktRC5pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWxdLg0KPiA+ID4N Cj4gPiA+IEkgdGhpbmsgd2Ugc2hvdWxkIHNwbGl0IHRoZSAibXV0dWFsIGF1dGhlbnRpY2F0aW9u IiBhbmQgImNvdXBsaW5nIG9mDQo+ID4gPiBzaWduYWwgYW5kIGRhdGEgY2hhbm5lbHMiIGludG8g dGhlaXIgb3duIHNlbnRlbmNlLCBhbmQgZmxlc2ggdGhlbQ0KPiA+ID4gb3V0IHNsaWdodGx5IG1v cmUuICBTbywgc2VjdGlvbiByZWZlcmVuY2VzIHRvIFNlY3Rpb25zIDggYW5kIDQuNC4xLA0KPiA+ ID4gcmVzcGVjdGl2ZWx5LCB0aGUgdXNhZ2Ugb2YgVExTIGNsaWVudCBjZXJ0aWZpY2F0ZXMsIHRo ZSBjb3VwbGluZyBvZg0KPiA+ID4gY2hhbm5lbHMgdmlhIHRoZSBjbGllbnQncyBpZGVudGl0eSAo J2N1aWQnIGFuZCAnY2RpZCcpLCBldGMuDQo+ID4NCj4gPiBbTWVkXSBEb25lLg0KPiA+DQo+ID4g Pg0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEgVExTIGhlYXJ0YmVh dCBbUkZDNjUyMF0gdmVyaWZpZXMNCj4gPiA+ICAgIHRoYXQgdGhlIERPVFMgc2VydmVyIHN0aWxs IGhhcyBUTFMgc3RhdGUgYnkgcmV0dXJuaW5nIGEgVExTIG1lc3NhZ2UuDQo+ID4gPg0KPiA+ID4g SSBleHBlY3QgdGhpcyB3aWxsIGdldCBzb21lIHBvaW50ZWQgY29tbWVudHMgZHVyaW5nIElFVEYg TEMsIGdpdmVuDQo+ID4gPiB0aGUgcmVjZW50LWlzaCBJRVRGLXdpZGUgZGlzY3Vzc2lvbnMgYWJv dXQgaGVhcnRiZWF0cy9rZWVwYWxpdmVzIGluIGdlbmVyYWwuDQo+ID4gPiBJcyB0aGVyZSBwZXJo YXBzIGEgUkVTVENPTkYtbGV2ZWwgcHJvYmUgbWVzc2FnZSB0aGF0IGNvdWxkIGJlIHVzZWQNCj4g PiA+IHRvIGNoZWNrIGxpdmVsaW5lc3M7IGEgY2FwYWJpbGl0aWVzIHF1ZXJ5IHBlcmhhcHM/DQo+ ID4NCj4gPiBbTWVkXSBUaGVyZSBpcyBubyBzdWNoIG1lY2hhbmlzbS4gVGhlIGFwcHJvYWNoIGlu IHRoZSBkYXRhIGNoYW5uZWwgZHJhZnQgaXMNCj4gYWxpZ25lZCB3aXRoIFJGQzgwNzEgZm9yIGtl ZXBhbGl2ZXMuDQo+IA0KPiBJIGd1ZXNzIHdlJ2xsIGp1c3QgaGF2ZSB0byB3YWl0IHRvIHNlZSB3 aGF0IGtpbmQgb2YgY29tbWVudHMgd2UgZ2V0LCB0aGVuLg0KPiAoVGhhbmtzIGZvciB0aGUgcG9p bnRlciB0byA4MDcxLikNCj4gDQo+ID4gPg0KPiA+ID4gICAgQSBET1RTIHNlcnZlciBtYXkgZGV0 ZWN0IGNvbmZsaWN0aW5nIGZpbHRlcmluZyByZXF1ZXN0cyBmcm9tIGRpc3RpbmN0DQo+ID4gPiAg ICBET1RTIGNsaWVudHMgd2hpY2ggYmVsb25nIHRvIHRoZSBzYW1lIGRvbWFpbi4gIEZvciBleGFt cGxlLCBhIERPVFMNCj4gPiA+ICAgIGNsaWVudCBjb3VsZCByZXF1ZXN0IHRvIGRyb3AtbGlzdCBh IHByZWZpeCBieSBzcGVjaWZ5aW5nIHRoZSBzb3VyY2UNCj4gPiA+ICAgIHByZWZpeCwgd2hpbGUg YW5vdGhlciBET1RTIGNsaWVudCBjb3VsZCByZXF1ZXN0IHRvIGFjY2VwdC1saXN0IHRoYXQNCj4g PiA+ICAgIHNhbWUgc291cmNlIHByZWZpeCwgYnV0IGJvdGggaGF2aW5nIHRoZSBzYW1lIGRlc3Rp bmF0aW9uIHByZWZpeC4gIEl0DQo+ID4gPiAgICBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBzcGVj aWZpY2F0aW9uIHRvIHJlY29tbWVuZCB0aGUgYmVoYXZpb3IgdG8NCj4gPiA+ICAgIGZvbGxvdyBm b3IgaGFuZGxpbmcgY29uZmxpY3RpbmcgcmVxdWVzdHMgKGUuZy4sIHJlamVjdCBhbGwsIHJlamVj dA0KPiA+ID4gICAgdGhlIG5ldyByZXF1ZXN0LCBub3RpZnkgYW4gYWRtaW5pc3RyYXRvciBmb3Ig dmFsaWRhdGlvbikuICBET1RTDQo+ID4gPiAgICBzZXJ2ZXJzIFNIT1VMRCBzdXBwb3J0IGEgY29u ZmlndXJhdGlvbiBwYXJhbWV0ZXIgdG8gaW5kaWNhdGUgdGhlDQo+ID4gPiAgICBiZWhhdmlvciB0 byBmb2xsb3cgd2hlbiBhIGNvbmZsaWN0IGlzIGRldGVjdGVkLiAgU2VjdGlvbiA3LjINCj4gPiA+ ICAgIHNwZWNpZmllcyB0aGUgYmVoYXZpb3Igd2hlbiBubyBpbnN0cnVjdGlvbiBpcyBzdXBwbGll ZCB0byBhIERPVFMNCj4gPiA+ICAgIHNlcnZlci4NCj4gPiA+DQo+ID4gPiBJJ20gYSBiaXQgY29u ZnVzZWQgYnkgdGhlICJvdXQgb2Ygc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHRvDQo+ID4g PiByZWNvbW1lbmQgdGhlIGJlaGF2aW9yIHRvIGZvbGxvdyBmb3IgaGFuZGxpbmcgY29uZmxpY3Rp bmcgcmVxdWVzdHMiLA0KPiA+ID4gc2luY2Ugbm90IG9ubHkgZG9lcyB0aGUgbGFzdCBzZW50ZW5j ZSBvZiB0aGUgcGFyYWdyYXBoIGdpdmUgYQ0KPiA+ID4gcG9pbnRlciB0byBhIHNwZWNpZmllZCBi ZWhhdmlvciBpbiBjYXNlIG9mIGNvbmZsaWN0cywgYnV0IHdlIGFsc28NCj4gPiA+IG1lbnRpb24g aXQgaW4gYSBjb3VwbGUgb3RoZXIgcGxhY2VzIChlLmcuLCB0aGUgYm90dG9tIG9mIHBhZ2UgNDMp Lg0KPiA+DQo+ID4gW01lZF0gVGhlIHNwZWNpZmllZCBiZWhhdmlvciBpcyBhIGRlZmF1bHQgYmVo YXZpb3IsIG5vdCBhIHJlY29tbWVuZGVkIG9uZS4NCj4gDQo+IEluIGVmZmVjdCBhIGRlZmF1bHQg aXMgYSByZWNvbW1lbmRhdGlvbiwgdGhvdWdoIC0tIGEgcmVjb21tZW5kYXRpb24gZm9yIHdoYXQN Cj4gdG8gZG8gaWYgeW91IGRvbid0IGtub3cgYW55IGJldHRlci4gIFBlcmhhcHMgIml0IGlzIG91 dCBvZiBzY29wZSBvZiB0aGlzDQo+IHNwZWNpZmljYXRpb24gdG8gcHJvdmlkZSBndWlkYW5jZSBv biBob3cgY29uZmxpY3RpbmcgcmVxdWVzdHMgbWF5IGJlIHNhZmVseQ0KPiBoYW5kbGVkLCB3aXRo IHRoZSBkZWZhdWx0IGJlaGF2aW9yIGJlaW5nIHRvIHJlamVjdCBzdWNoIHJlcXVlc3RzIj8NCj4g DQo+ID4gSSB1cGRhdGUgdGhpcyB0ZXh0Og0KPiA+DQo+ID4gICAgSWYgdGhlIHJlcXVlc3QgaXMg Y29uZmxpY3Rpbmcgd2l0aCBhbiBleGlzdGluZyBmaWx0ZXJpbmcgaW5zdGFsbGVkIGJ5DQo+ID4g ICAgYW5vdGhlciBET1RTIGNsaWVudCBvZiB0aGUgZG9tYWluLCBhbmQgYWJzZW50IGFueSBsb2Nh bCBwb2xpY3ksIHRoZQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiANCj4gVGhhdCBoZWxwcyAobWF5YmUgdGhl ICJhbmQiIGlzIG5vdCBldmVuIG5lZWRlZD8pLiAgRG8geW91IHdhbnQgdG8gZG8gYSBzd2VlcA0K PiBmb3Igb3RoZXIgcGxhY2VzIHdoZXJlIHRoZSB0ZXh0IHRhbGtzIGFib3V0IDQwOSByZXNwb25z ZXM/DQo+IA0KPiA+ICAgIERPVFMgc2VydmVyIHJldHVybnMgIjQwOSBDb25mbGljdCIgc3RhdHVz LWxpbmUgdG8gdGhlIHJlcXVlc3RpbmcgRE9UUw0KPiA+ICAgIGNsaWVudC4gIFRoZSBlcnJvci10 YWcgInJlc291cmNlLWRlbmllZCIgaXMgdXNlZCBpbiB0aGlzIGNhc2UuDQo+ID4NCj4gPiA+DQo+ ID4gPiBBbHNvIGluIHRoYXQgcGFyYWdyYXBoLCBpdCdzIHVuY2xlYXIgdGhhdCBhIDIxMTkgU0hP VUxEIGlzDQo+ID4gPiBhcHByb3ByaWF0ZSBmb3IgInN1cHBvcnQgYSBjb25maWd1cmF0aW9uIHBh cmFtZXRlciI7IHRoZXJlJ3Mgbm8NCj4gPiA+IGludGVyb3BlcmFiaWxpdHkgY29uc2lkZXJhdGlv bnMgZm9yIGhhdmluZyBvciBub3QgaGF2aW5nIHN1Y2ggYSBjb25maWd1cmF0aW9uDQo+IGtub2Iu DQo+ID4NCj4gPiBbTWVkXSBUaGlzIGlzIGltcG9ydGFudCBmb3IgaW50ZXJvcGVyYWJpbGl0eSAo b3IgYXQgbGVhc3QgZm9yIGVuc3VyaW5nIGENCj4gZGV0ZXJtaW5pc3RpYyBiZWhhdmlvcikuIEUu Zy4sIGR1cmluZyBzZXJ2aWNlIHN1YnNjcmlwdGlvbiBhIHRlY2huaWNhbCBjbGF1c2UgbWF5DQo+ IGJlIG5lZ290aWF0ZWQgb3V0IG9mIGJhbmQgaG93IHRvIGRlYWwgd2l0aCBjb25mbGljdHMgZnJv bSBjbGllbnRzIG9mIHRoZSBzYW1lDQo+IGRvbWFpbi4NCj4gDQo+IEl0IHNlZW1zIHRoYXQgdGhl IGRlZmF1bHQgYmVoYXZpb3Igb2YgZGlzYWxsb3dpbmcgY29uZmxpY3RzIHdvdWxkIGFsd2F5cyBi ZQ0KPiBpbnRlcm9wZXJhYmxlLCBidXQgSSdtIGhhcHB5IHRvIGxlYXZlIHRoaXMgYXMtaXMgZm9y IG5vdy4NCj4gDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzLjMgTkFUIENvbnNpZGVyYXRpb25zIGhh dmUgImhpZ2ggb3ZlcmxhcCIgd2l0aCB0aGUgdGV4dCBhdA0KPiA+ID4gdGhlIGVuZCBvZiB0aGUg c2lnbmFsLWNoYW5uZWwncyAiRGVzaWduIE92ZXJ2aWV3Ii4gIEF0IGEgbWluaW11bSB3ZQ0KPiA+ ID4gc2hvdWxkIGRpZmYgdGhlbSBhbmQgZW5mb3JjZSBjb252ZXJnZW5jZSwgYnV0IGRvIHdlIHdh bnQgdG8gY29uc2lkZXINCj4gPiA+IGp1c3QgaGF2aW5nIG9uZSByZWZlciB0byB0aGUgb3RoZXI/ DQo+ID4NCj4gPiBbTWVkXSBNYWtlcyBzZW5zZS4gU2VjdGlvbiAzLjMgaXMgbm93IGRlbGV0ZWQg YW5kIHJlcGxhY2VkIHdpdGggdGhpcyBORVcNCj4gdGV4dDoNCj4gPg0KPiA+ICAgIE5BVCBjb25z aWRlcmF0aW9ucyBmb3IgdGhlIERPVFMgZGF0YSBjaGFubmVsIGFyZSBzaW1pbGFyIHRvIHRob3Nl DQo+ID4gICAgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMyBvZiBbSS1ELmlldGYtZG90cy1zaWduYWwt Y2hhbm5lbF0uDQo+IA0KPiBDb29sLCB0aGFua3MuDQo+IA0KPiA+ID4NCj4gPiA+IFNlY3Rpb24g My41DQo+ID4gPg0KPiA+ID4gSSBoYWQgdG8gcmVhZCB1cCBvbiBSRVNUQ09ORiBhbmQgTkVUQ09O RiB3aGlsZSByZXZpZXdpbmcgdGhpcywgYnV0DQo+ID4gPiBmcm9tIHdoYXQgSSd2ZSBzZWVuIHNv IGZhciwgdGhlICJlcnJvci1zZXZlcml0eSIgZmllbGQgaXMgb25seQ0KPiA+ID4gcHJlc2VudCBp biBORVRDT05GIGFuZCBub3QgUkVTVENPTkYuICBJZiBzbywgdGhlbiB3ZSBzaG91bGRuJ3QgbmVl ZA0KPiA+ID4gdG8gdGFsayBhYm91dCBpdCBoZXJlLCBzaW5jZSB3ZSB1c2UgUkVTVENPTkYgZXhj bHVzaXZlbHkuICBJIGFsc28NCj4gPiA+IGNvdWxkbid0IGZpbmQgd2hldGhlciB0aGVyZSdzIGEg cmVnaXN0cnkgdGhhdCB3ZSBzaG91bGQgYWRkIHRoZSAibG9vcC0NCj4gZGV0ZWN0ZWQiIGVycm9y LXRhZyB0by4NCj4gPiA+IENhbiBhbnlvbmUgaGVyZSBoZWxwIG1lIG91dD8NCj4gPiA+DQo+ID4N Cj4gPiBbTWVkXSBXZSB1c2VkIHRoZSB0ZW1wbGF0ZSBpbiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjI0MSNhcHBlbmRpeC0NCj4gQSBiZWNhdXNlIHRoZSBlcnJvcnMgaW4gODA0MCBh cmUgdGhlIG9uZXMgaW1wb3J0ZWQgZnJvbSB0aGVyZS4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHBv aW50ZXIuICAgSXQgc291bmRzIGxpa2UgSSdsbCBuZWVkIHRvIGFzayBhcm91bmQgYWJvdXQgdGhp cw0KPiBvbmUuDQo+IA0KPiA+IFRoZXJlIGlzIG5vIHJlZ2lzdHJ5IGZvciB0aGUgZXJyb3JzOyBv bmx5IGEgWUFORyBtb2R1bGUgd2hpY2ggaXMgbm90DQo+IG1haW50YWluZWQgYnkgSUFOQS4gVGhp cyBpcyB3aHkgbm8gYWN0aW9uIGlzIGluY2x1ZGVkIGluIHRoZSBJQU5BIHNlY3Rpb24uDQo+ID4N Cj4gPiA+IFNlY3Rpb24gNC4yDQo+ID4gPg0KPiA+ID4gSXMgdGhlcmUgYW55IHBsYW4vZXhwZWN0 YXRpb24gZm9yIGZpbHRlcmluZy9tYXRjaCBydWxlcyBmb3IgUVVJQz8NCj4gPiA+IEl0IGlzIHBy b2JhYmx5IHByZW1hdHVyZSB0byBwdXQgYW55dGhpbmcgaW4gdGhpcyBkb2N1bWVudA0KPiA+ID4g c3BlY2lmaWNhbGx5LCBidXQgc3RpbGwgd29ydGggdGhpbmtpbmcgYWJvdXQuDQo+ID4NCj4gPiBb TWVkXSBTb21lIG9mIHRoZSBleGlzdGluZyBmaWVsZHMgY2FuIGJlIGFscmVhZHkgcmV1c2VkIGZv ciBRVUlDIChVRFAsIHBvcnQNCj4gbnVtYmVyKS4gVGhlcmUgYXJlIGZldyBmaWVsZHMgaW4gdGhl IFFVSUMgcHVibGljIGhlYWRlciB0aGF0IGFyZSBhdmFpbGFibGUNCj4gKHB1YmxpYyBmbGFncywg Q0lELCB2ZXJzaW9uKS4gQSBtYXRjaCBvbiB0aGUgZmlyc3QgTiBieXRlcyBvZiB0aGUgVURQIHBh eWxvYWQgY2FuDQo+IGJlIGNvbnNpZGVyZWQgYnV0IEkgZG8gdGhpbmsgdGhpcyBpcyBub3QgbWF0 dXJlIGVub3VnaC4NCj4gPg0KPiA+IFRoZSBrZXkgcG9pbnQgaXMgdGhhdCBvdXIgbW9kdWxlIGlz IGV4dGVuc2libGUuDQo+IA0KPiBJbmRlZWQuDQo+IA0KPiA+ID4NCj4gPiA+IFRoZSBvcmRlciBp biB3aGljaCB0aGUgbGVhdmVzIGFwcGVhciBpbiB0aGUgImNhcGFiaWxpdGllcy9pcHY2IiBhbmQN Cj4gPiA+ICJjYXBhYmlsaXRpZXMvdGNwIiBzdWJ0cmVlcyBkbyBub3QgbWF0Y2ggdGhlIG9yZGVy IHRoZXkgYXBwZWFyIGluDQo+ID4gPiB0aGUgQUNMIHN1YnRyZWUgaXRzZWxmOyBpdCB3b3VsZCBi ZSBnb29kIHRvIGtlZXAgdGhlIG9yZGVyIGNvbnNpc3RlbnQuDQo+ID4NCj4gPiBbTWVkXSBGaXhl ZC4NCj4gPg0KPiA+IEZXSVcsIHRoZSBvcmRlciBpbiBjYXBhYmlsaXRpZXMvKiBmb2xsb3dzIHRo ZSBvcmRlciBvZiB0aGUgZmllbGRzIGFzIHRoZXkNCj4gYXBwZWFyIGluIHRoZSBoZWFkZXIuIFdl IGRvbid0IGhhdmUgYSBjb250cm9sIG9uIHRoZSBBQ0wgb3JkZXIgYmVjYXVzZSB3ZQ0KPiBhcmUg cmV1c2luZyBhbiBleHRlcm5hbCBtb2R1bGUuDQo+IA0KPiBBaCwgZ29vZCB0byBrbm93Lg0KPiAN Cj4gPiA+DQo+ID4gPiBXZSBkb24ndCByZWFsbHkgc2F5IG11Y2ggYWJvdXQgd2hhdCB0aGUgc2Vt YW50aXMgb2YgdGhlICJwb3J0LXJhbmdlIg0KPiA+ID4gY2FwYWJpbGl0aWVzIGFyZTsgaXMgdGhh dCBzdXBwb3NlZCB0byBpbmRpY2F0ZSBhbnkgcG9ydC1tYXRjaGluZw0KPiA+ID4gYWJpbGl0eSBh dCBhbGwsIG9yIHNwZWNpZmljYWxseSB0aGUgbG93LXRvLWhpZ2ggcmFuZ2UgbWF0Y2hpbmcsIG9y IGFsc28gdGhlDQo+ICJvcGVyYXRvciINCj4gPiA+IG9wdGlvbnM/DQo+ID4NCj4gPiBbTWVkXSBV cGRhdGVkIGFzIGZvbGxvd3M6DQo+ID4NCj4gPiBPTEQ6DQo+ID4gICAgICAgICAgICAgICAiU3Vw cG9ydCBvZiBmaWx0ZXJpbmcgYmFzZWQgb24gYSBwb3J0IHJhbmdlLiI7DQo+ID4NCj4gPiBORVc6 DQo+ID4NCj4gPiAgICAgICAgICAgICAgIlN1cHBvcnQgb2YgZmlsdGVyaW5nIGJhc2VkIG9uIGEg cG9ydCByYW5nZS4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgVGhpcyBpbmNsdWRlcyBmaWx0ZXJp bmcgYmFzZWQgb24gYSBzb3VyY2UgcG9ydCByYW5nZSwNCj4gPiAgICAgICAgICAgICAgIGRlc3Rp bmF0aW9uIHBvcnQgcmFuZ2UsIG9yIGJvdGguIEFsbCBvcGVyYXRvcnMNCj4gPiAgICAgICAgICAg ICAgIChpLmUsIGxlc3MgdGhhbiBvciBlcXVhbCwgZ3JlYXRlciB0aGFuIG9yIGVxdWFsLCBlcXVh bCB0bywNCj4gPiAgICAgICAgICAgICAgIGFuZCBub3QgZXF1YWwgdG8pIGFyZSBzdXBwb3J0ZWQu IjsNCj4gDQo+IFRoYW5rcyENCj4gDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiA0LjMNCj4gPiA+DQo+ ID4gPiBXZSBkZWZpbmUgYW4gIm9wZXJhdG9yIiB0eXBlZGVmIHRoYXQgaXMgcmF0aGVyIGRpZmZl cmVudCBmcm9tIHRoYXQNCj4gPiA+IGZyb20gbmV0bW9kLWFjbC1tb2RlbC4gIERvIHdlIHdhbnQg dG8gdXNlIGEgZGlmZmVyZW50IG5hbWUgdG8gYWlkDQo+ID4gPiBkaXNhbWJpZ3VhdGlvbj8gICgi Yml0bWFzay1vcGVyYXRvciIgY29tZXMgdG8gbWluZCBhcyBhbiBvcHRpb24uKQ0KPiA+DQo+ID4g W01lZF0gSXQgaXMgbm90IHJlY29tbWVuZGVkIGluIHlhbmcgdG8gdXNlIHByZWZpeGVzIHRvIGRp c2FtYmlndWF0ZSBub2Rlcy4uDQo+IFRoZSBkaXNhbWJpZ3VhdGlvbiBpcyBlbnN1cmVkIGJ5IHRo ZSBjb250ZXh0L3Bvc2l0aW9uIGluIHRoZSB0cmVlLiBGb3IgZXhhbXBsZSwNCj4gdGhpcyBpcyB3 aHkgd2UgYXJlIHVzaW5nIG5hbWUgYW5kIG5vdCBhY2wtbmFtZSBvciBhY2UtbmFtZSwgZXRjLiBJ IHdpbGwgbGVhdmUNCj4gdGhlIHRleHQgYXMgaXQgaXMuDQo+IA0KPiBGb3IgbmFtZXMgdGhpcyBt YWtlcyBuYXR1cmFsIHNlbnNlIHRvIG1lLCBidXQgdGhpcyBxdWVzdGlvbiBpcyBhYm91dCBhIHR5 cGVkZWYuDQo+IEkgaGF2ZSBsZXNzIGNsZWFyIG9mIGEgcGljdHVyZSBmb3IgaG93IHR5cGVkZWZz IGFyZSBvciBhcmUgbm90IG5hbWVzcGFjZWQgKGlzIGl0DQo+IGp1c3QgcGVyLW1vZHVsZT8pLg0K PiANCj4gPiA+DQo+ID4gPiAgICAgdHlwZWRlZiBmcmFnbWVudC10eXBlIHsNCj4gPiA+ICAgICAg IHR5cGUgYml0cyB7DQo+ID4gPiAgICAgICAgIGJpdCBkZiB7DQo+ID4gPiAgICAgICAgICAgcG9z aXRpb24gMDsNCj4gPiA+ICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ID4gICAgICAgICAgICAg IkRvbid0IGZyYWdtZW50IGJpdCBmb3IgSVB2NC4NCj4gPiA+ICAgICAgICAgICAgICBUaGlzIGJp dCBtdXN0IGJlIHNldCB0byAwIGZvciBJUHY2LiI7DQo+ID4gPg0KPiA+ID4gU2V0IHRvIHplcm8g Ynkgd2hvbT8gIFdoYXQgc2hvdWxkIHRoZSByZWNlaXZlciBkbyBpZiBpdCBpcyBzZXQgb3RoZXJ3 aXNlPw0KPiA+ID4NCj4gPg0KPiA+IFtNZWRdIEluIElQdjYsIGZyYWdtZW50YXRpb24gaXMgb25s eSBkb25lIGJ5IHRoZSBzb3VyY2UuIEhlbmNlLCB0aGlzIHZhbHVlIGZvcg0KPiBJUHY2LiBBIGZy YWdtZW50LXR5cGUgd2l0aCB0aGUgZmlyc3QgYml0IHNldCB3aWxsIGJlIGRpc2NhcmRlZCBieSB0 aGUgc2VydmVyLg0KPiANCj4gSSB3YXMgbG9va2luZyBmb3IgYSBmZXcgbW9yZSB3b3JkcyBpbiB0 aGUgdGV4dCwgbGlrZSAibXVzdCBiZSBzZXQgdG8gMCB3aGVuIGl0DQo+IGFwcGVhcnMgaW4gYW4g SVB2NiBmaWx0ZXIiLg0KPiANCj4gPiA+IFdoYXQgYXJlIHRoZSBzZW1hbnRpY3MgaWYgKGVpdGhl ciBvciBib3RoIG9mIHRhcmdldC1mcWRuIGFuZA0KPiA+ID4gdGFyZ2V0LXVyaSkgYW5kIHRhcmdl dC1wcmVmaXggYXJlIHNwZWNpZmllZD8gIChJIHN1cHBvc2UgbWF5YmUgdGhpcw0KPiA+ID4gY291 bGQgYmUgY292ZXJlZCBpbiBTZWN0aW9uIDYuMSB3aGVuIHdlIHNheSB0aGF0IGF0IGxlYXN0IG9u ZSBpcw0KPiA+ID4gcmVxdWlyZWQgaW4gQUNMLWNyZWF0aW9uDQo+ID4gPiByZXF1ZXN0cy4pDQo+ ID4NCj4gPiBbTWVkXSBUaGUgcmVzdWx0aW5nIElQIHByZWZpeGVzL2FkZHJlc3NlcyB3aWxsIGJl IGJvdW5kIHRvIHRoZSBhbGlhcy4gQWRkZWQNCj4gdGhlIGZvbGxvd2luZyBpbiBTZWN0aW9uIDYu MToNCj4gPg0KPiA+ICAgIElmIG1vcmUgdGFyZ2V0LSogY2xhdXNlcyAoZS5nLiwgJ3RhcmdldC1w cmVmaXgnIGFuZCAndGFyZ2V0LWZxZG4nKQ0KPiA+ICAgIGFyZSBpbmNsdWRlZCBpbiBhIFBPU1Qg b3IgUFVUIHJlcXVlc3QsIHRoZSBET1RTIHNlcnZlciBiaW5kcyBhbGwNCj4gPiAgICByZXN1bHRp bmcgSVAgYWRkcmVzc2VzL3ByZWZpeGVzIHRvIHRoZSBzYW1lIHJlc291cmNlLg0KPiA+DQo+ID4g Pg0KPiA+ID4gVGhlIHVuaXRzIGZvciB0aGUgInJhdGUtbGltaXQiIG5vZGUgc2hvdWxkIGJlIHNw ZWNpZmllZCBpbiB0aGUgWUFORw0KPiA+ID4gbW9kdWxlIGFuZCBub3QgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIGhvdyB0byBpbnN0YWxsIGZpbHRlcmluZyBydWxlcy4NCj4gPg0KPiA+IFtNZWRdIEFk ZGVkICJ1bml0cyIgdG8gdGhlIFlBTkcgbW9kdWxlLg0KPiA+DQo+ID4gPg0KPiA+ID4gICAgICAg bGlzdCBkb3RzLWNsaWVudCB7DQo+ID4gPiAgICAgICAgIGtleSAiY3VpZCI7DQo+ID4gPiAgICAg ICAgIGRlc2NyaXB0aW9uDQo+ID4gPiAgICAgICAgICAgIkxpc3Qgb2YgRE9UUyBjbGllbnRzLiI7 DQo+ID4gPiAgICAgICAgIGxlYWYgY3VpZCB7DQo+ID4gPiAgICAgICAgICAgdHlwZSBzdHJpbmc7 DQo+ID4gPiAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiA+ICAgICAgICAgICAgICJBIHVuaXF1 ZSBpZGVudGlmaWVyIHRoYXQgaXMgcmFuZG9tbHkgZ2VuZXJhdGVkIGJ5DQo+ID4gPiAgICAgICAg ICAgICAgYSBET1RTIGNsaWVudCB0byBwcmV2ZW50IHJlcXVlc3QgY29sbGlzaW9ucy4iOw0KPiA+ ID4NCj4gPiA+IEkgZG9uJ3QgdGhpbmsgInJhbmRvbWx5IGdlbmVyYXRlZCIgaXMgcmVhbGx5IGNv cnJlY3QgaGVyZS4NCj4gPg0KPiA+IFtNZWRdIENoYW5nZWQgdG86DQo+ID4NCj4gPiAgICAgICAg ICAiQSB1bmlxdWUgaWRlbnRpZmllciB0aGF0IGlzIGdlbmVyYXRlZCBieSBhIERPVFMgY2xpZW50 DQo+ID4gICAgICAgICAgIHRvIHByZXZlbnQgcmVxdWVzdCBjb2xsaXNpb25zLiI7DQo+ID4NCj4g PiA+DQo+ID4gPiBUaGUgImNhcGFiaWxpdGllcy9pY21wL3Jlc3Qtb2YtaGVhZGVyIiBkZXNjcmlw dGlvbiBzaG91bGQgYmUgbW9yZQ0KPiA+ID4gY2xlYXIgdGhhdCAocGVyIGRyYWZ0LWlldGYtbmV0 bW9kLWFjbC1tb2RlbCkgaXQgaXMgc3VwcG9zZWQgdG8gbWF0Y2gNCj4gPiA+IGJvdGggdGhlIElD TVAgZm91ci1ieXRlIGZpZWxkIGFuZCB0aGUgSUNNUHY2IG1lc3NhZ2UgYm9keS4NCj4gPg0KPiA+ IFtNZWRdIE9LLg0KPiA+DQo+ID4gPg0KPiA+ID4gU2VjdGlvbiA1LjENCj4gPiA+DQo+ID4gPiBJ dCBtYXkgYmUgd29ydGggcmVpdGVyYXRpbmcgdGhhdCAocGVyIHRoZSBzaWduYWwtY2hhbm5lbCBk b2MpDQo+ID4gPiBnYXRld2F5cyBtYXkgcmV3cml0ZSB0aGUgJ2N1aWQnLg0KPiA+DQo+ID4gW01l ZF0gT0s6DQo+ID4NCj4gPiAgICBBcyBhIHJlbWluZGVyLCBET1RTIGdhdGV3YXlzIG1heSByZXdy aXRlIHRoZSAnY3VpZCcgdXNlZCBieSBwZWVyIERPVFMNCj4gPiAgICBjbGllbnRzIChTZWN0aW9u IDQuNC4xIG9mIFtJLUQuaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsXSkuDQo+ID4NCj4gPiA+DQo+ ID4gPiBXaGVuIFBPU1QgaXMgdXNlZCB0byBjcmVhdGUgYSBkb3RzLWNsaWVudCByZXNvdXJjZSwg aG93IGRvZXMgdGhlDQo+ID4gPiBjbGllbnQga25vdyB0aGUgcGF0aCBvZiB0aGUgY3JlYXRlZCBy ZXNvdXJjZSAodG8gYmUgdXNlZCBmb3INCj4gPiA+IHN1YnNlcXVlbnQgUkVTVENPTkYgcmVxdWVz dHMpPyAgKEkgYXNzdW1lIGl0IGlzIHN1cHBvc2VkIHRvIGp1c3QgdXNlDQo+ID4gPiB0aGUgc3Vi bWl0dGVkICdjdWlkJywgYnV0IHdlIG5lZWQgdG8gZXhwbGljaXRseSBzYXkgdGhpcy4gIFRoaXMg YWxzbw0KPiA+ID4gc2VlbXMgdG8gcmVuZGVyIG11Y2ggb2YgdGhlIGRpc3RpbmN0aW9uIGJldHdl ZW4gUE9TVCBhbmQgUFVUIG1vb3QsDQo+ID4gPiBmb3Igb3VyIHVzYWdlLCB0aG91Z2ggSSBkbyBu b3QgcHJvcG9zZSBhbnkgY2hhbmdlIHRvIHRoZSB0ZXh0LikNCj4gPg0KPiA+IFtNZWRdIFRoZSBw cm9jZWR1cmUgdG8gZGV0ZXJtaW5lIHRoZSByb290IHBhdGggaXMgcmVjYWxsZWQgaW4gU2VjdGlv biAzLjEsDQo+IHRoZW4gbm9ybWFsIFJFU1RDT05GIG9wZXJhdGlvbiBpcyBmb2xsb3dlZC4NCj4g Pg0KPiA+ID4NCj4gPiA+ICAgIFRoZSBET1RTIGdhdGV3YXksIHRoYXQgaW5zZXJ0ZWQgYSAnY2Rp ZCcgaW4gYSBQVVQgcmVxdWVzdCwgTVVTVCBzdHJpcA0KPiA+ID4gICAgdGhlICdjZGlkJyBwYXJh bWV0ZXIgaW4gdGhlIGNvcnJlc3BvbmRpbmcgcmVzcG9uc2UgYmVmb3JlIGZvcndhcmRpbmcNCj4g PiA+ICAgIHRoZSByZXNwb25zZSB0byB0aGUgRE9UUyBjbGllbnQuDQo+ID4gPg0KPiA+ID4gV2h5 IGRvZXMgdGhpcyBhcHBseSBvbmx5IHRvIFBVVCBhbmQgbm90IFBPU1Q/DQo+ID4NCj4gPiBbTWVk XSBCZWNhdXNlIFJGQzgwNDAgc2F5cyB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gICAgSWYgdGhl IFBPU1QgbWV0aG9kIHN1Y2NlZWRzLCBhICIyMDEgQ3JlYXRlZCIgc3RhdHVzLWxpbmUgaXMgcmV0 dXJuZWQNCj4gPiAgICBhbmQgdGhlcmUgaXMgbm8gcmVzcG9uc2UgbWVzc2FnZS1ib2R5Lg0KPiA+ ICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+IA0KPiBXaG9vcHMs IEkgY2xlYXJseSBtaXNzZWQgdGhhdCBwYXJ0LiAgVGhhbmtzIGZvciBjYWxsaW5nIGl0IG91dC4N Cj4gDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiA2LjENCj4gPiA+DQo+ID4gPiAgICBET1RTIGNsaWVu dHMgd2l0aGluIHRoZSBzYW1lIGRvbWFpbiBjYW4gY3JlYXRlIGRpZmZlcmVudCBhbGlhc2VzIGZv cg0KPiA+ID4gICAgdGhlIHNhbWUgcmVzb3VyY2UuDQo+ID4gPg0KPiA+ID4gTXkgcmVhZGluZyBv ZiB0aGlzIHRleHQgaXMgdGhhdCBjbGllbnQgQSBjYW4gY3JlYXRlIGFsaWFzICJmb28iIGZvcg0K PiA+ID4gSVAgcHJlZml4IDEyOC4wLjEuNS8zMSBhbmQgY2xpbmV0IEIgY2FuIGNyZWF0ZSBhbGlh cyAiYmFyIiBmb3IgdGhlDQo+ID4gPiBzYW1lIElQIHByZWZpeCwgYW5kIHRoYXQgRE9UUyBzdXBw b3J0cyB0aGF0IHByb2Nlc3MuICAoSnVzdCB0bw0KPiA+ID4gY29uZmlybSB0aGF0IHRoZSB0ZXh0 IGlzIHNheWluZyB3aGF0IGl0J3MgaW50ZW5kZWQgdG8uKQ0KPiA+DQo+ID4gW01lZF0gWWVzLg0K PiA+DQo+ID4gICBJIGRvIHdvbmRlciBpZiB3ZSB3YW50IHRvIHNheQ0KPiA+ID4gc29tZXRoaW5n IGFib3V0IHdoZXRoZXIgYWxpYXMgbmFtZXMgbmVlZCBvbmx5IGJlIHVuaXF1ZSBwZXIgJ2N1aWQn DQo+ID4gPiBvciBpbiBzb21lIG1vcmUgZ2xvYmFsIGZhc2hpb24uICAoSGF2aW5nIGEgZ2xvYmFs IHVuaXF1ZW5lc3MNCj4gPiA+IHByb3BlcnR5IGlzIHBlcmhhcHMgY29udmVuaWVudCBpbiBvcmRl ciB0byBpbnRlcmZhY2Ugd2l0aCBub24tRE9UUw0KPiA+ID4gbWVjaGFuaXNtcyBmb3IgcXVlcnlp bmcgYWxpYXNlcywgb3IgZm9yIHRoZSBET1RTIHNlcnZlciB0byBpbnRlcmFjdA0KPiA+ID4gd2l0 aCBuZXR3b3JrIGZpbHRlcmluZw0KPiA+ID4gYXBwbGlhbmNlcy4pDQo+ID4NCj4gPiBbTWVkXSBU aGUgc3BlY2lmaWNhdGlvbiBkb2VzIHJlcXVpcmUgdW5pcXVlbmVzcyBwZXIgY3VpZDoNCj4gPg0K PiA+ICAgICAgICAgfCAgKy0tcncgYWxpYXNlcw0KPiA+ICAgICAgICAgICB8ICB8ICArLS1ydyBh bGlhcyogW25hbWVdDQo+ID4gICAgICAgICAgIHwgIHwgICAgICstLXJ3IG5hbWUgICAgICAgICAg ICAgICAgIHN0cmluZw0KPiA+DQo+ID4gV2UgZG9uJ3QgaGF2ZSBhIHJlcXVpcmVtZW50IGZvciB1 bmlxdWVuZXNzIHBlciBkb21haW4gb3IgZ2xvYmFsbHkuDQo+ID4NCj4gPiBJZiBzdWNoIHJlcXVp cmVtZW50IGFyaXNlLCB0aGUgc2VtYW50aWMvbG9naWMgZm9yIGNyZWF0aW5nIHRob3NlIGFsaWFz ZXMgY2FuDQo+IGJlIGhhbmRsZWQgb3V0IG9mIGJhbmQuDQo+IA0KPiBPay4NCj4gDQo+ID4gPg0K PiA+ID4gRmlndXJlIDE2IHB1dHMgZG91YmxlLXF1b3RlcyBhcm91bmQgInN0cmluZyIgaW4gdGhl IHBzZXVkby1zY2hlbWEsDQo+ID4gPiB3aGljaCBmZWVscyB3ZWlyZCB0byBtZS4NCj4gPg0KPiA+ IFtNZWRdIFRoaXMgaXMgYWxzbyB3aGF0IHdlIGhhdmUgZG9uZSBmb3Igb3RoZXIgZmlndXJlcyAs IGUuZy4sIDExLiBUaGUgaW50ZW50IGlzDQo+IHRvIHVzZSBhIHNjaGVtZS1saWtlIG1lc3NhZ2Ug Ym9keSB3aGlsZSB0cnlpbmcgdG8gcHJlc2VydmUgSlNPTiBjb21wbGlhbmNlLg0KPiA+DQo+ID4g Pg0KPiA+ID4gICAgdGFyZ2V0LWZxZG46ICAgQSBsaXN0IG9mIEZ1bGx5IFF1YWxpZmllZCBEb21h aW4gTmFtZXMgKEZRRE5zKS4gIEFuDQo+ID4gPiAgICAgICBGUUROIGlzIHRoZSBmdWxsIG5hbWUg b2YgYSByZXNvdXJjZSwgcmF0aGVyIHRoYW4ganVzdCBpdHMNCj4gPiA+ICAgICAgIGhvc3RuYW1l LiAgRm9yIGV4YW1wbGUsICJ2ZW5lcmEiIGlzIGEgaG9zdG5hbWUsIGFuZA0KPiA+ID4gICAgICAg InZlbmVyYS5pc2kuZWR1IiBpcyBhbiBGUUROIFtSRkMxOTgzXS4gIFJlZmVyIHRvDQo+ID4gPiAg ICAgICBbSS1ELmlldGYtZG5zb3AtdGVybWlub2xvZ3ktYmlzXSBmb3IgbW9yZSBkZXRhaWxzLg0K PiA+ID4NCj4gPiA+IEkgZG9uJ3QgdGhpbmsgdGhpcyB0ZXh0IGlzIHBhcnRpY3VsYXJseSB3ZWxs LWFsaWduZWQgd2l0aCBSRkMgODQ5OQ0KPiA+ID4gYW5kIHdvdWxkIHN1Z2dlc3QgdHJpbW1pbmcg aXQgc3Vic3RhbnRpYWxseSBhbmQganVzdCBwb2ludGluZyB0byB0aGF0IFJGQy4NCj4gPg0KPiA+ IFtNZWRdIERvbmUuDQo+ID4NCj4gPiA+DQo+ID4gPiAgICBJZiB0aGUgcmVxdWVzdCBpcyBtaXNz aW5nIGEgbWFuZGF0b3J5IGF0dHJpYnV0ZSBvciBpdHMgY29udGFpbnMgYW4NCj4gPiA+ICAgIGlu dmFsaWQgb3IgdW5rbm93biBwYXJhbWV0ZXIsICI0MDAgQmFkIFJlcXVlc3QiIHN0YXR1cy1saW5l IE1VU1QgYmUNCj4gPiA+ICAgIHJldHVybmVkIGJ5IHRoZSBET1RTIHNlcnZlci4gIFRoZSBlcnJv ci10YWcgaXMgc2V0IHRvICJtaXNzaW5nLQ0KPiA+ID4gICAgYXR0cmlidXRlIiwgImludmFsaWQt dmFsdWUiLCBvciAidW5rbm93bi1lbGVtZW50IiBhcyBhIGZ1bmN0aW9uIG9mDQo+ID4gPiAgICB0 aGUgZW5jb3VudGVyZWQgZXJyb3IuDQo+ID4gPg0KPiA+ID4gVGhpcyB0ZXh0IHNlZW1zIHRvIHBy ZWNsdWRlIGFueSBmdXR1cmUgZXh0ZW5zaW9uIHRoYXQgYWRkcyBuZXcgZXJyb3INCj4gPiA+IHRh Z3M7IGlzIHRoaXMgaW50ZW5kZWQ/DQo+ID4NCj4gPiBbTWVkXSBUaG9zZSBlcnJvcnMgYXJlIG9u bHkgYWJvdXQgdGhlIHRyZWUgZmFpbHVyZSBjYXNlcyBjYWxsZWQgaW4gdGhlIGZpcnN0DQo+IHNl bnRlbmNlLg0KPiA+DQo+ID4gPg0KPiA+ID4gU2VjdGlvbiA3LjENCj4gPiA+DQo+ID4gPiAgICBB IERPVFMgY2xpZW50IHdoaWNoIGlzc3VlZCBhIEdFVCByZXF1ZXN0IHRvIHJldHJpZXZlIHRoZSBm aWx0ZXJpbmcNCj4gPiA+ICAgIGNhcGFiaWxpdGllcyBzdXBwb3J0ZWQgYnkgaXRzIERPVFMgc2Vy dmVyLCBTSE9VTEQgTk9UIHJlcXVlc3QgZm9yDQo+ID4gPiAgICBmaWx0ZXJpbmcgYWN0aW9ucyB0 aGF0IGFyZSBub3Qgc3VwcG9ydGVkIGJ5IHRoYXQgRE9UUyBzZXJ2ZXIuDQo+ID4gPg0KPiA+ID4g V2hhdCBpcyB0aGUgc2VydmVyIGJlaGF2aW9yIGlmIHRoZSBjbGllbnQgaWdub3JlcyB0aGlzIFNI T1VMRCBOT1Q/DQo+ID4NCj4gPiBbTWVkXSBUaGlzIGlzIGNvdmVyZWQgYnkgdGhpcyB0ZXh0Og0K PiA+DQo+ID4gICAgSWYgdGhlIHJlcXVlc3QgaXMgbWlzc2luZyBhIG1hbmRhdG9yeSBhdHRyaWJ1 dGUgb3INCj4gPiAgICBjb250YWlucyBhbiBpbnZhbGlkIG9yIHVua25vd24gcGFyYW1ldGVyIChl LmcuLCBhIG1hdGNoIGZpZWxkIG5vdA0KPiA+ICAgIHN1cHBvcnRlZCBieSB0aGUgRE9UUyBzZXJ2 ZXIpLCAiNDAwIEJhZCBSZXF1ZXN0IiBzdGF0dXMtbGluZSBNVVNUIGJlDQo+ID4gICAgcmV0dXJu ZWQgYnkgdGhlIERPVFMgc2VydmVyIGluIHRoZSByZXNwb25zZS4NCj4gDQo+IHNvdW5kcyBnb29k Lg0KPiANCj4gPiA+DQo+ID4gPiAgICBGaWd1cmUgMjMgc2hvd3MgYW4gZXhhbXBsZSBvZiBhIHJl c3BvbnNlIHJlY2VpdmVkIGZyb20gYSBET1RTIHNlcnZlcg0KPiA+ID4gICAgd2hpY2ggb25seSBz dXBwb3J0cyB0aGUgbWFuZGF0b3J5IGZpbHRlcmluZyBjcml0ZXJpYSBsaXN0ZWQgaW4NCj4gPiA+ ICAgIFNlY3Rpb24gNC4xLg0KPiA+ID4NCj4gPiA+IFRoaXMgc2VlbXMgaW5hY2N1cmF0ZSwgYXMg dGhlIG1hbmRhdG9yeSBmaWx0ZXJpbmcgY3JpdGVyaWEgZXhsdWRlDQo+ID4gPiB0aGUgcmF0ZS1s aW1pdCBhbW9uZyBvdGhlcnMuDQo+ID4NCj4gPiBbTWVkXSByYXRlLWxpbWl0IGlzIGFuIGFjdGlv biwgbm90IGEgZmlsdGVyaW5nIGNyaXRlcmlhLg0KPiA+DQo+ID4gPg0KPiA+ID4gU2VjdGlvbiA3 LjINCj4gPiA+DQo+ID4gPiAgICBhY3RpdmF0aW9uLXR5cGU6ICBJbmRpY2F0ZXMgd2hldGhlciBh biBBQ0wgaGFzIHRvIGJlIGFjdGl2YXRlZA0KPiA+ID4gICAgICAgKGltbWVkaWF0ZWx5IG9yIGR1 cmluZyBtaXRpZ2F0aW9uIHRpbWUpIG9yIGluc3RhbnRpYXRlZCB3aXRob3V0DQo+ID4gPiAgICAg ICBiZWluZyBhY3RpdmF0ZWQgKGRlYWN0aXZhdGVkKS4gIERlYWN0aXZhdGVkIEFDTHMgY2FuIGJl IGFjdGl2YXRlZA0KPiA+ID4gICAgICAgdXNpbmcgYSB2YXJpZXR5IG9mIG1lYW5zIHN1Y2ggYXMg bWFudWFsIGNvbmZpZ3VyYXRpb24gb24gYSBET1RTDQo+ID4gPiAgICAgICBzZXJ2ZXIgb3IgdXNp bmcgdGhlIERPVFMgZGF0YSBjaGFubmVsLg0KPiA+ID4NCj4gPiA+IElzIHRoaXMgZG9uZSBieSB0 aGUgZGF0YSBjaGFubmVsIG9yIHRoZSBzaWduYWwgY2hhbm5lbD8NCj4gPg0KPiA+IFtNZWRdIFll cywgYnV0IHRoaXMgaXMgbm90IHN1cHBvcnRlZCBpbiB0aGUgYmFzZSBzaWduYWwtY2hhbm5lbCBz cGVjLiBUaGlzIGlzDQo+IHRoZSBkb25lIHVzaW5nIHRoZSBmaWx0ZXJpbmcgY29udHJvbCBmZWF0 dXJlIChkcmFmdC1uaXNoaXp1a2EtZG90cy1zaWduYWwtY29udHJvbC0NCj4gZmlsdGVyaW5nKS4g VGhpcyBpcyB3aHkgc2lnbmFsIGNoYW5uZWwgaXMgbm90IGxpc3RlZCBhZnRlciAic3VjaCBhcyIu DQo+IA0KPiBPa2F5LiAgKEkgd2FzIGxpdGVyYWxseSBqdXN0IHdvbmRlcmluZyBpZiB0aGlzIHdh cyBhIHR5cG8uKQ0KPiANCj4gPiA+DQo+ID4gPiAgICAgICBJZiB0aGlzIGF0dHJpYnV0ZSBpcyBu b3QgcHJvdmlkZWQsIHRoZSBET1RTIHNlcnZlciBNVVNUIHVzZQ0KPiA+ID4gICAgICAgJ2FjdGl2 YXRlLXdoZW4tbWl0aWdhdGluZycgYXMgZGVmYXVsdCB2YWx1ZS4NCj4gPiA+DQo+ID4gPiBXaHkg ZG8gd2Ugc3BlY2lmeSBkZWZhdWx0IHZhbHVlcyBoZXJlIGluc3RlYWQgb2YgaW4gdGhlIFlBTkcg bW9kdWxlPw0KPiA+DQo+ID4gW01lZF0gVGhlcmUgaXMgbm8gZGVmYXVsdCBzdGF0ZW1lbnQgZm9y IGVudW1lcmF0aW9uLiBUbyBzb2x2ZSB0aGlzLCBhIG5ldw0KPiB0eXBlIGlzIGRlZmluZWQgaW4g dGhlIG1vZHVsZSAoYWN0aXZhdGlvbi10eXBlKS4gVGhpcyB0eXBlIGlzIHRoZW4gdXNlZCBmb3Ig dGhlDQo+IGFjdGl2YXRpb24tdHlwZSBsZWFmIHdpdGggYSBkZWZhdWx0IHZhbHVlIHNldCB0byBh Y3RpdmF0ZS13aGVuLW1pdGlnYXRpbmcuDQo+IA0KPiBUaGF0J3MgYSBjbGV2ZXIgd29ya2Fyb3Vu ZCENCj4gDQo+ID4gVGhlIGNoYW5nZSBpbiB0cmVlIGRpYWdyYW0gaXMgKG5vIG5lZWQgdG8gaW5z ZXJ0IHRoZSBjb2RlIGhlcmUpOg0KPiA+DQo+ID4gT0xEOg0KPiA+ICAgICAgICB8ICAgICAgICAr LS1ydyBhY3RpdmF0aW9uLXR5cGU/ICAgIEVudW1lcmF0aW9uDQo+ID4NCj4gPiBORVc6DQo+ID4g ICAgICB8ICAgICAgICArLS1ydyBhY3RpdmF0aW9uLXR5cGU/ICAgIGFjdGl2YXRpb24tdHlwZQ0K PiA+DQo+ID4NCj4gPiA+DQo+ID4gPiAgICAgICBGaWx0ZXJzIHRoYXQgYXJlIGFjdGl2YXRlZCBv bmx5IHdoZW4gYSBtaXRpZ2F0aW9uIGlzIGluIHByb2dyZXNzDQo+ID4gPiAgICAgICBNVVNUIGJl IGJvdW5kIHRvIHRoZSBET1RTIGNsaWVudCB3aGljaCBjcmVhdGVkIHRoZSBmaWx0ZXJpbmcgcnVs ZS4NCj4gPiA+DQo+ID4gPiBPdGhlciBmaWx0ZXJzIGRvIG5vdCBuZWVkIHRvIGJlIGJvdW5kIHRv IHRoZSBET1RTIGNsaWVudCB0aGF0IGNyZWF0ZWQgdGhlbT8NCj4gPg0KPiA+IFtNZWRdIFRoZXkg YXJlLi4uYnV0IHRob3NlIGZpbHRlcnMgYXJlIGFscmVhZHkgZW5mb3JjZWQgYmVjYXVzZSB0aGV5 IGFyZQ0KPiBpbW1lZGlhdGUuDQo+IA0KPiBUaGUgd29yZGluZyBoZXJlIGlzIHN0aWxsIHdlaXJk LCB0aG91Z2ggLS0gYnkgY2FsbGluZyBvdXQgdGhlIGRlbGF5ZWQtYWN0aXZhdGlvbg0KPiBmaWx0 ZXJzIGl0IGltcGxpZXMgdGhhdCBpbW1lZGlhdGUtYWN0aXZhdGlvbiBmaWx0ZXJzIGFyZSBleGNs dWRlZCBmcm9tIHRoZQ0KPiBzdGF0ZW1lbnQsIGJ1dCB3ZSBrbm93IHRoYXQgaW1tZWRpYXRlLWFj dGl2YXRpb24gZmlsdGVycw0KPiBhbHNvIGhhdmUgdGhlIHNhbWUgcHJvcGVydHkuICAgU28gSSdt IG5vdCBlbnRpcmVseSBzdXJlIGV4YWN0bHkgd2hhdA0KPiBpbmZvcm1hdGlvbiB0aGlzIHNlbnRl bmNlIGlzIGludGVuZGVkIHRvIGNhbGwgb3V0Lg0KPiANCj4gPiA+IFdvdWxkbid0IHdlIHN0aWxs IHdhbnQgdG8gcmVtb3ZlIHRoZW0gd2hlbiB0aGUgZG90cy1jbGllbnQgcmVzb3VyY2UNCj4gPiA+ IGluIHF1ZXN0aW9uIGlzIGRlbGV0ZWQ/DQo+ID4NCj4gPiBbTWVkXSBUaGlzIGlzIHN1cHBvc2Vk IHRvIGJlIGRvbmUgYnkgdGhlIGNsaWVudCBpdHNlbGYuIEZvciBhbW5lc2lhYyBjbGllbnRzLA0K PiB3ZSBkbyBoYXZlIHRoZSBmb2xsb3dpbmc6DQo+IA0KPiBPaC4gIEkgdGhpbmsgSSB3YXMgcmVt ZW1iZXJpbmcgU2VjdGlvbiA1LjIncyAicmVzb3VyY2VzIGJvdW5kIHRvIHRoaXMgRE9UUw0KPiBj bGllbnQgd2lsbCBiZSBkZWxldGVkIGJ5IHRoZSBET1RTIHNlcnZlciIgYW5kIGFzc3VtaW5nIGl0 IGFwcGxpZXMgdG8gdGhlIGZpbHRlcnMNCj4gYXNzb2NpYXRlZCB3aXRoIHRoYXQgY2xpZW50Lg0K PiANCj4gPiAgICBJbiBvcmRlciB0byBhdm9pZCBzdGFsZSBlbnRyaWVzLCBhIGxpZmV0aW1lIGlz IGFzc29jaWF0ZWQgd2l0aCBhbGlhcw0KPiA+ICAgIGFuZCBmaWx0ZXJpbmcgZW50cmllcyBjcmVh dGVkIGJ5IERPVFMgY2xpZW50cy4gIEFsc28sIERPVFMgc2VydmVycw0KPiA+ICAgIG1heSB0cmFj ayB0aGUgaW5hY3Rpdml0eSB0aW1lb3V0IG9mIERPVFMgY2xpZW50cyB0byBkZXRlY3Qgc3RhbGUN Cj4gPiAgICBlbnRyaWVzLg0KPiANCj4gVGhpcyBpcyBwcm9iYWJseSBlbm91Z2ggdG8gZW5zdXJl IHNhZmUgb3BlcmF0aW9uIHdpdGhvdXQgdGhlIGFib3ZlLCB0aG91Z2gsDQo+IGhtbS4uLg0KPiAN Cj4gPiA+DQo+ID4gPiAgICBkZXN0aW5hdGlvbi1pcHY0LW5ldHdvcms6ICBUaGUgZGVzdGluYXRp b24gSVB2NCBwcmVmaXguICBET1RTIHNlcnZlcnMNCj4gPiA+ICAgICAgIFsuLi5dDQo+ID4gPiAg ICAgICBUaGlzIGlzIGEgbWFuZGF0b3J5IGF0dHJpYnV0ZSBpbiByZXF1ZXN0cyB3aXRoIGFuICdh Y3RpdmF0aW9uLQ0KPiA+ID4gICAgICAgdHlwZScgc2V0IHRvICdpbW1lZGlhdGUnLg0KPiA+ID4N Cj4gPiA+IEkgc29tZWhvdyB0aG91Z2h0IHRoZXJlIHdlcmUgWUFORyBhdHRyaWJ1dGVzIHRoYXQg Y291bGQgaW5kaWNhdGUNCj4gPiA+IHRoaXMgY29uZGl0aW9uYWwgcmVxdWlyZW1lbnQgaW4gdGhl IG1vZHVsZSBpdHNlbGYsIHRob3VnaCBJIGFtDQo+ID4gPiBoYXJkbHkgYSBZQU5HIGV4cGVydC4N Cj4gPg0KPiA+IFtNZWRdIFdlIGFyZSByZXVzaW5nIGZpZWxkcyBmcm9tIGlldGYtbmV0bW9kLWFj bCwgaXQgaXMgbm90IGVhc3kgdG8NCj4gbWFuaXB1bGF0ZSB0aGUgZmllbGRzIGFzIHdlIHdvdWxk IHdhbnQuDQo+IA0KPiBPa2F5Lg0KPiANCj4gPiA+DQo+ID4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIGVycm9yLXRhZyBpcyBzZXQgdG8NCj4g PiA+ICAgICJtaXNzaW5nLWF0dHJpYnV0ZSIsICJpbnZhbGlkLXZhbHVlIiwgb3IgInVua25vd24t ZWxlbWVudCIgYXMgYQ0KPiA+ID4gICAgZnVuY3Rpb24gb2YgdGhlIGVuY291bnRlcmVkIGVycm9y Lg0KPiA+ID4NCj4gPiA+IFNhbWUgY29tbWVudCBhcyBhYm92ZSBhYm91dCAobm9uLSlleHRlbnNp YmlsaXR5Lg0KPiA+DQo+ID4gW01lZF0gSWRlbSBhcyBhYm92ZS4NCj4gPg0KPiA+ID4NCj4gPiA+ IFNlY3Rpb24gNy4zDQo+ID4gPg0KPiA+ID4gSSBzZWUgdGhhdCB0aGUgInRlc3QtYWNsLSoiIGFu ZCAidGVzdC1hY2UtKiIgYWNsIGFuZCBhY2Ugb2JqZWN0cyBpbg0KPiA+ID4gdGhlc2UgZXhhbXBs ZXMgZG8gaW4gZmFjdCB1c2UgZGlmZmVyZW50IG5hbWVzIGZvciB0aGUgc2VtYW50aWNhbGx5DQo+ ID4gPiBkaWZmZXJlbnQgb2JqZWN0cywgYnV0IHBlcmhhcHMgd2UgY291bGQgaGVscCB0aGUgcmVh ZGVyJ3MgZXllIGFuZA0KPiA+ID4gdXNlIHN0cmluZ3Mgd2l0aCBhIGxhcmdlciBIYW1taW5nIGRp c3RhbmNlPyAgKEkgdGhvdWdodCB0aGV5IHdlcmUNCj4gPiA+IGFsbCB0aGUgc2FtZSBvbiBteSBm aXJzdA0KPiA+ID4gcmVhZC4pDQo+ID4NCj4gPiBbTWVkXSBGaXhlZC4NCj4gPg0KPiA+ID4NCj4g PiA+IChJIGFsc28gYW0gYSBsaXR0bGUgY29uZnVzZWQgYXQgd2h5IHRoZSAiYWNlIiAibmFtZSIg ZmllbGQgaXMNCj4gPiA+IGNvbnNpZGVyZWQgYSBub24tY29uZmlnIGZpZWxkLCBpbiBGaWd1cmUg MzEsIGJ1dCB0aGlzIHNlZW1zIG1vcmUNCj4gPiA+IGxpa2VseSB0byBiZSBteSBjb25mdXNpb24g dGhhbiBhbiBlcnJvciBpbiB0aGUgZG9jdW1lbnQuKQ0KPiA+DQo+ID4gW01lZF0gVGhpcyBpcyBi ZWNhdXNlIHRoZSBuYW1lIGlzIHRoZSBrZXkgb2YgdGhlIGFjZSBsaXN0Lg0KPiA+DQo+ID4gUkZD ODA0MCBzYXlzIHRoZSBmb2xsb3dpbmc6DQo+ID4NCj4gPiAgICBUbyByZXRyaWV2ZSBvbmx5IHRo ZSBub24tY29uZmlndXJhdGlvbiBjaGlsZCByZXNvdXJjZXMsIHRoZSAiY29udGVudCINCj4gPiAg ICBwYXJhbWV0ZXIgaXMgc2V0IHRvICJub25jb25maWciLiAgTm90ZSB0aGF0IGNvbmZpZ3VyYXRp b24gYW5jZXN0b3JzDQo+ID4gICAgKGlmIGFueSkgYW5kIGxpc3Qga2V5IGxlYWZzIChpZiBhbnkp IGFyZSBhbHNvIHJldHVybmVkLg0KPiANCj4gVGhhbmtzIGZvciB0aGUgcG9pbnRlci4NCj4gDQo+ ID4gPg0KPiA+ID4gU2VjdGlvbiA4DQo+ID4gPg0KPiA+ID4gICAgbyAgRE9UUyBzZXJ2ZXIgTVVT VCBOT1QgZW5hYmxlIGJvdGggRE9UUyBkYXRhIGNoYW5uZWwgYW5kIGRpcmVjdA0KPiA+ID4gICAg ICAgY29uZmlndXJhdGlvbiB0byBhdm9pZCByYWNlIGNvbmRpdGlvbnMgYW5kIGluY29uc2lzdGVu dA0KPiA+ID4gICAgICAgY29uZmlndXJhdGlvbnMgYXJpc2luZyBmcm9tIHNpbXVsdGFuZW91cyB1 cGRhdGVzIGZyb20gbXVsdGlwbGUNCj4gPiA+ICAgICAgIHNvdXJjZXMuDQo+ID4gPg0KPiA+ID4g ICAgbyAgRE9UUyBhZ2VudHMgU0hPVUxEIGVuYWJsZSBET1RTIGRhdGEgY2hhbm5lbCB0byBjb25m aWd1cmUgYWxpYXNlcw0KPiA+ID4gICAgICAgYW5kIEFDTHMsIGFuZCBvbmx5IHVzZSBkaXJlY3Qg Y29uZmlndXJhdGlvbiBhcyBhIHN0b3AtZ2FwDQo+ID4gPiAgICAgICBtZWNoYW5pc20gdG8gdGVz dCBET1RTIHNpZ25hbCBjaGFubmVsIHdpdGggYWxpYXNlcyBhbmQgQUNMcy4NCj4gPiA+ICAgICAg IEZ1cnRoZXIsIGRpcmVjdCBjb25maWd1cmF0aW9uIFNIT1VMRCBvbmx5IGJlIHVzZWQgd2hlbiB0 aGUgb24tcGF0aA0KPiA+ID4gICAgICAgRE9UUyBhZ2VudHMgYXJlIHdpdGhpbiB0aGUgc2FtZSBk b21haW4uDQo+ID4gPg0KPiA+ID4gRG9lc24ndCBhbGwgdGhpcyBkaXNjdXNzaW9uIG9mICJkaXJl Y3QgY29uZmlndXJhdGlvbiIgY29uZmxpY3Qgd2l0aA0KPiA+ID4gdGhlICJNVVNUIE5PVCIgaW4g dGhlIGZpcnN0IGJ1bGxldCBwb2ludD8NCj4gPg0KPiA+IFtNZWRdIFRoZSBzZWNvbmQgYnVsbGV0 IGlzIGFib3V0IGNvbnRyb2xsZWQgdGVzdGluZyBvZiB0aGUgKnNpZ25hbCBjaGFubmVsKg0KPiB3 aXRoIGFsaWFzZXMvYWNscyBjb21tdW5pY2F0ZWQgYnkgdGhlIGRhdGEgY2hhbm5lbC4NCj4gDQo+ IFdob29wcywgbXkgbWlzcmVhZC4NCj4gDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAxMA0KPiA+ID4N Cj4gPiA+IEdlbmVyYWxseSB3aXRoIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0ZW1wbGF0 ZSBmb3IgWUFORw0KPiA+ID4gbW9kdWxlcywgd2UgbmVlZCB0byBsaXN0IG91dCBhbGwgdGhlIG5v ZGVzIGNvbnNpZGVyZWQgc2Vuc2l0aXZlIGFuZA0KPiA+ID4gdGhlIGNvbnNlcXVlbmNlcyBvZg0K PiA+ID4gd3JpdGluZygvcmVhZGluZykgZWFjaCBvbmUgaW4gdHVybi4NCj4gPiA+DQo+ID4NCj4g PiBbTWVkXSBUaGUgdGV4dCBkb2VzIGFscmVhZHkgY2FsbCBvdXQgdGhvc2UgdGhhdCBhcmUgc3Bl Y2lmaWMgdG8gdGhpcyBkb2N1bWVudC4NCj4gRm9yIG90aGVyIG5vZGVzLCB3ZSBkbyBoYXZlIHRo aXMgdGV4dDoNCj4gPg0KPiA+ICAgICJZQU5HIEFDTC1zcGVjaWZpYyBzZWN1cml0eQ0KPiA+ICAg IGNvbnNpZGVyYXRpb25zIGFyZSBkaXNjdXNzZWQgaW4gW0ktRC5pZXRmLW5ldG1vZC1hY2wtbW9k ZWxdLiINCj4gPg0KPiA+IEkgdGhpbmsgd2UgYXJlIE9LLg0KPiANCj4gSSB3b3VsZCBzdWdnZXN0 IGFkZGluZyBhIG5ldyBzZW50ZW5jZSBpbiB0aGUgIkFsbCBkYXRhIG5vZGVzIGRlZmluZWQiDQo+ IHBhcmFncmFwaCBhYm91dCAiVGhpcyBtb2R1bGUgcmV1c2VzIFlBTkcgc3RydWN0dXJlcyBmcm9t IFtJLUQuaWV0Zi1uZXRtb2QtDQo+IGFjbC1tb2RlbF0sIGFuZCB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgZm9yIHRob3NlIG5vZGVzIGNvbnRpbnVlIHRvIGFwcGx5DQo+IGZvciB0aGlzIHVz YWdlLiIsIHNpbmNlIHRoYXQgdGV4dCBpcyBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBzZWN0aW9u IGFuZCBpdCdzDQo+IG90aGVyd2lzZSBoYXJkIHRvIG1ha2UgYSBsaW5rYWdlIGJldHdlZW4gdGhl bS4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IEJlbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90c0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Fri Feb 15 03:06:42 2019 Return-Path: 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 7A95B130F84; Fri, 15 Feb 2019 03:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 2diJmB3KyNH3; Fri, 15 Feb 2019 03:06:38 -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 5B23E130FA2; Fri, 15 Feb 2019 03:06:38 -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=1550228690; 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=Q4M/Iv1Awip/5yfZljcOZK0+55kimu1nhOTIy1 GnfEk=; b=H5qjkdEku+ijGpvIx368Dnzv9+AlfeoqBv6r+2y6 XJoTILBB16769OcnYpI5P5HAa+wld3rrHUwi4+u78vs0MjW3Gi Wn012nYKHvNwZB3dXVIyWGPI+G1hzt2xtPj6BxG+V/e5qm0GFn k1RYg7Hkf7oUhVZPHFMAVP4wehordwg= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 530d_7877_d48c8805_08b7_4046_8c09_40568a9be5e8; Fri, 15 Feb 2019 04:04:50 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Feb 2019 04:06:19 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 15 Feb 2019 04:06:19 -0700 Received: from NAM04-CO1-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; Fri, 15 Feb 2019 04:06:18 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2423.namprd16.prod.outlook.com (20.177.225.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Fri, 15 Feb 2019 11:06:17 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1622.016; Fri, 15 Feb 2019 11:06:17 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Benjamin Kaduk" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxRIUo475NEhnvke5Q68IH00fwKXgsiOQ Date: Fri, 15 Feb 2019 11:06:17 +0000 Message-ID: References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA1FCF6@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0f788349-1341-4b4b-7d17-08d693359c03 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2423; x-ms-traffictypediagnostic: BYAPR16MB2423: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNDIzOzIzOmZLblhTYm9ndGVzY3BtTUtJbUtyUG9mSTJl?= =?utf-8?B?N05XYWVNMUFUR0dDa3NTNmcweFZsVXpTL0ZwT1JqQUZqU3haK0JKUHJjWFJS?= =?utf-8?B?V2o3UW1jVVBqNU5yK0Zxb0w2ZDF6eXJXUXlHdWtsRkRNWmNJOG5QTEJSaDNV?= =?utf-8?B?YlpFcWM1M25iM0hVUGpNbndDV2lUZHZQcmtUU2psM3JveklBcEFPVWg0RWM1?= =?utf-8?B?RDFJMEJ1T3RYRU9yYjVBVXpuRytObythNFpiOTF4M1pLeUd6a1JJSTBqZVZW?= =?utf-8?B?aUlaM292ekZOazNqS2JTUkNDY2xDakVvTURSZjB2ME9wM3FBaUc3LzlvS08x?= =?utf-8?B?ZEhGY1p5enR3VWVxN3RYZUV3OHRBOE82VHgydDQ2T3RqMzhmVVJiS0NIdG5I?= =?utf-8?B?NDRFRFpEZEJsY0NrMUVWOXd6YVNrQVYwTWJuNGYxS2JzcXFzSndidktZY0sr?= =?utf-8?B?VGtYU1VYcThHaWtWVnhNYUk0ZEhPYThka1VaZFRCdTA4bDZBam1XMzVuTVNO?= =?utf-8?B?VytSL3ZjQWd4R3kvTXV2TW1qTURvRTZ3SFYrYU1MelJOcHZIbGtaL2M4SWJv?= =?utf-8?B?amhEY2RISjZGaFFEMnhMZnJTcHV2NzlLYU5Fb3dPV2lpcDZPTWFDMWpHS2hk?= =?utf-8?B?RkFscGVtM3JNY1B4QlQxUFYxMEZkV0NwellTZ0ZUdzNPVzUzTHZTNGtnZUJT?= =?utf-8?B?Yk03QW81U2s2WkljejlPeXRCMmRxVTR6Uzk5QnVMc0FVeDBUazhaNEZYdEtl?= =?utf-8?B?cCtaaHVrZnM2VitDTzg0bncrVm9CVzhaODNqcEZTU29UellRRUduWDQ1Qy9h?= =?utf-8?B?UDhwRjZRdHFhMjcrOWFMMms3UWhBTmI2cTZHbEtsc0RUQUtpbmtUczQyS0JR?= =?utf-8?B?S081alNYRFFOZmcrb21kSmtTZ3NNa2lQUXJMNlFkMDFhQXRyVW1FYVl4VW5S?= =?utf-8?B?YU5TMHdqVWtQb2Z6NTliL0dObUIvSFl1bDc1UThKK0lSa3Y5eWdVN0JtK0w3?= =?utf-8?B?elJlbXlFcytaeFJIdEhpOFJMRVVIR1ZBQ3YycXhvaThrYjBuS1I1VGxEV1Bt?= =?utf-8?B?VjFIbnQ0QjVlRnJBbjkzc1JMZEtreFYwWG5kVWZSMlVTdTBNYVVpQzdyOXFp?= =?utf-8?B?eWkvUEZTVXFNejJrOHpkOVhibTJFcGRPZHRCZTJJN0I5M2YzNjl0STFnTmht?= =?utf-8?B?ekVVc0xRSkJmTGNQTU5CR1RBYVJsWlRKeFNiUHFkN0t2NnpCQzNQMmNwd1Rq?= =?utf-8?B?Z2F5UG1NQktveFdKS3VMTEN4VDc2Ym5LV0NFZlVRQlVOVm1od1BDUEExS2pJ?= =?utf-8?B?bjU4L3JqYmhuU3IvZVBzQktSZ1FwSGVXQjZISmRHZm5IZkhyQzNkSFpyT1Fr?= =?utf-8?B?RXpJYURscFJnR1BUZGFjajkxT2VQbVNJd1R6UmlEUUticHJZakhvTzhoU2hK?= =?utf-8?B?YjlFbmlBaldUT0NWNHdxcXZ4Vk51MW9OYmlUMUJZQ3lSVVlReHVxaHNpUndR?= =?utf-8?B?RG50ZDQ1dGdJR0JCbWtZR2NPSGdHdnQvcENpR1RKa1VvU0FxdGRFUnpvVUg3?= =?utf-8?B?VHNka0hsU0VBUUo4anluZUpsTTg1RUhBbjU3TXlnWThEU0hoQjlVendFcTQx?= =?utf-8?B?RFhIb0E0RGZnbVBsdzJaa1lTRmZuZ0Q3dWJUcWxleElnYWs1dzVEZ21MM25H?= =?utf-8?B?bE44dnlyTldWZDU0MjBITHFWb28yQVJYSGVRVU8vdy93c0xNSWhIMzU5N1lo?= =?utf-8?B?alhkL0JBcGtlKyttMkpxb0hOVFg1OFJ3L1NNUWhwdFNzQnIxdXBIQVFjM3BF?= =?utf-8?Q?1Nw2folv7jTQu?= x-microsoft-antispam-prvs: x-forefront-prvs: 09497C15EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(376002)(346002)(136003)(189003)(199004)(32952001)(93886005)(11346002)(486006)(2171002)(106356001)(4326008)(25786009)(6246003)(66066001)(14444005)(256004)(53936002)(80792005)(86362001)(72206003)(478600001)(55016002)(97736004)(6436002)(229853002)(14454004)(9686003)(68736007)(316002)(305945005)(7736002)(8936002)(99286004)(186003)(2501003)(74316002)(8676002)(54906003)(26005)(81156014)(110136005)(2906002)(102836004)(105586002)(7696005)(81166006)(33656002)(71200400001)(71190400001)(76176011)(446003)(6506007)(476003)(6116002)(3846002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2423; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: ZHs5FiSBO6adkxXjTJbOoBgynhxwdtNBr4ptq6GfAlGVhvU5Mumq30Zv+Q9Q5tXHZt7szvgTtBlJFd9G/nfzhu5NcMpqColef/eCKarI6FVCXYAbX7cU4iB/fCoBqQa8joc7/Rvt3Lp4ha17p4dn+gc1rXgzsjdPkEwnGOjSaCBrgfLhjpsZ8/ViL1Rzx8juDDQxmr9cNY+g6ZF8z9fosirqM1DqhTNNh2jIVcK7n1w/BGTB+QRKtXDe0Wv4/Lye1Mq+YRhnOS3M2rXXyWBSXyd8PXsDJ7s369sAmBXt6vNKBfl/45J5eKnD62LTHL3c+QqoldAHOooQbN05i5DKpz0lgvhPU8qnEMom9K8RtEHCAGEDDAnSxHNASdAY1bg9w2+0GK5hXn6njgFiYV69OcLrRuAsYd+ZSLpLtSMxYRE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0f788349-1341-4b4b-7d17-08d693359c03 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 11:06:17.8036 (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: BYAPR16MB2423 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6484> : inlines <7018> : streams <1813101> : uri <2796702> Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 11:06:41 -0000 SSBhbSBjYXRjaGluZyB1cCB3aXRoIHRoZSBkaXNjdXNzaW9uLCBjb3VwbGUgb2YgcG9pbnRzOg0K DQoxKQ0KICAgICAgKiAgSWYgYSBuZXR3b3JrIHJlc291cmNlIChET1RTIGNsaWVudCkgZGV0ZWN0 cyBhIHBvdGVudGlhbCBERG9TDQogICAgICAgICBhdHRhY2sgZnJvbSBhIHNldCBvZiBJUCBhZGRy ZXNzZXMsIHRoZSBET1RTIGNsaWVudCBpbmZvcm1zIGl0cw0KICAgICAgICAgc2VydmljaW5nIERP VFMgZ2F0ZXdheSBvZiBhbGwgc3VzcGVjdCBJUCBhZGRyZXNzZXMgdGhhdCBuZWVkIHRvDQogICAg ICAgICBiZSBkcm9wLSBvciBhY2NlcHQtbGlzdGVkIGZvciBmdXJ0aGVyIGludmVzdGlnYXRpb24u DQoNCkNvbW1lbnQ+IEkgZG9uJ3Qgc2VlIHdoeSBzdXNwZWN0IElQIGFkZHJlc3NlcyB3aWxsIGJl IGFjY2VwdC1saXN0ZWQgPw0KICAgICAgICAgICAgICAgICAgICBXZSBtYXkgd2FudCB0byByZW1v dmUgIm9yIGFjY2VwdC1saXN0ZWQiIGZyb20gdGhlIGFib3ZlIGxpbmUuDQoNCltNZWRdIFRoZSBk b3RzIGNsaWVudCB3aWxsIGtub3cgaWYgaXRzIHJlcXVlc3QgaXMgc3VjY2Vzc2Z1bGx5IGRlbGl2 ZXJlZC4gV2hlbiBhbiBhdHRhY2sgaXMgb25nb2luZywgdGhlIGRvdHMgY2xpZW50IHNob3VsZCBu b3QgdXNlIGl0IGRhdGEgY2hhbm5lbCBiZWNhdXNlIGl0IGlzIGxpa2VseSB0byBiZSBwZXJ0dXJi ZWQuICAgDQoNCkNvbW1lbnQ+IElmIHRoZSBIVFRQIHJlc3BvbnNlIGZyb20gdGhlIHNlcnZlciBk aWQgbm90IHJlYWNoIHRoZSBjbGllbnQgYmVjYXVzZSBvZiBhIHZvbHVtZXRyaWMgYXR0YWNrIHNh dHVyYXRpbmcgdGhlIGluY29taW5nIHRoZSBsaW5rLCB0aGUgRE9UUyBjbGllbnQgd2lsbCBub3Qg a25vdw0Kd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBpcyBzdWNjZXNzZnVsbHkgdXBkYXRlZCBv ciBub3QuIEFmdGVyIHRoZSBhdHRhY2sgaXMgbWl0aWdhdGVkLCB0aGUgY2xpZW50IHdpbGwgaGF2 ZSB0byByZS1lc3RhYmxpc2ggdGhlIFRMUyBzZXNzaW9uIGFuZCByZXRyaWV2ZQ0KdGhlIGNvbmZp Z3VyYXRpb24gdG8gY2hlY2sgaWYgaXRzIGxhc3QgcmVxdWVzdCB3YXMgc3VjY2Vzc2Z1bGx5IGFw cGxpZWQgb3Igbm90IGJlZm9yZSB1cGRhdGluZyB0aGUgY29uZmlndXJhdGlvbi4NCg0KQ2hlZXJz LA0KLVRpcnUgICAgICAgICANCg== From nobody Fri Feb 15 04:22:36 2019 Return-Path: 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 8A856130DC9; Fri, 15 Feb 2019 04:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 K3ZXBRdleoJv; Fri, 15 Feb 2019 04:22:33 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8885F128AFB; Fri, 15 Feb 2019 04:22:32 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 441C7p5dLdz5wZG; Fri, 15 Feb 2019 13:22:30 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 441C7p4d1SzCqkd; Fri, 15 Feb 2019 13:22:30 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0435.000; Fri, 15 Feb 2019 13:22:30 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Benjamin Kaduk" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxRIUxeBzH579tUeqIgtYPD9bE6XgsiOQgAAS3wA= Date: Fri, 15 Feb 2019 12:22:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1FEC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 12:22:35 -0000 SGkgVGlydSwgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHkgW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiBFbnZvecOp wqA6IHZlbmRyZWRpIDE1IGbDqXZyaWVyIDIwMTkgMTI6MDYNCj4gw4DCoDogQk9VQ0FEQUlSIE1v aGFtZWQgVEdJL09MTjsgQmVuamFtaW4gS2FkdWsNCj4gQ2PCoDogZG90c0BpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiBPYmpldMKgOiBSRTogQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4gDQo+IEkgYW0gY2F0Y2hp bmcgdXAgd2l0aCB0aGUgZGlzY3Vzc2lvbiwgY291cGxlIG9mIHBvaW50czoNCj4gDQo+IDEpDQo+ ICAgICAgICogIElmIGEgbmV0d29yayByZXNvdXJjZSAoRE9UUyBjbGllbnQpIGRldGVjdHMgYSBw b3RlbnRpYWwgRERvUw0KPiAgICAgICAgICBhdHRhY2sgZnJvbSBhIHNldCBvZiBJUCBhZGRyZXNz ZXMsIHRoZSBET1RTIGNsaWVudCBpbmZvcm1zIGl0cw0KPiAgICAgICAgICBzZXJ2aWNpbmcgRE9U UyBnYXRld2F5IG9mIGFsbCBzdXNwZWN0IElQIGFkZHJlc3NlcyB0aGF0IG5lZWQgdG8NCj4gICAg ICAgICAgYmUgZHJvcC0gb3IgYWNjZXB0LWxpc3RlZCBmb3IgZnVydGhlciBpbnZlc3RpZ2F0aW9u Lg0KPiANCj4gQ29tbWVudD4gSSBkb24ndCBzZWUgd2h5IHN1c3BlY3QgSVAgYWRkcmVzc2VzIHdp bGwgYmUgYWNjZXB0LWxpc3RlZCA/DQo+ICAgICAgICAgICAgICAgICAgICAgV2UgbWF5IHdhbnQg dG8gcmVtb3ZlICJvciBhY2NlcHQtbGlzdGVkIiBmcm9tIHRoZSBhYm92ZQ0KPiBsaW5lLg0KPiAN Cg0KW01lZF0gQWNrLiAgDQoNCj4gW01lZF0gVGhlIGRvdHMgY2xpZW50IHdpbGwga25vdyBpZiBp dHMgcmVxdWVzdCBpcyBzdWNjZXNzZnVsbHkgZGVsaXZlcmVkLg0KPiBXaGVuIGFuIGF0dGFjayBp cyBvbmdvaW5nLCB0aGUgZG90cyBjbGllbnQgc2hvdWxkIG5vdCB1c2UgaXQgZGF0YSBjaGFubmVs DQo+IGJlY2F1c2UgaXQgaXMgbGlrZWx5IHRvIGJlIHBlcnR1cmJlZC4NCj4gDQo+IENvbW1lbnQ+ IElmIHRoZSBIVFRQIHJlc3BvbnNlIGZyb20gdGhlIHNlcnZlciBkaWQgbm90IHJlYWNoIHRoZSBj bGllbnQNCj4gYmVjYXVzZSBvZiBhIHZvbHVtZXRyaWMgYXR0YWNrIHNhdHVyYXRpbmcgdGhlIGlu Y29taW5nIHRoZSBsaW5rLCB0aGUgRE9UUw0KPiBjbGllbnQgd2lsbCBub3Qga25vdw0KPiB3aGV0 aGVyIHRoZSBjb25maWd1cmF0aW9uIGlzIHN1Y2Nlc3NmdWxseSB1cGRhdGVkIG9yIG5vdC4gQWZ0 ZXIgdGhlIGF0dGFjayBpcw0KPiBtaXRpZ2F0ZWQsIHRoZSBjbGllbnQgd2lsbCBoYXZlIHRvIHJl LWVzdGFibGlzaCB0aGUgVExTIHNlc3Npb24gYW5kIHJldHJpZXZlDQo+IHRoZSBjb25maWd1cmF0 aW9uIHRvIGNoZWNrIGlmIGl0cyBsYXN0IHJlcXVlc3Qgd2FzIHN1Y2Nlc3NmdWxseSBhcHBsaWVk IG9yDQo+IG5vdCBiZWZvcmUgdXBkYXRpbmcgdGhlIGNvbmZpZ3VyYXRpb24uDQo+IA0KDQpbTWVk XSBBZ3JlZS4gU3RpbGwsIGhvdyB0aGUgY2xpZW50IHN5bmNzIGl0cyBjb25maWcgd2l0aCB0aGUg b25lIG1haW50YWluZWQgYnkgdGhlIHNlcnZlciBpcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4g QSBjbGllbnQgY2FuIHNlbmQgYSBHRVQgYmVmb3JlIGFuZC9vciBhZnRlciBhIGNvbmZpZ3VyYXRp b24gY2hhbmdlIHJlcXVlc3QsIGluIHJlZ3VsYXIgaW50ZXJ2YWxzLCBhZnRlciBhdHRhY2sgbWl0 aWdhdGlvbiwgZXRjLiAgDQoNCj4gQ2hlZXJzLA0KPiAtVGlydQ0K From nobody Fri Feb 15 07:01:36 2019 Return-Path: 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 CCBA812D84D; Fri, 15 Feb 2019 07:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 kirE7eq-2Mxh; Fri, 15 Feb 2019 07:01:31 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8607E124D68; Fri, 15 Feb 2019 07:01:31 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 441GgF5S1JzyhY; Fri, 15 Feb 2019 16:01:29 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 441GgF4h1tz8sY1; Fri, 15 Feb 2019 16:01:29 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([fe80::c489:b768:686a:545b%23]) with mapi id 14.03.0435.000; Fri, 15 Feb 2019 16:01:29 +0100 From: To: Benjamin Kaduk CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AdS31vEPJD2qMb3JSyKP8BrrvaReRQNaC3bQ Date: Fri, 15 Feb 2019 15:01:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 15:01:34 -0000 Hi Ben, What is the status for this one? Are we OK to move forward?=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: mardi 29 janvier 2019 14:32 > =C0=A0: Benjamin Kaduk > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org= ; > dots@ietf.org > Objet=A0: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-do= ts- > signal-channel) >=20 > Hi Ben, all, >=20 > We edited a short draft (https://tools.ietf.org/html/draft-boucadair-dots= - > earlydata-00) to motivate the following text included in the signal chann= el > draft: >=20 > Section 8 of [RFC8446] discusses some mechanisms to implement to > limit the impact of replay attacks on 0-RTT data. If the DOTS > server accepts 0-RTT, it MUST implement one of these mechanisms. > A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest. > The DOTS signal channel messages sent as early data by the DOTS > client are idempotent requests. As a reminder, Message ID > (Section 3 of [RFC7252]) is changed each time a new CoAP request > is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized > in each CoAP request. The DOTS server(s) can use Message ID and > Token in the DOTS signal channel message to detect replay of early > data, and accept 0-RTT data at most once. Furthermore, 'mid' > value is monotonically increased by the DOTS client for each > mitigation request, attackers replaying mitigation requests with > lower numeric 'mid' values and overlapping scopes with mitigation > requests having higher numeric 'mid' values will be rejected > systematically by the DOTS server. >=20 > Owing to the aforementioned protections, especially those afforded > by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446 > anti-replay mechanisms, all DOTS signal channel requests are safe > to transmit in TLS 1.3 as early data. Refer to > [I-D.boucadair-dots-earlydata] for more details. >=20 > This text and also the Designated Expert guidelines are implemented in -2= 8. > These are the two pending issues from your AD review. >=20 > Other edits were also made to record what was agreed on the list. >=20 > We hope this version is now ready to move forward. >=20 > Cheers, > Med >=20 > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that > "Application > > > > > > protocols MUST NOT use 0-RTT data without a profile that define= s > its > > > use. > > > > > > That profile needs to identify which messages or interactions a= re > > safe > > > to > > > > > use > > > > > > with 0-RTT and how to handle the situation when the server reje= cts > 0- > > > RTT > > > > > and > > > > > > falls back to 1-RTT." So we either need to say which client > requests > > > are > > > > > 0-RTT > > > > > > safe (and why) or defer that profile to another document. draf= t- > > ietf- > > > > > dnsop- > > > > > > session-signal is perhaps an example of a document that specifi= es > > which > > > > > > messages are/aren't allowed in early data. > > > > > > (draft-ietf-acme-acme is another, but an uninteresting one, sin= ce > > they > > > make > > > > > > every request include a single-use nonce, and all messages are = 0- > RTT > > > safe.) > > > > > > Our use of increasing 'mid' values may help here, in terms of > > allowing > > > > > DELETEs > > > > > > to be safe, but I'd have to think a little more to be sure that > > > requesting > > > > > > mitigation would be safe. (On first glance the session-managem= net > > bits > > > > > would > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and DELETE), an= d > CoAP > > > is > > > > > capable of detecting message duplication (see > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both confirm= able > > and > > > > > non-confirmable messages. > > > > > [1] An attacker replaying DELETE will not have any adverse impac= t, > > 2.02 > > > > > (Deleted) Response Code is returned even if the mitigation reques= t > does > > > not > > > > > exist. > > > > > [2] The techniques discussed in Section 8 of RFC8446 should suffi= ce > to > > > handle > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying an = old > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement= to > > > > limit the impact of replay attacks on 0-RTT data. If the DOT= S > > > > server accepts 0-RTT, it MUST implement one of these mechanis= ms From nobody Fri Feb 15 07:05:10 2019 Return-Path: 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 3469012D84D; Fri, 15 Feb 2019 07:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 b25bBT-IypOg; Fri, 15 Feb 2019 07:05:06 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on072d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A41124D68; Fri, 15 Feb 2019 07:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WWXtzxXewbk8YV6zZEnaQQuNuEX/jV5d9m8Y6AOCBWA=; b=c3Tjeog349fYjpcsddz2xwh4+7cluQ0wTbkBNKB20oNxDkksYVDkD4evgq8howwfGANYbJ44owNg6h9wWNlMNdVP93aqqS1e47otS8yKN6ZlN9SInc2NNY9RATx13a5AipVvMSDug1jebgoW9mu2OsFcCzvT67zvwM6RT82Ars8= Received: from SN2PR01CA0055.prod.exchangelabs.com (2603:10b6:800::23) by DM6PR01MB4860.prod.exchangelabs.com (2603:10b6:5:6d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Fri, 15 Feb 2019 15:05:03 +0000 Received: from BY2NAM03FT062.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::202) by SN2PR01CA0055.outlook.office365.com (2603:10b6:800::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.19 via Frontend Transport; Fri, 15 Feb 2019 15:05:03 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT062.mail.protection.outlook.com (10.152.85.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Fri, 15 Feb 2019 15:05:02 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1FF4wmV000731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Feb 2019 10:05:00 -0500 Date: Fri, 15 Feb 2019 09:04:58 -0600 From: Benjamin Kaduk To: CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190215150458.GV56447@kduck.mit.edu> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(39860400002)(376002)(2980300002)(55784004)(199004)(189003)(229853002)(336012)(26005)(246002)(106002)(75432002)(8676002)(2906002)(186003)(305945005)(6246003)(4326008)(426003)(8936002)(33656002)(316002)(36906005)(1076003)(58126008)(786003)(54906003)(2351001)(476003)(6306002)(126002)(106466001)(14444005)(53416004)(486006)(26826003)(2870700001)(446003)(478600001)(50466002)(356004)(7696005)(47776003)(6916009)(86362001)(76176011)(956004)(88552002)(104016004)(966005)(23756003)(11346002)(55016002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4860; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9d8e38ff-b2aa-4927-764e-08d69356f670 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:DM6PR01MB4860; X-MS-TrafficTypeDiagnostic: DM6PR01MB4860: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4860; 20:vAgVHNme7FiO8A5bQB701Og9oWKPa2ep09HfEttl6Ot5otO1++5N+z2wVbDvIWaUMV+tYAl4Io593QUfHFtHGIQXwV2Bv40JEvh+G7tobb1MAQ5pRi8XE0ZC8ZnA6/1O/qKPqqO9JZBs0ihfXjp4FUUmpoAzOFeBX1mnE350eGFE/l8pY4woOg7SktvvDtbw4aZU68QcXgLle0pfc6yT1+Jk5Stcxmtk55c10X3rZq7KSvb6Z6RCDvb8XqrRqVonrlBE8R0rhKw+7KJsRRrI8J7I/R6WkiOALuuVhhuXUKA2PMpuC+SIGipuH5JMYozflXpCFZMCaCDwIf2LjQ/WrublJoLaZ4dq2NhG5xG3IObZfSun13jVOFQOOb1+E7IbuihtD2I4Czr68dwDd7ObLIkcWJNdcyx2b9ivdEElyVDsmB97H34Kjvcm1iWowc4GNnCvdc9/rlr5voO7Wst9Vud+C9mX/ZBRZ82GpuT8cbqsd1aI5El50Dx7O0bg9wvE6DA85smKg/ikLPT68yT8XH8vMoMhnaErnYsnPs6ytmvsiNWkGX8+JYGUs9ck/97Vy+pK0t7slPBfENgng0x8bzFIDQHDFwK30nbSoL1wjro= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09497C15EB X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM6PR01MB4860; 23:jtYSNXyqefW57/rGNvNNeJa/vRjc8HbLZEPXKxW?= =?iso-8859-1?Q?cDfrykJE6qflRX/uT2MnojG9Lbsagwxj6JWdaWSTmeSMjUQlI6z+9aI/PC?= =?iso-8859-1?Q?N0i2qQ5tcpmbQMgiuWNVVisSCHOw+bpT7xCcwbO3lG6XOhujGIL/xqkmEw?= =?iso-8859-1?Q?qS5wF8NkRdrp+x6QbwDnDTELtACjMQkHEBUNEXKMgorI5qUXGw25w/y7qz?= =?iso-8859-1?Q?qh2utU4IvSYUW5t4L5C9mdcXyg0D/640egSwTKy0KDoOx5E6Mot0jPUy0d?= =?iso-8859-1?Q?bX+pG45AxkvPa0oELyIAEnCkcOqGRv2U0wnUiU5ClCXRPXMOCHiGhLLtwz?= =?iso-8859-1?Q?pL9nik7wYRkCzSU9uFW6hSzWemv3Ev7NI3YDuqbydBP+Er6Pi6fkhf4qch?= =?iso-8859-1?Q?BI9uCJIyeWYLiTPVvat9pbTvtHN0lPeJl1izpJX1bZleTDWI/YUxORd/i7?= =?iso-8859-1?Q?T7kCbO08hsorN/oDY3ILtngJITNSoao+MyMWOZ2wsCBcExSbN/ZODbAqCQ?= =?iso-8859-1?Q?G/Mb0EJJni+Ha3+9FrBUn/QOJaWQmLH7SN+xt77OVJ2PwUsu99Fdk6ec6J?= =?iso-8859-1?Q?bOb+WE55pi+Uwk6Ly5ID9gBIuN5iA53HKbpvIsQDX3TEBCAP4Oli9V0l3V?= =?iso-8859-1?Q?E11Hyipywawob4UI+IuFVhFJxpBkd191i+c9qNDfWfrWc7J5kEhvZqtO1z?= =?iso-8859-1?Q?ajVwKbIZteAASviKv6GPzFGwAEztI4PCjA/jLflAI5NeapsQLoy92zRheh?= =?iso-8859-1?Q?aNAPZr97qMstKQpXqsOB3/L4sAyO2WvLAlgd9Rp74sVD0aRlsf3fzCOhL4?= =?iso-8859-1?Q?Je/foeUFVLO87Fp4A4YpdEEMUTG1ZlUZlGam+TMPo716txRn7oLxs+c9Zy?= =?iso-8859-1?Q?lqXTY/O7aUEqEyWEnPXxhXYud/7W7hqggfDb28z8v/oTGgc7RNt5PzXo4l?= =?iso-8859-1?Q?TAdONvqPxdUDRY1C6zGVWWjbhlh0V10rx60RmlblWHc/nRgwc2b74EdimN?= =?iso-8859-1?Q?e8PfJiwvkhmtxgJjCQ07mEhbgV6TZ8rdjGYTvTr+Fa+Gh7+lQdXGtBGv1W?= =?iso-8859-1?Q?mzMm/MpGMadkL4UqPnx97dpPVquRKd/F5+3+JLrU2rXamlafZMl5ZoGOmW?= =?iso-8859-1?Q?GkROnBDCcX0bl7tH+JlFF0YV/yWBs9+jFZtZPQNMIZKew/dh7LBqAmH7zJ?= =?iso-8859-1?Q?gfewsKY7TnE/ZjOnAATWnnMyR4EEeiseJtK3Hax4z9yT0/JhxV+6/lQsYD?= =?iso-8859-1?Q?RxaxD1u1sW2lz8mXN2SnteHlbfvdmpkgKPYxSAJ/LTTdyTSB0KJInyXrtb?= =?iso-8859-1?Q?pc=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: tvuWNiBz9qQoJXgyNj49/uGLJBAWDSLe/WPJznKiop4BByBJOL//K3cZ/ioSnGfMsw16Otg49+DMP1Qj+ybFNc4NDT9HWS+k3+LMKt/RTQbRVqHpU/U2/byoh6t4foA/RFxTEJ6bnUkpWKd9I/Hlf+sfQMGn56Tvt+GOKGEVP2PeXTZpq/QW8S24tpfAWEaLK6odcFSEb0n+K9oFLi4tyFsyO0iVTkE6u6FedyhNLHStM3njyijHKUPFfBrOeJ490Puu6MKb4Oqa8A8tG2VPAAZaDu8dSrTxvf/TNZGAANGhWwRHtcck3TbrUTVlOp6cOOcvVIChdpe7ztRGmAa4UCzehAd1OCW0NUSBzWTsXPc5H+cIgJmZcPGN6C1sFmseHW6O/qILnAqAacqReQy5KAFjbba/nqD1TV+0Uy31GHc= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2019 15:05:02.7137 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9d8e38ff-b2aa-4927-764e-08d69356f670 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4860 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 15:05:09 -0000 Hi Med, Short form: I need to think about it harder. There's some indication that the CoAp Message ID is at the wrong level to protect the 0-RTT data, but I'm not sure yet. Sorry for the delays; this has been a frenetic couple weeks :( -Ben On Fri, Feb 15, 2019 at 03:01:29PM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > What is the status for this one? Are we OK to move forward? > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > > Envoyé : mardi 29 janvier 2019 14:32 > > À : Benjamin Kaduk > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > dots@ietf.org > > Objet : Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots- > > signal-channel) > > > > Hi Ben, all, > > > > We edited a short draft (https://tools.ietf.org/html/draft-boucadair-dots- > > earlydata-00) to motivate the following text included in the signal channel > > draft: > > > > Section 8 of [RFC8446] discusses some mechanisms to implement to > > limit the impact of replay attacks on 0-RTT data. If the DOTS > > server accepts 0-RTT, it MUST implement one of these mechanisms. > > A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest. > > The DOTS signal channel messages sent as early data by the DOTS > > client are idempotent requests. As a reminder, Message ID > > (Section 3 of [RFC7252]) is changed each time a new CoAP request > > is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized > > in each CoAP request. The DOTS server(s) can use Message ID and > > Token in the DOTS signal channel message to detect replay of early > > data, and accept 0-RTT data at most once. Furthermore, 'mid' > > value is monotonically increased by the DOTS client for each > > mitigation request, attackers replaying mitigation requests with > > lower numeric 'mid' values and overlapping scopes with mitigation > > requests having higher numeric 'mid' values will be rejected > > systematically by the DOTS server. > > > > Owing to the aforementioned protections, especially those afforded > > by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446 > > anti-replay mechanisms, all DOTS signal channel requests are safe > > to transmit in TLS 1.3 as early data. Refer to > > [I-D.boucadair-dots-earlydata] for more details. > > > > This text and also the Designated Expert guidelines are implemented in -28. > > These are the two pending issues from your AD review. > > > > Other edits were also made to record what was agreed on the list. > > > > We hope this version is now ready to move forward. > > > > Cheers, > > Med > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that > > "Application > > > > > > > protocols MUST NOT use 0-RTT data without a profile that defines > > its > > > > use. > > > > > > > That profile needs to identify which messages or interactions are > > > safe > > > > to > > > > > > use > > > > > > > with 0-RTT and how to handle the situation when the server rejects > > 0- > > > > RTT > > > > > > and > > > > > > > falls back to 1-RTT." So we either need to say which client > > requests > > > > are > > > > > > 0-RTT > > > > > > > safe (and why) or defer that profile to another document. draft- > > > ietf- > > > > > > dnsop- > > > > > > > session-signal is perhaps an example of a document that specifies > > > which > > > > > > > messages are/aren't allowed in early data. > > > > > > > (draft-ietf-acme-acme is another, but an uninteresting one, since > > > they > > > > make > > > > > > > every request include a single-use nonce, and all messages are 0- > > RTT > > > > safe.) > > > > > > > Our use of increasing 'mid' values may help here, in terms of > > > allowing > > > > > > DELETEs > > > > > > > to be safe, but I'd have to think a little more to be sure that > > > > requesting > > > > > > > mitigation would be safe. (On first glance the session-managemnet > > > bits > > > > > > would > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and DELETE), and > > CoAP > > > > is > > > > > > capable of detecting message duplication (see > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both confirmable > > > and > > > > > > non-confirmable messages. > > > > > > [1] An attacker replaying DELETE will not have any adverse impact, > > > 2.02 > > > > > > (Deleted) Response Code is returned even if the mitigation request > > does > > > > not > > > > > > exist. > > > > > > [2] The techniques discussed in Section 8 of RFC8446 should suffice > > to > > > > handle > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying an old > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement to > > > > > limit the impact of replay attacks on 0-RTT data. If the DOTS > > > > > server accepts 0-RTT, it MUST implement one of these mechanisms From nobody Fri Feb 15 07:36:10 2019 Return-Path: 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 6F328124D68; Fri, 15 Feb 2019 07:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 g4VHy9FZIaEL; Fri, 15 Feb 2019 07:36:07 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D61D12008F; Fri, 15 Feb 2019 07:36:07 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 441HR93bNyz5wGs; Fri, 15 Feb 2019 16:36:05 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 441HR92bgdz1xp9; Fri, 15 Feb 2019 16:36:05 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0435.000; Fri, 15 Feb 2019 16:36:05 +0100 From: To: Benjamin Kaduk CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUxT/XkMbs4nOP80KV8KXTaawAqqXg/D4w Date: Fri, 15 Feb 2019 15:36:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> In-Reply-To: <20190215150458.GV56447@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 15:36:10 -0000 Re-, Looking forward to discuss this further.=20 I wonder whether you can consider putting the document in the IETF LC for n= ow. If it happen that we need to modify the 0-RTT text, we will handle it a= s other IETF LC comments. Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: vendredi 15 f=E9vrier 2019 16:05 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org= ; > dots@ietf.org > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-iet= f- > dots-signal-channel) >=20 > Hi Med, >=20 > Short form: I need to think about it harder. There's some indication tha= t > the CoAp Message ID is at the wrong level to protect the 0-RTT data, but > I'm not sure yet. >=20 > Sorry for the delays; this has been a frenetic couple weeks :( >=20 > -Ben >=20 > On Fri, Feb 15, 2019 at 03:01:29PM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Ben, > > > > What is the status for this one? Are we OK to move forward? > > > > Thank you. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.= com] > > > Envoy=E9=A0: mardi 29 janvier 2019 14:32 > > > =C0=A0: Benjamin Kaduk > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf= .org; > > > dots@ietf.org > > > Objet=A0: Using Early Data in DOTS (RE: [Dots] AD review of draft-iet= f- > dots- > > > signal-channel) > > > > > > Hi Ben, all, > > > > > > We edited a short draft (https://tools.ietf.org/html/draft-boucadair- > dots- > > > earlydata-00) to motivate the following text included in the signal > channel > > > draft: > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement t= o > > > limit the impact of replay attacks on 0-RTT data. If the DOTS > > > server accepts 0-RTT, it MUST implement one of these mechanisms= . > > > A DOTS server can reject 0-RTT by sending a TLS HelloRetryReque= st. > > > The DOTS signal channel messages sent as early data by the DOTS > > > client are idempotent requests. As a reminder, Message ID > > > (Section 3 of [RFC7252]) is changed each time a new CoAP reques= t > > > is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomiz= ed > > > in each CoAP request. The DOTS server(s) can use Message ID an= d > > > Token in the DOTS signal channel message to detect replay of ea= rly > > > data, and accept 0-RTT data at most once. Furthermore, 'mid' > > > value is monotonically increased by the DOTS client for each > > > mitigation request, attackers replaying mitigation requests wit= h > > > lower numeric 'mid' values and overlapping scopes with mitigati= on > > > requests having higher numeric 'mid' values will be rejected > > > systematically by the DOTS server. > > > > > > Owing to the aforementioned protections, especially those affor= ded > > > by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446 > > > anti-replay mechanisms, all DOTS signal channel requests are sa= fe > > > to transmit in TLS 1.3 as early data. Refer to > > > [I-D.boucadair-dots-earlydata] for more details. > > > > > > This text and also the Designated Expert guidelines are implemented i= n - > 28. > > > These are the two pending issues from your AD review. > > > > > > Other edits were also made to record what was agreed on the list. > > > > > > We hope this version is now ready to move forward. > > > > > > Cheers, > > > Med > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that > > > "Application > > > > > > > > protocols MUST NOT use 0-RTT data without a profile that > defines > > > its > > > > > use. > > > > > > > > That profile needs to identify which messages or interactio= ns > are > > > > safe > > > > > to > > > > > > > use > > > > > > > > with 0-RTT and how to handle the situation when the server > rejects > > > 0- > > > > > RTT > > > > > > > and > > > > > > > > falls back to 1-RTT." So we either need to say which clien= t > > > requests > > > > > are > > > > > > > 0-RTT > > > > > > > > safe (and why) or defer that profile to another document. > draft- > > > > ietf- > > > > > > > dnsop- > > > > > > > > session-signal is perhaps an example of a document that > specifies > > > > which > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > (draft-ietf-acme-acme is another, but an uninteresting one, > since > > > > they > > > > > make > > > > > > > > every request include a single-use nonce, and all messages = are > 0- > > > RTT > > > > > safe.) > > > > > > > > Our use of increasing 'mid' values may help here, in terms = of > > > > allowing > > > > > > > DELETEs > > > > > > > > to be safe, but I'd have to think a little more to be sure = that > > > > > requesting > > > > > > > > mitigation would be safe. (On first glance the session- > managemnet > > > > bits > > > > > > > would > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and DELETE)= , > and > > > CoAP > > > > > is > > > > > > > capable of detecting message duplication (see > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both > confirmable > > > > and > > > > > > > non-confirmable messages. > > > > > > > [1] An attacker replaying DELETE will not have any adverse > impact, > > > > 2.02 > > > > > > > (Deleted) Response Code is returned even if the mitigation > request > > > does > > > > > not > > > > > > > exist. > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 should > suffice > > > to > > > > > handle > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying= an > old > > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to imple= ment > to > > > > > > limit the impact of replay attacks on 0-RTT data. If the > DOTS > > > > > > server accepts 0-RTT, it MUST implement one of these > mechanisms From nobody Sat Feb 16 00:11:25 2019 Return-Path: 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 80B8B129C6A; Sat, 16 Feb 2019 00:11:23 -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 DaMkRxxtvMnC; Sat, 16 Feb 2019 00:11:20 -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 E6EF0128766; Sat, 16 Feb 2019 00:11:19 -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=1550304562; 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-ms-exchange-purlcount: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=/hvyIIutT9H2xkHM87p32pr9fBAQ7YdAn/3v/F eYDBU=; b=Rfk0VEyqzccp5aJu2qWOSJxK/2T8Z7M4Rj95WEHt UBQ67pqwRUHYtcB78aJltXXl1ckXD5UD7CnczYBXatTZvWEfQB 5sQ0GAkERAbKcDIUv7LbSYkbLgb9yFDJPCT5c2VqyJSXfHk0sM CmRnj3VcTXFH24lrPEhUAcLRb1XlFlo= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1096_142e_376f9ef5_625b_4f7d_a526_b0a68cc303b0; Sat, 16 Feb 2019 01:09:22 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 16 Feb 2019 01:11:06 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 16 Feb 2019 01:11:06 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 16 Feb 2019 01:11:05 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB3015.namprd16.prod.outlook.com (20.178.236.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Sat, 16 Feb 2019 08:11:02 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::a92f:410f:4068:d183%5]) with mapi id 15.20.1622.018; Sat, 16 Feb 2019 08:11:02 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , "mohamed.boucadair@orange.com" CC: "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AdS31vEPJD2qMb3JSyKP8BrrvaReRQNaC3bQAAAsgwAAI1p60A== Date: Sat, 16 Feb 2019 08:11:02 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> In-Reply-To: <20190215150458.GV56447@kduck.mit.edu> 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: [122.171.104.55] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f62e952b-0d9c-41ce-0480-08d693e64ae8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB3015; x-ms-traffictypediagnostic: BYAPR16MB3015: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIzMDE1OzIzOkNkeCtsWE5jdjZ6MVcwdjE4SkROTXp1SHFG?= =?utf-8?B?OGpWSmw3OEhJNW1ueGI5UzZpWDJzZkdIMkZES2s2c3lrS0ZnTjBlMkZIRVYv?= =?utf-8?B?QThMd3lMUU8wUmdka0lpRWJwMHcvL2duRXZpYjk0TTNKNzFycEswMlVwN1Zm?= =?utf-8?B?NnhPOHp6NVJlR05QZk50RTJTQitIQlo2S01sR3VYUFluVU94OURIZVg5emsw?= =?utf-8?B?bHUxUkZKMW8rWUVwVEJtMXdnMExCK1E0aFFWL2d6ZUFLRm5LeGY2UUVxbmZv?= =?utf-8?B?WEZNak5oWnM3QlRmcDk0U1M1SDRUdC8rU3FGYjZPM2tNMjZnWkRxeVlUN2JR?= =?utf-8?B?bXA5ZVUwOEpCVGJKblQ1OTlDRks0S1d3RjZvQ2c4cTNRb0NicU1oWHJGNW40?= =?utf-8?B?MXorTXlRNEltTFRMZjVYOVhNSGQrcHlXVmNFUG9EUVZFUjhCZDlVVE4zQUxq?= =?utf-8?B?dTUzMWMrbUZNV1NXcFUySTNuV1Z1cG1MWnl1QkdVdVMvVm45NmhSclMvT2Zj?= =?utf-8?B?a0FRZmk3YkNvVHBERXgwZjFyK1lpbnVpTkxtWW9LK0FVeW5tVUU4OXVPT2d0?= =?utf-8?B?elRDTGVZV3JsenpaRGJBNDh3b25XMzFaTk9YazBXa3J4cnRHY1FkWVJOaDFk?= =?utf-8?B?K256WE5ZL0dTVlJpakVoRC8xNmw3cVB2bEswOHRrWmU5bnN1QUJKbjNJdGhp?= =?utf-8?B?alVFKzZTeEpjb2NxVTN4U3FTZVE0V0ZoemRZczZUempjS3NGRmI2MDhuTXBY?= =?utf-8?B?RUU4ZHBrMitwNk1OckxmZ2c2M3JKWDJ1aTljTnZNL09QRVhmb3FJcFZ1Mmhj?= =?utf-8?B?YnUyYitQdzE4NHlURDJYQktKcE5BbGlvSDVwMXlLU0RTQ2Q5VWxzOUpTREpD?= =?utf-8?B?akpjbDN6SW5lTEFBeXBaVVpSWjBNdmJablExa3ZKc0tnK2wxVW1KNXBlbEU1?= =?utf-8?B?UWp0Y1Z6QTFOQnllZUJsblg4NEtFb0FZNVpKMTJPWkprcjZZeUJNODJRc0di?= =?utf-8?B?RlhaWEpjeXViUFp2M3I4SlE1WDhRNVBJeDE0dnYxcTluaVRsbk1lZWl2QmtP?= =?utf-8?B?TzRXblQxRlRWcmNhUS9ubWxnb3V4VExRaWUzMU00L2swM0p2Ull4R1ZEZ2wr?= =?utf-8?B?NytXY1pZQjFyQkgvK21RZis1MzMwWXZNZm94aW1sRUJ0MWJncVZVbEtlTTlm?= =?utf-8?B?b3Q1UDh3U1drT2IwRDh1SjhOMTFNVG1WNDV4WjFYR2FNVVl0cG4zaTZPeWE5?= =?utf-8?B?WUtHYkhERzVXVE1qcWl4MmNXY2p5MlRYZXVTL3EvVHpQNHIxZmZsbE1wSzZZ?= =?utf-8?B?aTJhZ1VJRFZQek9leHFub3MraVA1Wkc0KzIyYlJqOHhGMkNzM1A5RVJ6bEpS?= =?utf-8?B?clFEWnprd0dtbjdiZ2VrbTlsZnVNWmpRalA4aE40UVVqcExmbzVCWUZlVzFp?= =?utf-8?B?UXFQL1hjQlVzbkNFbk9wMldrcFEraG5KYkdrYkQ4UFg1cGlUQjVSU3hlVGVZ?= =?utf-8?B?SCsxeWRnL0h1VjQ3MHRpZ3Fvbks5eUxwQ0hyTkt4cTgzdnVnT3YwNDM1Zndr?= =?utf-8?B?elExSWREcGVaMHdONFBpWUc4bEMyRG5EQ3k0OHRWelBDUVJXZEoyb0l0aEFL?= =?utf-8?B?VExCdWczU2RiUEtWYjZONnVwNnUxTUE5RERBT0NiNkRXZHcrekcxVzB2K2gr?= =?utf-8?B?M2hVQlNqd1BCWG5SRjh3OHY1VGxwZ2RCa0lWRU14VWVhZ0s4ZkV2NXJVN3Rp?= =?utf-8?B?Q21Qa3VTY0tGd0RybDNJZUdBUUovQXB1NnBUTzZoZG9IKzdacVZ2VmJDUUIz?= =?utf-8?B?dktmWGNIRWl3U2ROYmNVQlk0VW5WTHZMSG5iR1EvMTBwRmp3Q1UrVEV2cTZX?= =?utf-8?B?cDVzNHZHSDlxVVZ5K2JIS25TbnBJZWdZblpySnErSk5aY3JSZ1VBSUpCSE55?= =?utf-8?B?WkxJejNjTWxRVkFjeE0zTFB1aWVDOWV6RFY3M3N3OVhlQmJhOUhmK1dOR1ZC?= =?utf-8?B?dStTNk9senpBZHBIS1EyN0o2ZGRmbWdHRnVXQT09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0950706AC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(376002)(346002)(39860400002)(32952001)(55784004)(13464003)(189003)(199004)(26005)(86362001)(102836004)(446003)(11346002)(105586002)(486006)(476003)(106356001)(478600001)(186003)(14454004)(72206003)(966005)(6436002)(305945005)(256004)(53936002)(80792005)(5024004)(14444005)(97736004)(2501003)(55016002)(9686003)(6306002)(6246003)(7736002)(8936002)(2171002)(66066001)(74316002)(25786009)(81166006)(8676002)(81156014)(4326008)(229853002)(2906002)(99286004)(3846002)(6116002)(7696005)(53546011)(6506007)(76176011)(33656002)(54906003)(110136005)(71200400001)(68736007)(78486014)(71190400001)(316002)(5660300002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB3015; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 5OT7QmOyMu0bep9VwEXV45vbap49E/vc470cd8/1U8fVAX0yD3vikkZnHH+z5K+Vq+9LxjvJ897QAqQYkDqqBLD35MkAfIrNAz/xTtQFkXMorkeJgbfzZt5hl62SVf4IA3EGKw9gz6nchn2UnC/ycO7qRbuBTurjvBatFbIhY8+UY9PaSR4NzgNOjbQ05WhUf3KAQvqLXb5sdEGap+IdA89+708uhO4AlZwmVlG6hVCxJJAmXP84S7fDSXXBGFoFruHUkhROXZoAhHu/0tZjLSHjQvdiZ4/+QwFiNTZej9PFt2Y6TCS6YWJXbYIkv8xlD4KPYFoXzIvL2CvxGtYMNExA/iZxMVB4oO/rwhJTaFnKTN+tUS8ykmdIyPdvIeHmIGbrhR1mXf4/APs1SU0LI+yz0CheM9l7K6p3pxAnids= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f62e952b-0d9c-41ce-0480-08d693e64ae8 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2019 08:11:02.5842 (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: BYAPR16MB3015 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6484> : inlines <7018> : streams <1813184> : uri <2797121> Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 08:11:24 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1ayA8a2Fk dWtAbWl0LmVkdT4NCj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNSwgMjAxOSA4OjM1IFBNDQo+ IFRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IENjOiBLb25kYSwgVGlydW1hbGVz d2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsNCj4gZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBVc2luZyBFYXJseSBEYXRhIGluIERPVFMgKFJFOiBbRG90c10gQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtZG90cy0NCj4gc2lnbmFsLWNoYW5uZWwpDQo+IA0KPiBUaGlzIGVtYWlsIG9y aWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBs aW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5k ZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEhpIE1lZCwNCj4gDQo+IFNo b3J0IGZvcm06IEkgbmVlZCB0byB0aGluayBhYm91dCBpdCBoYXJkZXIuICBUaGVyZSdzIHNvbWUg aW5kaWNhdGlvbiB0aGF0IHRoZQ0KPiBDb0FwIE1lc3NhZ2UgSUQgaXMgYXQgdGhlIHdyb25nIGxl dmVsIHRvIHByb3RlY3QgdGhlIDAtUlRUIGRhdGEsIGJ1dCBJJ20gbm90DQo+IHN1cmUgeWV0Lg0K DQpJIGRvbid0IHRoaW5rIE1lc3NhZ2UgSUQgYW5kIFRva2VuIGFyZSBhdCBhIHdyb25nIGxldmVs IHRvIHByb3RlY3QgMC1SVFQgZGF0YSwgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRzY2hvZmVuaWctdXRhLXRsczEzLXByb2ZpbGUtMDEgZGlzY3Vzc2VzIGludHJvZHVjaW5nIGEg bmV3IENvQVAgb3B0aW9uICJ0aW1lc3RhbXAiLCB3aGljaCBhbGxvd3MgdGhlIGNsaWVudCB0byBh dHRhY2ggYSB0aW1lc3RhbXAgdG8gZWFjaCBDb0FQIG1lc3NhZ2UgZm9yIHRoZSBwdXJwb3NlIA0K b2YgcmVwbGF5IGRldGVjdGlvbi4gDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IFNvcnJ5IGZv ciB0aGUgZGVsYXlzOyB0aGlzIGhhcyBiZWVuIGEgZnJlbmV0aWMgY291cGxlIHdlZWtzIDooDQo+ IA0KPiAtQmVuDQo+IA0KPiBPbiBGcmksIEZlYiAxNSwgMjAxOSBhdCAwMzowMToyOVBNICswMDAw LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IHdyb3RlOg0KPiA+IEhpIEJlbiwNCj4g Pg0KPiA+IFdoYXQgaXMgdGhlIHN0YXR1cyBmb3IgdGhpcyBvbmU/IEFyZSB3ZSBPSyB0byBtb3Zl IGZvcndhcmQ/DQo+ID4NCj4gPiBUaGFuayB5b3UuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVk DQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gRGXCoDogbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tXQ0KPiA+ID4gRW52b3nDqcKgOiBtYXJkaSAyOSBqYW52aWVyIDIwMTkgMTQ6 MzIgw4DCoDogQmVuamFtaW4gS2FkdWsgQ2PCoDogS29uZGEsDQo+ID4gPiBUaXJ1bWFsZXN3YXIg UmVkZHk7IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbEBpZXRmLm9yZzsNCj4gPiA+IGRv dHNAaWV0Zi5vcmcNCj4gPiA+IE9iamV0wqA6IFVzaW5nIEVhcmx5IERhdGEgaW4gRE9UUyAoUkU6 IFtEb3RzXSBBRCByZXZpZXcgb2YNCj4gPiA+IGRyYWZ0LWlldGYtZG90cy0NCj4gPiA+IHNpZ25h bC1jaGFubmVsKQ0KPiA+ID4NCj4gPiA+IEhpIEJlbiwgYWxsLA0KPiA+ID4NCj4gPiA+IFdlIGVk aXRlZCBhIHNob3J0IGRyYWZ0DQo+ID4gPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJvdWNhZGFpci1kb3RzLQ0KPiA+ID4gZWFybHlkYXRhLTAwKSB0byBtb3RpdmF0ZSB0aGUg Zm9sbG93aW5nIHRleHQgaW5jbHVkZWQgaW4gdGhlIHNpZ25hbA0KPiA+ID4gY2hhbm5lbA0KPiA+ ID4gZHJhZnQ6DQo+ID4gPg0KPiA+ID4gICAgICAgU2VjdGlvbiA4IG9mIFtSRkM4NDQ2XSBkaXNj dXNzZXMgc29tZSBtZWNoYW5pc21zIHRvIGltcGxlbWVudCB0bw0KPiA+ID4gICAgICAgbGltaXQg dGhlIGltcGFjdCBvZiByZXBsYXkgYXR0YWNrcyBvbiAwLVJUVCBkYXRhLiAgSWYgdGhlIERPVFMN Cj4gPiA+ICAgICAgIHNlcnZlciBhY2NlcHRzIDAtUlRULCBpdCBNVVNUIGltcGxlbWVudCBvbmUg b2YgdGhlc2UgbWVjaGFuaXNtcy4NCj4gPiA+ICAgICAgIEEgRE9UUyBzZXJ2ZXIgY2FuIHJlamVj dCAwLVJUVCBieSBzZW5kaW5nIGEgVExTIEhlbGxvUmV0cnlSZXF1ZXN0Lg0KPiA+ID4gICAgICAg VGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgbWVzc2FnZXMgc2VudCBhcyBlYXJseSBkYXRhIGJ5IHRo ZSBET1RTDQo+ID4gPiAgICAgICBjbGllbnQgYXJlIGlkZW1wb3RlbnQgcmVxdWVzdHMuICBBcyBh IHJlbWluZGVyLCBNZXNzYWdlIElEDQo+ID4gPiAgICAgICAoU2VjdGlvbiAzIG9mIFtSRkM3MjUy XSkgaXMgY2hhbmdlZCBlYWNoIHRpbWUgYSBuZXcgQ29BUCByZXF1ZXN0DQo+ID4gPiAgICAgICBp cyBzZW50LCBhbmQgdGhlIFRva2VuIChTZWN0aW9uIDUuMy4xIG9mIFtSRkM3MjUyXSkgaXMgcmFu ZG9taXplZA0KPiA+ID4gICAgICAgaW4gZWFjaCBDb0FQIHJlcXVlc3QuICBUaGUgRE9UUyBzZXJ2 ZXIocykgY2FuIHVzZSBNZXNzYWdlIElEIGFuZA0KPiA+ID4gICAgICAgVG9rZW4gaW4gdGhlIERP VFMgc2lnbmFsIGNoYW5uZWwgbWVzc2FnZSB0byBkZXRlY3QgcmVwbGF5IG9mIGVhcmx5DQo+ID4g PiAgICAgICBkYXRhLCBhbmQgYWNjZXB0IDAtUlRUIGRhdGEgYXQgbW9zdCBvbmNlLiAgRnVydGhl cm1vcmUsICdtaWQnDQo+ID4gPiAgICAgICB2YWx1ZSBpcyBtb25vdG9uaWNhbGx5IGluY3JlYXNl ZCBieSB0aGUgRE9UUyBjbGllbnQgZm9yIGVhY2gNCj4gPiA+ICAgICAgIG1pdGlnYXRpb24gcmVx dWVzdCwgYXR0YWNrZXJzIHJlcGxheWluZyBtaXRpZ2F0aW9uIHJlcXVlc3RzIHdpdGgNCj4gPiA+ ICAgICAgIGxvd2VyIG51bWVyaWMgJ21pZCcgdmFsdWVzIGFuZCBvdmVybGFwcGluZyBzY29wZXMg d2l0aCBtaXRpZ2F0aW9uDQo+ID4gPiAgICAgICByZXF1ZXN0cyBoYXZpbmcgaGlnaGVyIG51bWVy aWMgJ21pZCcgdmFsdWVzIHdpbGwgYmUgcmVqZWN0ZWQNCj4gPiA+ICAgICAgIHN5c3RlbWF0aWNh bGx5IGJ5IHRoZSBET1RTIHNlcnZlci4NCj4gPiA+DQo+ID4gPiAgICAgICBPd2luZyB0byB0aGUg YWZvcmVtZW50aW9uZWQgcHJvdGVjdGlvbnMsIGVzcGVjaWFsbHkgdGhvc2UgYWZmb3JkZWQNCj4g PiA+ICAgICAgIGJ5IENvQVAgZGVkdXBsaWNhdGlvbiAoU2VjdGlvbiA0LjUgb2YgW1JGQzcyNTJd KSBhbmQgUkZDIDg0NDYNCj4gPiA+ICAgICAgIGFudGktcmVwbGF5IG1lY2hhbmlzbXMsIGFsbCBE T1RTIHNpZ25hbCBjaGFubmVsIHJlcXVlc3RzIGFyZSBzYWZlDQo+ID4gPiAgICAgICB0byB0cmFu c21pdCBpbiBUTFMgMS4zIGFzIGVhcmx5IGRhdGEuICBSZWZlciB0bw0KPiA+ID4gICAgICAgW0kt RC5ib3VjYWRhaXItZG90cy1lYXJseWRhdGFdIGZvciBtb3JlIGRldGFpbHMuDQo+ID4gPg0KPiA+ ID4gVGhpcyB0ZXh0IGFuZCBhbHNvIHRoZSBEZXNpZ25hdGVkIEV4cGVydCBndWlkZWxpbmVzIGFy ZSBpbXBsZW1lbnRlZCBpbiAtMjguDQo+ID4gPiBUaGVzZSBhcmUgdGhlIHR3byBwZW5kaW5nIGlz c3VlcyBmcm9tIHlvdXIgQUQgcmV2aWV3Lg0KPiA+ID4NCj4gPiA+IE90aGVyIGVkaXRzIHdlcmUg YWxzbyBtYWRlIHRvIHJlY29yZCB3aGF0IHdhcyBhZ3JlZWQgb24gdGhlIGxpc3QuDQo+ID4gPg0K PiA+ID4gV2UgaG9wZSB0aGlzIHZlcnNpb24gaXMgbm93IHJlYWR5IHRvIG1vdmUgZm9yd2FyZC4N Cj4gPiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiBNZWQNCj4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g UmVnYXJkaW5nIHRoZSAoRClUTFMgMS4zIDAtUlRUIGRhdGEsIFJGQyA4NDQ2IG5vdGVzIHRoYXQN Cj4gPiA+ICJBcHBsaWNhdGlvbg0KPiA+ID4gPiA+ID4gPiA+IHByb3RvY29scyBNVVNUIE5PVCB1 c2UgMC1SVFQgZGF0YSB3aXRob3V0IGEgcHJvZmlsZSB0aGF0DQo+ID4gPiA+ID4gPiA+ID4gZGVm aW5lcw0KPiA+ID4gaXRzDQo+ID4gPiA+ID4gdXNlLg0KPiA+ID4gPiA+ID4gPiA+IFRoYXQgcHJv ZmlsZSBuZWVkcyB0byBpZGVudGlmeSB3aGljaCBtZXNzYWdlcyBvcg0KPiA+ID4gPiA+ID4gPiA+ IGludGVyYWN0aW9ucyBhcmUNCj4gPiA+ID4gc2FmZQ0KPiA+ID4gPiA+IHRvDQo+ID4gPiA+ID4g PiA+IHVzZQ0KPiA+ID4gPiA+ID4gPiA+IHdpdGggMC1SVFQgYW5kIGhvdyB0byBoYW5kbGUgdGhl IHNpdHVhdGlvbiB3aGVuIHRoZSBzZXJ2ZXINCj4gPiA+ID4gPiA+ID4gPiByZWplY3RzDQo+ID4g PiAwLQ0KPiA+ID4gPiA+IFJUVA0KPiA+ID4gPiA+ID4gPiBhbmQNCj4gPiA+ID4gPiA+ID4gPiBm YWxscyBiYWNrIHRvIDEtUlRULiIgIFNvIHdlIGVpdGhlciBuZWVkIHRvIHNheSB3aGljaA0KPiA+ ID4gPiA+ID4gPiA+IGNsaWVudA0KPiA+ID4gcmVxdWVzdHMNCj4gPiA+ID4gPiBhcmUNCj4gPiA+ ID4gPiA+ID4gMC1SVFQNCj4gPiA+ID4gPiA+ID4gPiBzYWZlIChhbmQgd2h5KSBvciBkZWZlciB0 aGF0IHByb2ZpbGUgdG8gYW5vdGhlciBkb2N1bWVudC4NCj4gPiA+ID4gPiA+ID4gPiBkcmFmdC0N Cj4gPiA+ID4gaWV0Zi0NCj4gPiA+ID4gPiA+ID4gZG5zb3AtDQo+ID4gPiA+ID4gPiA+ID4gc2Vz c2lvbi1zaWduYWwgaXMgcGVyaGFwcyBhbiBleGFtcGxlIG9mIGEgZG9jdW1lbnQgdGhhdA0KPiA+ ID4gPiA+ID4gPiA+IHNwZWNpZmllcw0KPiA+ID4gPiB3aGljaA0KPiA+ID4gPiA+ID4gPiA+IG1l c3NhZ2VzIGFyZS9hcmVuJ3QgYWxsb3dlZCBpbiBlYXJseSBkYXRhLg0KPiA+ID4gPiA+ID4gPiA+ IChkcmFmdC1pZXRmLWFjbWUtYWNtZSBpcyBhbm90aGVyLCBidXQgYW4gdW5pbnRlcmVzdGluZw0K PiA+ID4gPiA+ID4gPiA+IG9uZSwgc2luY2UNCj4gPiA+ID4gdGhleQ0KPiA+ID4gPiA+IG1ha2UN Cj4gPiA+ID4gPiA+ID4gPiBldmVyeSByZXF1ZXN0IGluY2x1ZGUgYSBzaW5nbGUtdXNlIG5vbmNl LCBhbmQgYWxsIG1lc3NhZ2VzDQo+ID4gPiA+ID4gPiA+ID4gYXJlIDAtDQo+ID4gPiBSVFQNCj4g PiA+ID4gPiBzYWZlLikNCj4gPiA+ID4gPiA+ID4gPiBPdXIgdXNlIG9mIGluY3JlYXNpbmcgJ21p ZCcgdmFsdWVzIG1heSBoZWxwIGhlcmUsIGluIHRlcm1zDQo+ID4gPiA+ID4gPiA+ID4gb2YNCj4g PiA+ID4gYWxsb3dpbmcNCj4gPiA+ID4gPiA+ID4gREVMRVRFcw0KPiA+ID4gPiA+ID4gPiA+IHRv IGJlIHNhZmUsIGJ1dCBJJ2QgaGF2ZSB0byB0aGluayBhIGxpdHRsZSBtb3JlIHRvIGJlIHN1cmUN Cj4gPiA+ID4gPiA+ID4gPiB0aGF0DQo+ID4gPiA+ID4gcmVxdWVzdGluZw0KPiA+ID4gPiA+ID4g PiA+IG1pdGlnYXRpb24gd291bGQgYmUgc2FmZS4gIChPbiBmaXJzdCBnbGFuY2UgdGhlDQo+ID4g PiA+ID4gPiA+ID4gc2Vzc2lvbi1tYW5hZ2VtbmV0DQo+ID4gPiA+IGJpdHMNCj4gPiA+ID4gPiA+ ID4gd291bGQNCj4gPiA+ID4gPiA+ID4gPiBub3QgYmUgc2FmZSwgYnV0IEkgbWF5IGJlIG1pc3Np bmcgc29tZXRoaW5nLikNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gVGhlIGRyYWZ0IG9u bHkgdXNlcyBpZGVtcG90ZW50IHJlcXVlc3RzIChHRVQsIFBVVCBhbmQNCj4gPiA+ID4gPiA+ID4g REVMRVRFKSwgYW5kDQo+ID4gPiBDb0FQDQo+ID4gPiA+ID4gaXMNCj4gPiA+ID4gPiA+ID4gY2Fw YWJsZSBvZiBkZXRlY3RpbmcgbWVzc2FnZSBkdXBsaWNhdGlvbiAoc2VlDQo+ID4gPiA+ID4gPiA+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tNC41KSBmb3IgYm90 aA0KPiA+ID4gPiA+ID4gPiBjb25maXJtYWJsZQ0KPiA+ID4gPiBhbmQNCj4gPiA+ID4gPiA+ID4g bm9uLWNvbmZpcm1hYmxlIG1lc3NhZ2VzLg0KPiA+ID4gPiA+ID4gPiAgWzFdIEFuIGF0dGFja2Vy IHJlcGxheWluZyBERUxFVEUgd2lsbCBub3QgaGF2ZSBhbnkgYWR2ZXJzZQ0KPiA+ID4gPiA+ID4g PiBpbXBhY3QsDQo+ID4gPiA+IDIuMDINCj4gPiA+ID4gPiA+ID4gKERlbGV0ZWQpIFJlc3BvbnNl IENvZGUgaXMgcmV0dXJuZWQgZXZlbiBpZiB0aGUgbWl0aWdhdGlvbg0KPiA+ID4gPiA+ID4gPiBy ZXF1ZXN0DQo+ID4gPiBkb2VzDQo+ID4gPiA+ID4gbm90DQo+ID4gPiA+ID4gPiA+IGV4aXN0Lg0K PiA+ID4gPiA+ID4gPiBbMl0gVGhlIHRlY2huaXF1ZXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gOCBv ZiBSRkM4NDQ2IHNob3VsZA0KPiA+ID4gPiA+ID4gPiBzdWZmaWNlDQo+ID4gPiB0bw0KPiA+ID4g PiA+IGhhbmRsZQ0KPiA+ID4gPiA+ID4gPiBhbnRpLXJlcGxheSAoZS5nLiBhbiBhdHRhY2tlciBy ZXBsYXlpbmcgYSAwLVJUVCBkYXRhDQo+ID4gPiA+ID4gPiA+IGNhcnJ5aW5nIGFuIG9sZCBtaXRp Z2F0aW9uIHJlcXVlc3QgcmVwbGFjZWQgYnkgYSBuZXcgbWl0aWdhdGlvbg0KPiBzY29wZSkuDQo+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW01lZF0gRldJVywgd2UgZG8g YWxyZWFkeSBoYXZlIHRoaXMgdGV4dCBpbiB0aGUgZHJhZnQ6DQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gICAgICAgU2VjdGlvbiA4IG9mIFtSRkM4NDQ2XSBkaXNjdXNzZXMgc29tZSBtZWNoYW5p c21zIHRvIGltcGxlbWVudA0KPiB0bw0KPiA+ID4gPiA+ID4gICAgICAgbGltaXQgdGhlIGltcGFj dCBvZiByZXBsYXkgYXR0YWNrcyBvbiAwLVJUVCBkYXRhLiAgSWYgdGhlIERPVFMNCj4gPiA+ID4g PiA+ICAgICAgIHNlcnZlciBhY2NlcHRzIDAtUlRULCBpdCBNVVNUIGltcGxlbWVudCBvbmUgb2Yg dGhlc2UNCj4gPiA+ID4gPiA+IG1lY2hhbmlzbXMNCg== From nobody Mon Feb 18 04:56:44 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73003127AC2; Mon, 18 Feb 2019 04:56:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <155049459642.5615.1531443959140669891@ietfa.amsl.com> Date: Mon, 18 Feb 2019 04:56:36 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-26.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 12:56:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification Authors : Mohamed Boucadair Tirumaleswar Reddy Filename : draft-ietf-dots-data-channel-26.txt Pages : 70 Date : 2019-02-18 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; o reference: RFC XXXX Please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-26 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 18 05:06:55 2019 Return-Path: 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 5D80C130EF2 for ; Mon, 18 Feb 2019 05:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ewraU7WI08R1 for ; Mon, 18 Feb 2019 05:06:52 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6CD1277CC for ; Mon, 18 Feb 2019 05:06:52 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4433zZ5xDfz5vVh; Mon, 18 Feb 2019 14:06:50 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4433zZ4KHkzFpWY; Mon, 18 Feb 2019 14:06:50 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([fe80::393d:418c:3f1d:991d%21]) with mapi id 14.03.0435.000; Mon, 18 Feb 2019 14:06:50 +0100 From: To: "Benjamin Kaduk (kaduk@mit.edu)" , "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-data-channel-26.txt Thread-Index: AQHUx4lvlZY5RarULEKEOXk0QZ84ZaXlhL6Q Date: Mon, 18 Feb 2019 13:06:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA20FD1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155049459642.5615.1531443959140669891@ietfa.amsl.com> In-Reply-To: <155049459642.5615.1531443959140669891@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-26.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 13:06:54 -0000 Hi Ben, all, This version addresses the comments from the AD review.=20 A diff to track the changes is available at:=20 https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dots-data-channel-25&url2=3D= draft-ietf-dots-data-channel-26&difftype=3D--hwdiff=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: lundi 18 f=E9vrier 2019 13:57 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-data-channel-26.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling > (DOTS) Data Channel Specification > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Filename : draft-ietf-dots-data-channel-26.txt > Pages : 70 > Date : 2019-02-18 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data that > cannot easily or appropriately communicated through the DOTS signal > channel under attack conditions. >=20 > This is a companion document to the DOTS signal channel > specification. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements within the document with the RFC > number to be assigned to this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel Specification"; >=20 > o reference: RFC XXXX >=20 > Please update the "revision" date of the YANG module. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-26 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-26 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-26 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 18 08:23:32 2019 Return-Path: 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 64EB5130F1D; Mon, 18 Feb 2019 08:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 GTEn3ikKR5kS; Mon, 18 Feb 2019 08:23:29 -0800 (PST) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710110.outbound.protection.outlook.com [40.107.71.110]) (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 EA68F1277CC; Mon, 18 Feb 2019 08:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Tg70s9u19AsNt5RWSNstRyZxYUFzT1S5BmMlRTgEJQ=; b=wn57dhJLFyQnloo7cBu7vDPSgZK7GnfWBTten+7mhrKjROTBHoy+pO5ypQF+wu7v8jVyTbgvoxPeSXwdkpymLnGbDXhKINeyySyUdNqquEPzeIwgANYtk0AIGQhOCoHzOsNOi0XI4Iq26LU+5SvKtxdgWApS75h1yWhf7a5PIck= Received: from MWHPR01CA0040.prod.exchangelabs.com (2603:10b6:300:101::26) by DM6PR01MB5177.prod.exchangelabs.com (2603:10b6:5:8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Mon, 18 Feb 2019 16:23:27 +0000 Received: from DM3NAM03FT047.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::201) by MWHPR01CA0040.outlook.office365.com (2603:10b6:300:101::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Mon, 18 Feb 2019 16:23:26 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT047.mail.protection.outlook.com (10.152.83.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 18 Feb 2019 16:23:26 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1IGNM3L023003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 11:23:24 -0500 Date: Mon, 18 Feb 2019 10:23:22 -0600 From: Benjamin Kaduk To: CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190218162322.GI24387@kduck.mit.edu> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(136003)(396003)(2980300002)(51444003)(199004)(189003)(55784004)(2351001)(6306002)(246002)(6916009)(33656002)(229853002)(8936002)(426003)(66574012)(106466001)(55016002)(6246003)(47776003)(1076003)(104016004)(53416004)(14444005)(8676002)(126002)(93886005)(2870700001)(88552002)(58126008)(316002)(54906003)(786003)(2906002)(75432002)(446003)(36906005)(26826003)(478600001)(336012)(486006)(966005)(86362001)(5660300002)(956004)(26005)(76176011)(23756003)(50466002)(476003)(106002)(11346002)(7696005)(4326008)(305945005)(186003)(356004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB5177; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ea080144-dba3-483f-5fc1-08d695bd6926 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:DM6PR01MB5177; X-MS-TrafficTypeDiagnostic: DM6PR01MB5177: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB5177; 20:Mjnd+40HmPDm8EnVjdGfuZeokW1wTeXQirwBNZPGYZO7LibWIQx0Zl8sfpUqqy0T2gD3c8xPRfu2r0K/H9Zy4iSNxMFqkqGTvOORekdCU5MJUEXe5baFxoiM8SMfbxGfNengJgC74O7joRsvw4i0vJTEgOvoPbsAu2d43ZJy0FcEYgEtaPUNOT13O2FYs67rcgX53g4KvCpsPJk9ZLSyfkJjp0EPsxuUFVBCzDgsVR3LIGnsWa2uvkJEQVhUjcvZyKNK+qz0gY5rTCglr55nRpJkO/KxQBlAJc1g7fnJszD1VeMo4ASEK4C4cPTGBUp2rWxxdY8V2NeCyuQync8aGRUiOjdqfQ7jh7YpPXtd06k6cA4qvqOnGsrcZlocQwTa9nRmRsXKJfYac6ulBkQnbBUDTMbw4JSKxHZ5zMSx7pD7GPzpmhtqoolAVTnVjRD+zvdzrKJrTbi4rQBLLNO2G4IjbELEq7ndrMKUmQv4+Vgpum6zZsKSL7lqO/K2/PtbPab/Wt/3F2Ng1obBOp09UU8G+WHwzgfWphEYszQEe36MZxLKoKnByLqpzMOK9hwki8YTorPmq/lkwlrW8Tk8KwXgiQ5KOzMUDhHPYDNhojY= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09525C61DB X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM6PR01MB5177; 23:D8phmiZ+hVwrrQe4o5OVdCAGVI/u9wv+1R3gzF/?= =?iso-8859-1?Q?xCrjADTg3iVKBDIv2r9+WPLhrJoOt46RuALDlHPO33zt1gigllAoO2uDfx?= =?iso-8859-1?Q?mch92BnXvcZtOE2VBFwITkmUHp3VxPspdGnxTGRWuS9T9FDGFO22wk2BuK?= =?iso-8859-1?Q?sA67j25/AGdX26EgLHEphLg4qT9RY8+mbDyvCBdwAX6c9QPApMHupJfLOZ?= =?iso-8859-1?Q?9JOSFihA3P4npsb1FXzUiuJymMxGb3gOkzLsPVVy+bOshaAY0MCBizTC3X?= =?iso-8859-1?Q?zhKgDN+IV9NB8HUIGJ2WUT60hB4jLFHZWtZzdJ1kd1yN6YRzN5rfib8imK?= =?iso-8859-1?Q?zmuY+x2GQ6mCijF0qdq7AOb7Zx8a8pT3lkBMjxg71lC3dIMAiKHE/qbk33?= =?iso-8859-1?Q?W2R79HztEvcZvBsBeFhcJ40uNnX3jcQqXLgP/Yk1MTX06srAoUXbmarVPa?= =?iso-8859-1?Q?2JliSTTiTo2L0MYPIFEGnpAbR8Ls9QZAhziOu6/3nKNHnwOM117oM2DI3F?= =?iso-8859-1?Q?RK9LKTevSSYejSj2JPg/SgOlOMMijqygeqylyezh7WhuIaNT8kUuSd4+Jp?= =?iso-8859-1?Q?w81KMu63V7bU8V/lD90oRTeRtkSk8+ycPqxItBYwotEoxjABiBSfreSurD?= =?iso-8859-1?Q?Zw+z20ofw9O3lRo/g0WB2IQH9Wd8zpLUO07JZLAEstAN4CERrcNjTDAmMg?= =?iso-8859-1?Q?TLY/yuRcEtQvq+/ZDdR2xPkG8TVlpeM9puungwWd9xEPHEWLgelejBqWde?= =?iso-8859-1?Q?F0O56QI4LQPDAkQIhMODFEXYGlP66uKNfQXDOQHw8XWzAfi8VNkIRsj/6y?= =?iso-8859-1?Q?zuGcePr3Art5gFgim/Of4V2inPBo0K9EAe4KUIL99tpjG+B883qNintdkF?= =?iso-8859-1?Q?CZQReTNtW04CIHEAt7K2ihZ5t3NhTkIAu39CQIeHrL4FCKOmBqOurRA/e8?= =?iso-8859-1?Q?H421t3qzvKUyxoZZ1SkgWVEljx8VFJF9bjMGnfN/2iLesFDUGOCDu3HWhV?= =?iso-8859-1?Q?cZZX81gMzBT6Dl7Gp/oTON8vax+bwZ403P+yyCiplHvIXYy25W4Lp3LRCB?= =?iso-8859-1?Q?qZeIXqfa+UUWjI1Mc2gGZgGJTt/jTFrRHYStqh/2/F3QNtgCbU4d2kdye3?= =?iso-8859-1?Q?QjYi6FAsSUJ66JvXe1d/F3BWHfAv3gJXo+0xYMjfopkWZJoIZsL2sJXlx1?= =?iso-8859-1?Q?pL9uIH6vJ3VSri8qkFyt4IvYRBbqN6+qtcFnrAJBVkHQGpjtUA8JhSXT9z?= =?iso-8859-1?Q?Ddk9nuTAng4NtPrBp54wukNRlhW3HdQ1uMVsw0wsvR5fgNouMpqzPtwXAk?= =?iso-8859-1?Q?GMJZo/x/nXC9gKXYiib+laFbtjn0AshAhkZvu7lSBMySzSqcl1rGB/MEgb?= =?iso-8859-1?Q?/R0xiIA8bbNpbSnZh915bYEaFvFHD?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 3tTn6+4ceacYTJoqSVq0hiLvf4hPuoNPwAXfpwZQX9q4JOaJKIXPet2kRDdfM4EA0FS2EkzdFELzjC0Z5Z2fZrc1WFFN0g3A8PGiJz1ZvV5GdZC2t+os4w7Ib8z3RAiDViVcjE2WWlPUD8g0LTth1SsZr8aP4Sh6MzLjPSV16KYH0AO+9n0q7p5HQBCetOiG1DTGBHQlrGvTqzLlu5QPBkxODUsIUhtOsbTS//rRYfZ3X9sNOBICNob1nRgT9w4Tl6UrgDTjaKTxiDuYvWvt5JzfBSbLMFVqbVNWAfzJ5Boyh0wkKaDx3naTmVp+YUf+jKGZt96BGrkI6XQBGxzbgVfOlOSjCsG9nYgiPWQ54cAU5yQ4fUi5+C++Y7Ge986VFNN/fa5YlhpX1Sr2m7Mk5mO94txST0fHoePRY/KqjNg= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2019 16:23:26.0710 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea080144-dba3-483f-5fc1-08d695bd6926 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB5177 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 16:23:31 -0000 On Fri, Feb 15, 2019 at 03:36:05PM +0000, mohamed.boucadair@orange.com wrote: > Re-, > > Looking forward to discuss this further. > > I wonder whether you can consider putting the document in the IETF LC for now. If it happen that we need to modify the 0-RTT text, we will handle it as other IETF LC comments. I would normally be pretty amenable to starting IETF LC and continuing discussion; it's just for this issue in particular that I seem to be the main person on the IESG that enforces the "application profile for 0-RTT data" requirement, so it would feel rather odd to go forward in this case. Luckily, I spent some time this weekend reading RFC 7252 and have some substantive comments. The key oberservation here seems to be that the Message ID is scoped per endpoint, and replays can come from arbitrary addresses. Specifically, we recall that: The DOTS signal channel is layered on existing standards (Figure 3). +---------------------+ | DOTS Signal Channel | +---------------------+ | CoAP | +----------+----------+ | TLS | DTLS | +----------+----------+ | TCP | UDP | +----------+----------+ | IP | +---------------------+ We note that CoAP is using the IP address or "DTLS session" (arguably a poorly chosen term) to identify a CoAP association and that Message IDs are only used within the scope of such an association, it seems pretty clear that an attacker able to replay TLS 1.3 0-RTT data will slice off the top three lines of this figure and swap out the TCP/UDP/IP layers. In the absence of DTLS connection IDs, my understanding is that the "DTLS session" is identified solely by the transport connection, just as for coap-not-s, so by spoofing the source address, the attacker causes the replayed 0-RTT data (and thus, CoAP request) to be interpreted as a new incoming coaps connection. Given that Message ID is only 16 bits and the servers accepting 0-RTT data have potential to be quite busy, it does not seem workable to attempt to use the incoming Message IDs as globally unique replay defense, as the risk of collision would be pretty large. So I think that the 'mid' monotonicity and the rejection of conflicting request scopes are the main mitigating factors against replay in the current design (alongside the RFC 8446 mechanisms, of course), and the text should be adjusted to reflect that. It seems that the 'mid' ordering is probably enough to protect reordering/replay of mitigiation request and withdraw, even when reordered across other mitigation actions. But I am more concerned about reordering/replay of other messages, like efficacy updates and session configuration changes. Consider client attacker server | |----efficacy: attack mitigated--------------------->| | | |----efficacy: under attack------------------------->| | | | |-replay: attack mitigated->| Is the server going to end up with the expected state? -Ben > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : vendredi 15 février 2019 16:05 > > À : BOUCADAIR Mohamed TGI/OLN > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > dots@ietf.org > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf- > > dots-signal-channel) > > > > Hi Med, > > > > Short form: I need to think about it harder. There's some indication that > > the CoAp Message ID is at the wrong level to protect the 0-RTT data, but > > I'm not sure yet. > > > > Sorry for the delays; this has been a frenetic couple weeks :( > > > > -Ben > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000, mohamed.boucadair@orange.com wrote: > > > Hi Ben, > > > > > > What is the status for this one? Are we OK to move forward? > > > > > > Thank you. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > > > > Envoyé : mardi 29 janvier 2019 14:32 > > > > À : Benjamin Kaduk > > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > > > dots@ietf.org > > > > Objet : Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf- > > dots- > > > > signal-channel) > > > > > > > > Hi Ben, all, > > > > > > > > We edited a short draft (https://tools.ietf.org/html/draft-boucadair- > > dots- > > > > earlydata-00) to motivate the following text included in the signal > > channel > > > > draft: > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement to > > > > limit the impact of replay attacks on 0-RTT data. If the DOTS > > > > server accepts 0-RTT, it MUST implement one of these mechanisms. > > > > A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest. > > > > The DOTS signal channel messages sent as early data by the DOTS > > > > client are idempotent requests. As a reminder, Message ID > > > > (Section 3 of [RFC7252]) is changed each time a new CoAP request > > > > is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized > > > > in each CoAP request. The DOTS server(s) can use Message ID and > > > > Token in the DOTS signal channel message to detect replay of early > > > > data, and accept 0-RTT data at most once. Furthermore, 'mid' > > > > value is monotonically increased by the DOTS client for each > > > > mitigation request, attackers replaying mitigation requests with > > > > lower numeric 'mid' values and overlapping scopes with mitigation > > > > requests having higher numeric 'mid' values will be rejected > > > > systematically by the DOTS server. > > > > > > > > Owing to the aforementioned protections, especially those afforded > > > > by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446 > > > > anti-replay mechanisms, all DOTS signal channel requests are safe > > > > to transmit in TLS 1.3 as early data. Refer to > > > > [I-D.boucadair-dots-earlydata] for more details. > > > > > > > > This text and also the Designated Expert guidelines are implemented in - > > 28. > > > > These are the two pending issues from your AD review. > > > > > > > > Other edits were also made to record what was agreed on the list. > > > > > > > > We hope this version is now ready to move forward. > > > > > > > > Cheers, > > > > Med > > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that > > > > "Application > > > > > > > > > protocols MUST NOT use 0-RTT data without a profile that > > defines > > > > its > > > > > > use. > > > > > > > > > That profile needs to identify which messages or interactions > > are > > > > > safe > > > > > > to > > > > > > > > use > > > > > > > > > with 0-RTT and how to handle the situation when the server > > rejects > > > > 0- > > > > > > RTT > > > > > > > > and > > > > > > > > > falls back to 1-RTT." So we either need to say which client > > > > requests > > > > > > are > > > > > > > > 0-RTT > > > > > > > > > safe (and why) or defer that profile to another document. > > draft- > > > > > ietf- > > > > > > > > dnsop- > > > > > > > > > session-signal is perhaps an example of a document that > > specifies > > > > > which > > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > > (draft-ietf-acme-acme is another, but an uninteresting one, > > since > > > > > they > > > > > > make > > > > > > > > > every request include a single-use nonce, and all messages are > > 0- > > > > RTT > > > > > > safe.) > > > > > > > > > Our use of increasing 'mid' values may help here, in terms of > > > > > allowing > > > > > > > > DELETEs > > > > > > > > > to be safe, but I'd have to think a little more to be sure that > > > > > > requesting > > > > > > > > > mitigation would be safe. (On first glance the session- > > managemnet > > > > > bits > > > > > > > > would > > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and DELETE), > > and > > > > CoAP > > > > > > is > > > > > > > > capable of detecting message duplication (see > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both > > confirmable > > > > > and > > > > > > > > non-confirmable messages. > > > > > > > > [1] An attacker replaying DELETE will not have any adverse > > impact, > > > > > 2.02 > > > > > > > > (Deleted) Response Code is returned even if the mitigation > > request > > > > does > > > > > > not > > > > > > > > exist. > > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 should > > suffice > > > > to > > > > > > handle > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying an > > old > > > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement > > to > > > > > > > limit the impact of replay attacks on 0-RTT data. If the > > DOTS > > > > > > > server accepts 0-RTT, it MUST implement one of these > > mechanisms From nobody Mon Feb 18 22:41:16 2019 Return-Path: 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 CFB9C130E76; Mon, 18 Feb 2019 22:41:13 -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 o7pvalwznurD; Mon, 18 Feb 2019 22:41:11 -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 C4981130E7A; Mon, 18 Feb 2019 22:41:10 -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=1550558345; 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-ms-exchange-purlcount: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=yehttd8r3ha2RM+VV3NMKkG11ij8z9LPd+5G4y m6W9o=; b=qOQgkWXhYf3STVOtV/6E25qOFe+JvXABipxDqXFw rRaOSePh3/23pKSp4oCjCpq3yIxqJfxOC0gBtBcTVXhExbedIr gJQsD0ah0gxX9LtP9S/vECjpLEj69cfp7DPWTR+uMigVGhnVR0 ZsxTg4rnhIVpLRw4Q/2y3NgNXm7byrA= 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 604b_1f5f_a623e17a_5469_4eea_bf53_fa1d9a75ca34; Mon, 18 Feb 2019 23:39:04 -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; Mon, 18 Feb 2019 23:40:32 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 18 Feb 2019 23:40:33 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Feb 2019 23:40:28 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2760.namprd16.prod.outlook.com (20.178.233.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Tue, 19 Feb 2019 06:40:31 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Tue, 19 Feb 2019 06:40:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , "mohamed.boucadair@orange.com" CC: "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUx6Zad4wSPXSxIUiJUgMrwAb+nKXmpwyw Date: Tue, 19 Feb 2019 06:40:30 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> In-Reply-To: <20190218162322.GI24387@kduck.mit.edu> 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: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f6b8499-d9f6-43a4-4dfb-08d69635248d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2760; x-ms-traffictypediagnostic: BYAPR16MB2760: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNzYwOzIzOm5BSHlCUkRkcHRwSzRKNlo5Ti8vOUdzWVhN?= =?utf-8?B?Mm9HZEZpOTZBSy9jRXN3RlVGWEtiZUU1MDc1R2dmWkIwR082VWhwLytqT0tT?= =?utf-8?B?RHZQdTEyS1NCYnVjZUlVOWU1SHk0aloxd3JHN0hsYXdJZ3pPRm1vZ0gvQ0Rn?= =?utf-8?B?SGg0c0Y5TjFFT3NSVjdvMDVZUlBST0Z0RXozdFVqWkxrVkpHOXFxVW5TcG40?= =?utf-8?B?MXRJbGYzeEJRTHN2VFdVZ0dvOWVGVkVBZ3VOR3VhTzR0a2pSK1VpdFIzRVcz?= =?utf-8?B?Ulp1ZC9wZkpCQ3l1RGFpWHFYMXlDN2hUbys5SG4vTTFvWlNwejhscFYrSEZw?= =?utf-8?B?Um1ReXFPS2wrazB1Q1ZQcGgrdHFsd0RVcHcrd2d6cWZwSlloSDgyeUdQNDlQ?= =?utf-8?B?YkVyTGx5M3BoN0ZBQ2w2TVRKZklaOWFRbm9XOWhyc2dpTHM2WEl1SGhrMVd3?= =?utf-8?B?Mkx5SmhRWVlETnJLRVBOMjE5NEZQVlJweEI3VnFKVnlXWTR2akpNekphNkp1?= =?utf-8?B?TWppUUVLRGkxbjRpM3NLQnFlcjg3U1RwS05WMGdTZnV1dVpWamNpSkxQNk85?= =?utf-8?B?TmNQWmlXb3pmZjFkRDlwbWtpUHI3YU9GMVR2dnJWV3JJaHpqVlp1K21yRE5i?= =?utf-8?B?enI3dUVIQUJZMmFjTUhyWnR5S2l4dHFEVFNlKzA3YnNabDdoU0Z0QytsYVdQ?= =?utf-8?B?Nm0vdTZTVk5NWTFjTDBKLzZkYWxsNG45cUNoY3krdkgrdG9KR3hCVThMSkRV?= =?utf-8?B?U2FhSmZiYm5Ja2dMNk9BU3dUa2Fsb0NQOXRrK1YydUpaSUxuZktvSEgvK3da?= =?utf-8?B?d3E1Qmx5WGE3WWJGWHE0K2JvS2FjOEVQbXZkRVR2Vm5ndVFnbzNmbUN4MERz?= =?utf-8?B?NVhiYW50UlJNUEc1dHJVa2FBVmN5T1gzMm9xKzE4VXgwUGEwY3pPYkM3R2ND?= =?utf-8?B?UkVlSVdtazJPaWptenlSUE9YYkdUSkEwTkIxU3k1YXh0dUxrZXJhS2kvY3ht?= =?utf-8?B?SjhmeURkeUxkeGltZit6S05NNmRLRUFrWmhPOTMwRHN0NGd5em5YeU5YL00w?= =?utf-8?B?VVBxSEl1Qjl3V09Cb3BrN0FvSGV0YzdFUHgzMUlta21EV25sOVVPYS82UWg1?= =?utf-8?B?UFJ4YjJ1UFd3czJZZGNoV1ptOEJzcHZSVlkrRnZQMkpIcXBsQVJaK1lqWEhW?= =?utf-8?B?RE95emQ4c1ZEVjgwN3BhZE4yVmVFQms2UnZmdXIwdkY1b09HNjJVeVEvRVJU?= =?utf-8?B?bGRlT1RVL1lqMWhEdzV4MHBFZHcyYytXMUVJRnRuOVhRZStLbHpXWWtaajhU?= =?utf-8?B?b2pwcnBpL1MrSnVsVjJyV0RETHVqaGNubkVwSjRxSlpzMGNWcGFvTEdGYnls?= =?utf-8?B?QWpZOXhSUFhVaXBiZjNMbXFiVEFiL0dnZVA4dC9EOUQyMU1LWTBhRGZ1TGll?= =?utf-8?B?NitNV1E4K3hQajRtZXhjL0Myd0V3dzl1RktwSEduMG5pc2dTRWdQZGF4KzF1?= =?utf-8?B?WGRCS3FMM0JRRFZXU2ZaQ1AxbDVjNnl1Q09XVHFtZFU2Z3NjUy83eDllRXZr?= =?utf-8?B?bWN0bjRpVXVRTmZKUmhOUXBFeVkzRVFOZFNmSzNSZkVjbEh3N3Y5ZkRhZmlw?= =?utf-8?B?Z2hRN0JpS3FVTEJYdmZCK0FoaGkyOWRlL0lScUdINTFIcVpzSkNLaXlHL2Y5?= =?utf-8?B?b01DR3FNKzRiekw1eHh5UE9yM0Rrc0JubGFZTzdFNWFvRzBPelZmVFNhSUFx?= =?utf-8?B?SkpQc3ZQV1NNMzdMYzd2UGJNdU5ySkk2TFRwZzRreFRuQllNeWZieUJQdkxH?= =?utf-8?B?b1pwRmZBa2xsdlRzNFZSdGViRFc1cHlLeW1IQzJQUUFxMkhHY2pNN3Jld3lG?= =?utf-8?B?V2lZTlVzMG13SFM2RDMxcGQ2azlhYzR4aElVelV4a2phNzdIWjV0ZlI4WHVQ?= =?utf-8?B?Qktjcy9EU0gzS04yV2VNUitxYUdya1JVZm5KWkg5U3R6cFR4M2Vqd2ZrdHJX?= =?utf-8?B?VzFBaExzN040amphZmxsL1FhZWpzVG5lcDNZWko2alpZMk1sbWVIY0JPU3VI?= =?utf-8?B?VmZtSmhDd0NxQ3Q0WDJkdWEwNGk1Tnl4LzhDTUZDUk44SjVpWFhlMHhIZkJz?= =?utf-8?B?aGc9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(376002)(39860400002)(366004)(55784004)(199004)(189003)(13464003)(32952001)(51444003)(105586002)(80792005)(97736004)(106356001)(6436002)(74316002)(86362001)(93886005)(54906003)(110136005)(316002)(305945005)(7736002)(3846002)(4326008)(6116002)(9686003)(6306002)(71200400001)(71190400001)(7696005)(99286004)(55016002)(76176011)(25786009)(66574012)(8676002)(2171002)(81166006)(81156014)(68736007)(229853002)(66066001)(5024004)(6246003)(30864003)(2501003)(53546011)(6506007)(446003)(11346002)(33656002)(186003)(102836004)(26005)(2906002)(14454004)(486006)(476003)(53936002)(256004)(8936002)(72206003)(966005)(5660300002)(14444005)(478600001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2760; H:BYAPR16MB2790.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: WUh3jkgaaXvA4UfP1EfVdYaDrnGmQ20Qq2EexFaNMbx+dep5eWJ3E1SxFyB9kWw1Og1lBWm7PK2dJ09dHwNhA2YwGtia7R+PWyGSwzVv4hMthUHQS8Rt6cZOfEvFs/YMLCBUqGiB4mIVLFguY7RntjLOdPjPktbCTKmbPSv/ZcZ34m3I6Au0djpA2lo/Kj7kfJmnGOzxoNTlNC+18jJk0Ss2o9Rl0iYCmdCXP4SqliGe8CiUeRSa5ZizH0owimfRXGHejCrHPuV6znsgUi3bKbgCbroTFZS0+U4TLUiXTx2uC7TdIL9IPWoiRRUi8zpS0dH6NeGHQG+pKrdIk9tov0bW4k9bxUjBaLBRf+h8x0FoacxzntfaLxl+go0vAUDEXi65kHnyph8sCygHCWGRvMnADcuF1vSR66D/3VvcM9Q= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f6b8499-d9f6-43a4-4dfb-08d69635248d X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 06:40:30.8416 (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: BYAPR16MB2760 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6485> : inlines <7018> : streams <1813464> : uri <2798664> Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 06:41:14 -0000 SGkgQmVuLA0KDQpBZ3JlZSB3aXRoIHlvdSB0aGF0IE1lc3NhZ2UgSURzIGNhbm5vdCBiZSB1c2Vk IGFzIGdsb2JhbGx5IHVuaXF1ZSByZXBsYXkgZGVmZW5zZSBidXQgdGhlIGRyYWZ0IGlzIHVzaW5n IGJvdGggTWVzc2FnZSBJRCBhbmQgVG9rZW4gKG9yIHJlcXVlc3QgSUQpIGFzIHVuaXF1ZSByZWxh eSBkZWZlbnNlIHdpdGhpbiB0aGUgRE9UUyBzZXJ2ZXIgZG9tYWluLiBDb0FQIGFsbG93cyB0aGUg c2l6ZSBvZiBUb2tlbiB0byBiZSB1cCB0byA4IGJ5dGVzIGFuZCBpcyByYW5kb21pemVkIChzZWUg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjc2VjdGlvbi01LjMuMSkuIA0KDQpJ IGFsc28gYWdyZWUgd2l0aCB5b3UgdGhhdCAnbWlkJyBpcyBub3Qgc3VmZmljaWVudCB0byBkZXRl Y3QgYWxsIHR5cGVzIG9mIHJlcGxheSBhdHRhY2tzIGFuZCBoZW5jZSB0aGUgRE9UUyBzaWduYWwg Y2hhbm5lbCBpcyByZXBseWluZyBvbiBNZXNzYWdlIElEIGFuZCBUb2tlbiBhbG9uZy1zaWRlIHRo ZSAwLVJUVCByZWxheSBkZXRlY3Rpb24gbWVjaGFuaXNtcyBpbiBSRkMgODQ0NiB0byBkZWZlbmQg YWdhaW5zdCBhdHRhY2tlcnMgc3Bvb2ZpbmcgdGhlIERPVFMgY2xpZW50IElQIGFkZHJlc3MgYW5k IHJlcGxheWluZyB0aGUgMC1SVFQgZGF0YS4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVk dT4NCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAxOCwgMjAxOSA5OjUzIFBNDQo+IFRvOiBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IENjOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsNCj4gZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1jaGFubmVsQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBV c2luZyBFYXJseSBEYXRhIGluIERPVFMgKFJFOiBbRG90c10gQUQgcmV2aWV3IG9mIGRyYWZ0LWll dGYtZG90cy0NCj4gc2lnbmFsLWNoYW5uZWwpDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQg ZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0K PiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtu b3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IE9uIEZyaSwgRmViIDE1LCAyMDE5IGF0IDAz OjM2OjA1UE0gKzAwMDAsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gd3JvdGU6DQo+ ID4gUmUtLA0KPiA+DQo+ID4gTG9va2luZyBmb3J3YXJkIHRvIGRpc2N1c3MgdGhpcyBmdXJ0aGVy Lg0KPiA+DQo+ID4gSSB3b25kZXIgd2hldGhlciB5b3UgY2FuIGNvbnNpZGVyIHB1dHRpbmcgdGhl IGRvY3VtZW50IGluIHRoZSBJRVRGIExDIGZvcg0KPiBub3cuIElmIGl0IGhhcHBlbiB0aGF0IHdl IG5lZWQgdG8gbW9kaWZ5IHRoZSAwLVJUVCB0ZXh0LCB3ZSB3aWxsIGhhbmRsZSBpdCBhcw0KPiBv dGhlciBJRVRGIExDIGNvbW1lbnRzLg0KPiANCj4gSSB3b3VsZCBub3JtYWxseSBiZSBwcmV0dHkg YW1lbmFibGUgdG8gc3RhcnRpbmcgSUVURiBMQyBhbmQgY29udGludWluZw0KPiBkaXNjdXNzaW9u OyBpdCdzIGp1c3QgZm9yIHRoaXMgaXNzdWUgaW4gcGFydGljdWxhciB0aGF0IEkgc2VlbSB0byBi ZSB0aGUgbWFpbiBwZXJzb24NCj4gb24gdGhlIElFU0cgdGhhdCBlbmZvcmNlcyB0aGUgImFwcGxp Y2F0aW9uIHByb2ZpbGUgZm9yIDAtUlRUIGRhdGEiIHJlcXVpcmVtZW50LA0KPiBzbyBpdCB3b3Vs ZCBmZWVsIHJhdGhlciBvZGQgdG8gZ28gZm9yd2FyZCBpbiB0aGlzIGNhc2UuDQo+IEx1Y2tpbHks IEkgc3BlbnQgc29tZSB0aW1lIHRoaXMgd2Vla2VuZCByZWFkaW5nIFJGQyA3MjUyIGFuZCBoYXZl IHNvbWUNCj4gc3Vic3RhbnRpdmUgY29tbWVudHMuDQo+IA0KPiBUaGUga2V5IG9iZXJzZXJ2YXRp b24gaGVyZSBzZWVtcyB0byBiZSB0aGF0IHRoZSBNZXNzYWdlIElEIGlzIHNjb3BlZCBwZXINCj4g ZW5kcG9pbnQsIGFuZCByZXBsYXlzIGNhbiBjb21lIGZyb20gYXJiaXRyYXJ5IGFkZHJlc3Nlcy4N Cj4gDQo+IFNwZWNpZmljYWxseSwgd2UgcmVjYWxsIHRoYXQ6DQo+IA0KPiAgICBUaGUgRE9UUyBz aWduYWwgY2hhbm5lbCBpcyBsYXllcmVkIG9uIGV4aXN0aW5nIHN0YW5kYXJkcyAoRmlndXJlIDMp Lg0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgRE9UUyBTaWduYWwgQ2hhbm5lbCB8DQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgQ29BUCAgICAgICAgfA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgIFRMUyAgICB8ICAgRFRMUyAgIHwNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICBUQ1AgICAgfCAgIFVEUCAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgIElQICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQo+IA0KPiBXZSBub3RlIHRoYXQgQ29BUCBpcyB1c2luZyB0aGUg SVAgYWRkcmVzcyBvciAiRFRMUyBzZXNzaW9uIiAoYXJndWFibHkgYSBwb29ybHkNCj4gY2hvc2Vu IHRlcm0pIHRvIGlkZW50aWZ5IGEgQ29BUCBhc3NvY2lhdGlvbiBhbmQgdGhhdCBNZXNzYWdlIElE cyBhcmUgb25seSB1c2VkDQo+IHdpdGhpbiB0aGUgc2NvcGUgb2Ygc3VjaCBhbiBhc3NvY2lhdGlv biwgaXQgc2VlbXMgcHJldHR5IGNsZWFyIHRoYXQgYW4gYXR0YWNrZXINCj4gYWJsZSB0byByZXBs YXkgVExTIDEuMyAwLVJUVCBkYXRhIHdpbGwgc2xpY2Ugb2ZmIHRoZSB0b3AgdGhyZWUgbGluZXMg b2YgdGhpcyBmaWd1cmUNCj4gYW5kIHN3YXAgb3V0IHRoZSBUQ1AvVURQL0lQIGxheWVycy4gIElu IHRoZSBhYnNlbmNlIG9mIERUTFMgY29ubmVjdGlvbiBJRHMsDQo+IG15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCB0aGUgIkRUTFMgc2Vzc2lvbiINCj4gaXMgaWRlbnRpZmllZCBzb2xlbHkgYnkgdGhl IHRyYW5zcG9ydCBjb25uZWN0aW9uLCBqdXN0IGFzIGZvciBjb2FwLW5vdC1zLCBzbyBieQ0KPiBz cG9vZmluZyB0aGUgc291cmNlIGFkZHJlc3MsIHRoZSBhdHRhY2tlciBjYXVzZXMgdGhlIHJlcGxh eWVkIDAtUlRUIGRhdGEgKGFuZA0KPiB0aHVzLCBDb0FQIHJlcXVlc3QpIHRvIGJlIGludGVycHJl dGVkIGFzIGEgbmV3IGluY29taW5nIGNvYXBzIGNvbm5lY3Rpb24uDQo+IA0KPiBHaXZlbiB0aGF0 IE1lc3NhZ2UgSUQgaXMgb25seSAxNiBiaXRzIGFuZCB0aGUgc2VydmVycyBhY2NlcHRpbmcgMC1S VFQgZGF0YQ0KPiBoYXZlIHBvdGVudGlhbCB0byBiZSBxdWl0ZSBidXN5LCBpdCBkb2VzIG5vdCBz ZWVtIHdvcmthYmxlIHRvIGF0dGVtcHQgdG8gdXNlDQo+IHRoZSBpbmNvbWluZyBNZXNzYWdlIElE cyBhcyBnbG9iYWxseSB1bmlxdWUgcmVwbGF5IGRlZmVuc2UsIGFzIHRoZSByaXNrIG9mDQo+IGNv bGxpc2lvbiB3b3VsZCBiZSBwcmV0dHkgbGFyZ2UuDQo+IA0KPiBTbyBJIHRoaW5rIHRoYXQgdGhl ICdtaWQnIG1vbm90b25pY2l0eSBhbmQgdGhlIHJlamVjdGlvbiBvZiBjb25mbGljdGluZyByZXF1 ZXN0DQo+IHNjb3BlcyBhcmUgdGhlIG1haW4gbWl0aWdhdGluZyBmYWN0b3JzIGFnYWluc3QgcmVw bGF5IGluIHRoZSBjdXJyZW50IGRlc2lnbg0KPiAoYWxvbmdzaWRlIHRoZSBSRkMgODQ0NiBtZWNo YW5pc21zLCBvZiBjb3Vyc2UpLCBhbmQgdGhlIHRleHQgc2hvdWxkIGJlDQo+IGFkanVzdGVkIHRv IHJlZmxlY3QgdGhhdC4NCj4gDQo+IEl0IHNlZW1zIHRoYXQgdGhlICdtaWQnIG9yZGVyaW5nIGlz IHByb2JhYmx5IGVub3VnaCB0byBwcm90ZWN0DQo+IHJlb3JkZXJpbmcvcmVwbGF5IG9mIG1pdGln aWF0aW9uIHJlcXVlc3QgYW5kIHdpdGhkcmF3LCBldmVuIHdoZW4gcmVvcmRlcmVkDQo+IGFjcm9z cyBvdGhlciBtaXRpZ2F0aW9uIGFjdGlvbnMuICBCdXQgSSBhbSBtb3JlIGNvbmNlcm5lZCBhYm91 dA0KPiByZW9yZGVyaW5nL3JlcGxheSBvZiBvdGhlciBtZXNzYWdlcywgbGlrZSBlZmZpY2FjeSB1 cGRhdGVzIGFuZCBzZXNzaW9uDQo+IGNvbmZpZ3VyYXRpb24gY2hhbmdlcy4NCj4gDQo+IENvbnNp ZGVyDQo+IA0KPiBjbGllbnQgICAgICAgICAgICAgICAgICAgYXR0YWNrZXIgICAgICAgICAgICAg ICAgICAgIHNlcnZlcg0KPiB8DQo+IHwtLS0tZWZmaWNhY3k6IGF0dGFjayBtaXRpZ2F0ZWQtLS0t LS0tLS0tLS0tLS0tLS0tLS0+fA0KPiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCj4gfC0tLS1lZmZpY2FjeTogdW5kZXIgYXR0YWNrLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPiB8ICAgICAgICAgICAgICAgICAgICAgICAgfC1yZXBs YXk6IGF0dGFjayBtaXRpZ2F0ZWQtPnwNCj4gDQo+IElzIHRoZSBzZXJ2ZXIgZ29pbmcgdG8gZW5k IHVwIHdpdGggdGhlIGV4cGVjdGVkIHN0YXRlPw0KPiANCj4gLUJlbg0KPiANCj4gDQo+ID4NCj4g PiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gRGXCoDogQmVuamFtaW4gS2Fk dWsgW21haWx0bzprYWR1a0BtaXQuZWR1XSBFbnZvecOpwqA6IHZlbmRyZWRpIDE1DQo+ID4gPiBm w6l2cmllciAyMDE5IDE2OjA1IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gQ2PCoDog S29uZGEsDQo+ID4gPiBUaXJ1bWFsZXN3YXIgUmVkZHk7IGRyYWZ0LWlldGYtZG90cy1zaWduYWwt Y2hhbm5lbEBpZXRmLm9yZzsNCj4gPiA+IGRvdHNAaWV0Zi5vcmcNCj4gPiA+IE9iamV0wqA6IFJl OiBVc2luZyBFYXJseSBEYXRhIGluIERPVFMgKFJFOiBbRG90c10gQUQgcmV2aWV3IG9mDQo+ID4g PiBkcmFmdC1pZXRmLQ0KPiA+ID4gZG90cy1zaWduYWwtY2hhbm5lbCkNCj4gPiA+DQo+ID4gPiBI aSBNZWQsDQo+ID4gPg0KPiA+ID4gU2hvcnQgZm9ybTogSSBuZWVkIHRvIHRoaW5rIGFib3V0IGl0 IGhhcmRlci4gIFRoZXJlJ3Mgc29tZQ0KPiA+ID4gaW5kaWNhdGlvbiB0aGF0IHRoZSBDb0FwIE1l c3NhZ2UgSUQgaXMgYXQgdGhlIHdyb25nIGxldmVsIHRvIHByb3RlY3QNCj4gPiA+IHRoZSAwLVJU VCBkYXRhLCBidXQgSSdtIG5vdCBzdXJlIHlldC4NCj4gPiA+DQo+ID4gPiBTb3JyeSBmb3IgdGhl IGRlbGF5czsgdGhpcyBoYXMgYmVlbiBhIGZyZW5ldGljIGNvdXBsZSB3ZWVrcyA6KA0KPiA+ID4N Cj4gPiA+IC1CZW4NCj4gPiA+DQo+ID4gPiBPbiBGcmksIEZlYiAxNSwgMjAxOSBhdCAwMzowMToy OVBNICswMDAwLA0KPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+ID4g PiBIaSBCZW4sDQo+ID4gPiA+DQo+ID4gPiA+IFdoYXQgaXMgdGhlIHN0YXR1cyBmb3IgdGhpcyBv bmU/IEFyZSB3ZSBPSyB0byBtb3ZlIGZvcndhcmQ/DQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rIHlv dS4NCj4gPiA+ID4NCj4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBNZWQNCj4gPiA+ID4NCj4gPiA+ ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiBEZcKgOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gPiA+ID4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tXQ0KPiA+ID4gPiA+IEVudm95w6nCoDogbWFyZGkgMjkgamFudmllciAyMDE5 IDE0OjMyIMOAwqA6IEJlbmphbWluIEthZHVrIENjwqA6DQo+ID4gPiA+ID4gS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeTsNCj4gPiA+ID4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWxA aWV0Zi5vcmc7DQo+ID4gPiA+ID4gZG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+IE9iamV0wqA6IFVz aW5nIEVhcmx5IERhdGEgaW4gRE9UUyAoUkU6IFtEb3RzXSBBRCByZXZpZXcgb2YNCj4gPiA+ID4g PiBkcmFmdC1pZXRmLQ0KPiA+ID4gZG90cy0NCj4gPiA+ID4gPiBzaWduYWwtY2hhbm5lbCkNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IEhpIEJlbiwgYWxsLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2Ug ZWRpdGVkIGEgc2hvcnQgZHJhZnQNCj4gPiA+ID4gPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvdWNhZGFpci0NCj4gPiA+IGRvdHMtDQo+ID4gPiA+ID4gZWFybHlkYXRhLTAw KSB0byBtb3RpdmF0ZSB0aGUgZm9sbG93aW5nIHRleHQgaW5jbHVkZWQgaW4gdGhlDQo+ID4gPiA+ ID4gc2lnbmFsDQo+ID4gPiBjaGFubmVsDQo+ID4gPiA+ID4gZHJhZnQ6DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiAgICAgICBTZWN0aW9uIDggb2YgW1JGQzg0NDZdIGRpc2N1c3NlcyBzb21lIG1lY2hh bmlzbXMgdG8gaW1wbGVtZW50IHRvDQo+ID4gPiA+ID4gICAgICAgbGltaXQgdGhlIGltcGFjdCBv ZiByZXBsYXkgYXR0YWNrcyBvbiAwLVJUVCBkYXRhLiAgSWYgdGhlIERPVFMNCj4gPiA+ID4gPiAg ICAgICBzZXJ2ZXIgYWNjZXB0cyAwLVJUVCwgaXQgTVVTVCBpbXBsZW1lbnQgb25lIG9mIHRoZXNl IG1lY2hhbmlzbXMuDQo+ID4gPiA+ID4gICAgICAgQSBET1RTIHNlcnZlciBjYW4gcmVqZWN0IDAt UlRUIGJ5IHNlbmRpbmcgYSBUTFMgSGVsbG9SZXRyeVJlcXVlc3QuDQo+ID4gPiA+ID4gICAgICAg VGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgbWVzc2FnZXMgc2VudCBhcyBlYXJseSBkYXRhIGJ5IHRo ZSBET1RTDQo+ID4gPiA+ID4gICAgICAgY2xpZW50IGFyZSBpZGVtcG90ZW50IHJlcXVlc3RzLiAg QXMgYSByZW1pbmRlciwgTWVzc2FnZSBJRA0KPiA+ID4gPiA+ICAgICAgIChTZWN0aW9uIDMgb2Yg W1JGQzcyNTJdKSBpcyBjaGFuZ2VkIGVhY2ggdGltZSBhIG5ldyBDb0FQIHJlcXVlc3QNCj4gPiA+ ID4gPiAgICAgICBpcyBzZW50LCBhbmQgdGhlIFRva2VuIChTZWN0aW9uIDUuMy4xIG9mIFtSRkM3 MjUyXSkgaXMgcmFuZG9taXplZA0KPiA+ID4gPiA+ICAgICAgIGluIGVhY2ggQ29BUCByZXF1ZXN0 LiAgVGhlIERPVFMgc2VydmVyKHMpIGNhbiB1c2UgTWVzc2FnZSBJRCBhbmQNCj4gPiA+ID4gPiAg ICAgICBUb2tlbiBpbiB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBtZXNzYWdlIHRvIGRldGVjdCBy ZXBsYXkgb2YgZWFybHkNCj4gPiA+ID4gPiAgICAgICBkYXRhLCBhbmQgYWNjZXB0IDAtUlRUIGRh dGEgYXQgbW9zdCBvbmNlLiAgRnVydGhlcm1vcmUsICdtaWQnDQo+ID4gPiA+ID4gICAgICAgdmFs dWUgaXMgbW9ub3RvbmljYWxseSBpbmNyZWFzZWQgYnkgdGhlIERPVFMgY2xpZW50IGZvciBlYWNo DQo+ID4gPiA+ID4gICAgICAgbWl0aWdhdGlvbiByZXF1ZXN0LCBhdHRhY2tlcnMgcmVwbGF5aW5n IG1pdGlnYXRpb24gcmVxdWVzdHMgd2l0aA0KPiA+ID4gPiA+ICAgICAgIGxvd2VyIG51bWVyaWMg J21pZCcgdmFsdWVzIGFuZCBvdmVybGFwcGluZyBzY29wZXMgd2l0aCBtaXRpZ2F0aW9uDQo+ID4g PiA+ID4gICAgICAgcmVxdWVzdHMgaGF2aW5nIGhpZ2hlciBudW1lcmljICdtaWQnIHZhbHVlcyB3 aWxsIGJlIHJlamVjdGVkDQo+ID4gPiA+ID4gICAgICAgc3lzdGVtYXRpY2FsbHkgYnkgdGhlIERP VFMgc2VydmVyLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgICAgT3dpbmcgdG8gdGhlIGFmb3Jl bWVudGlvbmVkIHByb3RlY3Rpb25zLCBlc3BlY2lhbGx5IHRob3NlIGFmZm9yZGVkDQo+ID4gPiA+ ID4gICAgICAgYnkgQ29BUCBkZWR1cGxpY2F0aW9uIChTZWN0aW9uIDQuNSBvZiBbUkZDNzI1Ml0p IGFuZCBSRkMgODQ0Ng0KPiA+ID4gPiA+ICAgICAgIGFudGktcmVwbGF5IG1lY2hhbmlzbXMsIGFs bCBET1RTIHNpZ25hbCBjaGFubmVsIHJlcXVlc3RzIGFyZSBzYWZlDQo+ID4gPiA+ID4gICAgICAg dG8gdHJhbnNtaXQgaW4gVExTIDEuMyBhcyBlYXJseSBkYXRhLiAgUmVmZXIgdG8NCj4gPiA+ID4g PiAgICAgICBbSS1ELmJvdWNhZGFpci1kb3RzLWVhcmx5ZGF0YV0gZm9yIG1vcmUgZGV0YWlscy4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgdGV4dCBhbmQgYWxzbyB0aGUgRGVzaWduYXRlZCBF eHBlcnQgZ3VpZGVsaW5lcyBhcmUNCj4gPiA+ID4gPiBpbXBsZW1lbnRlZCBpbiAtDQo+ID4gPiAy OC4NCj4gPiA+ID4gPiBUaGVzZSBhcmUgdGhlIHR3byBwZW5kaW5nIGlzc3VlcyBmcm9tIHlvdXIg QUQgcmV2aWV3Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT3RoZXIgZWRpdHMgd2VyZSBhbHNvIG1h ZGUgdG8gcmVjb3JkIHdoYXQgd2FzIGFncmVlZCBvbiB0aGUgbGlzdC4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IFdlIGhvcGUgdGhpcyB2ZXJzaW9uIGlzIG5vdyByZWFkeSB0byBtb3ZlIGZvcndhcmQu DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+ID4gTWVkDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gPiA+ID4gUmVnYXJkaW5nIHRoZSAoRClUTFMgMS4zIDAtUlRUIGRhdGEs IFJGQyA4NDQ2IG5vdGVzDQo+ID4gPiA+ID4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiAiQXBw bGljYXRpb24NCj4gPiA+ID4gPiA+ID4gPiA+ID4gcHJvdG9jb2xzIE1VU1QgTk9UIHVzZSAwLVJU VCBkYXRhIHdpdGhvdXQgYSBwcm9maWxlDQo+ID4gPiA+ID4gPiA+ID4gPiA+IHRoYXQNCj4gPiA+ IGRlZmluZXMNCj4gPiA+ID4gPiBpdHMNCj4gPiA+ID4gPiA+ID4gdXNlLg0KPiA+ID4gPiA+ID4g PiA+ID4gPiBUaGF0IHByb2ZpbGUgbmVlZHMgdG8gaWRlbnRpZnkgd2hpY2ggbWVzc2FnZXMgb3IN Cj4gPiA+ID4gPiA+ID4gPiA+ID4gaW50ZXJhY3Rpb25zDQo+ID4gPiBhcmUNCj4gPiA+ID4gPiA+ IHNhZmUNCj4gPiA+ID4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+ID4gPiA+IHVzZQ0KPiA+ID4gPiA+ ID4gPiA+ID4gPiB3aXRoIDAtUlRUIGFuZCBob3cgdG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gd2hl biB0aGUNCj4gPiA+ID4gPiA+ID4gPiA+ID4gc2VydmVyDQo+ID4gPiByZWplY3RzDQo+ID4gPiA+ ID4gMC0NCj4gPiA+ID4gPiA+ID4gUlRUDQo+ID4gPiA+ID4gPiA+ID4gPiBhbmQNCj4gPiA+ID4g PiA+ID4gPiA+ID4gZmFsbHMgYmFjayB0byAxLVJUVC4iICBTbyB3ZSBlaXRoZXIgbmVlZCB0byBz YXkgd2hpY2gNCj4gPiA+ID4gPiA+ID4gPiA+ID4gY2xpZW50DQo+ID4gPiA+ID4gcmVxdWVzdHMN Cj4gPiA+ID4gPiA+ID4gYXJlDQo+ID4gPiA+ID4gPiA+ID4gPiAwLVJUVA0KPiA+ID4gPiA+ID4g PiA+ID4gPiBzYWZlIChhbmQgd2h5KSBvciBkZWZlciB0aGF0IHByb2ZpbGUgdG8gYW5vdGhlciBk b2N1bWVudC4NCj4gPiA+IGRyYWZ0LQ0KPiA+ID4gPiA+ID4gaWV0Zi0NCj4gPiA+ID4gPiA+ID4g PiA+IGRuc29wLQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiBzZXNzaW9uLXNpZ25hbCBpcyBwZXJoYXBz IGFuIGV4YW1wbGUgb2YgYSBkb2N1bWVudA0KPiA+ID4gPiA+ID4gPiA+ID4gPiB0aGF0DQo+ID4g PiBzcGVjaWZpZXMNCj4gPiA+ID4gPiA+IHdoaWNoDQo+ID4gPiA+ID4gPiA+ID4gPiA+IG1lc3Nh Z2VzIGFyZS9hcmVuJ3QgYWxsb3dlZCBpbiBlYXJseSBkYXRhLg0KPiA+ID4gPiA+ID4gPiA+ID4g PiAoZHJhZnQtaWV0Zi1hY21lLWFjbWUgaXMgYW5vdGhlciwgYnV0IGFuIHVuaW50ZXJlc3RpbmcN Cj4gPiA+ID4gPiA+ID4gPiA+ID4gb25lLA0KPiA+ID4gc2luY2UNCj4gPiA+ID4gPiA+IHRoZXkN Cj4gPiA+ID4gPiA+ID4gbWFrZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiBldmVyeSByZXF1ZXN0IGlu Y2x1ZGUgYSBzaW5nbGUtdXNlIG5vbmNlLCBhbmQgYWxsDQo+ID4gPiA+ID4gPiA+ID4gPiA+IG1l c3NhZ2VzIGFyZQ0KPiA+ID4gMC0NCj4gPiA+ID4gPiBSVFQNCj4gPiA+ID4gPiA+ID4gc2FmZS4p DQo+ID4gPiA+ID4gPiA+ID4gPiA+IE91ciB1c2Ugb2YgaW5jcmVhc2luZyAnbWlkJyB2YWx1ZXMg bWF5IGhlbHAgaGVyZSwgaW4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gdGVybXMgb2YNCj4gPiA+ID4g PiA+IGFsbG93aW5nDQo+ID4gPiA+ID4gPiA+ID4gPiBERUxFVEVzDQo+ID4gPiA+ID4gPiA+ID4g PiA+IHRvIGJlIHNhZmUsIGJ1dCBJJ2QgaGF2ZSB0byB0aGluayBhIGxpdHRsZSBtb3JlIHRvIGJl DQo+ID4gPiA+ID4gPiA+ID4gPiA+IHN1cmUgdGhhdA0KPiA+ID4gPiA+ID4gPiByZXF1ZXN0aW5n DQo+ID4gPiA+ID4gPiA+ID4gPiA+IG1pdGlnYXRpb24gd291bGQgYmUgc2FmZS4gIChPbiBmaXJz dCBnbGFuY2UgdGhlDQo+ID4gPiA+ID4gPiA+ID4gPiA+IHNlc3Npb24tDQo+ID4gPiBtYW5hZ2Vt bmV0DQo+ID4gPiA+ID4gPiBiaXRzDQo+ID4gPiA+ID4gPiA+ID4gPiB3b3VsZA0KPiA+ID4gPiA+ ID4gPiA+ID4gPiBub3QgYmUgc2FmZSwgYnV0IEkgbWF5IGJlIG1pc3Npbmcgc29tZXRoaW5nLikN Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBUaGUgZHJhZnQgb25seSB1c2Vz IGlkZW1wb3RlbnQgcmVxdWVzdHMgKEdFVCwgUFVUIGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4gREVM RVRFKSwNCj4gPiA+IGFuZA0KPiA+ID4gPiA+IENvQVANCj4gPiA+ID4gPiA+ID4gaXMNCj4gPiA+ ID4gPiA+ID4gPiA+IGNhcGFibGUgb2YgZGV0ZWN0aW5nIG1lc3NhZ2UgZHVwbGljYXRpb24gKHNl ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIj c2VjdGlvbi00LjUpIGZvcg0KPiA+ID4gPiA+ID4gPiA+ID4gYm90aA0KPiA+ID4gY29uZmlybWFi bGUNCj4gPiA+ID4gPiA+IGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4gbm9uLWNvbmZpcm1hYmxlIG1l c3NhZ2VzLg0KPiA+ID4gPiA+ID4gPiA+ID4gIFsxXSBBbiBhdHRhY2tlciByZXBsYXlpbmcgREVM RVRFIHdpbGwgbm90IGhhdmUgYW55DQo+ID4gPiA+ID4gPiA+ID4gPiBhZHZlcnNlDQo+ID4gPiBp bXBhY3QsDQo+ID4gPiA+ID4gPiAyLjAyDQo+ID4gPiA+ID4gPiA+ID4gPiAoRGVsZXRlZCkgUmVz cG9uc2UgQ29kZSBpcyByZXR1cm5lZCBldmVuIGlmIHRoZQ0KPiA+ID4gPiA+ID4gPiA+ID4gbWl0 aWdhdGlvbg0KPiA+ID4gcmVxdWVzdA0KPiA+ID4gPiA+IGRvZXMNCj4gPiA+ID4gPiA+ID4gbm90 DQo+ID4gPiA+ID4gPiA+ID4gPiBleGlzdC4NCj4gPiA+ID4gPiA+ID4gPiA+IFsyXSBUaGUgdGVj aG5pcXVlcyBkaXNjdXNzZWQgaW4gU2VjdGlvbiA4IG9mIFJGQzg0NDYNCj4gPiA+ID4gPiA+ID4g PiA+IHNob3VsZA0KPiA+ID4gc3VmZmljZQ0KPiA+ID4gPiA+IHRvDQo+ID4gPiA+ID4gPiA+IGhh bmRsZQ0KPiA+ID4gPiA+ID4gPiA+ID4gYW50aS1yZXBsYXkgKGUuZy4gYW4gYXR0YWNrZXIgcmVw bGF5aW5nIGEgMC1SVFQgZGF0YQ0KPiA+ID4gPiA+ID4gPiA+ID4gY2FycnlpbmcgYW4NCj4gPiA+ IG9sZA0KPiA+ID4gPiA+ID4gPiA+ID4gbWl0aWdhdGlvbiByZXF1ZXN0IHJlcGxhY2VkIGJ5IGEg bmV3IG1pdGlnYXRpb24gc2NvcGUpLg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+IFtNZWRdIEZXSVcsIHdlIGRvIGFscmVhZHkgaGF2ZSB0aGlzIHRl eHQgaW4gdGhlIGRyYWZ0Og0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gICAgICAg U2VjdGlvbiA4IG9mIFtSRkM4NDQ2XSBkaXNjdXNzZXMgc29tZSBtZWNoYW5pc21zIHRvDQo+ID4g PiA+ID4gPiA+ID4gaW1wbGVtZW50DQo+ID4gPiB0bw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIGxp bWl0IHRoZSBpbXBhY3Qgb2YgcmVwbGF5IGF0dGFja3Mgb24gMC1SVFQgZGF0YS4NCj4gPiA+ID4g PiA+ID4gPiBJZiB0aGUNCj4gPiA+IERPVFMNCj4gPiA+ID4gPiA+ID4gPiAgICAgICBzZXJ2ZXIg YWNjZXB0cyAwLVJUVCwgaXQgTVVTVCBpbXBsZW1lbnQgb25lIG9mIHRoZXNlDQo+ID4gPiBtZWNo YW5pc21zDQo= From nobody Mon Feb 18 23:59:36 2019 Return-Path: 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 DDC5C1276D0; Mon, 18 Feb 2019 23:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uorRSfuieo4d; Mon, 18 Feb 2019 23:59:32 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD41124B0C; Mon, 18 Feb 2019 23:59:31 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 443Y6V2Dsbz8tPg; Tue, 19 Feb 2019 08:59:30 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 443Y6V1Bkcz3wbH; Tue, 19 Feb 2019 08:59:30 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0435.000; Tue, 19 Feb 2019 08:59:30 +0100 From: To: Benjamin Kaduk CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUx6ZJ1F7LXcjiyEyakQdm0IXWmKXmq4XA Date: Tue, 19 Feb 2019 07:59:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> In-Reply-To: <20190218162322.GI24387@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 07:59:35 -0000 Hi Ben,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: lundi 18 f=E9vrier 2019 17:23 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org= ; > dots@ietf.org > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-iet= f- > dots-signal-channel) >=20 > On Fri, Feb 15, 2019 at 03:36:05PM +0000, mohamed.boucadair@orange.com wr= ote: > > Re-, > > > > Looking forward to discuss this further. > > > > I wonder whether you can consider putting the document in the IETF LC f= or > now. If it happen that we need to modify the 0-RTT text, we will handle i= t as > other IETF LC comments. >=20 > I would normally be pretty amenable to starting IETF LC and continuing > discussion; it's just for this issue in particular that I seem to be the > main person on the IESG that enforces the "application profile for 0-RTT > data" requirement, so it would feel rather odd to go forward in this case= . [Med] Fair enough.=20 > Luckily, I spent some time this weekend reading RFC 7252 and have some > substantive comments. >=20 > The key oberservation here seems to be that the Message ID is scoped per > endpoint, and replays can come from arbitrary addresses. >=20 > Specifically, we recall that: >=20 > The DOTS signal channel is layered on existing standards (Figure 3). >=20 > +---------------------+ > | DOTS Signal Channel | > +---------------------+ > | CoAP | > +----------+----------+ > | TLS | DTLS | > +----------+----------+ > | TCP | UDP | > +----------+----------+ > | IP | > +---------------------+ >=20 > We note that CoAP is using the IP address or "DTLS session" (arguably a > poorly chosen term) to identify a CoAP association and that Message IDs a= re > only used within the scope of such an association, it seems pretty clear > that an attacker able to replay TLS 1.3 0-RTT data will slice off the top > three lines of this figure and swap out the TCP/UDP/IP layers. In the > absence of DTLS connection IDs, my understanding is that the "DTLS sessio= n" > is identified solely by the transport connection, just as for coap-not-s, > so by spoofing the source address, the attacker causes the replayed 0-RTT > data (and thus, CoAP request) to be interpreted as a new incoming coaps > connection. >=20 > Given that Message ID is only 16 bits and the servers accepting 0-RTT dat= a > have potential to be quite busy, it does not seem workable to attempt to > use the incoming Message IDs as globally unique replay defense, as the ri= sk > of collision would be pretty large. [Med] The replay detection relies on both Message ID and Token. >=20 > So I think that the 'mid' monotonicity and the rejection of conflicting > request scopes are the main mitigating factors against replay in the > current design (alongside the RFC 8446 mechanisms, of course), and the te= xt > should be adjusted to reflect that. [Med] We do already have the following in the draft: The DOTS server(s) can use Message ID and Token in the DOTS signal channel message to detect replay of early data, and accept 0-RTT data at most once. Furthermore, 'mid' ^^^^^^^^^^^^^^^^^^ value is monotonically increased by the DOTS client for each mitigation request, attackers replaying mitigation requests with lower numeric 'mid' values and overlapping scopes with mitigation requests having higher numeric 'mid' values will be rejected systematically by the DOTS server. >=20 > It seems that the 'mid' ordering is probably enough to protect > reordering/replay of mitigiation request and withdraw, even when reordere= d > across other mitigation actions. But I am more concerned about > reordering/replay of other messages, like efficacy updates and session > configuration changes. [Med] For the configuration changes, I don't expect the exchange to happen = during an attack. The part of the text we are discussing is about mitigatio= n requests.=20 o 0-RTT mode in which the DOTS client can authenticate itself and send DOTS mitigation request messages in the first message, thus ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ reducing handshake latency. Putting that aside, we do have the following:=20 The PUT request with a higher numeric 'sid' value overrides the DOTS signal channel session configuration data installed by a PUT request with a lower numeric 'sid' value. To avoid maintaining a long list of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be automatically deleted and no longer available at the DOTS server. Any replayed configuration change request will be discarded owing to the 's= id' checks.=20 >=20 > Consider >=20 > client attacker server > | > |----efficacy: attack mitigated--------------------->| > | | > |----efficacy: under attack------------------------->| > | | > | |-replay: attack mitigated->| >=20 > Is the server going to end up with the expected state? [Med] A general comment: The dots server uses the information conveyed in t= he efficacy update as a hint; it may but it is not required to rely on thos= e requests to adjust its mitigation actions.=20 If the two first status messages are bound to distinct "mids" and adjusted = scopes, the replayed request will be discarded by the server thanks to the = presence of If-Match option. The server does not maintain the request with = the old mid. =20 If, for some reason, the same mid is used and this flow is observed, the se= rver will detect that the same Message ID and Token are reused again and th= en reject. =20 >=20 > -Ben >=20 >=20 > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoy=E9=A0: vendredi 15 f=E9vrier 2019 16:05 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf= .org; > > > dots@ietf.org > > > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft= -ietf- > > > dots-signal-channel) > > > > > > Hi Med, > > > > > > Short form: I need to think about it harder. There's some indication > that > > > the CoAp Message ID is at the wrong level to protect the 0-RTT data, = but > > > I'm not sure yet. > > > > > > Sorry for the delays; this has been a frenetic couple weeks :( > > > > > > -Ben > > > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000, mohamed.boucadair@orange.co= m > wrote: > > > > Hi Ben, > > > > > > > > What is the status for this one? Are we OK to move forward? > > > > > > > > Thank you. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > > > > > Envoy=E9=A0: mardi 29 janvier 2019 14:32 > > > > > =C0=A0: Benjamin Kaduk > > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > channel@ietf.org; > > > > > dots@ietf.org > > > > > Objet=A0: Using Early Data in DOTS (RE: [Dots] AD review of draft= -ietf- > > > dots- > > > > > signal-channel) > > > > > > > > > > Hi Ben, all, > > > > > > > > > > We edited a short draft (https://tools.ietf.org/html/draft-boucad= air- > > > dots- > > > > > earlydata-00) to motivate the following text included in the sign= al > > > channel > > > > > draft: > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to impleme= nt > to > > > > > limit the impact of replay attacks on 0-RTT data. If the D= OTS > > > > > server accepts 0-RTT, it MUST implement one of these > mechanisms. > > > > > A DOTS server can reject 0-RTT by sending a TLS > HelloRetryRequest. > > > > > The DOTS signal channel messages sent as early data by the = DOTS > > > > > client are idempotent requests. As a reminder, Message ID > > > > > (Section 3 of [RFC7252]) is changed each time a new CoAP > request > > > > > is sent, and the Token (Section 5.3.1 of [RFC7252]) is > randomized > > > > > in each CoAP request. The DOTS server(s) can use Message I= D > and > > > > > Token in the DOTS signal channel message to detect replay o= f > early > > > > > data, and accept 0-RTT data at most once. Furthermore, 'mi= d' > > > > > value is monotonically increased by the DOTS client for eac= h > > > > > mitigation request, attackers replaying mitigation requests > with > > > > > lower numeric 'mid' values and overlapping scopes with > mitigation > > > > > requests having higher numeric 'mid' values will be rejecte= d > > > > > systematically by the DOTS server. > > > > > > > > > > Owing to the aforementioned protections, especially those > afforded > > > > > by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 84= 46 > > > > > anti-replay mechanisms, all DOTS signal channel requests ar= e > safe > > > > > to transmit in TLS 1.3 as early data. Refer to > > > > > [I-D.boucadair-dots-earlydata] for more details. > > > > > > > > > > This text and also the Designated Expert guidelines are implement= ed > in - > > > 28. > > > > > These are the two pending issues from your AD review. > > > > > > > > > > Other edits were also made to record what was agreed on the list. > > > > > > > > > > We hope this version is now ready to move forward. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes tha= t > > > > > "Application > > > > > > > > > > protocols MUST NOT use 0-RTT data without a profile tha= t > > > defines > > > > > its > > > > > > > use. > > > > > > > > > > That profile needs to identify which messages or > interactions > > > are > > > > > > safe > > > > > > > to > > > > > > > > > use > > > > > > > > > > with 0-RTT and how to handle the situation when the ser= ver > > > rejects > > > > > 0- > > > > > > > RTT > > > > > > > > > and > > > > > > > > > > falls back to 1-RTT." So we either need to say which > client > > > > > requests > > > > > > > are > > > > > > > > > 0-RTT > > > > > > > > > > safe (and why) or defer that profile to another documen= t. > > > draft- > > > > > > ietf- > > > > > > > > > dnsop- > > > > > > > > > > session-signal is perhaps an example of a document that > > > specifies > > > > > > which > > > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > > > (draft-ietf-acme-acme is another, but an uninteresting = one, > > > since > > > > > > they > > > > > > > make > > > > > > > > > > every request include a single-use nonce, and all messa= ges > are > > > 0- > > > > > RTT > > > > > > > safe.) > > > > > > > > > > Our use of increasing 'mid' values may help here, in te= rms > of > > > > > > allowing > > > > > > > > > DELETEs > > > > > > > > > > to be safe, but I'd have to think a little more to be s= ure > that > > > > > > > requesting > > > > > > > > > > mitigation would be safe. (On first glance the session= - > > > managemnet > > > > > > bits > > > > > > > > > would > > > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and > DELETE), > > > and > > > > > CoAP > > > > > > > is > > > > > > > > > capable of detecting message duplication (see > > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both > > > confirmable > > > > > > and > > > > > > > > > non-confirmable messages. > > > > > > > > > [1] An attacker replaying DELETE will not have any adver= se > > > impact, > > > > > > 2.02 > > > > > > > > > (Deleted) Response Code is returned even if the mitigatio= n > > > request > > > > > does > > > > > > > not > > > > > > > > > exist. > > > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 shou= ld > > > suffice > > > > > to > > > > > > > handle > > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carr= ying > an > > > old > > > > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to > implement > > > to > > > > > > > > limit the impact of replay attacks on 0-RTT data. If= the > > > DOTS > > > > > > > > server accepts 0-RTT, it MUST implement one of these > > > mechanisms From nobody Mon Feb 18 23:59:45 2019 Return-Path: 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 07EEF130EC1 for ; Mon, 18 Feb 2019 23:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nttv6.jp 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 m0NCF4BA0ity for ; Mon, 18 Feb 2019 23:59:37 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id AA53A1276D0 for ; Mon, 18 Feb 2019 23:59:36 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 1187525F6B8; Tue, 19 Feb 2019 16:59:35 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1550563175; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Axy7x2woMDcDHpXfwlogemwziGRPXGruq+s+GvBUxYs=; b=EDt85hNGDVFHqSVKzz/sLurrPHkOyBZW6h2iftBKNMn7n8UswoF4JWt+r4pWBXUHcYorRN NbMvmkKQxPZIQmA2w+tVfQYDYe1deFLZD9IBReFZn0eupAhx2JcONrhVFHlRookc4MKC1J T1BNpSaRcbh8WiC7+/7hOC6GXr5Hm40= Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id E0ED876351B; Tue, 19 Feb 2019 16:59:34 +0900 (JST) To: mohamed.boucadair@orange.com, "Benjamin Kaduk (kaduk@mit.edu)" , "dots@ietf.org" References: <155049459642.5615.1531443959140669891@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA20FD1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <0423e4f1-41be-a924-3c51-3d20977b7eae@nttv6.jp> Date: Tue, 19 Feb 2019 16:59:37 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA20FD1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-26.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 07:59:43 -0000 Hi, The revised text is more precise. Thanks for your careful work. I'll check if our implementation is compatible with the specified types and behavior. thanks, Kaname On 2019/02/18 22:06, mohamed.boucadair@orange.com wrote: > Hi Ben, all, > > This version addresses the comments from the AD review. > > A diff to track the changes is available at: > https://www.ietf.org/rfcdiff?url1=draft-ietf-dots-data-channel-25&url2=draft-ietf-dots-data-channel-26&difftype=--hwdiff > > Cheers, > Med > >> -----Message d'origine----- >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >> internet-drafts@ietf.org >> Envoyé : lundi 18 février 2019 13:57 >> À : i-d-announce@ietf.org >> Cc : dots@ietf.org >> Objet : I-D Action: draft-ietf-dots-data-channel-26.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. >> >> Title : Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Data Channel Specification >> Authors : Mohamed Boucadair >> Tirumaleswar Reddy >> Filename : draft-ietf-dots-data-channel-26.txt >> Pages : 70 >> Date : 2019-02-18 >> >> Abstract: >> The document specifies a Distributed Denial-of-Service Open Threat >> Signaling (DOTS) data channel used for bulk exchange of data that >> cannot easily or appropriately communicated through the DOTS signal >> channel under attack conditions. >> >> This is a companion document to the DOTS signal channel >> specification. >> >> Editorial Note (To be removed by RFC Editor) >> >> Please update these statements within the document with the RFC >> number to be assigned to this document: >> >> o "This version of this YANG module is part of RFC XXXX;" >> >> o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Data Channel Specification"; >> >> o reference: RFC XXXX >> >> Please update the "revision" date of the YANG module. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dots-data-channel-26 >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-26 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-26 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Feb 19 00:12:14 2019 Return-Path: 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 4AD5E124B0C for ; Tue, 19 Feb 2019 00:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 haHF6Aswj0nn for ; Tue, 19 Feb 2019 00:12:06 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F67D130E77 for ; Tue, 19 Feb 2019 00:12:06 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 443YP050tcz4wxJ; Tue, 19 Feb 2019 09:12:04 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 443YP04HgJzDq82; Tue, 19 Feb 2019 09:12:04 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([fe80::8899:bbc3:9726:cd5e%22]) with mapi id 14.03.0435.000; Tue, 19 Feb 2019 09:12:04 +0100 From: To: kaname nishizuka , "Benjamin Kaduk (kaduk@mit.edu)" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-26.txt Thread-Index: AQHUyCkQ29sbJMsplkyd3xdE3asfnaXmxBNQ Date: Tue, 19 Feb 2019 08:12:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA21AFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155049459642.5615.1531443959140669891@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA20FD1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0423e4f1-41be-a924-3c51-3d20977b7eae@nttv6.jp> In-Reply-To: <0423e4f1-41be-a924-3c51-3d20977b7eae@nttv6.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-26.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 08:12:13 -0000 SGkgS2FuYW1lLA0KDQpGV0lXLCB0aGUgbWFpbiBjaGFuZ2VzIGFyZSB0aGUgZm9sbG93aW5nOiAN Cg0KKiB1c2UgZXJyb3ItYXBwLXRhZyBpbnN0ZWFkIG9mIGRlZmluaW5nIGEgbmV3IGVycm9yLXRh Zy4NCiogZGVzY3JpYmUgdGhlIGJlaGF2aW9yIHdoZW4gbXVsdGlwbGUgdGFyZ2V0LSogc2NvcGUg dHlwZXMgYXJlIGluY2x1ZGVkIGluIHRoZSBzYW1lIHJlcXVlc3QuIA0KDQpUaGUgc3RydWN0dXJl IG9mIHRoZSBZQU5HIG1vZHVsZSBpcyB0aGUgc2FtZTsgb25seSBzb21lIHJlb3JkZXJpbmcgb2Yg c29tZSBub2Rlcy4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiBrYW5hbWUgbmlzaGl6dWthIFttYWlsdG86a2FuYW1lQG50dHY2LmpwXQ0K PiBFbnZvecOpwqA6IG1hcmRpIDE5IGbDqXZyaWVyIDIwMTkgMDk6MDANCj4gw4DCoDogQk9VQ0FE QUlSIE1vaGFtZWQgVEdJL09MTjsgQmVuamFtaW4gS2FkdWsgKGthZHVrQG1pdC5lZHUpOyBkb3Rz QGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1k b3RzLWRhdGEtY2hhbm5lbC0yNi50eHQNCj4gDQo+IEhpLA0KPiANCj4gVGhlIHJldmlzZWQgdGV4 dCBpcyBtb3JlIHByZWNpc2UuIFRoYW5rcyBmb3IgeW91ciBjYXJlZnVsIHdvcmsuDQo+IEknbGwg Y2hlY2sgaWYgb3VyIGltcGxlbWVudGF0aW9uIGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgc3BlY2lm aWVkIHR5cGVzIGFuZA0KPiBiZWhhdmlvci4NCj4gDQo+IHRoYW5rcywNCj4gS2FuYW1lDQo+IA0K PiANCj4gT24gMjAxOS8wMi8xOCAyMjowNiwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3 cm90ZToNCj4gPiBIaSBCZW4sIGFsbCwNCj4gPg0KPiA+IFRoaXMgdmVyc2lvbiBhZGRyZXNzZXMg dGhlIGNvbW1lbnRzIGZyb20gdGhlIEFEIHJldmlldy4NCj4gPg0KPiA+IEEgZGlmZiB0byB0cmFj ayB0aGUgY2hhbmdlcyBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtDQo+IDI1JnVybDI9ZHJh ZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0yNiZkaWZmdHlwZT0tLWh3ZGlmZg0KPiA+DQo+ID4g Q2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiA+PiBEZcKgOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGEgcGFydCBkZQ0KPiA+PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPj4g RW52b3nDqcKgOiBsdW5kaSAxOCBmw6l2cmllciAyMDE5IDEzOjU3DQo+ID4+IMOAwqA6IGktZC1h bm5vdW5jZUBpZXRmLm9yZw0KPiA+PiBDY8KgOiBkb3RzQGlldGYub3JnDQo+ID4+IE9iamV0wqA6 IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjYudHh0DQo+ID4+DQo+ ID4+DQo+ID4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cw0KPiA+PiBkaXJlY3Rvcmllcy4NCj4gPj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cgb2YgdGhl DQo+IElFVEYuDQo+ID4+DQo+ID4+ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IERpc3RyaWJ1 dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0DQo+IFNpZ25hbGluZw0KPiA+PiAoRE9U UykgRGF0YSBDaGFubmVsIFNwZWNpZmljYXRpb24NCj4gPj4gICAgICAgICAgQXV0aG9ycyAgICAg ICAgIDogTW9oYW1lZCBCb3VjYWRhaXINCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg VGlydW1hbGVzd2FyIFJlZGR5DQo+ID4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRv dHMtZGF0YS1jaGFubmVsLTI2LnR4dA0KPiA+PiAJUGFnZXMgICAgICAgICAgIDogNzANCj4gPj4g CURhdGUgICAgICAgICAgICA6IDIwMTktMDItMTgNCj4gPj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ ICAgICBUaGUgZG9jdW1lbnQgc3BlY2lmaWVzIGEgRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZp Y2UgT3BlbiBUaHJlYXQNCj4gPj4gICAgIFNpZ25hbGluZyAoRE9UUykgZGF0YSBjaGFubmVsIHVz ZWQgZm9yIGJ1bGsgZXhjaGFuZ2Ugb2YgZGF0YSB0aGF0DQo+ID4+ICAgICBjYW5ub3QgZWFzaWx5 IG9yIGFwcHJvcHJpYXRlbHkgY29tbXVuaWNhdGVkIHRocm91Z2ggdGhlIERPVFMgc2lnbmFsDQo+ ID4+ICAgICBjaGFubmVsIHVuZGVyIGF0dGFjayBjb25kaXRpb25zLg0KPiA+Pg0KPiA+PiAgICAg VGhpcyBpcyBhIGNvbXBhbmlvbiBkb2N1bWVudCB0byB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbA0K PiA+PiAgICAgc3BlY2lmaWNhdGlvbi4NCj4gPj4NCj4gPj4gRWRpdG9yaWFsIE5vdGUgKFRvIGJl IHJlbW92ZWQgYnkgUkZDIEVkaXRvcikNCj4gPj4NCj4gPj4gICAgIFBsZWFzZSB1cGRhdGUgdGhl c2Ugc3RhdGVtZW50cyB3aXRoaW4gdGhlIGRvY3VtZW50IHdpdGggdGhlIFJGQw0KPiA+PiAgICAg bnVtYmVyIHRvIGJlIGFzc2lnbmVkIHRvIHRoaXMgZG9jdW1lbnQ6DQo+ID4+DQo+ID4+ICAgICBv ICAiVGhpcyB2ZXJzaW9uIG9mIHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWDsi DQo+ID4+DQo+ID4+ICAgICBvICAiUkZDIFhYWFg6IERpc3RyaWJ1dGVkIERlbmlhbC1vZi1TZXJ2 aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZw0KPiA+PiAgICAgICAgKERPVFMpIERhdGEgQ2hhbm5l bCBTcGVjaWZpY2F0aW9uIjsNCj4gPj4NCj4gPj4gICAgIG8gIHJlZmVyZW5jZTogUkZDIFhYWFgN Cj4gPj4NCj4gPj4gICAgIFBsZWFzZSB1cGRhdGUgdGhlICJyZXZpc2lvbiIgZGF0ZSBvZiB0aGUg WUFORyBtb2R1bGUuDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLw0KPiA+Pg0KPiA+PiBUaGVyZSBh cmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI2DQo+ID4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWRhdGEt Y2hhbm5lbC0yNg0KPiA+Pg0KPiA+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI2DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m DQo+IHN1Ym1pc3Npb24NCj4gPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBJLUQtQW5ub3VuY2UgbWFpbGlu ZyBsaXN0DQo+ID4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiA+PiBJbnRlcm5ldC1EcmFmdCBk aXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPiA+PiBvciBmdHA6 Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzDQoNCg== From nobody Tue Feb 19 01:01:58 2019 Return-Path: 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 430C4130E9D for ; Tue, 19 Feb 2019 01:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nttv6.jp 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 PVatyVjoXe-L for ; Tue, 19 Feb 2019 01:01:46 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAC3130EDD for ; Tue, 19 Feb 2019 01:01:36 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 9703325F6B8; Tue, 19 Feb 2019 18:01:34 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1550566894; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TxAd3XfQXhVAWC+5e58RUoskBn9SheG9KE1wu5Gj044=; b=gf7TgC7PMlqS0/bjkjrgrVNqeNkSRqxSBs4jrHCt08YnK06sme0uj0dwhRbcie8KwslwH5 Oz5MPe/S0baMh+SElZlu5rwsDaKsFY4Rr8c97sOYcmo/ZIzmAPvXLOmO5S4NtaYySmjdCx Im5tgK6QNA+9Az9y77h6CX0uCneBPp4= Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 73BE376350E; Tue, 19 Feb 2019 18:01:34 +0900 (JST) To: mohamed.boucadair@orange.com, "Benjamin Kaduk (kaduk@mit.edu)" , "dots@ietf.org" References: <155049459642.5615.1531443959140669891@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA20FD1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0423e4f1-41be-a924-3c51-3d20977b7eae@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302EA21AFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: Date: Tue, 19 Feb 2019 18:01:36 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA21AFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-26.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 09:01:56 -0000 Hi Med, Thanks for the summary. I'll check it. regards, Kaname On 2019/02/19 17:12, mohamed.boucadair@orange.com wrote: > Hi Kaname, > > FWIW, the main changes are the following: > > * use error-app-tag instead of defining a new error-tag. > * describe the behavior when multiple target-* scope types are included in the same request. > > The structure of the YANG module is the same; only some reordering of some nodes. > > Cheers, > Med > >> -----Message d'origine----- >> De : kaname nishizuka [mailto:kaname@nttv6.jp] >> Envoyé : mardi 19 février 2019 09:00 >> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk (kaduk@mit.edu); dots@ietf.org >> Objet : Re: [Dots] I-D Action: draft-ietf-dots-data-channel-26.txt >> >> Hi, >> >> The revised text is more precise. Thanks for your careful work. >> I'll check if our implementation is compatible with the specified types and >> behavior. >> >> thanks, >> Kaname >> >> >> On 2019/02/18 22:06, mohamed.boucadair@orange.com wrote: >>> Hi Ben, all, >>> >>> This version addresses the comments from the AD review. >>> >>> A diff to track the changes is available at: >>> https://www.ietf.org/rfcdiff?url1=draft-ietf-dots-data-channel- >> 25&url2=draft-ietf-dots-data-channel-26&difftype=--hwdiff >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >>>> internet-drafts@ietf.org >>>> Envoyé : lundi 18 février 2019 13:57 >>>> À : i-d-announce@ietf.org >>>> Cc : dots@ietf.org >>>> Objet : I-D Action: draft-ietf-dots-data-channel-26.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the DDoS Open Threat Signaling WG of the >> IETF. >>>> Title : Distributed Denial-of-Service Open Threat >> Signaling >>>> (DOTS) Data Channel Specification >>>> Authors : Mohamed Boucadair >>>> Tirumaleswar Reddy >>>> Filename : draft-ietf-dots-data-channel-26.txt >>>> Pages : 70 >>>> Date : 2019-02-18 >>>> >>>> Abstract: >>>> The document specifies a Distributed Denial-of-Service Open Threat >>>> Signaling (DOTS) data channel used for bulk exchange of data that >>>> cannot easily or appropriately communicated through the DOTS signal >>>> channel under attack conditions. >>>> >>>> This is a companion document to the DOTS signal channel >>>> specification. >>>> >>>> Editorial Note (To be removed by RFC Editor) >>>> >>>> Please update these statements within the document with the RFC >>>> number to be assigned to this document: >>>> >>>> o "This version of this YANG module is part of RFC XXXX;" >>>> >>>> o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling >>>> (DOTS) Data Channel Specification"; >>>> >>>> o reference: RFC XXXX >>>> >>>> Please update the "revision" date of the YANG module. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-dots-data-channel-26 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-26 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-26 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 20 07:58:58 2019 Return-Path: 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 E2B3A1295EC; Wed, 20 Feb 2019 07:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 O2rYnTdkd0OH; Wed, 20 Feb 2019 07:58:53 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780114.outbound.protection.outlook.com [40.107.78.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B763127AC2; Wed, 20 Feb 2019 07:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=anIZp5FnARfH9OCBcNH5JUnvglEBOvFX/HLmPHCc5i0=; b=pSyZ81Dy3OUI50duFzCYyXGIF/LrBv41l2mZFOi2rV/7m8NA2thFB1p0XrW+etVA4HkWlyuTxuvqMoba7JKWUlDnlkBgv6+TpWodQ4FCLNSQA0cbqM6MmpS5eRjlX3ruWISds8/nhtJpLAGXgw6pGqx4lhkg4atgL5NV1coLRO4= Received: from SN2PR01CA0075.prod.exchangelabs.com (2603:10b6:800::43) by DM6PR01MB3995.prod.exchangelabs.com (2603:10b6:5:92::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Wed, 20 Feb 2019 15:58:52 +0000 Received: from DM3NAM03FT027.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::201) by SN2PR01CA0075.outlook.office365.com (2603:10b6:800::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.19 via Frontend Transport; Wed, 20 Feb 2019 15:58:51 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT027.mail.protection.outlook.com (10.152.82.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 20 Feb 2019 15:58:51 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1KFwmbx025160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 10:58:50 -0500 Date: Wed, 20 Feb 2019 09:58:48 -0600 From: Benjamin Kaduk To: CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190220155847.GC69562@kduck.mit.edu> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190214191707.GM56447@kduck.mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(376002)(39860400002)(2980300002)(199004)(189003)(55784004)(51914003)(7696005)(5660300002)(104016004)(76176011)(50466002)(66574012)(1076003)(54906003)(23756003)(58126008)(36906005)(186003)(106002)(786003)(86362001)(305945005)(26005)(4326008)(316002)(336012)(106466001)(446003)(356004)(126002)(476003)(33656002)(486006)(246002)(55016002)(47776003)(88552002)(426003)(6916009)(2906002)(229853002)(53416004)(956004)(2870700001)(26826003)(75432002)(14444005)(8676002)(6246003)(2351001)(966005)(478600001)(8936002)(11346002)(6306002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB3995; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1e07c7e5-4ad0-4452-939e-08d6974c4ef5 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:DM6PR01MB3995; X-MS-TrafficTypeDiagnostic: DM6PR01MB3995: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB3995; 20:LC5SRGwnOdA10VKcce7ZjIHycS5ydt1o+R9Unr4r+1BWo7o+xIl/Mb9BO7zpx4xlJ3p77Y68N6CsvqPFxEyAx+131EveIhSSxQdRJLb8rTWXnCALJN6P4IovZZGyrxy6jq6ZAiT7aMSNKPdbQQ9W4BtEbpF/S02RbNH1CfPPjSEJjN3JdnB9Cm6cc7Q8r97w3QjsgNA8Tu6zXYny22YZ3b0oiSOBMwf8b5TZIPEDoStvVzkxL9fWUJ988/b3f9NFqHXim1P1GYMuzSs6vDEJ7mX+CpM2s+gb1aX9efZ+HfLAgjm+SjmJ9ISEXo+zcXmYsIFW4YXA/1J9c0QA3Y/pWZdsN4hz+SnbTDIvSpC9JH+4O3vg1g9WQgC3cXfYr7i9J4TBH1T2xjXODm3zQ6wHRJOM+HLTmMaC1Ot4izfrGT7U4dVis9L81HO80axioxDNhkrMX7eoTQUZUXnefQDF9npVkj9Y1IjIGoFNEkh5qs/g8SaIsBGmsJTyCib0jySobbszQ5DK/2GCibc4EVhUK6wVTezyWk4eOYsAdCArSY2z9Ra+ExE4vct83P+JUIG5eYYjEfmwaWsfa0BwN4v3AHFPRZ0mjn7Dq3/wychl/9c= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0954EE4910 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM6PR01MB3995; 23:3kt0tRwNPiCHU0o5uYXnYPRJ+EnMlf2221N8LAH?= =?iso-8859-1?Q?6IahEc1XJD48T5E9l0aEPoBSwFQ4Vew/eNgw3RBmr6b72qQlxc5FrY5kz3?= =?iso-8859-1?Q?pqYj1HV9RzerNOJDxZ/uFQ/MiWO6SbN/0cqJ+XZl2dX5fNPiwUtts8Jlcy?= =?iso-8859-1?Q?rAFE4UHDYa8h3y0JIwncNuJHN6hrvYL2/QcE92BfHko6yUhklnLerInZm/?= =?iso-8859-1?Q?kVpi+26oS4Yqqyl6B5NgKFQPN+g76RI7NiL1krtnBDnZff9FX5Bz1tPJ5d?= =?iso-8859-1?Q?otRNj15EGiTcsCwQePPkeoKqsF1qs4aOxF3GtwckT8Ohr/JnPWBLJ4ym3k?= =?iso-8859-1?Q?nGaTXLJ5ZvAqh45QlLQ0ohKD6Jq0izuATrUDzTv6M75Qf9VkHfkx7lzXtn?= =?iso-8859-1?Q?5YislDscjLWCMKpDem0me2jgrlaFBhvuil3SOnuZd1KqpzW/0hBqZWo5So?= =?iso-8859-1?Q?Sq5D1zIiYGPjcjisWi9+0aP9wQgt7D4QIB+WJaayU5CsG0WMYWh5KN9MEP?= =?iso-8859-1?Q?nDvOtuSojycnwbBUjGYFXhMUkARvXBD4iz3A2TYUqC3KQwp6XCqyKVTUdv?= =?iso-8859-1?Q?ZUoXK1lgsH97lUGa3gcspNPmuqYT/R+39HmWJvVSKBIaw+37HSK8rXjDtj?= =?iso-8859-1?Q?1nLygrtDH6LReSbCbfWmlBKvR62E4uV6h+8SzYgp4XBEgd2ZIRmu/RPshC?= =?iso-8859-1?Q?PFhiMsAzirb0X10Byh+zHoxsEeycW6fnpN0DJ20TXjUCq7P1irRG4aO8er?= =?iso-8859-1?Q?EfHC9bakFtNRp9Swz5JR7DVhmY7dMddsJVRmSS+0g7AtiZYsYdUn174bY7?= =?iso-8859-1?Q?RZPjoRf3HtBtJYRkmzeECwrEsoq0QZRZnVOC/ur81TMkU4uFdJV4reIo3u?= =?iso-8859-1?Q?J/uwzboyp46CckPtT1f7vfKikXMi9yNuiS3YiNyjhrexxLDMWi1n1vCPWV?= =?iso-8859-1?Q?WAbUEkVNQKnm9IYdL/39zF+Qe8P1dJLvN/m0F5zeUMIwnHVPTDd0PAK09E?= =?iso-8859-1?Q?C1VIxTCbm8sofokQcgubXRl0QO9PHknsvcoIYwXwEwJ5K3MYKzR8mpQ/aL?= =?iso-8859-1?Q?TuuvaQKDS5M2VwJELXARrTGow66zAKw66MSraqqov+wivqpEcdjwMwhoVF?= =?iso-8859-1?Q?givE+o07cJUC67WqZXSQLIBfJu8pn/zaK9d3OQzpm/HwQ6UYN2VxnRRxn2?= =?iso-8859-1?Q?ZvLFzHeVBw6f25JgXwremx4MV26hB1mCjGNgUryca/EX5Ps1Qh/lpPB8W9?= =?iso-8859-1?Q?0ErM/peA7vFeOVl5p7eWAIoMFrZ0/GsZs3deHbaU1hnS9XMf8XRK3C+RmY?= =?iso-8859-1?Q?FHoZyBN3X3bj797E7Mx+na+I465E4YqENqZ0OJJzN97IeT55bFpmRoeC7h?= =?iso-8859-1?Q?CwY16V8Y=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: PZ7GqGd7MHleDC00CFSDnoq92BTB24M9XuadnJu69UtCik8O903lztrMKTW2O7YcvtpZDoe2x3CJYIwyd3itZMsNS9q5y7qphqrx+xfR3Yd5GYepHlzqLLWImWWM0e6SEGZ+MmlZkd0ZuDDq8mP8iYbSOK0mzR9I9KOuIph4nbIfLPtQhlhspcO+rlxbXCJ6oOamkKhA5+nxaRyhBZ3aVInmrKqW1XTz8gIASFsZDJKZkHK5zSGo418qhkN5E8L3NGpPxOJ87KJFgfttrsc3Pq4rSYtEXHvLEIeMIcd7X7zmK0zDFwA2HFV7oEXwU86gRGt/mmScGIOnjrinvjlGOtLYNUEBtQ9Dwlo+aStpryMlpNzyu+YsGHNxfO9ZfFLte138Y5A5qhYbF55K9AEwr7liN0P8ojjUCkej4WLQ4uI= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2019 15:58:51.4256 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1e07c7e5-4ad0-4452-939e-08d6974c4ef5 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB3995 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:58:56 -0000 On Thu, Feb 14, 2019 at 01:17:07PM -0600, Benjamin Kaduk wrote: > > On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.com wrote: > > > > > -----Message d'origine----- > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoyé : mercredi 13 février 2019 17:46 > > > À : draft-ietf-dots-data-channel@ietf.org > > > Cc : dots@ietf.org > > > Objet : AD review of draft-ietf-dots-data-channel-25 > > > > > > > > > Section 3.5 > > > > > > I had to read up on RESTCONF and NETCONF while reviewing this, but from > > > what I've seen so far, the "error-severity" field is only present in > > > NETCONF and not RESTCONF. If so, then we shouldn't need to talk about it > > > here, since we use RESTCONF exclusively. I also couldn't find whether > > > there's a registry that we should add the "loop-detected" error-tag to. > > > Can anyone here help me out? > > > > > > > [Med] We used the template in https://tools.ietf.org/html/rfc6241#appendix-A because the errors in 8040 are the ones imported from there. > > Thanks for the pointer. It sounds like I'll need to ask around about this > one. Benoit and Martin confirm that "error-severity" has no purpose in RESTCONF, so I think we can safely drop this line. -Ben From nobody Wed Feb 20 09:53:58 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 854A2130E5F; Wed, 20 Feb 2019 09:53:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-dots-requirements@ietf.org, Liang Xia , dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2019 09:53:48 -0800 Archived-At: Subject: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 17:53:49 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dots-requirements-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for addressing the TSV-ART comments (and thanks Joe for the review)! In-line with Joe's comment, please see some additional comments below. 1) One minor edit is required still for SIG-002: for PLMTUD the correct reference is RFC4821, however, as commented by Joe RFC1191 is less reliable and therefore usually not recommended. I would recommend to re-add a reference to RFC4821 and no reference to RFC1191 (or only with a warning that RFC4821 is preferred due to ICMP blocking). Further, the correct reference for datagram PLMTUD is draft-ietf-tsvwg-datagram-plpmtud. 2) Also on this text in SIG-004: "The heartbeat interval during active mitigation could be negotiable, but MUST be frequent enough to maintain any on-path NAT or Firewall bindings during mitigation. When TCP is used as transport, the DOTS signal channel heartbeat messages need to be frequent enough to maintain the TCP connection state." As Joe commented already, different heartbeats at different layers can be used at the same time for different purposes. You can use heartbeats at the application layer to check service availability while e.g. using a higher frequent heartbeat at the transport layer to maintain firewall and NAT state. The advantage to such an approach is that there is less application layer overhead/load e.g. in scenarios where it might be expensive to wake up the application or a server is already highly loaded. Also note that the time-outs values of NATs and firewalls on the path are usually unknown, therefore an application can never rely on heartbeats (no matter at which level) and must be prepared to try to reconnect on the application layer if the connection fails. Usually, the main reason for using heartbeats to maintain NAT or firewall state (vs. reconnect every time) in TCP is if the application is time-sensitive and a full TCP handshake takes too long for the desired service. I'm not sure that the case for DOTS, however, I understand it may be beneficial to have established state if an attack is on-going. For UDP I guess it's more complicated in your case. Time-outs are usually very short, however, state is created with the first packet of a flow (as there is no handshake in UDP). As you don't see blocking if state is expired as new state is created immediately, it's kind of impossible to measure the configured time-out values. Only if the firewall is under attack it would start blocking UDP traffic that is has no state for yet. So I understand why it is desirable to maintain UDP state for you, however, I don't understand how you can know that your frequency is high enough to actually keep the state open. Note that TCP time-outs are usually in the order of hours, while UDP time-outs are usually in range of tens of seconds, and might expire even quicker if a system is under attack. If that is a scenario that is important for you, and assuming that not all time-outs values on the path can be known, I guess it would be recommendable to use TCP instead. In any case this can not be a MUST requirement (as timers are usually not known). I would recommend to state something like: "MAY be frequent enough to maintain NAT or firewall state, if timer values are known, or if TCP is used, SHOULD use in addition TCP heartbeats to maintain the TCP connection state and reconnect immediately if a failure is detected." And also for this part it is different for TCP and UDP: "Because heartbeat loss is much more likely during volumetric attack, DOTS agents SHOULD avoid signal channel termination when mitigation is active and heartbeats are not received by either DOTS agent for an extended period." If TCP would be used and no ACKs are received, TCP would try to retransmit a few times and some point terminate the connection. However, UDP is a connection-less protocol, there is nothing to terminate. Also note that for reliable transports, it is sufficient if one end-hosts sends heartbeats as the other end is required to acknowledge the reception on the transport layer (and if no ack is received the connection is terminated on the transport layer). So I guess what you want to say above is that if a connection-less protocol is used, heartbeats should continuously be sent even if no heartbeats are received from the other end. However, I think you still need to define a termination criteria, as you for sure don't want to keep sending heartbeats forever. Also the next part: " * To handle possible DOTS server restart or crash, the DOTS clients MAY attempt to establish a new signal channel session, but MUST continue to send heartbeats on the current session so that the DOTS server knows the session is still alive. If the new session is successfully established, the DOTS client can terminate the current session." There is nothing like connection re-establishing in UDP, you just keep sending traffic. While in TCP, as explained above, the connection will be terminated at the transport layer and there is no way to keep sending heartbeats on the "old" session. Or do have something like DTLS in mind in this case? 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). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One editorial comment on SEC-002: "A security mechanism at the network layer (e.g., TLS) is thus adequate to provide hop-by-hop security. In other words, end-to-end security is not required for DOTS protocols." TLS is transport layer security (not network layer) and therefore known as providing end-to-end security while the term hop-by-hop is used for e.g. IPSec. I would recommend to change the wording here in order to avoid confusion, e.g. "A security mechanism at the transport layer (e.g., TLS) is thus adequate to provide security between different DOTS agents. In other words, a direct security association between the server and client, excluding any proxy, is not required for DOTS protocols." And finally one general comment: I understand that having wg consensus for this document is import to proceed the work of the group, however, I don't see the value in archiving this document in the IETF RFC series as a stand-alone document. If the group thinks documenting these requirements for consumption outside the group's work at a later point in time is valuable, I would rather recommend to add the respective requirements to the appendix of the respective protocol specs. From nobody Wed Feb 20 19:42:02 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8B128CB7; Wed, 20 Feb 2019 19:42:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dots-requirements@ietf.org, Liang Xia , dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155072052056.20358.15761578065156106209.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2019 19:42:00 -0800 Archived-At: Subject: [Dots] Ben Campbell's No Objection on draft-ietf-dots-requirements-18: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 03:42:00 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dots-requirements-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I'm curious what the archival value this has for publishing as an RFC. Did the WG consider alternative publication methods? (e.g., leave as a draft, publish in a WG wiki) §1.2: The draft uses 2119/8174 keywords to describe requirements for protocol design. That's not really how 2119 defines them. That doesn't prevent using them here, but it would be helpful to modify or add to the boilerplate to indicate this. From nobody Wed Feb 20 22:16:31 2019 Return-Path: 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 32B1A12F1AB; Wed, 20 Feb 2019 22:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 PsKJ2IJ2lksP; Wed, 20 Feb 2019 22:16:27 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7530412F1A6; Wed, 20 Feb 2019 22:16:27 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 444kkd2RGNz5wLy; Thu, 21 Feb 2019 07:16:25 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 444kkW3VlLz8sYT; Thu, 21 Feb 2019 07:16:19 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7%21]) with mapi id 14.03.0435.000; Thu, 21 Feb 2019 07:16:19 +0100 From: To: Benjamin Kaduk CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUyTUuwyprX++Zj0q/Tpc5E7J3eaXpxvrg Date: Thu, 21 Feb 2019 06:16:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA230C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <20190220155847.GC69562@kduck.mit.edu> In-Reply-To: <20190220155847.GC69562@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 06:16:30 -0000 Hi Ben,=20 Done in my local copy.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 20 f=E9vrier 2019 16:59 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > Objet=A0: Re: AD review of draft-ietf-dots-data-channel-25 >=20 > On Thu, Feb 14, 2019 at 01:17:07PM -0600, Benjamin Kaduk wrote: > > > > On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.com > wrote: > > > > > > > -----Message d'origine----- > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > Envoy=E9=A0: mercredi 13 f=E9vrier 2019 17:46 > > > > =C0=A0: draft-ietf-dots-data-channel@ietf.org > > > > Cc=A0: dots@ietf.org > > > > Objet=A0: AD review of draft-ietf-dots-data-channel-25 > > > > > > > > > > > > Section 3.5 > > > > > > > > I had to read up on RESTCONF and NETCONF while reviewing this, but = from > > > > what I've seen so far, the "error-severity" field is only present i= n > > > > NETCONF and not RESTCONF. If so, then we shouldn't need to talk ab= out > it > > > > here, since we use RESTCONF exclusively. I also couldn't find whet= her > > > > there's a registry that we should add the "loop-detected" error-tag= to. > > > > Can anyone here help me out? > > > > > > > > > > [Med] We used the template in > https://tools.ietf.org/html/rfc6241#appendix-A because the errors in 8040= are > the ones imported from there. > > > > Thanks for the pointer. It sounds like I'll need to ask around about = this > > one. >=20 > Benoit and Martin confirm that "error-severity" has no purpose in RESTCON= F, > so I think we can safely drop this line. >=20 > -Ben From nobody Wed Feb 20 23:43:36 2019 Return-Path: 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 C0538126C01; Wed, 20 Feb 2019 23:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GWwhGlTjkaDG; Wed, 20 Feb 2019 23:43:24 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC30C124C04; Wed, 20 Feb 2019 23:43:23 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 444mfy05WRz4wVB; Thu, 21 Feb 2019 08:43:22 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 444mfx5kfBzyPk; Thu, 21 Feb 2019 08:43:21 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0435.000; Thu, 21 Feb 2019 08:43:21 +0100 From: To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?B?dGYtZG90cy1yZXF1aXJlbWVudHMtMTg6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHUyUVCxCLiGfX7702dEWEkaKI4qKXpyJ0Q Date: Thu, 21 Feb 2019 07:43:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> In-Reply-To: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 07:43:27 -0000 SGkgTWlyamEsIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWlyamEgS8O8aGxld2luZA0KPiBFbnZvecOpwqA6 IG1lcmNyZWRpIDIwIGbDqXZyaWVyIDIwMTkgMTg6NTQNCj4gw4DCoDogVGhlIElFU0cNCj4gQ2PC oDogZG90cy1jaGFpcnNAaWV0Zi5vcmc7IGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb207IGRyYWZ0 LWlldGYtZG90cy0NCj4gcmVxdWlyZW1lbnRzQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IE9i amV0wqA6IFtEb3RzXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRv dHMtcmVxdWlyZW1lbnRzLTE4Og0KPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4g TWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCj4gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xODogRGlzY3Vzcw0KPiANCj4g V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0K PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtZG90cy1yZXF1aXJlbWVudHMvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElT Q1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhhbmtzIGZvciBhZGRyZXNzaW5nIHRoZSBU U1YtQVJUIGNvbW1lbnRzIChhbmQgdGhhbmtzIEpvZSBmb3IgdGhlIHJldmlldykhDQo+IEluLWxp bmUgd2l0aCBKb2UncyBjb21tZW50LCBwbGVhc2Ugc2VlIHNvbWUgYWRkaXRpb25hbCBjb21tZW50 cyBiZWxvdy4NCj4gDQo+IDEpIE9uZSBtaW5vciBlZGl0IGlzIHJlcXVpcmVkIHN0aWxsIGZvciBT SUctMDAyOiBmb3IgUExNVFVEIHRoZSBjb3JyZWN0DQo+IHJlZmVyZW5jZSBpcyBSRkM0ODIxLCBo b3dldmVyLA0KDQpbTWVkXSBBY3R1YWxseSwgdGhlIGRvY3VtZW50IGlzIHJlZmVycmluZyB0byBk cmFmdC1pZXRmLWludGFyZWEtZnJhZy1mcmFnaWxlIGZvciBQTVRVRCBtYXR0ZXJzLiBUaGF0IGRv Y3VtZW50IGNpdGVzIHRoZSBhcHByb3ByaWF0ZSBkb2N1bWVudHM6IHJmYzgyMDEsIHJmYzQ4MjEs IGRyYWZ0LWlldGYtdHN2d2ctZGF0YWdyYW0tcGxwbXR1ZCwgZXRjLiANCg0KIGFzIGNvbW1lbnRl ZCBieSBKb2UgUkZDMTE5MSBpcyBsZXNzIHJlbGlhYmxlDQoNCltNZWRdIFJGQzExOTEgaXMgY2l0 ZWQgdG8ganVzdGlmeSB3aHkgUE1UVSBvZiA1NzYgYnl0ZXMgd2FzIGNob3Nlbi4NCg0KPiBhbmQN Cj4gdGhlcmVmb3JlIHVzdWFsbHkgbm90IHJlY29tbWVuZGVkLiBJIHdvdWxkIHJlY29tbWVuZCB0 byByZS1hZGQgYSByZWZlcmVuY2UgdG8NCj4gUkZDNDgyMSBhbmQgbm8gcmVmZXJlbmNlIHRvIFJG QzExOTEgKG9yIG9ubHkgd2l0aCBhIHdhcm5pbmcgdGhhdCBSRkM0ODIxIGlzDQo+IHByZWZlcnJl ZCBkdWUgdG8gSUNNUCBibG9ja2luZykuIEZ1cnRoZXIsIHRoZSBjb3JyZWN0IHJlZmVyZW5jZSBm b3IgZGF0YWdyYW0NCj4gUExNVFVEIGlzIGRyYWZ0LWlldGYtdHN2d2ctZGF0YWdyYW0tcGxwbXR1 ZC4NCg0KW01lZF0gVGhpcyBpcyBhbHJlYWR5IGNpdGVkIGluIGRyYWZ0LWlldGYtaW50YXJlYS1m cmFnLWZyYWdpbGUuIE5vIG5lZWQgdG8gYmUgcmVkdW5kYW50LCBJTU8uIA0KDQo+IDIpIEFsc28g b24gdGhpcyB0ZXh0IGluIFNJRy0wMDQ6DQo+ICJUaGUgaGVhcnRiZWF0IGludGVydmFsIGR1cmlu ZyBhY3RpdmUgbWl0aWdhdGlvbiBjb3VsZCBiZQ0KPiAgICAgICBuZWdvdGlhYmxlLCBidXQgTVVT VCBiZSBmcmVxdWVudCBlbm91Z2ggdG8gbWFpbnRhaW4gYW55IG9uLXBhdGgNCj4gICAgICAgTkFU IG9yIEZpcmV3YWxsIGJpbmRpbmdzIGR1cmluZyBtaXRpZ2F0aW9uLiAgV2hlbiBUQ1AgaXMgdXNl ZCBhcw0KPiAgICAgICB0cmFuc3BvcnQsIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGhlYXJ0YmVh dCBtZXNzYWdlcyBuZWVkIHRvIGJlDQo+ICAgICAgIGZyZXF1ZW50IGVub3VnaCB0byBtYWludGFp biB0aGUgVENQIGNvbm5lY3Rpb24gc3RhdGUuIg0KPiANCj4gQXMgSm9lIGNvbW1lbnRlZCBhbHJl YWR5LCBkaWZmZXJlbnQgaGVhcnRiZWF0cyBhdCBkaWZmZXJlbnQgbGF5ZXJzIGNhbiBiZQ0KPiB1 c2VkDQo+IGF0IHRoZSBzYW1lIHRpbWUgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcy4gWW91IGNhbiB1 c2UgaGVhcnRiZWF0cyBhdCB0aGUNCj4gYXBwbGljYXRpb24gbGF5ZXIgdG8gY2hlY2sgc2Vydmlj ZSBhdmFpbGFiaWxpdHkgd2hpbGUgZS5nLiB1c2luZyBhIGhpZ2hlcg0KPiBmcmVxdWVudCBoZWFy dGJlYXQgYXQgdGhlIHRyYW5zcG9ydCBsYXllciB0byBtYWludGFpbiBmaXJld2FsbCBhbmQgTkFU IHN0YXRlLg0KDQpbTWVkXSBQbGVhc2Ugbm90ZSB0aGF0IHRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMg YWJvdXQgImR1cmluZyBhY3RpdmUgbWl0aWdhdGlvbiIuIFdoZW4gbm8gYXR0YWNrIGlzIG9uZ29p bmcsIHdlIGRvIGhhdmUgdGhlIGZvbGxvd2luZyBiZWhhdmlvciB3aGljaCBjb3ZlcnMgeW91ciBj b21tZW50OiANCg0KICAgICAgV2hlbiBET1RTIGFnZW50cyBhcmUgZXhjaGFuZ2luZyBoZWFydGJl YXRzIGFuZCBubw0KICAgICAgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGFjdGl2ZSwgZWl0aGVyIGFn ZW50IE1BWSByZXF1ZXN0IGNoYW5nZXMgdG8NCiAgICAgIHRoZSBoZWFydGJlYXQgcmF0ZS4gIEZv ciBleGFtcGxlLCBhIERPVFMgc2VydmVyIG1pZ2h0IHdhbnQgdG8NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCiAgICAg IHJlZHVjZSBoZWFydGJlYXQgZnJlcXVlbmN5IG9yIGNlYXNlIGhlYXJ0YmVhdCBleGNoYW5nZXMg d2hlbiBhbg0KICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KICAgICAgYWN0aXZlIERPVFMgY2xpZW50IGhhcyBub3Qg cmVxdWVzdGVkIG1pdGlnYXRpb24sIGluIG9yZGVyIHRvDQogICAgICBeXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCiAgICAgIGNvbnRyb2wgbG9hZC4NCg0K PiBUaGUgYWR2YW50YWdlIHRvIHN1Y2ggYW4gYXBwcm9hY2ggaXMgdGhhdCB0aGVyZSBpcyBsZXNz IGFwcGxpY2F0aW9uIGxheWVyDQo+IG92ZXJoZWFkL2xvYWQgZS5nLiBpbiBzY2VuYXJpb3Mgd2hl cmUgaXQgbWlnaHQgYmUgZXhwZW5zaXZlIHRvIHdha2UgdXAgdGhlDQo+IGFwcGxpY2F0aW9uIG9y IGEgc2VydmVyIGlzIGFscmVhZHkgaGlnaGx5IGxvYWRlZC4gQWxzbyBub3RlIHRoYXQgdGhlICB0 aW1lLQ0KPiBvdXRzDQo+IHZhbHVlcyBvZiBOQVRzIGFuZCBmaXJld2FsbHMgb24gdGhlIHBhdGgg YXJlIHVzdWFsbHkgdW5rbm93biwgdGhlcmVmb3JlIGFuDQo+IGFwcGxpY2F0aW9uIGNhbiBuZXZl ciByZWx5IG9uIGhlYXJ0YmVhdHMgKG5vIG1hdHRlciBhdCB3aGljaCBsZXZlbCkgYW5kIG11c3QN Cj4gYmUNCj4gcHJlcGFyZWQgdG8gdHJ5IHRvIHJlY29ubmVjdCBvbiB0aGUgYXBwbGljYXRpb24g bGF5ZXIgaWYgdGhlIGNvbm5lY3Rpb24NCj4gZmFpbHMuDQo+IFVzdWFsbHksIHRoZSBtYWluIHJl YXNvbiBmb3IgdXNpbmcgaGVhcnRiZWF0cyB0byBtYWludGFpbiBOQVQgb3IgZmlyZXdhbGwNCj4g c3RhdGUNCj4gKHZzLiByZWNvbm5lY3QgZXZlcnkgdGltZSkgaW4gVENQIGlzIGlmIHRoZSBhcHBs aWNhdGlvbiBpcyB0aW1lLXNlbnNpdGl2ZSBhbmQNCj4gYQ0KPiBmdWxsIFRDUCBoYW5kc2hha2Ug dGFrZXMgdG9vIGxvbmcgZm9yIHRoZSBkZXNpcmVkIHNlcnZpY2UuIEknbSBub3Qgc3VyZSB0aGF0 DQo+IHRoZSBjYXNlIGZvciBET1RTLCBob3dldmVyLCBJIHVuZGVyc3RhbmQgaXQgbWF5IGJlIGJl bmVmaWNpYWwgdG8gaGF2ZQ0KPiBlc3RhYmxpc2hlZCBzdGF0ZSBpZiBhbiBhdHRhY2sgaXMgb24t Z29pbmcuDQoNCltNZWRdIFRoaXMgaXMgaW1wb3J0YW50IHRvIGF2b2lkIG5ldyBoYW5kc2hha2Vz IHdoZW4gdGhlIGNsaWVudCBoYXMgdG8gcmVxdWVzdCBhIG1pdGlnYXRpb24uIA0KDQo+IA0KPiBG b3IgVURQIEkgZ3Vlc3MgaXQncyBtb3JlIGNvbXBsaWNhdGVkIGluIHlvdXIgY2FzZS4gVGltZS1v dXRzIGFyZSB1c3VhbGx5DQo+IHZlcnkNCj4gc2hvcnQsIGhvd2V2ZXIsIHN0YXRlIGlzIGNyZWF0 ZWQgd2l0aCB0aGUgZmlyc3QgcGFja2V0IG9mIGEgZmxvdyAoYXMgdGhlcmUgaXMNCj4gbm8gaGFu ZHNoYWtlIGluIFVEUCkuIEFzIHlvdSBkb24ndCBzZWUgYmxvY2tpbmcgaWYgc3RhdGUgaXMgZXhw aXJlZCBhcyBuZXcNCj4gc3RhdGUgaXMgY3JlYXRlZCBpbW1lZGlhdGVseSwgaXQncyBraW5kIG9m IGltcG9zc2libGUgdG8gbWVhc3VyZSB0aGUNCj4gY29uZmlndXJlZA0KPiB0aW1lLW91dCB2YWx1 ZXMuIE9ubHkgaWYgdGhlIGZpcmV3YWxsIGlzIHVuZGVyIGF0dGFjayBpdCB3b3VsZCBzdGFydCBi bG9ja2luZw0KPiBVRFAgdHJhZmZpYyB0aGF0IGlzIGhhcyBubyBzdGF0ZSBmb3IgeWV0LiBTbyBJ IHVuZGVyc3RhbmQgd2h5IGl0IGlzIGRlc2lyYWJsZQ0KPiB0byBtYWludGFpbiBVRFAgc3RhdGUg Zm9yIHlvdSwgaG93ZXZlciwgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB5b3UgY2FuIGtub3cNCj4g dGhhdCB5b3VyIGZyZXF1ZW5jeSBpcyBoaWdoIGVub3VnaCB0byBhY3R1YWxseSBrZWVwIHRoZSBz dGF0ZSBvcGVuLiBOb3RlIHRoYXQNCj4gVENQIHRpbWUtb3V0cyBhcmUgdXN1YWxseSBpbiB0aGUg b3JkZXIgb2YgaG91cnMsIHdoaWxlIFVEUCB0aW1lLW91dHMgYXJlDQo+IHVzdWFsbHkgaW4gcmFu Z2Ugb2YgdGVucyBvZiBzZWNvbmRzLCBhbmQgbWlnaHQgZXhwaXJlIGV2ZW4gcXVpY2tlciBpZiBh DQo+IHN5c3RlbQ0KPiBpcyB1bmRlciBhdHRhY2suIElmIHRoYXQgaXMgYSBzY2VuYXJpbyB0aGF0 IGlzIGltcG9ydGFudCBmb3IgeW91LCBhbmQNCj4gYXNzdW1pbmcNCj4gdGhhdCBub3QgYWxsIHRp bWUtb3V0cyB2YWx1ZXMgb24gdGhlIHBhdGggY2FuIGJlIGtub3duLCBJIGd1ZXNzIGl0IHdvdWxk IGJlDQo+IHJlY29tbWVuZGFibGUgdG8gdXNlIFRDUCBpbnN0ZWFkLg0KPiANCj4gSW4gYW55IGNh c2UgdGhpcyBjYW4gbm90IGJlIGEgTVVTVCByZXF1aXJlbWVudCAoYXMgdGltZXJzIGFyZSB1c3Vh bGx5IG5vdA0KPiBrbm93bikuIEkgd291bGQgcmVjb21tZW5kIHRvIHN0YXRlIHNvbWV0aGluZyBs aWtlOg0KPiANCj4gIk1BWSBiZSBmcmVxdWVudCBlbm91Z2ggdG8gbWFpbnRhaW4gTkFUIG9yIGZp cmV3YWxsIHN0YXRlLCBpZiB0aW1lciB2YWx1ZXMNCj4gYXJlDQo+IGtub3duLCBvciBpZiBUQ1Ag aXMgdXNlZCwgU0hPVUxEIHVzZSBpbiBhZGRpdGlvbiBUQ1AgaGVhcnRiZWF0cyAgdG8gbWFpbnRh aW4NCj4gdGhlIFRDUCBjb25uZWN0aW9uIHN0YXRlIGFuZCByZWNvbm5lY3QgaW1tZWRpYXRlbHkg aWYgYSBmYWlsdXJlIGlzIGRldGVjdGVkLiINCj4gDQoNCltNZWRdIFRoZSBvcmlnaW5hbCB3b3Jk aW5nIGlzIGFjY3VyYXRlIGFuZCByZWZsZWN0cyB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlIFdHLiBI b3cgdGhpcyB3aWxsIGJlIGVuZm9yY2VkIGlzIHBhcnQgb2YgdGhlIHNvbHV0aW9uL3NwZWNpZmlj YXRpb24gc3BhY2UuDQoNCj4gQW5kIGFsc28gZm9yIHRoaXMgcGFydCBpdCBpcyBkaWZmZXJlbnQg Zm9yIFRDUCBhbmQgVURQOg0KPiANCj4gIkJlY2F1c2UgaGVhcnRiZWF0IGxvc3MgaXMgbXVjaCBt b3JlIGxpa2VseSBkdXJpbmcgdm9sdW1ldHJpYyBhdHRhY2ssIERPVFMNCj4gICAgICAgYWdlbnRz IFNIT1VMRCBhdm9pZCBzaWduYWwgY2hhbm5lbCB0ZXJtaW5hdGlvbiB3aGVuIG1pdGlnYXRpb24g aXMNCj4gICAgICAgYWN0aXZlIGFuZCBoZWFydGJlYXRzIGFyZSBub3QgcmVjZWl2ZWQgYnkgZWl0 aGVyIERPVFMgYWdlbnQgZm9yIGFuDQo+ICAgICAgIGV4dGVuZGVkIHBlcmlvZC4iDQo+IA0KPiBJ ZiBUQ1Agd291bGQgYmUgdXNlZCBhbmQgbm8gQUNLcyBhcmUgcmVjZWl2ZWQsIFRDUCB3b3VsZCB0 cnkgdG8gcmV0cmFuc21pdCBhDQo+IGZldyB0aW1lcyBhbmQgc29tZSBwb2ludCB0ZXJtaW5hdGUg dGhlIGNvbm5lY3Rpb24uIEhvd2V2ZXIsIFVEUCBpcyBhDQo+IGNvbm5lY3Rpb24tbGVzcyBwcm90 b2NvbCwgdGhlcmUgaXMgbm90aGluZyB0byB0ZXJtaW5hdGUuDQoNCltNZWRdIFRoZSB0ZXh0IGlz IGFib3V0ICJzaWduYWwgY2hhbm5lbCB0ZXJtaW5hdGlvbiIuIFRoZSBjb25jZXB0IG9mIERPVFMg c2Vzc2lvbiBpcyBkZWZpbmVkIGhlcmU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlLTExI3NlY3Rpb24tMy4xIA0KDQo+IA0KPiBBbHNvIG5v dGUgdGhhdCBmb3IgcmVsaWFibGUgdHJhbnNwb3J0cywgaXQgaXMgc3VmZmljaWVudCBpZiBvbmUg ZW5kLWhvc3RzDQo+IHNlbmRzDQo+IGhlYXJ0YmVhdHMgYXMgdGhlIG90aGVyIGVuZCBpcyByZXF1 aXJlZCB0byBhY2tub3dsZWRnZSB0aGUgcmVjZXB0aW9uIG9uIHRoZQ0KPiB0cmFuc3BvcnQgbGF5 ZXIgKGFuZCBpZiBubyBhY2sgaXMgcmVjZWl2ZWQgdGhlIGNvbm5lY3Rpb24gaXMgdGVybWluYXRl ZCBvbg0KPiB0aGUNCj4gdHJhbnNwb3J0IGxheWVyKS4NCj4gDQo+IFNvIEkgZ3Vlc3Mgd2hhdCB5 b3Ugd2FudCB0byBzYXkgYWJvdmUgaXMgdGhhdCBpZiBhIGNvbm5lY3Rpb24tbGVzcyBwcm90b2Nv bA0KPiBpcw0KPiB1c2VkLCBoZWFydGJlYXRzIHNob3VsZCBjb250aW51b3VzbHkgYmUgc2VudCBl dmVuIGlmIG5vIGhlYXJ0YmVhdHMgYXJlDQo+IHJlY2VpdmVkDQo+IGZyb20gdGhlIG90aGVyIGVu ZC4gSG93ZXZlciwgSSB0aGluayB5b3Ugc3RpbGwgbmVlZCB0byBkZWZpbmUgYSB0ZXJtaW5hdGlv bg0KPiBjcml0ZXJpYSwgYXMgeW91IGZvciBzdXJlIGRvbid0IHdhbnQgdG8ga2VlcCBzZW5kaW5n IGhlYXJ0YmVhdHMgZm9yZXZlci4NCg0KW01lZF0gQWdyZWUuIE9uZSBjb25kaXRpb24gaXMgYWxy ZWFkeSBjaXRlZCBpbiB0aGUgYWJvdmUgdGV4dDogIndoZW4gbWl0aWdhdGlvbiBpcyBhY3RpdmUi LiBBIHRlcm1pbmF0aW9uIGNyaXRlcmlhIHdvdWxkIGJlIHRoYXQgdGhlIG1pdGlnYXRpb24gaXMg bm90IGFjdGl2ZSBhbnltb3JlLiBIb3cgdGVybWluYXRpb24gaXMgYWNoaWV2ZWQgaXMgcGFydCBv ZiB0aGUgc29sdXRpb24gc3BhY2UuIA0KDQo+IA0KPiBBbHNvIHRoZSBuZXh0IHBhcnQ6DQo+IA0K PiAiICAgICAgKiAgVG8gaGFuZGxlIHBvc3NpYmxlIERPVFMgc2VydmVyIHJlc3RhcnQgb3IgY3Jh c2gsIHRoZSBET1RTDQo+ICAgICAgICAgIGNsaWVudHMgTUFZIGF0dGVtcHQgdG8gZXN0YWJsaXNo IGEgbmV3IHNpZ25hbCBjaGFubmVsIHNlc3Npb24sDQo+ICAgICAgICAgIGJ1dCBNVVNUIGNvbnRp bnVlIHRvIHNlbmQgaGVhcnRiZWF0cyBvbiB0aGUgY3VycmVudCBzZXNzaW9uIHNvDQo+ICAgICAg ICAgIHRoYXQgdGhlIERPVFMgc2VydmVyIGtub3dzIHRoZSBzZXNzaW9uIGlzIHN0aWxsIGFsaXZl LiAgSWYgdGhlDQo+ICAgICAgICAgIG5ldyBzZXNzaW9uIGlzIHN1Y2Nlc3NmdWxseSBlc3RhYmxp c2hlZCwgdGhlIERPVFMgY2xpZW50IGNhbg0KPiAgICAgICAgICB0ZXJtaW5hdGUgdGhlIGN1cnJl bnQgc2Vzc2lvbi4iDQo+IA0KPiBUaGVyZSBpcyBub3RoaW5nIGxpa2UgY29ubmVjdGlvbiByZS1l c3RhYmxpc2hpbmcgaW4gVURQLCB5b3UganVzdCBrZWVwDQo+IHNlbmRpbmcNCj4gdHJhZmZpYy4N Cg0KW01lZF0gVGhlIHRleHQgaXMgYWJvdXQgInNpZ25hbCBjaGFubmVsIHNlc3Npb24iLg0KDQog V2hpbGUgaW4gVENQLCBhcyBleHBsYWluZWQgYWJvdmUsIHRoZSBjb25uZWN0aW9uIHdpbGwgYmUg dGVybWluYXRlZA0KPiBhdA0KPiB0aGUgdHJhbnNwb3J0IGxheWVyIGFuZCB0aGVyZSBpcyBubyB3 YXkgdG8ga2VlcCBzZW5kaW5nIGhlYXJ0YmVhdHMgb24gdGhlDQo+ICJvbGQiDQo+IHNlc3Npb24u IE9yIGRvIGhhdmUgc29tZXRoaW5nIGxpa2UgRFRMUyBpbiBtaW5kIGluIHRoaXMgY2FzZT8NCg0K W01lZF0gWWVzLg0KDQo+IA0KPiAzKSBJbiBTSUctMDA2IHlvdSBzYXk6DQo+ICIgICAgICBEdWUg dG8gdGhlIGhpZ2hlciBsaWtlbGlob29kIG9mIHBhY2tldCBsb3NzIGR1cmluZyBhIEREb1MgYXR0 YWNrLA0KPiAgICAgICBET1RTIHNlcnZlcnMgTVVTVCByZWd1bGFybHkgc2VuZCBtaXRpZ2F0aW9u IHN0YXR1cyB0byBhdXRob3JpemVkDQo+ICAgICAgIERPVFMgY2xpZW50cyB3aGljaCBoYXZlIHJl cXVlc3RlZCBhbmQgYmVlbiBncmFudGVkIG1pdGlnYXRpb24sDQo+ICAgICAgIHJlZ2FyZGxlc3Mg b2YgY2xpZW50IHJlcXVlc3RzIGZvciBtaXRpZ2F0aW9uIHN0YXR1cy4iDQo+IA0KPiBQbGVhc2Ug bm90ZSB0aGF0IHRoaXMgaXMgb25seSB0cnVlIGlmIGEgbm90LXJlbGlhYmxlIHRyYW5zcG9ydCBp cyB1c2VkLiBJZiBhDQo+IHJlbGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkLCBkYXRhIGlzIHJlY2Vp dmVkIGF0IHRoZSBhcHBsaWNhdGlvbiBsZXZlbCB3aXRob3V0DQo+IGxvc3MgKGJ1dCBtYXliZSBz b21lIGRlbGF5KSBvciB0aGUgY29ubmVjdGlvbiBpcyB0ZXJtaW5hdGVkIChpZiBsb3NzIGlzIHRv bw0KPiBoaWdoIHRvIHJldHJhbnNtaXQgc3VjY2Vzc2Z1bGx5KS4NCj4gDQoNCltNZWRdIFRoZSBy ZXF1aXJlbWVudCBhcyB3b3JkZWQgaXMgT0suIA0KDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENP TU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IE9uZSBlZGl0b3JpYWwgY29tbWVudCBvbiBT RUMtMDAyOg0KPiANCj4gIkEgc2VjdXJpdHkgbWVjaGFuaXNtIGF0IHRoZSBuZXR3b3JrIGxheWVy IChlLmcuLA0KPiAgICAgICBUTFMpIGlzIHRodXMgYWRlcXVhdGUgdG8gcHJvdmlkZSBob3AtYnkt aG9wIHNlY3VyaXR5LiAgSW4gb3RoZXINCj4gICAgICAgd29yZHMsIGVuZC10by1lbmQgc2VjdXJp dHkgaXMgbm90IHJlcXVpcmVkIGZvciBET1RTIHByb3RvY29scy4iDQo+IA0KPiBUTFMgaXMgdHJh bnNwb3J0IGxheWVyIHNlY3VyaXR5IChub3QgbmV0d29yayBsYXllcikgYW5kIHRoZXJlZm9yZSBr bm93biBhcw0KPiBwcm92aWRpbmcgZW5kLXRvLWVuZCBzZWN1cml0eSB3aGlsZSB0aGUgdGVybSBo b3AtYnktaG9wIGlzIHVzZWQgZm9yIGUuZy4NCj4gSVBTZWMuDQo+IA0KPiBJIHdvdWxkIHJlY29t bWVuZCB0byBjaGFuZ2UgdGhlIHdvcmRpbmcgaGVyZSBpbiBvcmRlciB0byBhdm9pZCBjb25mdXNp b24sDQo+IGUuZy4NCj4gDQo+ICJBIHNlY3VyaXR5IG1lY2hhbmlzbSBhdCB0aGUgdHJhbnNwb3J0 IGxheWVyIChlLmcuLA0KPiAgICAgICBUTFMpIGlzIHRodXMgYWRlcXVhdGUgdG8gcHJvdmlkZSBz ZWN1cml0eSBiZXR3ZWVuIGRpZmZlcmVudCBET1RTDQo+IGFnZW50cy4NCj4gICAgICAgSW4gb3Ro ZXIgd29yZHMsIGEgZGlyZWN0IHNlY3VyaXR5IGFzc29jaWF0aW9uIGJldHdlZW4gdGhlIHNlcnZl ciBhbmQNCj4gICAgICAgY2xpZW50LCBleGNsdWRpbmcgYW55IHByb3h5LCBpcyBub3QgcmVxdWly ZWQgZm9yIERPVFMgcHJvdG9jb2xzLiINCj4gDQoNCltNZWRdIEkgZGlzYWdyZWUgd2l0aCB0aGUg bGFzdCBwYXJ0IG9mIHRoZSBwcm9wb3NlZCB3b3JkaW5nLiBUaGUgRE9UUyBhcmNoaXRlY3R1cmUg aW52b2x2ZXMgZ2F0ZXdheXMsIGhlbmNlIHRoZSBob3AtYnktaG9wIHNlY3VyaXR5IG1vZGVsLiAg DQoNCj4gQW5kIGZpbmFsbHkgb25lIGdlbmVyYWwgY29tbWVudDoNCj4gDQo+IEkgdW5kZXJzdGFu ZCB0aGF0IGhhdmluZyB3ZyAgY29uc2Vuc3VzIGZvciB0aGlzIGRvY3VtZW50IGlzIGltcG9ydCB0 byBwcm9jZWVkDQo+IHRoZSB3b3JrIG9mIHRoZSBncm91cCwgaG93ZXZlciwgSSBkb24ndCBzZWUg dGhlIHZhbHVlIGluIGFyY2hpdmluZyB0aGlzDQo+IGRvY3VtZW50IGluIHRoZSBJRVRGIFJGQyBz ZXJpZXMgYXMgYSBzdGFuZC1hbG9uZSBkb2N1bWVudC4gSWYgdGhlIGdyb3VwDQo+IHRoaW5rcw0K PiBkb2N1bWVudGluZyB0aGVzZSByZXF1aXJlbWVudHMgZm9yIGNvbnN1bXB0aW9uIG91dHNpZGUg dGhlIGdyb3VwJ3Mgd29yayBhdCBhDQo+IGxhdGVyIHBvaW50IGluIHRpbWUgaXMgdmFsdWFibGUs IEkgd291bGQgcmF0aGVyIHJlY29tbWVuZCB0byBhZGQgdGhlDQo+IHJlc3BlY3RpdmUNCj4gcmVx dWlyZW1lbnRzIHRvIHRoZSBhcHBlbmRpeCBvZiB0aGUgcmVzcGVjdGl2ZSBwcm90b2NvbCBzcGVj cy4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Thu Feb 21 02:34:47 2019 Return-Path: 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 49241130DC2; Thu, 21 Feb 2019 02:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 h0ZXfWdeeZhW; Thu, 21 Feb 2019 02:34:37 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE69C1276D0; Thu, 21 Feb 2019 02:34:36 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 444rSW1hNbzCrjB; Thu, 21 Feb 2019 11:34:35 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 444rSW0hmXzDq7q; Thu, 21 Feb 2019 11:34:35 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0435.000; Thu, 21 Feb 2019 11:34:35 +0100 From: To: Ben Campbell , The IESG CC: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] Ben Campbell's No Objection on draft-ietf-dots-requirements-18: (with COMMENT) Thread-Index: AQHUyZd9LQ0fza0CVUiFAnUSOMz4DKXqDG3A Date: Thu, 21 Feb 2019 10:34:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA231D2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155072052056.20358.15761578065156106209.idtracker@ietfa.amsl.com> In-Reply-To: <155072052056.20358.15761578065156106209.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Ben Campbell's No Objection on draft-ietf-dots-requirements-18: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 10:34:39 -0000 SGkgQmVuLA0KDQooYXMgYSBXRyBwYXJ0aWNpcGFudCkNCg0KRldJVywgdGhlIFdHIGRpc2N1c3Nl ZCB5b3VyIGZpcnN0IHBvaW50IGVhcmx5IGluIHRoZSBwcm9jZXNzIGFuZCBtYWRlIGEgZGVjaXNp b24uIFBsZWFzZSBjaGVjayBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Rv dHMvbDBwaFFkcG1TYzRqNlhoZnhVeXgtbHJyRHprLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQmVuIENhbXBiZWxsDQo+IEVudm95w6nCoDogamV1 ZGkgMjEgZsOpdnJpZXIgMjAxOSAwNDo0Mg0KPiDDgMKgOiBUaGUgSUVTRw0KPiBDY8KgOiBkb3Rz LWNoYWlyc0BpZXRmLm9yZzsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTsgZHJhZnQtaWV0Zi1k b3RzLQ0KPiByZXF1aXJlbWVudHNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDog W0RvdHNdIEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWRvdHMtcmVx dWlyZW1lbnRzLQ0KPiAxODogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEJlbiBDYW1wYmVsbCBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1k b3RzLXJlcXVpcmVtZW50cy0xODogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4g ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0K PiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNH IERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwg YWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVt ZW50cy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiAtIEknbSBjdXJpb3VzIHdoYXQgdGhlIGFyY2hpdmFsIHZhbHVlIHRoaXMg aGFzIGZvciBwdWJsaXNoaW5nIGFzIGFuIFJGQy4gRGlkDQo+IHRoZSBXRyBjb25zaWRlciBhbHRl cm5hdGl2ZSBwdWJsaWNhdGlvbiBtZXRob2RzPyAoZS5nLiwgbGVhdmUgYXMgYSBkcmFmdCwNCj4g cHVibGlzaCBpbiBhIFdHIHdpa2kpDQo+IA0KPiDCpzEuMjogVGhlIGRyYWZ0IHVzZXMgMjExOS84 MTc0IGtleXdvcmRzIHRvIGRlc2NyaWJlIHJlcXVpcmVtZW50cyBmb3IgcHJvdG9jb2wNCj4gZGVz aWduLiBUaGF0J3Mgbm90IHJlYWxseSBob3cgMjExOSBkZWZpbmVzIHRoZW0uIFRoYXQgZG9lc24n dCBwcmV2ZW50IHVzaW5nDQo+IHRoZW0gaGVyZSwgYnV0IGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8g bW9kaWZ5IG9yIGFkZCB0byB0aGUgYm9pbGVycGxhdGUgdG8NCj4gaW5kaWNhdGUgdGhpcy4NCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Thu Feb 21 02:58:46 2019 Return-Path: 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 A27011276D0; Thu, 21 Feb 2019 02:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dhKs9pORx2fm; Thu, 21 Feb 2019 02:58:37 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE21130F19; Thu, 21 Feb 2019 02:58:36 -0800 (PST) Received: from 200116b82cde9500947f70fc4af24b59.dip.versatel-1u1.de ([2001:16b8:2cde:9500:947f:70fc:4af2:4b59]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gwm3k-0003Ez-Uy; Thu, 21 Feb 2019 11:58:33 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 21 Feb 2019 11:58:31 +0100 Cc: The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1550746716;f310f732; X-HE-SMSGID: 1gwm3k-0003Ez-Uy Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 10:58:41 -0000 Hi Med, please see below. > Am 21.02.2019 um 08:43 schrieb mohamed.boucadair@orange.com: >=20 > Hi Mirja,=20 >=20 > Please see inline. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de Mirja = K=C3=BChlewind >> Envoy=C3=A9 : mercredi 20 f=C3=A9vrier 2019 18:54 >> =C3=80 : The IESG >> Cc : dots-chairs@ietf.org; frank.xialiang@huawei.com; = draft-ietf-dots- >> requirements@ietf.org; dots@ietf.org >> Objet : [Dots] Mirja K=C3=BChlewind's Discuss on = draft-ietf-dots-requirements-18: >> (with DISCUSS and COMMENT) >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-dots-requirements-18: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thanks for addressing the TSV-ART comments (and thanks Joe for the = review)! >> In-line with Joe's comment, please see some additional comments = below. >>=20 >> 1) One minor edit is required still for SIG-002: for PLMTUD the = correct >> reference is RFC4821, however, >=20 > [Med] Actually, the document is referring to = draft-ietf-intarea-frag-fragile for PMTUD matters. That document cites = the appropriate documents: rfc8201, rfc4821, = draft-ietf-tsvwg-datagram-plpmtud, etc.=20 >=20 > as commented by Joe RFC1191 is less reliable >=20 > [Med] RFC1191 is cited to justify why PMTU of 576 bytes was chosen. >=20 >> and >> therefore usually not recommended. I would recommend to re-add a = reference to >> RFC4821 and no reference to RFC1191 (or only with a warning that = RFC4821 is >> preferred due to ICMP blocking). Further, the correct reference for = datagram >> PLMTUD is draft-ietf-tsvwg-datagram-plpmtud. >=20 > [Med] This is already cited in draft-ietf-intarea-frag-fragile. No = need to be redundant, IMO.=20 Actually, yes this is probably more an editorial comment from my side, = that citing rfc4821 and draft-ietf-tsvwg-datagram-plpmtud directly could = be good. But I will not hold my discuss for this. >=20 >> 2) Also on this text in SIG-004: >> "The heartbeat interval during active mitigation could be >> negotiable, but MUST be frequent enough to maintain any on-path >> NAT or Firewall bindings during mitigation. When TCP is used as >> transport, the DOTS signal channel heartbeat messages need to be >> frequent enough to maintain the TCP connection state." >>=20 >> As Joe commented already, different heartbeats at different layers = can be >> used >> at the same time for different purposes. You can use heartbeats at = the >> application layer to check service availability while e.g. using a = higher >> frequent heartbeat at the transport layer to maintain firewall and = NAT state. >=20 > [Med] Please note that the text you quoted is about "during active = mitigation". When no attack is ongoing, we do have the following = behavior which covers your comment:=20 >=20 > When DOTS agents are exchanging heartbeats and no > mitigation request is active, either agent MAY request changes to > the heartbeat rate. For example, a DOTS server might want to > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > reduce heartbeat frequency or cease heartbeat exchanges when an > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > active DOTS client has not requested mitigation, in order to > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > control load. >=20 >> The advantage to such an approach is that there is less application = layer >> overhead/load e.g. in scenarios where it might be expensive to wake = up the >> application or a server is already highly loaded. Also note that the = time- >> outs >> values of NATs and firewalls on the path are usually unknown, = therefore an >> application can never rely on heartbeats (no matter at which level) = and must >> be >> prepared to try to reconnect on the application layer if the = connection >> fails. >> Usually, the main reason for using heartbeats to maintain NAT or = firewall >> state >> (vs. reconnect every time) in TCP is if the application is = time-sensitive and >> a >> full TCP handshake takes too long for the desired service. I'm not = sure that >> the case for DOTS, however, I understand it may be beneficial to have >> established state if an attack is on-going. >=20 > [Med] This is important to avoid new handshakes when the client has to = request a mitigation.=20 This is okay but could be spelled out more explicitly as a requirement, = rather than taking about the details of sending heartbeats. >=20 >>=20 >> For UDP I guess it's more complicated in your case. Time-outs are = usually >> very >> short, however, state is created with the first packet of a flow (as = there is >> no handshake in UDP). As you don't see blocking if state is expired = as new >> state is created immediately, it's kind of impossible to measure the >> configured >> time-out values. Only if the firewall is under attack it would start = blocking >> UDP traffic that is has no state for yet. So I understand why it is = desirable >> to maintain UDP state for you, however, I don't understand how you = can know >> that your frequency is high enough to actually keep the state open. = Note that >> TCP time-outs are usually in the order of hours, while UDP time-outs = are >> usually in range of tens of seconds, and might expire even quicker if = a >> system >> is under attack. If that is a scenario that is important for you, and >> assuming >> that not all time-outs values on the path can be known, I guess it = would be >> recommendable to use TCP instead. >>=20 >> In any case this can not be a MUST requirement (as timers are usually = not >> known). I would recommend to state something like: >>=20 >> "MAY be frequent enough to maintain NAT or firewall state, if timer = values >> are >> known, or if TCP is used, SHOULD use in addition TCP heartbeats to = maintain >> the TCP connection state and reconnect immediately if a failure is = detected." >>=20 >=20 > [Med] The original wording is accurate and reflects the requirement of = the WG. How this will be enforced is part of the solution/specification = space. My hold point here is that=20 "MUST be frequent enough to maintain any on-path NAT or Firewall = bindings during mitigation.=E2=80=9C cannot be a MUST requirement as the network time-out values are not = known by the endpoints. Therefore it is impossible to fulfill this = requirement. >=20 >> And also for this part it is different for TCP and UDP: >>=20 >> "Because heartbeat loss is much more likely during volumetric attack, = DOTS >> agents SHOULD avoid signal channel termination when mitigation = is >> active and heartbeats are not received by either DOTS agent for = an >> extended period." >>=20 >> If TCP would be used and no ACKs are received, TCP would try to = retransmit a >> few times and some point terminate the connection. However, UDP is a >> connection-less protocol, there is nothing to terminate. >=20 > [Med] The text is about "signal channel termination". The concept of = DOTS session is defined here: = https://tools.ietf.org/html/draft-ietf-dots-architecture-11#section-3.1=20= Okay I was actually misinterpreting this. However, I actually think this = is going too much into technical details for a requirements document. = But re-reading I think the requirement if really needed on this level is = okay. >=20 >>=20 >> Also note that for reliable transports, it is sufficient if one = end-hosts >> sends >> heartbeats as the other end is required to acknowledge the reception = on the >> transport layer (and if no ack is received the connection is = terminated on >> the >> transport layer). >>=20 >> So I guess what you want to say above is that if a connection-less = protocol >> is >> used, heartbeats should continuously be sent even if no heartbeats = are >> received >> from the other end. However, I think you still need to define a = termination >> criteria, as you for sure don't want to keep sending heartbeats = forever. >=20 > [Med] Agree. One condition is already cited in the above text: "when = mitigation is active". A termination criteria would be that the = mitigation is not active anymore. How termination is achieved is part of = the solution space.=20 >=20 One clarification question: If mitigation is active and you loose the = heartbeat, is it always the case that the mitigation ends after a well = defined time or could the mitigation go on =E2=80=9Eforever"? >>=20 >> Also the next part: >>=20 >> " * To handle possible DOTS server restart or crash, the DOTS >> clients MAY attempt to establish a new signal channel = session, >> but MUST continue to send heartbeats on the current session = so >> that the DOTS server knows the session is still alive. If = the >> new session is successfully established, the DOTS client can >> terminate the current session." >>=20 >> There is nothing like connection re-establishing in UDP, you just = keep >> sending >> traffic. >=20 > [Med] The text is about "signal channel session=E2=80=9C. Yes, misinterpreted that. That should be okay. >=20 > While in TCP, as explained above, the connection will be terminated >> at >> the transport layer and there is no way to keep sending heartbeats on = the >> "old" >> session. Or do have something like DTLS in mind in this case? >=20 > [Med] Yes. >=20 >>=20 >> 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." >>=20 >> 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). >>=20 >=20 > [Med] The requirement as worded is OK.=20 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. >=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> One editorial comment on SEC-002: >>=20 >> "A security mechanism at the network layer (e.g., >> TLS) is thus adequate to provide hop-by-hop security. In other >> words, end-to-end security is not required for DOTS protocols." >>=20 >> TLS is transport layer security (not network layer) and therefore = known as >> providing end-to-end security while the term hop-by-hop is used for = e.g. >> IPSec. >>=20 >> I would recommend to change the wording here in order to avoid = confusion, >> e.g. >>=20 >> "A security mechanism at the transport layer (e.g., >> TLS) is thus adequate to provide security between different DOTS >> agents. >> In other words, a direct security association between the server = and >> client, excluding any proxy, is not required for DOTS = protocols." >>=20 >=20 > [Med] I disagree with the last part of the proposed wording. The DOTS = architecture involves gateways, hence the hop-by-hop security model. This is not a technical comment. The technical content is correct. = However, as I said above, the term hop-by-hop is associated by many = people in the community with something like IPSec, while application = layer gateways are rather considered as endpoints. All I'm requesting is = to avoid the terms end-to-end and hop-by-hop in this context as it might = be confusing to others. Mirja > =20 >=20 >> And finally one general comment: >>=20 >> I understand that having wg consensus for this document is import to = proceed >> the work of the group, however, I don't see the value in archiving = this >> document in the IETF RFC series as a stand-alone document. If the = group >> thinks >> documenting these requirements for consumption outside the group's = work at a >> later point in time is valuable, I would rather recommend to add the >> respective >> requirements to the appendix of the respective protocol specs. >>=20 >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 21 03:19:00 2019 Return-Path: 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 DFDFA130F5C; Thu, 21 Feb 2019 03:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 aowIBfHU6r4E; Thu, 21 Feb 2019 03:18:57 -0800 (PST) Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 6F3F21276D0; Thu, 21 Feb 2019 03:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1638; q=dns/txt; s=VRSN; t=1550747938; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=PGdW+tdQ8TUp+SYt5+lCbIXBkHzNNpb1fURj//Mbc2M=; b=BSjA+LYLCpe8hMwQAszSfiMTfK1JlLe0wk/VVg9mNi2efp3x0WQwoGqg pSiz3NVBX7yqgvhiAN2KUHkCe3OAWEOc3dR0vH3/vGmuoytI+B3IUcYWh oZX5YTYn9M9C35iojP6BMND+kGSslH347YZrgzsAgAOAdU4sBknIitdeo jbt9zntPIYGSK/gEtxaSCVuEgG+bMTFmj5bhF5gOlH4mYIOJtGJ3SCNWM iumi8DQRtCl8SAEuBkWcCS2drw4+6gpR7dDp7cr3qHH8bQNNPcd6SBqvF XrXx1JfGcMi4s72IsncAS+hBAf88LAHPcFUf2IoD8mBVtPmmhRLZGVGJL w==; X-IronPort-AV: E=Sophos;i="5.58,395,1544504400"; d="scan'208";a="6953260" IronPort-PHdr: =?us-ascii?q?9a23=3ApL0kXxQPHqvB5bq//VwyaZzqatpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa67ZhWOt8tkgFKBZ4jH8fUM07OQ7/iwHzRYqb+681k6OKRWUB?= =?us-ascii?q?EEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAA?= =?us-ascii?q?jwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba9xIRmssQndqtQdjJd/JKo21h?= =?us-ascii?q?bHuGZDdf5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2?= =?us-ascii?q?Ao/8LrrgXMTRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VD?= =?us-ascii?q?K/5KpwVhTmlDkIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWG?= =?us-ascii?q?hPUdtLVyFZAo2ycZYBD/YPM+hboYnypUcBoxSxCgS3GOPg0TpIimPq0aEm0e?= =?us-ascii?q?ksFxzN0gw6H9IJtXTZtNv5OrkMXu+vw6nI0CvMY+tL0jnl6YjIcR4tquyLUL?= =?us-ascii?q?J2bcre11MgFwzYjlqOsoHqMC2a1v4Ms2iA7upgWuSvh3Q7pAF2pzii38EhgZ?= =?us-ascii?q?TKiIIN0l3I6Dl1zJwoKdC6RkN3e8OoHZteui2AOIZ7RtsuQ292tys51rELvJ?= =?us-ascii?q?u2czIJxZkj3BHSbvKKf5aV7R/iUeueOjN1iXNndb+6iRu//0qtxfD6W8Kpyl?= =?us-ascii?q?hFtDBFncPJtn0V0hzT7dWIReVl80e63DaPyxjT6uZZIUAojabbK4Auwro3lp?= =?us-ascii?q?cLrEnNAjf4lFj2g6GOeUsr+/Sk5/r9brX4upCcMJV0ihnkPqs0h8OzG/o4Mh?= =?us-ascii?q?IVX2id4+izyLrj/UjhTLVLiP05jLXZvYjHKcgHvKK1Hg1Y34g55xqiDzqr3s?= =?us-ascii?q?4UkHYDIV5dfRKIlYnpO1XAIPDiCve/hkyhkDF3x//YJLLhDYjNIWbYnbf/Y7?= =?us-ascii?q?l98U9cyBEyzdBQ4ZJYEK0OIPX2WkPprtzXEgc5MxCow+bgENh9150RWX6BAq?= =?us-ascii?q?KCM6PSrEGH5uIrI+aSao4VuTD9JOU/6/7ok3A5hUcXfbO10psPdHC4AvNmLl?= =?us-ascii?q?2cYXrrgtcOC2IKsRQjQ+Dwk1KCViNTaGqoUK0h/D47CZimAJzERoC3mrOB2i?= =?us-ascii?q?i7EYNMam9aDVCMFG/id5+YVPcUdCKSPshhnyQZWrimV48hzgiiuxP6y7V9L+?= =?us-ascii?q?rU4DYYuIni1Ndr++3Tmws+9TtuD8SSy2uNVX17nnsURz8q26ByuUJ9yk2Z3q?= =?us-ascii?q?h+gPxUD9NS5/JTXQc+NJ7T1ep6C9/pVwLBY9eGUlinTcunAT0rUt0xxNoOaV?= =?us-ascii?q?5nG9q+lhDDwzaqA7gNmrOWA5w07rnc0mPwJ8lj13bG2rMtj148QstALWemnL?= =?us-ascii?q?Jw9xDPB47VlEWUj6eqeroH3C7C72qDzHSBvF1WUAJqVqXFR38fbFPMrdvl/k?= =?us-ascii?q?PCU6OuCbM/PwRc086NMKVKasHwgVVHWvjjJNreb3uslGe3GRaI3aqAbJD0dG?= =?us-ascii?q?UEwSXdCVIEnB4W/XmYMwg+GjyhrnnfDDNwCVLvbVng8e5kqHO0HQcIyFTASk?= =?us-ascii?q?x71bP92QMYhfiRVPIV0vpEmQodhXQ+VAK80s7YI9mdqgplcbpdZ9975lpbgz?= =?us-ascii?q?H3rQt4a9acIqltm1NaOyJ2vAmmgxNrB4xPjMUCkn4wzRFzJqTe21REIWDLla?= =?us-ascii?q?vsM6HafzGhtCukbLTbjxSHiI6b?= X-IPAS-Result: =?us-ascii?q?A2FsAABPiG5c/zGZrQpkHgEGBwaBUggLAYJZgTuEB5V8g?= =?us-ascii?q?1qURIF7DAGEbAIXhAQ1CA0BAwEBAQEBAQIBAQKBEYI6KQGCaAEEASMRRRACA?= =?us-ascii?q?QgaAh8HAgICMBUFCwIEDgWDIIFrrTeBL4ovgQuIdYEegUGBQT6BEScfgkyFA?= =?us-ascii?q?YMJMYImAowOl0UJApJ1gXGFWotAglaZegIEAgQFAhSBSAFfgS5wFWUBgkGCK?= =?us-ascii?q?BcTjgtykAsBAQ?= Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 21 Feb 2019 06:18:54 -0500 Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Thu, 21 Feb 2019 06:18:54 -0500 From: "Teague, Nik" To: "Mirja Kuehlewind (IETF)" CC: "mohamed.boucadair@orange.com" , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Thread-Topic: =?utf-8?B?W0VYVEVSTkFMXSBSZTogW0RvdHNdICBNaXJqYSBLw7xobGV3aW5kJ3MgRGlz?= =?utf-8?B?Y3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE4OiAod2l0?= =?utf-8?Q?h_DISCUSS_and_COMMENT)?= Thread-Index: AQHUybkrfwluAygrYEyDVStNiFqCoqXqaSKA//+x4eg= Date: Thu, 21 Feb 2019 11:18:54 +0000 Message-ID: <5CE85A1F-16DC-485C-BA5F-278E0E8CFF3C@Verisign.com> References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>, <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> In-Reply-To: <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 11:18:59 -0000 SGksDQoNCg0KT24gMjEgRmViIDIwMTksIGF0IDEwOjU4LCBNaXJqYSBLdWVobGV3aW5kIChJRVRG KSA8aWV0ZkBrdWVobGV3aW5kLm5ldD4gd3JvdGU6DQoNCj4+PiAzKSBJbiBTSUctMDA2IHlvdSBz YXk6DQo+Pj4gIiAgICAgIER1ZSB0byB0aGUgaGlnaGVyIGxpa2VsaWhvb2Qgb2YgcGFja2V0IGxv c3MgZHVyaW5nIGEgRERvUyBhdHRhY2ssDQo+Pj4gICAgIERPVFMgc2VydmVycyBNVVNUIHJlZ3Vs YXJseSBzZW5kIG1pdGlnYXRpb24gc3RhdHVzIHRvIGF1dGhvcml6ZWQNCj4+PiAgICAgRE9UUyBj bGllbnRzIHdoaWNoIGhhdmUgcmVxdWVzdGVkIGFuZCBiZWVuIGdyYW50ZWQgbWl0aWdhdGlvbiwN Cj4+PiAgICAgcmVnYXJkbGVzcyBvZiBjbGllbnQgcmVxdWVzdHMgZm9yIG1pdGlnYXRpb24gc3Rh dHVzLiINCj4+PiANCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgb25seSB0cnVlIGlmIGEg bm90LXJlbGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkLiBJZiBhDQo+Pj4gcmVsaWFibGUgdHJhbnNw b3J0IGlzIHVzZWQsIGRhdGEgaXMgcmVjZWl2ZWQgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVsIHdp dGhvdXQNCj4+PiBsb3NzIChidXQgbWF5YmUgc29tZSBkZWxheSkgb3IgdGhlIGNvbm5lY3Rpb24g aXMgdGVybWluYXRlZCAoaWYgbG9zcyBpcyB0b28NCj4+PiBoaWdoIHRvIHJldHJhbnNtaXQgc3Vj Y2Vzc2Z1bGx5KS4NCj4+PiANCj4+IA0KPj4gW01lZF0gVGhlIHJlcXVpcmVtZW50IGFzIHdvcmRl ZCBpcyBPSy4gDQo+IA0KPiBJIGRpc2FncmVlLCBiZWNhdXNlIGFzIEkgc2FpZCBpZiBhIHJlbGlh YmxlIHRyYW5zcG9ydCBpcyB1c2VkIHRoaXMgaXMgbm90IHRydWUuIE1heWJlIHlvdSBjYW4gYWRh cHQgdGhpcyBzZW50ZW5jZSBzbGlnaHRseSB0byBjbGFyaWZ5IHRoYXQgeW91IHByb2JhYmx5IGhh ZCBhIHNjZW5hcmlvIGluIG1pbmQgd2hlcmUgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQgaXMgdXNl ZA0KDQpUaGUga2V5IHBhcnQgaGVyZSBpcyDigJhwYWNrZXTigJkgdnMg4oCYZGF0YeKAmSAtIHBh Y2tldHMgd2lsbCBiZSBsb3N0IG9uIGNvbmdlc3RlZCBsaW5rcyByZWdhcmRsZXNzIG9mIGRhdGEg aW50ZWdyaXR5LiAgVGhpcyBtYXkgZGVncmFkZSBjb25uZWN0aW9uIHJlLWVzdGFibGlzaG1lbnQg d2l0aCB0Y3AgYW5kIGNhdXNlIGRhdGEgbG9zcyBpbiBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydC4= From nobody Thu Feb 21 03:41:51 2019 Return-Path: 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 5827A130F88; Thu, 21 Feb 2019 03:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xWkkHN25iJhd; Thu, 21 Feb 2019 03:41:42 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3D9130F86; Thu, 21 Feb 2019 03:41:42 -0800 (PST) Received: from 200116b82cde9500947f70fc4af24b59.dip.versatel-1u1.de ([2001:16b8:2cde:9500:947f:70fc:4af2:4b59]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gwmjR-0000NP-9y; Thu, 21 Feb 2019 12:41:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5CE85A1F-16DC-485C-BA5F-278E0E8CFF3C@Verisign.com> Date: Thu, 21 Feb 2019 12:41:36 +0100 Cc: "mohamed.boucadair@orange.com" , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3089053C-CF9B-491A-ACB0-0BC053C50E88@kuehlewind.net> 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> To: "Teague, Nik" X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1550749302;9b913764; X-HE-SMSGID: 1gwmjR-0000NP-9y Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 11:41:44 -0000 Hi, please see below. > Am 21.02.2019 um 12:18 schrieb Teague, Nik : >=20 > Hi, >=20 >=20 > On 21 Feb 2019, at 10:58, Mirja Kuehlewind (IETF) = wrote: >=20 >>>> 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." >>>>=20 >>>> 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). >>>>=20 >>>=20 >>> [Med] The requirement as worded is OK.=20 >>=20 >> 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 >=20 > The key part here is =E2=80=98packet=E2=80=99 vs =E2=80=98data=E2=80=99 = - 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=E2=80=99t 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? Mirja From nobody Thu Feb 21 04:17:43 2019 Return-Path: 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 40CAE13103C; Thu, 21 Feb 2019 04:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Tb9sAJtFJK_y; Thu, 21 Feb 2019 04:17:28 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A840130FAF; Thu, 21 Feb 2019 04:17:27 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 444tl94VSYz2xWp; Thu, 21 Feb 2019 13:17:25 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 444tl935M7z5vMq; Thu, 21 Feb 2019 13:17:25 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA4.corporate.adroot.infra.ftgroup ([fe80::4538:d7b0:3c64:8ed3%22]) with mapi id 14.03.0435.000; Thu, 21 Feb 2019 13:17:25 +0100 From: To: "Mirja Kuehlewind (IETF)" CC: The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?B?dGYtZG90cy1yZXF1aXJlbWVudHMtMTg6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHUydRlftW7vgDVt0eZilGwszmCLKXqJj4w Date: Thu, 21 Feb 2019 12:17:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA232A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> In-Reply-To: <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 12:17:35 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBNaXJqYSBLdWVobGV3aW5kIChJRVRGKSBbbWFp bHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+IEVudm95w6nCoDogamV1ZGkgMjEgZsOpdnJpZXIg MjAxOSAxMTo1OQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IFRo ZSBJRVNHOyBkb3RzLWNoYWlyc0BpZXRmLm9yZzsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTsg ZHJhZnQtaWV0Zi0NCj4gZG90cy1yZXF1aXJlbWVudHNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcN Cj4gT2JqZXTCoDogUmU6IFtEb3RzXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFm dC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLQ0KPiAxODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCj4gDQo+IEhpIE1lZCwNCj4gDQo+IHBsZWFzZSBzZWUgYmVsb3cuDQo+IA0KPiA+IEFtIDIx LjAyLjIwMTkgdW0gMDg6NDMgc2NocmllYiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOg0K PiA+DQo+ID4gSGkgTWlyamEsDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+ IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gPj4gRGUgOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0 IGRlIE1pcmphIEvDvGhsZXdpbmQNCj4gPj4gRW52b3nDqSA6IG1lcmNyZWRpIDIwIGbDqXZyaWVy IDIwMTkgMTg6NTQNCj4gPj4gw4AgOiBUaGUgSUVTRw0KPiA+PiBDYyA6IGRvdHMtY2hhaXJzQGll dGYub3JnOyBmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tOyBkcmFmdC1pZXRmLWRvdHMtDQo+ID4+ IHJlcXVpcmVtZW50c0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZw0KPiA+PiBPYmpldCA6IFtEb3Rz XSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1l bnRzLQ0KPiAxODoNCj4gPj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPj4NCj4gPj4g TWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCj4gPj4gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xODogRGlzY3Vzcw0KPiA+ Pg0KPiA+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gPj4gaW50cm9kdWN0 b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSByZWZlciB0 byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWwNCj4gPj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01N RU5UIHBvc2l0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+PiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLw0K PiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IERJU0NVU1M6DQo+ID4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4gVGhhbmtzIGZvciBhZGRyZXNzaW5nIHRoZSBUU1Yt QVJUIGNvbW1lbnRzIChhbmQgdGhhbmtzIEpvZSBmb3IgdGhlDQo+IHJldmlldykhDQo+ID4+IElu LWxpbmUgd2l0aCBKb2UncyBjb21tZW50LCBwbGVhc2Ugc2VlIHNvbWUgYWRkaXRpb25hbCBjb21t ZW50cyBiZWxvdy4NCj4gPj4NCj4gPj4gMSkgT25lIG1pbm9yIGVkaXQgaXMgcmVxdWlyZWQgc3Rp bGwgZm9yIFNJRy0wMDI6IGZvciBQTE1UVUQgdGhlIGNvcnJlY3QNCj4gPj4gcmVmZXJlbmNlIGlz IFJGQzQ4MjEsIGhvd2V2ZXIsDQo+ID4NCj4gPiBbTWVkXSBBY3R1YWxseSwgdGhlIGRvY3VtZW50 IGlzIHJlZmVycmluZyB0byBkcmFmdC1pZXRmLWludGFyZWEtZnJhZy0NCj4gZnJhZ2lsZSBmb3Ig UE1UVUQgbWF0dGVycy4gVGhhdCBkb2N1bWVudCBjaXRlcyB0aGUgYXBwcm9wcmlhdGUgZG9jdW1l bnRzOg0KPiByZmM4MjAxLCByZmM0ODIxLCBkcmFmdC1pZXRmLXRzdndnLWRhdGFncmFtLXBscG10 dWQsIGV0Yy4NCj4gPg0KPiA+IGFzIGNvbW1lbnRlZCBieSBKb2UgUkZDMTE5MSBpcyBsZXNzIHJl bGlhYmxlDQo+ID4NCj4gPiBbTWVkXSBSRkMxMTkxIGlzIGNpdGVkIHRvIGp1c3RpZnkgd2h5IFBN VFUgb2YgNTc2IGJ5dGVzIHdhcyBjaG9zZW4uDQo+ID4NCj4gPj4gYW5kDQo+ID4+IHRoZXJlZm9y ZSB1c3VhbGx5IG5vdCByZWNvbW1lbmRlZC4gSSB3b3VsZCByZWNvbW1lbmQgdG8gcmUtYWRkIGEg cmVmZXJlbmNlDQo+IHRvDQo+ID4+IFJGQzQ4MjEgYW5kIG5vIHJlZmVyZW5jZSB0byBSRkMxMTkx IChvciBvbmx5IHdpdGggYSB3YXJuaW5nIHRoYXQgUkZDNDgyMQ0KPiBpcw0KPiA+PiBwcmVmZXJy ZWQgZHVlIHRvIElDTVAgYmxvY2tpbmcpLiBGdXJ0aGVyLCB0aGUgY29ycmVjdCByZWZlcmVuY2Ug Zm9yDQo+IGRhdGFncmFtDQo+ID4+IFBMTVRVRCBpcyBkcmFmdC1pZXRmLXRzdndnLWRhdGFncmFt LXBscG10dWQuDQo+ID4NCj4gPiBbTWVkXSBUaGlzIGlzIGFscmVhZHkgY2l0ZWQgaW4gZHJhZnQt aWV0Zi1pbnRhcmVhLWZyYWctZnJhZ2lsZS4gTm8gbmVlZCB0bw0KPiBiZSByZWR1bmRhbnQsIElN Ty4NCj4gDQo+IEFjdHVhbGx5LCB5ZXMgdGhpcyBpcyBwcm9iYWJseSBtb3JlIGFuIGVkaXRvcmlh bCBjb21tZW50IGZyb20gbXkgc2lkZSwgdGhhdA0KPiBjaXRpbmcgcmZjNDgyMSBhbmQgZHJhZnQt aWV0Zi10c3Z3Zy1kYXRhZ3JhbS1wbHBtdHVkIGRpcmVjdGx5IGNvdWxkIGJlIGdvb2QuDQo+IEJ1 dCBJIHdpbGwgbm90IGhvbGQgbXkgZGlzY3VzcyBmb3IgdGhpcy4NCj4gDQo+ID4NCj4gPj4gMikg QWxzbyBvbiB0aGlzIHRleHQgaW4gU0lHLTAwNDoNCj4gPj4gIlRoZSBoZWFydGJlYXQgaW50ZXJ2 YWwgZHVyaW5nIGFjdGl2ZSBtaXRpZ2F0aW9uIGNvdWxkIGJlDQo+ID4+ICAgICAgbmVnb3RpYWJs ZSwgYnV0IE1VU1QgYmUgZnJlcXVlbnQgZW5vdWdoIHRvIG1haW50YWluIGFueSBvbi1wYXRoDQo+ ID4+ICAgICAgTkFUIG9yIEZpcmV3YWxsIGJpbmRpbmdzIGR1cmluZyBtaXRpZ2F0aW9uLiAgV2hl biBUQ1AgaXMgdXNlZCBhcw0KPiA+PiAgICAgIHRyYW5zcG9ydCwgdGhlIERPVFMgc2lnbmFsIGNo YW5uZWwgaGVhcnRiZWF0IG1lc3NhZ2VzIG5lZWQgdG8gYmUNCj4gPj4gICAgICBmcmVxdWVudCBl bm91Z2ggdG8gbWFpbnRhaW4gdGhlIFRDUCBjb25uZWN0aW9uIHN0YXRlLiINCj4gPj4NCj4gPj4g QXMgSm9lIGNvbW1lbnRlZCBhbHJlYWR5LCBkaWZmZXJlbnQgaGVhcnRiZWF0cyBhdCBkaWZmZXJl bnQgbGF5ZXJzIGNhbiBiZQ0KPiA+PiB1c2VkDQo+ID4+IGF0IHRoZSBzYW1lIHRpbWUgZm9yIGRp ZmZlcmVudCBwdXJwb3Nlcy4gWW91IGNhbiB1c2UgaGVhcnRiZWF0cyBhdCB0aGUNCj4gPj4gYXBw bGljYXRpb24gbGF5ZXIgdG8gY2hlY2sgc2VydmljZSBhdmFpbGFiaWxpdHkgd2hpbGUgZS5nLiB1 c2luZyBhIGhpZ2hlcg0KPiA+PiBmcmVxdWVudCBoZWFydGJlYXQgYXQgdGhlIHRyYW5zcG9ydCBs YXllciB0byBtYWludGFpbiBmaXJld2FsbCBhbmQgTkFUDQo+IHN0YXRlLg0KPiA+DQo+ID4gW01l ZF0gUGxlYXNlIG5vdGUgdGhhdCB0aGUgdGV4dCB5b3UgcXVvdGVkIGlzIGFib3V0ICJkdXJpbmcg YWN0aXZlDQo+IG1pdGlnYXRpb24iLiBXaGVuIG5vIGF0dGFjayBpcyBvbmdvaW5nLCB3ZSBkbyBo YXZlIHRoZSBmb2xsb3dpbmcgYmVoYXZpb3INCj4gd2hpY2ggY292ZXJzIHlvdXIgY29tbWVudDoN Cj4gPg0KPiA+ICAgICAgV2hlbiBET1RTIGFnZW50cyBhcmUgZXhjaGFuZ2luZyBoZWFydGJlYXRz IGFuZCBubw0KPiA+ICAgICAgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGFjdGl2ZSwgZWl0aGVyIGFn ZW50IE1BWSByZXF1ZXN0IGNoYW5nZXMgdG8NCj4gPiAgICAgIHRoZSBoZWFydGJlYXQgcmF0ZS4g IEZvciBleGFtcGxlLCBhIERPVFMgc2VydmVyIG1pZ2h0IHdhbnQgdG8NCj4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4N Cj4gPiAgICAgIHJlZHVjZSBoZWFydGJlYXQgZnJlcXVlbmN5IG9yIGNlYXNlIGhlYXJ0YmVhdCBl eGNoYW5nZXMgd2hlbiBhbg0KPiA+ICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiA+ICAgICAgYWN0aXZlIERPVFMg Y2xpZW50IGhhcyBub3QgcmVxdWVzdGVkIG1pdGlnYXRpb24sIGluIG9yZGVyIHRvDQo+ID4gICAg ICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gPiAg ICAgIGNvbnRyb2wgbG9hZC4NCj4gPg0KPiA+PiBUaGUgYWR2YW50YWdlIHRvIHN1Y2ggYW4gYXBw cm9hY2ggaXMgdGhhdCB0aGVyZSBpcyBsZXNzIGFwcGxpY2F0aW9uIGxheWVyDQo+ID4+IG92ZXJo ZWFkL2xvYWQgZS5nLiBpbiBzY2VuYXJpb3Mgd2hlcmUgaXQgbWlnaHQgYmUgZXhwZW5zaXZlIHRv IHdha2UgdXAgdGhlDQo+ID4+IGFwcGxpY2F0aW9uIG9yIGEgc2VydmVyIGlzIGFscmVhZHkgaGln aGx5IGxvYWRlZC4gQWxzbyBub3RlIHRoYXQgdGhlDQo+IHRpbWUtDQo+ID4+IG91dHMNCj4gPj4g dmFsdWVzIG9mIE5BVHMgYW5kIGZpcmV3YWxscyBvbiB0aGUgcGF0aCBhcmUgdXN1YWxseSB1bmtu b3duLCB0aGVyZWZvcmUgYW4NCj4gPj4gYXBwbGljYXRpb24gY2FuIG5ldmVyIHJlbHkgb24gaGVh cnRiZWF0cyAobm8gbWF0dGVyIGF0IHdoaWNoIGxldmVsKSBhbmQNCj4gbXVzdA0KPiA+PiBiZQ0K PiA+PiBwcmVwYXJlZCB0byB0cnkgdG8gcmVjb25uZWN0IG9uIHRoZSBhcHBsaWNhdGlvbiBsYXll ciBpZiB0aGUgY29ubmVjdGlvbg0KPiA+PiBmYWlscy4NCj4gPj4gVXN1YWxseSwgdGhlIG1haW4g cmVhc29uIGZvciB1c2luZyBoZWFydGJlYXRzIHRvIG1haW50YWluIE5BVCBvciBmaXJld2FsbA0K PiA+PiBzdGF0ZQ0KPiA+PiAodnMuIHJlY29ubmVjdCBldmVyeSB0aW1lKSBpbiBUQ1AgaXMgaWYg dGhlIGFwcGxpY2F0aW9uIGlzIHRpbWUtc2Vuc2l0aXZlDQo+IGFuZA0KPiA+PiBhDQo+ID4+IGZ1 bGwgVENQIGhhbmRzaGFrZSB0YWtlcyB0b28gbG9uZyBmb3IgdGhlIGRlc2lyZWQgc2VydmljZS4g SSdtIG5vdCBzdXJlDQo+IHRoYXQNCj4gPj4gdGhlIGNhc2UgZm9yIERPVFMsIGhvd2V2ZXIsIEkg dW5kZXJzdGFuZCBpdCBtYXkgYmUgYmVuZWZpY2lhbCB0byBoYXZlDQo+ID4+IGVzdGFibGlzaGVk IHN0YXRlIGlmIGFuIGF0dGFjayBpcyBvbi1nb2luZy4NCj4gPg0KPiA+IFtNZWRdIFRoaXMgaXMg aW1wb3J0YW50IHRvIGF2b2lkIG5ldyBoYW5kc2hha2VzIHdoZW4gdGhlIGNsaWVudCBoYXMgdG8N Cj4gcmVxdWVzdCBhIG1pdGlnYXRpb24uDQo+IA0KPiBUaGlzIGlzIG9rYXkgYnV0IGNvdWxkIGJl IHNwZWxsZWQgb3V0IG1vcmUgZXhwbGljaXRseSBhcyBhIHJlcXVpcmVtZW50LA0KPiByYXRoZXIg dGhhbiB0YWtpbmcgYWJvdXQgdGhlIGRldGFpbHMgb2Ygc2VuZGluZyBoZWFydGJlYXRzLg0KPiA+ DQo+ID4+DQo+ID4+IEZvciBVRFAgSSBndWVzcyBpdCdzIG1vcmUgY29tcGxpY2F0ZWQgaW4geW91 ciBjYXNlLiBUaW1lLW91dHMgYXJlIHVzdWFsbHkNCj4gPj4gdmVyeQ0KPiA+PiBzaG9ydCwgaG93 ZXZlciwgc3RhdGUgaXMgY3JlYXRlZCB3aXRoIHRoZSBmaXJzdCBwYWNrZXQgb2YgYSBmbG93IChh cyB0aGVyZQ0KPiBpcw0KPiA+PiBubyBoYW5kc2hha2UgaW4gVURQKS4gQXMgeW91IGRvbid0IHNl ZSBibG9ja2luZyBpZiBzdGF0ZSBpcyBleHBpcmVkIGFzIG5ldw0KPiA+PiBzdGF0ZSBpcyBjcmVh dGVkIGltbWVkaWF0ZWx5LCBpdCdzIGtpbmQgb2YgaW1wb3NzaWJsZSB0byBtZWFzdXJlIHRoZQ0K PiA+PiBjb25maWd1cmVkDQo+ID4+IHRpbWUtb3V0IHZhbHVlcy4gT25seSBpZiB0aGUgZmlyZXdh bGwgaXMgdW5kZXIgYXR0YWNrIGl0IHdvdWxkIHN0YXJ0DQo+IGJsb2NraW5nDQo+ID4+IFVEUCB0 cmFmZmljIHRoYXQgaXMgaGFzIG5vIHN0YXRlIGZvciB5ZXQuIFNvIEkgdW5kZXJzdGFuZCB3aHkg aXQgaXMNCj4gZGVzaXJhYmxlDQo+ID4+IHRvIG1haW50YWluIFVEUCBzdGF0ZSBmb3IgeW91LCBo b3dldmVyLCBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHlvdSBjYW4NCj4ga25vdw0KPiA+PiB0aGF0 IHlvdXIgZnJlcXVlbmN5IGlzIGhpZ2ggZW5vdWdoIHRvIGFjdHVhbGx5IGtlZXAgdGhlIHN0YXRl IG9wZW4uIE5vdGUNCj4gdGhhdA0KPiA+PiBUQ1AgdGltZS1vdXRzIGFyZSB1c3VhbGx5IGluIHRo ZSBvcmRlciBvZiBob3Vycywgd2hpbGUgVURQIHRpbWUtb3V0cyBhcmUNCj4gPj4gdXN1YWxseSBp biByYW5nZSBvZiB0ZW5zIG9mIHNlY29uZHMsIGFuZCBtaWdodCBleHBpcmUgZXZlbiBxdWlja2Vy IGlmIGENCj4gPj4gc3lzdGVtDQo+ID4+IGlzIHVuZGVyIGF0dGFjay4gSWYgdGhhdCBpcyBhIHNj ZW5hcmlvIHRoYXQgaXMgaW1wb3J0YW50IGZvciB5b3UsIGFuZA0KPiA+PiBhc3N1bWluZw0KPiA+ PiB0aGF0IG5vdCBhbGwgdGltZS1vdXRzIHZhbHVlcyBvbiB0aGUgcGF0aCBjYW4gYmUga25vd24s IEkgZ3Vlc3MgaXQgd291bGQNCj4gYmUNCj4gPj4gcmVjb21tZW5kYWJsZSB0byB1c2UgVENQIGlu c3RlYWQuDQo+ID4+DQo+ID4+IEluIGFueSBjYXNlIHRoaXMgY2FuIG5vdCBiZSBhIE1VU1QgcmVx dWlyZW1lbnQgKGFzIHRpbWVycyBhcmUgdXN1YWxseSBub3QNCj4gPj4ga25vd24pLiBJIHdvdWxk IHJlY29tbWVuZCB0byBzdGF0ZSBzb21ldGhpbmcgbGlrZToNCj4gPj4NCj4gPj4gIk1BWSBiZSBm cmVxdWVudCBlbm91Z2ggdG8gbWFpbnRhaW4gTkFUIG9yIGZpcmV3YWxsIHN0YXRlLCBpZiB0aW1l ciB2YWx1ZXMNCj4gPj4gYXJlDQo+ID4+IGtub3duLCBvciBpZiBUQ1AgaXMgdXNlZCwgU0hPVUxE IHVzZSBpbiBhZGRpdGlvbiBUQ1AgaGVhcnRiZWF0cyAgdG8NCj4gbWFpbnRhaW4NCj4gPj4gdGhl IFRDUCBjb25uZWN0aW9uIHN0YXRlIGFuZCByZWNvbm5lY3QgaW1tZWRpYXRlbHkgaWYgYSBmYWls dXJlIGlzDQo+IGRldGVjdGVkLiINCj4gPj4NCj4gPg0KPiA+IFtNZWRdIFRoZSBvcmlnaW5hbCB3 b3JkaW5nIGlzIGFjY3VyYXRlIGFuZCByZWZsZWN0cyB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlDQo+ IFdHLiBIb3cgdGhpcyB3aWxsIGJlIGVuZm9yY2VkIGlzIHBhcnQgb2YgdGhlIHNvbHV0aW9uL3Nw ZWNpZmljYXRpb24gc3BhY2UuDQo+IA0KPiBNeSBob2xkIHBvaW50IGhlcmUgaXMgdGhhdA0KPiAN Cj4gIk1VU1QgYmUgZnJlcXVlbnQgZW5vdWdoIHRvIG1haW50YWluIGFueSBvbi1wYXRoIE5BVCBv ciBGaXJld2FsbCBiaW5kaW5ncw0KPiBkdXJpbmcgbWl0aWdhdGlvbi7igJwNCj4gDQo+IGNhbm5v dCBiZSBhIE1VU1QgcmVxdWlyZW1lbnQgYXMgdGhlIG5ldHdvcmsgdGltZS1vdXQgdmFsdWVzIGFy ZSBub3Qga25vd24gYnkNCj4gdGhlIGVuZHBvaW50cy4gVGhlcmVmb3JlIGl0IGlzIGltcG9zc2li bGUgdG8gZnVsZmlsbCB0aGlzIHJlcXVpcmVtZW50Lg0KDQpbTWVkXSBUd28gY29tbWVudHMgaGVy ZTogDQoqIFRoZSByZXF1aXJlbWVudCBjYW4gYmUgZnVsZmlsbGVkIGJ5IHJlbHlpbmcgUkZDODA4 NSByZWNvbW1lbmRhdGlvbnMuIFRoaXMgaXMgZGlzY3Vzc2VkIGluIHRoZSBzcGVjIGRvY3VtZW50 cy4gDQoqIHRoZXJlIGFyZSBkZXBsb3ltZW50cyBpbiB3aGljaCB0aW1lcnMgY2FuIGJlIGRpc2Nv dmVyZWQgKGUuZy4sIFBDUCAoUkZDNjg4NykpLg0KDQo+IA0KPiA+DQo+ID4+IEFuZCBhbHNvIGZv ciB0aGlzIHBhcnQgaXQgaXMgZGlmZmVyZW50IGZvciBUQ1AgYW5kIFVEUDoNCj4gPj4NCj4gPj4g IkJlY2F1c2UgaGVhcnRiZWF0IGxvc3MgaXMgbXVjaCBtb3JlIGxpa2VseSBkdXJpbmcgdm9sdW1l dHJpYyBhdHRhY2ssIERPVFMNCj4gPj4gICAgICBhZ2VudHMgU0hPVUxEIGF2b2lkIHNpZ25hbCBj aGFubmVsIHRlcm1pbmF0aW9uIHdoZW4gbWl0aWdhdGlvbiBpcw0KPiA+PiAgICAgIGFjdGl2ZSBh bmQgaGVhcnRiZWF0cyBhcmUgbm90IHJlY2VpdmVkIGJ5IGVpdGhlciBET1RTIGFnZW50IGZvciBh bg0KPiA+PiAgICAgIGV4dGVuZGVkIHBlcmlvZC4iDQo+ID4+DQo+ID4+IElmIFRDUCB3b3VsZCBi ZSB1c2VkIGFuZCBubyBBQ0tzIGFyZSByZWNlaXZlZCwgVENQIHdvdWxkIHRyeSB0byByZXRyYW5z bWl0DQo+IGENCj4gPj4gZmV3IHRpbWVzIGFuZCBzb21lIHBvaW50IHRlcm1pbmF0ZSB0aGUgY29u bmVjdGlvbi4gSG93ZXZlciwgVURQIGlzIGENCj4gPj4gY29ubmVjdGlvbi1sZXNzIHByb3RvY29s LCB0aGVyZSBpcyBub3RoaW5nIHRvIHRlcm1pbmF0ZS4NCj4gPg0KPiA+IFtNZWRdIFRoZSB0ZXh0 IGlzIGFib3V0ICJzaWduYWwgY2hhbm5lbCB0ZXJtaW5hdGlvbiIuIFRoZSBjb25jZXB0IG9mIERP VFMNCj4gc2Vzc2lvbiBpcyBkZWZpbmVkIGhlcmU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWRvdHMtDQo+IGFyY2hpdGVjdHVyZS0xMSNzZWN0aW9uLTMuMQ0KPiANCj4g T2theSBJIHdhcyBhY3R1YWxseSBtaXNpbnRlcnByZXRpbmcgdGhpcy4gSG93ZXZlciwgSSBhY3R1 YWxseSB0aGluayB0aGlzIGlzDQo+IGdvaW5nIHRvbyBtdWNoIGludG8gdGVjaG5pY2FsIGRldGFp bHMgZm9yIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiBCdXQgcmUtDQo+IHJlYWRpbmcgSSB0aGlu ayB0aGUgcmVxdWlyZW1lbnQgaWYgcmVhbGx5IG5lZWRlZCBvbiB0aGlzIGxldmVsIGlzIG9rYXku DQo+IA0KPiA+DQo+ID4+DQo+ID4+IEFsc28gbm90ZSB0aGF0IGZvciByZWxpYWJsZSB0cmFuc3Bv cnRzLCBpdCBpcyBzdWZmaWNpZW50IGlmIG9uZSBlbmQtaG9zdHMNCj4gPj4gc2VuZHMNCj4gPj4g aGVhcnRiZWF0cyBhcyB0aGUgb3RoZXIgZW5kIGlzIHJlcXVpcmVkIHRvIGFja25vd2xlZGdlIHRo ZSByZWNlcHRpb24gb24NCj4gdGhlDQo+ID4+IHRyYW5zcG9ydCBsYXllciAoYW5kIGlmIG5vIGFj ayBpcyByZWNlaXZlZCB0aGUgY29ubmVjdGlvbiBpcyB0ZXJtaW5hdGVkIG9uDQo+ID4+IHRoZQ0K PiA+PiB0cmFuc3BvcnQgbGF5ZXIpLg0KPiA+Pg0KPiA+PiBTbyBJIGd1ZXNzIHdoYXQgeW91IHdh bnQgdG8gc2F5IGFib3ZlIGlzIHRoYXQgaWYgYSBjb25uZWN0aW9uLWxlc3MNCj4gcHJvdG9jb2wN Cj4gPj4gaXMNCj4gPj4gdXNlZCwgaGVhcnRiZWF0cyBzaG91bGQgY29udGludW91c2x5IGJlIHNl bnQgZXZlbiBpZiBubyBoZWFydGJlYXRzIGFyZQ0KPiA+PiByZWNlaXZlZA0KPiA+PiBmcm9tIHRo ZSBvdGhlciBlbmQuIEhvd2V2ZXIsIEkgdGhpbmsgeW91IHN0aWxsIG5lZWQgdG8gZGVmaW5lIGEN Cj4gdGVybWluYXRpb24NCj4gPj4gY3JpdGVyaWEsIGFzIHlvdSBmb3Igc3VyZSBkb24ndCB3YW50 IHRvIGtlZXAgc2VuZGluZyBoZWFydGJlYXRzIGZvcmV2ZXIuDQo+ID4NCj4gPiBbTWVkXSBBZ3Jl ZS4gT25lIGNvbmRpdGlvbiBpcyBhbHJlYWR5IGNpdGVkIGluIHRoZSBhYm92ZSB0ZXh0OiAid2hl bg0KPiBtaXRpZ2F0aW9uIGlzIGFjdGl2ZSIuIEEgdGVybWluYXRpb24gY3JpdGVyaWEgd291bGQg YmUgdGhhdCB0aGUgbWl0aWdhdGlvbiBpcw0KPiBub3QgYWN0aXZlIGFueW1vcmUuIEhvdyB0ZXJt aW5hdGlvbiBpcyBhY2hpZXZlZCBpcyBwYXJ0IG9mIHRoZSBzb2x1dGlvbg0KPiBzcGFjZS4NCj4g Pg0KPiBPbmUgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbjogSWYgbWl0aWdhdGlvbiBpcyBhY3RpdmUg YW5kIHlvdSBsb29zZSB0aGUNCj4gaGVhcnRiZWF0LCBpcyBpdCBhbHdheXMgdGhlIGNhc2UgdGhh dCB0aGUgbWl0aWdhdGlvbiBlbmRzIGFmdGVyIGEgd2VsbA0KPiBkZWZpbmVkIHRpbWUgb3IgY291 bGQgdGhlIG1pdGlnYXRpb24gZ28gb24g4oCeZm9yZXZlciI/DQo+IA0KDQpbTWVkXSBNaXRpZ2F0 aW9ucyBhcmUgYXNzb2NpYXRlZCB3aXRoIGxpZmV0aW1lcy4gDQoNCj4gDQo+ID4+DQo+ID4+IEFs c28gdGhlIG5leHQgcGFydDoNCj4gPj4NCj4gPj4gIiAgICAgICogIFRvIGhhbmRsZSBwb3NzaWJs ZSBET1RTIHNlcnZlciByZXN0YXJ0IG9yIGNyYXNoLCB0aGUgRE9UUw0KPiA+PiAgICAgICAgIGNs aWVudHMgTUFZIGF0dGVtcHQgdG8gZXN0YWJsaXNoIGEgbmV3IHNpZ25hbCBjaGFubmVsIHNlc3Np b24sDQo+ID4+ICAgICAgICAgYnV0IE1VU1QgY29udGludWUgdG8gc2VuZCBoZWFydGJlYXRzIG9u IHRoZSBjdXJyZW50IHNlc3Npb24gc28NCj4gPj4gICAgICAgICB0aGF0IHRoZSBET1RTIHNlcnZl ciBrbm93cyB0aGUgc2Vzc2lvbiBpcyBzdGlsbCBhbGl2ZS4gIElmIHRoZQ0KPiA+PiAgICAgICAg IG5ldyBzZXNzaW9uIGlzIHN1Y2Nlc3NmdWxseSBlc3RhYmxpc2hlZCwgdGhlIERPVFMgY2xpZW50 IGNhbg0KPiA+PiAgICAgICAgIHRlcm1pbmF0ZSB0aGUgY3VycmVudCBzZXNzaW9uLiINCj4gPj4N Cj4gPj4gVGhlcmUgaXMgbm90aGluZyBsaWtlIGNvbm5lY3Rpb24gcmUtZXN0YWJsaXNoaW5nIGlu IFVEUCwgeW91IGp1c3Qga2VlcA0KPiA+PiBzZW5kaW5nDQo+ID4+IHRyYWZmaWMuDQo+ID4NCj4g PiBbTWVkXSBUaGUgdGV4dCBpcyBhYm91dCAic2lnbmFsIGNoYW5uZWwgc2Vzc2lvbuKAnC4NCj4g DQo+IFllcywgbWlzaW50ZXJwcmV0ZWQgdGhhdC4gVGhhdCBzaG91bGQgYmUgb2theS4NCj4gDQo+ ID4NCj4gPiBXaGlsZSBpbiBUQ1AsIGFzIGV4cGxhaW5lZCBhYm92ZSwgdGhlIGNvbm5lY3Rpb24g d2lsbCBiZSB0ZXJtaW5hdGVkDQo+ID4+IGF0DQo+ID4+IHRoZSB0cmFuc3BvcnQgbGF5ZXIgYW5k IHRoZXJlIGlzIG5vIHdheSB0byBrZWVwIHNlbmRpbmcgaGVhcnRiZWF0cyBvbiB0aGUNCj4gPj4g Im9sZCINCj4gPj4gc2Vzc2lvbi4gT3IgZG8gaGF2ZSBzb21ldGhpbmcgbGlrZSBEVExTIGluIG1p bmQgaW4gdGhpcyBjYXNlPw0KPiA+DQo+ID4gW01lZF0gWWVzLg0KPiA+DQo+ID4+DQo+ID4+IDMp IEluIFNJRy0wMDYgeW91IHNheToNCj4gPj4gIiAgICAgIER1ZSB0byB0aGUgaGlnaGVyIGxpa2Vs aWhvb2Qgb2YgcGFja2V0IGxvc3MgZHVyaW5nIGEgRERvUyBhdHRhY2ssDQo+ID4+ICAgICAgRE9U UyBzZXJ2ZXJzIE1VU1QgcmVndWxhcmx5IHNlbmQgbWl0aWdhdGlvbiBzdGF0dXMgdG8gYXV0aG9y aXplZA0KPiA+PiAgICAgIERPVFMgY2xpZW50cyB3aGljaCBoYXZlIHJlcXVlc3RlZCBhbmQgYmVl biBncmFudGVkIG1pdGlnYXRpb24sDQo+ID4+ICAgICAgcmVnYXJkbGVzcyBvZiBjbGllbnQgcmVx dWVzdHMgZm9yIG1pdGlnYXRpb24gc3RhdHVzLiINCj4gPj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhh dCB0aGlzIGlzIG9ubHkgdHJ1ZSBpZiBhIG5vdC1yZWxpYWJsZSB0cmFuc3BvcnQgaXMgdXNlZC4g SWYNCj4gYQ0KPiA+PiByZWxpYWJsZSB0cmFuc3BvcnQgaXMgdXNlZCwgZGF0YSBpcyByZWNlaXZl ZCBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwNCj4gd2l0aG91dA0KPiA+PiBsb3NzIChidXQgbWF5 YmUgc29tZSBkZWxheSkgb3IgdGhlIGNvbm5lY3Rpb24gaXMgdGVybWluYXRlZCAoaWYgbG9zcyBp cw0KPiB0b28NCj4gPj4gaGlnaCB0byByZXRyYW5zbWl0IHN1Y2Nlc3NmdWxseSkuDQo+ID4+DQo+ ID4NCj4gPiBbTWVkXSBUaGUgcmVxdWlyZW1lbnQgYXMgd29yZGVkIGlzIE9LLg0KPiANCj4gSSBk aXNhZ3JlZSwgYmVjYXVzZSBhcyBJIHNhaWQgaWYgYSByZWxpYWJsZSB0cmFuc3BvcnQgaXMgdXNl ZCB0aGlzIGlzIG5vdA0KPiB0cnVlLiBNYXliZSB5b3UgY2FuIGFkYXB0IHRoaXMgc2VudGVuY2Ug c2xpZ2h0bHkgdG8gY2xhcmlmeSB0aGF0IHlvdSBwcm9iYWJseQ0KPiBoYWQgYSBzY2VuYXJpbyBp biBtaW5kIHdoZXJlIGFuIHVucmVsaWFibGUgdHJhbnNwb3J0IGlzIHVzZWQuDQoNCltNZWRdIElN SE8sIHRoYXQgcmVxdWlyZW1lbnQgc2hvdWxkIGJlIGxpbmtlZCB3aXRoIHRoaXMgb25lOiANCg0K ICAgU0lHLTAwMSAgVXNlIG9mIENvbW1vbiBUcmFuc3BvcnQgUHJvdG9jb2xzOiBET1RTIE1VU1Qg b3BlcmF0ZSBvdmVyDQogICAgICBjb21tb24gd2lkZWx5IGRlcGxveWVkIGFuZCBzdGFuZGFyZGl6 ZWQgdHJhbnNwb3J0IHByb3RvY29scy4NCiAgICAgIFdoaWxlIGNvbm5lY3Rpb25sZXNzIHRyYW5z cG9ydCBzdWNoIGFzIHRoZSBVc2VyIERhdGFncmFtIFByb3RvY29sDQogICAgICAoVURQKSBbUkZD MDc2OF0gU0hPVUxEIGJlIHVzZWQgZm9yIHRoZSBzaWduYWwgY2hhbm5lbCwgdGhlDQogICAgICBU cmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCAoVENQKSBbUkZDMDc5M10gTUFZIGJlIHVzZWQg aWYNCiAgICAgIG5lY2Vzc2FyeSBkdWUgdG8gbmV0d29yayBwb2xpY3kgb3IgbWlkZGxlYm94IGNh cGFiaWxpdGllcyBvcg0KICAgICAgY29uZmlndXJhdGlvbnMuDQoNCj4gDQo+ID4NCj4gPj4NCj4g Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBDT01NRU5UOg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ DQo+ID4+IE9uZSBlZGl0b3JpYWwgY29tbWVudCBvbiBTRUMtMDAyOg0KPiA+Pg0KPiA+PiAiQSBz ZWN1cml0eSBtZWNoYW5pc20gYXQgdGhlIG5ldHdvcmsgbGF5ZXIgKGUuZy4sDQo+ID4+ICAgICAg VExTKSBpcyB0aHVzIGFkZXF1YXRlIHRvIHByb3ZpZGUgaG9wLWJ5LWhvcCBzZWN1cml0eS4gIElu IG90aGVyDQo+ID4+ICAgICAgd29yZHMsIGVuZC10by1lbmQgc2VjdXJpdHkgaXMgbm90IHJlcXVp cmVkIGZvciBET1RTIHByb3RvY29scy4iDQo+ID4+DQo+ID4+IFRMUyBpcyB0cmFuc3BvcnQgbGF5 ZXIgc2VjdXJpdHkgKG5vdCBuZXR3b3JrIGxheWVyKSBhbmQgdGhlcmVmb3JlIGtub3duIGFzDQo+ ID4+IHByb3ZpZGluZyBlbmQtdG8tZW5kIHNlY3VyaXR5IHdoaWxlIHRoZSB0ZXJtIGhvcC1ieS1o b3AgaXMgdXNlZCBmb3IgZS5nLg0KPiA+PiBJUFNlYy4NCj4gPj4NCj4gPj4gSSB3b3VsZCByZWNv bW1lbmQgdG8gY2hhbmdlIHRoZSB3b3JkaW5nIGhlcmUgaW4gb3JkZXIgdG8gYXZvaWQgY29uZnVz aW9uLA0KPiA+PiBlLmcuDQo+ID4+DQo+ID4+ICJBIHNlY3VyaXR5IG1lY2hhbmlzbSBhdCB0aGUg dHJhbnNwb3J0IGxheWVyIChlLmcuLA0KPiA+PiAgICAgIFRMUykgaXMgdGh1cyBhZGVxdWF0ZSB0 byBwcm92aWRlIHNlY3VyaXR5IGJldHdlZW4gZGlmZmVyZW50IERPVFMNCj4gPj4gYWdlbnRzLg0K PiA+PiAgICAgIEluIG90aGVyIHdvcmRzLCBhIGRpcmVjdCBzZWN1cml0eSBhc3NvY2lhdGlvbiBi ZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5kDQo+ID4+ICAgICAgY2xpZW50LCBleGNsdWRpbmcgYW55IHBy b3h5LCBpcyBub3QgcmVxdWlyZWQgZm9yIERPVFMgcHJvdG9jb2xzLiINCj4gPj4NCj4gPg0KPiA+ IFtNZWRdIEkgZGlzYWdyZWUgd2l0aCB0aGUgbGFzdCBwYXJ0IG9mIHRoZSBwcm9wb3NlZCB3b3Jk aW5nLiBUaGUgRE9UUw0KPiBhcmNoaXRlY3R1cmUgaW52b2x2ZXMgZ2F0ZXdheXMsIGhlbmNlIHRo ZSBob3AtYnktaG9wIHNlY3VyaXR5IG1vZGVsLg0KPiANCj4gVGhpcyBpcyBub3QgYSB0ZWNobmlj YWwgY29tbWVudC4gVGhlIHRlY2huaWNhbCBjb250ZW50IGlzIGNvcnJlY3QuIEhvd2V2ZXIsDQo+ IGFzIEkgc2FpZCBhYm92ZSwgdGhlIHRlcm0gaG9wLWJ5LWhvcCBpcyBhc3NvY2lhdGVkIGJ5IG1h bnkgcGVvcGxlIGluIHRoZQ0KPiBjb21tdW5pdHkgd2l0aCBzb21ldGhpbmcgbGlrZSBJUFNlYywg d2hpbGUgYXBwbGljYXRpb24gbGF5ZXIgZ2F0ZXdheXMgYXJlDQo+IHJhdGhlciBjb25zaWRlcmVk IGFzIGVuZHBvaW50cy4gQWxsIEknbSByZXF1ZXN0aW5nIGlzIHRvIGF2b2lkIHRoZSB0ZXJtcyBl bmQtDQo+IHRvLWVuZCBhbmQgaG9wLWJ5LWhvcCBpbiB0aGlzIGNvbnRleHQgYXMgaXQgbWlnaHQg YmUgY29uZnVzaW5nIHRvIG90aGVycy4NCg0KW01lZF0gV2hhdCBhYm91dD8NCg0KTkVXOg0KICAg ICAgQSBzZWN1cml0eSBtZWNoYW5pc20gYXQgdGhlIHRyYW5zcG9ydCBsYXllciAoZS5nLiwNCiAg ICAgIFRMUykgaXMgdGh1cyBhZGVxdWF0ZSB0byBwcm92aWRlIHNlY3VyaXR5IGJldHdlZW4gcGVl ciBET1RTIGFnZW50cy4NCg0KPiANCj4gTWlyamENCj4gDQo+ID4NCj4gPg0KPiA+PiBBbmQgZmlu YWxseSBvbmUgZ2VuZXJhbCBjb21tZW50Og0KPiA+Pg0KPiA+PiBJIHVuZGVyc3RhbmQgdGhhdCBo YXZpbmcgd2cgIGNvbnNlbnN1cyBmb3IgdGhpcyBkb2N1bWVudCBpcyBpbXBvcnQgdG8NCj4gcHJv Y2VlZA0KPiA+PiB0aGUgd29yayBvZiB0aGUgZ3JvdXAsIGhvd2V2ZXIsIEkgZG9uJ3Qgc2VlIHRo ZSB2YWx1ZSBpbiBhcmNoaXZpbmcgdGhpcw0KPiA+PiBkb2N1bWVudCBpbiB0aGUgSUVURiBSRkMg c2VyaWVzIGFzIGEgc3RhbmQtYWxvbmUgZG9jdW1lbnQuIElmIHRoZSBncm91cA0KPiA+PiB0aGlu a3MNCj4gPj4gZG9jdW1lbnRpbmcgdGhlc2UgcmVxdWlyZW1lbnRzIGZvciBjb25zdW1wdGlvbiBv dXRzaWRlIHRoZSBncm91cCdzIHdvcmsgYXQNCj4gYQ0KPiA+PiBsYXRlciBwb2ludCBpbiB0aW1l IGlzIHZhbHVhYmxlLCBJIHdvdWxkIHJhdGhlciByZWNvbW1lbmQgdG8gYWRkIHRoZQ0KPiA+PiBy ZXNwZWN0aXZlDQo+ID4+IHJlcXVpcmVtZW50cyB0byB0aGUgYXBwZW5kaXggb2YgdGhlIHJlc3Bl Y3RpdmUgcHJvdG9jb2wgc3BlY3MuDQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IERvdHMgbWFpbGluZyBsaXN0DQo+ ID4+IERvdHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzDQoNCg== From nobody Thu Feb 21 04:25:14 2019 Return-Path: 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 6B0F5130F9F; Thu, 21 Feb 2019 04:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 feyJwP2vUrVu; Thu, 21 Feb 2019 04:25:01 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C200130FA5; Thu, 21 Feb 2019 04:25:01 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 444tvv5m2Dz5w49; Thu, 21 Feb 2019 13:24:59 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 444tvv4zTdz1xnt; Thu, 21 Feb 2019 13:24:59 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA4.corporate.adroot.infra.ftgroup ([fe80::4538:d7b0:3c64:8ed3%22]) with mapi id 14.03.0435.000; Thu, 21 Feb 2019 13:24:59 +0100 From: To: "Mirja Kuehlewind (IETF)" , "Teague, Nik" CC: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Thread-Topic: =?utf-8?B?UmU6IFtEb3RzXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJh?= =?utf-8?B?ZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xODogKHdpdGggRElTQ1VTUyBh?= =?utf-8?Q?nd_COMMENT)?= Thread-Index: AQHUydpqmjkDk7Q0KUymxuFXxQ11XqXqKy0A Date: Thu, 21 Feb 2019 12:24:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA232C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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> In-Reply-To: <3089053C-CF9B-491A-ACB0-0BC053C50E88@kuehlewind.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 12:25:04 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIFttYWls dG86aWV0ZkBrdWVobGV3aW5kLm5ldF0NCj4gRW52b3nDqcKgOiBqZXVkaSAyMSBmw6l2cmllciAy MDE5IDEyOjQyDQo+IMOAwqA6IFRlYWd1ZSwgTmlrDQo+IENjwqA6IEJPVUNBREFJUiBNb2hhbWVk IFRHSS9PTE47IGRvdHMtY2hhaXJzQGlldGYub3JnOw0KPiBmcmFuay54aWFsaWFuZ0BodWF3ZWku Y29tOyBkb3RzQGlldGYub3JnOyBUaGUgSUVTRzsgZHJhZnQtaWV0Zi1kb3RzLQ0KPiByZXF1aXJl bWVudHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFJlOiBbRG90c10gTWlyamEgS8O8aGxld2lu ZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3RzLQ0KPiByZXF1aXJlbWVudHMtMTg6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSwNCj4gDQo+IHBsZWFzZSBzZWUgYmVsb3cu DQo+IA0KPiA+IEFtIDIxLjAyLjIwMTkgdW0gMTI6MTggc2NocmllYiBUZWFndWUsIE5payA8bnRl YWd1ZUBWZXJpc2lnbi5jb20+Og0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPg0KPiA+IE9uIDIxIEZl YiAyMDE5LCBhdCAxMDo1OCwgTWlyamEgS3VlaGxld2luZCAoSUVURikgPGlldGZAa3VlaGxld2lu ZC5uZXQ+DQo+IHdyb3RlOg0KPiA+DQo+ID4+Pj4gMykgSW4gU0lHLTAwNiB5b3Ugc2F5Og0KPiA+ Pj4+ICIgICAgICBEdWUgdG8gdGhlIGhpZ2hlciBsaWtlbGlob29kIG9mIHBhY2tldCBsb3NzIGR1 cmluZyBhIEREb1MgYXR0YWNrLA0KPiA+Pj4+ICAgIERPVFMgc2VydmVycyBNVVNUIHJlZ3VsYXJs eSBzZW5kIG1pdGlnYXRpb24gc3RhdHVzIHRvIGF1dGhvcml6ZWQNCj4gPj4+PiAgICBET1RTIGNs aWVudHMgd2hpY2ggaGF2ZSByZXF1ZXN0ZWQgYW5kIGJlZW4gZ3JhbnRlZCBtaXRpZ2F0aW9uLA0K PiA+Pj4+ICAgIHJlZ2FyZGxlc3Mgb2YgY2xpZW50IHJlcXVlc3RzIGZvciBtaXRpZ2F0aW9uIHN0 YXR1cy4iDQo+ID4+Pj4NCj4gPj4+PiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgb25seSB0cnVl IGlmIGEgbm90LXJlbGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkLg0KPiBJZiBhDQo+ID4+Pj4gcmVs aWFibGUgdHJhbnNwb3J0IGlzIHVzZWQsIGRhdGEgaXMgcmVjZWl2ZWQgYXQgdGhlIGFwcGxpY2F0 aW9uIGxldmVsDQo+IHdpdGhvdXQNCj4gPj4+PiBsb3NzIChidXQgbWF5YmUgc29tZSBkZWxheSkg b3IgdGhlIGNvbm5lY3Rpb24gaXMgdGVybWluYXRlZCAoaWYgbG9zcyBpcw0KPiB0b28NCj4gPj4+ PiBoaWdoIHRvIHJldHJhbnNtaXQgc3VjY2Vzc2Z1bGx5KS4NCj4gPj4+Pg0KPiA+Pj4NCj4gPj4+ IFtNZWRdIFRoZSByZXF1aXJlbWVudCBhcyB3b3JkZWQgaXMgT0suDQo+ID4+DQo+ID4+IEkgZGlz YWdyZWUsIGJlY2F1c2UgYXMgSSBzYWlkIGlmIGEgcmVsaWFibGUgdHJhbnNwb3J0IGlzIHVzZWQg dGhpcyBpcyBub3QNCj4gdHJ1ZS4gTWF5YmUgeW91IGNhbiBhZGFwdCB0aGlzIHNlbnRlbmNlIHNs aWdodGx5IHRvIGNsYXJpZnkgdGhhdCB5b3UgcHJvYmFibHkNCj4gaGFkIGEgc2NlbmFyaW8gaW4g bWluZCB3aGVyZSBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkDQo+ID4NCj4gPiBUaGUg a2V5IHBhcnQgaGVyZSBpcyDigJhwYWNrZXTigJkgdnMg4oCYZGF0YeKAmSAtIHBhY2tldHMgd2ls bCBiZSBsb3N0IG9uIGNvbmdlc3RlZA0KPiBsaW5rcyByZWdhcmRsZXNzIG9mIGRhdGEgaW50ZWdy aXR5LiAgVGhpcyBtYXkgZGVncmFkZSBjb25uZWN0aW9uIHJlLQ0KPiBlc3RhYmxpc2htZW50IHdp dGggdGNwIGFuZCBjYXVzZSBkYXRhIGxvc3MgaW4gYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQuDQo+ IA0KPiBZZXMsIHBhY2tldCBsb3NzIGFsc28gb2NjdXJzIGFsc28gd2l0aCByZWxpYWJsZSB0cmFu c3BvcnRzIGFuZCBtaWdodCBsZWFkIHRvDQo+IGNvbm5lY3Rpb24gZmFpbHVyZS4gSG93ZXZlciwg SSBkb27igJl0IHRoaXMgaG93IHRoaXMgcmVxdWlyZW1lbnQgaXMgZGVyaXZlZA0KPiBmcm9tIHRo YXQgZWZmZWN0LiBJZiBJIHVzZSBhIHJlbGlhYmxlIHRyYW5zcG9ydCBhbmQgbXkgY29ubmVjdGlv biBkb2VzIG5vdA0KPiBmYWlsLCBJIGNhbiBiZSBzdXJlIHRoYXQgdGhlIG1pdGlnYXRpb24gc3Rh dHVzIGluZm9ybWF0aW9uIGhhdmUgYmVlbiByZWNlaXZlZA0KPiBjb3JyZWN0bHksIHNvIHdoeSBk byBJIG5lZWQgdG8gcmUtc2VuZCBmcmVxdWVudGx5IHRoZW4/DQoNCltNZWRdIFRoZSB0ZXh0IHlv dSBxdW90ZWQgaXMgbm90IGFib3V0ICJmcmVxdWVudCByZXRyYW5zbWlzc2lvbiIgYnV0IGFib3V0 IHNlbmRpbmcgdXBkYXRlcyByZWxhdGVkIHRvIHRoZSBzdGF0dXMgb2YgYSBtaXRpZ2F0aW9uIGlu IHByb2dyZXNzLiBUaGUgc2VydmVyIGhhcyB0byBzZW5kIHJlZ3VsYXIgbm90aWZpY2F0aW9ucyB0 byB1cGRhdGUgdGhlIGNsaWVudCBhYm91dCB0aGUgc3RhdHVzIG9mIGEgbWl0aWdhdGlvbi4gDQoN Cj4gDQo+IE1pcmphDQo+IA0KPiANCj4gDQoNCg== From nobody Thu Feb 21 05:04:35 2019 Return-Path: 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 978A9129284; Thu, 21 Feb 2019 05:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 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, RCVD_IN_SORBS_WEB=1.5, 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 Sib5WBJk_wLA; Thu, 21 Feb 2019 05:04:20 -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 6E0BC130FA5; Thu, 21 Feb 2019 05:04:18 -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=1550754123; 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=2DRUn4UGtYcJkNs0FZ0JtfwiacK/aePiD5IJw5 eesUM=; b=Wy8tp9fOYgRMVpQYXohqxsaoDwFo5wZTbAKlmiSF 0+ayzZf1h7V+lEzxHWm2/0ZffqCxyVAM7cWQHqc+yjLUCnCcni mOfLKb8ySNIlOV98TTRH8da4EZ2QLc91Y4ci9gygj9D7u02xYP ycvlS1EX5ClmsQnTu3cqz90FEcv4dxI= 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 5b68_87f0_23bc126b_c4e8_4c5e_a941_d3f6bc1e0bee; Thu, 21 Feb 2019 06:02:03 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 06:04:00 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 21 Feb 2019 06:03:59 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 06:03:58 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2517.namprd16.prod.outlook.com (20.177.224.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.18; Thu, 21 Feb 2019 13:03:58 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Thu, 21 Feb 2019 13:03:58 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Mirja Kuehlewind (IETF)" , "Teague, Nik" CC: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Thread-Topic: =?utf-8?B?UmU6IFtEb3RzXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJh?= =?utf-8?B?ZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xODogKHdpdGggRElTQ1VTUyBh?= =?utf-8?Q?nd_COMMENT)?= Thread-Index: AQHUydp28lwXZ6Env0yGO8HD26apx6XqLTUAgAAKZMA= Date: Thu, 21 Feb 2019 13:03:58 +0000 Message-ID: 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> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA232C1@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.76.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ae11c9a0-a1c4-4a37-e4b8-08d697fd0acc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2517; x-ms-traffictypediagnostic: BYAPR16MB2517: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNTE3OzIzOkZRMzBON1p0WnlBLzZVYVhwYlhYcmplMnpk?= =?utf-8?B?U2k5SDNFVWh6RWxVc3gzdEF2QWhnc04wWDFjd1dvR2lxUHhHRXY4N3FhUllj?= =?utf-8?B?ZkVUd1lsQzdidTcrTDhpZFFORkdzZUhQdDAxbkVNamhTY3lOUDZXK1pUSzNw?= =?utf-8?B?OUpMN0dIaTRSZU5zM25tZUNXSzNMZUVkTDlyMElDbVA3dzFyQW1WUXNrbFhZ?= =?utf-8?B?SGRrUC94L3dyajVuaGtpZDgyblRRUm1ZVGwwcnFpTkRvRnVBclhlVjNTcC9F?= =?utf-8?B?dnVwNU44YmtlaitWRE1jWjJwSDRvOWJkNEREMVBPc2craGFkYWMzWEZ6WjZW?= =?utf-8?B?M3hqV2RmWHR6N0taMnliajZMRzRQUDNnUXRMaENUR1NDNFIweXFLZ0xIWWZF?= =?utf-8?B?c3NlWW05aU93Y2NxQUpyZldqWnozQjJLQm94Z1ZycFAzUGNnMFRYdHcrWWlx?= =?utf-8?B?cERCUUlYc3A0R3dyM1czNzRvV2dpNnlJNUIrUENMQkdzamFHTFppb0NYZm1w?= =?utf-8?B?NnhBRUcycjkzTWZIZlN4ZUs0MmNUQzhSTlJtdUVIa3BUcGxnM1JaVVdpWWtm?= =?utf-8?B?ekcwT01iMXE5Vy95cjNPa2lGWnAyMzc1ak1LSytnYkM2c1ZVZmQzU2FTbVc0?= =?utf-8?B?MUVCbitncFhFTUZHdi9ROUtwZDE1TVZWSzBQdDYxckg4VzVXS0NkYktSMlVr?= =?utf-8?B?UTZYcE1ZWndaL0lINW1Ub0ZlbTgwYk1KYTFxY1hYOFhYd0V6NG5WblJhVmF1?= =?utf-8?B?K0psTXZMelJzV2hYOXpmdytkYXRlSHlzZjNLTGUyaCtlZ2F6VnNPVFQ5MkE1?= =?utf-8?B?WDZVQlZaclJjOVd0Uk5RUlBqSytjNU5aRE4ycGM5UDMveDBPL2lnZ0p5cU8r?= =?utf-8?B?QmhmRWp5QlBhWGo2RjZoandFLzU1TGlPSlRtRUZwTHFlREpjWVN3eHpoV0h2?= =?utf-8?B?bHBSQlE5ZlN3S216SklsRWZOTHVZdUh5aFJ3TEVkZ1pVNEtNOVRpVlYxU2RC?= =?utf-8?B?M2NMdEVGMDRXOTl0ZnBKa2liU0FWRTZrMC9zZ2xkZjJRMDBxeUdHQmRmYzZR?= =?utf-8?B?VG5ZR3pJd3JoLzV2RURJWHEzNDVrRFY2WkdqTVdkb0RWMXNTNVpsQ1ZSeEl6?= =?utf-8?B?WlptUitTbGxKOTUwSFBUMldyNUlTY1RiTUZDNDJVend3Nk1FL1RCNEpFMnkw?= =?utf-8?B?Smd1SENmWk0xUFZXcW1Ua005L21rWUZPY2pHQ0tMdFlUQlFhUHpzNENDUXJl?= =?utf-8?B?ZWRXRFYxeW5RVkczYlIxWkJ6OGRKY3c5UEczTEtaSmU5cURFZWNYT3lHdHMr?= =?utf-8?B?dWdmSUZQeVlqQmZnZWJDRUNoTHptZVJHWHR6Smd3TmY4SjhnTGgxa0Fwbldw?= =?utf-8?B?Qm5tck9pcmZDQmZoanhqVm9mTGFmS2x1S2FXUlpoVWhhUGpEa3dNd0JaTDZ4?= =?utf-8?B?RHpVbUdJampaajBFTDZoMVdVTmY0SURUeUJCd2lXVXdUUjgvQ016NXZZZkxy?= =?utf-8?B?WVlzOFB0dlF4UlVpRmd2U3BlZ25uaksvRmVvaWhXY3BGdk1HYWVKU3FycThY?= =?utf-8?B?OXcxak1IM0FYRGZCUk10RGk5Qzl1U1lPRm81dTIrb2V3UWFKWHRld3U1Nzlp?= =?utf-8?B?UkZQZzVyZDhEYzhjZnUvVlNxVUZnY0VFcnk4aTBHTlhUaEl5azlPaktvanRy?= =?utf-8?B?VFAyQ3hHUUxXTzdBTDZuckJ0SENNNDB0SDA3ajN5WldDbWdwbWU4ZW4rSndU?= =?utf-8?B?VmJQTjNSOUlDNWxJN1JtT0ZQRkMvTVcvU3NLREJQNkR6aEFuRzE2VXhGTkgy?= =?utf-8?B?SURTUkxxSzlTVUhmNzRmUXVmQyszZW5YanVWNWJQL215NzVtNUNkTDJEb0or?= =?utf-8?B?VlVxc2lJclhtejNxTUp0QjljTjlINm9JSlpPQmRoOU9oVTZnajVQU1YzOHRH?= =?utf-8?B?V3p4TmszL3hCek5wMlg4V1cvNWFpS01tandSMVNiZWs1Tk1pUk5TMTFXTVU2?= =?utf-8?Q?YbVGD9?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(136003)(366004)(55784004)(199004)(13464003)(32952001)(189003)(7736002)(7696005)(2906002)(81156014)(76176011)(93886005)(53936002)(66574012)(68736007)(78486014)(4326008)(9686003)(224303003)(25786009)(80792005)(5660300002)(81166006)(305945005)(71200400001)(229853002)(71190400001)(8936002)(97736004)(86362001)(74316002)(6436002)(6506007)(186003)(72206003)(26005)(66066001)(6116002)(55016002)(53546011)(106356001)(105586002)(110136005)(486006)(33656002)(11346002)(14454004)(476003)(478600001)(446003)(6246003)(102836004)(99286004)(54906003)(256004)(14444005)(5024004)(316002)(2501003)(3846002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2517; H:BYAPR16MB2790.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: JNLWNXZbv0kQsYuqxucE3IspHELOum2os86YaWqbCMvkoR40T/tcUn7wq774/YE4f50qVW3lexe4VS6NmrGMnzJ3B+YLYZUJ2G7zBiKak9WJP6JUMdnWO0i2VcBgzCbvAxHxeBxpnRxoGrM3dJvfMkrS8RthZWxPzY+tg3JRhBnWWLsAZeJ1nflPYp86KJJB0wMBi4Kj3rBbex/DKYPY5HulQCEnzHlYVbSpKQAfqArRLB+L2z8wasqBGJPoVispj8Z4fAi3l/2+IbJKipF1rT6rUEkUfaKJlPH2WHWsY/7RSVjsIdbKVXY9He/Z0MTmbxdh8Of5I+DxfGAIa+tNryZd6OF7Fy2TgoK1+JBoBOtdfwZHqfm77jT3i0kVSYxz+UDpwO4TgvVHuBBqS5nm2Zwp7gXbjY+yc0bBdUz2AdM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ae11c9a0-a1c4-4a37-e4b8-08d697fd0acc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 13:03:58.1712 (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: BYAPR16MB2517 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 <6488> : inlines <7019> : streams <1813680> : uri <2799928> Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 13:04:27 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMjEsIDIwMTkgNTo1NSBQTQ0KPiBUbzogTWlyamEgS3VlaGxld2luZCAoSUVU RikgPGlldGZAa3VlaGxld2luZC5uZXQ+OyBUZWFndWUsIE5paw0KPiA8bnRlYWd1ZUBWZXJpc2ln bi5jb20+DQo+IENjOiBkb3RzLWNoYWlyc0BpZXRmLm9yZzsgZnJhbmsueGlhbGlhbmdAaHVhd2Vp LmNvbTsgZG90c0BpZXRmLm9yZzsgVGhlIElFU0cNCj4gPGllc2dAaWV0Zi5vcmc+OyBkcmFmdC1p ZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBSZTogW0RvdHNd IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy0NCj4gcmVxdWly ZW1lbnRzLTE4OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gVGhpcyBlbWFpbCBv cmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sg bGlua3Mgb3INCj4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2Vu ZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0KPiBSZS0sDQo+IA0KPiBQbGVh c2Ugc2VlIGlubGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIFttYWls dG86aWV0ZkBrdWVobGV3aW5kLm5ldF0gRW52b3nDqcKgOg0KPiA+IGpldWRpIDIxIGbDqXZyaWVy IDIwMTkgMTI6NDIgw4DCoDogVGVhZ3VlLCBOaWsgQ2PCoDogQk9VQ0FEQUlSIE1vaGFtZWQNCj4g PiBUR0kvT0xOOyBkb3RzLWNoYWlyc0BpZXRmLm9yZzsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNv bTsNCj4gPiBkb3RzQGlldGYub3JnOyBUaGUgSUVTRzsgZHJhZnQtaWV0Zi1kb3RzLSByZXF1aXJl bWVudHNAaWV0Zi5vcmcgT2JqZXQNCj4gPiA6IFJlOiBSZTogW0RvdHNdIE1pcmphIEvDvGhsZXdp bmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy0NCj4gPiByZXF1aXJlbWVudHMtMTg6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IHBsZWFzZSBz ZWUgYmVsb3cuDQo+ID4NCj4gPiA+IEFtIDIxLjAyLjIwMTkgdW0gMTI6MTggc2NocmllYiBUZWFn dWUsIE5payA8bnRlYWd1ZUBWZXJpc2lnbi5jb20+Og0KPiA+ID4NCj4gPiA+IEhpLA0KPiA+ID4N Cj4gPiA+DQo+ID4gPiBPbiAyMSBGZWIgMjAxOSwgYXQgMTA6NTgsIE1pcmphIEt1ZWhsZXdpbmQg KElFVEYpDQo+ID4gPiA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NCj4gPiB3cm90ZToNCj4gPiA+DQo+ ID4gPj4+PiAzKSBJbiBTSUctMDA2IHlvdSBzYXk6DQo+ID4gPj4+PiAiICAgICAgRHVlIHRvIHRo ZSBoaWdoZXIgbGlrZWxpaG9vZCBvZiBwYWNrZXQgbG9zcyBkdXJpbmcgYSBERG9TIGF0dGFjaywN Cj4gPiA+Pj4+ICAgIERPVFMgc2VydmVycyBNVVNUIHJlZ3VsYXJseSBzZW5kIG1pdGlnYXRpb24g c3RhdHVzIHRvIGF1dGhvcml6ZWQNCj4gPiA+Pj4+ICAgIERPVFMgY2xpZW50cyB3aGljaCBoYXZl IHJlcXVlc3RlZCBhbmQgYmVlbiBncmFudGVkIG1pdGlnYXRpb24sDQo+ID4gPj4+PiAgICByZWdh cmRsZXNzIG9mIGNsaWVudCByZXF1ZXN0cyBmb3IgbWl0aWdhdGlvbiBzdGF0dXMuIg0KPiA+ID4+ Pj4NCj4gPiA+Pj4+IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBvbmx5IHRydWUgaWYgYSBub3Qt cmVsaWFibGUgdHJhbnNwb3J0IGlzIHVzZWQuDQo+ID4gSWYgYQ0KPiA+ID4+Pj4gcmVsaWFibGUg dHJhbnNwb3J0IGlzIHVzZWQsIGRhdGEgaXMgcmVjZWl2ZWQgYXQgdGhlIGFwcGxpY2F0aW9uDQo+ ID4gPj4+PiBsZXZlbA0KPiA+IHdpdGhvdXQNCj4gPiA+Pj4+IGxvc3MgKGJ1dCBtYXliZSBzb21l IGRlbGF5KSBvciB0aGUgY29ubmVjdGlvbiBpcyB0ZXJtaW5hdGVkIChpZg0KPiA+ID4+Pj4gbG9z cyBpcw0KPiA+IHRvbw0KPiA+ID4+Pj4gaGlnaCB0byByZXRyYW5zbWl0IHN1Y2Nlc3NmdWxseSku DQo+ID4gPj4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiBbTWVkXSBUaGUgcmVxdWlyZW1lbnQgYXMgd29y ZGVkIGlzIE9LLg0KPiA+ID4+DQo+ID4gPj4gSSBkaXNhZ3JlZSwgYmVjYXVzZSBhcyBJIHNhaWQg aWYgYSByZWxpYWJsZSB0cmFuc3BvcnQgaXMgdXNlZCB0aGlzDQo+ID4gPj4gaXMgbm90DQo+ID4g dHJ1ZS4gTWF5YmUgeW91IGNhbiBhZGFwdCB0aGlzIHNlbnRlbmNlIHNsaWdodGx5IHRvIGNsYXJp ZnkgdGhhdCB5b3UNCj4gPiBwcm9iYWJseSBoYWQgYSBzY2VuYXJpbyBpbiBtaW5kIHdoZXJlIGFu IHVucmVsaWFibGUgdHJhbnNwb3J0IGlzIHVzZWQNCj4gPiA+DQo+ID4gPiBUaGUga2V5IHBhcnQg aGVyZSBpcyDigJhwYWNrZXTigJkgdnMg4oCYZGF0YeKAmSAtIHBhY2tldHMgd2lsbCBiZSBsb3N0 IG9uDQo+ID4gPiBjb25nZXN0ZWQNCj4gPiBsaW5rcyByZWdhcmRsZXNzIG9mIGRhdGEgaW50ZWdy aXR5LiAgVGhpcyBtYXkgZGVncmFkZSBjb25uZWN0aW9uIHJlLQ0KPiA+IGVzdGFibGlzaG1lbnQg d2l0aCB0Y3AgYW5kIGNhdXNlIGRhdGEgbG9zcyBpbiBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydC4N Cj4gPg0KPiA+IFllcywgcGFja2V0IGxvc3MgYWxzbyBvY2N1cnMgYWxzbyB3aXRoIHJlbGlhYmxl IHRyYW5zcG9ydHMgYW5kIG1pZ2h0DQo+ID4gbGVhZCB0byBjb25uZWN0aW9uIGZhaWx1cmUuIEhv d2V2ZXIsIEkgZG9u4oCZdCB0aGlzIGhvdyB0aGlzIHJlcXVpcmVtZW50DQo+ID4gaXMgZGVyaXZl ZCBmcm9tIHRoYXQgZWZmZWN0LiBJZiBJIHVzZSBhIHJlbGlhYmxlIHRyYW5zcG9ydCBhbmQgbXkN Cj4gPiBjb25uZWN0aW9uIGRvZXMgbm90IGZhaWwsIEkgY2FuIGJlIHN1cmUgdGhhdCB0aGUgbWl0 aWdhdGlvbiBzdGF0dXMNCj4gPiBpbmZvcm1hdGlvbiBoYXZlIGJlZW4gcmVjZWl2ZWQgY29ycmVj dGx5LCBzbyB3aHkgZG8gSSBuZWVkIHRvIHJlLXNlbmQNCj4gZnJlcXVlbnRseSB0aGVuPw0KPiAN Cj4gW01lZF0gVGhlIHRleHQgeW91IHF1b3RlZCBpcyBub3QgYWJvdXQgImZyZXF1ZW50IHJldHJh bnNtaXNzaW9uIiBidXQgYWJvdXQNCj4gc2VuZGluZyB1cGRhdGVzIHJlbGF0ZWQgdG8gdGhlIHN0 YXR1cyBvZiBhIG1pdGlnYXRpb24gaW4gcHJvZ3Jlc3MuIFRoZSBzZXJ2ZXIgaGFzDQo+IHRvIHNl bmQgcmVndWxhciBub3RpZmljYXRpb25zIHRvIHVwZGF0ZSB0aGUgY2xpZW50IGFib3V0IHRoZSBz dGF0dXMgb2YgYQ0KPiBtaXRpZ2F0aW9uLg0KDQpJIGhhdmUgbW9kaWZpZWQgdGhlIHRleHQgYXMg Zm9sbG93cyB0byBhZGRyZXNzIHRoZSBjb21tZW50Og0KDQpET1RTIHNlcnZlciBNVVNUIHJlZ3Vs YXJseSBzZW5kIG1pdGlnYXRpb24gc3RhdHVzIHVwZGF0ZXMgdG8gYXV0aG9yaXplZCBET1RTIGNs aWVudHMgd2hpY2ggaGF2ZSByZXF1ZXN0ZWQgYW5kIGJlZW4gZ3JhbnRlZCBtaXRpZ2F0aW9uLiBJ ZiB1bnJlbGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkIGZvciB0aGUgc2lnbmFsIGNoYW5uZWwgcHJv dG9jb2wsIGR1ZSB0byB0aGUgaGlnaGVyIGxpa2VsaWhvb2Qgb2YgcGFja2V0IGxvc3MgZHVyaW5n IGEgRERvUyBhdHRhY2ssIERPVFMgc2VydmVyIE1VU1QgcmVndWxhcmx5IHJldHJhbnNtaXQgbWl0 aWdhdGlvbiBzdGF0dXMuDQoNCi1UaXJ1DQoNCj4gDQo+ID4NCj4gPiBNaXJqYQ0KPiA+DQo+ID4N Cj4gPg0KDQo= From nobody Thu Feb 21 05:40:14 2019 Return-Path: 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 C1969129284; Thu, 21 Feb 2019 05:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m1--r3OngO6G; Thu, 21 Feb 2019 05:40:08 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DE41279E6; Thu, 21 Feb 2019 05:40:08 -0800 (PST) Received: from 200116b82cde9500947f70fc4af24b59.dip.versatel-1u1.de ([2001:16b8:2cde:9500:947f:70fc:4af2:4b59]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gwoa3-0002Wb-M0; Thu, 21 Feb 2019 14:40:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 21 Feb 2019 14:40:02 +0100 Cc: "mohamed.boucadair@orange.com" , "Teague, Nik" , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: "Konda, Tirumaleswar Reddy" X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1550756408;24219637; X-HE-SMSGID: 1gwoa3-0002Wb-M0 Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 13:40:12 -0000 Hi Tiru, please see below. > Am 21.02.2019 um 14:03 schrieb Konda, Tirumaleswar Reddy = : >=20 >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> Sent: Thursday, February 21, 2019 5:55 PM >> To: Mirja Kuehlewind (IETF) ; Teague, Nik >> >> Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; = The IESG >> ; draft-ietf-dots-requirements@ietf.org >> Subject: RE: Re: [Dots] Mirja K=C3=BChlewind's Discuss on = draft-ietf-dots- >> requirements-18: (with DISCUSS and COMMENT) >>=20 >> 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. >>=20 >> Re-, >>=20 >> Please see inline. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] Envoy=C3=A9 = : >>> jeudi 21 f=C3=A9vrier 2019 12:42 =C3=80 : 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=C3=BChlewind's Discuss on draft-ietf-dots- >>> requirements-18: (with DISCUSS and COMMENT) >>>=20 >>> Hi, >>>=20 >>> please see below. >>>=20 >>>> Am 21.02.2019 um 12:18 schrieb Teague, Nik : >>>>=20 >>>> Hi, >>>>=20 >>>>=20 >>>> On 21 Feb 2019, at 10:58, Mirja Kuehlewind (IETF) >>>> >>> wrote: >>>>=20 >>>>>>> 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." >>>>>>>=20 >>>>>>> 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). >>>>>>>=20 >>>>>>=20 >>>>>> [Med] The requirement as worded is OK. >>>>>=20 >>>>> 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 >>>>=20 >>>> The key part here is =E2=80=98packet=E2=80=99 vs =E2=80=98data=E2=80=99= - 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. >>>=20 >>> Yes, packet loss also occurs also with reliable transports and might >>> lead to connection failure. However, I don=E2=80=99t 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? >>=20 >> [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. >=20 > I have modified the text as follows to address the comment: >=20 > 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=E2=80= =99t think there is any kind of acknowledgment mechanism when unreliable = transport is used. There the use of the word =E2=80=9Eretransmit=E2=80=9C = 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.=E2=80=9C ? Mirja >=20 > -Tiru >=20 >>=20 >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >=20 From nobody Thu Feb 21 05:46:23 2019 Return-Path: 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 0D9DE130E67; Thu, 21 Feb 2019 05:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HuGseU2IDGXX; Thu, 21 Feb 2019 05:46:12 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7881279E6; Thu, 21 Feb 2019 05:46:12 -0800 (PST) Received: from 200116b82cde9500947f70fc4af24b59.dip.versatel-1u1.de ([2001:16b8:2cde:9500:947f:70fc:4af2:4b59]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gwofw-0008E8-16; Thu, 21 Feb 2019 14:46:08 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA232A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 21 Feb 2019 14:46:06 +0100 Cc: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6EFF6377-02A4-4D0B-BCF2-313FDB3B18B8@kuehlewind.net> References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA232A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1550756772;6d406a60; X-HE-SMSGID: 1gwofw-0008E8-16 Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 13:46:15 -0000 Hi Med, please see below. > Am 21.02.2019 um 13:17 schrieb mohamed.boucadair@orange.com: >=20 >>>> 2) Also on this text in SIG-004: >>>> "The heartbeat interval during active mitigation could be >>>> negotiable, but MUST be frequent enough to maintain any on-path >>>> NAT or Firewall bindings during mitigation. When TCP is used = as >>>> transport, the DOTS signal channel heartbeat messages need to = be >>>> frequent enough to maintain the TCP connection state." >>>>=20 >>>> As Joe commented already, different heartbeats at different layers = can be >>>> used >>>> at the same time for different purposes. You can use heartbeats at = the >>>> application layer to check service availability while e.g. using a = higher >>>> frequent heartbeat at the transport layer to maintain firewall and = NAT >> state. >>>=20 >>> [Med] Please note that the text you quoted is about "during active >> mitigation". When no attack is ongoing, we do have the following = behavior >> which covers your comment: >>>=20 >>> When DOTS agents are exchanging heartbeats and no >>> mitigation request is active, either agent MAY request changes = to >>> the heartbeat rate. For example, a DOTS server might want to >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> reduce heartbeat frequency or cease heartbeat exchanges when an >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> active DOTS client has not requested mitigation, in order to >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> control load. >>>=20 >>>> The advantage to such an approach is that there is less application = layer >>>> overhead/load e.g. in scenarios where it might be expensive to wake = up the >>>> application or a server is already highly loaded. Also note that = the >> time- >>>> outs >>>> values of NATs and firewalls on the path are usually unknown, = therefore an >>>> application can never rely on heartbeats (no matter at which level) = and >> must >>>> be >>>> prepared to try to reconnect on the application layer if the = connection >>>> fails. >>>> Usually, the main reason for using heartbeats to maintain NAT or = firewall >>>> state >>>> (vs. reconnect every time) in TCP is if the application is = time-sensitive >> and >>>> a >>>> full TCP handshake takes too long for the desired service. I'm not = sure >> that >>>> the case for DOTS, however, I understand it may be beneficial to = have >>>> established state if an attack is on-going. >>>=20 >>> [Med] This is important to avoid new handshakes when the client has = to >> request a mitigation. >>=20 >> This is okay but could be spelled out more explicitly as a = requirement, >> rather than taking about the details of sending heartbeats. >>>=20 >>>>=20 >>>> For UDP I guess it's more complicated in your case. Time-outs are = usually >>>> very >>>> short, however, state is created with the first packet of a flow = (as there >> is >>>> no handshake in UDP). As you don't see blocking if state is expired = as new >>>> state is created immediately, it's kind of impossible to measure = the >>>> configured >>>> time-out values. Only if the firewall is under attack it would = start >> blocking >>>> UDP traffic that is has no state for yet. So I understand why it is >> desirable >>>> to maintain UDP state for you, however, I don't understand how you = can >> know >>>> that your frequency is high enough to actually keep the state open. = Note >> that >>>> TCP time-outs are usually in the order of hours, while UDP = time-outs are >>>> usually in range of tens of seconds, and might expire even quicker = if a >>>> system >>>> is under attack. If that is a scenario that is important for you, = and >>>> assuming >>>> that not all time-outs values on the path can be known, I guess it = would >> be >>>> recommendable to use TCP instead. >>>>=20 >>>> In any case this can not be a MUST requirement (as timers are = usually not >>>> known). I would recommend to state something like: >>>>=20 >>>> "MAY be frequent enough to maintain NAT or firewall state, if timer = values >>>> are >>>> known, or if TCP is used, SHOULD use in addition TCP heartbeats to >> maintain >>>> the TCP connection state and reconnect immediately if a failure is >> detected." >>>>=20 >>>=20 >>> [Med] The original wording is accurate and reflects the requirement = of the >> WG. How this will be enforced is part of the solution/specification = space. >>=20 >> My hold point here is that >>=20 >> "MUST be frequent enough to maintain any on-path NAT or Firewall = bindings >> during mitigation.=E2=80=9C >>=20 >> cannot be a MUST requirement as the network time-out values are not = known by >> the endpoints. Therefore it is impossible to fulfill this = requirement. >=20 > [Med] Two comments here:=20 > * The requirement can be fulfilled by relying RFC8085 recommendations. = This is discussed in the spec documents.=20 RFC8085 provide recommended value and limits, however, this does not = guarantee that the proposed values actually match the time-out values as = deployed on the path. > * there are deployments in which timers can be discovered (e.g., PCP = (RFC6887)). This does not work in all cases and the draft does not seem to require = the usage of anything like this. If a requirement is that the timeout = values MUST be known in the deployed scenario, then that should be = spelled out, however, I assume that is not your intention because that = would limit deployment heavily. Mirja From nobody Thu Feb 21 06:04:14 2019 Return-Path: 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 2FDB1131064; Thu, 21 Feb 2019 06:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 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, RCVD_IN_SORBS_WEB=1.5, 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 d6qN22gFC3UN; Thu, 21 Feb 2019 06:03:56 -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 99E4B13109B; Thu, 21 Feb 2019 06:03:54 -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=1550757698; 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=n1TTVeZ2beGVJSnkGHSTnqpl8b+1zjzZYozQla l5ECM=; b=mO/kpkm7383AYTt2NzDtVRvT7fL4y2RIAb0QHg2M /+WACbFWIA4of9RWGqI6+bprcgDCBVzN1yYHhfBAnHR+hRlLx/ yB8FNTf3jY281NAw7ftYRlybQckwvndSgdzwn9hWTFoQzVKnzb Z0N720tly91a+ew8af2lvs5Gu43Uyfk= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5b68_186f_d829f995_ee5a_4e0a_b183_a142cacd760f; Thu, 21 Feb 2019 07:01:37 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 07:03:02 -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; Thu, 21 Feb 2019 07:03:02 -0700 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 07:03:00 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2552.namprd16.prod.outlook.com (20.177.225.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Thu, 21 Feb 2019 14:03:00 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Thu, 21 Feb 2019 14:03:00 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mirja Kuehlewind (IETF)" CC: "mohamed.boucadair@orange.com" , "Teague, Nik" , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdICBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE4OiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHUyesDP1CNrYXQskG52S/8z8vxv6XqQ+wA Date: Thu, 21 Feb 2019 14:02:59 +0000 Message-ID: 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> In-Reply-To: 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: [122.171.76.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8e759a34-1c3c-41ff-2fd0-08d6980549db x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2552; x-ms-traffictypediagnostic: BYAPR16MB2552: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNTUyOzIzOjQ5Y1dDSnZneE54RjJwTE5CVVRYR3Z6SHFP?= =?utf-8?B?TkJXME42dDVlbGxvdXNOcHlTZm85dkJkREN2cjI0dEVZQ25FZ3RZWVN4NEJt?= =?utf-8?B?cXd5RXhkZ2pvaG55cnJmb3VKaWJjWDhYcllOenI2bm91MjhycHZmVTVnT1hm?= =?utf-8?B?M1Z4NFhEeUJvVnlyTzc0QnV1cTdnRU4wd2R3Ky92L1VnWHJ4RUFLZTJ0VmJE?= =?utf-8?B?a2RTanF5aGNycWc1NWpsV0phd1FHQjY5K285cmI5OFg2bTZwRVZJdXR6VitD?= =?utf-8?B?TDdtWFdkcnBVVDVrRlFEbGhvMW1vQ0NzSVJqOWZlSGtJVC9jcm5VVC80RWd4?= =?utf-8?B?RVYzcjhUeXNMQldjRHlZWTlzRWNhcXZXMzRzMTQ2dXpoenR5aEx1bzcyWXNT?= =?utf-8?B?NmlVb2k4Ujd0cFk0Z2RiQ28yL0xQcnZ1aS9ubStNcHowQ1FKZEVyTWlOUHV3?= =?utf-8?B?a2JiS2tXSVdRMjlMUFNpSVJVM2J1dWNjbjRaWnZXRStDOTNpOFRHYjl5QmRL?= =?utf-8?B?RCtMcWhyc0hhbGw4Ukhjd1Jzd1BRRWFqTUVTWnlGU0tEeHFFazRoQTZEMTB0?= =?utf-8?B?Q0dKUmZoY2wrWjBYNlU3aTh5SWtoUHgxb3FsZ01EdGlINjlyNXB1U0h5TnZU?= =?utf-8?B?LzJuY1Y3eVhpK1VHTDdERzRrZGVrODZGNzNPWGp5NEU4bU9BOWRjbkVaYWNK?= =?utf-8?B?Znl6cHQzOXhqOUhHMExVMk1XUE9ad1ptL1lqL2VlRExBZlZBRDdKd1phR3dQ?= =?utf-8?B?bE9zbGdLZmdWNnJENmlIZ0I1MFpBSzJ3REF1VUV0YzA1WHR3K3BxMzdpREZ3?= =?utf-8?B?VkRHOGdPdW5aN29qVDVQbHhib1JvYmJnY2Z0RGRCRUdpV3ZEZjZ2eWpvSHcr?= =?utf-8?B?bkdENVVGRlRwWnJLb09qNVFHcjZlNDUycTM5Q1grdzJacTI0RThNZ25uUThs?= =?utf-8?B?L2t4ODRqcVIxbXR6dEtxUUtSbTVUYm41eTkrL1IxTS9nSXBYWWowWG96VjVh?= =?utf-8?B?UmdhOEpGeHd4dVJZa2UzMXk5dFMwaXVnTFlzNDdQVHdzQzN4N2NHWTZtNUlE?= =?utf-8?B?bE9tMXd6a0FCcEhrSzhHU2NjZStMd04wazArcHdNc1dhbG8xNndjWTE4dC9J?= =?utf-8?B?amlzVVExbzZBSk1RVjFVUzRlSDNJY1h4eVNidnVvUDFHS3ZHNnhBdzhyak9x?= =?utf-8?B?SmRPUmwzSzJWeERxVXpBTXB1c2VJc1pHTkVqeG9YZkRZalVXMVVBNm1IK0Zj?= =?utf-8?B?RjZZNnZRTGhMcXVaSm84aUxNYnVaTTdjUHJJckxVNHFDVDhhM1RJQ0htZkVt?= =?utf-8?B?aG9nSFl0UzY0dVplUzBsbUJzVC9TYnJGVnk0dmNSbFBNZ3FIRm9oZGs4ZGFG?= =?utf-8?B?bXcyMWthWFlUd05yb29MVm5wWklBKyt6NW9sMGI2MEk5UzZrZ1k3OXRCY0Iy?= =?utf-8?B?dW9ydUNNTG1XQWtpWVZuWEo1VS83ejF5VHZTOWgrVEQ0NEVDRkRPRTdTUmRu?= =?utf-8?B?YUlCUzIyUEhIUE1RdGhFSS8zZGd6VGlTRWNEZy9nd3JmRWE4NEYzSDYrUkdp?= =?utf-8?B?M0dYcXZISmtFSi9CU2JiQWNJOWRlZ2J0cmdpVTIyWlQ3aUpNYTNScjU2aWlQ?= =?utf-8?B?TGJJUXBCWG5BRWdUbGgzWTYySmhJcGVDSXl4dzNjRUxkeFg5YnMxeU51RlVv?= =?utf-8?B?RE51NHpYdDRtcU9VRDdQNFdzbzVGZ0FOb3ZGc1VVRVhDQkFDeVlTdmVTVDVY?= =?utf-8?B?dkpPdnVZSTlteEE1QUJzTWgzaGN0VzN3bm1OQlZnTTROSDlUYWJ6VVJna2JJ?= =?utf-8?B?NnR1VTFGOE1GYjh5WVVPNGpkL29SSjUrUStaV1BodE9oZ0ErZzg0aTRpQWVN?= =?utf-8?B?RGNTQVZySytvTnNoSjlyNk9KaXVOd3hWK0xER2U1MSs2YTRJaVZ5MEdwZWEr?= =?utf-8?Q?Q5XkJ4TbmwJMhXnWtkXtP6jtLZo8ec=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39860400002)(346002)(136003)(32952001)(13464003)(55784004)(189003)(199004)(53936002)(6916009)(229853002)(25786009)(5660300002)(68736007)(55016002)(9686003)(224303003)(26005)(106356001)(97736004)(4326008)(11346002)(6506007)(53546011)(6246003)(105586002)(80792005)(486006)(186003)(72206003)(478600001)(76176011)(33656002)(2906002)(102836004)(14454004)(446003)(6436002)(476003)(66066001)(305945005)(78486014)(71190400001)(316002)(81156014)(86362001)(93886005)(81166006)(54906003)(71200400001)(99286004)(6116002)(8936002)(5024004)(66574012)(7736002)(74316002)(256004)(7696005)(14444005)(3846002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2552; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: rFtlqEMDgVGsGqm+VXbhOiFDxQ/pVDj5Cf9sRcqCvXqJI97jELhQbwTbSZdrkeAmGHm+R4hGSTvMaNNgXXaIIsyW/kuojMxHtZ1KdIfZJTxsmU9WgxiCBuNucgxG5vxVrwSGw/Qwhk5bfqWViyJwHQy6BtrvCgPIfu0A7RW5mNZerLoNkTcxR7d5ZBS/uWmaOK64nS3DatFzyDjzrhiDwmC/VeZr39v9Ax/Y6YkOi7oHKZMoXF2GwWPhq2ILDfJAn0F5iXnBAJRs8bsigS8wbZL8zR2buvBH/IjeJbZpWRSFDOryII6qVWDZtTRGyxpcxotD2ondITujmHwxi6Khtw+IAFzodjgUNrXTBvgJacFrUHzoCRtTUKHaNaGX6kMTfZptWwYYtGV+h4BH51Rqi3s8TxmYhEJCzDtGzCMpQ7I= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8e759a34-1c3c-41ff-2fd0-08d6980549db X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 14:02:59.9622 (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: BYAPR16MB2552 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 <6488> : inlines <7019> : streams <1813684> : uri <2799951> Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:04:05 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaXJqYSBLdWVobGV3aW5kIChJ RVRGKSA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIx LCAyMDE5IDc6MTAgUE0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBUZWFndWUsIE5payA8bnRlYWd1ZUBWZXJpc2lnbi5jb20+Ow0KPiBkb3RzLWNoYWly c0BpZXRmLm9yZzsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTsgZG90c0BpZXRmLm9yZzsgVGhl IElFU0cNCj4gPGllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRG90c10gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0NCj4gMTg6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRo ZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMg c2FmZS4NCj4gDQo+IEhpIFRpcnUsDQo+IA0KPiBwbGVhc2Ugc2VlIGJlbG93Lg0KPiANCj4gPiBB bSAyMS4wMi4yMDE5IHVtIDE0OjAzIHNjaHJpZWIgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0K PiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT46DQo+ID4NCj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbQ0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPj4gU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDIxLCAyMDE5IDU6NTUgUE0NCj4gPj4gVG86IE1pcmphIEt1ZWhsZXdpbmQg KElFVEYpIDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsgVGVhZ3VlLCBOaWsNCj4gPj4gPG50ZWFndWVA VmVyaXNpZ24uY29tPg0KPiA+PiBDYzogZG90cy1jaGFpcnNAaWV0Zi5vcmc7IGZyYW5rLnhpYWxp YW5nQGh1YXdlaS5jb207IGRvdHNAaWV0Zi5vcmc7DQo+ID4+IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPjsgZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50c0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0 OiBSRTogUmU6IFtEb3RzXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LWRvdHMtDQo+ID4+IHJlcXVpcmVtZW50cy0xODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN Cj4gPj4NCj4gPj4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3Jn YW5pemF0aW9uLiBEbyBub3QgY2xpY2sNCj4gPj4gbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1 bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZQ0KPiBjb250ZW50IGlz IHNhZmUuDQo+ID4+DQo+ID4+IFJlLSwNCj4gPj4NCj4gPj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ ID4+DQo+ID4+IENoZWVycywNCj4gPj4gTWVkDQo+ID4+DQo+ID4+PiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4gPj4+IERlIDogTWlyamEgS3VlaGxld2luZCAoSUVURikgW21haWx0bzpp ZXRmQGt1ZWhsZXdpbmQubmV0XSBFbnZvecOpIDoNCj4gPj4+IGpldWRpIDIxIGbDqXZyaWVyIDIw MTkgMTI6NDIgw4AgOiBUZWFndWUsIE5payBDYyA6IEJPVUNBREFJUiBNb2hhbWVkDQo+ID4+PiBU R0kvT0xOOyBkb3RzLWNoYWlyc0BpZXRmLm9yZzsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTsN Cj4gPj4+IGRvdHNAaWV0Zi5vcmc7IFRoZSBJRVNHOyBkcmFmdC1pZXRmLWRvdHMtIHJlcXVpcmVt ZW50c0BpZXRmLm9yZw0KPiA+Pj4gT2JqZXQNCj4gPj4+IDogUmU6IFJlOiBbRG90c10gTWlyamEg S8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3RzLQ0KPiA+Pj4gcmVxdWlyZW1l bnRzLTE4OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+Pj4NCj4gPj4+IEhpLA0KPiA+ Pj4NCj4gPj4+IHBsZWFzZSBzZWUgYmVsb3cuDQo+ID4+Pg0KPiA+Pj4+IEFtIDIxLjAyLjIwMTkg dW0gMTI6MTggc2NocmllYiBUZWFndWUsIE5payA8bnRlYWd1ZUBWZXJpc2lnbi5jb20+Og0KPiA+ Pj4+DQo+ID4+Pj4gSGksDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDIxIEZlYiAyMDE5LCBh dCAxMDo1OCwgTWlyamEgS3VlaGxld2luZCAoSUVURikNCj4gPj4+PiA8aWV0ZkBrdWVobGV3aW5k Lm5ldD4NCj4gPj4+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4+Pj4gMykgSW4gU0lHLTAwNiB5b3Ug c2F5Og0KPiA+Pj4+Pj4+ICIgICAgICBEdWUgdG8gdGhlIGhpZ2hlciBsaWtlbGlob29kIG9mIHBh Y2tldCBsb3NzIGR1cmluZyBhIEREb1MgYXR0YWNrLA0KPiA+Pj4+Pj4+ICAgRE9UUyBzZXJ2ZXJz IE1VU1QgcmVndWxhcmx5IHNlbmQgbWl0aWdhdGlvbiBzdGF0dXMgdG8gYXV0aG9yaXplZA0KPiA+ Pj4+Pj4+ICAgRE9UUyBjbGllbnRzIHdoaWNoIGhhdmUgcmVxdWVzdGVkIGFuZCBiZWVuIGdyYW50 ZWQgbWl0aWdhdGlvbiwNCj4gPj4+Pj4+PiAgIHJlZ2FyZGxlc3Mgb2YgY2xpZW50IHJlcXVlc3Rz IGZvciBtaXRpZ2F0aW9uIHN0YXR1cy4iDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgaXMgb25seSB0cnVlIGlmIGEgbm90LXJlbGlhYmxlIHRyYW5zcG9ydCBpcyB1 c2VkLg0KPiA+Pj4gSWYgYQ0KPiA+Pj4+Pj4+IHJlbGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkLCBk YXRhIGlzIHJlY2VpdmVkIGF0IHRoZSBhcHBsaWNhdGlvbg0KPiA+Pj4+Pj4+IGxldmVsDQo+ID4+ PiB3aXRob3V0DQo+ID4+Pj4+Pj4gbG9zcyAoYnV0IG1heWJlIHNvbWUgZGVsYXkpIG9yIHRoZSBj b25uZWN0aW9uIGlzIHRlcm1pbmF0ZWQgKGlmDQo+ID4+Pj4+Pj4gbG9zcyBpcw0KPiA+Pj4gdG9v DQo+ID4+Pj4+Pj4gaGlnaCB0byByZXRyYW5zbWl0IHN1Y2Nlc3NmdWxseSkuDQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBbTWVkXSBUaGUgcmVxdWlyZW1lbnQgYXMgd29yZGVkIGlzIE9L Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGRpc2FncmVlLCBiZWNhdXNlIGFzIEkgc2FpZCBpZiBhIHJl bGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkIHRoaXMNCj4gPj4+Pj4gaXMgbm90DQo+ID4+PiB0cnVl LiBNYXliZSB5b3UgY2FuIGFkYXB0IHRoaXMgc2VudGVuY2Ugc2xpZ2h0bHkgdG8gY2xhcmlmeSB0 aGF0IHlvdQ0KPiA+Pj4gcHJvYmFibHkgaGFkIGEgc2NlbmFyaW8gaW4gbWluZCB3aGVyZSBhbiB1 bnJlbGlhYmxlIHRyYW5zcG9ydCBpcw0KPiA+Pj4gdXNlZA0KPiA+Pj4+DQo+ID4+Pj4gVGhlIGtl eSBwYXJ0IGhlcmUgaXMg4oCYcGFja2V04oCZIHZzIOKAmGRhdGHigJkgLSBwYWNrZXRzIHdpbGwg YmUgbG9zdCBvbg0KPiA+Pj4+IGNvbmdlc3RlZA0KPiA+Pj4gbGlua3MgcmVnYXJkbGVzcyBvZiBk YXRhIGludGVncml0eS4gIFRoaXMgbWF5IGRlZ3JhZGUgY29ubmVjdGlvbiByZS0NCj4gPj4+IGVz dGFibGlzaG1lbnQgd2l0aCB0Y3AgYW5kIGNhdXNlIGRhdGEgbG9zcyBpbiBhbiB1bnJlbGlhYmxl IHRyYW5zcG9ydC4NCj4gPj4+DQo+ID4+PiBZZXMsIHBhY2tldCBsb3NzIGFsc28gb2NjdXJzIGFs c28gd2l0aCByZWxpYWJsZSB0cmFuc3BvcnRzIGFuZCBtaWdodA0KPiA+Pj4gbGVhZCB0byBjb25u ZWN0aW9uIGZhaWx1cmUuIEhvd2V2ZXIsIEkgZG9u4oCZdCB0aGlzIGhvdyB0aGlzDQo+ID4+PiBy ZXF1aXJlbWVudCBpcyBkZXJpdmVkIGZyb20gdGhhdCBlZmZlY3QuIElmIEkgdXNlIGEgcmVsaWFi bGUNCj4gPj4+IHRyYW5zcG9ydCBhbmQgbXkgY29ubmVjdGlvbiBkb2VzIG5vdCBmYWlsLCBJIGNh biBiZSBzdXJlIHRoYXQgdGhlDQo+ID4+PiBtaXRpZ2F0aW9uIHN0YXR1cyBpbmZvcm1hdGlvbiBo YXZlIGJlZW4gcmVjZWl2ZWQgY29ycmVjdGx5LCBzbyB3aHkNCj4gPj4+IGRvIEkgbmVlZCB0byBy ZS1zZW5kDQo+ID4+IGZyZXF1ZW50bHkgdGhlbj8NCj4gPj4NCj4gPj4gW01lZF0gVGhlIHRleHQg eW91IHF1b3RlZCBpcyBub3QgYWJvdXQgImZyZXF1ZW50IHJldHJhbnNtaXNzaW9uIiBidXQNCj4g Pj4gYWJvdXQgc2VuZGluZyB1cGRhdGVzIHJlbGF0ZWQgdG8gdGhlIHN0YXR1cyBvZiBhIG1pdGln YXRpb24gaW4NCj4gPj4gcHJvZ3Jlc3MuIFRoZSBzZXJ2ZXIgaGFzIHRvIHNlbmQgcmVndWxhciBu b3RpZmljYXRpb25zIHRvIHVwZGF0ZSB0aGUNCj4gPj4gY2xpZW50IGFib3V0IHRoZSBzdGF0dXMg b2YgYSBtaXRpZ2F0aW9uLg0KPiA+DQo+ID4gSSBoYXZlIG1vZGlmaWVkIHRoZSB0ZXh0IGFzIGZv bGxvd3MgdG8gYWRkcmVzcyB0aGUgY29tbWVudDoNCj4gPg0KPiA+IERPVFMgc2VydmVyIE1VU1Qg cmVndWxhcmx5IHNlbmQgbWl0aWdhdGlvbiBzdGF0dXMgdXBkYXRlcyB0byBhdXRob3JpemVkDQo+ IERPVFMgY2xpZW50cyB3aGljaCBoYXZlIHJlcXVlc3RlZCBhbmQgYmVlbiBncmFudGVkIG1pdGln YXRpb24uIElmIHVucmVsaWFibGUNCj4gdHJhbnNwb3J0IGlzIHVzZWQgZm9yIHRoZSBzaWduYWwg Y2hhbm5lbCBwcm90b2NvbCwgZHVlIHRvIHRoZSBoaWdoZXIgbGlrZWxpaG9vZCBvZg0KPiBwYWNr ZXQgbG9zcyBkdXJpbmcgYSBERG9TIGF0dGFjaywgRE9UUyBzZXJ2ZXIgTVVTVCByZWd1bGFybHkg cmV0cmFuc21pdA0KPiBtaXRpZ2F0aW9uIHN0YXR1cy4NCj4gDQo+IFRoYW5rcyEgT25lIHdvcmRp bmcgY29tbWVudCwgdW5sZXNzIEkgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcsIEkgZG9u4oCZdCB0 aGluaw0KPiB0aGVyZSBpcyBhbnkga2luZCBvZiBhY2tub3dsZWRnbWVudCBtZWNoYW5pc20gd2hl biB1bnJlbGlhYmxlIHRyYW5zcG9ydCBpcw0KPiB1c2VkLiBUaGVyZSB0aGUgdXNlIG9mIHRoZSB3 b3JkIOKAnnJldHJhbnNtaXTigJwgc2VlbXMgaXJyaXRhdGluZyBoZXJlLiBEbyB5b3UNCj4gbWF5 YmUgd2FudCB0byBzYXkgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4gDQo+ICJET1RTIHNlcnZlciBN VVNUIHJlZ3VsYXJseSBzZW5kIG1pdGlnYXRpb24gc3RhdHVzIHVwZGF0ZXMgdG8gYXV0aG9yaXpl ZA0KPiBET1RTIGNsaWVudHMgd2hpY2ggaGF2ZSByZXF1ZXN0ZWQgYW5kIGJlZW4gZ3JhbnRlZCBt aXRpZ2F0aW9uLiBJZiB1bnJlbGlhYmxlDQo+IHRyYW5zcG9ydCBpcyB1c2VkIGZvciB0aGUgc2ln bmFsIGNoYW5uZWwgcHJvdG9jb2wsIGR1ZSB0byB0aGUgaGlnaGVyIGxpa2VsaWhvb2Qgb2YNCj4g cGFja2V0IGxvc3MgZHVyaW5nIGEgRERvUyBhdHRhY2ssIERPVFMgc2VydmVyIFNIT1VMRCBzZW5k IG1pdGlnYXRpb24gc3RhdHVzDQo+IHVwZGF0ZXMgbW9yZSBmcmVxdWVudGx5LuKAnA0KDQpUaGUg dXBkYXRlZCBtaXRpZ2F0aW9uIHN0YXR1cyBuZWVkcyB0byBiZSBzZW50IG11bHRpcGxlIHRpbWVz IHRvIGluY3JlYXNlIHRoZSBsaWtlbGluZXNzIG9mIHRoZSBtZXNzYWdlIHJlYWNoaW5nIHRoZSBj bGllbnQsIGFuZCBhbnkgc3BlY2lmaWMgcmVhc29uIGZvciB1c2luZyBTSE9VTEQgaW5zdGVhZCBv ZiBNVVNULiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB1cGRhdGU6IA0KRE9UUyBzZXJ2ZXIgTVVT VCByZWd1bGFybHkgc2VuZCBtaXRpZ2F0aW9uIHN0YXR1cyB1cGRhdGVzIHRvIGF1dGhvcml6ZWQg RE9UUyBjbGllbnRzIHdoaWNoIGhhdmUgcmVxdWVzdGVkIGFuZCBiZWVuIGdyYW50ZWQgbWl0aWdh dGlvbi4gSWYgdW5yZWxpYWJsZSB0cmFuc3BvcnQgaXMgdXNlZCBmb3IgdGhlIHNpZ25hbCBjaGFu bmVsIHByb3RvY29sLCBkdWUgdG8gdGhlIGhpZ2hlciBsaWtlbGlob29kIG9mIHBhY2tldCBsb3Nz IGR1cmluZyBhIEREb1MgYXR0YWNrLCBET1RTIHNlcnZlciBNVVNUIHNlbmQgbWl0aWdhdGlvbiBz dGF0dXMgbXVsdGlwbGUgdGltZXMgYXQgcmVndWxhciBpbnRlcnZhbHMgZm9sbG93aW5nIHRoZSBk YXRhIHRyYW5zbWlzc2lvbiBndWlkZWxpbmVzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMuMS4zIG9m IFtSRkM4MDg1XS4NCg0KLVRpcnUNCg0KPiANCj4gPw0KPiANCj4gTWlyamENCj4gDQo+IA0KPiAN Cj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPj4NCj4gPj4+DQo+ID4+PiBNaXJqYQ0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+DQoNCg== From nobody Thu Feb 21 06:11:19 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF092130FCF; Thu, 21 Feb 2019 06:11:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-dots-requirements@ietf.org, Liang Xia , dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155075827097.8690.6403334025705603554.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2019 06:11:10 -0800 Archived-At: Subject: [Dots] Suresh Krishnan's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:11:11 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-dots-requirements-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think SIG-002 is a bit underspecified. It points to draft-ietf-intarea-frag-fragile as the recommended mechanism for discovering PMTUD, but in fact draft-ietf-intarea-frag-fragile is designed to provide a list of potential solutions and recommendations for application and protocol developers (Section 7.1.). So I expect this document to specify what it intends to do for fragmentation instead of a vague reference. IPv4 does not support a minimum PMTU of 576 as claimed here. RFC791 clearly states that the minimum PMTU is 68 octets. I suggest rewording this to OLD: DOTS implementations MAY rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in [RFC0791] and [RFC1122]. NEW: DOTS implementations MAY assume on a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes as discussed in [RFC0791] and [RFC1122]. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The recommendation of the 1280 byte minimum for IPv6 needs some reasoning and a reference to RFC8200. e.g. something like this would work OLD: If the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for IPv6. NEW: If the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater as specified in [RFC8200]. From nobody Thu Feb 21 06:17:47 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 666FC1279E6; Thu, 21 Feb 2019 06:17:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-dots-requirements@ietf.org, Liang Xia , dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155075865941.8650.17460104991818500820.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2019 06:17:39 -0800 Archived-At: Subject: [Dots] Alissa Cooper's No Objection on draft-ietf-dots-requirements-18: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:17:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dots-requirements-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with others in that this document seems to have been overtaken by events. I agree with the Gen-ART reviewer that the specification of the heartbeat requirements is so detailed that I suspect much of it will be essentially reproduced in the actual solution documents. From nobody Thu Feb 21 06:18:51 2019 Return-Path: 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 AE9C212867A; Thu, 21 Feb 2019 06:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=trHXTgtT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=5OdoMWK3 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 dq1sEk57Pt1Y; Thu, 21 Feb 2019 06:18:40 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6BE1279E6; Thu, 21 Feb 2019 06:18:40 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id A661830B5; Thu, 21 Feb 2019 09:18:38 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 21 Feb 2019 09:18:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=YZ07ZMnatOHyoufL9ZS1mSM 3yo2UFEHE8wjJvbEHsWo=; b=trHXTgtTukeOWtlh8MsP661MC2nCHMnr5fX07uW YDK8NR1JGXtby0HQD4173bDvl0A9OwIMaeyjhVB2LNGnwMHZnWbQAD2ig2XuRUU9 vJu6CNzHndWSQPNIhHN+0/XehZSSBNNU/NHIUZGJzuzXt45xil7mvUKtG7mKl/M3 erZ6Lv5Z47BypFX2UM0aIdNn1FMHA94mm3cYEf1cI7kpZHZqBnJXzxb/JovHqUCy cTNQz5M5ZdOWexDLp+hTq7oyKx/3JjUH2BILUzUAdi/mmmI1FL4Xia8DGiq9YS7A PFKL8U3CpcVXlLku5cczXG+kzAY/klFlO5S5DsHpHBzu50A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=YZ07ZM natOHyoufL9ZS1mSM3yo2UFEHE8wjJvbEHsWo=; b=5OdoMWK3dc2E2r6EqyCquo 8RFez8hcT2FB9lxOZE1cLA2DnqYhrMM5tU4Wo7OoYLvNUqqlQJu0rE/TeBkcBZfL nwGob9jHbJNoQD/+RB4Tx0dJiYIeSq0QPaP3WWk4bapa6eaP0EnLVxVz079dIqZ4 VTKDO68eOu1ZJJV2EFqTN2qjJdc0QuqgBRme13P5PBaYzkIwOGINby3GPwa5o+wo 327bOXJIZZswGbiKXoFtowpnPB0FVsdOfQWyFeWCfPMZfxczdAyyccXKmrBHbPcT Cs4w9po+0MYXD/OLg1CcxoD0liPfWJO/twVJdLnKjv+FGwh0QcJE4UFHZlgc2nIA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdekgdeigeculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppeduje efrdefkedruddujedrieeknecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrges tghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-vpn2-1805.cisco.com (unknown [173.38.117.68]) by mail.messagingengine.com (Postfix) with ESMTPA id D16F9E425A; Thu, 21 Feb 2019 09:18:36 -0500 (EST) From: Alissa Cooper Message-Id: <1C51C4F3-5B18-4F5A-A25D-4A9129E2EE38@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1C67C0C-24F2-402B-91BA-4F88BE28C00A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 21 Feb 2019 09:18:35 -0500 In-Reply-To: Cc: "gen-art@ietf.org" , "draft-ietf-dots-requirements.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" To: "Konda, Tirumaleswar Reddy" , Robert Sparks References: <155007101476.9655.11486107409890423462@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Dots] [Gen-art] Genart telechat review of draft-ietf-dots-requirements-18 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:18:43 -0000 --Apple-Mail=_A1C67C0C-24F2-402B-91BA-4F88BE28C00A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Robert, thanks for your review. I agree about the heartbeat requirements = and said so in my No Objection ballot. Tiru, thanks for your response on = the other point. Alissa > On Feb 14, 2019, at 1:08 AM, Konda, Tirumaleswar Reddy = wrote: >=20 > Hi Robert, >=20 > Please see inline >=20 >> -----Original Message----- >> From: Robert Sparks > >> Sent: Wednesday, February 13, 2019 8:47 PM >> To: gen-art@ietf.org >> Cc: draft-ietf-dots-requirements.all@ietf.org = ; ietf@ietf.org = ; dots@ietf.org >> Subject: Genart telechat review of draft-ietf-dots-requirements-18 >>=20 >> 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. >>=20 >> Reviewer: Robert Sparks >> Review result: Ready with Issues >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area = Review >> Team (Gen-ART) reviews all IETF documents being processed by the IESG = for >> the IETF Chair. Please wait for direction from your document shepherd = or AD >> before posting a new version of the draft. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-dots-requirements-18 >> Reviewer: Robert Sparks >> Review Date: 2019-02-13 >> IETF LC End Date: 2018-11-23 >> IESG Telechat date: 2019-02-21 >>=20 >> Summary: Ready, but with a process issue for the shepherd and AD to = consider. >>=20 >> This version addressed all of my comments on version -16. Thank you. >>=20 >> However, the diff shows that a large number of SHOULDs were changed = to >> MUSTs. >> I'm guessing that was in response to a comment in the TSVART review = of -16. >=20 > Yup. >=20 >> This large scale substitution makes me worry - are they really the = right >> adjustments? Has the group reviewed and agreed to these normative = changes? >=20 > The WG has not identified any qualifying exceptional conditions for = these requirements when the discussing the DOTS protocol and = requirements drafts, hence I updated=20 > these requirements to use MUST. >=20 >>=20 >> As a nit, I'll note that the additional description of heartbeating = creeps into >> specifying protocol rather than requirements. >=20 > The additional text in SIG-004 is added to justify the reason for = using "SHOULD". >=20 > Cheers, > -Tiru=20 >=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_A1C67C0C-24F2-402B-91BA-4F88BE28C00A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Robert, thanks for your review. I agree about the heartbeat = requirements and said so in my No Objection ballot. Tiru, thanks for = your response on the other point.

Alissa

On Feb 14, 2019, at 1:08 AM, = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> wrote:

Hi Robert,

Please see inline

-----Original Message-----
From: Robert Sparks = <rjsparks@nostrum.com>
Sent: Wednesday, = February 13, 2019 8:47 PM
To: gen-art@ietf.org
Cc: draft-ietf-dots-requirements.all@ietf.org; ietf@ietf.org; dots@ietf.org
Subject: Genart telechat review of = draft-ietf-dots-requirements-18

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.

Reviewer: Robert Sparks
Review result: Ready with Issues

I= am the assigned Gen-ART reviewer for this draft. The General Area = Review
Team (Gen-ART) reviews all IETF documents being = processed by the IESG for
the IETF Chair. Please wait for = direction from your document shepherd or AD
before posting = a new version of the draft.

For more = information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dots-requirements-18
Reviewer: Robert Sparks
Review Date: = 2019-02-13
IETF LC End Date: 2018-11-23
IESG = Telechat date: 2019-02-21

Summary: Ready, = but with a process issue for the shepherd and AD to consider.

This version addressed all of my comments on = version -16. Thank you.

However, the diff = shows that a large number of SHOULDs were changed to
MUSTs.
I'm guessing that was in response to a = comment in the TSVART review of -16.

Yup.

This = large scale substitution makes me worry - are they really the right
adjustments? Has the group reviewed and agreed to these = normative changes?

The WG has not identified any qualifying exceptional = conditions for these requirements when the discussing the DOTS protocol = and requirements drafts, hence I updated 
these requirements to use = MUST.


As a nit, I'll note that the additional description of = heartbeating creeps into
specifying protocol rather than = requirements.

The additional text in SIG-004 is added to justify the reason = for using "SHOULD".

Cheers,
-Tiru 



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_A1C67C0C-24F2-402B-91BA-4F88BE28C00A-- From nobody Thu Feb 21 06:23:59 2019 Return-Path: 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 D0DFF130F85; Thu, 21 Feb 2019 06:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 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, RCVD_IN_SORBS_WEB=1.5, 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 D5Pt_jxEmYnp; Thu, 21 Feb 2019 06:23:41 -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 9DDC61279E6; Thu, 21 Feb 2019 06:23:39 -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=1550758885; 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-ms-exchange-purlcount: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=wuSVynCLQj0Ij/qSkZg7kcwNyhkC6TIXn7baap eCjYQ=; b=Hk5jHo4pEAuFENKvHi3WiwZ3O56CrvFeNiLcShnJ Awhwp8I8YuRXbX4aQ0H5fVijAZSKABPq2ztpChlZKZ5k5GkU6L wYRV5N+Yt5yQ49ZNga3EImmVMmGttOPfOPbWs2iSdGwBjUmi3M qF4djyXTIbkAUQ+vIwrGhdYvJz7oFO0= Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5b68_4ddc_d171580a_c0c5_451d_996a_5d18856a0b8b; Thu, 21 Feb 2019 07:21:25 -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; Thu, 21 Feb 2019 07:23:19 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 21 Feb 2019 07:23:20 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 07:23:18 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2886.namprd16.prod.outlook.com (20.178.234.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Thu, 21 Feb 2019 14:23:18 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Thu, 21 Feb 2019 14:23:18 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mirja Kuehlewind (IETF)" , "mohamed.boucadair@orange.com" CC: The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?B?dGYtZG90cy1yZXF1aXJlbWVudHMtMTg6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHUyUVCi/rE6uJSNkeWAAO1fEcJnaXp37GAgAA2h4CAACUg4A== Date: Thu, 21 Feb 2019 14:23:18 +0000 Message-ID: References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> In-Reply-To: <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@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: [122.171.76.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a1de26a2-b073-40de-1fab-08d698081ff2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2886; x-ms-traffictypediagnostic: BYAPR16MB2886: x-ms-exchange-purlcount: 4 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyODg2OzIzOkRkVklVQi9yUmlJVS9iSFZRcndhSUlBbHBJ?= =?utf-8?B?Y1l4VnN4SjB6L1Q5Y3pFVGFvOHpIeDFTVzllMHRwRy9uWkd6ZkhFbktKOTd6?= =?utf-8?B?Wk1IS0didjNtR1JsT2MrUUFUOW5IR1ZQRCtPSTRieTliNW9CZzAwMTVGMmpB?= =?utf-8?B?OXpPQXhiTkM1WFdmYkR2MVJwakRicTZ5VlQrNk03RWNhRGdsOXVQaFRUeDdB?= =?utf-8?B?ZWpjclBCc0hXMUQ1eW9hNlAwTVRPSFJxdG9iRngzZFFhU2FOMlQxYi9LUnRP?= =?utf-8?B?OWE0SlV3TFFoSHJoR21qTmQxY0NYYXI0TWFvbWowQXdWUUlYaXRjSVNPNkVr?= =?utf-8?B?UlJZeDQ4L3pkWVhubWV5ZkdTTVRUNTlLYXlwUnhyb3IrOG5NeUlQTVVCWmJr?= =?utf-8?B?OWtwVEgzSVdJZ2FwNE1hY0g3aTNlQkhld2ZKNDBtUVo3RklqbjZXaDA1YUw2?= =?utf-8?B?TGlRdnNIMjQyYTZUOUUwY2QzcGU1Y3JxZnN3L3Y5dWMxRmZ1Y01QSXdqNGo3?= =?utf-8?B?eFY1N2Vpd0pUdjdRTWxUOTc2WWJiUEdXcGV0dlJjYnl3aGdocSt1eGl2eE5Z?= =?utf-8?B?TXYwVFNwL04wYWY4YmlkUFhoYkFkR0srMENVdXAvWVU2ZXdWZkQwbUI5cEkz?= =?utf-8?B?RWUzU3Y5ZXhiOW01QzZuZCtwK0VGS2l6dmRmbHNHSXFNbkFQbERaSENwdHlJ?= =?utf-8?B?N0Fiek40YTh1UUpZbUlOU1AxcFoxWExCelhuT2RWSC9OLzhLblg3NHlBaktK?= =?utf-8?B?bU5yd0R4VUtMYnprSTZBYW0yUnlibGp0bXl5Z1VKRXMzS1p1bWVuL0R4TXp4?= =?utf-8?B?T0Z0TlJOMHZKMlpHZjZsYjRZSHh5TFBkbGZnQXBCdWpmMmYwQi84dDBrS3Vk?= =?utf-8?B?MzBWS2FTNStyNHhJTEt1bWcvRWt5TG1kSGkxaE9VS2pnQ3hBS3A4NnNZSFBU?= =?utf-8?B?dXZIZTcxcVV4TzVmTU13cUQxOWRHWjRFMjNjUis1K3lkbldpcWM3bHRlR2VJ?= =?utf-8?B?eXpMVVgycTRoTUlLVXpuV1U4bSsrNENidXFzRWVySVc4Ly9SVzNJQ2FPL1h4?= =?utf-8?B?RzFybE9sYS8yclQ3RW92RWVLTWF2NjNtekRSbzA5OWs3SDB3OHovM0dwdlp3?= =?utf-8?B?REtTQnBuNFpSVzROMmk4WVlHNmxiMGFXYzcrL1M3WEd2bWVyVHllZm1OVGU1?= =?utf-8?B?aDFCRTdMRDdtUDJQa1NBVm5wVElzc1I1YitTRHRXTlRqNTk5RUlGdE1SNSsr?= =?utf-8?B?ZnJIWVFjMTE1TzNLdzI2djdNSWhDT3hPTUp6bHRiczFHRGxVTHowdU8wdTN6?= =?utf-8?B?WXZqblA4UVR3SmxiMmx0bHdIZHpJZ2VKdkZQbS9oUVpwcmdPdUxTRENQbWxj?= =?utf-8?B?Ymc1SkxuVTF6VzdnU3dTS1RldnhSeVlmVVRyMG95eDRoNWVGdmtsNHNyU3N3?= =?utf-8?B?eUJ4b0ZOOTlKUFhnN3RWQ2JvaHNGTDBmdGRsT1RSeTIzaVVpcU0wY3pEVVY0?= =?utf-8?B?RS9qZzA2THBXZ0pkd3dlQzkvQVVpMUFpZnNDUGN0Q01CR09PamtNN29wLzdQ?= =?utf-8?B?bm5PRERoOHgycUdKZUg4QStQU05ZWG1lOEk2NGNKWW9wKzlibnR0U0RxL0RK?= =?utf-8?B?dmZaVzh6U3MvckpOMmFlN1hMSUl2S2pqaDQ0TnFpK3lmekFZeEhJaDgyclM0?= =?utf-8?B?eFNmMkJ1NEo5RjcwdDBFRGhjcW5WUUhTaWlzRHNWRE11Y3VoV3R3UkhCM1d2?= =?utf-8?B?VHFvUjNsajUyN01iNTcyYlYxR3ZwTnYxVnkzWnNja0NXYVBtYXZsMXYyOUht?= =?utf-8?B?V0p3dU13YnN3YmRldUd3MjRvdlBuc1JFZmYzYlVQUGRrL2FNM2NGY0dFMkpj?= =?utf-8?B?WUhCWG9LTVhBSFNtTW9MYkhDRmg5TFVmZnZQNVlXYUE1T0dFSDBteVFQYUIw?= =?utf-8?B?MGNabWhqWHhsZGh6N3JzZEhpNzVOZi9KRWY5azFZaXNjYjVMWnBGQ2FWQ0Ja?= =?utf-8?B?QmdFenNDSEl4em5ZTGFSTDZaYVovVTI3YUNGeTU2Kzh2K2Y3UXNTT3dUbkFp?= =?utf-8?Q?I1iw=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(376002)(346002)(39860400002)(32952001)(55784004)(199004)(189003)(13464003)(2906002)(486006)(6306002)(53936002)(476003)(76176011)(8936002)(11346002)(80792005)(33656002)(25786009)(71200400001)(66066001)(9686003)(6246003)(68736007)(99286004)(78486014)(14444005)(71190400001)(5024004)(4326008)(229853002)(55016002)(6436002)(81166006)(81156014)(7736002)(446003)(66574012)(7696005)(256004)(6116002)(74316002)(26005)(224303003)(105586002)(966005)(97736004)(106356001)(5660300002)(102836004)(478600001)(2501003)(72206003)(6506007)(186003)(53546011)(86362001)(305945005)(30864003)(54906003)(316002)(3846002)(110136005)(14454004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2886; H:BYAPR16MB2790.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: ugbW4FU+TZ2FEi44s+p4siejdENOp5ETT//dc51kRDF9JLCd6mOvdR/5FrGochJg5SdeTflUiPOA1f11+X4VqEyT86U0dXrE2Tq6wl/6yHyiTvAOSbQimtk+m9tLxt2N96JvGTP8OB8x5eYCer9s6boPSyU3HZnICFu71S02VDl8nU5zaBVGnnF6z3cf8XrPgCg413h1UmJobNCfgmH+f6fgm6DGWsHSn5MBk+j9v5CFGB1GqDQ24uCfLk661UmejBZiBYBNI2o0ssqTZKkwS9+99j2yRdoElxZsPgD9Zy4jxQ36rJS4u8Ym6EXfiC11GV0dDK6+k7AIwevMEftp/pFjD84T1Nqb0+opaxGl2e1M2VbwvLU/apeed/lFm6ukn4LDzS5CjazM4OfEOdxmNI4FmX9hsXABf++P4GpouDM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a1de26a2-b073-40de-1fab-08d698081ff2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 14:23:18.1284 (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: BYAPR16MB2886 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6488> : inlines <7019> : streams <1813685> : uri <2799957> Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:23:45 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaXJqYSBLdWVobGV3aW5kIChJ RVRGKSA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIx LCAyMDE5IDQ6MjkgUE0NCj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gQ2M6 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGZyYW5r LnhpYWxpYW5nQGh1YXdlaS5jb207IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHNAaWV0Zi5v cmc7DQo+IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEb3RzXSBNaXJqYSBLw7xobGV3 aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLQ0KPiAxODogKHdp dGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9t IG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yDQo+IG9w ZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0 aGUgY29udGVudCBpcyBzYWZlLg0KPiANCj4gSGkgTWVkLA0KPiANCj4gcGxlYXNlIHNlZSBiZWxv dy4NCj4gDQo+ID4gQW0gMjEuMDIuMjAxOSB1bSAwODo0MyBzY2hyaWViIG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb206DQo+ID4NCj4gPiBIaSBNaXJqYSwNCj4gPg0KPiA+IFBsZWFzZSBzZWUg aW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZSA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgTWlyamENCj4gPj4gS8O8aGxld2luZCBFbnZvecOpIDogbWVy Y3JlZGkgMjAgZsOpdnJpZXIgMjAxOSAxODo1NCDDgCA6IFRoZSBJRVNHIENjIDoNCj4gPj4gZG90 cy1jaGFpcnNAaWV0Zi5vcmc7IGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb207IGRyYWZ0LWlldGYt ZG90cy0NCj4gPj4gcmVxdWlyZW1lbnRzQGlldGYub3JnOyBkb3RzQGlldGYub3JnIE9iamV0IDog W0RvdHNdIE1pcmphIEvDvGhsZXdpbmQncw0KPiA+PiBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90 cy1yZXF1aXJlbWVudHMtMTg6DQo+ID4+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4+ DQo+ID4+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTg6IERpc2N1 c3MNCj4gPj4NCj4gPj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+PiB0aGlzIGlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVhc2Ug cmVmZXIgdG8NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy1jcml0ZXJpYS5odG1sDQo+ID4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXJl cXVpcmVtZW50cy8NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0N Cj4gPj4gRElTQ1VTUzoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4gVGhh bmtzIGZvciBhZGRyZXNzaW5nIHRoZSBUU1YtQVJUIGNvbW1lbnRzIChhbmQgdGhhbmtzIEpvZSBm b3IgdGhlDQo+IHJldmlldykhDQo+ID4+IEluLWxpbmUgd2l0aCBKb2UncyBjb21tZW50LCBwbGVh c2Ugc2VlIHNvbWUgYWRkaXRpb25hbCBjb21tZW50cyBiZWxvdy4NCj4gPj4NCj4gPj4gMSkgT25l IG1pbm9yIGVkaXQgaXMgcmVxdWlyZWQgc3RpbGwgZm9yIFNJRy0wMDI6IGZvciBQTE1UVUQgdGhl DQo+ID4+IGNvcnJlY3QgcmVmZXJlbmNlIGlzIFJGQzQ4MjEsIGhvd2V2ZXIsDQo+ID4NCj4gPiBb TWVkXSBBY3R1YWxseSwgdGhlIGRvY3VtZW50IGlzIHJlZmVycmluZyB0byBkcmFmdC1pZXRmLWlu dGFyZWEtZnJhZy1mcmFnaWxlIGZvcg0KPiBQTVRVRCBtYXR0ZXJzLiBUaGF0IGRvY3VtZW50IGNp dGVzIHRoZSBhcHByb3ByaWF0ZSBkb2N1bWVudHM6IHJmYzgyMDEsDQo+IHJmYzQ4MjEsIGRyYWZ0 LWlldGYtdHN2d2ctZGF0YWdyYW0tcGxwbXR1ZCwgZXRjLg0KPiA+DQo+ID4gYXMgY29tbWVudGVk IGJ5IEpvZSBSRkMxMTkxIGlzIGxlc3MgcmVsaWFibGUNCj4gPg0KPiA+IFtNZWRdIFJGQzExOTEg aXMgY2l0ZWQgdG8ganVzdGlmeSB3aHkgUE1UVSBvZiA1NzYgYnl0ZXMgd2FzIGNob3Nlbi4NCj4g Pg0KPiA+PiBhbmQNCj4gPj4gdGhlcmVmb3JlIHVzdWFsbHkgbm90IHJlY29tbWVuZGVkLiBJIHdv dWxkIHJlY29tbWVuZCB0byByZS1hZGQgYQ0KPiA+PiByZWZlcmVuY2UgdG8NCj4gPj4gUkZDNDgy MSBhbmQgbm8gcmVmZXJlbmNlIHRvIFJGQzExOTEgKG9yIG9ubHkgd2l0aCBhIHdhcm5pbmcgdGhh dA0KPiA+PiBSRkM0ODIxIGlzIHByZWZlcnJlZCBkdWUgdG8gSUNNUCBibG9ja2luZykuIEZ1cnRo ZXIsIHRoZSBjb3JyZWN0DQo+ID4+IHJlZmVyZW5jZSBmb3IgZGF0YWdyYW0gUExNVFVEIGlzIGRy YWZ0LWlldGYtdHN2d2ctZGF0YWdyYW0tcGxwbXR1ZC4NCj4gPg0KPiA+IFtNZWRdIFRoaXMgaXMg YWxyZWFkeSBjaXRlZCBpbiBkcmFmdC1pZXRmLWludGFyZWEtZnJhZy1mcmFnaWxlLiBObyBuZWVk IHRvIGJlDQo+IHJlZHVuZGFudCwgSU1PLg0KPiANCj4gQWN0dWFsbHksIHllcyB0aGlzIGlzIHBy b2JhYmx5IG1vcmUgYW4gZWRpdG9yaWFsIGNvbW1lbnQgZnJvbSBteSBzaWRlLCB0aGF0DQo+IGNp dGluZyByZmM0ODIxIGFuZCBkcmFmdC1pZXRmLXRzdndnLWRhdGFncmFtLXBscG10dWQgZGlyZWN0 bHkgY291bGQgYmUgZ29vZC4NCj4gQnV0IEkgd2lsbCBub3QgaG9sZCBteSBkaXNjdXNzIGZvciB0 aGlzLg0KPiANCj4gPg0KPiA+PiAyKSBBbHNvIG9uIHRoaXMgdGV4dCBpbiBTSUctMDA0Og0KPiA+ PiAiVGhlIGhlYXJ0YmVhdCBpbnRlcnZhbCBkdXJpbmcgYWN0aXZlIG1pdGlnYXRpb24gY291bGQg YmUNCj4gPj4gICAgICBuZWdvdGlhYmxlLCBidXQgTVVTVCBiZSBmcmVxdWVudCBlbm91Z2ggdG8g bWFpbnRhaW4gYW55IG9uLXBhdGgNCj4gPj4gICAgICBOQVQgb3IgRmlyZXdhbGwgYmluZGluZ3Mg ZHVyaW5nIG1pdGlnYXRpb24uICBXaGVuIFRDUCBpcyB1c2VkIGFzDQo+ID4+ICAgICAgdHJhbnNw b3J0LCB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBoZWFydGJlYXQgbWVzc2FnZXMgbmVlZCB0byBi ZQ0KPiA+PiAgICAgIGZyZXF1ZW50IGVub3VnaCB0byBtYWludGFpbiB0aGUgVENQIGNvbm5lY3Rp b24gc3RhdGUuIg0KPiA+Pg0KPiA+PiBBcyBKb2UgY29tbWVudGVkIGFscmVhZHksIGRpZmZlcmVu dCBoZWFydGJlYXRzIGF0IGRpZmZlcmVudCBsYXllcnMNCj4gPj4gY2FuIGJlIHVzZWQgYXQgdGhl IHNhbWUgdGltZSBmb3IgZGlmZmVyZW50IHB1cnBvc2VzLiBZb3UgY2FuIHVzZQ0KPiA+PiBoZWFy dGJlYXRzIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciB0byBjaGVjayBzZXJ2aWNlIGF2YWlsYWJp bGl0eQ0KPiA+PiB3aGlsZSBlLmcuIHVzaW5nIGEgaGlnaGVyIGZyZXF1ZW50IGhlYXJ0YmVhdCBh dCB0aGUgdHJhbnNwb3J0IGxheWVyDQo+ID4+IHRvIG1haW50YWluIGZpcmV3YWxsIGFuZCBOQVQg c3RhdGUuDQo+ID4NCj4gPiBbTWVkXSBQbGVhc2Ugbm90ZSB0aGF0IHRoZSB0ZXh0IHlvdSBxdW90 ZWQgaXMgYWJvdXQgImR1cmluZyBhY3RpdmUgbWl0aWdhdGlvbiIuDQo+IFdoZW4gbm8gYXR0YWNr IGlzIG9uZ29pbmcsIHdlIGRvIGhhdmUgdGhlIGZvbGxvd2luZyBiZWhhdmlvciB3aGljaCBjb3Zl cnMNCj4geW91ciBjb21tZW50Og0KPiA+DQo+ID4gICAgICBXaGVuIERPVFMgYWdlbnRzIGFyZSBl eGNoYW5naW5nIGhlYXJ0YmVhdHMgYW5kIG5vDQo+ID4gICAgICBtaXRpZ2F0aW9uIHJlcXVlc3Qg aXMgYWN0aXZlLCBlaXRoZXIgYWdlbnQgTUFZIHJlcXVlc3QgY2hhbmdlcyB0bw0KPiA+ICAgICAg dGhlIGhlYXJ0YmVhdCByYXRlLiAgRm9yIGV4YW1wbGUsIGEgRE9UUyBzZXJ2ZXIgbWlnaHQgd2Fu dCB0bw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXg0KPiA+ICAgICAgcmVkdWNlIGhlYXJ0YmVhdCBmcmVxdWVuY3kg b3IgY2Vhc2UgaGVhcnRiZWF0IGV4Y2hhbmdlcyB3aGVuIGFuDQo+ID4NCj4gXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiA+ ICAgICAgYWN0aXZlIERPVFMgY2xpZW50IGhhcyBub3QgcmVxdWVzdGVkIG1pdGlnYXRpb24sIGlu IG9yZGVyIHRvDQo+ID4gICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl4NCj4gPiAgICAgIGNvbnRyb2wgbG9hZC4NCj4gPg0KPiA+PiBUaGUgYWR2YW50 YWdlIHRvIHN1Y2ggYW4gYXBwcm9hY2ggaXMgdGhhdCB0aGVyZSBpcyBsZXNzIGFwcGxpY2F0aW9u DQo+ID4+IGxheWVyIG92ZXJoZWFkL2xvYWQgZS5nLiBpbiBzY2VuYXJpb3Mgd2hlcmUgaXQgbWln aHQgYmUgZXhwZW5zaXZlIHRvDQo+ID4+IHdha2UgdXAgdGhlIGFwcGxpY2F0aW9uIG9yIGEgc2Vy dmVyIGlzIGFscmVhZHkgaGlnaGx5IGxvYWRlZC4gQWxzbw0KPiA+PiBub3RlIHRoYXQgdGhlICB0 aW1lLSBvdXRzIHZhbHVlcyBvZiBOQVRzIGFuZCBmaXJld2FsbHMgb24gdGhlIHBhdGgNCj4gPj4g YXJlIHVzdWFsbHkgdW5rbm93biwgdGhlcmVmb3JlIGFuIGFwcGxpY2F0aW9uIGNhbiBuZXZlciBy ZWx5IG9uDQo+ID4+IGhlYXJ0YmVhdHMgKG5vIG1hdHRlciBhdCB3aGljaCBsZXZlbCkgYW5kIG11 c3QgYmUgcHJlcGFyZWQgdG8gdHJ5IHRvDQo+ID4+IHJlY29ubmVjdCBvbiB0aGUgYXBwbGljYXRp b24gbGF5ZXIgaWYgdGhlIGNvbm5lY3Rpb24gZmFpbHMuDQo+ID4+IFVzdWFsbHksIHRoZSBtYWlu IHJlYXNvbiBmb3IgdXNpbmcgaGVhcnRiZWF0cyB0byBtYWludGFpbiBOQVQgb3INCj4gPj4gZmly ZXdhbGwgc3RhdGUgKHZzLiByZWNvbm5lY3QgZXZlcnkgdGltZSkgaW4gVENQIGlzIGlmIHRoZQ0K PiA+PiBhcHBsaWNhdGlvbiBpcyB0aW1lLXNlbnNpdGl2ZSBhbmQgYSBmdWxsIFRDUCBoYW5kc2hh a2UgdGFrZXMgdG9vIGxvbmcNCj4gPj4gZm9yIHRoZSBkZXNpcmVkIHNlcnZpY2UuIEknbSBub3Qg c3VyZSB0aGF0IHRoZSBjYXNlIGZvciBET1RTLA0KPiA+PiBob3dldmVyLCBJIHVuZGVyc3RhbmQg aXQgbWF5IGJlIGJlbmVmaWNpYWwgdG8gaGF2ZSBlc3RhYmxpc2hlZCBzdGF0ZQ0KPiA+PiBpZiBh biBhdHRhY2sgaXMgb24tZ29pbmcuDQo+ID4NCj4gPiBbTWVkXSBUaGlzIGlzIGltcG9ydGFudCB0 byBhdm9pZCBuZXcgaGFuZHNoYWtlcyB3aGVuIHRoZSBjbGllbnQgaGFzIHRvDQo+IHJlcXVlc3Qg YSBtaXRpZ2F0aW9uLg0KPiANCj4gVGhpcyBpcyBva2F5IGJ1dCBjb3VsZCBiZSBzcGVsbGVkIG91 dCBtb3JlIGV4cGxpY2l0bHkgYXMgYSByZXF1aXJlbWVudCwgcmF0aGVyDQo+IHRoYW4gdGFraW5n IGFib3V0IHRoZSBkZXRhaWxzIG9mIHNlbmRpbmcgaGVhcnRiZWF0cy4NCg0KU3VyZSwgdXBkYXRl ZCB0ZXh0IGFzIGZvbGxvd3M6DQoNClRoZSBoZWFydGJlYXQgaW50ZXJ2YWwgZHVyaW5nIGFjdGl2 ZSBtaXRpZ2F0aW9uIGNvdWxkIGJlIG5lZ290aWFibGUsIGJ1dCBpbiBvcmRlciB0byBhdm9pZCBj cnlwdG9ncmFwaGljIGhhbmRzaGFrZSBmb3IgbWl0aWdhdGlvbiByZXF1ZXN0cywgaGVhcnRiZWF0 IGludGVydmFsIE1VU1QgYmUgZnJlcXVlbnQgZW5vdWdoIHRvIA0KbWFpbnRhaW4gYW55IG9uLXBh dGggTkFUIG9yIEZpcmV3YWxsIGJpbmRpbmdzIGR1cmluZyBtaXRpZ2F0aW9uLg0KDQo+ID4NCj4g Pj4NCj4gPj4gRm9yIFVEUCBJIGd1ZXNzIGl0J3MgbW9yZSBjb21wbGljYXRlZCBpbiB5b3VyIGNh c2UuIFRpbWUtb3V0cyBhcmUNCj4gPj4gdXN1YWxseSB2ZXJ5IHNob3J0LCBob3dldmVyLCBzdGF0 ZSBpcyBjcmVhdGVkIHdpdGggdGhlIGZpcnN0IHBhY2tldA0KPiA+PiBvZiBhIGZsb3cgKGFzIHRo ZXJlIGlzIG5vIGhhbmRzaGFrZSBpbiBVRFApLiBBcyB5b3UgZG9uJ3Qgc2VlDQo+ID4+IGJsb2Nr aW5nIGlmIHN0YXRlIGlzIGV4cGlyZWQgYXMgbmV3IHN0YXRlIGlzIGNyZWF0ZWQgaW1tZWRpYXRl bHksDQo+ID4+IGl0J3Mga2luZCBvZiBpbXBvc3NpYmxlIHRvIG1lYXN1cmUgdGhlIGNvbmZpZ3Vy ZWQgdGltZS1vdXQgdmFsdWVzLg0KPiA+PiBPbmx5IGlmIHRoZSBmaXJld2FsbCBpcyB1bmRlciBh dHRhY2sgaXQgd291bGQgc3RhcnQgYmxvY2tpbmcgVURQDQo+ID4+IHRyYWZmaWMgdGhhdCBpcyBo YXMgbm8gc3RhdGUgZm9yIHlldC4gU28gSSB1bmRlcnN0YW5kIHdoeSBpdCBpcw0KPiA+PiBkZXNp cmFibGUgdG8gbWFpbnRhaW4gVURQIHN0YXRlIGZvciB5b3UsIGhvd2V2ZXIsIEkgZG9uJ3QgdW5k ZXJzdGFuZA0KPiA+PiBob3cgeW91IGNhbiBrbm93IHRoYXQgeW91ciBmcmVxdWVuY3kgaXMgaGln aCBlbm91Z2ggdG8gYWN0dWFsbHkga2VlcA0KPiA+PiB0aGUgc3RhdGUgb3Blbi4gTm90ZSB0aGF0 IFRDUCB0aW1lLW91dHMgYXJlIHVzdWFsbHkgaW4gdGhlIG9yZGVyIG9mDQo+ID4+IGhvdXJzLCB3 aGlsZSBVRFAgdGltZS1vdXRzIGFyZSB1c3VhbGx5IGluIHJhbmdlIG9mIHRlbnMgb2Ygc2Vjb25k cywNCj4gPj4gYW5kIG1pZ2h0IGV4cGlyZSBldmVuIHF1aWNrZXIgaWYgYSBzeXN0ZW0gaXMgdW5k ZXIgYXR0YWNrLiBJZiB0aGF0IGlzDQo+ID4+IGEgc2NlbmFyaW8gdGhhdCBpcyBpbXBvcnRhbnQg Zm9yIHlvdSwgYW5kIGFzc3VtaW5nIHRoYXQgbm90IGFsbA0KPiA+PiB0aW1lLW91dHMgdmFsdWVz IG9uIHRoZSBwYXRoIGNhbiBiZSBrbm93biwgSSBndWVzcyBpdCB3b3VsZCBiZQ0KPiA+PiByZWNv bW1lbmRhYmxlIHRvIHVzZSBUQ1AgaW5zdGVhZC4NCj4gPj4NCj4gPj4gSW4gYW55IGNhc2UgdGhp cyBjYW4gbm90IGJlIGEgTVVTVCByZXF1aXJlbWVudCAoYXMgdGltZXJzIGFyZSB1c3VhbGx5DQo+ ID4+IG5vdCBrbm93bikuIEkgd291bGQgcmVjb21tZW5kIHRvIHN0YXRlIHNvbWV0aGluZyBsaWtl Og0KPiA+Pg0KPiA+PiAiTUFZIGJlIGZyZXF1ZW50IGVub3VnaCB0byBtYWludGFpbiBOQVQgb3Ig ZmlyZXdhbGwgc3RhdGUsIGlmIHRpbWVyDQo+ID4+IHZhbHVlcyBhcmUga25vd24sIG9yIGlmIFRD UCBpcyB1c2VkLCBTSE9VTEQgdXNlIGluIGFkZGl0aW9uIFRDUA0KPiA+PiBoZWFydGJlYXRzICB0 byBtYWludGFpbiB0aGUgVENQIGNvbm5lY3Rpb24gc3RhdGUgYW5kIHJlY29ubmVjdA0KPiA+PiBp bW1lZGlhdGVseSBpZiBhIGZhaWx1cmUgaXMgZGV0ZWN0ZWQuIg0KPiA+Pg0KPiA+DQo+ID4gW01l ZF0gVGhlIG9yaWdpbmFsIHdvcmRpbmcgaXMgYWNjdXJhdGUgYW5kIHJlZmxlY3RzIHRoZSByZXF1 aXJlbWVudCBvZiB0aGUNCj4gV0cuIEhvdyB0aGlzIHdpbGwgYmUgZW5mb3JjZWQgaXMgcGFydCBv ZiB0aGUgc29sdXRpb24vc3BlY2lmaWNhdGlvbiBzcGFjZS4NCj4gDQo+IE15IGhvbGQgcG9pbnQg aGVyZSBpcyB0aGF0DQo+IA0KPiAiTVVTVCBiZSBmcmVxdWVudCBlbm91Z2ggdG8gbWFpbnRhaW4g YW55IG9uLXBhdGggTkFUIG9yIEZpcmV3YWxsIGJpbmRpbmdzDQo+IGR1cmluZyBtaXRpZ2F0aW9u LuKAnA0KPiANCj4gY2Fubm90IGJlIGEgTVVTVCByZXF1aXJlbWVudCBhcyB0aGUgbmV0d29yayB0 aW1lLW91dCB2YWx1ZXMgYXJlIG5vdCBrbm93bg0KPiBieSB0aGUgZW5kcG9pbnRzLiBUaGVyZWZv cmUgaXQgaXMgaW1wb3NzaWJsZSB0byBmdWxmaWxsIHRoaXMgcmVxdWlyZW1lbnQuDQo+IA0KPiA+ DQo+ID4+IEFuZCBhbHNvIGZvciB0aGlzIHBhcnQgaXQgaXMgZGlmZmVyZW50IGZvciBUQ1AgYW5k IFVEUDoNCj4gPj4NCj4gPj4gIkJlY2F1c2UgaGVhcnRiZWF0IGxvc3MgaXMgbXVjaCBtb3JlIGxp a2VseSBkdXJpbmcgdm9sdW1ldHJpYyBhdHRhY2ssIERPVFMNCj4gPj4gICAgICBhZ2VudHMgU0hP VUxEIGF2b2lkIHNpZ25hbCBjaGFubmVsIHRlcm1pbmF0aW9uIHdoZW4gbWl0aWdhdGlvbiBpcw0K PiA+PiAgICAgIGFjdGl2ZSBhbmQgaGVhcnRiZWF0cyBhcmUgbm90IHJlY2VpdmVkIGJ5IGVpdGhl ciBET1RTIGFnZW50IGZvciBhbg0KPiA+PiAgICAgIGV4dGVuZGVkIHBlcmlvZC4iDQo+ID4+DQo+ ID4+IElmIFRDUCB3b3VsZCBiZSB1c2VkIGFuZCBubyBBQ0tzIGFyZSByZWNlaXZlZCwgVENQIHdv dWxkIHRyeSB0bw0KPiA+PiByZXRyYW5zbWl0IGEgZmV3IHRpbWVzIGFuZCBzb21lIHBvaW50IHRl cm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4NCj4gPj4gSG93ZXZlciwgVURQIGlzIGEgY29ubmVjdGlv bi1sZXNzIHByb3RvY29sLCB0aGVyZSBpcyBub3RoaW5nIHRvIHRlcm1pbmF0ZS4NCj4gPg0KPiA+ IFtNZWRdIFRoZSB0ZXh0IGlzIGFib3V0ICJzaWduYWwgY2hhbm5lbCB0ZXJtaW5hdGlvbiIuIFRo ZSBjb25jZXB0IG9mDQo+ID4gRE9UUyBzZXNzaW9uIGlzIGRlZmluZWQgaGVyZToNCj4gPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVyZS0xMSNz ZWN0aW9uLTMuDQo+ID4gMQ0KPiANCj4gT2theSBJIHdhcyBhY3R1YWxseSBtaXNpbnRlcnByZXRp bmcgdGhpcy4gSG93ZXZlciwgSSBhY3R1YWxseSB0aGluayB0aGlzIGlzIGdvaW5nDQo+IHRvbyBt dWNoIGludG8gdGVjaG5pY2FsIGRldGFpbHMgZm9yIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiBC dXQgcmUtcmVhZGluZyBJDQo+IHRoaW5rIHRoZSByZXF1aXJlbWVudCBpZiByZWFsbHkgbmVlZGVk IG9uIHRoaXMgbGV2ZWwgaXMgb2theS4NCj4gDQo+ID4NCj4gPj4NCj4gPj4gQWxzbyBub3RlIHRo YXQgZm9yIHJlbGlhYmxlIHRyYW5zcG9ydHMsIGl0IGlzIHN1ZmZpY2llbnQgaWYgb25lDQo+ID4+ IGVuZC1ob3N0cyBzZW5kcyBoZWFydGJlYXRzIGFzIHRoZSBvdGhlciBlbmQgaXMgcmVxdWlyZWQg dG8NCj4gPj4gYWNrbm93bGVkZ2UgdGhlIHJlY2VwdGlvbiBvbiB0aGUgdHJhbnNwb3J0IGxheWVy IChhbmQgaWYgbm8gYWNrIGlzDQo+ID4+IHJlY2VpdmVkIHRoZSBjb25uZWN0aW9uIGlzIHRlcm1p bmF0ZWQgb24gdGhlIHRyYW5zcG9ydCBsYXllcikuDQo+ID4+DQo+ID4+IFNvIEkgZ3Vlc3Mgd2hh dCB5b3Ugd2FudCB0byBzYXkgYWJvdmUgaXMgdGhhdCBpZiBhIGNvbm5lY3Rpb24tbGVzcw0KPiA+ PiBwcm90b2NvbCBpcyB1c2VkLCBoZWFydGJlYXRzIHNob3VsZCBjb250aW51b3VzbHkgYmUgc2Vu dCBldmVuIGlmIG5vDQo+ID4+IGhlYXJ0YmVhdHMgYXJlIHJlY2VpdmVkIGZyb20gdGhlIG90aGVy IGVuZC4gSG93ZXZlciwgSSB0aGluayB5b3UNCj4gPj4gc3RpbGwgbmVlZCB0byBkZWZpbmUgYSB0 ZXJtaW5hdGlvbiBjcml0ZXJpYSwgYXMgeW91IGZvciBzdXJlIGRvbid0DQo+ID4+IHdhbnQgdG8g a2VlcCBzZW5kaW5nIGhlYXJ0YmVhdHMgZm9yZXZlci4NCj4gPg0KPiA+IFtNZWRdIEFncmVlLiBP bmUgY29uZGl0aW9uIGlzIGFscmVhZHkgY2l0ZWQgaW4gdGhlIGFib3ZlIHRleHQ6ICJ3aGVuDQo+ IG1pdGlnYXRpb24gaXMgYWN0aXZlIi4gQSB0ZXJtaW5hdGlvbiBjcml0ZXJpYSB3b3VsZCBiZSB0 aGF0IHRoZSBtaXRpZ2F0aW9uIGlzIG5vdA0KPiBhY3RpdmUgYW55bW9yZS4gSG93IHRlcm1pbmF0 aW9uIGlzIGFjaGlldmVkIGlzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHNwYWNlLg0KPiA+DQo+IE9u ZSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOiBJZiBtaXRpZ2F0aW9uIGlzIGFjdGl2ZSBhbmQgeW91 IGxvb3NlIHRoZSBoZWFydGJlYXQsIGlzDQo+IGl0IGFsd2F5cyB0aGUgY2FzZSB0aGF0IHRoZSBt aXRpZ2F0aW9uIGVuZHMgYWZ0ZXIgYSB3ZWxsIGRlZmluZWQgdGltZSBvciBjb3VsZA0KPiB0aGUg bWl0aWdhdGlvbiBnbyBvbiDigJ5mb3JldmVyIj8NCj4gDQo+IA0KPiA+Pg0KPiA+PiBBbHNvIHRo ZSBuZXh0IHBhcnQ6DQo+ID4+DQo+ID4+ICIgICAgICAqICBUbyBoYW5kbGUgcG9zc2libGUgRE9U UyBzZXJ2ZXIgcmVzdGFydCBvciBjcmFzaCwgdGhlIERPVFMNCj4gPj4gICAgICAgICBjbGllbnRz IE1BWSBhdHRlbXB0IHRvIGVzdGFibGlzaCBhIG5ldyBzaWduYWwgY2hhbm5lbCBzZXNzaW9uLA0K PiA+PiAgICAgICAgIGJ1dCBNVVNUIGNvbnRpbnVlIHRvIHNlbmQgaGVhcnRiZWF0cyBvbiB0aGUg Y3VycmVudCBzZXNzaW9uIHNvDQo+ID4+ICAgICAgICAgdGhhdCB0aGUgRE9UUyBzZXJ2ZXIga25v d3MgdGhlIHNlc3Npb24gaXMgc3RpbGwgYWxpdmUuICBJZiB0aGUNCj4gPj4gICAgICAgICBuZXcg c2Vzc2lvbiBpcyBzdWNjZXNzZnVsbHkgZXN0YWJsaXNoZWQsIHRoZSBET1RTIGNsaWVudCBjYW4N Cj4gPj4gICAgICAgICB0ZXJtaW5hdGUgdGhlIGN1cnJlbnQgc2Vzc2lvbi4iDQo+ID4+DQo+ID4+ IFRoZXJlIGlzIG5vdGhpbmcgbGlrZSBjb25uZWN0aW9uIHJlLWVzdGFibGlzaGluZyBpbiBVRFAs IHlvdSBqdXN0DQo+ID4+IGtlZXAgc2VuZGluZyB0cmFmZmljLg0KPiA+DQo+ID4gW01lZF0gVGhl IHRleHQgaXMgYWJvdXQgInNpZ25hbCBjaGFubmVsIHNlc3Npb27igJwuDQo+IA0KPiBZZXMsIG1p c2ludGVycHJldGVkIHRoYXQuIFRoYXQgc2hvdWxkIGJlIG9rYXkuDQo+IA0KPiA+DQo+ID4gV2hp bGUgaW4gVENQLCBhcyBleHBsYWluZWQgYWJvdmUsIHRoZSBjb25uZWN0aW9uIHdpbGwgYmUgdGVy bWluYXRlZA0KPiA+PiBhdA0KPiA+PiB0aGUgdHJhbnNwb3J0IGxheWVyIGFuZCB0aGVyZSBpcyBu byB3YXkgdG8ga2VlcCBzZW5kaW5nIGhlYXJ0YmVhdHMgb24NCj4gPj4gdGhlICJvbGQiDQo+ID4+ IHNlc3Npb24uIE9yIGRvIGhhdmUgc29tZXRoaW5nIGxpa2UgRFRMUyBpbiBtaW5kIGluIHRoaXMg Y2FzZT8NCj4gPg0KPiA+IFtNZWRdIFllcy4NCj4gPg0KPiA+Pg0KPiA+PiAzKSBJbiBTSUctMDA2 IHlvdSBzYXk6DQo+ID4+ICIgICAgICBEdWUgdG8gdGhlIGhpZ2hlciBsaWtlbGlob29kIG9mIHBh Y2tldCBsb3NzIGR1cmluZyBhIEREb1MgYXR0YWNrLA0KPiA+PiAgICAgIERPVFMgc2VydmVycyBN VVNUIHJlZ3VsYXJseSBzZW5kIG1pdGlnYXRpb24gc3RhdHVzIHRvIGF1dGhvcml6ZWQNCj4gPj4g ICAgICBET1RTIGNsaWVudHMgd2hpY2ggaGF2ZSByZXF1ZXN0ZWQgYW5kIGJlZW4gZ3JhbnRlZCBt aXRpZ2F0aW9uLA0KPiA+PiAgICAgIHJlZ2FyZGxlc3Mgb2YgY2xpZW50IHJlcXVlc3RzIGZvciBt aXRpZ2F0aW9uIHN0YXR1cy4iDQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBv bmx5IHRydWUgaWYgYSBub3QtcmVsaWFibGUgdHJhbnNwb3J0IGlzDQo+ID4+IHVzZWQuIElmIGEg cmVsaWFibGUgdHJhbnNwb3J0IGlzIHVzZWQsIGRhdGEgaXMgcmVjZWl2ZWQgYXQgdGhlDQo+ID4+ IGFwcGxpY2F0aW9uIGxldmVsIHdpdGhvdXQgbG9zcyAoYnV0IG1heWJlIHNvbWUgZGVsYXkpIG9y IHRoZQ0KPiA+PiBjb25uZWN0aW9uIGlzIHRlcm1pbmF0ZWQgKGlmIGxvc3MgaXMgdG9vIGhpZ2gg dG8gcmV0cmFuc21pdCBzdWNjZXNzZnVsbHkpLg0KPiA+Pg0KPiA+DQo+ID4gW01lZF0gVGhlIHJl cXVpcmVtZW50IGFzIHdvcmRlZCBpcyBPSy4NCj4gDQo+IEkgZGlzYWdyZWUsIGJlY2F1c2UgYXMg SSBzYWlkIGlmIGEgcmVsaWFibGUgdHJhbnNwb3J0IGlzIHVzZWQgdGhpcyBpcyBub3QgdHJ1ZS4N Cj4gTWF5YmUgeW91IGNhbiBhZGFwdCB0aGlzIHNlbnRlbmNlIHNsaWdodGx5IHRvIGNsYXJpZnkg dGhhdCB5b3UgcHJvYmFibHkgaGFkIGENCj4gc2NlbmFyaW8gaW4gbWluZCB3aGVyZSBhbiB1bnJl bGlhYmxlIHRyYW5zcG9ydCBpcyB1c2VkLg0KPiANCj4gPg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPj4gLQ0KPiA+PiBDT01NRU5UOg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLQ0KPiA+ Pg0KPiA+PiBPbmUgZWRpdG9yaWFsIGNvbW1lbnQgb24gU0VDLTAwMjoNCj4gPj4NCj4gPj4gIkEg c2VjdXJpdHkgbWVjaGFuaXNtIGF0IHRoZSBuZXR3b3JrIGxheWVyIChlLmcuLA0KPiA+PiAgICAg IFRMUykgaXMgdGh1cyBhZGVxdWF0ZSB0byBwcm92aWRlIGhvcC1ieS1ob3Agc2VjdXJpdHkuICBJ biBvdGhlcg0KPiA+PiAgICAgIHdvcmRzLCBlbmQtdG8tZW5kIHNlY3VyaXR5IGlzIG5vdCByZXF1 aXJlZCBmb3IgRE9UUyBwcm90b2NvbHMuIg0KPiA+Pg0KPiA+PiBUTFMgaXMgdHJhbnNwb3J0IGxh eWVyIHNlY3VyaXR5IChub3QgbmV0d29yayBsYXllcikgYW5kIHRoZXJlZm9yZQ0KPiA+PiBrbm93 biBhcyBwcm92aWRpbmcgZW5kLXRvLWVuZCBzZWN1cml0eSB3aGlsZSB0aGUgdGVybSBob3AtYnkt aG9wIGlzIHVzZWQNCj4gZm9yIGUuZy4NCj4gPj4gSVBTZWMuDQo+ID4+DQo+ID4+IEkgd291bGQg cmVjb21tZW5kIHRvIGNoYW5nZSB0aGUgd29yZGluZyBoZXJlIGluIG9yZGVyIHRvIGF2b2lkDQo+ ID4+IGNvbmZ1c2lvbiwgZS5nLg0KPiA+Pg0KPiA+PiAiQSBzZWN1cml0eSBtZWNoYW5pc20gYXQg dGhlIHRyYW5zcG9ydCBsYXllciAoZS5nLiwNCj4gPj4gICAgICBUTFMpIGlzIHRodXMgYWRlcXVh dGUgdG8gcHJvdmlkZSBzZWN1cml0eSBiZXR3ZWVuIGRpZmZlcmVudCBET1RTDQo+ID4+IGFnZW50 cy4NCj4gPj4gICAgICBJbiBvdGhlciB3b3JkcywgYSBkaXJlY3Qgc2VjdXJpdHkgYXNzb2NpYXRp b24gYmV0d2VlbiB0aGUgc2VydmVyIGFuZA0KPiA+PiAgICAgIGNsaWVudCwgZXhjbHVkaW5nIGFu eSBwcm94eSwgaXMgbm90IHJlcXVpcmVkIGZvciBET1RTIHByb3RvY29scy4iDQo+ID4+DQo+ID4N Cj4gPiBbTWVkXSBJIGRpc2FncmVlIHdpdGggdGhlIGxhc3QgcGFydCBvZiB0aGUgcHJvcG9zZWQg d29yZGluZy4gVGhlIERPVFMNCj4gYXJjaGl0ZWN0dXJlIGludm9sdmVzIGdhdGV3YXlzLCBoZW5j ZSB0aGUgaG9wLWJ5LWhvcCBzZWN1cml0eSBtb2RlbC4NCj4gDQo+IFRoaXMgaXMgbm90IGEgdGVj aG5pY2FsIGNvbW1lbnQuIFRoZSB0ZWNobmljYWwgY29udGVudCBpcyBjb3JyZWN0LiBIb3dldmVy LCBhcyBJDQo+IHNhaWQgYWJvdmUsIHRoZSB0ZXJtIGhvcC1ieS1ob3AgaXMgYXNzb2NpYXRlZCBi eSBtYW55IHBlb3BsZSBpbiB0aGUNCj4gY29tbXVuaXR5IHdpdGggc29tZXRoaW5nIGxpa2UgSVBT ZWMsIHdoaWxlIGFwcGxpY2F0aW9uIGxheWVyIGdhdGV3YXlzIGFyZQ0KPiByYXRoZXIgY29uc2lk ZXJlZCBhcyBlbmRwb2ludHMuIEFsbCBJJ20gcmVxdWVzdGluZyBpcyB0byBhdm9pZCB0aGUgdGVy bXMgZW5kLXRvLQ0KPiBlbmQgYW5kIGhvcC1ieS1ob3AgaW4gdGhpcyBjb250ZXh0IGFzIGl0IG1p Z2h0IGJlIGNvbmZ1c2luZyB0byBvdGhlcnMuDQoNCg0KU0VDLTAwMiBpcyBtb2RpZmllZCBpbiB2 ZXJzaW9uIDE4IHRvIGFkZCBtb3JlIGRldGFpbHMgdG8gYWRkcmVzcyB0aGUgZm9sbG93aW5nIGNv bW1lbnQgZnJvbSBSb2JlcnQgU3BhcmtzIChHZW5hcnQgcmV2aWV3KSA6DQpmcm9tIFBhcmFncmFw aCAzIG9mIFNFQy0wMDI6IFRoaXMgcGFyYWdyYXBoIGRvZXNuJ3QgcmVhZCBhcyBzZW5zaWJseSB3 aGVuIHlvdSBoYXZlIHRoZSBwaWN0dXJlcyBvZiBhZ2dyZWdhdGluZyBnYXRld2F5cyBmcm9tIHRo ZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaW4gbWluZC4NCkRvZXMgaXQgY29uc3RyYWluIHRoZSB0 eXBlcyBvZiBjb25uZWN0aW9ucyB0aGF0IGNhbiBiZSBhZ2dyZWdhdGVkIHRvIHRob3NlIHRoYXQg c2hhcmUgZXF1aXZhbGVudCBzZWN1cml0eSBwcm9wZXJ0aWVzPyBJZiBzbywgaXQgc2hvdWxkIGJl IGV4cGxpY2l0Lg0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IA0KPiBNaXJqYQ0KPiANCj4gPg0KPiA+ DQo+ID4+IEFuZCBmaW5hbGx5IG9uZSBnZW5lcmFsIGNvbW1lbnQ6DQo+ID4+DQo+ID4+IEkgdW5k ZXJzdGFuZCB0aGF0IGhhdmluZyB3ZyAgY29uc2Vuc3VzIGZvciB0aGlzIGRvY3VtZW50IGlzIGlt cG9ydCB0bw0KPiA+PiBwcm9jZWVkIHRoZSB3b3JrIG9mIHRoZSBncm91cCwgaG93ZXZlciwgSSBk b24ndCBzZWUgdGhlIHZhbHVlIGluDQo+ID4+IGFyY2hpdmluZyB0aGlzIGRvY3VtZW50IGluIHRo ZSBJRVRGIFJGQyBzZXJpZXMgYXMgYSBzdGFuZC1hbG9uZQ0KPiA+PiBkb2N1bWVudC4gSWYgdGhl IGdyb3VwIHRoaW5rcyBkb2N1bWVudGluZyB0aGVzZSByZXF1aXJlbWVudHMgZm9yDQo+ID4+IGNv bnN1bXB0aW9uIG91dHNpZGUgdGhlIGdyb3VwJ3Mgd29yayBhdCBhIGxhdGVyIHBvaW50IGluIHRp bWUgaXMNCj4gPj4gdmFsdWFibGUsIEkgd291bGQgcmF0aGVyIHJlY29tbWVuZCB0byBhZGQgdGhl IHJlc3BlY3RpdmUgcmVxdWlyZW1lbnRzDQo+ID4+IHRvIHRoZSBhcHBlbmRpeCBvZiB0aGUgcmVz cGVjdGl2ZSBwcm90b2NvbCBzcGVjcy4NCj4gPj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gPj4gRG90c0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RvdHMNCg0K From nobody Thu Feb 21 06:40:06 2019 Return-Path: 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 D84D112D7F8; Thu, 21 Feb 2019 06:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 X9lPKxP16sjY; Thu, 21 Feb 2019 06:40:02 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9A81279E6; Thu, 21 Feb 2019 06:40:02 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 444xvg6vpsz10Lp; Thu, 21 Feb 2019 15:39:59 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 444xvg5N8MzDq7h; Thu, 21 Feb 2019 15:39:59 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA4.corporate.adroot.infra.ftgroup ([fe80::4538:d7b0:3c64:8ed3%22]) with mapi id 14.03.0435.000; Thu, 21 Feb 2019 15:39:59 +0100 From: To: "Mirja Kuehlewind (IETF)" CC: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?B?dGYtZG90cy1yZXF1aXJlbWVudHMtMTg6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHUyevO1gebaU+aZ0KlHgwWkSlAwKXqUDqA Date: Thu, 21 Feb 2019 14:39:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA2346F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA232A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EFF6377-02A4-4D0B-BCF2-313FDB3B18B8@kuehlewind.net> In-Reply-To: <6EFF6377-02A4-4D0B-BCF2-313FDB3B18B8@kuehlewind.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:40:05 -0000 UmUtLA0KDQpNeSBwb2ludCBpcyB0aGF0IGNvbWJpbmluZyBSRkM4MDg1IGFuZCBkZXBsb3ltZW50 cyB3aGVyZSB0aW1lcnMgY2FuIGJlIGNvbnRyb2xsZWQvZGlzY292ZXJlZCBpcyBzdWZmaWNpZW50 IHRvIGZ1bGZpbGwgdGhlIHJlcXVpcmVtZW50LiANCg0KT2YgY291cnNlLCB0aGlzIGRvZXMgbm90 IGd1YXJhbnRlZSB0aGF0IGJpbmRpbmdzIGFyZSBrZXB0IGFjdGl2ZSBpZiBhIE5BVC9GVyBhc3Np Z25zIHRpbWVycyBvZiBsZXNzIHRoYW4gMTUgc2Vjb25kcy4uLndoaWNoIGlzIGZhaXIuIFRoZSBy ZXF1aXJlbWVudCBkb2VzIG5vdCBhc2sgZm9yIHN1Y2ggZ3VhcmFudGVlLiANCg0KQ2hlZXJzLA0K TWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1pcmphIEt1ZWhs ZXdpbmQgKElFVEYpIFttYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5ldF0NCj4gRW52b3nDqcKgOiBq ZXVkaSAyMSBmw6l2cmllciAyMDE5IDE0OjQ2DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRH SS9PTE4NCj4gQ2PCoDogZG90cy1jaGFpcnNAaWV0Zi5vcmc7IGZyYW5rLnhpYWxpYW5nQGh1YXdl aS5jb207IGRvdHNAaWV0Zi5vcmc7IFRoZQ0KPiBJRVNHOyBkcmFmdC1pZXRmLWRvdHMtcmVxdWly ZW1lbnRzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbRG90c10gTWlyamEgS8O8aGxld2luZCdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0NCj4gMTg6ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBwbGVhc2Ugc2VlIGJlbG93 Lg0KPiANCj4gPiBBbSAyMS4wMi4yMDE5IHVtIDEzOjE3IHNjaHJpZWIgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbToNCj4gPg0KPiA+Pj4+IDIpIEFsc28gb24gdGhpcyB0ZXh0IGluIFNJRy0w MDQ6DQo+ID4+Pj4gIlRoZSBoZWFydGJlYXQgaW50ZXJ2YWwgZHVyaW5nIGFjdGl2ZSBtaXRpZ2F0 aW9uIGNvdWxkIGJlDQo+ID4+Pj4gICAgIG5lZ290aWFibGUsIGJ1dCBNVVNUIGJlIGZyZXF1ZW50 IGVub3VnaCB0byBtYWludGFpbiBhbnkgb24tcGF0aA0KPiA+Pj4+ICAgICBOQVQgb3IgRmlyZXdh bGwgYmluZGluZ3MgZHVyaW5nIG1pdGlnYXRpb24uICBXaGVuIFRDUCBpcyB1c2VkIGFzDQo+ID4+ Pj4gICAgIHRyYW5zcG9ydCwgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgaGVhcnRiZWF0IG1lc3Nh Z2VzIG5lZWQgdG8gYmUNCj4gPj4+PiAgICAgZnJlcXVlbnQgZW5vdWdoIHRvIG1haW50YWluIHRo ZSBUQ1AgY29ubmVjdGlvbiBzdGF0ZS4iDQo+ID4+Pj4NCj4gPj4+PiBBcyBKb2UgY29tbWVudGVk IGFscmVhZHksIGRpZmZlcmVudCBoZWFydGJlYXRzIGF0IGRpZmZlcmVudCBsYXllcnMgY2FuDQo+ IGJlDQo+ID4+Pj4gdXNlZA0KPiA+Pj4+IGF0IHRoZSBzYW1lIHRpbWUgZm9yIGRpZmZlcmVudCBw dXJwb3Nlcy4gWW91IGNhbiB1c2UgaGVhcnRiZWF0cyBhdCB0aGUNCj4gPj4+PiBhcHBsaWNhdGlv biBsYXllciB0byBjaGVjayBzZXJ2aWNlIGF2YWlsYWJpbGl0eSB3aGlsZSBlLmcuIHVzaW5nIGEN Cj4gaGlnaGVyDQo+ID4+Pj4gZnJlcXVlbnQgaGVhcnRiZWF0IGF0IHRoZSB0cmFuc3BvcnQgbGF5 ZXIgdG8gbWFpbnRhaW4gZmlyZXdhbGwgYW5kIE5BVA0KPiA+PiBzdGF0ZS4NCj4gPj4+DQo+ID4+ PiBbTWVkXSBQbGVhc2Ugbm90ZSB0aGF0IHRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgYWJvdXQgImR1 cmluZyBhY3RpdmUNCj4gPj4gbWl0aWdhdGlvbiIuIFdoZW4gbm8gYXR0YWNrIGlzIG9uZ29pbmcs IHdlIGRvIGhhdmUgdGhlIGZvbGxvd2luZyBiZWhhdmlvcg0KPiA+PiB3aGljaCBjb3ZlcnMgeW91 ciBjb21tZW50Og0KPiA+Pj4NCj4gPj4+ICAgICBXaGVuIERPVFMgYWdlbnRzIGFyZSBleGNoYW5n aW5nIGhlYXJ0YmVhdHMgYW5kIG5vDQo+ID4+PiAgICAgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGFj dGl2ZSwgZWl0aGVyIGFnZW50IE1BWSByZXF1ZXN0IGNoYW5nZXMgdG8NCj4gPj4+ICAgICB0aGUg aGVhcnRiZWF0IHJhdGUuICBGb3IgZXhhbXBsZSwgYSBET1RTIHNlcnZlciBtaWdodCB3YW50IHRv DQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXg0KPiA+Pj4gICAgIHJlZHVjZSBoZWFydGJlYXQgZnJlcXVlbmN5IG9y IGNlYXNlIGhlYXJ0YmVhdCBleGNoYW5nZXMgd2hlbiBhbg0KPiA+Pj4gICAgIF5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4g Pj4+ICAgICBhY3RpdmUgRE9UUyBjbGllbnQgaGFzIG5vdCByZXF1ZXN0ZWQgbWl0aWdhdGlvbiwg aW4gb3JkZXIgdG8NCj4gPj4+ICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl4NCj4gPj4+ICAgICBjb250cm9sIGxvYWQuDQo+ID4+Pg0KPiA+Pj4+IFRo ZSBhZHZhbnRhZ2UgdG8gc3VjaCBhbiBhcHByb2FjaCBpcyB0aGF0IHRoZXJlIGlzIGxlc3MgYXBw bGljYXRpb24NCj4gbGF5ZXINCj4gPj4+PiBvdmVyaGVhZC9sb2FkIGUuZy4gaW4gc2NlbmFyaW9z IHdoZXJlIGl0IG1pZ2h0IGJlIGV4cGVuc2l2ZSB0byB3YWtlIHVwDQo+IHRoZQ0KPiA+Pj4+IGFw cGxpY2F0aW9uIG9yIGEgc2VydmVyIGlzIGFscmVhZHkgaGlnaGx5IGxvYWRlZC4gQWxzbyBub3Rl IHRoYXQgdGhlDQo+ID4+IHRpbWUtDQo+ID4+Pj4gb3V0cw0KPiA+Pj4+IHZhbHVlcyBvZiBOQVRz IGFuZCBmaXJld2FsbHMgb24gdGhlIHBhdGggYXJlIHVzdWFsbHkgdW5rbm93biwgdGhlcmVmb3Jl DQo+IGFuDQo+ID4+Pj4gYXBwbGljYXRpb24gY2FuIG5ldmVyIHJlbHkgb24gaGVhcnRiZWF0cyAo bm8gbWF0dGVyIGF0IHdoaWNoIGxldmVsKSBhbmQNCj4gPj4gbXVzdA0KPiA+Pj4+IGJlDQo+ID4+ Pj4gcHJlcGFyZWQgdG8gdHJ5IHRvIHJlY29ubmVjdCBvbiB0aGUgYXBwbGljYXRpb24gbGF5ZXIg aWYgdGhlIGNvbm5lY3Rpb24NCj4gPj4+PiBmYWlscy4NCj4gPj4+PiBVc3VhbGx5LCB0aGUgbWFp biByZWFzb24gZm9yIHVzaW5nIGhlYXJ0YmVhdHMgdG8gbWFpbnRhaW4gTkFUIG9yDQo+IGZpcmV3 YWxsDQo+ID4+Pj4gc3RhdGUNCj4gPj4+PiAodnMuIHJlY29ubmVjdCBldmVyeSB0aW1lKSBpbiBU Q1AgaXMgaWYgdGhlIGFwcGxpY2F0aW9uIGlzIHRpbWUtDQo+IHNlbnNpdGl2ZQ0KPiA+PiBhbmQN Cj4gPj4+PiBhDQo+ID4+Pj4gZnVsbCBUQ1AgaGFuZHNoYWtlIHRha2VzIHRvbyBsb25nIGZvciB0 aGUgZGVzaXJlZCBzZXJ2aWNlLiBJJ20gbm90IHN1cmUNCj4gPj4gdGhhdA0KPiA+Pj4+IHRoZSBj YXNlIGZvciBET1RTLCBob3dldmVyLCBJIHVuZGVyc3RhbmQgaXQgbWF5IGJlIGJlbmVmaWNpYWwg dG8gaGF2ZQ0KPiA+Pj4+IGVzdGFibGlzaGVkIHN0YXRlIGlmIGFuIGF0dGFjayBpcyBvbi1nb2lu Zy4NCj4gPj4+DQo+ID4+PiBbTWVkXSBUaGlzIGlzIGltcG9ydGFudCB0byBhdm9pZCBuZXcgaGFu ZHNoYWtlcyB3aGVuIHRoZSBjbGllbnQgaGFzIHRvDQo+ID4+IHJlcXVlc3QgYSBtaXRpZ2F0aW9u Lg0KPiA+Pg0KPiA+PiBUaGlzIGlzIG9rYXkgYnV0IGNvdWxkIGJlIHNwZWxsZWQgb3V0IG1vcmUg ZXhwbGljaXRseSBhcyBhIHJlcXVpcmVtZW50LA0KPiA+PiByYXRoZXIgdGhhbiB0YWtpbmcgYWJv dXQgdGhlIGRldGFpbHMgb2Ygc2VuZGluZyBoZWFydGJlYXRzLg0KPiA+Pj4NCj4gPj4+Pg0KPiA+ Pj4+IEZvciBVRFAgSSBndWVzcyBpdCdzIG1vcmUgY29tcGxpY2F0ZWQgaW4geW91ciBjYXNlLiBU aW1lLW91dHMgYXJlDQo+IHVzdWFsbHkNCj4gPj4+PiB2ZXJ5DQo+ID4+Pj4gc2hvcnQsIGhvd2V2 ZXIsIHN0YXRlIGlzIGNyZWF0ZWQgd2l0aCB0aGUgZmlyc3QgcGFja2V0IG9mIGEgZmxvdyAoYXMN Cj4gdGhlcmUNCj4gPj4gaXMNCj4gPj4+PiBubyBoYW5kc2hha2UgaW4gVURQKS4gQXMgeW91IGRv bid0IHNlZSBibG9ja2luZyBpZiBzdGF0ZSBpcyBleHBpcmVkIGFzDQo+IG5ldw0KPiA+Pj4+IHN0 YXRlIGlzIGNyZWF0ZWQgaW1tZWRpYXRlbHksIGl0J3Mga2luZCBvZiBpbXBvc3NpYmxlIHRvIG1l YXN1cmUgdGhlDQo+ID4+Pj4gY29uZmlndXJlZA0KPiA+Pj4+IHRpbWUtb3V0IHZhbHVlcy4gT25s eSBpZiB0aGUgZmlyZXdhbGwgaXMgdW5kZXIgYXR0YWNrIGl0IHdvdWxkIHN0YXJ0DQo+ID4+IGJs b2NraW5nDQo+ID4+Pj4gVURQIHRyYWZmaWMgdGhhdCBpcyBoYXMgbm8gc3RhdGUgZm9yIHlldC4g U28gSSB1bmRlcnN0YW5kIHdoeSBpdCBpcw0KPiA+PiBkZXNpcmFibGUNCj4gPj4+PiB0byBtYWlu dGFpbiBVRFAgc3RhdGUgZm9yIHlvdSwgaG93ZXZlciwgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB5 b3UgY2FuDQo+ID4+IGtub3cNCj4gPj4+PiB0aGF0IHlvdXIgZnJlcXVlbmN5IGlzIGhpZ2ggZW5v dWdoIHRvIGFjdHVhbGx5IGtlZXAgdGhlIHN0YXRlIG9wZW4uIE5vdGUNCj4gPj4gdGhhdA0KPiA+ Pj4+IFRDUCB0aW1lLW91dHMgYXJlIHVzdWFsbHkgaW4gdGhlIG9yZGVyIG9mIGhvdXJzLCB3aGls ZSBVRFAgdGltZS1vdXRzIGFyZQ0KPiA+Pj4+IHVzdWFsbHkgaW4gcmFuZ2Ugb2YgdGVucyBvZiBz ZWNvbmRzLCBhbmQgbWlnaHQgZXhwaXJlIGV2ZW4gcXVpY2tlciBpZiBhDQo+ID4+Pj4gc3lzdGVt DQo+ID4+Pj4gaXMgdW5kZXIgYXR0YWNrLiBJZiB0aGF0IGlzIGEgc2NlbmFyaW8gdGhhdCBpcyBp bXBvcnRhbnQgZm9yIHlvdSwgYW5kDQo+ID4+Pj4gYXNzdW1pbmcNCj4gPj4+PiB0aGF0IG5vdCBh bGwgdGltZS1vdXRzIHZhbHVlcyBvbiB0aGUgcGF0aCBjYW4gYmUga25vd24sIEkgZ3Vlc3MgaXQg d291bGQNCj4gPj4gYmUNCj4gPj4+PiByZWNvbW1lbmRhYmxlIHRvIHVzZSBUQ1AgaW5zdGVhZC4N Cj4gPj4+Pg0KPiA+Pj4+IEluIGFueSBjYXNlIHRoaXMgY2FuIG5vdCBiZSBhIE1VU1QgcmVxdWly ZW1lbnQgKGFzIHRpbWVycyBhcmUgdXN1YWxseQ0KPiBub3QNCj4gPj4+PiBrbm93bikuIEkgd291 bGQgcmVjb21tZW5kIHRvIHN0YXRlIHNvbWV0aGluZyBsaWtlOg0KPiA+Pj4+DQo+ID4+Pj4gIk1B WSBiZSBmcmVxdWVudCBlbm91Z2ggdG8gbWFpbnRhaW4gTkFUIG9yIGZpcmV3YWxsIHN0YXRlLCBp ZiB0aW1lcg0KPiB2YWx1ZXMNCj4gPj4+PiBhcmUNCj4gPj4+PiBrbm93biwgb3IgaWYgVENQIGlz IHVzZWQsIFNIT1VMRCB1c2UgaW4gYWRkaXRpb24gVENQIGhlYXJ0YmVhdHMgIHRvDQo+ID4+IG1h aW50YWluDQo+ID4+Pj4gdGhlIFRDUCBjb25uZWN0aW9uIHN0YXRlIGFuZCByZWNvbm5lY3QgaW1t ZWRpYXRlbHkgaWYgYSBmYWlsdXJlIGlzDQo+ID4+IGRldGVjdGVkLiINCj4gPj4+Pg0KPiA+Pj4N Cj4gPj4+IFtNZWRdIFRoZSBvcmlnaW5hbCB3b3JkaW5nIGlzIGFjY3VyYXRlIGFuZCByZWZsZWN0 cyB0aGUgcmVxdWlyZW1lbnQgb2YNCj4gdGhlDQo+ID4+IFdHLiBIb3cgdGhpcyB3aWxsIGJlIGVu Zm9yY2VkIGlzIHBhcnQgb2YgdGhlIHNvbHV0aW9uL3NwZWNpZmljYXRpb24gc3BhY2UuDQo+ID4+ DQo+ID4+IE15IGhvbGQgcG9pbnQgaGVyZSBpcyB0aGF0DQo+ID4+DQo+ID4+ICJNVVNUIGJlIGZy ZXF1ZW50IGVub3VnaCB0byBtYWludGFpbiBhbnkgb24tcGF0aCBOQVQgb3IgRmlyZXdhbGwgYmlu ZGluZ3MNCj4gPj4gZHVyaW5nIG1pdGlnYXRpb24u4oCcDQo+ID4+DQo+ID4+IGNhbm5vdCBiZSBh IE1VU1QgcmVxdWlyZW1lbnQgYXMgdGhlIG5ldHdvcmsgdGltZS1vdXQgdmFsdWVzIGFyZSBub3Qg a25vd24NCj4gYnkNCj4gPj4gdGhlIGVuZHBvaW50cy4gVGhlcmVmb3JlIGl0IGlzIGltcG9zc2li bGUgdG8gZnVsZmlsbCB0aGlzIHJlcXVpcmVtZW50Lg0KPiA+DQo+ID4gW01lZF0gVHdvIGNvbW1l bnRzIGhlcmU6DQo+ID4gKiBUaGUgcmVxdWlyZW1lbnQgY2FuIGJlIGZ1bGZpbGxlZCBieSByZWx5 aW5nIFJGQzgwODUgcmVjb21tZW5kYXRpb25zLiBUaGlzDQo+IGlzIGRpc2N1c3NlZCBpbiB0aGUg c3BlYyBkb2N1bWVudHMuDQo+IA0KPiBSRkM4MDg1IHByb3ZpZGUgcmVjb21tZW5kZWQgdmFsdWUg YW5kIGxpbWl0cywgaG93ZXZlciwgdGhpcyBkb2VzIG5vdA0KPiBndWFyYW50ZWUgdGhhdCB0aGUg cHJvcG9zZWQgdmFsdWVzIGFjdHVhbGx5IG1hdGNoIHRoZSB0aW1lLW91dCB2YWx1ZXMgYXMNCj4g ZGVwbG95ZWQgb24gdGhlIHBhdGguDQo+IA0KPiA+ICogdGhlcmUgYXJlIGRlcGxveW1lbnRzIGlu IHdoaWNoIHRpbWVycyBjYW4gYmUgZGlzY292ZXJlZCAoZS5nLiwgUENQDQo+IChSRkM2ODg3KSku DQo+IA0KPiBUaGlzIGRvZXMgbm90IHdvcmsgaW4gYWxsIGNhc2VzIGFuZCB0aGUgZHJhZnQgZG9l cyBub3Qgc2VlbSB0byByZXF1aXJlIHRoZQ0KPiB1c2FnZSBvZiBhbnl0aGluZyBsaWtlIHRoaXMu IElmIGEgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGUgdGltZW91dCB2YWx1ZXMgTVVTVA0KPiBiZSBr bm93biBpbiB0aGUgZGVwbG95ZWQgc2NlbmFyaW8sIHRoZW4gdGhhdCBzaG91bGQgYmUgc3BlbGxl ZCBvdXQsIGhvd2V2ZXIsDQo+IEkgYXNzdW1lIHRoYXQgaXMgbm90IHlvdXIgaW50ZW50aW9uIGJl Y2F1c2UgdGhhdCB3b3VsZCBsaW1pdCBkZXBsb3ltZW50DQo+IGhlYXZpbHkuDQo+IA0KPiBNaXJq YQ0KPiANCg0K From nobody Thu Feb 21 06:59:44 2019 Return-Path: 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 BE12A1286E7; Thu, 21 Feb 2019 06:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 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, RCVD_IN_SORBS_WEB=1.5, 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 oCl10qYLsVeS; Thu, 21 Feb 2019 06:59:30 -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 77D75124408; Thu, 21 Feb 2019 06:59:28 -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=1550761032; 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=st+hqCQENeUJgsowiMi9uSO0OkI+XPrRfvlOob PxrfU=; b=RGAbvssMswf3N0n7bifb8mJ75Z6lYJTgyN1l9dMF 4d2PaowzveTrlswrC0e01Y0KSE+XbckG76mSfQxxeh2biuKfjt ++rff8XKDJo9cWkPKzWGm+hk9VAd9b4RaRlcmeuQAeM76U2oVO Qb5mjh4HSk2e8VAhto/VLKb1Vp4cBHY= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5b5e_65cb_6508e61e_8556_470f_abb7_b3097e354ee8; Thu, 21 Feb 2019 07:57:12 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 07:58:56 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 21 Feb 2019 07:58:56 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 07:58:55 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2422.namprd16.prod.outlook.com (20.177.225.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Thu, 21 Feb 2019 14:58:55 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Thu, 21 Feb 2019 14:58:55 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Mirja Kuehlewind (IETF)" CC: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWll?= =?utf-8?B?dGYtZG90cy1yZXF1aXJlbWVudHMtMTg6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHUyfNmchRbiQkDSUaSyjwDnUu6AqXqVlbA Date: Thu, 21 Feb 2019 14:58:55 +0000 Message-ID: References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA232A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EFF6377-02A4-4D0B-BCF2-313FDB3B18B8@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA2346F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA2346F@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.76.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d3e7f2f-e551-4dbd-b8a6-08d6980d19b5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2422; x-ms-traffictypediagnostic: BYAPR16MB2422: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNDIyOzIzOjBBSWtIRWpuOFpxbXlOd1JWdS9xY1R4alZE?= =?utf-8?B?a083ZElpYlAvLzMwL01QZjlDN3p5UlpmSlhDU2F6N08xWUpQSG9HM0RwMmVh?= =?utf-8?B?QlpRMWozSUlqWGRKa0k4SEoxaWpJbFJSVWhoWXQ3eG9UWFgzbmFJSHNlWHZq?= =?utf-8?B?MmI1M0QvajJ1MzZJUWorRTYzZkkzZHU4KzZnZmM1dTNLTk1teHlKWEpINk1n?= =?utf-8?B?bTIrTlAya0FzM2RSb0M1ODBhNjBIWlFwa3MvSGtSeDFkTDVlbzRhemY1ejFv?= =?utf-8?B?MkN6dmtUUWZQd3c5VnhYUEE5L1FteVl0dzNrbFI3eXhpWWhlamNYNCsxeW9x?= =?utf-8?B?Z1g3RW16MzBmYVAyRE9tejlzdHd2aW0zNTBvRCtnZ1c2QVVKUGJtMG4zb0Zp?= =?utf-8?B?UGN1ejdETjNaZzhiZzJqVmduS2p6N2k5Vy9Md3U4eENlV09zM3RSZld1OTJz?= =?utf-8?B?d1ZISzVCODdxNXYwb3NGUFREME5VbFlqOW1SN0w2LzAvNVVyYjJFbnZzOHUw?= =?utf-8?B?cEYxTmRvby82VkVhSGZzcmlacWx1WFRYR2FFbUhWY0xLek41WHV6L0MrTkhP?= =?utf-8?B?MHZhOFBxeFpzN3BuUHdvdTFmT0tYRzR6MFA3VlN6bEZYVWlKbWVJa0oxRE5B?= =?utf-8?B?ZnJTVXBxRUdJUHpjTmJnU21WcHg5bXlUbnhFNDJKQmhlQzFtcTFoNXFLWXZ2?= =?utf-8?B?SnNRSi9PcStjNFN3N2tKT2lWTlJaUFFRbG5YUjcyMUtxYmRGcXJyOTExU2FX?= =?utf-8?B?RUM5K3pwdHZoT2VUbVZBY1V3UDZjOUYzSCt1bWVHRUFsWTN6ZW9ObDQrdGZm?= =?utf-8?B?UkxhS29PdzZvSHNobTlhcGZmODhic2ZGYmJmTG14allzZXhNUU9ZanBndktp?= =?utf-8?B?bHJSL1V5eTByZEY5Ujl3NkRwa0k4S0RlL0RiekpJa3lHS0lEeEJsbGFPWUd3?= =?utf-8?B?QWpQZjMzN0ZHMWpXVGNnamgwYXhneExJMlNlRExNS3Z4QkJKOCtJZi9HcXpi?= =?utf-8?B?RWw4VkxIY3VLYThUUDc4NDdHSDIrZ3dsUkd1MWZrUGdZQjhWQzNnaFFtVFZM?= =?utf-8?B?OHgvVkdlUFh3bVZxNUh6YzllWGJUVGprY0J4U282NWJOTDdTd1lXUHFBRkNT?= =?utf-8?B?d2w3WTl5dkt3YUtVT3p4TysycEpKMkFOQyt4VW12TGRBVnQ3eUZZc3dxL3Mv?= =?utf-8?B?djN6b2F3SlZGYkxLUzBTZ0w2ZDBzUkM1TkRYTzA0c1IwR2dwY1lLNVd1YkxY?= =?utf-8?B?dzRYTmtVTDg5Q0Q0cG5NYkxqb1hObnV5N1pYenREdmtwM3dxODNqZ3l3SGJE?= =?utf-8?B?Q0pFM0tnWmdXc1htdlFZaG1UWWUxSDRBYjYveHZMUmczL1lzaXRFRmtCTkMr?= =?utf-8?B?ajJ4WmpXMmN4RzVZSjcwa1hWaG9yendrYk5xU0dhMWh0bVMvbFlhN2RLWVRP?= =?utf-8?B?UGlNbGlBR1A3V00vMk9ZamphNmtRaTFFYlE3L281aWV6K0pBOVp6dGdYWHh5?= =?utf-8?B?UGdwQU0veWZiL3VJcWgrTVFVejJUWmMvOFJRWVc5TTQ3Tld5dUx3TDVzYnZ3?= =?utf-8?B?eWZzWEM5OTRLcCtRaG1qTU44VkxTYXltd0VrU29zZEVLbzBWQU4wZHhiSVNX?= =?utf-8?B?a3BPMm5Vbm1ZTFY3M0lMdi93SFRDcjZiWW1XUzJpMVN3RUdFSjgrSjlrZHFr?= =?utf-8?B?OWd2aXJnUHhTckkxNGswM0NvS2xTd29GeHB0aitqVm1telpPUG9ZVXhqQUk3?= =?utf-8?B?QXZPVXdlbHNPTlhxRFpIZmh5dTlDZEV5UUIzSldZU1RrcGJoZlJrWms3QmVL?= =?utf-8?B?eVNMbnVwZ2RMZU5XbHViRFVJckt4UGpOWDlzU1NJc2h2eFRidlZPZEcrbDMz?= =?utf-8?B?MjJvUUQxSkxaVzhlZUttTEc3TnN6RDZwQXlvU0VoUS9rcitNS0g3eU1HT2Jv?= =?utf-8?B?M3Z6YUx0dHFnUnhuQld4UmZPNlJXRjNSVlRoM3NiKzhrOUtTblg5VjROZ0dI?= =?utf-8?Q?w2woOP?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(346002)(136003)(199004)(189003)(13464003)(55784004)(32952001)(78486014)(86362001)(105586002)(80792005)(66574012)(4326008)(5024004)(106356001)(224303003)(14444005)(256004)(2501003)(53936002)(3846002)(66066001)(25786009)(6116002)(74316002)(93886005)(6436002)(305945005)(55016002)(7736002)(97736004)(6506007)(68736007)(7696005)(76176011)(9686003)(81166006)(99286004)(81156014)(478600001)(186003)(316002)(33656002)(54906003)(5660300002)(8936002)(11346002)(446003)(2906002)(110136005)(486006)(14454004)(6246003)(53546011)(71200400001)(71190400001)(229853002)(102836004)(476003)(26005)(72206003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2422; H:BYAPR16MB2790.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: MyvLkZ7srFRz5lHhW++DZCiN6oO4sTd4tGvgpigdPkGF0QKmXjipUg+tVFBb7kkhP70X/rw382ooWaig/+9wNwBY6+2NRwr6BJbsnms19DoVCakxbq8pP9F7/uI5hcSrIOZbr2gbBMZpqKZpvvS6ze8ny2L8Nu7oyIGp9t1raTUBVcjvEsyOxr9dytU2d8rw+yFSsLsS5M6ySkhfU1sYlUlD9k2p+LVfhnDB3LIYEsw+z5sqWYyVtqbHWKzlycWCekpr+LVqkq9OEzWm5zAhxw2rOpFDAHiOx2yT8Evw9n++9etVpoan1pkArXMaEnoMirRwxLtxablHEL+SmzIMo0Y3lwjIfaIdE2MJh7PiInRhykc59l5cZ+NVm9TnXp6XrEI/Tyz0LuNXDbFY0taxofnYTv6/FRnQHe8qMa+EXU8= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9d3e7f2f-e551-4dbd-b8a6-08d6980d19b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 14:58:55.1759 (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: BYAPR16MB2422 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 <6488> : inlines <7019> : streams <1813688> : uri <2799975> Archived-At: Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-requirements-18=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 14:59:34 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMjEsIDIwMTkgODoxMCBQTQ0KPiBUbzogTWlyamEgS3VlaGxld2luZCAoSUVU RikgPGlldGZAa3VlaGxld2luZC5uZXQ+DQo+IENjOiBkb3RzLWNoYWlyc0BpZXRmLm9yZzsgZnJh bmsueGlhbGlhbmdAaHVhd2VpLmNvbTsgZG90c0BpZXRmLm9yZzsgVGhlIElFU0cNCj4gPGllc2dA aWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJFOiBbRG90c10gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1k b3RzLXJlcXVpcmVtZW50cy0NCj4gMTg6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0K PiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24u IERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVj b2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IFJl LSwNCj4gDQo+IE15IHBvaW50IGlzIHRoYXQgY29tYmluaW5nIFJGQzgwODUgYW5kIGRlcGxveW1l bnRzIHdoZXJlIHRpbWVycyBjYW4gYmUNCj4gY29udHJvbGxlZC9kaXNjb3ZlcmVkIGlzIHN1ZmZp Y2llbnQgdG8gZnVsZmlsbCB0aGUgcmVxdWlyZW1lbnQuDQo+IA0KPiBPZiBjb3Vyc2UsIHRoaXMg ZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgYmluZGluZ3MgYXJlIGtlcHQgYWN0aXZlIGlmIGEgTkFU L0ZXDQo+IGFzc2lnbnMgdGltZXJzIG9mIGxlc3MgdGhhbiAxNSBzZWNvbmRzLi4ud2hpY2ggaXMg ZmFpci4gVGhlIHJlcXVpcmVtZW50IGRvZXMgbm90DQo+IGFzayBmb3Igc3VjaCBndWFyYW50ZWUu DQoNCkFncmVlZCwgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdXBkYXRlIHRvIGNhcHR1cmUgdGhl IGRpc2N1c3Npb24gYW5kIGFkZHJlc3NlcyB0aGUgY29tbWVudDoNCg0KQ2hhbm5lbCBIZWFsdGgg TW9uaXRvcmluZzogRE9UUyBhZ2VudHMgTVVTVCBzdXBwb3J0IGV4Y2hhbmdlIG9mIGhlYXJ0YmVh dCBtZXNzYWdlcyBvdmVyIHRoZSBzaWduYWwgY2hhbm5lbCB0byBtb25pdG9yIGNoYW5uZWwgaGVh bHRoLiBUaGVzZSBrZWVwYWxpdmVzIHNlcnZlIHRoZSBwdXJwb3NlIHRvIG1haW50YWluIGFueSBv bi1wYXRoIE5BVCBvciBGaXJld2FsbCBiaW5kaW5ncyB0byBhdm9pZCBjcnlwdG9ncmFwaGljIGhh bmRzaGFrZSBmb3IgbmV3IG1pdGlnYXRpb24gcmVxdWVzdHMuIFRoZSBoZWFydGJlYXQgaW50ZXJ2 YWwgZHVyaW5nIGFjdGl2ZSBtaXRpZ2F0aW9uIGNvdWxkIGJlIG5lZ290aWFibGUgYmFzZWQgb24g TkFUL0ZpcmV3YWxsIGNoYXJhY3RlcmlzdGljcy4gQWJzZW50IGluZm9ybWF0aW9uIGFib3V0IHRo ZSBOQVQvRmlyZXdhbGwgY2hhcmFjdGVyaXN0aWNzLCBET1RTIGFnZW50IG5lZWRzIHRvIGVuc3Vy ZSBpdHMgb24tcGF0aCBOQVQgb3IgRmlyZXdhbGwgYmluZGluZ3MgZG8gbm90IGV4cGlyZSwgYnkg dXNpbmcgdGhlIGtlZXAtYWxpdmUgZnJlcXVlbmN5IGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMuNSBv ZiBbUkZDODA4NV0uDQoNCkNoZWVycw0KLVRpcnUNCg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4g DQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogTWlyamEgS3VlaGxl d2luZCAoSUVURikgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XSBFbnZvecOpwqA6DQo+ID4g amV1ZGkgMjEgZsOpdnJpZXIgMjAxOSAxNDo0NiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kv T0xOIENjwqA6DQo+ID4gZG90cy1jaGFpcnNAaWV0Zi5vcmc7IGZyYW5rLnhpYWxpYW5nQGh1YXdl aS5jb207IGRvdHNAaWV0Zi5vcmc7IFRoZQ0KPiA+IElFU0c7IGRyYWZ0LWlldGYtZG90cy1yZXF1 aXJlbWVudHNAaWV0Zi5vcmcNCj4gPiBPYmpldMKgOiBSZTogW0RvdHNdIE1pcmphIEvDvGhsZXdp bmQncyBEaXNjdXNzIG9uDQo+ID4gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0NCj4gPiAx ODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPg0KPiA+IEhpIE1lZCwNCj4gPg0KPiA+ IHBsZWFzZSBzZWUgYmVsb3cuDQo+ID4NCj4gPiA+IEFtIDIxLjAyLjIwMTkgdW0gMTM6MTcgc2No cmllYiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOg0KPiA+ID4NCj4gPiA+Pj4+IDIpIEFs c28gb24gdGhpcyB0ZXh0IGluIFNJRy0wMDQ6DQo+ID4gPj4+PiAiVGhlIGhlYXJ0YmVhdCBpbnRl cnZhbCBkdXJpbmcgYWN0aXZlIG1pdGlnYXRpb24gY291bGQgYmUNCj4gPiA+Pj4+ICAgICBuZWdv dGlhYmxlLCBidXQgTVVTVCBiZSBmcmVxdWVudCBlbm91Z2ggdG8gbWFpbnRhaW4gYW55IG9uLXBh dGgNCj4gPiA+Pj4+ICAgICBOQVQgb3IgRmlyZXdhbGwgYmluZGluZ3MgZHVyaW5nIG1pdGlnYXRp b24uICBXaGVuIFRDUCBpcyB1c2VkIGFzDQo+ID4gPj4+PiAgICAgdHJhbnNwb3J0LCB0aGUgRE9U UyBzaWduYWwgY2hhbm5lbCBoZWFydGJlYXQgbWVzc2FnZXMgbmVlZCB0byBiZQ0KPiA+ID4+Pj4g ICAgIGZyZXF1ZW50IGVub3VnaCB0byBtYWludGFpbiB0aGUgVENQIGNvbm5lY3Rpb24gc3RhdGUu Ig0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEFzIEpvZSBjb21tZW50ZWQgYWxyZWFkeSwgZGlmZmVyZW50 IGhlYXJ0YmVhdHMgYXQgZGlmZmVyZW50DQo+ID4gPj4+PiBsYXllcnMgY2FuDQo+ID4gYmUNCj4g PiA+Pj4+IHVzZWQNCj4gPiA+Pj4+IGF0IHRoZSBzYW1lIHRpbWUgZm9yIGRpZmZlcmVudCBwdXJw b3Nlcy4gWW91IGNhbiB1c2UgaGVhcnRiZWF0cw0KPiA+ID4+Pj4gYXQgdGhlIGFwcGxpY2F0aW9u IGxheWVyIHRvIGNoZWNrIHNlcnZpY2UgYXZhaWxhYmlsaXR5IHdoaWxlIGUuZy4NCj4gPiA+Pj4+ IHVzaW5nIGENCj4gPiBoaWdoZXINCj4gPiA+Pj4+IGZyZXF1ZW50IGhlYXJ0YmVhdCBhdCB0aGUg dHJhbnNwb3J0IGxheWVyIHRvIG1haW50YWluIGZpcmV3YWxsDQo+ID4gPj4+PiBhbmQgTkFUDQo+ ID4gPj4gc3RhdGUuDQo+ID4gPj4+DQo+ID4gPj4+IFtNZWRdIFBsZWFzZSBub3RlIHRoYXQgdGhl IHRleHQgeW91IHF1b3RlZCBpcyBhYm91dCAiZHVyaW5nIGFjdGl2ZQ0KPiA+ID4+IG1pdGlnYXRp b24iLiBXaGVuIG5vIGF0dGFjayBpcyBvbmdvaW5nLCB3ZSBkbyBoYXZlIHRoZSBmb2xsb3dpbmcN Cj4gPiA+PiBiZWhhdmlvciB3aGljaCBjb3ZlcnMgeW91ciBjb21tZW50Og0KPiA+ID4+Pg0KPiA+ ID4+PiAgICAgV2hlbiBET1RTIGFnZW50cyBhcmUgZXhjaGFuZ2luZyBoZWFydGJlYXRzIGFuZCBu bw0KPiA+ID4+PiAgICAgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGFjdGl2ZSwgZWl0aGVyIGFnZW50 IE1BWSByZXF1ZXN0IGNoYW5nZXMgdG8NCj4gPiA+Pj4gICAgIHRoZSBoZWFydGJlYXQgcmF0ZS4g IEZvciBleGFtcGxlLCBhIERPVFMgc2VydmVyIG1pZ2h0IHdhbnQgdG8NCj4gPiA+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl4NCj4gPiA+Pj4gICAgIHJlZHVjZSBoZWFydGJlYXQgZnJlcXVlbmN5IG9yIGNlYXNlIGhlYXJ0 YmVhdCBleGNoYW5nZXMgd2hlbiBhbg0KPiA+ID4+Pg0KPiBeXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4gPj4+ICAgICBh Y3RpdmUgRE9UUyBjbGllbnQgaGFzIG5vdCByZXF1ZXN0ZWQgbWl0aWdhdGlvbiwgaW4gb3JkZXIg dG8NCj4gPiA+Pj4gICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXg0KPiA+ID4+PiAgICAgY29udHJvbCBsb2FkLg0KPiA+ID4+Pg0KPiA+ID4+Pj4gVGhl IGFkdmFudGFnZSB0byBzdWNoIGFuIGFwcHJvYWNoIGlzIHRoYXQgdGhlcmUgaXMgbGVzcw0KPiA+ ID4+Pj4gYXBwbGljYXRpb24NCj4gPiBsYXllcg0KPiA+ID4+Pj4gb3ZlcmhlYWQvbG9hZCBlLmcu IGluIHNjZW5hcmlvcyB3aGVyZSBpdCBtaWdodCBiZSBleHBlbnNpdmUgdG8NCj4gPiA+Pj4+IHdh a2UgdXANCj4gPiB0aGUNCj4gPiA+Pj4+IGFwcGxpY2F0aW9uIG9yIGEgc2VydmVyIGlzIGFscmVh ZHkgaGlnaGx5IGxvYWRlZC4gQWxzbyBub3RlIHRoYXQNCj4gPiA+Pj4+IHRoZQ0KPiA+ID4+IHRp bWUtDQo+ID4gPj4+PiBvdXRzDQo+ID4gPj4+PiB2YWx1ZXMgb2YgTkFUcyBhbmQgZmlyZXdhbGxz IG9uIHRoZSBwYXRoIGFyZSB1c3VhbGx5IHVua25vd24sDQo+ID4gPj4+PiB0aGVyZWZvcmUNCj4g PiBhbg0KPiA+ID4+Pj4gYXBwbGljYXRpb24gY2FuIG5ldmVyIHJlbHkgb24gaGVhcnRiZWF0cyAo bm8gbWF0dGVyIGF0IHdoaWNoDQo+ID4gPj4+PiBsZXZlbCkgYW5kDQo+ID4gPj4gbXVzdA0KPiA+ ID4+Pj4gYmUNCj4gPiA+Pj4+IHByZXBhcmVkIHRvIHRyeSB0byByZWNvbm5lY3Qgb24gdGhlIGFw cGxpY2F0aW9uIGxheWVyIGlmIHRoZQ0KPiA+ID4+Pj4gY29ubmVjdGlvbiBmYWlscy4NCj4gPiA+ Pj4+IFVzdWFsbHksIHRoZSBtYWluIHJlYXNvbiBmb3IgdXNpbmcgaGVhcnRiZWF0cyB0byBtYWlu dGFpbiBOQVQgb3INCj4gPiBmaXJld2FsbA0KPiA+ID4+Pj4gc3RhdGUNCj4gPiA+Pj4+ICh2cy4g cmVjb25uZWN0IGV2ZXJ5IHRpbWUpIGluIFRDUCBpcyBpZiB0aGUgYXBwbGljYXRpb24gaXMgdGlt ZS0NCj4gPiBzZW5zaXRpdmUNCj4gPiA+PiBhbmQNCj4gPiA+Pj4+IGENCj4gPiA+Pj4+IGZ1bGwg VENQIGhhbmRzaGFrZSB0YWtlcyB0b28gbG9uZyBmb3IgdGhlIGRlc2lyZWQgc2VydmljZS4gSSdt DQo+ID4gPj4+PiBub3Qgc3VyZQ0KPiA+ID4+IHRoYXQNCj4gPiA+Pj4+IHRoZSBjYXNlIGZvciBE T1RTLCBob3dldmVyLCBJIHVuZGVyc3RhbmQgaXQgbWF5IGJlIGJlbmVmaWNpYWwgdG8NCj4gPiA+ Pj4+IGhhdmUgZXN0YWJsaXNoZWQgc3RhdGUgaWYgYW4gYXR0YWNrIGlzIG9uLWdvaW5nLg0KPiA+ ID4+Pg0KPiA+ID4+PiBbTWVkXSBUaGlzIGlzIGltcG9ydGFudCB0byBhdm9pZCBuZXcgaGFuZHNo YWtlcyB3aGVuIHRoZSBjbGllbnQNCj4gPiA+Pj4gaGFzIHRvDQo+ID4gPj4gcmVxdWVzdCBhIG1p dGlnYXRpb24uDQo+ID4gPj4NCj4gPiA+PiBUaGlzIGlzIG9rYXkgYnV0IGNvdWxkIGJlIHNwZWxs ZWQgb3V0IG1vcmUgZXhwbGljaXRseSBhcyBhDQo+ID4gPj4gcmVxdWlyZW1lbnQsIHJhdGhlciB0 aGFuIHRha2luZyBhYm91dCB0aGUgZGV0YWlscyBvZiBzZW5kaW5nIGhlYXJ0YmVhdHMuDQo+ID4g Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gRm9yIFVEUCBJIGd1ZXNzIGl0J3MgbW9yZSBjb21wbGlj YXRlZCBpbiB5b3VyIGNhc2UuIFRpbWUtb3V0cyBhcmUNCj4gPiB1c3VhbGx5DQo+ID4gPj4+PiB2 ZXJ5DQo+ID4gPj4+PiBzaG9ydCwgaG93ZXZlciwgc3RhdGUgaXMgY3JlYXRlZCB3aXRoIHRoZSBm aXJzdCBwYWNrZXQgb2YgYSBmbG93DQo+ID4gPj4+PiAoYXMNCj4gPiB0aGVyZQ0KPiA+ID4+IGlz DQo+ID4gPj4+PiBubyBoYW5kc2hha2UgaW4gVURQKS4gQXMgeW91IGRvbid0IHNlZSBibG9ja2lu ZyBpZiBzdGF0ZSBpcw0KPiA+ID4+Pj4gZXhwaXJlZCBhcw0KPiA+IG5ldw0KPiA+ID4+Pj4gc3Rh dGUgaXMgY3JlYXRlZCBpbW1lZGlhdGVseSwgaXQncyBraW5kIG9mIGltcG9zc2libGUgdG8gbWVh c3VyZQ0KPiA+ID4+Pj4gdGhlIGNvbmZpZ3VyZWQgdGltZS1vdXQgdmFsdWVzLiBPbmx5IGlmIHRo ZSBmaXJld2FsbCBpcyB1bmRlcg0KPiA+ID4+Pj4gYXR0YWNrIGl0IHdvdWxkIHN0YXJ0DQo+ID4g Pj4gYmxvY2tpbmcNCj4gPiA+Pj4+IFVEUCB0cmFmZmljIHRoYXQgaXMgaGFzIG5vIHN0YXRlIGZv ciB5ZXQuIFNvIEkgdW5kZXJzdGFuZCB3aHkgaXQNCj4gPiA+Pj4+IGlzDQo+ID4gPj4gZGVzaXJh YmxlDQo+ID4gPj4+PiB0byBtYWludGFpbiBVRFAgc3RhdGUgZm9yIHlvdSwgaG93ZXZlciwgSSBk b24ndCB1bmRlcnN0YW5kIGhvdw0KPiA+ID4+Pj4geW91IGNhbg0KPiA+ID4+IGtub3cNCj4gPiA+ Pj4+IHRoYXQgeW91ciBmcmVxdWVuY3kgaXMgaGlnaCBlbm91Z2ggdG8gYWN0dWFsbHkga2VlcCB0 aGUgc3RhdGUNCj4gPiA+Pj4+IG9wZW4uIE5vdGUNCj4gPiA+PiB0aGF0DQo+ID4gPj4+PiBUQ1Ag dGltZS1vdXRzIGFyZSB1c3VhbGx5IGluIHRoZSBvcmRlciBvZiBob3Vycywgd2hpbGUgVURQDQo+ ID4gPj4+PiB0aW1lLW91dHMgYXJlIHVzdWFsbHkgaW4gcmFuZ2Ugb2YgdGVucyBvZiBzZWNvbmRz LCBhbmQgbWlnaHQNCj4gPiA+Pj4+IGV4cGlyZSBldmVuIHF1aWNrZXIgaWYgYSBzeXN0ZW0gaXMg dW5kZXIgYXR0YWNrLiBJZiB0aGF0IGlzIGENCj4gPiA+Pj4+IHNjZW5hcmlvIHRoYXQgaXMgaW1w b3J0YW50IGZvciB5b3UsIGFuZCBhc3N1bWluZyB0aGF0IG5vdCBhbGwNCj4gPiA+Pj4+IHRpbWUt b3V0cyB2YWx1ZXMgb24gdGhlIHBhdGggY2FuIGJlIGtub3duLCBJIGd1ZXNzIGl0IHdvdWxkDQo+ ID4gPj4gYmUNCj4gPiA+Pj4+IHJlY29tbWVuZGFibGUgdG8gdXNlIFRDUCBpbnN0ZWFkLg0KPiA+ ID4+Pj4NCj4gPiA+Pj4+IEluIGFueSBjYXNlIHRoaXMgY2FuIG5vdCBiZSBhIE1VU1QgcmVxdWly ZW1lbnQgKGFzIHRpbWVycyBhcmUNCj4gPiA+Pj4+IHVzdWFsbHkNCj4gPiBub3QNCj4gPiA+Pj4+ IGtub3duKS4gSSB3b3VsZCByZWNvbW1lbmQgdG8gc3RhdGUgc29tZXRoaW5nIGxpa2U6DQo+ID4g Pj4+Pg0KPiA+ID4+Pj4gIk1BWSBiZSBmcmVxdWVudCBlbm91Z2ggdG8gbWFpbnRhaW4gTkFUIG9y IGZpcmV3YWxsIHN0YXRlLCBpZg0KPiA+ID4+Pj4gdGltZXINCj4gPiB2YWx1ZXMNCj4gPiA+Pj4+ IGFyZQ0KPiA+ID4+Pj4ga25vd24sIG9yIGlmIFRDUCBpcyB1c2VkLCBTSE9VTEQgdXNlIGluIGFk ZGl0aW9uIFRDUCBoZWFydGJlYXRzDQo+ID4gPj4+PiB0bw0KPiA+ID4+IG1haW50YWluDQo+ID4g Pj4+PiB0aGUgVENQIGNvbm5lY3Rpb24gc3RhdGUgYW5kIHJlY29ubmVjdCBpbW1lZGlhdGVseSBp ZiBhIGZhaWx1cmUNCj4gPiA+Pj4+IGlzDQo+ID4gPj4gZGV0ZWN0ZWQuIg0KPiA+ID4+Pj4NCj4g PiA+Pj4NCj4gPiA+Pj4gW01lZF0gVGhlIG9yaWdpbmFsIHdvcmRpbmcgaXMgYWNjdXJhdGUgYW5k IHJlZmxlY3RzIHRoZQ0KPiA+ID4+PiByZXF1aXJlbWVudCBvZg0KPiA+IHRoZQ0KPiA+ID4+IFdH LiBIb3cgdGhpcyB3aWxsIGJlIGVuZm9yY2VkIGlzIHBhcnQgb2YgdGhlIHNvbHV0aW9uL3NwZWNp ZmljYXRpb24gc3BhY2UuDQo+ID4gPj4NCj4gPiA+PiBNeSBob2xkIHBvaW50IGhlcmUgaXMgdGhh dA0KPiA+ID4+DQo+ID4gPj4gIk1VU1QgYmUgZnJlcXVlbnQgZW5vdWdoIHRvIG1haW50YWluIGFu eSBvbi1wYXRoIE5BVCBvciBGaXJld2FsbA0KPiA+ID4+IGJpbmRpbmdzIGR1cmluZyBtaXRpZ2F0 aW9uLuKAnA0KPiA+ID4+DQo+ID4gPj4gY2Fubm90IGJlIGEgTVVTVCByZXF1aXJlbWVudCBhcyB0 aGUgbmV0d29yayB0aW1lLW91dCB2YWx1ZXMgYXJlIG5vdA0KPiA+ID4+IGtub3duDQo+ID4gYnkN Cj4gPiA+PiB0aGUgZW5kcG9pbnRzLiBUaGVyZWZvcmUgaXQgaXMgaW1wb3NzaWJsZSB0byBmdWxm aWxsIHRoaXMgcmVxdWlyZW1lbnQuDQo+ID4gPg0KPiA+ID4gW01lZF0gVHdvIGNvbW1lbnRzIGhl cmU6DQo+ID4gPiAqIFRoZSByZXF1aXJlbWVudCBjYW4gYmUgZnVsZmlsbGVkIGJ5IHJlbHlpbmcg UkZDODA4NQ0KPiA+ID4gcmVjb21tZW5kYXRpb25zLiBUaGlzDQo+ID4gaXMgZGlzY3Vzc2VkIGlu IHRoZSBzcGVjIGRvY3VtZW50cy4NCj4gPg0KPiA+IFJGQzgwODUgcHJvdmlkZSByZWNvbW1lbmRl ZCB2YWx1ZSBhbmQgbGltaXRzLCBob3dldmVyLCB0aGlzIGRvZXMgbm90DQo+ID4gZ3VhcmFudGVl IHRoYXQgdGhlIHByb3Bvc2VkIHZhbHVlcyBhY3R1YWxseSBtYXRjaCB0aGUgdGltZS1vdXQgdmFs dWVzDQo+ID4gYXMgZGVwbG95ZWQgb24gdGhlIHBhdGguDQo+ID4NCj4gPiA+ICogdGhlcmUgYXJl IGRlcGxveW1lbnRzIGluIHdoaWNoIHRpbWVycyBjYW4gYmUgZGlzY292ZXJlZCAoZS5nLiwgUENQ DQo+ID4gKFJGQzY4ODcpKS4NCj4gPg0KPiA+IFRoaXMgZG9lcyBub3Qgd29yayBpbiBhbGwgY2Fz ZXMgYW5kIHRoZSBkcmFmdCBkb2VzIG5vdCBzZWVtIHRvIHJlcXVpcmUNCj4gPiB0aGUgdXNhZ2Ug b2YgYW55dGhpbmcgbGlrZSB0aGlzLiBJZiBhIHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlIHRpbWVv dXQNCj4gPiB2YWx1ZXMgTVVTVCBiZSBrbm93biBpbiB0aGUgZGVwbG95ZWQgc2NlbmFyaW8sIHRo ZW4gdGhhdCBzaG91bGQgYmUNCj4gPiBzcGVsbGVkIG91dCwgaG93ZXZlciwgSSBhc3N1bWUgdGhh dCBpcyBub3QgeW91ciBpbnRlbnRpb24gYmVjYXVzZSB0aGF0DQo+ID4gd291bGQgbGltaXQgZGVw bG95bWVudCBoZWF2aWx5Lg0KPiA+DQo+ID4gTWlyamENCj4gPg0KDQo= From nobody Thu Feb 21 07:03:08 2019 Return-Path: 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 EC1E1124408; Thu, 21 Feb 2019 07:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 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, RCVD_IN_SORBS_WEB=1.5, 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 GZo7-EPgUJPW; Thu, 21 Feb 2019 07:02:55 -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 E003813109B; Thu, 21 Feb 2019 07:02:52 -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=1550761230; 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-ms-exchange-purlcount: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=q ASCQW6e+8YGGj6CDaoJ1reQcPBpWVcTx86ZLGZ9rH U=; b=hv+Y05mq3VEuMxLzLJGz6DM6HG1hCMDt6xpnxnAUgw80 3sXm4pOi33lzpwBxTFSdR5zu+cBrjQk9EwWz//TxxtHsAhzXMM bpoQBgGGRcSIRRIMHOfFEWawgyUSfRZHpV6WyNDfuWL/TwFySF GVbkU627h3OWHnrxQFah5wYY4Qg= Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5b5e_6f62_c0520da0_81ac_4ef1_9879_10d06a04010c; Thu, 21 Feb 2019 08:00:29 -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; Thu, 21 Feb 2019 08:02:18 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 21 Feb 2019 08:02:19 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 08:02:18 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2775.namprd16.prod.outlook.com (20.178.233.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Thu, 21 Feb 2019 15:02:17 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Thu, 21 Feb 2019 15:02:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Ben Campbell , The IESG CC: "draft-ietf-dots-requirements@ietf.org" , Liang Xia , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-dots-requirements-18: (with COMMENT) Thread-Index: AQHUyZd7LAXuYmhVsUmv3GjVaNyFjKXqWVnw Date: Thu, 21 Feb 2019 15:02:17 +0000 Message-ID: References: <155072052056.20358.15761578065156106209.idtracker@ietfa.amsl.com> In-Reply-To: <155072052056.20358.15761578065156106209.idtracker@ietfa.amsl.com> 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: [122.171.76.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fd370c98-2c63-48eb-595e-08d6980d925d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2775; x-ms-traffictypediagnostic: BYAPR16MB2775: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNzc1OzIzOnRycTFVMXlyc1FCaVE5NmVFTk5kVlhqWW1R?= =?utf-8?B?ZUVWQUlZZ3JKYlVjY3BrbDhTbVRYQ3VPQkpmY1Z0a2xUbGVHVVp1akNrSVpE?= =?utf-8?B?b2xQN3FWaVJWM1dRck9Eb2plenpiT0FpSXBGY05jMkFNRjFwd3lBMzMwY25X?= =?utf-8?B?SHRmZERKdisvYXlQMXUzaGgveXdEVnBNTXhxaW9RWnhiT0t6amVlQ2ljRUo5?= =?utf-8?B?N1JKYjdUejUvWGFLamE0VDc4S1Z2amFIM2wxVHN4aDhEU29TQUt5bjU0dHdn?= =?utf-8?B?ZUZlQ3NmWWJiQ1pwUmxFOTdQU1BiREhXSXlzelQ2N3ZaOFBKWDVqaFljVDRS?= =?utf-8?B?alZiSVlaNlhPaHJpR1J2UDdITW44OXMzeEJMWDJoYmMwM3I0RysyVGNtRm9w?= =?utf-8?B?aEk4UnZ0SGZtbW1UUmZhN2ZSb0RrdTlra1pQUm1rcVFtckhEYzY2K2w2WUJH?= =?utf-8?B?TWpQT2o1UElxVGdwelZuZ1M4Z2FnTVo3aW40dCs5M0lNTFZyQm01dmFJTkVm?= =?utf-8?B?ZGtrbG5FNE1BUmVmMFVYNTVYWDBoQVoxcHN2TkFVazk3RU9qcTcvWUVCQ2tF?= =?utf-8?B?OGVOLzBVWXEvRVI3cysrR3JvZ1p0eUJyTGwwci9sYUpQa3V6RTJGNmhmZmZU?= =?utf-8?B?bkJCeEhJT1pyUmNMSEZmNnJ3bTRtVjdGd0g5dHV4RkhMTUh0NndVUVRlNTBT?= =?utf-8?B?WkFnZWZKdTV2cklCSjRMWFlXTEgvLzhHU1ZFaTdEalVZbFJmdjhhTHVldnZI?= =?utf-8?B?cE1iOGdNSjdvbWNaZmVuSVNhVGNxeWFKREw1di9iOVpKa05mVmVVTlk4T25D?= =?utf-8?B?N2JLV081T1VWbFdNK2RNV0hadDFGNlhZUHV6M0FVbW56YU1WczhXWFE2aGFT?= =?utf-8?B?Q25mRkptdCs4cDdvcmlzbzBWd2NJaUdOVFcxdXJzem84TFdkS0g4NHVXdXU2?= =?utf-8?B?cUNZZE5FSlEwanV4MjladnQvTmROa0s4Q1JlRS9IZnB2b1lhek1FMXlIcEdE?= =?utf-8?B?Z1VuSHoxMldMUEFUQ01jL01tZ0RMVGF6bTZ3Q0UwQkh2TVFyMXFFUkNWcjZ6?= =?utf-8?B?aS9zQVIvOUpIT0JuNzN2Z0pOMWVna2pHNU5WYldtMjZCeXFnYWROdmpXZGJn?= =?utf-8?B?VXRCaTNvQVFmb2JseHJaa3M4WUlIUlBFdVV0NFpvQ3ZZbXVGOHBjbDB1cFZT?= =?utf-8?B?d1Z2S21jT1dTMmxvSEtPOGhkWE1ZczFNK3NVUldmbGpiVmtjUTVvWXYvaHhv?= =?utf-8?B?ZFFScTJiSDNCUDFGOHYxYTdGM3Vid1NCYmU1bWZqV1dGV3diajUrYjlualox?= =?utf-8?B?OEhJOW5JeFJmNC9adVVLQWVIZkZVYjBNeHZoRVJHVnhiNkp2MFpWQk1yNGp5?= =?utf-8?B?dWdKSzdROHVDMXBUZGtSeCtuTDVuTWdCT3hJaEFSSkYzVkJiZjhVSjh3WUxS?= =?utf-8?B?cDd1MzgzRjQwcXI3RUFpeWd1RjJwYVNJTG43RVN4bUFraXBUTERQc243Q2lz?= =?utf-8?B?Nk5JbVp6NnBnMml3UWQ4VEtUdlNjek1RZ1BZcWw0R0FhRiszYldtOVFqRHlI?= =?utf-8?B?SUdOcWgzcW5XeEEwYmx4dlA5YUR0cEFwTDUrTnNDM0pBZkJVcTlld2I2MmpW?= =?utf-8?B?eEFIcytEVHU3NGxUZkZCV2NLZkVYQk4xbUE4aWdVT0ZQVGp1VHRSTlUvMTNv?= =?utf-8?B?YitUcjdOVUtYaEtSZXBQT25rb1ZTNThoVjdRdGh0cWx6dWpLUldITllXTjFB?= =?utf-8?B?RFJMRmUyakY3clYrakFuSWlqZUthU05HL0g2Q2p5S1VZK0VnSXloVFlQeDdS?= =?utf-8?B?Q2R4WVBMN01hQTBMSWR2R1VIOEtDYmFJNzN5bG1ubGVDMkl1SjZ5c2k3UWFI?= =?utf-8?Q?HIZz7HxwE2o=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(376002)(136003)(396003)(199004)(189003)(32952001)(13464003)(8676002)(8936002)(78486014)(68736007)(316002)(6436002)(229853002)(105586002)(55016002)(106356001)(81166006)(81156014)(71200400001)(25786009)(71190400001)(966005)(76176011)(72206003)(478600001)(9686003)(7696005)(6306002)(14454004)(256004)(53936002)(305945005)(86362001)(486006)(80792005)(446003)(2906002)(7736002)(6246003)(186003)(11346002)(476003)(6506007)(54906003)(53546011)(99286004)(3846002)(110136005)(102836004)(33656002)(74316002)(4326008)(6116002)(5660300002)(26005)(66066001)(97736004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2775; H:BYAPR16MB2790.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: W2EkhpOlc2Ms2JMX+9kZ4fWcOz7l2bmqCtxvN7b4YKkqUVkbyagAIbYm8StTPqd7uwIBYfPURUYABH1i/v53OpywYI9O2gocxwtx1rDFv1OYlZAiGiDPuytkMaTomKR+X+bYPZk756336Ej1vjKHo4SJ6/tQt+yTo5jbim1THWI4mhzg+/EYggJ9BbPyh4XH6pUCERRAIL+z440jjLP5LP9MAdEx2OHZZ40lTbR17X2xZGwt5E+03rtLpNthU0qYMaFUSJ3RwwMX/wVdNKmVwlYvDLBWNoio+0VN92dMOHJlSt700OZg67IWHqV8YtfvA2MLAmlXFqcvPsbhvxVrO9IN8BPDIHxu8YurqUP/niPDhkv8pagd9/EhYGUs1PdvfoqorwRZXh/0pIY+oqWpDetY7Z500uCOyLbBeHOdX6w= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fd370c98-2c63-48eb-595e-08d6980d925d X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 15:02:17.6321 (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: BYAPR16MB2775 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6488> : inlines <7019> : streams <1813688> : uri <2799976> Archived-At: Subject: Re: [Dots] Ben Campbell's No Objection on draft-ietf-dots-requirements-18: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 15:02:59 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwgPGJlbkBu b3N0cnVtLmNvbT4NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE5IDk6MTIgQU0N Cj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1kb3RzLXJl cXVpcmVtZW50c0BpZXRmLm9yZzsgTGlhbmcgWGlhDQo+IDxmcmFuay54aWFsaWFuZ0BodWF3ZWku Y29tPjsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb207 IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogQmVuIENhbXBiZWxsJ3MgTm8gT2JqZWN0aW9uIG9u IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTg6ICh3aXRoDQo+IENPTU1FTlQpDQo+IA0K PiANCj4gDQo+IEJlbiBDYW1wYmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xODogTm8gT2JqZWN0 aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+ IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAtIEknbSBjdXJpb3VzIHdo YXQgdGhlIGFyY2hpdmFsIHZhbHVlIHRoaXMgaGFzIGZvciBwdWJsaXNoaW5nIGFzIGFuIFJGQy4g RGlkIHRoZQ0KPiBXRyBjb25zaWRlciBhbHRlcm5hdGl2ZSBwdWJsaWNhdGlvbiBtZXRob2RzPyAo ZS5nLiwgbGVhdmUgYXMgYSBkcmFmdCwgcHVibGlzaCBpbg0KPiBhIFdHIHdpa2kpDQo+IA0KPiDC pzEuMjogVGhlIGRyYWZ0IHVzZXMgMjExOS84MTc0IGtleXdvcmRzIHRvIGRlc2NyaWJlIHJlcXVp cmVtZW50cyBmb3IgcHJvdG9jb2wNCj4gZGVzaWduLiBUaGF0J3Mgbm90IHJlYWxseSBob3cgMjEx OSBkZWZpbmVzIHRoZW0uIFRoYXQgZG9lc24ndCBwcmV2ZW50IHVzaW5nDQo+IHRoZW0gaGVyZSwg YnV0IGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gbW9kaWZ5IG9yIGFkZCB0byB0aGUgYm9pbGVycGxh dGUgdG8NCj4gaW5kaWNhdGUgdGhpcy4NCg0KU3VyZSwgYWRkZWQgdGhlIGZvbGxvd2luZyBsaW5l Og0KVGhlc2UgY2FwaXRhbGl6ZWQgd29yZHMgYXJlIHVzZWQgdG8gc2lnbmlmeSB0aGUgcmVxdWly ZW1lbnRzIGZvciBET1RTIHByb3RvY29scyBkZXNpZ24uDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4g DQoNCg== From nobody Thu Feb 21 07:03:22 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D6C13101B; Thu, 21 Feb 2019 07:03:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: dots-chairs@ietf.org, frank.xialiang@huawei.com, Liang Xia , draft-ietf-dots-requirements@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2019 07:03:03 -0800 Archived-At: Subject: [Dots] Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 15:03:08 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-dots-requirements-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3543 I only had a short time to read this, but I find myself confused about the COMSEC requirements here. There is no COMSEC requirement for the signaling channel in S 2.2. DATA-002 requires a secure COMSEC protocol for the data channel. SEC-001 and SEC-002 require "peer mutual authentication" and "message confidentiality, integrity, and authentication" according to "industry best practices". This doesn't seem to be a requirement which I can verify or evaluate. If "industry best practices" were to use raw TCP, would such an implementation be conformant. I think what needs to be required here is cryptographic authentication of both sides and of the messages on both channels. Generally I would prefer to require confidentiality on both, but I could maybe see an argument for why that wasn't needed. DETAIL S 2.2. > free to attempt abbreviated security negotiation methods supported > by the protocol, such as DTLS session resumption, but MUST be > prepared to negotiate new security state with the redirection > target DOTS server. The authentication domain of the redirection > target DOTS server MUST be the same as the authentication domain > of the redirecting DOTS server. what is an "authentication domain"? S 2.4. > SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS > protocols MUST take steps to protect the confidentiality, > integrity and authenticity of messages sent between client and > server. While specific transport- and message-level security > options are not specified, the protocols MUST follow current > industry best practices for encryption and message authentication. This is not a verifiable conformance requirement ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 2.1. > proprietary DDoS defenses. Future extensions MUST be backward > compatible. Implementations of older protocol versions MUST > ignore optional information added to DOTS messages as part of > newer protocol versions. Implementations of older protocol > versions MUST reject mandatory information added to DOTS messages > as part of newer protocol versions. MUST reject the information or MUST reject the messages. Conventionally, it's the latter. S 2.2. > discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot > be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for > IPv6. If IPv4 support on legacy or otherwise unusual networks is > a consideration and the PMTU is unknown, DOTS implementations MAY > rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in > [RFC0791] and [RFC1122]. I'm having trouble reading this text. You say above "MUST assume" and "MAY rely" here. Are you saying "send no more than 576" or "you can assume you can send at least 576 and we're not saying anything about the upper bound" S 2.2. > active DOTS client has not requested mitigation, in order to > control load. > > Following mutual authentication, a signal channel MUST be > considered active until a DOTS agent explicitly ends the session. > During peace time, signal channel MUST be considered active until "peace time" is probably not the right word here. After all, my country might be at peace but still subject to a DoS attack From nobody Thu Feb 21 09:25:50 2019 Return-Path: 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 3D8CB131010; Thu, 21 Feb 2019 09:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 ldw9W4lzzweY; Thu, 21 Feb 2019 09:25:47 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33C6131007; Thu, 21 Feb 2019 09:25:46 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1LHPaQ4018357 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Feb 2019 11:25:38 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550769939; bh=96jT6e5vCCUQTz4sDnlt9EKQYo3tTP3MCNVJBwM2z94=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=C8pTlT79kW0Ky2JGtIWkaGhqmglgN5WEa80eGhym5l/IzNd/x4QoKwzQmJ03gseUT 4IK7SXOQsTOBQUIkLjqRwWn8YdPCvOJRZwlk40gcb7KDy8AtpyHBOQ/228tmL7VQ8n WbycqtySJ5rA7KGi+gnYwlgbovRokgbt8qRgJOKQ= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A34B4CD0-3BB4-4E81-A472-2659D30B72DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 21 Feb 2019 11:25:35 -0600 In-Reply-To: Cc: The IESG , "draft-ietf-dots-requirements@ietf.org" , Liang Xia , "dots-chairs@ietf.org" , "dots@ietf.org" To: "Konda, Tirumaleswar Reddy" References: <155072052056.20358.15761578065156106209.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Dots] Ben Campbell's No Objection on draft-ietf-dots-requirements-18: (with 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 17:25:48 -0000 --Apple-Mail=_A34B4CD0-3BB4-4E81-A472-2659D30B72DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 21, 2019, at 9:02 AM, Konda, Tirumaleswar Reddy = wrote: >=20 >> -----Original Message----- >> From: Ben Campbell >> Sent: Thursday, February 21, 2019 9:12 AM >> To: The IESG >> Cc: draft-ietf-dots-requirements@ietf.org; Liang Xia >> ; dots-chairs@ietf.org; >> frank.xialiang@huawei.com; dots@ietf.org >> Subject: Ben Campbell's No Objection on = draft-ietf-dots-requirements-18: (with >> COMMENT) >>=20 >>=20 >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-dots-requirements-18: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> - I'm curious what the archival value this has for publishing as an = RFC. Did the >> WG consider alternative publication methods? (e.g., leave as a draft, = publish in >> a WG wiki) >>=20 >> =C2=A71.2: The draft uses 2119/8174 keywords to describe requirements = for protocol >> design. That's not really how 2119 defines them. That doesn't prevent = using >> them here, but it would be helpful to modify or add to the = boilerplate to >> indicate this. >=20 > Sure, added the following line: > These capitalized words are used to signify the requirements for DOTS = protocols design. That looks good, thanks! Ben. --Apple-Mail=_A34B4CD0-3BB4-4E81-A472-2659D30B72DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxu3w8ACgkQgFZKbJXz 1A3Z9w/+LyktBq84BhC2E5b9Twq/Z4DzFvq0yrKvVppRhY63jgQ6N8jywGXGh/n7 Trhx9cNeMnKCeTmnO7AJrrqGijj2qQkn3496i6jMVPSSgl/9dDPNlbcMOf9PgxWa 29XTgYF89MK9YdxV3LqSRERYPBTR8H9Ez736L6YLomV1/W+DiQL4+jxftXHiinYH rCApQFulYB/l2dX+N+IDtZt06bQ4mzeiN0udwdonA4d0Ial2PfKz63zzAuXRoiAJ dq17baqBMgc6fknUXxgmpshgJ0HEnJFQhYryxoUNvLXMIW2tiGuKsG4C/wQTT8cT q48ONloinudW/xROC6t1zNPgs7nLOdS6fDL3kBmqRPtLyaRudm9ehN6vyOpzf6nk QP0HdnwpDGzFzr2mZYHrRSEtnaeIbbKdxwso8+91FC9WOH3DEfK8uhHeNdNxpj+F VZzyTYKkC3DI5d5Tz8kurpWZesvj+OshU8bj3BmYzeHeCsoQLlQgWsSrPApuUarU WuQmjpvo6425OsMDrKUuk2CeaV36naV4KnRQr/4S2UqgNf1ZlVGsjQvjYUQjpsA0 I71in++m/fC6SJhqKVdL1jbH9SfoSU49krcUxN8LrJVuWL90Tt2jhIFkoVTp9wpw 5EFC8gwLpseyJx+BtcuR9TOOgDFRXWKUUSCLeZj5qE5loUaKiYU= =8YnU -----END PGP SIGNATURE----- --Apple-Mail=_A34B4CD0-3BB4-4E81-A472-2659D30B72DB-- From nobody Fri Feb 22 01:05:32 2019 Return-Path: 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 A43FD126C15; Fri, 22 Feb 2019 01:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 opZdiVnTELcC; Fri, 22 Feb 2019 01:05:29 -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 8AB0A124D68; Fri, 22 Feb 2019 01:05:28 -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=1550826195; 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-ms-exchange-purlcount: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=T8vCib/ITmZn48oyfWbqtUeYFXYsSjSFub3m1M 3YCl0=; b=YsMjuxuz2wHm+ZDL7EsP5/kgppN6UlbY0ldyv6iK DPjfT7+1gkRPlRMVoLc519Y84UMASqJDE+oJqinwVqwxPz9IkK BFU03ZJy5mk+03+lCwRbH5JoWai3Ok7vS7JWXb0KcYg657YZEX Y8ijPjQy8M0JpGfqKKKH1YJ8955HfRA= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2094_ae8a_11076879_7c10_4f59_8f08_36b22147cd0b; Fri, 22 Feb 2019 02:03:15 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 02:05:19 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 22 Feb 2019 02:05:19 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 02:05:18 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2869.namprd16.prod.outlook.com (20.178.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Fri, 22 Feb 2019 09:05:17 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Fri, 22 Feb 2019 09:05:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Suresh Krishnan , The IESG CC: "draft-ietf-dots-requirements@ietf.org" , Liang Xia , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) Thread-Index: AQHUye9Z3rywrNen/UWV2MRMW3H/n6XrTqmw Date: Fri, 22 Feb 2019 09:05:17 +0000 Message-ID: References: <155075827097.8690.6403334025705603554.idtracker@ietfa.amsl.com> In-Reply-To: <155075827097.8690.6403334025705603554.idtracker@ietfa.amsl.com> 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: 56ca5161-bd24-4762-e731-08d698a4dd5f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2869; x-ms-traffictypediagnostic: BYAPR16MB2869: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyODY5OzIzOmN5QUFUd1ljdWtORWhBbkF3VnR4TmFmMTBM?= =?utf-8?B?enZCcnV6M2dpbStrenFoMGFGSlFSek5JRmhwdU4wV28yb3R1ZDhnYjd5RU9U?= =?utf-8?B?cDZkUVh4NnhUakxudExPU3pqcVV2UDFJZDZrOUxBOUFaYmt4eGxiUm11VVI0?= =?utf-8?B?TXg4ZzA1YjEydUIzVU1MOElnZFI3Y1IxaW9MdGhWQXZ6WGV3eTh0QXRZSmJF?= =?utf-8?B?dDZkQ0ZKZVorekRkQ3E3WWgwVDQ2bENiR2dZZ1kySXJjK1pNb0NtakxCZDBZ?= =?utf-8?B?a0Z1dGJHQkc0dEpnQXdVRk9LMnpVM0pUeW83bnBUWHhsUHJqcmZmR0NSZjlj?= =?utf-8?B?UG1mZHhCNHQ2b1RSWGJ6MW9meSttR0o4ZHV3cHZCYmZ2MTZGcjcvcHh2MVBX?= =?utf-8?B?cDQvdWk0SDlPMWUyZ0VRdDFqS3JUcHZEM083RkJwRXZudzFiSHhpODRmNm9I?= =?utf-8?B?K0pFcmZ5Z0E3UUdlYm8xLzdVRWVkWnNKUkhackd5VTBuWFpjNFRGd1JzYnhN?= =?utf-8?B?ZmIwaCt3MmlCYTRQSE9sYVVHRVM2Rmo3OTRxUjYrVU8xekc1TFFXYkJIbHNN?= =?utf-8?B?R09NYXV0bVZiS1ZIRENaOTdXSXhoSlN6YjJUMkh5eXpIby9XTTZEL1R0TkYr?= =?utf-8?B?Tk9BOCtQOVI4dmZ5MmxjNzI4WkJNTWpDOXRGTWVzTmdwazRxS09yaFZib3ZJ?= =?utf-8?B?Ynd5THQvTUFuNWVBNGlFYkxyOUxiSDJoZTkvRWlIWE9lT3ViVnZzbXJRWXU0?= =?utf-8?B?WDJuamc2MHFhN0lvc2JMT0c2UXVjY3ZSa0FvYmhmbEJJd3NaM1VGUnBpTk84?= =?utf-8?B?SkpkbzA1eWdYUytGZ3NaV2RuNDFOZnlQeTlka1N5eFRMTE1WTG0vUEZzN2hx?= =?utf-8?B?VVNjTWYrdG5Pd09rYTNITUlzVFZlSHp2MGxvT081VUE1M0JtS0lFTDlYNkpR?= =?utf-8?B?eXhSWGtsQVdYYXFrVzRXSUp0NytaQ25NbloySGYrblM2R2s5SmZBY2hxTWp4?= =?utf-8?B?TTlvR3pQYXJYdmpLTUlxODNCQVZ4ays5akIrUnZLeFNQZERrcDV5TlhiOWI5?= =?utf-8?B?d1hKdnhFZlA1ZmZRQ2xXak9wOFFBL0Q3ay9ER0s5VXVEVmc3dVNVNlJhL2d1?= =?utf-8?B?MzJkTlFSVlZEdHNDV2g0M2laQUhiaXQ3ZnpzdnN4RnRZSlVmV0NrYmJhQUYz?= =?utf-8?B?bHU1TVQ3YUhNUDU1WlpiL1lkcE50d0g1QWVjZHFmTmlhV203SzNjeEJna2Za?= =?utf-8?B?RWlTNGFzYzlLaEJzaGRZQzFwV3poQW5UT0ZpdTVxU1BFeGlvNUlHSzJCZ2VV?= =?utf-8?B?dUxldmc0MG5NL045Z0gvQVM3cGU0Vnl3dlJiL0hmSmFHbmlTWExaemI2aVpO?= =?utf-8?B?T25BOCtTbkFIYlFHQ2tucnJmVlZRdHRZSDgzYUc4ZkdMWWFZeSsyYk56QXcr?= =?utf-8?B?dUZENjZiMThINFdCZnhaS3diZFVtbnlvek43UDZuNmhEUGlRMDlZZEZNRUh1?= =?utf-8?B?WC9Zb05mQ09hZzhpYTRrSmVyNVRKeTVsUHFockFIZDRmZzdpMmdFMXVEN0J1?= =?utf-8?B?TmF5NVdKeVE0TGw0eUhDSGdlUjAxVzh3U3owRGhmeFFsSjhCK1lUOXdJVFJh?= =?utf-8?B?Ky9RZDRzZml4UzlSdi91NjFwcFhyVmZLTlJQT0NqWnVnbnhiUmlqczFia05U?= =?utf-8?B?eGFRWXBSaDlEeDJSaGc1N3JVTWc5SW4rTFRGbmpkcE9GTUt3UkFlQWFsSkdo?= =?utf-8?B?ZVllM0NsbkErRkY1RWcrNDJ2UzNKVzRGQkFOT2xzMk5PZnd3SjNheEFhNExG?= =?utf-8?B?UVkvSVNzQngxT1A0aXhDWmp1YlhpQUZJZ2dvN29FVXczenFNcks3cWNKcmtt?= =?utf-8?Q?3s5IZWlhG4mCyi2wftyV0PEsQp2UuZPk?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(366004)(396003)(376002)(189003)(32952001)(199004)(13464003)(9686003)(6246003)(6306002)(486006)(186003)(8936002)(316002)(26005)(74316002)(66574012)(256004)(53546011)(6506007)(81166006)(7736002)(305945005)(5660300002)(6116002)(53936002)(81156014)(6436002)(5024004)(66066001)(55016002)(102836004)(4326008)(33656002)(25786009)(8676002)(86362001)(3846002)(229853002)(106356001)(2906002)(71190400001)(71200400001)(105586002)(476003)(80792005)(966005)(110136005)(446003)(76176011)(99286004)(11346002)(97736004)(7696005)(478600001)(54906003)(14454004)(68736007)(72206003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2869; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: /uRb6ARl/69MgsMFKslvot2snJUwUdM9lrHY+78z2J4qZIvf1H+7PzJsqf+bnogoByIC6AFAb7QgGMtm9TnIN3O7mbqZa096Oo1kRRobsKsHKIzVz27zriMFuGeKmNakrc3Zj8L9sektSIzR2yMebqyFELTz3nvN4KJyuFCwJC0YfDigyBVbvucCGFsM+INB5Lr4HjRHuF9rzESeRkD/ciMLZAqRE6TiZkucQ54cYmeTFK9UgKkLmfCOrj5AvVRk5HC2wp7RjL+0catduvltN4nzvWaWbeWr3fiZsJx0ybTFTnNFVcpFS3Kxig6eg4kt6TfAxMC4rRmvah86QdRtLhmgg4mhKwf/iP32bqrtE7kA8H4ASjwkpGQ250JeZk7yzpvu1argn9EhOgOA6OwDuw/Z0iYimAsHOReQMtNV8CE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 56ca5161-bd24-4762-e731-08d698a4dd5f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 09:05:17.4201 (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: BYAPR16MB2869 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6488> : inlines <7019> : streams <1813760> : uri <2800416> Archived-At: Subject: Re: [Dots] Suresh Krishnan'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 09:05:32 -0000 SGkgU3VyZXNoLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoQGthbG9vbS5jb20+DQo+IFNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMSwgMjAxOSA3OjQxIFBNDQo+IFRvOiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHNAaWV0Zi5v cmc7IExpYW5nIFhpYQ0KPiA8ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbT47IGRvdHMtY2hhaXJz QGlldGYub3JnOw0KPiBmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tOyBkb3RzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFN1cmVzaCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3RzLXJl cXVpcmVtZW50cy0xODogKHdpdGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IFRoaXMg ZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90 IGNsaWNrIGxpbmtzIG9yDQo+IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUg dGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiANCj4gU3VyZXNoIEty aXNobmFuIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBk cmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE4OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG ZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4p DQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVy ZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXJl cXVpcmVtZW50cy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KPiBJIHRoaW5rIFNJRy0wMDIgaXMgYSBiaXQgdW5kZXJzcGVjaWZp ZWQuIEl0IHBvaW50cyB0byBkcmFmdC1pZXRmLWludGFyZWEtZnJhZy1mcmFnaWxlDQo+IGFzIHRo ZSByZWNvbW1lbmRlZCBtZWNoYW5pc20gZm9yIGRpc2NvdmVyaW5nIFBNVFVELCBidXQgaW4gZmFj dCBkcmFmdC1pZXRmLQ0KPiBpbnRhcmVhLWZyYWctZnJhZ2lsZSBpcyBkZXNpZ25lZCB0byBwcm92 aWRlIGEgbGlzdCBvZiBwb3RlbnRpYWwgc29sdXRpb25zIGFuZA0KPiByZWNvbW1lbmRhdGlvbnMg Zm9yIGFwcGxpY2F0aW9uIGFuZCBwcm90b2NvbCBkZXZlbG9wZXJzIChTZWN0aW9uIDcuMS4pLiBT byBJDQo+IGV4cGVjdCB0aGlzIGRvY3VtZW50IHRvIHNwZWNpZnkgd2hhdCBpdCBpbnRlbmRzIHRv IGRvIGZvciBmcmFnbWVudGF0aW9uIGluc3RlYWQNCj4gb2YgYSB2YWd1ZSByZWZlcmVuY2UuDQoN CkFkZGVkIHRoZSBmb2xsb3dpbmcgbGluZSB0byBTSUctMDAyOg0KDQpJZiB0aGUgdG90YWwgbWVz c2FnZSBzaXplIGV4Y2VlZHMgdGhlIHBhdGggTVRVLCB0aGUgRE9UUyBhZ2VudCBNVVNUIHNwbGl0 IHRoZSBtZXNzYWdlIGludG8gc2VwYXJhdGUgbWVzc2FnZXM7IGZvciBleGFtcGxlLCB0aGUgbGlz dCBvZiBtaXRpZ2F0aW9uIHNjb3BlIHR5cGVzIA0KY291bGQgYmUgc3BsaXQgaW50byBtdWx0aXBs ZSBsaXN0cyBhbmQgZWFjaCBsaXN0IGNvbnZleWVkIGluIGEgbmV3IG1lc3NhZ2UuDQoNCg0KPiAN Cj4gSVB2NCBkb2VzIG5vdCBzdXBwb3J0IGEgbWluaW11bSBQTVRVIG9mIDU3NiBhcyBjbGFpbWVk IGhlcmUuIFJGQzc5MQ0KPiBjbGVhcmx5IHN0YXRlcyB0aGF0IHRoZSBtaW5pbXVtIFBNVFUgaXMg Njggb2N0ZXRzLiBJIHN1Z2dlc3QgcmV3b3JkaW5nIHRoaXMgdG8NCj4gDQo+IE9MRDoNCj4gRE9U UyBpbXBsZW1lbnRhdGlvbnMgTUFZIHJlbHkgb24gYSBQTVRVIG9mIDU3NiBieXRlcyBmb3IgSVB2 NCBkYXRhZ3JhbXMsDQo+IGFzIGRpc2N1c3NlZCBpbiBbUkZDMDc5MV0gYW5kIFtSRkMxMTIyXS4N Cj4gDQo+IE5FVzoNCj4gRE9UUyBpbXBsZW1lbnRhdGlvbnMgTUFZIGFzc3VtZSBvbiBhIFBNVFUg b2YgNTc2IGJ5dGVzIGZvciBJUHY0DQo+IGRhdGFncmFtcywgYXMgZXZlcnkgSVB2NCBob3N0IG11 c3QgYmUgY2FwYWJsZSBvZiByZWNlaXZpbmcgYSBwYWNrZXQgd2hvc2UNCj4gbGVuZ3RoIGlzIGVx dWFsIHRvDQo+IDU3NiBieXRlcyBhcyBkaXNjdXNzZWQgaW4gW1JGQzA3OTFdIGFuZCBbUkZDMTEy Ml0uDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiBUaGUgcmVjb21tZW5kYXRpb24gb2YgdGhlIDEyODAgYnl0ZSBtaW5pbXVtIGZvciBJ UHY2IG5lZWRzIHNvbWUNCj4gcmVhc29uaW5nIGFuZCBhIHJlZmVyZW5jZSB0byBSRkM4MjAwLiBl LmcuIHNvbWV0aGluZyBsaWtlIHRoaXMgd291bGQgd29yaw0KPiANCj4gT0xEOg0KPiBJZiB0aGUg UE1UVSBjYW5ub3QgYmUgZGlzY292ZXJlZCwgRE9UUyBhZ2VudHMgTVVTVCBhc3N1bWUgYSBQTVRV IG9mIDEyODANCj4gYnl0ZXMgZm9yIElQdjYuDQo+IA0KPiBORVc6DQo+IElmIHRoZSBQTVRVIGNh bm5vdCBiZSBkaXNjb3ZlcmVkLCBET1RTIGFnZW50cyBNVVNUIGFzc3VtZSBhIFBNVFUgb2YgMTI4 MA0KPiBieXRlcywgYXMgSVB2NiByZXF1aXJlcyB0aGF0IGV2ZXJ5IGxpbmsgaW4gdGhlIEludGVy bmV0IGhhdmUgYW4gTVRVIG9mIDEyODANCj4gb2N0ZXRzIG9yIGdyZWF0ZXIgYXMgc3BlY2lmaWVk IGluIFtSRkM4MjAwXS4NCg0KVGhhbmtzLCB1cGRhdGVkIGRyYWZ0IHRvIHVzZSB0aGUgTkVXIHRl eHQgZm9yIElQdjQgYW5kIElQdjYuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQoNCg== From nobody Fri Feb 22 03:42:03 2019 Return-Path: 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 0985B12DD85; Fri, 22 Feb 2019 03:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 oPOMy3p5ojGt; Fri, 22 Feb 2019 03:41:59 -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 DC5BA1277CC; Fri, 22 Feb 2019 03:41:58 -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=1550835583; 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:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-exchange-diagnostics: x-microsoft-antispam-prvs:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: 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=tQeH398KHL5BXKyeXeZgaYzeN8aaFJUuMum4BZ dsY78=; b=osNgsyHBZ1FVH0tBFvi3qC9UPKo09+auXPgTdRDS gE3dJG8XNFkuvRGt8HiDpv8M2F46RomtcDEbcUcAoQ2kQcuo7T h/jFK0zRZdvASS1sUc62nHz40FsB6pWxxTmksoo1GrfzhD6Onp 23tYlWYDvIjUrE8h7PB7QOe0yae8czw= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2098_cb0d_c3e84a10_760a_4f2e_a356_1d385da24152; Fri, 22 Feb 2019 04:39:43 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 04:41:48 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 22 Feb 2019 04:41:48 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 04:41:47 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2821.namprd16.prod.outlook.com (20.178.233.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Fri, 22 Feb 2019 11:41:47 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1622.020; Fri, 22 Feb 2019 11:41:47 +0000 From: "Konda, Tirumaleswar Reddy" To: Eric Rescorla , The IESG CC: "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , Liang Xia , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) Thread-Index: AQHUyfabISbEMvRzDk6nelzTde89MqXrVJcw Date: Fri, 22 Feb 2019 11:41:47 +0000 Message-ID: References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> In-Reply-To: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> 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 x-originating-ip: [49.37.201.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 768c092f-a13e-4c96-ac40-08d698baba01 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2821; x-ms-traffictypediagnostic: BYAPR16MB2821: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyODIxOzIzOlhrR3FvN0Y3NWFCcUFWckRqbFlZNXpLQWhs?= =?utf-8?B?NnRRY1ZCaXlveXN3ZWF3VzRNZ1luNlJsNjltdmpWVzRhVTJ2bVUzQzNoSXdK?= =?utf-8?B?YnNpc29taDR2VkZiTkd0cXB0NERrQ1JyUDV4bElNY1dSWXBnRTU4SFRKZDhL?= =?utf-8?B?UHJRYmpmblpvS3Fpd3R1L2dIaGdsMFdPNVpEQmtwaSs1VmVwWFFzRWVlTmhL?= =?utf-8?B?UWpJaGRVcDBLL3BSNE1SSS9XNTBIWjRwRzVxdkx5Y2VCKzZKNzV4TCtLRFdu?= =?utf-8?B?L0Fsb21VNE54R3N2TFltK2ZKVWdOTzk0T3JjbzZuUzZqenBVRTZvUVFQV0NH?= =?utf-8?B?TlNsaXlzVUQ3bExRU2hKSFFzRW1OVmphUTdkbzdvWnhvMGtOR3RuRTZucmdF?= =?utf-8?B?SjdIcVI5K09JaTR4NnNIRlNGKzhFbDdBaWk1TnZYSkZvZnBUYncrRGxMaTQ0?= =?utf-8?B?NEdaVVhSOVVtM0F3THVoV3VxV1dLYW1OcC9ZempKSTVSMTlJbXE0UTIyM2Nv?= =?utf-8?B?Um0zUWZoZVlrMklia0NaZnNEMThsYXpmalFZQkNPM05jbjliSHA1VERiTi9B?= =?utf-8?B?cXI2MGMwNW94cExQc0RhdzdUam8rSWtQYUFDQTBGdy9LRXdySVl3bm5EODV5?= =?utf-8?B?blAyZmN5WUppMUtLNzdwaUNmOFV6UWxad1V1U2J2bGxCUHBmMitOdmNQYlB3?= =?utf-8?B?NHpLWDJYZ05VSjU1OUxJNTUrV20wYXlpSENRUWxIL1p3VHlubld4anlhRi9s?= =?utf-8?B?cDFlZGJ3eUI1SGRvcDdMc1dhMGVaYzM0ZEZRZThZNUh0ampsRGZSTDBGRWxX?= =?utf-8?B?OUgwdXg2TmFlN1lydGtCVElNU0VhYUgvb2JXZWZKR3BBdDlqcVk1YnYxWndO?= =?utf-8?B?aTREeXp3cDBTd3Qrc3NTUEpmUElzSCtQam9UeHJXTHN2UWgwN3oxcHJIZGJX?= =?utf-8?B?UFJGQXlWZ3hRdlhFWEpFYS9XZE5GcS9pY3lHblJHTzZmQjJLZlM2YzVXbDV5?= =?utf-8?B?ZFgzTkM0MXNFNlY1OFNmczc2Tno1UFBIY2dMd3RGZkpZdEZZcW5RK3VDeFhp?= =?utf-8?B?eXhEVmkyVHlOc25XdndmMVhaL2hzSWlndndBVzZzaS9SbjRISWEycDBhOUJ0?= =?utf-8?B?am9jMHN2YjY2Ylc2R2x3VUw3bjhmM3UwNm5DNGZZVzN2UnRFUlduSmIvWEZn?= =?utf-8?B?cDlWNklPM2l5UGVZME5LekpzTXJqUEsvYWMxQzlyalRHZlpMbVRnQzYxODlE?= =?utf-8?B?SDhyYUNLMjJ0SWVWUzVLa04wZW9ZanFRWmxVUXlTbVU2K0tKdDNwSE0xUnor?= =?utf-8?B?RFNBbWhMRDFaeUJLdndpV24xc212c0FGaFFZU0p6V1Z0bWxBN0RPMlRUc3NK?= =?utf-8?B?clBuWWpkdG9xWmd0bVpXNmI4VTFQblFRZWNPSFRxYWhKNTJxbEx6aGpXSFMz?= =?utf-8?B?dTVKNnM3alZMVk1HajBnRlhFNlVtREoyU3lCa2xHUHNnVHd6dm9jYlBKQzJW?= =?utf-8?B?ZktBdEZrOHpORVY1aVNsMUl5cUpFaVBNNnU0bzd6Z0Y2ZC80b2p4cFVBVVNI?= =?utf-8?B?YlN2R1hBZlZWRVdWT0VTOXVpSm9HaGRYdFl4VWJ1UWhSZmZGYVlQekxXNVlu?= =?utf-8?B?ZjVQVUJsVXVGNmYwQkNnYm9hSWE3aytwZXZvaHl5eDRtQlg4Wlg5UXZrc0dv?= =?utf-8?B?UXdTY3NpOWJMMHJRbmQ5UkJKNjZ3K1dsNGFvdFJMeHRjMmNkMnFTNW5FYWRD?= =?utf-8?B?K09SVmE1YzVvTWR3TEpySHVNdkpGczk4SXN6dmM5M0ZxL1ozRys3UlNNek5v?= =?utf-8?B?eHBESFdkU0NOOGpTQzNRdUN0bXc0S1Z6Z1EvSHJkbEpETXJpTzBEcEN2Vit4?= =?utf-8?B?Um9SNnprVk4xM0FTYUlCUHc3Q0djdFN0WmM0azVITGlYZE1aWTJ5NnNMVXVz?= =?utf-8?B?UEJHUERlT0dRPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(376002)(346002)(13464003)(32952001)(199004)(189003)(5660300002)(33656002)(9686003)(7736002)(25786009)(305945005)(74316002)(81156014)(71200400001)(81166006)(53936002)(8676002)(76176011)(54906003)(110136005)(105586002)(8936002)(6306002)(71190400001)(66066001)(106356001)(316002)(7696005)(99286004)(55016002)(2906002)(229853002)(476003)(72206003)(11346002)(3846002)(486006)(6116002)(446003)(6436002)(80792005)(966005)(14454004)(5024004)(14444005)(256004)(53546011)(68736007)(6506007)(6246003)(97736004)(26005)(4326008)(478600001)(86362001)(102836004)(6346003)(186003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2821; H:BYAPR16MB2790.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: S/TROwwA9QfeMrH6fJsBEMw8SfOw9DbzizsBghskwE+Sxh5YAaTZJdlyp8RSq+sPUcqx+5ONf5yGgNas5dK4rJZz++oFOnksEzW9irDxT7qrLb6QrQxImJFTkw1bmWRQ/FWnBokAuxPvz6g3OztXTs7kAoZ5zKkyYSM975cf6QXMF0EFMU6LfW5hOxgNal88fhYrbt2LHjRN0ncGeR/JxhhYI6cJzBoG/SC28wMKcWy90SM/CGk3UgxcNi9g9yyq17bF1aQDWLt5MSnU+B4eiiY+bM1RrycEQKQDWkg+81KloIo06SaQwcKnsPRX37hgvnpStnjY4SoayDnOabOGKxUj3AgeHPy8PZZcasFMylH6mFjTzV/xVd7VqkTJNSo1t9w1OczhgrMbPH2GtdkRkrAQUQV94unA/1xkyNlBFmU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 768c092f-a13e-4c96-ac40-08d698baba01 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 11:41:47.0564 (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: BYAPR16MB2821 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.3 X-NAI-Spam-Version: 2.3.0.9418 : core <6489> : inlines <7019> : streams <1813770> : uri <2800478> Archived-At: Subject: Re: [Dots] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 11:42:02 -0000 SGkgRXJpYywNCg0KUGxlYXNlIHNlZSBpbmxpbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+DQo+IFNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAyMSwgMjAxOSA4OjMzIFBNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz4NCj4gQ2M6IGRvdHMtY2hhaXJzQGlldGYub3JnOyBmcmFuay54aWFsaWFuZ0BodWF3ZWku Y29tOyBMaWFuZyBYaWENCj4gPGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+OyBkcmFmdC1pZXRm LWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnOw0KPiBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6 IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMt MTg6ICh3aXRoDQo+IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdp bmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5r cyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIg YW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEVyaWMgUmVzY29ybGEgaGFzIGVu dGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtZG90 cy1yZXF1aXJlbWVudHMtMTg6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQ bGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLw0K PiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IFJpY2ggdmVyc2lvbiBvZiB0aGlzIHJldmlldyBhdDoNCj4gaHR0cHM6Ly9tb3pwaGFi LWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDM1NDMNCj4gDQo+IA0KPiBJIG9ubHkgaGFkIGEg c2hvcnQgdGltZSB0byByZWFkIHRoaXMsIGJ1dCBJIGZpbmQgbXlzZWxmIGNvbmZ1c2VkIGFib3V0 IHRoZQ0KPiBDT01TRUMgcmVxdWlyZW1lbnRzIGhlcmUuDQo+IA0KPiBUaGVyZSBpcyBubyBDT01T RUMgcmVxdWlyZW1lbnQgZm9yIHRoZSBzaWduYWxpbmcgY2hhbm5lbCBpbiBTIDIuMi4NCj4gREFU QS0wMDIgcmVxdWlyZXMgYSBzZWN1cmUgQ09NU0VDIHByb3RvY29sIGZvciB0aGUgZGF0YSBjaGFu bmVsLg0KDQpCb3RoIHNpZ25hbCBhbmQgZGF0YSBjaGFubmVsIHJlcXVpcmUgY29uZmlkZW50aWFs aXR5IGFuZCBoYXZlIHRoZSBzYW1lIGRhdGEgcHJpdmFjeSBhbmQgaW50ZWdyaXR5IHJlcXVpcmVt ZW50cy4NCg0KPiBTRUMtMDAxIGFuZCBTRUMtMDAyIHJlcXVpcmUgInBlZXIgbXV0dWFsIGF1dGhl bnRpY2F0aW9uIiBhbmQgIm1lc3NhZ2UNCj4gY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHksIGFu ZCBhdXRoZW50aWNhdGlvbiIgYWNjb3JkaW5nIHRvICJpbmR1c3RyeSBiZXN0DQo+IHByYWN0aWNl cyIuIFRoaXMgZG9lc24ndCBzZWVtIHRvIGJlIGEgcmVxdWlyZW1lbnQgd2hpY2ggSSBjYW4gdmVy aWZ5IG9yDQo+IGV2YWx1YXRlLiBJZiAiaW5kdXN0cnkgYmVzdCBwcmFjdGljZXMiIHdlcmUgdG8g dXNlIHJhdyBUQ1AsIHdvdWxkIHN1Y2ggYW4NCj4gaW1wbGVtZW50YXRpb24gYmUgY29uZm9ybWFu dC4NCj4gDQo+IEkgdGhpbmsgd2hhdCBuZWVkcyB0byBiZSByZXF1aXJlZCBoZXJlIGlzIGNyeXB0 b2dyYXBoaWMgYXV0aGVudGljYXRpb24gb2YgYm90aA0KPiBzaWRlcyBhbmQgb2YgdGhlIG1lc3Nh Z2VzIG9uIGJvdGggY2hhbm5lbHMuIA0KDQpZZXMsIGJvdGggdGhlIHByb3RvY29scyB1c2luZyAo RClUTFMgdG8gbXV0dWFsbHkgYXV0aGVudGljYXRlIGJvdGggc2lkZXMgYW5kIHRoZSBtZXNzYWdl cyBvbiBib3RoIGNoYW5uZWxzIGFyZSBlbmNyeXB0ZWQuDQoNCj4gR2VuZXJhbGx5IEkgd291bGQg cHJlZmVyIHRvIHJlcXVpcmUNCj4gY29uZmlkZW50aWFsaXR5IG9uIGJvdGgsIGJ1dCBJIGNvdWxk IG1heWJlIHNlZSBhbiBhcmd1bWVudCBmb3Igd2h5IHRoYXQgd2Fzbid0DQo+IG5lZWRlZC4NCg0K UmVtb3ZlZCBEQVRBLTAwMiBhbmQgdXBkYXRlZCBzZWN1cml0eSByZXF1aXJlbWVudHMgdG8gZGlz Y3VzcyBjb25maWRlbnRpYWxpdHkgZm9yIGJvdGggRE9UUyBwcm90b2NvbHMuDQoNCiAgIFNFQy0w MDMgIERhdGEgcHJpdmFjeSBhbmQgaW50ZWdyaXR5OiBUcmFuc21pc3Npb25zIG92ZXIgdGhlIERP VFMNCiAgICAgIHByb3RvY29scyBhcmUgbGlrZWx5IHRvIGNvbnRhaW4gb3BlcmF0aW9uYWxseSBv ciBwcml2YWN5LXNlbnNpdGl2ZQ0KICAgICAgaW5mb3JtYXRpb24gb3IgaW5zdHJ1Y3Rpb25zIGZy b20gdGhlIHJlbW90ZSBET1RTIGFnZW50LiAgVGhlZnQsDQogICAgICBtb2RpZmljYXRpb24sIG9y IHJlcGxheSBvZiBtZXNzYWdlIHRyYW5zbWlzc2lvbnMgY291bGQgbGVhZCB0bw0KICAgICAgaW5m b3JtYXRpb24gbGVha3Mgb3IgbWFsaWNpb3VzIHRyYW5zYWN0aW9ucyBvbiBiZWhhbGYgb2YgdGhl DQogICAgICBzZW5kaW5nIGFnZW50IChzZWUgU2VjdGlvbiA0IGJlbG93KS4gIENvbnNlcXVlbnRs eSBkYXRhIHNlbnQgb3Zlcg0KICAgICAgdGhlIERPVFMgcHJvdG9jb2xzIE1VU1QgYmUgZW5jcnlw dGVkIHVzaW5nIHNlY3VyZSB0cmFuc3BvcnRzIA0KICAgICAgKGxpa2UgVExTIGFuZCBEVExTKS4g IERPVFMgc2VydmVycyBNVVNUIGVuYWJsZSBtZWFucyB0byBwcmV2ZW50IGxlYWtpbmcNCiAgICAg IG9wZXJhdGlvbmFsbHkgb3IgcHJpdmFjeS1zZW5zaXRpdmUgZGF0YS4gIEFsdGhvdWdoIGFkbWlu aXN0cmF0aXZlDQogICAgICBlbnRpdGllcyBwYXJ0aWNpcGF0aW5nIGluIERPVFMgbWF5IGRldGFp bCB3aGF0IGRhdGEgbWF5IGJlDQogICAgICByZXZlYWxlZCB0byB0aGlyZC1wYXJ0eSBET1RTIGFn ZW50cywgc3VjaCBjb25zaWRlcmF0aW9ucyBhcmUgbm90DQogICAgICBpbiBzY29wZSBmb3IgdGhp cyBkb2N1bWVudC4NCg0KPiANCj4gREVUQUlMDQo+IFMgMi4yLg0KPiA+ICAgICAgICAgZnJlZSB0 byBhdHRlbXB0IGFiYnJldmlhdGVkIHNlY3VyaXR5IG5lZ290aWF0aW9uIG1ldGhvZHMgc3VwcG9y dGVkDQo+ID4gICAgICAgICBieSB0aGUgcHJvdG9jb2wsIHN1Y2ggYXMgRFRMUyBzZXNzaW9uIHJl c3VtcHRpb24sIGJ1dCBNVVNUIGJlDQo+ID4gICAgICAgICBwcmVwYXJlZCB0byBuZWdvdGlhdGUg bmV3IHNlY3VyaXR5IHN0YXRlIHdpdGggdGhlIHJlZGlyZWN0aW9uDQo+ID4gICAgICAgICB0YXJn ZXQgRE9UUyBzZXJ2ZXIuICBUaGUgYXV0aGVudGljYXRpb24gZG9tYWluIG9mIHRoZSByZWRpcmVj dGlvbg0KPiA+ICAgICAgICAgdGFyZ2V0IERPVFMgc2VydmVyIE1VU1QgYmUgdGhlIHNhbWUgYXMg dGhlIGF1dGhlbnRpY2F0aW9uIGRvbWFpbg0KPiA+ICAgICAgICAgb2YgdGhlIHJlZGlyZWN0aW5n IERPVFMgc2VydmVyLg0KPiANCj4gd2hhdCBpcyBhbiAiYXV0aGVudGljYXRpb24gZG9tYWluIj8N Cg0KV2UgYXJlIHRyeWluZyB0byBzYXkgYm90aCB0aGUgcmVkaXJlY3RpbmcgYW5kIHJlZGlyZWN0 ZWQgdGFyZ2V0IERPVFMgc2VydmVyIGJlbG9uZyB0byB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBk b21haW4uDQoNCk1vZGlmaWVkIHRoZSBsYXN0IGxpbmUgYXMgZm9sbG93czoNClRoZSByZWRpcmVj dGlvbiBET1RTIHNlcnZlciBhbmQgcmVkaXJlY3RpbmcgRE9UUyBzZXJ2ZXIgTVVTVCBiZWxvbmcg dG8gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KDQo+IA0KPiANCj4gUyAyLjQuDQo+ ID4gICAgICBTRUMtMDAyICBNZXNzYWdlIENvbmZpZGVudGlhbGl0eSwgSW50ZWdyaXR5IGFuZCBB dXRoZW50aWNpdHk6IERPVFMNCj4gPiAgICAgICAgIHByb3RvY29scyBNVVNUIHRha2Ugc3RlcHMg dG8gcHJvdGVjdCB0aGUgY29uZmlkZW50aWFsaXR5LA0KPiA+ICAgICAgICAgaW50ZWdyaXR5IGFu ZCBhdXRoZW50aWNpdHkgb2YgbWVzc2FnZXMgc2VudCBiZXR3ZWVuIGNsaWVudCBhbmQNCj4gPiAg ICAgICAgIHNlcnZlci4gIFdoaWxlIHNwZWNpZmljIHRyYW5zcG9ydC0gYW5kIG1lc3NhZ2UtbGV2 ZWwgc2VjdXJpdHkNCj4gPiAgICAgICAgIG9wdGlvbnMgYXJlIG5vdCBzcGVjaWZpZWQsIHRoZSBw cm90b2NvbHMgTVVTVCBmb2xsb3cgY3VycmVudA0KPiA+ICAgICAgICAgaW5kdXN0cnkgYmVzdCBw cmFjdGljZXMgZm9yIGVuY3J5cHRpb24gYW5kIG1lc3NhZ2UgYXV0aGVudGljYXRpb24uDQo+IA0K PiBUaGlzIGlzIG5vdCBhIHZlcmlmaWFibGUgY29uZm9ybWFuY2UgcmVxdWlyZW1lbnQNCg0KV2hl biB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0IGlzIGluaXRpYWxseSBkcmFmdGVkLCB0aGUgV0cgd2Fu dGVkIHRvIHNlbGVjdCB0aGUgY3VycmVudCBJRVRGIGJlc3QgcHJhY3RpY2VzIGZvciBlbmNyeXB0 aW9uIGFuZCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIG9mIERPVFMgbWVzc2FnZXMuICBUaGUgRE9U UyBXRyBoYXMgZGVjaWRlZCB0byB1c2UgKEQpVExTIGZvciBzaWduYWwgY2hhbm5lbCBhbmQgVExT ICBmb3IgZGF0YSBjaGFubmVsLiAgSSBjYW4gbW9kaWZ5IHRoZSB0ZXh0IHRvIHNheSAiY3VycmVu dCBJRVRGIGJlc3QgcHJhY3RpY2VzIGZvciBlbmNyeXB0aW9uIGFuZCBtZXNzYWdlIGF1dGhlbnRp Y2F0aW9uIiBmb3IgYm90aCBTRUMtMDAxIGFuZCBTRUMtMDAyLg0KDQoNCj4gDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFMgMi4xLg0KPiA+ ICAgICAgICAgcHJvcHJpZXRhcnkgRERvUyBkZWZlbnNlcy4gIEZ1dHVyZSBleHRlbnNpb25zIE1V U1QgYmUgYmFja3dhcmQNCj4gPiAgICAgICAgIGNvbXBhdGlibGUuICBJbXBsZW1lbnRhdGlvbnMg b2Ygb2xkZXIgcHJvdG9jb2wgdmVyc2lvbnMgTVVTVA0KPiA+ICAgICAgICAgaWdub3JlIG9wdGlv bmFsIGluZm9ybWF0aW9uIGFkZGVkIHRvIERPVFMgbWVzc2FnZXMgYXMgcGFydCBvZg0KPiA+ICAg ICAgICAgbmV3ZXIgcHJvdG9jb2wgdmVyc2lvbnMuICBJbXBsZW1lbnRhdGlvbnMgb2Ygb2xkZXIg cHJvdG9jb2wNCj4gPiAgICAgICAgIHZlcnNpb25zIE1VU1QgcmVqZWN0IG1hbmRhdG9yeSBpbmZv cm1hdGlvbiBhZGRlZCB0byBET1RTIG1lc3NhZ2VzDQo+ID4gICAgICAgICBhcyBwYXJ0IG9mIG5l d2VyIHByb3RvY29sIHZlcnNpb25zLg0KPiANCj4gTVVTVCByZWplY3QgdGhlIGluZm9ybWF0aW9u IG9yIE1VU1QgcmVqZWN0IHRoZSBtZXNzYWdlcy4NCj4gQ29udmVudGlvbmFsbHksIGl0J3MgdGhl IGxhdHRlci4NCg0KWWVzLCBtb2RpZmllZCB0aGUgbGluZSBhcyBmb2xsb3dzOg0KSW1wbGVtZW50 YXRpb25zIG9mIG9sZGVyIHByb3RvY29sIHZlcnNpb25zIE1VU1QgcmVqZWN0IERPVFMgbWVzc2Fn ZXMgY2FycnlpbmcgbWFuZGF0b3J5IGluZm9ybWF0aW9uIGFzIHBhcnQgb2YgbmV3ZXIgcHJvdG9j b2wgdmVyc2lvbnMuDQoNCj4gDQo+IA0KPiBTIDIuMi4NCj4gPiAgICAgICAgIGRpc2N1c3NlZCBp biBbSS1ELmlldGYtaW50YXJlYS1mcmFnLWZyYWdpbGVdLiAgSWYgdGhlIFBNVFUgY2Fubm90DQo+ ID4gICAgICAgICBiZSBkaXNjb3ZlcmVkLCBET1RTIGFnZW50cyBNVVNUIGFzc3VtZSBhIFBNVFUg b2YgMTI4MCBieXRlcyBmb3INCj4gPiAgICAgICAgIElQdjYuICBJZiBJUHY0IHN1cHBvcnQgb24g bGVnYWN5IG9yIG90aGVyd2lzZSB1bnVzdWFsIG5ldHdvcmtzIGlzDQo+ID4gICAgICAgICBhIGNv bnNpZGVyYXRpb24gYW5kIHRoZSBQTVRVIGlzIHVua25vd24sIERPVFMgaW1wbGVtZW50YXRpb25z IE1BWQ0KPiA+ICAgICAgICAgcmVseSBvbiBhIFBNVFUgb2YgNTc2IGJ5dGVzIGZvciBJUHY0IGRh dGFncmFtcywgYXMgZGlzY3Vzc2VkIGluDQo+ID4gICAgICAgICBbUkZDMDc5MV0gYW5kIFtSRkMx MTIyXS4NCj4gDQo+IEknbSBoYXZpbmcgdHJvdWJsZSByZWFkaW5nIHRoaXMgdGV4dC4gWW91IHNh eSBhYm92ZSAiTVVTVCBhc3N1bWUiIGFuZCAiTUFZDQo+IHJlbHkiIGhlcmUuIEFyZSB5b3Ugc2F5 aW5nICJzZW5kIG5vIG1vcmUgdGhhbiA1NzYiIG9yICJ5b3UgY2FuIGFzc3VtZSB5b3UgY2FuDQo+ IHNlbmQgYXQgbGVhc3QgNTc2IGFuZCB3ZSdyZSBub3Qgc2F5aW5nIGFueXRoaW5nIGFib3V0IHRo ZSB1cHBlciBib3VuZCINCg0KSSBoYXZlIHJlcGxhY2VkIHRoZSBhYm92ZSBsaW5lcyB3aXRoIHRo ZSB0ZXh0IHN1Z2dlc3RlZCBieSBTdXJlc2guDQoNCj4gDQo+IA0KPiBTIDIuMi4NCj4gPiAgICAg ICAgIGFjdGl2ZSBET1RTIGNsaWVudCBoYXMgbm90IHJlcXVlc3RlZCBtaXRpZ2F0aW9uLCBpbiBv cmRlciB0bw0KPiA+ICAgICAgICAgY29udHJvbCBsb2FkLg0KPiA+DQo+ID4gICAgICAgICBGb2xs b3dpbmcgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBhIHNpZ25hbCBjaGFubmVsIE1VU1QgYmUNCj4g PiAgICAgICAgIGNvbnNpZGVyZWQgYWN0aXZlIHVudGlsIGEgRE9UUyBhZ2VudCBleHBsaWNpdGx5 IGVuZHMgdGhlIHNlc3Npb24uDQo+ID4gICAgICAgICBEdXJpbmcgcGVhY2UgdGltZSwgc2lnbmFs IGNoYW5uZWwgTVVTVCBiZSBjb25zaWRlcmVkIGFjdGl2ZQ0KPiA+IHVudGlsDQo+IA0KPiAicGVh Y2UgdGltZSIgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCB3b3JkIGhlcmUuIEFmdGVyIGFsbCwg bXkgY291bnRyeSBtaWdodA0KPiBiZSBhdCBwZWFjZSBidXQgc3RpbGwgc3ViamVjdCB0byBhIERv UyBhdHRhY2sNCg0KQWRkZWQgdGhlIGZvbGxvd2luZyB0ZXJtIHRvIGF2b2lkIGNvbmZ1c2lvbiA6 DQpQZWFjZXRpbWU6IEluIEREb1MsIOKAmHBlYWNldGltZeKAmSByZWZlcnMgdG8gdGhlIHBlcmlv ZCBkdXJpbmcgd2hpY2ggdGhlIHRhcmdldCBuZXR3b3JrIGlzIG5vdCB1bmRlciBERG9TIGF0dGFj ay4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiANCg0K From nobody Fri Feb 22 05:42:02 2019 Return-Path: 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 6CEA8128766 for ; Fri, 22 Feb 2019 05:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 TzGEPdQxiexi for ; Fri, 22 Feb 2019 05:41:53 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59B7130ED8 for ; Fri, 22 Feb 2019 05:41:49 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id q11so1749034lfd.3 for ; Fri, 22 Feb 2019 05:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6R0egXVGyhbRm7SBkgqsh/D9HbNAOvOAeKQtkHkM7K4=; b=Yob9e1ZZ5uwaLRvxKrmr4D8Uk3/ZZhox+dF3QuxvVkA7pe7+BlSWcmLmRE2PushDr1 l1op1Xv801hoUAvvP/iyC9TLks43tbuufeUmZ/sxXQ1QD4VQr6kjNXPOgw/gpUptX99p y49sGeZfxHEfn2i/7y/1TDcCdr/RYkFp7U4yRlLIYFabtqjyIgN9BN4qGVMGwQ/Lhl++ Ffb4d95Me5V9SOaNdhelc0Y5/RJMIOIVKizn38CmB6TKjDBuYdOeDfYV49EXAie6ORKy wYU2macz317OiqFtDPQD/LJrKm3o5kkV0mieEsJOaNJoHASgjPSm/48ssLr5y4omofBs 0YCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6R0egXVGyhbRm7SBkgqsh/D9HbNAOvOAeKQtkHkM7K4=; b=ASXRq0STGLnGHYEBbLMCFs2iYL8mJc6VcYHIg0NMjzyqeJ+7uFEaVvttu5MgAyIHp0 0/6piagHyF0HUqqaTE8yaBpPBYjStjsiaYLyi/mzxRrNGPdiYohITVMr8kdSUZFHFcxS iULqrgAbbtxDSwShM4Ojd3+yvnC2nc896GtZvMPL5CjTnaox/QFE/rgJ44IcB8cg68y4 Z6KL512ktdpnY6eScUJKmImcIsyRkrdyhl69NgyDzFgntdL2NA5OjQaEodkNiKNRjO1y CfXVOSLAzihh3OxWTRsIoklwWRX+3fEwrd6gWvbS3etjZqBmJdPJ74hrensNJZBXxtZd TiyQ== X-Gm-Message-State: AHQUAuaiYytGSci6u9p4ojuk0V1c7rCYZItxZPbU20QWSNnWIJxlcczF rduWLiPmHXLWgQjHUpfzg6/CzcaqpAWF4ke0WYRFow== X-Google-Smtp-Source: AHgI3IZsbF7rnpVO4/spoXtgnkZDLBU3ySS0MkQZOksGz25nZ3abGOgd2lWY3TfrIorpQdBV8LfTaBcPm+RwhnfUotg= X-Received: by 2002:ac2:51bc:: with SMTP id f28mr2669064lfk.123.1550842907533; Fri, 22 Feb 2019 05:41:47 -0800 (PST) MIME-Version: 1.0 References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Fri, 22 Feb 2019 05:41:10 -0800 Message-ID: To: "Konda, Tirumaleswar Reddy" Cc: The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009b3d0d05827bc010" Archived-At: Subject: Re: [Dots] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 13:41:57 -0000 --0000000000009b3d0d05827bc010 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 3:41 AM Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@mcafee.com> wrote: > Hi Eric, > > Please see inline > > > -----Original Message----- > > From: Eric Rescorla > > Sent: Thursday, February 21, 2019 8:33 PM > > To: The IESG > > Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; Liang Xia > > ; draft-ietf-dots-requirements@ietf.org; > > dots@ietf.org > > Subject: Eric Rescorla'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 i= s > safe. > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-dots-requirements-18: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3543 > > > > > > I only had a short time to read this, but I find myself confused about > the > > COMSEC requirements here. > > > > There is no COMSEC requirement for the signaling channel in S 2.2. > > DATA-002 requires a secure COMSEC protocol for the data channel. > > Both signal and data channel require confidentiality and have the same > data privacy and integrity requirements. > Great. That seems appropriate. > > SEC-001 and SEC-002 require "peer mutual authentication" and "message > > confidentiality, integrity, and authentication" according to "industry > best > > practices". This doesn't seem to be a requirement which I can verify or > > evaluate. If "industry best practices" were to use raw TCP, would such = an > > implementation be conformant. > > > > I think what needs to be required here is cryptographic authentication > of both > > sides and of the messages on both channels. > > Yes, both the protocols using (D)TLS to mutually authenticate both sides > and the messages on both channels are encrypted. > > > Generally I would prefer to require > > confidentiality on both, but I could maybe see an argument for why that > wasn't > > needed. > > Removed DATA-002 and updated security requirements to discuss > confidentiality for both DOTS protocols. > > SEC-003 Data privacy and integrity: Transmissions over the DOTS > protocols are likely to contain operationally or privacy-sensitive > information or instructions from the remote DOTS agent. Theft, > modification, or replay of message transmissions could lead to > information leaks or malicious transactions on behalf of the > sending agent (see Section 4 below). Consequently data sent over > the DOTS protocols MUST be encrypted using secure transports > (like TLS and DTLS). DOTS servers MUST enable means to prevent > leaking > operationally or privacy-sensitive data. Although administrative > entities participating in DOTS may detail what data may be > revealed to third-party DOTS agents, such considerations are not > in scope for this document. > This looks good. Note that if you are using DTLS, you may need to opt-in to the anti-replay service, as it is optional. > > > > DETAIL > > S 2.2. > > > free to attempt abbreviated security negotiation methods > supported > > > by the protocol, such as DTLS session resumption, but MUST be > > > prepared to negotiate new security state with the redirection > > > target DOTS server. The authentication domain of the > redirection > > > target DOTS server MUST be the same as the authentication > domain > > > of the redirecting DOTS server. > > > > what is an "authentication domain"? > > We are trying to say both the redirecting and redirected target DOTS > server belong to the same administrative domain. > > Modified the last line as follows: > The redirection DOTS server and redirecting DOTS server MUST belong to th= e > same administrative domain. > How do I interpret this as the redirected party? Does it have to be the same identity in the certificate? Something else? > > S 2.4. > > > SEC-002 Message Confidentiality, Integrity and Authenticity: DO= TS > > > protocols MUST take steps to protect the confidentiality, > > > integrity and authenticity of messages sent between client an= d > > > server. While specific transport- and message-level security > > > options are not specified, the protocols MUST follow current > > > industry best practices for encryption and message > authentication. > > > > This is not a verifiable conformance requirement > > When the requirements draft is initially drafted, the WG wanted to select > the current IETF best practices for encryption and message authentication > of DOTS messages. The DOTS WG has decided to use (D)TLS for signal chann= el > and TLS for data channel. I can modify the text to say "current IETF be= st > practices for encryption and message authentication" for both SEC-001 and > SEC-002. > If it 's (D)TLS, then I think you want to cite RFC 7525 here > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 2.1. > > > proprietary DDoS defenses. Future extensions MUST be backwar= d > > > compatible. Implementations of older protocol versions MUST > > > ignore optional information added to DOTS messages as part of > > > newer protocol versions. Implementations of older protocol > > > versions MUST reject mandatory information added to DOTS > messages > > > as part of newer protocol versions. > > > > MUST reject the information or MUST reject the messages. > > Conventionally, it's the latter. > > Yes, modified the line as follows: > Implementations of older protocol versions MUST reject DOTS messages > carrying mandatory information as part of newer protocol versions. > Thanks. > > > > > > S 2.2. > > > discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU > cannot > > > be discovered, DOTS agents MUST assume a PMTU of 1280 bytes f= or > > > IPv6. If IPv4 support on legacy or otherwise unusual network= s > is > > > a consideration and the PMTU is unknown, DOTS implementations > MAY > > > rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed = in > > > [RFC0791] and [RFC1122]. > > > > I'm having trouble reading this text. You say above "MUST assume" and > "MAY > > rely" here. Are you saying "send no more than 576" or "you can assume > you can > > send at least 576 and we're not saying anything about the upper bound" > > I have replaced the above lines with the text suggested by Suresh. > OK. > > > > > > S 2.2. > > > active DOTS client has not requested mitigation, in order to > > > control load. > > > > > > Following mutual authentication, a signal channel MUST be > > > considered active until a DOTS agent explicitly ends the > session. > > > During peace time, signal channel MUST be considered active > > > until > > > > "peace time" is probably not the right word here. After all, my country > might > > be at peace but still subject to a DoS attack > > Added the following term to avoid confusion : > Peacetime: In DDoS, =E2=80=98peacetime=E2=80=99 refers to the period duri= ng which the > target network is not under DDoS attack. > If you must, but I think this is might be considered a little in bad taste by people who are involved in actual wars. -Ekr > Cheers, > -Tiru > > > > > --0000000000009b3d0d05827bc010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 3:41 AM Konda= , Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.com> wrote:
Hi Eric,

Please see inline

> -----Original Message-----
> From: Eric Rescorla <ekr@rtfm.com>
> Sent: Thursday, February 21, 2019 8:33 PM
> To: The IESG <ie= sg@ietf.org>
> Cc: dots-cha= irs@ietf.org; frank.xialiang@huawei.com; Liang Xia
> <fra= nk.xialiang@huawei.com>; draft-ietf-dots-requirements@ietf.org;<= br> > dots@ietf.org > Subject: Eric Rescorla's Discuss on draft-ietf-dots-requirements-1= 8: (with
> DISCUSS and COMMENT)
>
> This email originated from outside of the organization. Do not click l= inks or
> open attachments unless you recognize the sender and know the content = is safe.
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dots-requirements-18: Discuss
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/= draft-ietf-dots-requirements/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3543<= /a>
>
>
> I only had a short time to read this, but I find myself confused about= the
> COMSEC requirements here.
>
> There is no COMSEC requirement for the signaling channel in S 2.2.
> DATA-002 requires a secure COMSEC protocol for the data channel.

Both signal and data channel require confidentiality and have the same data= privacy and integrity requirements.



> SEC-001 and SEC-002 require "peer mutual authentication" and= "message
> confidentiality, integrity, and authentication" according to &quo= t;industry best
> practices". This doesn't seem to be a requirement which I can= verify or
> evaluate. If "industry best practices" were to use raw TCP, = would such an
> implementation be conformant.
>
> I think what needs to be required here is cryptographic authentication= of both
> sides and of the messages on both channels.

Yes, both the protocols using (D)TLS to mutually authenticate both sides an= d the messages on both channels are encrypted.

> Generally I would prefer to require
> confidentiality on both, but I could maybe see an argument for why tha= t wasn't
> needed.

Removed DATA-002 and updated security requirements to discuss confidentiali= ty for both DOTS protocols.

=C2=A0 =C2=A0SEC-003=C2=A0 Data privacy and integrity: Transmissions over t= he DOTS
=C2=A0 =C2=A0 =C2=A0 protocols are likely to contain operationally or priva= cy-sensitive
=C2=A0 =C2=A0 =C2=A0 information or instructions from the remote DOTS agent= .=C2=A0 Theft,
=C2=A0 =C2=A0 =C2=A0 modification, or replay of message transmissions could= lead to
=C2=A0 =C2=A0 =C2=A0 information leaks or malicious transactions on behalf = of the
=C2=A0 =C2=A0 =C2=A0 sending agent (see Section 4 below).=C2=A0 Consequentl= y data sent over
=C2=A0 =C2=A0 =C2=A0 the DOTS protocols MUST be encrypted using secure tran= sports
=C2=A0 =C2=A0 =C2=A0 (like TLS and DTLS).=C2=A0 DOTS servers MUST enable me= ans to prevent leaking
=C2=A0 =C2=A0 =C2=A0 operationally or privacy-sensitive data.=C2=A0 Althoug= h administrative
=C2=A0 =C2=A0 =C2=A0 entities participating in DOTS may detail what data ma= y be
=C2=A0 =C2=A0 =C2=A0 revealed to third-party DOTS agents, such consideratio= ns are not
=C2=A0 =C2=A0 =C2=A0 in scope for this document.

<= /div>
This looks good. Note that if you are using DTLS, you may need to= opt-in to the anti-replay service,
as it is optional.
=

>
> DETAIL
> S 2.2.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0free to attempt abbreviated secu= rity negotiation methods supported
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the protocol, such as DTLS se= ssion resumption, but MUST be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prepared to negotiate new securi= ty state with the redirection
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0target DOTS server.=C2=A0 The au= thentication domain of the redirection
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0target DOTS server MUST be the s= ame as the authentication domain
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the redirecting DOTS server.<= br> >
> what is an "authentication domain"?

We are trying to say both the redirecting and redirected target DOTS server= belong to the same administrative domain.

Modified the last line as follows:
The redirection DOTS server and redirecting DOTS server MUST belong to the = same administrative domain.

How do I in= terpret this as the redirected party? Does it have to be the same identity = in the certificate? Something else?



> S 2.4.
> >=C2=A0 =C2=A0 =C2=A0 SEC-002=C2=A0 Message Confidentiality, Integr= ity and Authenticity: DOTS
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocols MUST take steps to pro= tect the confidentiality,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0integrity and authenticity of me= ssages sent between client and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server.=C2=A0 While specific tra= nsport- and message-level security
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0options are not specified, the p= rotocols MUST follow current
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0industry best practices for encr= yption and message authentication.
>
> This is not a verifiable conformance requirement

When the requirements draft is initially drafted, the WG wanted to select t= he current IETF best practices for encryption and message authentication of= DOTS messages.=C2=A0 The DOTS WG has decided to use (D)TLS for signal chan= nel and TLS=C2=A0 for data channel.=C2=A0 I can modify the text to say &quo= t;current IETF best practices for encryption and message authentication&quo= t; for both SEC-001 and SEC-002.

If it = 's (D)TLS, then I think you want to cite RFC 7525 here




> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> S 2.1.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proprietary DDoS defenses.=C2=A0= Future extensions MUST be backward
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible.=C2=A0 Implementation= s of older protocol versions MUST
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ignore optional information adde= d to DOTS messages as part of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0newer protocol versions.=C2=A0 I= mplementations of older protocol
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0versions MUST reject mandatory i= nformation added to DOTS messages
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as part of newer protocol versio= ns.
>
> MUST reject the information or MUST reject the messages.
> Conventionally, it's the latter.

Yes, modified the line as follows:
Implementations of older protocol versions MUST reject DOTS messages carryi= ng mandatory information as part of newer protocol versions.

Thanks.



>
>
> S 2.2.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussed in [I-D.ietf-intarea-f= rag-fragile].=C2=A0 If the PMTU cannot
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be discovered, DOTS agents MUST = assume a PMTU of 1280 bytes for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6.=C2=A0 If IPv4 support on l= egacy or otherwise unusual networks is
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a consideration and the PMTU is = unknown, DOTS implementations MAY
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rely on a PMTU of 576 bytes for = IPv4 datagrams, as discussed in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC0791] and [RFC1122].
>
> I'm having trouble reading this text. You say above "MUST ass= ume" and "MAY
> rely" here. Are you saying "send no more than 576" or &= quot;you can assume you can
> send at least 576 and we're not saying anything about the upper bo= und"

I have replaced the above lines with the text suggested by Suresh.

OK.


>
>
> S 2.2.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0active DOTS client has not reque= sted mitigation, in order to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0control load.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Following mutual authentication,= a signal channel MUST be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0considered active until a DOTS a= gent explicitly ends the session.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0During peace time, signal channe= l MUST be considered active
> > until
>
> "peace time" is probably not the right word here. After all,= my country might
> be at peace but still subject to a DoS attack

Added the following term to avoid confusion :
Peacetime: In DDoS, =E2=80=98peacetime=E2=80=99 refers to the period during= which the target network is not under DDoS attack.
If you must, but I think this is might be considered a little = in bad taste by people who are involved in actual wars.

<= /div>
-Ekr


Cheers,
-Tiru

>

--0000000000009b3d0d05827bc010-- From nobody Fri Feb 22 07:02:45 2019 Return-Path: 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 3D58812941A; Fri, 22 Feb 2019 07:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 j9bQczGEEVbF; Fri, 22 Feb 2019 07:02:33 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37C612EB11; Fri, 22 Feb 2019 07:02:31 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id z131so3303428itf.5; Fri, 22 Feb 2019 07:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XGCsqTCmmL67VIBMMrADEFrocujw7jEjlyvhbevpo70=; b=YuWEmOLEzfr1VrPD1/oDrMe1Q5LB9pqWU2KPcu1ibM3NP/MEDZFNetGT4ehfq9D38m 1WpyrZwb4Z7//sCnp2Nj7iHGsWPBwDD9so0VwaOC+5p8JKxiYKkDfyALIdP+1xENdyTO FAU2YjLb8dpwfRrxqM/h48j7ho9Z87FCm5Y3HGjsgt7AQsGwDLYH0Ti6dk1ctJZuJG5L SN9AkZUqzElhxyQJt4OaqsLYMC0S/5n3MyeREwI4S+G+kaeHRAccP7ODNNPVDuVNGW5+ hSwo0A/8P0dj5Tf5oYobgiyRmaNe04EsCLS84OkqeW0r53tHhXEyrVpCSAVuFWffTpDm uUFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XGCsqTCmmL67VIBMMrADEFrocujw7jEjlyvhbevpo70=; b=q2ffAK12pJNAwpQ275BbQY524fSaHyydaI9Kb6n/J5FGf+ml/Xb6mpCvTphCe5T6Jb ubpnHZg7wJ8WnUbVtWNQrR95h3gvUZxs4OAIURfvxD8CDUv6kl9p5K2UDwztFtJTA2Bq 4CvLpHcbNueFJEW6k1HUyzfXl+OZ8tUlfzsIXXpjmUrNKOAN1VVegBv8t96sFpbRQqsw sNi6p58CtI5PscH51FPyAx/tP2ypc676Ps6h3pyIsXJc/VtIxhbHjdqaoPYRYQxV2kyM S5taLnLCI3WI6/45rv0XCGuceBf58KFk63VjknOJJ+oGtZDuV/l/t5Cnug2yD0pqiOlu eqGw== X-Gm-Message-State: AHQUAuaEMk+ILkiLEoVllmTs6DRoPLd4kRQGjdUrK9wKz6dwKUttm8qg gPO0I8S5ANxSVfQKaMT/34s= X-Google-Smtp-Source: AHgI3Iaufdes4BlmCofYoHlfrpETHzA2NbdZQQBm4JyONZK+ofz5S3hGjnrlsCIvs00eD5SV+fq5yQ== X-Received: by 2002:a24:1fc5:: with SMTP id d188mr2363967itd.61.1550847751085; Fri, 22 Feb 2019 07:02:31 -0800 (PST) Received: from [192.168.1.110] (c-73-145-178-129.hsd1.mi.comcast.net. [73.145.178.129]) by smtp.gmail.com with ESMTPSA id m25sm711151iti.16.2019.02.22.07.02.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 07:02:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Andrew Mortensen In-Reply-To: <85EA2A21-3C7C-4C8E-A72F-56026958D7E4@moretension.com> Date: Fri, 22 Feb 2019 10:02:29 -0500 Cc: "Konda, Tirumaleswar Reddy" , The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> <85EA2A21-3C7C-4C8E-A72F-56026958D7E4@moretension.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Dots] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:02:35 -0000 See below. > On Feb 22, 2019, at 8:41 AM, Eric Rescorla wrote: > =E2=80=A6snip... >=20 >>=20 >>=20 >> S 2.2. >>> active DOTS client has not requested mitigation, in order to >>> control load. >>>=20 >>> Following mutual authentication, a signal channel MUST be >>> considered active until a DOTS agent explicitly ends the = session. >>> During peace time, signal channel MUST be considered active >>> until >>=20 >> "peace time" is probably not the right word here. After all, my = country might >> be at peace but still subject to a DoS attack >=20 > Added the following term to avoid confusion : > Peacetime: In DDoS, =E2=80=98peacetime=E2=80=99 refers to the period = during which the target network is not under DDoS attack. >=20 > If you must, but I think this is might be considered a little in bad = taste by people who are involved in actual wars. I think we can just change the text to =E2=80=9CWhen no attack traffic = is present, the signal channel MUST be=E2=80=A6.=E2=80=9D No need for = the extra definition. andrew From nobody Fri Feb 22 07:12:17 2019 Return-Path: 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 2500412941A; Fri, 22 Feb 2019 07:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 I99HeJoyDgru; Fri, 22 Feb 2019 07:12:06 -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 73ABB130DC2; Fri, 22 Feb 2019 07:12:05 -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=1550848181; 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=OZvVShuY0LWW1A4LLh4O+NPO04TgrYfeqFaniS hhEtY=; b=ZtwxtJib5OvP7W89WWVYr70MWKJYczKLeY1qqYQr Tpw+9JfjpildiStglp4sTftwZuKu42dGPLPIKJmId1yvIiEz9J R+eE5kq4M0c0CkJzizcmVX9LSQVJ85o8TXQ8vQhT9X9LRqZ4u5 ENiNtU1s3GLqMEU7HEd3aXw8FOV2T5c= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2094_1994_ea98f5d3_8716_4301_aef6_dfd4fc153eb1; Fri, 22 Feb 2019 08:09:40 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 08:11:46 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 22 Feb 2019 08:11:46 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 08:11:45 -0700 Received: from DM6PR16MB2794.namprd16.prod.outlook.com (20.178.225.219) by DM6PR16MB2457.namprd16.prod.outlook.com (20.177.216.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Fri, 22 Feb 2019 15:11:45 +0000 Received: from DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::d8d0:f6b5:5c38:87b6]) by DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::d8d0:f6b5:5c38:87b6%2]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 15:11:45 +0000 From: "Konda, Tirumaleswar Reddy" To: Andrew Mortensen , Eric Rescorla CC: The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) Thread-Index: AQHUyfabISbEMvRzDk6nelzTde89MqXrVJcwgACABQCAABVcgIAAAVyAgAABgMA= Date: Fri, 22 Feb 2019 15:11:45 +0000 Message-ID: References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> <85EA2A21-3C7C-4C8E-A72F-56026958D7E4@moretension.com> In-Reply-To: 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: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 704a44bd-537b-4ad7-74d2-08d698d80f20 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR16MB2457; x-ms-traffictypediagnostic: DM6PR16MB2457: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE2TUIyNDU3OzIzOk9zV2gyK0R5MEZ1TnlJeCtKZ3lPNVNVNGh1?= =?utf-8?B?aWtYbk5WbzNFanRFaTQvSHorN3p6V3JwUkpLSUtFNC9zdTFpWHF6Smovd1Jq?= =?utf-8?B?VkNPTUcxV3pVUWk5c2NTOXpkMjRPTGdhZHR2VVlOb0hyd1RENGJoK3Bodmp6?= =?utf-8?B?eHJzQ2FHcDBjM3RWZVNrcXNhWmpwM25KQ25lNXVYaVlNMGh4ZWxER2tySEhD?= =?utf-8?B?dE51ZlRxbms5VDFGNlZyZU5MNHlKa0Vob3BCWGQ1b3NmZFVVc3VPWDBEYlJO?= =?utf-8?B?MFFncmFiVTkvM2dtOVR4ZjFkQ2QxT0Z2R3k3Z3A5cDFwMzdjOUE2TVlKSTVQ?= =?utf-8?B?amtqeHZqNGU4MUNDaHEvUkErVk5tdFlRU2k4Q1VpMHhqWG5zMmJvbGcwOVJI?= =?utf-8?B?SVRMV0NMYnIzdUFTbytyTVdUOUpEaEFnbDE1bTBPOE1PL2htM08xaXhQQjQy?= =?utf-8?B?ZTl6cnR5b3d6NE1weWw1NnlpeXB4Q2Z4UEtZRFlHTTFTOHVHbEwxQUp5UU1S?= =?utf-8?B?OE5RTDk1MFRWQkE0akNNNmFoMTViL1ZURGFjUGQ2TEdLYVJDa2FzcHdqcXE5?= =?utf-8?B?bFI0YjhyL3h3NVZieG5HcmRDYmlUbFZCYkVBWGZtOUYvdEVJTHJ0SHFNekxD?= =?utf-8?B?elRNS0lmd3FxdzRTMzN6cmk2WWFrZ09hUXFHT1BmRlBQL1l2SVhRVHVGV2hP?= =?utf-8?B?NGI5NGtiLzNMb2YwMHZJYUVTblQ0RGRmVzhYZ2lpOW9nbnVTeSs5M3VIdWRH?= =?utf-8?B?eDV6N1B5UVN4RUIwd0NRR3lBd0hRNkR3b2pIdUVBZlVFY29VTkpoSTM2QVo2?= =?utf-8?B?ZEVsWEk1YzFUZ2RrVkhJRjMrWW40M0VISWpJN3NYYmd0dkFKc1M5d09xemRV?= =?utf-8?B?bklLTDN2Y2tqVzR1Qkx4QWtiWitDeVlKUEVPL3dKeFU3YlJjUmpaczZ5REls?= =?utf-8?B?RlplNExBNzA5UWZIdUM4dGFoVmNxV2VPdk9iSzBjUEhEWFJOZ2drU1lMd0pO?= =?utf-8?B?NFFweDlOTmcvTGZHVCtkancyWDdWeEVzckNwSWlmVURaV3dXVE5ZV3AzbWxD?= =?utf-8?B?VitvSXFZaGRCaFN4VHdPRkRlSFgyZkFZUzgyTi9MbVFxNGh0aThkRDJ6N3FD?= =?utf-8?B?MGhRc0trYnpjeXhzN0dOeWZQazZ4d3JNNHZpMkZ0b0pSeWNmcURmbStESmh4?= =?utf-8?B?cjhjZTBJWjdpcG9nQy9Vc2ZFc3dEZDZFbEhYZzg2Umt1L1pFZFhka1JtejJM?= =?utf-8?B?Q1hCUWV4MVVYMUVUSWhEU2xaN1hpWTBHQ2RCd1FRWVZqMEZ6eGZWa1ZlaEhw?= =?utf-8?B?amVBS0xUMWVjeG9YMHJGMnhNNWdBSHVQamROc3ZhVERPRlJCVU53R1E1NXI3?= =?utf-8?B?MWVQWmFTSFpBanhlcm1OSFpNUXJ0aGttZ0N2a1cxUTdlR2xaeFNRZTByMGFS?= =?utf-8?B?bVdHcW5DYWIyazMxdXg3U3pVclEyWmxDUVJQaTBaZjVDbER0OEFUS2VNYk9q?= =?utf-8?B?U3JmdnJVZ0dsSHdCSjFMWnQ5NzMxd0ZuRHJZN2ZreGlPQjhsS2p4dHdJYkhw?= =?utf-8?B?UWNJSEUxcmRuQ3l6VDFXd2gwbml1QXRodGRQa2Q3NGxERkJrVUxiK3RUVnB2?= =?utf-8?B?OG1zVUxIc0sxejZsN25ObnZrWDlHeWowT0xidUhpemZFcWMvUnRnZ2dOR01L?= =?utf-8?B?akpuazUzWmllSmtVd2NNd1ZLZmlLb2ZFS1hIQlIzTSsvWW5hWStuMHhYQzFi?= =?utf-8?B?blFLZWR1dEdSY3hvU0hHZW1JSG5yd2Q5Ym85MEd2dkdoR2pWODZYOE5vdSt4?= =?utf-8?B?WDlnSFU0bHpRRVFkbHVPdVpKWWtqQzZGNVFIMFJwMWhyVEprbVdnd2p6UnFQ?= =?utf-8?Q?opdjjK2s13g=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(136003)(366004)(346002)(13464003)(189003)(199004)(32952001)(71190400001)(76176011)(71200400001)(3846002)(99286004)(5660300002)(102836004)(7696005)(93886005)(53546011)(6506007)(66066001)(8936002)(6116002)(86362001)(8676002)(81166006)(54906003)(14454004)(110136005)(81156014)(316002)(11346002)(2906002)(256004)(446003)(5024004)(486006)(14444005)(97736004)(25786009)(476003)(74316002)(478600001)(26005)(105586002)(55016002)(186003)(72206003)(80792005)(68736007)(6246003)(7736002)(4326008)(33656002)(6436002)(53936002)(229853002)(9686003)(106356001)(305945005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR16MB2457; H:DM6PR16MB2794.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: m+l3Px3rQjadl9tWKfjdwnueA9QH6smVsjkqJwEZ9VdLlrkXgBE/fTktCd942XfAQoRFKWtJ0anzIo1JimcBIldjk8i2lBuW1jhvKRlgYtdqwbX2A0aSIUHusPDIQD1SDb/i4s+57SGRxO7TxxUCaCl5ZZDBgC2E45sHnDS9Ej19deo1MsyGWAnuWBV/SdsIstnkyMA5r0GyAhzA/hSMUFQ78BitBBb6d6H6tqjEHun8R5vTZ8sVgQ87l9OSXSu/rFD3HriO1XYWfso5PeWoZZ7qLZqdBt4BT1hw12V8galgp3KJxTwbq/bFXQkmcGztTr0LCWDBHTmS6173qoKCaFyIOa63OMJ8meUVEzxEA4TbmQCdBCQox7EP1P4WgYGg+PEMAaN9oqzW+OTPVwTXA+uRoYXXhVfBYKZaLfSHS2Q= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 704a44bd-537b-4ad7-74d2-08d698d80f20 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 15:11:45.2095 (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: DM6PR16MB2457 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6489> : inlines <7019> : streams <1813784> : uri <2800557> Archived-At: Subject: Re: [Dots] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:12:08 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcgTW9ydGVuc2VuIDxh bmRyZXdtb3J0ZW5zZW5AZ21haWwuY29tPg0KPiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIyLCAy MDE5IDg6MzIgUE0NCj4gVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCj4gQ2M6IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b20+Ow0KPiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRvdHMtY2hhaXJzQGlldGYub3JnOyBm cmFuay54aWFsaWFuZ0BodWF3ZWkuY29tOw0KPiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRz QGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBFcmljIFJlc2NvcmxhJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE4OiAod2l0aA0KPiBESVND VVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lk ZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3INCj4gb3BlbiBhdHRh Y2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250 ZW50IGlzIHNhZmUuDQo+IA0KPiBTZWUgYmVsb3cuDQo+IA0KPiA+IE9uIEZlYiAyMiwgMjAxOSwg YXQgODo0MSBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPiB3cm90ZToNCj4gPiDigKZz bmlwLi4uDQo+ID4NCj4gPj4NCj4gPj4NCj4gPj4gUyAyLjIuDQo+ID4+PiAgICAgICAgYWN0aXZl IERPVFMgY2xpZW50IGhhcyBub3QgcmVxdWVzdGVkIG1pdGlnYXRpb24sIGluIG9yZGVyIHRvDQo+ ID4+PiAgICAgICAgY29udHJvbCBsb2FkLg0KPiA+Pj4NCj4gPj4+ICAgICAgICBGb2xsb3dpbmcg bXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBhIHNpZ25hbCBjaGFubmVsIE1VU1QgYmUNCj4gPj4+ICAg ICAgICBjb25zaWRlcmVkIGFjdGl2ZSB1bnRpbCBhIERPVFMgYWdlbnQgZXhwbGljaXRseSBlbmRz IHRoZSBzZXNzaW9uLg0KPiA+Pj4gICAgICAgIER1cmluZyBwZWFjZSB0aW1lLCBzaWduYWwgY2hh bm5lbCBNVVNUIGJlIGNvbnNpZGVyZWQgYWN0aXZlDQo+ID4+PiB1bnRpbA0KPiA+Pg0KPiA+PiAi cGVhY2UgdGltZSIgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCB3b3JkIGhlcmUuIEFmdGVyIGFs bCwgbXkNCj4gPj4gY291bnRyeSBtaWdodCBiZSBhdCBwZWFjZSBidXQgc3RpbGwgc3ViamVjdCB0 byBhIERvUyBhdHRhY2sNCj4gPg0KPiA+IEFkZGVkIHRoZSBmb2xsb3dpbmcgdGVybSB0byBhdm9p ZCBjb25mdXNpb24gOg0KPiA+IFBlYWNldGltZTogSW4gRERvUywg4oCYcGVhY2V0aW1l4oCZIHJl ZmVycyB0byB0aGUgcGVyaW9kIGR1cmluZyB3aGljaCB0aGUgdGFyZ2V0DQo+IG5ldHdvcmsgaXMg bm90IHVuZGVyIEREb1MgYXR0YWNrLg0KPiA+DQo+ID4gSWYgeW91IG11c3QsIGJ1dCBJIHRoaW5r IHRoaXMgaXMgbWlnaHQgYmUgY29uc2lkZXJlZCBhIGxpdHRsZSBpbiBiYWQgdGFzdGUgYnkNCj4g cGVvcGxlIHdobyBhcmUgaW52b2x2ZWQgaW4gYWN0dWFsIHdhcnMuDQo+IA0KPiBJIHRoaW5rIHdl IGNhbiBqdXN0IGNoYW5nZSB0aGUgdGV4dCB0byDigJxXaGVuIG5vIGF0dGFjayB0cmFmZmljIGlz IHByZXNlbnQsIHRoZQ0KPiBzaWduYWwgY2hhbm5lbCBNVVNUIGJl4oCmLuKAnSBObyBuZWVkIGZv ciB0aGUgZXh0cmEgZGVmaW5pdGlvbi4NCg0KWWVzLCB3aWxsIGFsc28gcmVtb3ZlIHRoZSB1c2Ug b2YgJ3BlYWNldGltZScgd29yZCBmcm9tIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGRyYWZ0Lg0K DQotVGlydQ0KDQo+IA0KPiBhbmRyZXcNCg0K From nobody Fri Feb 22 07:28:50 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F1112EB11; Fri, 22 Feb 2019 07:28:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <155084932838.5476.5609302154538066964@ietfa.amsl.com> Date: Fri, 22 Feb 2019 07:28:48 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-27.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:28:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification Authors : Mohamed Boucadair Tirumaleswar Reddy Filename : draft-ietf-dots-data-channel-27.txt Pages : 70 Date : 2019-02-22 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; o reference: RFC XXXX Please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-27 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 22 07:29:43 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E47130EEB; Fri, 22 Feb 2019 07:29:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <155084937056.5323.18401033305053602209@ietfa.amsl.com> Date: Fri, 22 Feb 2019 07:29:30 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 15:29:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-29.txt Pages : 99 Date : 2019-02-22 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data- channel) Please update TBD/TBD1/TBD2 statements with the assignments made by IANA to DOTS Signal Channel Protocol. Also, please update the "revision" date of the YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-29 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 22 08:07:20 2019 Return-Path: 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 EBA95130E8C; Fri, 22 Feb 2019 08:07:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 LV8GGLxdYY2X; Fri, 22 Feb 2019 08:07:02 -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 51F9A130EA5; Fri, 22 Feb 2019 08:07:01 -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=1550851482; 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-ms-exchange-purlcount: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: 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=0TAxMrGv+DnSI+xSx2ZwVRIJzp8aB17pL3EQNf KO32M=; b=dKyWQSt/+BF8+v1ibs4PA4vK61uOHL0pvVBUMGaw oflw5uVPfmmUOHFy+isAaRZhWr0A0tYJNsw3+igIdDWOQU+v+x /2UAA+813p3jl4KcPuTsAHMVopTBDbNRzg9n+IUWWmI+IrvLWr cdyL/U1zgQuoFyi44KJVoVZyM5TZPQo= 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 2098_7938_e8b8c833_959d_48aa_9d0b_45e3e298a432; Fri, 22 Feb 2019 09:04:41 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 09:06:06 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 22 Feb 2019 09:06:06 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 09:06:05 -0700 Received: from DM6PR16MB2794.namprd16.prod.outlook.com (20.178.225.219) by DM6PR16MB2938.namprd16.prod.outlook.com (20.178.226.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Fri, 22 Feb 2019 16:06:05 +0000 Received: from DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::d8d0:f6b5:5c38:87b6]) by DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::d8d0:f6b5:5c38:87b6%2]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 16:06:05 +0000 From: "Konda, Tirumaleswar Reddy" To: Eric Rescorla CC: The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) Thread-Index: AQHUyfabISbEMvRzDk6nelzTde89MqXrVJcwgACABQCAABlgMA== Date: Fri, 22 Feb 2019 16:06:05 +0000 Message-ID: References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> In-Reply-To: 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: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a31f5d09-8915-4733-e042-08d698dfa62b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR16MB2938; x-ms-traffictypediagnostic: DM6PR16MB2938: x-ms-exchange-purlcount: 4 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE2TUIyOTM4OzIzOjcvOFJjVHVISlNJU29xT014N3RYY1FrOVZk?= =?utf-8?B?c3NOVTBEUUpEV1BONEFkelozL2VVcU1ieWt0cnM5R0VuUFpJU1FPNnU5Si92?= =?utf-8?B?REEzcjFFMUt5ZFhaeUtmaGZnMUxyRXVpN3A1Wk5wU2FxWkNjcVhJQzZvTW13?= =?utf-8?B?bmY0bGFlT1FpRy9XT0tSR2FSSU8vYkU4TlVVQUJjYzk5OStYeTBmYjBTYVQ1?= =?utf-8?B?bkhqays3VWhON0FRYzA5VjQvV2U0dVVYRmZuclFBamZ4UFpOTmZlWTZWRTBx?= =?utf-8?B?OVZqa3J5YkF5ZC95Q2RGbEtZczVuOVQ4RE1pUGFseUhaZjV6clBhdmNtb1lT?= =?utf-8?B?cGQyazFBMzdaRGpQS05Kdk13Y0twb1hvUXYySU44ZmdqeG9lTWNLNllYZVhL?= =?utf-8?B?OWZQVXk1L0ZpSU4rZHNpaGY4TWJBYW5WY0lGRXZReTRoR25QZjkzaUR6T3BN?= =?utf-8?B?eXYrMG52THc5cmNTZGY0U2k4WEJNcHFyMDVMczJKbVllUlh5VDB4L0JPYllz?= =?utf-8?B?eVFWc2htK3I5cDJ4VEIrblBlNUx5TVZhK3dlM2ZVZFRCSlJZT1drTW1YRWJ4?= =?utf-8?B?UUI3UXpaNEYyd1NNejh4TmlQc2M0Ymc5VzhmZVRWaXdkcjFRVXQxOHhLUXVq?= =?utf-8?B?QmpFMm83V2JJczhvTUV2UnR0WG9GR2cxL2dURDYxNk5qSm1PdTBjR01qRzRH?= =?utf-8?B?T3RETnVJb2FrdVlGdHZFRGxCbnVYSmZmSEFhd1ZSRmU4STFrd3ZnUnJHMkk0?= =?utf-8?B?T3Rkd2ptWkx4aUkxWjBodHlMVStTdGgrSXB3Ym1WYzBCWFpsT3EvQ1pNRHJ0?= =?utf-8?B?TGhwVWNwM1hEUkYveEpTY3hTNmppVzRxY2RtemhvSTdOQU9zWmRvQTZjTmpE?= =?utf-8?B?dCt4NEVZS0o3Snh5VnJHNU1ZMlpZamhmd1g3VDBydTJkbjduODJHY1V1S3pI?= =?utf-8?B?R1lYOGIzM2FOZjk0bGxTanhzUjc2eUZDRFJEcmFuS3FUUGZlVG4wRWJOOG5n?= =?utf-8?B?QjZkWWxuMXI5emJHYUhPem9jM0hYQ2ZPd1dZNDVyeVpWTjNrS2ZUeWk5alNR?= =?utf-8?B?Z3N2K3U5bDRkYUpESDlzZERXYTc0UHR3Z3dwbkk1dVkwS1lRMUgrSWNBY0xP?= =?utf-8?B?WmpIKzhIMVVjNFNPd0N2OWlJdktheEtTb0RZZWpIdmFqeTRTUEgwR0xxbXAz?= =?utf-8?B?WXF5WFMrVVp5TUhJL2RuOFNGdU8zWUYzRkp3endKZDRNT3B1UVNCanZkajhL?= =?utf-8?B?NUR6b2xJeTNwNFRmMjVDTDYxcHJaNDJCOTg4MWlkbmpuWTBZUjhmT1lieDM0?= =?utf-8?B?amtlMGtVY3ZtaEIraEYrRG1wamE0ZU54b1N0bitUQVkxZCszOS8wWUtJQTdw?= =?utf-8?B?R1pudms5RzlKak96aE8ydEpMUlpjTTcyWG5zVm4xZHNzNzN4M0dqTTZkakxt?= =?utf-8?B?ZHlib0VSR29LMlFvZmJ2c2h5N3hmUllzTmhNTk1LclBDNnlDQXFsVkExSk9t?= =?utf-8?B?eU00Q2hMZ1lUMzI5UzIyazdMdkdaYkYxNXR5clhMOFBFNkxjekJMT3Y1QjFy?= =?utf-8?B?MVBKK083U2h4bUxTRWlBZ0pZMHNSWEVKK21MbHV0dGdpenkxandSTmlPcCtl?= =?utf-8?B?MTIvWVNnNGFCcjRNSjRFWTIwSkhmcVNVeEJlMEJTOUdvZm5Jand6L0dWRW1r?= =?utf-8?B?WWR3RjVFMDZTa0l0dVhQbndybGwxM2ptYVUrdFZWRjZDR3hiR2dTdnYyZWRI?= =?utf-8?B?RkdLM0ZKNW9hZk5wZU9MWlRBQTJ3UDR6UEJqaUZ4ajN5MWd6ZEI5TFBIbVJ0?= =?utf-8?B?bTZSampLc0Y0Qk45amJ4VFcxeE56WitESHI0azNDSFhRNWFaVUQrVnFXSWJv?= =?utf-8?B?MmdScmhDVUNrQ0xwWHlybUxpSFpSNTFSMnNRbmJxZGExOExTYmd5dldCWHV2?= =?utf-8?B?eGllMFZ3ZXcyR0ZWTFU4bmhvUys3MFA5alRyUTVCcFhNRmtjaUljNnNVMHhv?= =?utf-8?Q?rmvVvW?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(39860400002)(366004)(346002)(32952001)(13464003)(189003)(199004)(71190400001)(2906002)(14454004)(97736004)(478600001)(606006)(102836004)(6506007)(26005)(72206003)(966005)(316002)(5024004)(25786009)(71200400001)(4326008)(53546011)(99286004)(14444005)(446003)(21615005)(476003)(11346002)(256004)(486006)(86362001)(5660300002)(186003)(8676002)(80792005)(6916009)(8936002)(6306002)(55016002)(6246003)(229853002)(105586002)(33656002)(7736002)(68736007)(81156014)(81166006)(106356001)(53936002)(54906003)(76176011)(790700001)(6116002)(236005)(3846002)(54896002)(9686003)(7696005)(74316002)(66066001)(6436002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR16MB2938; H:DM6PR16MB2794.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 9MaGKi81SWaM3k7DlpkZO0+lrvMpjuPEcpv2Bz+ACGfRS8y7VH+eNfQRBUPZAiXaB1YN3sg4wwFkRiOdlzEkRums4kUwwRJwCNv42Kco7OCMT8wStzRt9scgkrOW3dA7KSH1s5m/4rmr809VYY81HXUTKSDbaNyO+A+z2g79mwrjEVHXGiq+I8YqTDC4no4h3GpYq4OxLf6zrosi073/t/GRwj1K2PNeGVFrLTY5oAGw7xIbOLp5YEc79sKuCJsmpA63cvB4EYSoRbZF1ngSB1/zzeta14kvDehdZJRTjPSaC9/Rsn6lOaTABt8LtyjElasKKopzbk5SB+0YssByWCETvQfAvM+cE2JPQiMLsjfa1UrKaB9iMa6mVlju9esfXHBOv55cS+WpBpD3Yv8nHt2y2OY+kAZUdrbVFOHM7pM= Content-Type: multipart/alternative; boundary="_000_DM6PR16MB27948B94FCBF0A460F90A9C7EA7F0DM6PR16MB2794namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a31f5d09-8915-4733-e042-08d698dfa62b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 16:06:05.1715 (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: DM6PR16MB2938 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 <6489> : inlines <7019> : streams <1813788> : uri <2800578> Archived-At: Subject: Re: [Dots] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 16:07:06 -0000 --_000_DM6PR16MB27948B94FCBF0A460F90A9C7EA7F0DM6PR16MB2794namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0K U2VudDogRnJpZGF5LCBGZWJydWFyeSAyMiwgMjAxOSA3OjExIFBNDQpUbzogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCkNjOiBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRvdHMtY2hhaXJzQGlldGYub3JnOyBmcmFuay54aWFs aWFuZ0BodWF3ZWkuY29tOyBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzQGlldGYub3JnOyBk b3RzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogRXJpYyBSZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN Cg0KDQpDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4g YXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUg Y29udGVudCBpcyBzYWZlLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Cg0KT24gRnJpLCBGZWIgMjIsIDIwMTkgYXQgMzo0MSBBTSBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPj4gd3JvdGU6DQpIaSBFcmljLA0KDQpQbGVhc2Ugc2Vl IGlubGluZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEVyaWMgUmVz Y29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4NCj4gU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDIxLCAyMDE5IDg6MzMgUE0NCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4NCj4gQ2M6IGRvdHMtY2hhaXJzQGlldGYub3JnPG1h aWx0bzpkb3RzLWNoYWlyc0BpZXRmLm9yZz47IGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb208bWFp bHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+OyBMaWFuZyBYaWENCj4gPGZyYW5rLnhpYWxp YW5nQGh1YXdlaS5jb208bWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+PjsgZHJhZnQt aWV0Zi1kb3RzLXJlcXVpcmVtZW50c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1kb3RzLXJl cXVpcmVtZW50c0BpZXRmLm9yZz47DQo+IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5v cmc+DQo+IFN1YmplY3Q6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90 cy1yZXF1aXJlbWVudHMtMTg6ICh3aXRoDQo+IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+DQo+IFRo aXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8g bm90IGNsaWNrIGxpbmtzIG9yDQo+IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25p emUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPg0KPiBFcmljIFJl c2NvcmxhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBk cmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE4OiBEaXNjdXNzDQo+DQo+IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZl ZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikN Cj4NCj4NCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPg0KPg0KPiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1yZXF1aXJl bWVudHMvDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPg0KPiBSaWNoIHZlcnNpb24gb2YgdGhpcyByZXZpZXcgYXQ6DQo+IGh0dHBzOi8vbW96 cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0QzNTQzDQo+DQo+DQo+IEkgb25seSBoYWQg YSBzaG9ydCB0aW1lIHRvIHJlYWQgdGhpcywgYnV0IEkgZmluZCBteXNlbGYgY29uZnVzZWQgYWJv dXQgdGhlDQo+IENPTVNFQyByZXF1aXJlbWVudHMgaGVyZS4NCj4NCj4gVGhlcmUgaXMgbm8gQ09N U0VDIHJlcXVpcmVtZW50IGZvciB0aGUgc2lnbmFsaW5nIGNoYW5uZWwgaW4gUyAyLjIuDQo+IERB VEEtMDAyIHJlcXVpcmVzIGEgc2VjdXJlIENPTVNFQyBwcm90b2NvbCBmb3IgdGhlIGRhdGEgY2hh bm5lbC4NCg0KQm90aCBzaWduYWwgYW5kIGRhdGEgY2hhbm5lbCByZXF1aXJlIGNvbmZpZGVudGlh bGl0eSBhbmQgaGF2ZSB0aGUgc2FtZSBkYXRhIHByaXZhY3kgYW5kIGludGVncml0eSByZXF1aXJl bWVudHMuDQoNCkdyZWF0LiBUaGF0IHNlZW1zIGFwcHJvcHJpYXRlLg0KDQoNCg0KPiBTRUMtMDAx IGFuZCBTRUMtMDAyIHJlcXVpcmUgInBlZXIgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIiBhbmQgIm1l c3NhZ2UNCj4gY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHksIGFuZCBhdXRoZW50aWNhdGlvbiIg YWNjb3JkaW5nIHRvICJpbmR1c3RyeSBiZXN0DQo+IHByYWN0aWNlcyIuIFRoaXMgZG9lc24ndCBz ZWVtIHRvIGJlIGEgcmVxdWlyZW1lbnQgd2hpY2ggSSBjYW4gdmVyaWZ5IG9yDQo+IGV2YWx1YXRl LiBJZiAiaW5kdXN0cnkgYmVzdCBwcmFjdGljZXMiIHdlcmUgdG8gdXNlIHJhdyBUQ1AsIHdvdWxk IHN1Y2ggYW4NCj4gaW1wbGVtZW50YXRpb24gYmUgY29uZm9ybWFudC4NCj4NCj4gSSB0aGluayB3 aGF0IG5lZWRzIHRvIGJlIHJlcXVpcmVkIGhlcmUgaXMgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNh dGlvbiBvZiBib3RoDQo+IHNpZGVzIGFuZCBvZiB0aGUgbWVzc2FnZXMgb24gYm90aCBjaGFubmVs cy4NCg0KWWVzLCBib3RoIHRoZSBwcm90b2NvbHMgdXNpbmcgKEQpVExTIHRvIG11dHVhbGx5IGF1 dGhlbnRpY2F0ZSBib3RoIHNpZGVzIGFuZCB0aGUgbWVzc2FnZXMgb24gYm90aCBjaGFubmVscyBh cmUgZW5jcnlwdGVkLg0KDQo+IEdlbmVyYWxseSBJIHdvdWxkIHByZWZlciB0byByZXF1aXJlDQo+ IGNvbmZpZGVudGlhbGl0eSBvbiBib3RoLCBidXQgSSBjb3VsZCBtYXliZSBzZWUgYW4gYXJndW1l bnQgZm9yIHdoeSB0aGF0IHdhc24ndA0KPiBuZWVkZWQuDQoNClJlbW92ZWQgREFUQS0wMDIgYW5k IHVwZGF0ZWQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHRvIGRpc2N1c3MgY29uZmlkZW50aWFsaXR5 IGZvciBib3RoIERPVFMgcHJvdG9jb2xzLg0KDQogICBTRUMtMDAzICBEYXRhIHByaXZhY3kgYW5k IGludGVncml0eTogVHJhbnNtaXNzaW9ucyBvdmVyIHRoZSBET1RTDQogICAgICBwcm90b2NvbHMg YXJlIGxpa2VseSB0byBjb250YWluIG9wZXJhdGlvbmFsbHkgb3IgcHJpdmFjeS1zZW5zaXRpdmUN CiAgICAgIGluZm9ybWF0aW9uIG9yIGluc3RydWN0aW9ucyBmcm9tIHRoZSByZW1vdGUgRE9UUyBh Z2VudC4gIFRoZWZ0LA0KICAgICAgbW9kaWZpY2F0aW9uLCBvciByZXBsYXkgb2YgbWVzc2FnZSB0 cmFuc21pc3Npb25zIGNvdWxkIGxlYWQgdG8NCiAgICAgIGluZm9ybWF0aW9uIGxlYWtzIG9yIG1h bGljaW91cyB0cmFuc2FjdGlvbnMgb24gYmVoYWxmIG9mIHRoZQ0KICAgICAgc2VuZGluZyBhZ2Vu dCAoc2VlIFNlY3Rpb24gNCBiZWxvdykuICBDb25zZXF1ZW50bHkgZGF0YSBzZW50IG92ZXINCiAg ICAgIHRoZSBET1RTIHByb3RvY29scyBNVVNUIGJlIGVuY3J5cHRlZCB1c2luZyBzZWN1cmUgdHJh bnNwb3J0cw0KICAgICAgKGxpa2UgVExTIGFuZCBEVExTKS4gIERPVFMgc2VydmVycyBNVVNUIGVu YWJsZSBtZWFucyB0byBwcmV2ZW50IGxlYWtpbmcNCiAgICAgIG9wZXJhdGlvbmFsbHkgb3IgcHJp dmFjeS1zZW5zaXRpdmUgZGF0YS4gIEFsdGhvdWdoIGFkbWluaXN0cmF0aXZlDQogICAgICBlbnRp dGllcyBwYXJ0aWNpcGF0aW5nIGluIERPVFMgbWF5IGRldGFpbCB3aGF0IGRhdGEgbWF5IGJlDQog ICAgICByZXZlYWxlZCB0byB0aGlyZC1wYXJ0eSBET1RTIGFnZW50cywgc3VjaCBjb25zaWRlcmF0 aW9ucyBhcmUgbm90DQogICAgICBpbiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC4NCg0KVGhpcyBs b29rcyBnb29kLiBOb3RlIHRoYXQgaWYgeW91IGFyZSB1c2luZyBEVExTLCB5b3UgbWF5IG5lZWQg dG8gb3B0LWluIHRvIHRoZSBhbnRpLXJlcGxheSBzZXJ2aWNlLA0KYXMgaXQgaXMgb3B0aW9uYWwu DQoNClllcywgRFRMUyBhbnRpLXJlcGxheSBpcyBhIG1hbmRhdG9yeSBwcm9maWxlIGZvciB0aGUg RE9UUyBhZ2VudHMgKHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1k b3RzLXNpZ25hbC1jaGFubmVsLTI4I3NlY3Rpb24tNy4xKS4NCg0KDQo+DQo+IERFVEFJTA0KPiBT IDIuMi4NCj4gPiAgICAgICAgIGZyZWUgdG8gYXR0ZW1wdCBhYmJyZXZpYXRlZCBzZWN1cml0eSBu ZWdvdGlhdGlvbiBtZXRob2RzIHN1cHBvcnRlZA0KPiA+ICAgICAgICAgYnkgdGhlIHByb3RvY29s LCBzdWNoIGFzIERUTFMgc2Vzc2lvbiByZXN1bXB0aW9uLCBidXQgTVVTVCBiZQ0KPiA+ICAgICAg ICAgcHJlcGFyZWQgdG8gbmVnb3RpYXRlIG5ldyBzZWN1cml0eSBzdGF0ZSB3aXRoIHRoZSByZWRp cmVjdGlvbg0KPiA+ICAgICAgICAgdGFyZ2V0IERPVFMgc2VydmVyLiAgVGhlIGF1dGhlbnRpY2F0 aW9uIGRvbWFpbiBvZiB0aGUgcmVkaXJlY3Rpb24NCj4gPiAgICAgICAgIHRhcmdldCBET1RTIHNl cnZlciBNVVNUIGJlIHRoZSBzYW1lIGFzIHRoZSBhdXRoZW50aWNhdGlvbiBkb21haW4NCj4gPiAg ICAgICAgIG9mIHRoZSByZWRpcmVjdGluZyBET1RTIHNlcnZlci4NCj4NCj4gd2hhdCBpcyBhbiAi YXV0aGVudGljYXRpb24gZG9tYWluIj8NCg0KV2UgYXJlIHRyeWluZyB0byBzYXkgYm90aCB0aGUg cmVkaXJlY3RpbmcgYW5kIHJlZGlyZWN0ZWQgdGFyZ2V0IERPVFMgc2VydmVyIGJlbG9uZyB0byB0 aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4uDQoNCk1vZGlmaWVkIHRoZSBsYXN0IGxpbmUg YXMgZm9sbG93czoNClRoZSByZWRpcmVjdGlvbiBET1RTIHNlcnZlciBhbmQgcmVkaXJlY3Rpbmcg RE9UUyBzZXJ2ZXIgTVVTVCBiZWxvbmcgdG8gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9tYWlu Lg0KDQpIb3cgZG8gSSBpbnRlcnByZXQgdGhpcyBhcyB0aGUgcmVkaXJlY3RlZCBwYXJ0eT8gRG9l cyBpdCBoYXZlIHRvIGJlIHRoZSBzYW1lIGlkZW50aXR5IGluIHRoZSBjZXJ0aWZpY2F0ZT8gU29t ZXRoaW5nIGVsc2U/DQoNClRoZSByZWRpcmVjdGVkIChvciBhbHRlcm5hdGUpIERPVFMgc2VydmVy 4oCZcyBGUUROIHdpbGwgYmUgY29udmV5ZWQgYnkgdGhlIHJlZGlyZWN0aW5nIERPVFMgc2VydmVy LCBhbmQgRE9UUyBjbGllbnQgdXNlcyB0aGUgc2FtZSBleHBsaWNpdCB0cnVzdCBzdG9yZSB0byB2 YWxpZGF0ZQ0KYm90aCB0aGUgc2VydmVycyBjZXJ0aWZpY2F0ZXMuDQoNCg0KPiBTIDIuNC4NCj4g PiAgICAgIFNFQy0wMDIgIE1lc3NhZ2UgQ29uZmlkZW50aWFsaXR5LCBJbnRlZ3JpdHkgYW5kIEF1 dGhlbnRpY2l0eTogRE9UUw0KPiA+ICAgICAgICAgcHJvdG9jb2xzIE1VU1QgdGFrZSBzdGVwcyB0 byBwcm90ZWN0IHRoZSBjb25maWRlbnRpYWxpdHksDQo+ID4gICAgICAgICBpbnRlZ3JpdHkgYW5k IGF1dGhlbnRpY2l0eSBvZiBtZXNzYWdlcyBzZW50IGJldHdlZW4gY2xpZW50IGFuZA0KPiA+ICAg ICAgICAgc2VydmVyLiAgV2hpbGUgc3BlY2lmaWMgdHJhbnNwb3J0LSBhbmQgbWVzc2FnZS1sZXZl bCBzZWN1cml0eQ0KPiA+ICAgICAgICAgb3B0aW9ucyBhcmUgbm90IHNwZWNpZmllZCwgdGhlIHBy b3RvY29scyBNVVNUIGZvbGxvdyBjdXJyZW50DQo+ID4gICAgICAgICBpbmR1c3RyeSBiZXN0IHBy YWN0aWNlcyBmb3IgZW5jcnlwdGlvbiBhbmQgbWVzc2FnZSBhdXRoZW50aWNhdGlvbi4NCj4NCj4g VGhpcyBpcyBub3QgYSB2ZXJpZmlhYmxlIGNvbmZvcm1hbmNlIHJlcXVpcmVtZW50DQoNCldoZW4g dGhlIHJlcXVpcmVtZW50cyBkcmFmdCBpcyBpbml0aWFsbHkgZHJhZnRlZCwgdGhlIFdHIHdhbnRl ZCB0byBzZWxlY3QgdGhlIGN1cnJlbnQgSUVURiBiZXN0IHByYWN0aWNlcyBmb3IgZW5jcnlwdGlv biBhbmQgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBvZiBET1RTIG1lc3NhZ2VzLiAgVGhlIERPVFMg V0cgaGFzIGRlY2lkZWQgdG8gdXNlIChEKVRMUyBmb3Igc2lnbmFsIGNoYW5uZWwgYW5kIFRMUyAg Zm9yIGRhdGEgY2hhbm5lbC4gIEkgY2FuIG1vZGlmeSB0aGUgdGV4dCB0byBzYXkgImN1cnJlbnQg SUVURiBiZXN0IHByYWN0aWNlcyBmb3IgZW5jcnlwdGlvbiBhbmQgbWVzc2FnZSBhdXRoZW50aWNh dGlvbiIgZm9yIGJvdGggU0VDLTAwMSBhbmQgU0VDLTAwMi4NCg0KSWYgaXQgJ3MgKEQpVExTLCB0 aGVuIEkgdGhpbmsgeW91IHdhbnQgdG8gY2l0ZSBSRkMgNzUyNSBoZXJlDQoNClN1cmUsIHdpbGwg Y2l0ZSBSRkM3NTI1Lg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPg0KPiBTIDIuMS4NCj4gPiAgICAgICAgIHByb3ByaWV0YXJ5IEREb1MgZGVmZW5zZXMu ICBGdXR1cmUgZXh0ZW5zaW9ucyBNVVNUIGJlIGJhY2t3YXJkDQo+ID4gICAgICAgICBjb21wYXRp YmxlLiAgSW1wbGVtZW50YXRpb25zIG9mIG9sZGVyIHByb3RvY29sIHZlcnNpb25zIE1VU1QNCj4g PiAgICAgICAgIGlnbm9yZSBvcHRpb25hbCBpbmZvcm1hdGlvbiBhZGRlZCB0byBET1RTIG1lc3Nh Z2VzIGFzIHBhcnQgb2YNCj4gPiAgICAgICAgIG5ld2VyIHByb3RvY29sIHZlcnNpb25zLiAgSW1w bGVtZW50YXRpb25zIG9mIG9sZGVyIHByb3RvY29sDQo+ID4gICAgICAgICB2ZXJzaW9ucyBNVVNU IHJlamVjdCBtYW5kYXRvcnkgaW5mb3JtYXRpb24gYWRkZWQgdG8gRE9UUyBtZXNzYWdlcw0KPiA+ ICAgICAgICAgYXMgcGFydCBvZiBuZXdlciBwcm90b2NvbCB2ZXJzaW9ucy4NCj4NCj4gTVVTVCBy ZWplY3QgdGhlIGluZm9ybWF0aW9uIG9yIE1VU1QgcmVqZWN0IHRoZSBtZXNzYWdlcy4NCj4gQ29u dmVudGlvbmFsbHksIGl0J3MgdGhlIGxhdHRlci4NCg0KWWVzLCBtb2RpZmllZCB0aGUgbGluZSBh cyBmb2xsb3dzOg0KSW1wbGVtZW50YXRpb25zIG9mIG9sZGVyIHByb3RvY29sIHZlcnNpb25zIE1V U1QgcmVqZWN0IERPVFMgbWVzc2FnZXMgY2FycnlpbmcgbWFuZGF0b3J5IGluZm9ybWF0aW9uIGFz IHBhcnQgb2YgbmV3ZXIgcHJvdG9jb2wgdmVyc2lvbnMuDQoNClRoYW5rcy4NCg0KDQoNCj4NCj4N Cj4gUyAyLjIuDQo+ID4gICAgICAgICBkaXNjdXNzZWQgaW4gW0ktRC5pZXRmLWludGFyZWEtZnJh Zy1mcmFnaWxlXS4gIElmIHRoZSBQTVRVIGNhbm5vdA0KPiA+ICAgICAgICAgYmUgZGlzY292ZXJl ZCwgRE9UUyBhZ2VudHMgTVVTVCBhc3N1bWUgYSBQTVRVIG9mIDEyODAgYnl0ZXMgZm9yDQo+ID4g ICAgICAgICBJUHY2LiAgSWYgSVB2NCBzdXBwb3J0IG9uIGxlZ2FjeSBvciBvdGhlcndpc2UgdW51 c3VhbCBuZXR3b3JrcyBpcw0KPiA+ICAgICAgICAgYSBjb25zaWRlcmF0aW9uIGFuZCB0aGUgUE1U VSBpcyB1bmtub3duLCBET1RTIGltcGxlbWVudGF0aW9ucyBNQVkNCj4gPiAgICAgICAgIHJlbHkg b24gYSBQTVRVIG9mIDU3NiBieXRlcyBmb3IgSVB2NCBkYXRhZ3JhbXMsIGFzIGRpc2N1c3NlZCBp bg0KPiA+ICAgICAgICAgW1JGQzA3OTFdIGFuZCBbUkZDMTEyMl0uDQo+DQo+IEknbSBoYXZpbmcg dHJvdWJsZSByZWFkaW5nIHRoaXMgdGV4dC4gWW91IHNheSBhYm92ZSAiTVVTVCBhc3N1bWUiIGFu ZCAiTUFZDQo+IHJlbHkiIGhlcmUuIEFyZSB5b3Ugc2F5aW5nICJzZW5kIG5vIG1vcmUgdGhhbiA1 NzYiIG9yICJ5b3UgY2FuIGFzc3VtZSB5b3UgY2FuDQo+IHNlbmQgYXQgbGVhc3QgNTc2IGFuZCB3 ZSdyZSBub3Qgc2F5aW5nIGFueXRoaW5nIGFib3V0IHRoZSB1cHBlciBib3VuZCINCg0KSSBoYXZl IHJlcGxhY2VkIHRoZSBhYm92ZSBsaW5lcyB3aXRoIHRoZSB0ZXh0IHN1Z2dlc3RlZCBieSBTdXJl c2guDQoNCk9LLg0KDQoNCj4NCj4NCj4gUyAyLjIuDQo+ID4gICAgICAgICBhY3RpdmUgRE9UUyBj bGllbnQgaGFzIG5vdCByZXF1ZXN0ZWQgbWl0aWdhdGlvbiwgaW4gb3JkZXIgdG8NCj4gPiAgICAg ICAgIGNvbnRyb2wgbG9hZC4NCj4gPg0KPiA+ICAgICAgICAgRm9sbG93aW5nIG11dHVhbCBhdXRo ZW50aWNhdGlvbiwgYSBzaWduYWwgY2hhbm5lbCBNVVNUIGJlDQo+ID4gICAgICAgICBjb25zaWRl cmVkIGFjdGl2ZSB1bnRpbCBhIERPVFMgYWdlbnQgZXhwbGljaXRseSBlbmRzIHRoZSBzZXNzaW9u Lg0KPiA+ICAgICAgICAgRHVyaW5nIHBlYWNlIHRpbWUsIHNpZ25hbCBjaGFubmVsIE1VU1QgYmUg Y29uc2lkZXJlZCBhY3RpdmUNCj4gPiB1bnRpbA0KPg0KPiAicGVhY2UgdGltZSIgaXMgcHJvYmFi bHkgbm90IHRoZSByaWdodCB3b3JkIGhlcmUuIEFmdGVyIGFsbCwgbXkgY291bnRyeSBtaWdodA0K PiBiZSBhdCBwZWFjZSBidXQgc3RpbGwgc3ViamVjdCB0byBhIERvUyBhdHRhY2sNCg0KQWRkZWQg dGhlIGZvbGxvd2luZyB0ZXJtIHRvIGF2b2lkIGNvbmZ1c2lvbiA6DQpQZWFjZXRpbWU6IEluIERE b1MsIOKAmHBlYWNldGltZeKAmSByZWZlcnMgdG8gdGhlIHBlcmlvZCBkdXJpbmcgd2hpY2ggdGhl IHRhcmdldCBuZXR3b3JrIGlzIG5vdCB1bmRlciBERG9TIGF0dGFjay4NCg0KSWYgeW91IG11c3Qs IGJ1dCBJIHRoaW5rIHRoaXMgaXMgbWlnaHQgYmUgY29uc2lkZXJlZCBhIGxpdHRsZSBpbiBiYWQg dGFzdGUgYnkgcGVvcGxlIHdobyBhcmUgaW52b2x2ZWQgaW4gYWN0dWFsIHdhcnMuDQoNCk9rYXks IHJlbW92ZWQgdGhlIHdvcmQuDQoNCkNoZWVycywNCi1UaXJ1DQoNCi1Fa3INCg0KDQpDaGVlcnMs DQotVGlydQ0KDQo+DQo= --_000_DM6PR16MB27948B94FCBF0A460F90A9C7EA7F0DM6PR16MB2794namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHNlZSBp bmxpbmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRXJpYyBSZXNjb3Js YSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFy eSAyMiwgMjAxOSA3OjExIFBNPGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5ICZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkb3RzLWNoYWlyc0BpZXRmLm9y ZzsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTsgZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50 c0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRXJpYyBS ZXNjb3JsYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xODogKHdp dGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0i YmFja2dyb3VuZDojRjNGRjMzO2JvcmRlcjpzb2xpZCAjOUI5QTg3IDEuNXB0Ij4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu NzVwdCI+DQo8cD48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5QjhCM0UiPkNBVVRJT048L3NwYW4+PC9zdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzlCOEIzRSI+Ojwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IEV4dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sg bGlua3Mgb3Igb3Blbg0KIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5k ZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0i MiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAyMiwgMjAxOSBhdCAzOjQxIEFNIEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhyZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBtY2FmZWUuY29tIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBFcmljLDxicj4NCjxicj4NClBsZWFzZSBzZWUgaW5saW5lPGJy Pg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTog RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMjEsIDIwMTkgODozMyBQTTxicj4NCiZndDsgVG86IFRoZSBJRVNHICZsdDs8YSBocmVm PSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2dAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpkb3RzLWNoYWlyc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmRvdHMtY2hhaXJzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZnJhbmsueGlhbGlh bmdAaHVhd2VpLmNvbTwvYT47IExpYW5nIFhpYTxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZnJhbmsueGlhbGlh bmdAaHVhd2VpLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtZG90cy1y ZXF1aXJlbWVudHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLWRvdHMtcmVx dWlyZW1lbnRzQGlldGYub3JnPC9hPjs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1Ympl Y3Q6IEVyaWMgUmVzY29ybGEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVu dHMtMTg6ICh3aXRoPGJyPg0KJmd0OyBESVNDVVNTIGFuZCBDT01NRU5UKTxicj4NCiZndDsgPGJy Pg0KJmd0OyBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6 YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcjxicj4NCiZndDsgb3BlbiBhdHRhY2htZW50cyB1 bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNh ZmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEVyaWMgUmVzY29ybGEgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KJmd0OyBkcmFmdC1pZXRmLWRvdHMtcmVx dWlyZW1lbnRzLTE4OiBEaXNjdXNzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoZW4gcmVzcG9uZGlu ZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBl bWFpbDxicj4NCiZndDsgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5PGJyPg0KJmd0OyBwYXJhZ3JhcGgs IGhvd2V2ZXIuKTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSByZWZlciB0 byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48YnI+DQomZ3Q7IGZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVt ZW50cy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMvPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgRElTQ1VTUzo8YnI+ DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgUmljaCB2ZXJzaW9uIG9m IHRoaXMgcmV2aWV3IGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYu ZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDM1NDMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21venBo YWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9EMzU0MzwvYT48YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBJIG9ubHkgaGFkIGEgc2hvcnQgdGltZSB0byByZWFkIHRoaXMsIGJ1dCBJ IGZpbmQgbXlzZWxmIGNvbmZ1c2VkIGFib3V0IHRoZTxicj4NCiZndDsgQ09NU0VDIHJlcXVpcmVt ZW50cyBoZXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSBpcyBubyBDT01TRUMgcmVxdWly ZW1lbnQgZm9yIHRoZSBzaWduYWxpbmcgY2hhbm5lbCBpbiBTIDIuMi48YnI+DQomZ3Q7IERBVEEt MDAyIHJlcXVpcmVzIGEgc2VjdXJlIENPTVNFQyBwcm90b2NvbCBmb3IgdGhlIGRhdGEgY2hhbm5l bC48YnI+DQo8YnI+DQpCb3RoIHNpZ25hbCBhbmQgZGF0YSBjaGFubmVsIHJlcXVpcmUgY29uZmlk ZW50aWFsaXR5IGFuZCBoYXZlIHRoZSBzYW1lIGRhdGEgcHJpdmFjeSBhbmQgaW50ZWdyaXR5IHJl cXVpcmVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkdyZWF0LiBUaGF0IHNlZW1zIGFwcHJvcHJpYXRlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CiZndDsgU0VDLTAwMSBhbmQgU0VDLTAwMiByZXF1aXJlICZxdW90O3BlZXIgbXV0dWFsIGF1dGhl bnRpY2F0aW9uJnF1b3Q7IGFuZCAmcXVvdDttZXNzYWdlPGJyPg0KJmd0OyBjb25maWRlbnRpYWxp dHksIGludGVncml0eSwgYW5kIGF1dGhlbnRpY2F0aW9uJnF1b3Q7IGFjY29yZGluZyB0byAmcXVv dDtpbmR1c3RyeSBiZXN0PGJyPg0KJmd0OyBwcmFjdGljZXMmcXVvdDsuIFRoaXMgZG9lc24ndCBz ZWVtIHRvIGJlIGEgcmVxdWlyZW1lbnQgd2hpY2ggSSBjYW4gdmVyaWZ5IG9yPGJyPg0KJmd0OyBl dmFsdWF0ZS4gSWYgJnF1b3Q7aW5kdXN0cnkgYmVzdCBwcmFjdGljZXMmcXVvdDsgd2VyZSB0byB1 c2UgcmF3IFRDUCwgd291bGQgc3VjaCBhbjxicj4NCiZndDsgaW1wbGVtZW50YXRpb24gYmUgY29u Zm9ybWFudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB3aGF0IG5lZWRzIHRvIGJlIHJl cXVpcmVkIGhlcmUgaXMgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiBvZiBib3RoPGJyPg0K Jmd0OyBzaWRlcyBhbmQgb2YgdGhlIG1lc3NhZ2VzIG9uIGJvdGggY2hhbm5lbHMuIDxicj4NCjxi cj4NClllcywgYm90aCB0aGUgcHJvdG9jb2xzIHVzaW5nIChEKVRMUyB0byBtdXR1YWxseSBhdXRo ZW50aWNhdGUgYm90aCBzaWRlcyBhbmQgdGhlIG1lc3NhZ2VzIG9uIGJvdGggY2hhbm5lbHMgYXJl IGVuY3J5cHRlZC48YnI+DQo8YnI+DQomZ3Q7IEdlbmVyYWxseSBJIHdvdWxkIHByZWZlciB0byBy ZXF1aXJlPGJyPg0KJmd0OyBjb25maWRlbnRpYWxpdHkgb24gYm90aCwgYnV0IEkgY291bGQgbWF5 YmUgc2VlIGFuIGFyZ3VtZW50IGZvciB3aHkgdGhhdCB3YXNuJ3Q8YnI+DQomZ3Q7IG5lZWRlZC48 YnI+DQo8YnI+DQpSZW1vdmVkIERBVEEtMDAyIGFuZCB1cGRhdGVkIHNlY3VyaXR5IHJlcXVpcmVt ZW50cyB0byBkaXNjdXNzIGNvbmZpZGVudGlhbGl0eSBmb3IgYm90aCBET1RTIHByb3RvY29scy48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7U0VDLTAwMyZuYnNwOyBEYXRhIHByaXZhY3kgYW5kIGlu dGVncml0eTogVHJhbnNtaXNzaW9ucyBvdmVyIHRoZSBET1RTPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgcHJvdG9jb2xzIGFyZSBsaWtlbHkgdG8gY29udGFpbiBvcGVyYXRpb25hbGx5IG9yIHBy aXZhY3ktc2Vuc2l0aXZlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5mb3JtYXRpb24gb3Ig aW5zdHJ1Y3Rpb25zIGZyb20gdGhlIHJlbW90ZSBET1RTIGFnZW50LiZuYnNwOyBUaGVmdCw8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBtb2RpZmljYXRpb24sIG9yIHJlcGxheSBvZiBtZXNzYWdl IHRyYW5zbWlzc2lvbnMgY291bGQgbGVhZCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlu Zm9ybWF0aW9uIGxlYWtzIG9yIG1hbGljaW91cyB0cmFuc2FjdGlvbnMgb24gYmVoYWxmIG9mIHRo ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHNlbmRpbmcgYWdlbnQgKHNlZSBTZWN0aW9uIDQg YmVsb3cpLiZuYnNwOyBDb25zZXF1ZW50bHkgZGF0YSBzZW50IG92ZXI8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyB0aGUgRE9UUyBwcm90b2NvbHMgTVVTVCBiZSBlbmNyeXB0ZWQgdXNpbmcgc2Vj dXJlIHRyYW5zcG9ydHMgPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgKGxpa2UgVExTIGFuZCBE VExTKS4mbmJzcDsgRE9UUyBzZXJ2ZXJzIE1VU1QgZW5hYmxlIG1lYW5zIHRvIHByZXZlbnQgbGVh a2luZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG9wZXJhdGlvbmFsbHkgb3IgcHJpdmFjeS1z ZW5zaXRpdmUgZGF0YS4mbmJzcDsgQWx0aG91Z2ggYWRtaW5pc3RyYXRpdmU8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBlbnRpdGllcyBwYXJ0aWNpcGF0aW5nIGluIERPVFMgbWF5IGRldGFpbCB3 aGF0IGRhdGEgbWF5IGJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmV2ZWFsZWQgdG8gdGhp cmQtcGFydHkgRE9UUyBhZ2VudHMsIHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG5vdDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IGluIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBs b29rcyBnb29kLiBOb3RlIHRoYXQgaWYgeW91IGFyZSB1c2luZyBEVExTLCB5b3UgbWF5IG5lZWQg dG8gb3B0LWluIHRvIHRoZSBhbnRpLXJlcGxheSBzZXJ2aWNlLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXMgaXQgaXMgb3B0aW9uYWwuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlllcywgRFRMUyBhbnRpLXJlcGxheSBpcyBhIG1hbmRhdG9yeSBw cm9maWxlIGZvciB0aGUgRE9UUyBhZ2VudHMgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0yOCNzZWN0aW9uLTcu MSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1j aGFubmVsLTI4I3NlY3Rpb24tNy4xPC9hPikuIDxvOnA+DQo8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgPGJyPg0KJmd0OyBE RVRBSUw8YnI+DQomZ3Q7IFMgMi4yLjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtmcmVlIHRvIGF0dGVtcHQgYWJicmV2aWF0ZWQgc2VjdXJpdHkgbmVnb3Rp YXRpb24gbWV0aG9kcyBzdXBwb3J0ZWQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YnkgdGhlIHByb3RvY29sLCBzdWNoIGFzIERUTFMgc2Vzc2lvbiByZXN1 bXB0aW9uLCBidXQgTVVTVCBiZTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtwcmVwYXJlZCB0byBuZWdvdGlhdGUgbmV3IHNlY3VyaXR5IHN0YXRlIHdpdGgg dGhlIHJlZGlyZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3RhcmdldCBET1RTIHNlcnZlci4mbmJzcDsgVGhlIGF1dGhlbnRpY2F0aW9uIGRvbWFp biBvZiB0aGUgcmVkaXJlY3Rpb248YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dGFyZ2V0IERPVFMgc2VydmVyIE1VU1QgYmUgdGhlIHNhbWUgYXMgdGhlIGF1 dGhlbnRpY2F0aW9uIGRvbWFpbjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtvZiB0aGUgcmVkaXJlY3RpbmcgRE9UUyBzZXJ2ZXIuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IHdoYXQgaXMgYW4gJnF1b3Q7YXV0aGVudGljYXRpb24gZG9tYWluJnF1b3Q7Pzxicj4N Cjxicj4NCldlIGFyZSB0cnlpbmcgdG8gc2F5IGJvdGggdGhlIHJlZGlyZWN0aW5nIGFuZCByZWRp cmVjdGVkIHRhcmdldCBET1RTIHNlcnZlciBiZWxvbmcgdG8gdGhlIHNhbWUgYWRtaW5pc3RyYXRp dmUgZG9tYWluLjxicj4NCjxicj4NCk1vZGlmaWVkIHRoZSBsYXN0IGxpbmUgYXMgZm9sbG93czo8 YnI+DQpUaGUgcmVkaXJlY3Rpb24gRE9UUyBzZXJ2ZXIgYW5kIHJlZGlyZWN0aW5nIERPVFMgc2Vy dmVyIE1VU1QgYmVsb25nIHRvIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGRvbWFpbi48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhv dyBkbyBJIGludGVycHJldCB0aGlzIGFzIHRoZSByZWRpcmVjdGVkIHBhcnR5PyBEb2VzIGl0IGhh dmUgdG8gYmUgdGhlIHNhbWUgaWRlbnRpdHkgaW4gdGhlIGNlcnRpZmljYXRlPyBTb21ldGhpbmcg ZWxzZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJlZGlyZWN0 ZWQgKG9yIGFsdGVybmF0ZSkgRE9UUyBzZXJ2ZXLigJlzIEZRRE4gd2lsbCBiZSBjb252ZXllZCBi eSB0aGUgcmVkaXJlY3RpbmcgRE9UUyBzZXJ2ZXIsIGFuZCBET1RTIGNsaWVudCB1c2VzIHRoZSBz YW1lIGV4cGxpY2l0IHRydXN0IHN0b3JlIHRvIHZhbGlkYXRlDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmJvdGggdGhlIHNlcnZlcnMgY2VydGlmaWNhdGVzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQomZ3Q7IFMgMi40Ljxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFNFQy0wMDIm bmJzcDsgTWVzc2FnZSBDb25maWRlbnRpYWxpdHksIEludGVncml0eSBhbmQgQXV0aGVudGljaXR5 OiBET1RTPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3By b3RvY29scyBNVVNUIHRha2Ugc3RlcHMgdG8gcHJvdGVjdCB0aGUgY29uZmlkZW50aWFsaXR5LDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbnRlZ3JpdHkg YW5kIGF1dGhlbnRpY2l0eSBvZiBtZXNzYWdlcyBzZW50IGJldHdlZW4gY2xpZW50IGFuZDxicj4N CiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZXJ2ZXIuJm5ic3A7 IFdoaWxlIHNwZWNpZmljIHRyYW5zcG9ydC0gYW5kIG1lc3NhZ2UtbGV2ZWwgc2VjdXJpdHk8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3B0aW9ucyBhcmUg bm90IHNwZWNpZmllZCwgdGhlIHByb3RvY29scyBNVVNUIGZvbGxvdyBjdXJyZW50PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZHVzdHJ5IGJlc3QgcHJh Y3RpY2VzIGZvciBlbmNyeXB0aW9uIGFuZCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaGlzIGlzIG5vdCBhIHZlcmlmaWFibGUgY29uZm9ybWFuY2UgcmVxdWly ZW1lbnQ8YnI+DQo8YnI+DQpXaGVuIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgaXMgaW5pdGlhbGx5 IGRyYWZ0ZWQsIHRoZSBXRyB3YW50ZWQgdG8gc2VsZWN0IHRoZSBjdXJyZW50IElFVEYgYmVzdCBw cmFjdGljZXMgZm9yIGVuY3J5cHRpb24gYW5kIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gb2YgRE9U UyBtZXNzYWdlcy4mbmJzcDsgVGhlIERPVFMgV0cgaGFzIGRlY2lkZWQgdG8gdXNlIChEKVRMUyBm b3Igc2lnbmFsIGNoYW5uZWwgYW5kIFRMUyZuYnNwOyBmb3IgZGF0YSBjaGFubmVsLiZuYnNwOyBJ IGNhbg0KIG1vZGlmeSB0aGUgdGV4dCB0byBzYXkgJnF1b3Q7Y3VycmVudCBJRVRGIGJlc3QgcHJh Y3RpY2VzIGZvciBlbmNyeXB0aW9uIGFuZCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uJnF1b3Q7IGZv ciBib3RoIFNFQy0wMDEgYW5kIFNFQy0wMDIuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBpdCAncyAoRClUTFMsIHRoZW4gSSB0 aGluayB5b3Ugd2FudCB0byBjaXRlIFJGQyA3NTI1IGhlcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U3VyZSwgd2lsbCBjaXRlIFJGQzc1MjUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsgQ09NTUVOVDo8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQom Z3Q7IDxicj4NCiZndDsgUyAyLjEuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3Byb3ByaWV0YXJ5IEREb1MgZGVmZW5zZXMuJm5ic3A7IEZ1dHVyZSBleHRl bnNpb25zIE1VU1QgYmUgYmFja3dhcmQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Y29tcGF0aWJsZS4mbmJzcDsgSW1wbGVtZW50YXRpb25zIG9mIG9sZGVy IHByb3RvY29sIHZlcnNpb25zIE1VU1Q8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7aWdub3JlIG9wdGlvbmFsIGluZm9ybWF0aW9uIGFkZGVkIHRvIERPVFMg bWVzc2FnZXMgYXMgcGFydCBvZjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtuZXdlciBwcm90b2NvbCB2ZXJzaW9ucy4mbmJzcDsgSW1wbGVtZW50YXRpb25z IG9mIG9sZGVyIHByb3RvY29sPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3ZlcnNpb25zIE1VU1QgcmVqZWN0IG1hbmRhdG9yeSBpbmZvcm1hdGlvbiBhZGRl ZCB0byBET1RTIG1lc3NhZ2VzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2FzIHBhcnQgb2YgbmV3ZXIgcHJvdG9jb2wgdmVyc2lvbnMuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IE1VU1QgcmVqZWN0IHRoZSBpbmZvcm1hdGlvbiBvciBNVVNUIHJlamVjdCB0aGUg bWVzc2FnZXMuPGJyPg0KJmd0OyBDb252ZW50aW9uYWxseSwgaXQncyB0aGUgbGF0dGVyLjxicj4N Cjxicj4NClllcywgbW9kaWZpZWQgdGhlIGxpbmUgYXMgZm9sbG93czo8YnI+DQpJbXBsZW1lbnRh dGlvbnMgb2Ygb2xkZXIgcHJvdG9jb2wgdmVyc2lvbnMgTVVTVCByZWplY3QgRE9UUyBtZXNzYWdl cyBjYXJyeWluZyBtYW5kYXRvcnkgaW5mb3JtYXRpb24gYXMgcGFydCBvZiBuZXdlciBwcm90b2Nv bCB2ZXJzaW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyBTIDIuMi48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZGlzY3Vzc2VkIGluIFtJLUQuaWV0Zi1pbnRhcmVhLWZyYWctZnJhZ2lsZV0uJm5ic3A7IElm IHRoZSBQTVRVIGNhbm5vdDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtiZSBkaXNjb3ZlcmVkLCBET1RTIGFnZW50cyBNVVNUIGFzc3VtZSBhIFBNVFUgb2Yg MTI4MCBieXRlcyBmb3I8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7SVB2Ni4mbmJzcDsgSWYgSVB2NCBzdXBwb3J0IG9uIGxlZ2FjeSBvciBvdGhlcndpc2Ug dW51c3VhbCBuZXR3b3JrcyBpczxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDthIGNvbnNpZGVyYXRpb24gYW5kIHRoZSBQTVRVIGlzIHVua25vd24sIERPVFMg aW1wbGVtZW50YXRpb25zIE1BWTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtyZWx5IG9uIGEgUE1UVSBvZiA1NzYgYnl0ZXMgZm9yIElQdjQgZGF0YWdyYW1z LCBhcyBkaXNjdXNzZWQgaW48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7W1JGQzA3OTFdIGFuZCBbUkZDMTEyMl0uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkn bSBoYXZpbmcgdHJvdWJsZSByZWFkaW5nIHRoaXMgdGV4dC4gWW91IHNheSBhYm92ZSAmcXVvdDtN VVNUIGFzc3VtZSZxdW90OyBhbmQgJnF1b3Q7TUFZPGJyPg0KJmd0OyByZWx5JnF1b3Q7IGhlcmUu IEFyZSB5b3Ugc2F5aW5nICZxdW90O3NlbmQgbm8gbW9yZSB0aGFuIDU3NiZxdW90OyBvciAmcXVv dDt5b3UgY2FuIGFzc3VtZSB5b3UgY2FuPGJyPg0KJmd0OyBzZW5kIGF0IGxlYXN0IDU3NiBhbmQg d2UncmUgbm90IHNheWluZyBhbnl0aGluZyBhYm91dCB0aGUgdXBwZXIgYm91bmQmcXVvdDs8YnI+ DQo8YnI+DQpJIGhhdmUgcmVwbGFjZWQgdGhlIGFib3ZlIGxpbmVzIHdpdGggdGhlIHRleHQgc3Vn Z2VzdGVkIGJ5IFN1cmVzaC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyBTIDIuMi48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7YWN0aXZlIERPVFMgY2xpZW50IGhhcyBub3QgcmVxdWVzdGVkIG1pdGlnYXRpb24sIGluIG9y ZGVyIHRvPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nv bnRyb2wgbG9hZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Rm9sbG93aW5nIG11dHVhbCBhdXRoZW50aWNhdGlvbiwgYSBzaWdu YWwgY2hhbm5lbCBNVVNUIGJlPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2NvbnNpZGVyZWQgYWN0aXZlIHVudGlsIGEgRE9UUyBhZ2VudCBleHBsaWNpdGx5 IGVuZHMgdGhlIHNlc3Npb24uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0R1cmluZyBwZWFjZSB0aW1lLCBzaWduYWwgY2hhbm5lbCBNVVNUIGJlIGNvbnNp ZGVyZWQgYWN0aXZlPGJyPg0KJmd0OyAmZ3Q7IHVudGlsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZx dW90O3BlYWNlIHRpbWUmcXVvdDsgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCB3b3JkIGhlcmUu IEFmdGVyIGFsbCwgbXkgY291bnRyeSBtaWdodDxicj4NCiZndDsgYmUgYXQgcGVhY2UgYnV0IHN0 aWxsIHN1YmplY3QgdG8gYSBEb1MgYXR0YWNrPGJyPg0KPGJyPg0KQWRkZWQgdGhlIGZvbGxvd2lu ZyB0ZXJtIHRvIGF2b2lkIGNvbmZ1c2lvbiA6PGJyPg0KUGVhY2V0aW1lOiBJbiBERG9TLCDigJhw ZWFjZXRpbWXigJkgcmVmZXJzIHRvIHRoZSBwZXJpb2QgZHVyaW5nIHdoaWNoIHRoZSB0YXJnZXQg bmV0d29yayBpcyBub3QgdW5kZXIgRERvUyBhdHRhY2suPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgbXVzdCwgYnV0IEkg dGhpbmsgdGhpcyBpcyBtaWdodCBiZSBjb25zaWRlcmVkIGEgbGl0dGxlIGluIGJhZCB0YXN0ZSBi eSBwZW9wbGUgd2hvIGFyZSBpbnZvbHZlZCBpbiBhY3R1YWwgd2Fycy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T2theSwgcmVtb3ZlZCB0aGUgd29yZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LVRpcnU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkNoZWVycyw8YnI+DQotVGlydTxicj4N Cjxicj4NCiZndDsgPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR16MB27948B94FCBF0A460F90A9C7EA7F0DM6PR16MB2794namp_-- From nobody Fri Feb 22 08:20:34 2019 Return-Path: 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 7A95F130EA5; Fri, 22 Feb 2019 08:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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] 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 ndZkUORT3jr1; Fri, 22 Feb 2019 08:20:31 -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 55096130DEC; Fri, 22 Feb 2019 08:20:31 -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=1550852302; h=From: To: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-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=dxXJymW41ovo0c/0guUgdC4vnlEMCZwnuv7l7S sMXTw=; b=PUMCHj7XtcUkvqykPv2GGWqKRXWMZjuj+zLE9G9X 1rSi+iff38awfobfIBZx1k4oXZ3AGQvjlexhCJTxgUcZJA6aue CL+Zyc8vS9BdyRSh5ZLPXTYtG+svpWM9CiGVSIZGnRyBkBTARc UoxfUnxNNGoIGcOcUacFZeyGdMuSYaI= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2094_b5bd_29e8766a_e459_4147_a7ed_65882a491388; Fri, 22 Feb 2019 09:18:21 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 09:20:27 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 22 Feb 2019 09:20:27 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 09:20:26 -0700 Received: from DM6PR16MB2794.namprd16.prod.outlook.com (20.178.225.219) by DM6PR16MB2473.namprd16.prod.outlook.com (20.177.217.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Fri, 22 Feb 2019 16:20:26 +0000 Received: from DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::d8d0:f6b5:5c38:87b6]) by DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::d8d0:f6b5:5c38:87b6%2]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 16:20:26 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt Thread-Index: AQHUysO2BSyTdnM0Qka7k+Ykw8xjSaXr/0pg Date: Fri, 22 Feb 2019 16:20:26 +0000 Message-ID: References: <155084937056.5323.18401033305053602209@ietfa.amsl.com> In-Reply-To: <155084937056.5323.18401033305053602209@ietfa.amsl.com> 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: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3b2a2c8e-669b-45e4-96f0-08d698e1a786 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR16MB2473; x-ms-traffictypediagnostic: DM6PR16MB2473: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; DM6PR16MB2473; 23:OybgKva6K/kDj9HsVeL2x1pq4BrJL6avhpmmP0oK/?= =?us-ascii?Q?WM3DSX5J473FKG4vN9ySmNi9WE9kxFU6vexjoTSyx27g6EHfqVAE46dsf/BF?= =?us-ascii?Q?kg+4vESghEFrpo1Cbv0Jk+Hc7PXSmthVtvxMsApCE3RGr/JJX1QpTAC4vIvg?= =?us-ascii?Q?xs2PaHhsPPjlLJrG1RzUnkhTmpSItQJ4f8iPEURu28TgKDnAQ9ddBO39BhY6?= =?us-ascii?Q?v9dWglBzuvVblTiYmgmXkWwkgpwJjkugfRvyH1n6lfhglCabFIIavcEYlAmP?= =?us-ascii?Q?20nqvxF9uK3cEOnsVy9aJg/NoqUQkLncNqrNNj21OQ2ZFQFBkco9BUEOectD?= =?us-ascii?Q?FvzoPJntCq17jNr31kCHc73uV+S/5oH2kyVpMLlr45C1ce72qESqJjlgepSN?= =?us-ascii?Q?NaCl0AkBAm4Dd6AeE45ypjkBgeyG2040X5unGprhoIPCBRXMjIX0Nkx7nzBh?= =?us-ascii?Q?ZvFh1O8JjA2xp5WJWVk9m0arzlZex2MaXn4sXNJogxmPNZz9l2o/3/3pBUN/?= =?us-ascii?Q?oKg7J8hSTjAdU6mpITW2pmwY6wQkeMP8rEvQB0tlB6ChO3zVHPg85Y25KEzX?= =?us-ascii?Q?DF9WKEECHnPDu/pWWggMBSDoqk8/9dpYM2txc6ZU6iwckN4lmXaDnoaJSm5d?= =?us-ascii?Q?d2OFfKXS/gXpZMf4+myjbSUdRdCpQy76xNPBZ0gonS3ml1aU/nnDXVAWiMUa?= =?us-ascii?Q?0SQkZbETgRVy7SIJ0dMsOTJdNHq0Ce2WGtI6LAw/27vi7FxUgNFFKJdkNbn7?= =?us-ascii?Q?l+nL24fXtTMnPX8UK3OUbOt7BiyaeI+qd3/gJNlK107TYvGNjJgAhf1oDZmC?= =?us-ascii?Q?f78MgGqKsfoZHG075ReeJh16RfSYcSpi9WNfpjWZUkFw16Qx4nY/EUu5p0IW?= =?us-ascii?Q?XOrO8mdyPZMVnEl6r49wKW1ofAlmJEVAHyMXJyLMDsjsU/vh08/DYJYept6+?= =?us-ascii?Q?dzIQvb9zDFgdtiNCE+CT/YYTf6ybFCuIqTMGY+VINyAqPdaER05TzACX3VEc?= =?us-ascii?Q?n7TZ5VzwlPMysw3u75MVSqZs+5D7hLIgEtvZ6h0LNQbZr5UoeLBXu964eyW6?= =?us-ascii?Q?9qxNdd5e2Y/9ShwaEIOJ10LXTzTVo9QemYC4aiu+WXT5LWMHcMwHcCKzp26O?= =?us-ascii?Q?w0vo1B+ThcblTPZ3FGmHpWk0VChcPW9b7EsTDdcvsbJrgYHpUx8W3gnlHxNT?= =?us-ascii?Q?jrosNg9R5/o1MrJgQTJbNIHPrRmjpGN5OEzUZnBwTIxuzKV1pDgrVm5mUUVF?= =?us-ascii?Q?KI5nLlASjaFSkEx7A8BE20Ukre6RaujRjDPoxQKIv+e7yQHAZ1OoW/d6G9nE?= =?us-ascii?Q?nvHTkctbeoXKfu17+5DHmK1peJ3P1G+7AVhL7rqb4b4c/vtyjaDJYoh0M5uD?= =?us-ascii?Q?2XPj85VG2yuKYwkN4Z9NX4YrGPy+KYyZZ4nsZoesyWNZt2QeLNc1xDILagtG?= =?us-ascii?Q?Zm76Cgddg=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(366004)(39860400002)(376002)(13464003)(199004)(189003)(32952001)(72206003)(76176011)(966005)(66574012)(316002)(6506007)(14454004)(450100002)(102836004)(3846002)(66066001)(6436002)(6116002)(486006)(2906002)(53936002)(5660300002)(5024004)(256004)(99286004)(25786009)(106356001)(7696005)(110136005)(14444005)(11346002)(68736007)(8936002)(8676002)(6306002)(446003)(81166006)(81156014)(55016002)(71200400001)(71190400001)(9686003)(33656002)(7736002)(478600001)(26005)(6246003)(105586002)(97736004)(80792005)(305945005)(86362001)(74316002)(53546011)(186003)(2501003)(476003)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR16MB2473; 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: xeGTaBA/uds9Rpt2t16609G6h2I9jfUU6wJk0j+qyftdgsB+pQJWTkqTm9+wAZdDNIk+gPRy8pl8rIQuByTE0jTGz0IlsGub9gDVz7L4Vcp0lQ1sCHG3bbU79PWvSg0s5yFRLHox2dItpFolTMRU/kxngvgPkn5WeEyB2Gyq5qX0/KUcnmOjlDT3EEj8SOnypQ0Kwsny6DmNfjsvC/9K05OP9XxzmzcUs1kA0ZTFDvJSBMDjQU4xS6e4gIxgq0XIvL//JNXQlNID6VicrS9C0gqmpmXPO0ZMsuaoVmy6vy8vGTPfqI9Zq4O1fp5Bu8u+Y9zg2tB8JRIV3LXyAWgz9Bpa7UwxtZjgYqvva04JiRb/d13W2IoHbCQxtru1//COLTLiJTgwQgoG2VgZNMMrrb7lboiBmFmFeBsTlYzY9cg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3b2a2c8e-669b-45e4-96f0-08d698e1a786 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 16:20:26.4282 (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: DM6PR16MB2473 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6489> : inlines <7020> : streams <1813789> : uri <2800583> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 16:20:34 -0000 Hi Med, Couple of Nits: 1) OLD: Likewise, 'sid' value is=09 monotonically increased by the DOTS client for each configuration=09 session, attackers replaying configuration requests with lower=09 numeric 'sid' values will be rejected by the DOTS server if it=09 maintains a higher numeric 'sid' value for this DOTS client. NEW: Likewise, 'sid' value is=09 monotonically increased by the DOTS client for each configuration=09 request, attackers replaying configuration requests with lower=09 numeric 'sid' values will be rejected by the DOTS server if it=09 maintains a higher numeric 'sid' value for this DOTS client. 2) Define 'idle' time (i.e. when no attack traffic is present). -Tiru > -----Original Message----- > From: Dots On Behalf Of internet-drafts@ietf.org > Sent: Friday, February 22, 2019 9:00 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is = safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Signal Channel Specification > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-29.txt > Pages : 99 > Date : 2019-02-22 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration > purposes. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements within the document with the RFC > number to be assigned to this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification"; >=20 > o "| [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > Please update this statement with the RFC number to be assigned to > the following documents: >=20 > o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data- > channel) >=20 > Please update TBD/TBD1/TBD2 statements with the assignments made by > IANA to DOTS Signal Channel Protocol. >=20 > Also, please update the "revision" date of the YANG modules. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-29 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-29 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-29 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Feb 22 08:45:57 2019 Return-Path: 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 55D96130F18 for ; Fri, 22 Feb 2019 08:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 h2uBHZQSmeMb for ; Fri, 22 Feb 2019 08:45:44 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2479130FA0 for ; Fri, 22 Feb 2019 08:45:39 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id g12so2173300lfb.13 for ; Fri, 22 Feb 2019 08:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UedpWwMSZs8R3IBG98POE5b5cXLAwzCcDUN8JFncDEE=; b=hwAQUeVDK8sfOy3P+wRsZYNk00TnWaLmtol1Ynov8/4v8GTfpRn5u6paBpNuSnrN84 nyhZ9E8usAqJCLL14Zp0DOnAMEPkVz3LzLWcfQyk/LQZPtl0rHbde9gC2PXDEZW/i7ux x3exW8At4mynZDVoucRW97WLUeRs1Mc4Ew0GbNFsHdBWzDs02AHFIheg36OWkUryZSFB E6ZtiTg9Dbi4efOYC86i/QrcQabJi6qzwOJf2tYOc2Y3qm6Equ0R2csW4E8P+3ARtBkO c/Lc9KQL+SO+rXUGDucExt2PWF8XHLKLufnBkTEQ609TqXGmv2thbw2FJaw5gbPyA0Ic ZEsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UedpWwMSZs8R3IBG98POE5b5cXLAwzCcDUN8JFncDEE=; b=UGYWuq1ORE4nB4qgt2JA/+wseliOX9o7sYXFg6UMNnJPpNdKEUE5Gbr6elmkugHgso Ek5m/xc3u/e5nVjcYT4L6Ix7J71u683gjFf8IQCUkjdV/CBsBWQ6cBbF3GHyHGNd3NnM fJ2b/nzGi/FcYIig9lqNzh2dcXSgZiYyqB4IMToL8Q2d79JOyMfVm/+roZwm73h7Z5vn rqQkmLLnMyQgSGPBNsjc84xRTFM7rM+pquAsKQ2uZApIkMcjB3l6KzkP2lMZ60rVnw4b dCy+iGA79RiPlG1NqLq7NQymkz1aDmb0rjwxpY3xF0qSGlG65eNty4eHdGhOnTLER80g PH6Q== X-Gm-Message-State: AHQUAubJOEvFdy8tyti7TjqkbuPR3EIMIJLAA1RVc6we7a54/sHqjAmf tmjdioJxjFAFs4AnXFNU2RyF00o5NeZgzmmf8pnJog== X-Google-Smtp-Source: AHgI3IZPqFC28cc7/PQqtJmTHqSh4BWEYE3eN71/jtz8eZhwVdSdEtwpN2N32UXF8vkdf6rvfnAOSyTqcAE7+LDrIKk= X-Received: by 2002:a19:2d44:: with SMTP id t4mr2913433lft.90.1550853937404; Fri, 22 Feb 2019 08:45:37 -0800 (PST) MIME-Version: 1.0 References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Fri, 22 Feb 2019 08:44:58 -0800 Message-ID: To: "Konda, Tirumaleswar Reddy" Cc: The IESG , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "draft-ietf-dots-requirements@ietf.org" , "dots@ietf.org" Content-Type: multipart/alternative; boundary="00000000000009c2c205827e5235" Archived-At: Subject: Re: [Dots] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 16:45:52 -0000 --00000000000009c2c205827e5235 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 8:06 AM Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@mcafee.com> wrote: > Please see inline > > > > *From:* Eric Rescorla > *Sent:* Friday, February 22, 2019 7:11 PM > *To:* Konda, Tirumaleswar Reddy > *Cc:* The IESG ; dots-chairs@ietf.org; > frank.xialiang@huawei.com; draft-ietf-dots-requirements@ietf.org; > dots@ietf.org > *Subject:* Re: Eric Rescorla's Discuss on > draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) > > > > *CAUTION*: External email. Do not click links or open attachments unless > you recognize the sender and know the content is safe. > ------------------------------ > > > > > > On Fri, Feb 22, 2019 at 3:41 AM Konda, Tirumaleswar Reddy < > TirumaleswarReddy_Konda@mcafee.com> wrote: > > Hi Eric, > > Please see inline > > > -----Original Message----- > > From: Eric Rescorla > > Sent: Thursday, February 21, 2019 8:33 PM > > To: The IESG > > Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; Liang Xia > > ; draft-ietf-dots-requirements@ietf.org; > > dots@ietf.org > > Subject: Eric Rescorla'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 i= s > safe. > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-dots-requirements-18: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3543 > > > > > > I only had a short time to read this, but I find myself confused about > the > > COMSEC requirements here. > > > > There is no COMSEC requirement for the signaling channel in S 2.2. > > DATA-002 requires a secure COMSEC protocol for the data channel. > > Both signal and data channel require confidentiality and have the same > data privacy and integrity requirements. > > > > Great. That seems appropriate. > > > > > > > > SEC-001 and SEC-002 require "peer mutual authentication" and "message > > confidentiality, integrity, and authentication" according to "industry > best > > practices". This doesn't seem to be a requirement which I can verify or > > evaluate. If "industry best practices" were to use raw TCP, would such = an > > implementation be conformant. > > > > I think what needs to be required here is cryptographic authentication > of both > > sides and of the messages on both channels. > > Yes, both the protocols using (D)TLS to mutually authenticate both sides > and the messages on both channels are encrypted. > > > Generally I would prefer to require > > confidentiality on both, but I could maybe see an argument for why that > wasn't > > needed. > > Removed DATA-002 and updated security requirements to discuss > confidentiality for both DOTS protocols. > > SEC-003 Data privacy and integrity: Transmissions over the DOTS > protocols are likely to contain operationally or privacy-sensitive > information or instructions from the remote DOTS agent. Theft, > modification, or replay of message transmissions could lead to > information leaks or malicious transactions on behalf of the > sending agent (see Section 4 below). Consequently data sent over > the DOTS protocols MUST be encrypted using secure transports > (like TLS and DTLS). DOTS servers MUST enable means to prevent > leaking > operationally or privacy-sensitive data. Although administrative > entities participating in DOTS may detail what data may be > revealed to third-party DOTS agents, such considerations are not > in scope for this document. > > > > This looks good. Note that if you are using DTLS, you may need to opt-in > to the anti-replay service, > > as it is optional. > > > > Yes, DTLS anti-replay is a mandatory profile for the DOTS agents (see > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-28#section-7.1= ). > > > > > > > > > DETAIL > > S 2.2. > > > free to attempt abbreviated security negotiation methods > supported > > > by the protocol, such as DTLS session resumption, but MUST be > > > prepared to negotiate new security state with the redirection > > > target DOTS server. The authentication domain of the > redirection > > > target DOTS server MUST be the same as the authentication > domain > > > of the redirecting DOTS server. > > > > what is an "authentication domain"? > > We are trying to say both the redirecting and redirected target DOTS > server belong to the same administrative domain. > > Modified the last line as follows: > The redirection DOTS server and redirecting DOTS server MUST belong to th= e > same administrative domain. > > > > How do I interpret this as the redirected party? Does it have to be the > same identity in the certificate? Something else? > > > > The redirected (or alternate) DOTS server=E2=80=99s FQDN will be conveyed= by the > redirecting DOTS server, and DOTS client uses the same explicit trust sto= re > to validate > > both the servers certificates. > OK, so the client has no way of knowing if these are actually the same admin domain, it's just an operational requirement? -Ekr > > > > S 2.4. > > > SEC-002 Message Confidentiality, Integrity and Authenticity: DO= TS > > > protocols MUST take steps to protect the confidentiality, > > > integrity and authenticity of messages sent between client an= d > > > server. While specific transport- and message-level security > > > options are not specified, the protocols MUST follow current > > > industry best practices for encryption and message > authentication. > > > > This is not a verifiable conformance requirement > > When the requirements draft is initially drafted, the WG wanted to select > the current IETF best practices for encryption and message authentication > of DOTS messages. The DOTS WG has decided to use (D)TLS for signal chann= el > and TLS for data channel. I can modify the text to say "current IETF be= st > practices for encryption and message authentication" for both SEC-001 and > SEC-002. > > > > If it 's (D)TLS, then I think you want to cite RFC 7525 here > > > > Sure, will cite RFC7525. > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 2.1. > > > proprietary DDoS defenses. Future extensions MUST be backwar= d > > > compatible. Implementations of older protocol versions MUST > > > ignore optional information added to DOTS messages as part of > > > newer protocol versions. Implementations of older protocol > > > versions MUST reject mandatory information added to DOTS > messages > > > as part of newer protocol versions. > > > > MUST reject the information or MUST reject the messages. > > Conventionally, it's the latter. > > Yes, modified the line as follows: > Implementations of older protocol versions MUST reject DOTS messages > carrying mandatory information as part of newer protocol versions. > > > > Thanks. > > > > > > > > > > > > S 2.2. > > > discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU > cannot > > > be discovered, DOTS agents MUST assume a PMTU of 1280 bytes f= or > > > IPv6. If IPv4 support on legacy or otherwise unusual network= s > is > > > a consideration and the PMTU is unknown, DOTS implementations > MAY > > > rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed = in > > > [RFC0791] and [RFC1122]. > > > > I'm having trouble reading this text. You say above "MUST assume" and > "MAY > > rely" here. Are you saying "send no more than 576" or "you can assume > you can > > send at least 576 and we're not saying anything about the upper bound" > > I have replaced the above lines with the text suggested by Suresh. > > > > OK. > > > > > > > > > > S 2.2. > > > active DOTS client has not requested mitigation, in order to > > > control load. > > > > > > Following mutual authentication, a signal channel MUST be > > > considered active until a DOTS agent explicitly ends the > session. > > > During peace time, signal channel MUST be considered active > > > until > > > > "peace time" is probably not the right word here. After all, my country > might > > be at peace but still subject to a DoS attack > > Added the following term to avoid confusion : > Peacetime: In DDoS, =E2=80=98peacetime=E2=80=99 refers to the period duri= ng which the > target network is not under DDoS attack. > > > > If you must, but I think this is might be considered a little in bad tast= e > by people who are involved in actual wars. > > > > Okay, removed the word. > > > > Cheers, > > -Tiru > > > > -Ekr > > > > > Cheers, > -Tiru > > > > > --00000000000009c2c205827e5235 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 8:06 AM Konda= , Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.com> wrote:

Please see inline

=C2=A0

From: Eric Rescorla <ekr@rtfm.com>
Sent: Friday, February 22, 2019 7:11 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >
Cc: The IESG <= iesg@ietf.org>; dots-chairs@ietf.org; frank.xialiang@huawei.com; draft-ietf-dots-requirem= ents@ietf.org; dots@= ietf.org
Subject: Re: Eric Rescorla's Discuss on draft-ietf-dots-requirem= ents-18: (with DISCUSS and COMMENT)

=C2=A0

CAUTION: External email. Do not click links or op= en attachments unless you recognize the sender and know the content is safe.<= /span>

=C2=A0

=C2=A0

On Fri, Feb 22, 2019 at 3:41 AM Konda, Tirumaleswar = Reddy <TirumaleswarReddy_Konda@mcafee.com> wrote:

Hi Eric,

Please see inline

> -----Original Message-----
> From: Eric Rescorla <ekr@rtfm.com>
> Sent: Thursday, February 21, 2019 8:33 PM
> To: The IESG <ie= sg@ietf.org>
> Cc: dots-cha= irs@ietf.org; frank.xialia= ng@huawei.com; Liang Xia
> <fra= nk.xialiang@huawei.com>; = draft-ietf-dots-requirements@ietf.org;
> dots@ietf.org > Subject: Eric Rescorla's Discuss on draft-ietf-dots-requirements-1= 8: (with
> DISCUSS and COMMENT)
>
> This email originated from outside of the organization. Do not click l= inks or
> open attachments unless you recognize the sender and know the content = is safe.
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dots-requirements-18: Discuss
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3543
>
>
> I only had a short time to read this, but I find myself confused about= the
> COMSEC requirements here.
>
> There is no COMSEC requirement for the signaling channel in S 2.2.
> DATA-002 requires a secure COMSEC protocol for the data channel.

Both signal and data channel require confidentiality and have the same data= privacy and integrity requirements.

=C2=A0

Great. That seems appropriate.

=C2=A0

=C2=A0


> SEC-001 and SEC-002 require "peer mutual authentication" and= "message
> confidentiality, integrity, and authentication" according to &quo= t;industry best
> practices". This doesn't seem to be a requirement which I can= verify or
> evaluate. If "industry best practices" were to use raw TCP, = would such an
> implementation be conformant.
>
> I think what needs to be required here is cryptographic authentication= of both
> sides and of the messages on both channels.

Yes, both the protocols using (D)TLS to mutually authenticate both sides an= d the messages on both channels are encrypted.

> Generally I would prefer to require
> confidentiality on both, but I could maybe see an argument for why tha= t wasn't
> needed.

Removed DATA-002 and updated security requirements to discuss confidentiali= ty for both DOTS protocols.

=C2=A0 =C2=A0SEC-003=C2=A0 Data privacy and integrity: Transmissions over t= he DOTS
=C2=A0 =C2=A0 =C2=A0 protocols are likely to contain operationally or priva= cy-sensitive
=C2=A0 =C2=A0 =C2=A0 information or instructions from the remote DOTS agent= .=C2=A0 Theft,
=C2=A0 =C2=A0 =C2=A0 modification, or replay of message transmissions could= lead to
=C2=A0 =C2=A0 =C2=A0 information leaks or malicious transactions on behalf = of the
=C2=A0 =C2=A0 =C2=A0 sending agent (see Section 4 below).=C2=A0 Consequentl= y data sent over
=C2=A0 =C2=A0 =C2=A0 the DOTS protocols MUST be encrypted using secure tran= sports
=C2=A0 =C2=A0 =C2=A0 (like TLS and DTLS).=C2=A0 DOTS servers MUST enable me= ans to prevent leaking
=C2=A0 =C2=A0 =C2=A0 operationally or privacy-sensitive data.=C2=A0 Althoug= h administrative
=C2=A0 =C2=A0 =C2=A0 entities participating in DOTS may detail what data ma= y be
=C2=A0 =C2=A0 =C2=A0 revealed to third-party DOTS agents, such consideratio= ns are not
=C2=A0 =C2=A0 =C2=A0 in scope for this document.

=C2=A0

This looks good. Note that if you are using DTLS, yo= u may need to opt-in to the anti-replay service,

as it is optional.

=C2=A0

Yes, DTLS anti-replay is a mandatory profile for the= DOTS agents (see https://tools.ietf.org/html/draft-ietf-dots-signal-channel-28#section-7.1).

=C2=A0


>
> DETAIL
> S 2.2.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0free to attempt abbreviated secu= rity negotiation methods supported
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the protocol, such as DTLS se= ssion resumption, but MUST be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prepared to negotiate new securi= ty state with the redirection
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0target DOTS server.=C2=A0 The au= thentication domain of the redirection
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0target DOTS server MUST be the s= ame as the authentication domain
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the redirecting DOTS server.<= br> >
> what is an "authentication domain"?

We are trying to say both the redirecting and redirected target DOTS server= belong to the same administrative domain.

Modified the last line as follows:
The redirection DOTS server and redirecting DOTS server MUST belong to the = same administrative domain.

=C2=A0

How do I interpret this as the redirected party? Doe= s it have to be the same identity in the certificate? Something else?

=C2=A0

The redirected (or alternate) DOTS server=E2=80=99s = FQDN will be conveyed by the redirecting DOTS server, and DOTS client uses = the same explicit trust store to validate

both the servers certificates.

=


=C2=A0


> S 2.4.
> >=C2=A0 =C2=A0 =C2=A0 SEC-002=C2=A0 Message Confidentiality, Integr= ity and Authenticity: DOTS
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocols MUST take steps to pro= tect the confidentiality,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0integrity and authenticity of me= ssages sent between client and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server.=C2=A0 While specific tra= nsport- and message-level security
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0options are not specified, the p= rotocols MUST follow current
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0industry best practices for encr= yption and message authentication.
>
> This is not a verifiable conformance requirement

When the requirements draft is initially drafted, the WG wanted to select t= he current IETF best practices for encryption and message authentication of= DOTS messages.=C2=A0 The DOTS WG has decided to use (D)TLS for signal chan= nel and TLS=C2=A0 for data channel.=C2=A0 I can modify the text to say "current IETF best practices for encryption an= d message authentication" for both SEC-001 and SEC-002.<= /p>

=C2=A0

If it 's (D)TLS, then I think you want to cite R= FC 7525 here

=C2=A0

Sure, will cite RFC7525.

=C2=A0

> -----------------------------------------------= -----------------------
> COMMENT:
> ----------------------------------------------------------------------=
>
> S 2.1.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proprietary DDoS defenses.=C2=A0= Future extensions MUST be backward
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible.=C2=A0 Implementation= s of older protocol versions MUST
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ignore optional information adde= d to DOTS messages as part of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0newer protocol versions.=C2=A0 I= mplementations of older protocol
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0versions MUST reject mandatory i= nformation added to DOTS messages
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as part of newer protocol versio= ns.
>
> MUST reject the information or MUST reject the messages.
> Conventionally, it's the latter.

Yes, modified the line as follows:
Implementations of older protocol versions MUST reject DOTS messages carryi= ng mandatory information as part of newer protocol versions.<= /p>

=C2=A0

Thanks.

=C2=A0

=C2=A0


>
>
> S 2.2.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussed in [I-D.ietf-intarea-f= rag-fragile].=C2=A0 If the PMTU cannot
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be discovered, DOTS agents MUST = assume a PMTU of 1280 bytes for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6.=C2=A0 If IPv4 support on l= egacy or otherwise unusual networks is
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a consideration and the PMTU is = unknown, DOTS implementations MAY
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rely on a PMTU of 576 bytes for = IPv4 datagrams, as discussed in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC0791] and [RFC1122].
>
> I'm having trouble reading this text. You say above "MUST ass= ume" and "MAY
> rely" here. Are you saying "send no more than 576" or &= quot;you can assume you can
> send at least 576 and we're not saying anything about the upper bo= und"

I have replaced the above lines with the text suggested by Suresh.

=C2=A0

OK.

=C2=A0


>
>
> S 2.2.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0active DOTS client has not reque= sted mitigation, in order to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0control load.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Following mutual authentication,= a signal channel MUST be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0considered active until a DOTS a= gent explicitly ends the session.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0During peace time, signal channe= l MUST be considered active
> > until
>
> "peace time" is probably not the right word here. After all,= my country might
> be at peace but still subject to a DoS attack

Added the following term to avoid confusion :
Peacetime: In DDoS, =E2=80=98peacetime=E2=80=99 refers to the period during= which the target network is not under DDoS attack.

=C2=A0

If you must, but I think this is might be considered= a little in bad taste by people who are involved in actual wars.=

=C2=A0

Okay, removed the word.

=C2=A0

Cheers,

-Tiru

=C2=A0

-Ekr

=C2=A0


Cheers,
-Tiru

>

--00000000000009c2c205827e5235-- From nobody Fri Feb 22 14:19:17 2019 Return-Path: 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 93847130FB7; Fri, 22 Feb 2019 14:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 HqdhuxZYKJ0z; Fri, 22 Feb 2019 14:19:09 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820102.outbound.protection.outlook.com [40.107.82.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B0B130E7F; Fri, 22 Feb 2019 14:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wyINtex64m1Rti1o5hC4AxvhS07O3G9i5P34SnaTVqE=; b=LVwkWeY6LRWFMyIJobKT4CfHhRSkathqNF7xSrUxjUauxt/l6D36DXBrqoZ7V6X9vQwnJd9YK/BOqSX7rVeVi1IRou75kK2iOVI4rg++Qf7ixjnlpKIvljh9lWmp7bwW64GmZThIuojW6x683w9kV1jC2xLsJPPpt1ueluTfEeg= Received: from CY4PR01CA0018.prod.exchangelabs.com (2603:10b6:903:1f::28) by SN6PR01MB5182.prod.exchangelabs.com (2603:10b6:805:c1::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Fri, 22 Feb 2019 22:19:06 +0000 Received: from DM3NAM03FT013.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::206) by CY4PR01CA0018.outlook.office365.com (2603:10b6:903:1f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.15 via Frontend Transport; Fri, 22 Feb 2019 22:19:06 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT013.mail.protection.outlook.com (10.152.82.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Fri, 22 Feb 2019 22:19:05 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1MMJ1Wu030838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Feb 2019 17:19:03 -0500 Date: Fri, 22 Feb 2019 16:19:01 -0600 From: Benjamin Kaduk To: Eric Rescorla CC: "Konda, Tirumaleswar Reddy" , "dots-chairs@ietf.org" , "frank.xialiang@huawei.com" , "dots@ietf.org" , The IESG , "draft-ietf-dots-requirements@ietf.org" Message-ID: <20190222221900.GG69562@kduck.mit.edu> References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(136003)(39860400002)(376002)(346002)(396003)(2980300002)(13464003)(199004)(189003)(76176011)(356004)(106002)(58126008)(7696005)(23676004)(2486003)(36906005)(316002)(246002)(50466002)(54906003)(786003)(2870700001)(88552002)(93886005)(336012)(2906002)(426003)(186003)(86362001)(26005)(5660300002)(305945005)(53546011)(1076003)(8676002)(6916009)(4326008)(476003)(956004)(33656002)(8936002)(11346002)(446003)(229853002)(126002)(14444005)(486006)(47776003)(6246003)(55016002)(53416004)(75432002)(106466001)(104016004)(478600001)(26826003)(18370500001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB5182; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8795cb9f-35f7-43c3-be38-08d69913c240 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:SN6PR01MB5182; X-MS-TrafficTypeDiagnostic: SN6PR01MB5182: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB5182; 20:LmiDf+1wXMaiw/a0Z9THVtqLcjkewGtK9T9mkym6/TNDra1KaWZ7fvv2DZOmCfj90jppKH0OVYW3QJX66OI59aBwssXmYoiBaHermjqaj+GWfv+mhYVpKDfYw+MecgV5fpgt+mBEDh8TEYr0TFEBk26fIFXA9cQfmSLJjajj9YUPKo4jkTXZgndpgexuS1g4YdZJCWCDl82+fFCR9p5PRKsGfpnh3dxgS1hDjXUHqdH7gLxgB77EbLhjMAYZpeVP0TI65HWhwNZk0TOaoKJuGRaKdH3FigrxROxUJC2nTcmbrmEPvt9as8vOWHcXOz4hlJViMGWM5ak+mSNMqVLJAunNAEGcRqkII5aaL9uv3h5qI3jds1mCaJB+Uow2shJOSAJ48WGSDQ5fuEjk4NnXWQGT5BsNJDC2ZGPZPJIaXnsN1sKYBFlgFdUmfRp/qDysdal763lQBmD/oLG3056Fl0pWyivA9OAkoFWI8kHYS4h332eGTWZx99UGhvATNPHYmPQjqGN8R+8NyxupVDjBCwRTxJs7hq9OYV45gx+XkAY/VE1yQaoigKPR9WsgWp84rLIvWStPfrLS4m6htQ2OTYcN6BAPsNDhdrgOCeH/eRA= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09565527D6 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjZQUjAxTUI1MTgyOzIzOnBiNUdHbERJTURqM1JKei9STjJLbmljU2d6?= =?utf-8?B?NmNtNGVWbHE2OVZLZFJmd1ZxM1N0dTJ5elV6Vk1YUi9CSDJZV2dvTC9LNE1j?= =?utf-8?B?N29LUGwzcU5DWTNqeEs0ODYxNEVSVlg5V2VqS1I5UUZEVk81Vk9JcjByRVJk?= =?utf-8?B?N2hpa0ZtZWhaS0hhUnNTc0ZIQjd0ZmFTNFpyQm96RmZZRFN0UDlrM0V3Wm04?= =?utf-8?B?Y3FjL1orRVQ1YVJwZzlXRlA4UmxCWlJDVEFrdUxNd21pV3l5MldwZVJuQmV6?= =?utf-8?B?VGVTcjdxOExvdGZZT01OMXVacDJTVjBiMEZsZ2dONU9yNWNBaS9Tc0V3UXI4?= =?utf-8?B?dTNnWjNEaTNUTU1JcUtDYWJuNmpINlMrMktpKzduWXlKQzd5bU5vaGVZc1ZT?= =?utf-8?B?NXdtS3psNkJMU1lJSS85eTJhdmZmK2p3cUU2VTR6SGt3b3FBS0JRUENXcGxF?= =?utf-8?B?WHdVcjVqNXg3bWtpL0Z2M3BEQkhKUDhPUUVhZGFnNGd2Q0hkY1U5aGtqR2pa?= =?utf-8?B?R1VtZ2p2UHJRTU5pRGs5Z2l1dklwMnhCQVBYaFd4L0g4enl0OUdxUEZydXpq?= =?utf-8?B?RWNxYmVadHZJeGlJRFlHNDMxbUpxWm5ZOXVtT1BJNVJqS2Y0U0x5Ly93MUZB?= =?utf-8?B?T01XdlMvUzYrU2dna0I5aUtkNzhpZk01MXNHNDN3Ukp6NmRoL2JiNWxsRVdW?= =?utf-8?B?Qk5FcklNWjZsUG83ZjJ0eVVrUDlEVDRNRFQ1c0tkalRxNGZuZGdROGt0OENP?= =?utf-8?B?Q3A3aUJJSkF4MkhYeDEyOE5rU1hqdDB5cVI0U2NvbGV0RS9IMGU1cEcyWElU?= =?utf-8?B?SThHSGcwV3gzUDNUTCtPN3BSYmlLT3VrZkltTFU2YlptZURWZHJwR2x4Tkgv?= =?utf-8?B?Ry9OaXUram52SFNsUGdtWFdGYkJpSkZKMXcvVGlxcEtoVmFrbVdrKy9OaGxl?= =?utf-8?B?c2FIUzVLMlNHNFRpUHNWLzdVZzdMdkJ2L3pnNUtncEhpS2xESHZzQ0xhMEF6?= =?utf-8?B?bS9VYVJFaTN1Y0xYdGZjODRIZlZiSElNbVQzY2xQQVg5dnlZMngwbVpZSkw2?= =?utf-8?B?cUhKa0FOUTczQ3UyaGU0dC9ZcDdkOUpJVzN0UXpxaE81cG1FM2RkdVFSRWkr?= =?utf-8?B?WkVBMVVudVZWbFh5RnhsbmVXQjNpbUdqRW1ibXZ2clFTUlBaRExMdjFJeWFX?= =?utf-8?B?L1BsZ0FRYkFYQit6VFlqZFJXc2hJVnprZnZPSlpZVnQvN0dPUE9qYy9BRnQ4?= =?utf-8?B?TUtCOTJ2ZXArVWpaZmVuRjBUWWs1bVNibHp2MDArL29hc3E2Z29RZkV2eDFZ?= =?utf-8?B?dks2enBpeFczRzFDU2J5NjF1NWtYUW5NRS8vZkVHa0JMVG5SdngvcDZWRTRF?= =?utf-8?B?ZkxscVFNZlR2S2FINzIzazBlZ2toUDJUMVFXY0VyRzZ1Y0IzcWt1YThKcTlu?= =?utf-8?B?dkxMWTdLL0EzdWtjS2VzcDltTWl5N3QxNnE4NGxxMlRBajUyUEpxaEtNaDJJ?= =?utf-8?B?NFFuOHFCc0l2NHE5akNaZWN2d3VPK1BoZDZaMzl3am5xbEtyVEl0bkNHbmM4?= =?utf-8?B?ZFZ0bTR4Wi9GaWdHbDVGbXdERVpKYXdzSG5JTDVDS21GRkYvcEN4eU1acFlv?= =?utf-8?B?Y1dQL2lGenVrbVZPemJkSUxUN09kU04wbFIrazFiYmh1TmN2bnJ6NnBNdEVE?= =?utf-8?B?VS9KSjVZR0psU09uU3FvdlppOUg0RTM2YWxjYU5iU2svMUJzaXZuOWs3d0tZ?= =?utf-8?B?cElMalYvL1R0K01aYm9ONUQraFMyQVhkcHdJU3ZXWmNyd2kvb0Z1VEdWNkR3?= =?utf-8?B?bkJrK3cxMThkRGJBU3dETFFETUFROE01T2l3cisrdFJIUlE9PQ==?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: lz8jyG5NodCrH4xbmkiLheiT4cl2TYOL3FjRVKZd7yxx3kEaWgR7U59hdSQhBw7tlCZgJz+aMZUREvt+AUPjcOm+XCMI5W2vUHvqk6rqY56rEG3wbh/X11QXUE4dhJUdplh4ry+e9CcmrK7Gv3sr0xMPmLAuFAFiDklV5CjT2GoQfCp/s7/qPGEPTUFIrqlTc16p9uLOIpaY3h5jA/G58xwZwo1p7A23SJrpLcehGuQYEK0whlxe2aHg5JqF4GHzshMrUbXJIcXjqQLujpFhRsX5mVCI5kbBRK1mM1amQ2MbvJqBvgwfpCgnVoTzlmP4UX9pbJxu6Fmr/urQUDi39fQVEXWwqLCTPwn4Ll0bq6Glxba8YoukejtNfJO+Rpe1lTNMWnUeUmkBW5Kqz05NobOA2me41Tm1Zf4CHRsY6Cs= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2019 22:19:05.6541 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8795cb9f-35f7-43c3-be38-08d69913c240 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB5182 Archived-At: Subject: Re: [Dots] Eric Rescorla'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 22:19:16 -0000 On Fri, Feb 22, 2019 at 08:44:58AM -0800, Eric Rescorla wrote: > On Fri, Feb 22, 2019 at 8:06 AM Konda, Tirumaleswar Reddy < > TirumaleswarReddy_Konda@mcafee.com> wrote: > > > *From:* Eric Rescorla > > *Sent:* Friday, February 22, 2019 7:11 PM > > *To:* Konda, Tirumaleswar Reddy > > *Cc:* The IESG ; dots-chairs@ietf.org; > > frank.xialiang@huawei.com; draft-ietf-dots-requirements@ietf.org; > > dots@ietf.org > > *Subject:* Re: Eric Rescorla's Discuss on > > draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT) > > > > On Fri, Feb 22, 2019 at 3:41 AM Konda, Tirumaleswar Reddy < > > TirumaleswarReddy_Konda@mcafee.com> wrote: > > > > > -----Original Message----- > > > From: Eric Rescorla > > > Sent: Thursday, February 21, 2019 8:33 PM > > > To: The IESG > > > Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; Liang Xia > > > ; draft-ietf-dots-requirements@ietf.org; > > > dots@ietf.org > > > Subject: Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: > > (with > > > DISCUSS and COMMENT) > > > > > > > > > DETAIL > > > S 2.2. > > > > free to attempt abbreviated security negotiation methods > > supported > > > > by the protocol, such as DTLS session resumption, but MUST be > > > > prepared to negotiate new security state with the redirection > > > > target DOTS server. The authentication domain of the > > redirection > > > > target DOTS server MUST be the same as the authentication > > domain > > > > of the redirecting DOTS server. > > > > > > what is an "authentication domain"? > > > > We are trying to say both the redirecting and redirected target DOTS > > server belong to the same administrative domain. > > > > Modified the last line as follows: > > The redirection DOTS server and redirecting DOTS server MUST belong to the > > same administrative domain. > > > > > > > > How do I interpret this as the redirected party? Does it have to be the > > same identity in the certificate? Something else? > > > > > > > > The redirected (or alternate) DOTS server’s FQDN will be conveyed by the > > redirecting DOTS server, and DOTS client uses the same explicit trust store > > to validate > > > > both the servers certificates. > > > > OK, so the client has no way of knowing if these are actually the same > admin domain, it's just an operational requirement? (D)TLS mutual auth is used, so there is some information available as a proxy for "same admin domain", like "certificate issued by same private CA hierarchy" or similar. -Benjamin From nobody Sun Feb 24 20:55:04 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F79130F28; Sun, 24 Feb 2019 20:54:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <155107048754.10950.7646451304619656582@ietfa.amsl.com> Date: Sun, 24 Feb 2019 20:54:47 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 04:54:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Tirumaleswar Reddy Robert Moskowitz Filename : draft-ietf-dots-requirements-19.txt Pages : 22 Date : 2019-02-24 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-19 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 24 21:23:40 2019 Return-Path: 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 C2616130DD3 for ; Sun, 24 Feb 2019 21:23:38 -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 pQrFVTbq_ewH for ; Sun, 24 Feb 2019 21:23:37 -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 3C00D1200D8 for ; Sun, 24 Feb 2019 21:23:37 -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=1551072079; 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-ms-exchange-purlcount: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=y tZs4TbYQGnYmbtZRTevmmkPLdHLpgjYLurjAPcsVD E=; b=HOMJ1oP5zxh+jUoiT2lKmskvBdVpF6+FfyfeCWFmvpmT OL2CKe3kgQBlb0V3se4ShvyrDbLshg2+qYhp3EP+BP2CMF8MFh xAcovH0l5XtNWlBTZnHHUxhOS0+KJc/t9hCFWsbHH9QtW3FgUq 8oe7rwRAc4zuHdqYOAZX7z3tA4Q= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2555_2249_cba3824b_fd85_4801_9d34_6b4e4776091e; Sun, 24 Feb 2019 22:21:18 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 24 Feb 2019 22:23:33 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sun, 24 Feb 2019 22:23:33 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 24 Feb 2019 22:23:33 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2615.namprd16.prod.outlook.com (20.177.227.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Mon, 25 Feb 2019 05:23:32 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 05:23:32 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" CC: Eric Rescorla , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , Benjamin Kaduk , Ben Campbell , "Mirja Kuehlewind (IETF)" , Alvaro Retana Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt Thread-Index: AQHUzMaKd30Uc+GrIUyTZNhaRaMfHaXv+kdw Date: Mon, 25 Feb 2019 05:23:32 +0000 Message-ID: References: <155107048754.10950.7646451304619656582@ietfa.amsl.com> In-Reply-To: <155107048754.10950.7646451304619656582@ietfa.amsl.com> 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: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 549e6346-8132-443c-95dc-08d69ae16211 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2615; x-ms-traffictypediagnostic: BYAPR16MB2615: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR16MB2615; 23:pog+X51J9bp4kLkycXjZ0zTXM7nXh0hKlcdOKfn1W?= =?us-ascii?Q?Yq64XmpuAurmOFYnLZMElZtCpSyF7QxVyzkopslQCdtKeXnkjW5Dv5kPH5Sv?= =?us-ascii?Q?icvCcwExCGiGFbDnzB7/6sMwEDKUm+9jBOVhlQo7yLFECOiDQEtzALNOthM6?= =?us-ascii?Q?RVUGzrJlyXPC+W+AN2VmcdkpEyfECpPImIcKYxa2QmKYRN58sO/Xc92fDv0U?= =?us-ascii?Q?zsRo9hKPYACd3uYvQixv2TAE6DZdG5wzzb8PhY7Fleu47cXLSUNDqsb+ZNWU?= =?us-ascii?Q?g6zedZmE9Yi5PKHPZlU6mEQpURtpysr5gXMSIX18w8AFzOUalv4PFQmejEah?= =?us-ascii?Q?UP5I44ralHzelXIeseDjRPzE56+tWCitAMnED52ie8sy0HF4oxmmq57HRgwO?= =?us-ascii?Q?aSbM0MMXRl7JkX5x1pnJRZj0wFNbmFvkVvR6UTMvQifpwt1u5RSALkqT2CI/?= =?us-ascii?Q?fWBe63mn5bqSThzPggjLh/iJwbDX01G1IDXpJ5xIFVahLf6MdtBZCJr++wiv?= =?us-ascii?Q?vz8A7Lp/AwZp2yvO6PyARzV12BCet3nBCodyvO5I1NaA2Hc5oo30G+orU2FX?= =?us-ascii?Q?tTpB9MvY/Zn6lZ3RJ09GxU8alkCAKE7dChAi70ynlq+WjcHijyd09nbPmwjG?= =?us-ascii?Q?usA2RC7LVaBYeJ3YliANqLYhpdLgzuP9DrosRWcdj5Hn3rqgj1CAD5dNMI6H?= =?us-ascii?Q?rCfnaJELyGYK1sk99UQ4kwG1WceJ04dPyP2UKxmBKvZX+efIBSJQFMEBhdg9?= =?us-ascii?Q?Qi/9RPHiU69pL4ZI++WXICLzjZ6aAHN+Sa9K4PYsdvygaF+vhs3BfNglMIn7?= =?us-ascii?Q?e9jk8SsBKe/GdMagQaWjl07+jPKfC8wKosJebp0ub7m+V0AY8K7DFvAXNDtV?= =?us-ascii?Q?hldENhqXoZ1HHpJ0qAxqz6C2D6aPpt8hKWU5crJWYhhEgN221sQXCNM40wl9?= =?us-ascii?Q?XMzkl7NChtJEwo6IHYMuB/+mr3zNKRoFnpBjSJvCHkxlSlEZc0H3NLJRf7rc?= =?us-ascii?Q?mbJwyZqWfRO1JTSBk9k6Y9OTanAoFB9+SrwVApGe/DxMU+SEJ82MlO2INoKD?= =?us-ascii?Q?j5+Tq1eTi+TPOe6yt/EJ5KLTIdUFFZKalCcaUl9elwBU99jNuvy8jH281rde?= =?us-ascii?Q?fV1rZBpR3FPMz7c2Krck70VPR/LoDUUStZIkuaeF8L3lLqe7RDBwv8c+Vwnv?= =?us-ascii?Q?lQCFEF5lx2sdNI+criZVDoAgnVPQbxEbOmTMalNWYvOz/4TqVTvEKNylcN5R?= =?us-ascii?Q?DjoztD1lbyhc7PEmeyalmra5cDbwLTbDn+GtyC3cFp4jtunuz1ZlXdc8rtMV?= =?us-ascii?Q?iEwUfcX20S01ePiGfTnFPXH/ohTe+9i8fcmlshBR631im+L9QE9gjf24PtlU?= =?us-ascii?Q?vg1BeoMCV4mimR/pPEMulRA9usselq961AyTEqEtJoU9WH1OCTOx+2vTqm1d?= =?us-ascii?Q?jhnuzeG44QFS0HQEJ6cezYfgEmBChb2RaxOJVIqZ1wuHgeiIGYLgyArC7Dqm?= =?us-ascii?Q?NxP4ZuEGCpEG5ydg8fUxjKEpVY+2BD0rgI=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(136003)(376002)(39850400004)(189003)(199004)(13464003)(32952001)(80792005)(4326008)(97736004)(11346002)(446003)(966005)(478600001)(72206003)(486006)(476003)(68736007)(33656002)(6246003)(102836004)(186003)(26005)(2501003)(14454004)(53936002)(53546011)(6506007)(2351001)(229853002)(105586002)(106356001)(6916009)(9686003)(6306002)(66066001)(55016002)(2906002)(25786009)(5640700003)(6436002)(6116002)(3846002)(256004)(7736002)(54906003)(1730700003)(5024004)(99286004)(7696005)(81166006)(81156014)(76176011)(86362001)(305945005)(8676002)(66574012)(52536013)(71200400001)(71190400001)(5660300002)(316002)(8936002)(74316002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2615; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: Nw506xVzvsWK0XC4c2V/xeOPo5gArsFyuoigfriMcFiw+I2IQ2oOMOnBeCgpmZgeMmOnbyX4j1OXG8Zm7tM5keI9Rvg4fYusTn8r8u0MvEGpaMR9yPJ6LMoHJBsKnlSiKzWb3MqD4FTRZHFS4388FrmpjgaCTA+Wo/jSUtWVjHC/N5bc5QqTpzUsdY1PcNoy9bt3RB6/0EVdsEFZRGh1yHfdqbQ4LffWH7CO3OFc4FMOtZ+QBExwBw8irfIFMH6djcb9nB98jBXg+o3qEiuRr8lgaqnSw8J8d6O/uSD8NtBwRcR7+KjOdGjaTM7rhMf2XcSkF5G3QBBQKcp7RnDfQvKi4U86RyAus1OiX6hRI+qDRQNuy5FFbLqdwcQcr+Bp1Q/bjkzLpdiaIN9If+rKkDZuZQ83J1rc4X8kkT+y7X0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 549e6346-8132-443c-95dc-08d69ae16211 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 05:23:32.1431 (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: BYAPR16MB2615 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6489> : inlines <7020> : streams <1814031> : uri <2801890> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 05:23:39 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-requirements-19 a= ddresses DISCUSS and comments from ISEG members. -Tiru > -----Original Message----- > From: Dots On Behalf Of internet-drafts@ietf.org > Sent: Monday, February 25, 2019 10:25 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is = safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial of Service (DDoS) Open Threa= t Signaling > Requirements > Authors : Andrew Mortensen > Tirumaleswar Reddy > Robert Moskowitz > Filename : draft-ietf-dots-requirements-19.txt > Pages : 22 > Date : 2019-02-24 >=20 > Abstract: > This document defines the requirements for the Distributed Denial of > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > coordinated response to DDoS attacks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-requirements-19 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-19 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-requirements-19 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sun Feb 24 22:18:41 2019 Return-Path: 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 DD66B130DE4; Sun, 24 Feb 2019 22:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 JdvUJkLGwwoe; Sun, 24 Feb 2019 22:18:38 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5677A12F1AC; Sun, 24 Feb 2019 22:18:38 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 447BbJ2n6jz2xnl; Mon, 25 Feb 2019 07:18:36 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 447BbJ1m2VzCqks; Mon, 25 Feb 2019 07:18:36 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0435.000; Mon, 25 Feb 2019 07:18:36 +0100 From: To: Benjamin Kaduk CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUyTUuwyprX++Zj0q/Tpc5E7J3eaXpxvrggAZKQzA= Date: Mon, 25 Feb 2019 06:18:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA24A19@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <20190220155847.GC69562@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA230C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA230C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 06:18:40 -0000 Hi Ben,=20 The updated version with this change is available online. Cheers, Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: jeudi 21 f=E9vrier 2019 07:16 > =C0=A0: Benjamin Kaduk > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > Objet=A0: RE: AD review of draft-ietf-dots-data-channel-25 >=20 > Hi Ben, >=20 > Done in my local copy. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoy=E9=A0: mercredi 20 f=E9vrier 2019 16:59 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > > Objet=A0: Re: AD review of draft-ietf-dots-data-channel-25 > > > > On Thu, Feb 14, 2019 at 01:17:07PM -0600, Benjamin Kaduk wrote: > > > > > > On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.co= m > > wrote: > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > > Envoy=E9=A0: mercredi 13 f=E9vrier 2019 17:46 > > > > > =C0=A0: draft-ietf-dots-data-channel@ietf.org > > > > > Cc=A0: dots@ietf.org > > > > > Objet=A0: AD review of draft-ietf-dots-data-channel-25 > > > > > > > > > > > > > > > Section 3.5 > > > > > > > > > > I had to read up on RESTCONF and NETCONF while reviewing this, bu= t > from > > > > > what I've seen so far, the "error-severity" field is only present= in > > > > > NETCONF and not RESTCONF. If so, then we shouldn't need to talk > about > > it > > > > > here, since we use RESTCONF exclusively. I also couldn't find > whether > > > > > there's a registry that we should add the "loop-detected" error-t= ag > to. > > > > > Can anyone here help me out? > > > > > > > > > > > > > [Med] We used the template in > > https://tools.ietf.org/html/rfc6241#appendix-A because the errors in 80= 40 > are > > the ones imported from there. > > > > > > Thanks for the pointer. It sounds like I'll need to ask around abou= t > this > > > one. > > > > Benoit and Martin confirm that "error-severity" has no purpose in RESTC= ONF, > > so I think we can safely drop this line. > > > > -Ben From nobody Mon Feb 25 22:25:08 2019 Return-Path: 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 EDB77130E77 for ; Mon, 25 Feb 2019 22:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 Fa4G3FsqJ2Bb for ; Mon, 25 Feb 2019 22:25:04 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D2046130E78 for ; Mon, 25 Feb 2019 22:25:03 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A50996265E29EE0E023A for ; Tue, 26 Feb 2019 06:25:01 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Feb 2019 06:25:00 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.156]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Tue, 26 Feb 2019 14:24:54 +0800 From: "Panwei (William)" To: "Konda, Tirumaleswar Reddy" CC: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt Thread-Index: AQHUzMZ+gc8CIkvvTkS5XmN47F8DoaXvdNUAgAIna2A= Date: Tue, 26 Feb 2019 06:24:53 +0000 Message-ID: <30E95A901DB42F44BA42D69DB20DFA6A6096B1CE@nkgeml513-mbx.china.huawei.com> References: <155107048754.10950.7646451304619656582@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.37.117] Content-Type: multipart/alternative; boundary="_000_30E95A901DB42F44BA42D69DB20DFA6A6096B1CEnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 06:25:07 -0000 --_000_30E95A901DB42F44BA42D69DB20DFA6A6096B1CEnkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tiru, There is a nit in the new version. DOTS agents can attempt to learn PMTU using the procedures discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for IPv6. If the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater as specified in [RFC8200]. The red sentence is duplicated with the previous one. Best Regards Wei Pan -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy Sent: Monday, February 25, 2019 1:24 PM To: dots@ietf.org Cc: Ben Campbell ; Eric Rescorla ; Alvaro Re= tana ; Mirja Kuehlewind (IETF) ; Benjamin Kaduk ; Suresh Krishnan Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt This revision https://tools.ietf.org/html/draft-ietf-dots-requirements-19 a= ddresses DISCUSS and comments from ISEG members. -Tiru > -----Original Message----- > From: Dots > On Behal= f Of > internet-drafts@ietf.org > Sent: Monday, February 25, 2019 10:25 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt > > This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the co= ntent is safe. > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. > > Title : Distributed Denial of Service (DDoS) Open Threa= t Signaling > Requirements > Authors : Andrew Mortensen > Tirumaleswar Reddy > Robert Moskowitz > Filename : draft-ietf-dots-requirements-19.txt > Pages : 22 > Date : 2019-02-24 > > Abstract: > This document defines the requirements for the Distributed Denial of > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > coordinated response to DDoS attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-requirements-19 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-19 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-requirements-19 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots --_000_30E95A901DB42F44BA42D69DB20DFA6A6096B1CEnkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

There is a nit in the = new version.

 

DOTS agent= s can attempt to learn PMTU using the procedures

discussed = in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot

be discove= red, DOTS agents MUST assume a PMTU of 1280 bytes for

IPv6. If the PM= TU cannot be discovered, DOTS agents MUST assume a

PMTU of 1280= bytes, as IPv6 requires that every link in the

Internet h= ave an MTU of 1280 octets or greater as specified in

[RFC8200].=

 

The red sentence is du= plicated with the previous one.

 

Best Regards

Wei Pan

 

 

-----Original Message-= ----
From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: Monday, February 25, 2019 1:24 PM
To: dots@ietf.org
Cc: Ben Campbell <ben@nostrum.com>; Eric Rescorla <ekr@rtfm.com>= ;; Alvaro Retana <aretana.ietf@gmail.com>; Mirja Kuehlewind (IETF) &l= t;ietf@kuehlewind.net>; Benjamin Kaduk <kaduk@mit.edu>; Suresh Kri= shnan <suresh@kaloom.com>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt

 

This revision https://tools.ietf.or= g/html/draft-ietf-dots-requirements-19 addresses DISCUSS and com= ments from ISEG members.

 

-Tiru

 

> -----Original Mes= sage-----

> From: Dots <dots-bounces@ietf.org> On Behalf Of

> internet-drafts@ietf.= org

> Sent: Monday, Feb= ruary 25, 2019 10:25 AM

> To: i-d-announce@ietf.org=

> Cc: dots@ietf.org<= /a>

> Subject: [Dots] I= -D Action: draft-ietf-dots-requirements-19.txt

>

> This email origin= ated from outside of the organization. Do not click

> links or open att= achments unless you recognize the sender and know the content is safe.=

>

>

> A New Internet-Dr= aft is available from the on-line Internet-Drafts directories.

> This draft is a w= ork item of the DDoS Open Threat Signaling WG of the IETF.

>

>   =       Title      &nb= sp;    : Distributed Denial of Service (DDoS) Open Threat Si= gnaling

> Requirements=

>   =       Authors      &= nbsp;  : Andrew Mortensen

>   =             &nb= sp;           Tirumaleswa= r Reddy

>   =             &nb= sp;           Robert Mosk= owitz

>    = ;      Filename      = ;  : draft-ietf-dots-requirements-19.txt

>    = ;      Pages      &n= bsp;    : 22

>    = ;      Date      &nb= sp;     : 2019-02-24

>

> Abstract:

>   = This document defines the requirements for the Distributed Denial of<= /o:p>

>   = Service (DDoS) Open Threat Signaling (DOTS) protocols enabling<= /p>

>   = coordinated response to DDoS attacks.

>

>

> The IETF datatrac= ker status page for this draft is:

> https://datatracker.i= etf.org/doc/draft-ietf-dots-requirements/

>

> There are also ht= mlized versions available at:

> https://tools.ietf.or= g/html/draft-ietf-dots-requirements-19

> https://datatracker.i= etf.org/doc/html/draft-ietf-dots-requirements-19

>

> A diff from the p= revious version is available at:

> https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-dots-requirements-19

>

>

> Please note that = it may take a couple of minutes from the time of

> submission until = the htmlized version and diff are available at tools.ietf.org.

>

> Internet-Drafts a= re also available by anonymous FTP at:

> ftp://ftp.ietf.org/in= ternet-drafts/

>

> _________________= ______________________________

> Dots mailing list=

> Dots@ietf.org<= /a>

> https://www.ietf.org/= mailman/listinfo/dots

 

______________________= _________________________

Dots mailing list=

Dots@ietf.= org

https://www.ietf.org/mailman/listinfo/dots

--_000_30E95A901DB42F44BA42D69DB20DFA6A6096B1CEnkgeml513mbxchi_-- From nobody Mon Feb 25 23:57:03 2019 Return-Path: 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 D459C130E8C for ; Mon, 25 Feb 2019 23:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 O_zReXFCHbwf for ; Mon, 25 Feb 2019 23:56:57 -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 DD27C130E86 for ; Mon, 25 Feb 2019 23:56:56 -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=1551167666; 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-ms-exchange-purlcount: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: 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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=/ FdcRWBJuBUkpby6+hYg7VE15qBENbdrvJTebRZtev k=; b=WD3x0maaDCKlS3wGyaDkqrOllFnG4Hcvcs7fySAIX5Ve 2mo/nkGv1TzhIVo+P5U0e+O64X5ww/A0seKonNOdEXuhlRLvUk D9TT56lx5Bl+Qpa68uLJDi1K4k1eESfCta/AZCgxZdiPV1GL20 jd1rZAHLouiWWaabLDj/Ly0PszM= 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 241e_a427_802d7404_51be_47dd_b626_ad10b02ee7e1; Tue, 26 Feb 2019 00:54:25 -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, 26 Feb 2019 00:56:37 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 26 Feb 2019 00:56:37 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 00:56:37 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2584.namprd16.prod.outlook.com (20.177.226.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.21; Tue, 26 Feb 2019 07:56:36 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 07:56:36 +0000 From: "Konda, Tirumaleswar Reddy" To: "Panwei (William)" CC: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt Thread-Index: AQHUzMaKd30Uc+GrIUyTZNhaRaMfHaXv+kdwgAGkI4CAABluwA== Date: Tue, 26 Feb 2019 07:56:35 +0000 Message-ID: References: <155107048754.10950.7646451304619656582@ietfa.amsl.com> <30E95A901DB42F44BA42D69DB20DFA6A6096B1CE@nkgeml513-mbx.china.huawei.com> In-Reply-To: <30E95A901DB42F44BA42D69DB20DFA6A6096B1CE@nkgeml513-mbx.china.huawei.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3edad51-221f-470c-18bc-08d69bbfee69 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2584; x-ms-traffictypediagnostic: BYAPR16MB2584: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNTg0OzIzOmI3RzRUNjNPbmpGOTBjWHNybWZqbEFoZVFl?= =?utf-8?B?T3BDdUxKS1lrSEE3Y3RmRkJ4dks2YUpnYkRoSGNmbjkvL0JwbGpRRVd6QjA3?= =?utf-8?B?cDg4RUJwUFM3WmEvQUtRcEQxZTBjeURtRm4xcENTNnRGMllMT1BXRnVyR2dD?= =?utf-8?B?UStSWnRXSUN2a0p5Uk91Y1lDdkE4UUZockhsNDRRM3cxZm1BMDdaTzd2YXdh?= =?utf-8?B?azdQaFNSTy9VdzRsWUM5STdhclYwdUtHVFJNRHB3UDA4K1cyQ2R0WHBRZUd0?= =?utf-8?B?V0ZQb0dFNlo1eENzcDUvbFFaL0E3cmNnRnk3Q1hYOG00eVVKb3o5aWZnZ1VJ?= =?utf-8?B?blM2bnN3RklId1hZOG9CZUxwMzJpd2JVQXpWOEVwV2g3REEzM1pEYmRSdlY5?= =?utf-8?B?L09Tam5MN1hWdFY0WXFPTTZZU1A0elFCbjZhSE5namVXemxPeHNYc2NKdGlJ?= =?utf-8?B?cmhyMzJibHVUWTRTKzUwVlBQbGlpdlBPdmQwUXAwL0Q0dmVvRENVR3dQRFFE?= =?utf-8?B?MjZEejN6TmxpbTZRNFhhL3JzdVVzYUs0RmlZVnQrbGg4VG5vQ2JHMWlDM1Rp?= =?utf-8?B?VGVFTW90WEx2c1NqRGxQbEJxRVQvTE8wR280OEFqMUN2WFduUmozRnN6TFNE?= =?utf-8?B?TUo1V3BDTXBSSDNuNFlZK1EzZjdqVkxEeFdwaGxMZEo3KzdHby9yTUgwcVlv?= =?utf-8?B?eW1BTzIybC81ZWJPZm5pbElSNU1zOEYwQ0ZpUUxjQUR4WWkrL2VYTUpVOVRl?= =?utf-8?B?OW1NaHJBKzFodnlHTFluOXRaSmxxQkNxY2J0WXdwRWZtWUpHc2FtSTl6NUpH?= =?utf-8?B?dVhUaXZpRVdlM2xtNHQ5Vnh0eXIrcWpiVXoyZmJJOXBVa3cwZWpVelhaQWpG?= =?utf-8?B?dWFCdGlScXFjU0piTWNkdjQxSmhIOUF0SSsyU2VveG1DRVRhL2VZcU5taVQz?= =?utf-8?B?bGlJMWJnVWpVbzZ3NDYwWHAyZFJ3KzVGcGRQalh3Q2VPNWtyeHM4NnNkOVpR?= =?utf-8?B?YXJKK2NuTG5mVlNxU3Vyckl1QzR2Sy9aQzBCcDVyUzd5aTRhMDNXZTVFN0da?= =?utf-8?B?WFIxKytKcTB0VWZvNGp5N09jM1YzdzVpNnZyZUhhZElsSExWTmJuUUNUd29N?= =?utf-8?B?a2RhN0c3b3NrQnJnYTlKSHJYQ2RxWnJndVBVaHV3TkQrWGVlNjFMd0doOER2?= =?utf-8?B?dk5yVHVGcEZUYTBlQW95dkVDc3V5a3lscFpDLzl6cmVJSWtyOXpHZm8rajF2?= =?utf-8?B?MFlwdXBlOWRqK3pQUlNGV0cwNzllS0F2bVAyMWlpYUZSTTFGMnZNWVVQTnNs?= =?utf-8?B?VGh0Z2Nnd3NtL3d6VE1QTTQrdklFWlh5QkxnMWZkcU5WakNDbUhlQXNwdWlW?= =?utf-8?B?aHF4RzBRcXN1NDE5RWE2bTNzUk1zVVNJby9Tc29NaEp3cXR3bzFvM1JyL1VD?= =?utf-8?B?OUVFMVV0L0pGY0ZyK2hwajZ0Q3ljRWxVYURwUi8rQXRJVUhVY3lhanJodGxD?= =?utf-8?B?Z3Vudm4wSDlBTVFIWWZHcERPM2VzME8xMTNPU1ZsZlhhVzRIcXplcEdiNjJU?= =?utf-8?B?S3BzSlVyb1JYQWVWaWFiNDZ3Nlk1Znd6cWtYcXUyMUdzekpGL3JaT2pBeUxC?= =?utf-8?B?Q3VxMGhBNzZSZEZ0NnR6dnJ1YkQzakUyUDJYL3NUUkZmUFR5aFlhcHVCT0Uv?= =?utf-8?B?UWFoOVVydjY5enJJOGhGSFg4a1VqS2Z2S2g3VXlnbnJJQUdNWjFvY3hZdmxx?= =?utf-8?B?eTdORDFOdVFSSDBYalNNT1czTDhFVWk3UkpXaGZZNTFnbEpDeDRTeE5Eb3JV?= =?utf-8?B?Z3BsUFJXeGZJdXo2UFVEaWxGUjV2eWV4am9jdmVsd1QvYUowUFhmSU5ITjRC?= =?utf-8?B?SmN2WFAxTGQ5ZFBrRG1tTDRnaXVJVVF2VitycWJ6b0VFWit6cnQ5UGJJUFNx?= =?utf-8?Q?b2OACSxg6mOKXiuV4fR6si6njSlgbU=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(396003)(136003)(346002)(199004)(189003)(13464003)(32952001)(6506007)(53546011)(186003)(53936002)(25786009)(66066001)(71190400001)(71200400001)(81156014)(81166006)(8936002)(26005)(66574012)(6116002)(3846002)(790700001)(8676002)(106356001)(102836004)(7736002)(74316002)(229853002)(486006)(99286004)(476003)(4326008)(105586002)(6916009)(6436002)(11346002)(446003)(80792005)(97736004)(256004)(5024004)(86362001)(6246003)(9686003)(55016002)(54896002)(6306002)(7696005)(76176011)(478600001)(72206003)(316002)(2906002)(68736007)(33656002)(606006)(236005)(14454004)(966005)(52536013)(5660300002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2584; H:BYAPR16MB2790.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: JPzUbhFSYuLRRfgkHjZPEakZDv65vzyZPFmZzGCB/p7aCYTQJz3ucL/LRhFJLO909dD36WcaTY9Vy2slPRYENqTJm/9qb+37WZO5tNM6H8sLf8DLD4Of0QwXc2tqvWZ+lYhLzr/ZifS10dByFUO8bx81gvl3OD2EntJA9PbbaceaR6vutIYkHnESjb//g32Mt/CNwgsnFcOCxaig9WGPkIFuL2/S/M+uD6UaYzQn5uwft1N/G1Ziav+zbsXCRuu0b1CaYSCqq88OQOaTYGtlTlDB2Fav/yaPkIV9BURNcdxS9HUKLjP5ALvnuRJqMwc5+NyNU5w2ypgMf1pq6zDe4xfmiX29+n23lem7KG7I4bjvk2fqITj0feyxSkj/n/cDXLX+Iq80TEZL5Cosi8J99dXc4WKS6jfTvvjdg2/w9Yg= Content-Type: multipart/alternative; boundary="_000_BYAPR16MB27901DF313CDA80D7B1E6338EA7B0BYAPR16MB2790namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d3edad51-221f-470c-18bc-08d69bbfee69 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 07:56:35.9356 (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: BYAPR16MB2584 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6490> : inlines <7023> : streams <1814137> : uri <2802447> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-19.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 07:57:00 -0000 --_000_BYAPR16MB27901DF313CDA80D7B1E6338EA7B0BYAPR16MB2790namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFdlaSwgd2lsbCBmaXggdGhlIG5pdCBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KLVRp cnUNCg0KRnJvbTogUGFud2VpIChXaWxsaWFtKSA8d2lsbGlhbS5wYW53ZWlAaHVhd2VpLmNvbT4N ClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE5IDExOjU1IEFNDQpUbzogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCkNj OiBkb3RzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0RvdHNdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtZG90cy1yZXF1aXJlbWVudHMtMTkudHh0DQoNCg0KQ0FVVElPTjogRXh0ZXJuYWwgZW1haWwu IERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2du aXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpIaSBUaXJ1LA0KDQoNCg0KVGhlcmUgaXMgYSBu aXQgaW4gdGhlIG5ldyB2ZXJzaW9uLg0KDQoNCkRPVFMgYWdlbnRzIGNhbiBhdHRlbXB0IHRvIGxl YXJuIFBNVFUgdXNpbmcgdGhlIHByb2NlZHVyZXMNCmRpc2N1c3NlZCBpbiBbSS1ELmlldGYtaW50 YXJlYS1mcmFnLWZyYWdpbGVdLiBJZiB0aGUgUE1UVSBjYW5ub3QNCmJlIGRpc2NvdmVyZWQsIERP VFMgYWdlbnRzIE1VU1QgYXNzdW1lIGEgUE1UVSBvZiAxMjgwIGJ5dGVzIGZvcg0KSVB2Ni4gSWYg dGhlIFBNVFUgY2Fubm90IGJlIGRpc2NvdmVyZWQsIERPVFMgYWdlbnRzIE1VU1QgYXNzdW1lIGEN ClBNVFUgb2YgMTI4MCBieXRlcywgYXMgSVB2NiByZXF1aXJlcyB0aGF0IGV2ZXJ5IGxpbmsgaW4g dGhlDQpJbnRlcm5ldCBoYXZlIGFuIE1UVSBvZiAxMjgwIG9jdGV0cyBvciBncmVhdGVyIGFzIHNw ZWNpZmllZCBpbg0KW1JGQzgyMDBdLg0KDQoNCg0KVGhlIHJlZCBzZW50ZW5jZSBpcyBkdXBsaWNh dGVkIHdpdGggdGhlIHByZXZpb3VzIG9uZS4NCg0KDQoNCkJlc3QgUmVnYXJkcw0KDQpXZWkgUGFu DQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERvdHMgW21haWx0 bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLb25kYSwgVGlydW1hbGVzd2Fy IFJlZGR5DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDE5IDE6MjQgUE0NClRvOiBkb3Rz QGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KQ2M6IEJlbiBDYW1wYmVsbCA8YmVuQG5v c3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PjsgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0 Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PjsgQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRm QGdtYWlsLmNvbTxtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4+OyBNaXJqYSBLdWVobGV3 aW5kIChJRVRGKSA8aWV0ZkBrdWVobGV3aW5kLm5ldDxtYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5l dD4+OyBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdTxtYWlsdG86a2FkdWtAbWl0LmVkdT4+ OyBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaEBrYWxvb20uY29tPG1haWx0bzpzdXJlc2hAa2Fsb29t LmNvbT4+DQpTdWJqZWN0OiBSZTogW0RvdHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1y ZXF1aXJlbWVudHMtMTkudHh0DQoNCg0KDQpUaGlzIHJldmlzaW9uIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5IGFkZHJlc3NlcyBESVND VVNTIGFuZCBjb21tZW50cyBmcm9tIElTRUcgbWVtYmVycy4NCg0KDQoNCi1UaXJ1DQoNCg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogRG90cyA8ZG90cy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YNCg0K PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4NCg0KPiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDE5IDEwOjI1IEFNDQoNCj4gVG86 IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KDQo+ IENjOiBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFtE b3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5LnR4dA0KDQo+ DQoNCj4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0 aW9uLiBEbyBub3QgY2xpY2sNCg0KPiBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5 b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0K Pg0KDQo+DQoNCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQo+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFdHIG9mIHRoZSBJRVRG Lg0KDQo+DQoNCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBEaXN0cmlidXRlZCBEZW5pYWwg b2YgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nDQoNCj4gUmVxdWlyZW1lbnRz DQoNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBBbmRyZXcgTW9ydGVuc2VuDQoNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICBUaXJ1bWFsZXN3YXIgUmVkZHkNCg0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJvYmVydCBNb3Nrb3dpdHoNCg0KPiAgICAgICAgICBGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5LnR4dA0KDQo+ICAgICAgICAg IFBhZ2VzICAgICAgICAgICA6IDIyDQoNCj4gICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAx OS0wMi0yNA0KDQo+DQoNCj4gQWJzdHJhY3Q6DQoNCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBEaXN0cmlidXRlZCBEZW5pYWwgb2YNCg0KPiAgICBT ZXJ2aWNlIChERG9TKSBPcGVuIFRocmVhdCBTaWduYWxpbmcgKERPVFMpIHByb3RvY29scyBlbmFi bGluZw0KDQo+ICAgIGNvb3JkaW5hdGVkIHJlc3BvbnNlIHRvIEREb1MgYXR0YWNrcy4NCg0KPg0K DQo+DQoNCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3Rz LXJlcXVpcmVtZW50cy8NCg0KPg0KDQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25z IGF2YWlsYWJsZSBhdDoNCg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1kb3RzLXJlcXVpcmVtZW50cy0xOQ0KDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOQ0KDQo+DQoNCj4gQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5 DQoNCj4NCg0KPg0KDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQoNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQo+ DQoNCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KDQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCj4NCg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IERvdHMg bWFpbGluZyBsaXN0DQoNCj4gRG90c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCg0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRvdHMgbWFpbGlu ZyBsaXN0DQoNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K --_000_BYAPR16MB27901DF313CDA80D7B1E6338EA7B0BYAPR16MB2790namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAx MSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpHYWR1Z2k7DQoJ cGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhcmEtbWFyZ2luLXRvcDouM2dkOw0KCW1z by1wYXJhLW1hcmdpbi1yaWdodDowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouM2dkOw0K CW1zby1wYXJhLW1hcmdpbi1sZWZ0OjBpbjsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRl eHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhcmEtbWFyZ2luLXRvcDouM2dkOw0KCW1z by1wYXJhLW1hcmdpbi1yaWdodDowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTowaW47DQoJ bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJHYWR1Z2kiLHNhbnMtc2VyaWY7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1u YW1lOue6r+aWh+acrDsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYXJhLW1hcmdpbi10b3A6LjNn ZDsNCgltc28tcGFyYS1tYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206 LjNnZDsNCgltc28tcGFyYS1tYXJnaW4tbGVmdDowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglm b250LWZhbWlseToiR2FkdWdpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1 aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6LjA1aW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOi4wNWlu O21hcmdpbi1sZWZ0OjBpbiI+DQpUaGFua3MgV2VpLCB3aWxsIGZpeCB0aGUgbml0IGluIHRoZSBu ZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDouMDVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 LjA1aW47bWFyZ2luLWxlZnQ6MGluIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDouMDVpbjttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206LjA1aW47bWFyZ2luLWxlZnQ6MGluIj4NCi1UaXJ1PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4w NWluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTouMDVpbjttYXJnaW4tbGVmdDowaW4i Pg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBQYW53ZWkgKFdpbGxpYW0pICZsdDt3aWxsaWFtLnBhbndlaUBodWF3ZWkuY29tJmd0OyA8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMjYsIDIwMTkgMTE6NTUgQU08YnI+ DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0O1RpcnVtYWxlc3dhclJl ZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkb3RzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3Rz LXJlcXVpcmVtZW50cy0xOS50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4wNWluO21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTouMDVpbjttYXJnaW4tbGVmdDowaW4iPg0KPG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIxIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJhY2tncm91bmQ6I0YzRkYzMztib3JkZXI6c29s aWQgIzlCOUE4NyAxLjVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25l O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHA+PHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOUI4QjNF Ij5DQVVUSU9OPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5QjhCM0UiPjo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiBF eHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4NCiBhdHRhY2htZW50cyB1 bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNh ZmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVy Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LXRvcDouMDVpbiI+SGkgVGlydSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj5UaGVyZSBpcyBhIG5p dCBpbiB0aGUgbmV3IHZlcnNpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4wNWluO21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTouMDVpbjttYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291 cmllcjtjb2xvcjpibGFjayI+RE9UUyBhZ2VudHMgY2FuIGF0dGVtcHQgdG8gbGVhcm4gUE1UVSB1 c2luZyB0aGUgcHJvY2VkdXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6LjA1aW47bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOi4wNWluO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9y OmJsYWNrIj5kaXNjdXNzZWQgaW4gW0ktRC5pZXRmLWludGFyZWEtZnJhZy1mcmFnaWxlXS4gSWYg dGhlIFBNVFUgY2Fubm90PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDouMDVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206LjA1aW47bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6Ymxh Y2siPmJlIGRpc2NvdmVyZWQsIERPVFMgYWdlbnRzIE1VU1QgYXNzdW1lIGEgUE1UVSBvZiAxMjgw IGJ5dGVzIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6LjA1aW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOi4wNWluO21hcmdpbi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5J UHY2LiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291 cmllcjtjb2xvcjpyZWQiPklmIHRoZSBQTVRVIGNhbm5vdCBiZSBkaXNjb3ZlcmVkLCBET1RTIGFn ZW50cyBNVVNUIGFzc3VtZSBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDouMDVpbjttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206LjA1aW47bWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWF1dG9zcGFjZTpub25lIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6 cmVkIj5QTVRVIG9mIDEyODAgYnl0ZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+LCBhcyBJUHY2IHJlcXVpcmVzIHRo YXQgZXZlcnkgbGluayBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4wNWluO21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTouMDVpbjttYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xv cjpibGFjayI+SW50ZXJuZXQgaGF2ZSBhbiBNVFUgb2YgMTI4MCBvY3RldHMgb3IgZ3JlYXRlciBh cyBzcGVjaWZpZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4wNWluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTouMDVpbjttYXJnaW4tbGVmdDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFj ayI+W1JGQzgyMDBdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj5UaGUgcmVkIHNlbnRl bmNlIGlzIGR1cGxpY2F0ZWQgd2l0aCB0aGUgcHJldmlvdXMgb25lLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6 LjA1aW4iPkJlc3QgUmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPldlaSBQYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tdG9wOi4wNWluIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IERv dHMgWzxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eTxicj4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjUsIDIwMTkgMToyNCBQTTxicj4NClRvOiA8 YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQpDYzog QmVuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9z dHJ1bS5jb208L2E+Jmd0OzsgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBy dGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs7IEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9 Im1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tIj5hcmV0YW5hLmlldGZAZ21haWwuY29tPC9h PiZndDs7IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBr dWVobGV3aW5kLm5ldCI+aWV0ZkBrdWVobGV3aW5kLm5ldDwvYT4mZ3Q7Ow0KIEJlbmphbWluIEth ZHVrICZsdDs8YSBocmVmPSJtYWlsdG86a2FkdWtAbWl0LmVkdSI+a2FkdWtAbWl0LmVkdTwvYT4m Z3Q7OyBTdXJlc2ggS3Jpc2huYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpzdXJlc2hAa2Fsb29tLmNv bSI+c3VyZXNoQGthbG9vbS5jb208L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbRG90c10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOS50eHQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t dG9wOi4wNWluIj5UaGlzIHJldmlzaW9uIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5Ij4NCjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOTwvc3Bhbj48L2E+IGFkZHJlc3Nl cyBESVNDVVNTIGFuZCBjb21tZW50cyBmcm9tIElTRUcgbWVtYmVycy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9w Oi4wNWluIj4tVGlydTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi10b3A6LjA1aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IEZyb206IERvdHMgJmx0OzxhIGhyZWY9Im1haWx0bzpk b3RzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsgT24g QmVoYWxmIE9mDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyBT ZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDE5IDEwOjI1IEFNPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyBUbzog PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aS1kLWFubm91bmNlQGlldGYub3Jn PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9y ZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ ZG90c0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyBTdWJqZWN0OiBbRG90c10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOS50eHQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10 b3A6LjA1aW4iPiZndDsgVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUg b3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgbGlua3Mgb3Igb3BlbiBh dHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBj b250ZW50IGlzIHNhZmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsg QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cgb2YgdGhlIElFVEYuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDou MDVpbiI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogRGlzdHJpYnV0ZWQgRGVuaWFsIG9mIFNlcnZpY2Ug KEREb1MpIE9wZW4gVGhyZWF0IFNpZ25hbGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgUmVxdWlyZW1lbnRzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDou MDVpbiI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDogQW5kcmV3IE1vcnRlbnNlbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGlydW1hbGVzd2FyIFJlZGR5PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb2JlcnQgTW9za293aXR6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVp biI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFm dC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWlu Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBE YXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogMjAxOS0wMi0yNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyBBYnN0 cmFjdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tdG9wOi4wNWluIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVmaW5l cyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgRGlzdHJpYnV0ZWQgRGVuaWFsIG9mPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJ2aWNlIChERG9TKSBPcGVuIFRocmVhdCBTaWduYWxp bmcgKERPVFMpIHByb3RvY29scyBlbmFibGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsgY29vcmRpbmF0ZWQgcmVzcG9uc2UgdG8gRERvUyBhdHRhY2tzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDou MDVpbiI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy8iPg0KPHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMvPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tdG9wOi4wNWluIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTkiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5PC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t dG9wOi4wNWluIj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xOSI+DQo8c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTE5PC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t dG9wOi4wNWluIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG90cy1yZXF1aXJlbWVudHMtMTkiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRz LTE5PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLXRvcDouMDVpbiI+Jmd0OyBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0 OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t dG9wOi4wNWluIj4mZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LXRvcDouMDVpbiI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+Jmd0OyBEb3RzIG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1 aW4iPiZndDsgPGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkRvdHNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi10b3A6LjA1aW4iPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kb3RzIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi10b3A6LjA1aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4iPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDouMDVpbiI+RG90cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOi4wNWluIj48 YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkRvdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6LjA1aW4i PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR16MB27901DF313CDA80D7B1E6338EA7B0BYAPR16MB2790namp_-- From nobody Tue Feb 26 07:06:55 2019 Return-Path: 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 99A2F128CB7 for ; Tue, 26 Feb 2019 07:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 L2SAslTPtd2h for ; Tue, 26 Feb 2019 07:06:51 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5B8130E69 for ; Tue, 26 Feb 2019 07:06:51 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4482GK6LHQz10XP; Tue, 26 Feb 2019 16:06:49 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 4482GK5R4dzDq7q; Tue, 26 Feb 2019 16:06:49 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([fe80::7873:1668:636f:52c%21]) with mapi id 14.03.0435.000; Tue, 26 Feb 2019 16:06:49 +0100 From: To: "Panwei (William)" , "dots@ietf.org" Thread-Topic: Call for adoption on draft-boucadair-dots-server-discovery Thread-Index: AdSI+mzom/yrMKu/SJm1ohZrl+sYtAsQHQGABiof+eA= Date: Tue, 26 Feb 2019 15:06:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA257F3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC0184C52F1B@marathon> <30E95A901DB42F44BA42D69DB20DFA6A6093D744@nkgeml513-mbx.china.huawei.com> In-Reply-To: <30E95A901DB42F44BA42D69DB20DFA6A6093D744@nkgeml513-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA257F3OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Call for adoption on draft-boucadair-dots-server-discovery 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 15:06:54 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA257F3OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Wei, Apologies for the delay to answer this message. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Panwei (William) Envoy=E9 : samedi 26 janvier 2019 10:38 =C0 : dots@ietf.org Objet : Re: [Dots] Call for adoption on draft-boucadair-dots-server-discove= ry Hi, I support adoption of this draft. Two typos: 1. Section 5 When only DOTS server' IP ^^^^^^^ addresses are configured, a reference identifier must also be configured for authentication purposes. "server'" should be "server's". 2. Section 9.1.2 and 9..2.2 9.1.2. Format Format of DOTS Address Option ^^^^^^^^^^^^^ 9.2.2. Format Format of DOTS Address Option ^^^^^^^^^^^^^ Duplicate "Format". [Med] Fixed. Thanks. Two comments: 1. Section 9.1.1 and 9..2.1 describe the DOTS Reference Identifier Option, = but the content of these Option is DOTS server name. I'm not quite familiar= with this, so I just raise this and want to make sure if the content is ri= ght. [Med] That is on purpose. The introduction text in Section 9 states the fol= lowing: Defining the option to include a list of IP addresses would avoid a dependency on an underlying name resolution, but that design requires to also supply a name for PKIX-based authentication purposes. The option is not called "name" but reference identifier, because aliasing = is not recommended as per https://tools.ietf.org/html/rfc7227#section-7. 2. In section 9.1.2, the "List of DOTS IPv4 Addresses" contains one or more= IPv4 addresses of a DOTS server, and the "OPTION_V4_DOTS" can include mult= iple lists. When the "OPTION_V4_DOTS" includes multiple lists, do these lis= ts belong to one DOTS server or multiple DOTS servers? My understanding is = that multiple lists belong to multiple DOTS servers and one DOTS server onl= y has one list. I'm not quite sure, maybe an example can be added in the dr= aft. [Med] The text says the following: OPTION_V4_DOTS can include multiple lists of DOTS IPv4 addresses; each list is treated separately as it corresponds to a given DOTS server. That a client can be provided with one or multiple DOTS servers. Each of th= ese servers can be bound to one or multiple IPv4 addresses. Best Regards Wei Pan > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Saturday, December 01, 2018 6:22 AM > To: dots@ietf.org > Subject: [Dots] Call for adoption on draft-boucadair-dots-server-discover= y > > Hello! > > This is the start of a two week call for input on the WG adoption of the > document: > > draft-boucadair-dots-server-discovery > https://tools.ietf.org/html/draft-boucadair-dots-server-discovery-05 > > The document has been presented and discussed at IETF 103, IETF 100 > and IETF 99; and revisions have been made based on WG feedback. > Discussion of adoption of this draft was previously deferred pending > submission of the signal draft for publication (which occurred in > September 2018). > > At the IETF 103 meeting, there were not many participants who had read > the draft. > > Please provide feedback to the list/chairs if you believe that this > document should be adopted as a WG document. The adoption call will > end on December 14 2018. > > Regards, > Roman and Frank > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --_000_787AE7BB302AE849A7480A190F8B93302EA257F3OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Wei,

 

Apologies for the delay to answer this message.

 

Please see inline.

 

Cheers,

Med

 

De : Dots= [mailto:dots-bounces@ietf.org] De la part de Panwei (William)
Envoy=E9 : samedi 26 janvier 2019 10:38
=C0 : dots@ietf.org
Objet : Re: [Dots] Call for adoption on draft-boucadair-dots-se= rver-discovery

 

H= i,

<= o:p> 

I= support adoption of this draft.  

<= o:p> 

T= wo typos:

1= . Section 5

When on= ly DOTS server’ IP

 &= nbsp;           &nbs= p; ^^^^^^^

address= es are configured, a reference identifier must also be

configu= red for authentication purposes.

&= #8220;server’” should be “server’s”.

<= o:p> 

2= . Section 9.1.2 and 9..2.2

9.1.2. = Format Format of DOTS Address Option

 &= nbsp;     ^^^^^^^^^^^^^

9.2.2. = Format Format of DOTS Address Option

 &= nbsp;     ^^^^^^^^^^^^^

D= uplicate “Format”.

 

[= Med] Fixed. Thanks.

<= o:p> 

T= wo comments:

1= . Section 9.1.1 and 9..2.1 describe the DOTS Reference Identifier Option, b= ut the content of these Option is DOTS server name. I’m not quite fam= iliar with this, so I just raise this and want to make sure if the content is right.

 

[= Med] That is on purpose. The introduction text in Section 9 states the foll= owing:

 
   Defining the option to =
include a list of IP addresses would avoid a
   dependency on an underl=
ying name resolution, but that design requires
   to also supply a name f=
or PKIX-based authentication purposes.

<= o:p> 

T= he option is not called “name” but reference identifier, becaus= e aliasing is not recommended as per https://tools.iet= f.org/html/rfc7227#section-7.

<= o:p> 

2= . In section 9.1.2, the “List of DOTS IPv4 Addresses” contains = one or more IPv4 addresses of a DOTS server, and the “OPTION_V4_DOTS&= #8221; can include multiple lists. When the “OPTION_V4_DOTS” in= cludes multiple lists, do these lists belong to one DOTS server or multiple DOTS = servers? My understanding is that multiple lists belong to multiple DOTS se= rvers and one DOTS server only has one list. I’m not quite sure, mayb= e an example can be added in the draft.

<= o:p> 

[= Med] The text says the following:

 
      OPTIO=
N_V4_DOTS can include multiple lists of DOTS IPv4 addresses;
      each =
list is treated separately as it corresponds to a given DOTS
      server.

<= o:p> 

T= hat a client can be provided with one or multiple DOTS servers. Each of the= se servers can be bound to one or multiple IPv4 addresses.

 

B= est Regards

W= ei Pan

<= o:p> 

<= o:p> 

&= gt; -----Original Message-----

&= gt; From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw

&= gt; Sent: Saturday, December 01, 2018 6:22 AM

&= gt; To: dots@ietf.org

&= gt; Subject: [Dots] Call for adoption on draft-boucadair-dots-server-discov= ery

&= gt;

&= gt; Hello!

&= gt;

&= gt; This is the start of a two week call for input on the WG adoption of th= e

&= gt; document:

&= gt;

&= gt; draft-boucadair-dots-server-discovery

&= gt; https://tools.ietf.or= g/html/draft-boucadair-dots-server-discovery-05

&= gt;

&= gt; The document has been presented and discussed at IETF 103, IETF 100

&= gt; and IETF 99;  and revisions have been made based on WG feedback.

&= gt; Discussion of adoption of this draft was previously deferred pending

&= gt; submission of the signal draft for publication (which occurred in<= /o:p>

&= gt; September 2018).

&= gt;

&= gt; At the IETF 103 meeting, there were not many participants who had read<= o:p>

&= gt; the draft.

&= gt;

&= gt; Please provide feedback to the list/chairs if you believe that this

&= gt; document should be adopted as a WG document.  The adoption call wi= ll

&= gt; end on December 14 2018.

&= gt;

&= gt; Regards,

&= gt; Roman and Frank

&= gt;

&= gt; _______________________________________________

&= gt; Dots mailing list

&= gt; Dots@ietf.org<= /a>

&= gt; https://www.ietf.org/= mailman/listinfo/dots

--_000_787AE7BB302AE849A7480A190F8B93302EA257F3OPEXCAUBMA2corp_-- From nobody Tue Feb 26 07:12:10 2019 Return-Path: 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 E72C813106E for ; Tue, 26 Feb 2019 07:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ipAP2uLn7uDI for ; Tue, 26 Feb 2019 07:12:00 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD041310B7 for ; Tue, 26 Feb 2019 07:11:59 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4482NG0jHmz8thK; Tue, 26 Feb 2019 16:11:58 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4482NF724jz3wbN; Tue, 26 Feb 2019 16:11:57 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([fe80::34b6:11d0:147f:6560%21]) with mapi id 14.03.0435.000; Tue, 26 Feb 2019 16:11:57 +0100 From: To: "Konda, Tirumaleswar Reddy" CC: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt Thread-Index: AQHUysO2BSyTdnM0Qka7k+Ykw8xjSaXr/0pggAY1FWA= Date: Tue, 26 Feb 2019 15:11:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA25825@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155084937056.5323.18401033305053602209@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 15:12:08 -0000 Hi Tiru,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumales= war > Reddy > Envoy=E9=A0: vendredi 22 f=E9vrier 2019 17:20 > =C0=A0: dots@ietf.org; i-d-announce@ietf.org > Objet=A0: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt >=20 > Hi Med, >=20 > Couple of Nits: >=20 > 1) > OLD: > Likewise, 'sid' value is > monotonically increased by the DOTS client for each configuration > session, attackers replaying configuration requests with lower > numeric 'sid' values will be rejected by the DOTS server if it > maintains a higher numeric 'sid' value for this DOTS client. >=20 > NEW: > Likewise, 'sid' value is > monotonically increased by the DOTS client for each configuration > request, attackers replaying configuration requests with lower > numeric 'sid' values will be rejected by the DOTS server if it > maintains a higher numeric 'sid' value for this DOTS client. >=20 [Med] OK for s/session/request.=20 > 2) > Define 'idle' time (i.e. when no attack traffic is present). [Med] This one is not needed, IMHO. We do already have the following in the= draft:=20 The same or distinct configuration sets may be used during times when ^^^^^^^^^^ a mitigation is active ('mitigating-config') and when no mitigation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ is active ('idle-config'). This is particularly useful for DOTS ^^^^^^^^^^^^^^^^^ servers that might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation. If distinct configurations are used, DOTS agents MUST follow the appropriate configuration set as a function of the mitigation activity (e.g., if no mitigation request is active, 'idle- config'-related values must be followed). Additionally, DOTS agents MUST automatically switch to the other configuration upon a change in the mitigation activity (e.g., if an attack mitigation is launched after an 'idle' time, the DOTS agent switches from 'idle-config' to 'mitigating-config'-related values). >=20 > -Tiru >=20 > > -----Original Message----- > > From: Dots On Behalf Of internet-drafts@ietf.or= g > > Sent: Friday, February 22, 2019 9:00 PM > > To: i-d-announce@ietf.org > > Cc: dots@ietf.org > > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt > > > > This email originated from outside of the organization. Do not click li= nks > or > > open attachments unless you recognize the sender and know the content i= s > safe. > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of the I= ETF. > > > > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) > > Signal Channel Specification > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-29.txt > > Pages : 99 > > Date : 2019-02-22 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and configuration > > purposes. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements within the document with the RFC > > number to be assigned to this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel Specification"; > > > > o "| [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > Please update this statement with the RFC number to be assigned to > > the following documents: > > > > o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data- > > channel) > > > > Please update TBD/TBD1/TBD2 statements with the assignments made by > > IANA to DOTS Signal Channel Protocol. > > > > Also, please update the "revision" date of the YANG modules. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-29 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-29 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-29 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Feb 26 07:15:23 2019 Return-Path: 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 E2D99130EA7; Tue, 26 Feb 2019 07:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xWnFiL6YCbBh; Tue, 26 Feb 2019 07:15:19 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16502130EA0; Tue, 26 Feb 2019 07:15:19 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4482S56S3nz1yKJ; Tue, 26 Feb 2019 16:15:17 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4482S55fhyzyQW; Tue, 26 Feb 2019 16:15:17 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0435.000; Tue, 26 Feb 2019 16:15:17 +0100 From: To: Benjamin Kaduk CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUx6ZJ1F7LXcjiyEyakQdm0IXWmKXmq4XAgAuQhTA= Date: Tue, 26 Feb 2019 15:15:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA25857@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 15:15:22 -0000 Hi Ben, FWIW, a NEW text was added to -29 to cover the session configuration reply.= =20 Cheers, Med > -----Message d'origine----- > De=A0: BOUCADAIR Mohamed TGI/OLN > Envoy=E9=A0: mardi 19 f=E9vrier 2019 08:59 > =C0=A0: 'Benjamin Kaduk' > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org= ; > dots@ietf.org > Objet=A0: RE: Using Early Data in DOTS (RE: [Dots] AD review of draft-iet= f- > dots-signal-channel) >=20 > Hi Ben, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoy=E9=A0: lundi 18 f=E9vrier 2019 17:23 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.o= rg; > > dots@ietf.org > > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-i= etf- > > dots-signal-channel) > > > > On Fri, Feb 15, 2019 at 03:36:05PM +0000, mohamed.boucadair@orange.com > wrote: > > > Re-, > > > > > > Looking forward to discuss this further. > > > > > > I wonder whether you can consider putting the document in the IETF LC= for > > now. If it happen that we need to modify the 0-RTT text, we will handle= it > as > > other IETF LC comments. > > > > I would normally be pretty amenable to starting IETF LC and continuing > > discussion; it's just for this issue in particular that I seem to be th= e > > main person on the IESG that enforces the "application profile for 0-RT= T > > data" requirement, so it would feel rather odd to go forward in this ca= se. >=20 > [Med] Fair enough. >=20 > > Luckily, I spent some time this weekend reading RFC 7252 and have some > > substantive comments. > > > > The key oberservation here seems to be that the Message ID is scoped pe= r > > endpoint, and replays can come from arbitrary addresses. > > > > Specifically, we recall that: > > > > The DOTS signal channel is layered on existing standards (Figure 3). > > > > +---------------------+ > > | DOTS Signal Channel | > > +---------------------+ > > | CoAP | > > +----------+----------+ > > | TLS | DTLS | > > +----------+----------+ > > | TCP | UDP | > > +----------+----------+ > > | IP | > > +---------------------+ > > > > We note that CoAP is using the IP address or "DTLS session" (arguably a > > poorly chosen term) to identify a CoAP association and that Message IDs= are > > only used within the scope of such an association, it seems pretty clea= r > > that an attacker able to replay TLS 1.3 0-RTT data will slice off the t= op > > three lines of this figure and swap out the TCP/UDP/IP layers. In the > > absence of DTLS connection IDs, my understanding is that the "DTLS sess= ion" > > is identified solely by the transport connection, just as for coap-not-= s, > > so by spoofing the source address, the attacker causes the replayed 0-R= TT > > data (and thus, CoAP request) to be interpreted as a new incoming coaps > > connection. > > > > Given that Message ID is only 16 bits and the servers accepting 0-RTT d= ata > > have potential to be quite busy, it does not seem workable to attempt t= o > > use the incoming Message IDs as globally unique replay defense, as the = risk > > of collision would be pretty large. >=20 > [Med] The replay detection relies on both Message ID and Token. >=20 > > > > So I think that the 'mid' monotonicity and the rejection of conflicting > > request scopes are the main mitigating factors against replay in the > > current design (alongside the RFC 8446 mechanisms, of course), and the = text > > should be adjusted to reflect that. >=20 > [Med] We do already have the following in the draft: >=20 > The DOTS server(s) can use Message ID and > Token in the DOTS signal channel message to detect replay of early > data, and accept 0-RTT data at most once. Furthermore, 'mid' > ^^^^^^^^^^^^^^^^^^ > value is monotonically increased by the DOTS client for each > mitigation request, attackers replaying mitigation requests with > lower numeric 'mid' values and overlapping scopes with mitigation > requests having higher numeric 'mid' values will be rejected > systematically by the DOTS server. >=20 > > > > It seems that the 'mid' ordering is probably enough to protect > > reordering/replay of mitigiation request and withdraw, even when reorde= red > > across other mitigation actions. But I am more concerned about > > reordering/replay of other messages, like efficacy updates and session > > configuration changes. >=20 > [Med] For the configuration changes, I don't expect the exchange to happe= n > during an attack. The part of the text we are discussing is about mitigat= ion > requests. >=20 > o 0-RTT mode in which the DOTS client can authenticate itself and > send DOTS mitigation request messages in the first message, thus > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > reducing handshake latency. >=20 > Putting that aside, we do have the following: >=20 > The PUT request with a higher numeric 'sid' value overrides the DOTS > signal channel session configuration data installed by a PUT request > with a lower numeric 'sid' value. To avoid maintaining a long list > of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be > automatically deleted and no longer available at the DOTS server. >=20 > Any replayed configuration change request will be discarded owing to the > 'sid' checks. >=20 > > > > Consider > > > > client attacker server > > | > > |----efficacy: attack mitigated--------------------->| > > | | > > |----efficacy: under attack------------------------->| > > | | > > | |-replay: attack mitigated->| > > > > Is the server going to end up with the expected state? >=20 > [Med] A general comment: The dots server uses the information conveyed in= the > efficacy update as a hint; it may but it is not required to rely on those > requests to adjust its mitigation actions. >=20 > If the two first status messages are bound to distinct "mids" and adjuste= d > scopes, the replayed request will be discarded by the server thanks to th= e > presence of If-Match option. The server does not maintain the request wit= h > the old mid. >=20 > If, for some reason, the same mid is used and this flow is observed, the > server will detect that the same Message ID and Token are reused again an= d > then reject. >=20 > > > > -Ben > > > > > > > > > > > -----Message d'origine----- > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > Envoy=E9=A0: vendredi 15 f=E9vrier 2019 16:05 > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > channel@ietf.org; > > > > dots@ietf.org > > > > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of dra= ft- > ietf- > > > > dots-signal-channel) > > > > > > > > Hi Med, > > > > > > > > Short form: I need to think about it harder. There's some indicati= on > > that > > > > the CoAp Message ID is at the wrong level to protect the 0-RTT data= , > but > > > > I'm not sure yet. > > > > > > > > Sorry for the delays; this has been a frenetic couple weeks :( > > > > > > > > -Ben > > > > > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000, mohamed.boucadair@orange.= com > > wrote: > > > > > Hi Ben, > > > > > > > > > > What is the status for this one? Are we OK to move forward? > > > > > > > > > > Thank you. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > > > > > Envoy=E9=A0: mardi 29 janvier 2019 14:32 > > > > > > =C0=A0: Benjamin Kaduk > > > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > > channel@ietf.org; > > > > > > dots@ietf.org > > > > > > Objet=A0: Using Early Data in DOTS (RE: [Dots] AD review of dra= ft- > ietf- > > > > dots- > > > > > > signal-channel) > > > > > > > > > > > > Hi Ben, all, > > > > > > > > > > > > We edited a short draft (https://tools.ietf.org/html/draft- > boucadair- > > > > dots- > > > > > > earlydata-00) to motivate the following text included in the si= gnal > > > > channel > > > > > > draft: > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to imple= ment > > to > > > > > > limit the impact of replay attacks on 0-RTT data. If the > DOTS > > > > > > server accepts 0-RTT, it MUST implement one of these > > mechanisms. > > > > > > A DOTS server can reject 0-RTT by sending a TLS > > HelloRetryRequest. > > > > > > The DOTS signal channel messages sent as early data by th= e > DOTS > > > > > > client are idempotent requests. As a reminder, Message I= D > > > > > > (Section 3 of [RFC7252]) is changed each time a new CoAP > > request > > > > > > is sent, and the Token (Section 5.3.1 of [RFC7252]) is > > randomized > > > > > > in each CoAP request. The DOTS server(s) can use Message= ID > > and > > > > > > Token in the DOTS signal channel message to detect replay= of > > early > > > > > > data, and accept 0-RTT data at most once. Furthermore, '= mid' > > > > > > value is monotonically increased by the DOTS client for e= ach > > > > > > mitigation request, attackers replaying mitigation reques= ts > > with > > > > > > lower numeric 'mid' values and overlapping scopes with > > mitigation > > > > > > requests having higher numeric 'mid' values will be rejec= ted > > > > > > systematically by the DOTS server. > > > > > > > > > > > > Owing to the aforementioned protections, especially those > > afforded > > > > > > by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC = 8446 > > > > > > anti-replay mechanisms, all DOTS signal channel requests = are > > safe > > > > > > to transmit in TLS 1.3 as early data. Refer to > > > > > > [I-D.boucadair-dots-earlydata] for more details. > > > > > > > > > > > > This text and also the Designated Expert guidelines are impleme= nted > > in - > > > > 28. > > > > > > These are the two pending issues from your AD review. > > > > > > > > > > > > Other edits were also made to record what was agreed on the lis= t. > > > > > > > > > > > > We hope this version is now ready to move forward. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes t= hat > > > > > > "Application > > > > > > > > > > > protocols MUST NOT use 0-RTT data without a profile t= hat > > > > defines > > > > > > its > > > > > > > > use. > > > > > > > > > > > That profile needs to identify which messages or > > interactions > > > > are > > > > > > > safe > > > > > > > > to > > > > > > > > > > use > > > > > > > > > > > with 0-RTT and how to handle the situation when the > server > > > > rejects > > > > > > 0- > > > > > > > > RTT > > > > > > > > > > and > > > > > > > > > > > falls back to 1-RTT." So we either need to say which > > client > > > > > > requests > > > > > > > > are > > > > > > > > > > 0-RTT > > > > > > > > > > > safe (and why) or defer that profile to another docum= ent. > > > > draft- > > > > > > > ietf- > > > > > > > > > > dnsop- > > > > > > > > > > > session-signal is perhaps an example of a document th= at > > > > specifies > > > > > > > which > > > > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > > > > (draft-ietf-acme-acme is another, but an uninterestin= g > one, > > > > since > > > > > > > they > > > > > > > > make > > > > > > > > > > > every request include a single-use nonce, and all > messages > > are > > > > 0- > > > > > > RTT > > > > > > > > safe.) > > > > > > > > > > > Our use of increasing 'mid' values may help here, in > terms > > of > > > > > > > allowing > > > > > > > > > > DELETEs > > > > > > > > > > > to be safe, but I'd have to think a little more to be > sure > > that > > > > > > > > requesting > > > > > > > > > > > mitigation would be safe. (On first glance the sessi= on- > > > > managemnet > > > > > > > bits > > > > > > > > > > would > > > > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and > > DELETE), > > > > and > > > > > > CoAP > > > > > > > > is > > > > > > > > > > capable of detecting message duplication (see > > > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for bo= th > > > > confirmable > > > > > > > and > > > > > > > > > > non-confirmable messages. > > > > > > > > > > [1] An attacker replaying DELETE will not have any adv= erse > > > > impact, > > > > > > > 2.02 > > > > > > > > > > (Deleted) Response Code is returned even if the mitigat= ion > > > > request > > > > > > does > > > > > > > > not > > > > > > > > > > exist. > > > > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 sh= ould > > > > suffice > > > > > > to > > > > > > > > handle > > > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data > carrying > > an > > > > old > > > > > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to > > implement > > > > to > > > > > > > > > limit the impact of replay attacks on 0-RTT data. = If > the > > > > DOTS > > > > > > > > > server accepts 0-RTT, it MUST implement one of thes= e > > > > mechanisms From nobody Tue Feb 26 08:26:41 2019 Return-Path: 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 9A936128CB7 for ; Tue, 26 Feb 2019 08:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 p7d6Xabh4jnR for ; Tue, 26 Feb 2019 08:26:38 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 39BBE1200D8 for ; Tue, 26 Feb 2019 08:26:38 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1QGQbHT006309 for ; Tue, 26 Feb 2019 11:26:37 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x1QGQbHT006309 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1551198397; bh=7itvfyl5fdS5Ax77oAuAV+YHNc9VG3jLHOvK7n88v6c=; h=From:To:Subject:Date:From; b=tfDHDquWaLWQqqG9hzRejCkVQjS0sIXtvHaB6tZWqqaiRs77zt2pEQwswkZSVRZsO 2UbU8WazMIHIgFM0Dg6zg1e2twakhYS1DzdEST0WhXkOKFfYLPabJHNpVgu3sUka/t TbQkBgdUd++nWqPhgHEbGNeLaSO5vScSVyUbU8GY= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1QGQZXI026815 for ; Tue, 26 Feb 2019 11:26:35 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Tue, 26 Feb 2019 11:26:35 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Call for IETF 104 agenda items Thread-Index: AdTN78xk9P7U/UchQcGCKOHDvspV+A== Date: Tue, 26 Feb 2019 16:26:35 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857D9EB5@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Call for IETF 104 agenda items 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 16:26:39 -0000 Hello! DOTS has been tentatively scheduled for Thursday, March 28, 2019 from 1050-= 1220 per the draft agenda [1]. If you would like time on the agenda please= let the chairs know. Regards, Roman and Frank [1] https://datatracker.ietf.org/meeting/agenda/ From nobody Tue Feb 26 20:10:26 2019 Return-Path: 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 0684E130DF6; Tue, 26 Feb 2019 20:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 Eyoff6xcrZZt; Tue, 26 Feb 2019 20:10:20 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700114.outbound.protection.outlook.com [40.107.70.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06167130E13; Tue, 26 Feb 2019 20:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uc9GwOplDjAhl+kUZb1Dbyf0XlNziH9rxoxX2F7673s=; b=dVSXrVwx5nHJNirmtNv259qm3tZRlIlg6s1fhQp6ua2pJFfkKgtk6HcPhDWrWj92CN+rXg6ORbts7pBnsmpZGVtEKit9mVBn0M1ASHt0rbMVzi/H7xZ1ua/hfB5xuJltcdW7jq/TonjAKwtuBNYEfh2HSBNGjYpbQ5wqDcX8PZA= Received: from SN6PR0102CA0020.prod.exchangelabs.com (2603:10b6:805:1::33) by BN8PR01MB5604.prod.exchangelabs.com (2603:10b6:408:be::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Wed, 27 Feb 2019 04:10:16 +0000 Received: from DM3NAM03FT041.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::200) by SN6PR0102CA0020.outlook.office365.com (2603:10b6:805:1::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.15 via Frontend Transport; Wed, 27 Feb 2019 04:10:16 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT041.mail.protection.outlook.com (10.152.83.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 27 Feb 2019 04:10:15 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1R4ACem019740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Feb 2019 23:10:14 -0500 Date: Tue, 26 Feb 2019 22:10:12 -0600 From: Benjamin Kaduk To: CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190227041011.GG53396@kduck.mit.edu> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(396003)(2980300002)(51444003)(51914003)(199004)(189003)(52314003)(50466002)(53946003)(5660300002)(186003)(316002)(36906005)(106002)(966005)(786003)(2351001)(1076003)(55016002)(66574012)(47776003)(23756003)(356004)(2906002)(86362001)(75432002)(486006)(229853002)(8676002)(104016004)(26005)(6916009)(8936002)(54906003)(14444005)(93886005)(58126008)(26826003)(476003)(88552002)(426003)(11346002)(478600001)(126002)(106466001)(53416004)(446003)(956004)(6306002)(4326008)(76176011)(33656002)(7696005)(336012)(2870700001)(246002)(305945005)(30864003)(6246003)(18370500001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR01MB5604; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 53e5892b-83a1-4215-fe45-08d69c697ab0 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BN8PR01MB5604; X-MS-TrafficTypeDiagnostic: BN8PR01MB5604: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5604; 20:306Jqdt1MfyHcwTpTDFnypEhUYc1pyHosL67FaG7MaVkzPjcFX5qyJKDVpEd3nRdfHwY8dyZFg6jSV+288vMz3/NMsSOMhX5uR703A/WQa2sf0Q9TggLELgk3KylWzp/2b4DWFIYrv28C7ccf8NRnYH9DthxdR2nmhBsExi2ThMlvA/MGaEFwZefUnxsbKRtNlvQt1XD1KBjZwkihZ54Y3wvktkGMHYSFGsUXei8dgyDa8Vgtkkx88LJXxTZYbaC7lcClBX3uP0uklHSfcWMJu47QT7kI8Ebr2BcoK3/qGMfU5uWgw6xBIefIcIg6LuV7eLaRB1ZlrSS+6MpqQ2+UVUANLDWzv3/PgYojGkNygzj3AWYxoeyR1QI4aT1JaAafkch9HKyQ8+iLdho4OhxvDWaWbxmELhdX3VHiBLkZ56u4ddEFehC6jZflsxFmq6cnE+A3JX6a78fuNKtZFMXuDt37WpzwwDSwrxCxrHSqwLNYuGTGmVT8L2uzR6yFMLijtSjH1igTmDVPZGT5N/UHWT1X6xOv4jt7ImcKkzLvxWZB0e4MIzNslM64wxVB1gmD9CqUJKXCJx+Cd8iLkJhzQAgTZuZg3MVHZlBLuLRdNw= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN8PR01MB5604; 23:v0sckbUdcKjn5UFCWjVIFNztDW7kbNe2CkoEuJC?= =?iso-8859-1?Q?NAFz4Rl5BKO4izqDulY/QdpxSh6y60wyqWOnH0u0N48gGizh9L4XCm0hbr?= =?iso-8859-1?Q?ogBhVAzQT2dgxsw1dNOJS030EbWnr3LpZyntlr8U1XCzZjdIGc4M5Q36bI?= =?iso-8859-1?Q?4FC82gtkEXfdzGJbl2pD+GbMYLWdOvD0FBypWVl2jFb0AV0wWy0D/nFtMS?= =?iso-8859-1?Q?o5YUTxsmGEOPC9dOfrteLbQxfWltXJhhFp1r0v1PXIrjXqthgznb5Pwua+?= =?iso-8859-1?Q?LeJl0k1NFV55imw6Wy46e1IdiIOUktQTIwz412rgwf5rJTF55V+Zn/Puqq?= =?iso-8859-1?Q?HVJupDOHxgq6attdL+Hv8VzTIZLkiCw/nMUqH1QUDuPDEBp1uj2kGmwsGL?= =?iso-8859-1?Q?hA7B/1Kd7gc8NsSYkaIVoQNZboca8weQ27BEwrMxKvrGdaRUnVjAWfxo+9?= =?iso-8859-1?Q?kV/TTIyReO7Ai7GSOmYDA1hQkNvBGo7vVbcB44Ff4VzWLomKKXLVGMsJc3?= =?iso-8859-1?Q?P1tE6ZaExWvjCpYcw2JtET3ZJ2LseiqXwV/yeowl4RBVEexCz+ZzhkjJ12?= =?iso-8859-1?Q?ZGWUkgoK43zvKkjsvjfmdZiQ7AXyqhZAOMMN/gFlhuVY/W+XBviYZhK5hV?= =?iso-8859-1?Q?qXuXaGSAEHnDHa5Drn+A3SGB+/eRm9PnCdZObPHf/t1xEOIE4rrJ+bqnq9?= =?iso-8859-1?Q?YomgOYfOqiDidJBYBbjjRFZMnqbxhMHM/waeEOrDqSF7MiynBfk3JyBPuO?= =?iso-8859-1?Q?CmU4wqIwqrcoQMindRJ9M/QgNbN4NF1YsbHK6LJn2fcqvIdrd3j6QQvW/p?= =?iso-8859-1?Q?XdvjLIBQHIfCFSQQlFFUkcI4wEeiseOWykQIHuRYRIIdAA9YesEnft7awk?= =?iso-8859-1?Q?rpu3efMJKV+CffXM98gnDmx7N9f73lbj8nGs+CnGbnlSQx8KiDmFX6yVTH?= =?iso-8859-1?Q?EzqiuE4/iMN4Trif84n/64JvosNMfBp3fx7b+MuVuvjEH/S0vrGVQq8ndR?= =?iso-8859-1?Q?xKR2XOAScp78KgndV+R+f9mZm06my5NK3bh+5a6pD26Icf0Dtb9VRjP9I3?= =?iso-8859-1?Q?DUtEN0A4SCRjmf0PS9Ye8p00N6MxRAw3ap4cGP00/FdbNmaKza3RkX+gGt?= =?iso-8859-1?Q?dQtB0NNquvcUqkJzQDMKqbGgaHANI2QLFigImSA6gEjtrwgiYUsT8wTYXO?= =?iso-8859-1?Q?TmQTuojW4yNxBeXU+7+8jLGXj4AghknOzN8LneS54/JtaH/yg2qKtE051v?= =?iso-8859-1?Q?EWHIieQpeDhGpwcE01mpBN4u5ZfEMlG7K/KXqBC9zkA1kxFmLFUQgcunmm?= =?iso-8859-1?Q?eceR5nnFWse+sBa1DljSX38kC/+Hk2BqGIrhqk626HXwrPBEN98UVIiquM?= =?iso-8859-1?Q?LOCv/z9neTI7Ksbm3F8IZRk37vPZsVB+7FqG7qrZJbKj9k+Dz5NT7FeGfF?= =?iso-8859-1?Q?A5uTUkn9Soh6UU4wBw2lH2svFrnK0uHKQQo?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: dsIIyaeXmOUnATqslsraHFbX9p6IZJj0O3pXnUBPbLDUaawfiLfnGNCHJZ+oEQuq0VMbOU4ix0u+SYtOhVv87XS9Ng8WYW1a0CBmMGstCuO4efQVuLvI1H62Uca8R4bHUz4xHdIWPy1WTGmCfiFNPld2MvEy5Dsu04B3D/p7zLv77XgkE7MOtuCTPtyk33D+jmad37T0IMOqjzXBOciR66PFPY3hVy4zrGYvsKObdZsUc+RNKsMgcdLbdD5BFqi2j7HYF4BUdiKdsFVIMnCfnBOJlIe05/xi0JuCjTTHpc+vMtaXlWRXHjj+7/v3JO9SlsrocLA3r7z0GjVppBChSFZfhModVoUqxyvgbxoyNW22H5A6p8VVtyohg6OExQJNkpfT6CZE2/esyje2ruwS64r2jaFJvYzlnglFGdxTjIU= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2019 04:10:15.9719 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 53e5892b-83a1-4215-fe45-08d69c697ab0 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR01MB5604 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 04:10:24 -0000 On Fri, Feb 15, 2019 at 09:36:26AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Please see inline. > Thanks. The -27 is in good enough shape that I've requested the IETF last call; we can finish discussing the last few topics here in parallel. > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : jeudi 14 février 2019 20:17 > > À : BOUCADAIR Mohamed TGI/OLN > > Cc : draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > > Objet : Re: AD review of draft-ietf-dots-data-channel-25 > > > > Hi Med, > > > > On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.com wrote: > > > Hi Ben, > > > > > > Thank you for the review. > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > Envoyé : mercredi 13 février 2019 17:46 > > > > À : draft-ietf-dots-data-channel@ietf.org > > > > Cc : dots@ietf.org > > > > Objet : AD review of draft-ietf-dots-data-channel-25 > > > > > > > > This is my AD review of the -25 > > > > > > > > I see that Med made a commit on github that preemptively addressed at > > least > > > > one of these comments, but will trust the authors to do to the right > > thing > > > > with anything in here that's stale. > > > > > > > > A handful of generic and/or high-level comments before the > > > > section-by-section nitty-gritty stuff. > > > > > > > > The author count is large (7); RFC 7322 notes that the stream approver > > > > (i.e., the IESG) will ask questions if the count is more than five. What > > > > should I tell people when they ask? (The authors are listed also in the > > > > YANG module itself, if changes are made.) > > > > > > [Med] Actually, the set of co-authors of the YANG module is not exactly the > > same. > > > > Whoops, my bad for not checking. > > > > > Anyway, in order to comply with the rules and avoid spending extra cycles > > on this, we added a new section called "Contributing Authors". Nevertheless, > > the set of authors is not modified in the YANG module. > > > > Thanks. (To be clear, I'm happy to go to bat for everyone with the IESG > > for this sort of thing, I just need an argument to present that's not me > > making things up.) > > > > I don't know of a specific policy for YANG module authorship, so that part > > should be okay as far as I know. > > > > > > > > > > Can someone (the shepherd?) confirm that an automated syntax checker has > > > > run over the JSON in examples? > > > > > > > > The concept of "DOTS client domain" is being used for actual protocol > > > > purposes here (most notably as a bound on the prefix(es) that a client > > can > > > > request mitigation for, but I don't remember seeing a formal definition > > for > > > > how any DOTS actor would know the specific bounds of such a client > > domain. > > > > Is there text somewhere that I missed that we can point to, or will we > > need > > > > to add some? > > > > > > [Med] Both "DOTS client domain" and "DOTS server domain" are used in the > > architecture draft. "DOTS client's domain" and "DOTS server's domain" are > > also used in the architecture and requirements I-D. > > > > > > If a formal definition is needed, I prefer this to be done in the > > architecture or the requirements I-D. > > > > I think it would be a somewhat better fit in the architecture document, > > just to note that the "domain" is something that can concretely be > > demarcated by IP addresses/prefixes (as opposed to a more nebulous concept > > to aid conceptual understanding). > > > > [Med] Let's add that text into the architecture I-D. Okay. Tiru had a follow-up about how servers can identify DOTS client's domains, which is okay but not quite what I was aiming for. In the text Tiru quoted, we note that The DOTS server enforces authorization of DOTS clients' signals for mitigation. The mechanism of enforcement is not in scope for this document, but is expected to restrict requested mitigation scope to addresses, prefixes, and/or services owned by the DOTS client's administrative domain, such that a DOTS client from one domain is not able to influence the network path to another domain. I was hoping to see something like "For a given client (administrative) domain, the DOTS server needs to be able to determine whether a given resource is in that domain. This could take the form of associating a set of IP Prefixes per domain, for example." But I'm open to being persuaded that the existing text conveys the same meaning. > > > > > > > > We don't say much about what validation the server does on input data, > > and > > > > we probably should. For example, does the server need to validate 'cuid' > > > > > > [Med] We avoided to be redundant here. This is covered by this text: > > > > > > "This attribute has the same > > > meaning, syntax, and processing rules as the 'cuid' attribute > > > defined in [I-D.ietf-dots-signal-channel]." > > > > > > > and/or 'cdid' in dots-client-creation requests? > > > > > > [Med] This is covered by this text: > > > > > > "This attribute has the same meaning, syntax, and processing > > > rules as the 'cdid' attribute defined in > > > [I-D.ietf-dots-signal-channel]" > > > > I guess I'm mostly just concerned about if there's anything that doesn't > > translate directly, since the CoAP and HTTP constructs would have to > > describe the formal validation in somewhat different terms (i.e., for > > consistency between URL paths and message bodies). But in general I'm > > happy to avoid redundancy as you desire. > > > > > And other parts in the text such as: > > > > > > If the request is received via a server-domain DOTS gateway, but the > > > DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' > > > is expected to be supplied, the DOTS server MUST reply with "403 > > > Forbidden" status-line and the error-tag "access-denied". Upon > > > receipt of this message, the DOTS client MUST register (Section 5). > > > > > > > > > What about validating that > > > > the (e.g.) ACL name in the PUT URL matching the name in the body of the > > > > request? > > > > > > [Med] Those are supposed to be covered following RESTCONF base spec. > > > > Is this supposed to be RFC 8040 Section 3.5.3? I am not sure that I'm > > reading that as covering the property I want (and will double-check if you > > confirm that's what you have in mind). > > > > [Med] In addition to 3.5.3, Section 4.5 specifies the rules for PUT. > > The main point is that the validation you mentioned is not specific to DOTS but are governed by RESTCONF procedures. I only see 3.5.3 as talking about how to construct a request URI for a given data node in the YANG tree. What I'm wondering about for the data-channel document is if there are cases where a given path component of the YANG module appears both in the request URI and in the data in the request body. If so, it seems that the server will need to verify that the redundant data agree, and I still don't see where this is mandated by RFC 8040. (Sorry if I am being dense.) > > > There are probably others as well. > > > > > > > > The examples all use "Host: {host}:{port}" which is not really an example > > > > but rather a template. Since they are supposed to be examples, we should > > > > pick a concrete hostname (and port) to use. > > > > > > [Med] I will change some figures to "example.com" but will leave it for > > schema-like figures. > > > > Of course. > > > > > > > > > > There is, shall we say, a "high degree of overlap" between Sections 5/6/7 > > > > and the YANG model field descriptions. I mostly assume that the WG > > > > considered letting the YANG model (and the core RESTCONF spec) stand > > alone > > > > without the additional examples/specification of the use of RESTCONF to > > > > manage clients, aliases, and filter rules, so I won't suggest that we > > > > revisit the question. But I do think that it would be good to have some > > > > explicit text acknowledging the overlap and stating which one is > > > > authoritative. > > > > > > [Med] Fixed. > > > > > > > > > > > There seems to be some mismatch between whether the IPv6 ACL subtree uses > > > > "ttl" or "hoplimit" -- Figure 7 has "ttl" but the rest of the document > > > > seems to (properly) use "hoplimit". Someone else should double-check the > > > > relevant places, though, as I'm not sure I was looking at all of them > > with > > > > this issue in mind. > > > > > > [Med] Both are correct. > > > > > > Figure 7 reuses draft-ietf-netmod-acl-model which defines TTL as : > > > > > > leaf ttl { > > > type uint8; > > > description > > > "This field indicates the maximum time the datagram is allowed > > > to remain in the internet system. If this field contains the > > > value zero, then the datagram must be dropped. > > > > > > In IPv6, this field is known as the Hop Limit."; > > > reference > > > "RFC 791: Internet Protocol, > > > RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; > > > } > > > > > > For the other figures, the fields are defined in the data-channel draft. > > > > Ah, thanks for the pointer. > > > > > > > > > > I'm also a bit curious about the use of an explicit "capabilities" tree > > for > > > > fine-grained feature detection, as opposed to native YANG "feature"s. > > > > > > [Med] These are not serving the same purpose. Features are about parts of a > > module which are conditional, if you will. Our "capabilities" branch is meant > > to retrieve the filtering match capabilities are supported/enabled by a DOTS > > server. That information is used by a client to tweak its requests. > > > > > > The > > > > latter would allow the relevant nodes to just not exist when unsupported, > > > > > > [Med] A filtering capability may be supported but not enabled. The server > > is free to include an explicit field with the appropriate status or not. This > > is implementation-specific. > > > > Thanks for the explanation. > > > > > > as opposed to the explicit-capabilities formulation where they exist but > > > > are (presumably) ignored. (I don't remember us explictily saying that > > > > they're ignored in this case, either; might be worth adding some text.) > > > > > > > > In a similar vein, we include 'capabilities' nodes for a few matching > > > > features that are listed as "mandatory fields" for ACL matching in Table > > 1, > > > > and thus whose value would always be "true". Why do we need the > > capability > > > > leaves in such a case? > > > > > > [Med] I guess you are referring to Figure 23 which says the following: > > > > > > Figure 23 shows an example of a response received from a DOTS server > > > which only supports the mandatory filtering criteria listed in > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Section 4.1. > > > > Correct. > > > > > The module allows to return other capabilities than those listed in table > > 1. > > > > Yes. But the figure should not claim to be an example that *only* supports > > the mandatory parts, when it shows an example that supports additional > > capabilities than the mandatory ones. > > > > [Med] Which "additional capabilities" are you referring to? (The text in the -27 addresses my complaint here, even if I was confused about filtering criteria vs. actions.) > > > > > > > > > idnits notes a few references that can be updated along with the other > > > > changes; it also flags a "reference in abstract" for the RFC Editor note > > > > which we could probably ignore (but could probably also just remove the > > > > brackets around the text in question). > > > > > > [Med] idnits confuses the note to the RFC editor with the abstract. Fixed, > > anyway. > > > > > > > > > > > I also looked at the references (especially the normative/informative > > > > split) and have a few suggestions: > > > > > > > > - the IEEE.754.1985 reference is not needed; > > > > > > [Med] Agree, but it is not harmful to cite it either :-) > > > > My personal opinion is that it *is* harmful, since we are not using a > > floating-point wire encoding; we're using a string encoding. > > [Med] I removed the ref, but added a sentence to justify the unit we are using: mainly to align with traffic-rate in 5575. OK > > > > > The reference is quoted to justify why we went with decimal64, not uint64 > > for example + why that unit is chosen. This allows to ease grafting DOTS with > > BGP Flowspec for instance, which cites IEEE.754.1985 too. > > > > (RFC 5575 seems to claim to be using the actual binary floating-point > > encoding.) > > > > > we don't use the binary > > > > floating-point encoding but rather a string one for YANG decimal64 > > > > - I think that RFC 8499 (dnsop-terminology-bis) can wholly supersede our > > > > usage of RFC 1983, so the 1983 cite can be dropped as well > > > > > > [Med] Done. > > > > > > > - draft-ietf-dots-requirements (for terminology), > > > > > > [Med] For this one, we are following the same approach as for other > > terminology documents (e.g., RFC8340) that are listed as informative. I > > prefer to leave it as informative for now. > > > > Okay, we can see if anyone else complains. > > > > > RFC 7950, and RFC 8259 > > > > > > [Med] OK for these two. > > > > > > > should probably all move to the normative section > > > > > > > > Section 1 > > > > > > > > The sub-bullet point about "If a network resource ... informs its > > servicing > > > > DOTS gateway of all suspect IP addresses that need to be drop- or > > > > accept-listed ..." made me wonder if that was more of a signal-channel > > > > activity or a data-channel one. Perhaps this is just a matter of the > > text > > > > not being as clear as it could be. > > > > > > [Med] The point is that a client is not sure that an attack is active and > > targeting the client domain but it wants to enforce some preventive actions > > during an investigation period. For example, this can be triggered by an > > administrator who is informed that an attack is currently targeting other > > networks, but its network is likely to be subject to that attack too. Other > > preventive actions which require further investigation may be considered. > > > > > > I changed the text as follows: > > > > > > OLD: > > > detects a potential DDoS attack from > > > > > > NEW > > > is informed about a potential DDoS attack from > > > > > > (I also wonder if we should say > > > > "further investigation" since we don't really have an automated way to > > > > indicate that yet.) > > > > On further reflection, would "further manual investigation" be appropriate? > > [Med] No assumption is made how that investigation is made. I prefer to leave the text as it. OK > > > > > > Section 2 > > > > > > > > When we talk about tree diagrams, should we also say something like "Note > > > > that the full module's tree has been split across several figures to aid > > > > the exposition of the various sub-trees"? > > > > > > [Med] Done. Thanks. > > > > > > > > > > > Section 3.1 > > > > > > > > When we talk about using GET to retrieve running configuration, do we > > want > > > > to note that since the data channel can fail during attack time, it's > > > > expected to be common to perform such a GET before attempting to make > > > > modifications to configuration? > > > > > > [Med] The data channel is supposed to be invoked when no attack is ongoing. > > Normal RESTCONF operations are therefore followed. I don't see the need to > > add a note. > > > > I always have to consider edge cases in my IESG reviews -- what happens if > > an attack starts after the request is sent but before the response is > > received? > > [Med] The dots client will know if its request is successfully delivered. When an attack is ongoing, the dots client should not use it data channel because it is likely to be perturbed. (There was some further discussion with Med and Tiru but I seem to have lost track of the resolution.) > > > > > > > > > > A DOTS client registers itself to its DOTS server(s) in order to set > > > > up DOTS data channel-related configuration data and receive state > > > > data (i.e., non-configuration data) from the DOTS server(s) > > > > (Section 5). Mutual authentication and coupling of signal and data > > > > channels are specified in [I-D.ietf-dots-signal-channel]. > > > > > > > > I think we should split the "mutual authentication" and "coupling of > > signal > > > > and data channels" into their own sentence, and flesh them out slightly > > > > more. So, section references to Sections 8 and 4.4.1, respectively, the > > > > usage of TLS client certificates, the coupling of channels via the > > client's > > > > identity ('cuid' and 'cdid'), etc. > > > > > > [Med] Done. > > > > > > > > > > > A TLS heartbeat [RFC6520] verifies > > > > that the DOTS server still has TLS state by returning a TLS message. > > > > > > > > I expect this will get some pointed comments during IETF LC, given the > > > > recent-ish IETF-wide discussions about heartbeats/keepalives in general. > > > > Is there perhaps a RESTCONF-level probe message that could be used to > > check > > > > liveliness; a capabilities query perhaps? > > > > > > [Med] There is no such mechanism. The approach in the data channel draft is > > aligned with RFC8071 for keepalives. > > > > I guess we'll just have to wait to see what kind of comments we get, then. > > (Thanks for the pointer to 8071.) > > > > > > > > > > A DOTS server may detect conflicting filtering requests from distinct > > > > DOTS clients which belong to the same domain. For example, a DOTS > > > > client could request to drop-list a prefix by specifying the source > > > > prefix, while another DOTS client could request to accept-list that > > > > same source prefix, but both having the same destination prefix. It > > > > is out of scope of this specification to recommend the behavior to > > > > follow for handling conflicting requests (e.g., reject all, reject > > > > the new request, notify an administrator for validation). DOTS > > > > servers SHOULD support a configuration parameter to indicate the > > > > behavior to follow when a conflict is detected. Section 7.2 > > > > specifies the behavior when no instruction is supplied to a DOTS > > > > server. > > > > > > > > I'm a bit confused by the "out of scope of this specification to > > recommend > > > > the behavior to follow for handling conflicting requests", since not only > > > > does the last sentence of the paragraph give a pointer to a specified > > > > behavior in case of conflicts, but we also mention it in a couple other > > > > places (e.g., the bottom of page 43). > > > > > > [Med] The specified behavior is a default behavior, not a recommended one. > > > > In effect a default is a recommendation, though -- a recommendation for > > what to do if you don't know any better. Perhaps "it is out of scope of > > this specification to provide guidance on how conflicting requests may be > > safely handled, with the default behavior being to reject such requests"? > > [Med] I went for this updated text: > > DOTS servers SHOULD support a configuration parameter to indicate the > behavior to follow when a conflict is detected (e.g., reject all, > reject the new request, notify an administrator for validation). > Section 7.2 specifies a default behavior when no instruction is > supplied to a DOTS server. Works for me. > > > > > I update this text: > > > > > > If the request is conflicting with an existing filtering installed by > > > another DOTS client of the domain, and absent any local policy, the > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > That helps (maybe the "and" is not even needed?). Do you want to do a > > sweep for other places where the text talks about 409 responses? > > [Med] OK. > > > > > > DOTS server returns "409 Conflict" status-line to the requesting DOTS > > > client. The error-tag "resource-denied" is used in this case. > > > > > > > > > > > Also in that paragraph, it's unclear that a 2119 SHOULD is appropriate > > for > > > > "support a configuration parameter"; there's no interoperability > > > > considerations for having or not having such a configuration knob. > > > > > > [Med] This is important for interoperability (or at least for ensuring a > > deterministic behavior). E.g., during service subscription a technical clause > > may be negotiated out of band how to deal with conflicts from clients of the > > same domain. > > > > It seems that the default behavior of disallowing conflicts would always be > > interoperable, but I'm happy to leave this as-is for now. > > > > > > > > > > Section 3.3 NAT Considerations have "high overlap" with the > > > > text at the end of the signal-channel's "Design Overview". At a minimum > > we > > > > should diff them and enforce convergence, but do we want to consider just > > > > having one refer to the other? > > > > > > [Med] Makes sense. Section 3.3 is now deleted and replaced with this NEW > > text: > > > > > > NAT considerations for the DOTS data channel are similar to those > > > discussed in Section 3 of [I-D.ietf-dots-signal-channel]. > > > > Cool, thanks. > > > > > > > > > > Section 3.5 > > > > > > > > I had to read up on RESTCONF and NETCONF while reviewing this, but from > > > > what I've seen so far, the "error-severity" field is only present in > > > > NETCONF and not RESTCONF. If so, then we shouldn't need to talk about it > > > > here, since we use RESTCONF exclusively. I also couldn't find whether > > > > there's a registry that we should add the "loop-detected" error-tag to. > > > > Can anyone here help me out? > > > > > > > > > > [Med] We used the template in https://tools.ietf.org/html/rfc6241#appendix- > > A because the errors in 8040 are the ones imported from there. > > > > Thanks for the pointer. It sounds like I'll need to ask around about this > > one. > > [Med] I checked this with Martin Bjorklund. He confirmed that the error list in 6241 is fixed in the protocol version. He recommended to go with app-tags. Our error will look like the following: > > OLD: > error-tag: loop-detected > error-type: transport, application > error-severity: error > error-info: : A copy of the Via header when > the loop was detected. > Description: An infinite loop has been detected when forwarding > a requests via a proxy. > > NEW: > > error-app-tag: loop-detected > error-tag: operation-failed > error-type: transport, application > error-severity: error > error-info: : A copy of the Via header when > the loop was detected. > Description: An infinite loop has been detected when forwarding > a requests via a proxy. Thanks! I will try to remember to solicit a YANG doctors review during IETF LC if it does not get scheduled automagically. > > > > > There is no registry for the errors; only a YANG module which is not > > maintained by IANA. This is why no action is included in the IANA section. > > > > > > > Section 4.2 > > > > > > > > Is there any plan/expectation for filtering/match rules for QUIC? It is > > > > probably premature to put anything in this document specifically, but > > still > > > > worth thinking about. > > > > > > [Med] Some of the existing fields can be already reused for QUIC (UDP, port > > number). There are few fields in the QUIC public header that are available > > (public flags, CID, version). A match on the first N bytes of the UDP payload > > can be considered but I do think this is not mature enough. > > > > > > The key point is that our module is extensible. > > > > Indeed. > > > > > > > > > > The order in which the leaves appear in the "capabilities/ipv6" and > > > > "capabilities/tcp" subtrees do not match the order they appear in the ACL > > > > subtree itself; it would be good to keep the order consistent. > > > > > > [Med] Fixed. > > > > > > FWIW, the order in capabilities/* follows the order of the fields as they > > appear in the header. We don't have a control on the ACL order because we are > > reusing an external module. > > > > Ah, good to know. > > > > > > > > > > We don't really say much about what the semantis of the "port-range" > > > > capabilities are; is that supposed to indicate any port-matching ability > > at > > > > all, or specifically the low-to-high range matching, or also the > > "operator" > > > > options? > > > > > > [Med] Updated as follows: > > > > > > OLD: > > > "Support of filtering based on a port range."; > > > > > > NEW: > > > > > > "Support of filtering based on a port range. > > > > > > This includes filtering based on a source port range, > > > destination port range, or both. All operators > > > (i.e, less than or equal, greater than or equal, equal to, > > > and not equal to) are supported."; > > > > Thanks! > > > > > > > > > > Section 4.3 > > > > > > > > We define an "operator" typedef that is rather different from that from > > > > netmod-acl-model. Do we want to use a different name to aid > > > > disambiguation? ("bitmask-operator" comes to mind as an option.) > > > > > > [Med] It is not recommended in yang to use prefixes to disambiguate nodes. > > The disambiguation is ensured by the context/position in the tree. For > > example, this is why we are using name and not acl-name or ace-name, etc. I > > will leave the text as it is. > > > > For names this makes natural sense to me, but this question is about a > > typedef. I have less clear of a picture for how typedefs are or are not > > namespaced (is it just per-module?). > > > > [Med] They are namespaced. For example: > > type operator; > > is about the operator defined in the module itself. But, if we use: > > type packet-fields:operator; > > this means the operator is the one imported from ietf-packet-fields. Ah, thanks for the YANG lesson. > > > > > > > > > typedef fragment-type { > > > > type bits { > > > > bit df { > > > > position 0; > > > > description > > > > "Don't fragment bit for IPv4. > > > > This bit must be set to 0 for IPv6."; > > > > > > > > Set to zero by whom? What should the receiver do if it is set otherwise? > > > > > > > > > > [Med] In IPv6, fragmentation is only done by the source. Hence, this value > > for IPv6. A fragment-type with the first bit set will be discarded by the > > server. > > > > I was looking for a few more words in the text, like "must be set to 0 when > > it appears in an IPv6 filter". > > [Med] OK. > > > > > > > What are the semantics if (either or both of target-fqdn and target-uri) > > > > and target-prefix are specified? (I suppose maybe this could be covered > > in > > > > Section 6.1 when we say that at least one is required in ACL-creation > > > > requests.) > > > > > > [Med] The resulting IP prefixes/addresses will be bound to the alias. Added > > the following in Section 6.1: > > > > > > If more target-* clauses (e.g., 'target-prefix' and 'target-fqdn') > > > are included in a POST or PUT request, the DOTS server binds all > > > resulting IP addresses/prefixes to the same resource. > > > > > > > > > > > The units for the "rate-limit" node should be specified in the YANG > > module > > > > and not in the description of how to install filtering rules. > > > > > > [Med] Added "units" to the YANG module. > > > > > > > > > > > list dots-client { > > > > key "cuid"; > > > > description > > > > "List of DOTS clients."; > > > > leaf cuid { > > > > type string; > > > > description > > > > "A unique identifier that is randomly generated by > > > > a DOTS client to prevent request collisions."; > > > > > > > > I don't think "randomly generated" is really correct here. > > > > > > [Med] Changed to: > > > > > > "A unique identifier that is generated by a DOTS client > > > to prevent request collisions."; > > > > > > > > > > > The "capabilities/icmp/rest-of-header" description should be more clear > > > > that (per draft-ietf-netmod-acl-model) it is supposed to match both the > > > > ICMP four-byte field and the ICMPv6 message body. > > > > > > [Med] OK. > > > > > > > > > > > Section 5.1 > > > > > > > > It may be worth reiterating that (per the signal-channel doc) gateways > > may > > > > rewrite the 'cuid'. > > > > > > [Med] OK: > > > > > > As a reminder, DOTS gateways may rewrite the 'cuid' used by peer DOTS > > > clients (Section 4.4.1 of [I-D.ietf-dots-signal-channel]). > > > > > > > > > > > When POST is used to create a dots-client resource, how does the client > > > > know the path of the created resource (to be used for subsequent RESTCONF > > > > requests)? (I assume it is supposed to just use the submitted 'cuid', > > but > > > > we need to explicitly say this. This also seems to render much of the > > > > distinction between POST and PUT moot, for our usage, though I do not > > > > propose any change to the text.) > > > > > > [Med] The procedure to determine the root path is recalled in Section 3.1, > > then normal RESTCONF operation is followed. > > > > > > > > > > > The DOTS gateway, that inserted a 'cdid' in a PUT request, MUST strip > > > > the 'cdid' parameter in the corresponding response before forwarding > > > > the response to the DOTS client. > > > > > > > > Why does this apply only to PUT and not POST? > > > > > > [Med] Because RFC8040 says the following: > > > > > > If the POST method succeeds, a "201 Created" status-line is returned > > > and there is no response message-body. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Whoops, I clearly missed that part. Thanks for calling it out. > > > > > > > > > > Section 6.1 > > > > > > > > DOTS clients within the same domain can create different aliases for > > > > the same resource. > > > > > > > > My reading of this text is that client A can create alias "foo" for IP > > > > prefix 128.0.1.5/31 and clinet B can create alias "bar" for the same IP > > > > prefix, and that DOTS supports that process. (Just to confirm that the > > > > text is saying what it's intended to.) > > > > > > [Med] Yes. > > > > > > I do wonder if we want to say > > > > something about whether alias names need only be unique per 'cuid' or in > > > > some more global fashion. (Having a global uniqueness property is > > perhaps > > > > convenient in order to interface with non-DOTS mechanisms for querying > > > > aliases, or for the DOTS server to interact with network filtering > > > > appliances.) > > > > > > [Med] The specification does require uniqueness per cuid: > > > > > > | +--rw aliases > > > | | +--rw alias* [name] > > > | | +--rw name string > > > > > > We don't have a requirement for uniqueness per domain or globally. > > > > > > If such requirement arise, the semantic/logic for creating those aliases > > can be handled out of band. > > > > Ok. > > > > > > > > > > Figure 16 puts double-quotes around "string" in the pseudo-schema, which > > > > feels weird to me. > > > > > > [Med] This is also what we have done for other figures , e.g., 11. The > > intent is to use a scheme-like message body while trying to preserve JSON > > compliance. > > > > > > > > > > > target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An > > > > FQDN is the full name of a resource, rather than just its > > > > hostname. For example, "venera" is a hostname, and > > > > "venera.isi.edu" is an FQDN [RFC1983]. Refer to > > > > [I-D.ietf-dnsop-terminology-bis] for more details. > > > > > > > > I don't think this text is particularly well-aligned with RFC 8499 and > > > > would suggest trimming it substantially and just pointing to that RFC. > > > > > > [Med] Done. > > > > > > > > > > > If the request is missing a mandatory attribute or its contains an > > > > invalid or unknown parameter, "400 Bad Request" status-line MUST be > > > > returned by the DOTS server. The error-tag is set to "missing- > > > > attribute", "invalid-value", or "unknown-element" as a function of > > > > the encountered error. > > > > > > > > This text seems to preclude any future extension that adds new error > > tags; > > > > is this intended? > > > > > > [Med] Those errors are only about the tree failure cases called in the > > first sentence. > > > > > > > > > > > Section 7.1 > > > > > > > > A DOTS client which issued a GET request to retrieve the filtering > > > > capabilities supported by its DOTS server, SHOULD NOT request for > > > > filtering actions that are not supported by that DOTS server. > > > > > > > > What is the server behavior if the client ignores this SHOULD NOT? > > > > > > [Med] This is covered by this text: > > > > > > If the request is missing a mandatory attribute or > > > contains an invalid or unknown parameter (e.g., a match field not > > > supported by the DOTS server), "400 Bad Request" status-line MUST be > > > returned by the DOTS server in the response. > > > > sounds good. > > > > > > > > > > Figure 23 shows an example of a response received from a DOTS server > > > > which only supports the mandatory filtering criteria listed in > > > > Section 4.1. > > > > > > > > This seems inaccurate, as the mandatory filtering criteria exlude the > > > > rate-limit among others. > > > > > > [Med] rate-limit is an action, not a filtering criteria. > > > > > > > > > > > Section 7.2 > > > > > > > > activation-type: Indicates whether an ACL has to be activated > > > > (immediately or during mitigation time) or instantiated without > > > > being activated (deactivated). Deactivated ACLs can be activated > > > > using a variety of means such as manual configuration on a DOTS > > > > server or using the DOTS data channel. > > > > > > > > Is this done by the data channel or the signal channel? > > > > > > [Med] Yes, but this is not supported in the base signal-channel spec. This > > is the done using the filtering control feature (draft-nishizuka-dots-signal- > > control-filtering). This is why signal channel is not listed after "such as". > > > > Okay. (I was literally just wondering if this was a typo.) > > > > > > > > > > If this attribute is not provided, the DOTS server MUST use > > > > 'activate-when-mitigating' as default value. > > > > > > > > Why do we specify default values here instead of in the YANG module? > > > > > > [Med] There is no default statement for enumeration. To solve this, a new > > type is defined in the module (activation-type). This type is then used for > > the activation-type leaf with a default value set to activate-when- > > mitigating. > > > > That's a clever workaround! > > > > > The change in tree diagram is (no need to insert the code here): > > > > > > OLD: > > > | +--rw activation-type? Enumeration > > > > > > NEW: > > > | +--rw activation-type? activation-type > > > > > > > > > > > > > > Filters that are activated only when a mitigation is in progress > > > > MUST be bound to the DOTS client which created the filtering rule. > > > > > > > > Other filters do not need to be bound to the DOTS client that created > > them? > > > > > > [Med] They are...but those filters are already enforced because they are > > immediate. > > > > The wording here is still weird, though -- by calling out the > > delayed-activation filters it implies that immediate-activation filters are > > excluded from the statement, but we know that immediate-activation filters > > also have the same property. So I'm not entirely sure exactly what > > information this sentence is intended to call out. > > [Med] When a mitigation is in progress, only the filters bound to the client which triggered the mitigation have to be activated. 'activate-when-mitigating' filters of other clients of the same domain should not be activated: > > I changed the text as follows: > > OLD: > Filters that are activated only when a mitigation is in progress > MUST be bound to the DOTS client which created the filtering rule. > > NEW: > When a mitigation is in progress, the DOTS server MUST only > activate 'activate-when-mitigating' filters that are bound to the > DOTS client which triggered the mitigation. That looks great; thanks. -Ben > > > > > > Wouldn't we still want to remove them when the dots-client resource in > > > > question is deleted? > > > > > > [Med] This is supposed to be done by the client itself. For amnesiac > > clients, we do have the following: > > > > Oh. I think I was remembering Section 5.2's "resources bound to this DOTS > > client will be deleted by the DOTS server" and assuming it applies to the > > filters associated with that client. > > > > > In order to avoid stale entries, a lifetime is associated with alias > > > and filtering entries created by DOTS clients. Also, DOTS servers > > > may track the inactivity timeout of DOTS clients to detect stale > > > entries. > > > > This is probably enough to ensure safe operation without the above, though, > > hmm... > > > > > > > > > > destination-ipv4-network: The destination IPv4 prefix. DOTS servers > > > > [...] > > > > This is a mandatory attribute in requests with an 'activation- > > > > type' set to 'immediate'. > > > > > > > > I somehow thought there were YANG attributes that could indicate this > > > > conditional requirement in the module itself, though I am hardly a YANG > > > > expert. > > > > > > [Med] We are reusing fields from ietf-netmod-acl, it is not easy to > > manipulate the fields as we would want. > > > > Okay. > > > > > > > > > > The error-tag is set to > > > > "missing-attribute", "invalid-value", or "unknown-element" as a > > > > function of the encountered error. > > > > > > > > Same comment as above about (non-)extensibility. > > > > > > [Med] Idem as above. > > > > > > > > > > > Section 7.3 > > > > > > > > I see that the "test-acl-*" and "test-ace-*" acl and ace objects in these > > > > examples do in fact use different names for the semantically different > > > > objects, but perhaps we could help the reader's eye and use strings with > > a > > > > larger Hamming distance? (I thought they were all the same on my first > > > > read.) > > > > > > [Med] Fixed. > > > > > > > > > > > (I also am a little confused at why the "ace" "name" field is considered > > a > > > > non-config field, in Figure 31, but this seems more likely to be my > > > > confusion than an error in the document.) > > > > > > [Med] This is because the name is the key of the ace list. > > > > > > RFC8040 says the following: > > > > > > To retrieve only the non-configuration child resources, the "content" > > > parameter is set to "nonconfig". Note that configuration ancestors > > > (if any) and list key leafs (if any) are also returned. > > > > Thanks for the pointer. > > > > > > > > > > Section 8 > > > > > > > > o DOTS server MUST NOT enable both DOTS data channel and direct > > > > configuration to avoid race conditions and inconsistent > > > > configurations arising from simultaneous updates from multiple > > > > sources. > > > > > > > > o DOTS agents SHOULD enable DOTS data channel to configure aliases > > > > and ACLs, and only use direct configuration as a stop-gap > > > > mechanism to test DOTS signal channel with aliases and ACLs. > > > > Further, direct configuration SHOULD only be used when the on-path > > > > DOTS agents are within the same domain. > > > > > > > > Doesn't all this discussion of "direct configuration" conflict with the > > > > "MUST NOT" in the first bullet point? > > > > > > [Med] The second bullet is about controlled testing of the *signal channel* > > with aliases/acls communicated by the data channel. > > > > Whoops, my misread. > > > > > > > > > > Section 10 > > > > > > > > Generally with the security considerations template for YANG modules, we > > > > need to list out all the nodes considered sensitive and the consequences > > of > > > > writing(/reading) each one in turn. > > > > > > > > > > [Med] The text does already call out those that are specific to this > > document. For other nodes, we do have this text: > > > > > > "YANG ACL-specific security > > > considerations are discussed in [I-D.ietf-netmod-acl-model]." > > > > > > I think we are OK. > > > > I would suggest adding a new sentence in the "All data nodes defined" > > paragraph about "This module reuses YANG structures from > > [I-D.ietf-netmod-acl-model], and the security considerations for those > > nodes continue to apply for this usage.", since that text is at the other > > end of the section and it's otherwise hard to make a linkage between them. > > > > [Med] OK. > > > Thanks, > > > > Ben From nobody Tue Feb 26 22:59:25 2019 Return-Path: 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 7D0F212F19D; Tue, 26 Feb 2019 22:59:23 -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 2sEFA9MYRv6N; Tue, 26 Feb 2019 22:59:21 -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 39ABA128B01; Tue, 26 Feb 2019 22:59:21 -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=1551250606; 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=t8L2OIhu8zdbGJjwkTeQP6sxpZ4DcILyp51JIH f3zLM=; b=AhOMAn+zZ7gkVVD8CYV/5zaEQzdjafRmX6MZddm/ VglW1hcM5TEEZYnQwt5+KpLKc/VWY1I1Sn84p5IDSfCYo5Zmch /pEkBcOSfNCtFg7dCVesdDgVCpjCHQ3zLu3yNnCXkxTywEzrlY wELkiKZA1tAr39fYAyuZkNmUpjgU5zI= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6336_433e_40e96c58_341c_4094_8aaa_84e9a8d606df; Tue, 26 Feb 2019 23:56:46 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 23:59:10 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 26 Feb 2019 23:59:09 -0700 Received: from NAM01-SN1-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; Tue, 26 Feb 2019 23:59:08 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2934.namprd16.prod.outlook.com (20.178.235.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.21; Wed, 27 Feb 2019 06:59:07 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1643.022; Wed, 27 Feb 2019 06:59:07 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Benjamin Kaduk" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxRIUo475NEhnvke5Q68IH00fwKXgsiOQgAAV9gCAEoE9oA== Date: Wed, 27 Feb 2019 06:59:07 +0000 Message-ID: References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA1FEC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA1FEC0@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59e8e7db-24a4-4eaf-b61e-08d69c811136 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2934; x-ms-traffictypediagnostic: BYAPR16MB2934: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyOTM0OzIzOmRLYjBBdzcrUUcza2pkd25vaVpLb2drL3lU?= =?utf-8?B?UzkySTVMZzdrUS9NR3RtUEp0Ym9ZV0FYa3lJSHRPSVVEUmJQMjNzbGtURUxw?= =?utf-8?B?eFpnU0hiU2M2UjNWTk41LyszNDhYQnJCRENsMXRtVWVZNzBiNnJOcm5Zd2F4?= =?utf-8?B?citCaWUyQmp0THd2M1FmRDRua2VyTURGdEJHZi9hSzdsYVlBSXFlRndUZFly?= =?utf-8?B?M1l2SWJmdmpEK0FXcGRWRjMwanVUUWZFYVFxbG9oNnpHK0pBb2VnTTVRcllk?= =?utf-8?B?VXdYRVBvUlc2MTRDWlFjL2cwYkFQdjJHVTFQSFI2NFNMdG8wNk5SWTViSGlY?= =?utf-8?B?ZUdoWm1MT2pzOG8yaWIrbGl6ZnJOa0dXeWlERU1TRExOaEx0eTM5VkpKdmJj?= =?utf-8?B?VTZZWnBCVTZGZXZLZ28xUTNYbFFmVEE1WTcxWDFSNnI0T1BmaElMNjJuMk02?= =?utf-8?B?SGxjbzZ0UnFhQlJMRCszM1V5cVVoUnNHRWJBbG5IZnFhSm1TVkZraGY5UE0y?= =?utf-8?B?VStLVCtOT0FPVU81Q240a2dPbXJxTEorWWRjWGxKVHpYVEN1SENCOVJsZGpS?= =?utf-8?B?cEIybWpBbUFUQlkyOVNuSXBZdmRjcHNsTE4yVXlZQ0N5cUk1TVdHTUFNSGRN?= =?utf-8?B?SS9uU0RibjNGMzY5NkhWbllrdTNpaVk2MFNuRCtndGN1dlpMQ2t5eG51THNT?= =?utf-8?B?dmZHRkdDY2hqZkFLWUVkalZYKzZrajFLVWdjbkpxOWpVdEczNEY3RU9MYVBS?= =?utf-8?B?SkRMS3dwa0hNcG5qTGdMbFh5Tzh0a3dNVldaZHkzakhITVRWMXY0Q3lZYSt4?= =?utf-8?B?VnpnbVdKWFA0OFBCOEkwL0pGRSt4OGtydUlTMmR6Nzl2dmUrUEoyNW1hY01P?= =?utf-8?B?ZVR5QmJpTFhVaDVWVkZYaUp5d2EvS1dhNjdCd0NDdm1HZGNvYmliZFRSUjU5?= =?utf-8?B?c243M2RPSUxYaUE4alY3RWdOWmx0N3ZOOEp1dHBvSmJNY3p6M0VqckZzNG9M?= =?utf-8?B?WnJMaDh0WU90cTFiL1lUMzd0L2NkcUZSQ3JNbktzZ2JiaFNkaXZocXl2Q2NZ?= =?utf-8?B?S1hGb0s3bkZ4R0IwVDkvY3QwbWxFWmlzZmp3a25YSERNOWdLazF1VVAxZUdr?= =?utf-8?B?emxiYXlpcVN1ZkwvdmQ5WmV6aE9MWDVtR0RVMzNOb296WHcxUis0UmcvaXdP?= =?utf-8?B?aUsvVndtaUNZWEQ2M2MxQ3FOTElIUHV6REx1ZnAya0o2QmN4Mmx6YnVCNE41?= =?utf-8?B?T0N1ajdYenNwbWdHMEZ1c0ZMc0ZMR0VUbXlRenIzVEppalpwZGlBeGhNYytQ?= =?utf-8?B?RXFidVdYRkNZRENVYnlkdVpkQ2Q5OGpiL2ExbGxtSk1idE92M0sxZXVUWldS?= =?utf-8?B?MmhPRGpZbnBnY0thQndTL3NGbk5nUkdKUlBUVUh4NE9Fa1Uwd1NYRVMyRWhy?= =?utf-8?B?UmpzQ0d1Q056bSs0amYxSEVlY21FUjRZVSsrQy9PalBaNHU5RXpVclBiREgr?= =?utf-8?B?VkNWVDd1aUNEdVJ5RGtVUWs1QVlSSGdnTjR6bGhPRndXZlVSWVhPMGtOVWhw?= =?utf-8?B?K282V0cvRFJJd1BrSmZFSzMyWnlrWTVOaHJvc1JwKzY3M0pic3psTzMyMjRG?= =?utf-8?B?MzA5YTZzNjlBaGhmRjlQdk81andHNTFLQWMrQVZ0L1huVU5kcWpaWkpNL1Fu?= =?utf-8?B?NTI0YnQxc0NYNWRLdFVIVjJiUkpLSkZxVUlaM1UvL0ViYzN3V3c1MXZrSWVE?= =?utf-8?B?YUFreTFsUURDTjlSUk5wdC80VTBuZXZBcXIvQk5VS1E3TUl4cGxHSDZXbjRU?= =?utf-8?B?ZVg1L1RFSElscnpWWWQxMGp5UCtXSWFkb2cyVG9uc3BnWmNtSGZqU09TeTM5?= =?utf-8?B?US9kOHN1VkttQnhERWRTMkFCamhyNTJhODB3MTBsUlhBMVVhUkUvSXJhUTJz?= =?utf-8?B?WTM4V2JSeVV6SVArVkZsQWIzWTRtQjVYWkg3bVRxc3RPekhJVFZycU0walFN?= =?utf-8?Q?z8i/uK?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(39860400002)(366004)(376002)(13464003)(199004)(189003)(32952001)(76176011)(7736002)(305945005)(99286004)(2171002)(7696005)(6246003)(74316002)(4326008)(2501003)(81166006)(66574012)(102836004)(6116002)(81156014)(26005)(33656002)(53546011)(6506007)(53936002)(106356001)(2906002)(97736004)(8676002)(105586002)(25786009)(80792005)(478600001)(229853002)(72206003)(316002)(9686003)(5024004)(54906003)(66066001)(256004)(55016002)(14444005)(11346002)(110136005)(446003)(186003)(6436002)(8936002)(93886005)(86362001)(476003)(14454004)(71190400001)(52536013)(68736007)(486006)(3846002)(71200400001)(5660300002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2934; H:BYAPR16MB2790.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: /HAguDxXCcuxK6RdeQpjzk+BHqUe4ylXTCbpEOZDfI20Du2kYY3O37xRwxD8l3iVMZIQQPz7dPi9ntBTbVbwiBlo+fLybD5iUU8h82bdSQbhNZtP4ABNH9ebjQ7gx7+DzSEkjAhpZ7J26fHRqfwlmLEpIOWQekxvrx/HCNpnlqUiSr6BXLm2J5eHgZ0vuV9uB0lVmDgNHyml8uTyjHk/P1IGA1lHHS9m2K/QrJCt+/Iv3wn1YCB/560+v8Z98vuTHUrZJwHl75G+gEUTlKdejzhBatuEM4E/Ary2xgQdUDYD1pkHzWRVUPIAXQtGxK4wpaf9HpSq1NRAogFeDPDzaNL7B4KXd41+RgfTez5ru7/AwQo7kXzZSR0IDIi/idmWbPIoLYyJhGjotnmvUoyB2LKL3ziOPiIJrJQY9e6VoDc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 59e8e7db-24a4-4eaf-b61e-08d69c811136 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 06:59:07.1445 (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: BYAPR16MB2934 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6491> : inlines <7024> : streams <1814228> : uri <2802937> Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 06:59:23 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBGcmlkYXks IEZlYnJ1YXJ5IDE1LCAyMDE5IDU6NTMgUE0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Ow0KPiBCZW5qYW1pbiBLYWR1 ayA8a2FkdWtAbWl0LmVkdT4NCj4gQ2M6IGRvdHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZG90cy1k YXRhLWNoYW5uZWxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IEFEIHJldmlldyBvZiBkcmFmdC1p ZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI1DQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJv bSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBv cGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cg dGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEhpIFRpcnUsDQo+IA0KPiBQbGVhc2Ugc2VlIGlu bGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiA+IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiBbbWFpbHRv OlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21dDQo+ID4gRW52b3nDqcKgOiB2ZW5k cmVkaSAxNSBmw6l2cmllciAyMDE5IDEyOjA2IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9P TE47DQo+ID4gQmVuamFtaW4gS2FkdWsgQ2PCoDogZG90c0BpZXRmLm9yZzsNCj4gPiBkcmFmdC1p ZXRmLWRvdHMtZGF0YS1jaGFubmVsQGlldGYub3JnDQo+ID4gT2JqZXTCoDogUkU6IEFEIHJldmll dyBvZiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI1DQo+ID4NCj4gPiBJIGFtIGNhdGNo aW5nIHVwIHdpdGggdGhlIGRpc2N1c3Npb24sIGNvdXBsZSBvZiBwb2ludHM6DQo+ID4NCj4gPiAx KQ0KPiA+ICAgICAgICogIElmIGEgbmV0d29yayByZXNvdXJjZSAoRE9UUyBjbGllbnQpIGRldGVj dHMgYSBwb3RlbnRpYWwgRERvUw0KPiA+ICAgICAgICAgIGF0dGFjayBmcm9tIGEgc2V0IG9mIElQ IGFkZHJlc3NlcywgdGhlIERPVFMgY2xpZW50IGluZm9ybXMgaXRzDQo+ID4gICAgICAgICAgc2Vy dmljaW5nIERPVFMgZ2F0ZXdheSBvZiBhbGwgc3VzcGVjdCBJUCBhZGRyZXNzZXMgdGhhdCBuZWVk IHRvDQo+ID4gICAgICAgICAgYmUgZHJvcC0gb3IgYWNjZXB0LWxpc3RlZCBmb3IgZnVydGhlciBp bnZlc3RpZ2F0aW9uLg0KPiA+DQo+ID4gQ29tbWVudD4gSSBkb24ndCBzZWUgd2h5IHN1c3BlY3Qg SVAgYWRkcmVzc2VzIHdpbGwgYmUgYWNjZXB0LWxpc3RlZCA/DQo+ID4gICAgICAgICAgICAgICAg ICAgICBXZSBtYXkgd2FudCB0byByZW1vdmUgIm9yIGFjY2VwdC1saXN0ZWQiIGZyb20gdGhlDQo+ ID4gYWJvdmUgbGluZS4NCj4gPg0KPiANCj4gW01lZF0gQWNrLg0KPiANCj4gPiBbTWVkXSBUaGUg ZG90cyBjbGllbnQgd2lsbCBrbm93IGlmIGl0cyByZXF1ZXN0IGlzIHN1Y2Nlc3NmdWxseSBkZWxp dmVyZWQuDQo+ID4gV2hlbiBhbiBhdHRhY2sgaXMgb25nb2luZywgdGhlIGRvdHMgY2xpZW50IHNo b3VsZCBub3QgdXNlIGl0IGRhdGENCj4gPiBjaGFubmVsIGJlY2F1c2UgaXQgaXMgbGlrZWx5IHRv IGJlIHBlcnR1cmJlZC4NCj4gPg0KPiA+IENvbW1lbnQ+IElmIHRoZSBIVFRQIHJlc3BvbnNlIGZy b20gdGhlIHNlcnZlciBkaWQgbm90IHJlYWNoIHRoZSBjbGllbnQNCj4gPiBiZWNhdXNlIG9mIGEg dm9sdW1ldHJpYyBhdHRhY2sgc2F0dXJhdGluZyB0aGUgaW5jb21pbmcgdGhlIGxpbmssIHRoZQ0K PiA+IERPVFMgY2xpZW50IHdpbGwgbm90IGtub3cgd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBp cyBzdWNjZXNzZnVsbHkNCj4gPiB1cGRhdGVkIG9yIG5vdC4gQWZ0ZXIgdGhlIGF0dGFjayBpcyBt aXRpZ2F0ZWQsIHRoZSBjbGllbnQgd2lsbCBoYXZlIHRvDQo+ID4gcmUtZXN0YWJsaXNoIHRoZSBU TFMgc2Vzc2lvbiBhbmQgcmV0cmlldmUgdGhlIGNvbmZpZ3VyYXRpb24gdG8gY2hlY2sNCj4gPiBp ZiBpdHMgbGFzdCByZXF1ZXN0IHdhcyBzdWNjZXNzZnVsbHkgYXBwbGllZCBvciBub3QgYmVmb3Jl IHVwZGF0aW5nDQo+ID4gdGhlIGNvbmZpZ3VyYXRpb24uDQo+ID4NCj4gDQo+IFtNZWRdIEFncmVl LiBTdGlsbCwgaG93IHRoZSBjbGllbnQgc3luY3MgaXRzIGNvbmZpZyB3aXRoIHRoZSBvbmUgbWFp bnRhaW5lZCBieQ0KPiB0aGUgc2VydmVyIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLiBBIGNs aWVudCBjYW4gc2VuZCBhIEdFVCBiZWZvcmUgYW5kL29yDQo+IGFmdGVyIGEgY29uZmlndXJhdGlv biBjaGFuZ2UgcmVxdWVzdCwgaW4gcmVndWxhciBpbnRlcnZhbHMsIGFmdGVyIGF0dGFjaw0KPiBt aXRpZ2F0aW9uLCBldGMuDQoNCkFkZGluZyBhIEltcGxlbWVudGF0aW9uIE5vdGUgbG9va3MgdXNl ZnVsIHRvIG1lLg0KDQotVGlydQ0KDQo+IA0KPiA+IENoZWVycywNCj4gPiAtVGlydQ0K From nobody Tue Feb 26 23:02:17 2019 Return-Path: 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 11C6C12F19D for ; Tue, 26 Feb 2019 23:02:15 -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 w5RhRzqRNi0S for ; Tue, 26 Feb 2019 23:02:13 -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 A9BCC128B01 for ; Tue, 26 Feb 2019 23:02:12 -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=1551250468; 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-ms-exchange-purlcount: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=i9DIWZMdc68skmFNXjWkO908KoiZDQ36t/IljX nArHU=; b=pC/+nn/K6daP4UwjzSyp4lNsTbfaZWRyiw4zA+KW xywVLdR2LMrxV9D7/S4qEL4jPMcE61HVKXrISZnVEsP5kmeXhg l0enjulcJe9Lv9Mje53lj1rB9W8hEgO3jNB43hD+JuvA1Vub61 wCKw2qR2sKHRdoTVJZ00Tz9hSAGcov8= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6336_40f7_31d8d591_0254_4daf_a636_b1028b5544f4; Tue, 26 Feb 2019 23:54:27 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 23:56:27 -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, 26 Feb 2019 23:56:27 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 23:56:26 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2614.namprd16.prod.outlook.com (20.177.227.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Wed, 27 Feb 2019 06:56:26 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1643.022; Wed, 27 Feb 2019 06:56:26 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" CC: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt Thread-Index: AQHUysO2BSyTdnM0Qka7k+Ykw8xjSaXr/0pggAY1FWCAAQcR8A== Date: Wed, 27 Feb 2019 06:56:25 +0000 Message-ID: References: <155084937056.5323.18401033305053602209@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA25825@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA25825@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22087120-ea7e-43a9-e3f5-08d69c80b12b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2614; x-ms-traffictypediagnostic: BYAPR16MB2614: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNjE0OzIzOmwyTWNGOEJJU2cvK2FUUERXdnhQZXphQzA4?= =?utf-8?B?dm93SzBaMnZ1cjE1VVVGNSt5WmE4cFpVUlNCcGgrdnFGNG05TTY1OTlqWlJZ?= =?utf-8?B?VEphSmhaWERiL1JyRWpLbU5rK25OZE55bk1JcmdOLy9pYmVFd1JEZUNZRlIv?= =?utf-8?B?LzhBajRnMWoyejgweGZFZUV1TnI0S3pEVC9vWjZRV3VoanlYRTZ1azV3UFVF?= =?utf-8?B?QzR0c1ByUW9HRUY2a3ZFWFdoZWFUU05NcGx6VGMwcFFDZDRlMFE4c2Q2Rkw4?= =?utf-8?B?VnZuN2hZcitieDU5NWlXTzdnQzFiYkRJdXd6dkt6U0FaWEtMZVpjenVaZlIv?= =?utf-8?B?TTZOVTZjangwVHpSQVpEdjVGTXluZUFaRHg1L3VwdDQ4cFB3VUQ0SHh0Q2FU?= =?utf-8?B?U2xLMFZKeDRobjVPQkJ0aXNKQUhWVWtXdkFMYTc4elVZanFUb0lzWm8vRDBk?= =?utf-8?B?Vk9JcW9ISXc4RzczMVRqY3hBTllYTGtLNDYyeHFpblkvTGt3dmdBSDJUenE0?= =?utf-8?B?enMyVEpHVU5KbWFhQUJZdWMxN0N0WmV3NnQ2UzVTMFpzN2xxbDA4QlVjZm5z?= =?utf-8?B?em11VFZ3MXUvc0FidzdtY0hzRW1tMTFmcHovK1A5RWlEdGl1VEIxektRQSs2?= =?utf-8?B?cTBwS1NQVDROazhvVnk2RTRiV2c4TmRBcXl3c1FVVkNPRjdSZWVaQWJRb3NH?= =?utf-8?B?SEZmVE1SN0pnL1lZaEJLeWp3VmZEMnVUbG1rTG9QOHJXZUgvNldLTFpQeE5o?= =?utf-8?B?dkVuWUNBRzhVMldFUkROT0dnVVZkVTc3a2hRSFRoRDBzVFBnSWYzUkFEaW5o?= =?utf-8?B?bVVRdUZVL0d6QWhObW1oOU93czBGbEg5czdsaENrSW1OT1k1TmFDZGlGREtO?= =?utf-8?B?eGMvYkx4RGc1RDRsSG4wWHk0UjhaclYzYWJDK2VBdnU0d1ZKUGZjU0k3bkFp?= =?utf-8?B?RUN0N3Z5K0J1WUtyd0R0N0doVTlkNC96Si9hR2NVaml1dEo3bXpkczIyZitR?= =?utf-8?B?cTVpMmZGc1JSS0hEZGNmMjJaWWZ1eDJwNlpaUE9sOGs5MUsxcklEUUFKMTBO?= =?utf-8?B?bEZyVTFHdDV5VzJTaC8zS241V3N2UnBMNHNpOHR1NXNDSmNENlo1R00rdHMw?= =?utf-8?B?M3d1TjEzVGJaeVZiSG1kNkI0T0UxN0Y3UTF0RmRucFAycUMvcllOYXZTdFBI?= =?utf-8?B?UWF6QlpsOXh2QWdrMlpmeE01THdVd2dYZGlPVUM1b1B4dEw5WDlObmU5SHlh?= =?utf-8?B?Vi81ZGthZXJ5eVlieTlLeGRRV05RNm53MDhlQjZjbmtwYk9HbE15ZVNtVGhG?= =?utf-8?B?NzJ1Z1FuOEx4bGtOeDh2cUlBSDFETEZiUXpRQVhPa3ZlbmIrenI1VWVlRVdE?= =?utf-8?B?emdRVitIOVp3VHZ6ZXB6L0JMOUVuY3JsUG1ReEJPb3JTbEZDS1ozbjluUFhM?= =?utf-8?B?UDZGWUx2K1R1NEd2QTBnd0hFNDFUMlJveklQTDFYZm1ZTlgrV3hEbXVQdHY1?= =?utf-8?B?Qi9yZmppeEF6UURUdWpKNy9FYk4wMXpPVVpoMC9uYnNWT0NBWW54NHZ1cDVC?= =?utf-8?B?Zk1VcTdjS3ZaRzRoVWtKTm0zTVp3cFVrSFBBMlRxbEFGb3NvWi9XeFNIRVdM?= =?utf-8?B?VjI3czNicW9Pam05ZzF2cjR2eVZXcUNKaEJUKzZJUStTVHJvdzlpMWg0alhu?= =?utf-8?B?LzVMcWZVbmRKWFFsZzFQbW9GTjg1TkdCVDlLZVdQcTZaamROMnR6V0F0cU91?= =?utf-8?B?cmhsd3d6aUNKSnViV2FiMDdRSHU0Z1RlQ1FBYjFwdVNGaEF0U2FzUDN2ems2?= =?utf-8?B?cnJFWTArN2Q2S0ZFWmVuL0xpenZOemhCcElZUkdqKzlOd0NJY2ZTVGxkU2Vt?= =?utf-8?B?cXhROGVkN050alBNR3ZkdThTMkZPMnF0NC9GYUFnV0RzU0hud1l5eWJBZlls?= =?utf-8?B?U1lidVRsRXdkQVNOK01obDBDb2hDclJOZEl5eFU3VGlaNHlnOS95Z25XUzl0?= =?utf-8?B?YWpRK0xnN0dUcGRDWHFWQVkzSEN3M0s0Sm1vUT09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(346002)(396003)(39860400002)(13464003)(32952001)(189003)(199004)(53936002)(66574012)(5024004)(6306002)(256004)(9686003)(68736007)(52536013)(229853002)(25786009)(66066001)(8936002)(5640700003)(55016002)(99286004)(6436002)(478600001)(14454004)(966005)(71190400001)(72206003)(71200400001)(26005)(5660300002)(2501003)(4326008)(7696005)(33656002)(53546011)(102836004)(76176011)(3846002)(6116002)(6506007)(6916009)(186003)(14444005)(476003)(106356001)(2351001)(11346002)(446003)(316002)(486006)(80792005)(305945005)(81166006)(74316002)(7736002)(105586002)(81156014)(8676002)(86362001)(2906002)(97736004)(6246003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2614; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: HR4rum2vSnUPs6+4s2/7mYxtq0XNUy631SZFycftRkZpLhEkiBUqElwYC4p3apPWAx+Vu3NRdrY0VeXoz+j6EZkfjfrjrZGLT3sHhzrqC8aEsVUbkzK+2Lny//7cmH3Zf2Nd0r3Sydcoy6k0QzBr6sA0AC0g+Sh5CEbfuUiD2HrnU0RMFg4iOwteWfb41gU2DskCBfJI/ilu5MxDexnXwgxC3dP15U4XXpFUhEHqh8NsKUe3MW06oIe5djklC4jBVp9RQ4+wM1pT6mb9zOGoClxJkaP0T6LR76JT/JHzovW1Z1sl/ot0sgfajhKpUAwux/J7u43UP9GI1+KTu6CSb1uXi/gxlpuiaxgDOL1xFCS8RfFuuBnxG8BKSPjMnWpLSd2LkWCYYYdEXNoGMTYRQE7pO1d1SGS3g6im46p4ZSU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 22087120-ea7e-43a9-e3f5-08d69c80b12b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 06:56:26.0103 (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: BYAPR16MB2614 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6491> : inlines <7024> : streams <1814228> : uri <2802937> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 07:02:15 -0000 SGkgTWVkLA0KDQpQbGVhc2Ugc2VlIGlubGluZSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNiwgMjAxOSA4OjQy IFBNDQo+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tPg0KPiBDYzogZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0Rv dHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0yOS50eHQNCj4g DQo+IA0KPiANCj4gSGkgVGlydSwNCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiANCj4gQ2hl ZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXC oDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBLb25k YSwNCj4gPiBUaXJ1bWFsZXN3YXIgUmVkZHkgRW52b3nDqcKgOiB2ZW5kcmVkaSAyMiBmw6l2cmll ciAyMDE5IDE3OjIwIMOAwqA6DQo+ID4gZG90c0BpZXRmLm9yZzsgaS1kLWFubm91bmNlQGlldGYu b3JnIE9iamV0wqA6IFJlOiBbRG90c10gSS1EIEFjdGlvbjoNCj4gPiBkcmFmdC1pZXRmLWRvdHMt c2lnbmFsLWNoYW5uZWwtMjkudHh0DQo+ID4NCj4gPiBIaSBNZWQsDQo+ID4NCj4gPiBDb3VwbGUg b2YgTml0czoNCj4gPg0KPiA+IDEpDQo+ID4gT0xEOg0KPiA+IExpa2V3aXNlLCAnc2lkJyB2YWx1 ZSBpcw0KPiA+IG1vbm90b25pY2FsbHkgaW5jcmVhc2VkIGJ5IHRoZSBET1RTIGNsaWVudCBmb3Ig ZWFjaCBjb25maWd1cmF0aW9uDQo+ID4gc2Vzc2lvbiwgYXR0YWNrZXJzIHJlcGxheWluZyBjb25m aWd1cmF0aW9uIHJlcXVlc3RzIHdpdGggbG93ZXIgbnVtZXJpYw0KPiA+ICdzaWQnIHZhbHVlcyB3 aWxsIGJlIHJlamVjdGVkIGJ5IHRoZSBET1RTIHNlcnZlciBpZiBpdCBtYWludGFpbnMgYQ0KPiA+ IGhpZ2hlciBudW1lcmljICdzaWQnIHZhbHVlIGZvciB0aGlzIERPVFMgY2xpZW50Lg0KPiA+DQo+ ID4gTkVXOg0KPiA+IExpa2V3aXNlLCAnc2lkJyB2YWx1ZSBpcw0KPiA+IG1vbm90b25pY2FsbHkg aW5jcmVhc2VkIGJ5IHRoZSBET1RTIGNsaWVudCBmb3IgZWFjaCBjb25maWd1cmF0aW9uDQo+ID4g cmVxdWVzdCwgYXR0YWNrZXJzIHJlcGxheWluZyBjb25maWd1cmF0aW9uIHJlcXVlc3RzIHdpdGgg bG93ZXIgbnVtZXJpYw0KPiA+ICdzaWQnIHZhbHVlcyB3aWxsIGJlIHJlamVjdGVkIGJ5IHRoZSBE T1RTIHNlcnZlciBpZiBpdCBtYWludGFpbnMgYQ0KPiA+IGhpZ2hlciBudW1lcmljICdzaWQnIHZh bHVlIGZvciB0aGlzIERPVFMgY2xpZW50Lg0KPiA+DQo+IA0KPiBbTWVkXSBPSyBmb3Igcy9zZXNz aW9uL3JlcXVlc3QuDQo+IA0KPiA+IDIpDQo+ID4gRGVmaW5lICdpZGxlJyB0aW1lIChpLmUuIHdo ZW4gbm8gYXR0YWNrIHRyYWZmaWMgaXMgcHJlc2VudCkuDQo+IA0KPiBbTWVkXSBUaGlzIG9uZSBp cyBub3QgbmVlZGVkLCBJTUhPLiBXZSBkbyBhbHJlYWR5IGhhdmUgdGhlIGZvbGxvd2luZyBpbiB0 aGUNCj4gZHJhZnQ6DQo+IA0KPiAgICBUaGUgc2FtZSBvciBkaXN0aW5jdCBjb25maWd1cmF0aW9u IHNldHMgbWF5IGJlIHVzZWQgZHVyaW5nIHRpbWVzIHdoZW4NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eDQo+ ICAgIGEgbWl0aWdhdGlvbiBpcyBhY3RpdmUgKCdtaXRpZ2F0aW5nLWNvbmZpZycpIGFuZCB3aGVu IG5vIG1pdGlnYXRpb24NCj4gDQo+IF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gXl5eXg0KPiAgICBpcyBhY3RpdmUgKCdp ZGxlLWNvbmZpZycpLiAgVGhpcyBpcyBwYXJ0aWN1bGFybHkgdXNlZnVsIGZvciBET1RTDQo+ICAg IF5eXl5eXl5eXl5eXl5eXl5eDQoNClRoZSBhYm92ZSBsaW5lcyBkbyBub3QgZGVmaW5lIHRoZSB0 ZXJtICdpZGxlJy4NCldlIGp1c3QgaGF2ZSB0byBhcHBlbmQgIihpLmUuIHdoZW4gbm8gYXR0YWNr IHRyYWZmaWMgaXMgcHJlc2VudCkiIHRvICdpZGxlJyB0aW1lLiANCg0KQ2hlZXJzLA0KLVRpcnUN Cg0KPiAgICBzZXJ2ZXJzIHRoYXQgbWlnaHQgd2FudCB0byByZWR1Y2UgaGVhcnRiZWF0IGZyZXF1 ZW5jeSBvciBjZWFzZQ0KPiAgICBoZWFydGJlYXQgZXhjaGFuZ2VzIHdoZW4gYW4gYWN0aXZlIERP VFMgY2xpZW50IGhhcyBub3QgcmVxdWVzdGVkDQo+ICAgIG1pdGlnYXRpb24uICBJZiBkaXN0aW5j dCBjb25maWd1cmF0aW9ucyBhcmUgdXNlZCwgRE9UUyBhZ2VudHMgTVVTVA0KPiAgICBmb2xsb3cg dGhlIGFwcHJvcHJpYXRlIGNvbmZpZ3VyYXRpb24gc2V0IGFzIGEgZnVuY3Rpb24gb2YgdGhlDQo+ ICAgIG1pdGlnYXRpb24gYWN0aXZpdHkgKGUuZy4sIGlmIG5vIG1pdGlnYXRpb24gcmVxdWVzdCBp cyBhY3RpdmUsICdpZGxlLQ0KPiAgICBjb25maWcnLXJlbGF0ZWQgdmFsdWVzIG11c3QgYmUgZm9s bG93ZWQpLiAgQWRkaXRpb25hbGx5LCBET1RTIGFnZW50cw0KPiAgICBNVVNUIGF1dG9tYXRpY2Fs bHkgc3dpdGNoIHRvIHRoZSBvdGhlciBjb25maWd1cmF0aW9uIHVwb24gYSBjaGFuZ2UgaW4NCj4g ICAgdGhlIG1pdGlnYXRpb24gYWN0aXZpdHkgKGUuZy4sIGlmIGFuIGF0dGFjayBtaXRpZ2F0aW9u IGlzIGxhdW5jaGVkDQo+ICAgIGFmdGVyIGFuICdpZGxlJyB0aW1lLCB0aGUgRE9UUyBhZ2VudCBz d2l0Y2hlcyBmcm9tICdpZGxlLWNvbmZpZycgdG8NCj4gICAgJ21pdGlnYXRpbmctY29uZmlnJy1y ZWxhdGVkIHZhbHVlcykuDQo+IA0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IERvdHMgPGRvdHMtYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mDQo+ID4gPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPiA+IFNl bnQ6IEZyaWRheSwgRmVicnVhcnkgMjIsIDIwMTkgOTowMCBQTQ0KPiA+ID4gVG86IGktZC1hbm5v dW5jZUBpZXRmLm9yZw0KPiA+ID4gQ2M6IGRvdHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtE b3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMjkudHh0DQo+ ID4gPg0KPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3Jn YW5pemF0aW9uLiBEbyBub3QgY2xpY2sNCj4gPiA+IGxpbmtzDQo+ID4gb3INCj4gPiA+IG9wZW4g YXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUN Cj4gPiA+IGNvbnRlbnQgaXMNCj4gPiBzYWZlLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMNCj4gPiBkaXJlY3Rvcmllcy4NCj4gPiA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFdHIG9mIHRoZSBJRVRGLg0KPiA+ID4NCj4g PiA+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZp Y2UgT3BlbiBUaHJlYXQNCj4gPiBTaWduYWxpbmcgKERPVFMpDQo+ID4gPiBTaWduYWwgQ2hhbm5l bCBTcGVjaWZpY2F0aW9uDQo+ID4gPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRpcnVtYWxl c3dhciBSZWRkeQ0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBNb2hhbWVkIEJvdWNh ZGFpcg0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBQcmFzaGFudGggUGF0aWwNCj4g PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kcmV3IE1vcnRlbnNlbg0KPiA+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgICBOaWsgVGVhZ3VlDQo+ID4gPiAJRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTI5LnR4dA0KPiA+ID4gCVBhZ2VzICAg ICAgICAgICA6IDk5DQo+ID4gPiAJRGF0ZSAgICAgICAgICAgIDogMjAxOS0wMi0yMg0KPiA+ID4N Cj4gPiA+IEFic3RyYWN0Og0KPiA+ID4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIERP VFMgc2lnbmFsIGNoYW5uZWwsIGEgcHJvdG9jb2wgZm9yDQo+ID4gPiAgICBzaWduYWxpbmcgdGhl IG5lZWQgZm9yIHByb3RlY3Rpb24gYWdhaW5zdCBEaXN0cmlidXRlZCBEZW5pYWwtb2YtDQo+ID4g PiAgICBTZXJ2aWNlIChERG9TKSBhdHRhY2tzIHRvIGEgc2VydmVyIGNhcGFibGUgb2YgZW5hYmxp bmcgbmV0d29yaw0KPiA+ID4gICAgdHJhZmZpYyBtaXRpZ2F0aW9uIG9uIGJlaGFsZiBvZiB0aGUg cmVxdWVzdGluZyBjbGllbnQuDQo+ID4gPg0KPiA+ID4gICAgQSBjb21wYW5pb24gZG9jdW1lbnQg ZGVmaW5lcyB0aGUgRE9UUyBkYXRhIGNoYW5uZWwsIGEgc2VwYXJhdGUNCj4gPiA+ICAgIHJlbGlh YmxlIGNvbW11bmljYXRpb24gbGF5ZXIgZm9yIERPVFMgbWFuYWdlbWVudCBhbmQgY29uZmlndXJh dGlvbg0KPiA+ID4gICAgcHVycG9zZXMuDQo+ID4gPg0KPiA+ID4gRWRpdG9yaWFsIE5vdGUgKFRv IGJlIHJlbW92ZWQgYnkgUkZDIEVkaXRvcikNCj4gPiA+DQo+ID4gPiAgICBQbGVhc2UgdXBkYXRl IHRoZXNlIHN0YXRlbWVudHMgd2l0aGluIHRoZSBkb2N1bWVudCB3aXRoIHRoZSBSRkMNCj4gPiA+ ICAgIG51bWJlciB0byBiZSBhc3NpZ25lZCB0byB0aGlzIGRvY3VtZW50Og0KPiA+ID4NCj4gPiA+ ICAgIG8gICJUaGlzIHZlcnNpb24gb2YgdGhpcyBZQU5HIG1vZHVsZSBpcyBwYXJ0IG9mIFJGQyBY WFhYOyINCj4gPiA+DQo+ID4gPiAgICBvICAiUkZDIFhYWFg6IERpc3RyaWJ1dGVkIERlbmlhbC1v Zi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZw0KPiA+ID4gICAgICAgKERPVFMpIFNpZ25h bCBDaGFubmVsIFNwZWNpZmljYXRpb24iOw0KPiA+ID4NCj4gPiA+ICAgIG8gICJ8IFtSRkNYWFhY XSB8Ig0KPiA+ID4NCj4gPiA+ICAgIG8gIHJlZmVyZW5jZTogUkZDIFhYWFgNCj4gPiA+DQo+ID4g PiAgICBQbGVhc2UgdXBkYXRlIHRoaXMgc3RhdGVtZW50IHdpdGggdGhlIFJGQyBudW1iZXIgdG8g YmUgYXNzaWduZWQgdG8NCj4gPiA+ICAgIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzOg0KPiA+ID4N Cj4gPiA+ICAgIG8gICJSRkMgWVlZWTogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3Bl biBUaHJlYXQgU2lnbmFsaW5nDQo+ID4gPiAgICAgICAoRE9UUykgRGF0YSBDaGFubmVsIFNwZWNp ZmljYXRpb24gKHVzZWQgdG8gYmUgSS1ELmlldGYtZG90cy1kYXRhLQ0KPiA+ID4gICAgICAgY2hh bm5lbCkNCj4gPiA+DQo+ID4gPiAgICBQbGVhc2UgdXBkYXRlIFRCRC9UQkQxL1RCRDIgc3RhdGVt ZW50cyB3aXRoIHRoZSBhc3NpZ25tZW50cyBtYWRlIGJ5DQo+ID4gPiAgICBJQU5BIHRvIERPVFMg U2lnbmFsIENoYW5uZWwgUHJvdG9jb2wuDQo+ID4gPg0KPiA+ID4gICAgQWxzbywgcGxlYXNlIHVw ZGF0ZSB0aGUgInJldmlzaW9uIiBkYXRlIG9mIHRoZSBZQU5HIG1vZHVsZXMuDQo+ID4gPg0KPiA+ ID4NCj4gPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0 IGlzOg0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1k b3RzLXNpZ25hbC1jaGFubmVsLw0KPiA+ID4NCj4gPiA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMjkNCj4gPiA+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsDQo+ ID4gPiAtMjkNCj4gPiA+DQo+ID4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTI5DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mDQo+ID4gc3VibWlzc2lvbg0KPiA+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPiA+DQo+ID4gPiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ ID4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+ID4NCj4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBEb3Rz IG1haWxpbmcgbGlzdA0KPiA+ID4gRG90c0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4g RG90c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG90cw0K From nobody Wed Feb 27 02:25:45 2019 Return-Path: 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 4A583130EB5; Wed, 27 Feb 2019 02:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hQtRiQRh_jOV; Wed, 27 Feb 2019 02:25:39 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32238130E27; Wed, 27 Feb 2019 02:25:39 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 448WzP2qJNz10b7; Wed, 27 Feb 2019 11:25:37 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 448WzP1n4yzyQ2; Wed, 27 Feb 2019 11:25:37 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([fe80::d89a:9017:59c2:9724%21]) with mapi id 14.03.0435.000; Wed, 27 Feb 2019 11:25:37 +0100 From: To: Benjamin Kaduk CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUzlJcb7c2dDIvj0uWD4RT8wY9CqXzapPw Date: Wed, 27 Feb 2019 10:25:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA25FC4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227041011.GG53396@kduck.mit.edu> In-Reply-To: <20190227041011.GG53396@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 10:25:43 -0000 Hi Ben,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 27 f=E9vrier 2019 05:10 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > Objet=A0: Re: AD review of draft-ietf-dots-data-channel-25 >=20 > On Fri, Feb 15, 2019 at 09:36:26AM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Ben, > > > > Please see inline. > > >=20 > Thanks. The -27 is in good enough shape that I've requested the IETF las= t > call; we can finish discussing the last few topics here in parallel. >=20 [Med] Sure.=20 > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoy=E9=A0: jeudi 14 f=E9vrier 2019 20:17 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > > > Objet=A0: Re: AD review of draft-ietf-dots-data-channel-25 > > > > > > Hi Med, > > > > > > On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.co= m > wrote: > > > > Hi Ben, > > > > > > > > Thank you for the review. > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > > Envoy=E9=A0: mercredi 13 f=E9vrier 2019 17:46 > > > > > =C0=A0: draft-ietf-dots-data-channel@ietf.org > > > > > Cc=A0: dots@ietf.org > > > > > Objet=A0: AD review of draft-ietf-dots-data-channel-25 > > > > > > > > > > This is my AD review of the -25 > > > > > > > > > > I see that Med made a commit on github that preemptively addresse= d at > > > least > > > > > one of these comments, but will trust the authors to do to the ri= ght > > > thing > > > > > with anything in here that's stale. > > > > > > > > > > A handful of generic and/or high-level comments before the > > > > > section-by-section nitty-gritty stuff. > > > > > > > > > > The author count is large (7); RFC 7322 notes that the stream > approver > > > > > (i.e., the IESG) will ask questions if the count is more than fiv= e. > What > > > > > should I tell people when they ask? (The authors are listed also= in > the > > > > > YANG module itself, if changes are made.) > > > > > > > > [Med] Actually, the set of co-authors of the YANG module is not exa= ctly > the > > > same. > > > > > > Whoops, my bad for not checking. > > > > > > > Anyway, in order to comply with the rules and avoid spending extra > cycles > > > on this, we added a new section called "Contributing Authors". > Nevertheless, > > > the set of authors is not modified in the YANG module. > > > > > > Thanks. (To be clear, I'm happy to go to bat for everyone with the I= ESG > > > for this sort of thing, I just need an argument to present that's not= me > > > making things up.) > > > > > > I don't know of a specific policy for YANG module authorship, so that > part > > > should be okay as far as I know. > > > > > > > > > > > > > Can someone (the shepherd?) confirm that an automated syntax chec= ker > has > > > > > run over the JSON in examples? > > > > > > > > > > The concept of "DOTS client domain" is being used for actual prot= ocol > > > > > purposes here (most notably as a bound on the prefix(es) that a > client > > > can > > > > > request mitigation for, but I don't remember seeing a formal > definition > > > for > > > > > how any DOTS actor would know the specific bounds of such a clien= t > > > domain. > > > > > Is there text somewhere that I missed that we can point to, or wi= ll > we > > > need > > > > > to add some? > > > > > > > > [Med] Both "DOTS client domain" and "DOTS server domain" are used i= n > the > > > architecture draft. "DOTS client's domain" and "DOTS server's domain"= are > > > also used in the architecture and requirements I-D. > > > > > > > > If a formal definition is needed, I prefer this to be done in the > > > architecture or the requirements I-D. > > > > > > I think it would be a somewhat better fit in the architecture documen= t, > > > just to note that the "domain" is something that can concretely be > > > demarcated by IP addresses/prefixes (as opposed to a more nebulous > concept > > > to aid conceptual understanding). > > > > > > > [Med] Let's add that text into the architecture I-D. >=20 > Okay. Tiru had a follow-up about how servers can identify DOTS client's > domains, which is okay but not quite what I was aiming for. In the text > Tiru quoted, we note that >=20 > The DOTS server enforces authorization of DOTS clients' signals for > mitigation. The mechanism of enforcement is not in scope for this > document, but is expected to restrict requested mitigation scope to > addresses, prefixes, and/or services owned by the DOTS client's > administrative domain, such that a DOTS client from one domain is not > able to influence the network path to another domain. >=20 > I was hoping to see something like "For a given client (administrative) > domain, the DOTS server needs to be able to determine whether a given > resource is in that domain. This could take the form of associating a se= t > of IP Prefixes per domain, for example." But I'm open to being persuaded > that the existing text conveys the same meaning. >=20 [Med] Your proposed wording can be added to the architecture I-D, IMHO. FWIW, we do have this text in the protocol spec:=20 DOTS servers MUST verify that requesting DOTS clients are entitled to enforce filtering rules on a given IP prefix. That is, only filtering rules on IP resources that belong to the DOTS client's domain can be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. > > > > > > > > > > We don't say much about what validation the server does on input > data, > > > and > > > > > we probably should. For example, does the server need to validat= e > 'cuid' > > > > > > > > [Med] We avoided to be redundant here. This is covered by this text= : > > > > > > > > "This attribute has the same > > > > meaning, syntax, and processing rules as the 'cuid' attribute > > > > defined in [I-D.ietf-dots-signal-channel]." > > > > > > > > > and/or 'cdid' in dots-client-creation requests? > > > > > > > > [Med] This is covered by this text: > > > > > > > > "This attribute has the same meaning, syntax, and processing > > > > rules as the 'cdid' attribute defined in > > > > [I-D.ietf-dots-signal-channel]" > > > > > > I guess I'm mostly just concerned about if there's anything that does= n't > > > translate directly, since the CoAP and HTTP constructs would have to > > > describe the formal validation in somewhat different terms (i.e., for > > > consistency between URL paths and message bodies). But in general I'= m > > > happy to avoid redundancy as you desire. > > > > > > > And other parts in the text such as: > > > > > > > > If the request is received via a server-domain DOTS gateway, but= the > > > > DOTS server does not maintain a 'cdid' for this 'cuid' while a > 'cdid' > > > > is expected to be supplied, the DOTS server MUST reply with "403 > > > > Forbidden" status-line and the error-tag "access-denied". Upon > > > > receipt of this message, the DOTS client MUST register (Section = 5). > > > > > > > > > > > > What about validating that > > > > > the (e.g.) ACL name in the PUT URL matching the name in the body = of > the > > > > > request? > > > > > > > > [Med] Those are supposed to be covered following RESTCONF base spec= . > > > > > > Is this supposed to be RFC 8040 Section 3.5.3? I am not sure that I'= m > > > reading that as covering the property I want (and will double-check i= f > you > > > confirm that's what you have in mind). > > > > > > > [Med] In addition to 3.5.3, Section 4.5 specifies the rules for PUT. > > > > The main point is that the validation you mentioned is not specific to = DOTS > but are governed by RESTCONF procedures. >=20 > I only see 3.5.3 as talking about how to construct a request URI for a > given data node in the YANG tree. >=20 > What I'm wondering about for the data-channel document is if there are > cases where a given path component of the YANG module appears both in the > request URI and in the data in the request body. If so, it seems that th= e > server will need to verify that the redundant data agree, and I still don= 't > see where this is mandated by RFC 8040. (Sorry if I am being dense.) >=20 [Med] I hear you. As mentioned in my previous answer, this is covered in Se= ction 4.5 of RFC8040: If the target resource represents a YANG leaf-list, then the PUT method MUST NOT change the value of the leaf-list instance. If the target resource represents a YANG list instance, then the key leaf values, in message-body representation, MUST be the same as the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ key leaf values in the request URI. The PUT method MUST NOT be used ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to change the key leaf values for a data resource instance. > > > > There are probably others as well. > > > > > > > > > > The examples all use "Host: {host}:{port}" which is not really an > example > > > > > but rather a template. Since they are supposed to be examples, w= e > should > > > > > pick a concrete hostname (and port) to use. > > > > > > > > [Med] I will change some figures to "example.com" but will leave it= for > > > schema-like figures. > > > > > > Of course. > > > > > > > > > > > > > There is, shall we say, a "high degree of overlap" between Sectio= ns > 5/6/7 > > > > > and the YANG model field descriptions. I mostly assume that the = WG > > > > > considered letting the YANG model (and the core RESTCONF spec) st= and > > > alone > > > > > without the additional examples/specification of the use of RESTC= ONF > to > > > > > manage clients, aliases, and filter rules, so I won't suggest tha= t we > > > > > revisit the question. But I do think that it would be good to ha= ve > some > > > > > explicit text acknowledging the overlap and stating which one is > > > > > authoritative. > > > > > > > > [Med] Fixed. > > > > > > > > > > > > > > There seems to be some mismatch between whether the IPv6 ACL subt= ree > uses > > > > > "ttl" or "hoplimit" -- Figure 7 has "ttl" but the rest of the > document > > > > > seems to (properly) use "hoplimit". Someone else should double-c= heck > the > > > > > relevant places, though, as I'm not sure I was looking at all of = them > > > with > > > > > this issue in mind. > > > > > > > > [Med] Both are correct. > > > > > > > > Figure 7 reuses draft-ietf-netmod-acl-model which defines TTL as : > > > > > > > > leaf ttl { > > > > type uint8; > > > > description > > > > "This field indicates the maximum time the datagram is allo= wed > > > > to remain in the internet system. If this field contains = the > > > > value zero, then the datagram must be dropped. > > > > > > > > In IPv6, this field is known as the Hop Limit."; > > > > reference > > > > "RFC 791: Internet Protocol, > > > > RFC 8200: Internet Protocol, Version 6 (IPv6) Specificatio= n."; > > > > } > > > > > > > > For the other figures, the fields are defined in the data-channel > draft. > > > > > > Ah, thanks for the pointer. > > > > > > > > > > > > > I'm also a bit curious about the use of an explicit "capabilities= " > tree > > > for > > > > > fine-grained feature detection, as opposed to native YANG "featur= e"s. > > > > > > > > [Med] These are not serving the same purpose. Features are about pa= rts > of a > > > module which are conditional, if you will. Our "capabilities" branch = is > meant > > > to retrieve the filtering match capabilities are supported/enabled by= a > DOTS > > > server. That information is used by a client to tweak its requests. > > > > > > > > The > > > > > latter would allow the relevant nodes to just not exist when > unsupported, > > > > > > > > [Med] A filtering capability may be supported but not enabled. The > server > > > is free to include an explicit field with the appropriate status or n= ot. > This > > > is implementation-specific. > > > > > > Thanks for the explanation. > > > > > > > > as opposed to the explicit-capabilities formulation where they ex= ist > but > > > > > are (presumably) ignored. (I don't remember us explictily saying > that > > > > > they're ignored in this case, either; might be worth adding some > text.) > > > > > > > > > > In a similar vein, we include 'capabilities' nodes for a few matc= hing > > > > > features that are listed as "mandatory fields" for ACL matching i= n > Table > > > 1, > > > > > and thus whose value would always be "true". Why do we need the > > > capability > > > > > leaves in such a case? > > > > > > > > [Med] I guess you are referring to Figure 23 which says the followi= ng: > > > > > > > > Figure 23 shows an example of a response received from a DOTS se= rver > > > > which only supports the mandatory filtering criteria listed in > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Section 4.1. > > > > > > Correct. > > > > > > > The module allows to return other capabilities than those listed in > table > > > 1. > > > > > > Yes. But the figure should not claim to be an example that *only* > supports > > > the mandatory parts, when it shows an example that supports additiona= l > > > capabilities than the mandatory ones. > > > > > > > [Med] Which "additional capabilities" are you referring to? >=20 > (The text in the -27 addresses my complaint here, even if I was confused > about filtering criteria vs. actions.) >=20 > > > > > > > > > > > > idnits notes a few references that can be updated along with the > other > > > > > changes; it also flags a "reference in abstract" for the RFC Edit= or > note > > > > > which we could probably ignore (but could probably also just remo= ve > the > > > > > brackets around the text in question). > > > > > > > > [Med] idnits confuses the note to the RFC editor with the abstract. > Fixed, > > > anyway. > > > > > > > > > > > > > > I also looked at the references (especially the normative/informa= tive > > > > > split) and have a few suggestions: > > > > > > > > > > - the IEEE.754.1985 reference is not needed; > > > > > > > > [Med] Agree, but it is not harmful to cite it either :-) > > > > > > My personal opinion is that it *is* harmful, since we are not using a > > > floating-point wire encoding; we're using a string encoding. > > > > [Med] I removed the ref, but added a sentence to justify the unit we ar= e > using: mainly to align with traffic-rate in 5575. >=20 > OK >=20 > > > > > > > The reference is quoted to justify why we went with decimal64, not > uint64 > > > for example + why that unit is chosen. This allows to ease grafting D= OTS > with > > > BGP Flowspec for instance, which cites IEEE.754.1985 too. > > > > > > (RFC 5575 seems to claim to be using the actual binary floating-point > > > encoding.) > > > > > > > we don't use the binary > > > > > floating-point encoding but rather a string one for YANG decima= l64 > > > > > - I think that RFC 8499 (dnsop-terminology-bis) can wholly supers= ede > our > > > > > usage of RFC 1983, so the 1983 cite can be dropped as well > > > > > > > > [Med] Done. > > > > > > > > > - draft-ietf-dots-requirements (for terminology), > > > > > > > > [Med] For this one, we are following the same approach as for other > > > terminology documents (e.g., RFC8340) that are listed as informative.= I > > > prefer to leave it as informative for now. > > > > > > Okay, we can see if anyone else complains. > > > > > > > RFC 7950, and RFC 8259 > > > > > > > > [Med] OK for these two. > > > > > > > > > should probably all move to the normative section > > > > > > > > > > Section 1 > > > > > > > > > > The sub-bullet point about "If a network resource ... informs its > > > servicing > > > > > DOTS gateway of all suspect IP addresses that need to be drop- or > > > > > accept-listed ..." made me wonder if that was more of a signal- > channel > > > > > activity or a data-channel one. Perhaps this is just a matter of= the > > > text > > > > > not being as clear as it could be. > > > > > > > > [Med] The point is that a client is not sure that an attack is acti= ve > and > > > targeting the client domain but it wants to enforce some preventive > actions > > > during an investigation period. For example, this can be triggered by= an > > > administrator who is informed that an attack is currently targeting o= ther > > > networks, but its network is likely to be subject to that attack too. > Other > > > preventive actions which require further investigation may be conside= red. > > > > > > > > I changed the text as follows: > > > > > > > > OLD: > > > > detects a potential DDoS attack from > > > > > > > > NEW > > > > is informed about a potential DDoS attack from > > > > > > > > (I also wonder if we should say > > > > > "further investigation" since we don't really have an automated w= ay > to > > > > > indicate that yet.) > > > > > > On further reflection, would "further manual investigation" be > appropriate? > > > > [Med] No assumption is made how that investigation is made. I prefer to > leave the text as it. >=20 > OK >=20 > > > > > > > > Section 2 > > > > > > > > > > When we talk about tree diagrams, should we also say something li= ke > "Note > > > > > that the full module's tree has been split across several figures= to > aid > > > > > the exposition of the various sub-trees"? > > > > > > > > [Med] Done. Thanks. > > > > > > > > > > > > > > Section 3.1 > > > > > > > > > > When we talk about using GET to retrieve running configuration, d= o we > > > want > > > > > to note that since the data channel can fail during attack time, = it's > > > > > expected to be common to perform such a GET before attempting to = make > > > > > modifications to configuration? > > > > > > > > [Med] The data channel is supposed to be invoked when no attack is > ongoing. > > > Normal RESTCONF operations are therefore followed. I don't see the ne= ed > to > > > add a note. > > > > > > I always have to consider edge cases in my IESG reviews -- what happe= ns > if > > > an attack starts after the request is sent but before the response is > > > received? > > > > [Med] The dots client will know if its request is successfully delivere= d. > When an attack is ongoing, the dots client should not use it data channel > because it is likely to be perturbed. >=20 > (There was some further discussion with Med and Tiru but I seem to have > lost track of the resolution.) [Med] The conclusion is that how the client syncs with the server is implem= entation-specific. An implementation note may be added.=20 >=20 > > > > > > > > > > > > > A DOTS client registers itself to its DOTS server(s) in order = to > set > > > > > up DOTS data channel-related configuration data and receive st= ate > > > > > data (i.e., non-configuration data) from the DOTS server(s) > > > > > (Section 5). Mutual authentication and coupling of signal and > data > > > > > channels are specified in [I-D.ietf-dots-signal-channel]. > > > > > > > > > > I think we should split the "mutual authentication" and "coupling= of > > > signal > > > > > and data channels" into their own sentence, and flesh them out > slightly > > > > > more. So, section references to Sections 8 and 4.4.1, respective= ly, > the > > > > > usage of TLS client certificates, the coupling of channels via th= e > > > client's > > > > > identity ('cuid' and 'cdid'), etc. > > > > > > > > [Med] Done. > > > > > > > > > > > > > > A TLS heartbeat [RFC6520] verif= ies > > > > > that the DOTS server still has TLS state by returning a TLS > message. > > > > > > > > > > I expect this will get some pointed comments during IETF LC, give= n > the > > > > > recent-ish IETF-wide discussions about heartbeats/keepalives in > general. > > > > > Is there perhaps a RESTCONF-level probe message that could be use= d to > > > check > > > > > liveliness; a capabilities query perhaps? > > > > > > > > [Med] There is no such mechanism. The approach in the data channel > draft is > > > aligned with RFC8071 for keepalives. > > > > > > I guess we'll just have to wait to see what kind of comments we get, > then. > > > (Thanks for the pointer to 8071.) > > > > > > > > > > > > > A DOTS server may detect conflicting filtering requests from > distinct > > > > > DOTS clients which belong to the same domain. For example, a = DOTS > > > > > client could request to drop-list a prefix by specifying the > source > > > > > prefix, while another DOTS client could request to accept-list > that > > > > > same source prefix, but both having the same destination prefi= x. > It > > > > > is out of scope of this specification to recommend the behavio= r to > > > > > follow for handling conflicting requests (e.g., reject all, re= ject > > > > > the new request, notify an administrator for validation). DOT= S > > > > > servers SHOULD support a configuration parameter to indicate t= he > > > > > behavior to follow when a conflict is detected. Section 7.2 > > > > > specifies the behavior when no instruction is supplied to a DO= TS > > > > > server. > > > > > > > > > > I'm a bit confused by the "out of scope of this specification to > > > recommend > > > > > the behavior to follow for handling conflicting requests", since = not > only > > > > > does the last sentence of the paragraph give a pointer to a speci= fied > > > > > behavior in case of conflicts, but we also mention it in a couple > other > > > > > places (e.g., the bottom of page 43). > > > > > > > > [Med] The specified behavior is a default behavior, not a recommend= ed > one. > > > > > > In effect a default is a recommendation, though -- a recommendation f= or > > > what to do if you don't know any better. Perhaps "it is out of scope= of > > > this specification to provide guidance on how conflicting requests ma= y be > > > safely handled, with the default behavior being to reject such reques= ts"? > > > > [Med] I went for this updated text: > > > > DOTS servers SHOULD support a configuration parameter to indicate th= e > > behavior to follow when a conflict is detected (e.g., reject all, > > reject the new request, notify an administrator for validation). > > Section 7.2 specifies a default behavior when no instruction is > > supplied to a DOTS server. >=20 > Works for me. >=20 > > > > > > > I update this text: > > > > > > > > If the request is conflicting with an existing filtering install= ed > by > > > > another DOTS client of the domain, and absent any local policy, = the > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > That helps (maybe the "and" is not even needed?). Do you want to do = a > > > sweep for other places where the text talks about 409 responses? > > > > [Med] OK. > > > > > > > > > DOTS server returns "409 Conflict" status-line to the requesting > DOTS > > > > client. The error-tag "resource-denied" is used in this case. > > > > > > > > > > > > > > Also in that paragraph, it's unclear that a 2119 SHOULD is > appropriate > > > for > > > > > "support a configuration parameter"; there's no interoperability > > > > > considerations for having or not having such a configuration knob= . > > > > > > > > [Med] This is important for interoperability (or at least for ensur= ing > a > > > deterministic behavior). E.g., during service subscription a technica= l > clause > > > may be negotiated out of band how to deal with conflicts from clients= of > the > > > same domain. > > > > > > It seems that the default behavior of disallowing conflicts would alw= ays > be > > > interoperable, but I'm happy to leave this as-is for now. > > > > > > > > > > > > > Section 3.3 NAT Considerations have "high overlap" with the > > > > > text at the end of the signal-channel's "Design Overview". At a > minimum > > > we > > > > > should diff them and enforce convergence, but do we want to consi= der > just > > > > > having one refer to the other? > > > > > > > > [Med] Makes sense. Section 3.3 is now deleted and replaced with thi= s > NEW > > > text: > > > > > > > > NAT considerations for the DOTS data channel are similar to thos= e > > > > discussed in Section 3 of [I-D.ietf-dots-signal-channel]. > > > > > > Cool, thanks. > > > > > > > > > > > > > Section 3.5 > > > > > > > > > > I had to read up on RESTCONF and NETCONF while reviewing this, bu= t > from > > > > > what I've seen so far, the "error-severity" field is only present= in > > > > > NETCONF and not RESTCONF. If so, then we shouldn't need to talk > about it > > > > > here, since we use RESTCONF exclusively. I also couldn't find > whether > > > > > there's a registry that we should add the "loop-detected" error-t= ag > to. > > > > > Can anyone here help me out? > > > > > > > > > > > > > [Med] We used the template in > https://tools.ietf.org/html/rfc6241#appendix- > > > A because the errors in 8040 are the ones imported from there. > > > > > > Thanks for the pointer. It sounds like I'll need to ask around abou= t > this > > > one. > > > > [Med] I checked this with Martin Bjorklund. He confirmed that the error > list in 6241 is fixed in the protocol version. He recommended to go with = app- > tags. Our error will look like the following: > > > > OLD: > > error-tag: loop-detected > > error-type: transport, application > > error-severity: error > > error-info: : A copy of the Via header when > > the loop was detected. > > Description: An infinite loop has been detected when forwardin= g > > a requests via a proxy. > > > > NEW: > > > > error-app-tag: loop-detected > > error-tag: operation-failed > > error-type: transport, application > > error-severity: error > > error-info: : A copy of the Via header when > > the loop was detected. > > Description: An infinite loop has been detected when forwardi= ng > > a requests via a proxy. >=20 > Thanks! I will try to remember to solicit a YANG doctors review during > IETF LC if it does not get scheduled automagically. >=20 > > > > > > > There is no registry for the errors; only a YANG module which is no= t > > > maintained by IANA. This is why no action is included in the IANA > section. > > > > > > > > > Section 4.2 > > > > > > > > > > Is there any plan/expectation for filtering/match rules for QUIC?= It > is > > > > > probably premature to put anything in this document specifically,= but > > > still > > > > > worth thinking about. > > > > > > > > [Med] Some of the existing fields can be already reused for QUIC (U= DP, > port > > > number). There are few fields in the QUIC public header that are > available > > > (public flags, CID, version). A match on the first N bytes of the UDP > payload > > > can be considered but I do think this is not mature enough. > > > > > > > > The key point is that our module is extensible. > > > > > > Indeed. > > > > > > > > > > > > > The order in which the leaves appear in the "capabilities/ipv6" a= nd > > > > > "capabilities/tcp" subtrees do not match the order they appear in= the > ACL > > > > > subtree itself; it would be good to keep the order consistent. > > > > > > > > [Med] Fixed. > > > > > > > > FWIW, the order in capabilities/* follows the order of the fields a= s > they > > > appear in the header. We don't have a control on the ACL order becaus= e we > are > > > reusing an external module. > > > > > > Ah, good to know. > > > > > > > > > > > > > We don't really say much about what the semantis of the "port-ran= ge" > > > > > capabilities are; is that supposed to indicate any port-matching > ability > > > at > > > > > all, or specifically the low-to-high range matching, or also the > > > "operator" > > > > > options? > > > > > > > > [Med] Updated as follows: > > > > > > > > OLD: > > > > "Support of filtering based on a port range."; > > > > > > > > NEW: > > > > > > > > "Support of filtering based on a port range. > > > > > > > > This includes filtering based on a source port range, > > > > destination port range, or both. All operators > > > > (i.e, less than or equal, greater than or equal, equa= l > to, > > > > and not equal to) are supported."; > > > > > > Thanks! > > > > > > > > > > > > > Section 4.3 > > > > > > > > > > We define an "operator" typedef that is rather different from tha= t > from > > > > > netmod-acl-model. Do we want to use a different name to aid > > > > > disambiguation? ("bitmask-operator" comes to mind as an option.) > > > > > > > > [Med] It is not recommended in yang to use prefixes to disambiguate > nodes. > > > The disambiguation is ensured by the context/position in the tree. Fo= r > > > example, this is why we are using name and not acl-name or ace-name, = etc. > I > > > will leave the text as it is. > > > > > > For names this makes natural sense to me, but this question is about = a > > > typedef. I have less clear of a picture for how typedefs are or are = not > > > namespaced (is it just per-module?). > > > > > > > [Med] They are namespaced. For example: > > > > type operator; > > > > is about the operator defined in the module itself. But, if we use: > > > > type packet-fields:operator; > > > > this means the operator is the one imported from ietf-packet-fields. >=20 > Ah, thanks for the YANG lesson. >=20 > > > > > > > > > > > > typedef fragment-type { > > > > > type bits { > > > > > bit df { > > > > > position 0; > > > > > description > > > > > "Don't fragment bit for IPv4. > > > > > This bit must be set to 0 for IPv6."; > > > > > > > > > > Set to zero by whom? What should the receiver do if it is set > otherwise? > > > > > > > > > > > > > [Med] In IPv6, fragmentation is only done by the source. Hence, thi= s > value > > > for IPv6. A fragment-type with the first bit set will be discarded by= the > > > server. > > > > > > I was looking for a few more words in the text, like "must be set to = 0 > when > > > it appears in an IPv6 filter". > > > > [Med] OK. > > > > > > > > > > What are the semantics if (either or both of target-fqdn and targ= et- > uri) > > > > > and target-prefix are specified? (I suppose maybe this could be > covered > > > in > > > > > Section 6.1 when we say that at least one is required in ACL-crea= tion > > > > > requests.) > > > > > > > > [Med] The resulting IP prefixes/addresses will be bound to the alia= s. > Added > > > the following in Section 6.1: > > > > > > > > If more target-* clauses (e.g., 'target-prefix' and 'target-fqdn= ') > > > > are included in a POST or PUT request, the DOTS server binds all > > > > resulting IP addresses/prefixes to the same resource. > > > > > > > > > > > > > > The units for the "rate-limit" node should be specified in the YA= NG > > > module > > > > > and not in the description of how to install filtering rules. > > > > > > > > [Med] Added "units" to the YANG module. > > > > > > > > > > > > > > list dots-client { > > > > > key "cuid"; > > > > > description > > > > > "List of DOTS clients."; > > > > > leaf cuid { > > > > > type string; > > > > > description > > > > > "A unique identifier that is randomly generated by > > > > > a DOTS client to prevent request collisions."; > > > > > > > > > > I don't think "randomly generated" is really correct here. > > > > > > > > [Med] Changed to: > > > > > > > > "A unique identifier that is generated by a DOTS client > > > > to prevent request collisions."; > > > > > > > > > > > > > > The "capabilities/icmp/rest-of-header" description should be more > clear > > > > > that (per draft-ietf-netmod-acl-model) it is supposed to match bo= th > the > > > > > ICMP four-byte field and the ICMPv6 message body. > > > > > > > > [Med] OK. > > > > > > > > > > > > > > Section 5.1 > > > > > > > > > > It may be worth reiterating that (per the signal-channel doc) > gateways > > > may > > > > > rewrite the 'cuid'. > > > > > > > > [Med] OK: > > > > > > > > As a reminder, DOTS gateways may rewrite the 'cuid' used by peer > DOTS > > > > clients (Section 4.4.1 of [I-D.ietf-dots-signal-channel]). > > > > > > > > > > > > > > When POST is used to create a dots-client resource, how does the > client > > > > > know the path of the created resource (to be used for subsequent > RESTCONF > > > > > requests)? (I assume it is supposed to just use the submitted > 'cuid', > > > but > > > > > we need to explicitly say this. This also seems to render much o= f > the > > > > > distinction between POST and PUT moot, for our usage, though I do= not > > > > > propose any change to the text.) > > > > > > > > [Med] The procedure to determine the root path is recalled in Secti= on > 3.1, > > > then normal RESTCONF operation is followed. > > > > > > > > > > > > > > The DOTS gateway, that inserted a 'cdid' in a PUT request, MUS= T > strip > > > > > the 'cdid' parameter in the corresponding response before > forwarding > > > > > the response to the DOTS client. > > > > > > > > > > Why does this apply only to PUT and not POST? > > > > > > > > [Med] Because RFC8040 says the following: > > > > > > > > If the POST method succeeds, a "201 Created" status-line is retu= rned > > > > and there is no response message-body. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > Whoops, I clearly missed that part. Thanks for calling it out. > > > > > > > > > > > > > Section 6.1 > > > > > > > > > > DOTS clients within the same domain can create different alias= es > for > > > > > the same resource. > > > > > > > > > > My reading of this text is that client A can create alias "foo" f= or > IP > > > > > prefix 128.0.1.5/31 and clinet B can create alias "bar" for the s= ame > IP > > > > > prefix, and that DOTS supports that process. (Just to confirm th= at > the > > > > > text is saying what it's intended to.) > > > > > > > > [Med] Yes. > > > > > > > > I do wonder if we want to say > > > > > something about whether alias names need only be unique per 'cuid= ' or > in > > > > > some more global fashion. (Having a global uniqueness property i= s > > > perhaps > > > > > convenient in order to interface with non-DOTS mechanisms for > querying > > > > > aliases, or for the DOTS server to interact with network filterin= g > > > > > appliances.) > > > > > > > > [Med] The specification does require uniqueness per cuid: > > > > > > > > | +--rw aliases > > > > | | +--rw alias* [name] > > > > | | +--rw name string > > > > > > > > We don't have a requirement for uniqueness per domain or globally. > > > > > > > > If such requirement arise, the semantic/logic for creating those > aliases > > > can be handled out of band. > > > > > > Ok. > > > > > > > > > > > > > Figure 16 puts double-quotes around "string" in the pseudo-schema= , > which > > > > > feels weird to me. > > > > > > > > [Med] This is also what we have done for other figures , e.g., 11. = The > > > intent is to use a scheme-like message body while trying to preserve = JSON > > > compliance. > > > > > > > > > > > > > > target-fqdn: A list of Fully Qualified Domain Names (FQDNs).= An > > > > > FQDN is the full name of a resource, rather than just its > > > > > hostname. For example, "venera" is a hostname, and > > > > > "venera.isi.edu" is an FQDN [RFC1983]. Refer to > > > > > [I-D.ietf-dnsop-terminology-bis] for more details. > > > > > > > > > > I don't think this text is particularly well-aligned with RFC 849= 9 > and > > > > > would suggest trimming it substantially and just pointing to that > RFC. > > > > > > > > [Med] Done. > > > > > > > > > > > > > > If the request is missing a mandatory attribute or its contain= s an > > > > > invalid or unknown parameter, "400 Bad Request" status-line MU= ST > be > > > > > returned by the DOTS server. The error-tag is set to "missing= - > > > > > attribute", "invalid-value", or "unknown-element" as a functio= n of > > > > > the encountered error. > > > > > > > > > > This text seems to preclude any future extension that adds new er= ror > > > tags; > > > > > is this intended? > > > > > > > > [Med] Those errors are only about the tree failure cases called in = the > > > first sentence. > > > > > > > > > > > > > > Section 7.1 > > > > > > > > > > A DOTS client which issued a GET request to retrieve the filte= ring > > > > > capabilities supported by its DOTS server, SHOULD NOT request = for > > > > > filtering actions that are not supported by that DOTS server. > > > > > > > > > > What is the server behavior if the client ignores this SHOULD NOT= ? > > > > > > > > [Med] This is covered by this text: > > > > > > > > If the request is missing a mandatory attribute or > > > > contains an invalid or unknown parameter (e.g., a match field no= t > > > > supported by the DOTS server), "400 Bad Request" status-line MUS= T be > > > > returned by the DOTS server in the response. > > > > > > sounds good. > > > > > > > > > > > > > Figure 23 shows an example of a response received from a DOTS > server > > > > > which only supports the mandatory filtering criteria listed in > > > > > Section 4.1. > > > > > > > > > > This seems inaccurate, as the mandatory filtering criteria exlude= the > > > > > rate-limit among others. > > > > > > > > [Med] rate-limit is an action, not a filtering criteria. > > > > > > > > > > > > > > Section 7.2 > > > > > > > > > > activation-type: Indicates whether an ACL has to be activated > > > > > (immediately or during mitigation time) or instantiated wit= hout > > > > > being activated (deactivated). Deactivated ACLs can be > activated > > > > > using a variety of means such as manual configuration on a = DOTS > > > > > server or using the DOTS data channel. > > > > > > > > > > Is this done by the data channel or the signal channel? > > > > > > > > [Med] Yes, but this is not supported in the base signal-channel spe= c. > This > > > is the done using the filtering control feature (draft-nishizuka-dots= - > signal- > > > control-filtering). This is why signal channel is not listed after "s= uch > as". > > > > > > Okay. (I was literally just wondering if this was a typo.) > > > > > > > > > > > > > If this attribute is not provided, the DOTS server MUST use > > > > > 'activate-when-mitigating' as default value. > > > > > > > > > > Why do we specify default values here instead of in the YANG modu= le? > > > > > > > > [Med] There is no default statement for enumeration. To solve this,= a > new > > > type is defined in the module (activation-type). This type is then us= ed > for > > > the activation-type leaf with a default value set to activate-when- > > > mitigating. > > > > > > That's a clever workaround! > > > > > > > The change in tree diagram is (no need to insert the code here): > > > > > > > > OLD: > > > > | +--rw activation-type? Enumeration > > > > > > > > NEW: > > > > | +--rw activation-type? activation-type > > > > > > > > > > > > > > > > > > Filters that are activated only when a mitigation is in > progress > > > > > MUST be bound to the DOTS client which created the filterin= g > rule. > > > > > > > > > > Other filters do not need to be bound to the DOTS client that cre= ated > > > them? > > > > > > > > [Med] They are...but those filters are already enforced because the= y > are > > > immediate. > > > > > > The wording here is still weird, though -- by calling out the > > > delayed-activation filters it implies that immediate-activation filte= rs > are > > > excluded from the statement, but we know that immediate-activation > filters > > > also have the same property. So I'm not entirely sure exactly what > > > information this sentence is intended to call out. > > > > [Med] When a mitigation is in progress, only the filters bound to the > client which triggered the mitigation have to be activated. 'activate-whe= n- > mitigating' filters of other clients of the same domain should not be > activated: > > > > I changed the text as follows: > > > > OLD: > > Filters that are activated only when a mitigation is in progress > > MUST be bound to the DOTS client which created the filtering rule= . > > > > NEW: > > When a mitigation is in progress, the DOTS server MUST only > > activate 'activate-when-mitigating' filters that are bound to the > > DOTS client which triggered the mitigation. >=20 > That looks great; thanks. >=20 > -Ben >=20 > > > > > > > > Wouldn't we still want to remove them when the dots-client resour= ce > in > > > > > question is deleted? > > > > > > > > [Med] This is supposed to be done by the client itself. For amnesia= c > > > clients, we do have the following: > > > > > > Oh. I think I was remembering Section 5.2's "resources bound to this > DOTS > > > client will be deleted by the DOTS server" and assuming it applies to= the > > > filters associated with that client. > > > > > > > In order to avoid stale entries, a lifetime is associated with a= lias > > > > and filtering entries created by DOTS clients. Also, DOTS serve= rs > > > > may track the inactivity timeout of DOTS clients to detect stale > > > > entries. > > > > > > This is probably enough to ensure safe operation without the above, > though, > > > hmm... > > > > > > > > > > > > > destination-ipv4-network: The destination IPv4 prefix. DOTS > servers > > > > > [...] > > > > > This is a mandatory attribute in requests with an 'activati= on- > > > > > type' set to 'immediate'. > > > > > > > > > > I somehow thought there were YANG attributes that could indicate = this > > > > > conditional requirement in the module itself, though I am hardly = a > YANG > > > > > expert. > > > > > > > > [Med] We are reusing fields from ietf-netmod-acl, it is not easy to > > > manipulate the fields as we would want. > > > > > > Okay. > > > > > > > > > > > > > The error-tag is= set > to > > > > > "missing-attribute", "invalid-value", or "unknown-element" as = a > > > > > function of the encountered error. > > > > > > > > > > Same comment as above about (non-)extensibility. > > > > > > > > [Med] Idem as above. > > > > > > > > > > > > > > Section 7.3 > > > > > > > > > > I see that the "test-acl-*" and "test-ace-*" acl and ace objects = in > these > > > > > examples do in fact use different names for the semantically > different > > > > > objects, but perhaps we could help the reader's eye and use strin= gs > with > > > a > > > > > larger Hamming distance? (I thought they were all the same on my > first > > > > > read.) > > > > > > > > [Med] Fixed. > > > > > > > > > > > > > > (I also am a little confused at why the "ace" "name" field is > considered > > > a > > > > > non-config field, in Figure 31, but this seems more likely to be = my > > > > > confusion than an error in the document.) > > > > > > > > [Med] This is because the name is the key of the ace list. > > > > > > > > RFC8040 says the following: > > > > > > > > To retrieve only the non-configuration child resources, the > "content" > > > > parameter is set to "nonconfig". Note that configuration ancest= ors > > > > (if any) and list key leafs (if any) are also returned. > > > > > > Thanks for the pointer. > > > > > > > > > > > > > Section 8 > > > > > > > > > > o DOTS server MUST NOT enable both DOTS data channel and dire= ct > > > > > configuration to avoid race conditions and inconsistent > > > > > configurations arising from simultaneous updates from multi= ple > > > > > sources. > > > > > > > > > > o DOTS agents SHOULD enable DOTS data channel to configure > aliases > > > > > and ACLs, and only use direct configuration as a stop-gap > > > > > mechanism to test DOTS signal channel with aliases and ACLs= . > > > > > Further, direct configuration SHOULD only be used when the = on- > path > > > > > DOTS agents are within the same domain. > > > > > > > > > > Doesn't all this discussion of "direct configuration" conflict wi= th > the > > > > > "MUST NOT" in the first bullet point? > > > > > > > > [Med] The second bullet is about controlled testing of the *signal > channel* > > > with aliases/acls communicated by the data channel. > > > > > > Whoops, my misread. > > > > > > > > > > > > > Section 10 > > > > > > > > > > Generally with the security considerations template for YANG modu= les, > we > > > > > need to list out all the nodes considered sensitive and the > consequences > > > of > > > > > writing(/reading) each one in turn. > > > > > > > > > > > > > [Med] The text does already call out those that are specific to thi= s > > > document. For other nodes, we do have this text: > > > > > > > > "YANG ACL-specific security > > > > considerations are discussed in [I-D.ietf-netmod-acl-model]." > > > > > > > > I think we are OK. > > > > > > I would suggest adding a new sentence in the "All data nodes defined" > > > paragraph about "This module reuses YANG structures from > > > [I-D.ietf-netmod-acl-model], and the security considerations for thos= e > > > nodes continue to apply for this usage.", since that text is at the o= ther > > > end of the section and it's otherwise hard to make a linkage between > them. > > > > > > > [Med] OK. > > > > > Thanks, > > > > > > Ben From nobody Wed Feb 27 06:33:44 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F06130EBD; Wed, 27 Feb 2019 06:33:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk CC: rdd@cert.org, dots@ietf.org, Roman Danyliw , dots-chairs@ietf.org, draft-ietf-dots-data-channel@ietf.org, kaduk@mit.edu Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <155127802240.13985.12710692781572812550.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2019 06:33:42 -0800 Archived-At: Subject: [Dots] Last Call: (Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification) to Proposed Standard X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 14:33:43 -0000 The IESG has received a request from the DDoS Open Threat Signaling WG (dots) to consider the following document: - 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-03-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; o reference: RFC XXXX Please update the "revision" date of the YANG module. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 27 06:45:09 2019 Return-Path: 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 BC24C130FD9; Wed, 27 Feb 2019 06:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 UvdFElpjkSmx; Wed, 27 Feb 2019 06:45:04 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770132.outbound.protection.outlook.com [40.107.77.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35603130FCF; Wed, 27 Feb 2019 06:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UtpA/Tc3sOqTyh1ilUnU2ON1OHaewKFiK8pJ+NhKN2E=; b=TljE2fxY4AOtV0HmxFdW6AElEYiBcFy4BHbu/YCXL5epp1kVUa7HOH4DWmoXRjCi0HVOtyfwZuDOzV81lVQsU9DMLlwYfpoXfVUyCn3v2PonU/s8ANan9jZwI7o/o08yyaVlkqcPebUiWv5O8zAy7bGTTegtFCfeVxUm+5stx14= Received: from MN2PR01CA0011.prod.exchangelabs.com (2603:10b6:208:10c::24) by DM6PR01MB4857.prod.exchangelabs.com (2603:10b6:5:6d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Wed, 27 Feb 2019 14:45:02 +0000 Received: from CO1NAM03FT003.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::200) by MN2PR01CA0011.outlook.office365.com (2603:10b6:208:10c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.15 via Frontend Transport; Wed, 27 Feb 2019 14:45:01 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT003.mail.protection.outlook.com (10.152.80.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 27 Feb 2019 14:45:01 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1REivD2031210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Feb 2019 09:44:59 -0500 Date: Wed, 27 Feb 2019 08:44:57 -0600 From: Benjamin Kaduk To: CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190227144456.GJ53396@kduck.mit.edu> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227041011.GG53396@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA25FC4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA25FC4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(346002)(376002)(2980300002)(52314003)(189003)(199004)(52284002)(54906003)(106002)(8676002)(246002)(2351001)(23756003)(956004)(6916009)(86362001)(478600001)(26826003)(36906005)(8936002)(5660300002)(7696005)(76176011)(229853002)(356004)(106466001)(305945005)(53416004)(55016002)(66574012)(1076003)(58126008)(30864003)(786003)(316002)(93886005)(2906002)(4326008)(6246003)(47776003)(486006)(476003)(14444005)(126002)(33656002)(11346002)(446003)(336012)(426003)(26005)(186003)(75432002)(104016004)(2870700001)(88552002)(50466002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4857; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c1357eb5-8c37-4d2f-7976-08d69cc2274b X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:DM6PR01MB4857; X-MS-TrafficTypeDiagnostic: DM6PR01MB4857: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4857; 20:lrmEl5xEZTf4SX0Sp3oHZibI/6WE8eqp6l3xs+uiiNZic6EesUC5PDBpaj1xQv6LOGjDfzKGCUcHLBcpWjWS2o6HiRemHd7hQOVPrLKVxTbuvf2NC6UyKqa2zDgAWdDAcfLtNOoFWleprasXiFr+JlE81ZW7UwvriX0ewtV8pDjuLNU7dg5tf93jtpL1FPZJj3cbPNBJPzoJ2dnSpvJRcMRNnE7QFwVW5uKn5rClaHsbtVbNFaSq6Isye90IOgTB/spgD/JTY9Vxawc648Psrf/0zzeX2uMcNnQMjSK3U5Mk6rJ2XEjurj5DCIhI3njT8dAAm8RNDt6g8yhgF0kbKal1US18T+cJycvNsSEdHreXw55Y3QgU2Es/1dpR+Iq/hylieskJR0JhBDhtgynNcZqa6dwZry3Pm+pgy7uUXm7AyF2S7S1ehsm/1yymqSZHBSY8wfjfdVzuD80mmAywSNicONysJZId1ka6bNH09izJd6/zE2dTmx/p50n7pNxK2poc92XAyZmx3BmL653AdyUOwBGgSc1gkJKYYVAr5wMxf2HfVSmccne7Viy1Qk5Lnzjpnn37KLVQcmabhqdvL/4k9GRnPsR6SuLFnYnk5d0= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM6PR01MB4857; 23:35eDv6hd/DN6XGbExhQWTHz7INKGOLb/Zfp0TFf?= =?iso-8859-1?Q?Bm9qaq1eTLcBVMKfbvMqUiJw9wVAQxVXCfKELYlCfuTnvMJPFAEYfjZkAN?= =?iso-8859-1?Q?FmYTTjgKZ/2IxCB2aOv+7A71P8dHj6KPg0hYqrU62cvqsTvF4q/+VoL3xl?= =?iso-8859-1?Q?zJrtnQvG/MFfauqP4PAD+2yKRbRi0STToWUYBzOmPZmNDa/abRxIPF49hh?= =?iso-8859-1?Q?QvrT3LPNvV01OuVXoY3pyY+iESyU1faOkNLPrguw0ReWntHMRx+suyeA2M?= =?iso-8859-1?Q?tOnLkARmLB2XZ+9PtPgHWumtsUiTQ4lvD0WCYFQ/FB1JYUO8pthg4xUddK?= =?iso-8859-1?Q?vh2sJDTih+qThn05njvx0Iia+Rbyt4U0ZrFZ48hJeBHKjBXJuY8kHwKxXP?= =?iso-8859-1?Q?mhYLLVW1RWfrG7JK7X5VF40PBnZV5MtMrZ8QY4ZhySmFrJsRYVndkOUbWx?= =?iso-8859-1?Q?ZVEVpKiyKciTfpB/E+9T3nDc35v9XPBf8M8fXs3cS36zFSkasB2CvHvfVv?= =?iso-8859-1?Q?O+i6lc1n7aFFkYu5WRMDZ0pb5HEST6g4Bf1AwC3M0Xxjeqxyqd+By8WVng?= =?iso-8859-1?Q?roiiBBNo5u+SZ7iRmMBEG6NSVQwl5a3fWrwj1vNnH6ikUU2JwA6NsIvqvY?= =?iso-8859-1?Q?PnUjwCGyDhn62rMtAuWu3E3EeZsPVeiTMU402SzHY6OT16oaD0Qx158Oc/?= =?iso-8859-1?Q?Cv+mTFmjXoqJtkRJlTEM4w7L9H1aeeR+N8lJPPXZzzNbJTrrVRQAz+5pnS?= =?iso-8859-1?Q?6QZccUtFFfYDy4FCv6m9tyiq1H+c12k7JDhBc4AhJuBWiVequgLDpWxvTL?= =?iso-8859-1?Q?ou1sidqTWmZDO0X3A/3QKU+kR1NtgnZUhpAjlpRvA0V7mwYkmLWN3HoJzY?= =?iso-8859-1?Q?Wd7RgvM/JXEtqQiyXuz45fxUm77K1d65gn8P8wsPdqr97GrP2gHBmTFXps?= =?iso-8859-1?Q?R7YW78z3qMSTJfGPs3RjKNPzTTFWT9x/97ijJTYbYXxAyLEPvZ+T90A8fe?= =?iso-8859-1?Q?gxCOonfDt0nwHi2/EsoSPbCwnRwbL0Ur0QPODOMIhu4h5OKXfH6FG5uB1E?= =?iso-8859-1?Q?wJb5e+JMcNa0xLVmt37ej3zHVH0+OU7ssJ4DWEMUADVOro6zbKZBtHRgE0?= =?iso-8859-1?Q?/wFGDGH8iSMssShaepWfZlYrVvA7bTAQbjmk8ekvpqbb7tjvAGQuRT5KzA?= =?iso-8859-1?Q?b0w8RfrcDh+mr2zpTTW0x2EwrUFLA7wd5dM28srWc2ymm5X0oB8Cd2FFPy?= =?iso-8859-1?Q?TLl+PN2aGPBkLz4SHGm7IaLSa09D40Apt0Ap815dfdBIIPnBU2dcG7Ga8m?= =?iso-8859-1?Q?brekgIUF4ZNVTip91ATuNdhBy8a6bOAgAoYBO5BWCoxIwTcDM1NrYKNY7y?= =?iso-8859-1?Q?mBihOvwQ=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 9+zfpVEnxUepm7kv2NEOx9uvHhw28bVfAZKrks61+6NGzE+jLZNqI2Licje5vhSR2ktm9weeCGsybQzc8kiN9QaiKc66vywPQwd3MNpqE3rsx3tpGnUyLh2Y7Vf+vv5nWJ7NSxvmtHYSMQrrnS6GXfEatL98GkPZwLHSvidoqLms4KIwuKcrB2E3GviG+aPQV4+5DtrMxM82IOtmkiQWA5UTgJN75Q+wScmmRrutdxH1AzUGa0cIK0vQJU+c31Fci4as+NVes0V5xUw/823F8g8qr6cNVHwPAP2KSWEnJrmMH0/cYUhdYb17RATeZXkvbpI1DGUYFu7oogPS6j5MJrltqsbKznvTUzvC7/W8JZHWjLdHkSK68891Zyu0wE7AQmltvH2OiD5jQfygiSeotE83ZBE4n4JRio4NnJRxZp0= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2019 14:45:01.3117 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c1357eb5-8c37-4d2f-7976-08d69cc2274b X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4857 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 14:45:07 -0000 On Wed, Feb 27, 2019 at 10:25:36AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : mercredi 27 février 2019 05:10 > > À : BOUCADAIR Mohamed TGI/OLN > > Cc : draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > > Objet : Re: AD review of draft-ietf-dots-data-channel-25 > > > > On Fri, Feb 15, 2019 at 09:36:26AM +0000, mohamed.boucadair@orange.com wrote: > > > Hi Ben, > > > > > > Please see inline. > > > > > > > Thanks. The -27 is in good enough shape that I've requested the IETF last > > call; we can finish discussing the last few topics here in parallel. > > > > [Med] Sure. > > > > > > > > -----Message d'origine----- > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > Envoyé : jeudi 14 février 2019 20:17 > > > > À : BOUCADAIR Mohamed TGI/OLN > > > > Cc : draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > > > > Objet : Re: AD review of draft-ietf-dots-data-channel-25 > > > > > > > > Hi Med, > > > > > > > > On Thu, Feb 14, 2019 at 02:31:26PM +0000, mohamed.boucadair@orange.com > > wrote: > > > > > Hi Ben, > > > > > > > > > > Thank you for the review. > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > > > Envoyé : mercredi 13 février 2019 17:46 > > > > > > À : draft-ietf-dots-data-channel@ietf.org > > > > > > Cc : dots@ietf.org > > > > > > Objet : AD review of draft-ietf-dots-data-channel-25 > > > > > > > > > > > > This is my AD review of the -25 > > > > > > > > > > > > I see that Med made a commit on github that preemptively addressed at > > > > least > > > > > > one of these comments, but will trust the authors to do to the right > > > > thing > > > > > > with anything in here that's stale. > > > > > > > > > > > > A handful of generic and/or high-level comments before the > > > > > > section-by-section nitty-gritty stuff. > > > > > > > > > > > > The author count is large (7); RFC 7322 notes that the stream > > approver > > > > > > (i.e., the IESG) will ask questions if the count is more than five. > > What > > > > > > should I tell people when they ask? (The authors are listed also in > > the > > > > > > YANG module itself, if changes are made.) > > > > > > > > > > [Med] Actually, the set of co-authors of the YANG module is not exactly > > the > > > > same. > > > > > > > > Whoops, my bad for not checking. > > > > > > > > > Anyway, in order to comply with the rules and avoid spending extra > > cycles > > > > on this, we added a new section called "Contributing Authors". > > Nevertheless, > > > > the set of authors is not modified in the YANG module. > > > > > > > > Thanks. (To be clear, I'm happy to go to bat for everyone with the IESG > > > > for this sort of thing, I just need an argument to present that's not me > > > > making things up.) > > > > > > > > I don't know of a specific policy for YANG module authorship, so that > > part > > > > should be okay as far as I know. > > > > > > > > > > > > > > > > Can someone (the shepherd?) confirm that an automated syntax checker > > has > > > > > > run over the JSON in examples? > > > > > > > > > > > > The concept of "DOTS client domain" is being used for actual protocol > > > > > > purposes here (most notably as a bound on the prefix(es) that a > > client > > > > can > > > > > > request mitigation for, but I don't remember seeing a formal > > definition > > > > for > > > > > > how any DOTS actor would know the specific bounds of such a client > > > > domain. > > > > > > Is there text somewhere that I missed that we can point to, or will > > we > > > > need > > > > > > to add some? > > > > > > > > > > [Med] Both "DOTS client domain" and "DOTS server domain" are used in > > the > > > > architecture draft. "DOTS client's domain" and "DOTS server's domain" are > > > > also used in the architecture and requirements I-D. > > > > > > > > > > If a formal definition is needed, I prefer this to be done in the > > > > architecture or the requirements I-D. > > > > > > > > I think it would be a somewhat better fit in the architecture document, > > > > just to note that the "domain" is something that can concretely be > > > > demarcated by IP addresses/prefixes (as opposed to a more nebulous > > concept > > > > to aid conceptual understanding). > > > > > > > > > > [Med] Let's add that text into the architecture I-D. > > > > Okay. Tiru had a follow-up about how servers can identify DOTS client's > > domains, which is okay but not quite what I was aiming for. In the text > > Tiru quoted, we note that > > > > The DOTS server enforces authorization of DOTS clients' signals for > > mitigation. The mechanism of enforcement is not in scope for this > > document, but is expected to restrict requested mitigation scope to > > addresses, prefixes, and/or services owned by the DOTS client's > > administrative domain, such that a DOTS client from one domain is not > > able to influence the network path to another domain. > > > > I was hoping to see something like "For a given client (administrative) > > domain, the DOTS server needs to be able to determine whether a given > > resource is in that domain. This could take the form of associating a set > > of IP Prefixes per domain, for example." But I'm open to being persuaded > > that the existing text conveys the same meaning. > > > > [Med] Your proposed wording can be added to the architecture I-D, IMHO. > > FWIW, we do have this text in the protocol spec: > > DOTS servers MUST verify that requesting DOTS clients are entitled to > enforce filtering rules on a given IP prefix. That is, only > filtering rules on IP resources that belong to the DOTS client's > domain can be authorized by a DOTS server. The exact mechanism for > the DOTS servers to validate that the target prefixes are within the > scope of the DOTS client's domain is deployment-specific. To me that text is just reading that it mandates authorization checks, whereas the text in the data-channel document that prompted this comment has me thinking that the DOTS server needs an explicit mapping between "DOTS client domain" and "this set of IP addresses and/or other identifiers", which is a slightly different thing. > > > > > > > > > > > > We don't say much about what validation the server does on input > > data, > > > > and > > > > > > we probably should. For example, does the server need to validate > > 'cuid' > > > > > > > > > > [Med] We avoided to be redundant here. This is covered by this text: > > > > > > > > > > "This attribute has the same > > > > > meaning, syntax, and processing rules as the 'cuid' attribute > > > > > defined in [I-D.ietf-dots-signal-channel]." > > > > > > > > > > > and/or 'cdid' in dots-client-creation requests? > > > > > > > > > > [Med] This is covered by this text: > > > > > > > > > > "This attribute has the same meaning, syntax, and processing > > > > > rules as the 'cdid' attribute defined in > > > > > [I-D.ietf-dots-signal-channel]" > > > > > > > > I guess I'm mostly just concerned about if there's anything that doesn't > > > > translate directly, since the CoAP and HTTP constructs would have to > > > > describe the formal validation in somewhat different terms (i.e., for > > > > consistency between URL paths and message bodies). But in general I'm > > > > happy to avoid redundancy as you desire. > > > > > > > > > And other parts in the text such as: > > > > > > > > > > If the request is received via a server-domain DOTS gateway, but the > > > > > DOTS server does not maintain a 'cdid' for this 'cuid' while a > > 'cdid' > > > > > is expected to be supplied, the DOTS server MUST reply with "403 > > > > > Forbidden" status-line and the error-tag "access-denied". Upon > > > > > receipt of this message, the DOTS client MUST register (Section 5). > > > > > > > > > > > > > > > What about validating that > > > > > > the (e.g.) ACL name in the PUT URL matching the name in the body of > > the > > > > > > request? > > > > > > > > > > [Med] Those are supposed to be covered following RESTCONF base spec. > > > > > > > > Is this supposed to be RFC 8040 Section 3.5.3? I am not sure that I'm > > > > reading that as covering the property I want (and will double-check if > > you > > > > confirm that's what you have in mind). > > > > > > > > > > [Med] In addition to 3.5.3, Section 4.5 specifies the rules for PUT. > > > > > > The main point is that the validation you mentioned is not specific to DOTS > > but are governed by RESTCONF procedures. > > > > I only see 3.5.3 as talking about how to construct a request URI for a > > given data node in the YANG tree. > > > > What I'm wondering about for the data-channel document is if there are > > cases where a given path component of the YANG module appears both in the > > request URI and in the data in the request body. If so, it seems that the > > server will need to verify that the redundant data agree, and I still don't > > see where this is mandated by RFC 8040. (Sorry if I am being dense.) > > > > [Med] I hear you. As mentioned in my previous answer, this is covered in Section 4.5 of RFC8040: > > If the target resource represents a YANG leaf-list, then the PUT > method MUST NOT change the value of the leaf-list instance. > > If the target resource represents a YANG list instance, then the key > leaf values, in message-body representation, MUST be the same as the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > key leaf values in the request URI. The PUT method MUST NOT be used > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > to change the key leaf values for a data resource instance. This quoted statement is predicated on the target resource being a list instance. Thinking about this a little bit, I suppose that could be the only case in which the redundant encoding arises. So, I will drop this topic, and thank you for your patience explaining the situation to me. -Ben From nobody Wed Feb 27 07:42:49 2019 Return-Path: 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 24567130FF9; Wed, 27 Feb 2019 07:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MKGsTt86jw1D; Wed, 27 Feb 2019 07:42:46 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DA7128CE4; Wed, 27 Feb 2019 07:42:46 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 448g1J4B5Mz5w6c; Wed, 27 Feb 2019 16:42:44 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 448g1J3Rq8zDq7V; Wed, 27 Feb 2019 16:42:44 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([fe80::9108:27dc:3496:8db3%21]) with mapi id 14.03.0435.000; Wed, 27 Feb 2019 16:42:44 +0100 From: To: Benjamin Kaduk CC: "draft-ietf-dots-data-channel@ietf.org" , "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUzqsCb7c2dDIvj0uWD4RT8wY9CqXzx9/g Date: Wed, 27 Feb 2019 15:42:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA261BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227041011.GG53396@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA25FC4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227144456.GJ53396@kduck.mit.edu> In-Reply-To: <20190227144456.GJ53396@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:42:48 -0000 Re-, I agree.=20 Let's add your proposed text to the architecture I-D.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 27 f=E9vrier 2019 15:45 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-dots-data-channel@ietf.org; dots@ietf.org > Objet=A0: Re: AD review of draft-ietf-dots-data-channel-25 >=20 > On Wed, Feb 27, 2019 at 10:25:36AM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Ben, > > > > > > > > > > [Med] Let's add that text into the architecture I-D. > > > > > > Okay. Tiru had a follow-up about how servers can identify DOTS clien= t's > > > domains, which is okay but not quite what I was aiming for. In the t= ext > > > Tiru quoted, we note that > > > > > > The DOTS server enforces authorization of DOTS clients' signals fo= r > > > mitigation. The mechanism of enforcement is not in scope for this > > > document, but is expected to restrict requested mitigation scope t= o > > > addresses, prefixes, and/or services owned by the DOTS client's > > > administrative domain, such that a DOTS client from one domain is = not > > > able to influence the network path to another domain. > > > > > > I was hoping to see something like "For a given client (administrativ= e) > > > domain, the DOTS server needs to be able to determine whether a given > > > resource is in that domain. This could take the form of associating = a > set > > > of IP Prefixes per domain, for example." But I'm open to being persu= aded > > > that the existing text conveys the same meaning. > > > > > > > [Med] Your proposed wording can be added to the architecture I-D, IMHO. > > > > FWIW, we do have this text in the protocol spec: > > > > DOTS servers MUST verify that requesting DOTS clients are entitled t= o > > enforce filtering rules on a given IP prefix. That is, only > > filtering rules on IP resources that belong to the DOTS client's > > domain can be authorized by a DOTS server. The exact mechanism for > > the DOTS servers to validate that the target prefixes are within the > > scope of the DOTS client's domain is deployment-specific. >=20 > To me that text is just reading that it mandates authorization checks, > whereas the text in the data-channel document that prompted this comment > has me thinking that the DOTS server needs an explicit mapping between > "DOTS client domain" and "this set of IP addresses and/or other > identifiers", which is a slightly different thing. From nobody Wed Feb 27 07:57:43 2019 Return-Path: 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 A54CC130FF4; Wed, 27 Feb 2019 07:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 VNVrU780cX0r; Wed, 27 Feb 2019 07:57:38 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810095.outbound.protection.outlook.com [40.107.81.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB2C1200B3; Wed, 27 Feb 2019 07:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4IDaIC6Otb+A7CG3i2d1ijt07xcu5MinnOSAx0mUQw4=; b=onkxylS7/4UD/mTnuixYSLs8WTPorvEcptGNCDOxw/iNH8gKCRLqi45rTys+MAmc8g5/m1VjKphHgv6on/CZtgZkG0xiGaTmB5Bzsxvxx2ip4WWcfH8VP3bQp6PF66gBteVF6hyUW87pwTPd8rDzP/tLmuxPX8M3SBoKTeIwQrg= Received: from BYAPR01CA0066.prod.exchangelabs.com (2603:10b6:a03:94::43) by DM6PR01MB3995.prod.exchangelabs.com (2603:10b6:5:92::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Wed, 27 Feb 2019 15:57:35 +0000 Received: from DM3NAM03FT021.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::200) by BYAPR01CA0066.outlook.office365.com (2603:10b6:a03:94::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.15 via Frontend Transport; Wed, 27 Feb 2019 15:57:34 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT021.mail.protection.outlook.com (10.152.82.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 27 Feb 2019 15:57:34 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1RFvUJ5005026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Feb 2019 10:57:32 -0500 Date: Wed, 27 Feb 2019 09:57:30 -0600 From: Benjamin Kaduk To: CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190227155729.GL53396@kduck.mit.edu> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(346002)(136003)(2980300002)(51444003)(189003)(199004)(54906003)(23756003)(2351001)(229853002)(106002)(6246003)(6916009)(106466001)(33656002)(356004)(36906005)(104016004)(2870700001)(88552002)(53416004)(7696005)(76176011)(305945005)(316002)(58126008)(2906002)(786003)(14444005)(30864003)(26826003)(186003)(26005)(8676002)(966005)(8936002)(126002)(486006)(956004)(476003)(5660300002)(47776003)(11346002)(478600001)(50466002)(426003)(446003)(336012)(4326008)(86362001)(55016002)(6306002)(66574012)(246002)(75432002)(93886005)(1076003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB3995; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b24668bd-b941-43bb-4ba0-08d69ccc49d7 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:DM6PR01MB3995; X-MS-TrafficTypeDiagnostic: DM6PR01MB3995: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB3995; 20:NcIpUkBCaIOVakzICkO6kUi+11JNM0CwilaO5H+trZfrQhvPzGxDcpGk/gluCCcLy0x9iS9u5ZIEh8JNMFM4UG2+UTsVh0GrUWyKcVPd0Qp30a0LJtfby/XftLra4FUi5qg/LM0GHvOS+wEpXED1moQgU5Ixp5g4Ug0broPXd4iSnlHPbtGOXrMqOfZ94MtNHVARXjelKdzf26tljb8WDWEfYjV55SAa2rQAd8vVfgUeoI5H0mfu5Qt1BjmxqmATMntMOpc6h4qt0/WWyVo5jDqWDJX0cV0bcsDufZZzryJUDrRj3tx3+wCekK9myDNF9ZACYL5YJPAuYuSsKVtLddI136lKXAHtYa/kXMTEiPxxKpjfmw/vf94i9GJyIAPSN86aB7FfXH8tVMK3HWGNJPhLbW2DuAuGVkHTvvld/DV7P3wC61FztSe3c7PBGiM2qGuR9X2Qj8EMTkbN/0G1kVkkpoRd6Iw+TEdt7Hlv+lynursdTF1gCeqCo9hNqd/BCk7yJW8oFxhASzO2QNxtyTSQYyCxhw4zadvwNiRItgdMOX4jf6PxxyXrMaKJiTwK29p/GT75jkhgkqE86J6YjkCsi75pq6MRlYvsZaWVLwg= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM6PR01MB3995; 23:dCJGIECWoPGkjwqg76GSE6TwDyb4a/FO472cRfF?= =?iso-8859-1?Q?gPskua9tfGjRyAlBHNeKEqelwv9r2wTGv/D4ULSaEuQc5CdDEXgnW5Y7wa?= =?iso-8859-1?Q?b2ViwmxjQDQJFSigYGymnCr3LHiyCiePLovGpjWCcVxMi3BIQF2lsaE7kJ?= =?iso-8859-1?Q?X8Zxz46Ku3wXYoiWYjE8E0AJnONyZT3pzsCw19Vh72o5RWtDRIKdkjqaC9?= =?iso-8859-1?Q?F2YI7yQn7en2hhbrEktMPDkvh43RmK/h8RUqrLrBggmE4OpqSsw7L2qq00?= =?iso-8859-1?Q?fndRRx9OHO6HeXzv7G+G6lb6uIaROWwiqgwn0EbFcIWWH/Krm2bhvWmoFO?= =?iso-8859-1?Q?ZDZ4Av2278JDI6PqqXReQ/hkUFMWS8qiVK2j37WKHpf2jpXO4GpQwuCk7E?= =?iso-8859-1?Q?DNaLin3aXB56cenLIbfwTwiXMTcovkE8Kj8fOltCAwUZnLA4nyT5bzZe+N?= =?iso-8859-1?Q?zx8VxnNyQzVhk63QUJCUPafGF+wDzk4lhZh52BLJt3wZFQ/4MCEHnTS48j?= =?iso-8859-1?Q?UBNzWBJlhNQWEdTyqyIUAU/GicZITwGtVbwYWuAYWQXauU00YtduVbTn6T?= =?iso-8859-1?Q?uNI+Y72Pfk7kH2FlFDhMbLr/MHJlRQ56IsAXA2gpNO+ls7fFxhECig+pvw?= =?iso-8859-1?Q?sgXcADLF3jYPx5fZngbCQlcp/a7pv3NS0kUjmFm1qldMA+71X3z0Sog6J9?= =?iso-8859-1?Q?WzIgq2Eg6XbGvWsYQu97AFwJY7GuuEtVMA9nkyxsIyZLmF+9CMB4lDuxFm?= =?iso-8859-1?Q?Pc7E8H2nfvBwwpogikx0h65BNvDc4PLVtnOJF9ouBBcFapOjQ9N4UfIu94?= =?iso-8859-1?Q?uuXhFmWRZJmOYZbAeVghOODt1zxITrYc1YIoweogIzLVEwahzlvMxSiiTW?= =?iso-8859-1?Q?NMt2q6b/jWKtwpplMnnhIJGr2/j9XURtfNWUGc0WSRXGTh6siYehM/7Zt+?= =?iso-8859-1?Q?MPvIsS0TS3Y+8uKHWIuJBCMTrP0mFM/9S5o4hyHcSCrMA5BEq4VRVLdEkQ?= =?iso-8859-1?Q?u3fpY4U/Ie8rFe9/9kfq9ByDPUZA8rE9LJZ8Hi+Ezbin8NKNAADUNY1jGE?= =?iso-8859-1?Q?9tRgSOwZeAD+q63x56fxdHYEtXhLXUI/oe+g3km6LqPet9rZiSOVbQupxe?= =?iso-8859-1?Q?d2avPvhMJB0+mnbtuTkn58CssKdlBiSEBMADkVQ1/NuD9yifQ5V4uz3YRi?= =?iso-8859-1?Q?C/ZFwvtbt0ZN8z0BSupn8T2jzZE4Zso5Jjq0lw2MeXasSBoTWpY+JaLwvB?= =?iso-8859-1?Q?ADGfkRkl67+L9wfl7JnFc8PVgVWCEuN9AFHEqbcO2Fy1U/i/0isq4Fy5g6?= =?iso-8859-1?Q?B+iT+aUuAoNYjEOw80GE13q3gfC7FtveDm1tXMc5NQ73+IxXy0fSbQMJP5?= =?iso-8859-1?Q?QY/9FdWCvBXxc65I0J5UTKm+9ZQ78?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: Vph+H1nVvBwH7UL+IzVgVRQ1aPGpmE8mtGZmyCl67yhHkJblY0JJGi2IQ5pHPwPIbhb3ir5TJq6w+bMxwNUULgIX+/a+s12VTZRQcEQrDeji5MQRY/SNT3Fan3DHg2/7QqTpoKfsLIIra5P2zaoXdqJxLrX2ygZlsEqc18NPZ0fngC91E8UOfC2fDdYutrS60p29DOABGwB2PC4sgSMaeBSpUW8r7A9UPMqLUcgSiMXxuk7TCR8Y2cQtdJDrLSHncpf9EadOGCo77lBLw2dPFwrCxci/kO+CtdeC3cUqWltBaR1J/KNTZz4WOwRj7WBsCekmMmRT5jXXZgPh8FJurFauf03vI8hkUOSTHPJedcNINmY/uGJRSSQX0OgiXAOJYCNSvVHkW79X5xuUp8sY3irxRttY3ZEPN9yw97709zI= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2019 15:57:34.0557 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b24668bd-b941-43bb-4ba0-08d69ccc49d7 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB3995 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:57:42 -0000 On Tue, Feb 19, 2019 at 07:59:29AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Please see inline. Okay. BTW, it is looking like this is the last topic to resolve before starting IETF LC. It's probably worth s/the exponent is 2/the base of the exponent is 2/ in the next rev, though, just as a minor nit-fix. > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : lundi 18 février 2019 17:23 > > À : BOUCADAIR Mohamed TGI/OLN > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > dots@ietf.org > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf- > > dots-signal-channel) > > > > On Fri, Feb 15, 2019 at 03:36:05PM +0000, mohamed.boucadair@orange.com wrote: > > > Re-, > > > > > > Looking forward to discuss this further. > > > > > > I wonder whether you can consider putting the document in the IETF LC for > > now. If it happen that we need to modify the 0-RTT text, we will handle it as > > other IETF LC comments. > > > > I would normally be pretty amenable to starting IETF LC and continuing > > discussion; it's just for this issue in particular that I seem to be the > > main person on the IESG that enforces the "application profile for 0-RTT > > data" requirement, so it would feel rather odd to go forward in this case. > > [Med] Fair enough. > > > Luckily, I spent some time this weekend reading RFC 7252 and have some > > substantive comments. > > > > The key oberservation here seems to be that the Message ID is scoped per > > endpoint, and replays can come from arbitrary addresses. > > > > Specifically, we recall that: > > > > The DOTS signal channel is layered on existing standards (Figure 3). > > > > +---------------------+ > > | DOTS Signal Channel | > > +---------------------+ > > | CoAP | > > +----------+----------+ > > | TLS | DTLS | > > +----------+----------+ > > | TCP | UDP | > > +----------+----------+ > > | IP | > > +---------------------+ > > > > We note that CoAP is using the IP address or "DTLS session" (arguably a > > poorly chosen term) to identify a CoAP association and that Message IDs are > > only used within the scope of such an association, it seems pretty clear > > that an attacker able to replay TLS 1.3 0-RTT data will slice off the top > > three lines of this figure and swap out the TCP/UDP/IP layers. In the > > absence of DTLS connection IDs, my understanding is that the "DTLS session" > > is identified solely by the transport connection, just as for coap-not-s, > > so by spoofing the source address, the attacker causes the replayed 0-RTT > > data (and thus, CoAP request) to be interpreted as a new incoming coaps > > connection. > > > > Given that Message ID is only 16 bits and the servers accepting 0-RTT data > > have potential to be quite busy, it does not seem workable to attempt to > > use the incoming Message IDs as globally unique replay defense, as the risk > > of collision would be pretty large. > > [Med] The replay detection relies on both Message ID and Token. In stock CoAP, the Message ID and Token are used only with the context of a specific transport association. In order to use them for (D)TLS 1.3 replay defense, we need to expand that context to a broader scope, and direct the server to check the Message ID/Token globally (or at least within the scope of a given 'cuid'/'cdid'). Since this would reflect a divergence from normal CoAP, if we are going to rely on this sort of behavior, we must call it out very loudly as specific to DOTS. > > > > So I think that the 'mid' monotonicity and the rejection of conflicting > > request scopes are the main mitigating factors against replay in the > > current design (alongside the RFC 8446 mechanisms, of course), and the text > > should be adjusted to reflect that. > > [Med] We do already have the following in the draft: > > The DOTS server(s) can use Message ID and > Token in the DOTS signal channel message to detect replay of early > data, and accept 0-RTT data at most once. Furthermore, 'mid' > ^^^^^^^^^^^^^^^^^^ > value is monotonically increased by the DOTS client for each > mitigation request, attackers replaying mitigation requests with > lower numeric 'mid' values and overlapping scopes with mitigation > requests having higher numeric 'mid' values will be rejected > systematically by the DOTS server. Sorry for being unclear in my comment. I was intending to emphasize that 'mid' and scope are the *only* measures that actually mitigate against 0-RTT replay, and that we are wrong to have text that indicates anything else is an effective anti-replay mechanism, at least given the present design. So I was trying to ask for the text about Message ID and Token to be removed. (Our subsequent discussion indicates that it would maybe also work to expand on it instead of remove it, noting that DOTS is requiring additional behavior not mandated by the CoAP spec.) > > > > It seems that the 'mid' ordering is probably enough to protect > > reordering/replay of mitigiation request and withdraw, even when reordered > > across other mitigation actions. But I am more concerned about > > reordering/replay of other messages, like efficacy updates and session > > configuration changes. > > [Med] For the configuration changes, I don't expect the exchange to happen during an attack. The part of the text we are discussing is about mitigation requests. > > o 0-RTT mode in which the DOTS client can authenticate itself and > send DOTS mitigation request messages in the first message, thus > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > reducing handshake latency. If we don't expect to do anything other than mitigation requests in 0-RTT, then why don't we just limit the messages allowed in 0-RTT data to be such mitigation request messages (and explicitly exclude session configuration)? I am not going to insist on it, but that does seem like the simplest way to resolve the question, at least from over here. > Putting that aside, we do have the following: > > The PUT request with a higher numeric 'sid' value overrides the DOTS > signal channel session configuration data installed by a PUT request > with a lower numeric 'sid' value. To avoid maintaining a long list > of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be > automatically deleted and no longer available at the DOTS server. > > Any replayed configuration change request will be discarded owing to the 'sid' checks. That does help, yes. (I'm not sure whether I had confused myself that the sid was for the abstract "DOTS session" that is roughly akin to the DTLS association, or this was added in response to some of my earlier comments and I failed to internalize it properly. It shows up as new in the diff from -25 to -29 that I'm looking at in preparation for starting IETF LC.) > > > > Consider > > > > client attacker server > > | > > |----efficacy: attack mitigated--------------------->| > > | | > > |----efficacy: under attack------------------------->| > > | | > > | |-replay: attack mitigated->| > > > > Is the server going to end up with the expected state? > > [Med] A general comment: The dots server uses the information conveyed in the efficacy update as a hint; it may but it is not required to rely on those requests to adjust its mitigation actions. > > If the two first status messages are bound to distinct "mids" and adjusted scopes, the replayed request will be discarded by the server thanks to the presence of If-Match option. The server does not maintain the request with the old mid. > > If, for some reason, the same mid is used and this flow is observed, the server will detect that the same Message ID and Token are reused again and then reject. Not if the replay comes from a different transport endpoint! (But let's keep this topic at the discussion above, as it's the same topic.) -Ben > > > > -Ben > > > > > > > > > > > -----Message d'origine----- > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > Envoyé : vendredi 15 février 2019 16:05 > > > > À : BOUCADAIR Mohamed TGI/OLN > > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > > > dots@ietf.org > > > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf- > > > > dots-signal-channel) > > > > > > > > Hi Med, > > > > > > > > Short form: I need to think about it harder. There's some indication > > that > > > > the CoAp Message ID is at the wrong level to protect the 0-RTT data, but > > > > I'm not sure yet. > > > > > > > > Sorry for the delays; this has been a frenetic couple weeks :( > > > > > > > > -Ben > > > > > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000, mohamed.boucadair@orange.com > > wrote: > > > > > Hi Ben, > > > > > > > > > > What is the status for this one? Are we OK to move forward? > > > > > > > > > > Thank you. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > > > > > Envoyé : mardi 29 janvier 2019 14:32 > > > > > > À : Benjamin Kaduk > > > > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > > channel@ietf.org; > > > > > > dots@ietf.org > > > > > > Objet : Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf- > > > > dots- > > > > > > signal-channel) > > > > > > > > > > > > Hi Ben, all, > > > > > > > > > > > > We edited a short draft (https://tools.ietf.org/html/draft-boucadair- > > > > dots- > > > > > > earlydata-00) to motivate the following text included in the signal > > > > channel > > > > > > draft: > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement > > to > > > > > > limit the impact of replay attacks on 0-RTT data. If the DOTS > > > > > > server accepts 0-RTT, it MUST implement one of these > > mechanisms. > > > > > > A DOTS server can reject 0-RTT by sending a TLS > > HelloRetryRequest. > > > > > > The DOTS signal channel messages sent as early data by the DOTS > > > > > > client are idempotent requests. As a reminder, Message ID > > > > > > (Section 3 of [RFC7252]) is changed each time a new CoAP > > request > > > > > > is sent, and the Token (Section 5.3.1 of [RFC7252]) is > > randomized > > > > > > in each CoAP request. The DOTS server(s) can use Message ID > > and > > > > > > Token in the DOTS signal channel message to detect replay of > > early > > > > > > data, and accept 0-RTT data at most once. Furthermore, 'mid' > > > > > > value is monotonically increased by the DOTS client for each > > > > > > mitigation request, attackers replaying mitigation requests > > with > > > > > > lower numeric 'mid' values and overlapping scopes with > > mitigation > > > > > > requests having higher numeric 'mid' values will be rejected > > > > > > systematically by the DOTS server. > > > > > > > > > > > > Owing to the aforementioned protections, especially those > > afforded > > > > > > by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446 > > > > > > anti-replay mechanisms, all DOTS signal channel requests are > > safe > > > > > > to transmit in TLS 1.3 as early data. Refer to > > > > > > [I-D.boucadair-dots-earlydata] for more details. > > > > > > > > > > > > This text and also the Designated Expert guidelines are implemented > > in - > > > > 28. > > > > > > These are the two pending issues from your AD review. > > > > > > > > > > > > Other edits were also made to record what was agreed on the list. > > > > > > > > > > > > We hope this version is now ready to move forward. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that > > > > > > "Application > > > > > > > > > > > protocols MUST NOT use 0-RTT data without a profile that > > > > defines > > > > > > its > > > > > > > > use. > > > > > > > > > > > That profile needs to identify which messages or > > interactions > > > > are > > > > > > > safe > > > > > > > > to > > > > > > > > > > use > > > > > > > > > > > with 0-RTT and how to handle the situation when the server > > > > rejects > > > > > > 0- > > > > > > > > RTT > > > > > > > > > > and > > > > > > > > > > > falls back to 1-RTT." So we either need to say which > > client > > > > > > requests > > > > > > > > are > > > > > > > > > > 0-RTT > > > > > > > > > > > safe (and why) or defer that profile to another document. > > > > draft- > > > > > > > ietf- > > > > > > > > > > dnsop- > > > > > > > > > > > session-signal is perhaps an example of a document that > > > > specifies > > > > > > > which > > > > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > > > > (draft-ietf-acme-acme is another, but an uninteresting one, > > > > since > > > > > > > they > > > > > > > > make > > > > > > > > > > > every request include a single-use nonce, and all messages > > are > > > > 0- > > > > > > RTT > > > > > > > > safe.) > > > > > > > > > > > Our use of increasing 'mid' values may help here, in terms > > of > > > > > > > allowing > > > > > > > > > > DELETEs > > > > > > > > > > > to be safe, but I'd have to think a little more to be sure > > that > > > > > > > > requesting > > > > > > > > > > > mitigation would be safe. (On first glance the session- > > > > managemnet > > > > > > > bits > > > > > > > > > > would > > > > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and > > DELETE), > > > > and > > > > > > CoAP > > > > > > > > is > > > > > > > > > > capable of detecting message duplication (see > > > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both > > > > confirmable > > > > > > > and > > > > > > > > > > non-confirmable messages. > > > > > > > > > > [1] An attacker replaying DELETE will not have any adverse > > > > impact, > > > > > > > 2.02 > > > > > > > > > > (Deleted) Response Code is returned even if the mitigation > > > > request > > > > > > does > > > > > > > > not > > > > > > > > > > exist. > > > > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 should > > > > suffice > > > > > > to > > > > > > > > handle > > > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying > > an > > > > old > > > > > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to > > implement > > > > to > > > > > > > > > limit the impact of replay attacks on 0-RTT data. If the > > > > DOTS > > > > > > > > > server accepts 0-RTT, it MUST implement one of these > > > > mechanisms From nobody Wed Feb 27 08:02:04 2019 Return-Path: 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 78457130FFF; Wed, 27 Feb 2019 08:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 2HwUCe48VKXa; Wed, 27 Feb 2019 08:01:59 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690102.outbound.protection.outlook.com [40.107.69.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5D6130FF4; Wed, 27 Feb 2019 08:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u57ARN8NA7U42NQjmp/pLPybvfYMG0DPd4l3oW+IoHU=; b=C49Ze6YCcSqW2xnZdka+9ooozbz5bqPYx3Cbge33KxdF3HUSJnPwlDHZ9dBU09j4hXqw/tH9NUFgiaHozVRPOCcQUoqq32eRRKrvVrbwbbZHIkx9hnqHCh1VsswTkGq3DxVDjIPd6oXnvVlDFdNjTE0934k2jPqZTRLUnP429hI= Received: from SN2PR01CA0062.prod.exchangelabs.com (2603:10b6:800::30) by BN6PR01MB3283.prod.exchangelabs.com (2603:10b6:404:d7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Wed, 27 Feb 2019 16:01:56 +0000 Received: from DM3NAM03FT026.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by SN2PR01CA0062.outlook.office365.com (2603:10b6:800::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.19 via Frontend Transport; Wed, 27 Feb 2019 16:01:56 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT026.mail.protection.outlook.com (10.152.82.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 27 Feb 2019 16:01:55 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1RG1q4Y006687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Feb 2019 11:01:54 -0500 Date: Wed, 27 Feb 2019 10:01:52 -0600 From: Benjamin Kaduk To: CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Message-ID: <20190227160151.GM53396@kduck.mit.edu> References: <787AE7BB302AE849A7480A190F8B93302EA0C5BC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0C5BC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(136003)(396003)(39860400002)(346002)(2980300002)(13464003)(189003)(199004)(52314003)(53754006)(5660300002)(86362001)(356004)(246002)(50466002)(106002)(8936002)(88552002)(2870700001)(229853002)(8676002)(55016002)(6306002)(58126008)(54906003)(2906002)(305945005)(33656002)(47776003)(36906005)(786003)(316002)(478600001)(1076003)(30864003)(6916009)(486006)(7696005)(76176011)(26826003)(126002)(476003)(956004)(966005)(11346002)(106466001)(14444005)(5024004)(446003)(104016004)(23756003)(6246003)(2351001)(26005)(186003)(336012)(53416004)(75432002)(426003)(4326008)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR01MB3283; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 50b8afa8-5afc-4dd7-c0bf-08d69ccce5ce X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BN6PR01MB3283; X-MS-TrafficTypeDiagnostic: BN6PR01MB3283: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; BN6PR01MB3283; 20:4Lixg2uFAz0VivbK0+eB2ljUEBY53cnD+HEC0kslzvoqMzfwgEvK1xnU0+zoLwfzwv6UZoENALULfLTbfXgRMP+OfHU7OasCGLvTgAtfFqQmxXT1eR3RcSxA6rgU5z/De+gF/ke1cL15XG1+zObo//ZkT2ryAigfGRbtz2/FrpsVA3xS5GNIzfxzy9NlEz7/jAlV3B9KJFslRVl7FWWz8CjtwhPsyj1+3i5+es9Ryg3af20gPm0W+khajdTabPAT5BJoayY6lKGnKVNTQnQcV4aSUUNhAyjtwFqLO9dSknYe+vGU0lBDjrg8hf2xJvDHt/mHu65yxNJxY1Pafzxs9amiS2qt947+Cr9euE3F6Tlu/NMJ3V48nHk/IfYREnBMKj2pWwuybIdEXQWm+GaBI3aVIzZS6zEwODd+qBA9kZZkO6AhH9zsAttJSWRzgW11KrT/qnDAT3IpcvwTwYHzhSyVBldgJcTwfloDwdRf10yxsvDDsMmMYZm8zY/J5djH87B8LeXJjzEOFsTpzh22ffI3ISMB0n3YoX8r5hvv2BA34rH+Jler5LllO+sIkpEzJphhMmYwDaESUI2nSV5YleOaIQUYfkj5zcJICe/W9XI= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0961DF5286 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN6PR01MB3283; 23:DCx0wsqe4r6Tx1N3e3H+HAKMeFqWYcImm5TWw1p?= =?iso-8859-1?Q?NrJmOWJnqCipWn8/mSiIQZXbU3nL7ro/twsschbASoF7EZoT5o7Q1c/k7v?= =?iso-8859-1?Q?CGghrpemfKAIb3nr+9PAgEag40TBmRs2ovAZWQix6qVrokgRW9MMVkb1Z6?= =?iso-8859-1?Q?57pFN04iyRitKLO6JwxYXoZSvpFazxqGsZxrJRygKTpNtDhERM29d8E2Jv?= =?iso-8859-1?Q?g7EMKwiRDnMXcTNrYO+f4JnT471CEtMvANJG/Hf6HdZTsQkFwh/4ln/NJn?= =?iso-8859-1?Q?kEVfoWj1t9hdEGVIqLVKxO+U85YFiNHLC4DBdlWXlznwbOyfteqEqSG96T?= =?iso-8859-1?Q?H+i91S4iyUgsBSFlPXLRjSFDlzNYj1rsyooxTOA//inBS2YLdYOBGs6Bb4?= =?iso-8859-1?Q?/bavpdjllavXd4RLMWbu+VqXbtI1c9FJzDnGIfGIOki3mbWQQYNjfuby6X?= =?iso-8859-1?Q?NvcPiGx5pv68Wc48omXZJ6c9oTXHXMgp77LxJ1ZY7pihVI2GhByca5JCMK?= =?iso-8859-1?Q?gArcLLyYYLe/1GT/YfH4EhXGsw+izqHX2ve+2rd5KdY8OtOeXeLSgxBhKH?= =?iso-8859-1?Q?ZXOF4J6cP01T/CAsk3dH03kZi0qxuNbkrj4B6dvxytPc369BqSdMrKnbNp?= =?iso-8859-1?Q?qWeDROaqPAeE+1yEqP77hf8gji+TkOZWQvVwrGhqRc13ooq0pSloD4kV6l?= =?iso-8859-1?Q?k7WJ9317qrgdSt81PSlUO8KOpKcPaz+T1EdyZyfSBPU2D67VSvc2QOmLM/?= =?iso-8859-1?Q?zuwX7xuxe7Pmr1F/dF5yPajhqmztr9q6YxK0m7mTWJ8SXqsBbQRgFX7HTF?= =?iso-8859-1?Q?lb+lsLey18oOecRwANKUFNVBUGW4apk53IwU1q1iqLDDfg4PvF3eQIAsI4?= =?iso-8859-1?Q?K6Bsd3FBfZ5ZjVHApQkIWavMtg5Ms87bQO6u/Y8vv7sbXnWHYqZuMAEZaD?= =?iso-8859-1?Q?d2jNHT5a+fXi3FXjboFvdxAblUjHDl9cDeVvJMXliaenv8RggnrPnYXmrc?= =?iso-8859-1?Q?hzBExWjSexgoC4E/QWEiSaGrBaiXRdyFk5Qh3pPcq78wF+/09ncOA12/yN?= =?iso-8859-1?Q?K8S4lcFl6afS/TXsj4KxLJ/KtCRNMgffCwLF8K3W+J3NyIOwD0v098JflW?= =?iso-8859-1?Q?WkBdBwGn2LfFkQsgPnbR+ukg4JLuVx8FFbon8bfoCOfWrewfXQpijSzLeS?= =?iso-8859-1?Q?4wa3amtgedXoiqFq+6qFp2aRSEusp/5jQFcQlGzOQuCALgyT+PZjGVURDi?= =?iso-8859-1?Q?cUMsC7BT6g+YpdynclQyyzj4DD30KTlrpQeTHU1wcsK3Bw+5Tuylh7P81p?= =?iso-8859-1?Q?g9O6vQSLnW9KR76uFga5ZFLc9rAx5476FswBnum+uT9FdhwjsD2+4iKPjZ?= =?iso-8859-1?Q?T9qKhQosABcg1M6SqLGuJN53gfkX2?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: /qzM6CnK6W3zMFQcuh0wtYLasm1cEjLA8rlSphFHQf3exrhAE/X+ubh74quNbKZVcWXYDZCnrlnbJgXE2nrmxQOJyNz6u5pdrc+gbollB1wywBYNDZ1okIw48gPDQ/5rYSmlg2v4pZ4aFSFxfPOqCDpCngEBY5lxV4u8oG82um+7yQwALDSlIHhCDILVLu+8QJiqSfdj5SnPRmSQEZbU5FMltUI39NNcdZtmJW3h8eGmL6Lp4JgSGVHRQMKPxle+LdZ9G5QfVDz50/9WLdlS44FCPAXhlMQAo0xrGjctyGosmubgve5dTklnT6TcVsDJgV5kzHIFc+EM9GTkDZzb/P5CudKv0qz82z5b+YMacoaxxVmlm1Kq8Onqdxsz421sbCzUA9YjRyeHB/bR5druuytZOlqXITgUqwetfR483b0= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2019 16:01:55.8024 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 50b8afa8-5afc-4dd7-c0bf-08d69ccce5ce X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR01MB3283 Archived-At: Subject: Re: [Dots] Designed Expert Guidelines (RE: AD review of draft-ietf-dots-signal-channel-25 (5th Part)) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 16:02:03 -0000 Thanks! This is similar text to what's been floating around for a while in a handful of documents; subsequent real-world experience with the procedure has revealed that it's helpful to be very clear in the document about what the entrypoint is for someone requesting a new registration. For many of the existing registries, the expected procedure is "person making registration request sends email to the named list" (as opposed to filling out IANA's webform and having IANA send mail to the list), so we could consider adding some text like "New registration requests should be sent in the form of email to the review mailing list. IANA will only accept new registrations from the Designated Experts, and will check that review was requested on the mailing list in accordance with these procedures." -Ben On Wed, Jan 23, 2019 at 12:15:27PM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > I implemented this change in my local copy: > > OLD: > CBOR Key Value: > Key value for the parameter. The key value MUST be an integer in > the 1-65535 range. The key values of the comprehension-required > range (0x0001 - 0x3FFF) and of the comprehension-optional range > (0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key > values of the comprehension-optional range (0x4000 - 0x7FFF) are > assigned by Designated Expert [RFC8126] and of the comprehension- > optional range (0xC000 - 0xFFFF) are reserved for Private Use > [RFC8126]. > > NEW: > CBOR Key Value: > Key value for the parameter. The key value MUST be an integer in > the 1-65535 range. The key values of the comprehension-required > range (0x0001 - 0x3FFF) and of the comprehension-optional range > (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of > [RFC8126]). The key values of the comprehension-optional range > (0x4000 - 0x7FFF) are assigned by Specification Required > (Section 4.6 of [RFC8126]) and of the comprehension-optional range > (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of > [RFC8126]). > > Registration requests for the 0x4000 - 0x7FFF range are evaluated > after a three-week review period on the dots-signal-reg- > review@ietf.org mailing list, on the advice of one or more > Designated Experts. However, to allow for the allocation of > values prior to publication, the Designated Experts may approve > registration once they are satisfied that such a specification > will be published. Registration requests sent to the mailing list > for review should use an appropriate subject (e.g., "Request to > register CBOR Key Value: example"). > > Within the review period, the Designated Experts will either > approve or deny the registration request, communicating this > decision to the review list and IANA. Denials should include an > explanation and, if applicable, suggestions as to how to make the > request successful. Registration requests that are undetermined > for a period longer than 21 days can be brought to the IESG's > attention (using the iesg@ietf.org mailing list) for resolution. > > Criteria that should be applied by the Designated Experts includes > determining whether the proposed registration duplicates existing > functionality, whether it is likely to be of general applicability > or whether it is useful only for a single use case, and whether > the registration description is clear. IANA must only accept > registry updates to the 0x4000 - 0x7FFF range from the Designated > Experts and should direct all requests for registration to the > review mailing list. It is suggested that multiple Designated > Experts be appointed. In cases where a registration decision > could be perceived as creating a conflict of interest for a > particular Expert, that Expert should defer to the judgment of the > other Experts. > > Cheers, > Med > > > -----Message d'origine----- > > De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > > Envoyé : mardi 22 janvier 2019 08:16 > > À : Benjamin Kaduk > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > dots@ietf.org > > Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part) > > > > Hi Ben, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoyé : lundi 21 janvier 2019 19:11 > > > À : BOUCADAIR Mohamed TGI/OLN > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > > dots@ietf.org > > > Objet : Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th > > Part) > > > > > > On Mon, Jan 21, 2019 at 03:37:38PM +0000, mohamed.boucadair@orange.com > > wrote: > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > > Envoyé : lundi 21 janvier 2019 16:10 > > > > > À : BOUCADAIR Mohamed TGI/OLN > > > > > Cc : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > > channel@ietf.org; > > > > > dots@ietf.org > > > > > Objet : Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th > > > Part) > > > > > > > > > > On Mon, Jan 21, 2019 at 07:31:28AM +0000, mohamed.boucadair@orange.com > > > wrote: > > > > > > Hi Ben, all, > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De : Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoyé : samedi 19 janvier 2019 07:32 > > > > > > > À : Benjamin Kaduk; BOUCADAIR Mohamed TGI/OLN > > > > > > > Cc : draft-ietf-dots-signal-channel@ietf.org; dots@ietf.org > > > > > > > Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 > > > (5th > > > > > Part) > > > > > > > > > > > > > > Hi Ben, > > > > > > > > > > > > > > Please see inline > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots On Behalf Of Benjamin Kaduk > > > > > > > > Sent: Saturday, January 19, 2019 2:33 AM > > > > > > > > To: mohamed.boucadair@orange.com > > > > > > > > Cc: draft-ietf-dots-signal-channel@ietf.org; dots@ietf.org > > > > > > > > Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel- > > 25 > > > (5th > > > > > > > Part) > > > > > > > > > > > > > > > > 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 all, > > > > > > > > > > > > > > > > Thanks for all the edits and the published -27. > > > > > > > > Assuming I'm actually caught up on all the review/response > > threads, > > > I > > > > > think > > > > > > > > we're pretty close to being able to go to IETF LC -- here's what > > I > > > see > > > > > as > > > > > > > still left: > > > > > > > > > > > > > > > > - We need to settle the risk of needing normative downrefs called > > > out > > > > > for > > > > > > > > the last call > > > > > > > > > > > > [Med] I updated the text to: > > > > > > * cite 7618/7624 as normative (+ indicate that a similar mechanism to > > > false > > > > > start may also be defined for DTLS). > > > > > > * tweak the TFO text to maintain it as informative. > > > > > > > > > > Sounds good. > > > > > > > > > > > > > - I just noticed while reviewing the diff that we also need to > > say > > > a > > > > > > > > little more about (D)TLS 1.3 0-RTT data (more below) > > > > > > > > - It looks like we lost the guidance to the Experts and text > > about > > > the > > > > > > > > review mailing list from the IANA Considerations, during the > > > > > reshuffling > > > > > > > > around having IANA manage more things > > > > > > > > > > > > > > > > > > > > [Med] That was on purpose. We would like to rely on RFC8126 rules for > > > > > deigned expert reviews. > > > > > > > > > > I'm not sure I understand this -- 8126 explicitly says that documents > > > > > should provide guidance to the designated expert on what to look for > > and > > > > > what is grounds for rejecting a request. > > > > > > > > > > > > > [Med] What I meant is that the text we used to have in -25 is generic, > > and > > > IMHO does not bring new guidelines to what is discussed in Section 5 of > > 8126. > > > > > > I think there can still be value in repeating the "general applicability, > > > clarity of description, etc. language. (But it would be even better to > > > come up with some guidance that is tightly tailored to DOTS, if we can.) > > > > [Med] I tried, actually. It is indeed when I rechecked 8126 that I found that > > text is generic. Seeking for expert reviews will be done via IANA, which is > > familiar with the process of soliciting experts. > > > > Moreover, I found a bug in the text because it does not apply to the range > > requiring IETF review, but only to a the comprehensive-optional range. > > > > > And the text about the mailing list and how to format registration requests > > > is definitely not covered in 8126! > > > > [Med] that mailing list is likely to include the designed experts. This is > > why I thought it is simple to let IANA decide how to reach out designed > > expert(s) once assigned. > > > > Anyway, I can reinsert the text if you still think it brings value. > > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that > > > "Application > > > > > > > > protocols MUST NOT use 0-RTT data without a profile that defines > > > its > > > > > use. > > > > > > > > That profile needs to identify which messages or interactions are > > > safe > > > > > to > > > > > > > use > > > > > > > > with 0-RTT and how to handle the situation when the server > > rejects > > > 0- > > > > > RTT > > > > > > > and > > > > > > > > falls back to 1-RTT." So we either need to say which client > > > requests > > > > > are > > > > > > > 0-RTT > > > > > > > > safe (and why) or defer that profile to another document. draft- > > > ietf- > > > > > > > dnsop- > > > > > > > > session-signal is perhaps an example of a document that specifies > > > which > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > (draft-ietf-acme-acme is another, but an uninteresting one, since > > > they > > > > > make > > > > > > > > every request include a single-use nonce, and all messages are 0- > > > RTT > > > > > safe.) > > > > > > > > Our use of increasing 'mid' values may help here, in terms of > > > allowing > > > > > > > DELETEs > > > > > > > > to be safe, but I'd have to think a little more to be sure that > > > > > requesting > > > > > > > > mitigation would be safe. (On first glance the session- > > managemnet > > > bits > > > > > > > would > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and DELETE), and > > > CoAP > > > > > is > > > > > > > capable of detecting message duplication (see > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both > > confirmable > > > and > > > > > > > non-confirmable messages. > > > > > > > [1] An attacker replaying DELETE will not have any adverse impact, > > > 2.02 > > > > > > > (Deleted) Response Code is returned even if the mitigation request > > > does > > > > > not > > > > > > > exist. > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 should suffice > > > to > > > > > handle > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carrying an > > old > > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement > > to > > > > > > limit the impact of replay attacks on 0-RTT data. If the DOTS > > > > > > server accepts 0-RTT, it MUST implement one of these > > mechanisms. > > > > > > A DOTS server can reject 0-RTT by sending a TLS > > > HelloRetryRequest. > > > > > > > > > > (As I noted in my reply to Tiru, we need a more explicit statement.) > > > > > > > > > > > > > [Med] OK. If the assessment is confirmed, we can update the text as > > > follows: > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to implement to > > > > limit the impact of replay attacks on 0-RTT data. If the DOTS > > > > server accepts 0-RTT, it MUST implement one of these mechanisms. > > > > A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest From nobody Wed Feb 27 08:52:47 2019 Return-Path: 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 231711310C4; Wed, 27 Feb 2019 08:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hlyGiOENkJgf; Wed, 27 Feb 2019 08:52:36 -0800 (PST) Received: from smtp70.ord1d.emailsrvr.com (smtp70.ord1d.emailsrvr.com [184.106.54.70]) (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 C6FE7131092; Wed, 27 Feb 2019 08:52:32 -0800 (PST) Received: from smtp17.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 22BAF20251; Wed, 27 Feb 2019 11:52:32 -0500 (EST) X-Auth-ID: bgreene@senki.org Received: by smtp17.relay.ord1d.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 67D3C2025D; Wed, 27 Feb 2019 11:52:31 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from [10.0.0.116] (c-73-92-124-43.hsd1.ca.comcast.net [73.92.124.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 27 Feb 2019 11:52:32 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Barry Raveendran Greene X-Mailer: iPad Mail (16D57) In-Reply-To: <155127802240.13985.12710692781572812550.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2019 08:52:30 -0800 Cc: IETF-Announce , Roman Danyliw , dots-chairs@ietf.org, kaduk@mit.edu, dots@ietf.org, draft-ietf-dots-data-channel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155127802240.13985.12710692781572812550.idtracker@ietfa.amsl.com> To: ietf@ietf.org Archived-At: Subject: Re: [Dots] Last Call: (Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification) to Proposed Standard 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 16:52:43 -0000 Do we have working implementations to validate the movement to a proposed st= andard? Does it work? > On Feb 27, 2019, at 06:33, The IESG wrote: >=20 >=20 > The IESG has received a request from the DDoS Open Threat Signaling WG (do= ts) > to consider the following document: - 'Distributed Denial-of-Service Open > Threat Signaling (DOTS) Data > Channel Specification' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits fina= l > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2019-03-13. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning= of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data that > cannot easily or appropriately communicated through the DOTS signal > channel under attack conditions. >=20 > This is a companion document to the DOTS signal channel > specification. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements within the document with the RFC > number to be assigned to this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel Specification"; >=20 > o reference: RFC XXXX >=20 > Please update the "revision" date of the YANG module. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 27 09:04:33 2019 Return-Path: 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 4E4601310B0; Wed, 27 Feb 2019 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cert.org 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 tsyssiBkpSit; Wed, 27 Feb 2019 09:04:22 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 1284C131041; Wed, 27 Feb 2019 09:04:21 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1RH4KNu004436; Wed, 27 Feb 2019 12:04:20 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x1RH4KNu004436 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1551287060; bh=jx1MlLfeSb9lMWonbdRiJgLj8rLuv8gqR4otD9XWo8Q=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=KaNWt1bbMAAbIDJViYL/qNm7apwotDv9qEOl36heYBFJTDd9A3zeBYLEmaefBVWly TIlO3NMkzHfYjDQVftRE+RgNIYqkzeJcTgOE26J1J/ZaTYDlH5Jo6cIHZAFWnueIG7 HxUCCVFOWN0TUk+vUMRhF/c9GuAZcnmEGA5Tfs3g= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1RH4IaK009205; Wed, 27 Feb 2019 12:04:18 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Wed, 27 Feb 2019 12:04:18 -0500 From: Roman Danyliw To: Barry Raveendran Greene , "ietf@ietf.org" CC: IETF-Announce , "dots-chairs@ietf.org" , "kaduk@mit.edu" , "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: [Dots] Last Call: (Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification) to Proposed Standard Thread-Index: AQHUzql0X7WKeLBkNUCj9i7xUt9vTaX0MCUA//+sdnA= Date: Wed, 27 Feb 2019 17:04:17 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857DC0F8@marathon> References: <155127802240.13985.12710692781572812550.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Last Call: (Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification) to Proposed Standard 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 17:04:33 -0000 Hi Barry, > -----Original Message----- > From: Barry Raveendran Greene [mailto:bgreene@senki.org] > Sent: Wednesday, February 27, 2019 11:53 AM > To: ietf@ietf.org > Cc: IETF-Announce ; Roman Danyliw > ; dots-chairs@ietf.org; kaduk@mit.edu; dots@ietf.org; draft= - > ietf-dots-data-channel@ietf.org > Subject: Re: [Dots] Last Call: > (Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel > Specification) to Proposed Standard >=20 >=20 > Do we have working implementations to validate the movement to a > proposed standard? Does it work? Yes. There are two implementations [1] (from NTT and NCC Group) of this da= ta channel specification. These implementations did an interop at IETF 102 = [2] and IETF 103 [3] which improved the current specification. Regards, Roman [1] https://trac.ietf.org/trac/dots [2] https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-ietf= -102-hackathon-interop-report-00 [3] https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-inte= rop-report-from-ietf-103-hackathon-00=20 > > On Feb 27, 2019, at 06:33, The IESG wrote: > > > > > > The IESG has received a request from the DDoS Open Threat Signaling WG > > (dots) to consider the following document: - 'Distributed > > Denial-of-Service Open Threat Signaling (DOTS) Data > > Channel Specification' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2019-03-13. Exceptionally, comments may > > be sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The document specifies a Distributed Denial-of-Service Open Threat > > Signaling (DOTS) data channel used for bulk exchange of data that > > cannot easily or appropriately communicated through the DOTS signal > > channel under attack conditions. > > > > This is a companion document to the DOTS signal channel > > specification. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements within the document with the RFC > > number to be assigned to this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Data Channel Specification"; > > > > o reference: RFC XXXX > > > > Please update the "revision" date of the YANG module. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 28 00:18:27 2019 Return-Path: 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 00E97130DF6; Thu, 28 Feb 2019 00:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0sMAFxkaR4bl; Thu, 28 Feb 2019 00:18:22 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C604012D4E7; Thu, 28 Feb 2019 00:18:21 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4495636VbCz2xl2; Thu, 28 Feb 2019 09:18:19 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4495635k31zBrLG; Thu, 28 Feb 2019 09:18:19 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([fe80::54f9:a664:e400:452a%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 09:18:19 +0100 From: To: Benjamin Kaduk CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUzrUqRGWVfXoV+kCvM9AjMnGoAqX0wcIQ Date: Thu, 28 Feb 2019 08:18:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA2680B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227155729.GL53396@kduck.mit.edu> In-Reply-To: <20190227155729.GL53396@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 08:18:26 -0000 Hi Ben,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 27 f=E9vrier 2019 16:58 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org= ; > dots@ietf.org > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft-iet= f- > dots-signal-channel) >=20 > On Tue, Feb 19, 2019 at 07:59:29AM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Ben, > > > > Please see inline. >=20 > Okay. BTW, it is looking like this is the last topic to resolve before > starting IETF LC. It's probably worth s/the exponent is 2/the base of th= e > exponent is 2/ in the next rev, though, just as a minor nit-fix. >=20 [Med] Fixed. > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoy=E9=A0: lundi 18 f=E9vrier 2019 17:23 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf= .org; > > > dots@ietf.org > > > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of draft= -ietf- > > > dots-signal-channel) > > > > > > On Fri, Feb 15, 2019 at 03:36:05PM +0000, mohamed.boucadair@orange.co= m > wrote: > > > > Re-, > > > > > > > > Looking forward to discuss this further. > > > > > > > > I wonder whether you can consider putting the document in the IETF = LC > for > > > now. If it happen that we need to modify the 0-RTT text, we will hand= le > it as > > > other IETF LC comments. > > > > > > I would normally be pretty amenable to starting IETF LC and continuin= g > > > discussion; it's just for this issue in particular that I seem to be = the > > > main person on the IESG that enforces the "application profile for 0-= RTT > > > data" requirement, so it would feel rather odd to go forward in this > case. > > > > [Med] Fair enough. > > > > > Luckily, I spent some time this weekend reading RFC 7252 and have som= e > > > substantive comments. > > > > > > The key oberservation here seems to be that the Message ID is scoped = per > > > endpoint, and replays can come from arbitrary addresses. > > > > > > Specifically, we recall that: > > > > > > The DOTS signal channel is layered on existing standards (Figure 3= ). > > > > > > +---------------------+ > > > | DOTS Signal Channel | > > > +---------------------+ > > > | CoAP | > > > +----------+----------+ > > > | TLS | DTLS | > > > +----------+----------+ > > > | TCP | UDP | > > > +----------+----------+ > > > | IP | > > > +---------------------+ > > > > > > We note that CoAP is using the IP address or "DTLS session" (arguably= a > > > poorly chosen term) to identify a CoAP association and that Message I= Ds > are > > > only used within the scope of such an association, it seems pretty cl= ear > > > that an attacker able to replay TLS 1.3 0-RTT data will slice off the= top > > > three lines of this figure and swap out the TCP/UDP/IP layers. In th= e > > > absence of DTLS connection IDs, my understanding is that the "DTLS > session" > > > is identified solely by the transport connection, just as for coap-no= t-s, > > > so by spoofing the source address, the attacker causes the replayed 0= -RTT > > > data (and thus, CoAP request) to be interpreted as a new incoming coa= ps > > > connection. > > > > > > Given that Message ID is only 16 bits and the servers accepting 0-RTT > data > > > have potential to be quite busy, it does not seem workable to attempt= to > > > use the incoming Message IDs as globally unique replay defense, as th= e > risk > > > of collision would be pretty large. > > > > [Med] The replay detection relies on both Message ID and Token. >=20 > In stock CoAP, the Message ID and Token are used only with the context of= a > specific transport association.=20 [Med] Hmm...RFC7252 defines an endpoint as follows:=20 The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9): With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode. DOTS adheres to that definition: it assumes that an endpoint is not identif= ied by its transport coordinates but with its identity.=20 Furthermore, the correlation between sessions is clearly mentioned in the t= ext: The DOTS server couples the DOTS signal channel sessions using the DOTS client identity and optionally the 'cdid' parameter value, and the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to detect duplicate mitigation requests. =20 In order to use them for (D)TLS 1.3 replay > defense, we need to expand that context to a broader scope, and direct th= e > server to check the Message ID/Token globally (or at least within the sco= pe > of a given 'cuid'/'cdid'). Since this would reflect a divergence from > normal CoAP, if we are going to rely on this sort of behavior, we must ca= ll > it out very loudly as specific to DOTS. >=20 [Med] We can make this change if it helps:=20 OLD: The DOTS server(s) can use Message ID and Token in the DOTS signal channel message to detect replay of early data, and accept 0-RTT data at most once. NEW: The DOTS server(s) can use Message ID and Token in the DOTS signal channel message to detect replay of early data, and accept 0-RTT data at most once from the same DOTS client. DOTS servers do not rely on transport coordinates to=20 identify its peers. As a reminder, DOTS servers couples the DOTS sign= al channel sessions=20 using the DOTS client identity and optionally the 'cdid' parameter va= lue. > > > > > > So I think that the 'mid' monotonicity and the rejection of conflicti= ng > > > request scopes are the main mitigating factors against replay in the > > > current design (alongside the RFC 8446 mechanisms, of course), and th= e > text > > > should be adjusted to reflect that. > > > > [Med] We do already have the following in the draft: > > > > The DOTS server(s) can use Message ID and > > Token in the DOTS signal channel message to detect replay of earl= y > > data, and accept 0-RTT data at most once. Furthermore, 'mid' > > ^^^^^^^^^^^^^^^^^^ > > value is monotonically increased by the DOTS client for each > > mitigation request, attackers replaying mitigation requests with > > lower numeric 'mid' values and overlapping scopes with mitigation > > requests having higher numeric 'mid' values will be rejected > > systematically by the DOTS server. >=20 > Sorry for being unclear in my comment. I was intending to emphasize that > 'mid' and scope are the *only* measures that actually mitigate against > 0-RTT replay, and that we are wrong to have text that indicates anything > else is an effective anti-replay mechanism, at least given the present > design. So I was trying to ask for the text about Message ID and Token t= o > be removed. (Our subsequent discussion indicates that it would maybe als= o > work to expand on it instead of remove it, noting that DOTS is requiring > additional behavior not mandated by the CoAP spec.) >=20 > > > > > > It seems that the 'mid' ordering is probably enough to protect > > > reordering/replay of mitigiation request and withdraw, even when > reordered > > > across other mitigation actions. But I am more concerned about > > > reordering/replay of other messages, like efficacy updates and sessio= n > > > configuration changes. > > > > [Med] For the configuration changes, I don't expect the exchange to hap= pen > during an attack. The part of the text we are discussing is about mitigat= ion > requests. > > > > o 0-RTT mode in which the DOTS client can authenticate itself and > > send DOTS mitigation request messages in the first message, thus > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > reducing handshake latency. >=20 > If we don't expect to do anything other than mitigation requests in 0-RTT= , > then why don't we just limit the messages allowed in 0-RTT data to be suc= h > mitigation request messages (and explicitly exclude session configuration= )? > I am not going to insist on it, but that does seem like the simplest way > to resolve the question, at least from over here. >=20 > > Putting that aside, we do have the following: > > > > The PUT request with a higher numeric 'sid' value overrides the DOTS > > signal channel session configuration data installed by a PUT request > > with a lower numeric 'sid' value. To avoid maintaining a long list > > of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST b= e > > automatically deleted and no longer available at the DOTS server. > > > > Any replayed configuration change request will be discarded owing to th= e > 'sid' checks. >=20 > That does help, yes. [Med] OK. (I'm not sure whether I had confused myself that the > sid was for the abstract "DOTS session" that is roughly akin to the DTLS > association, or this was added in response to some of my earlier comments > and I failed to internalize it properly. It shows up as new in the diff > from -25 to -29 that I'm looking at in preparation for starting IETF LC.) >=20 > > > > > > Consider > > > > > > client attacker server > > > | > > > |----efficacy: attack mitigated--------------------->| > > > | | > > > |----efficacy: under attack------------------------->| > > > | | > > > | |-replay: attack mitigated->| > > > > > > Is the server going to end up with the expected state? > > > > [Med] A general comment: The dots server uses the information conveyed = in > the efficacy update as a hint; it may but it is not required to rely on t= hose > requests to adjust its mitigation actions. > > > > If the two first status messages are bound to distinct "mids" and adjus= ted > scopes, the replayed request will be discarded by the server thanks to th= e > presence of If-Match option. The server does not maintain the request wit= h > the old mid. > > > > If, for some reason, the same mid is used and this flow is observed, th= e > server will detect that the same Message ID and Token are reused again an= d > then reject. >=20 > Not if the replay comes from a different transport endpoint! (But let's > keep this topic at the discussion above, as it's the same topic.) >=20 > -Ben >=20 > > > > > > -Ben > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > > Envoy=E9=A0: vendredi 15 f=E9vrier 2019 16:05 > > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > channel@ietf.org; > > > > > dots@ietf.org > > > > > Objet=A0: Re: Using Early Data in DOTS (RE: [Dots] AD review of d= raft- > ietf- > > > > > dots-signal-channel) > > > > > > > > > > Hi Med, > > > > > > > > > > Short form: I need to think about it harder. There's some indica= tion > > > that > > > > > the CoAp Message ID is at the wrong level to protect the 0-RTT da= ta, > but > > > > > I'm not sure yet. > > > > > > > > > > Sorry for the delays; this has been a frenetic couple weeks :( > > > > > > > > > > -Ben > > > > > > > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000, > mohamed.boucadair@orange.com > > > wrote: > > > > > > Hi Ben, > > > > > > > > > > > > What is the status for this one? Are we OK to move forward? > > > > > > > > > > > > Thank you. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > Envoy=E9=A0: mardi 29 janvier 2019 14:32 > > > > > > > =C0=A0: Benjamin Kaduk > > > > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > > > channel@ietf.org; > > > > > > > dots@ietf.org > > > > > > > Objet=A0: Using Early Data in DOTS (RE: [Dots] AD review of d= raft- > ietf- > > > > > dots- > > > > > > > signal-channel) > > > > > > > > > > > > > > Hi Ben, all, > > > > > > > > > > > > > > We edited a short draft (https://tools.ietf.org/html/draft- > boucadair- > > > > > dots- > > > > > > > earlydata-00) to motivate the following text included in the > signal > > > > > channel > > > > > > > draft: > > > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to > implement > > > to > > > > > > > limit the impact of replay attacks on 0-RTT data. If t= he > DOTS > > > > > > > server accepts 0-RTT, it MUST implement one of these > > > mechanisms. > > > > > > > A DOTS server can reject 0-RTT by sending a TLS > > > HelloRetryRequest. > > > > > > > The DOTS signal channel messages sent as early data by = the > DOTS > > > > > > > client are idempotent requests. As a reminder, Message= ID > > > > > > > (Section 3 of [RFC7252]) is changed each time a new CoA= P > > > request > > > > > > > is sent, and the Token (Section 5.3.1 of [RFC7252]) is > > > randomized > > > > > > > in each CoAP request. The DOTS server(s) can use Messa= ge > ID > > > and > > > > > > > Token in the DOTS signal channel message to detect repl= ay > of > > > early > > > > > > > data, and accept 0-RTT data at most once. Furthermore, > 'mid' > > > > > > > value is monotonically increased by the DOTS client for > each > > > > > > > mitigation request, attackers replaying mitigation requ= ests > > > with > > > > > > > lower numeric 'mid' values and overlapping scopes with > > > mitigation > > > > > > > requests having higher numeric 'mid' values will be > rejected > > > > > > > systematically by the DOTS server. > > > > > > > > > > > > > > Owing to the aforementioned protections, especially tho= se > > > afforded > > > > > > > by CoAP deduplication (Section 4.5 of [RFC7252]) and RF= C > 8446 > > > > > > > anti-replay mechanisms, all DOTS signal channel request= s > are > > > safe > > > > > > > to transmit in TLS 1.3 as early data. Refer to > > > > > > > [I-D.boucadair-dots-earlydata] for more details. > > > > > > > > > > > > > > This text and also the Designated Expert guidelines are > implemented > > > in - > > > > > 28. > > > > > > > These are the two pending issues from your AD review. > > > > > > > > > > > > > > Other edits were also made to record what was agreed on the l= ist. > > > > > > > > > > > > > > We hope this version is now ready to move forward. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes > that > > > > > > > "Application > > > > > > > > > > > > protocols MUST NOT use 0-RTT data without a profile > that > > > > > defines > > > > > > > its > > > > > > > > > use. > > > > > > > > > > > > That profile needs to identify which messages or > > > interactions > > > > > are > > > > > > > > safe > > > > > > > > > to > > > > > > > > > > > use > > > > > > > > > > > > with 0-RTT and how to handle the situation when the > server > > > > > rejects > > > > > > > 0- > > > > > > > > > RTT > > > > > > > > > > > and > > > > > > > > > > > > falls back to 1-RTT." So we either need to say whi= ch > > > client > > > > > > > requests > > > > > > > > > are > > > > > > > > > > > 0-RTT > > > > > > > > > > > > safe (and why) or defer that profile to another > document. > > > > > draft- > > > > > > > > ietf- > > > > > > > > > > > dnsop- > > > > > > > > > > > > session-signal is perhaps an example of a document = that > > > > > specifies > > > > > > > > which > > > > > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > > > > > (draft-ietf-acme-acme is another, but an uninterest= ing > one, > > > > > since > > > > > > > > they > > > > > > > > > make > > > > > > > > > > > > every request include a single-use nonce, and all > messages > > > are > > > > > 0- > > > > > > > RTT > > > > > > > > > safe.) > > > > > > > > > > > > Our use of increasing 'mid' values may help here, i= n > terms > > > of > > > > > > > > allowing > > > > > > > > > > > DELETEs > > > > > > > > > > > > to be safe, but I'd have to think a little more to = be > sure > > > that > > > > > > > > > requesting > > > > > > > > > > > > mitigation would be safe. (On first glance the > session- > > > > > managemnet > > > > > > > > bits > > > > > > > > > > > would > > > > > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and > > > DELETE), > > > > > and > > > > > > > CoAP > > > > > > > > > is > > > > > > > > > > > capable of detecting message duplication (see > > > > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for = both > > > > > confirmable > > > > > > > > and > > > > > > > > > > > non-confirmable messages. > > > > > > > > > > > [1] An attacker replaying DELETE will not have any > adverse > > > > > impact, > > > > > > > > 2.02 > > > > > > > > > > > (Deleted) Response Code is returned even if the > mitigation > > > > > request > > > > > > > does > > > > > > > > > not > > > > > > > > > > > exist. > > > > > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 > should > > > > > suffice > > > > > > > to > > > > > > > > > handle > > > > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data > carrying > > > an > > > > > old > > > > > > > > > > > mitigation request replaced by a new mitigation scope= ). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms = to > > > implement > > > > > to > > > > > > > > > > limit the impact of replay attacks on 0-RTT data.= If > the > > > > > DOTS > > > > > > > > > > server accepts 0-RTT, it MUST implement one of th= ese > > > > > mechanisms From nobody Thu Feb 28 00:20:15 2019 Return-Path: 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 83342130DF6; Thu, 28 Feb 2019 00:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ohrQ3GrtjvlA; Thu, 28 Feb 2019 00:20:11 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E85912D4E7; Thu, 28 Feb 2019 00:20:11 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4495893SsDz8tD8; Thu, 28 Feb 2019 09:20:09 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4495892FKSz5vMq; Thu, 28 Feb 2019 09:20:09 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 09:20:09 +0100 From: To: Benjamin Kaduk CC: "Konda, Tirumaleswar Reddy" , "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Designed Expert Guidelines (RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)) Thread-Index: AQHUzrXGf7e1+/wr+k6jSV69s/yU6KX03woA Date: Thu, 28 Feb 2019 08:20:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA26821@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA0C5BC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227160151.GM53396@kduck.mit.edu> In-Reply-To: <20190227160151.GM53396@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Designed Expert Guidelines (RE: AD review of draft-ietf-dots-signal-channel-25 (5th Part)) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 08:20:14 -0000 Re-, Works for me.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 27 f=E9vrier 2019 17:02 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org= ; > dots@ietf.org > Objet=A0: Re: Designed Expert Guidelines (RE: [Dots] AD review of draft-i= etf- > dots-signal-channel-25 (5th Part)) >=20 > Thanks! This is similar text to what's been floating around for a while = in > a handful of documents; subsequent real-world experience with the procedu= re > has revealed that it's helpful to be very clear in the document about wha= t > the entrypoint is for someone requesting a new registration. For many of > the existing registries, the expected procedure is "person making > registration request sends email to the named list" (as opposed to fillin= g > out IANA's webform and having IANA send mail to the list), so we could > consider adding some text like "New registration requests should be sent > in the form of email to the review mailing list. IANA will only accept n= ew > registrations from the Designated Experts, and will check that review was > requested on the mailing list in accordance with these procedures." >=20 > -Ben >=20 > On Wed, Jan 23, 2019 at 12:15:27PM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Ben, > > > > I implemented this change in my local copy: > > > > OLD: > > CBOR Key Value: > > Key value for the parameter. The key value MUST be an integer in > > the 1-65535 range. The key values of the comprehension-required > > range (0x0001 - 0x3FFF) and of the comprehension-optional range > > (0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key > > values of the comprehension-optional range (0x4000 - 0x7FFF) are > > assigned by Designated Expert [RFC8126] and of the comprehension- > > optional range (0xC000 - 0xFFFF) are reserved for Private Use > > [RFC8126]. > > > > NEW: > > CBOR Key Value: > > Key value for the parameter. The key value MUST be an integer in > > the 1-65535 range. The key values of the comprehension-required > > range (0x0001 - 0x3FFF) and of the comprehension-optional range > > (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of > > [RFC8126]). The key values of the comprehension-optional range > > (0x4000 - 0x7FFF) are assigned by Specification Required > > (Section 4.6 of [RFC8126]) and of the comprehension-optional rang= e > > (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of > > [RFC8126]). > > > > Registration requests for the 0x4000 - 0x7FFF range are evaluated > > after a three-week review period on the dots-signal-reg- > > review@ietf.org mailing list, on the advice of one or more > > Designated Experts. However, to allow for the allocation of > > values prior to publication, the Designated Experts may approve > > registration once they are satisfied that such a specification > > will be published. Registration requests sent to the mailing lis= t > > for review should use an appropriate subject (e.g., "Request to > > register CBOR Key Value: example"). > > > > Within the review period, the Designated Experts will either > > approve or deny the registration request, communicating this > > decision to the review list and IANA. Denials should include an > > explanation and, if applicable, suggestions as to how to make the > > request successful. Registration requests that are undetermined > > for a period longer than 21 days can be brought to the IESG's > > attention (using the iesg@ietf.org mailing list) for resolution. > > > > Criteria that should be applied by the Designated Experts include= s > > determining whether the proposed registration duplicates existing > > functionality, whether it is likely to be of general applicabilit= y > > or whether it is useful only for a single use case, and whether > > the registration description is clear. IANA must only accept > > registry updates to the 0x4000 - 0x7FFF range from the Designated > > Experts and should direct all requests for registration to the > > review mailing list. It is suggested that multiple Designated > > Experts be appointed. In cases where a registration decision > > could be perceived as creating a conflict of interest for a > > particular Expert, that Expert should defer to the judgment of th= e > > other Experts. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.= com] > > > Envoy=E9=A0: mardi 22 janvier 2019 08:16 > > > =C0=A0: Benjamin Kaduk > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf= .org; > > > dots@ietf.org > > > Objet=A0: RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (= 5th > Part) > > > > > > Hi Ben, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > Envoy=E9=A0: lundi 21 janvier 2019 19:11 > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > channel@ietf.org; > > > > dots@ietf.org > > > > Objet=A0: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25= (5th > > > Part) > > > > > > > > On Mon, Jan 21, 2019 at 03:37:38PM +0000, mohamed.boucadair@orange.= com > > > wrote: > > > > > Re-, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > > > Envoy=E9=A0: lundi 21 janvier 2019 16:10 > > > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > > > > > Cc=A0: Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > > > channel@ietf.org; > > > > > > dots@ietf.org > > > > > > Objet=A0: Re: [Dots] AD review of draft-ietf-dots-signal-channe= l-25 > (5th > > > > Part) > > > > > > > > > > > > On Mon, Jan 21, 2019 at 07:31:28AM +0000, > mohamed.boucadair@orange.com > > > > wrote: > > > > > > > Hi Ben, all, > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: samedi 19 janvier 2019 07:32 > > > > > > > > =C0=A0: Benjamin Kaduk; BOUCADAIR Mohamed TGI/OLN > > > > > > > > Cc=A0: draft-ietf-dots-signal-channel@ietf.org; dots@ietf.o= rg > > > > > > > > Objet=A0: RE: [Dots] AD review of draft-ietf-dots-signal-ch= annel- > 25 > > > > (5th > > > > > > Part) > > > > > > > > > > > > > > > > Hi Ben, > > > > > > > > > > > > > > > > Please see inline > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots On Behalf Of Benjamin > Kaduk > > > > > > > > > Sent: Saturday, January 19, 2019 2:33 AM > > > > > > > > > To: mohamed.boucadair@orange.com > > > > > > > > > Cc: draft-ietf-dots-signal-channel@ietf.org; dots@ietf.or= g > > > > > > > > > Subject: Re: [Dots] AD review of draft-ietf-dots-signal- > channel- > > > 25 > > > > (5th > > > > > > > > Part) > > > > > > > > > > > > > > > > > > This email originated from outside of the organization. D= o > not > > > > click > > > > > > links > > > > > > > > or > > > > > > > > > open attachments unless you recognize the sender and know= the > > > > content > > > > > > is > > > > > > > > safe. > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > Thanks for all the edits and the published -27. > > > > > > > > > Assuming I'm actually caught up on all the review/respons= e > > > threads, > > > > I > > > > > > think > > > > > > > > > we're pretty close to being able to go to IETF LC -- here= 's > what > > > I > > > > see > > > > > > as > > > > > > > > still left: > > > > > > > > > > > > > > > > > > - We need to settle the risk of needing normative downref= s > called > > > > out > > > > > > for > > > > > > > > > the last call > > > > > > > > > > > > > > [Med] I updated the text to: > > > > > > > * cite 7618/7624 as normative (+ indicate that a similar > mechanism to > > > > false > > > > > > start may also be defined for DTLS). > > > > > > > * tweak the TFO text to maintain it as informative. > > > > > > > > > > > > Sounds good. > > > > > > > > > > > > > > > - I just noticed while reviewing the diff that we also ne= ed > to > > > say > > > > a > > > > > > > > > little more about (D)TLS 1.3 0-RTT data (more below) > > > > > > > > > - It looks like we lost the guidance to the Experts and t= ext > > > about > > > > the > > > > > > > > > review mailing list from the IANA Considerations, durin= g > the > > > > > > reshuffling > > > > > > > > > around having IANA manage more things > > > > > > > > > > > > > > > > > > > > > > > [Med] That was on purpose. We would like to rely on RFC8126 r= ules > for > > > > > > deigned expert reviews. > > > > > > > > > > > > I'm not sure I understand this -- 8126 explicitly says that > documents > > > > > > should provide guidance to the designated expert on what to loo= k > for > > > and > > > > > > what is grounds for rejecting a request. > > > > > > > > > > > > > > > > [Med] What I meant is that the text we used to have in -25 is > generic, > > > and > > > > IMHO does not bring new guidelines to what is discussed in Section = 5 of > > > 8126. > > > > > > > > I think there can still be value in repeating the "general > applicability, > > > > clarity of description, etc. language. (But it would be even bette= r to > > > > come up with some guidance that is tightly tailored to DOTS, if we > can.) > > > > > > [Med] I tried, actually. It is indeed when I rechecked 8126 that I fo= und > that > > > text is generic. Seeking for expert reviews will be done via IANA, wh= ich > is > > > familiar with the process of soliciting experts. > > > > > > Moreover, I found a bug in the text because it does not apply to the > range > > > requiring IETF review, but only to a the comprehensive-optional range= . > > > > > > > And the text about the mailing list and how to format registration > requests > > > > is definitely not covered in 8126! > > > > > > [Med] that mailing list is likely to include the designed experts. Th= is > is > > > why I thought it is simple to let IANA decide how to reach out design= ed > > > expert(s) once assigned. > > > > > > Anyway, I can reinsert the text if you still think it brings value. > > > > > > > > > > > > > > > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that > > > > "Application > > > > > > > > > protocols MUST NOT use 0-RTT data without a profile that > defines > > > > its > > > > > > use. > > > > > > > > > That profile needs to identify which messages or interact= ions > are > > > > safe > > > > > > to > > > > > > > > use > > > > > > > > > with 0-RTT and how to handle the situation when the serve= r > > > rejects > > > > 0- > > > > > > RTT > > > > > > > > and > > > > > > > > > falls back to 1-RTT." So we either need to say which cli= ent > > > > requests > > > > > > are > > > > > > > > 0-RTT > > > > > > > > > safe (and why) or defer that profile to another document. > draft- > > > > ietf- > > > > > > > > dnsop- > > > > > > > > > session-signal is perhaps an example of a document that > specifies > > > > which > > > > > > > > > messages are/aren't allowed in early data. > > > > > > > > > (draft-ietf-acme-acme is another, but an uninteresting on= e, > since > > > > they > > > > > > make > > > > > > > > > every request include a single-use nonce, and all message= s > are 0- > > > > RTT > > > > > > safe.) > > > > > > > > > Our use of increasing 'mid' values may help here, in term= s of > > > > allowing > > > > > > > > DELETEs > > > > > > > > > to be safe, but I'd have to think a little more to be sur= e > that > > > > > > requesting > > > > > > > > > mitigation would be safe. (On first glance the session- > > > managemnet > > > > bits > > > > > > > > would > > > > > > > > > not be safe, but I may be missing something.) > > > > > > > > > > > > > > > > The draft only uses idempotent requests (GET, PUT and DELET= E), > and > > > > CoAP > > > > > > is > > > > > > > > capable of detecting message duplication (see > > > > > > > > https://tools.ietf.org/html/rfc7252#section-4.5) for both > > > confirmable > > > > and > > > > > > > > non-confirmable messages. > > > > > > > > [1] An attacker replaying DELETE will not have any adverse > impact, > > > > 2.02 > > > > > > > > (Deleted) Response Code is returned even if the mitigation > request > > > > does > > > > > > not > > > > > > > > exist. > > > > > > > > [2] The techniques discussed in Section 8 of RFC8446 should > suffice > > > > to > > > > > > handle > > > > > > > > anti-replay (e.g. an attacker replaying a 0-RTT data carryi= ng > an > > > old > > > > > > > > mitigation request replaced by a new mitigation scope). > > > > > > > > > > > > > > > > > > > > > > [Med] FWIW, we do already have this text in the draft: > > > > > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to > implement > > > to > > > > > > > limit the impact of replay attacks on 0-RTT data. If t= he > DOTS > > > > > > > server accepts 0-RTT, it MUST implement one of these > > > mechanisms. > > > > > > > A DOTS server can reject 0-RTT by sending a TLS > > > > HelloRetryRequest. > > > > > > > > > > > > (As I noted in my reply to Tiru, we need a more explicit > statement.) > > > > > > > > > > > > > > > > [Med] OK. If the assessment is confirmed, we can update the text = as > > > > follows: > > > > > > > > > > Section 8 of [RFC8446] discusses some mechanisms to impleme= nt > to > > > > > limit the impact of replay attacks on 0-RTT data. If the D= OTS > > > > > server accepts 0-RTT, it MUST implement one of these > mechanisms. > > > > > A DOTS server can reject 0-RTT by sending a TLS > HelloRetryRequest From nobody Thu Feb 28 01:15:12 2019 Return-Path: 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 9AB5D130E79 for ; Thu, 28 Feb 2019 01:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DNJQhVwn9m8N for ; Thu, 28 Feb 2019 01:15:09 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1419C130E6B for ; Thu, 28 Feb 2019 01:15:09 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4496Mb0ZWVz2ygc; Thu, 28 Feb 2019 10:15:07 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4496MZ6tJkzBrLH; Thu, 28 Feb 2019 10:15:06 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([fe80::d89a:9017:59c2:9724%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 10:15:06 +0100 From: To: "Konda, Tirumaleswar Reddy" CC: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt Thread-Index: AQHUysO2BSyTdnM0Qka7k+Ykw8xjSaXr/0pggAY1FWCAAQcR8IABuGog Date: Thu, 28 Feb 2019 09:15:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA268D4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155084937056.5323.18401033305053602209@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA25825@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 09:15:12 -0000 SGkgVGlydSwgDQoNCidpZGxlJyB0aW1lIGlzIG5vdCB3aGVuIG5vIGF0dGFjayB0cmFmZmljIGlz IHByZXNlbnQsIGJ1dCB3aGVuIG5vIGF0dGFjayBtaXRpZ2F0aW9uIGlzIGFjdGl2ZS4gV2UgaGF2 ZSBkcmF3biB0aGlzIGRpc3RpbmN0aW9uIGluIC0xNS4gDQoNClRoZSBpZGxlIGFuZCBtaXRpZ2F0 aW9uIHRpbWVzIGFyZSBpbnRyb2R1Y2VkIGluIHRoZSBkcmFmdC4gSSBtYWRlIHRoaXMgY2hhbmdl IHRvIGF2b2lkIG1pc2ludGVycHJldGF0aW9uOg0KIA0KICAgVGhlIHNhbWUgb3IgZGlzdGluY3Qg Y29uZmlndXJhdGlvbiBzZXRzIG1heSBiZSB1c2VkIGR1cmluZyB0aW1lcyB3aGVuDQogICBhIG1p dGlnYXRpb24gaXMgYWN0aXZlICgnbWl0aWdhdGluZy1jb25maWcnKSBhbmQgd2hlbiBubyBtaXRp Z2F0aW9uDQogICBpcyBhY3RpdmUgKCdpZGxlLWNvbmZpZycpLiAgVGhpcyBpcyBwYXJ0aWN1bGFy bHkgdXNlZnVsIGZvciBET1RTDQogICBzZXJ2ZXJzIHRoYXQgbWlnaHQgd2FudCB0byByZWR1Y2Ug aGVhcnRiZWF0IGZyZXF1ZW5jeSBvciBjZWFzZQ0KICAgaGVhcnRiZWF0IGV4Y2hhbmdlcyB3aGVu IGFuIGFjdGl2ZSBET1RTIGNsaWVudCBoYXMgbm90IHJlcXVlc3RlZA0KICAgbWl0aWdhdGlvbi4g IElmIGRpc3RpbmN0IGNvbmZpZ3VyYXRpb25zIGFyZSB1c2VkLCBET1RTIGFnZW50cyBNVVNUDQog ICBmb2xsb3cgdGhlIGFwcHJvcHJpYXRlIGNvbmZpZ3VyYXRpb24gc2V0IGFzIGEgZnVuY3Rpb24g b2YgdGhlDQogICBtaXRpZ2F0aW9uIGFjdGl2aXR5IChlLmcuLCBpZiBubyBtaXRpZ2F0aW9uIHJl cXVlc3QgaXMgYWN0aXZlIChhbHNvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXiANCiAgIHJlZmVycmVkIHRvIGFz ICdpZGxlJyB0aW1lKSwgJ2lkbGUtY29uZmlnJy1yZWxhdGVkIHZhbHVlcyBtdXN0IGJlDQogICBe Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KICAgZm9sbG93ZWQpLiAgQWRkaXRpb25hbGx5LCBE T1RTIGFnZW50cyBNVVNUIGF1dG9tYXRpY2FsbHkgc3dpdGNoIHRvDQogICB0aGUgb3RoZXIgY29u ZmlndXJhdGlvbiB1cG9uIGEgY2hhbmdlIGluIHRoZSBtaXRpZ2F0aW9uIGFjdGl2aXR5DQogICAo ZS5nLiwgaWYgYW4gYXR0YWNrIG1pdGlnYXRpb24gaXMgbGF1bmNoZWQgYWZ0ZXIgYW4gJ2lkbGUn IHRpbWUsIHRoZQ0KICAgRE9UUyBhZ2VudCBzd2l0Y2hlcyBmcm9tICdpZGxlLWNvbmZpZycgdG8g J21pdGlnYXRpbmctY29uZmlnJy1yZWxhdGVkDQogICB2YWx1ZXMpLg0KDQpCZXR0ZXI/IA0KDQpD aGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb21dDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMjcgZsOpdnJpZXIgMjAxOSAwNzo1Ng0K PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IGRvdHNAaWV0Zi5vcmcN Cj4gT2JqZXTCoDogUkU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFs LWNoYW5uZWwtMjkudHh0DQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZQ0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ID4gU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMjYsIDIwMTkgODo0MiBQTQ0KPiA+IFRvOiBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0KPiA+ IENjOiBkb3RzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFtEb3RzXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMjkudHh0DQo+ID4NCj4gPg0KPiA+DQo+ID4g SGkgVGlydSwNCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0K PiA+IE1lZA0KPiA+DQo+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERl wqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgS29u ZGEsDQo+ID4gPiBUaXJ1bWFsZXN3YXIgUmVkZHkgRW52b3nDqcKgOiB2ZW5kcmVkaSAyMiBmw6l2 cmllciAyMDE5IDE3OjIwIMOAwqA6DQo+ID4gPiBkb3RzQGlldGYub3JnOyBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOg0KPiA+ID4gZHJhZnQtaWV0 Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTI5LnR4dA0KPiA+ID4NCj4gPiA+IEhpIE1lZCwNCj4gPiA+ DQo+ID4gPiBDb3VwbGUgb2YgTml0czoNCj4gPiA+DQo+ID4gPiAxKQ0KPiA+ID4gT0xEOg0KPiA+ ID4gTGlrZXdpc2UsICdzaWQnIHZhbHVlIGlzDQo+ID4gPiBtb25vdG9uaWNhbGx5IGluY3JlYXNl ZCBieSB0aGUgRE9UUyBjbGllbnQgZm9yIGVhY2ggY29uZmlndXJhdGlvbg0KPiA+ID4gc2Vzc2lv biwgYXR0YWNrZXJzIHJlcGxheWluZyBjb25maWd1cmF0aW9uIHJlcXVlc3RzIHdpdGggbG93ZXIg bnVtZXJpYw0KPiA+ID4gJ3NpZCcgdmFsdWVzIHdpbGwgYmUgcmVqZWN0ZWQgYnkgdGhlIERPVFMg c2VydmVyIGlmIGl0IG1haW50YWlucyBhDQo+ID4gPiBoaWdoZXIgbnVtZXJpYyAnc2lkJyB2YWx1 ZSBmb3IgdGhpcyBET1RTIGNsaWVudC4NCj4gPiA+DQo+ID4gPiBORVc6DQo+ID4gPiBMaWtld2lz ZSwgJ3NpZCcgdmFsdWUgaXMNCj4gPiA+IG1vbm90b25pY2FsbHkgaW5jcmVhc2VkIGJ5IHRoZSBE T1RTIGNsaWVudCBmb3IgZWFjaCBjb25maWd1cmF0aW9uDQo+ID4gPiByZXF1ZXN0LCBhdHRhY2tl cnMgcmVwbGF5aW5nIGNvbmZpZ3VyYXRpb24gcmVxdWVzdHMgd2l0aCBsb3dlciBudW1lcmljDQo+ ID4gPiAnc2lkJyB2YWx1ZXMgd2lsbCBiZSByZWplY3RlZCBieSB0aGUgRE9UUyBzZXJ2ZXIgaWYg aXQgbWFpbnRhaW5zIGENCj4gPiA+IGhpZ2hlciBudW1lcmljICdzaWQnIHZhbHVlIGZvciB0aGlz IERPVFMgY2xpZW50Lg0KPiA+ID4NCj4gPg0KPiA+IFtNZWRdIE9LIGZvciBzL3Nlc3Npb24vcmVx dWVzdC4NCj4gPg0KPiA+ID4gMikNCj4gPiA+IERlZmluZSAnaWRsZScgdGltZSAoaS5lLiB3aGVu IG5vIGF0dGFjayB0cmFmZmljIGlzIHByZXNlbnQpLg0KPiA+DQo+ID4gW01lZF0gVGhpcyBvbmUg aXMgbm90IG5lZWRlZCwgSU1ITy4gV2UgZG8gYWxyZWFkeSBoYXZlIHRoZSBmb2xsb3dpbmcgaW4g dGhlDQo+ID4gZHJhZnQ6DQo+ID4NCj4gPiAgICBUaGUgc2FtZSBvciBkaXN0aW5jdCBjb25maWd1 cmF0aW9uIHNldHMgbWF5IGJlIHVzZWQgZHVyaW5nIHRpbWVzIHdoZW4NCj4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5e Xl5eXl4NCj4gPiAgICBhIG1pdGlnYXRpb24gaXMgYWN0aXZlICgnbWl0aWdhdGluZy1jb25maWcn KSBhbmQgd2hlbiBubyBtaXRpZ2F0aW9uDQo+ID4NCj4gPiBeXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4gXl5eXg0KPiA+ ICAgIGlzIGFjdGl2ZSAoJ2lkbGUtY29uZmlnJykuICBUaGlzIGlzIHBhcnRpY3VsYXJseSB1c2Vm dWwgZm9yIERPVFMNCj4gPiAgICBeXl5eXl5eXl5eXl5eXl5eXg0KPiANCj4gVGhlIGFib3ZlIGxp bmVzIGRvIG5vdCBkZWZpbmUgdGhlIHRlcm0gJ2lkbGUnLg0KPiBXZSBqdXN0IGhhdmUgdG8gYXBw ZW5kICIoaS5lLiB3aGVuIG5vIGF0dGFjayB0cmFmZmljIGlzIHByZXNlbnQpIiB0byAnaWRsZScN Cj4gdGltZS4NCj4gDQo+IENoZWVycywNCj4gLVRpcnUNCj4gDQo+ID4gICAgc2VydmVycyB0aGF0 IG1pZ2h0IHdhbnQgdG8gcmVkdWNlIGhlYXJ0YmVhdCBmcmVxdWVuY3kgb3IgY2Vhc2UNCj4gPiAg ICBoZWFydGJlYXQgZXhjaGFuZ2VzIHdoZW4gYW4gYWN0aXZlIERPVFMgY2xpZW50IGhhcyBub3Qg cmVxdWVzdGVkDQo+ID4gICAgbWl0aWdhdGlvbi4gIElmIGRpc3RpbmN0IGNvbmZpZ3VyYXRpb25z IGFyZSB1c2VkLCBET1RTIGFnZW50cyBNVVNUDQo+ID4gICAgZm9sbG93IHRoZSBhcHByb3ByaWF0 ZSBjb25maWd1cmF0aW9uIHNldCBhcyBhIGZ1bmN0aW9uIG9mIHRoZQ0KPiA+ICAgIG1pdGlnYXRp b24gYWN0aXZpdHkgKGUuZy4sIGlmIG5vIG1pdGlnYXRpb24gcmVxdWVzdCBpcyBhY3RpdmUsICdp ZGxlLQ0KPiA+ICAgIGNvbmZpZyctcmVsYXRlZCB2YWx1ZXMgbXVzdCBiZSBmb2xsb3dlZCkuICBB ZGRpdGlvbmFsbHksIERPVFMgYWdlbnRzDQo+ID4gICAgTVVTVCBhdXRvbWF0aWNhbGx5IHN3aXRj aCB0byB0aGUgb3RoZXIgY29uZmlndXJhdGlvbiB1cG9uIGEgY2hhbmdlIGluDQo+ID4gICAgdGhl IG1pdGlnYXRpb24gYWN0aXZpdHkgKGUuZy4sIGlmIGFuIGF0dGFjayBtaXRpZ2F0aW9uIGlzIGxh dW5jaGVkDQo+ID4gICAgYWZ0ZXIgYW4gJ2lkbGUnIHRpbWUsIHRoZSBET1RTIGFnZW50IHN3aXRj aGVzIGZyb20gJ2lkbGUtY29uZmlnJyB0bw0KPiA+ICAgICdtaXRpZ2F0aW5nLWNvbmZpZyctcmVs YXRlZCB2YWx1ZXMpLg0KPiA+DQo+ID4gPg0KPiA+ID4gLVRpcnUNCj4gPiA+DQo+ID4gPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IERvdHMgPGRvdHMtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+ID4gPiA+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zw0KPiA+ID4gPiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIyLCAyMDE5IDk6MDAgUE0NCj4gPiA+ ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+ID4gPiBDYzogZG90c0BpZXRmLm9yZw0K PiA+ID4gPiBTdWJqZWN0OiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXNpZ25h bC1jaGFubmVsLTI5LnR4dA0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQg ZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljaw0KPiA+ID4gPiBs aW5rcw0KPiA+ID4gb3INCj4gPiA+ID4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29n bml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZQ0KPiA+ID4gPiBjb250ZW50IGlzDQo+ID4gPiBz YWZlLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPiA+IGRpcmVjdG9y aWVzLg0KPiA+ID4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBERG9TIE9wZW4g VGhyZWF0IFNpZ25hbGluZyBXRyBvZiB0aGUNCj4gSUVURi4NCj4gPiA+ID4NCj4gPiA+ID4gICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBEaXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVu IFRocmVhdA0KPiA+ID4gU2lnbmFsaW5nIChET1RTKQ0KPiA+ID4gPiBTaWduYWwgQ2hhbm5lbCBT cGVjaWZpY2F0aW9uDQo+ID4gPiA+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogVGlydW1hbGVz d2FyIFJlZGR5DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9oYW1lZCBCb3Vj YWRhaXINCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBQcmFzaGFudGggUGF0aWwN Cj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBBbmRyZXcgTW9ydGVuc2VuDQo+ID4g PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTmlrIFRlYWd1ZQ0KPiA+ID4gPiAJRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTI5LnR4dA0KPiA+ID4g PiAJUGFnZXMgICAgICAgICAgIDogOTkNCj4gPiA+ID4gCURhdGUgICAgICAgICAgICA6IDIwMTkt MDItMjINCj4gPiA+ID4NCj4gPiA+ID4gQWJzdHJhY3Q6DQo+ID4gPiA+ICAgIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsLCBhIHByb3RvY29sIGZvcg0KPiA+ ID4gPiAgICBzaWduYWxpbmcgdGhlIG5lZWQgZm9yIHByb3RlY3Rpb24gYWdhaW5zdCBEaXN0cmli dXRlZCBEZW5pYWwtb2YtDQo+ID4gPiA+ICAgIFNlcnZpY2UgKEREb1MpIGF0dGFja3MgdG8gYSBz ZXJ2ZXIgY2FwYWJsZSBvZiBlbmFibGluZyBuZXR3b3JrDQo+ID4gPiA+ICAgIHRyYWZmaWMgbWl0 aWdhdGlvbiBvbiBiZWhhbGYgb2YgdGhlIHJlcXVlc3RpbmcgY2xpZW50Lg0KPiA+ID4gPg0KPiA+ ID4gPiAgICBBIGNvbXBhbmlvbiBkb2N1bWVudCBkZWZpbmVzIHRoZSBET1RTIGRhdGEgY2hhbm5l bCwgYSBzZXBhcmF0ZQ0KPiA+ID4gPiAgICByZWxpYWJsZSBjb21tdW5pY2F0aW9uIGxheWVyIGZv ciBET1RTIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24NCj4gPiA+ID4gICAgcHVycG9zZXMu DQo+ID4gPiA+DQo+ID4gPiA+IEVkaXRvcmlhbCBOb3RlIChUbyBiZSByZW1vdmVkIGJ5IFJGQyBF ZGl0b3IpDQo+ID4gPiA+DQo+ID4gPiA+ICAgIFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50 cyB3aXRoaW4gdGhlIGRvY3VtZW50IHdpdGggdGhlIFJGQw0KPiA+ID4gPiAgICBudW1iZXIgdG8g YmUgYXNzaWduZWQgdG8gdGhpcyBkb2N1bWVudDoNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgIlRo aXMgdmVyc2lvbiBvZiB0aGlzIFlBTkcgbW9kdWxlIGlzIHBhcnQgb2YgUkZDIFhYWFg7Ig0KPiA+ ID4gPg0KPiA+ID4gPiAgICBvICAiUkZDIFhYWFg6IERpc3RyaWJ1dGVkIERlbmlhbC1vZi1TZXJ2 aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZw0KPiA+ID4gPiAgICAgICAoRE9UUykgU2lnbmFsIENo YW5uZWwgU3BlY2lmaWNhdGlvbiI7DQo+ID4gPiA+DQo+ID4gPiA+ICAgIG8gICJ8IFtSRkNYWFhY XSB8Ig0KPiA+ID4gPg0KPiA+ID4gPiAgICBvICByZWZlcmVuY2U6IFJGQyBYWFhYDQo+ID4gPiA+ DQo+ID4gPiA+ICAgIFBsZWFzZSB1cGRhdGUgdGhpcyBzdGF0ZW1lbnQgd2l0aCB0aGUgUkZDIG51 bWJlciB0byBiZSBhc3NpZ25lZCB0bw0KPiA+ID4gPiAgICB0aGUgZm9sbG93aW5nIGRvY3VtZW50 czoNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgIlJGQyBZWVlZOiBEaXN0cmlidXRlZCBEZW5pYWwt b2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcNCj4gPiA+ID4gICAgICAgKERPVFMpIERh dGEgQ2hhbm5lbCBTcGVjaWZpY2F0aW9uICh1c2VkIHRvIGJlIEktRC5pZXRmLWRvdHMtZGF0YS0N Cj4gPiA+ID4gICAgICAgY2hhbm5lbCkNCj4gPiA+ID4NCj4gPiA+ID4gICAgUGxlYXNlIHVwZGF0 ZSBUQkQvVEJEMS9UQkQyIHN0YXRlbWVudHMgd2l0aCB0aGUgYXNzaWdubWVudHMgbWFkZSBieQ0K PiA+ID4gPiAgICBJQU5BIHRvIERPVFMgU2lnbmFsIENoYW5uZWwgUHJvdG9jb2wuDQo+ID4gPiA+ DQo+ID4gPiA+ICAgIEFsc28sIHBsZWFzZSB1cGRhdGUgdGhlICJyZXZpc2lvbiIgZGF0ZSBvZiB0 aGUgWUFORyBtb2R1bGVzLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiA+ID4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLw0K PiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFi bGUgYXQ6DQo+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRv dHMtc2lnbmFsLWNoYW5uZWwtMjkNCj4gPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwNCj4gPiA+ID4gLTI5DQo+ ID4gPiA+DQo+ID4gPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0yOQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPiA+ID4gc3VibWlzc2lvbg0KPiA+ID4gPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+ID4gPg0K PiA+ID4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+ID4gPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4g PiA+DQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+IERvdHNAaWV0Zi5vcmcNCj4g PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPg0K PiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPiBEb3RzQGlldGYub3JnDQo+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Thu Feb 28 01:29:11 2019 Return-Path: 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 AC0BA130E5B; Thu, 28 Feb 2019 01:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EDD0WLZUXJel; Thu, 28 Feb 2019 01:29:09 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDB3130E25; Thu, 28 Feb 2019 01:29:09 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4496gl51q4z8v1Z; Thu, 28 Feb 2019 10:29:07 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4496gl4GVWzCqks; Thu, 28 Feb 2019 10:29:07 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([fe80::9108:27dc:3496:8db3%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 10:29:07 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Benjamin Kaduk" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxRIUb7c2dDIvj0uWD4RT8wY9CqXgsiOQgAAV9gCAEoE9oIABuMSw Date: Thu, 28 Feb 2019 09:29:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA26902@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA1FEC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 09:29:11 -0000 UmUtLA0KDQpJIGFkZGVkIHRoaXMgbm90ZSB0byBteSBsb2NhbCBjb3B5OiANCg0KICAgSG93IGEg RE9UUyBjbGllbnQgc3luY2hyb25pemVzIGl0cyBjb25maWd1cmF0aW9uIHdpdGggdGhlIG9uZQ0K ICAgbWFpbnRhaW5lZCBieSBpdHMgRE9UUyBzZXJ2ZXIocykgaXMgaW1wbGVtZW50YXRpb24tc3Bl Y2lmaWMuICBGb3INCiAgIGV4YW1wbGUsIGEgRE9UUyBjbGllbnQgY2FuIHNlbmQgYSBHRVQgbWVz c2FnZSBiZWZvcmUgYW5kL29yIGFmdGVyIGVhY2gNCiAgIGNvbmZpZ3VyYXRpb24gY2hhbmdlIHJl cXVlc3QuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAyNyBmw6l2cmllciAy MDE5IDA3OjU5DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IEJlbmphbWluIEth ZHVrDQo+IENjwqA6IGRvdHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWxA aWV0Zi5vcmcNCj4gT2JqZXTCoDogUkU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtZGF0 YS1jaGFubmVsLTI1DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJv bTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4NCj4gPiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE1LCAyMDE5IDU6NTMgUE0NCj4gPiBU bzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbT47DQo+ID4gQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+ID4gQ2M6IGRv dHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWxAaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUN Cj4gPg0KPiA+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2Fu aXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzDQo+IG9yDQo+ID4gb3BlbiBhdHRhY2htZW50cyB1 bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzDQo+ IHNhZmUuDQo+ID4NCj4gPiBIaSBUaXJ1LA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiA+ID4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gW21h aWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+ID4gRW52b3nDqcKg OiB2ZW5kcmVkaSAxNSBmw6l2cmllciAyMDE5IDEyOjA2IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVk IFRHSS9PTE47DQo+ID4gPiBCZW5qYW1pbiBLYWR1ayBDY8KgOiBkb3RzQGlldGYub3JnOw0KPiA+ ID4gZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiA+ID4gT2JqZXTCoDog UkU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI1DQo+ID4gPg0K PiA+ID4gSSBhbSBjYXRjaGluZyB1cCB3aXRoIHRoZSBkaXNjdXNzaW9uLCBjb3VwbGUgb2YgcG9p bnRzOg0KPiA+ID4NCj4gPiA+IDEpDQo+ID4gPiAgICAgICAqICBJZiBhIG5ldHdvcmsgcmVzb3Vy Y2UgKERPVFMgY2xpZW50KSBkZXRlY3RzIGEgcG90ZW50aWFsIEREb1MNCj4gPiA+ICAgICAgICAg IGF0dGFjayBmcm9tIGEgc2V0IG9mIElQIGFkZHJlc3NlcywgdGhlIERPVFMgY2xpZW50IGluZm9y bXMgaXRzDQo+ID4gPiAgICAgICAgICBzZXJ2aWNpbmcgRE9UUyBnYXRld2F5IG9mIGFsbCBzdXNw ZWN0IElQIGFkZHJlc3NlcyB0aGF0IG5lZWQgdG8NCj4gPiA+ICAgICAgICAgIGJlIGRyb3AtIG9y IGFjY2VwdC1saXN0ZWQgZm9yIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbi4NCj4gPiA+DQo+ID4gPiBD b21tZW50PiBJIGRvbid0IHNlZSB3aHkgc3VzcGVjdCBJUCBhZGRyZXNzZXMgd2lsbCBiZSBhY2Nl cHQtbGlzdGVkID8NCj4gPiA+ICAgICAgICAgICAgICAgICAgICAgV2UgbWF5IHdhbnQgdG8gcmVt b3ZlICJvciBhY2NlcHQtbGlzdGVkIiBmcm9tIHRoZQ0KPiA+ID4gYWJvdmUgbGluZS4NCj4gPiA+ DQo+ID4NCj4gPiBbTWVkXSBBY2suDQo+ID4NCj4gPiA+IFtNZWRdIFRoZSBkb3RzIGNsaWVudCB3 aWxsIGtub3cgaWYgaXRzIHJlcXVlc3QgaXMgc3VjY2Vzc2Z1bGx5IGRlbGl2ZXJlZC4NCj4gPiA+ IFdoZW4gYW4gYXR0YWNrIGlzIG9uZ29pbmcsIHRoZSBkb3RzIGNsaWVudCBzaG91bGQgbm90IHVz ZSBpdCBkYXRhDQo+ID4gPiBjaGFubmVsIGJlY2F1c2UgaXQgaXMgbGlrZWx5IHRvIGJlIHBlcnR1 cmJlZC4NCj4gPiA+DQo+ID4gPiBDb21tZW50PiBJZiB0aGUgSFRUUCByZXNwb25zZSBmcm9tIHRo ZSBzZXJ2ZXIgZGlkIG5vdCByZWFjaCB0aGUgY2xpZW50DQo+ID4gPiBiZWNhdXNlIG9mIGEgdm9s dW1ldHJpYyBhdHRhY2sgc2F0dXJhdGluZyB0aGUgaW5jb21pbmcgdGhlIGxpbmssIHRoZQ0KPiA+ ID4gRE9UUyBjbGllbnQgd2lsbCBub3Qga25vdyB3aGV0aGVyIHRoZSBjb25maWd1cmF0aW9uIGlz IHN1Y2Nlc3NmdWxseQ0KPiA+ID4gdXBkYXRlZCBvciBub3QuIEFmdGVyIHRoZSBhdHRhY2sgaXMg bWl0aWdhdGVkLCB0aGUgY2xpZW50IHdpbGwgaGF2ZSB0bw0KPiA+ID4gcmUtZXN0YWJsaXNoIHRo ZSBUTFMgc2Vzc2lvbiBhbmQgcmV0cmlldmUgdGhlIGNvbmZpZ3VyYXRpb24gdG8gY2hlY2sNCj4g PiA+IGlmIGl0cyBsYXN0IHJlcXVlc3Qgd2FzIHN1Y2Nlc3NmdWxseSBhcHBsaWVkIG9yIG5vdCBi ZWZvcmUgdXBkYXRpbmcNCj4gPiA+IHRoZSBjb25maWd1cmF0aW9uLg0KPiA+ID4NCj4gPg0KPiA+ IFtNZWRdIEFncmVlLiBTdGlsbCwgaG93IHRoZSBjbGllbnQgc3luY3MgaXRzIGNvbmZpZyB3aXRo IHRoZSBvbmUgbWFpbnRhaW5lZA0KPiBieQ0KPiA+IHRoZSBzZXJ2ZXIgaXMgaW1wbGVtZW50YXRp b24tc3BlY2lmaWMuIEEgY2xpZW50IGNhbiBzZW5kIGEgR0VUIGJlZm9yZQ0KPiBhbmQvb3INCj4g PiBhZnRlciBhIGNvbmZpZ3VyYXRpb24gY2hhbmdlIHJlcXVlc3QsIGluIHJlZ3VsYXIgaW50ZXJ2 YWxzLCBhZnRlciBhdHRhY2sNCj4gPiBtaXRpZ2F0aW9uLCBldGMuDQo+IA0KPiBBZGRpbmcgYSBJ bXBsZW1lbnRhdGlvbiBOb3RlIGxvb2tzIHVzZWZ1bCB0byBtZS4NCj4gDQo+IC1UaXJ1DQo+IA0K PiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiAtVGlydQ0K From nobody Thu Feb 28 02:32:34 2019 Return-Path: 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 C3DB1130E6E; Thu, 28 Feb 2019 02:32:32 -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 ZxJakCo1dNRd; Thu, 28 Feb 2019 02:32:29 -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 19FDA128B36; Thu, 28 Feb 2019 02:32:28 -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=1551349787; 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-ms-exchange-purlcount: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=p FVIi3qmRwHCpdan2cDiiXgX/obsaSUn0i/sQcmhY6 A=; b=XF7isXWb4iFk0roq6zC5N/9F/BaZo6iqI1gaxVzOrLbN 0yca3lWgRIlA27ak12T4tPuExGgvFxCpYsk6K76WUZEEyU5XA7 feXnlukWWCFl5pJwtPbkP3XqwdT9zze/iYv0el1PVa460e5Kcv etpq7o38GVPkNhZ2fiwDK5Sp2Oo= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 21ae_f807_ebaa70e7_f0b2_4909_9076_c19674750f64; Thu, 28 Feb 2019 03:29:47 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:31:53 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 28 Feb 2019 03:31:53 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:31:52 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2903.namprd16.prod.outlook.com (20.178.235.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Thu, 28 Feb 2019 10:31:51 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 10:31:51 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , "mohamed.boucadair@orange.com" CC: "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUx6Zad4wSPXSxIUiJUgMrwAb+nKXmwseAgA0YNQCAAAXmIA== Date: Thu, 28 Feb 2019 10:31:50 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227155729.GL53396@kduck.mit.edu> In-Reply-To: <20190227155729.GL53396@kduck.mit.edu> 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: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b899997-f09d-4e72-5259-08d69d67f388 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2903; x-ms-traffictypediagnostic: BYAPR16MB2903: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyOTAzOzIzOkM2KzU5MFJjQ0REaXhwZXl2UTVyVVBjQ2ZC?= =?utf-8?B?bkZPeVl1dENyL3UrZVhQa3ZvMHljSGE3ZWpCV04rMHU2TU1SUXhmSzdnczFk?= =?utf-8?B?VTlVaUlXdXBtbDlEWElWRWdnK2xHdk1Ea3lwNndsaFNvcUM3OFdWd0p1U0lk?= =?utf-8?B?TjY2cUF6a3BPNTJjUk5ta0owQ1hnWit0QzFTeGtFaEpkY3pkRlJaWUZOU3Y0?= =?utf-8?B?b0ZXL1lnS0RqRFlmMUVBbEJpaVoyTFFJV01kcnJqVHViSFBFZitTNFJKQ0tD?= =?utf-8?B?Tml4N2p1eWsraUhxS3hEeml5elJMbFh1MlhaZkNwYUIvbm8xbXRGNkowMXhI?= =?utf-8?B?anFUSUtORFkvL04zL2NvZWJlZ1dNOTRaa0k5Q1NzSEJYTnVZaDJ3VjFDRXhN?= =?utf-8?B?VkdJSmozQk82VE1sK01wbFdKVTBtdnlPZXRGejNIai9SN1BPaTFCNmc1NXB5?= =?utf-8?B?UXIyczdUdElQNURFQmdRWWpoUnI2Yzh0U3NkYkMrd0ZwaGFDQ1NmM3FKNlZs?= =?utf-8?B?YnBMYVdjTFRSNnFSQS93THJkeFMwM1p0YmRsZERLQXE1cjd0OTNRK2RINld4?= =?utf-8?B?Zy80WUV5Qit0WjVJRFY3TlRxZEp4Nk5nVEthNnlFNGV1dnJ2L0lweDI0R1RN?= =?utf-8?B?bkxIYW5mSjVoS1hPdmY3RUgybHNxMjBVekdsbFNsN1Q0SmkrNjB1c0d0TldV?= =?utf-8?B?UmNkT2hsOXN5UUhRc3VmS1pXVTFqdm9hUnVvSXBseHRPVkxlVTdTYkw1QWFw?= =?utf-8?B?TlJJcUhvZGlQUmZERVZDRkg2alhmWUdBWC9GeFErVHJXeWs2R0JwWWRCck9r?= =?utf-8?B?bVNiQVc5TXdUdEhVY29zeEQ4TGRCUEErOEUvZ0FiMmpRaWw3cisyK3pYYmVt?= =?utf-8?B?MnRzSkc5djBlQlhnL2creFVTVDhwQzV2K1R0TVFQVXg4VDJMcyt1ZlhFaVZz?= =?utf-8?B?MUt4TUlaOHpaZnpPaUNnSVdWcnNKSnNET2hnS0tBL0g4SXZ6bmVDNG0wMUpC?= =?utf-8?B?L2xuM3NHanhTeU40TVZ4WkcxdFJ3Y3F6bUF3OVpHQVh3SWRKcVJLV2JNQ2lZ?= =?utf-8?B?OW5jYmxPNHVQRE4yRWJYUnFXeW5kRFNPc3JOc0FZSTFiSHlKTkp3Qm1lZjJS?= =?utf-8?B?dVBCR1d1UUVTa0FFcHZTNmZrcklOckVMby9LSE5KVEVlWUhoVjVJN0RGTmhu?= =?utf-8?B?cTJCbnlqY3JocjZiTGRCT1cybkNjbGRqYkZuM0NsOHB4UlMvWGRyemRtcnFZ?= =?utf-8?B?RC8yTFNLcE9jZDRZTEx6cXJucjVqTy96QjJVQkNWRjBLZC82aGExcUpWWGdy?= =?utf-8?B?dEc0cyttM0Z5L2dYU0RuS0pHYldXaWE4TCt3UlljekxkdGJXc2s4Qzdya0pE?= =?utf-8?B?Ym9YSWs4VWRnL0FTOHhTQk5rWWdPQzJGNE1qczJYSFkrUVZiRGNvYU1ZSXBS?= =?utf-8?B?cjliNHg3dW5XcTZRTjF0eTB3bCtMTnFpR2dkOVZOemZjRjUzTE56OWlHVzY0?= =?utf-8?B?MlI3YVpaSXYrOTBHQlBOYmFyYmttU0pPYWlPaXZIK1ZTcE40NHJGUkxBbGht?= =?utf-8?B?NWNGaW1HMXkzZTE1bzRZTnlTUTN0STNsNjVZWDdiOEFsZCt3YmNTeGFuWWgz?= =?utf-8?B?R3JlOEdaSEZKU1lsY0xtamFjUTRMdUorR2dCdXhrWkV0eERidHFWM0dtZW9I?= =?utf-8?B?THlFUEduQUxxK2U3aUk1dFpDbmgxOFVsbHFWb3J0SEhFcVFhUUZDb0ZWZ2ZM?= =?utf-8?B?ZVQyRFBvbEJQVHc5Q2FyRm0vNVRuUFZBaktVUExFOFhKRWM5YUNZanhGZTZW?= =?utf-8?B?WHpKeGgvd2IzbDhLK1pUUE90UlVSNnFJc2VGYmhDWDhocW1pUWZGdkVhbm1J?= =?utf-8?B?b0MxRHJMRG1MQ0JrOGRmdkFEc3ZlekxSK2pvU1JuSnlxTWNxemJ4bWE4OE5m?= =?utf-8?B?RHBqTVBubnFhSzhBcGxrWmg2QW11Tkt4eUJwampUMGc1enQxanJsTVovcmFB?= =?utf-8?B?NkR6RXZuQnBIMGlDcFFERXBWSVlvYVpmRk9WWmc0WVY3akJPQnptQVY1ZzZw?= =?utf-8?B?R3Vkd093WSs3akh3c09mSS9zbXk2YmhoaGpqRStibUwyYlh2Y2Jsa2hNN1pY?= =?utf-8?Q?vX1rw9vzss3rmyhMLn/YyfM=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39850400004)(51444003)(199004)(189003)(13464003)(32952001)(81156014)(81166006)(9686003)(6306002)(5660300002)(6436002)(102836004)(53546011)(6506007)(55016002)(72206003)(105586002)(8676002)(99286004)(66574012)(229853002)(7696005)(25786009)(6246003)(2171002)(4326008)(561944003)(7736002)(97736004)(33656002)(53946003)(53936002)(74316002)(76176011)(305945005)(26005)(966005)(80792005)(14454004)(2906002)(71190400001)(478600001)(71200400001)(93886005)(30864003)(68736007)(476003)(8936002)(66066001)(106356001)(54906003)(110136005)(3846002)(6116002)(316002)(86362001)(2501003)(14444005)(256004)(186003)(486006)(11346002)(52536013)(446003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2903; H:BYAPR16MB2790.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: mleEAolyRhjidiHbJv76O/m2NaKEzbn4TiXz4JyHT80eeejW2DtMGxVUtLFoC1kqtucCbiCPK8yfnnI3ww8ahU083AMqgaMVTQv+xJ1dQMgi03w+aInC+qo9NF2s3p5xreWUGoDJK6AFHjGMZ9pH2FUqVeQ1lfbtIu2CM50v9u8lWN1V3vqhraJ4WjcCdBHVpvKyJtPzvX1/g2wvp3ugC0UvvFYYJEpS2QlHB3TBvm2mGfQNWptJU/Ac+BMKmGswJ2tkwApwYVCMecbbmLEC5YLfdUdK4tY0UtTv9YnwXjLKTku7ngMxK+XlIzNW7wIpb8EdAD7MCYr4DarBjKRg5CdXIoHa12AHwt4ElTZZAVcznQmOmnotkx6mzk6aB8acUHXmITDAAPk30LJDsan6k/lITslbbxozuijL0BeRQBI= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6b899997-f09d-4e72-5259-08d69d67f388 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 10:31:51.1352 (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: BYAPR16MB2903 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7025> : streams <1814337> : uri <2803626> Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 10:32:33 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1ayA8a2Fk dWtAbWl0LmVkdT4NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNywgMjAxOSA5OjI4IFBN DQo+IFRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IENjOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsNCj4gZHJh ZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBVc2luZyBFYXJseSBEYXRhIGluIERPVFMgKFJFOiBbRG90c10gQUQgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtZG90cy0NCj4gc2lnbmFsLWNoYW5uZWwpDQo+IA0KPiANCj4gDQo+IE9u IFR1ZSwgRmViIDE5LCAyMDE5IGF0IDA3OjU5OjI5QU0gKzAwMDAsIG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20NCj4gd3JvdGU6DQo+ID4gSGkgQmVuLA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBp bmxpbmUuDQo+IA0KPiBPa2F5LiAgQlRXLCBpdCBpcyBsb29raW5nIGxpa2UgdGhpcyBpcyB0aGUg bGFzdCB0b3BpYyB0byByZXNvbHZlIGJlZm9yZSBzdGFydGluZyBJRVRGDQo+IExDLiAgSXQncyBw cm9iYWJseSB3b3J0aCBzL3RoZSBleHBvbmVudCBpcyAyL3RoZSBiYXNlIG9mIHRoZSBleHBvbmVu dCBpcyAyLyBpbiB0aGUNCj4gbmV4dCByZXYsIHRob3VnaCwganVzdCBhcyBhIG1pbm9yIG5pdC1m aXguDQo+IA0KPiA+DQo+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERl wqA6IEJlbmphbWluIEthZHVrIFttYWlsdG86a2FkdWtAbWl0LmVkdV0gRW52b3nDqcKgOiBsdW5k aSAxOCBmw6l2cmllcg0KPiA+ID4gMjAxOSAxNzoyMyDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBU R0kvT0xOIENjwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXINCj4gPiA+IFJlZGR5OyBkcmFmdC1pZXRm LWRvdHMtc2lnbmFsLWNoYW5uZWxAaWV0Zi5vcmc7DQo+ID4gPiBkb3RzQGlldGYub3JnDQo+ID4g PiBPYmpldMKgOiBSZTogVXNpbmcgRWFybHkgRGF0YSBpbiBET1RTIChSRTogW0RvdHNdIEFEIHJl dmlldyBvZg0KPiA+ID4gZHJhZnQtaWV0Zi0NCj4gPiA+IGRvdHMtc2lnbmFsLWNoYW5uZWwpDQo+ ID4gPg0KPiA+ID4gT24gRnJpLCBGZWIgMTUsIDIwMTkgYXQgMDM6MzY6MDVQTSArMDAwMCwNCj4g bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiA+ID4gUmUtLA0KPiA+ID4g Pg0KPiA+ID4gPiBMb29raW5nIGZvcndhcmQgdG8gZGlzY3VzcyB0aGlzIGZ1cnRoZXIuDQo+ID4g PiA+DQo+ID4gPiA+IEkgd29uZGVyIHdoZXRoZXIgeW91IGNhbiBjb25zaWRlciBwdXR0aW5nIHRo ZSBkb2N1bWVudCBpbiB0aGUgSUVURg0KPiA+ID4gPiBMQyBmb3INCj4gPiA+IG5vdy4gSWYgaXQg aGFwcGVuIHRoYXQgd2UgbmVlZCB0byBtb2RpZnkgdGhlIDAtUlRUIHRleHQsIHdlIHdpbGwNCj4g PiA+IGhhbmRsZSBpdCBhcyBvdGhlciBJRVRGIExDIGNvbW1lbnRzLg0KPiA+ID4NCj4gPiA+IEkg d291bGQgbm9ybWFsbHkgYmUgcHJldHR5IGFtZW5hYmxlIHRvIHN0YXJ0aW5nIElFVEYgTEMgYW5k DQo+ID4gPiBjb250aW51aW5nIGRpc2N1c3Npb247IGl0J3MganVzdCBmb3IgdGhpcyBpc3N1ZSBp biBwYXJ0aWN1bGFyIHRoYXQgSQ0KPiA+ID4gc2VlbSB0byBiZSB0aGUgbWFpbiBwZXJzb24gb24g dGhlIElFU0cgdGhhdCBlbmZvcmNlcyB0aGUNCj4gPiA+ICJhcHBsaWNhdGlvbiBwcm9maWxlIGZv ciAwLVJUVCBkYXRhIiByZXF1aXJlbWVudCwgc28gaXQgd291bGQgZmVlbCByYXRoZXIgb2RkDQo+ IHRvIGdvIGZvcndhcmQgaW4gdGhpcyBjYXNlLg0KPiA+DQo+ID4gW01lZF0gRmFpciBlbm91Z2gu DQo+ID4NCj4gPiA+IEx1Y2tpbHksIEkgc3BlbnQgc29tZSB0aW1lIHRoaXMgd2Vla2VuZCByZWFk aW5nIFJGQyA3MjUyIGFuZCBoYXZlDQo+ID4gPiBzb21lIHN1YnN0YW50aXZlIGNvbW1lbnRzLg0K PiA+ID4NCj4gPiA+IFRoZSBrZXkgb2JlcnNlcnZhdGlvbiBoZXJlIHNlZW1zIHRvIGJlIHRoYXQg dGhlIE1lc3NhZ2UgSUQgaXMgc2NvcGVkDQo+ID4gPiBwZXIgZW5kcG9pbnQsIGFuZCByZXBsYXlz IGNhbiBjb21lIGZyb20gYXJiaXRyYXJ5IGFkZHJlc3Nlcy4NCj4gPiA+DQo+ID4gPiBTcGVjaWZp Y2FsbHksIHdlIHJlY2FsbCB0aGF0Og0KPiA+ID4NCj4gPiA+ICAgIFRoZSBET1RTIHNpZ25hbCBj aGFubmVsIGlzIGxheWVyZWQgb24gZXhpc3Rpbmcgc3RhbmRhcmRzIChGaWd1cmUgMykuDQo+ID4g Pg0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICB8IERPVFMgU2lnbmFsIENoYW5uZWwg fA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgQ29BUCAgICAgICAg fA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0t Kw0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgVExTICAgIHwgICBEVExTICAg fA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0t Kw0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgVENQICAgIHwgICBVRFAgICAg fA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0t Kw0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIElQICAgICAgICAg fA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPiA+ID4NCj4gPiA+IFdlIG5vdGUgdGhhdCBDb0FQIGlzIHVzaW5nIHRoZSBJUCBhZGRyZXNz IG9yICJEVExTIHNlc3Npb24iDQo+ID4gPiAoYXJndWFibHkgYSBwb29ybHkgY2hvc2VuIHRlcm0p IHRvIGlkZW50aWZ5IGEgQ29BUCBhc3NvY2lhdGlvbiBhbmQNCj4gPiA+IHRoYXQgTWVzc2FnZSBJ RHMgYXJlIG9ubHkgdXNlZCB3aXRoaW4gdGhlIHNjb3BlIG9mIHN1Y2ggYW4NCj4gPiA+IGFzc29j aWF0aW9uLCBpdCBzZWVtcyBwcmV0dHkgY2xlYXIgdGhhdCBhbiBhdHRhY2tlciBhYmxlIHRvIHJl cGxheQ0KPiA+ID4gVExTIDEuMyAwLVJUVCBkYXRhIHdpbGwgc2xpY2Ugb2ZmIHRoZSB0b3AgdGhy ZWUgbGluZXMgb2YgdGhpcyBmaWd1cmUNCj4gPiA+IGFuZCBzd2FwIG91dCB0aGUgVENQL1VEUC9J UCBsYXllcnMuICBJbiB0aGUgYWJzZW5jZSBvZiBEVExTIGNvbm5lY3Rpb24gSURzLA0KPiBteSB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlICJEVExTIHNlc3Npb24iDQo+ID4gPiBpcyBpZGVudGlm aWVkIHNvbGVseSBieSB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24sIGp1c3QgYXMgZm9yDQo+ID4g PiBjb2FwLW5vdC1zLCBzbyBieSBzcG9vZmluZyB0aGUgc291cmNlIGFkZHJlc3MsIHRoZSBhdHRh Y2tlciBjYXVzZXMNCj4gPiA+IHRoZSByZXBsYXllZCAwLVJUVCBkYXRhIChhbmQgdGh1cywgQ29B UCByZXF1ZXN0KSB0byBiZSBpbnRlcnByZXRlZA0KPiA+ID4gYXMgYSBuZXcgaW5jb21pbmcgY29h cHMgY29ubmVjdGlvbi4NCj4gPiA+DQo+ID4gPiBHaXZlbiB0aGF0IE1lc3NhZ2UgSUQgaXMgb25s eSAxNiBiaXRzIGFuZCB0aGUgc2VydmVycyBhY2NlcHRpbmcNCj4gPiA+IDAtUlRUIGRhdGEgaGF2 ZSBwb3RlbnRpYWwgdG8gYmUgcXVpdGUgYnVzeSwgaXQgZG9lcyBub3Qgc2VlbQ0KPiA+ID4gd29y a2FibGUgdG8gYXR0ZW1wdCB0byB1c2UgdGhlIGluY29taW5nIE1lc3NhZ2UgSURzIGFzIGdsb2Jh bGx5DQo+ID4gPiB1bmlxdWUgcmVwbGF5IGRlZmVuc2UsIGFzIHRoZSByaXNrIG9mIGNvbGxpc2lv biB3b3VsZCBiZSBwcmV0dHkgbGFyZ2UuDQo+ID4NCj4gPiBbTWVkXSBUaGUgcmVwbGF5IGRldGVj dGlvbiByZWxpZXMgb24gYm90aCBNZXNzYWdlIElEIGFuZCBUb2tlbi4NCj4gDQo+IEluIHN0b2Nr IENvQVAsIHRoZSBNZXNzYWdlIElEIGFuZCBUb2tlbiBhcmUgdXNlZCBvbmx5IHdpdGggdGhlIGNv bnRleHQgb2YgYQ0KPiBzcGVjaWZpYyB0cmFuc3BvcnQgYXNzb2NpYXRpb24uICBJbiBvcmRlciB0 byB1c2UgdGhlbSBmb3IgKEQpVExTIDEuMyByZXBsYXkNCj4gZGVmZW5zZSwgd2UgbmVlZCB0byBl eHBhbmQgdGhhdCBjb250ZXh0IHRvIGEgYnJvYWRlciBzY29wZSwgYW5kIGRpcmVjdCB0aGUNCj4g c2VydmVyIHRvIGNoZWNrIHRoZSBNZXNzYWdlIElEL1Rva2VuIGdsb2JhbGx5IChvciBhdCBsZWFz dCB3aXRoaW4gdGhlIHNjb3BlIG9mIGENCj4gZ2l2ZW4gJ2N1aWQnLydjZGlkJykuICBTaW5jZSB0 aGlzIHdvdWxkIHJlZmxlY3QgYSBkaXZlcmdlbmNlIGZyb20gbm9ybWFsIENvQVAsIGlmDQo+IHdl IGFyZSBnb2luZyB0byByZWx5IG9uIHRoaXMgc29ydCBvZiBiZWhhdmlvciwgd2UgbXVzdCBjYWxs IGl0IG91dCB2ZXJ5IGxvdWRseSBhcw0KPiBzcGVjaWZpYyB0byBET1RTLg0KDQpBZ3JlZWQuDQoN Cj4gDQo+ID4gPg0KPiA+ID4gU28gSSB0aGluayB0aGF0IHRoZSAnbWlkJyBtb25vdG9uaWNpdHkg YW5kIHRoZSByZWplY3Rpb24gb2YNCj4gPiA+IGNvbmZsaWN0aW5nIHJlcXVlc3Qgc2NvcGVzIGFy ZSB0aGUgbWFpbiBtaXRpZ2F0aW5nIGZhY3RvcnMgYWdhaW5zdA0KPiA+ID4gcmVwbGF5IGluIHRo ZSBjdXJyZW50IGRlc2lnbiAoYWxvbmdzaWRlIHRoZSBSRkMgODQ0NiBtZWNoYW5pc21zLCBvZg0K PiA+ID4gY291cnNlKSwgYW5kIHRoZSB0ZXh0IHNob3VsZCBiZSBhZGp1c3RlZCB0byByZWZsZWN0 IHRoYXQuDQo+ID4NCj4gPiBbTWVkXSBXZSBkbyBhbHJlYWR5IGhhdmUgdGhlIGZvbGxvd2luZyBp biB0aGUgZHJhZnQ6DQo+ID4NCj4gPiAgICAgICBUaGUgRE9UUyBzZXJ2ZXIocykgY2FuIHVzZSBN ZXNzYWdlIElEIGFuZA0KPiA+ICAgICAgIFRva2VuIGluIHRoZSBET1RTIHNpZ25hbCBjaGFubmVs IG1lc3NhZ2UgdG8gZGV0ZWN0IHJlcGxheSBvZiBlYXJseQ0KPiA+ICAgICAgIGRhdGEsIGFuZCBh Y2NlcHQgMC1SVFQgZGF0YSBhdCBtb3N0IG9uY2UuICBGdXJ0aGVybW9yZSwgJ21pZCcNCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5e Xl5eXl5eXl5eDQo+ID4gICAgICAgdmFsdWUgaXMgbW9ub3RvbmljYWxseSBpbmNyZWFzZWQgYnkg dGhlIERPVFMgY2xpZW50IGZvciBlYWNoDQo+ID4gICAgICAgbWl0aWdhdGlvbiByZXF1ZXN0LCBh dHRhY2tlcnMgcmVwbGF5aW5nIG1pdGlnYXRpb24gcmVxdWVzdHMgd2l0aA0KPiA+ICAgICAgIGxv d2VyIG51bWVyaWMgJ21pZCcgdmFsdWVzIGFuZCBvdmVybGFwcGluZyBzY29wZXMgd2l0aCBtaXRp Z2F0aW9uDQo+ID4gICAgICAgcmVxdWVzdHMgaGF2aW5nIGhpZ2hlciBudW1lcmljICdtaWQnIHZh bHVlcyB3aWxsIGJlIHJlamVjdGVkDQo+ID4gICAgICAgc3lzdGVtYXRpY2FsbHkgYnkgdGhlIERP VFMgc2VydmVyLg0KPiANCj4gU29ycnkgZm9yIGJlaW5nIHVuY2xlYXIgaW4gbXkgY29tbWVudC4g SSB3YXMgaW50ZW5kaW5nIHRvIGVtcGhhc2l6ZSB0aGF0ICdtaWQnDQo+IGFuZCBzY29wZSBhcmUg dGhlICpvbmx5KiBtZWFzdXJlcyB0aGF0IGFjdHVhbGx5IG1pdGlnYXRlIGFnYWluc3QgMC1SVFQg cmVwbGF5LA0KPiBhbmQgdGhhdCB3ZSBhcmUgd3JvbmcgdG8gaGF2ZSB0ZXh0IHRoYXQgaW5kaWNh dGVzIGFueXRoaW5nIGVsc2UgaXMgYW4gZWZmZWN0aXZlDQo+IGFudGktcmVwbGF5IG1lY2hhbmlz bSwgYXQgbGVhc3QgZ2l2ZW4gdGhlIHByZXNlbnQgZGVzaWduLiAgU28gSSB3YXMgdHJ5aW5nIHRv IGFzaw0KPiBmb3IgdGhlIHRleHQgYWJvdXQgTWVzc2FnZSBJRCBhbmQgVG9rZW4gdG8gYmUgcmVt b3ZlZC4gIChPdXIgc3Vic2VxdWVudA0KPiBkaXNjdXNzaW9uIGluZGljYXRlcyB0aGF0IGl0IHdv dWxkIG1heWJlIGFsc28gd29yayB0byBleHBhbmQgb24gaXQgaW5zdGVhZCBvZg0KPiByZW1vdmUg aXQsIG5vdGluZyB0aGF0IERPVFMgaXMgcmVxdWlyaW5nIGFkZGl0aW9uYWwgYmVoYXZpb3Igbm90 IG1hbmRhdGVkIGJ5DQo+IHRoZSBDb0FQIHNwZWMuKQ0KPiANCj4gPiA+DQo+ID4gPiBJdCBzZWVt cyB0aGF0IHRoZSAnbWlkJyBvcmRlcmluZyBpcyBwcm9iYWJseSBlbm91Z2ggdG8gcHJvdGVjdA0K PiA+ID4gcmVvcmRlcmluZy9yZXBsYXkgb2YgbWl0aWdpYXRpb24gcmVxdWVzdCBhbmQgd2l0aGRy YXcsIGV2ZW4gd2hlbg0KPiA+ID4gcmVvcmRlcmVkIGFjcm9zcyBvdGhlciBtaXRpZ2F0aW9uIGFj dGlvbnMuICBCdXQgSSBhbSBtb3JlIGNvbmNlcm5lZA0KPiA+ID4gYWJvdXQgcmVvcmRlcmluZy9y ZXBsYXkgb2Ygb3RoZXIgbWVzc2FnZXMsIGxpa2UgZWZmaWNhY3kgdXBkYXRlcyBhbmQNCj4gPiA+ IHNlc3Npb24gY29uZmlndXJhdGlvbiBjaGFuZ2VzLg0KPiA+DQo+ID4gW01lZF0gRm9yIHRoZSBj b25maWd1cmF0aW9uIGNoYW5nZXMsIEkgZG9uJ3QgZXhwZWN0IHRoZSBleGNoYW5nZSB0byBoYXBw ZW4NCj4gZHVyaW5nIGFuIGF0dGFjay4gVGhlIHBhcnQgb2YgdGhlIHRleHQgd2UgYXJlIGRpc2N1 c3NpbmcgaXMgYWJvdXQgbWl0aWdhdGlvbg0KPiByZXF1ZXN0cy4NCj4gPg0KPiA+ICAgIG8gIDAt UlRUIG1vZGUgaW4gd2hpY2ggdGhlIERPVFMgY2xpZW50IGNhbiBhdXRoZW50aWNhdGUgaXRzZWxm IGFuZA0KPiA+ICAgICAgIHNlbmQgRE9UUyBtaXRpZ2F0aW9uIHJlcXVlc3QgbWVzc2FnZXMgaW4g dGhlIGZpcnN0IG1lc3NhZ2UsIHRodXMNCj4gPiAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4gICAgICAgcmVkdWNpbmcg aGFuZHNoYWtlIGxhdGVuY3kuDQo+IA0KPiBJZiB3ZSBkb24ndCBleHBlY3QgdG8gZG8gYW55dGhp bmcgb3RoZXIgdGhhbiBtaXRpZ2F0aW9uIHJlcXVlc3RzIGluIDAtUlRULCB0aGVuDQo+IHdoeSBk b24ndCB3ZSBqdXN0IGxpbWl0IHRoZSBtZXNzYWdlcyBhbGxvd2VkIGluIDAtUlRUIGRhdGEgdG8g YmUgc3VjaA0KPiBtaXRpZ2F0aW9uIHJlcXVlc3QgbWVzc2FnZXMgKGFuZCBleHBsaWNpdGx5IGV4 Y2x1ZGUgc2Vzc2lvbiBjb25maWd1cmF0aW9uKT8NCj4gSSBhbSBub3QgZ29pbmcgdG8gaW5zaXN0 IG9uIGl0LCBidXQgdGhhdCBkb2VzIHNlZW0gbGlrZSB0aGUgc2ltcGxlc3Qgd2F5IHRvDQo+IHJl c29sdmUgdGhlIHF1ZXN0aW9uLCBhdCBsZWFzdCBmcm9tIG92ZXIgaGVyZS4NCg0KSSBsaWtlIHRo ZSBwcm9wb3NhbCwgYXZvaWRzIHRoZSBuZWVkIHRvIHNoYXJlIE1lc3NhZ2UgSUQgYW5kIFRva2Vu IHNlbnQgaW4gMC1SVFQgZGF0YSBhbW9uZyBhbGwgdGhlIERPVFMgc2VydmVycyBpbiB0aGUgZG9t YWluLiAgSWYgdGhlIGNsaWVudCB1c2VzIGEgbmV3ICdtaWQnIHZhbHVlIChvciBhIG5ldyBtaXRp Z2F0aW9uIHJlcXVlc3QpIGV2ZXJ5IHRpbWUgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgaXMgc2VudCBh cyAwLVJUVCBkYXRhLCBzaGFyaW5nIHRoZSAnbWlkJyB2YWx1ZSBzZW50IGluIHRoZSAwLVJUVCBk YXRhIGFtb25nIHRoZSBET1RTIHNlcnZlcnMgaW4gdGhlIGRvbWFpbiBpcyBzdWZmaWNpZW50IHRv IGRldGVjdCByZXBsYXkgYXR0YWNrcy4gRE9UUyBzZXJ2ZXJzIGFueXdheSBoYXZlIHRvIGNvLW9y ZGluYXRlIGFuZCBzeW5jIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3RzLCBhbGlhc2VzIGFuZCBmaWx0 ZXJpbmcgcnVsZXMuIA0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IA0KPiA+IFB1dHRpbmcgdGhhdCBh c2lkZSwgd2UgZG8gaGF2ZSB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gICAgVGhlIFBVVCByZXF1 ZXN0IHdpdGggYSBoaWdoZXIgbnVtZXJpYyAnc2lkJyB2YWx1ZSBvdmVycmlkZXMgdGhlIERPVFMN Cj4gPiAgICBzaWduYWwgY2hhbm5lbCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24gZGF0YSBpbnN0YWxs ZWQgYnkgYSBQVVQgcmVxdWVzdA0KPiA+ICAgIHdpdGggYSBsb3dlciBudW1lcmljICdzaWQnIHZh bHVlLiAgVG8gYXZvaWQgbWFpbnRhaW5pbmcgYSBsb25nIGxpc3QNCj4gPiAgICBvZiAnc2lkJyBy ZXF1ZXN0cyBmcm9tIGEgRE9UUyBjbGllbnQsIHRoZSBsb3dlciBudW1lcmljICdzaWQnIE1VU1Qg YmUNCj4gPiAgICBhdXRvbWF0aWNhbGx5IGRlbGV0ZWQgYW5kIG5vIGxvbmdlciBhdmFpbGFibGUg YXQgdGhlIERPVFMgc2VydmVyLg0KPiA+DQo+ID4gQW55IHJlcGxheWVkIGNvbmZpZ3VyYXRpb24g Y2hhbmdlIHJlcXVlc3Qgd2lsbCBiZSBkaXNjYXJkZWQgb3dpbmcgdG8gdGhlDQo+ICdzaWQnIGNo ZWNrcy4NCj4gDQo+IFRoYXQgZG9lcyBoZWxwLCB5ZXMuICAoSSdtIG5vdCBzdXJlIHdoZXRoZXIg SSBoYWQgY29uZnVzZWQgbXlzZWxmIHRoYXQgdGhlIHNpZA0KPiB3YXMgZm9yIHRoZSBhYnN0cmFj dCAiRE9UUyBzZXNzaW9uIiB0aGF0IGlzIHJvdWdobHkgYWtpbiB0byB0aGUgRFRMUyBhc3NvY2lh dGlvbiwNCj4gb3IgdGhpcyB3YXMgYWRkZWQgaW4gcmVzcG9uc2UgdG8gc29tZSBvZiBteSBlYXJs aWVyIGNvbW1lbnRzIGFuZCBJIGZhaWxlZCB0bw0KPiBpbnRlcm5hbGl6ZSBpdCBwcm9wZXJseS4g IEl0IHNob3dzIHVwIGFzIG5ldyBpbiB0aGUgZGlmZiBmcm9tIC0yNSB0byAtMjkgdGhhdCBJJ20N Cj4gbG9va2luZyBhdCBpbiBwcmVwYXJhdGlvbiBmb3Igc3RhcnRpbmcgSUVURiBMQy4pDQo+IA0K PiA+ID4NCj4gPiA+IENvbnNpZGVyDQo+ID4gPg0KPiA+ID4gY2xpZW50ICAgICAgICAgICAgICAg ICAgIGF0dGFja2VyICAgICAgICAgICAgICAgICAgICBzZXJ2ZXINCj4gPiA+IHwNCj4gPiA+IHwt LS0tZWZmaWNhY3k6IGF0dGFjayBtaXRpZ2F0ZWQtLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPiA+ ID4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQo+ID4gPiB8LS0tLWVmZmljYWN5OiB1bmRlciBhdHRhY2stLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwNCj4gPiA+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KPiA+ID4gfCAgICAgICAgICAgICAgICAgICAgICAgIHwtcmVwbGF5OiBhdHRh Y2sgbWl0aWdhdGVkLT58DQo+ID4gPg0KPiA+ID4gSXMgdGhlIHNlcnZlciBnb2luZyB0byBlbmQg dXAgd2l0aCB0aGUgZXhwZWN0ZWQgc3RhdGU/DQo+ID4NCj4gPiBbTWVkXSBBIGdlbmVyYWwgY29t bWVudDogVGhlIGRvdHMgc2VydmVyIHVzZXMgdGhlIGluZm9ybWF0aW9uIGNvbnZleWVkIGluDQo+ IHRoZSBlZmZpY2FjeSB1cGRhdGUgYXMgYSBoaW50OyBpdCBtYXkgYnV0IGl0IGlzIG5vdCByZXF1 aXJlZCB0byByZWx5IG9uIHRob3NlDQo+IHJlcXVlc3RzIHRvIGFkanVzdCBpdHMgbWl0aWdhdGlv biBhY3Rpb25zLg0KPiA+DQo+ID4gSWYgdGhlIHR3byBmaXJzdCBzdGF0dXMgbWVzc2FnZXMgYXJl IGJvdW5kIHRvIGRpc3RpbmN0ICJtaWRzIiBhbmQgYWRqdXN0ZWQNCj4gc2NvcGVzLCB0aGUgcmVw bGF5ZWQgcmVxdWVzdCB3aWxsIGJlIGRpc2NhcmRlZCBieSB0aGUgc2VydmVyIHRoYW5rcyB0byB0 aGUNCj4gcHJlc2VuY2Ugb2YgSWYtTWF0Y2ggb3B0aW9uLiBUaGUgc2VydmVyIGRvZXMgbm90IG1h aW50YWluIHRoZSByZXF1ZXN0IHdpdGggdGhlDQo+IG9sZCBtaWQuDQo+ID4NCj4gPiBJZiwgZm9y IHNvbWUgcmVhc29uLCB0aGUgc2FtZSBtaWQgaXMgdXNlZCBhbmQgdGhpcyBmbG93IGlzIG9ic2Vy dmVkLCB0aGUgc2VydmVyDQo+IHdpbGwgZGV0ZWN0IHRoYXQgdGhlIHNhbWUgTWVzc2FnZSBJRCBh bmQgVG9rZW4gYXJlIHJldXNlZCBhZ2FpbiBhbmQgdGhlbg0KPiByZWplY3QuDQo+IA0KPiBOb3Qg aWYgdGhlIHJlcGxheSBjb21lcyBmcm9tIGEgZGlmZmVyZW50IHRyYW5zcG9ydCBlbmRwb2ludCEg IChCdXQgbGV0J3Mga2VlcCB0aGlzDQo+IHRvcGljIGF0IHRoZSBkaXNjdXNzaW9uIGFib3ZlLCBh cyBpdCdzIHRoZSBzYW1lIHRvcGljLikNCj4gDQo+IC1CZW4NCj4gDQo+ID4gPg0KPiA+ID4gLUJl bg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+ID4gPiA+ID4gRGXCoDogQmVuamFtaW4gS2FkdWsgW21haWx0bzprYWR1a0BtaXQu ZWR1XSBFbnZvecOpwqA6IHZlbmRyZWRpIDE1DQo+ID4gPiA+ID4gZsOpdnJpZXIgMjAxOSAxNjow NSDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIENjwqA6IEtvbmRhLA0KPiA+ID4gPiA+ IFRpcnVtYWxlc3dhciBSZWRkeTsgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsQGlldGYu b3JnOw0KPiA+ID4gPiA+IGRvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBPYmpldMKgOiBSZTogVXNp bmcgRWFybHkgRGF0YSBpbiBET1RTIChSRTogW0RvdHNdIEFEIHJldmlldyBvZg0KPiA+ID4gPiA+ IGRyYWZ0LWlldGYtDQo+ID4gPiA+ID4gZG90cy1zaWduYWwtY2hhbm5lbCkNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEhpIE1lZCwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFNob3J0IGZvcm06IEkgbmVl ZCB0byB0aGluayBhYm91dCBpdCBoYXJkZXIuICBUaGVyZSdzIHNvbWUNCj4gPiA+ID4gPiBpbmRp Y2F0aW9uDQo+ID4gPiB0aGF0DQo+ID4gPiA+ID4gdGhlIENvQXAgTWVzc2FnZSBJRCBpcyBhdCB0 aGUgd3JvbmcgbGV2ZWwgdG8gcHJvdGVjdCB0aGUgMC1SVFQNCj4gPiA+ID4gPiBkYXRhLCBidXQg SSdtIG5vdCBzdXJlIHlldC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFNvcnJ5IGZvciB0aGUgZGVs YXlzOyB0aGlzIGhhcyBiZWVuIGEgZnJlbmV0aWMgY291cGxlIHdlZWtzIDooDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiAtQmVuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiBGcmksIEZlYiAxNSwgMjAx OSBhdCAwMzowMToyOVBNICswMDAwLA0KPiA+ID4gPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gPiA+IHdyb3RlOg0KPiA+ID4gPiA+ID4gSGkgQmVuLA0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IFdoYXQgaXMgdGhlIHN0YXR1cyBmb3IgdGhpcyBvbmU/IEFyZSB3ZSBPSyB0byBt b3ZlIGZvcndhcmQ/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhhbmsgeW91Lg0KPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gPiA+IE1lZA0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+ID4gPiA+ IERlwqA6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+IFttYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4gPiA+ID4gPiA+ID4gRW52b3nDqcKgOiBtYXJkaSAy OSBqYW52aWVyIDIwMTkgMTQ6MzIgw4DCoDogQmVuamFtaW4gS2FkdWsgQ2PCoDoNCj4gPiA+ID4g PiA+ID4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC0N Cj4gPiA+IGNoYW5uZWxAaWV0Zi5vcmc7DQo+ID4gPiA+ID4gPiA+IGRvdHNAaWV0Zi5vcmcNCj4g PiA+ID4gPiA+ID4gT2JqZXTCoDogVXNpbmcgRWFybHkgRGF0YSBpbiBET1RTIChSRTogW0RvdHNd IEFEIHJldmlldyBvZg0KPiA+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLQ0KPiA+ID4gPiA+IGRvdHMt DQo+ID4gPiA+ID4gPiA+IHNpZ25hbC1jaGFubmVsKQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiBIaSBCZW4sIGFsbCwNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gV2UgZWRpdGVk IGEgc2hvcnQgZHJhZnQNCj4gPiA+ID4gPiA+ID4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1ib3VjYWRhaXItDQo+ID4gPiA+ID4gZG90cy0NCj4gPiA+ID4gPiA+ID4gZWFybHlk YXRhLTAwKSB0byBtb3RpdmF0ZSB0aGUgZm9sbG93aW5nIHRleHQgaW5jbHVkZWQgaW4gdGhlDQo+ ID4gPiA+ID4gPiA+IHNpZ25hbA0KPiA+ID4gPiA+IGNoYW5uZWwNCj4gPiA+ID4gPiA+ID4gZHJh ZnQ6DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ICAgICAgIFNlY3Rpb24gOCBvZiBbUkZD ODQ0Nl0gZGlzY3Vzc2VzIHNvbWUgbWVjaGFuaXNtcyB0bw0KPiA+ID4gPiA+ID4gPiBpbXBsZW1l bnQNCj4gPiA+IHRvDQo+ID4gPiA+ID4gPiA+ICAgICAgIGxpbWl0IHRoZSBpbXBhY3Qgb2YgcmVw bGF5IGF0dGFja3Mgb24gMC1SVFQgZGF0YS4gIElmIHRoZSBET1RTDQo+ID4gPiA+ID4gPiA+ICAg ICAgIHNlcnZlciBhY2NlcHRzIDAtUlRULCBpdCBNVVNUIGltcGxlbWVudCBvbmUgb2YgdGhlc2UN Cj4gPiA+IG1lY2hhbmlzbXMuDQo+ID4gPiA+ID4gPiA+ICAgICAgIEEgRE9UUyBzZXJ2ZXIgY2Fu IHJlamVjdCAwLVJUVCBieSBzZW5kaW5nIGEgVExTDQo+ID4gPiBIZWxsb1JldHJ5UmVxdWVzdC4N Cj4gPiA+ID4gPiA+ID4gICAgICAgVGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgbWVzc2FnZXMgc2Vu dCBhcyBlYXJseSBkYXRhIGJ5IHRoZQ0KPiBET1RTDQo+ID4gPiA+ID4gPiA+ICAgICAgIGNsaWVu dCBhcmUgaWRlbXBvdGVudCByZXF1ZXN0cy4gIEFzIGEgcmVtaW5kZXIsIE1lc3NhZ2UgSUQNCj4g PiA+ID4gPiA+ID4gICAgICAgKFNlY3Rpb24gMyBvZiBbUkZDNzI1Ml0pIGlzIGNoYW5nZWQgZWFj aCB0aW1lIGEgbmV3DQo+ID4gPiA+ID4gPiA+IENvQVANCj4gPiA+IHJlcXVlc3QNCj4gPiA+ID4g PiA+ID4gICAgICAgaXMgc2VudCwgYW5kIHRoZSBUb2tlbiAoU2VjdGlvbiA1LjMuMSBvZiBbUkZD NzI1Ml0pIGlzDQo+ID4gPiByYW5kb21pemVkDQo+ID4gPiA+ID4gPiA+ICAgICAgIGluIGVhY2gg Q29BUCByZXF1ZXN0LiAgVGhlIERPVFMgc2VydmVyKHMpIGNhbiB1c2UNCj4gPiA+ID4gPiA+ID4g TWVzc2FnZSBJRA0KPiA+ID4gYW5kDQo+ID4gPiA+ID4gPiA+ICAgICAgIFRva2VuIGluIHRoZSBE T1RTIHNpZ25hbCBjaGFubmVsIG1lc3NhZ2UgdG8gZGV0ZWN0DQo+ID4gPiA+ID4gPiA+IHJlcGxh eSBvZg0KPiA+ID4gZWFybHkNCj4gPiA+ID4gPiA+ID4gICAgICAgZGF0YSwgYW5kIGFjY2VwdCAw LVJUVCBkYXRhIGF0IG1vc3Qgb25jZS4gIEZ1cnRoZXJtb3JlLCAnbWlkJw0KPiA+ID4gPiA+ID4g PiAgICAgICB2YWx1ZSBpcyBtb25vdG9uaWNhbGx5IGluY3JlYXNlZCBieSB0aGUgRE9UUyBjbGll bnQgZm9yIGVhY2gNCj4gPiA+ID4gPiA+ID4gICAgICAgbWl0aWdhdGlvbiByZXF1ZXN0LCBhdHRh Y2tlcnMgcmVwbGF5aW5nIG1pdGlnYXRpb24NCj4gPiA+ID4gPiA+ID4gcmVxdWVzdHMNCj4gPiA+ IHdpdGgNCj4gPiA+ID4gPiA+ID4gICAgICAgbG93ZXIgbnVtZXJpYyAnbWlkJyB2YWx1ZXMgYW5k IG92ZXJsYXBwaW5nIHNjb3BlcyB3aXRoDQo+ID4gPiBtaXRpZ2F0aW9uDQo+ID4gPiA+ID4gPiA+ ICAgICAgIHJlcXVlc3RzIGhhdmluZyBoaWdoZXIgbnVtZXJpYyAnbWlkJyB2YWx1ZXMgd2lsbCBi ZSByZWplY3RlZA0KPiA+ID4gPiA+ID4gPiAgICAgICBzeXN0ZW1hdGljYWxseSBieSB0aGUgRE9U UyBzZXJ2ZXIuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ICAgICAgIE93aW5nIHRvIHRo ZSBhZm9yZW1lbnRpb25lZCBwcm90ZWN0aW9ucywgZXNwZWNpYWxseQ0KPiA+ID4gPiA+ID4gPiB0 aG9zZQ0KPiA+ID4gYWZmb3JkZWQNCj4gPiA+ID4gPiA+ID4gICAgICAgYnkgQ29BUCBkZWR1cGxp Y2F0aW9uIChTZWN0aW9uIDQuNSBvZiBbUkZDNzI1Ml0pIGFuZCBSRkMgODQ0Ng0KPiA+ID4gPiA+ ID4gPiAgICAgICBhbnRpLXJlcGxheSBtZWNoYW5pc21zLCBhbGwgRE9UUyBzaWduYWwgY2hhbm5l bA0KPiA+ID4gPiA+ID4gPiByZXF1ZXN0cyBhcmUNCj4gPiA+IHNhZmUNCj4gPiA+ID4gPiA+ID4g ICAgICAgdG8gdHJhbnNtaXQgaW4gVExTIDEuMyBhcyBlYXJseSBkYXRhLiAgUmVmZXIgdG8NCj4g PiA+ID4gPiA+ID4gICAgICAgW0ktRC5ib3VjYWRhaXItZG90cy1lYXJseWRhdGFdIGZvciBtb3Jl IGRldGFpbHMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFRoaXMgdGV4dCBhbmQgYWxz byB0aGUgRGVzaWduYXRlZCBFeHBlcnQgZ3VpZGVsaW5lcyBhcmUNCj4gPiA+ID4gPiA+ID4gaW1w bGVtZW50ZWQNCj4gPiA+IGluIC0NCj4gPiA+ID4gPiAyOC4NCj4gPiA+ID4gPiA+ID4gVGhlc2Ug YXJlIHRoZSB0d28gcGVuZGluZyBpc3N1ZXMgZnJvbSB5b3VyIEFEIHJldmlldy4NCj4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gT3RoZXIgZWRpdHMgd2VyZSBhbHNvIG1hZGUgdG8gcmVjb3Jk IHdoYXQgd2FzIGFncmVlZCBvbiB0aGUgbGlzdC4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gV2UgaG9wZSB0aGlzIHZlcnNpb24gaXMgbm93IHJlYWR5IHRvIG1vdmUgZm9yd2FyZC4NCj4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gPiBNZWQNCj4g PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IFJlZ2FyZGluZyB0aGUgKEQpVExT IDEuMyAwLVJUVCBkYXRhLCBSRkMgODQ0Ng0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gbm90ZXMg dGhhdA0KPiA+ID4gPiA+ID4gPiAiQXBwbGljYXRpb24NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ IHByb3RvY29scyBNVVNUIE5PVCB1c2UgMC1SVFQgZGF0YSB3aXRob3V0IGENCj4gPiA+ID4gPiA+ ID4gPiA+ID4gPiA+IHByb2ZpbGUgdGhhdA0KPiA+ID4gPiA+IGRlZmluZXMNCj4gPiA+ID4gPiA+ ID4gaXRzDQo+ID4gPiA+ID4gPiA+ID4gPiB1c2UuDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBU aGF0IHByb2ZpbGUgbmVlZHMgdG8gaWRlbnRpZnkgd2hpY2ggbWVzc2FnZXMgb3INCj4gPiA+IGlu dGVyYWN0aW9ucw0KPiA+ID4gPiA+IGFyZQ0KPiA+ID4gPiA+ID4gPiA+IHNhZmUNCj4gPiA+ID4g PiA+ID4gPiA+IHRvDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gdXNlDQo+ID4gPiA+ID4gPiA+ID4g PiA+ID4gPiB3aXRoIDAtUlRUIGFuZCBob3cgdG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gd2hlbg0K PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gdGhlIHNlcnZlcg0KPiA+ID4gPiA+IHJlamVjdHMNCj4g PiA+ID4gPiA+ID4gMC0NCj4gPiA+ID4gPiA+ID4gPiA+IFJUVA0KPiA+ID4gPiA+ID4gPiA+ID4g PiA+IGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gZmFsbHMgYmFjayB0byAxLVJUVC4iICBT byB3ZSBlaXRoZXIgbmVlZCB0byBzYXkNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHdoaWNoDQo+ ID4gPiBjbGllbnQNCj4gPiA+ID4gPiA+ID4gcmVxdWVzdHMNCj4gPiA+ID4gPiA+ID4gPiA+IGFy ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IDAtUlRUDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBz YWZlIChhbmQgd2h5KSBvciBkZWZlciB0aGF0IHByb2ZpbGUgdG8gYW5vdGhlciBkb2N1bWVudC4N Cj4gPiA+ID4gPiBkcmFmdC0NCj4gPiA+ID4gPiA+ID4gPiBpZXRmLQ0KPiA+ID4gPiA+ID4gPiA+ ID4gPiA+IGRuc29wLQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gc2Vzc2lvbi1zaWduYWwgaXMg cGVyaGFwcyBhbiBleGFtcGxlIG9mIGEgZG9jdW1lbnQNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ IHRoYXQNCj4gPiA+ID4gPiBzcGVjaWZpZXMNCj4gPiA+ID4gPiA+ID4gPiB3aGljaA0KPiA+ID4g PiA+ID4gPiA+ID4gPiA+ID4gbWVzc2FnZXMgYXJlL2FyZW4ndCBhbGxvd2VkIGluIGVhcmx5IGRh dGEuDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiAoZHJhZnQtaWV0Zi1hY21lLWFjbWUgaXMgYW5v dGhlciwgYnV0IGFuDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiB1bmludGVyZXN0aW5nIG9uZSwN Cj4gPiA+ID4gPiBzaW5jZQ0KPiA+ID4gPiA+ID4gPiA+IHRoZXkNCj4gPiA+ID4gPiA+ID4gPiA+ IG1ha2UNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGV2ZXJ5IHJlcXVlc3QgaW5jbHVkZSBhIHNp bmdsZS11c2Ugbm9uY2UsIGFuZCBhbGwNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IG1lc3NhZ2Vz DQo+ID4gPiBhcmUNCj4gPiA+ID4gPiAwLQ0KPiA+ID4gPiA+ID4gPiBSVFQNCj4gPiA+ID4gPiA+ ID4gPiA+IHNhZmUuKQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gT3VyIHVzZSBvZiBpbmNyZWFz aW5nICdtaWQnIHZhbHVlcyBtYXkgaGVscCBoZXJlLA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g aW4gdGVybXMNCj4gPiA+IG9mDQo+ID4gPiA+ID4gPiA+ID4gYWxsb3dpbmcNCj4gPiA+ID4gPiA+ ID4gPiA+ID4gPiBERUxFVEVzDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiB0byBiZSBzYWZlLCBi dXQgSSdkIGhhdmUgdG8gdGhpbmsgYSBsaXR0bGUgbW9yZSB0bw0KPiA+ID4gPiA+ID4gPiA+ID4g PiA+ID4gYmUgc3VyZQ0KPiA+ID4gdGhhdA0KPiA+ID4gPiA+ID4gPiA+ID4gcmVxdWVzdGluZw0K PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gbWl0aWdhdGlvbiB3b3VsZCBiZSBzYWZlLiAgKE9uIGZp cnN0IGdsYW5jZSB0aGUNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHNlc3Npb24tDQo+ID4gPiA+ ID4gbWFuYWdlbW5ldA0KPiA+ID4gPiA+ID4gPiA+IGJpdHMNCj4gPiA+ID4gPiA+ID4gPiA+ID4g PiB3b3VsZA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gbm90IGJlIHNhZmUsIGJ1dCBJIG1heSBi ZSBtaXNzaW5nIHNvbWV0aGluZy4pDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gPiA+ID4gPiBUaGUgZHJhZnQgb25seSB1c2VzIGlkZW1wb3RlbnQgcmVxdWVzdHMgKEdFVCwg UFVUDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gYW5kDQo+ID4gPiBERUxFVEUpLA0KPiA+ID4gPiA+ IGFuZA0KPiA+ID4gPiA+ID4gPiBDb0FQDQo+ID4gPiA+ID4gPiA+ID4gPiBpcw0KPiA+ID4gPiA+ ID4gPiA+ID4gPiA+IGNhcGFibGUgb2YgZGV0ZWN0aW5nIG1lc3NhZ2UgZHVwbGljYXRpb24gKHNl ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 MjUyI3NlY3Rpb24tNC41KSBmb3INCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBib3RoDQo+ID4gPiA+ ID4gY29uZmlybWFibGUNCj4gPiA+ID4gPiA+ID4gPiBhbmQNCj4gPiA+ID4gPiA+ID4gPiA+ID4g PiBub24tY29uZmlybWFibGUgbWVzc2FnZXMuDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gIFsxXSBB biBhdHRhY2tlciByZXBsYXlpbmcgREVMRVRFIHdpbGwgbm90IGhhdmUgYW55DQo+ID4gPiA+ID4g PiA+ID4gPiA+ID4gYWR2ZXJzZQ0KPiA+ID4gPiA+IGltcGFjdCwNCj4gPiA+ID4gPiA+ID4gPiAy LjAyDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKERlbGV0ZWQpIFJlc3BvbnNlIENvZGUgaXMgcmV0 dXJuZWQgZXZlbiBpZiB0aGUNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBtaXRpZ2F0aW9uDQo+ID4g PiA+ID4gcmVxdWVzdA0KPiA+ID4gPiA+ID4gPiBkb2VzDQo+ID4gPiA+ID4gPiA+ID4gPiBub3QN Cj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBleGlzdC4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBbMl0g VGhlIHRlY2huaXF1ZXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gOCBvZiBSRkM4NDQ2DQo+ID4gPiA+ ID4gPiA+ID4gPiA+ID4gc2hvdWxkDQo+ID4gPiA+ID4gc3VmZmljZQ0KPiA+ID4gPiA+ID4gPiB0 bw0KPiA+ID4gPiA+ID4gPiA+ID4gaGFuZGxlDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gYW50aS1y ZXBsYXkgKGUuZy4gYW4gYXR0YWNrZXIgcmVwbGF5aW5nIGEgMC1SVFQgZGF0YQ0KPiA+ID4gPiA+ ID4gPiA+ID4gPiA+IGNhcnJ5aW5nDQo+ID4gPiBhbg0KPiA+ID4gPiA+IG9sZA0KPiA+ID4gPiA+ ID4gPiA+ID4gPiA+IG1pdGlnYXRpb24gcmVxdWVzdCByZXBsYWNlZCBieSBhIG5ldyBtaXRpZ2F0 aW9uIHNjb3BlKS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiA+ID4gPiBbTWVkXSBGV0lXLCB3ZSBkbyBhbHJlYWR5IGhhdmUgdGhpcyB0 ZXh0IGluIHRoZSBkcmFmdDoNCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ ID4gICAgICAgU2VjdGlvbiA4IG9mIFtSRkM4NDQ2XSBkaXNjdXNzZXMgc29tZSBtZWNoYW5pc21z DQo+ID4gPiA+ID4gPiA+ID4gPiA+IHRvDQo+ID4gPiBpbXBsZW1lbnQNCj4gPiA+ID4gPiB0bw0K PiA+ID4gPiA+ID4gPiA+ID4gPiAgICAgICBsaW1pdCB0aGUgaW1wYWN0IG9mIHJlcGxheSBhdHRh Y2tzIG9uIDAtUlRUDQo+ID4gPiA+ID4gPiA+ID4gPiA+IGRhdGEuICBJZiB0aGUNCj4gPiA+ID4g PiBET1RTDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICAgICAgIHNlcnZlciBhY2NlcHRzIDAtUlRULCBp dCBNVVNUIGltcGxlbWVudCBvbmUgb2YNCj4gPiA+ID4gPiA+ID4gPiA+ID4gdGhlc2UNCj4gPiA+ ID4gPiBtZWNoYW5pc21zDQo= From nobody Thu Feb 28 02:39:04 2019 Return-Path: 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 A0705130E6B for ; Thu, 28 Feb 2019 02:39:02 -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 cJdfqT0dAUfb for ; Thu, 28 Feb 2019 02:39:00 -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 CB5D7128BCC for ; Thu, 28 Feb 2019 02:38:59 -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=1551350181; 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-ms-exchange-purlcount: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=M SPfdPLCSXQuntvh/LLL0zb4TsylMRHy+8syERo++X c=; b=XF1pC3c4hteqspDpq5dTSNN7+HDF7GXNOPZsUGNcim1w CAa8lR2ErdqT83EmHh5SyETHNlvxkA6m7bWnDVn0iNpOXliILN FJkPbDZ+6StUGV7Gz0HX9nrJAqNx4eQ8aE2cjl+S8wwz/C3vQG LYBBYWfO3pLErGQrI7kwsoxtFlA= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 21ae_1714_4009dd2b_a7cd_4f48_b97b_2d65c9182be3; Thu, 28 Feb 2019 03:36:21 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:38:49 -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; Thu, 28 Feb 2019 03:38:49 -0700 Received: from NAM05-DM3-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; Thu, 28 Feb 2019 03:38:47 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2903.namprd16.prod.outlook.com (20.178.235.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Thu, 28 Feb 2019 10:38:46 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 10:38:46 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" CC: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt Thread-Index: AQHUysO2BSyTdnM0Qka7k+Ykw8xjSaXr/0pggAY1FWCAAQcR8IABuGoggAAaEtA= Date: Thu, 28 Feb 2019 10:38:46 +0000 Message-ID: References: <155084937056.5323.18401033305053602209@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA25825@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA268D4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA268D4@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fbd65793-12ea-409c-1ffe-08d69d68eb48 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2903; x-ms-traffictypediagnostic: BYAPR16MB2903: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyOTAzOzIzOkFNNTV6ZDJyYVdDTmpPeHhRN1NmTVRTRFpn?= =?utf-8?B?NGVuUjJzdTI2SXFERk5wNzd4MWZ4SDQwSDBMTE9wd1FXck9uY1JFL3B0SEFa?= =?utf-8?B?K2ZLYkczc3lTYmhJYnlpdGgyR3M3K0lpTUZqWFltOUlhbGNGbkd4SlNUWlNt?= =?utf-8?B?S3V6N1krWXNwaE9xdUIxOGliemJxa1FzbU9wWDFKZ2NOemVqQ0JVaG9sazhu?= =?utf-8?B?RVpPeEoxa1pSZlc4Q05SZ3RYc2UvRDlaVEs1dklOVWttSnFkc09IY0djeFNT?= =?utf-8?B?bzVac3lLTDZYYnhpWmVjSnVjalY1WjJFVXhnQ2Q0WHRhQ0x2eHRLbUdWYklD?= =?utf-8?B?ZDJtVGF3czJXVHoyRGVtV2RaNlAxbzluY0tBdmQ2RTBCZERibTBDZnk2cklS?= =?utf-8?B?ZWIwb2N5T1dERFl4Y3l5elVjSHJXMlBBUS9TQnk2dm9kR3dDU3BWZ0hqTHhF?= =?utf-8?B?cWZiU0NjSkQ5b2QvWkVMZStMNkFpdWJRL3gxUG5IZGpseW43Z2J0V0JkbUtM?= =?utf-8?B?dlRQK0pNQ1ROV3h4blFpcFdEM0dKaTBubmlkRE1HTit4STVqdGlOdURHdDg4?= =?utf-8?B?azE4ZTM3TFRvK2M3N2VOYjJVM2lHREFhZ252Z1dBS2ZDL2tTMWZhV1JtZmRM?= =?utf-8?B?RGtUZ0licEJBTVU0Z2VTR3F1MVNnUEozNGVHVkpGVnJ3aCtQeERPVWF1OHd4?= =?utf-8?B?T2FBN3lrdXJmTjAwMHF4TldpZUVmRE5GNkI5TXhFUWY5bHVyVHNFWXJDcmhp?= =?utf-8?B?dk9jWUZLQmhBdnZMMWJMQXJIOGxWdmkrOVFjV0xscExiZ1JIY3M4Njd5SU12?= =?utf-8?B?TmRSdFBZRFRFMEtHL3NrT3gybFVpeUQxc1E3NSs1UUlDbmFEdDZsaUNzeldF?= =?utf-8?B?RFBmVnVBU0x3WHVKYnVsbXNqZmZWRVBhZk50K2lLd0hRK1BKaUllaFN0b3B4?= =?utf-8?B?YUEzQUFzQUpQVklGci9peVY5a0E4KzV4bmwzYnFpeGJOMG13RkVwMTJ6ZnJh?= =?utf-8?B?RHhvMWw5TEllcFV5b2xNMVkzSzRTUW1FeDdGOEZvbXNJZUZWVVFObVloVHBu?= =?utf-8?B?TTJYdlZnakM5bnU3czcxNEphTGhOaExSQTJTaVlOYkcxaDc3cGZaWnZ5aHhL?= =?utf-8?B?T210RnpHRE0rWHZVOWVJY3BIZFhLV2xHS2ZtR0RjYjZxVkc2eTFZaHd4S25P?= =?utf-8?B?LzNYcnFHZ0pGUE94ZkZwV2pmTThBdFZUb3JGUy9mWnJsNGtyblRaTnJqYlhx?= =?utf-8?B?U09NelRkdDFFWExpazRUU1U2RUVvZHYxa2ZQNjFDOEtEdDNIS0JzdUhQQ2Vr?= =?utf-8?B?NC9UQXlSNUV1TkVvWXpvTUhwRTI4K0ZiWjRHNEU0eTBSQ0w3ejB3aU5TLzV0?= =?utf-8?B?TWhwbnBaQVV6N2NFb1RvN2tTeW16TlV2SWJsWDNXQlgwMnVGdjgxYUtPeWwy?= =?utf-8?B?YW5DU042MWJ0MlltUW5qL0dRWUF0cjBDaFIrMmxSZVRtdk52eXExbjZkcTJC?= =?utf-8?B?OU9meUVTZXl5ZzlZRHBsSGVubFJRVHpneWxCMGQrRFROeWhKRFozRExzQWZj?= =?utf-8?B?blkySHI3cWRUdXBCUlRoZDg4bjJucXlZVEt0K3U1bk5USlMreXhYSm9RVytQ?= =?utf-8?B?Rmd0anRwL0p3cFNFZjFQR2NoNDVNN2JSYkt0SytTMklxNkxuRnpYZTloNzQv?= =?utf-8?B?L3NMWXowZ2JnVUhNZ2RlOTNHcDZmT1ducFZuNVhSVUZ1Y2p4Vk83RTVsUitT?= =?utf-8?B?dXAwL1NieXBhcmNscXpuU3cyVkpWVnlIUWFZSnZQSW1JQ0JxOHJ0dy8ydzZ2?= =?utf-8?B?eTdiL3BKSUIwdit4bk93ZDV1eGpsK3pFQkp2ZXhSbHhZRlU4UUZWK0hSekRL?= =?utf-8?B?SHlyclFrUWFSQmtRb2Z1eW1wVHVJQlhBSDRFU3FhYW0xNlFIeFRLUnRjYVU4?= =?utf-8?B?L3RJVUhqYW04L0pSR0FzRG5EZkYrTHZHMHZtRHlBV1NZOU01cnZtRjhyclYr?= =?utf-8?B?UWx4YzFqWHBwNlRRcHNmY25NRkZDcmJhVzMrUUUyTHN2Qmk4WnhxZ1BVY0NM?= =?utf-8?Q?ug48=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39850400004)(199004)(189003)(13464003)(32952001)(81156014)(81166006)(9686003)(6306002)(5660300002)(6436002)(102836004)(53546011)(6506007)(55016002)(5640700003)(72206003)(105586002)(8676002)(99286004)(66574012)(229853002)(6916009)(7696005)(25786009)(6246003)(4326008)(7736002)(97736004)(33656002)(53936002)(74316002)(76176011)(305945005)(26005)(966005)(80792005)(14454004)(2906002)(71190400001)(478600001)(71200400001)(93886005)(2351001)(68736007)(476003)(8936002)(66066001)(106356001)(3846002)(6116002)(316002)(86362001)(2501003)(5024004)(14444005)(256004)(186003)(486006)(11346002)(52536013)(446003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2903; H:BYAPR16MB2790.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: ObyT6HHdjDm4ZiUwpRiTSfXRjFkJhjwCjJv40nbD2m5PngpFysu22TMX0tIqRghnOsz44auPyxfn08OS/CBxnHKisIYn1H7sHscPwk45e2ckAfLdOVrj1Nt4LjmCaeHaM7PfJnOlGr3RMDcugZsfADujoNvtuhhcNbEASxSb3TXYqvD/UVUvrUeSTX1C7JvB/zVw/wSGtHDJxjlbpsLhXEi3m/pQydh8Rb+dNiATDgtabSb/RBc7ngN7Y7uzUZwwr4tzTY6hJdcwFx7LVAmUluBxBtgkqGpH9matIauMoxICLTe1weacdEbvGuYrSlVNZ4iVHpifaXjx2XFo/SteNLEIQQcRSTf5SM/1qkYAM0E5Edm3e3qsaX+ohw218ib54vL7J8XU814EgvEzZ8FB5jsF0qoNeuBHUao7tWtFbAc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fbd65793-12ea-409c-1ffe-08d69d68eb48 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 10:38:46.7885 (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: BYAPR16MB2903 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7025> : streams <1814338> : uri <2803628> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 10:39:03 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMjgsIDIwMTkgMjo0NSBQTQ0KPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCj4gQ2M6IGRvdHNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMt c2lnbmFsLWNoYW5uZWwtMjkudHh0DQo+IA0KPiANCj4gDQo+IEhpIFRpcnUsDQo+IA0KPiAnaWRs ZScgdGltZSBpcyBub3Qgd2hlbiBubyBhdHRhY2sgdHJhZmZpYyBpcyBwcmVzZW50LCBidXQgd2hl biBubyBhdHRhY2sNCj4gbWl0aWdhdGlvbiBpcyBhY3RpdmUuIFdlIGhhdmUgZHJhd24gdGhpcyBk aXN0aW5jdGlvbiBpbiAtMTUuDQo+IA0KPiBUaGUgaWRsZSBhbmQgbWl0aWdhdGlvbiB0aW1lcyBh cmUgaW50cm9kdWNlZCBpbiB0aGUgZHJhZnQuIEkgbWFkZSB0aGlzIGNoYW5nZSB0bw0KPiBhdm9p ZCBtaXNpbnRlcnByZXRhdGlvbjoNCj4gDQo+ICAgIFRoZSBzYW1lIG9yIGRpc3RpbmN0IGNvbmZp Z3VyYXRpb24gc2V0cyBtYXkgYmUgdXNlZCBkdXJpbmcgdGltZXMgd2hlbg0KPiAgICBhIG1pdGln YXRpb24gaXMgYWN0aXZlICgnbWl0aWdhdGluZy1jb25maWcnKSBhbmQgd2hlbiBubyBtaXRpZ2F0 aW9uDQo+ICAgIGlzIGFjdGl2ZSAoJ2lkbGUtY29uZmlnJykuICBUaGlzIGlzIHBhcnRpY3VsYXJs eSB1c2VmdWwgZm9yIERPVFMNCj4gICAgc2VydmVycyB0aGF0IG1pZ2h0IHdhbnQgdG8gcmVkdWNl IGhlYXJ0YmVhdCBmcmVxdWVuY3kgb3IgY2Vhc2UNCj4gICAgaGVhcnRiZWF0IGV4Y2hhbmdlcyB3 aGVuIGFuIGFjdGl2ZSBET1RTIGNsaWVudCBoYXMgbm90IHJlcXVlc3RlZA0KPiAgICBtaXRpZ2F0 aW9uLiAgSWYgZGlzdGluY3QgY29uZmlndXJhdGlvbnMgYXJlIHVzZWQsIERPVFMgYWdlbnRzIE1V U1QNCj4gICAgZm9sbG93IHRoZSBhcHByb3ByaWF0ZSBjb25maWd1cmF0aW9uIHNldCBhcyBhIGZ1 bmN0aW9uIG9mIHRoZQ0KPiAgICBtaXRpZ2F0aW9uIGFjdGl2aXR5IChlLmcuLCBpZiBubyBtaXRp Z2F0aW9uIHJlcXVlc3QgaXMgYWN0aXZlIChhbHNvDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eDQo+ICAgIHJl ZmVycmVkIHRvIGFzICdpZGxlJyB0aW1lKSwgJ2lkbGUtY29uZmlnJy1yZWxhdGVkIHZhbHVlcyBt dXN0IGJlDQo+ICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ICAgIGZvbGxvd2VkKS4g IEFkZGl0aW9uYWxseSwgRE9UUyBhZ2VudHMgTVVTVCBhdXRvbWF0aWNhbGx5IHN3aXRjaCB0bw0K PiAgICB0aGUgb3RoZXIgY29uZmlndXJhdGlvbiB1cG9uIGEgY2hhbmdlIGluIHRoZSBtaXRpZ2F0 aW9uIGFjdGl2aXR5DQo+ICAgIChlLmcuLCBpZiBhbiBhdHRhY2sgbWl0aWdhdGlvbiBpcyBsYXVu Y2hlZCBhZnRlciBhbiAnaWRsZScgdGltZSwgdGhlDQo+ICAgIERPVFMgYWdlbnQgc3dpdGNoZXMg ZnJvbSAnaWRsZS1jb25maWcnIHRvICdtaXRpZ2F0aW5nLWNvbmZpZyctcmVsYXRlZA0KPiAgICB2 YWx1ZXMpLg0KPiANCj4gQmV0dGVyPw0KDQpUaGFua3MsIHVwZGF0ZSBsb29rcyBnb29kLg0KDQot VGlydQ0KDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gW21haWx0 bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+IEVudm95w6nCoDogbWVy Y3JlZGkgMjcgZsOpdnJpZXIgMjAxOSAwNzo1NiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kv T0xODQo+ID4gQ2PCoDogZG90c0BpZXRmLm9yZyBPYmpldMKgOiBSRTogW0RvdHNdIEktRCBBY3Rp b246DQo+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTI5LnR4dA0KPiA+DQo+ID4g SGkgTWVkLA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUNCj4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20NCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ID4gPiBTZW50OiBUdWVzZGF5 LCBGZWJydWFyeSAyNiwgMjAxOSA4OjQyIFBNDQo+ID4gPiBUbzogS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCj4gPiA+IENjOiBk b3RzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogW0RvdHNdIEktRCBBY3Rpb246DQo+ID4g PiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMjkudHh0DQo+ID4gPg0KPiA+ID4NCj4g PiA+DQo+ID4gPiBIaSBUaXJ1LA0KPiA+ID4NCj4gPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ ID4NCj4gPiA+IENoZWVycywNCj4gPiA+IE1lZA0KPiA+ID4NCj4gPiA+ID4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgS29uZGEsDQo+ID4gPiA+IFRpcnVtYWxlc3dhciBSZWRk eSBFbnZvecOpwqA6IHZlbmRyZWRpIDIyIGbDqXZyaWVyIDIwMTkgMTc6MjAgw4DCoDoNCj4gPiA+ ID4gZG90c0BpZXRmLm9yZzsgaS1kLWFubm91bmNlQGlldGYub3JnIE9iamV0wqA6IFJlOiBbRG90 c10gSS1EIEFjdGlvbjoNCj4gPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTI5 LnR4dA0KPiA+ID4gPg0KPiA+ID4gPiBIaSBNZWQsDQo+ID4gPiA+DQo+ID4gPiA+IENvdXBsZSBv ZiBOaXRzOg0KPiA+ID4gPg0KPiA+ID4gPiAxKQ0KPiA+ID4gPiBPTEQ6DQo+ID4gPiA+IExpa2V3 aXNlLCAnc2lkJyB2YWx1ZSBpcw0KPiA+ID4gPiBtb25vdG9uaWNhbGx5IGluY3JlYXNlZCBieSB0 aGUgRE9UUyBjbGllbnQgZm9yIGVhY2ggY29uZmlndXJhdGlvbg0KPiA+ID4gPiBzZXNzaW9uLCBh dHRhY2tlcnMgcmVwbGF5aW5nIGNvbmZpZ3VyYXRpb24gcmVxdWVzdHMgd2l0aCBsb3dlcg0KPiA+ ID4gPiBudW1lcmljICdzaWQnIHZhbHVlcyB3aWxsIGJlIHJlamVjdGVkIGJ5IHRoZSBET1RTIHNl cnZlciBpZiBpdA0KPiA+ID4gPiBtYWludGFpbnMgYSBoaWdoZXIgbnVtZXJpYyAnc2lkJyB2YWx1 ZSBmb3IgdGhpcyBET1RTIGNsaWVudC4NCj4gPiA+ID4NCj4gPiA+ID4gTkVXOg0KPiA+ID4gPiBM aWtld2lzZSwgJ3NpZCcgdmFsdWUgaXMNCj4gPiA+ID4gbW9ub3RvbmljYWxseSBpbmNyZWFzZWQg YnkgdGhlIERPVFMgY2xpZW50IGZvciBlYWNoIGNvbmZpZ3VyYXRpb24NCj4gPiA+ID4gcmVxdWVz dCwgYXR0YWNrZXJzIHJlcGxheWluZyBjb25maWd1cmF0aW9uIHJlcXVlc3RzIHdpdGggbG93ZXIN Cj4gPiA+ID4gbnVtZXJpYyAnc2lkJyB2YWx1ZXMgd2lsbCBiZSByZWplY3RlZCBieSB0aGUgRE9U UyBzZXJ2ZXIgaWYgaXQNCj4gPiA+ID4gbWFpbnRhaW5zIGEgaGlnaGVyIG51bWVyaWMgJ3NpZCcg dmFsdWUgZm9yIHRoaXMgRE9UUyBjbGllbnQuDQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gW01lZF0g T0sgZm9yIHMvc2Vzc2lvbi9yZXF1ZXN0Lg0KPiA+ID4NCj4gPiA+ID4gMikNCj4gPiA+ID4gRGVm aW5lICdpZGxlJyB0aW1lIChpLmUuIHdoZW4gbm8gYXR0YWNrIHRyYWZmaWMgaXMgcHJlc2VudCku DQo+ID4gPg0KPiA+ID4gW01lZF0gVGhpcyBvbmUgaXMgbm90IG5lZWRlZCwgSU1ITy4gV2UgZG8g YWxyZWFkeSBoYXZlIHRoZSBmb2xsb3dpbmcNCj4gPiA+IGluIHRoZQ0KPiA+ID4gZHJhZnQ6DQo+ ID4gPg0KPiA+ID4gICAgVGhlIHNhbWUgb3IgZGlzdGluY3QgY29uZmlndXJhdGlvbiBzZXRzIG1h eSBiZSB1c2VkIGR1cmluZyB0aW1lcyB3aGVuDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl4NCj4gPiA+ ICAgIGEgbWl0aWdhdGlvbiBpcyBhY3RpdmUgKCdtaXRpZ2F0aW5nLWNvbmZpZycpIGFuZCB3aGVu IG5vDQo+ID4gPiBtaXRpZ2F0aW9uDQo+ID4gPg0KPiA+ID4NCj4gXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiA+ID4gXl5e Xg0KPiA+ID4gICAgaXMgYWN0aXZlICgnaWRsZS1jb25maWcnKS4gIFRoaXMgaXMgcGFydGljdWxh cmx5IHVzZWZ1bCBmb3IgRE9UUw0KPiA+ID4gICAgXl5eXl5eXl5eXl5eXl5eXl4NCj4gPg0KPiA+ IFRoZSBhYm92ZSBsaW5lcyBkbyBub3QgZGVmaW5lIHRoZSB0ZXJtICdpZGxlJy4NCj4gPiBXZSBq dXN0IGhhdmUgdG8gYXBwZW5kICIoaS5lLiB3aGVuIG5vIGF0dGFjayB0cmFmZmljIGlzIHByZXNl bnQpIiB0byAnaWRsZScNCj4gPiB0aW1lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IC1UaXJ1DQo+ ID4NCj4gPiA+ICAgIHNlcnZlcnMgdGhhdCBtaWdodCB3YW50IHRvIHJlZHVjZSBoZWFydGJlYXQg ZnJlcXVlbmN5IG9yIGNlYXNlDQo+ID4gPiAgICBoZWFydGJlYXQgZXhjaGFuZ2VzIHdoZW4gYW4g YWN0aXZlIERPVFMgY2xpZW50IGhhcyBub3QgcmVxdWVzdGVkDQo+ID4gPiAgICBtaXRpZ2F0aW9u LiAgSWYgZGlzdGluY3QgY29uZmlndXJhdGlvbnMgYXJlIHVzZWQsIERPVFMgYWdlbnRzIE1VU1QN Cj4gPiA+ICAgIGZvbGxvdyB0aGUgYXBwcm9wcmlhdGUgY29uZmlndXJhdGlvbiBzZXQgYXMgYSBm dW5jdGlvbiBvZiB0aGUNCj4gPiA+ICAgIG1pdGlnYXRpb24gYWN0aXZpdHkgKGUuZy4sIGlmIG5v IG1pdGlnYXRpb24gcmVxdWVzdCBpcyBhY3RpdmUsICdpZGxlLQ0KPiA+ID4gICAgY29uZmlnJy1y ZWxhdGVkIHZhbHVlcyBtdXN0IGJlIGZvbGxvd2VkKS4gIEFkZGl0aW9uYWxseSwgRE9UUyBhZ2Vu dHMNCj4gPiA+ICAgIE1VU1QgYXV0b21hdGljYWxseSBzd2l0Y2ggdG8gdGhlIG90aGVyIGNvbmZp Z3VyYXRpb24gdXBvbiBhIGNoYW5nZSBpbg0KPiA+ID4gICAgdGhlIG1pdGlnYXRpb24gYWN0aXZp dHkgKGUuZy4sIGlmIGFuIGF0dGFjayBtaXRpZ2F0aW9uIGlzIGxhdW5jaGVkDQo+ID4gPiAgICBh ZnRlciBhbiAnaWRsZScgdGltZSwgdGhlIERPVFMgYWdlbnQgc3dpdGNoZXMgZnJvbSAnaWRsZS1j b25maWcnIHRvDQo+ID4gPiAgICAnbWl0aWdhdGluZy1jb25maWcnLXJlbGF0ZWQgdmFsdWVzKS4N Cj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC1UaXJ1DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZg0KPiA+ID4gPiA+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zw0KPiA+ID4gPiA+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjIsIDIwMTkgOTowMCBQTQ0KPiA+ ID4gPiA+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gPiA+ID4gPiBDYzogZG90c0BpZXRm Lm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFtEb3RzXSBJLUQgQWN0aW9uOg0KPiA+ID4gPiA+IGRy YWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0yOS50eHQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4g RG8gbm90DQo+ID4gPiA+ID4gY2xpY2sgbGlua3MNCj4gPiA+ID4gb3INCj4gPiA+ID4gPiBvcGVu IGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhl DQo+ID4gPiA+ID4gY29udGVudCBpcw0KPiA+ID4gPiBzYWZlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZQ0KPiA+ID4gPiA+IEludGVybmV0LURyYWZ0cw0KPiA+ID4gPiBkaXJlY3Rvcmllcy4N Cj4gPiA+ID4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBERG9TIE9wZW4gVGhy ZWF0IFNpZ25hbGluZyBXRw0KPiA+ID4gPiA+IG9mIHRoZQ0KPiA+IElFVEYuDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IERpc3RyaWJ1dGVkIERlbmlhbC1v Zi1TZXJ2aWNlIE9wZW4gVGhyZWF0DQo+ID4gPiA+IFNpZ25hbGluZyAoRE9UUykNCj4gPiA+ID4g PiBTaWduYWwgQ2hhbm5lbCBTcGVjaWZpY2F0aW9uDQo+ID4gPiA+ID4gICAgICAgICBBdXRob3Jz ICAgICAgICAgOiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIE1vaGFtZWQgQm91Y2FkYWlyDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAg ICAgICAgICBQcmFzaGFudGggUGF0aWwNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIEFuZHJldyBNb3J0ZW5zZW4NCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg IE5payBUZWFndWUNCj4gPiA+ID4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1jaGFubmVsLTI5LnR4dA0KPiA+ID4gPiA+IAlQYWdlcyAgICAgICAgICAgOiA5OQ0K PiA+ID4gPiA+IAlEYXRlICAgICAgICAgICAgOiAyMDE5LTAyLTIyDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBBYnN0cmFjdDoNCj4gPiA+ID4gPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUg RE9UUyBzaWduYWwgY2hhbm5lbCwgYSBwcm90b2NvbCBmb3INCj4gPiA+ID4gPiAgICBzaWduYWxp bmcgdGhlIG5lZWQgZm9yIHByb3RlY3Rpb24gYWdhaW5zdCBEaXN0cmlidXRlZCBEZW5pYWwtb2Yt DQo+ID4gPiA+ID4gICAgU2VydmljZSAoRERvUykgYXR0YWNrcyB0byBhIHNlcnZlciBjYXBhYmxl IG9mIGVuYWJsaW5nIG5ldHdvcmsNCj4gPiA+ID4gPiAgICB0cmFmZmljIG1pdGlnYXRpb24gb24g YmVoYWxmIG9mIHRoZSByZXF1ZXN0aW5nIGNsaWVudC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAg IEEgY29tcGFuaW9uIGRvY3VtZW50IGRlZmluZXMgdGhlIERPVFMgZGF0YSBjaGFubmVsLCBhIHNl cGFyYXRlDQo+ID4gPiA+ID4gICAgcmVsaWFibGUgY29tbXVuaWNhdGlvbiBsYXllciBmb3IgRE9U UyBtYW5hZ2VtZW50IGFuZA0KPiBjb25maWd1cmF0aW9uDQo+ID4gPiA+ID4gICAgcHVycG9zZXMu DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBFZGl0b3JpYWwgTm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBS RkMgRWRpdG9yKQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgUGxlYXNlIHVwZGF0ZSB0aGVzZSBz dGF0ZW1lbnRzIHdpdGhpbiB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgUkZDDQo+ID4gPiA+ID4gICAg bnVtYmVyIHRvIGJlIGFzc2lnbmVkIHRvIHRoaXMgZG9jdW1lbnQ6DQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiAgICBvICAiVGhpcyB2ZXJzaW9uIG9mIHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBS RkMgWFhYWDsiDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgICBvICAiUkZDIFhYWFg6IERpc3RyaWJ1 dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZw0KPiA+ID4gPiA+ICAg ICAgIChET1RTKSBTaWduYWwgQ2hhbm5lbCBTcGVjaWZpY2F0aW9uIjsNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+ICAgIG8gICJ8IFtSRkNYWFhYXSB8Ig0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgbyAg cmVmZXJlbmNlOiBSRkMgWFhYWA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgUGxlYXNlIHVwZGF0 ZSB0aGlzIHN0YXRlbWVudCB3aXRoIHRoZSBSRkMgbnVtYmVyIHRvIGJlIGFzc2lnbmVkIHRvDQo+ ID4gPiA+ID4gICAgdGhlIGZvbGxvd2luZyBkb2N1bWVudHM6DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiAgICBvICAiUkZDIFlZWVk6IERpc3RyaWJ1dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhy ZWF0IFNpZ25hbGluZw0KPiA+ID4gPiA+ICAgICAgIChET1RTKSBEYXRhIENoYW5uZWwgU3BlY2lm aWNhdGlvbiAodXNlZCB0byBiZSBJLUQuaWV0Zi1kb3RzLWRhdGEtDQo+ID4gPiA+ID4gICAgICAg Y2hhbm5lbCkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIFBsZWFzZSB1cGRhdGUgVEJEL1RCRDEv VEJEMiBzdGF0ZW1lbnRzIHdpdGggdGhlIGFzc2lnbm1lbnRzDQo+IG1hZGUgYnkNCj4gPiA+ID4g PiAgICBJQU5BIHRvIERPVFMgU2lnbmFsIENoYW5uZWwgUHJvdG9jb2wuDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiAgICBBbHNvLCBwbGVhc2UgdXBkYXRlIHRoZSAicmV2aXNpb24iIGRhdGUgb2YgdGhl IFlBTkcgbW9kdWxlcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gPiA+ID4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFu bmVsLw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lv bnMgYXZhaWxhYmxlIGF0Og0KPiA+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMjkNCj4gPiA+ID4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhDQo+ID4g PiA+ID4gbm5lbA0KPiA+ID4gPiA+IC0yOQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+ID4gPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5u ZWwNCj4gPiA+ID4gPiAtMjkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUN Cj4gPiA+ID4gPiBvZg0KPiA+ID4gPiBzdWJtaXNzaW9uDQo+ID4gPiA+ID4gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiA+ID4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ ID4gPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4g PiA+ID4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHMNCg== From nobody Thu Feb 28 02:51:09 2019 Return-Path: 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 A4E60131231; Thu, 28 Feb 2019 02:50:58 -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 FiqF_eNeXHh6; Thu, 28 Feb 2019 02:50:52 -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 F2FA0130FD3; Thu, 28 Feb 2019 02:50:47 -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=1551350887; 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-ms-exchange-purlcount: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=/ WIr1RrL6mOMRE1Qkz0S4APXgcnDIEfzIwqaEm/Ff7 Q=; b=BPnhkUii3qzg1pAd06d0NlXSt7XJuHnueyd9H3LYalvm /jqqVnzGyUP6ZG0toL4Qg3qKgNAUPJC2g75W5c/z8A8yECgdMs Z9VN91xApAWObLMIAhLjy3v5d0H0LtokZhg9Cm/su5UNPpwaW9 Cv64aL+9A76FxA31BAQmvGSQ/0s= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 21a9_8292_7f94a86a_e958_4a25_b2e6_d9b059a159d0; Thu, 28 Feb 2019 03:48:07 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:49:53 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 28 Feb 2019 03:49:53 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:49:51 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2869.namprd16.prod.outlook.com (20.178.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Thu, 28 Feb 2019 10:49:49 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 10:49:49 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Benjamin Kaduk" CC: "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUzz5BCXFDawydokCSl6Px8wMDQaX1B8jw Date: Thu, 28 Feb 2019 10:49:48 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227155729.GL53396@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA2680B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA2680B@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e05268a-6b8a-43e6-8a2a-08d69d6a7601 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2869; x-ms-traffictypediagnostic: BYAPR16MB2869: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyODY5OzIzOllPemluWUFnU1A4L05oYWFOK1hWVUNXTGhN?= =?utf-8?B?bU94RjRQdnpxdHE3eUxHK05MWjJ5bWxtdXBJMC9XdjZhaVR3ZmI5NWs4RWpo?= =?utf-8?B?WmthM00xdXdieUt0SWFxd3JmanBTRVA5UlJKSkdITVNESGRoVVZXZmZqOUhG?= =?utf-8?B?SWVMdG1NYVFhUFRQRXlmeUJZUmxPUkgvWEd1Zys1TU5Na3ZHU0JmOWxsSDRV?= =?utf-8?B?R000ZGd4cE9xOTVWUVlCQ0RkQnNSbkVNRERuY3lab3Z0TGJLenlxWTZZZmwz?= =?utf-8?B?elQwODlQVTZhZmJZc3NMaStkRUgydE80amVjd1VMVHIxaU1FQXZ5bDlQSEdK?= =?utf-8?B?a0VCMFRsZDl1M1NkNHJNYU90dzR5OVdwZnFNNDlqZ3lBN0xXQUlhNzVMcUtR?= =?utf-8?B?ZnNhMjZtZlgrd2dpQURaRmhrSzB6RGlzRG94MTdEZmw5WVNNa2ZhcGhncDc2?= =?utf-8?B?MXF6aHUwcitTUGNTcU9GcFhBRVNVSTZ5Z1hXaGpFMVpEUnhVSE5HWUowdGlK?= =?utf-8?B?YWk4SjRLeGtPSk44U2xYYThIR2ZYbE5xVnBhUzMwbXptK05LVDZnblUrckMr?= =?utf-8?B?WjdxOGJ2NjREaWR1cmFPSmptVkRXTjNJV3dOUFAxcVQ1SGk5djZzL002amFK?= =?utf-8?B?NmE4M09ESlZ5WXJ4WGhOaU84UjNNU3haZ0p5a3VQVTNWR1NLQ1dwQUJ4SHMr?= =?utf-8?B?bTZIWXlBb1g0ZGdoOG1aQzBoQUtzTUp1ZlI3QSt6VXRnelBaaUxxQUVFU3hP?= =?utf-8?B?RlVHWDlaT1ZBSW9ONy95UExkUUJEK3ZtOXE2S3dQYjNtQmI2K3lEaFN0NEgv?= =?utf-8?B?eDk2NjhJdzhnMEJDc3pNU2p5YVcrZlVEYWJXUG83MWJ0bU9rRlp2Ym5EUEYr?= =?utf-8?B?NlFoeDMyQ3lhTEs0K2dVcmEzUE10cWJFU2I1NjNnYllCOUJzUlovNHYwek11?= =?utf-8?B?SjVGREcwbjlJam1OT1c5UzBOeG4rWGVQYlJXMW85dlBsNm5Rcm1Tb3dWcjYv?= =?utf-8?B?YW1NVk5QUnFnb3hUSWV2TW95L2YvcFhTRHB5eXhCVVozUlo3RVlPbWt0QU1O?= =?utf-8?B?a2k0ZHlzTHdnMFY2dTlQM3BqajQybXJWNjdiR1U5dnZQa056dE1va252cjhn?= =?utf-8?B?SzNMN1JqZUpieTErV3pKbGdxTHFzMUpnRTNoYlF4VUlpWWE5a1pEcERpWWxM?= =?utf-8?B?WlhLOVdnUFgyWjc2VUhjdUk2eitSeEVTMG94SWJ4Vis2d3FkWXNoMUlrQnZr?= =?utf-8?B?TGh0UUIxVUU5K2E0cmNETTNXYS9WdDBza1BuRzNaY3BKL3RacVFCUjVQWERD?= =?utf-8?B?WUF6ZmpmbFVZOUJsTXlwbVlLZzR5OWphTUdOZGRoM3VWZ2tnM2J3OVRtLzEw?= =?utf-8?B?NlNYN05EdjhhaC8wOVZ1NUFpVUFRcDFGY25oOVFya1RzRlRWUWlvdllaeGNy?= =?utf-8?B?YkkxZWw5S0JPWEtmdUV2YkdwS3FQK3R0S0w2WFlDM0Y2ZmY0UUxlNXVzc3J3?= =?utf-8?B?NUNudHJiNmZDeUJ3d2VjVitmM3FNTVRUQzR3TDd1UkI4NE4rUEJ2WVByendz?= =?utf-8?B?NUk4eGo4bms0c21vSThOWUZpMVdkYVl3YU5yNENVenhRcjl4cVNYa2dCSTRG?= =?utf-8?B?YnBLWjJ2QmkwVUs4UXlNQndiOWd0SHl3WFYyemRlMGNnN3JubkdwYXM2elVu?= =?utf-8?B?YjR3bVQwSEVmOHBrTE16ZUloc3U2MzlURzlodDExbDNkOHhlNEtHa2JqNmdS?= =?utf-8?B?bkNHUlB3a3lDS1ZBKzkwbFdQdlVwTmVrY2dKdy8zVllBbkdOOXlrZ0wyZmxJ?= =?utf-8?B?V1VSRzFZSUx1M200dkE4aE04SzJNRVEvL3UwaGcxdHlrNmQxTUZHbENnVmd5?= =?utf-8?B?dm1JaUNKaTlyU2oxbDNBcnRYUVZJdVk5ZGhzeUVRUFVnN3ErTjQ2VERKMllT?= =?utf-8?B?WjlacDFRRDJ4UEJnZE9zMVM2MHhEMWxhV3RiMStDd1NlbWxxTjBWcVJBMDFq?= =?utf-8?B?RkV6bXFRbHFsWGR2aDZMQXBtaTM3WENqdVRJSnAyVmFOWXVITkgzaFQ4bVJB?= =?utf-8?B?b0FoSUZZMnNhMCtzMW91WGFUQUY1c2FFb2ZmMGQ5d3hYZDlWdXByWHpweWlp?= =?utf-8?Q?8Pi2kj7IlS7z1ZRNkPd1ssU=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(366004)(199004)(13464003)(189003)(51444003)(32952001)(8676002)(66574012)(81156014)(106356001)(30864003)(102836004)(93886005)(966005)(53946003)(4326008)(2501003)(81166006)(53546011)(6506007)(33656002)(53936002)(5024004)(2906002)(256004)(5660300002)(14444005)(105586002)(7736002)(6116002)(74316002)(186003)(305945005)(52536013)(68736007)(229853002)(3846002)(8936002)(6306002)(11346002)(446003)(486006)(316002)(86362001)(476003)(71200400001)(71190400001)(99286004)(55016002)(72206003)(478600001)(9686003)(14454004)(25786009)(76176011)(7696005)(54906003)(110136005)(97736004)(2171002)(80792005)(26005)(6246003)(66066001)(6436002)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2869; H:BYAPR16MB2790.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: BjK4aI64UHnUIgD168v+YegkEyvy+84I8H7Lr96G33/ttnHkH7JwKcJyj5qbWBsJcWiCmnTeVHkkqBhG90OYbHjZbbKPSM4OUuHBK9jKPzLQ7DGm4QOGXpyrxx+We0XkL+iL+nWbGuyn382vxyyxN2NCVGj3NqKu2ynvcS9rN+t54TSL28ot7pPo85I3mXyhmkluAJeZLEwl73lnee8fikk3uvOFS479PeAEhHBVC8s2YeIqlh977J6WfS3AWNINkyMigNrYQCa9aotj9tAF36xGWGmc+W8cMk9thYeJ6lll/TjUmDRILpZXBkKBNtcs1Y2woftBwneWFKWLSQGz0VzPg4PFJP+7VaoCyrz1pgHflfD9X27lUBiDjlSZ/SxvJEOUOXruTWd5CWnXdGGbUeG16G/ydUrTcR3ghDsjEho= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3e05268a-6b8a-43e6-8a2a-08d69d6a7601 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 10:49:49.0189 (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: BYAPR16MB2869 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7025> : streams <1814339> : uri <2803632> Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 10:51:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZg0KPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyOCwgMjAxOSAxOjQ4IFBNDQo+IFRvOiBCZW5qYW1p biBLYWR1ayA8a2FkdWtAbWl0LmVkdT4NCj4gQ2M6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hh bm5lbEBpZXRmLm9yZzsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA8VGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbT47IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtE b3RzXSBVc2luZyBFYXJseSBEYXRhIGluIERPVFMgKFJFOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1kb3RzLQ0KPiBzaWduYWwtY2hhbm5lbCkNCj4gDQo+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBm cm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yDQo+ IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25v dyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiANCj4gSGkgQmVuLA0KPiANCj4gUGxlYXNlIHNlZSBp bmxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPiBEZcKgOiBCZW5qYW1pbiBLYWR1ayBbbWFpbHRvOmthZHVrQG1pdC5lZHVd IEVudm95w6nCoDogbWVyY3JlZGkgMjcNCj4gPiBmw6l2cmllciAyMDE5IDE2OjU4IMOAwqA6IEJP VUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gQ2PCoDogS29uZGEsDQo+ID4gVGlydW1hbGVzd2FyIFJl ZGR5OyBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWxAaWV0Zi5vcmc7DQo+ID4gZG90c0Bp ZXRmLm9yZw0KPiA+IE9iamV0wqA6IFJlOiBVc2luZyBFYXJseSBEYXRhIGluIERPVFMgKFJFOiBb RG90c10gQUQgcmV2aWV3IG9mDQo+ID4gZHJhZnQtaWV0Zi0NCj4gPiBkb3RzLXNpZ25hbC1jaGFu bmVsKQ0KPiA+DQo+ID4gT24gVHVlLCBGZWIgMTksIDIwMTkgYXQgMDc6NTk6MjlBTSArMDAwMCwN Cj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiA+IEhpIEJlbiwNCj4g PiA+DQo+ID4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IE9rYXkuICBCVFcsIGl0IGlz IGxvb2tpbmcgbGlrZSB0aGlzIGlzIHRoZSBsYXN0IHRvcGljIHRvIHJlc29sdmUNCj4gPiBiZWZv cmUgc3RhcnRpbmcgSUVURiBMQy4gIEl0J3MgcHJvYmFibHkgd29ydGggcy90aGUgZXhwb25lbnQg aXMgMi90aGUNCj4gPiBiYXNlIG9mIHRoZSBleHBvbmVudCBpcyAyLyBpbiB0aGUgbmV4dCByZXYs IHRob3VnaCwganVzdCBhcyBhIG1pbm9yIG5pdC1maXguDQo+ID4NCj4gDQo+IFtNZWRdIEZpeGVk Lg0KPiANCj4gPiA+DQo+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4g PiBEZcKgOiBCZW5qYW1pbiBLYWR1ayBbbWFpbHRvOmthZHVrQG1pdC5lZHVdIEVudm95w6nCoDog bHVuZGkgMTgNCj4gPiA+ID4gZsOpdnJpZXIgMjAxOSAxNzoyMyDDgMKgOiBCT1VDQURBSVIgTW9o YW1lZCBUR0kvT0xOIENjwqA6IEtvbmRhLA0KPiA+ID4gPiBUaXJ1bWFsZXN3YXIgUmVkZHk7IGRy YWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbEBpZXRmLi5vcmc7DQo+ID4gPiA+IGRvdHNAaWV0 Zi5vcmcNCj4gPiA+ID4gT2JqZXTCoDogUmU6IFVzaW5nIEVhcmx5IERhdGEgaW4gRE9UUyAoUkU6 IFtEb3RzXSBBRCByZXZpZXcgb2YNCj4gPiA+ID4gZHJhZnQtaWV0Zi0NCj4gPiA+ID4gZG90cy1z aWduYWwtY2hhbm5lbCkNCj4gPiA+ID4NCj4gPiA+ID4gT24gRnJpLCBGZWIgMTUsIDIwMTkgYXQg MDM6MzY6MDVQTSArMDAwMCwNCj4gPiA+ID4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0K PiA+IHdyb3RlOg0KPiA+ID4gPiA+IFJlLSwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IExvb2tpbmcg Zm9yd2FyZCB0byBkaXNjdXNzIHRoaXMgZnVydGhlci4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkg d29uZGVyIHdoZXRoZXIgeW91IGNhbiBjb25zaWRlciBwdXR0aW5nIHRoZSBkb2N1bWVudCBpbiB0 aGUNCj4gPiA+ID4gPiBJRVRGIExDDQo+ID4gZm9yDQo+ID4gPiA+IG5vdy4gSWYgaXQgaGFwcGVu IHRoYXQgd2UgbmVlZCB0byBtb2RpZnkgdGhlIDAtUlRUIHRleHQsIHdlIHdpbGwNCj4gPiA+ID4g aGFuZGxlDQo+ID4gaXQgYXMNCj4gPiA+ID4gb3RoZXIgSUVURiBMQyBjb21tZW50cy4NCj4gPiA+ ID4NCj4gPiA+ID4gSSB3b3VsZCBub3JtYWxseSBiZSBwcmV0dHkgYW1lbmFibGUgdG8gc3RhcnRp bmcgSUVURiBMQyBhbmQNCj4gPiA+ID4gY29udGludWluZyBkaXNjdXNzaW9uOyBpdCdzIGp1c3Qg Zm9yIHRoaXMgaXNzdWUgaW4gcGFydGljdWxhciB0aGF0DQo+ID4gPiA+IEkgc2VlbSB0byBiZSB0 aGUgbWFpbiBwZXJzb24gb24gdGhlIElFU0cgdGhhdCBlbmZvcmNlcyB0aGUNCj4gPiA+ID4gImFw cGxpY2F0aW9uIHByb2ZpbGUgZm9yIDAtUlRUIGRhdGEiIHJlcXVpcmVtZW50LCBzbyBpdCB3b3Vs ZCBmZWVsDQo+ID4gPiA+IHJhdGhlciBvZGQgdG8gZ28gZm9yd2FyZCBpbiB0aGlzDQo+ID4gY2Fz ZS4NCj4gPiA+DQo+ID4gPiBbTWVkXSBGYWlyIGVub3VnaC4NCj4gPiA+DQo+ID4gPiA+IEx1Y2tp bHksIEkgc3BlbnQgc29tZSB0aW1lIHRoaXMgd2Vla2VuZCByZWFkaW5nIFJGQyA3MjUyIGFuZCBo YXZlDQo+ID4gPiA+IHNvbWUgc3Vic3RhbnRpdmUgY29tbWVudHMuDQo+ID4gPiA+DQo+ID4gPiA+ IFRoZSBrZXkgb2JlcnNlcnZhdGlvbiBoZXJlIHNlZW1zIHRvIGJlIHRoYXQgdGhlIE1lc3NhZ2Ug SUQgaXMNCj4gPiA+ID4gc2NvcGVkIHBlciBlbmRwb2ludCwgYW5kIHJlcGxheXMgY2FuIGNvbWUg ZnJvbSBhcmJpdHJhcnkgYWRkcmVzc2VzLg0KPiA+ID4gPg0KPiA+ID4gPiBTcGVjaWZpY2FsbHks IHdlIHJlY2FsbCB0aGF0Og0KPiA+ID4gPg0KPiA+ID4gPiAgICBUaGUgRE9UUyBzaWduYWwgY2hh bm5lbCBpcyBsYXllcmVkIG9uIGV4aXN0aW5nIHN0YW5kYXJkcyAoRmlndXJlIDMpLg0KPiA+ID4g Pg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBET1RTIFNpZ25hbCBDaGFu bmVsIHwNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBDb0FQ ICAgICAgICB8DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0r LS0tLS0tLS0tLSsNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgVExTICAg IHwgICBEVExTICAgfA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tKy0tLS0tLS0tLS0rDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIFRD UCAgICB8ICAgVURQICAgIHwNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLSstLS0tLS0tLS0tKw0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgSVAgICAgICAgICB8DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPiA+ID4NCj4gPiA+ID4gV2Ugbm90ZSB0aGF0IENv QVAgaXMgdXNpbmcgdGhlIElQIGFkZHJlc3Mgb3IgIkRUTFMgc2Vzc2lvbiINCj4gPiA+ID4gKGFy Z3VhYmx5IGEgcG9vcmx5IGNob3NlbiB0ZXJtKSB0byBpZGVudGlmeSBhIENvQVAgYXNzb2NpYXRp b24gYW5kDQo+ID4gPiA+IHRoYXQgTWVzc2FnZSBJRHMNCj4gPiBhcmUNCj4gPiA+ID4gb25seSB1 c2VkIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc3VjaCBhbiBhc3NvY2lhdGlvbiwgaXQgc2VlbXMgcHJl dHR5DQo+ID4gPiA+IGNsZWFyIHRoYXQgYW4gYXR0YWNrZXIgYWJsZSB0byByZXBsYXkgVExTIDEu MyAwLVJUVCBkYXRhIHdpbGwNCj4gPiA+ID4gc2xpY2Ugb2ZmIHRoZSB0b3AgdGhyZWUgbGluZXMg b2YgdGhpcyBmaWd1cmUgYW5kIHN3YXAgb3V0IHRoZQ0KPiA+ID4gPiBUQ1AvVURQL0lQIGxheWVy cy4gIEluIHRoZSBhYnNlbmNlIG9mIERUTFMgY29ubmVjdGlvbiBJRHMsIG15DQo+ID4gPiA+IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgIkRUTFMNCj4gPiBzZXNzaW9uIg0KPiA+ID4gPiBpcyBp ZGVudGlmaWVkIHNvbGVseSBieSB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24sIGp1c3QgYXMgZm9y DQo+ID4gPiA+IGNvYXAtbm90LXMsIHNvIGJ5IHNwb29maW5nIHRoZSBzb3VyY2UgYWRkcmVzcywg dGhlIGF0dGFja2VyIGNhdXNlcw0KPiA+ID4gPiB0aGUgcmVwbGF5ZWQgMC1SVFQgZGF0YSAoYW5k IHRodXMsIENvQVAgcmVxdWVzdCkgdG8gYmUgaW50ZXJwcmV0ZWQNCj4gPiA+ID4gYXMgYSBuZXcg aW5jb21pbmcgY29hcHMgY29ubmVjdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4gR2l2ZW4gdGhhdCBN ZXNzYWdlIElEIGlzIG9ubHkgMTYgYml0cyBhbmQgdGhlIHNlcnZlcnMgYWNjZXB0aW5nDQo+ID4g PiA+IDAtUlRUDQo+ID4gZGF0YQ0KPiA+ID4gPiBoYXZlIHBvdGVudGlhbCB0byBiZSBxdWl0ZSBi dXN5LCBpdCBkb2VzIG5vdCBzZWVtIHdvcmthYmxlIHRvDQo+ID4gPiA+IGF0dGVtcHQgdG8gdXNl IHRoZSBpbmNvbWluZyBNZXNzYWdlIElEcyBhcyBnbG9iYWxseSB1bmlxdWUgcmVwbGF5DQo+ID4g PiA+IGRlZmVuc2UsIGFzIHRoZQ0KPiA+IHJpc2sNCj4gPiA+ID4gb2YgY29sbGlzaW9uIHdvdWxk IGJlIHByZXR0eSBsYXJnZS4NCj4gPiA+DQo+ID4gPiBbTWVkXSBUaGUgcmVwbGF5IGRldGVjdGlv biByZWxpZXMgb24gYm90aCBNZXNzYWdlIElEIGFuZCBUb2tlbi4NCj4gPg0KPiA+IEluIHN0b2Nr IENvQVAsIHRoZSBNZXNzYWdlIElEIGFuZCBUb2tlbiBhcmUgdXNlZCBvbmx5IHdpdGggdGhlIGNv bnRleHQNCj4gPiBvZiBhIHNwZWNpZmljIHRyYW5zcG9ydCBhc3NvY2lhdGlvbi4NCj4gDQo+IFtN ZWRdIEhtbS4uLlJGQzcyNTIgZGVmaW5lcyBhbiBlbmRwb2ludCBhcyBmb2xsb3dzOg0KPiANCj4g ICAgVGhlIHNwZWNpZmljIGRlZmluaXRpb24gb2YgYW4gZW5kcG9pbnQgZGVwZW5kcyBvbiB0aGUg dHJhbnNwb3J0IGJlaW5nDQo+ICAgIHVzZWQgZm9yIENvQVAuICBGb3IgdGhlIHRyYW5zcG9ydHMg ZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24sIHRoZQ0KPiAgICBlbmRwb2ludCBpcyBpZGVu dGlmaWVkIGRlcGVuZGluZyBvbiB0aGUgc2VjdXJpdHkgbW9kZSB1c2VkIChzZWUNCj4gICAgU2Vj dGlvbiA5KTogV2l0aCBubyBzZWN1cml0eSwgdGhlIGVuZHBvaW50IGlzIHNvbGVseSBpZGVudGlm aWVkIGJ5IGFuDQo+ICAgIElQIGFkZHJlc3MgYW5kIGEgVURQIHBvcnQgbnVtYmVyLiAgV2l0aCBv dGhlciBzZWN1cml0eSBtb2RlcywgdGhlDQo+ICAgIGVuZHBvaW50IGlzIGlkZW50aWZpZWQgYXMg ZGVmaW5lZCBieSB0aGUgc2VjdXJpdHkgbW9kZS4NCj4gDQo+IERPVFMgYWRoZXJlcyB0byB0aGF0 IGRlZmluaXRpb246IGl0IGFzc3VtZXMgdGhhdCBhbiBlbmRwb2ludCBpcyBub3QgaWRlbnRpZmll ZCBieQ0KPiBpdHMgdHJhbnNwb3J0IGNvb3JkaW5hdGVzIGJ1dCB3aXRoIGl0cyBpZGVudGl0eS4N Cj4gDQo+IEZ1cnRoZXJtb3JlLCB0aGUgY29ycmVsYXRpb24gYmV0d2VlbiBzZXNzaW9ucyBpcyBj bGVhcmx5IG1lbnRpb25lZCBpbiB0aGUgdGV4dDoNCj4gDQo+ICAgIFRoZSBET1RTIHNlcnZlciBj b3VwbGVzIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIHNlc3Npb25zIHVzaW5nIHRoZQ0KPiAgICBE T1RTIGNsaWVudCBpZGVudGl0eSBhbmQgb3B0aW9uYWxseSB0aGUgJ2NkaWQnIHBhcmFtZXRlciB2 YWx1ZSwgYW5kDQo+ICAgIHRoZSBET1RTIHNlcnZlciB1c2VzICdtaWQnIGFuZCAnY3VpZCcgVXJp LVBhdGggcGFyYW1ldGVyIHZhbHVlcyB0bw0KPiAgICBkZXRlY3QgZHVwbGljYXRlIG1pdGlnYXRp b24gcmVxdWVzdHMuDQo+IA0KPiANCj4gIEluIG9yZGVyIHRvIHVzZSB0aGVtIGZvciAoRClUTFMg MS4zIHJlcGxheQ0KPiA+IGRlZmVuc2UsIHdlIG5lZWQgdG8gZXhwYW5kIHRoYXQgY29udGV4dCB0 byBhIGJyb2FkZXIgc2NvcGUsIGFuZCBkaXJlY3QNCj4gPiB0aGUgc2VydmVyIHRvIGNoZWNrIHRo ZSBNZXNzYWdlIElEL1Rva2VuIGdsb2JhbGx5IChvciBhdCBsZWFzdCB3aXRoaW4NCj4gPiB0aGUg c2NvcGUgb2YgYSBnaXZlbiAnY3VpZCcvJ2NkaWQnKS4gIFNpbmNlIHRoaXMgd291bGQgcmVmbGVj dCBhDQo+ID4gZGl2ZXJnZW5jZSBmcm9tIG5vcm1hbCBDb0FQLCBpZiB3ZSBhcmUgZ29pbmcgdG8g cmVseSBvbiB0aGlzIHNvcnQgb2YNCj4gPiBiZWhhdmlvciwgd2UgbXVzdCBjYWxsIGl0IG91dCB2 ZXJ5IGxvdWRseSBhcyBzcGVjaWZpYyB0byBET1RTLg0KPiA+DQo+IA0KPiBbTWVkXSBXZSBjYW4g bWFrZSB0aGlzIGNoYW5nZSBpZiBpdCBoZWxwczoNCj4gDQo+IE9MRDoNCj4gICAgICAgVGhlIERP VFMgc2VydmVyKHMpIGNhbiB1c2UgTWVzc2FnZSBJRCBhbmQNCj4gICAgICAgVG9rZW4gaW4gdGhl IERPVFMgc2lnbmFsIGNoYW5uZWwgbWVzc2FnZSB0byBkZXRlY3QgcmVwbGF5IG9mIGVhcmx5DQo+ ICAgICAgIGRhdGEsIGFuZCBhY2NlcHQgMC1SVFQgZGF0YSBhdCBtb3N0IG9uY2UuDQo+IA0KPiBO RVc6DQo+ICAgICAgIFRoZSBET1RTIHNlcnZlcihzKSBjYW4gdXNlIE1lc3NhZ2UgSUQgYW5kDQo+ ICAgICAgIFRva2VuIGluIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIG1lc3NhZ2UgdG8gZGV0ZWN0 IHJlcGxheSBvZiBlYXJseQ0KPiAgICAgICBkYXRhLCBhbmQgYWNjZXB0IDAtUlRUIGRhdGEgYXQg bW9zdCBvbmNlIGZyb20gdGhlIHNhbWUgRE9UUyBjbGllbnQuDQo+ICAgICAgIERPVFMgc2VydmVy cyBkbyBub3QgcmVseSBvbiB0cmFuc3BvcnQgY29vcmRpbmF0ZXMgdG8NCj4gICAgICAgaWRlbnRp ZnkgaXRzIHBlZXJzLiBBcyBhIHJlbWluZGVyLCBET1RTIHNlcnZlcnMgY291cGxlcyB0aGUgRE9U UyBzaWduYWwNCj4gY2hhbm5lbCBzZXNzaW9ucw0KPiAgICAgICB1c2luZyB0aGUgRE9UUyBjbGll bnQgaWRlbnRpdHkgYW5kIG9wdGlvbmFsbHkgdGhlICdjZGlkJyBwYXJhbWV0ZXIgdmFsdWUuDQoN CkkgcHJvcG9zZSB0byB1cGRhdGUgdGhlIHRleHQgYXMgZm9sbG93czoNCg0KICAgICAgVGhlIERP VFMgc2VydmVyKHMpIGNhbiB1c2UgdGhlIE1lc3NhZ2UgSUQgYW5kDQogICAgICBUb2tlbiBpbiB0 aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBtZXNzYWdlIHRvIGRldGVjdCByZXBsYXkgb2YgZWFybHkN CiAgICAgIGRhdGEsIGFuZCBhY2NlcHQgMC1SVFQgZGF0YSBhdCBtb3N0IG9uY2UgZnJvbSB0aGUg c2FtZSBET1RTIGNsaWVudC4NCiAgICAgIFRoaXMgYW50aS1yZXBsYXkgZGVmZW5zZSByZXF1aXJl cyBzaGFyaW5nIHRoZSBNZXNzYWdlIElEIGFuZCBUb2tlbiBpbiB0aGUgMC1SVFQgZGF0YQ0KICAg ICAgYmV0d2VlbiBET1RTIHNlcnZlcnMgaW4gdGhlIERPVFMgc2VydmVyIGRvbWFpbi4gDQogICAg ICBET1RTIHNlcnZlcnMgZG8gbm90IHJlbHkgb24gdHJhbnNwb3J0IGNvb3JkaW5hdGVzIHRvIA0K ICAgICAgaWRlbnRpZnkgaXRzIHBlZXJzLiBBcyBhIHJlbWluZGVyLCBET1RTIHNlcnZlcnMgY291 cGxlcyB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBzZXNzaW9ucyANCiAgICAgIHVzaW5nIHRoZSBE T1RTIGNsaWVudCBpZGVudGl0eSBhbmQgb3B0aW9uYWxseSB0aGUgJ2NkaWQnIHBhcmFtZXRlciB2 YWx1ZS4NCg0KLVRpcnUNCg0KPiANCj4gPiA+ID4NCj4gPiA+ID4gU28gSSB0aGluayB0aGF0IHRo ZSAnbWlkJyBtb25vdG9uaWNpdHkgYW5kIHRoZSByZWplY3Rpb24gb2YNCj4gPiA+ID4gY29uZmxp Y3RpbmcgcmVxdWVzdCBzY29wZXMgYXJlIHRoZSBtYWluIG1pdGlnYXRpbmcgZmFjdG9ycyBhZ2Fp bnN0DQo+ID4gPiA+IHJlcGxheSBpbiB0aGUgY3VycmVudCBkZXNpZ24gKGFsb25nc2lkZSB0aGUg UkZDIDg0NDYgbWVjaGFuaXNtcywNCj4gPiA+ID4gb2YgY291cnNlKSwgYW5kIHRoZQ0KPiA+IHRl eHQNCj4gPiA+ID4gc2hvdWxkIGJlIGFkanVzdGVkIHRvIHJlZmxlY3QgdGhhdC4NCj4gPiA+DQo+ ID4gPiBbTWVkXSBXZSBkbyBhbHJlYWR5IGhhdmUgdGhlIGZvbGxvd2luZyBpbiB0aGUgZHJhZnQ6 DQo+ID4gPg0KPiA+ID4gICAgICAgVGhlIERPVFMgc2VydmVyKHMpIGNhbiB1c2UgTWVzc2FnZSBJ RCBhbmQNCj4gPiA+ICAgICAgIFRva2VuIGluIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIG1lc3Nh Z2UgdG8gZGV0ZWN0IHJlcGxheSBvZiBlYXJseQ0KPiA+ID4gICAgICAgZGF0YSwgYW5kIGFjY2Vw dCAwLVJUVCBkYXRhIGF0IG1vc3Qgb25jZS4gIEZ1cnRoZXJtb3JlLCAnbWlkJw0KPiA+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5e Xl5eXl5eXg0KPiA+ID4gICAgICAgdmFsdWUgaXMgbW9ub3RvbmljYWxseSBpbmNyZWFzZWQgYnkg dGhlIERPVFMgY2xpZW50IGZvciBlYWNoDQo+ID4gPiAgICAgICBtaXRpZ2F0aW9uIHJlcXVlc3Qs IGF0dGFja2VycyByZXBsYXlpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyB3aXRoDQo+ID4gPiAgICAg ICBsb3dlciBudW1lcmljICdtaWQnIHZhbHVlcyBhbmQgb3ZlcmxhcHBpbmcgc2NvcGVzIHdpdGgg bWl0aWdhdGlvbg0KPiA+ID4gICAgICAgcmVxdWVzdHMgaGF2aW5nIGhpZ2hlciBudW1lcmljICdt aWQnIHZhbHVlcyB3aWxsIGJlIHJlamVjdGVkDQo+ID4gPiAgICAgICBzeXN0ZW1hdGljYWxseSBi eSB0aGUgRE9UUyBzZXJ2ZXIuDQo+ID4NCj4gPiBTb3JyeSBmb3IgYmVpbmcgdW5jbGVhciBpbiBt eSBjb21tZW50LiBJIHdhcyBpbnRlbmRpbmcgdG8gZW1waGFzaXplDQo+ID4gdGhhdCAnbWlkJyBh bmQgc2NvcGUgYXJlIHRoZSAqb25seSogbWVhc3VyZXMgdGhhdCBhY3R1YWxseSBtaXRpZ2F0ZQ0K PiA+IGFnYWluc3QgMC1SVFQgcmVwbGF5LCBhbmQgdGhhdCB3ZSBhcmUgd3JvbmcgdG8gaGF2ZSB0 ZXh0IHRoYXQNCj4gPiBpbmRpY2F0ZXMgYW55dGhpbmcgZWxzZSBpcyBhbiBlZmZlY3RpdmUgYW50 aS1yZXBsYXkgbWVjaGFuaXNtLCBhdA0KPiA+IGxlYXN0IGdpdmVuIHRoZSBwcmVzZW50IGRlc2ln bi4gIFNvIEkgd2FzIHRyeWluZyB0byBhc2sgZm9yIHRoZSB0ZXh0DQo+ID4gYWJvdXQgTWVzc2Fn ZSBJRCBhbmQgVG9rZW4gdG8gYmUgcmVtb3ZlZC4gIChPdXIgc3Vic2VxdWVudCBkaXNjdXNzaW9u DQo+ID4gaW5kaWNhdGVzIHRoYXQgaXQgd291bGQgbWF5YmUgYWxzbyB3b3JrIHRvIGV4cGFuZCBv biBpdCBpbnN0ZWFkIG9mDQo+ID4gcmVtb3ZlIGl0LCBub3RpbmcgdGhhdCBET1RTIGlzIHJlcXVp cmluZyBhZGRpdGlvbmFsIGJlaGF2aW9yIG5vdA0KPiA+IG1hbmRhdGVkIGJ5IHRoZSBDb0FQIHNw ZWMuKQ0KPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEl0IHNlZW1zIHRoYXQgdGhlICdtaWQnIG9yZGVy aW5nIGlzIHByb2JhYmx5IGVub3VnaCB0byBwcm90ZWN0DQo+ID4gPiA+IHJlb3JkZXJpbmcvcmVw bGF5IG9mIG1pdGlnaWF0aW9uIHJlcXVlc3QgYW5kIHdpdGhkcmF3LCBldmVuIHdoZW4NCj4gPiBy ZW9yZGVyZWQNCj4gPiA+ID4gYWNyb3NzIG90aGVyIG1pdGlnYXRpb24gYWN0aW9ucy4gIEJ1dCBJ IGFtIG1vcmUgY29uY2VybmVkIGFib3V0DQo+ID4gPiA+IHJlb3JkZXJpbmcvcmVwbGF5IG9mIG90 aGVyIG1lc3NhZ2VzLCBsaWtlIGVmZmljYWN5IHVwZGF0ZXMgYW5kDQo+ID4gPiA+IHNlc3Npb24g Y29uZmlndXJhdGlvbiBjaGFuZ2VzLg0KPiA+ID4NCj4gPiA+IFtNZWRdIEZvciB0aGUgY29uZmln dXJhdGlvbiBjaGFuZ2VzLCBJIGRvbid0IGV4cGVjdCB0aGUgZXhjaGFuZ2UgdG8NCj4gPiA+IGhh cHBlbg0KPiA+IGR1cmluZyBhbiBhdHRhY2suIFRoZSBwYXJ0IG9mIHRoZSB0ZXh0IHdlIGFyZSBk aXNjdXNzaW5nIGlzIGFib3V0DQo+ID4gbWl0aWdhdGlvbiByZXF1ZXN0cy4NCj4gPiA+DQo+ID4g PiAgICBvICAwLVJUVCBtb2RlIGluIHdoaWNoIHRoZSBET1RTIGNsaWVudCBjYW4gYXV0aGVudGlj YXRlIGl0c2VsZiBhbmQNCj4gPiA+ICAgICAgIHNlbmQgRE9UUyBtaXRpZ2F0aW9uIHJlcXVlc3Qg bWVzc2FnZXMgaW4gdGhlIGZpcnN0IG1lc3NhZ2UsIHRodXMNCj4gPiA+ICAgICAgIF5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gPiA+ ICAgICAgIHJlZHVjaW5nIGhhbmRzaGFrZSBsYXRlbmN5Lg0KPiA+DQo+ID4gSWYgd2UgZG9uJ3Qg ZXhwZWN0IHRvIGRvIGFueXRoaW5nIG90aGVyIHRoYW4gbWl0aWdhdGlvbiByZXF1ZXN0cyBpbg0K PiA+IDAtUlRULCB0aGVuIHdoeSBkb24ndCB3ZSBqdXN0IGxpbWl0IHRoZSBtZXNzYWdlcyBhbGxv d2VkIGluIDAtUlRUIGRhdGENCj4gPiB0byBiZSBzdWNoIG1pdGlnYXRpb24gcmVxdWVzdCBtZXNz YWdlcyAoYW5kIGV4cGxpY2l0bHkgZXhjbHVkZSBzZXNzaW9uDQo+IGNvbmZpZ3VyYXRpb24pPw0K PiA+IEkgYW0gbm90IGdvaW5nIHRvIGluc2lzdCBvbiBpdCwgYnV0IHRoYXQgZG9lcyBzZWVtIGxp a2UgdGhlIHNpbXBsZXN0DQo+ID4gd2F5IHRvIHJlc29sdmUgdGhlIHF1ZXN0aW9uLCBhdCBsZWFz dCBmcm9tIG92ZXIgaGVyZS4NCj4gPg0KPiA+ID4gUHV0dGluZyB0aGF0IGFzaWRlLCB3ZSBkbyBo YXZlIHRoZSBmb2xsb3dpbmc6DQo+ID4gPg0KPiA+ID4gICAgVGhlIFBVVCByZXF1ZXN0IHdpdGgg YSBoaWdoZXIgbnVtZXJpYyAnc2lkJyB2YWx1ZSBvdmVycmlkZXMgdGhlIERPVFMNCj4gPiA+ICAg IHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIGluc3RhbGxlZCBieSBh IFBVVCByZXF1ZXN0DQo+ID4gPiAgICB3aXRoIGEgbG93ZXIgbnVtZXJpYyAnc2lkJyB2YWx1ZS4g IFRvIGF2b2lkIG1haW50YWluaW5nIGEgbG9uZyBsaXN0DQo+ID4gPiAgICBvZiAnc2lkJyByZXF1 ZXN0cyBmcm9tIGEgRE9UUyBjbGllbnQsIHRoZSBsb3dlciBudW1lcmljICdzaWQnIE1VU1QgYmUN Cj4gPiA+ICAgIGF1dG9tYXRpY2FsbHkgZGVsZXRlZCBhbmQgbm8gbG9uZ2VyIGF2YWlsYWJsZSBh dCB0aGUgRE9UUyBzZXJ2ZXIuDQo+ID4gPg0KPiA+ID4gQW55IHJlcGxheWVkIGNvbmZpZ3VyYXRp b24gY2hhbmdlIHJlcXVlc3Qgd2lsbCBiZSBkaXNjYXJkZWQgb3dpbmcgdG8NCj4gPiA+IHRoZQ0K PiA+ICdzaWQnIGNoZWNrcy4NCj4gPg0KPiA+IFRoYXQgZG9lcyBoZWxwLCB5ZXMuDQo+IA0KPiBb TWVkXSBPSy4NCj4gDQo+ICAgKEknbSBub3Qgc3VyZSB3aGV0aGVyIEkgaGFkIGNvbmZ1c2VkIG15 c2VsZiB0aGF0IHRoZQ0KPiA+IHNpZCB3YXMgZm9yIHRoZSBhYnN0cmFjdCAiRE9UUyBzZXNzaW9u IiB0aGF0IGlzIHJvdWdobHkgYWtpbiB0byB0aGUNCj4gPiBEVExTIGFzc29jaWF0aW9uLCBvciB0 aGlzIHdhcyBhZGRlZCBpbiByZXNwb25zZSB0byBzb21lIG9mIG15IGVhcmxpZXINCj4gPiBjb21t ZW50cyBhbmQgSSBmYWlsZWQgdG8gaW50ZXJuYWxpemUgaXQgcHJvcGVybHkuICBJdCBzaG93cyB1 cCBhcyBuZXcNCj4gPiBpbiB0aGUgZGlmZiBmcm9tIC0yNSB0byAtMjkgdGhhdCBJJ20gbG9va2lu ZyBhdCBpbiBwcmVwYXJhdGlvbiBmb3INCj4gPiBzdGFydGluZyBJRVRGIExDLikNCj4gPg0KPiA+ ID4gPg0KPiA+ID4gPiBDb25zaWRlcg0KPiA+ID4gPg0KPiA+ID4gPiBjbGllbnQgICAgICAgICAg ICAgICAgICAgYXR0YWNrZXIgICAgICAgICAgICAgICAgICAgIHNlcnZlcg0KPiA+ID4gPiB8DQo+ ID4gPiA+IHwtLS0tZWZmaWNhY3k6IGF0dGFjayBtaXRpZ2F0ZWQtLS0tLS0tLS0tLS0tLS0tLS0t LS0+fA0KPiA+ID4gPiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4gPiA+ID4gfC0tLS1lZmZpY2FjeTogdW5kZXIgYXR0YWNrLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLT58DQo+ID4gPiA+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ID4gPiB8ICAgICAgICAgICAgICAgICAgICAg ICAgfC1yZXBsYXk6IGF0dGFjayBtaXRpZ2F0ZWQtPnwNCj4gPiA+ID4NCj4gPiA+ID4gSXMgdGhl IHNlcnZlciBnb2luZyB0byBlbmQgdXAgd2l0aCB0aGUgZXhwZWN0ZWQgc3RhdGU/DQo+ID4gPg0K PiA+ID4gW01lZF0gQSBnZW5lcmFsIGNvbW1lbnQ6IFRoZSBkb3RzIHNlcnZlciB1c2VzIHRoZSBp bmZvcm1hdGlvbg0KPiA+ID4gY29udmV5ZWQgaW4NCj4gPiB0aGUgZWZmaWNhY3kgdXBkYXRlIGFz IGEgaGludDsgaXQgbWF5IGJ1dCBpdCBpcyBub3QgcmVxdWlyZWQgdG8gcmVseQ0KPiA+IG9uIHRo b3NlIHJlcXVlc3RzIHRvIGFkanVzdCBpdHMgbWl0aWdhdGlvbiBhY3Rpb25zLg0KPiA+ID4NCj4g PiA+IElmIHRoZSB0d28gZmlyc3Qgc3RhdHVzIG1lc3NhZ2VzIGFyZSBib3VuZCB0byBkaXN0aW5j dCAibWlkcyIgYW5kDQo+ID4gPiBhZGp1c3RlZA0KPiA+IHNjb3BlcywgdGhlIHJlcGxheWVkIHJl cXVlc3Qgd2lsbCBiZSBkaXNjYXJkZWQgYnkgdGhlIHNlcnZlciB0aGFua3MgdG8NCj4gPiB0aGUg cHJlc2VuY2Ugb2YgSWYtTWF0Y2ggb3B0aW9uLiBUaGUgc2VydmVyIGRvZXMgbm90IG1haW50YWlu IHRoZQ0KPiA+IHJlcXVlc3Qgd2l0aCB0aGUgb2xkIG1pZC4NCj4gPiA+DQo+ID4gPiBJZiwgZm9y IHNvbWUgcmVhc29uLCB0aGUgc2FtZSBtaWQgaXMgdXNlZCBhbmQgdGhpcyBmbG93IGlzIG9ic2Vy dmVkLA0KPiA+ID4gdGhlDQo+ID4gc2VydmVyIHdpbGwgZGV0ZWN0IHRoYXQgdGhlIHNhbWUgTWVz c2FnZSBJRCBhbmQgVG9rZW4gYXJlIHJldXNlZCBhZ2Fpbg0KPiA+IGFuZCB0aGVuIHJlamVjdC4N Cj4gPg0KPiA+IE5vdCBpZiB0aGUgcmVwbGF5IGNvbWVzIGZyb20gYSBkaWZmZXJlbnQgdHJhbnNw b3J0IGVuZHBvaW50ISAoQnV0DQo+ID4gbGV0J3Mga2VlcCB0aGlzIHRvcGljIGF0IHRoZSBkaXNj dXNzaW9uIGFib3ZlLCBhcyBpdCdzIHRoZSBzYW1lDQo+ID4gdG9waWMuKQ0KPiA+DQo+ID4gLUJl bg0KPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC1CZW4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+ID4gPiBE ZcKgOiBCZW5qYW1pbiBLYWR1ayBbbWFpbHRvOmthZHVrQG1pdC5lZHVdIEVudm95w6nCoDogdmVu ZHJlZGkNCj4gPiA+ID4gPiA+IDE1IGbDqXZyaWVyIDIwMTkgMTY6MDUgw4DCoDogQk9VQ0FEQUlS IE1vaGFtZWQgVEdJL09MTiBDY8KgOg0KPiA+ID4gPiA+ID4gS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeTsgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC0NCj4gPiBjaGFubmVsQGlldGYub3JnOw0KPiA+ ID4gPiA+ID4gZG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+ID4gT2JqZXTCoDogUmU6IFVzaW5nIEVh cmx5IERhdGEgaW4gRE9UUyAoUkU6IFtEb3RzXSBBRCByZXZpZXcgb2YNCj4gPiA+ID4gPiA+IGRy YWZ0LQ0KPiA+IGlldGYtDQo+ID4gPiA+ID4gPiBkb3RzLXNpZ25hbC1jaGFubmVsKQ0KPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+IEhpIE1lZCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTaG9y dCBmb3JtOiBJIG5lZWQgdG8gdGhpbmsgYWJvdXQgaXQgaGFyZGVyLiAgVGhlcmUncyBzb21lDQo+ ID4gPiA+ID4gPiBpbmRpY2F0aW9uDQo+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiA+IHRoZSBDb0Fw IE1lc3NhZ2UgSUQgaXMgYXQgdGhlIHdyb25nIGxldmVsIHRvIHByb3RlY3QgdGhlIDAtUlRUDQo+ ID4gPiA+ID4gPiBkYXRhLA0KPiA+IGJ1dA0KPiA+ID4gPiA+ID4gSSdtIG5vdCBzdXJlIHlldC4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTb3JyeSBmb3IgdGhlIGRlbGF5czsgdGhpcyBoYXMg YmVlbiBhIGZyZW5ldGljIGNvdXBsZSB3ZWVrcyA6KA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ IC1CZW4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBPbiBGcmksIEZlYiAxNSwgMjAxOSBhdCAw MzowMToyOVBNICswMDAwLA0KPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+ ID4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+IEhpIEJlbiwNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+ID4gV2hhdCBpcyB0aGUgc3RhdHVzIGZvciB0aGlzIG9uZT8gQXJlIHdlIE9LIHRvIG1vdmUg Zm9yd2FyZD8NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gVGhhbmsgeW91Lg0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+ID4gPiA+IE1lZA0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBEZcKg Og0KPiA+ID4gPiA+ID4gPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+ID4g W21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiA+ID4gPiA+ID4gPiA+IEVu dm95w6nCoDogbWFyZGkgMjkgamFudmllciAyMDE5IDE0OjMyIMOAwqA6IEJlbmphbWluIEthZHVr IENjDQo+ID4gPiA+ID4gPiA+ID4gOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBkcmFmdC1p ZXRmLWRvdHMtc2lnbmFsLQ0KPiA+ID4gPiBjaGFubmVsQGlldGYub3JnOw0KPiA+ID4gPiA+ID4g PiA+IGRvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4gPiBPYmpldMKgOiBVc2luZyBFYXJseSBE YXRhIGluIERPVFMgKFJFOiBbRG90c10gQUQgcmV2aWV3IG9mDQo+ID4gPiA+ID4gPiA+ID4gZHJh ZnQtDQo+ID4gaWV0Zi0NCj4gPiA+ID4gPiA+IGRvdHMtDQo+ID4gPiA+ID4gPiA+ID4gc2lnbmFs LWNoYW5uZWwpDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBIaSBCZW4sIGFsbCwN Cj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IFdlIGVkaXRlZCBhIHNob3J0IGRyYWZ0 DQo+ID4gPiA+ID4gPiA+ID4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0NCj4g PiBib3VjYWRhaXItDQo+ID4gPiA+ID4gPiBkb3RzLQ0KPiA+ID4gPiA+ID4gPiA+IGVhcmx5ZGF0 YS0wMCkgdG8gbW90aXZhdGUgdGhlIGZvbGxvd2luZyB0ZXh0IGluY2x1ZGVkIGluDQo+ID4gPiA+ ID4gPiA+ID4gdGhlDQo+ID4gc2lnbmFsDQo+ID4gPiA+ID4gPiBjaGFubmVsDQo+ID4gPiA+ID4g PiA+ID4gZHJhZnQ6DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICBTZWN0 aW9uIDggb2YgW1JGQzg0NDZdIGRpc2N1c3NlcyBzb21lIG1lY2hhbmlzbXMgdG8NCj4gPiBpbXBs ZW1lbnQNCj4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+ID4gPiAgICAgICBsaW1pdCB0aGUgaW1wYWN0 IG9mIHJlcGxheSBhdHRhY2tzIG9uIDAtUlRUIGRhdGEuDQo+ID4gPiA+ID4gPiA+ID4gSWYgdGhl DQo+ID4gRE9UUw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIHNlcnZlciBhY2NlcHRzIDAtUlRULCBp dCBNVVNUIGltcGxlbWVudCBvbmUgb2YgdGhlc2UNCj4gPiA+ID4gbWVjaGFuaXNtcy4NCj4gPiA+ ID4gPiA+ID4gPiAgICAgICBBIERPVFMgc2VydmVyIGNhbiByZWplY3QgMC1SVFQgYnkgc2VuZGlu ZyBhIFRMUw0KPiA+ID4gPiBIZWxsb1JldHJ5UmVxdWVzdC4NCj4gPiA+ID4gPiA+ID4gPiAgICAg ICBUaGUgRE9UUyBzaWduYWwgY2hhbm5lbCBtZXNzYWdlcyBzZW50IGFzIGVhcmx5IGRhdGENCj4g PiA+ID4gPiA+ID4gPiBieSB0aGUNCj4gPiBET1RTDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgY2xp ZW50IGFyZSBpZGVtcG90ZW50IHJlcXVlc3RzLiAgQXMgYSByZW1pbmRlciwgTWVzc2FnZSBJRA0K PiA+ID4gPiA+ID4gPiA+ICAgICAgIChTZWN0aW9uIDMgb2YgW1JGQzcyNTJdKSBpcyBjaGFuZ2Vk IGVhY2ggdGltZSBhIG5ldw0KPiA+ID4gPiA+ID4gPiA+IENvQVANCj4gPiA+ID4gcmVxdWVzdA0K PiA+ID4gPiA+ID4gPiA+ICAgICAgIGlzIHNlbnQsIGFuZCB0aGUgVG9rZW4gKFNlY3Rpb24gNS4z LjEgb2YgW1JGQzcyNTJdKQ0KPiA+ID4gPiA+ID4gPiA+IGlzDQo+ID4gPiA+IHJhbmRvbWl6ZWQN Cj4gPiA+ID4gPiA+ID4gPiAgICAgICBpbiBlYWNoIENvQVAgcmVxdWVzdC4gIFRoZSBET1RTIHNl cnZlcihzKSBjYW4gdXNlDQo+ID4gPiA+ID4gPiA+ID4gTWVzc2FnZQ0KPiA+IElEDQo+ID4gPiA+ IGFuZA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIFRva2VuIGluIHRoZSBET1RTIHNpZ25hbCBjaGFu bmVsIG1lc3NhZ2UgdG8gZGV0ZWN0DQo+ID4gPiA+ID4gPiA+ID4gcmVwbGF5DQo+ID4gb2YNCj4g PiA+ID4gZWFybHkNCj4gPiA+ID4gPiA+ID4gPiAgICAgICBkYXRhLCBhbmQgYWNjZXB0IDAtUlRU IGRhdGEgYXQgbW9zdCBvbmNlLg0KPiA+ID4gPiA+ID4gPiA+IEZ1cnRoZXJtb3JlLA0KPiA+ICdt aWQnDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgdmFsdWUgaXMgbW9ub3RvbmljYWxseSBpbmNyZWFz ZWQgYnkgdGhlIERPVFMgY2xpZW50DQo+ID4gPiA+ID4gPiA+ID4gZm9yDQo+ID4gZWFjaA0KPiA+ ID4gPiA+ID4gPiA+ICAgICAgIG1pdGlnYXRpb24gcmVxdWVzdCwgYXR0YWNrZXJzIHJlcGxheWlu ZyBtaXRpZ2F0aW9uDQo+ID4gPiA+ID4gPiA+ID4gcmVxdWVzdHMNCj4gPiA+ID4gd2l0aA0KPiA+ ID4gPiA+ID4gPiA+ICAgICAgIGxvd2VyIG51bWVyaWMgJ21pZCcgdmFsdWVzIGFuZCBvdmVybGFw cGluZyBzY29wZXMNCj4gPiA+ID4gPiA+ID4gPiB3aXRoDQo+ID4gPiA+IG1pdGlnYXRpb24NCj4g PiA+ID4gPiA+ID4gPiAgICAgICByZXF1ZXN0cyBoYXZpbmcgaGlnaGVyIG51bWVyaWMgJ21pZCcg dmFsdWVzIHdpbGwgYmUNCj4gPiByZWplY3RlZA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIHN5c3Rl bWF0aWNhbGx5IGJ5IHRoZSBET1RTIHNlcnZlci4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiA+ICAgICAgIE93aW5nIHRvIHRoZSBhZm9yZW1lbnRpb25lZCBwcm90ZWN0aW9ucywgZXNw ZWNpYWxseQ0KPiA+ID4gPiA+ID4gPiA+IHRob3NlDQo+ID4gPiA+IGFmZm9yZGVkDQo+ID4gPiA+ ID4gPiA+ID4gICAgICAgYnkgQ29BUCBkZWR1cGxpY2F0aW9uIChTZWN0aW9uIDQuNSBvZiBbUkZD NzI1Ml0pIGFuZA0KPiA+ID4gPiA+ID4gPiA+IFJGQw0KPiA+IDg0NDYNCj4gPiA+ID4gPiA+ID4g PiAgICAgICBhbnRpLXJlcGxheSBtZWNoYW5pc21zLCBhbGwgRE9UUyBzaWduYWwgY2hhbm5lbA0K PiA+ID4gPiA+ID4gPiA+IHJlcXVlc3RzDQo+ID4gYXJlDQo+ID4gPiA+IHNhZmUNCj4gPiA+ID4g PiA+ID4gPiAgICAgICB0byB0cmFuc21pdCBpbiBUTFMgMS4zIGFzIGVhcmx5IGRhdGEuICBSZWZl ciB0bw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgIFtJLUQuYm91Y2FkYWlyLWRvdHMtZWFybHlkYXRh XSBmb3IgbW9yZSBkZXRhaWxzLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gVGhp cyB0ZXh0IGFuZCBhbHNvIHRoZSBEZXNpZ25hdGVkIEV4cGVydCBndWlkZWxpbmVzIGFyZQ0KPiA+ IGltcGxlbWVudGVkDQo+ID4gPiA+IGluIC0NCj4gPiA+ID4gPiA+IDI4Lg0KPiA+ID4gPiA+ID4g PiA+IFRoZXNlIGFyZSB0aGUgdHdvIHBlbmRpbmcgaXNzdWVzIGZyb20geW91ciBBRCByZXZpZXcu DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBPdGhlciBlZGl0cyB3ZXJlIGFsc28g bWFkZSB0byByZWNvcmQgd2hhdCB3YXMgYWdyZWVkIG9uIHRoZSBsaXN0Lg0KPiA+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+ID4gV2UgaG9wZSB0aGlzIHZlcnNpb24gaXMgbm93IHJlYWR5IHRv IG1vdmUgZm9yd2FyZC4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IENoZWVycywN Cj4gPiA+ID4gPiA+ID4gPiBNZWQNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g PiA+ID4gPiBSZWdhcmRpbmcgdGhlIChEKVRMUyAxLjMgMC1SVFQgZGF0YSwgUkZDIDg0NDYNCj4g PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gbm90ZXMNCj4gPiB0aGF0DQo+ID4gPiA+ID4gPiA+ID4g IkFwcGxpY2F0aW9uDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHByb3RvY29scyBNVVNUIE5P VCB1c2UgMC1SVFQgZGF0YSB3aXRob3V0IGENCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gcHJv ZmlsZQ0KPiA+IHRoYXQNCj4gPiA+ID4gPiA+IGRlZmluZXMNCj4gPiA+ID4gPiA+ID4gPiBpdHMN Cj4gPiA+ID4gPiA+ID4gPiA+ID4gdXNlLg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBUaGF0 IHByb2ZpbGUgbmVlZHMgdG8gaWRlbnRpZnkgd2hpY2ggbWVzc2FnZXMgb3INCj4gPiA+ID4gaW50 ZXJhY3Rpb25zDQo+ID4gPiA+ID4gPiBhcmUNCj4gPiA+ID4gPiA+ID4gPiA+IHNhZmUNCj4gPiA+ ID4gPiA+ID4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHVzZQ0KPiA+ID4gPiA+ ID4gPiA+ID4gPiA+ID4gPiB3aXRoIDAtUlRUIGFuZCBob3cgdG8gaGFuZGxlIHRoZSBzaXR1YXRp b24gd2hlbg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiB0aGUNCj4gPiBzZXJ2ZXINCj4gPiA+ ID4gPiA+IHJlamVjdHMNCj4gPiA+ID4gPiA+ID4gPiAwLQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiBS VFQNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGFuZA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g PiBmYWxscyBiYWNrIHRvIDEtUlRULiIgIFNvIHdlIGVpdGhlciBuZWVkIHRvIHNheQ0KPiA+ID4g PiA+ID4gPiA+ID4gPiA+ID4gPiB3aGljaA0KPiA+ID4gPiBjbGllbnQNCj4gPiA+ID4gPiA+ID4g PiByZXF1ZXN0cw0KPiA+ID4gPiA+ID4gPiA+ID4gPiBhcmUNCj4gPiA+ID4gPiA+ID4gPiA+ID4g PiA+IDAtUlRUDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHNhZmUgKGFuZCB3aHkpIG9yIGRl ZmVyIHRoYXQgcHJvZmlsZSB0byBhbm90aGVyDQo+ID4gZG9jdW1lbnQuDQo+ID4gPiA+ID4gPiBk cmFmdC0NCj4gPiA+ID4gPiA+ID4gPiA+IGlldGYtDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBk bnNvcC0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gc2Vzc2lvbi1zaWduYWwgaXMgcGVyaGFw cyBhbiBleGFtcGxlIG9mIGENCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gZG9jdW1lbnQgdGhh dA0KPiA+ID4gPiA+ID4gc3BlY2lmaWVzDQo+ID4gPiA+ID4gPiA+ID4gPiB3aGljaA0KPiA+ID4g PiA+ID4gPiA+ID4gPiA+ID4gPiBtZXNzYWdlcyBhcmUvYXJlbid0IGFsbG93ZWQgaW4gZWFybHkg ZGF0YS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKGRyYWZ0LWlldGYtYWNtZS1hY21lIGlz IGFub3RoZXIsIGJ1dCBhbg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiB1bmludGVyZXN0aW5n DQo+ID4gb25lLA0KPiA+ID4gPiA+ID4gc2luY2UNCj4gPiA+ID4gPiA+ID4gPiA+IHRoZXkNCj4g PiA+ID4gPiA+ID4gPiA+ID4gbWFrZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBldmVyeSBy ZXF1ZXN0IGluY2x1ZGUgYSBzaW5nbGUtdXNlIG5vbmNlLCBhbmQNCj4gPiA+ID4gPiA+ID4gPiA+ ID4gPiA+ID4gYWxsDQo+ID4gbWVzc2FnZXMNCj4gPiA+ID4gYXJlDQo+ID4gPiA+ID4gPiAwLQ0K PiA+ID4gPiA+ID4gPiA+IFJUVA0KPiA+ID4gPiA+ID4gPiA+ID4gPiBzYWZlLikNCj4gPiA+ID4g PiA+ID4gPiA+ID4gPiA+ID4gT3VyIHVzZSBvZiBpbmNyZWFzaW5nICdtaWQnIHZhbHVlcyBtYXkg aGVscA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBoZXJlLCBpbg0KPiA+IHRlcm1zDQo+ID4g PiA+IG9mDQo+ID4gPiA+ID4gPiA+ID4gPiBhbGxvd2luZw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ ID4gREVMRVRFcw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiB0byBiZSBzYWZlLCBidXQgSSdk IGhhdmUgdG8gdGhpbmsgYSBsaXR0bGUgbW9yZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiB0 byBiZQ0KPiA+IHN1cmUNCj4gPiA+ID4gdGhhdA0KPiA+ID4gPiA+ID4gPiA+ID4gPiByZXF1ZXN0 aW5nDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IG1pdGlnYXRpb24gd291bGQgYmUgc2FmZS4g IChPbiBmaXJzdCBnbGFuY2UgdGhlDQo+ID4gc2Vzc2lvbi0NCj4gPiA+ID4gPiA+IG1hbmFnZW1u ZXQNCj4gPiA+ID4gPiA+ID4gPiA+IGJpdHMNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHdvdWxk DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IG5vdCBiZSBzYWZlLCBidXQgSSBtYXkgYmUgbWlz c2luZyBzb21ldGhpbmcuKQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g PiA+ID4gPiA+IFRoZSBkcmFmdCBvbmx5IHVzZXMgaWRlbXBvdGVudCByZXF1ZXN0cyAoR0VULCBQ VVQNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGFuZA0KPiA+ID4gPiBERUxFVEUpLA0KPiA+ID4g PiA+ID4gYW5kDQo+ID4gPiA+ID4gPiA+ID4gQ29BUA0KPiA+ID4gPiA+ID4gPiA+ID4gPiBpcw0K PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gY2FwYWJsZSBvZiBkZXRlY3RpbmcgbWVzc2FnZSBkdXBs aWNhdGlvbiAoc2VlDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTQuNSkNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGZv ciBib3RoDQo+ID4gPiA+ID4gPiBjb25maXJtYWJsZQ0KPiA+ID4gPiA+ID4gPiA+ID4gYW5kDQo+ ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBub24tY29uZmlybWFibGUgbWVzc2FnZXMuDQo+ID4gPiA+ ID4gPiA+ID4gPiA+ID4gPiAgWzFdIEFuIGF0dGFja2VyIHJlcGxheWluZyBERUxFVEUgd2lsbCBu b3QgaGF2ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gYW55DQo+ID4gYWR2ZXJzZQ0KPiA+ID4g PiA+ID4gaW1wYWN0LA0KPiA+ID4gPiA+ID4gPiA+ID4gMi4wMg0KPiA+ID4gPiA+ID4gPiA+ID4g PiA+ID4gKERlbGV0ZWQpIFJlc3BvbnNlIENvZGUgaXMgcmV0dXJuZWQgZXZlbiBpZiB0aGUNCj4g PiBtaXRpZ2F0aW9uDQo+ID4gPiA+ID4gPiByZXF1ZXN0DQo+ID4gPiA+ID4gPiA+ID4gZG9lcw0K PiA+ID4gPiA+ID4gPiA+ID4gPiBub3QNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGV4aXN0Lg0K PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gWzJdIFRoZSB0ZWNobmlxdWVzIGRpc2N1c3NlZCBpbiBT ZWN0aW9uIDggb2YNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IFJGQzg0NDYNCj4gPiBzaG91bGQN Cj4gPiA+ID4gPiA+IHN1ZmZpY2UNCj4gPiA+ID4gPiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4gPiA+ ID4gPiBoYW5kbGUNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGFudGktcmVwbGF5IChlLmcuIGFu IGF0dGFja2VyIHJlcGxheWluZyBhIDAtUlRUDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBkYXRh DQo+ID4gY2FycnlpbmcNCj4gPiA+ID4gYW4NCj4gPiA+ID4gPiA+IG9sZA0KPiA+ID4gPiA+ID4g PiA+ID4gPiA+ID4gbWl0aWdhdGlvbiByZXF1ZXN0IHJlcGxhY2VkIGJ5IGEgbmV3IG1pdGlnYXRp b24gc2NvcGUpLg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IFtNZWRdIEZXSVcsIHdlIGRvIGFscmVhZHkgaGF2ZSB0 aGlzIHRleHQgaW4gdGhlIGRyYWZ0Og0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiA+ID4gPiA+ID4gICAgICAgU2VjdGlvbiA4IG9mIFtSRkM4NDQ2XSBkaXNjdXNzZXMgc29tZQ0K PiA+ID4gPiA+ID4gPiA+ID4gPiA+IG1lY2hhbmlzbXMgdG8NCj4gPiA+ID4gaW1wbGVtZW50DQo+ ID4gPiA+ID4gPiB0bw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICAgICAgIGxpbWl0IHRoZSBpbXBh Y3Qgb2YgcmVwbGF5IGF0dGFja3Mgb24gMC1SVFQNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBkYXRh LiAgSWYNCj4gPiB0aGUNCj4gPiA+ID4gPiA+IERPVFMNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiAg ICAgICBzZXJ2ZXIgYWNjZXB0cyAwLVJUVCwgaXQgTVVTVCBpbXBsZW1lbnQgb25lIG9mDQo+ID4g PiA+ID4gPiA+ID4gPiA+ID4gdGhlc2UNCj4gPiA+ID4gPiA+IG1lY2hhbmlzbXMNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IERvdHMgbWFp bGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kb3RzDQo= From nobody Thu Feb 28 03:00:28 2019 Return-Path: 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 47AFC128BCC; Thu, 28 Feb 2019 03:00:27 -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 WCbuTTVxL-Zg; Thu, 28 Feb 2019 03:00:23 -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 E733E12D4E8; Thu, 28 Feb 2019 03:00:22 -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=1551351466; 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=rgtArY2CSyIMdgdd9s6uyhVrL9MEa4z1//VTn9 flWUY=; b=BrugsCqJzjOlV+fZyCbTFAJjoNHfHw9afhmGcFee qSNNnmHwg4xyr0qKHevffo5n/INek9N4Qdq9sVGYu/ESSrI9E1 r/4srJCmnVduI0t1bZzehPN+rctVU1ckn9k+rTAkCieao8tKxp IlJaPd6PVWYbqZgOktkiTx+VCk3KOsw= 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 21ae_4980_f6b9dcf7_6809_458d_ab0a_4f70d75040f1; Thu, 28 Feb 2019 03:57:46 -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; Thu, 28 Feb 2019 04:00:13 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 28 Feb 2019 04:00:13 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 04:00:10 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2725.namprd16.prod.outlook.com (20.178.232.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Thu, 28 Feb 2019 11:00:08 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 11:00:08 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Benjamin Kaduk" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxRIUo475NEhnvke5Q68IH00fwKXgsiOQgAAV9gCAEoE9oIABvKCAgAAWnNA= Date: Thu, 28 Feb 2019 11:00:07 +0000 Message-ID: References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA1FEC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA26902@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA26902@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.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 643b1901-9a09-4393-96bb-08d69d6be6e5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2725; x-ms-traffictypediagnostic: BYAPR16MB2725: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyNzI1OzIzOitWOTFhOE1OQm52U0g5WTBCeTY0ZHNqVnRh?= =?utf-8?B?OHZXOEVCeWYwVDFQc2NGNEFSVlZkUWp1aVE0MjFMYWkwbnI5bXRKOWRUd2ov?= =?utf-8?B?eDZPRXgzeFVDVkk4Sm5JVjFwM1lPZHhMY0JpMUpkb1ZEY1NROUkyQUM1RkxK?= =?utf-8?B?WXRISkwrbU9KSzRITjFpbjlnVnRHbHAxd2pzUzJMZEFDMFRvbkVPdWUzS2lF?= =?utf-8?B?UjhFa0c4ZFQ2eFZWRHd1UVByc0hsNjd4WjhQSXM2a2NGUlhGZmNONXJadStZ?= =?utf-8?B?ZGpLUGxXNWc0aUpSR1d0QktYOXlSUTREVVF6cTM0ZXZBbENyK0dPUi9TNmtm?= =?utf-8?B?THB0MjNjQldXM2V5YUlMUTVXSWFuak03RkRNeTQ3a3U0b2habSs0L1BHV1lN?= =?utf-8?B?R1NLWnRKYjhVYmdsVG1nQXZuSnB6R0dSWnREdTZlYVJLcVFLdUxhTktZS2Ny?= =?utf-8?B?Vlh6U0hhRC9rckg2WlI4V3haaHE2VWNzcEIzTVUyU0oxMFVjKzJJcWJoQlFK?= =?utf-8?B?dmYxeHE3VXIvejVFSE4zeXUvVmd4Y0dyUE9DZ083N3Z3RFFmQTlwL1FwQk5W?= =?utf-8?B?T0dJUkFmN2hnUzRkc3pzdHpIME5pbCtDWWs4RWp6WllOeWdMRUpFdmJtaTRE?= =?utf-8?B?U01ORmtzYzh1akFoMWZjYjdVL0VBdm1PcEFScndOVWNBYllqR3hsd25NeWR3?= =?utf-8?B?bUpvU0ZhUi8zMy9yMVBsdmZySExham0zVSsvK2Q1elNKa1cxT1MvbUtKbDls?= =?utf-8?B?ZWI4eE9XOURPejU5N0FybDl6cUNpU1l1RnZzZWt5NmpnVkNHM0F2NUV4eTZ2?= =?utf-8?B?cmFFWlhkWFZHdzB2dGJ5TE1pazFMQU92RlNVOVhSOWY5N1QyWFFNVmtlQk9t?= =?utf-8?B?V2VjV1hiL2VFNmtRelpUY2JrdHB2aktadnQvQ21CRDI5UUxYUnF5Y1pFZnRl?= =?utf-8?B?RUMwMGJTVnRIcjgvc2p5dW8wU0Iza3doc3VGN0pwUW55eHJMQUY3Y2NwYkps?= =?utf-8?B?OG85VDFibnRpZ081VWcyanluVXp0RS9WOEpGREJvYllmZFU1T1JDMUFBL2dx?= =?utf-8?B?Z080N2Q2NHFSVklaUXZlbTNwdUpkdkRHZU5QTWRZcms2aFY0c2dvQ0NsTnVs?= =?utf-8?B?bEhEZGxMZ1o5dlZOWlF4UGVwa1lESStjaU13K2FYUy8zTzNRZ3h0OVdNOEh3?= =?utf-8?B?Q2g0NnJGdUM4ZUdrWm14MTQrb2gxWE9yaUZ6M1pKTDBXeXhNNU9vNDVDUlJG?= =?utf-8?B?VVExeDkyczY4RndScEx4YUNrZkNGeGtmN3kzVk1uTFh6R3lia29uQlJ4bHZt?= =?utf-8?B?OHFCVEZKcFhRbU4zL3d3dlhIMENxR1JIeXNzNGtWR3V0M0lvaDNHTnRXbFdj?= =?utf-8?B?MnhTL0w2NGxPbVlKdFdURWxCVm9JdUE1ZHd4cjQ3clF5QTBXcTBaZGdpY2pG?= =?utf-8?B?NTZzRkpQN29jU0F5R1o3TVVMOWEvUVVwbzRUT2JyMUxkTUFKZEZjdWdUOTFG?= =?utf-8?B?MFRlUi94NDI3YlB0ays0aWFKMEplMzRzcnFjQTMzZzBCUGI4b3RFTldsTG80?= =?utf-8?B?UXEycGhmM21nd0tSR3FDNmFIblFYV0YwT3h2V1BXaVh5WWF2dnQ2TU5nanRW?= =?utf-8?B?TCtHY2doNXNSMkpITHViT3E3WnpTOC9BSUN1d21NNVBQZ2NvdVB4SFdMUkZp?= =?utf-8?B?UTMwMUowZU50akRGTHBsYmRSN1lKakQzNTBUUDdQeGpOR1BWd3g4MHhtVTBm?= =?utf-8?B?Z21ZMDFNS0wyU3Frcm4vdTc1QkVDR0kxSWlBL0JmTTI1SXNFVjFlVVovVVRX?= =?utf-8?B?MFhZQlNnN2RySDZkM1c3R09EKzJwNGpsazNydndaWWxubFoyK2gvUUdVMlVa?= =?utf-8?B?V3dja05tOHBteXZzMFlxWEN1L0pBVCs5bDlicXdTTlF2MkdPdG5LZEU1Q3du?= =?utf-8?B?S0tHbmJhV3VidndvajFkc0srNVFEaHI0RGNCRlk5a1Rib25NOUh2U1pCZjdw?= =?utf-8?Q?mobIH0?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(396003)(376002)(346002)(189003)(199004)(13464003)(32952001)(6116002)(6246003)(93886005)(53936002)(2501003)(7696005)(486006)(446003)(33656002)(8936002)(2906002)(11346002)(99286004)(3846002)(2171002)(68736007)(81156014)(81166006)(110136005)(476003)(54906003)(186003)(76176011)(8676002)(316002)(66066001)(26005)(25786009)(6436002)(53546011)(5660300002)(6506007)(52536013)(66574012)(102836004)(5024004)(14444005)(256004)(74316002)(478600001)(72206003)(80792005)(106356001)(9686003)(55016002)(305945005)(97736004)(7736002)(229853002)(4326008)(86362001)(71200400001)(71190400001)(14454004)(105586002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2725; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: aNhU4yuvwpZ+6Za5Tmm3R77sdFQ9kjhFlwzMfdwwNX1Izx/ExSmKCXxC8U9ISQ1B7s2j36touH4ismosHbHLZgwfv3HuwNsVUgi3+J4xr5KgMI1LVg4RI9fN5dTlMCKdxSw20zvUA1NLjQ8kBafru9Ee/Ruj5pgy7L2IFSog7UxOFYkSmPzSW7A4Ci7CQI/vo3cgqYJ997BsDP7Le0OoNvYHfzeLLQZYcw7WD91wVn4ldieNf0WQimiIKlv6qZRHJUGT+tGDo01Dvyapz7nY9DVS/E8hJqM2jJ2Y0o/ULgQ1WNKUz5WnGClODGzCNEV5DXLRxeLwxVX580RIIt4WDcOdGzUA+p/r295yFk629quWBeC4KMts4N7kZBPnu0+C3je7eCEbEaai30HGhdbzCqqT6RtK9EHRzN0z2Iuy0i4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 643b1901-9a09-4393-96bb-08d69d6be6e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 11:00:07.8710 (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: BYAPR16MB2725 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7025> : streams <1814339> : uri <2803637> Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 11:00:27 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMjgsIDIwMTkgMjo1OSBQTQ0KPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+IEJlbmphbWluIEth ZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiBDYzogZG90c0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kb3Rz LWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4gDQo+IA0KPiANCj4gUmUtLA0KPiANCj4gSSBh ZGRlZCB0aGlzIG5vdGUgdG8gbXkgbG9jYWwgY29weToNCj4gDQo+ICAgIEhvdyBhIERPVFMgY2xp ZW50IHN5bmNocm9uaXplcyBpdHMgY29uZmlndXJhdGlvbiB3aXRoIHRoZSBvbmUNCj4gICAgbWFp bnRhaW5lZCBieSBpdHMgRE9UUyBzZXJ2ZXIocykgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMu ICBGb3INCj4gICAgZXhhbXBsZSwgYSBET1RTIGNsaWVudCBjYW4gc2VuZCBhIEdFVCBtZXNzYWdl IGJlZm9yZSBhbmQvb3IgYWZ0ZXIgZWFjaA0KPiAgICBjb25maWd1cmF0aW9uIGNoYW5nZSByZXF1 ZXN0Lg0KDQpUaGUgZXhhbXBsZSBkb2VzIG5vdCBsb29rIGNvcnJlY3QsIG5vIG5lZWQgdG8gc2Vu ZCBHRVQgbWVzc2FnZXMgdG8gc3luY2hyb25pemUgdGhlIGNvbmZpZ3VyYXRpb24gZHVyaW5nIHBl YWNlIHRpbWUuICBXZSBuZWVkIGFuIGV4YW1wbGUgdG8gZGlzY3VzcyB0aGUgc2NlbmFyaW8gd2hl biBhdHRhY2sgdHJhZmZpYyBpcyBpbml0aWF0ZWQgYW5kIGNsaWVudCBkaWQgbm90IHJlY2VpdmUg cmVzcG9uc2UgdG8gdGhlIGNvbmZpZ3VyYXRpb24gcmVxdWVzdCBmcm9tIHRoZSBET1RTIHNlcnZl ci4NCkkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIHVwZGF0ZToNCkZvciBleGFtcGxlLCBhIERPVFMg Y2xpZW50IGNhbiByZS1lc3RhYmxpc2ggdGhlIGRpc2Nvbm5lY3RlZCBET1RTIHNpZ25hbCBjaGFu bmVsIHNlc3Npb24gYWZ0ZXIgdGhlIGF0dGFjayBpcyBtaXRpZ2F0ZWQgYW5kIA0Kc2VuZHMgYSBH RVQgbWVzc2FnZSBiZWZvcmUgY29uZmlndXJhdGlvbiBjaGFuZ2UgcmVxdWVzdC4NCg0KQ2hlZXJz LA0KLVRpcnUNCg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+IFtt YWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gPiBFbnZvecOpwqA6 IG1lcmNyZWRpIDI3IGbDqXZyaWVyIDIwMTkgMDc6NTkgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQg VEdJL09MTjsNCj4gPiBCZW5qYW1pbiBLYWR1ayBDY8KgOiBkb3RzQGlldGYub3JnOw0KPiA+IGRy YWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWxAaWV0Zi5vcmcNCj4gPiBPYmpldMKgOiBSRTogQUQg cmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4gPg0KPiA+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ID4gPiBTZW50OiBG cmlkYXksIEZlYnJ1YXJ5IDE1LCAyMDE5IDU6NTMgUE0NCj4gPiA+IFRvOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5DQo+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsNCj4g PiA+IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiA+ID4gQ2M6IGRvdHNAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWxAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6 IFJFOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0yNQ0KPiA+ID4N Cj4gPiA+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXph dGlvbi4gRG8gbm90IGNsaWNrDQo+ID4gPiBsaW5rcw0KPiA+IG9yDQo+ID4gPiBvcGVuIGF0dGFj aG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlDQo+ID4g PiBjb250ZW50IGlzDQo+ID4gc2FmZS4NCj4gPiA+DQo+ID4gPiBIaSBUaXJ1LA0KPiA+ID4NCj4g PiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ID4NCj4gPiA+IENoZWVycywNCj4gPiA+IE1lZA0K PiA+ID4NCj4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+IERlwqA6 IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiA+ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+ID4gPiBFbnZvecOpwqA6IHZlbmRyZWRpIDE1IGbD qXZyaWVyIDIwMTkgMTI6MDYgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQNCj4gPiA+ID4gVEdJL09M TjsgQmVuamFtaW4gS2FkdWsgQ2PCoDogZG90c0BpZXRmLm9yZzsNCj4gPiA+ID4gZHJhZnQtaWV0 Zi1kb3RzLWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiA+ID4gPiBPYmpldMKgOiBSRTogQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4gPiA+ID4NCj4gPiA+ID4g SSBhbSBjYXRjaGluZyB1cCB3aXRoIHRoZSBkaXNjdXNzaW9uLCBjb3VwbGUgb2YgcG9pbnRzOg0K PiA+ID4gPg0KPiA+ID4gPiAxKQ0KPiA+ID4gPiAgICAgICAqICBJZiBhIG5ldHdvcmsgcmVzb3Vy Y2UgKERPVFMgY2xpZW50KSBkZXRlY3RzIGEgcG90ZW50aWFsIEREb1MNCj4gPiA+ID4gICAgICAg ICAgYXR0YWNrIGZyb20gYSBzZXQgb2YgSVAgYWRkcmVzc2VzLCB0aGUgRE9UUyBjbGllbnQgaW5m b3JtcyBpdHMNCj4gPiA+ID4gICAgICAgICAgc2VydmljaW5nIERPVFMgZ2F0ZXdheSBvZiBhbGwg c3VzcGVjdCBJUCBhZGRyZXNzZXMgdGhhdCBuZWVkIHRvDQo+ID4gPiA+ICAgICAgICAgIGJlIGRy b3AtIG9yIGFjY2VwdC1saXN0ZWQgZm9yIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbi4NCj4gPiA+ID4N Cj4gPiA+ID4gQ29tbWVudD4gSSBkb24ndCBzZWUgd2h5IHN1c3BlY3QgSVAgYWRkcmVzc2VzIHdp bGwgYmUgYWNjZXB0LWxpc3RlZCA/DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgV2UgbWF5 IHdhbnQgdG8gcmVtb3ZlICJvciBhY2NlcHQtbGlzdGVkIiBmcm9tDQo+ID4gPiA+IHRoZSBhYm92 ZSBsaW5lLg0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IFtNZWRdIEFjay4NCj4gPiA+DQo+ID4gPiA+ IFtNZWRdIFRoZSBkb3RzIGNsaWVudCB3aWxsIGtub3cgaWYgaXRzIHJlcXVlc3QgaXMgc3VjY2Vz c2Z1bGx5IGRlbGl2ZXJlZC4NCj4gPiA+ID4gV2hlbiBhbiBhdHRhY2sgaXMgb25nb2luZywgdGhl IGRvdHMgY2xpZW50IHNob3VsZCBub3QgdXNlIGl0IGRhdGENCj4gPiA+ID4gY2hhbm5lbCBiZWNh dXNlIGl0IGlzIGxpa2VseSB0byBiZSBwZXJ0dXJiZWQuDQo+ID4gPiA+DQo+ID4gPiA+IENvbW1l bnQ+IElmIHRoZSBIVFRQIHJlc3BvbnNlIGZyb20gdGhlIHNlcnZlciBkaWQgbm90IHJlYWNoIHRo ZQ0KPiA+ID4gPiBDb21tZW50PiBjbGllbnQNCj4gPiA+ID4gYmVjYXVzZSBvZiBhIHZvbHVtZXRy aWMgYXR0YWNrIHNhdHVyYXRpbmcgdGhlIGluY29taW5nIHRoZSBsaW5rLA0KPiA+ID4gPiB0aGUg RE9UUyBjbGllbnQgd2lsbCBub3Qga25vdyB3aGV0aGVyIHRoZSBjb25maWd1cmF0aW9uIGlzDQo+ ID4gPiA+IHN1Y2Nlc3NmdWxseSB1cGRhdGVkIG9yIG5vdC4gQWZ0ZXIgdGhlIGF0dGFjayBpcyBt aXRpZ2F0ZWQsIHRoZQ0KPiA+ID4gPiBjbGllbnQgd2lsbCBoYXZlIHRvIHJlLWVzdGFibGlzaCB0 aGUgVExTIHNlc3Npb24gYW5kIHJldHJpZXZlIHRoZQ0KPiA+ID4gPiBjb25maWd1cmF0aW9uIHRv IGNoZWNrIGlmIGl0cyBsYXN0IHJlcXVlc3Qgd2FzIHN1Y2Nlc3NmdWxseQ0KPiA+ID4gPiBhcHBs aWVkIG9yIG5vdCBiZWZvcmUgdXBkYXRpbmcgdGhlIGNvbmZpZ3VyYXRpb24uDQo+ID4gPiA+DQo+ ID4gPg0KPiA+ID4gW01lZF0gQWdyZWUuIFN0aWxsLCBob3cgdGhlIGNsaWVudCBzeW5jcyBpdHMg Y29uZmlnIHdpdGggdGhlIG9uZQ0KPiA+ID4gbWFpbnRhaW5lZA0KPiA+IGJ5DQo+ID4gPiB0aGUg c2VydmVyIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLiBBIGNsaWVudCBjYW4gc2VuZCBhIEdF VA0KPiA+ID4gYmVmb3JlDQo+ID4gYW5kL29yDQo+ID4gPiBhZnRlciBhIGNvbmZpZ3VyYXRpb24g Y2hhbmdlIHJlcXVlc3QsIGluIHJlZ3VsYXIgaW50ZXJ2YWxzLCBhZnRlcg0KPiA+ID4gYXR0YWNr IG1pdGlnYXRpb24sIGV0Yy4NCj4gPg0KPiA+IEFkZGluZyBhIEltcGxlbWVudGF0aW9uIE5vdGUg bG9va3MgdXNlZnVsIHRvIG1lLg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+ID4NCj4gPiA+ID4g Q2hlZXJzLA0KPiA+ID4gPiAtVGlydQ0K From nobody Thu Feb 28 04:30:17 2019 Return-Path: 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 F22F2130F56; Thu, 28 Feb 2019 04:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cHYDaic5a0oP; Thu, 28 Feb 2019 04:30:11 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA198130F90; Thu, 28 Feb 2019 04:30:09 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 449Bhc0NBJz5wkY; Thu, 28 Feb 2019 13:30:08 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 449Bhb6mVwzDq7g; Thu, 28 Feb 2019 13:30:07 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([fe80::81c9:5f:b9c5:1241%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 13:30:07 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Benjamin Kaduk" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxRIUo475NEhnvke5Q68IH00fwKXgsiOQgAAV9gCAEoE9oIABvKCAgAAWnNCAABl5QA== Date: Thu, 28 Feb 2019 12:30:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA26A2B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA1FEC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA26902@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 12:30:15 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFtt YWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gRW52b3nDqcKgOiBq ZXVkaSAyOCBmw6l2cmllciAyMDE5IDEyOjAwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRH SS9PTE47IEJlbmphbWluIEthZHVrDQo+IENjwqA6IGRvdHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt ZG90cy1kYXRhLWNoYW5uZWxAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUkU6IEFEIHJldmlldyBvZiBk cmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTI1DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSA8bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjgs IDIwMTkgMjo1OSBQTQ0KPiA+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsNCj4gPiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtA bWl0LmVkdT4NCj4gPiBDYzogZG90c0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hh bm5lbEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1k b3RzLWRhdGEtY2hhbm5lbC0yNQ0KPiA+DQo+ID4NCj4gPg0KPiA+IFJlLSwNCj4gPg0KPiA+IEkg YWRkZWQgdGhpcyBub3RlIHRvIG15IGxvY2FsIGNvcHk6DQo+ID4NCj4gPiAgICBIb3cgYSBET1RT IGNsaWVudCBzeW5jaHJvbml6ZXMgaXRzIGNvbmZpZ3VyYXRpb24gd2l0aCB0aGUgb25lDQo+ID4g ICAgbWFpbnRhaW5lZCBieSBpdHMgRE9UUyBzZXJ2ZXIocykgaXMgaW1wbGVtZW50YXRpb24tc3Bl Y2lmaWMuICBGb3INCj4gPiAgICBleGFtcGxlLCBhIERPVFMgY2xpZW50IGNhbiBzZW5kIGEgR0VU IG1lc3NhZ2UgYmVmb3JlIGFuZC9vciBhZnRlciBlYWNoDQo+ID4gICAgY29uZmlndXJhdGlvbiBj aGFuZ2UgcmVxdWVzdC4NCj4gDQo+IFRoZSBleGFtcGxlIGRvZXMgbm90IGxvb2sgY29ycmVjdCwg bm8gbmVlZCB0byBzZW5kIEdFVCBtZXNzYWdlcyB0bw0KPiBzeW5jaHJvbml6ZSB0aGUgY29uZmln dXJhdGlvbiBkdXJpbmcgcGVhY2UgdGltZS4NCg0KW01lZF0gVGhlIGV4YW1wbGUgd2FzIG9uIHB1 cnBvc2UuIFdlIGRvbid0IHNwZWNpZnkgd2hlbiBhbmQgd2h5IGEgY2xpZW50IGhhcyB0byBjaGVj ay4gVGhhdCBpcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4gDQoNCiAgV2UgbmVlZCBhbiBleGFt cGxlIHRvDQo+IGRpc2N1c3MgdGhlIHNjZW5hcmlvIHdoZW4gYXR0YWNrIHRyYWZmaWMgaXMgaW5p dGlhdGVkIGFuZCBjbGllbnQgZGlkIG5vdA0KPiByZWNlaXZlIHJlc3BvbnNlIHRvIHRoZSBjb25m aWd1cmF0aW9uIHJlcXVlc3QgZnJvbSB0aGUgRE9UUyBzZXJ2ZXIuDQo+IEkgcHJvcG9zZSB0aGUg Zm9sbG93aW5nIHVwZGF0ZToNCj4gRm9yIGV4YW1wbGUsIGEgRE9UUyBjbGllbnQgY2FuIHJlLWVz dGFibGlzaCB0aGUgZGlzY29ubmVjdGVkIERPVFMgc2lnbmFsDQo+IGNoYW5uZWwgc2Vzc2lvbiBh ZnRlciB0aGUgYXR0YWNrIGlzIG1pdGlnYXRlZCBhbmQNCj4gc2VuZHMgYSBHRVQgbWVzc2FnZSBi ZWZvcmUgY29uZmlndXJhdGlvbiBjaGFuZ2UgcmVxdWVzdC4NCj4gDQoNCltNZWRdIEkgdXBkYXRl ZCB0aGUgdGV4dCBhcyBmb2xsb3dzICh3ZSBkb24ndCBuZWVkIHRvIGJlIGV4aGF1c3RpdmUpOg0K DQogIEhvdyBhIERPVFMgY2xpZW50IHN5bmNocm9uaXplcyBpdHMgY29uZmlndXJhdGlvbiB3aXRo IHRoZSBvbmUNCiAgIG1haW50YWluZWQgYnkgaXRzIERPVFMgc2VydmVyKHMpIGlzIGltcGxlbWVu dGF0aW9uLXNwZWNpZmljLiAgRm9yDQogICBleGFtcGxlOg0KDQogICBvICBhIERPVFMgY2xpZW50 IGNhbiBzeXN0ZW1hdGljYWxseSBzZW5kIGEgR0VUIG1lc3NhZ2UgYmVmb3JlIGFuZC9vcg0KICAg ICAgYWZ0ZXIgYSBjb25maWd1cmF0aW9uIGNoYW5nZSByZXF1ZXN0Lg0KDQogICBvICBhIERPVFMg Y2xpZW50IGNhbiByZS1lc3RhYmxpc2ggdGhlIGRpc2Nvbm5lY3RlZCBET1RTIHNlc3Npb24gYWZ0 ZXINCiAgICAgIGFuIGF0dGFjayBpcyBtaXRpZ2F0ZWQgYW5kIHNlbmRzIGEgR0VUIG1lc3NhZ2Ug YmVmb3JlIGENCiAgICAgIGNvbmZpZ3VyYXRpb24gY2hhbmdlIHJlcXVlc3QuDQoNCg0KPiBDaGVl cnMsDQo+IC1UaXJ1DQo+IA0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkNCj4gPiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNv bV0NCj4gPiA+IEVudm95w6nCoDogbWVyY3JlZGkgMjcgZsOpdnJpZXIgMjAxOSAwNzo1OSDDgMKg OiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOw0KPiA+ID4gQmVuamFtaW4gS2FkdWsgQ2PCoDog ZG90c0BpZXRmLm9yZzsNCj4gPiA+IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWxAaWV0Zi5v cmcNCj4gPiA+IE9iamV0wqA6IFJFOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLWRhdGEt Y2hhbm5lbC0yNQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+IDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPg0KPiA+ID4gPiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE1LCAy MDE5IDU6NTMgUE0NCj4gPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiA8 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+ID4gPiA+IEJlbmphbWluIEth ZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiA+ID4gPiBDYzogZG90c0BpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1kb3RzLWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSRTogQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4gPiA+ID4NCj4gPiA+ID4g VGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBE byBub3QgY2xpY2sNCj4gPiA+ID4gbGlua3MNCj4gPiA+IG9yDQo+ID4gPiA+IG9wZW4gYXR0YWNo bWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUNCj4gPiA+ ID4gY29udGVudCBpcw0KPiA+ID4gc2FmZS4NCj4gPiA+ID4NCj4gPiA+ID4gSGkgVGlydSwNCj4g PiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPiA+DQo+ID4gPiA+IENoZWVy cywNCj4gPiA+ID4gTWVkDQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+ID4gPiA+ID4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4g PiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gPiA+ID4g PiBFbnZvecOpwqA6IHZlbmRyZWRpIDE1IGbDqXZyaWVyIDIwMTkgMTI6MDYgw4DCoDogQk9VQ0FE QUlSIE1vaGFtZWQNCj4gPiA+ID4gPiBUR0kvT0xOOyBCZW5qYW1pbiBLYWR1ayBDY8KgOiBkb3Rz QGlldGYub3JnOw0KPiA+ID4gPiA+IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWxAaWV0Zi5v cmcNCj4gPiA+ID4gPiBPYmpldMKgOiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1k YXRhLWNoYW5uZWwtMjUNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgYW0gY2F0Y2hpbmcgdXAgd2l0 aCB0aGUgZGlzY3Vzc2lvbiwgY291cGxlIG9mIHBvaW50czoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IDEpDQo+ID4gPiA+ID4gICAgICAgKiAgSWYgYSBuZXR3b3JrIHJlc291cmNlIChET1RTIGNsaWVu dCkgZGV0ZWN0cyBhIHBvdGVudGlhbCBERG9TDQo+ID4gPiA+ID4gICAgICAgICAgYXR0YWNrIGZy b20gYSBzZXQgb2YgSVAgYWRkcmVzc2VzLCB0aGUgRE9UUyBjbGllbnQgaW5mb3Jtcw0KPiBpdHMN Cj4gPiA+ID4gPiAgICAgICAgICBzZXJ2aWNpbmcgRE9UUyBnYXRld2F5IG9mIGFsbCBzdXNwZWN0 IElQIGFkZHJlc3NlcyB0aGF0IG5lZWQNCj4gdG8NCj4gPiA+ID4gPiAgICAgICAgICBiZSBkcm9w LSBvciBhY2NlcHQtbGlzdGVkIGZvciBmdXJ0aGVyIGludmVzdGlnYXRpb24uDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBDb21tZW50PiBJIGRvbid0IHNlZSB3aHkgc3VzcGVjdCBJUCBhZGRyZXNzZXMg d2lsbCBiZSBhY2NlcHQtbGlzdGVkID8NCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIFdl IG1heSB3YW50IHRvIHJlbW92ZSAib3IgYWNjZXB0LWxpc3RlZCIgZnJvbQ0KPiA+ID4gPiA+IHRo ZSBhYm92ZSBsaW5lLg0KPiA+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IFtNZWRdIEFjay4NCj4g PiA+ID4NCj4gPiA+ID4gPiBbTWVkXSBUaGUgZG90cyBjbGllbnQgd2lsbCBrbm93IGlmIGl0cyBy ZXF1ZXN0IGlzIHN1Y2Nlc3NmdWxseQ0KPiBkZWxpdmVyZWQuDQo+ID4gPiA+ID4gV2hlbiBhbiBh dHRhY2sgaXMgb25nb2luZywgdGhlIGRvdHMgY2xpZW50IHNob3VsZCBub3QgdXNlIGl0IGRhdGEN Cj4gPiA+ID4gPiBjaGFubmVsIGJlY2F1c2UgaXQgaXMgbGlrZWx5IHRvIGJlIHBlcnR1cmJlZC4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IENvbW1lbnQ+IElmIHRoZSBIVFRQIHJlc3BvbnNlIGZyb20g dGhlIHNlcnZlciBkaWQgbm90IHJlYWNoIHRoZQ0KPiA+ID4gPiA+IENvbW1lbnQ+IGNsaWVudA0K PiA+ID4gPiA+IGJlY2F1c2Ugb2YgYSB2b2x1bWV0cmljIGF0dGFjayBzYXR1cmF0aW5nIHRoZSBp bmNvbWluZyB0aGUgbGluaywNCj4gPiA+ID4gPiB0aGUgRE9UUyBjbGllbnQgd2lsbCBub3Qga25v dyB3aGV0aGVyIHRoZSBjb25maWd1cmF0aW9uIGlzDQo+ID4gPiA+ID4gc3VjY2Vzc2Z1bGx5IHVw ZGF0ZWQgb3Igbm90LiBBZnRlciB0aGUgYXR0YWNrIGlzIG1pdGlnYXRlZCwgdGhlDQo+ID4gPiA+ ID4gY2xpZW50IHdpbGwgaGF2ZSB0byByZS1lc3RhYmxpc2ggdGhlIFRMUyBzZXNzaW9uIGFuZCBy ZXRyaWV2ZSB0aGUNCj4gPiA+ID4gPiBjb25maWd1cmF0aW9uIHRvIGNoZWNrIGlmIGl0cyBsYXN0 IHJlcXVlc3Qgd2FzIHN1Y2Nlc3NmdWxseQ0KPiA+ID4gPiA+IGFwcGxpZWQgb3Igbm90IGJlZm9y ZSB1cGRhdGluZyB0aGUgY29uZmlndXJhdGlvbi4NCj4gPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4g PiBbTWVkXSBBZ3JlZS4gU3RpbGwsIGhvdyB0aGUgY2xpZW50IHN5bmNzIGl0cyBjb25maWcgd2l0 aCB0aGUgb25lDQo+ID4gPiA+IG1haW50YWluZWQNCj4gPiA+IGJ5DQo+ID4gPiA+IHRoZSBzZXJ2 ZXIgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMuIEEgY2xpZW50IGNhbiBzZW5kIGEgR0VUDQo+ ID4gPiA+IGJlZm9yZQ0KPiA+ID4gYW5kL29yDQo+ID4gPiA+IGFmdGVyIGEgY29uZmlndXJhdGlv biBjaGFuZ2UgcmVxdWVzdCwgaW4gcmVndWxhciBpbnRlcnZhbHMsIGFmdGVyDQo+ID4gPiA+IGF0 dGFjayBtaXRpZ2F0aW9uLCBldGMuDQo+ID4gPg0KPiA+ID4gQWRkaW5nIGEgSW1wbGVtZW50YXRp b24gTm90ZSBsb29rcyB1c2VmdWwgdG8gbWUuDQo+ID4gPg0KPiA+ID4gLVRpcnUNCj4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+IC1UaXJ1DQo= From nobody Thu Feb 28 04:32:18 2019 Return-Path: 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 0EA50129741; Thu, 28 Feb 2019 04:32:17 -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 0iG5taNz5jeZ; Thu, 28 Feb 2019 04:32:14 -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 7687C124D68; Thu, 28 Feb 2019 04:32:14 -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=1551356977; 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=VRATLVciBMEilhc39L3KU9IFaA+krE1SkEf+zG /Nb98=; b=lkoH7V6tpbaoKTyfdyJZWwfWym9pyaPnWZE/uBhs XNhKd6715u/wfV2f50kE4vJkn6iEnTUkRQMkVc2hayP+9QVvxC MdenebBPDcRUQSY08uzdbGEK2a2sJDwL3Fp4yO6m24002z5rRn bQ2hGKlU5ZYa+OZi7L6geFQ08dl0doo= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 21ae_081f_17e07d63_5483_4206_85e7_bee8b9fc20b0; Thu, 28 Feb 2019 05:29:36 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 05:31:50 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 28 Feb 2019 05:31:50 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 05:31:49 -0700 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2952.namprd16.prod.outlook.com (20.178.235.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Thu, 28 Feb 2019 12:31:49 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 12:31:49 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Benjamin Kaduk" CC: "dots@ietf.org" , "draft-ietf-dots-data-channel@ietf.org" Thread-Topic: AD review of draft-ietf-dots-data-channel-25 Thread-Index: AQHUxRIUo475NEhnvke5Q68IH00fwKXgsiOQgAAV9gCAEoE9oIABvKCAgAAWnNCAABl5QIAAAtbg Date: Thu, 28 Feb 2019 12:31:48 +0000 Message-ID: References: <20190213164622.GX56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1F03D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190214191707.GM56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA1FCF6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA1FEC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA26902@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA26A2B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA26A2B@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.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: 1f21c0ab-d7ad-4041-9d15-08d69d78b5d5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2952; x-ms-traffictypediagnostic: BYAPR16MB2952: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE2TUIyOTUyOzIzOllwR0xRVzJIdjNTSm4yS3pTaWVTMXVqOEs4?= =?utf-8?B?NnFyUG1QVEtGaC9WSzByMXNZckZ6MzBVd1I0SUsrb3JwMVJyTVZlMEZSMWlj?= =?utf-8?B?WEZZb2ZlR01SOFB1U1NlOEVmSHpuOFBBamtRTU1YMklwUW92OXVXS2ZqWTZU?= =?utf-8?B?N0svVkxZQUMyd3dGbjRoUlF3NWFYL1NpVE5OM3FlaWwzWVo3TDErempiSVRB?= =?utf-8?B?MXVtTjFQdGZzdXR6cUhBdTY4M29jUjFjVjl4bmZ1b09SSUZmQ1hWa1ZNYjlS?= =?utf-8?B?RzBZcUI4ZTE4MFY0SzQ0SFBLU3krbDY1V1Z0RTFXZ0NXMDkwaW5VYkdWNkcr?= =?utf-8?B?dkhjWDREUExyejRGa3ZjNUdSOU9rN0F0TCs5d1hla2xwQitxNUowWVk0aFRN?= =?utf-8?B?RGY1UlRvbFhld3RnRFZQMHZVNVRJSnNlS3AvQklKTDV1MGorU2lPNU8vZUpQ?= =?utf-8?B?dVhueS9CMVI5TFdzY2pZVjl5L2tQOVpmRVlQcEREMURObm9Bdm9kVVFsUE5m?= =?utf-8?B?YzBic1dtS3Y0S1BCNWh3akx3bnBIN1QyekVtKzFUZ2FWbFlkYXFGMzVTZDJ1?= =?utf-8?B?Qzd3NW52NSt5dGUxQzFwRFRGNnA5RUNzMWZSUmVOeWp4TGRwWGJ4Y0hTTENW?= =?utf-8?B?SXlHV0d0aDhXYm9UeWFWUk9xRmdJaFpwOCtsanRaZm8ybHR0NGpqM2hKcExk?= =?utf-8?B?SUluTFlYV0hkV2NDMVk0TVZRVVhqald0Umt4RTEzcS9yZDVsdGlZeU5kVnRy?= =?utf-8?B?UUsrT1c0QlBiZHFJVEpyRmJGSVcveldtaGkydktaOU9COUFwQU1JTlFjNXpF?= =?utf-8?B?cmRqOG1yNXpHNWJYOHg5enFrUlYwcGYzM3hkUnRMNEV2SE84R3pRMnRoWm0r?= =?utf-8?B?QW5uV2plNXdXZnIxUGt3L0xrQVkzeW5iTUJSZTJJV0FmY0hxMnZDc1A1SENW?= =?utf-8?B?NzNmZTY5ZlNJTmhCRGxRZWJFbTdVa3hKREJndklicmNkOCtBNjlqMHd5dnRX?= =?utf-8?B?ZlBtTUp4Mk15MGpBeGRmeVVxTVdNdjFvTlV4N0JvOGp4M0NnUnY2bEoxdENK?= =?utf-8?B?YnNmdGJzSGYrRGdOMXFuQmlmdDFBcmkyTjVmSTdzWnljd3hsVWQvM2VKdzlz?= =?utf-8?B?Yk9tNERiTWFwbjZ2NnB0MDdjVU56d05FUisvU0M1cW92b3JINlMrV2I4eC8z?= =?utf-8?B?VVQ5a2xDVEE1UzdMWEU3RElic2NOTnBxNEw0cWhMRWZzVzBMOEVxV3FNNzR2?= =?utf-8?B?RDBzSzFsbXdxbFBNbXlqUUlDbm5nckdZWWs0a1ZWOTZpeGE3TFBFZGxzTmY3?= =?utf-8?B?K2JsWC9UVm5IKzdac1lGbHV1WXd4ZzRybEVLNG1wWENIbXlVVHczTFFDS2tW?= =?utf-8?B?RXdZU1kyZFRuTEgwSTMrVGFHdC9uckorblVXckVNT1VnaXQzSk9VZkY5WjdD?= =?utf-8?B?VURnN3YxTXQ1OWR5N0l2Tk10emVXRFFjMnBMKzJSQVJOZTNvd1BoUU50Q0dT?= =?utf-8?B?OTM4ZHZMV0NJWloyV1BWSFdBN2E2RGRYTlBKR280VGd2OHVrZzk1elkxbWFv?= =?utf-8?B?Z2lxNkQ4Z0p1RVM4U0h4Y1UyeWd3SGsweXQ5SWM5enZMaWRVNHFFTnN5bitl?= =?utf-8?B?dWZwK01UWUprU0xTMmV1TFBjaHhuQlFaOU95OXE3cTZVTVNjODNPS1BtNVAw?= =?utf-8?B?bSszTVBtL0tjaWplSWtPMEdkOFVOUHBkTEpHVC8wUXgzL21mUkl4VS92Y3o4?= =?utf-8?B?d2F0UEEzUHV3RVR2c1ZnYmc5RUpLVWNKLzF4MlJTcFJYNFVoSlBCNW1PUW5F?= =?utf-8?B?NzJ5Y3RvbjAwbG5Ya0kvWTFtZFNnRHF2TGtGQVZZc1hFR2hyaUh3QzUxSU5V?= =?utf-8?B?U0V6Y29UVjhSQ1UrUGZyMjA3QmZyY3AzOUJ5WStOaFVKSGF3RjJ0c1hNaTdD?= =?utf-8?B?Zy9rMkdYQ3BmNUF3ZHpmK0hoWWhVTmlBU05IREJ1UFcrUmVBdDNieVBiMHMy?= =?utf-8?Q?5b5Md0?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(396003)(39860400002)(32952001)(13464003)(199004)(189003)(97736004)(80792005)(2501003)(72206003)(5660300002)(478600001)(25786009)(186003)(8936002)(33656002)(66574012)(68736007)(5024004)(14444005)(14454004)(256004)(66066001)(229853002)(26005)(2171002)(6246003)(106356001)(99286004)(71200400001)(71190400001)(8676002)(3846002)(53936002)(7736002)(6436002)(105586002)(316002)(76176011)(7696005)(6506007)(4326008)(81156014)(102836004)(52536013)(81166006)(53546011)(110136005)(9686003)(55016002)(446003)(11346002)(476003)(2906002)(86362001)(54906003)(486006)(6116002)(305945005)(74316002)(93886005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2952; H:BYAPR16MB2790.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: p4+/TmZkf03lw4UGPzWdZdSkWH06yQaP9QyFOsMgN5ODJS01etk242vuA9SZNFjXlbkgoEN1zzkZfuZDmmWkIygAx6cLRXgj/6Q6H+Lc5t2WhOUSNbwc7pTB0KKu+3Buy7IzxHZfx2lpMNnOo9QmQAZ8Zlw3Bpjg9xVrfsqkCXfEhncKTpHlBHZS0q/K8ZswiV9lBxW8gWf/vFy4yeX91vZMiJzPLU15CuhloKcT8PJCwLmJUb3Q/iWSzx3shADrOYBVDGHJlOE0KAm47kod3Rliacgyb7nZbSMiRHf5Q2NU8kh8odtIevnyHr2RW8h5Vr1WX8+3d4aB8r4rkTeBHrCiP21Ood4OnDjXchbL/cogkexF+SzVho6h1U9PGg5EjFiaq+AngOO/D6gJF4lgVwa0kw7MU41c4wikTUnNDWg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1f21c0ab-d7ad-4041-9d15-08d69d78b5d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 12:31:49.0194 (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: BYAPR16MB2952 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7025> : streams <1814345> : uri <2803685> Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-data-channel-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 12:32:17 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMjgsIDIwMTkgNjowMCBQTQ0KPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47DQo+IEJlbmphbWluIEth ZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiBDYzogZG90c0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kb3Rz LWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4gDQo+IA0KPiANCj4gUmUtLA0KPiANCj4gUGxl YXNlIHNlZSBpbmxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ ID4gW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+IEVudm95 w6nCoDogamV1ZGkgMjggZsOpdnJpZXIgMjAxOSAxMjowMA0KPiA+IMOAwqA6IEJPVUNBREFJUiBN b2hhbWVkIFRHSS9PTE47IEJlbmphbWluIEthZHVrIENjwqA6IGRvdHNAaWV0Zi5vcmc7DQo+ID4g ZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbEBpZXRmLm9yZw0KPiA+IE9iamV0wqA6IFJFOiBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0yNQ0KPiA+DQo+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbQ0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPiA+IFNlbnQ6 IFRodXJzZGF5LCBGZWJydWFyeSAyOCwgMjAxOSAyOjU5IFBNDQo+ID4gPiBUbzogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeQ0KPiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47 DQo+ID4gPiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4NCj4gPiA+IENjOiBkb3RzQGll dGYub3JnOyBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsQGlldGYub3JnDQo+ID4gPiBTdWJq ZWN0OiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4g PiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFJlLSwNCj4gPiA+DQo+ID4gPiBJIGFkZGVkIHRoaXMg bm90ZSB0byBteSBsb2NhbCBjb3B5Og0KPiA+ID4NCj4gPiA+ICAgIEhvdyBhIERPVFMgY2xpZW50 IHN5bmNocm9uaXplcyBpdHMgY29uZmlndXJhdGlvbiB3aXRoIHRoZSBvbmUNCj4gPiA+ICAgIG1h aW50YWluZWQgYnkgaXRzIERPVFMgc2VydmVyKHMpIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmlj LiAgRm9yDQo+ID4gPiAgICBleGFtcGxlLCBhIERPVFMgY2xpZW50IGNhbiBzZW5kIGEgR0VUIG1l c3NhZ2UgYmVmb3JlIGFuZC9vciBhZnRlciBlYWNoDQo+ID4gPiAgICBjb25maWd1cmF0aW9uIGNo YW5nZSByZXF1ZXN0Lg0KPiA+DQo+ID4gVGhlIGV4YW1wbGUgZG9lcyBub3QgbG9vayBjb3JyZWN0 LCBubyBuZWVkIHRvIHNlbmQgR0VUIG1lc3NhZ2VzIHRvDQo+ID4gc3luY2hyb25pemUgdGhlIGNv bmZpZ3VyYXRpb24gZHVyaW5nIHBlYWNlIHRpbWUuDQo+IA0KPiBbTWVkXSBUaGUgZXhhbXBsZSB3 YXMgb24gcHVycG9zZS4gV2UgZG9uJ3Qgc3BlY2lmeSB3aGVuIGFuZCB3aHkgYSBjbGllbnQNCj4g aGFzIHRvIGNoZWNrLiBUaGF0IGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLg0KPiANCj4gICBX ZSBuZWVkIGFuIGV4YW1wbGUgdG8NCj4gPiBkaXNjdXNzIHRoZSBzY2VuYXJpbyB3aGVuIGF0dGFj ayB0cmFmZmljIGlzIGluaXRpYXRlZCBhbmQgY2xpZW50IGRpZA0KPiA+IG5vdCByZWNlaXZlIHJl c3BvbnNlIHRvIHRoZSBjb25maWd1cmF0aW9uIHJlcXVlc3QgZnJvbSB0aGUgRE9UUyBzZXJ2ZXIu DQo+ID4gSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdXBkYXRlOg0KPiA+IEZvciBleGFtcGxlLCBh IERPVFMgY2xpZW50IGNhbiByZS1lc3RhYmxpc2ggdGhlIGRpc2Nvbm5lY3RlZCBET1RTDQo+ID4g c2lnbmFsIGNoYW5uZWwgc2Vzc2lvbiBhZnRlciB0aGUgYXR0YWNrIGlzIG1pdGlnYXRlZCBhbmQg c2VuZHMgYSBHRVQNCj4gPiBtZXNzYWdlIGJlZm9yZSBjb25maWd1cmF0aW9uIGNoYW5nZSByZXF1 ZXN0Lg0KPiA+DQo+IA0KPiBbTWVkXSBJIHVwZGF0ZWQgdGhlIHRleHQgYXMgZm9sbG93cyAod2Ug ZG9uJ3QgbmVlZCB0byBiZSBleGhhdXN0aXZlKToNCj4gDQo+ICAgSG93IGEgRE9UUyBjbGllbnQg c3luY2hyb25pemVzIGl0cyBjb25maWd1cmF0aW9uIHdpdGggdGhlIG9uZQ0KPiAgICBtYWludGFp bmVkIGJ5IGl0cyBET1RTIHNlcnZlcihzKSBpcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4gIEZv cg0KPiAgICBleGFtcGxlOg0KPiANCj4gICAgbyAgYSBET1RTIGNsaWVudCBjYW4gc3lzdGVtYXRp Y2FsbHkgc2VuZCBhIEdFVCBtZXNzYWdlIGJlZm9yZSBhbmQvb3INCj4gICAgICAgYWZ0ZXIgYSBj b25maWd1cmF0aW9uIGNoYW5nZSByZXF1ZXN0Lg0KPiANCj4gICAgbyAgYSBET1RTIGNsaWVudCBj YW4gcmUtZXN0YWJsaXNoIHRoZSBkaXNjb25uZWN0ZWQgRE9UUyBzZXNzaW9uIGFmdGVyDQo+ICAg ICAgIGFuIGF0dGFjayBpcyBtaXRpZ2F0ZWQgYW5kIHNlbmRzIGEgR0VUIG1lc3NhZ2UgYmVmb3Jl IGENCj4gICAgICAgY29uZmlndXJhdGlvbiBjaGFuZ2UgcmVxdWVzdC4NCg0KVGhhbmtzLCB1cGRh dGUgbG9va3MgZ29vZC4NCg0KLVRpcnUNCg0KPiANCj4gDQo+ID4gQ2hlZXJzLA0KPiA+IC1UaXJ1 DQo+ID4NCj4gPiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiBNZWQNCj4gPiA+DQo+ID4gPiA+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVz d2FyIFJlZGR5DQo+ID4gPiA+IFttYWlsdG86VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVl LmNvbV0NCj4gPiA+ID4gRW52b3nDqcKgOiBtZXJjcmVkaSAyNyBmw6l2cmllciAyMDE5IDA3OjU5 IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkDQo+ID4gPiA+IFRHSS9PTE47IEJlbmphbWluIEthZHVr IENjwqA6IGRvdHNAaWV0Zi5vcmc7DQo+ID4gPiA+IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5u ZWxAaWV0Zi5vcmcNCj4gPiA+ID4gT2JqZXTCoDogUkU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRm LWRvdHMtZGF0YS1jaGFubmVsLTI1DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t DQo+ID4gPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPiA+ID4gPiBTZW50OiBG cmlkYXksIEZlYnJ1YXJ5IDE1LCAyMDE5IDU6NTMgUE0NCj4gPiA+ID4gPiBUbzogS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5j b20+Ow0KPiA+ID4gPiA+IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiA+ID4gPiA+ IENjOiBkb3RzQGlldGYub3JnOyBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsQGlldGYub3Jn DQo+ID4gPiA+ID4gU3ViamVjdDogUkU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtZGF0 YS1jaGFubmVsLTI1DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQg ZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdA0KPiA+ID4gPiA+IGNsaWNr IGxpbmtzDQo+ID4gPiA+IG9yDQo+ID4gPiA+ID4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91 IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZQ0KPiA+ID4gPiA+IGNvbnRlbnQgaXMN Cj4gPiA+ID4gc2FmZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpIFRpcnUsDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IENoZWVy cywNCj4gPiA+ID4gPiBNZWQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4gPiA+ID4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5 DQo+ID4gPiA+ID4gPiBbbWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21d DQo+ID4gPiA+ID4gPiBFbnZvecOpwqA6IHZlbmRyZWRpIDE1IGbDqXZyaWVyIDIwMTkgMTI6MDYg w4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQNCj4gPiA+ID4gPiA+IFRHSS9PTE47IEJlbmphbWluIEth ZHVrIENjwqA6IGRvdHNAaWV0Zi5vcmc7DQo+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLWRvdHMtZGF0 YS1jaGFubmVsQGlldGYub3JnDQo+ID4gPiA+ID4gPiBPYmpldMKgOiBSRTogQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMjUNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiBJIGFtIGNhdGNoaW5nIHVwIHdpdGggdGhlIGRpc2N1c3Npb24sIGNvdXBsZSBvZiBwb2ludHM6 DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gMSkNCj4gPiA+ID4gPiA+ICAgICAgICogIElmIGEg bmV0d29yayByZXNvdXJjZSAoRE9UUyBjbGllbnQpIGRldGVjdHMgYSBwb3RlbnRpYWwgRERvUw0K PiA+ID4gPiA+ID4gICAgICAgICAgYXR0YWNrIGZyb20gYSBzZXQgb2YgSVAgYWRkcmVzc2VzLCB0 aGUgRE9UUyBjbGllbnQNCj4gPiA+ID4gPiA+IGluZm9ybXMNCj4gPiBpdHMNCj4gPiA+ID4gPiA+ ICAgICAgICAgIHNlcnZpY2luZyBET1RTIGdhdGV3YXkgb2YgYWxsIHN1c3BlY3QgSVAgYWRkcmVz c2VzDQo+ID4gPiA+ID4gPiB0aGF0IG5lZWQNCj4gPiB0bw0KPiA+ID4gPiA+ID4gICAgICAgICAg YmUgZHJvcC0gb3IgYWNjZXB0LWxpc3RlZCBmb3IgZnVydGhlciBpbnZlc3RpZ2F0aW9uLg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IENvbW1lbnQ+IEkgZG9uJ3Qgc2VlIHdoeSBzdXNwZWN0IElQ IGFkZHJlc3NlcyB3aWxsIGJlIGFjY2VwdC1saXN0ZWQgPw0KPiA+ID4gPiA+ID4gICAgICAgICAg ICAgICAgICAgICBXZSBtYXkgd2FudCB0byByZW1vdmUgIm9yIGFjY2VwdC1saXN0ZWQiDQo+ID4g PiA+ID4gPiBmcm9tIHRoZSBhYm92ZSBsaW5lLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IFtNZWRdIEFjay4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gW01lZF0gVGhlIGRvdHMg Y2xpZW50IHdpbGwga25vdyBpZiBpdHMgcmVxdWVzdCBpcyBzdWNjZXNzZnVsbHkNCj4gPiBkZWxp dmVyZWQuDQo+ID4gPiA+ID4gPiBXaGVuIGFuIGF0dGFjayBpcyBvbmdvaW5nLCB0aGUgZG90cyBj bGllbnQgc2hvdWxkIG5vdCB1c2UgaXQNCj4gPiA+ID4gPiA+IGRhdGEgY2hhbm5lbCBiZWNhdXNl IGl0IGlzIGxpa2VseSB0byBiZSBwZXJ0dXJiZWQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g Q29tbWVudD4gSWYgdGhlIEhUVFAgcmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyIGRpZCBub3QgcmVh Y2gNCj4gPiA+ID4gPiA+IENvbW1lbnQ+IHRoZSBjbGllbnQNCj4gPiA+ID4gPiA+IGJlY2F1c2Ug b2YgYSB2b2x1bWV0cmljIGF0dGFjayBzYXR1cmF0aW5nIHRoZSBpbmNvbWluZyB0aGUNCj4gPiA+ ID4gPiA+IGxpbmssIHRoZSBET1RTIGNsaWVudCB3aWxsIG5vdCBrbm93IHdoZXRoZXIgdGhlIGNv bmZpZ3VyYXRpb24NCj4gPiA+ID4gPiA+IGlzIHN1Y2Nlc3NmdWxseSB1cGRhdGVkIG9yIG5vdC4g QWZ0ZXIgdGhlIGF0dGFjayBpcyBtaXRpZ2F0ZWQsDQo+ID4gPiA+ID4gPiB0aGUgY2xpZW50IHdp bGwgaGF2ZSB0byByZS1lc3RhYmxpc2ggdGhlIFRMUyBzZXNzaW9uIGFuZA0KPiA+ID4gPiA+ID4g cmV0cmlldmUgdGhlIGNvbmZpZ3VyYXRpb24gdG8gY2hlY2sgaWYgaXRzIGxhc3QgcmVxdWVzdCB3 YXMNCj4gPiA+ID4gPiA+IHN1Y2Nlc3NmdWxseSBhcHBsaWVkIG9yIG5vdCBiZWZvcmUgdXBkYXRp bmcgdGhlIGNvbmZpZ3VyYXRpb24uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g W01lZF0gQWdyZWUuIFN0aWxsLCBob3cgdGhlIGNsaWVudCBzeW5jcyBpdHMgY29uZmlnIHdpdGgg dGhlIG9uZQ0KPiA+ID4gPiA+IG1haW50YWluZWQNCj4gPiA+ID4gYnkNCj4gPiA+ID4gPiB0aGUg c2VydmVyIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLiBBIGNsaWVudCBjYW4gc2VuZCBhIEdF VA0KPiA+ID4gPiA+IGJlZm9yZQ0KPiA+ID4gPiBhbmQvb3INCj4gPiA+ID4gPiBhZnRlciBhIGNv bmZpZ3VyYXRpb24gY2hhbmdlIHJlcXVlc3QsIGluIHJlZ3VsYXIgaW50ZXJ2YWxzLA0KPiA+ID4g PiA+IGFmdGVyIGF0dGFjayBtaXRpZ2F0aW9uLCBldGMuDQo+ID4gPiA+DQo+ID4gPiA+IEFkZGlu ZyBhIEltcGxlbWVudGF0aW9uIE5vdGUgbG9va3MgdXNlZnVsIHRvIG1lLg0KPiA+ID4gPg0KPiA+ ID4gPiAtVGlydQ0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBDaGVlcnMsDQo+ID4g PiA+ID4gPiAtVGlydQ0K From nobody Thu Feb 28 05:09:02 2019 Return-Path: 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 34B50129741; Thu, 28 Feb 2019 05:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zS_WZ93uxB88; Thu, 28 Feb 2019 05:08:59 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A5812894E; Thu, 28 Feb 2019 05:08:59 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 449CYP2NvkzCrP2; Thu, 28 Feb 2019 14:08:57 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 449CYP1Bkjz1xpS; Thu, 28 Feb 2019 14:08:57 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([fe80::54f9:a664:e400:452a%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 14:08:57 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Benjamin Kaduk" CC: "draft-ietf-dots-signal-channel@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) Thread-Index: AQHUzz5BCXFDawydokCSl6Px8wMDQaX1B8jwgAAmWzA= Date: Thu, 28 Feb 2019 13:08:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA26AD5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227155729.GL53396@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA2680B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 13:09:01 -0000 UmUtLA0KDQpJIHJlYXJyYW5nZWQgdGhlIHRleHQgYXMgZm9sbG93czogDQoNCk9MRDogDQogICAg ICBTZWN0aW9uIDggb2YgW1JGQzg0NDZdIGRpc2N1c3NlcyBzb21lIG1lY2hhbmlzbXMgdG8gaW1w bGVtZW50IHRvDQogICAgICBsaW1pdCB0aGUgaW1wYWN0IG9mIHJlcGxheSBhdHRhY2tzIG9uIDAt UlRUIGRhdGEuICBJZiB0aGUgRE9UUw0KICAgICAgc2VydmVyIGFjY2VwdHMgMC1SVFQsIGl0IE1V U1QgaW1wbGVtZW50IG9uZSBvZiB0aGVzZSBtZWNoYW5pc21zLg0KICAgICAgQSBET1RTIHNlcnZl ciBjYW4gcmVqZWN0IDAtUlRUIGJ5IHNlbmRpbmcgYSBUTFMgSGVsbG9SZXRyeVJlcXVlc3QuDQog ICAgICBUaGUgRE9UUyBzaWduYWwgY2hhbm5lbCBtZXNzYWdlcyBzZW50IGFzIGVhcmx5IGRhdGEg YnkgdGhlIERPVFMNCiAgICAgIGNsaWVudCBhcmUgaWRlbXBvdGVudCByZXF1ZXN0cy4gIEFzIGEg cmVtaW5kZXIsIE1lc3NhZ2UgSUQNCiAgICAgIChTZWN0aW9uIDMgb2YgW1JGQzcyNTJdKSBpcyBj aGFuZ2VkIGVhY2ggdGltZSBhIG5ldyBDb0FQIHJlcXVlc3QNCiAgICAgIGlzIHNlbnQsIGFuZCB0 aGUgVG9rZW4gKFNlY3Rpb24gNS4zLjEgb2YgW1JGQzcyNTJdKSBpcyByYW5kb21pemVkDQogICAg ICBpbiBlYWNoIENvQVAgcmVxdWVzdC4gIFRoZSBET1RTIHNlcnZlcihzKSBjYW4gdXNlIE1lc3Nh Z2UgSUQgYW5kDQogICAgICBUb2tlbiBpbiB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBtZXNzYWdl IHRvIGRldGVjdCByZXBsYXkgb2YgZWFybHkNCiAgICAgIGRhdGEsIGFuZCBhY2NlcHQgMC1SVFQg ZGF0YSBhdCBtb3N0IG9uY2UuICBGdXJ0aGVybW9yZSwgJ21pZCcNCiAgICAgIHZhbHVlIGlzIG1v bm90b25pY2FsbHkgaW5jcmVhc2VkIGJ5IHRoZSBET1RTIGNsaWVudCBmb3IgZWFjaA0KICAgICAg bWl0aWdhdGlvbiByZXF1ZXN0LCBhdHRhY2tlcnMgcmVwbGF5aW5nIG1pdGlnYXRpb24gcmVxdWVz dHMgd2l0aA0KICAgICAgbG93ZXIgbnVtZXJpYyAnbWlkJyB2YWx1ZXMgYW5kIG92ZXJsYXBwaW5n IHNjb3BlcyB3aXRoIG1pdGlnYXRpb24NCiAgICAgIHJlcXVlc3RzIGhhdmluZyBoaWdoZXIgbnVt ZXJpYyAnbWlkJyB2YWx1ZXMgd2lsbCBiZSByZWplY3RlZA0KICAgICAgc3lzdGVtYXRpY2FsbHkg YnkgdGhlIERPVFMgc2VydmVyLiAgTGlrZXdpc2UsICdzaWQnIHZhbHVlIGlzDQogICAgICBtb25v dG9uaWNhbGx5IGluY3JlYXNlZCBieSB0aGUgRE9UUyBjbGllbnQgZm9yIGVhY2ggY29uZmlndXJh dGlvbg0KICAgICAgc2Vzc2lvbiwgYXR0YWNrZXJzIHJlcGxheWluZyBjb25maWd1cmF0aW9uIHJl cXVlc3RzIHdpdGggbG93ZXINCiAgICAgIG51bWVyaWMgJ3NpZCcgdmFsdWVzIHdpbGwgYmUgcmVq ZWN0ZWQgYnkgdGhlIERPVFMgc2VydmVyIGlmIGl0DQogICAgICBtYWludGFpbnMgYSBoaWdoZXIg bnVtZXJpYyAnc2lkJyB2YWx1ZSBmb3IgdGhpcyBET1RTIGNsaWVudC4NCg0KTkVXOg0KICAgICAg U2VjdGlvbiA4IG9mIFtSRkM4NDQ2XSBkaXNjdXNzZXMgc29tZSBtZWNoYW5pc21zIHRvIGltcGxl bWVudCB0bw0KICAgICAgbGltaXQgdGhlIGltcGFjdCBvZiByZXBsYXkgYXR0YWNrcyBvbiAwLVJU VCBkYXRhLiAgSWYgdGhlIERPVFMNCiAgICAgIHNlcnZlciBhY2NlcHRzIDAtUlRULCBpdCBNVVNU IGltcGxlbWVudCBvbmUgb2YgdGhlc2UgbWVjaGFuaXNtcyB0bw0KICAgICAgcHJldmVudCByZXBs YXkgYXQgdGhlIFRMUyBsYXllci4gIEEgRE9UUyBzZXJ2ZXIgY2FuIHJlamVjdCAwLVJUVA0KICAg ICAgYnkgc2VuZGluZyBhIFRMUyBIZWxsb1JldHJ5UmVxdWVzdC4NCg0KICAgICAgVGhlIERPVFMg c2lnbmFsIGNoYW5uZWwgbWVzc2FnZXMgc2VudCBhcyBlYXJseSBkYXRhIGJ5IHRoZSBET1RTDQog ICAgICBjbGllbnQgYXJlIGlkZW1wb3RlbnQgcmVxdWVzdHMuICBBcyBhIHJlbWluZGVyLCB0aGUg TWVzc2FnZSBJRA0KICAgICAgKFNlY3Rpb24gMyBvZiBbUkZDNzI1Ml0pIGlzIGNoYW5nZWQgZWFj aCB0aW1lIGEgbmV3IENvQVAgcmVxdWVzdA0KICAgICAgaXMgc2VudCwgYW5kIHRoZSBUb2tlbiAo U2VjdGlvbiA1LjMuMSBvZiBbUkZDNzI1Ml0pIGlzIHJhbmRvbWl6ZWQNCiAgICAgIGluIGVhY2gg Q29BUCByZXF1ZXN0LiAgVGhlIERPVFMgc2VydmVyKHMpIE1VU1QgdXNlIHRoZSBNZXNzYWdlIElE DQogICAgICBhbmQgdGhlIFRva2VuIGluIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIG1lc3NhZ2Ug dG8gZGV0ZWN0IHJlcGxheQ0KICAgICAgb2YgZWFybHkgZGF0YSBhdCB0aGUgYXBwbGljYXRpb24g bGF5ZXIsIGFuZCBhY2NlcHQgMC1SVFQgZGF0YSBhdA0KICAgICAgbW9zdCBvbmNlIGZyb20gdGhl IHNhbWUgRE9UUyBjbGllbnQuICBUaGlzIGFudGktcmVwbGF5IGRlZmVuc2UNCiAgICAgIHJlcXVp cmVzIHNoYXJpbmcgdGhlIE1lc3NhZ2UgSUQgYW5kIHRoZSBUb2tlbiBpbiB0aGUgMC1SVFQgZGF0 YQ0KICAgICAgYmV0d2VlbiBET1RTIHNlcnZlcnMgaW4gdGhlIERPVFMgc2VydmVyIGRvbWFpbi4g IERPVFMgc2VydmVycyBkbw0KICAgICAgbm90IHJlbHkgb24gdHJhbnNwb3J0IGNvb3JkaW5hdGVz IHRvIGlkZW50aWZ5IERPVFMgcGVlcnMuICBBcw0KICAgICAgc3BlY2lmaWVkIGluIFNlY3Rpb24g NC40LjEsIERPVFMgc2VydmVycyBjb3VwbGUgdGhlIERPVFMgc2lnbmFsDQogICAgICBjaGFubmVs IHNlc3Npb25zIHVzaW5nIHRoZSBET1RTIGNsaWVudCBpZGVudGl0eSBhbmQgb3B0aW9uYWxseSB0 aGUNCiAgICAgICdjZGlkJyBwYXJhbWV0ZXIgdmFsdWUuICBGdXJ0aGVybW9yZSwgJ21pZCcgdmFs dWUgaXMgbW9ub3RvbmljYWxseQ0KICAgICAgaW5jcmVhc2VkIGJ5IHRoZSBET1RTIGNsaWVudCBm b3IgZWFjaCBtaXRpZ2F0aW9uIHJlcXVlc3QsDQogICAgICBhdHRhY2tlcnMgcmVwbGF5aW5nIG1p dGlnYXRpb24gcmVxdWVzdHMgd2l0aCBsb3dlciBudW1lcmljICdtaWQnDQogICAgICB2YWx1ZXMg YW5kIG92ZXJsYXBwaW5nIHNjb3BlcyB3aXRoIG1pdGlnYXRpb24gcmVxdWVzdHMgaGF2aW5nDQog ICAgICBoaWdoZXIgbnVtZXJpYyAnbWlkJyB2YWx1ZXMgd2lsbCBiZSByZWplY3RlZCBzeXN0ZW1h dGljYWxseSBieSB0aGUNCiAgICAgIERPVFMgc2VydmVyLiAgTGlrZXdpc2UsICdzaWQnIHZhbHVl IGlzIG1vbm90b25pY2FsbHkgaW5jcmVhc2VkIGJ5DQogICAgICB0aGUgRE9UUyBjbGllbnQgZm9y IGVhY2ggY29uZmlndXJhdGlvbiByZXF1ZXN0IChTZWN0aW9uIDQuNS4yKSwNCiAgICAgIGF0dGFj a2VycyByZXBsYXlpbmcgY29uZmlndXJhdGlvbiByZXF1ZXN0cyB3aXRoIGxvd2VyIG51bWVyaWMN CiAgICAgICdzaWQnIHZhbHVlcyB3aWxsIGJlIHJlamVjdGVkIGJ5IHRoZSBET1RTIHNlcnZlciBp ZiBpdCBtYWludGFpbnMgYQ0KICAgICAgaGlnaGVyIG51bWVyaWMgJ3NpZCcgdmFsdWUgZm9yIHRo aXMgRE9UUyBjbGllbnQuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IFttYWlsdG86VGlydW1h bGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbV0NCj4gRW52b3nDqcKgOiBqZXVkaSAyOCBmw6l2 cmllciAyMDE5IDExOjUwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IEJlbmph bWluIEthZHVrDQo+IENjwqA6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbEBpZXRmLm9y ZzsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSRTogW0RvdHNdIFVzaW5nIEVhcmx5IERhdGEg aW4gRE9UUyAoUkU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLQ0KPiBkb3RzLXNpZ25hbC1jaGFu bmVsKQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERvdHMg PGRvdHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+ID4gbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyOCwgMjAxOSAxOjQ4 IFBNDQo+ID4gVG86IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiA+IENjOiBkcmFm dC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWxAaWV0Zi5vcmc7IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkNCj4gPiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IGRvdHNAaWV0 Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0RvdHNdIFVzaW5nIEVhcmx5IERhdGEgaW4gRE9UUyAo UkU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLQ0KPiBkb3RzLQ0KPiA+IHNpZ25hbC1jaGFubmVs KQ0KPiA+DQo+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3Jn YW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3MNCj4gb3INCj4gPiBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMN Cj4gc2FmZS4NCj4gPg0KPiA+IEhpIEJlbiwNCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0K PiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPiA+IERlwqA6IEJlbmphbWluIEthZHVrIFttYWlsdG86a2FkdWtAbWl0LmVk dV0gRW52b3nDqcKgOiBtZXJjcmVkaSAyNw0KPiA+ID4gZsOpdnJpZXIgMjAxOSAxNjo1OCDDgMKg OiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIENjwqA6IEtvbmRhLA0KPiA+ID4gVGlydW1hbGVz d2FyIFJlZGR5OyBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWxAaWV0Zi5vcmc7DQo+ID4g PiBkb3RzQGlldGYub3JnDQo+ID4gPiBPYmpldMKgOiBSZTogVXNpbmcgRWFybHkgRGF0YSBpbiBE T1RTIChSRTogW0RvdHNdIEFEIHJldmlldyBvZg0KPiA+ID4gZHJhZnQtaWV0Zi0NCj4gPiA+IGRv dHMtc2lnbmFsLWNoYW5uZWwpDQo+ID4gPg0KPiA+ID4gT24gVHVlLCBGZWIgMTksIDIwMTkgYXQg MDc6NTk6MjlBTSArMDAwMCwNCj4gPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3Rl Og0KPiA+ID4gPiBIaSBCZW4sDQo+ID4gPiA+DQo+ID4gPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0K PiA+ID4NCj4gPiA+IE9rYXkuICBCVFcsIGl0IGlzIGxvb2tpbmcgbGlrZSB0aGlzIGlzIHRoZSBs YXN0IHRvcGljIHRvIHJlc29sdmUNCj4gPiA+IGJlZm9yZSBzdGFydGluZyBJRVRGIExDLiAgSXQn cyBwcm9iYWJseSB3b3J0aCBzL3RoZSBleHBvbmVudCBpcyAyL3RoZQ0KPiA+ID4gYmFzZSBvZiB0 aGUgZXhwb25lbnQgaXMgMi8gaW4gdGhlIG5leHQgcmV2LCB0aG91Z2gsIGp1c3QgYXMgYSBtaW5v ciBuaXQtDQo+IGZpeC4NCj4gPiA+DQo+ID4NCj4gPiBbTWVkXSBGaXhlZC4NCj4gPg0KPiA+ID4g Pg0KPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPiA+IERlwqA6 IEJlbmphbWluIEthZHVrIFttYWlsdG86a2FkdWtAbWl0LmVkdV0gRW52b3nDqcKgOiBsdW5kaSAx OA0KPiA+ID4gPiA+IGbDqXZyaWVyIDIwMTkgMTc6MjMgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQg VEdJL09MTiBDY8KgOiBLb25kYSwNCj4gPiA+ID4gPiBUaXJ1bWFsZXN3YXIgUmVkZHk7IGRyYWZ0 LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbEBpZXRmLi5vcmc7DQo+ID4gPiA+ID4gZG90c0BpZXRm Lm9yZw0KPiA+ID4gPiA+IE9iamV0wqA6IFJlOiBVc2luZyBFYXJseSBEYXRhIGluIERPVFMgKFJF OiBbRG90c10gQUQgcmV2aWV3IG9mDQo+ID4gPiA+ID4gZHJhZnQtaWV0Zi0NCj4gPiA+ID4gPiBk b3RzLXNpZ25hbC1jaGFubmVsKQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gRnJpLCBGZWIgMTUs IDIwMTkgYXQgMDM6MzY6MDVQTSArMDAwMCwNCj4gPiA+ID4gPiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+ID4gPiB3cm90ZToNCj4gPiA+ID4gPiA+IFJlLSwNCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiBMb29raW5nIGZvcndhcmQgdG8gZGlzY3VzcyB0aGlzIGZ1cnRoZXIuDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gSSB3b25kZXIgd2hldGhlciB5b3UgY2FuIGNvbnNpZGVyIHB1 dHRpbmcgdGhlIGRvY3VtZW50IGluIHRoZQ0KPiA+ID4gPiA+ID4gSUVURiBMQw0KPiA+ID4gZm9y DQo+ID4gPiA+ID4gbm93LiBJZiBpdCBoYXBwZW4gdGhhdCB3ZSBuZWVkIHRvIG1vZGlmeSB0aGUg MC1SVFQgdGV4dCwgd2Ugd2lsbA0KPiA+ID4gPiA+IGhhbmRsZQ0KPiA+ID4gaXQgYXMNCj4gPiA+ ID4gPiBvdGhlciBJRVRGIExDIGNvbW1lbnRzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSB3b3Vs ZCBub3JtYWxseSBiZSBwcmV0dHkgYW1lbmFibGUgdG8gc3RhcnRpbmcgSUVURiBMQyBhbmQNCj4g PiA+ID4gPiBjb250aW51aW5nIGRpc2N1c3Npb247IGl0J3MganVzdCBmb3IgdGhpcyBpc3N1ZSBp biBwYXJ0aWN1bGFyIHRoYXQNCj4gPiA+ID4gPiBJIHNlZW0gdG8gYmUgdGhlIG1haW4gcGVyc29u IG9uIHRoZSBJRVNHIHRoYXQgZW5mb3JjZXMgdGhlDQo+ID4gPiA+ID4gImFwcGxpY2F0aW9uIHBy b2ZpbGUgZm9yIDAtUlRUIGRhdGEiIHJlcXVpcmVtZW50LCBzbyBpdCB3b3VsZCBmZWVsDQo+ID4g PiA+ID4gcmF0aGVyIG9kZCB0byBnbyBmb3J3YXJkIGluIHRoaXMNCj4gPiA+IGNhc2UuDQo+ID4g PiA+DQo+ID4gPiA+IFtNZWRdIEZhaXIgZW5vdWdoLg0KPiA+ID4gPg0KPiA+ID4gPiA+IEx1Y2tp bHksIEkgc3BlbnQgc29tZSB0aW1lIHRoaXMgd2Vla2VuZCByZWFkaW5nIFJGQyA3MjUyIGFuZCBo YXZlDQo+ID4gPiA+ID4gc29tZSBzdWJzdGFudGl2ZSBjb21tZW50cy4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IFRoZSBrZXkgb2JlcnNlcnZhdGlvbiBoZXJlIHNlZW1zIHRvIGJlIHRoYXQgdGhlIE1l c3NhZ2UgSUQgaXMNCj4gPiA+ID4gPiBzY29wZWQgcGVyIGVuZHBvaW50LCBhbmQgcmVwbGF5cyBj YW4gY29tZSBmcm9tIGFyYml0cmFyeSBhZGRyZXNzZXMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBT cGVjaWZpY2FsbHksIHdlIHJlY2FsbCB0aGF0Og0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgVGhl IERPVFMgc2lnbmFsIGNoYW5uZWwgaXMgbGF5ZXJlZCBvbiBleGlzdGluZyBzdGFuZGFyZHMgKEZp Z3VyZQ0KPiAzKS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgRE9UUyBTaWduYWwgQ2hhbm5lbCB8DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+ID4gPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgIENvQVAgICAgICAgIHwNCj4gPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQo+ID4gPiA+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgVExTICAgIHwgICBEVExTICAgfA0KPiA+ID4gPiA+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsNCj4gPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBUQ1AgICAgfCAgIFVEUCAgICB8DQo+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0t Kw0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBJUCAgICAg ICAgIHwNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXZSBub3RlIHRoYXQgQ29BUCBpcyB1c2lu ZyB0aGUgSVAgYWRkcmVzcyBvciAiRFRMUyBzZXNzaW9uIg0KPiA+ID4gPiA+IChhcmd1YWJseSBh IHBvb3JseSBjaG9zZW4gdGVybSkgdG8gaWRlbnRpZnkgYSBDb0FQIGFzc29jaWF0aW9uIGFuZA0K PiA+ID4gPiA+IHRoYXQgTWVzc2FnZSBJRHMNCj4gPiA+IGFyZQ0KPiA+ID4gPiA+IG9ubHkgdXNl ZCB3aXRoaW4gdGhlIHNjb3BlIG9mIHN1Y2ggYW4gYXNzb2NpYXRpb24sIGl0IHNlZW1zIHByZXR0 eQ0KPiA+ID4gPiA+IGNsZWFyIHRoYXQgYW4gYXR0YWNrZXIgYWJsZSB0byByZXBsYXkgVExTIDEu MyAwLVJUVCBkYXRhIHdpbGwNCj4gPiA+ID4gPiBzbGljZSBvZmYgdGhlIHRvcCB0aHJlZSBsaW5l cyBvZiB0aGlzIGZpZ3VyZSBhbmQgc3dhcCBvdXQgdGhlDQo+ID4gPiA+ID4gVENQL1VEUC9JUCBs YXllcnMuICBJbiB0aGUgYWJzZW5jZSBvZiBEVExTIGNvbm5lY3Rpb24gSURzLCBteQ0KPiA+ID4g PiA+IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgIkRUTFMNCj4gPiA+IHNlc3Npb24iDQo+ID4g PiA+ID4gaXMgaWRlbnRpZmllZCBzb2xlbHkgYnkgdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uLCBq dXN0IGFzIGZvcg0KPiA+ID4gPiA+IGNvYXAtbm90LXMsIHNvIGJ5IHNwb29maW5nIHRoZSBzb3Vy Y2UgYWRkcmVzcywgdGhlIGF0dGFja2VyIGNhdXNlcw0KPiA+ID4gPiA+IHRoZSByZXBsYXllZCAw LVJUVCBkYXRhIChhbmQgdGh1cywgQ29BUCByZXF1ZXN0KSB0byBiZSBpbnRlcnByZXRlZA0KPiA+ ID4gPiA+IGFzIGEgbmV3IGluY29taW5nIGNvYXBzIGNvbm5lY3Rpb24uDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBHaXZlbiB0aGF0IE1lc3NhZ2UgSUQgaXMgb25seSAxNiBiaXRzIGFuZCB0aGUgc2Vy dmVycyBhY2NlcHRpbmcNCj4gPiA+ID4gPiAwLVJUVA0KPiA+ID4gZGF0YQ0KPiA+ID4gPiA+IGhh dmUgcG90ZW50aWFsIHRvIGJlIHF1aXRlIGJ1c3ksIGl0IGRvZXMgbm90IHNlZW0gd29ya2FibGUg dG8NCj4gPiA+ID4gPiBhdHRlbXB0IHRvIHVzZSB0aGUgaW5jb21pbmcgTWVzc2FnZSBJRHMgYXMg Z2xvYmFsbHkgdW5pcXVlIHJlcGxheQ0KPiA+ID4gPiA+IGRlZmVuc2UsIGFzIHRoZQ0KPiA+ID4g cmlzaw0KPiA+ID4gPiA+IG9mIGNvbGxpc2lvbiB3b3VsZCBiZSBwcmV0dHkgbGFyZ2UuDQo+ID4g PiA+DQo+ID4gPiA+IFtNZWRdIFRoZSByZXBsYXkgZGV0ZWN0aW9uIHJlbGllcyBvbiBib3RoIE1l c3NhZ2UgSUQgYW5kIFRva2VuLg0KPiA+ID4NCj4gPiA+IEluIHN0b2NrIENvQVAsIHRoZSBNZXNz YWdlIElEIGFuZCBUb2tlbiBhcmUgdXNlZCBvbmx5IHdpdGggdGhlIGNvbnRleHQNCj4gPiA+IG9m IGEgc3BlY2lmaWMgdHJhbnNwb3J0IGFzc29jaWF0aW9uLg0KPiA+DQo+ID4gW01lZF0gSG1tLi4u UkZDNzI1MiBkZWZpbmVzIGFuIGVuZHBvaW50IGFzIGZvbGxvd3M6DQo+ID4NCj4gPiAgICBUaGUg c3BlY2lmaWMgZGVmaW5pdGlvbiBvZiBhbiBlbmRwb2ludCBkZXBlbmRzIG9uIHRoZSB0cmFuc3Bv cnQgYmVpbmcNCj4gPiAgICB1c2VkIGZvciBDb0FQLiAgRm9yIHRoZSB0cmFuc3BvcnRzIGRlZmlu ZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLCB0aGUNCj4gPiAgICBlbmRwb2ludCBpcyBpZGVudGlm aWVkIGRlcGVuZGluZyBvbiB0aGUgc2VjdXJpdHkgbW9kZSB1c2VkIChzZWUNCj4gPiAgICBTZWN0 aW9uIDkpOiBXaXRoIG5vIHNlY3VyaXR5LCB0aGUgZW5kcG9pbnQgaXMgc29sZWx5IGlkZW50aWZp ZWQgYnkgYW4NCj4gPiAgICBJUCBhZGRyZXNzIGFuZCBhIFVEUCBwb3J0IG51bWJlci4gIFdpdGgg b3RoZXIgc2VjdXJpdHkgbW9kZXMsIHRoZQ0KPiA+ICAgIGVuZHBvaW50IGlzIGlkZW50aWZpZWQg YXMgZGVmaW5lZCBieSB0aGUgc2VjdXJpdHkgbW9kZS4NCj4gPg0KPiA+IERPVFMgYWRoZXJlcyB0 byB0aGF0IGRlZmluaXRpb246IGl0IGFzc3VtZXMgdGhhdCBhbiBlbmRwb2ludCBpcyBub3QNCj4g aWRlbnRpZmllZCBieQ0KPiA+IGl0cyB0cmFuc3BvcnQgY29vcmRpbmF0ZXMgYnV0IHdpdGggaXRz IGlkZW50aXR5Lg0KPiA+DQo+ID4gRnVydGhlcm1vcmUsIHRoZSBjb3JyZWxhdGlvbiBiZXR3ZWVu IHNlc3Npb25zIGlzIGNsZWFybHkgbWVudGlvbmVkIGluIHRoZQ0KPiB0ZXh0Og0KPiA+DQo+ID4g ICAgVGhlIERPVFMgc2VydmVyIGNvdXBsZXMgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgc2Vzc2lv bnMgdXNpbmcgdGhlDQo+ID4gICAgRE9UUyBjbGllbnQgaWRlbnRpdHkgYW5kIG9wdGlvbmFsbHkg dGhlICdjZGlkJyBwYXJhbWV0ZXIgdmFsdWUsIGFuZA0KPiA+ICAgIHRoZSBET1RTIHNlcnZlciB1 c2VzICdtaWQnIGFuZCAnY3VpZCcgVXJpLVBhdGggcGFyYW1ldGVyIHZhbHVlcyB0bw0KPiA+ICAg IGRldGVjdCBkdXBsaWNhdGUgbWl0aWdhdGlvbiByZXF1ZXN0cy4NCj4gPg0KPiA+DQo+ID4gIElu IG9yZGVyIHRvIHVzZSB0aGVtIGZvciAoRClUTFMgMS4zIHJlcGxheQ0KPiA+ID4gZGVmZW5zZSwg d2UgbmVlZCB0byBleHBhbmQgdGhhdCBjb250ZXh0IHRvIGEgYnJvYWRlciBzY29wZSwgYW5kIGRp cmVjdA0KPiA+ID4gdGhlIHNlcnZlciB0byBjaGVjayB0aGUgTWVzc2FnZSBJRC9Ub2tlbiBnbG9i YWxseSAob3IgYXQgbGVhc3Qgd2l0aGluDQo+ID4gPiB0aGUgc2NvcGUgb2YgYSBnaXZlbiAnY3Vp ZCcvJ2NkaWQnKS4gIFNpbmNlIHRoaXMgd291bGQgcmVmbGVjdCBhDQo+ID4gPiBkaXZlcmdlbmNl IGZyb20gbm9ybWFsIENvQVAsIGlmIHdlIGFyZSBnb2luZyB0byByZWx5IG9uIHRoaXMgc29ydCBv Zg0KPiA+ID4gYmVoYXZpb3IsIHdlIG11c3QgY2FsbCBpdCBvdXQgdmVyeSBsb3VkbHkgYXMgc3Bl Y2lmaWMgdG8gRE9UUy4NCj4gPiA+DQo+ID4NCj4gPiBbTWVkXSBXZSBjYW4gbWFrZSB0aGlzIGNo YW5nZSBpZiBpdCBoZWxwczoNCj4gPg0KPiA+IE9MRDoNCj4gPiAgICAgICBUaGUgRE9UUyBzZXJ2 ZXIocykgY2FuIHVzZSBNZXNzYWdlIElEIGFuZA0KPiA+ICAgICAgIFRva2VuIGluIHRoZSBET1RT IHNpZ25hbCBjaGFubmVsIG1lc3NhZ2UgdG8gZGV0ZWN0IHJlcGxheSBvZiBlYXJseQ0KPiA+ICAg ICAgIGRhdGEsIGFuZCBhY2NlcHQgMC1SVFQgZGF0YSBhdCBtb3N0IG9uY2UuDQo+ID4NCj4gPiBO RVc6DQo+ID4gICAgICAgVGhlIERPVFMgc2VydmVyKHMpIGNhbiB1c2UgTWVzc2FnZSBJRCBhbmQN Cj4gPiAgICAgICBUb2tlbiBpbiB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBtZXNzYWdlIHRvIGRl dGVjdCByZXBsYXkgb2YgZWFybHkNCj4gPiAgICAgICBkYXRhLCBhbmQgYWNjZXB0IDAtUlRUIGRh dGEgYXQgbW9zdCBvbmNlIGZyb20gdGhlIHNhbWUgRE9UUyBjbGllbnQuDQo+ID4gICAgICAgRE9U UyBzZXJ2ZXJzIGRvIG5vdCByZWx5IG9uIHRyYW5zcG9ydCBjb29yZGluYXRlcyB0bw0KPiA+ICAg ICAgIGlkZW50aWZ5IGl0cyBwZWVycy4gQXMgYSByZW1pbmRlciwgRE9UUyBzZXJ2ZXJzIGNvdXBs ZXMgdGhlIERPVFMNCj4gc2lnbmFsDQo+ID4gY2hhbm5lbCBzZXNzaW9ucw0KPiA+ICAgICAgIHVz aW5nIHRoZSBET1RTIGNsaWVudCBpZGVudGl0eSBhbmQgb3B0aW9uYWxseSB0aGUgJ2NkaWQnIHBh cmFtZXRlcg0KPiB2YWx1ZS4NCj4gDQo+IEkgcHJvcG9zZSB0byB1cGRhdGUgdGhlIHRleHQgYXMg Zm9sbG93czoNCj4gDQo+ICAgICAgIFRoZSBET1RTIHNlcnZlcihzKSBjYW4gdXNlIHRoZSBNZXNz YWdlIElEIGFuZA0KPiAgICAgICBUb2tlbiBpbiB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBtZXNz YWdlIHRvIGRldGVjdCByZXBsYXkgb2YgZWFybHkNCj4gICAgICAgZGF0YSwgYW5kIGFjY2VwdCAw LVJUVCBkYXRhIGF0IG1vc3Qgb25jZSBmcm9tIHRoZSBzYW1lIERPVFMgY2xpZW50Lg0KPiAgICAg ICBUaGlzIGFudGktcmVwbGF5IGRlZmVuc2UgcmVxdWlyZXMgc2hhcmluZyB0aGUgTWVzc2FnZSBJ RCBhbmQgVG9rZW4gaW4NCj4gdGhlIDAtUlRUIGRhdGENCj4gICAgICAgYmV0d2VlbiBET1RTIHNl cnZlcnMgaW4gdGhlIERPVFMgc2VydmVyIGRvbWFpbi4NCj4gICAgICAgRE9UUyBzZXJ2ZXJzIGRv IG5vdCByZWx5IG9uIHRyYW5zcG9ydCBjb29yZGluYXRlcyB0bw0KPiAgICAgICBpZGVudGlmeSBp dHMgcGVlcnMuIEFzIGEgcmVtaW5kZXIsIERPVFMgc2VydmVycyBjb3VwbGVzIHRoZSBET1RTIHNp Z25hbA0KPiBjaGFubmVsIHNlc3Npb25zDQo+ICAgICAgIHVzaW5nIHRoZSBET1RTIGNsaWVudCBp ZGVudGl0eSBhbmQgb3B0aW9uYWxseSB0aGUgJ2NkaWQnIHBhcmFtZXRlcg0KPiB2YWx1ZS4NCj4g DQo+IC1UaXJ1DQo= From nobody Thu Feb 28 21:21:05 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C612008F; Thu, 28 Feb 2019 21:21:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <155141766120.28744.12221194665525627102@ietfa.amsl.com> Date: Thu, 28 Feb 2019 21:21:01 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-20.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 05:21:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Tirumaleswar Reddy Robert Moskowitz Filename : draft-ietf-dots-requirements-20.txt Pages : 22 Date : 2019-02-28 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-20 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 28 21:26:44 2019 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2AC12950A; Thu, 28 Feb 2019 21:26:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <155141800314.28570.12843465790370591801@ietfa.amsl.com> Date: Thu, 28 Feb 2019 21:26:43 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-12.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 05:26:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Authors : Andrew Mortensen Flemming Andreasen Tirumaleswar Reddy Nik Teague Rich Compton Christopher Gray Filename : draft-ietf-dots-architecture-12.txt Pages : 34 Date : 2019-02-28 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/