From nobody Mon Jan 4 01:18:47 2021 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 967793A095E; Mon, 4 Jan 2021 01:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.217 X-Spam-Level: X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 CkKtyEI7S7UA; Mon, 4 Jan 2021 01:18:43 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 874E43A0940; Mon, 4 Jan 2021 01:18:40 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4D8VRd755Mz5vlM; Mon, 4 Jan 2021 10:18:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1609751918; bh=bHj2BTPVEtHLWufSC55FuINUugX5DcHzh4jntHnbs/Q=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=jgFJq46vjQyz1SiNLWsxa49iuHjjqL1FslkEbiXBdNYoqfs96Gels87cP5AcaJO7w hBplaH/KZCYuBjVDcRUVOPRpHMp2Wbbo2NkPoeZorTmOlquiyMMffmG47FFKpj/wqA syO2hBOV/T3ZfD0sNbLi+vW1Iz+ip6fTUbBYh0JIgYTzstPedjnasrcFwWD9r9AAfS LXkbka9jYau2LOWp9q9rZWSiBChuyJc3Sd/knTR3OsbEWt3y9gfdiXEeKYt875xmnl +pvX4M5LM8VUgSzkbpdUqwSs26xdMpa4hcp0aL3IpRoMZvOORHBGA7cIt/0XdS5Srn rGNLK8biK8n5w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4D8VRd631czCqkT; Mon, 4 Jan 2021 10:18:37 +0100 (CET) From: To: "dots@ietf.org" , "draft-ietf-dots-use-cases@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: Any reason why RFC8903 is stale since 09/20? Thread-Index: AdbiemN5B5vlaoIhQaCWSWyKhOwKcw== Date: Mon, 4 Jan 2021 09:18:37 +0000 Message-ID: <5008_1609751917_5FF2DD6D_5008_29_10_787AE7BB302AE849A7480A190F8B9330315A67BC@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330315A67BCOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Any reason why RFC8903 is stale since 09/20? 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 Jan 2021 09:18:46 -0000 --_000_787AE7BB302AE849A7480A190F8B9330315A67BCOPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This document is in AUTH48 for too long. It would be appreciated if the authors can share an update of the blocking = issues, if any. If this is stale just because some authors didn't reply, I guess this state= ment can be followed: https://ietf.org/about/groups/iesg/statements/auth48/ Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_787AE7BB302AE849A7480A190F8B9330315A67BCOPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi all,

=  

This document is in AUTH48 for too long.

 

It would be appreciated if the authors can share an update o= f the blocking issues, if any.

 

If this is stale just because some authors didn’t repl= y, I guess this statement can be followed:

 

https://ietf.org/about/groups/iesg/statements/auth48/

 

Cheers,

Med  

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_787AE7BB302AE849A7480A190F8B9330315A67BCOPEXCAUBMA2corp_-- From nobody Mon Jan 4 08:07:49 2021 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 406F43A0E34; Mon, 4 Jan 2021 08:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.72 X-Spam-Level: X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=S4Kpa1qA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oNxOuwkG 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 udq56PXbHCDo; Mon, 4 Jan 2021 08:07:41 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D7C3A0E2E; Mon, 4 Jan 2021 08:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25060; q=dns/txt; s=iport; t=1609776460; x=1610986060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c7LSABptOXYF2FkAGzJB8+75mFc5CT/RkzeSlLIeeDs=; b=S4Kpa1qALZaA88aKHto3KHgLDaTYc8NE0ab+CA/KfAlTVbb+XavUTLpz wGzwwxULJUI2uoma7wtOxQBNeF0W6Ef4ILvD3I7EMSNUAoh0Uy1l0308E Ked8IFa1kOsZljGPBuwMfz6WjWUH+SDrzDD14DOjSqP/ynO7bZjcSLYSY s=; IronPort-PHdr: =?us-ascii?q?9a23=3AIQ46qhU+q+3998/XUqpPeV2W7irV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyFufVeguzZvubrXmlTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBpWe76zEfXB?= =?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AAA3PPNf/5BdJa1YChsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQFAgT4DAQEBCwGBUlEHdlsvLgqENYNIA41kA4EFjge?= =?us-ascii?q?KAYFCgREDVAsBAQENAQEYCwoCBAEBhEoCF4FYAiU3Bg4CAwEBCwEBBQEBAQI?= =?us-ascii?q?BBgRxhTQBLAyFcwEBAQMBAQEQEREMAQEpAQIIAwEEBwQCAQgRAQMBAQMCERI?= =?us-ascii?q?DAgICJQsUAQIGCAIEAQ0FCBMBBoMFglUDDiABAwukGwKBPIhpdoEygwQBAQa?= =?us-ascii?q?BR0GCexiCEAMGgQ4qAYJ0g3yCRoFLeCiBByYbgUE/gRFDgiE1PoJdAQECAQE?= =?us-ascii?q?VfxIBBwQHAQkaPYJZNIIsgU8LATYEFBkHXwQLCQ4ZFgIKAxMBLgwGGgQEDQc?= =?us-ascii?q?rBwkQHQIBDgISBQsECS+PHAoPAwcSC4MHpAqBEQqCdokqjRWFO4MpiiuUfJQ?= =?us-ascii?q?LixCRKS4LBAmENAIEAgQFAg4BAQaBbCRnWBEHcBU7gmlQFwINVkWGZYYhBwU?= =?us-ascii?q?XFIM6hRSFRHQ3AgYBCQEBAwl8ilgCJgeBBgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.78,474,1599523200"; d="scan'208";a="823417855" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jan 2021 16:07:38 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 104G7cxD020840 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2021 16:07:38 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 10:07:38 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 10:07:38 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 4 Jan 2021 10:07:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MrW7OlQAzReNQeIYR+0J0kMA1rAlqy8zRrNuQBc+E++dCVhqdku44rPtLnIUaE8NoFdZlkw9wHfFh4sPcYwuEtrIrS32pGqu5kz6XMPxJrxIHU9UHNZUJr/AdKxM/P3LnO5AqdzXw5FIoltgPc3HT+meVwbNb6SA/Em0Xhm7WKvM4lYx7pTDL3vN+Mnybaf053p367czLFyyaJp5H22qZpLGOTgljebFR6QJ710e4ND8GJTZxq6AuEhghEmYWU7X9tkTypcxuUqZb/0CeR2GgJtRTCJEo8UmdNIAe3DHUq/LiDGaKHxtNG+yppo2uKx3jYYb9vPCEvmY+gIfbbybNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c7LSABptOXYF2FkAGzJB8+75mFc5CT/RkzeSlLIeeDs=; b=aWzyXeqd0nDiGS/0SJENk4sKRunFblT+C5PJN7wT/Gzzrgmsvqwclqj1ACv1YCDo3aCyXV83v8kW6Od3Jhfa9pUS/PevG8xIFwFO1WGOJc8fMdul1KVNZkREeVO9kNoHQOAo0ZeiNct5wUGeOYw7IXsO+W7+rMy2rht35vo1BMjAmiOqri7EA+I8nzSC+EQM7Uvma6H1NTLARSvWoP1Uc8jTuFNt9CbynaP9qnZniU4nBPoXy67TrCbCHrPjXwMHdONYxtfhpgsxsFTja+qo7iLOzfKxaHJgYqguML2SBB+B4LTiib5Ppf7peVNeLtfGfXGIPmkrdMKWtq2WpdSzMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c7LSABptOXYF2FkAGzJB8+75mFc5CT/RkzeSlLIeeDs=; b=oNxOuwkGjVoYd73t0ipBAm7nG5fOSLlaVJ+kPGuFTUZY6XIhjF3NoeiemIb/n/gwF3WH7SnDq3Zf8hAoIZ9p9ZfCgcA7kIBB8PdPDtTOJ7NeZOH1MpjdYsGABveEann30jkQBFIm+3ULyNe+vltpR0oST4XwkS0OR51cU+dbbro= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4205.namprd11.prod.outlook.com (2603:10b6:208:192::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.21; Mon, 4 Jan 2021 16:07:36 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb%6]) with mapi id 15.20.3721.024; Mon, 4 Jan 2021 16:07:36 +0000 From: "Rob Wilton (rwilton)" To: "mohamed.boucadair@orange.com" , "Roman Danyliw" , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , Valery Smyslov , "dots@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x04GhVUrubF9E6Ldzi/FU9PuKn5Pw6AgAPYoACAB6gWgIAS/Rdg Date: Mon, 4 Jan 2021 16:07:36 +0000 Message-ID: References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <703969fb11df49a39c6241bb32934ff6@cert.org> <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0b3dc9e-06d6-4258-430f-08d8b0cada44 x-ms-traffictypediagnostic: MN2PR11MB4205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BTUAHAqsy32p1Tbo7rhBrrIHxXvm4h6itQTsYuLaLLO3CUxEtoh2ZrdGzfffoVrnd16BuDifJ2OXideJ6WC2h8ll5ucTCQ3GBzXlKAQtU/L5b5xdp7I94OZV2A/bfF/RiNMh6ZPWtEo2+I0iYDx6mHA/5Ck3kEFnBuRDvRivbOYvxH8c/mI5ymw+xzswER4t1/5QnRLOqBhdjAwbxabtJ863p3GEWNQ/sxAh8VI92sDrNEF61RwwW3OV7tXNSiVPMoNUk+nayMUmuhNoIVjDuTp3+QNzh6EXRRXRFP7kDp1pTgvB4gwc7K0kYyMel2mc9X9YIz8rtuhRHsMsQFDdnhO/T/3n/P+tcI8SNeFKxg+WbgJUEYt19R1fBx+Fs6ngZsWynMQaP75MMXERb5iZg61r3g+CMYmtj5If4ghcv3xdSjnjbFau/vIo8cLJvuGoyA6cvDvJfaC0jYDoBa+uHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(346002)(396003)(136003)(376002)(7696005)(4326008)(966005)(478600001)(33656002)(55016002)(186003)(52536014)(64756008)(66446008)(5660300002)(66556008)(66946007)(30864003)(66476007)(76116006)(8676002)(2906002)(83380400001)(66574015)(8936002)(110136005)(316002)(6506007)(86362001)(53546011)(9686003)(26005)(71200400001)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WHR4WEx1NUpQU3R6MnRhQjhIaEQvMnlrQzArYXE2L1J6TXJ1TTc1TXd6bkxW?= =?utf-8?B?dzEreThJUU9JN2NybUoxN3Z2eVRPNjB1aWlBV2VOYlMzbE1QaVAvS3VQT1p3?= =?utf-8?B?MCticzRBdFJqSWZvVUVYMThjL3FidmR4WW1TY0tqNDR3VUc0WW5nN3E1VUk3?= =?utf-8?B?TnJhSyt3UUJZOTEyZ2U1bEhwSjVpelROVlZQaGJDdzBXQUhxYlRqQU1NQnFx?= =?utf-8?B?c3ZvdXVUOEpRN2EwTXU5VitRY2w4eWJjQzNZdDd6ZmY1dDdxYmxmYUVHeEVa?= =?utf-8?B?MG9TY202dHdDUkZ1SGFmZ3FQempMTFZtcGJzcnlFQ2N2akdibVNVK2hlWWht?= =?utf-8?B?bFFlWnROelFlcExEcnJLR0xWME1RbHBpbUdRQ1Q3MlRFa2RCRzJVUmlhMDh0?= =?utf-8?B?bC9FYkRDSVBPTkx2M3FObHYydW5TNGpkSU15TlROMnVBOHArczR2SmFvVG9Q?= =?utf-8?B?bXpORlpiZStib1R1VUV3NnYvdkFHRkRPVzZJZy9BeG00YTdEeDB4QWY2cVVW?= =?utf-8?B?OUZaR3FKRFZGcmwyNTF1eDNHSnNSc3Rva3lEQ0k3UlowY2IrQVFFZ3BzT29m?= =?utf-8?B?UGxubkV3UExGTUIvR1JmTE9PK1l4cjlLMGJnNTYwRUJ5cGZDdFNqdWJlSmJI?= =?utf-8?B?ZEhWbWoyVHNVMUlzMUFCQlk3a0FsZG1XVTlPbjBqU3dHcU4xaVBQcklTcXdW?= =?utf-8?B?enVadzUwVmp0ZHVTMkowdTlZQjdhTkErcXJwam1rTVpSeGc2dno4WVUxVk4v?= =?utf-8?B?WWV1Z2RtK3l3OE5ERjBYU2dqTFk4KzVXd1Z1UWVjT090Rk9zd1NOSFlGbXdF?= =?utf-8?B?OW5OenlOc3ZSeDRRdW9FZ055YjM3RzJvS3BudTZFRnljb0lQRHhOOFpqdkNi?= =?utf-8?B?WmtlRy9WU0pJRWhxendjWXNQNm9RaXBmSkhJU1l1ZTZZUEZJcDRWU1NmL2J1?= =?utf-8?B?VUs0YjRsSDMyQ3hOcDd0OHA0WkdrV3UwOEx0NFRjL3crTmJGZ0FvTnQ2MFAz?= =?utf-8?B?MlE5NVNKRFpFZTR1WHRTMTFDeUVyUDhiSjZPbDdXWTNuRFVueWhhK2VoM1RM?= =?utf-8?B?eUYvWWJnRFZxVTFMWjZJTmpJZnd5NFF1SHBTRTFIMHoxUXgxNDFZcjNpZ056?= =?utf-8?B?K1M0MUdWbFFiVzE2TldWa0xhUExXZVFoQUdvc2MzeEUrMzdxTGZCNVordGdq?= =?utf-8?B?WjdpQS9OazNkY3kyVk1ISTIycUNrTlVsTUk0L3ZMNkVTaTBqckw1TVg0VndM?= =?utf-8?B?SlJrazc0eXhDa09ZTk5ZWUhMREhtdERlMTl6Skg1SWFac2h1VThJUFFNa0cv?= =?utf-8?Q?FK9mer9trfQwo=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0b3dc9e-06d6-4258-430f-08d8b0cada44 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 16:07:36.3075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uaahv3qXIU1mALkBp4LhOO0nxkIiRJ7aPpJtToTDNMOi4v2TYA4P9B3Sh2+AtWQ2Rlva2Gha7V2xceJUBi4j9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4205 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (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: Mon, 04 Jan 2021 16:07:43 -0000 SGkgTWVkLA0KDQpUaGlzIHRleHQgaXMgYW4gaW1wcm92ZW1lbnQgdG8gbWUsIHRoYW5rcy4NCg0K QWx0aG91Z2ggdGhlIGludHJvZHVjdGlvbiBzdGlsbCBkb2Vzbid0IHNlZW0gdG8gc3RhdGUgdGhl IHByZWNpc2UgcmVhc29uIHdoeSB0aGUgRE9UUyBjbGllbnQgY2Fubm90IG9wZW4gYSByZWd1bGFy IGNoYW5uZWwgdG8gdGhlIERPVHMgc2VydmVyIChlLmcuIHBhcmFncmFwaCAyIG9mIHRoZSBpbnRy b2R1Y3Rpb24pLCBvciBJIGFtIG1pc3NpbmcgaXQuDQoNCk15IGFzc3VtcHRpb24gb2YgdGhlIGRl cGxveW1lbnQgaXMgdGhhdCB0aGUgRE9UUyBjbGllbnQgaXMgd2l0aGluIHRoZSBvdXRib3VuZCBE T1MgYXR0YWNrIElTUCdzIG5ldHdvcmsuICBJcyB0aGUgc3BlY2lmaWMgaXNzdWUgdGhhdCB0aGlz IGRvY3VtZW50IGlzIGFkZHJlc3NpbmcgdGhhdCB0aGUgRE9UcyBzZXJ2ZXIgbWF5IGJlIGJlaGlu ZCBhIE5BVCBhbmQgaGVuY2Ugbm90IGJlIHB1YmxpY2x5IGFkZHJlc3NhYmxlPyAgT3IgYXJlIHRo ZXJlIGFsc28gb3RoZXIgcmVhc29ucyB3aHkgYSBDYWxsIEhvbWUgYXJjaGl0ZWN0dXJlIGlzIHJl cXVpcmVkPyAgSSBhcHByZWNpYXRlIHRoYXQgdGhlcmUgbWF5IGJlIHJlYXNvbnMgd2h5IGEgQ2Fs bCBIb21lIGFyY2hpdGVjdHVyZSBpcyBwcmVmZXJyZWQgYW5kIHBvdGVudGlhbGx5IHNpbXBsaWZp ZXMgdGhlIG1hbmFnZW1lbnQgb2YgdGhlIENQRSBkZXZpY2VzLg0KDQpSZWdhcmRzLA0KUm9iDQoN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGllc2ctYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20NCj4gU2VudDogMjMgRGVjZW1iZXIgMjAyMCAxMzo1NA0KPiBUbzogUm9tYW4gRGFueWxpdyA8 cmRkQGNlcnQub3JnPjsgUm9iIFdpbHRvbiAocndpbHRvbikNCj4gPHJ3aWx0b25AY2lzY28uY29t PjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFs LWNhbGwtaG9tZUBpZXRmLm9yZzsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7DQo+IFZhbGVyeSBTbXlz bG92IDx2YWxlcnlAc215c2xvdi5uZXQ+OyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBS b21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9t ZS0NCj4gMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBSb21hbiwgYWxs LA0KPiANCj4gV2UgdXBkYXRlZCB0aGUgZHJhZnQgdG8gdGFrZSBpbnRvIGFjY291bnQgeW91ciBz dWdnZXN0aW9ucy4gVGhlDQo+IGludHJvZHVjdGlvbiBhbmQgYXBwbGljYWJpbGl0eSBzZWN0aW9u cyB3ZXJlIHJld29ya2VkIGFjY29yZGluZ2x5LiBXZSBhbHNvDQo+IGtlcHQgaW4gbWluZCBSb2In cyBjb21tZW50IHdoZW4gdXBkYXRpbmcgdGhlc2UgdHdvIHNlY3Rpb25zLg0KPiANCj4gVGhlIG5l dyB2ZXJzaW9uIGFuZCBhIGRpZmYgY2FuIGJlIGZvdW5kIGF0Og0KPiANCj4gSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNh bGwtDQo+IGhvbWUtMTINCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLQ0KPiBjYWxsLWhvbWUtMTINCj4gDQo+ IFBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGlzIHZlcnNpb24gYWRkcmVzc2VzIHlvdXIgRElTQ1VT Uy4NCj4gDQo+IEFsc28sIHRoaXMgdmVyc2lvbiBpbnRlZ3JhdGVzIHRoZSBpbnB1dHMgZnJvbSB0 aGUgQmFycnkvRXJpYy9FcmlrIGFuZA0KPiBkaXJlY3RvcmF0ZSByZXZpZXdzLg0KPiANCj4gQ2hl ZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXC oDogUm9tYW4gRGFueWxpdyBbbWFpbHRvOnJkZEBjZXJ0Lm9yZ10NCj4gPiBFbnZvecOpwqA6IHZl bmRyZWRpIDE4IGTDqWNlbWJyZSAyMDIwIDE3OjU4DQo+ID4gw4DCoDogQk9VQ0FEQUlSIE1vaGFt ZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IFRoZQ0KPiA+IElFU0cg PGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2PCoDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhv bWVAaWV0Zi5vcmc7IGRvdHMtDQo+ID4gY2hhaXJzQGlldGYub3JnOyBWYWxlcnkgU215c2xvdiA8 dmFsZXJ5QHNteXNsb3YubmV0PjsgZG90c0BpZXRmLm9yZw0KPiA+IE9iamV0wqA6IFJFOiBSb21h biBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtDQo+ID4g aG9tZS0xMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPg0KPiA+IEhpIE1lZCENCj4g Pg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IERvdHMgPGRv dHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+ID4gPiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE2LCAyMDIwIDE6 MTQgQU0NCj4gPiA+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4gPiA+IENjOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9t ZUBpZXRmLm9yZzsgZG90cy0NCj4gPiBjaGFpcnNAaWV0Zi5vcmc7DQo+ID4gPiBWYWxlcnkgU215 c2xvdiA8dmFsZXJ5QHNteXNsb3YubmV0PjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDog UmU6IFtEb3RzXSBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbg0KPiA+ID4gZHJhZnQtaWV0Zi1k b3RzLXNpZ25hbC1jYWxsLQ0KPiA+ID4gaG9tZS0xMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCj4gPiA+DQo+ID4gPiBIaSBSb21hbiwNCj4gPiA+DQo+ID4gPiBUaGFuayB5b3UgZm9yIHRo ZSByZXZpZXcuDQo+ID4gPg0KPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHRoZSBESVNDVVNT IHBhcnQuIFdpbGwgc2VlIGlmL3doYXQgY2hhbmdlcw0KPiA+IGFyZQ0KPiA+ID4gbmVlZGVkIGZv ciB0aGUgQ09NTUVOVCBwYXJ0Lg0KPiA+ID4NCj4gPiA+IENoZWVycywNCj4gPiA+IE1lZA0KPiA+ ID4NCj4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+IERlwqA6IFJv bWFuIERhbnlsaXcgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4g PiBFbnZvecOpwqA6DQo+ID4gPiA+IG1hcmRpIDE1IGTDqWNlbWJyZSAyMDIwIDIxOjAxIMOAwqA6 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDY8KgOg0KPiA+ID4gPiBkcmFmdC1pZXRmLWRvdHMt c2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9yZzsgZG90cy0NCj4gPiBjaGFpcnNAaWV0Zi5vcmc7DQo+ ID4gPiA+IGRvdHNAaWV0Zi5vcmc7IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+ Ow0KPiA+ID4gPiB2YWxlcnlAc215c2xvdi5uZXQgT2JqZXTCoDogUm9tYW4gRGFueWxpdydzIERp c2N1c3Mgb24NCj4gPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWUtDQo+ID4g PiA+IDExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+ID4gPg0KPiA+ID4gPiBSb21h biBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K PiA+ID4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0xMTogRGlzY3Vzcw0KPiA+ ID4gPg0KPiA+ID4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseQ0KPiA+IHRvDQo+ID4gPiA+IGFsbCBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZQ0KPiA+IHRvDQo+ID4g PiA+IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy0NCj4gPiA+ID4gY3JpdGVyaWEuaHRtbA0KPiA+ID4gPiBmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kDQo+ID4gaGVyZToNCj4gPiA+ID4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxs LQ0KPiA+IGhvbWUvDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiAtLS0tDQo+ID4gPiA+IC0tDQo+ID4gPiA+IERJU0NVU1M6DQo+ID4gPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiAtLS0tDQo+ID4gPiA+IC0tDQo+ID4gPiA+DQo+ID4gPiA+IEl0IHNlZW1zIHRvIG1lIHRo ZXJlIGlzIGEgbWlzc2luZyBvcGVyYXRpb25hbCBndWlkYW5jZSBvcg0KPiA+ID4gPiB1bmRvY3Vt ZW50ZWQgZGVwbG95bWVudCBhc3N1bXB0aW9ucy4gIFNpbmNlIHRoZSBtb3RpdmF0aW9uYWwgdXNl DQo+ID4gPiA+IGNhc2Ugc2VlbXMgdG8gYmUgaG9tZSBuZXR3b3JrcyAocGVyIFNlY3Rpb24gMS4x KSwgSSBhc3N1bWVkIHRoYXQNCj4gPiB0aGUNCj4gPiA+ID4gY2FsbCBob21lIHNlcnZlcnMgYXJl IHJ1bm5pbmcgcHJpbWFyaWx5IGNvbnN1bWVyIGdyYWRlIHJvdXRlcnMNCj4gPiBub3QNCj4gPiA+ ID4gbWFuYWdlZCBieSBwcm9mZXNzaW9uYWwgSVQgZXhwZXJ0aXNlLg0KPiA+ID4NCj4gPiA+IFtN ZWRdIFRoZSBnZW5lcmFsaXplZCBhcHBsaWNhYmlsaXR5IHNjb3BlIGlzIHdoYXQgaXMgc2tldGNo ZWQgaW4NCj4gPiA+IFNlY3Rpb24gMy4gVGhlIHNvbHV0aW9uIGlzIG1lYW50IHRvIGJsb2NrIGF0 dGFja3MgY2xvc2UgdG8gdGhlaXINCj4gPiBzb3VyY2UuIFRoaXMgY2FuIGJlOg0KPiA+ID4gLSB0 aGUgaG9tZSBjYXNlLA0KPiA+ID4gLSBhbiBlbnRlcnByaXNlIG5ldHdvcmssDQo+ID4gPiAtIGEg dHJhbnNpdCBwcm92aWRlciBmaWx0ZXJpbmcgYXR0YWNrcyBmcm9tIGxlYWYgbmV0d29ya3MsDQo+ ID4gPiAtIGEgcHJvdmlkZXIgZmlsdGVyaW5nIGF0dGFja3MgZnJvbSBkYXRhIGNlbnRlcnMsDQo+ ID4gPiAtIGV0Yy4NCj4gPiA+DQo+ID4gPiBGb3IgdGhlIHBhcnRpY3VsYXIgY2FzZSBvZiBob21l IG5ldHdvcmtzLCB0aGlzIGNhbiBiZSBwYXJ0IG9mDQo+ID4gc2VydmljZXMNCj4gPiA+IHN1cHBv cnRlZCBieSBhIElTUC1tYW5hZ2VkIENQRSBvciBhIG1hbmFnZWQgc2VjdXJpdHkgc2VydmljZQ0K PiA+IHN1YnNjcmliZWQgYnkgdGhlIHVzZXIuDQo+ID4gPg0KPiA+ID4gV2UgY291bGQgbWVudGlv biB0aGF0IGluIHRoZSBkb2N1bWVudCwgYnV0IHdlIGRpZG4ndCBiZWNhdXNlIHRoaXMNCj4gPiBh cmUNCj4gPiA+IGRlcGxveW1lbnQtc3BlY2lmaWMuIFJlYWxseS4NCj4gPiA+DQo+ID4gPiBPdGhl ciB0aGFuIHRoZSBpbnRyb2R1Y3Rpb24sIHdlIGRvbid0IHdhbnQgdG8gb3ZlcmxvYWQgdGhlDQo+ ID4gZG9jdW1lbnQNCj4gPiA+IHdpdGggaG9tZS1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucy4NCj4g Pg0KPiA+IEkgc3RpbGwgdGhpbmsgd2UgbmVlZCBhIGJpdCBtb3JlIHByZWNpc2lvbi4gIEkgZG9u J3QgZGlzcHV0ZSB0aGUNCj4gPiBnZW5lcmFsIHV0aWxpdHkgb2YgdGhpcyBhcHByb2FjaCB0byBh IHZhcmlldHkgb2YgZW52aXJvbm1lbnRzLiAgSSBkbw0KPiA+IHNlZSB0aGUgdHdvIHNlbnRlbmNl cyBpbiB0aGUgZW50aXJlIGRvY3VtZW50IHdoaWNoIHNheSB0aGF0IHRoaXMgaXMNCj4gPiBhIGdl bmVyYWwgcHVycG9zZSBhcHByb2FjaDoNCj4gPg0KPiA+IEFic3RyYWN0OiBUaGUgRE9UUyBzaWdu YWwgY2hhbm5lbCBDYWxsIEhvbWUgaXMgbm90IHNwZWNpZmljIHRvIGhvbWUNCj4gPiBuZXR3b3Jr czsNCj4gPiAgICB0aGUgc29sdXRpb24gdGFyZ2V0cyBhbnkgZGVwbG95bWVudCBpbiB3aGljaCBp dCBpcyByZXF1aXJlZCB0bw0KPiA+IGJsb2NrDQo+ID4gICAgRERvUyBhdHRhY2sgdHJhZmZpYyBj bG9zZXIgdG8gdGhlIHNvdXJjZShzKSBvZiBhIEREb1MgYXR0YWNrLg0KPiA+DQo+ID4gU2VjdGlv biAzOiAiVGhlIGFmb3JlbWVudGlvbmVkIHByb2JsZW1zIG1heSBiZSBlbmNvdW50ZXJlZCBpbiBv dGhlcg0KPiA+IGRlcGxveW1lbnRzDQo+ID4gICAgdGhhbiB0aG9zZSBkaXNjdXNzZWQgaW4gU2Vj dGlvbiAxLjEgKGUuZy4sIGRhdGEgY2VudGVycywNCj4gPiBlbnRlcnByaXNlDQo+ID4gICAgbmV0 d29ya3MpLiINCj4gPg0KPiA+IEhvd2V2ZXIsIEkgd2lsbCByZWl0ZXJhdGUgdGhhdCBhbG1vc3Qg bm8gY29uc2lkZXJhdGlvbiBpcyBtYWRlIHRvDQo+ID4gZGlzdGluZ3Vpc2ggdGhlc2UgdXNlIGNh c2VzIGluIHRoZSBuYXJyYXRpdmUgdGV4dC4gIFRoZSBlbnRpcmUNCj4gPiBtb3RpdmF0aW9uIGZv ciB0aGUgd29yayBpbiBTZWN0aW9uIDEuMCBpcyB0aHJvdWdoIHRoZSBsZW5zIG9mDQo+ID4gbmV0 d29ya3Mgbm90IG1hbmFnZWQgYnkgcHJvZmVzc2lvbmFscyAoaG9tZSBuZXR3b3JrcykuICBGdXJ0 aGVybW9yZSwNCj4gPiB0aGUgZXhwbGFuYXRpb24gb2YgdGhlIHNvbHV0aW9uIGluIFNlY3Rpb24g MS4xLCA1LjEgYW5kIEFwcGVuZGl4IEENCj4gPiBpcyBkb25lIHRocm91Z2ggdGhlIGxlbnMgb2Yg YSAiaG9tZSBuZXR3b3JrIi4gIEZvciB0aGlzIHJlYXNvbiwgSSdtDQo+ID4gcHVzaGluZyB0byBt YWtlIHN1cmUgdGhlIGVkZ2VzIG9mIHRoYXQgZGVwbG95bWVudCBlbnZpcm9ubWVudCBhcmUNCj4g PiBjb3ZlcmVkLg0KPiA+DQo+ID4gSSB3b3VsZCBhc3NlcnQgdGhhdCBtb3N0IG9mIHRoZSBiZWhh dmlvciBkZXNjcmliZWQgYmVsb3cgcmVxdWlyZXMNCj4gPiB0aGF0IHByb2Zlc3Npb25hbCBJVCBl eHBlcnRpc2UgKGxldCBtZSBrbm93IGlmIHlvdSB0aGluayBJIGhhdmUgaXQNCj4gPiB3cm9uZyku ICBJJ20gbG9va2luZyBwcmltYXJpbHkgZm9yIGEgZmV3IHBpZWNlcyBvZiBjbGFyaWZ5aW5nIHRl eHQ6DQo+ID4gKDEpIGEgc3VnZ2VzdGlvbi9hY2tub3dsZWRnZW1lbnQgdGhhdCBDUEVzIHVzaW5n IHRoaXMgc3BlYyBpbiB0aGUNCj4gPiBob21lIGVudmlyb25tZW50IGFyZSBsaWtlbHkgdG8gYmUg bWFuYWdlZCwgcHJvdmlzaW9uZWQsIGlzc3VlZCAoPykNCj4gPiBieSBhbiBJU1AgKHRoaXMgYWRk cmVzc2VzIHdoZXJlIHRoZXJlIHByb2Zlc3Npb25hbCBJVCBleHBlcnRpc2UgaXMNCj4gPiBjb21p bmcgZnJvbSkNCj4gPiAoMikgYXNzdW1pbmcgKDEpIGlzIHRydWUsIGRpc3Rpbmd1aXNoaW5nIHRo ZSB2YXJpb3VzDQo+ID4gTVVTVC9TSE9VTEQvTUFZcyBhZG1pbiBiZWhhdmlvcnMgdGhhdCBpbnZv bHZlIHRoZSBJU1AgdnMuIHRoZSBhY3R1YWwNCj4gPiBodW1hbnMgb24gdGhlIGhvbWUgbmV0d29y aw0KPiA+DQo+ID4gTm90ZTogZXZlcnl0aGluZyBlbHNlIGJlbG93IGlzIGp1c3QgbW9yZSBkZXRh aWxlZCBjb21tZW50YXJ5IG9uIHRoaXMNCj4gPiB0aGVtZSBhYm92ZS4gIEknZCBzdW1tYXJpemUg ZXZlcnl0aGluZyBJJ3ZlIHNhaWQgaGVyZSBieSBzYXlpbmcgSQ0KPiA+IHRoaW5rIHdlIG5lZWQg bW9yZSBmaW5lc3NlIGluIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbmFsDQo+ID4gY29uc2lkZXJh dGlvbnMgYW5kIHdobyBpcyBleHBlY3RlZCB0byB0YWtlIHJlc3BvbnNpYmlsaXR5IGZvciB0aGVt DQo+ID4gKHJlYWxpemluZyB0aGVyZSB3aWxsIGJlIGEgZGl2ZXJzaXR5IG9mIGVudmlyb25tZW50 cykuICBIb3dldmVyLA0KPiA+IHNpbmNlIHRoZXJlIGFyZSBtdWx0aXBsZSB1c2UgY2FzZXMsIElN TywgdGhleSBkZXNlcnZlIHVuaXF1ZQ0KPiA+IGNvbnNpZGVyYXRpb24gd2hlbiB0aGV5IGFyZSBk aWZmZXJlbnQgZnJvbSBlYWNoIG90aGVyLg0KPiA+DQo+ID4gPiAgIElmIHRoYXQgYXNzdW1wdGlv biBpcyB0cnVlDQo+ID4gPiA+IChhbmQgaXQgc2hvdWxkIGJlIGRvY3VtZW50ZWQgaWYgdGhhdCBp cyB0aGUgY2FzZSksIHRoZW4gSSBmaW5kDQo+ID4gbWFueQ0KPiA+ID4gPiBvZiB0aGUgb3BlcmF0 aW9uYWwgcmVjb21tZW5kYXRpb25zIG5vdCBjb25ncnVlbnQgd2l0aCB0aGF0DQo+ID4gZW52aXJv bm1lbnQuDQo+ID4gPiA+IFNwZWNpZmljYWxseSwgdGhlIGRlZ3JlZSBvZiBpbnRlcmFjdGlvbiBh bmQgdHVuaW5nIHNlZW1zIG91dHNpZGUNCj4gPiB0aGUNCj4gPiA+ID4gcmVhbG0gb2YgZXhwZXJ0 aXNlIG9mIHNvbWVvbmUgd2l0aG91dCBJVCB0cmFpbmluZyBhbmQNCj4gPiBjYXBhYmlsaXRpZXMN Cj4gPiA+ID4gb2YgaG9tZSBuZXR3b3JrIGVjb3N5c3RlbS4gIEluIHBhcnRpY3VsYXI6DQo+ID4g PiA+DQo+ID4gPiA+IC0tIFNlY3Rpb24gMS4yDQo+ID4gPiA+IFRoZSBDYWxsIEhvbWUgRE9UUyBz ZXJ2ZXIgdXNlcyB0aGUgRERvUyBhdHRhY2sgdHJhZmZpYw0KPiA+IGluZm9ybWF0aW9uIHRvDQo+ ID4gPiA+ICAgIGlkZW50aWZ5IHRoZSBjb21wcm9taXNlZCBkZXZpY2UgaW4gaXRzIGRvbWFpbiB0 aGF0IGlzDQo+ID4gcmVzcG9uc2libGUNCj4gPiA+ID4gZm9yDQo+ID4gPiA+ICAgIGxhdW5jaGlu ZyB0aGUgRERvUyBhdHRhY2ssIG9wdGlvbmFsbHkgbm90aWZpZXMgYSBuZXR3b3JrDQo+ID4gPiA+ ICAgIGFkbWluaXN0cmF0b3IsIGFuZCB0YWtlcyBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9uIGFjdGlv bihzKS4NCj4gPiA+ID4NCj4gPiA+ID4gSG93IHdvdWxkIHN1Y2ggbm90aWZpY2F0aW9uIHdvcms/ DQo+ID4gPg0KPiA+ID4gW01lZF0gVGhpcyB3aWxsIGRlcGVuZCBvbiB0aGUgZGVwbG95bWVudCAo aG9tZSwgZW50ZXJwcmlzZSwgREMsDQo+ID4gYWNjZXNzDQo+ID4gPiBwcm92aWRlciwgcGVlciB0 cmFuc2l0IHByb3ZpZGVyLCBldGMuKS4gVGhpcyBjYW4gYmUgdXNpbmcgRE9UUw0KPiA+ICh0aGUN Cj4gPiA+IGFkbWluaXN0cmF0b3IgaGFzIGEgY2FsbCBob21lIGRvdHMgc2VydmVyIGFwcCksIGEg cHVzaCBmcm9tIHRoZQ0KPiA+IGFwcA0KPiA+ID4gdXNlIGZvciBtYW5hZ2luZyB0aGUgQ1BFLCBz eXNsb2csIHNubXAsIG5ldGNvbmYsIGFuIFNNUywgZXRjLg0KPiA+DQo+ID4gSSB1bmRlcnN0YW5k IHRoaXMgYW5zd2VyIGluIHRoZSBjb250ZXh0IG9mIHRoZSBlbnRlcnByaXNlIHVzZSBjYXNlLg0K PiA+IEhvdyB3b3VsZCB0aGlzIGhhcHBlbiBmb3IgdGhlIGhvbWUgdXNlciAobm9uLXByb2Zlc3Np b25hbCBJVA0KPiA+IHBlcnNvbik/DQo+ID4NCj4gPiBJZiB0aGlzIGFuIGluc3RhbmNlIHdoZXJl IGlmIHRoZSBDUEUgaXMgbWFuYWdlZCBvbiBiZWhhbGYgYSB0aGUNCj4gPiB1c2VyLCBwZXJoYXBz IHNheWluZyBhbiBvdXQtb2Ytc2NvcGUgbWVjaGFuaXNtcyAoYXBwLCBTTVMpIG5lZWRzIHRvDQo+ ID4gYmUgcHJvdmlkZWQgZm9yIHRoZSBlbmQtdXNlciAoaG9tZSB1c2VyKT8NCj4gPg0KPiA+ID4g QXMgeW91IGNhbiBzZWUgYSB2YXJpZXR5IG9mIHRvb2xzIGNhbiBiZSBjb25zaWRlcmVkIGFzIGEg ZnVuY3Rpb24NCj4gPiBvZg0KPiA+ID4gdGhlIGxvY2FsIGRlcGxveW1lbnQgY2FzZS4gTm9uZSBv ZiB0aGVtIGlzIGNhbGxlZCBvdXQgaW4gdGhlIHRleHQNCj4gPiBhcw0KPiA+ID4gdGhpcyBpcyBk ZXBsb3ltZW50LSBzcGVjaWZpYy4gTm90IGFsbCBvZiB0aGVtIGFyZSBhcHBsaWNhYmxlIGZvcg0K PiA+IGVhY2ggZGVwbG95bWVudCBjYXNlLg0KPiA+DQo+ID4gTWFrZSBzZW5zZS4gIFBlcmhhcHMg c29tZSBkZXRhaWxzIGRpc3Rpbmd1aXNoaW5nIHRoZSBndWlkYW5jZSBwZXINCj4gPiB0aGUgdXNl IGNhc2VzIGNvdWxkIGhlbHAuDQo+ID4NCj4gPiA+ID4NCj4gPiA+ID4gLS0gU2VjdGlvbiAxLjIg YW5kIDUuMS4gIExlYXZlcyBjcmVkZW50aWFscyBjb25maWd1cmF0aW9uIGFzIG91dA0KPiA+IG9m DQo+ID4gPiA+IHNjb3BlLg0KPiA+ID4NCj4gPiA+IFtNZWRdIFRoYXQgaXMgYWxpZ25lZCB3aXRo IGhvdyBjcmVkZW50aWFscyBhcmUgaGFuZGxlZCBpbiB0aGUgYmFzZQ0KPiA+ID4gc3BlYyAoUkZD ODc4MikuDQo+ID4gPg0KPiA+ID4gPiBTZWN0aW9uIDEuMiByZWZlcmVuY2VzIFtJLUQuaWV0Zi1k b3RzLXNlcnZlci1kaXNjb3ZlcnldIGZvcg0KPiA+ID4gPiBwcm92aXNpb25pbmcuICBJbiB0dXJu LCBTZWN0aW9uIDEgb2YgW0ktRC5pZXRmLnNlcnZlci1kaXNjb3ZlcnldDQo+ID4gPiA+IGFsc28g ZGVjbGFyZXMgdGhpcyBwcm9ibGVtIG91dCBvZiBzY29wZSBieSBzYXlpbmcg4oCcVGhpcyBkb2N1 bWVudA0KPiA+ID4gPiBhc3N1bWVzIHRoYXQgc2VjdXJpdHkgY3JlZGVudGlhbHMgdG8gYXV0aGVu dGljYXRlIERPVFMgc2VydmVyKHMpDQo+ID4gYXJlDQo+ID4gPiA+IHByZS1wcm92aXNpb25lZCB0 byBhIERPVFMgY2xpZW50IHVzaW5nIGEgbWVjaGFuaXNtIHN1Y2ggYXMgKGJ1dA0KPiA+IG5vdA0K PiA+ID4gPiBsaW1pdGVkIHRvKSB0aG9zZSBkaXNjdXNzZWQgaW4gW1JGQzg1NzJdIG9yIFtJLUQu aWV0Zi1hbmltYS0NCj4gPiA+ID4gYm9vdHN0cmFwcGluZy1rZXlpbmZyYV3igJ0uICBIb3dldmVy LCBSRkM4NTcyIHNlZW1zIHRvIHJlbHkgb24NCj4gPiBORVRDT05GDQo+ID4gPiA+IGFuZCBSRVNU Q09ORiB3aGljaCBzZWVtcyBsaWtlIGEgcmF0aGVyIHVuY29tbW9uIGZlYXR1cmUgb2YgaG9tZQ0K PiA+ID4gPiByb3V0ZXJzLiAgQlJLU0kgcmVsaWVzIG9uIGEgbWFudWZhY3R1cmVyIHN1cHBsaWVk L2NvbnRyYWN0ZWQNCj4gPiA+ID4gaW5mcmFzdHJ1Y3R1cmUgYW5kIGtleXN0b3JlcyB0aGF0IGFs c28gc2VlbSB1bmNvbW1vbiBmb3INCj4gPiBjb25zdW1lcg0KPiA+ID4gPiBncmFkZSBlcXVpcG1l bnQuDQo+ID4gPg0KPiA+ID4gW01lZF0gVGhlc2UgYXJlIG5vdCBtZWFudCB0byBiZSByZWNvbW1l bmRhdGlvbnMuIFRoZXNlIGV4YW1wbGVzDQo+ID4gbWF5IGJlDQo+ID4gPiBPSyBmb3Igc29tZSBk ZXBsb3ltZW50cywgYnV0IG5vdCBhcHByb3ByaWF0ZSBmb3Igb3RoZXJzLg0KPiA+ID4NCj4gPiA+ ID4NCj4gPiA+ID4gLS0gU2VjdGlvbiA1LjMuMS4NCj4gPiA+ID4gVGhlIENhbGwgSG9tZSBET1RT IHNlcnZlciBkb21haW4gYWRtaW5pc3RyYXRvciBjb25zZW50IE1BWSBiZQ0KPiA+ID4gPiAgICBy ZXF1aXJlZCB0byBibG9jayB0aGUgdHJhZmZpYyBmcm9tIHRoZSBjb21wcm9taXNlZCBkZXZpY2Ug dG8NCj4gPiB0aGUNCj4gPiA+ID4gICAgYXR0YWNrIHRhcmdldC4gIEFuIGltcGxlbWVudGF0aW9u IE1BWSBoYXZlIGEgY29uZmlndXJhdGlvbg0KPiA+IGtub2IgdG8NCj4gPiA+ID4gICAgYmxvY2sg dGhlIHRyYWZmaWMgZnJvbSB0aGUgY29tcHJvbWlzZWQgZGV2aWNlIHRvIHRoZSBhdHRhY2sNCj4g PiB0YXJnZXQNCj4gPiA+ID4gICAgd2l0aCBvciB3aXRob3V0IERPVFMgc2VydmVyIGRvbWFpbiBh ZG1pbmlzdHJhdG9yIGNvbnNlbnQuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBzdWdnZXN0aW9uIGhl cmUgc2VlbXMgdG8gYmUgdGhhdCBjb25zdW1lcnMgYXJlIGFjcXVpcmluZw0KPiA+IGRldmljZXMN Cj4gPiA+ID4gdGhhdCBjYW4gYmUgcmVtb3RlbHkgcmVjb25maWd1cmVkIHdpdGggb3V0IGEgZGVm aW5lZCB0cnVzdA0KPiA+IG1vZGVsPw0KPiA+ID4NCj4gPiA+IFtNZWRdIENhbiB5b3UgcGxlYXNl IGNsYXJpZnkgd2hpY2ggc3VnZ2VzdGlvbiBhcmUgeW91IHJlZmVycmluZw0KPiA+IHRvPw0KPiA+ DQo+ID4gSSdtIHdvbmRlcmluZyB3aG8gdGhlICJzZXJ2ZXIgZG9tYWluIGFkbWluaXN0cmF0b3Ii IGlzIGFuZCBob3cgdGhleQ0KPiA+IGFyZSBleHBlY3RlZCB0byBjb25zZW50IGluIHRoZSBob21l IHVzZXIgc2NlbmFyaW8/DQo+ID4NCj4gPiA+IFRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgcmVmZXJy aW5nIHRvIGJsb2NraW5nIHRyYWZmaWMgZnJvbSBkZXZpY2VzDQo+ID4gdGhhdA0KPiA+ID4gYXJl IGluamVjdGluZyBERG9TIHRyYWZmaWMgZnJvbSB3aXRoaW4gYSBkb21haW4uIFRoZXNlIGRldmlj ZXMgY2FuDQo+ID4gYmUNCj4gPiA+IGFuIElQIGNhbWVyYSwgYW4gaW5mZWN0ZWQgUEMsIGV0Yy4N Cj4gPiA+DQo+ID4gPiA+IFNvbWUgcG9saWN5IG9yIG9wZXJhdGlvbmFsIGNvbnRleHQgc2VlbXMg YXBwcm9wcmlhdGUgaGVyZS4NCj4gPiA+ID4NCj4gPiA+ID4gLS0gU2VjdGlvbiA1LjMuMQ0KPiA+ ID4gPiAuLi4gbm90aWZpZXMgdGhlIENQRQ0KPiA+ID4gPiAgICBhZG1pbmlzdHJhdG9yIGFib3V0 IHRoZSBjb21wcm9taXNlZCBkZXZpY2UNCj4gPiA+ID4NCj4gPiA+ID4gTm90aWZ5IGhvdz8NCj4g PiA+DQo+ID4gPiBbTWVkXSBTZWUgYWJvdmUuDQo+ID4NCj4gPiBMaWtlIEkgbm90ZWQgYWJvdmUs IGlmIEknbSBhIGhvbWUgdXNlciwgaG93IGFtIEkgbGlrZWx5IHRvIGdldCB0aGF0DQo+ID4gbm90 aWZpY2F0aW9uPw0KPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC0tIFNlY3Rpb24gOC4NCj4gPiA+ID4g QXBwcm9wcmlhdGUNCj4gPiA+ID4gICAgZmlsdGVycyAoZS5nLiwgYWNjZXNzIGNvbnRyb2wgbGlz dHMpIGNhbiBiZSBpbnN0YWxsZWQgb24gdGhlDQo+ID4gQ2FsbA0KPiA+ID4gPiAgICBIb21lIERP VFMgc2VydmVyIGFuZCBuZXR3b3JrIGJldHdlZW4gdGhlIENhbGwgSG9tZSBET1RTDQo+ID4gYWdl bnRzIHNvDQo+ID4gPiA+ICAgIHRoYXQgb25seSBjb21tdW5pY2F0aW9ucyBmcm9tIGEgdHJ1c3Rl ZCBDYWxsIEhvbWUgRE9UUyBjbGllbnQNCj4gPiB0bw0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gICAg Q2FsbCBIb21lIERPVFMgc2VydmVyIGFyZSBhbGxvd2VkLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlz IHNlZW1zIGxpa2UgYSBsZXZlbCBvZiBzb3BoaXN0aWNhdGlvbiBiZXlvbmQgeW91ciBhdmVyYWdl DQo+ID4gaG9tZQ0KPiA+ID4gPiByb3V0ZXIgdXNlciBhbmQgYSBwbGFjZSB3aGVyZSBpbXBsZW1l bnRhdGlvbnMgc2hvdWxkIGNvbnNpZGVyIGENCj4gPiA+ID4gc2VjdXJlIGRlZmF1bHRzLg0KPiA+ ID4NCj4gPiA+IFtNZWRdIFRoaXMgZmlsdGVyaW5nIGNhbiBiZSBhdXRvbWF0aWNhbGx5IHNldCBi YXNlZCBvbiB0aGUNCj4gPiBjb25maWd1cmVkDQo+ID4gPiBsaXN0IG9mIENhbGwgSG9tZSBET1RT IGNsaWVudHMuIFRoaXMgaXMgYSB3aWRlbHkgdXNlZCBwcmFjdGljZQ0KPiA+ICh0aGluaw0KPiA+ ID4gYWJvdXQgU0lQIHByb3h5IHNlcnZlcnMsIGV4YW1wbGUpLiBObyBpbnRlcnZlbnRpb24gbWF5 IGJlIHJlcXVpcmVkDQo+ID4gZnJvbSB0aGUgdXNlci4NCj4gPg0KPiA+IEFncmVlZC4gIEhvd2V2 ZXIsIHRoaXMgaXMgYXNzdW1pbmcgdGhhdCBzb21lb25lIGlzIG1hbmFnaW5nIHRoYXQNCj4gPiBj b25maWd1cmF0aW9uLiAgTXkgcG9pbnQgaXMgdGhhdCBpbiB0aGUgaG9tZSB1c2VyIHNwYWNlIHRo YXQgaXMgbW9zdA0KPiA+IGxpa2VseSB0aGUgSVNQLCBzbyBsZXQncyBqdXN0IHNheSB0aGF0Lg0K PiA+DQo+ID4gPiA+DQo+ID4gPiA+IC0tIFNlY3Rpb24gOC4NCj4gPiA+ID4gQ2FsbCBIb21lIERP VFMgc2VydmVycyBjYW4gYWxzbyBzZWVrIHRoZSBjb25zZW50IG9mIERPVFMNCj4gPiA+ID4gICAg c2VydmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIHRvIGJsb2NrIHRoZSB0cmFmZmljIGZyb20gdGhl DQo+ID4gPiA+IHBvdGVudGlhbGx5DQo+ID4gPiA+ICAgIGNvbXByb21pc2VkIGRldmljZSB0byB0 aGUgdGFyZ2V0IChzZWUgU2VjdGlvbiA1LjMuMSkuDQo+ID4gPiA+DQo+ID4gPiA+IFdoYXQgd291 bGQgYmUgdGhlIG1lYW5zIHRvIGdhaW4gc3VjaCBjb25zZW50Pw0KPiA+ID4NCj4gPiA+IFtNZWRd IFRoaXMgd2lsbCBkZXBlbmQgb24gdGhlIGRlcGxveW1lbnQgY2FzZTogdGhpcyBjYW4gYmUgYW4N Cj4gPiBhY3Rpb24NCj4gPiA+IGV4ZWN1dGVkIHVzaW5nIGFuIGFwcCwgYSBjb25maXJtYXRpb24g dG8gYSBub3RpZmljYXRpb24gbWVzc2FnZSwNCj4gPiBldGMuDQo+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPiAtLSBTZWN0aW9uIDkuDQo+ID4gPiA+IE5vdGUgdGhhdCBhIENhbGwgSG9tZSBET1RTIHNl cnZlciBjYW4gc2VlayBhbiBhZG1pbmlzdHJhdG9yJ3MNCj4gPiA+ID4gICAgY29uc2VudCwgdmFs aWRhdGUgdGhlIHJlcXVlc3QgYnkgaW5zcGVjdGluZyB0aGUgcmVsZXZhbnQNCj4gPiB0cmFmZmlj DQo+ID4gPiA+IGZvcg0KPiA+ID4gPiAgICBhdHRhY2sgc2lnbmF0dXJlcywgb3IgcHJvY2VlZCB3 aXRoIGJvdGggY291cnNlcyBvZiBhY3Rpb24uDQo+ID4gPiA+DQo+ID4gPiA+IEFzIGFib3ZlLg0K PiA+ID4NCj4gPiA+IFtNZWRdIEFzIGFib3ZlIDotKQ0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4g LS0gU2VjdGlvbiA5Lg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgVGhlIERPVFMgQ2FsbCBIb21lIGlz IG9ubHkgYWR2aXNvcnkgaW4gbmF0dXJlLiAgQ29uY3JldGVseSwNCj4gPiB0aGUNCj4gPiA+ID4g RE9UUw0KPiA+ID4gPiAgICBDYWxsIEhvbWUgZG9lcyBub3QgaW1wb3NlIGFueSBhY3Rpb24gdG8g YmUgZW5mb3JjZWQgd2l0aGluDQo+ID4gdGhlDQo+ID4gPiA+ICAgIG5ldHdvcmsgaG9zdGluZyBh biBhdHRhY2sgc291cmNlOyBpdCBpcyB1cCB0byB0aGUgQ2FsbCBIb21lDQo+ID4gRE9UUw0KPiA+ ID4gPiAgICBzZXJ2ZXIgKGFuZC9vciBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIHRvIGRlY2lkZSB3 aGV0aGVyIGFuZA0KPiA+IHdoaWNoDQo+ID4gPiA+ICAgIGFjdGlvbnMgYXJlIHJlcXVpcmVkLg0K PiA+ID4gPg0KPiA+ID4gPiBTdWNoIGEgZGVjaXNpb25zIHNlZW1zIG91dCBiZXlvbmQgdGhlIGFi aWxpdHkgb2YgeW91ciBhdmVyYWdlDQo+ID4gaG9tZQ0KPiA+ID4gPiByb3V0ZXIgdXNlci4NCj4g PiA+DQo+ID4gPiBbTWVkXSBXZSBkb24ndCBoYXZlIHRoZSBub3Rpb24gb2YgImF2ZXJhZ2UgaG9t ZSByb3V0ZXIgdXNlciIgOy0pDQo+ID4NCj4gPiBBZ3JlZWQuICBQcm9iYWJseSBub3QgdXMgdGhv dWdoIDotKS4gIE15IGludGVudCB3YXMgdG8gc2F5IHRoYXQgd2hlbg0KPiA+IHRoZSBhY3Rpb25z L2RlY2lzaW9ucyBhcmUgYmVpbmcgZnJhbWVkIGFzIGJlaW5nIGZvciBhICJuZXR3b3JrDQo+ID4g YWRtaW4iLCB0aGF0IHRvIG1lIHN1Z2dlc3RzIGEgbGV2ZWwgZXhwZXJ0aXNlIG91dHNpZGUgb2Yg dGhlDQo+ID4gY2FwYWJpbGl0eSBvZiB0eXBpY2FsIGVuZCBjb25zdW1lciB3aXRob3V0IHByb2Zl c3Npb25hbCBJVA0KPiA+IGRlY2lzaW9ucy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gUm9tYW4N Cj4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLSBTZWN0aW9uIDggIOKAnC4uLiBleHBsaWNpdCBwb2xp Y3kgKGUuZy4sIHRoZSBDYWxsIEhvbWUgRE9UUw0KPiA+IGNsaWVudA0KPiA+ID4gPiBhbmQgc2Vy dmVyIGFyZSBtYW5hZ2VkIGJ5IHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGVudGl0eSksDQo+ID4g PiA+DQo+ID4gPiA+IElzIHRoZXJlIGFuIHVuZGVybHlpbmcgYXNzdW1wdGlvbiB0aGF0IHRoZSBJ U1AgaXMgbWFuYWdpbmcgdGhlDQo+ID4gZGV2aWNlPw0KPiA+ID4NCj4gPiA+IFtNZWRdIElTUCBt YW5hZ2VkIGRldmljZXMgaXMgb25lIHR5cGljYWwgZGVwbG95bWVudCBjYXNlLg0KPiA+ID4NCj4g PiA+IFRoYXQncyBzYWlkLCB0aGUgdGV4dCB5b3UgcXVvdGVkIGlzIG5vdCBzcGVjaWZpYyB0byBJ U1BzLiBJdA0KPiA+IGFwcGxpZXMsDQo+ID4gPiBmb3IgZXhhbXBsZSwgd2hlbiBnYXRld2F5cyBh cmUgb24gdGhlIHBhdGggYW5kIGJvdGggdGhlIENhbGwgSG9tZQ0KPiA+IERPVFMNCj4gPiA+IHNl cnZlciBhbmQgQ2FsbCBIb21lIERPVFMgY2xpZW50IHdpbGwgdGh1cyBiZSBtYW5hZ2VkIGJ5IHRo ZSBEQw0KPiA+ID4gcHJvdmlkZXIsIHRoZSBlbnRlcnByaXNlIGFkbWluaXN0cmF0b3IsIHRoZSBh Y2Nlc3MgcHJvdmlkZXIsIGV0Yy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+DQo+ID4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPiA+IGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+ID4gZGlmZnVzZXMsDQo+ ID4gPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZQ0KPiA+IG1lc3NhZ2UNCj4gPiA+IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlDQo+ID4gYWluc2kNCj4gPiA+IHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50DQo+ID4g c3VzY2VwdGlibGVzDQo+ID4gPiBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYQ0KPiA+IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KPiA+ID4NCj4gPiA+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+ID4gcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZA0KPiA+IG5v dA0KPiA+ID4gYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4NCj4gPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+IGFuZA0KPiA+ID4gZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiA+IGhhdmUNCj4gPiA+IGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+ID4gVGhhbmsgeW91Lg0KPiA+ ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gRG90c0BpZXRmLm9yZw0KPiA+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiANCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jDQo+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoNCj4gcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPiBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+IE9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91DQo+IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkDQo+IGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kDQo+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4g QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4NCj4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBU aGFuayB5b3UuDQoNCg== From nobody Mon Jan 4 08:26:17 2021 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 549783A0E4F; Mon, 4 Jan 2021 08:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 l-QxjA1FOYFf; Mon, 4 Jan 2021 08:26:13 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 332C93A0E4D; Mon, 4 Jan 2021 08:26:13 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4D8gwz3zj5zCrMd; Mon, 4 Jan 2021 17:26:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1609777571; bh=1dw/DJ1mUYejQ6SEcBVFx6ZVnowOn6Pe+HNmLEh8HL0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=AmVX6i3MgPU6zDoZzIglDMd9s6iYjuHq1CBGphw+ysWYb/hbkCmZfgiXRyRbaiAiB k1PEPtK5zBUe4xt78A1PHucPcIdBX65+phmJvA7mLVF1i5wY9YAaL9tZJnahrjQBkF 6CRyUqpBWdTpuu6RzntD0Y/h5hS8md42jeAPbejxgdjluVKxFU9gQl1D2lLVVHll+o 0ESGQ6hxjlJCc2o/wX6TwgzbdhUamyNqBXmQ9WI+fgn484GQ2dOCJ/1EVyJGkqH1+u Oj5K4MxYU7TNNRFHP1NHfLUWiW8QetsBpA4+PFfECj/XB6qpXwsphfXtD/UHaRSWAE MZ6cgI3xLz2+g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4D8gwz1b4gzDq8X; Mon, 4 Jan 2021 17:26:11 +0100 (CET) From: To: "Rob Wilton (rwilton)" , Roman Danyliw , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , Valery Smyslov , "dots@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x04GhVUrubF9E6Ldzi/FU9PuKn5Pw6AgAPYoACAB6gWgIAS/RdggAAHj4A= Date: Mon, 4 Jan 2021 16:26:10 +0000 Message-ID: <21867_1609777571_5FF341A3_21867_195_25_787AE7BB302AE849A7480A190F8B9330315A6CFB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <703969fb11df49a39c6241bb32934ff6@cert.org> <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@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.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (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: Mon, 04 Jan 2021 16:26:16 -0000 SGkgUm9iLA0KDQpXZSB0aG91Z2h0IHRoaXMgd2FzIGNvdmVyZWQgYnkgdGhlIGZvbGxvd2luZzog DQoNCiAgIE90aGVyIG1vdGl2YXRpb25zIGZvciBpbnRyb2R1Y2luZyB0aGUgQ2FsbCBIb21lIGZ1 bmN0aW9uIGFyZQ0KICAgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMS4xIG9mIFtSRkM4MDcxXS4NCg0K V2UgcHJlZmVycmVkIHRoYXQgY2l0YXRpb24gdnMgZHVwbGljYXRpbmcgdGhlIDYgaXRlbXMgaW4g dGhpcyBkb2N1bWVudCBhcyB3ZWxsIChzL21hbmFnZW1lbnQgc3lzdGVtL21pdGlnYXRpb24gc3lz dGVtKS4gDQoNCkkgdW5kZXJzdGFuZCBmcm9tIHlvdXIgY29tbWVudCB0aGF0IHRoZSBsaW5rIHdh cyBub3QgZXZpZGVudC4gSWYgc28sIHdpbGwgc2VlIGhvdyB0byBtYWtlIHRoaW5ncyBiZXR0ZXIu IA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXC oDogUm9iIFdpbHRvbiAocndpbHRvbikgW21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0NCj4gRW52 b3nDqcKgOiBsdW5kaSA0IGphbnZpZXIgMjAyMSAxNzowOA0KPiDDgMKgOiBCT1VDQURBSVIgTW9o YW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgUm9tYW4NCj4gRGFu eWxpdyA8cmRkQGNlcnQub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjwqA6IGRy YWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3RzLQ0KPiBjaGFpcnNA aWV0Zi5vcmc7IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+OyBkb3RzQGlldGYu b3JnDQo+IE9iamV0wqA6IFJFOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LWRvdHMtc2lnbmFsLWNhbGwtDQo+IGhvbWUtMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQp DQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBUaGlzIHRleHQgaXMgYW4gaW1wcm92ZW1lbnQgdG8gbWUs IHRoYW5rcy4NCj4gDQo+IEFsdGhvdWdoIHRoZSBpbnRyb2R1Y3Rpb24gc3RpbGwgZG9lc24ndCBz ZWVtIHRvIHN0YXRlIHRoZSBwcmVjaXNlDQo+IHJlYXNvbiB3aHkgdGhlIERPVFMgY2xpZW50IGNh bm5vdCBvcGVuIGEgcmVndWxhciBjaGFubmVsIHRvIHRoZSBET1RzDQo+IHNlcnZlciAoZS5nLiBw YXJhZ3JhcGggMiBvZiB0aGUgaW50cm9kdWN0aW9uKSwgb3IgSSBhbSBtaXNzaW5nIGl0Lg0KPiAN Cj4gTXkgYXNzdW1wdGlvbiBvZiB0aGUgZGVwbG95bWVudCBpcyB0aGF0IHRoZSBET1RTIGNsaWVu dCBpcyB3aXRoaW4NCj4gdGhlIG91dGJvdW5kIERPUyBhdHRhY2sgSVNQJ3MgbmV0d29yay4gIElz IHRoZSBzcGVjaWZpYyBpc3N1ZSB0aGF0DQo+IHRoaXMgZG9jdW1lbnQgaXMgYWRkcmVzc2luZyB0 aGF0IHRoZSBET1RzIHNlcnZlciBtYXkgYmUgYmVoaW5kIGEgTkFUDQo+IGFuZCBoZW5jZSBub3Qg YmUgcHVibGljbHkgYWRkcmVzc2FibGU/ICBPciBhcmUgdGhlcmUgYWxzbyBvdGhlcg0KPiByZWFz b25zIHdoeSBhIENhbGwgSG9tZSBhcmNoaXRlY3R1cmUgaXMgcmVxdWlyZWQ/ICBJIGFwcHJlY2lh dGUgdGhhdA0KPiB0aGVyZSBtYXkgYmUgcmVhc29ucyB3aHkgYSBDYWxsIEhvbWUgYXJjaGl0ZWN0 dXJlIGlzIHByZWZlcnJlZCBhbmQNCj4gcG90ZW50aWFsbHkgc2ltcGxpZmllcyB0aGUgbWFuYWdl bWVudCBvZiB0aGUgQ1BFIGRldmljZXMuDQo+IA0KPiBSZWdhcmRzLA0KPiBSb2INCj4gDQo+IA0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGllc2cgPGllc2ct Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+ID4gbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbQ0KPiA+IFNlbnQ6IDIzIERlY2VtYmVyIDIwMjAgMTM6NTQNCj4gPiBUbzogUm9tYW4g RGFueWxpdyA8cmRkQGNlcnQub3JnPjsgUm9iIFdpbHRvbiAocndpbHRvbikNCj4gPiA8cndpbHRv bkBjaXNjby5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gPiBDYzogZHJhZnQtaWV0 Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtDQo+IGNoYWlyc0BpZXRmLm9y ZzsNCj4gPiBWYWxlcnkgU215c2xvdiA8dmFsZXJ5QHNteXNsb3YubmV0PjsgZG90c0BpZXRmLm9y Zw0KPiA+IFN1YmplY3Q6IFJFOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbg0KPiA+IGRyYWZ0 LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLQ0KPiA+IDExOiAod2l0aCBESVNDVVNTIGFuZCBD T01NRU5UKQ0KPiA+DQo+ID4gSGkgUm9tYW4sIGFsbCwNCj4gPg0KPiA+IFdlIHVwZGF0ZWQgdGhl IGRyYWZ0IHRvIHRha2UgaW50byBhY2NvdW50IHlvdXIgc3VnZ2VzdGlvbnMuIFRoZQ0KPiA+IGlu dHJvZHVjdGlvbiBhbmQgYXBwbGljYWJpbGl0eSBzZWN0aW9ucyB3ZXJlIHJld29ya2VkIGFjY29y ZGluZ2x5Lg0KPiBXZQ0KPiA+IGFsc28ga2VwdCBpbiBtaW5kIFJvYidzIGNvbW1lbnQgd2hlbiB1 cGRhdGluZyB0aGVzZSB0d28gc2VjdGlvbnMuDQo+ID4NCj4gPiBUaGUgbmV3IHZlcnNpb24gYW5k IGEgZGlmZiBjYW4gYmUgZm91bmQgYXQ6DQo+ID4NCj4gPiBIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy0NCj4gc2lnbmFsLWNhbGwtDQo+ ID4gaG9tZS0xMg0KPiA+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1kb3RzLQ0KPiBzaWduYWwtDQo+ID4gY2FsbC1ob21lLTEyDQo+ ID4NCj4gPiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB5b3Vy IERJU0NVU1MuDQo+ID4NCj4gPiBBbHNvLCB0aGlzIHZlcnNpb24gaW50ZWdyYXRlcyB0aGUgaW5w dXRzIGZyb20gdGhlIEJhcnJ5L0VyaWMvRXJpaw0KPiBhbmQNCj4gPiBkaXJlY3RvcmF0ZSByZXZp ZXdzLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlwqA6IFJvbWFuIERhbnlsaXcgW21haWx0bzpyZGRAY2Vy dC5vcmddIEVudm95w6nCoDogdmVuZHJlZGkgMTgNCj4gPiA+IGTDqWNlbWJyZSAyMDIwIDE3OjU4 IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPiA+IDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+IENjwqA6DQo+ID4gPiBkcmFm dC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9yZzsgZG90cy0NCj4gY2hhaXJzQGll dGYub3JnOw0KPiA+ID4gVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47IGRvdHNA aWV0Zi5vcmcgT2JqZXTCoDogUkU6DQo+IFJvbWFuDQo+ID4gPiBEYW55bGl3J3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtDQo+ID4gPiBob21lLTExOiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKQ0KPiA+ID4NCj4gPiA+IEhpIE1lZCENCj4gPiA+DQo+ID4gPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IERvdHMgPGRvdHMtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+ID4gPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAyMCAxOjE0IEFN DQo+ID4gPiA+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz4NCj4gPiA+ID4gQ2M6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21l QGlldGYub3JnOyBkb3RzLQ0KPiA+ID4gY2hhaXJzQGlldGYub3JnOw0KPiA+ID4gPiBWYWxlcnkg U215c2xvdiA8dmFsZXJ5QHNteXNsb3YubmV0PjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gPiBTdWJq ZWN0OiBSZTogW0RvdHNdIFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uDQo+ID4gPiA+IGRyYWZ0 LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4gPiA+ID4gaG9tZS0xMTogKHdpdGggRElTQ1VTUyBh bmQgQ09NTUVOVCkNCj4gPiA+ID4NCj4gPiA+ID4gSGkgUm9tYW4sDQo+ID4gPiA+DQo+ID4gPiA+ IFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZSBp bmxpbmUgZm9yIHRoZSBESVNDVVNTIHBhcnQuIFdpbGwgc2VlIGlmL3doYXQNCj4gY2hhbmdlcw0K PiA+ID4gYXJlDQo+ID4gPiA+IG5lZWRlZCBmb3IgdGhlIENPTU1FTlQgcGFydC4NCj4gPiA+ID4N Cj4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBNZWQNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiBEZcKgOiBSb21hbiBEYW55bGl3IHZpYSBE YXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ID4gPiBFbnZvecOpwqA6DQo+ ID4gPiA+ID4gbWFyZGkgMTUgZMOpY2VtYnJlIDIwMjAgMjE6MDEgw4DCoDogVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+DQo+IENjwqA6DQo+ID4gPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1j YWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtDQo+ID4gPiBjaGFpcnNAaWV0Zi5vcmc7DQo+ID4gPiA+ ID4gZG90c0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47DQo+ ID4gPiA+ID4gdmFsZXJ5QHNteXNsb3YubmV0IE9iamV0wqA6IFJvbWFuIERhbnlsaXcncyBEaXNj dXNzIG9uDQo+ID4gPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWUtDQo+ID4g PiA+ID4gMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBSb21hbiBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KPiA+ID4gPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLTExOiBEaXNj dXNzDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZA0KPiByZXBseQ0KPiA+ID4gdG8NCj4gPiA+ID4gPiBh bGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVs DQo+IGZyZWUNCj4gPiA+IHRvDQo+ID4gPiA+ID4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiA+ ID4gPiA+IGNyaXRlcmlhLmh0bWwNCj4gPiA+ID4gPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQNCj4gcG9zaXRpb25zLg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlDQo+IGZvdW5kDQo+ID4gPiBoZXJlOg0KPiA+ID4gPiA+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtDQo+IGNhbGwt DQo+ID4gPiBob21lLw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLS0tDQo+ID4gPiAtLS0tDQo+ID4gPiA+ID4gLS0NCj4gPiA+ID4gPiBESVNDVVNT Og0KPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tDQo+ID4gPiAtLS0tDQo+ID4gPiA+ID4gLS0NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IEl0IHNlZW1zIHRvIG1lIHRoZXJlIGlzIGEgbWlzc2luZyBvcGVyYXRp b25hbCBndWlkYW5jZSBvcg0KPiA+ID4gPiA+IHVuZG9jdW1lbnRlZCBkZXBsb3ltZW50IGFzc3Vt cHRpb25zLiAgU2luY2UgdGhlIG1vdGl2YXRpb25hbA0KPiB1c2UNCj4gPiA+ID4gPiBjYXNlIHNl ZW1zIHRvIGJlIGhvbWUgbmV0d29ya3MgKHBlciBTZWN0aW9uIDEuMSksIEkgYXNzdW1lZA0KPiB0 aGF0DQo+ID4gPiB0aGUNCj4gPiA+ID4gPiBjYWxsIGhvbWUgc2VydmVycyBhcmUgcnVubmluZyBw cmltYXJpbHkgY29uc3VtZXIgZ3JhZGUNCj4gcm91dGVycw0KPiA+ID4gbm90DQo+ID4gPiA+ID4g bWFuYWdlZCBieSBwcm9mZXNzaW9uYWwgSVQgZXhwZXJ0aXNlLg0KPiA+ID4gPg0KPiA+ID4gPiBb TWVkXSBUaGUgZ2VuZXJhbGl6ZWQgYXBwbGljYWJpbGl0eSBzY29wZSBpcyB3aGF0IGlzIHNrZXRj aGVkDQo+IGluDQo+ID4gPiA+IFNlY3Rpb24gMy4gVGhlIHNvbHV0aW9uIGlzIG1lYW50IHRvIGJs b2NrIGF0dGFja3MgY2xvc2UgdG8NCj4gdGhlaXINCj4gPiA+IHNvdXJjZS4gVGhpcyBjYW4gYmU6 DQo+ID4gPiA+IC0gdGhlIGhvbWUgY2FzZSwNCj4gPiA+ID4gLSBhbiBlbnRlcnByaXNlIG5ldHdv cmssDQo+ID4gPiA+IC0gYSB0cmFuc2l0IHByb3ZpZGVyIGZpbHRlcmluZyBhdHRhY2tzIGZyb20g bGVhZiBuZXR3b3JrcywNCj4gPiA+ID4gLSBhIHByb3ZpZGVyIGZpbHRlcmluZyBhdHRhY2tzIGZy b20gZGF0YSBjZW50ZXJzLA0KPiA+ID4gPiAtIGV0Yy4NCj4gPiA+ID4NCj4gPiA+ID4gRm9yIHRo ZSBwYXJ0aWN1bGFyIGNhc2Ugb2YgaG9tZSBuZXR3b3JrcywgdGhpcyBjYW4gYmUgcGFydCBvZg0K PiA+ID4gc2VydmljZXMNCj4gPiA+ID4gc3VwcG9ydGVkIGJ5IGEgSVNQLW1hbmFnZWQgQ1BFIG9y IGEgbWFuYWdlZCBzZWN1cml0eSBzZXJ2aWNlDQo+ID4gPiBzdWJzY3JpYmVkIGJ5IHRoZSB1c2Vy Lg0KPiA+ID4gPg0KPiA+ID4gPiBXZSBjb3VsZCBtZW50aW9uIHRoYXQgaW4gdGhlIGRvY3VtZW50 LCBidXQgd2UgZGlkbid0IGJlY2F1c2UNCj4gdGhpcw0KPiA+ID4gYXJlDQo+ID4gPiA+IGRlcGxv eW1lbnQtc3BlY2lmaWMuIFJlYWxseS4NCj4gPiA+ID4NCj4gPiA+ID4gT3RoZXIgdGhhbiB0aGUg aW50cm9kdWN0aW9uLCB3ZSBkb24ndCB3YW50IHRvIG92ZXJsb2FkIHRoZQ0KPiA+ID4gZG9jdW1l bnQNCj4gPiA+ID4gd2l0aCBob21lLXNwZWNpZmljIGNvbnNpZGVyYXRpb25zLg0KPiA+ID4NCj4g PiA+IEkgc3RpbGwgdGhpbmsgd2UgbmVlZCBhIGJpdCBtb3JlIHByZWNpc2lvbi4gIEkgZG9uJ3Qg ZGlzcHV0ZSB0aGUNCj4gPiA+IGdlbmVyYWwgdXRpbGl0eSBvZiB0aGlzIGFwcHJvYWNoIHRvIGEg dmFyaWV0eSBvZiBlbnZpcm9ubWVudHMuDQo+IEkgZG8NCj4gPiA+IHNlZSB0aGUgdHdvIHNlbnRl bmNlcyBpbiB0aGUgZW50aXJlIGRvY3VtZW50IHdoaWNoIHNheSB0aGF0IHRoaXMNCj4gaXMNCj4g PiA+IGEgZ2VuZXJhbCBwdXJwb3NlIGFwcHJvYWNoOg0KPiA+ID4NCj4gPiA+IEFic3RyYWN0OiBU aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBDYWxsIEhvbWUgaXMgbm90IHNwZWNpZmljIHRvDQo+IGhv bWUNCj4gPiA+IG5ldHdvcmtzOw0KPiA+ID4gICAgdGhlIHNvbHV0aW9uIHRhcmdldHMgYW55IGRl cGxveW1lbnQgaW4gd2hpY2ggaXQgaXMgcmVxdWlyZWQNCj4gdG8NCj4gPiA+IGJsb2NrDQo+ID4g PiAgICBERG9TIGF0dGFjayB0cmFmZmljIGNsb3NlciB0byB0aGUgc291cmNlKHMpIG9mIGEgRERv UyBhdHRhY2suDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzOiAiVGhlIGFmb3JlbWVudGlvbmVkIHBy b2JsZW1zIG1heSBiZSBlbmNvdW50ZXJlZCBpbg0KPiBvdGhlcg0KPiA+ID4gZGVwbG95bWVudHMN Cj4gPiA+ICAgIHRoYW4gdGhvc2UgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMS4xIChlLmcuLCBkYXRh IGNlbnRlcnMsDQo+ID4gPiBlbnRlcnByaXNlDQo+ID4gPiAgICBuZXR3b3JrcykuIg0KPiA+ID4N Cj4gPiA+IEhvd2V2ZXIsIEkgd2lsbCByZWl0ZXJhdGUgdGhhdCBhbG1vc3Qgbm8gY29uc2lkZXJh dGlvbiBpcyBtYWRlDQo+IHRvDQo+ID4gPiBkaXN0aW5ndWlzaCB0aGVzZSB1c2UgY2FzZXMgaW4g dGhlIG5hcnJhdGl2ZSB0ZXh0LiAgVGhlIGVudGlyZQ0KPiA+ID4gbW90aXZhdGlvbiBmb3IgdGhl IHdvcmsgaW4gU2VjdGlvbiAxLjAgaXMgdGhyb3VnaCB0aGUgbGVucyBvZg0KPiA+ID4gbmV0d29y a3Mgbm90IG1hbmFnZWQgYnkgcHJvZmVzc2lvbmFscyAoaG9tZSBuZXR3b3JrcykuDQo+IEZ1cnRo ZXJtb3JlLA0KPiA+ID4gdGhlIGV4cGxhbmF0aW9uIG9mIHRoZSBzb2x1dGlvbiBpbiBTZWN0aW9u IDEuMSwgNS4xIGFuZCBBcHBlbmRpeA0KPiBBDQo+ID4gPiBpcyBkb25lIHRocm91Z2ggdGhlIGxl bnMgb2YgYSAiaG9tZSBuZXR3b3JrIi4gIEZvciB0aGlzIHJlYXNvbiwNCj4gSSdtDQo+ID4gPiBw dXNoaW5nIHRvIG1ha2Ugc3VyZSB0aGUgZWRnZXMgb2YgdGhhdCBkZXBsb3ltZW50IGVudmlyb25t ZW50DQo+IGFyZQ0KPiA+ID4gY292ZXJlZC4NCj4gPiA+DQo+ID4gPiBJIHdvdWxkIGFzc2VydCB0 aGF0IG1vc3Qgb2YgdGhlIGJlaGF2aW9yIGRlc2NyaWJlZCBiZWxvdw0KPiByZXF1aXJlcw0KPiA+ ID4gdGhhdCBwcm9mZXNzaW9uYWwgSVQgZXhwZXJ0aXNlIChsZXQgbWUga25vdyBpZiB5b3UgdGhp bmsgSSBoYXZlDQo+IGl0DQo+ID4gPiB3cm9uZykuICBJJ20gbG9va2luZyBwcmltYXJpbHkgZm9y IGEgZmV3IHBpZWNlcyBvZiBjbGFyaWZ5aW5nDQo+IHRleHQ6DQo+ID4gPiAoMSkgYSBzdWdnZXN0 aW9uL2Fja25vd2xlZGdlbWVudCB0aGF0IENQRXMgdXNpbmcgdGhpcyBzcGVjIGluDQo+IHRoZQ0K PiA+ID4gaG9tZSBlbnZpcm9ubWVudCBhcmUgbGlrZWx5IHRvIGJlIG1hbmFnZWQsIHByb3Zpc2lv bmVkLCBpc3N1ZWQNCj4gKD8pDQo+ID4gPiBieSBhbiBJU1AgKHRoaXMgYWRkcmVzc2VzIHdoZXJl IHRoZXJlIHByb2Zlc3Npb25hbCBJVCBleHBlcnRpc2UNCj4gaXMNCj4gPiA+IGNvbWluZyBmcm9t KQ0KPiA+ID4gKDIpIGFzc3VtaW5nICgxKSBpcyB0cnVlLCBkaXN0aW5ndWlzaGluZyB0aGUgdmFy aW91cw0KPiA+ID4gTVVTVC9TSE9VTEQvTUFZcyBhZG1pbiBiZWhhdmlvcnMgdGhhdCBpbnZvbHZl IHRoZSBJU1AgdnMuIHRoZQ0KPiBhY3R1YWwNCj4gPiA+IGh1bWFucyBvbiB0aGUgaG9tZSBuZXR3 b3JrDQo+ID4gPg0KPiA+ID4gTm90ZTogZXZlcnl0aGluZyBlbHNlIGJlbG93IGlzIGp1c3QgbW9y ZSBkZXRhaWxlZCBjb21tZW50YXJ5IG9uDQo+IHRoaXMNCj4gPiA+IHRoZW1lIGFib3ZlLiAgSSdk IHN1bW1hcml6ZSBldmVyeXRoaW5nIEkndmUgc2FpZCBoZXJlIGJ5IHNheWluZw0KPiBJDQo+ID4g PiB0aGluayB3ZSBuZWVkIG1vcmUgZmluZXNzZSBpbiBkZXNjcmliaW5nIHRoZSBvcGVyYXRpb25h bA0KPiA+ID4gY29uc2lkZXJhdGlvbnMgYW5kIHdobyBpcyBleHBlY3RlZCB0byB0YWtlIHJlc3Bv bnNpYmlsaXR5IGZvcg0KPiB0aGVtDQo+ID4gPiAocmVhbGl6aW5nIHRoZXJlIHdpbGwgYmUgYSBk aXZlcnNpdHkgb2YgZW52aXJvbm1lbnRzKS4gIEhvd2V2ZXIsDQo+ID4gPiBzaW5jZSB0aGVyZSBh cmUgbXVsdGlwbGUgdXNlIGNhc2VzLCBJTU8sIHRoZXkgZGVzZXJ2ZSB1bmlxdWUNCj4gPiA+IGNv bnNpZGVyYXRpb24gd2hlbiB0aGV5IGFyZSBkaWZmZXJlbnQgZnJvbSBlYWNoIG90aGVyLg0KPiA+ ID4NCj4gPiA+ID4gICBJZiB0aGF0IGFzc3VtcHRpb24gaXMgdHJ1ZQ0KPiA+ID4gPiA+IChhbmQg aXQgc2hvdWxkIGJlIGRvY3VtZW50ZWQgaWYgdGhhdCBpcyB0aGUgY2FzZSksIHRoZW4gSQ0KPiBm aW5kDQo+ID4gPiBtYW55DQo+ID4gPiA+ID4gb2YgdGhlIG9wZXJhdGlvbmFsIHJlY29tbWVuZGF0 aW9ucyBub3QgY29uZ3J1ZW50IHdpdGggdGhhdA0KPiA+ID4gZW52aXJvbm1lbnQuDQo+ID4gPiA+ ID4gU3BlY2lmaWNhbGx5LCB0aGUgZGVncmVlIG9mIGludGVyYWN0aW9uIGFuZCB0dW5pbmcgc2Vl bXMNCj4gb3V0c2lkZQ0KPiA+ID4gdGhlDQo+ID4gPiA+ID4gcmVhbG0gb2YgZXhwZXJ0aXNlIG9m IHNvbWVvbmUgd2l0aG91dCBJVCB0cmFpbmluZyBhbmQNCj4gPiA+IGNhcGFiaWxpdGllcw0KPiA+ ID4gPiA+IG9mIGhvbWUgbmV0d29yayBlY29zeXN0ZW0uICBJbiBwYXJ0aWN1bGFyOg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gLS0gU2VjdGlvbiAxLjINCj4gPiA+ID4gPiBUaGUgQ2FsbCBIb21lIERP VFMgc2VydmVyIHVzZXMgdGhlIEREb1MgYXR0YWNrIHRyYWZmaWMNCj4gPiA+IGluZm9ybWF0aW9u IHRvDQo+ID4gPiA+ID4gICAgaWRlbnRpZnkgdGhlIGNvbXByb21pc2VkIGRldmljZSBpbiBpdHMg ZG9tYWluIHRoYXQgaXMNCj4gPiA+IHJlc3BvbnNpYmxlDQo+ID4gPiA+ID4gZm9yDQo+ID4gPiA+ ID4gICAgbGF1bmNoaW5nIHRoZSBERG9TIGF0dGFjaywgb3B0aW9uYWxseSBub3RpZmllcyBhIG5l dHdvcmsNCj4gPiA+ID4gPiAgICBhZG1pbmlzdHJhdG9yLCBhbmQgdGFrZXMgYXBwcm9wcmlhdGUg bWl0aWdhdGlvbg0KPiBhY3Rpb24ocykuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBIb3cgd291bGQg c3VjaCBub3RpZmljYXRpb24gd29yaz8NCj4gPiA+ID4NCj4gPiA+ID4gW01lZF0gVGhpcyB3aWxs IGRlcGVuZCBvbiB0aGUgZGVwbG95bWVudCAoaG9tZSwgZW50ZXJwcmlzZSwNCj4gREMsDQo+ID4g PiBhY2Nlc3MNCj4gPiA+ID4gcHJvdmlkZXIsIHBlZXIgdHJhbnNpdCBwcm92aWRlciwgZXRjLiku IFRoaXMgY2FuIGJlIHVzaW5nIERPVFMNCj4gPiA+ICh0aGUNCj4gPiA+ID4gYWRtaW5pc3RyYXRv ciBoYXMgYSBjYWxsIGhvbWUgZG90cyBzZXJ2ZXIgYXBwKSwgYSBwdXNoIGZyb20NCj4gdGhlDQo+ ID4gPiBhcHANCj4gPiA+ID4gdXNlIGZvciBtYW5hZ2luZyB0aGUgQ1BFLCBzeXNsb2csIHNubXAs IG5ldGNvbmYsIGFuIFNNUywgZXRjLg0KPiA+ID4NCj4gPiA+IEkgdW5kZXJzdGFuZCB0aGlzIGFu c3dlciBpbiB0aGUgY29udGV4dCBvZiB0aGUgZW50ZXJwcmlzZSB1c2UNCj4gY2FzZS4NCj4gPiA+ IEhvdyB3b3VsZCB0aGlzIGhhcHBlbiBmb3IgdGhlIGhvbWUgdXNlciAobm9uLXByb2Zlc3Npb25h bCBJVA0KPiA+ID4gcGVyc29uKT8NCj4gPiA+DQo+ID4gPiBJZiB0aGlzIGFuIGluc3RhbmNlIHdo ZXJlIGlmIHRoZSBDUEUgaXMgbWFuYWdlZCBvbiBiZWhhbGYgYSB0aGUNCj4gPiA+IHVzZXIsIHBl cmhhcHMgc2F5aW5nIGFuIG91dC1vZi1zY29wZSBtZWNoYW5pc21zIChhcHAsIFNNUykgbmVlZHMN Cj4gdG8NCj4gPiA+IGJlIHByb3ZpZGVkIGZvciB0aGUgZW5kLXVzZXIgKGhvbWUgdXNlcik/DQo+ ID4gPg0KPiA+ID4gPiBBcyB5b3UgY2FuIHNlZSBhIHZhcmlldHkgb2YgdG9vbHMgY2FuIGJlIGNv bnNpZGVyZWQgYXMgYQ0KPiBmdW5jdGlvbg0KPiA+ID4gb2YNCj4gPiA+ID4gdGhlIGxvY2FsIGRl cGxveW1lbnQgY2FzZS4gTm9uZSBvZiB0aGVtIGlzIGNhbGxlZCBvdXQgaW4gdGhlDQo+IHRleHQN Cj4gPiA+IGFzDQo+ID4gPiA+IHRoaXMgaXMgZGVwbG95bWVudC0gc3BlY2lmaWMuIE5vdCBhbGwg b2YgdGhlbSBhcmUgYXBwbGljYWJsZQ0KPiBmb3INCj4gPiA+IGVhY2ggZGVwbG95bWVudCBjYXNl Lg0KPiA+ID4NCj4gPiA+IE1ha2Ugc2Vuc2UuICBQZXJoYXBzIHNvbWUgZGV0YWlscyBkaXN0aW5n dWlzaGluZyB0aGUgZ3VpZGFuY2UNCj4gcGVyDQo+ID4gPiB0aGUgdXNlIGNhc2VzIGNvdWxkIGhl bHAuDQo+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0gU2VjdGlvbiAxLjIgYW5kIDUuMS4g IExlYXZlcyBjcmVkZW50aWFscyBjb25maWd1cmF0aW9uIGFzDQo+IG91dA0KPiA+ID4gb2YNCj4g PiA+ID4gPiBzY29wZS4NCj4gPiA+ID4NCj4gPiA+ID4gW01lZF0gVGhhdCBpcyBhbGlnbmVkIHdp dGggaG93IGNyZWRlbnRpYWxzIGFyZSBoYW5kbGVkIGluIHRoZQ0KPiBiYXNlDQo+ID4gPiA+IHNw ZWMgKFJGQzg3ODIpLg0KPiA+ID4gPg0KPiA+ID4gPiA+IFNlY3Rpb24gMS4yIHJlZmVyZW5jZXMg W0ktRC5pZXRmLWRvdHMtc2VydmVyLWRpc2NvdmVyeV0gZm9yDQo+ID4gPiA+ID4gcHJvdmlzaW9u aW5nLiAgSW4gdHVybiwgU2VjdGlvbiAxIG9mIFtJLUQuaWV0Zi5zZXJ2ZXItDQo+IGRpc2NvdmVy eV0NCj4gPiA+ID4gPiBhbHNvIGRlY2xhcmVzIHRoaXMgcHJvYmxlbSBvdXQgb2Ygc2NvcGUgYnkg c2F5aW5nIOKAnFRoaXMNCj4gZG9jdW1lbnQNCj4gPiA+ID4gPiBhc3N1bWVzIHRoYXQgc2VjdXJp dHkgY3JlZGVudGlhbHMgdG8gYXV0aGVudGljYXRlIERPVFMNCj4gc2VydmVyKHMpDQo+ID4gPiBh cmUNCj4gPiA+ID4gPiBwcmUtcHJvdmlzaW9uZWQgdG8gYSBET1RTIGNsaWVudCB1c2luZyBhIG1l Y2hhbmlzbSBzdWNoIGFzDQo+IChidXQNCj4gPiA+IG5vdA0KPiA+ID4gPiA+IGxpbWl0ZWQgdG8p IHRob3NlIGRpc2N1c3NlZCBpbiBbUkZDODU3Ml0gb3IgW0ktRC5pZXRmLWFuaW1hLQ0KPiA+ID4g PiA+IGJvb3RzdHJhcHBpbmcta2V5aW5mcmFd4oCdLiAgSG93ZXZlciwgUkZDODU3MiBzZWVtcyB0 byByZWx5IG9uDQo+ID4gPiBORVRDT05GDQo+ID4gPiA+ID4gYW5kIFJFU1RDT05GIHdoaWNoIHNl ZW1zIGxpa2UgYSByYXRoZXIgdW5jb21tb24gZmVhdHVyZSBvZg0KPiBob21lDQo+ID4gPiA+ID4g cm91dGVycy4gIEJSS1NJIHJlbGllcyBvbiBhIG1hbnVmYWN0dXJlciBzdXBwbGllZC9jb250cmFj dGVkDQo+ID4gPiA+ID4gaW5mcmFzdHJ1Y3R1cmUgYW5kIGtleXN0b3JlcyB0aGF0IGFsc28gc2Vl bSB1bmNvbW1vbiBmb3INCj4gPiA+IGNvbnN1bWVyDQo+ID4gPiA+ID4gZ3JhZGUgZXF1aXBtZW50 Lg0KPiA+ID4gPg0KPiA+ID4gPiBbTWVkXSBUaGVzZSBhcmUgbm90IG1lYW50IHRvIGJlIHJlY29t bWVuZGF0aW9ucy4gVGhlc2UNCj4gZXhhbXBsZXMNCj4gPiA+IG1heSBiZQ0KPiA+ID4gPiBPSyBm b3Igc29tZSBkZXBsb3ltZW50cywgYnV0IG5vdCBhcHByb3ByaWF0ZSBmb3Igb3RoZXJzLg0KPiA+ ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0gU2VjdGlvbiA1LjMuMS4NCj4gPiA+ID4gPiBU aGUgQ2FsbCBIb21lIERPVFMgc2VydmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIGNvbnNlbnQgTUFZ DQo+IGJlDQo+ID4gPiA+ID4gICAgcmVxdWlyZWQgdG8gYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0 aGUgY29tcHJvbWlzZWQgZGV2aWNlDQo+IHRvDQo+ID4gPiB0aGUNCj4gPiA+ID4gPiAgICBhdHRh Y2sgdGFyZ2V0LiAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGhhdmUgYQ0KPiBjb25maWd1cmF0aW9u DQo+ID4gPiBrbm9iIHRvDQo+ID4gPiA+ID4gICAgYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0aGUg Y29tcHJvbWlzZWQgZGV2aWNlIHRvIHRoZQ0KPiBhdHRhY2sNCj4gPiA+IHRhcmdldA0KPiA+ID4g PiA+ICAgIHdpdGggb3Igd2l0aG91dCBET1RTIHNlcnZlciBkb21haW4gYWRtaW5pc3RyYXRvciBj b25zZW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIHN1Z2dlc3Rpb24gaGVyZSBzZWVtcyB0 byBiZSB0aGF0IGNvbnN1bWVycyBhcmUgYWNxdWlyaW5nDQo+ID4gPiBkZXZpY2VzDQo+ID4gPiA+ ID4gdGhhdCBjYW4gYmUgcmVtb3RlbHkgcmVjb25maWd1cmVkIHdpdGggb3V0IGEgZGVmaW5lZCB0 cnVzdA0KPiA+ID4gbW9kZWw/DQo+ID4gPiA+DQo+ID4gPiA+IFtNZWRdIENhbiB5b3UgcGxlYXNl IGNsYXJpZnkgd2hpY2ggc3VnZ2VzdGlvbiBhcmUgeW91DQo+IHJlZmVycmluZw0KPiA+ID4gdG8/ DQo+ID4gPg0KPiA+ID4gSSdtIHdvbmRlcmluZyB3aG8gdGhlICJzZXJ2ZXIgZG9tYWluIGFkbWlu aXN0cmF0b3IiIGlzIGFuZCBob3cNCj4gdGhleQ0KPiA+ID4gYXJlIGV4cGVjdGVkIHRvIGNvbnNl bnQgaW4gdGhlIGhvbWUgdXNlciBzY2VuYXJpbz8NCj4gPiA+DQo+ID4gPiA+IFRoZSB0ZXh0IHlv dSBxdW90ZWQgaXMgcmVmZXJyaW5nIHRvIGJsb2NraW5nIHRyYWZmaWMgZnJvbQ0KPiBkZXZpY2Vz DQo+ID4gPiB0aGF0DQo+ID4gPiA+IGFyZSBpbmplY3RpbmcgRERvUyB0cmFmZmljIGZyb20gd2l0 aGluIGEgZG9tYWluLiBUaGVzZSBkZXZpY2VzDQo+IGNhbg0KPiA+ID4gYmUNCj4gPiA+ID4gYW4g SVAgY2FtZXJhLCBhbiBpbmZlY3RlZCBQQywgZXRjLg0KPiA+ID4gPg0KPiA+ID4gPiA+IFNvbWUg cG9saWN5IG9yIG9wZXJhdGlvbmFsIGNvbnRleHQgc2VlbXMgYXBwcm9wcmlhdGUgaGVyZS4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IC0tIFNlY3Rpb24gNS4zLjENCj4gPiA+ID4gPiAuLi4gbm90aWZp ZXMgdGhlIENQRQ0KPiA+ID4gPiA+ICAgIGFkbWluaXN0cmF0b3IgYWJvdXQgdGhlIGNvbXByb21p c2VkIGRldmljZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gTm90aWZ5IGhvdz8NCj4gPiA+ID4NCj4g PiA+ID4gW01lZF0gU2VlIGFib3ZlLg0KPiA+ID4NCj4gPiA+IExpa2UgSSBub3RlZCBhYm92ZSwg aWYgSSdtIGEgaG9tZSB1c2VyLCBob3cgYW0gSSBsaWtlbHkgdG8gZ2V0DQo+IHRoYXQNCj4gPiA+ IG5vdGlmaWNhdGlvbj8NCj4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtLSBTZWN0aW9uIDgu DQo+ID4gPiA+ID4gQXBwcm9wcmlhdGUNCj4gPiA+ID4gPiAgICBmaWx0ZXJzIChlLmcuLCBhY2Nl c3MgY29udHJvbCBsaXN0cykgY2FuIGJlIGluc3RhbGxlZCBvbg0KPiB0aGUNCj4gPiA+IENhbGwN Cj4gPiA+ID4gPiAgICBIb21lIERPVFMgc2VydmVyIGFuZCBuZXR3b3JrIGJldHdlZW4gdGhlIENh bGwgSG9tZSBET1RTDQo+ID4gPiBhZ2VudHMgc28NCj4gPiA+ID4gPiAgICB0aGF0IG9ubHkgY29t bXVuaWNhdGlvbnMgZnJvbSBhIHRydXN0ZWQgQ2FsbCBIb21lIERPVFMNCj4gY2xpZW50DQo+ID4g PiB0bw0KPiA+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ICAgIENhbGwgSG9tZSBET1RTIHNlcnZlciBh cmUgYWxsb3dlZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgc2VlbXMgbGlrZSBhIGxldmVs IG9mIHNvcGhpc3RpY2F0aW9uIGJleW9uZCB5b3VyDQo+IGF2ZXJhZ2UNCj4gPiA+IGhvbWUNCj4g PiA+ID4gPiByb3V0ZXIgdXNlciBhbmQgYSBwbGFjZSB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgc2hv dWxkDQo+IGNvbnNpZGVyIGENCj4gPiA+ID4gPiBzZWN1cmUgZGVmYXVsdHMuDQo+ID4gPiA+DQo+ ID4gPiA+IFtNZWRdIFRoaXMgZmlsdGVyaW5nIGNhbiBiZSBhdXRvbWF0aWNhbGx5IHNldCBiYXNl ZCBvbiB0aGUNCj4gPiA+IGNvbmZpZ3VyZWQNCj4gPiA+ID4gbGlzdCBvZiBDYWxsIEhvbWUgRE9U UyBjbGllbnRzLiBUaGlzIGlzIGEgd2lkZWx5IHVzZWQgcHJhY3RpY2UNCj4gPiA+ICh0aGluaw0K PiA+ID4gPiBhYm91dCBTSVAgcHJveHkgc2VydmVycywgZXhhbXBsZSkuIE5vIGludGVydmVudGlv biBtYXkgYmUNCj4gcmVxdWlyZWQNCj4gPiA+IGZyb20gdGhlIHVzZXIuDQo+ID4gPg0KPiA+ID4g QWdyZWVkLiAgSG93ZXZlciwgdGhpcyBpcyBhc3N1bWluZyB0aGF0IHNvbWVvbmUgaXMgbWFuYWdp bmcgdGhhdA0KPiA+ID4gY29uZmlndXJhdGlvbi4gIE15IHBvaW50IGlzIHRoYXQgaW4gdGhlIGhv bWUgdXNlciBzcGFjZSB0aGF0IGlzDQo+IG1vc3QNCj4gPiA+IGxpa2VseSB0aGUgSVNQLCBzbyBs ZXQncyBqdXN0IHNheSB0aGF0Lg0KPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC0tIFNlY3Rp b24gOC4NCj4gPiA+ID4gPiBDYWxsIEhvbWUgRE9UUyBzZXJ2ZXJzIGNhbiBhbHNvIHNlZWsgdGhl IGNvbnNlbnQgb2YgRE9UUw0KPiA+ID4gPiA+ICAgIHNlcnZlciBkb21haW4gYWRtaW5pc3RyYXRv ciB0byBibG9jayB0aGUgdHJhZmZpYyBmcm9tIHRoZQ0KPiA+ID4gPiA+IHBvdGVudGlhbGx5DQo+ ID4gPiA+ID4gICAgY29tcHJvbWlzZWQgZGV2aWNlIHRvIHRoZSB0YXJnZXQgKHNlZSBTZWN0aW9u IDUuMy4xKS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdoYXQgd291bGQgYmUgdGhlIG1lYW5zIHRv IGdhaW4gc3VjaCBjb25zZW50Pw0KPiA+ID4gPg0KPiA+ID4gPiBbTWVkXSBUaGlzIHdpbGwgZGVw ZW5kIG9uIHRoZSBkZXBsb3ltZW50IGNhc2U6IHRoaXMgY2FuIGJlIGFuDQo+ID4gPiBhY3Rpb24N Cj4gPiA+ID4gZXhlY3V0ZWQgdXNpbmcgYW4gYXBwLCBhIGNvbmZpcm1hdGlvbiB0byBhIG5vdGlm aWNhdGlvbg0KPiBtZXNzYWdlLA0KPiA+ID4gZXRjLg0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gLS0gU2VjdGlvbiA5Lg0KPiA+ID4gPiA+IE5vdGUgdGhhdCBhIENhbGwgSG9tZSBET1RT IHNlcnZlciBjYW4gc2VlayBhbg0KPiBhZG1pbmlzdHJhdG9yJ3MNCj4gPiA+ID4gPiAgICBjb25z ZW50LCB2YWxpZGF0ZSB0aGUgcmVxdWVzdCBieSBpbnNwZWN0aW5nIHRoZSByZWxldmFudA0KPiA+ ID4gdHJhZmZpYw0KPiA+ID4gPiA+IGZvcg0KPiA+ID4gPiA+ICAgIGF0dGFjayBzaWduYXR1cmVz LCBvciBwcm9jZWVkIHdpdGggYm90aCBjb3Vyc2VzIG9mDQo+IGFjdGlvbi4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEFzIGFib3ZlLg0KPiA+ID4gPg0KPiA+ID4gPiBbTWVkXSBBcyBhYm92ZSA6LSkN Cj4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC0tIFNlY3Rpb24gOS4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+ICAgICBUaGUgRE9UUyBDYWxsIEhvbWUgaXMgb25seSBhZHZpc29yeSBpbiBuYXR1 cmUuDQo+IENvbmNyZXRlbHksDQo+ID4gPiB0aGUNCj4gPiA+ID4gPiBET1RTDQo+ID4gPiA+ID4g ICAgQ2FsbCBIb21lIGRvZXMgbm90IGltcG9zZSBhbnkgYWN0aW9uIHRvIGJlIGVuZm9yY2VkDQo+ IHdpdGhpbg0KPiA+ID4gdGhlDQo+ID4gPiA+ID4gICAgbmV0d29yayBob3N0aW5nIGFuIGF0dGFj ayBzb3VyY2U7IGl0IGlzIHVwIHRvIHRoZSBDYWxsDQo+IEhvbWUNCj4gPiA+IERPVFMNCj4gPiA+ ID4gPiAgICBzZXJ2ZXIgKGFuZC9vciBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIHRvIGRlY2lkZSB3 aGV0aGVyDQo+IGFuZA0KPiA+ID4gd2hpY2gNCj4gPiA+ID4gPiAgICBhY3Rpb25zIGFyZSByZXF1 aXJlZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFN1Y2ggYSBkZWNpc2lvbnMgc2VlbXMgb3V0IGJl eW9uZCB0aGUgYWJpbGl0eSBvZiB5b3VyDQo+IGF2ZXJhZ2UNCj4gPiA+IGhvbWUNCj4gPiA+ID4g PiByb3V0ZXIgdXNlci4NCj4gPiA+ID4NCj4gPiA+ID4gW01lZF0gV2UgZG9uJ3QgaGF2ZSB0aGUg bm90aW9uIG9mICJhdmVyYWdlIGhvbWUgcm91dGVyIHVzZXIiDQo+IDstKQ0KPiA+ID4NCj4gPiA+ IEFncmVlZC4gIFByb2JhYmx5IG5vdCB1cyB0aG91Z2ggOi0pLiAgTXkgaW50ZW50IHdhcyB0byBz YXkgdGhhdA0KPiB3aGVuDQo+ID4gPiB0aGUgYWN0aW9ucy9kZWNpc2lvbnMgYXJlIGJlaW5nIGZy YW1lZCBhcyBiZWluZyBmb3IgYSAibmV0d29yaw0KPiA+ID4gYWRtaW4iLCB0aGF0IHRvIG1lIHN1 Z2dlc3RzIGEgbGV2ZWwgZXhwZXJ0aXNlIG91dHNpZGUgb2YgdGhlDQo+ID4gPiBjYXBhYmlsaXR5 IG9mIHR5cGljYWwgZW5kIGNvbnN1bWVyIHdpdGhvdXQgcHJvZmVzc2lvbmFsIElUDQo+ID4gPiBk ZWNpc2lvbnMuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IFJvbWFuDQo+ID4gPg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gLS0gU2VjdGlvbiA4ICDigJwuLi4gZXhwbGljaXQgcG9saWN5IChl LmcuLCB0aGUgQ2FsbCBIb21lIERPVFMNCj4gPiA+IGNsaWVudA0KPiA+ID4gPiA+IGFuZCBzZXJ2 ZXIgYXJlIG1hbmFnZWQgYnkgdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZW50aXR5KSwNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IElzIHRoZXJlIGFuIHVuZGVybHlpbmcgYXNzdW1wdGlvbiB0aGF0IHRo ZSBJU1AgaXMgbWFuYWdpbmcNCj4gdGhlDQo+ID4gPiBkZXZpY2U/DQo+ID4gPiA+DQo+ID4gPiA+ IFtNZWRdIElTUCBtYW5hZ2VkIGRldmljZXMgaXMgb25lIHR5cGljYWwgZGVwbG95bWVudCBjYXNl Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGF0J3Mgc2FpZCwgdGhlIHRleHQgeW91IHF1b3RlZCBpcyBu b3Qgc3BlY2lmaWMgdG8gSVNQcy4gSXQNCj4gPiA+IGFwcGxpZXMsDQo+ID4gPiA+IGZvciBleGFt cGxlLCB3aGVuIGdhdGV3YXlzIGFyZSBvbiB0aGUgcGF0aCBhbmQgYm90aCB0aGUgQ2FsbA0KPiBI b21lDQo+ID4gPiBET1RTDQo+ID4gPiA+IHNlcnZlciBhbmQgQ2FsbCBIb21lIERPVFMgY2xpZW50 IHdpbGwgdGh1cyBiZSBtYW5hZ2VkIGJ5IHRoZQ0KPiBEQw0KPiA+ID4gPiBwcm92aWRlciwgdGhl IGVudGVycHJpc2UgYWRtaW5pc3RyYXRvciwgdGhlIGFjY2VzcyBwcm92aWRlciwNCj4gZXRjLg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+ID4NCj4gPiA+ID4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMNCj4gaW5mb3JtYXRpb25zDQo+ID4gPiA+IGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+ID4gPiBkaWZmdXNlcywN Cj4gPiA+ID4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UNCj4gPiA+IG1lc3NhZ2UNCj4gPiA+ID4gcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUNCj4gPiA+IGFpbnNpDQo+ ID4gPiA+IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50DQo+ID4gPiBzdXNjZXB0aWJsZXMNCj4gPiA+ID4gZCdhbHRlcmF0aW9uLCBPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZQ0KPiBtZXNzYWdlIGENCj4gPiA+IGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+ID4gPg0KPiA+ID4gPiBU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3INCj4gPiA+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3OyB0aGV5DQo+IHNob3VsZA0KPiA+ID4gbm90DQo+ID4gPiA+IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gPiA+IElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlDQo+IHNl bmRlcg0KPiA+ID4gYW5kDQo+ID4gPiA+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCj4gPiA+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMNCj4gdGhhdA0KPiA+ID4gaGF2ZQ0KPiA+ID4gPiBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiA+ID4gVGhhbmsgeW91Lg0KPiA+ID4g Pg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+ID4gPiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBEb3RzQGlldGYub3JnDQo+ID4g PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+DQo+ID4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gX18NCj4gPiBfX19fIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPiBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0KPiBkaWZm dXNlcywNCj4gPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZQ0KPiBtZXNzYWdlDQo+ID4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUNCj4gYWluc2kNCj4gPiBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudA0KPiBzdXNj ZXB0aWJsZXMNCj4gPiBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYQ0KPiBldGUNCj4gPiBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLg0KPiA+DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZA0KPiBub3QNCj4gPiBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlcg0KPiBhbmQNCj4gPiBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQo+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdA0KPiBoYXZlDQo+ID4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQo+ID4gVGhhbmsgeW91Lg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Jan 4 08:56:38 2021 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 85FB83A0E7E; Mon, 4 Jan 2021 08:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.72 X-Spam-Level: X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=HhW3gPom; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zwNqaJ3a 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 gKIgk-wsnsQL; Mon, 4 Jan 2021 08:56:29 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45713A0E7C; Mon, 4 Jan 2021 08:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32834; q=dns/txt; s=iport; t=1609779388; x=1610988988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FAHEDt1wpOOM3Il2u8gnDrc7sqQQrH7ieAtQLKZkP0k=; b=HhW3gPomCI+kWAOQ4+f9WmB2z/mSabWkPmTw5Zj6ZVTwDyFfRJLC3Gxa +9SgdaosDwz9YNuMvurcy+HLQiObsFfVW/Z9abwR+IeCyWl2fb0smr2m/ PJhSZajHG4WTyZ0o5UjmNMoD2Z2vkLrfe9+1iggIi3oYlxM/7JLQw6nS9 g=; X-IPAS-Result: =?us-ascii?q?A0DzAABDR/NfkIwNJK1YChsBAQEBAQEBAQUBAQESAQEBA?= =?us-ascii?q?wMBAQFAgU+BU1F9Wy8uCoQ1g0gDjWQDgQWOB4oBgUKBEQNUCwEBAQ0BARgLC?= =?us-ascii?q?gIEAQGESgIXgVgCJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhgsBA?= =?us-ascii?q?SsMhXMBAQEDAQEBEAgJEQwBASkBAggDAQsEAgEIEQEDAQEDAhESAwICAiULF?= =?us-ascii?q?AECBggCBAENBQgTAQaDBAGCVQMOIAEDC6QlAoE8iGl2gTKDBAEBBoFHQYJ7G?= =?us-ascii?q?IIQAwaBDiqCdYN8gkaBS3gogQcmG4FBP4ERQ4IhNT6CXQEBAgEBFX8SAQcEB?= =?us-ascii?q?wEJGj2CWTSCLIFPCwEOKAQUGQdfBAsJDhkWAgoDEwEuAQsGEggEBA0HKwcJE?= =?us-ascii?q?B0CAQ4CEgULBAkvjxwKDwMHEguDB5NekCyBEQqCdokqjRWFO4MpiiuUfJQLi?= =?us-ascii?q?xCRKS4LBAmENAIEAgQFAg4BAQaBbSFpWBEHcBU7gmlQFwINVkAFhmWGIQcFD?= =?us-ascii?q?gkUgzqFFIVEdDcCBgEJAQEDCXyKWAImB4EGAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3Am9Xi7hPfqlFf40GTJ9cl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwz3ljTVIPU5rRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGH9z3YVLf5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,474,1599523200"; d="scan'208";a="622757624" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jan 2021 16:56:27 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 104GuQit013652 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2021 16:56:26 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 10:56:26 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 11:56:25 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 4 Jan 2021 10:56:25 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mmgNYUMk/zf2q2WvRp7ybdNKptUOCb8IHfrMbMi+iEy9HboNoy0l9AOelQJVQjGLBNilpq0kibNk2YpIbfIi0ED/k9mELby0OphXyjHBxxxLjU/bvHsHT1CGV0GlXjCWlYYg6HK0VpEHRh2hTWRLr4eZd4+rB9KaKfK4QaEudGUdUFKP7Ep6K4ZXqICQolT9kXRCRVMpOCHKiitNUq8/R8dusxhwtFbY5+++rdmYKQCLdm0OXeA/HrASq2AnMTt+s4QB1+rSVggtPDrKwab1sH7Xs78MOPUDx0IydC7wgNeeHd72jGBcivXhkSmLv6ZKRIqbMRSmUIEUBWUkFmqMmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FAHEDt1wpOOM3Il2u8gnDrc7sqQQrH7ieAtQLKZkP0k=; b=h+LECAakPquetrsvE/yS5jco0JI+vDqs4lEEiAZOrdLK8bi2KegXbtArC5bluxvTks4b1gR34zYd4JwOHjyP4r8wPDuFnKWUdkl5CZtlpmzok2dfyui0RGzrqi577llVJIp+pIZ2Zkce2YkEgI7GdmHgkSbS4YbWxIAzyoY0pMuCw7vblTY0+EOTYtK13/pt54O7SzLenC8DZkzDxR/ocxJt4aksaTRVlvBq+nQTyKam196xStO7280anGlq+vBYvQbi0uIHCCFPreZEA+hQ+Hu90RjgURhyNNl1o5FldkymWQRxkBglBzHUMvODR90FB0/4umPLZ9srQpVgs9EGog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FAHEDt1wpOOM3Il2u8gnDrc7sqQQrH7ieAtQLKZkP0k=; b=zwNqaJ3acZJum0IcwAlbD7jtcxg743bIY5Wn9UbKE7eyOiF4p2PLedcwsDXUuCERbNmb30gep5N8p0AmoYGKQLSnp+lnciBhzWvH/RQU5UjiBIUJi/FLIYHAsFtziY+clX8VpGWX1AweJAkHSVcemF7DezwSdk60eV83+LBX89I= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3377.namprd11.prod.outlook.com (2603:10b6:208:66::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Mon, 4 Jan 2021 16:56:23 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb%6]) with mapi id 15.20.3721.024; Mon, 4 Jan 2021 16:56:22 +0000 From: "Rob Wilton (rwilton)" To: "mohamed.boucadair@orange.com" , "Roman Danyliw" , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , Valery Smyslov , "dots@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x04GhVUrubF9E6Ldzi/FU9PuKn5Pw6AgAPYoACAB6gWgIAS/RdggAAHj4CAAAWsAA== Date: Mon, 4 Jan 2021 16:56:22 +0000 Message-ID: References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <703969fb11df49a39c6241bb32934ff6@cert.org> <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21867_1609777571_5FF341A3_21867_195_25_787AE7BB302AE849A7480A190F8B9330315A6CFB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <21867_1609777571_5FF341A3_21867_195_25_787AE7BB302AE849A7480A190F8B9330315A6CFB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 373755b4-b759-41e1-2c57-08d8b0d1aa63 x-ms-traffictypediagnostic: BL0PR11MB3377: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3vx9eINH2tKqzkNEA4mOk1+gY7qir2W+yaXHq/0YU68dFp+O5YPhTy9s3m3ZA7F5yoDAFo2tVaSECpFl1MGLhL2QJHJ5XED06Ji2CvkS74DJsc11Eb1lBP5rFDirm9VxkaMLHxJjiwM5QFAR0+w1i50Kmk/nJoEvQaPZbF8v1t0EkPgYFNjH33F254Xat3CVWBwbU57usjgOC5i9tW686Rdd/4o9/uDWb0jLsL54c2E6/KLkuSo3+qQaPzf0O/nIlY+YF1t7R5/mYE+ElL1T5oeqhX++vhr+41EYuCKbJnCdTA5Y/pppgsf6ZcXtehgeJ16wK/s6JnQkTULF68TH9v3TgYEAVdupQhm7H45hrGonjMsgjxYiKaL1PQsYOafnDE3r2opkYVnrbW1YZwyFFRttWetpnzeYfSJOGUZQOtIyEE2AgMR3XGAVtG618xwz1fJxYcUCNwv4Ewhrh1SLQg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(346002)(376002)(366004)(52536014)(6506007)(966005)(8936002)(53546011)(33656002)(66574015)(7696005)(2906002)(71200400001)(316002)(83380400001)(186003)(30864003)(66946007)(26005)(5660300002)(9686003)(8676002)(478600001)(66556008)(110136005)(66476007)(55016002)(86362001)(54906003)(66446008)(64756008)(76116006)(4326008)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?c2NOamRIcHVzQjFldVBHa0tWRld6bGZCeWRQOG1xenZieUIvcVFXSVpQSEts?= =?utf-8?B?S1I0c1JlL1Vib3dSUTNEaFJqOTRFU1RHd3RSYkZhOFFueXc3VDVNNTFabmRm?= =?utf-8?B?S0ZObEo2c0VPa0J6eTM1M01IWHJnU2dGMU5SdnJ4Tmp4R1FPdEgycTVrcUdz?= =?utf-8?B?MzdQT1ptR1FZbE9rc2xrcHFmUWROeXRQVWpZM2Y2SmFMNlppZDRxY1RSa0pC?= =?utf-8?B?OHo4d0Y5aEJIVzlHbTN4c3NMK29MR1phQkNUdGY3bnNmQlJuaGxCYjJ4alkz?= =?utf-8?B?NnJ3dngyaDB6dm1nZVd5MjMyRHVrUzdWN3VZQUY0M2pqR0hKaUx2QWdFYzlH?= =?utf-8?B?aTQ5REN5QlZXM01SSFRLMU1KL3FSS1dxZFhaRFJqekxySXA2SSt2VnFRVE41?= =?utf-8?B?cGVtWVRMWGY1UzZMMU1aUVNxZlo4c0FiU25ac2Q1aTJ0S3dFTHJuSnBVMC9q?= =?utf-8?B?THVoYTFnUlhuMVFBaW5zTnBMZVNMcWd3NlNOZjk2WG1NY1UweUNRZmY0enV3?= =?utf-8?B?bkpOby9BR0o0bCtBMCtPOVQ2STV6RlU5RGxUaEFGWTEraTloa1hhNjcvS3NN?= =?utf-8?B?MStBQThCWTkwQVByZ0JLUitKMlJPNlFCK3hHYktFZ29CU3VKK1craHN5Yng0?= =?utf-8?B?UnlRWmRpVmFPSHNKS250ckVGUXkrVzRaajNSTkpadWs0S3NydzEwaGszMklo?= =?utf-8?B?a2RLZE5rY3RpbVl2UDREd1YrNWFjNTgvVHBIQm1IemlVYkhLYThEMFUzOE83?= =?utf-8?B?aWFFenhxbVpKTzE1bEU3VVNBam8rUEt5OVZZQVN1ZWxaMUFtZVVJbXJRWDZ5?= =?utf-8?B?dHY2eFQvbUt5Q09MeVUxcnQ2UEVtdG4vNmxmVlFRY2pndHZ3dFkwNHo2MHZm?= =?utf-8?B?NWZrTjg1TjRxRVlmeFprN1ZQSWFId05xM21GbXJCZU9GOEdYN3FSN0Q3VitD?= =?utf-8?B?Y2xzU0JjbUxXUktTaWhhMklEUlN4ME52V0thWExlUkNoK0JFbUZ6cnR0bEho?= =?utf-8?B?QjNvVGkzWDBYc0ZheWFBUGlnM3FNM0xOZklCMElST0NUdjZGcmhBcnM0ZWxV?= =?utf-8?B?bGRqbnlpZk4zTGZRa3lkNFM5Tnkxa3BTc1VkYXZFQ3FSTzQzbE9NcnI0MXo5?= =?utf-8?B?OUh0VWFJYzM0ZVFFVmMrSk91bTgzUWkzNFNsOFZJRk1FQVJDOStSRHdYazYy?= =?utf-8?B?Mlo4MmxVU3pyTjZGank1MzgyekViNm5STndCQVpGZ2gvVFQ4cTZFbDcreVRT?= =?utf-8?B?RkwrZkNPOUs3WHdJVkh0a0NiODhXUDBDNUZUdFl0NFNDY09TZ0VnbEh5UFY3?= =?utf-8?Q?GHm2ck8qRKjwc=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 373755b4-b759-41e1-2c57-08d8b0d1aa63 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 16:56:22.4925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YKVn97tSlGu47C33gvCUem4600P4TEHtVaDneBOzlX2vcUgeEMlA6f8Ci4JpdiQMcAzZaV/ld4VzKZSHbPNJCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3377 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (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: Mon, 04 Jan 2021 16:56:33 -0000 SGkgTWVkLA0KDQpQbGVhc2Ugc2VlIGlubGluZSAuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiAwNCBKYW51YXJ5IDIwMjEgMTY6MjYNCj4gVG86 IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IFJvbWFuIERhbnlsaXcN Cj4gPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtY2hhaXJzQGlldGYub3Jn Ow0KPiBWYWxlcnkgU215c2xvdiA8dmFsZXJ5QHNteXNsb3YubmV0PjsgZG90c0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSRTogUm9tYW4gRGFueWxpdydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1jYWxsLWhvbWUtDQo+IDExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiAN Cj4gSGkgUm9iLA0KPiANCj4gV2UgdGhvdWdodCB0aGlzIHdhcyBjb3ZlcmVkIGJ5IHRoZSBmb2xs b3dpbmc6DQo+IA0KPiAgICBPdGhlciBtb3RpdmF0aW9ucyBmb3IgaW50cm9kdWNpbmcgdGhlIENh bGwgSG9tZSBmdW5jdGlvbiBhcmUNCj4gICAgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMS4xIG9mIFtS RkM4MDcxXS4NCltSV10gDQoNCkkgaGFkIG1pc3NlZCB0aGUgcmVmZXJlbmNlLg0KDQo+IA0KPiBX ZSBwcmVmZXJyZWQgdGhhdCBjaXRhdGlvbiB2cyBkdXBsaWNhdGluZyB0aGUgNiBpdGVtcyBpbiB0 aGlzIGRvY3VtZW50IGFzDQo+IHdlbGwgKHMvbWFuYWdlbWVudCBzeXN0ZW0vbWl0aWdhdGlvbiBz eXN0ZW0pLg0KW1JXXSANCg0KSSBhZ3JlZSB0aGF0IGEgcmVmZXJlbmNlIGlzIGJldHRlciB0aGFu IGNvcHlpbmcgdGhlbSBhbGwgb3V0IGFnYWluIGhlcmUuDQoNCj4gDQo+IEkgdW5kZXJzdGFuZCBm cm9tIHlvdXIgY29tbWVudCB0aGF0IHRoZSBsaW5rIHdhcyBub3QgZXZpZGVudC4gSWYgc28sIHdp bGwNCj4gc2VlIGhvdyB0byBtYWtlIHRoaW5ncyBiZXR0ZXIuDQpbUlddIA0KDQpTbywgdGhlIGRl c2lyZSB0byB3YW50IHRvIGJlIGFibGUgdG8gc3RvcCBERE9TIHRyYWZmaWMgYXQgc291cmNlIGlz IGNsZWFyLCBidXQgaXQgd2Fzbid0IGNsZWFyIHdoeSBDYWxsIEhvbWUgaXMgdGhlIG1lY2hhbmlz bSBuZWVkZWQgdG8gYWNoaWV2ZSB0aGF0LiAgUGVyaGFwcyB5b3VyIHNlbnRlbmNlIGNvdWxkIGJl IGV4cGFuZGVkIGEgYml0IHdpdGhvdXQgY29weWluZyBhbGwgdGhlIHJlYXNvbnMuICBFLmcuLCBt YXliZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIC4uLg0KDQpBbHRob3VnaCBDYWxsIEhv bWUgZnVuY3Rpb25hbGl0eSBpcyBub3QgYWx3YXlzIG5lY2Vzc2FyeSB0byBmYWNpbGl0YXRlIERP VFMgRERPUyBtaXRpZ2F0aW9uIGluIHRoZSBzb3VyY2UgbmV0d29yaywgdGhlcmUgYXJlIHZhcmlv dXMgbWFuYWdlbWVudCBhbmQgZGVwbG95bWVudCBjb25zaWRlcmF0aW9ucyB0aGF0IG1ha2UgQ2Fs bCBIb21lIGZ1bmN0aW9uYWxpdHkgZGVzaXJhYmxlIG9yIHJlcXVpcmVkIGluIHNvbWUgY2FzZXMs IGUuZy4sIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDEuMSBvZiBbUkZDODA3MV0uDQoNClJlZ2Fy ZHMsDQpSb2INCg0KDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gPiBEZcKgOiBSb2IgV2lsdG9uIChyd2lsdG9uKSBbbWFpbHRvOnJ3 aWx0b25AY2lzY28uY29tXQ0KPiA+IEVudm95w6nCoDogbHVuZGkgNCBqYW52aWVyIDIwMjEgMTc6 MDgNCj4gPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPjsgUm9tYW4NCj4gPiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZz4NCj4gPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwt aG9tZUBpZXRmLm9yZzsgZG90cy0NCj4gPiBjaGFpcnNAaWV0Zi5vcmc7IFZhbGVyeSBTbXlzbG92 IDx2YWxlcnlAc215c2xvdi5uZXQ+OyBkb3RzQGlldGYub3JnDQo+ID4gT2JqZXTCoDogUkU6IFJv bWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4g PiBob21lLTExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gSGkgTWVkLA0K PiA+DQo+ID4gVGhpcyB0ZXh0IGlzIGFuIGltcHJvdmVtZW50IHRvIG1lLCB0aGFua3MuDQo+ID4N Cj4gPiBBbHRob3VnaCB0aGUgaW50cm9kdWN0aW9uIHN0aWxsIGRvZXNuJ3Qgc2VlbSB0byBzdGF0 ZSB0aGUgcHJlY2lzZQ0KPiA+IHJlYXNvbiB3aHkgdGhlIERPVFMgY2xpZW50IGNhbm5vdCBvcGVu IGEgcmVndWxhciBjaGFubmVsIHRvIHRoZSBET1RzDQo+ID4gc2VydmVyIChlLmcuIHBhcmFncmFw aCAyIG9mIHRoZSBpbnRyb2R1Y3Rpb24pLCBvciBJIGFtIG1pc3NpbmcgaXQuDQo+ID4NCj4gPiBN eSBhc3N1bXB0aW9uIG9mIHRoZSBkZXBsb3ltZW50IGlzIHRoYXQgdGhlIERPVFMgY2xpZW50IGlz IHdpdGhpbg0KPiA+IHRoZSBvdXRib3VuZCBET1MgYXR0YWNrIElTUCdzIG5ldHdvcmsuICBJcyB0 aGUgc3BlY2lmaWMgaXNzdWUgdGhhdA0KPiA+IHRoaXMgZG9jdW1lbnQgaXMgYWRkcmVzc2luZyB0 aGF0IHRoZSBET1RzIHNlcnZlciBtYXkgYmUgYmVoaW5kIGEgTkFUDQo+ID4gYW5kIGhlbmNlIG5v dCBiZSBwdWJsaWNseSBhZGRyZXNzYWJsZT8gIE9yIGFyZSB0aGVyZSBhbHNvIG90aGVyDQo+ID4g cmVhc29ucyB3aHkgYSBDYWxsIEhvbWUgYXJjaGl0ZWN0dXJlIGlzIHJlcXVpcmVkPyAgSSBhcHBy ZWNpYXRlIHRoYXQNCj4gPiB0aGVyZSBtYXkgYmUgcmVhc29ucyB3aHkgYSBDYWxsIEhvbWUgYXJj aGl0ZWN0dXJlIGlzIHByZWZlcnJlZCBhbmQNCj4gPiBwb3RlbnRpYWxseSBzaW1wbGlmaWVzIHRo ZSBtYW5hZ2VtZW50IG9mIHRoZSBDUEUgZGV2aWNlcy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4g Um9iDQo+ID4NCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YNCj4gPiA+ IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+IFNlbnQ6IDIzIERlY2VtYmVyIDIw MjAgMTM6NTQNCj4gPiA+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBSb2IgV2ls dG9uIChyd2lsdG9uKQ0KPiA+ID4gPHJ3aWx0b25AY2lzY28uY29tPjsgVGhlIElFU0cgPGllc2dA aWV0Zi5vcmc+DQo+ID4gPiBDYzogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0 Zi5vcmc7IGRvdHMtDQo+ID4gY2hhaXJzQGlldGYub3JnOw0KPiA+ID4gVmFsZXJ5IFNteXNsb3Yg PHZhbGVyeUBzbXlzbG92Lm5ldD47IGRvdHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBS b21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbg0KPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1j YWxsLWhvbWUtDQo+ID4gPiAxMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPiA+DQo+ ID4gPiBIaSBSb21hbiwgYWxsLA0KPiA+ID4NCj4gPiA+IFdlIHVwZGF0ZWQgdGhlIGRyYWZ0IHRv IHRha2UgaW50byBhY2NvdW50IHlvdXIgc3VnZ2VzdGlvbnMuIFRoZQ0KPiA+ID4gaW50cm9kdWN0 aW9uIGFuZCBhcHBsaWNhYmlsaXR5IHNlY3Rpb25zIHdlcmUgcmV3b3JrZWQgYWNjb3JkaW5nbHku DQo+ID4gV2UNCj4gPiA+IGFsc28ga2VwdCBpbiBtaW5kIFJvYidzIGNvbW1lbnQgd2hlbiB1cGRh dGluZyB0aGVzZSB0d28gc2VjdGlvbnMuDQo+ID4gPg0KPiA+ID4gVGhlIG5ldyB2ZXJzaW9uIGFu ZCBhIGRpZmYgY2FuIGJlIGZvdW5kIGF0Og0KPiA+ID4NCj4gPiA+IEh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLQ0KPiA+IHNpZ25hbC1j YWxsLQ0KPiA+ID4gaG9tZS0xMg0KPiA+ID4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtDQo+ID4gc2lnbmFsLQ0KPiA+ID4g Y2FsbC1ob21lLTEyDQo+ID4gPg0KPiA+ID4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoaXMgdmVy c2lvbiBhZGRyZXNzZXMgeW91ciBESVNDVVNTLg0KPiA+ID4NCj4gPiA+IEFsc28sIHRoaXMgdmVy c2lvbiBpbnRlZ3JhdGVzIHRoZSBpbnB1dHMgZnJvbSB0aGUgQmFycnkvRXJpYy9FcmlrDQo+ID4g YW5kDQo+ID4gPiBkaXJlY3RvcmF0ZSByZXZpZXdzLg0KPiA+ID4NCj4gPiA+IENoZWVycywNCj4g PiA+IE1lZA0KPiA+ID4NCj4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4g PiA+IERlwqA6IFJvbWFuIERhbnlsaXcgW21haWx0bzpyZGRAY2VydC5vcmddIEVudm95w6nCoDog dmVuZHJlZGkgMTgNCj4gPiA+ID4gZMOpY2VtYnJlIDIwMjAgMTc6NTggw4DCoDogQk9VQ0FEQUlS IE1vaGFtZWQgVEdJL09MTg0KPiA+ID4gPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDY8KgOg0KPiA+ID4gPiBkcmFmdC1pZXRmLWRvdHMt c2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9yZzsgZG90cy0NCj4gPiBjaGFpcnNAaWV0Zi5vcmc7DQo+ ID4gPiA+IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+OyBkb3RzQGlldGYub3Jn IE9iamV0wqA6IFJFOg0KPiA+IFJvbWFuDQo+ID4gPiA+IERhbnlsaXcncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4gPiA+ID4gaG9tZS0xMTogKHdpdGggRElTQ1VT UyBhbmQgQ09NTUVOVCkNCj4gPiA+ID4NCj4gPiA+ID4gSGkgTWVkIQ0KPiA+ID4gPg0KPiA+ID4g PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogRG90cyA8ZG90 cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YNCj4gPiA+ID4gPiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tDQo+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwg MjAyMCAxOjE0IEFNDQo+ID4gPiA+ID4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiA+ID4gPiA+IENjOiBkcmFmdC1pZXRmLWRvdHMt c2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9yZzsgZG90cy0NCj4gPiA+ID4gY2hhaXJzQGlldGYub3Jn Ow0KPiA+ID4gPiA+IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+OyBkb3RzQGll dGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUmU6IFtEb3RzXSBSb21hbiBEYW55bGl3J3MgRGlz Y3VzcyBvbg0KPiA+ID4gPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4gPiA+ID4g PiBob21lLTExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gSGkgUm9tYW4sDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGFuayB5b3UgZm9yIHRoZSByZXZp ZXcuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBQbGVhc2Ugc2VlIGlubGluZSBmb3IgdGhlIERJU0NV U1MgcGFydC4gV2lsbCBzZWUgaWYvd2hhdA0KPiA+IGNoYW5nZXMNCj4gPiA+ID4gYXJlDQo+ID4g PiA+ID4gbmVlZGVkIGZvciB0aGUgQ09NTUVOVCBwYXJ0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g Q2hlZXJzLA0KPiA+ID4gPiA+IE1lZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiA+IERlwqA6IFJvbWFuIERhbnlsaXcgdmlhIERh dGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gPiA+ID4gRW52b3nDqcKgOg0K PiA+ID4gPiA+ID4gbWFyZGkgMTUgZMOpY2VtYnJlIDIwMjAgMjE6MDEgw4DCoDogVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2PCoDoNCj4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtZG90cy1z aWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3RzLQ0KPiA+ID4gPiBjaGFpcnNAaWV0Zi5vcmc7 DQo+ID4gPiA+ID4gPiBkb3RzQGlldGYub3JnOyBWYWxlcnkgU215c2xvdiA8dmFsZXJ5QHNteXNs b3YubmV0PjsNCj4gPiA+ID4gPiA+IHZhbGVyeUBzbXlzbG92Lm5ldCBPYmpldMKgOiBSb21hbiBE YW55bGl3J3MgRGlzY3VzcyBvbg0KPiA+ID4gPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1j YWxsLWhvbWUtDQo+ID4gPiA+ID4gPiAxMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBSb21hbiBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+ID4gPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNp Z25hbC1jYWxsLWhvbWUtMTE6IERpc2N1c3MNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZA0KPiA+ IHJlcGx5DQo+ID4gPiA+IHRvDQo+ID4gPiA+ID4gPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsDQo+ID4gZnJlZQ0KPiA+ID4gPiB0bw0K PiA+ID4gPiA+ID4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiA+ID4gPiA+ID4gY3Jp dGVyaWEuaHRtbA0KPiA+ID4gPiA+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UDQo+ID4gcG9zaXRpb25zLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlDQo+ID4gZm91bmQNCj4gPiA+ID4gaGVyZToNCj4gPiA+ID4gPiA+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtDQo+ ID4gY2FsbC0NCj4gPiA+ID4gaG9tZS8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tLS0NCj4gPiA+ID4gLS0tLQ0KPiA+ID4gPiA+ ID4gLS0NCj4gPiA+ID4gPiA+IERJU0NVU1M6DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLS0tDQo+ ID4gPiA+IC0tLS0NCj4gPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSXQg c2VlbXMgdG8gbWUgdGhlcmUgaXMgYSBtaXNzaW5nIG9wZXJhdGlvbmFsIGd1aWRhbmNlIG9yDQo+ ID4gPiA+ID4gPiB1bmRvY3VtZW50ZWQgZGVwbG95bWVudCBhc3N1bXB0aW9ucy4gIFNpbmNlIHRo ZSBtb3RpdmF0aW9uYWwNCj4gPiB1c2UNCj4gPiA+ID4gPiA+IGNhc2Ugc2VlbXMgdG8gYmUgaG9t ZSBuZXR3b3JrcyAocGVyIFNlY3Rpb24gMS4xKSwgSSBhc3N1bWVkDQo+ID4gdGhhdA0KPiA+ID4g PiB0aGUNCj4gPiA+ID4gPiA+IGNhbGwgaG9tZSBzZXJ2ZXJzIGFyZSBydW5uaW5nIHByaW1hcmls eSBjb25zdW1lciBncmFkZQ0KPiA+IHJvdXRlcnMNCj4gPiA+ID4gbm90DQo+ID4gPiA+ID4gPiBt YW5hZ2VkIGJ5IHByb2Zlc3Npb25hbCBJVCBleHBlcnRpc2UuDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBbTWVkXSBUaGUgZ2VuZXJhbGl6ZWQgYXBwbGljYWJpbGl0eSBzY29wZSBpcyB3aGF0IGlzIHNr ZXRjaGVkDQo+ID4gaW4NCj4gPiA+ID4gPiBTZWN0aW9uIDMuIFRoZSBzb2x1dGlvbiBpcyBtZWFu dCB0byBibG9jayBhdHRhY2tzIGNsb3NlIHRvDQo+ID4gdGhlaXINCj4gPiA+ID4gc291cmNlLiBU aGlzIGNhbiBiZToNCj4gPiA+ID4gPiAtIHRoZSBob21lIGNhc2UsDQo+ID4gPiA+ID4gLSBhbiBl bnRlcnByaXNlIG5ldHdvcmssDQo+ID4gPiA+ID4gLSBhIHRyYW5zaXQgcHJvdmlkZXIgZmlsdGVy aW5nIGF0dGFja3MgZnJvbSBsZWFmIG5ldHdvcmtzLA0KPiA+ID4gPiA+IC0gYSBwcm92aWRlciBm aWx0ZXJpbmcgYXR0YWNrcyBmcm9tIGRhdGEgY2VudGVycywNCj4gPiA+ID4gPiAtIGV0Yy4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IEZvciB0aGUgcGFydGljdWxhciBjYXNlIG9mIGhvbWUgbmV0d29y a3MsIHRoaXMgY2FuIGJlIHBhcnQgb2YNCj4gPiA+ID4gc2VydmljZXMNCj4gPiA+ID4gPiBzdXBw b3J0ZWQgYnkgYSBJU1AtbWFuYWdlZCBDUEUgb3IgYSBtYW5hZ2VkIHNlY3VyaXR5IHNlcnZpY2UN Cj4gPiA+ID4gc3Vic2NyaWJlZCBieSB0aGUgdXNlci4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdl IGNvdWxkIG1lbnRpb24gdGhhdCBpbiB0aGUgZG9jdW1lbnQsIGJ1dCB3ZSBkaWRuJ3QgYmVjYXVz ZQ0KPiA+IHRoaXMNCj4gPiA+ID4gYXJlDQo+ID4gPiA+ID4gZGVwbG95bWVudC1zcGVjaWZpYy4g UmVhbGx5Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT3RoZXIgdGhhbiB0aGUgaW50cm9kdWN0aW9u LCB3ZSBkb24ndCB3YW50IHRvIG92ZXJsb2FkIHRoZQ0KPiA+ID4gPiBkb2N1bWVudA0KPiA+ID4g PiA+IHdpdGggaG9tZS1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucy4NCj4gPiA+ID4NCj4gPiA+ID4g SSBzdGlsbCB0aGluayB3ZSBuZWVkIGEgYml0IG1vcmUgcHJlY2lzaW9uLiAgSSBkb24ndCBkaXNw dXRlIHRoZQ0KPiA+ID4gPiBnZW5lcmFsIHV0aWxpdHkgb2YgdGhpcyBhcHByb2FjaCB0byBhIHZh cmlldHkgb2YgZW52aXJvbm1lbnRzLg0KPiA+IEkgZG8NCj4gPiA+ID4gc2VlIHRoZSB0d28gc2Vu dGVuY2VzIGluIHRoZSBlbnRpcmUgZG9jdW1lbnQgd2hpY2ggc2F5IHRoYXQgdGhpcw0KPiA+IGlz DQo+ID4gPiA+IGEgZ2VuZXJhbCBwdXJwb3NlIGFwcHJvYWNoOg0KPiA+ID4gPg0KPiA+ID4gPiBB YnN0cmFjdDogVGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgQ2FsbCBIb21lIGlzIG5vdCBzcGVjaWZp YyB0bw0KPiA+IGhvbWUNCj4gPiA+ID4gbmV0d29ya3M7DQo+ID4gPiA+ICAgIHRoZSBzb2x1dGlv biB0YXJnZXRzIGFueSBkZXBsb3ltZW50IGluIHdoaWNoIGl0IGlzIHJlcXVpcmVkDQo+ID4gdG8N Cj4gPiA+ID4gYmxvY2sNCj4gPiA+ID4gICAgRERvUyBhdHRhY2sgdHJhZmZpYyBjbG9zZXIgdG8g dGhlIHNvdXJjZShzKSBvZiBhIEREb1MgYXR0YWNrLg0KPiA+ID4gPg0KPiA+ID4gPiBTZWN0aW9u IDM6ICJUaGUgYWZvcmVtZW50aW9uZWQgcHJvYmxlbXMgbWF5IGJlIGVuY291bnRlcmVkIGluDQo+ ID4gb3RoZXINCj4gPiA+ID4gZGVwbG95bWVudHMNCj4gPiA+ID4gICAgdGhhbiB0aG9zZSBkaXNj dXNzZWQgaW4gU2VjdGlvbiAxLjEgKGUuZy4sIGRhdGEgY2VudGVycywNCj4gPiA+ID4gZW50ZXJw cmlzZQ0KPiA+ID4gPiAgICBuZXR3b3JrcykuIg0KPiA+ID4gPg0KPiA+ID4gPiBIb3dldmVyLCBJ IHdpbGwgcmVpdGVyYXRlIHRoYXQgYWxtb3N0IG5vIGNvbnNpZGVyYXRpb24gaXMgbWFkZQ0KPiA+ IHRvDQo+ID4gPiA+IGRpc3Rpbmd1aXNoIHRoZXNlIHVzZSBjYXNlcyBpbiB0aGUgbmFycmF0aXZl IHRleHQuICBUaGUgZW50aXJlDQo+ID4gPiA+IG1vdGl2YXRpb24gZm9yIHRoZSB3b3JrIGluIFNl Y3Rpb24gMS4wIGlzIHRocm91Z2ggdGhlIGxlbnMgb2YNCj4gPiA+ID4gbmV0d29ya3Mgbm90IG1h bmFnZWQgYnkgcHJvZmVzc2lvbmFscyAoaG9tZSBuZXR3b3JrcykuDQo+ID4gRnVydGhlcm1vcmUs DQo+ID4gPiA+IHRoZSBleHBsYW5hdGlvbiBvZiB0aGUgc29sdXRpb24gaW4gU2VjdGlvbiAxLjEs IDUuMSBhbmQgQXBwZW5kaXgNCj4gPiBBDQo+ID4gPiA+IGlzIGRvbmUgdGhyb3VnaCB0aGUgbGVu cyBvZiBhICJob21lIG5ldHdvcmsiLiAgRm9yIHRoaXMgcmVhc29uLA0KPiA+IEknbQ0KPiA+ID4g PiBwdXNoaW5nIHRvIG1ha2Ugc3VyZSB0aGUgZWRnZXMgb2YgdGhhdCBkZXBsb3ltZW50IGVudmly b25tZW50DQo+ID4gYXJlDQo+ID4gPiA+IGNvdmVyZWQuDQo+ID4gPiA+DQo+ID4gPiA+IEkgd291 bGQgYXNzZXJ0IHRoYXQgbW9zdCBvZiB0aGUgYmVoYXZpb3IgZGVzY3JpYmVkIGJlbG93DQo+ID4g cmVxdWlyZXMNCj4gPiA+ID4gdGhhdCBwcm9mZXNzaW9uYWwgSVQgZXhwZXJ0aXNlIChsZXQgbWUg a25vdyBpZiB5b3UgdGhpbmsgSSBoYXZlDQo+ID4gaXQNCj4gPiA+ID4gd3JvbmcpLiAgSSdtIGxv b2tpbmcgcHJpbWFyaWx5IGZvciBhIGZldyBwaWVjZXMgb2YgY2xhcmlmeWluZw0KPiA+IHRleHQ6 DQo+ID4gPiA+ICgxKSBhIHN1Z2dlc3Rpb24vYWNrbm93bGVkZ2VtZW50IHRoYXQgQ1BFcyB1c2lu ZyB0aGlzIHNwZWMgaW4NCj4gPiB0aGUNCj4gPiA+ID4gaG9tZSBlbnZpcm9ubWVudCBhcmUgbGlr ZWx5IHRvIGJlIG1hbmFnZWQsIHByb3Zpc2lvbmVkLCBpc3N1ZWQNCj4gPiAoPykNCj4gPiA+ID4g YnkgYW4gSVNQICh0aGlzIGFkZHJlc3NlcyB3aGVyZSB0aGVyZSBwcm9mZXNzaW9uYWwgSVQgZXhw ZXJ0aXNlDQo+ID4gaXMNCj4gPiA+ID4gY29taW5nIGZyb20pDQo+ID4gPiA+ICgyKSBhc3N1bWlu ZyAoMSkgaXMgdHJ1ZSwgZGlzdGluZ3Vpc2hpbmcgdGhlIHZhcmlvdXMNCj4gPiA+ID4gTVVTVC9T SE9VTEQvTUFZcyBhZG1pbiBiZWhhdmlvcnMgdGhhdCBpbnZvbHZlIHRoZSBJU1AgdnMuIHRoZQ0K PiA+IGFjdHVhbA0KPiA+ID4gPiBodW1hbnMgb24gdGhlIGhvbWUgbmV0d29yaw0KPiA+ID4gPg0K PiA+ID4gPiBOb3RlOiBldmVyeXRoaW5nIGVsc2UgYmVsb3cgaXMganVzdCBtb3JlIGRldGFpbGVk IGNvbW1lbnRhcnkgb24NCj4gPiB0aGlzDQo+ID4gPiA+IHRoZW1lIGFib3ZlLiAgSSdkIHN1bW1h cml6ZSBldmVyeXRoaW5nIEkndmUgc2FpZCBoZXJlIGJ5IHNheWluZw0KPiA+IEkNCj4gPiA+ID4g dGhpbmsgd2UgbmVlZCBtb3JlIGZpbmVzc2UgaW4gZGVzY3JpYmluZyB0aGUgb3BlcmF0aW9uYWwN Cj4gPiA+ID4gY29uc2lkZXJhdGlvbnMgYW5kIHdobyBpcyBleHBlY3RlZCB0byB0YWtlIHJlc3Bv bnNpYmlsaXR5IGZvcg0KPiA+IHRoZW0NCj4gPiA+ID4gKHJlYWxpemluZyB0aGVyZSB3aWxsIGJl IGEgZGl2ZXJzaXR5IG9mIGVudmlyb25tZW50cykuICBIb3dldmVyLA0KPiA+ID4gPiBzaW5jZSB0 aGVyZSBhcmUgbXVsdGlwbGUgdXNlIGNhc2VzLCBJTU8sIHRoZXkgZGVzZXJ2ZSB1bmlxdWUNCj4g PiA+ID4gY29uc2lkZXJhdGlvbiB3aGVuIHRoZXkgYXJlIGRpZmZlcmVudCBmcm9tIGVhY2ggb3Ro ZXIuDQo+ID4gPiA+DQo+ID4gPiA+ID4gICBJZiB0aGF0IGFzc3VtcHRpb24gaXMgdHJ1ZQ0KPiA+ ID4gPiA+ID4gKGFuZCBpdCBzaG91bGQgYmUgZG9jdW1lbnRlZCBpZiB0aGF0IGlzIHRoZSBjYXNl KSwgdGhlbiBJDQo+ID4gZmluZA0KPiA+ID4gPiBtYW55DQo+ID4gPiA+ID4gPiBvZiB0aGUgb3Bl cmF0aW9uYWwgcmVjb21tZW5kYXRpb25zIG5vdCBjb25ncnVlbnQgd2l0aCB0aGF0DQo+ID4gPiA+ IGVudmlyb25tZW50Lg0KPiA+ID4gPiA+ID4gU3BlY2lmaWNhbGx5LCB0aGUgZGVncmVlIG9mIGlu dGVyYWN0aW9uIGFuZCB0dW5pbmcgc2VlbXMNCj4gPiBvdXRzaWRlDQo+ID4gPiA+IHRoZQ0KPiA+ ID4gPiA+ID4gcmVhbG0gb2YgZXhwZXJ0aXNlIG9mIHNvbWVvbmUgd2l0aG91dCBJVCB0cmFpbmlu ZyBhbmQNCj4gPiA+ID4gY2FwYWJpbGl0aWVzDQo+ID4gPiA+ID4gPiBvZiBob21lIG5ldHdvcmsg ZWNvc3lzdGVtLiAgSW4gcGFydGljdWxhcjoNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLSBT ZWN0aW9uIDEuMg0KPiA+ID4gPiA+ID4gVGhlIENhbGwgSG9tZSBET1RTIHNlcnZlciB1c2VzIHRo ZSBERG9TIGF0dGFjayB0cmFmZmljDQo+ID4gPiA+IGluZm9ybWF0aW9uIHRvDQo+ID4gPiA+ID4g PiAgICBpZGVudGlmeSB0aGUgY29tcHJvbWlzZWQgZGV2aWNlIGluIGl0cyBkb21haW4gdGhhdCBp cw0KPiA+ID4gPiByZXNwb25zaWJsZQ0KPiA+ID4gPiA+ID4gZm9yDQo+ID4gPiA+ID4gPiAgICBs YXVuY2hpbmcgdGhlIEREb1MgYXR0YWNrLCBvcHRpb25hbGx5IG5vdGlmaWVzIGEgbmV0d29yaw0K PiA+ID4gPiA+ID4gICAgYWRtaW5pc3RyYXRvciwgYW5kIHRha2VzIGFwcHJvcHJpYXRlIG1pdGln YXRpb24NCj4gPiBhY3Rpb24ocykuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSG93IHdvdWxk IHN1Y2ggbm90aWZpY2F0aW9uIHdvcms/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBbTWVkXSBUaGlz IHdpbGwgZGVwZW5kIG9uIHRoZSBkZXBsb3ltZW50IChob21lLCBlbnRlcnByaXNlLA0KPiA+IERD LA0KPiA+ID4gPiBhY2Nlc3MNCj4gPiA+ID4gPiBwcm92aWRlciwgcGVlciB0cmFuc2l0IHByb3Zp ZGVyLCBldGMuKS4gVGhpcyBjYW4gYmUgdXNpbmcgRE9UUw0KPiA+ID4gPiAodGhlDQo+ID4gPiA+ ID4gYWRtaW5pc3RyYXRvciBoYXMgYSBjYWxsIGhvbWUgZG90cyBzZXJ2ZXIgYXBwKSwgYSBwdXNo IGZyb20NCj4gPiB0aGUNCj4gPiA+ID4gYXBwDQo+ID4gPiA+ID4gdXNlIGZvciBtYW5hZ2luZyB0 aGUgQ1BFLCBzeXNsb2csIHNubXAsIG5ldGNvbmYsIGFuIFNNUywgZXRjLg0KPiA+ID4gPg0KPiA+ ID4gPiBJIHVuZGVyc3RhbmQgdGhpcyBhbnN3ZXIgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGVudGVy cHJpc2UgdXNlDQo+ID4gY2FzZS4NCj4gPiA+ID4gSG93IHdvdWxkIHRoaXMgaGFwcGVuIGZvciB0 aGUgaG9tZSB1c2VyIChub24tcHJvZmVzc2lvbmFsIElUDQo+ID4gPiA+IHBlcnNvbik/DQo+ID4g PiA+DQo+ID4gPiA+IElmIHRoaXMgYW4gaW5zdGFuY2Ugd2hlcmUgaWYgdGhlIENQRSBpcyBtYW5h Z2VkIG9uIGJlaGFsZiBhIHRoZQ0KPiA+ID4gPiB1c2VyLCBwZXJoYXBzIHNheWluZyBhbiBvdXQt b2Ytc2NvcGUgbWVjaGFuaXNtcyAoYXBwLCBTTVMpIG5lZWRzDQo+ID4gdG8NCj4gPiA+ID4gYmUg cHJvdmlkZWQgZm9yIHRoZSBlbmQtdXNlciAoaG9tZSB1c2VyKT8NCj4gPiA+ID4NCj4gPiA+ID4g PiBBcyB5b3UgY2FuIHNlZSBhIHZhcmlldHkgb2YgdG9vbHMgY2FuIGJlIGNvbnNpZGVyZWQgYXMg YQ0KPiA+IGZ1bmN0aW9uDQo+ID4gPiA+IG9mDQo+ID4gPiA+ID4gdGhlIGxvY2FsIGRlcGxveW1l bnQgY2FzZS4gTm9uZSBvZiB0aGVtIGlzIGNhbGxlZCBvdXQgaW4gdGhlDQo+ID4gdGV4dA0KPiA+ ID4gPiBhcw0KPiA+ID4gPiA+IHRoaXMgaXMgZGVwbG95bWVudC0gc3BlY2lmaWMuIE5vdCBhbGwg b2YgdGhlbSBhcmUgYXBwbGljYWJsZQ0KPiA+IGZvcg0KPiA+ID4gPiBlYWNoIGRlcGxveW1lbnQg Y2FzZS4NCj4gPiA+ID4NCj4gPiA+ID4gTWFrZSBzZW5zZS4gIFBlcmhhcHMgc29tZSBkZXRhaWxz IGRpc3Rpbmd1aXNoaW5nIHRoZSBndWlkYW5jZQ0KPiA+IHBlcg0KPiA+ID4gPiB0aGUgdXNlIGNh c2VzIGNvdWxkIGhlbHAuDQo+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0gU2Vj dGlvbiAxLjIgYW5kIDUuMS4gIExlYXZlcyBjcmVkZW50aWFscyBjb25maWd1cmF0aW9uIGFzDQo+ ID4gb3V0DQo+ID4gPiA+IG9mDQo+ID4gPiA+ID4gPiBzY29wZS4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+IFtNZWRdIFRoYXQgaXMgYWxpZ25lZCB3aXRoIGhvdyBjcmVkZW50aWFscyBhcmUgaGFuZGxl ZCBpbiB0aGUNCj4gPiBiYXNlDQo+ID4gPiA+ID4gc3BlYyAoUkZDODc4MikuDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IFNlY3Rpb24gMS4yIHJlZmVyZW5jZXMgW0ktRC5pZXRmLWRvdHMtc2VydmVy LWRpc2NvdmVyeV0gZm9yDQo+ID4gPiA+ID4gPiBwcm92aXNpb25pbmcuICBJbiB0dXJuLCBTZWN0 aW9uIDEgb2YgW0ktRC5pZXRmLnNlcnZlci0NCj4gPiBkaXNjb3ZlcnldDQo+ID4gPiA+ID4gPiBh bHNvIGRlY2xhcmVzIHRoaXMgcHJvYmxlbSBvdXQgb2Ygc2NvcGUgYnkgc2F5aW5nIOKAnFRoaXMN Cj4gPiBkb2N1bWVudA0KPiA+ID4gPiA+ID4gYXNzdW1lcyB0aGF0IHNlY3VyaXR5IGNyZWRlbnRp YWxzIHRvIGF1dGhlbnRpY2F0ZSBET1RTDQo+ID4gc2VydmVyKHMpDQo+ID4gPiA+IGFyZQ0KPiA+ ID4gPiA+ID4gcHJlLXByb3Zpc2lvbmVkIHRvIGEgRE9UUyBjbGllbnQgdXNpbmcgYSBtZWNoYW5p c20gc3VjaCBhcw0KPiA+IChidXQNCj4gPiA+ID4gbm90DQo+ID4gPiA+ID4gPiBsaW1pdGVkIHRv KSB0aG9zZSBkaXNjdXNzZWQgaW4gW1JGQzg1NzJdIG9yIFtJLUQuaWV0Zi1hbmltYS0NCj4gPiA+ ID4gPiA+IGJvb3RzdHJhcHBpbmcta2V5aW5mcmFd4oCdLiAgSG93ZXZlciwgUkZDODU3MiBzZWVt cyB0byByZWx5IG9uDQo+ID4gPiA+IE5FVENPTkYNCj4gPiA+ID4gPiA+IGFuZCBSRVNUQ09ORiB3 aGljaCBzZWVtcyBsaWtlIGEgcmF0aGVyIHVuY29tbW9uIGZlYXR1cmUgb2YNCj4gPiBob21lDQo+ ID4gPiA+ID4gPiByb3V0ZXJzLiAgQlJLU0kgcmVsaWVzIG9uIGEgbWFudWZhY3R1cmVyIHN1cHBs aWVkL2NvbnRyYWN0ZWQNCj4gPiA+ID4gPiA+IGluZnJhc3RydWN0dXJlIGFuZCBrZXlzdG9yZXMg dGhhdCBhbHNvIHNlZW0gdW5jb21tb24gZm9yDQo+ID4gPiA+IGNvbnN1bWVyDQo+ID4gPiA+ID4g PiBncmFkZSBlcXVpcG1lbnQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBbTWVkXSBUaGVzZSBhcmUg bm90IG1lYW50IHRvIGJlIHJlY29tbWVuZGF0aW9ucy4gVGhlc2UNCj4gPiBleGFtcGxlcw0KPiA+ ID4gPiBtYXkgYmUNCj4gPiA+ID4gPiBPSyBmb3Igc29tZSBkZXBsb3ltZW50cywgYnV0IG5vdCBh cHByb3ByaWF0ZSBmb3Igb3RoZXJzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gLS0gU2VjdGlvbiA1LjMuMS4NCj4gPiA+ID4gPiA+IFRoZSBDYWxsIEhvbWUgRE9UUyBzZXJ2 ZXIgZG9tYWluIGFkbWluaXN0cmF0b3IgY29uc2VudCBNQVkNCj4gPiBiZQ0KPiA+ID4gPiA+ID4g ICAgcmVxdWlyZWQgdG8gYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0aGUgY29tcHJvbWlzZWQgZGV2 aWNlDQo+ID4gdG8NCj4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiAgICBhdHRhY2sgdGFyZ2V0LiAg QW4gaW1wbGVtZW50YXRpb24gTUFZIGhhdmUgYQ0KPiA+IGNvbmZpZ3VyYXRpb24NCj4gPiA+ID4g a25vYiB0bw0KPiA+ID4gPiA+ID4gICAgYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0aGUgY29tcHJv bWlzZWQgZGV2aWNlIHRvIHRoZQ0KPiA+IGF0dGFjaw0KPiA+ID4gPiB0YXJnZXQNCj4gPiA+ID4g PiA+ICAgIHdpdGggb3Igd2l0aG91dCBET1RTIHNlcnZlciBkb21haW4gYWRtaW5pc3RyYXRvciBj b25zZW50Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoZSBzdWdnZXN0aW9uIGhlcmUgc2Vl bXMgdG8gYmUgdGhhdCBjb25zdW1lcnMgYXJlIGFjcXVpcmluZw0KPiA+ID4gPiBkZXZpY2VzDQo+ ID4gPiA+ID4gPiB0aGF0IGNhbiBiZSByZW1vdGVseSByZWNvbmZpZ3VyZWQgd2l0aCBvdXQgYSBk ZWZpbmVkIHRydXN0DQo+ID4gPiA+IG1vZGVsPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gW01lZF0g Q2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGljaCBzdWdnZXN0aW9uIGFyZSB5b3UNCj4gPiByZWZl cnJpbmcNCj4gPiA+ID4gdG8/DQo+ID4gPiA+DQo+ID4gPiA+IEknbSB3b25kZXJpbmcgd2hvIHRo ZSAic2VydmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIiBpcyBhbmQgaG93DQo+ID4gdGhleQ0KPiA+ ID4gPiBhcmUgZXhwZWN0ZWQgdG8gY29uc2VudCBpbiB0aGUgaG9tZSB1c2VyIHNjZW5hcmlvPw0K PiA+ID4gPg0KPiA+ID4gPiA+IFRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgcmVmZXJyaW5nIHRvIGJs b2NraW5nIHRyYWZmaWMgZnJvbQ0KPiA+IGRldmljZXMNCj4gPiA+ID4gdGhhdA0KPiA+ID4gPiA+ IGFyZSBpbmplY3RpbmcgRERvUyB0cmFmZmljIGZyb20gd2l0aGluIGEgZG9tYWluLiBUaGVzZSBk ZXZpY2VzDQo+ID4gY2FuDQo+ID4gPiA+IGJlDQo+ID4gPiA+ID4gYW4gSVAgY2FtZXJhLCBhbiBp bmZlY3RlZCBQQywgZXRjLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTb21lIHBvbGljeSBvciBv cGVyYXRpb25hbCBjb250ZXh0IHNlZW1zIGFwcHJvcHJpYXRlIGhlcmUuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gLS0gU2VjdGlvbiA1LjMuMQ0KPiA+ID4gPiA+ID4gLi4uIG5vdGlmaWVzIHRo ZSBDUEUNCj4gPiA+ID4gPiA+ICAgIGFkbWluaXN0cmF0b3IgYWJvdXQgdGhlIGNvbXByb21pc2Vk IGRldmljZQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE5vdGlmeSBob3c/DQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBbTWVkXSBTZWUgYWJvdmUuDQo+ID4gPiA+DQo+ID4gPiA+IExpa2UgSSBub3Rl ZCBhYm92ZSwgaWYgSSdtIGEgaG9tZSB1c2VyLCBob3cgYW0gSSBsaWtlbHkgdG8gZ2V0DQo+ID4g dGhhdA0KPiA+ID4gPiBub3RpZmljYXRpb24/DQo+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gLS0gU2VjdGlvbiA4Lg0KPiA+ID4gPiA+ID4gQXBwcm9wcmlhdGUNCj4gPiA+ID4gPiA+ ICAgIGZpbHRlcnMgKGUuZy4sIGFjY2VzcyBjb250cm9sIGxpc3RzKSBjYW4gYmUgaW5zdGFsbGVk IG9uDQo+ID4gdGhlDQo+ID4gPiA+IENhbGwNCj4gPiA+ID4gPiA+ICAgIEhvbWUgRE9UUyBzZXJ2 ZXIgYW5kIG5ldHdvcmsgYmV0d2VlbiB0aGUgQ2FsbCBIb21lIERPVFMNCj4gPiA+ID4gYWdlbnRz IHNvDQo+ID4gPiA+ID4gPiAgICB0aGF0IG9ubHkgY29tbXVuaWNhdGlvbnMgZnJvbSBhIHRydXN0 ZWQgQ2FsbCBIb21lIERPVFMNCj4gPiBjbGllbnQNCj4gPiA+ID4gdG8NCj4gPiA+ID4gPiA+IHRo ZQ0KPiA+ID4gPiA+ID4gICAgQ2FsbCBIb21lIERPVFMgc2VydmVyIGFyZSBhbGxvd2VkLg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoaXMgc2VlbXMgbGlrZSBhIGxldmVsIG9mIHNvcGhpc3Rp Y2F0aW9uIGJleW9uZCB5b3VyDQo+ID4gYXZlcmFnZQ0KPiA+ID4gPiBob21lDQo+ID4gPiA+ID4g PiByb3V0ZXIgdXNlciBhbmQgYSBwbGFjZSB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkDQo+ ID4gY29uc2lkZXIgYQ0KPiA+ID4gPiA+ID4gc2VjdXJlIGRlZmF1bHRzLg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gW01lZF0gVGhpcyBmaWx0ZXJpbmcgY2FuIGJlIGF1dG9tYXRpY2FsbHkgc2V0IGJh c2VkIG9uIHRoZQ0KPiA+ID4gPiBjb25maWd1cmVkDQo+ID4gPiA+ID4gbGlzdCBvZiBDYWxsIEhv bWUgRE9UUyBjbGllbnRzLiBUaGlzIGlzIGEgd2lkZWx5IHVzZWQgcHJhY3RpY2UNCj4gPiA+ID4g KHRoaW5rDQo+ID4gPiA+ID4gYWJvdXQgU0lQIHByb3h5IHNlcnZlcnMsIGV4YW1wbGUpLiBObyBp bnRlcnZlbnRpb24gbWF5IGJlDQo+ID4gcmVxdWlyZWQNCj4gPiA+ID4gZnJvbSB0aGUgdXNlci4N Cj4gPiA+ID4NCj4gPiA+ID4gQWdyZWVkLiAgSG93ZXZlciwgdGhpcyBpcyBhc3N1bWluZyB0aGF0 IHNvbWVvbmUgaXMgbWFuYWdpbmcgdGhhdA0KPiA+ID4gPiBjb25maWd1cmF0aW9uLiAgTXkgcG9p bnQgaXMgdGhhdCBpbiB0aGUgaG9tZSB1c2VyIHNwYWNlIHRoYXQgaXMNCj4gPiBtb3N0DQo+ID4g PiA+IGxpa2VseSB0aGUgSVNQLCBzbyBsZXQncyBqdXN0IHNheSB0aGF0Lg0KPiA+ID4gPg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tIFNlY3Rpb24gOC4NCj4gPiA+ID4gPiA+IENhbGwgSG9t ZSBET1RTIHNlcnZlcnMgY2FuIGFsc28gc2VlayB0aGUgY29uc2VudCBvZiBET1RTDQo+ID4gPiA+ ID4gPiAgICBzZXJ2ZXIgZG9tYWluIGFkbWluaXN0cmF0b3IgdG8gYmxvY2sgdGhlIHRyYWZmaWMg ZnJvbSB0aGUNCj4gPiA+ID4gPiA+IHBvdGVudGlhbGx5DQo+ID4gPiA+ID4gPiAgICBjb21wcm9t aXNlZCBkZXZpY2UgdG8gdGhlIHRhcmdldCAoc2VlIFNlY3Rpb24gNS4zLjEpLg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IFdoYXQgd291bGQgYmUgdGhlIG1lYW5zIHRvIGdhaW4gc3VjaCBjb25z ZW50Pw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gW01lZF0gVGhpcyB3aWxsIGRlcGVuZCBvbiB0aGUg ZGVwbG95bWVudCBjYXNlOiB0aGlzIGNhbiBiZSBhbg0KPiA+ID4gPiBhY3Rpb24NCj4gPiA+ID4g PiBleGVjdXRlZCB1c2luZyBhbiBhcHAsIGEgY29uZmlybWF0aW9uIHRvIGEgbm90aWZpY2F0aW9u DQo+ID4gbWVzc2FnZSwNCj4gPiA+ID4gZXRjLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gLS0gU2VjdGlvbiA5Lg0KPiA+ID4gPiA+ID4gTm90ZSB0aGF0IGEgQ2FsbCBIb21l IERPVFMgc2VydmVyIGNhbiBzZWVrIGFuDQo+ID4gYWRtaW5pc3RyYXRvcidzDQo+ID4gPiA+ID4g PiAgICBjb25zZW50LCB2YWxpZGF0ZSB0aGUgcmVxdWVzdCBieSBpbnNwZWN0aW5nIHRoZSByZWxl dmFudA0KPiA+ID4gPiB0cmFmZmljDQo+ID4gPiA+ID4gPiBmb3INCj4gPiA+ID4gPiA+ICAgIGF0 dGFjayBzaWduYXR1cmVzLCBvciBwcm9jZWVkIHdpdGggYm90aCBjb3Vyc2VzIG9mDQo+ID4gYWN0 aW9uLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEFzIGFib3ZlLg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gW01lZF0gQXMgYWJvdmUgOi0pDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPiAtLSBTZWN0aW9uIDkuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgIFRoZSBET1RT IENhbGwgSG9tZSBpcyBvbmx5IGFkdmlzb3J5IGluIG5hdHVyZS4NCj4gPiBDb25jcmV0ZWx5LA0K PiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+IERPVFMNCj4gPiA+ID4gPiA+ICAgIENhbGwgSG9tZSBk b2VzIG5vdCBpbXBvc2UgYW55IGFjdGlvbiB0byBiZSBlbmZvcmNlZA0KPiA+IHdpdGhpbg0KPiA+ ID4gPiB0aGUNCj4gPiA+ID4gPiA+ICAgIG5ldHdvcmsgaG9zdGluZyBhbiBhdHRhY2sgc291cmNl OyBpdCBpcyB1cCB0byB0aGUgQ2FsbA0KPiA+IEhvbWUNCj4gPiA+ID4gRE9UUw0KPiA+ID4gPiA+ ID4gICAgc2VydmVyIChhbmQvb3IgbmV0d29yayBhZG1pbmlzdHJhdG9yKSB0byBkZWNpZGUgd2hl dGhlcg0KPiA+IGFuZA0KPiA+ID4gPiB3aGljaA0KPiA+ID4gPiA+ID4gICAgYWN0aW9ucyBhcmUg cmVxdWlyZWQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gU3VjaCBhIGRlY2lzaW9ucyBzZWVt cyBvdXQgYmV5b25kIHRoZSBhYmlsaXR5IG9mIHlvdXINCj4gPiBhdmVyYWdlDQo+ID4gPiA+IGhv bWUNCj4gPiA+ID4gPiA+IHJvdXRlciB1c2VyLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gW01lZF0g V2UgZG9uJ3QgaGF2ZSB0aGUgbm90aW9uIG9mICJhdmVyYWdlIGhvbWUgcm91dGVyIHVzZXIiDQo+ ID4gOy0pDQo+ID4gPiA+DQo+ID4gPiA+IEFncmVlZC4gIFByb2JhYmx5IG5vdCB1cyB0aG91Z2gg Oi0pLiAgTXkgaW50ZW50IHdhcyB0byBzYXkgdGhhdA0KPiA+IHdoZW4NCj4gPiA+ID4gdGhlIGFj dGlvbnMvZGVjaXNpb25zIGFyZSBiZWluZyBmcmFtZWQgYXMgYmVpbmcgZm9yIGEgIm5ldHdvcmsN Cj4gPiA+ID4gYWRtaW4iLCB0aGF0IHRvIG1lIHN1Z2dlc3RzIGEgbGV2ZWwgZXhwZXJ0aXNlIG91 dHNpZGUgb2YgdGhlDQo+ID4gPiA+IGNhcGFiaWxpdHkgb2YgdHlwaWNhbCBlbmQgY29uc3VtZXIg d2l0aG91dCBwcm9mZXNzaW9uYWwgSVQNCj4gPiA+ID4gZGVjaXNpb25zLg0KPiA+ID4gPg0KPiA+ ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiBSb21hbg0KPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IC0tIFNlY3Rpb24gOCAg4oCcLi4uIGV4cGxpY2l0IHBvbGljeSAoZS5nLiwgdGhlIENh bGwgSG9tZSBET1RTDQo+ID4gPiA+IGNsaWVudA0KPiA+ID4gPiA+ID4gYW5kIHNlcnZlciBhcmUg bWFuYWdlZCBieSB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBlbnRpdHkpLA0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IElzIHRoZXJlIGFuIHVuZGVybHlpbmcgYXNzdW1wdGlvbiB0aGF0IHRoZSBJ U1AgaXMgbWFuYWdpbmcNCj4gPiB0aGUNCj4gPiA+ID4gZGV2aWNlPw0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gW01lZF0gSVNQIG1hbmFnZWQgZGV2aWNlcyBpcyBvbmUgdHlwaWNhbCBkZXBsb3ltZW50 IGNhc2UuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGF0J3Mgc2FpZCwgdGhlIHRleHQgeW91IHF1 b3RlZCBpcyBub3Qgc3BlY2lmaWMgdG8gSVNQcy4gSXQNCj4gPiA+ID4gYXBwbGllcywNCj4gPiA+ ID4gPiBmb3IgZXhhbXBsZSwgd2hlbiBnYXRld2F5cyBhcmUgb24gdGhlIHBhdGggYW5kIGJvdGgg dGhlIENhbGwNCj4gPiBIb21lDQo+ID4gPiA+IERPVFMNCj4gPiA+ID4gPiBzZXJ2ZXIgYW5kIENh bGwgSG9tZSBET1RTIGNsaWVudCB3aWxsIHRodXMgYmUgbWFuYWdlZCBieSB0aGUNCj4gPiBEQw0K PiA+ID4gPiA+IHByb3ZpZGVyLCB0aGUgZW50ZXJwcmlzZSBhZG1pbmlzdHJhdG9yLCB0aGUgYWNj ZXNzIHByb3ZpZGVyLA0KPiA+IGV0Yy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4N Cj4gPiA+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcw0KPiA+ IGluZm9ybWF0aW9ucw0KPiA+ID4gPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+ID4gPiA+IGRpZmZ1c2VzLA0KPiA+ID4gPiA+ IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlDQo+ID4gPiA+IG1lc3NhZ2UNCj4gPiA+ID4gPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZQ0KPiA+ID4gPiBhaW5zaQ0KPiA+ ID4gPiA+IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50DQo+ID4gPiA+IHN1c2NlcHRpYmxlcw0KPiA+ID4gPiA+IGQnYWx0ZXJhdGlvbiwgT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UNCj4gPiBtZXNzYWdlIGENCj4g PiA+ID4gZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3INCj4gPiA+ID4gPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkNCj4gPiBzaG91bGQNCj4gPiA+ID4gbm90DQo+ID4g PiA+ID4gYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4NCj4gPiA+ID4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZQ0KPiA+IHNlbmRlcg0KPiA+ID4gPiBhbmQNCj4gPiA+ID4gPiBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gPiA+ID4gQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMNCj4gPiB0 aGF0DQo+ID4gPiA+IGhhdmUNCj4gPiA+ID4gPiBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4NCj4gPiA+ID4gPiBUaGFuayB5b3UuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IERv dHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gRG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ID4NCj4gPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBfXw0KPiA+ID4gX19fXyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4NCj4gPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+ID4gY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUN Cj4gPiBkaWZmdXNlcywNCj4gPiA+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlDQo+ID4gbWVzc2FnZQ0KPiA+ID4gcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUNCj4gPiBh aW5zaQ0KPiA+ID4gcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQNCj4gPiBzdXNjZXB0aWJsZXMNCj4gPiA+IGQnYWx0ZXJhdGlvbiwgT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhDQo+ID4gZXRlDQo+ ID4gPiBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+ID4NCj4gPiA+IFRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv cg0KPiA+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OyB0aGV5IHNob3VsZA0KPiA+IG5vdA0KPiA+ID4gYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+IGFuZA0K PiA+ID4gZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ID4gQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdA0KPiA+IGhhdmUNCj4gPiA+IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KPiA+ID4gVGhhbmsgeW91Lg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN Cj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleg0KPiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzDQo+IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UNCj4gZmFsc2lmaWUu IE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsNCj4gdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4gZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl bg0KPiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCg0K From nobody Mon Jan 4 17:42:01 2021 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 7FCEB3A0CB7; Mon, 4 Jan 2021 17:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 meyE2lz5dDkr; Mon, 4 Jan 2021 17:41:54 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8B73A0C2A; Mon, 4 Jan 2021 17:41:53 -0800 (PST) Received: from z.nttv6.jp (unknown [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id BB2D325F6BB; Tue, 5 Jan 2021 10:41:50 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1609810910; 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: in-reply-to:in-reply-to:references:references; bh=/tjcu27zeQ/qwXyMa7V5IrP21q4ir0OlkT+G3XnLIGc=; b=ILzdqMWTXR8g2YR6xIXXm0ve3Dcznh0I36MPNCrwz1SsMHkcBUqKTdZNGODX3smd+52rq6 sOPSGoUlEvWVnbs1ItIIFr+Ef5lyVJ3hNK63nTYlmeGUJsfGC3aYkC2GAc9cTFrM3zwJUh 11dbY2pcuG3OOqHf0M9iLa2y5GnpqTA= Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 51A1B75900E; Tue, 5 Jan 2021 10:41:50 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" , "draft-ietf-dots-use-cases@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" References: <5008_1609751917_5FF2DD6D_5008_29_10_787AE7BB302AE849A7480A190F8B9330315A67BC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <6d9bb032-dc51-1190-ad3d-729ed899e8b6@nttv6.jp> Date: Tue, 5 Jan 2021 10:41:50 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <5008_1609751917_5FF2DD6D_5008_29_10_787AE7BB302AE849A7480A190F8B9330315A67BC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/mixed; boundary="------------000301A2CE74169FBE736DD7" Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] Any reason why RFC8903 is stale since 09/20? 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, 05 Jan 2021 01:42:00 -0000 This is a multi-part message in MIME format. --------------000301A2CE74169FBE736DD7 Content-Type: multipart/alternative; boundary="------------F7B57A55E27FEA6E2925C589" --------------F7B57A55E27FEA6E2925C589 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, Attached is the latest status. Yes, it's because some authors are not responding. I hope ADs will make it move forward. thanks, Kaname On 2021/01/04 18:18, mohamed.boucadair@orange.com wrote: > > Hi all, > > This document is in AUTH48 for too long. > > It would be appreciated if the authors can share an update of the blocking issues, if any. > > If this is stale just because some authors didn’t reply, I guess this statement can be followed: > > https://ietf.org/about/groups/iesg/statements/auth48/ > > Cheers, > > Med > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------F7B57A55E27FEA6E2925C589 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,

Attached is the latest status.
Yes, it's because some authors are not responding.
I hope ADs will make it move forward.

thanks,
Kaname

On 2021/01/04 18:18, mohamed.boucadair@orange.com wrote:

Hi all,

 

This document is in AUTH48 for too long.

 

It would be appreciated if the authors can share an update of the blocking issues, if any.

 

If this is stale just because some authors didn’t reply, I guess this statement can be followed:

 

https://ietf.org/about/groups/iesg/statements/auth48/

 

Cheers,

Med  

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


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

--------------F7B57A55E27FEA6E2925C589-- --------------000301A2CE74169FBE736DD7 Content-Type: message/rfc822; name="Re: [ADs] REMINDER Re: AUTH48 [MS]: RFC 8903 NOW AVAILABLE.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Re: [ADs] REMINDER Re: AUTH48 [MS]: RFC 8903 Delivered-To: kaname@nttv6.jp Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 12DE8763508 for ; Thu, 3 Dec 2020 15:28:19 +0900 (JST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id C993C25F6CE for ; Thu, 3 Dec 2020 15:28:17 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 4F3AE3C2C25; Wed, 2 Dec 2020 22:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV-dvMtyhABo; Wed, 2 Dec 2020 22:28:15 -0800 (PST) Received: from [192.168.1.175] (cpe-172-113-155-155.socal.res.rr.com [172.113.155.155]) by c8a.amsl.com (Postfix) with ESMTPSA id 94C113C2C24; Wed, 2 Dec 2020 22:28:14 -0800 (PST) From: Sandy Ginoza Message-Id: <908580E7-0120-4838-8422-DF5CFB1A65EC@amsl.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A64B540C-0104-4F40-84CD-53D582EDF474" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [ADs] REMINDER Re: AUTH48 [MS]: RFC 8903 NOW AVAILABLE Date: Wed, 2 Dec 2020 22:27:58 -0800 In-Reply-To: Cc: "dots-ads@ietf.org" , "dots-chairs@ietf.org" To: kaname nishizuka , "Teague, Francis" , Daniel Migault , "frank.xialiang@huawei.com" , "rdobbins@arbor.net" , "rgm@labs.htt-consult.com" , "valery@smyslov.net" , RFC Editor References: <20200912232637.771B3F40786@rfc-editor.org> <4C345C79-DBD2-42A8-8748-F0FCE967DD98@amsl.com> <11297601-0A24-4547-839C-6ADCAB59D031@amsl.com> <6966c861-0413-a29f-0bd4-f36809adaa4e@nttv6.jp> <963257FF-057D-4F52-A78A-809FBAAC8684@amsl.com> <2810F5F1-7A53-44E2-965C-1D6A3B882F25@amsl.com> X-Mailer: Apple Mail (2.3273) Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=sginoza@amsl.com --Apple-Mail=_A64B540C-0104-4F40-84CD-53D582EDF474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings again, > On Dec 2, 2020, at 10:15 PM, Sandy Ginoza wrote: >=20 > Greetings, >=20 > Just a friendly reminder that we await approvals from the individuals = listed below. We have not heard anything further in the last month. =20 >=20 > Please let us know how you would like to proceed. =20 Please see for some = information regarding options for moving forward when one or more = authors is unresponsive. Thank you, RFC Editor/sg >=20 > Thank you, > RFC Editor/sg >=20 >=20 >> On Nov 3, 2020, at 3:54 PM, Sandy Ginoza > wrote: >>=20 >> Greetings all, ADs*, >>=20 >> We do not believe we have heard from the following authors since the = document entered AUTH48 on 12 September:=20 >>=20 >> Roland Dobbins >> Robert Moskowitz >> Liang Xia >>=20 >> Please help us reach these authors to move the document along to = publication.=20 >>=20 >> * ADs, please consider whether you would like to approve the document = for publication in the absence of replies from these authors per = >. =20 >>=20 >> Thank you, >> RFC Editor/sg >>=20 >>=20 >>=20 >>> On Oct 15, 2020, at 11:07 AM, Marshika Szabo > wrote: >>>=20 >>> Authors, >>>=20 >>> This is a friendly reminder that we await approval of this document = from Roland, Robert, and Liang before continuing with the publication = process.=20 >>>=20 >>> Thank you, >>> RFC Editor/ms >>>=20 >>>=20 >>>=20 >>>> On Oct 6, 2020, at 10:34 AM, Marshika Szabo > wrote: >>>>=20 >>>> Kaname, >>>>=20 >>>> Thank you for your reply. We have noted your approval on the AUTH48 = status page for this document (http://www.rfc-editor.org/auth48/rfc8903 = ).=20 >>>>=20 >>>> Once we receive approval from Roland, Robert, and Liang, we can = move forward in the publication process. >>>>=20 >>>> Thank you, >>>>=20 >>>> RFC Editor/ms >>>>=20 >>>>> On Oct 4, 2020, at 9:44 PM, kaname nishizuka > wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I approve the document. >>>>>=20 >>>>> thanks, >>>>> Kaname Nishizuka >>>>>=20 >>>>>=20 >>>>> On 2020/10/03 3:51, Marshika Szabo wrote: >>>>>> Nik, >>>>>>=20 >>>>>> Thank you for your reply. We have noted your approval on the = AUTH48 status page for this document = (http://www.rfc-editor.org/auth48/rfc8903 = ). >>>>>>=20 >>>>>> Once we receive approval from Roland, Robert, Liang, and Kaname, = we can move forward in the publication process. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thank you, >>>>>>=20 >>>>>> RFC Editor/ms >>>>>>=20 >>>>>>> On Sep 30, 2020, at 3:51 AM, Teague, Francis = > wrote: >>>>>>>=20 >>>>>>> Hi please accept this email as my approval >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>> -Nik >>>>>>>=20 >>>>>>> On Wed, 30 Sep 2020 at 03:08, Marshika Szabo > wrote: >>>>>>> Daniel, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Thank you for the reply. Your approval has been noted on the = AUTH48 status page of this document = (http://www.rfc-editor.org/auth48/rfc8903 = ). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Please note that individual approvals are needed from all = authors before we can proceed with publication. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Thank you, >>>>>>>=20 >>>>>>> RFC Editor/ms >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Sep 29, 2020, at 2:19 PM, Daniel Migault = > = wrote: >>>>>>>> Hi, >>>>>>>> Thanks for the update. This seems fine to me. I approve the = document in its current form, I believe other co-authors do so as well. >>>>>>>> Yours, >>>>>>>> Daniel >>>>>>>> From: Marshika Szabo > >>>>>>>> Sent: Tuesday, September 29, 2020 2:51 PM >>>>>>>> To: Daniel Migault >; rfc-editor@rfc-editor.org = >; rdobbins@arbor.net = >; rgm@labs.htt-consult.com = >; nteague@ironmountain.co.uk = >;frank.xialiang@huawei.com = >; kaname@nttv6.jp = >; = dots-chairs@ietf.org >; dots-ads@ietf.org = >; valery@smyslov.net = > >>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 = NOW AVAILABLE >>>>>>>> Daniel, >>>>>>>> Thank you for your reply. The updated files are listed below. = Please review and let us know if any further changes are needed or if = you approve the document in its current form. >>>>>>>> __________________________ >>>>>>>> The updated XML file is here: >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3Db2ee2c48-ec5ff728-b2ee6cd3-86e2237= f51fb-34bc4e80e849360a&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.xml = >>>>>>>> The updated output files are here: >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D14ea9126-4a5b4a46-14ead1bd-86e2237= f51fb-47c0dd293b918466&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.html = >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D99937051-c722ab31-999330ca-86e2237= f51fb-5d5406b76e285aef&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt = >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D5f73cd53-01c21633-5f738dc8-86e2237= f51fb-746924ea09641497&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.pdf >>>>>>>> This diff file shows all changes made during AUTH48: >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D1fbf387c-410ee31c-1fbf78e7-86e2237= f51fb-cf7844dcc093708c&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-auth48diff.html >>>>>>>> The other diff files are here: >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D735a325b-2debe93b-735a72c0-86e2237= f51fb-22a9f694402fe7c5&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-diff.html >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D3f70c422-61c11f42-3f7084b9-86e2237= f51fb-f9b98daad763a156&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-alt-diff.html (this = diff makes viewing moved text easier) >>>>>>>> Note that it may be necessary for you to refresh your browser = to view the most recent version. >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D440c4d21-1abd9641-440c0dba-86e2237= f51fb-9c3159eecd0ff0fd&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903 >>>>>>>> Thank you, >>>>>>>> RFC Editor/ms >>>>>>>>> On Sep 28, 2020, at 6:36 PM, Daniel Migault = wrote: >>>>>>>>> Hi Marshika, >>>>>>>>> Thanks for the feed backs. I like proposal A) better which = corresponds to your example. I really appreciate the careful review you = are performing and apology for the inconvenience. >>>>>>>>> Yours, >>>>>>>>> Daniel >>>>>>>>> From: Marshika Szabo >>>>>>>>> Sent: Monday, September 28, 2020 8:28 PM >>>>>>>>> To: Daniel Migault ; = rfc-editor@rfc-editor.org; rdobbins@arbor.net; rgm@labs.htt-consult.com; = nteague@ironmountain.co.uk; frank.xialiang@huawei.com; kaname@nttv6.jp; = dots-chairs@ietf.org; dots-ads@ietf.org; valery@smyslov.net >>>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 = NOW AVAILABLE >>>>>>>>> Daniel, >>>>>>>>> Thank you for your reply. We have one follow-up question. >>>>>>>>> Before updating the terminology, we would like to clarify the = capitalization of =E2=80=98DDoS Mitigation=E2=80=99 (when not a part of = a term). We are wondering about consistency with 'DDoS Mitigation=E2=80=99= vs. 'DDoS mitigation capacity=E2=80=99, for example. Should = =E2=80=98Mitigation=E2=80=99 be either capitalized or lowercased in = these occurrences (i.e., either A) 'DDoS Mitigation=E2=80=99 and 'DDoS = Mitigation capacity=E2=80=99 or B) 'DDoS mitigation=E2=80=99 and 'DDoS = mitigation capacity=E2=80=99)? Please let us know your preference. >>>>>>>>> One example: >>>>>>>>> Original: >>>>>>>>> DDoS Mitigation System selection and DDoS Mitigation = techniques >>>>>>>>> may depend on the type of the DDoS attack. In some cases, a = manual >>>>>>>>> confirmation or selection may also be required to choose a = proposed >>>>>>>>> strategy to initiate a DDoS Mitigation. >>>>>>>>> Perhaps: >>>>>>>>> DMS selection and DDoS Mitigation techniques >>>>>>>>> may depend on the type of the DDoS attack. In some cases, a = manual >>>>>>>>> confirmation or selection may also be required to choose a = proposed >>>>>>>>> strategy to initiate a DDoS Mitigation. >>>>>>>>> Thank you, >>>>>>>>> RFC Editor/ms >>>>>>>>> On Sep 24, 2020, at 1:32 PM, Daniel Migault = wrote: >>>>>>>>> Hi, >>>>>>>>> This looks fine to me. Thanks! >>>>>>>>> Yours, >>>>>>>>> Daniel >>>>>>>>> From: Marshika Szabo >>>>>>>>> Sent: Wednesday, September 23, 2020 8:36 PM >>>>>>>>> To: Daniel Migault ; = rfc-editor@rfc-editor.org ; = rdobbins@arbor.net ; = rgm@labs.htt-consult.com; = nteague@ironmountain.co.uk;frank.xialiang@huaw= ei.com; kaname@nttv6.jp; = dots-chairs@ietf.org; dots-ads@ietf.org = ; valery@smyslov.net >>>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 = NOW AVAILABLE >>>>>>>>> Daniel, >>>>>>>>> Thank you for your response. We have updated the document = accordingly. The updates can be found in this diff file: = https://protect2.fireeye.com/v1/url?k=3De28ec4ff-bc3f1f9f-e28e8464-86e2237= f51fb-58a1a50b42039e1c&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903. >>>>>>>>> We have two followup questions/comments. >>>>>>>>> 1. Regarding this question: >>>>>>>>> 2) >>>>>>>>> >>>>>>>>> I think the idea was to indicate we used a word defined in the = terminology. One other aspect of the capitalized terminology is that it = indicates how to read the term. >>>>>>>>> I would say before the terminology section we do not use any = capitalized letters. These are used after the terminology section. >>>>>>>>> More explicitly here are the rules I had in mind - thought I = am very flexible. >>>>>>>>> Before the terminology section we use DDoS mitigation. >>>>>>>>> After the terminology section we use DDoS Mitigation >>>>>>>>> Before the terminology section we use DDoS mitigation systems. >>>>>>>>> After the terminology section we use DMS >>>>>>>>> Before the terminology section we use DDoS mitigation service = provider >>>>>>>>> After the terminology section we use DDoS Mitigation Service = Provider >>>>>>>>> When the term is not defined in the terminology section we do = not use capitalized letters. DDoS mitigation = activities/assistance/capacity/solutions (and more) do not have = capitalized letters. >>>>>>>>> We have changed all instances of "DDOS mitigation systems" = following the Terminology section to =E2=80=9CDMS=E2=80=9D. >>>>>>>>> Please note that in other RFCs, it=E2=80=99s typical and = acceptable for the authors to pick a case that is used consistently = throughout the doc, including any sections that appear before the = Terminology section. We suggest capitalizing the terms in question = throughout the document for consistency (except for the terms that you = noted should be lowercase). Please let us know if you agree with this = approach, and we will update the text accordingly. >>>>>>>>> _______________________________________________________ >>>>>>>>> The updated XML file is here: (please be sure to refresh) >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D598cc463-073d1f03-598c84f8-86e2237= f51fb-8fe958260b9d0efe&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.xml >>>>>>>>> The updated output files are here: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D51a2cb1f-0f13107f-51a28b84-86e2237= f51fb-5c2c964f4285e824&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.html >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D7b0bb38f-25ba68ef-7b0bf314-86e2237= f51fb-03715e75f5fefdb5&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3Db41ee505-eaaf3e65-b41ea59e-86e2237= f51fb-47f02f384c6f823c&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.pdf >>>>>>>>> This diff file shows all changes made during AUTH48: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D7d832425-2332ff45-7d8364be-86e2237= f51fb-698125781005d04f&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-auth48diff.html >>>>>>>>> The other diff files are here: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D6acb9158-347a4a38-6acbd1c3-86e2237= f51fb-023bc7c261109f80&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-diff.html >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D676b608c-39dabbec-676b2017-86e2237= f51fb-302faa3b33d55773&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-alt-diff.html (this = diff makes viewing moved text easier) >>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3Db4b0aa3e-ea01715e-b4b0eaa5-86e2237= f51fb-159941795be92f5b&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188560&u=3D= http%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903 >>>>>>>>> Thank you, >>>>>>>>> RFC Editor/ms >>>>>>>>> On Sep 18, 2020, at 3:42 PM, Daniel Migault = wrote: >>>>>>>>> Hi, >>>>>>>>> Thank you for the feedbacks. I apology for the delayed = response. Please find my comment inline. Feel free to let me know if = additional information is needed. >>>>>>>>> Yours, >>>>>>>>> Daniel >>>>>>>>> From: rfc-editor@rfc-editor.org >>>>>>>>> Sent: Saturday, September 12, 2020 7:26 PM >>>>>>>>> To: rdobbins@arbor.net ; Daniel Migault = ; = rgm@labs.htt-consult.com; = nteague@ironmountain.co.uk; = frank.xialiang@huawei.com; = kaname@nttv6.jp >>>>>>>>> Cc: rfc-editor@rfc-editor.org ; = dots-ads@ietf.org ; dots-chairs@ietf.org = ; valery@smyslov.net >>>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 = NOW AVAILABLE >>>>>>>>> Authors, >>>>>>>>> While reviewing this document during AUTH48, please resolve = (as necessary) >>>>>>>>> the following questions, which are also in the XML file. >>>>>>>>> 1) >>>>>>>>> >>>>>>>>> I think the title catch them all. >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> >>>>>>>>> I cannot see the difference between the two alternatives, but = I am fine with the proposed change. >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> >>>>>>>>> Works for me. >>>>>>>>> >>>>>>>>> 4) >>>>>>>>> >>>>>>>>> I understand that i.e routers means "that is to router" and = may not capture the fact that router are only one example. It seems to = me that e.g. would be more appropriated. >>>>>>>>> >>>>>>>>> 5) >>>>>>>>> >>>>>>>>> I agree with the change. >>>>>>>>> >>>>>>>>> 6) >>>>>>>>> >>>>>>>>> That is correct. >>>>>>>>> >>>>>>>>> 7) >>>>>>>>> >>>>>>>>> I think the idea was to indicate we used a word defined in the = terminology. One other aspect of the capitalized terminology is that it = indicates how to read the term. >>>>>>>>> I would say before the terminology section we do not use any = capitalized letters. These are used after the terminology section. >>>>>>>>> More explicitly here are the rules I had in mind - thought I = am very flexible. >>>>>>>>> Before the terminology section we use DDoS mitigation. >>>>>>>>> After the terminology section we use DDoS Mitigation >>>>>>>>> Before the terminology section we use DDoS mitigation systems. >>>>>>>>> After the terminology section we use DMS >>>>>>>>> Before the terminology section we use DDoS mitigation service = provider >>>>>>>>> After the terminology section we use DDoS Mitigation Service = Provider >>>>>>>>> ... >>>>>>>>> When the term is not defined in the terminology section we do = not use capitalized letters. DDoS mitigation = activities/assistance/capacity/solutions (and more) do not have = capitalized letters. >>>>>>>>> These are only my thoughts. >>>>>>>>> >>>>>>>>> Thank you. >>>>>>>>> RFC Editor/ms/ar >>>>>>>>> On Sep 12, 2020, rfc-editor@rfc-editor.org wrote: >>>>>>>>> *****IMPORTANT***** >>>>>>>>> Updated 2020/09/12 >>>>>>>>> RFC Author(s): >>>>>>>>> -------------- >>>>>>>>> Instructions for Completing AUTH48 in XML >>>>>>>>> This is your last chance to make changes to your RFC-to-be: >>>>>>>>> draft-ietf-dots-use-cases-25.txt. >>>>>>>>> Once the document is published as an RFC, we will not make = changes. >>>>>>>>> Please follow the instructions below to complete the AUTH48 = process. >>>>>>>>> (For frequently asked questions, please see >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D2f009f05-71a05cac-2f00df9e-86959e4= 72243-a2a62c04a7d60391&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F%23auth48.) >>>>>>>>> 1) This document is being processed using xml2rfc v3 tools. >>>>>>>>> Please help us by reviewing all formats carefully during = AUTH48. >>>>>>>>> The following files are available for review: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3Dab7a2c43-f5daefea-ab7a6cd8-86959e4= 72243-3ed16037e9fe8457&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.html >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3Daabe9828-f41e5b81-aabed8b3-86959e4= 72243-7775ec61a68e5a9b&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.pdf >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D593a6547-079aa6ee-593a25dc-86959e4= 72243-07f10801c34b8c0a&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D1fc7d422-4167178b-1fc794b9-86959e4= 72243-a9bf32629bbc85ae&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.xml >>>>>>>>> (Note: you may need to view the page source to save the = file.) >>>>>>>>> Note that provides tools to = make various >>>>>>>>> kinds of diff files. We provide the following for your = convenience. >>>>>>>>> Changes to the content are best viewable in the following >>>>>>>>> diff file of the text: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D4d59b343-13f970ea-4d59f3d8-86959e4= 72243-342a6d7afc375bce&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-diff.html >>>>>>>>> Changes to the XML file are viewable in the following diff = file >>>>>>>>> (includes updates to the XML tagging and the content): >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D15ed52aa-4b4d9103-15ed1231-86959e4= 72243-7a3ad49ca536272e&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-xmldiff1.html >>>>>>>>> The following files are provided to facilitate creation of = your own >>>>>>>>> diff files of the XML. >>>>>>>>> Initial XMLv3 created using XMLv2 as input: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D0c8bb516-522b76bf-0c8bf58d-86959e4= 72243-0451ac79abde77a3&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.original.v2v3.xml >>>>>>>>> XMLv3 file that is a best effort to capture v3-related format = updates only: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3D3289aec5-6c296d6c-3289ee5e-86959e4= 72243-f6ede64e9ef6e4bc&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.form.xml >>>>>>>>> 2) Review and resolve (as necessary) any questions raised by = the RFC >>>>>>>>> Editor. The questions (if any) have been included in the XML = file as >>>>>>>>> comments marked and will be sent in a = subsequent email. >>>>>>>>> 3) Send us your changes or respond with your approval for = publication. >>>>>>>>> Please use 'REPLY ALL' so that rfc-editor@rfc-editor.org and = the parties >>>>>>>>> CC'ed on this message receive your response. >>>>>>>>> Your document will not move forward until we have received >>>>>>>>> approvals from each of the authors listed on the front page. >>>>>>>>> Your approval indicates that you approve the .xml, .html, = .pdf, >>>>>>>>> and .txt for publication. Your approval also indicates that = you have >>>>>>>>> engaged other parties (e.g., Contributors or Working Group) = as >>>>>>>>> necessary before providing your approval. >>>>>>>>> If sending changes, please do one of the following: >>>>>>>>> a. Update the provided XML file, then email us the revised = XML file. >>>>>>>>> You may use any filename for the revised file; we will = rename >>>>>>>>> it as needed. >>>>>>>>> --OR-- >>>>>>>>> b. Provide us with an explicit list of changes in this = format. >>>>>>>>> Section # (or indicate Global) >>>>>>>>> OLD: >>>>>>>>> old text >>>>>>>>> NEW: >>>>>>>>> new text >>>>>>>>> Be sure to pay particular attention to these areas of the = document: >>>>>>>>> - IANA Considerations updates (if applicable) >>>>>>>>> - Contact information >>>>>>>>> - Copyright notice and legends; see the Trust Legal = Provisions (TLP) >>>>>>>>> -- https://trustee.ietf.org/license-info/ >>>>>>>>> In particular for XMLv3, please review the XML tagging to = ensure it >>>>>>>>> is correct. In addition, please do the following: >>>>>>>>> a) if applicable, review the type attribute of each = sourcecode element >>>>>>>>> in the XML file to ensure correctness. See the xml2rfc FAQ = for details >>>>>>>>> = (https://protect2.fireeye.com/v1/url?k=3D406271c9-1ec2b260-40623152-86959e= 472243-33590a3a090fc025&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2FFAQ-xml2rfcv3.html%23q_sour= cecode). >>>>>>>>> b) review each artwork element. Specifically, should any = artwork element >>>>>>>>> be tagged as sourcecode or another element? >>>>>>>>> c) update the XML if you would like to take advantage of any = of the >>>>>>>>> new features allowed in XML v3 (e.g., superscript and = bold). >>>>>>>>> 4) If your document contains an SVG image, please be aware = that the >>>>>>>>> RFC Editor will ask you to make any necessary changes to that = file. >>>>>>>>> Revisions to SVG are most easily done in the tool used to = create >>>>>>>>> the file. Please use svgcheck to validate your SVG file >>>>>>>>> before submission (see https://pypi.org/project/svgcheck/). >>>>>>>>> 5) Review changes submitted by your coauthors (if any). We = assume that >>>>>>>>> you will speak up if you do not agree with the proposed = changes. >>>>>>>>> That is, your silence is your assent to changes submitted by = your >>>>>>>>> coauthors. Note that any changes that are beyond editorial = will be >>>>>>>>> sent to the relevant body for approval. >>>>>>>>> 6) Please reply, as the document will not be published until = we receive >>>>>>>>> approvals from each author. The details of the AUTH48 status = of your >>>>>>>>> document are here: >>>>>>>>> = https://protect2.fireeye.com/v1/url?k=3Dd67237e1-88d2f448-d672777a-86959e4= 72243-35fa6ecd41a800ca&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad792&u=3D= https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903 >>>>>>>>> Thank you for your cooperation, >>>>>>>>> RFC Editor >>>>>>>>> -------------------------------------- >>>>>>>>> RFC8903 (draft-ietf-dots-use-cases-25) >>>>>>>>> Title : Use cases for DDoS Open Threat Signaling >>>>>>>>> Author(s) : R. Dobbins, D. Migault, R. Moskowitz, N. = Teague, L. Xia, K. Nishizuka >>>>>>>>> WG Chair(s) : Liang Xia, Valery Smyslov >>>>>>>>> Area Director(s) : Roman Danyliw, Benjamin Kaduk >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The information contained in this email message and its = attachments is intended only for the private and confidential use of the = recipient(s) named above, unless the sender expressly agrees otherwise. = Transmission of email over the Internet is not a secure communications = medium. If you are requesting or have requested the transmittal of = personal data, as defined in applicable privacy laws by means of email = or in an attachment to email, you must select a more secure alternate = means of transmittal that supports your obligations to protect such = personal data. >>>>>>>=20 >>>>>>> If the reader of this message is not the intended recipient = and/or you have received this email in error, you must take no action = based on the information in this email and you are hereby notified that = any dissemination, misuse or copying or disclosure of this communication = is strictly prohibited. If you have received this communication in = error, please notify us immediately by email and delete the original = message. >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_A64B540C-0104-4F40-84CD-53D582EDF474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Greetings again,

On = Dec 2, 2020, at 10:15 PM, Sandy Ginoza <sginoza@amsl.com> = wrote:

Greetings,

Just a = friendly reminder that we await approvals from the individuals listed = below.  We have not heard anything further in the last month. =  

Please = let us know how you would like to proceed. =  

Please= see <https://www.rfc-editor.org/faq/#missingauthor> for = some information regarding options for moving forward when one or more = authors is unresponsive.

Thank = you,
RFC Editor/sg



Thank you,
RFC = Editor/sg


On Nov 3, 2020, at 3:54 PM, Sandy Ginoza <sginoza@amsl.com> = wrote:

Greetings all, ADs*,

We do not believe we have heard from = the following authors since the document entered AUTH48 on 12 = September: 

Roland = Dobbins
Robert = Moskowitz
Liang = Xia

Please help us reach = these authors to move the document along to publication. 

* ADs, please consider whether you would = like to approve the document for publication in the absence of replies = from these authors per <https://www.ietf.org/about/groups/iesg/statements/auth48/&g= t;.  

Thank = you,
RFC = Editor/sg



On Oct 15, 2020, at 11:07 AM, Marshika Szabo = <mszabo@amsl.com> = wrote:

Authors,

This is a = friendly reminder that we await approval of this document from = Roland, Robert, and Liang before continuing with the publication = process. 

Thank you,
RFC = Editor/ms



On Oct 6, 2020, at 10:34 AM, Marshika Szabo <mszabo@amsl.com> = wrote:

Kaname,

Thank you for your = reply. We have noted your approval on the AUTH48 status page for this = document (http://www.rfc-editor.org/auth48/rfc8903).

Once we receive approval from Roland, Robert, = and Liang, we can move forward in the publication process.

Thank you,

RFC = Editor/ms

On Oct 4, 2020, at 9:44 PM, kaname nishizuka <kaname@nttv6.jp> = wrote:

Hi,

I = approve the document.

thanks,
Kaname Nishizuka


On= 2020/10/03 3:51, Marshika Szabo wrote:
Nik,

Thank you for = your reply. We have noted your approval on the AUTH48 status page for = this document (http://www.rfc-editor.org/auth48/rfc8903).

Once we receive approval from Roland, Robert, = Liang, and Kaname, we can move forward in the publication process.



Thank you,

RFC Editor/ms

On Sep 30, 2020, at 3:51 = AM, Teague, Francis <nteague@ironmountain.co.uk> wrote:

Hi please accept this email as my approval

Thanks

-Nik

On Wed, 30 Sep 2020 at 03:08, Marshika Szabo <mszabo@amsl.com> = wrote:
Daniel,



Thank you for the reply. Your approval has = been noted on the AUTH48 status page of this document (http://www.rfc-editor.org/auth48/rfc8903).



Please note that = individual approvals are needed from all authors before we can proceed = with publication.



Thank you,

RFC Editor/ms



On Sep 29, 2020, at 2:19 PM, Daniel Migault = <daniel.migault@ericsson.com> wrote:
Hi,Thanks for the update. This seems fine to me. I approve the = document in its current form, I believe other co-authors do so as = well.
Yours,
Daniel
From: = Marshika Szabo <mszabo@amsl.com>
Sent: Tuesday, = September 29, 2020 2:51 PM
To: Daniel Migault <daniel.migault@ericsson.com>; rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>; rdobbins@arbor.net = <rdobbins@arbor.net>; rgm@labs.htt-consult.com<rgm@labs.htt-consult.com>; nteague@ironmountain.co.uk <nteague@ironmountain.co.uk>;frank.xialiang@huawei.com <frank.xialiang@huawei.com>; kaname@nttv6.jp<kaname@nttv6.jp>; dots-chairs@ietf.org = <dots-chairs@ietf.org>; dots-ads@ietf.org = <dots-ads@ietf.org>; valery@smyslov.net = <valery@smyslov.net>
Subject: Re: AUTH48 = [MS]: RFC 8903 <draft-ietf-dots-use-cases-25.txt> NOW AVAILABLE
Daniel,
Thank you for your reply. The updated = files are listed below. Please review and let us know if any further = changes are needed or if you approve the document in its current = form.
__________________________
The updated = XML file is here:
https://protect2.fireeye.com/v1/url?k=3Db2ee2c48-ec5ff728-b2ee6= cd3-86e2237f51fb-34bc4e80e849360a&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .xml
The updated output files are here:
https://protect2.fireeye.com/v1/url?k=3D14ea9126-4a5b4a46-14ead= 1bd-86e2237f51fb-47c0dd293b918466&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .html
https://protect2.fireeye.com/v1/url?k=3D99937051-c722ab31-99933= 0ca-86e2237f51fb-5d5406b76e285aef&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .txt
https://protect2.fireeye.com/v1/url?k=3D5f73cd53-01c21633-5f738= dc8-86e2237f51fb-746924ea09641497&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .pdf
This diff file shows all changes made during = AUTH48:
https://protect2.fireeye.com/v1/url?k=3D1fbf387c-410ee31c-1fbf7= 8e7-86e2237f51fb-cf7844dcc093708c&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= -auth48diff.html
The other diff files are here:
https://protect2.fireeye.com/v1/url?k=3D735a325b-2debe93b-735a7= 2c0-86e2237f51fb-22a9f694402fe7c5&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= -diff.html
https://protect2.fireeye.com/v1/url?k=3D3f70c422-61c11f42-3f708= 4b9-86e2237f51fb-f9b98daad763a156&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= -alt-diff.html (this diff makes viewing moved text easier)
Note that it may be necessary for you to refresh your browser = to view the most recent version.
For the AUTH48 status of = this document, please see:
https://protect2.fireeye.com/v1/url?k=3D440c4d21-1abd9641-440c0= dba-86e2237f51fb-9c3159eecd0ff0fd&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903<= br class=3D"">Thank you,
RFC Editor/ms
On Sep 28, 2020, at 6:36 = PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Marshika,
Thanks for the feed backs. I like = proposal A) better  which corresponds to your example. I really = appreciate the careful review you are performing and apology for the = inconvenience.
Yours,
Daniel
= From: Marshika Szabo <mszabo@amsl.com>
Sent: Monday, = September 28, 2020 8:28 PM
To: Daniel Migault = <daniel.migault@ericsson.com>; rfc-editor@rfc-editor.org; = rdobbins@arbor.net; rgm@labs.htt-consult.com; = nteague@ironmountain.co.uk; frank.xialiang@huawei.com; kaname@nttv6.jp; = dots-chairs@ietf.org; dots-ads@ietf.org; valery@smyslov.net
Subject: Re: AUTH48 [MS]: RFC 8903 = <draft-ietf-dots-use-cases-25.txt> NOW AVAILABLE
= Daniel,
Thank you for your reply. We have one follow-up = question.
Before updating the terminology, we would like = to clarify the capitalization of =E2=80=98DDoS Mitigation=E2=80=99 (when = not a part of a term). We are wondering about consistency with 'DDoS = Mitigation=E2=80=99 vs. 'DDoS mitigation capacity=E2=80=99, for example. = Should =E2=80=98Mitigation=E2=80=99 be either capitalized or lowercased = in these occurrences (i.e., either A) 'DDoS Mitigation=E2=80=99 and = 'DDoS Mitigation capacity=E2=80=99 or B) 'DDoS mitigation=E2=80=99 and = 'DDoS mitigation capacity=E2=80=99)? Please let us know your = preference.
One example:
Original:
DDoS Mitigation System selection and DDoS Mitigation = techniques
may depend on the type of the DDoS attack. =  In some cases, a manual
confirmation or selection = may also be required to choose a proposed
strategy to = initiate a DDoS Mitigation.
Perhaps:
DMS = selection and DDoS Mitigation techniques
may depend on the = type of the DDoS attack.  In some cases, a manual
confirmation or selection may also be required to choose a = proposed
strategy to initiate a DDoS Mitigation.
Thank you,
RFC Editor/ms
On Sep = 24, 2020, at 1:32 PM, Daniel Migault <daniel.migault@ericsson.com> = wrote:
Hi,
This looks fine to me. = Thanks!
Yours,
Daniel
From: = Marshika Szabo <mszabo@amsl.com>
Sent: Wednesday, = September 23, 2020 8:36 PM
To: Daniel Migault = <daniel.migault@ericsson.com>; rfc-editor@rfc-editor.org = <rfc-editor@rfc-editor.org>; rdobbins@arbor.net = <rdobbins@arbor.net>; = rgm@labs.htt-consult.com<rgm@labs.htt-consult.com>; = nteague@ironmountain.co.uk<nteague@ironmountain.co.uk>;frank.xialian= g@huawei.com<frank.xialiang@huawei.com>; = kaname@nttv6.jp<kaname@nttv6.jp>; = dots-chairs@ietf.org<dots-chairs@ietf.org>; dots-ads@ietf.org = <dots-ads@ietf.org>; = valery@smyslov.net<valery@smyslov.net>
Subject: Re: = AUTH48 [MS]: RFC 8903 <draft-ietf-dots-use-cases-25.txt> NOW = AVAILABLE
Daniel,
Thank you for your = response. We have updated the document accordingly. The updates can be = found in this diff file: = https://protect2.fireeye.com/v1/url?k=3De28ec4ff-bc3f1f9f-e28e8464-86e2237= f51fb-58a1a50b42039e1c&q=3D1&e=3D184d3c26-e28c-4cbe-9a5e-b37e99188= 560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903.
We have two followup questions/comments.
1. = Regarding this question:
2) <!-- [rfced] Does = "decisions" refer to "some or all of the mitigation" or
"some or all...to another DDoS Mitigation System".
Original:
 The DDoS Mitigation System may = be composed of cluster of hardware and/or
 software = resources, but could also involve an orchestrator that may take
 decisions such as outsourcing some or all of the = mitigation to another DDoS
 Mitigation System.
Perhaps:
 The DDoS Mitigation System may = be composed of cluster of hardware and/or
 software = resources but could also involve an orchestrator that may make
 decisions, such as outsourcing some or all of the = mitigation, to another
 DDoS Mitigation System.
OR
 The DDoS Mitigation System may be = composed of cluster of hardware and/or
 software = resources but could also involve an orchestrator that may make
 decisions, such as outsourcing some or all of the = mitigation to another
 DDoS Mitigation System.
We have updated the document using the second option.
2. Regarding this issue:
7) <!-- [rfced] = Throughout the text, "DDoS Mitigation" appears to be capitalized
inconsistently. Please review these occurrences and let us = know if/how
they may be made consistent.
DDoS = Mitigation vs. DDoS mitigation
DDoS Mitigation System = (DMS) vs. DDoS mitigation system(s)
DDoS Mitigation = Service Provider
DDoS Mitigation Service(s)
DDoS mitigation activities/assistance/capacity/solutions (and = more)
-->
<mglt>
I = think the idea was to indicate we used a word defined in the = terminology. One other aspect of the capitalized terminology is that it = indicates how to read the term.
I would say before the = terminology section we do not use any capitalized letters. These are = used after the terminology section.
More explicitly here = are the rules I had in mind - thought I am very flexible.
Before the terminology section we use DDoS mitigation.
After the terminology section we use DDoS Mitigation
Before the terminology section we use DDoS mitigation = systems.
After the terminology section we use DMS
Before the terminology section we use DDoS mitigation service = provider
After the terminology section we use DDoS = Mitigation Service Provider
When the term is not defined = in the terminology section we do not use capitalized letters. DDoS = mitigation activities/assistance/capacity/solutions  (and more) do = not have capitalized letters.
We have changed all = instances of "DDOS mitigation systems" following the Terminology section = to =E2=80=9CDMS=E2=80=9D.
Please note that in other RFCs, = it=E2=80=99s typical and acceptable for the authors to pick a case that = is used consistently throughout the doc, including any sections that = appear before the Terminology section.  We suggest capitalizing the = terms in question throughout the document for consistency (except for = the terms that you noted should be lowercase).  Please let us know = if you agree with this approach, and we will update the text = accordingly.
= _______________________________________________________
The = updated XML file is here: (please be sure to refresh)
https://protect2.fireeye.com/v1/url?k=3D598cc463-073d1f03-598c8= 4f8-86e2237f51fb-8fe958260b9d0efe&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .xml
The updated output files are here:
https://protect2.fireeye.com/v1/url?k=3D51a2cb1f-0f13107f-51a28= b84-86e2237f51fb-5c2c964f4285e824&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .html
https://protect2.fireeye.com/v1/url?k=3D7b0bb38f-25ba68ef-7b0bf= 314-86e2237f51fb-03715e75f5fefdb5&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .txt
https://protect2.fireeye.com/v1/url?k=3Db41ee505-eaaf3e65-b41ea= 59e-86e2237f51fb-47f02f384c6f823c&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= .pdf
This diff file shows all changes made during = AUTH48:
https://protect2.fireeye.com/v1/url?k=3D7d832425-2332ff45-7d836= 4be-86e2237f51fb-698125781005d04f&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= -auth48diff.html
The other diff files are here:
https://protect2.fireeye.com/v1/url?k=3D6acb9158-347a4a38-6acbd= 1c3-86e2237f51fb-023bc7c261109f80&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= -diff.html
https://protect2.fireeye.com/v1/url?k=3D676b608c-39dabbec-676b2= 017-86e2237f51fb-302faa3b33d55773&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903= -alt-diff.html (this diff makes viewing moved text easier)
For the AUTH48 status of this document, please see:
https://protect2.fireeye.com/v1/url?k=3Db4b0aa3e-ea01715e-b4b0e= aa5-86e2237f51fb-159941795be92f5b&q=3D1&e=3D184d3c26-e28c-4cbe-9a5= e-b37e99188560&u=3Dhttp%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903<= br class=3D"">Thank you,
RFC Editor/ms
=   On Sep 18, 2020, at 3:42 PM, Daniel Migault = <daniel.migault@ericsson.com> wrote:
Hi,
Thank you for the feedbacks. I apology for the delayed = response. Please find my comment inline. Feel free to let me know if = additional information is needed.
Yours,
Daniel
From: rfc-editor@rfc-editor.org = <rfc-editor@rfc-editor.org>
Sent: Saturday, = September 12, 2020 7:26 PM
To: rdobbins@arbor.net = <rdobbins@arbor.net>; Daniel Migault = <daniel.migault@ericsson.com>; = rgm@labs.htt-consult.com<rgm@labs.htt-consult.com>; = nteague@ironmountain.co.uk<nteague@ironmountain.co.uk>; = frank.xialiang@huawei.com<frank.xialiang@huawei.com>; = kaname@nttv6.jp<kaname@nttv6.jp>
Cc: = rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>; = dots-ads@ietf.org <dots-ads@ietf.org>; dots-chairs@ietf.org = <dots-chairs@ietf.org>; = valery@smyslov.net<valery@smyslov.net>
Subject: Re: = AUTH48 [MS]: RFC 8903 <draft-ietf-dots-use-cases-25.txt> NOW = AVAILABLE
Authors,
While reviewing this = document during AUTH48, please resolve (as necessary)
the = following questions, which are also in the XML file.
1) = <!-- [rfced] Please insert any keywords (beyond those that appear = in
the title) for use on = https://protect2.fireeye.com/v1/url?k=3Dea8e512f-b42e9286-ea8e11b4-86959e4= 72243-93001f80ddc374f5&q=3D1&e=3D335774f9-c4e0-4694-8b93-b789516ad= 792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fsearch. -->
<mglt>
I think the title catch them = all.
</mglt>
2) <!-- [rfced] Does = "decisions" refer to "some or all of the mitigation" or
"some or all...to another DDoS Mitigation System".
Original:
  The DDoS Mitigation = System may be composed of cluster of hardware and/or
=   software resources, but could also involve an orchestrator = that may take
  decisions such as outsourcing = some or all of the mitigation to another DDoS
=   Mitigation System.
Perhaps:
=   The DDoS Mitigation System may be composed of cluster of = hardware and/or
  software resources but could = also involve an orchestrator that may make
=   decisions, such as outsourcing some or all of the = mitigation, to another
  DDoS Mitigation = System.
OR
  The DDoS Mitigation = System may be composed of cluster of hardware and/or
=   software resources but could also involve an orchestrator = that may make
  decisions, such as outsourcing = some or all of the mitigation to another
  DDoS = Mitigation System.
-->
<mglt>
I cannot see the difference between the two alternatives, but = I am fine with the proposed change.
</mglt>
3) <!-- [rfced] Would "does so" be an acceptable = substitute for "honors the
request"?
Original:
  The DOTS server which = receives the DOTS Mitigation request determines that
=   it has been configured to honor requests from the requesting = DOTS client,
  and honors the request by = orchestrating its own DMS.
Perhaps:
=   The DOTS server, which receives the DOTS Mitigation request, = determines that
  it has been configured to = honor requests from the requesting DOTS client and
=   does so by orchestrating its own DMS.
-->
<mglt>
Works for me.
</mglt>
4) <!-- [rfced] For clarity = and to avoid repetition of "such as", may
"such as = routers" be changed to "i.e., routers"?
Original:
  Then the orchestrator can take further actions = such as requesting
  forwarding nodes such as = routers to filter the traffic.
Perhaps:
=   Then the orchestrator can take further actions such as = requesting
  forwarding nodes (i.e., routers) = to filter the traffic.
-->
<mglt>
I understand that i.e routers means "that is to router" and = may not capture the fact that router are only one example. It seems to = me that e.g. would be more appropriated.
</mglt>
5) <!--[rfced] Does "the above DDoS Orchestration" refer = to Figure 4?
If so, we suggest lowercasing "orchestration" = and adding the figure
number as shown below. If not, = please clarify.
Original:
  In = addition to the above DDoS Orchestration, the selected DDoS
=   mitigation system can return back a mitigation request to = the
  orchestrator as an offloading.
Perhaps:
  In addition to the DDoS = orchestration shown in Figure 4, the selected
=   DDoS mitigation system can return back a mitigation request = to the
  orchestrator as an offloading.
-->
<mglt>
I agree with = the change.
</mglt>
6) <!--[rfced] = FYI, we added "(at the time of writing)" to this phrase
as = the WG chairs have changed. Please confirm this is accurate.
Original:
the DOTS WG chairs, Roman Danyliw and = Tobias Gondrom
Current:
the DOTS WG Chairs = (at the time of writing) Roman Danyliw and Tobias Gondrom
-->
<mglt>
That is = correct.
</mglt>
7) <!-- [rfced] = Throughout the text, "DDoS Mitigation" appears to be capitalized
inconsistently. Please review these occurrences and let us = know if/how
they may be made consistent.
DDoS = Mitigation vs. DDoS mitigation
DDoS Mitigation System = (DMS) vs. DDoS mitigation system(s)
DDoS Mitigation = Service Provider
DDoS Mitigation Service(s)
DDoS mitigation activities/assistance/capacity/solutions (and = more)
-->
<mglt>
I = think the idea was to indicate we used a word defined in the = terminology. One other aspect of the capitalized terminology is that it = indicates how to read the term.
I would say before the = terminology section we do not use any capitalized letters. These are = used after the terminology section.
More explicitly here = are the rules I had in mind - thought I am very flexible.
= Before the terminology section we use DDoS mitigation.
After= the terminology section we use DDoS Mitigation
Before = the terminology section we use DDoS mitigation systems.
After the terminology section we use DMS
= Before the terminology section we use DDoS mitigation service = provider
After the terminology section we use DDoS = Mitigation Service Provider
...
When the = term is not defined in the terminology section we do not use capitalized = letters. DDoS mitigation activities/assistance/capacity/solutions =  (and more) do not have capitalized letters.
These = are only my thoughts.
</mglt>
Thank = you.
RFC Editor/ms/ar
On Sep 12, 2020, = rfc-editor@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2020/09/12
RFC Author(s):
--------------
Instructions for Completing = AUTH48 in XML
This is your last chance to make changes to = your RFC-to-be:
draft-ietf-dots-use-cases-25.txt.
Once the document is published as an RFC, we will not make = changes.
Please follow the instructions below to complete = the AUTH48 process.
(For frequently asked questions, = please see
https://protect2.fireeye.com/v1/url?k=3D2f009f05-71a05cac-2f00d= f9e-86959e472243-a2a62c04a7d60391&q=3D1&e=3D335774f9-c4e0-4694-8b9= 3-b789516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F%23auth48.= )
1) This document is being processed using xml2rfc v3 = tools.
 Please help us by reviewing all formats = carefully during AUTH48.
 The following files are = available for review:
=  https://protect2.fireeye.com/v1/url?k=3Dab7a2c43-f5daefea-ab7a6cd8-8= 6959e472243-3ed16037e9fe8457&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.htm= l
=  https://protect2.fireeye.com/v1/url?k=3Daabe9828-f41e5b81-aabed8b3-8= 6959e472243-7775ec61a68e5a9b&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.pdf=
=  https://protect2.fireeye.com/v1/url?k=3D593a6547-079aa6ee-593a25dc-8= 6959e472243-07f10801c34b8c0a&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt=
=  https://protect2.fireeye.com/v1/url?k=3D1fc7d422-4167178b-1fc794b9-8= 6959e472243-a9bf32629bbc85ae&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.xml=
 (Note: you may need to view the page source to = save the file.)
Note that = <https://tools.ietf.org/rfcdiff> provides tools to make various
kinds of diff files.  We provide the following for your = convenience.
Changes to the content are best viewable in = the following
diff file of the text:
=  https://protect2.fireeye.com/v1/url?k=3D4d59b343-13f970ea-4d59f3d8-8= 6959e472243-342a6d7afc375bce&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-dif= f.html
Changes to the XML file are viewable in the = following diff file
(includes updates to the XML tagging = and the content):
=  https://protect2.fireeye.com/v1/url?k=3D15ed52aa-4b4d9103-15ed1231-8= 6959e472243-7a3ad49ca536272e&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-xml= diff1.html
The following files are provided to facilitate = creation of your own
diff files of the XML.
Initial XMLv3 created using XMLv2 as input:
=  https://protect2.fireeye.com/v1/url?k=3D0c8bb516-522b76bf-0c8bf58d-8= 6959e472243-0451ac79abde77a3&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.ori= ginal.v2v3.xml
XMLv3 file that is a best effort to capture = v3-related format updates only:
=  https://protect2.fireeye.com/v1/url?k=3D3289aec5-6c296d6c-3289ee5e-8= 6959e472243-f6ede64e9ef6e4bc&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.for= m.xml
2) Review and resolve (as necessary) any questions = raised by the RFC
 Editor.  The questions (if = any) have been included in the XML file as
 comments = marked <!-- [rfced] ... --> and will be sent in a subsequent = email.
3) Send us your changes or respond with your = approval for publication.
 Please use 'REPLY ALL' so = that rfc-editor@rfc-editor.org and the parties
=  CC'ed on this message receive your response.
=  Your document will not move forward until we have received
 approvals from each of the authors listed on the front = page.
 Your approval indicates that you approve the = .xml, .html, .pdf,
 and .txt for publication. Your = approval also indicates that you have
 engaged other = parties (e.g., Contributors or Working Group) as
=  necessary before providing your approval.
 If = sending changes, please do one of the following:
 a. = Update the provided XML file, then email us the revised XML file.
    You may use any filename for the = revised file; we will rename
    it = as needed.
--OR--
 b. Provide us with = an explicit list of changes in this format.
=     Section # (or indicate Global)
=     OLD:
    old = text
    NEW:
=     new text
 Be sure to pay = particular attention to these areas of the document:
=  - IANA Considerations updates (if applicable)
=  - Contact information
 - Copyright notice and = legends; see the Trust Legal Provisions (TLP)
=    -- https://trustee.ietf.org/license-info/
=  In particular for XMLv3, please review the XML tagging to ensure = it
 is correct. In addition, please do the = following:
 a) if applicable, review the type = attribute of each sourcecode element
=     in the XML file to ensure correctness. See the = xml2rfc FAQ for details
=     (https://protect2.fireeye.com/v1/url?k=3D406271c9-= 1ec2b260-40623152-86959e472243-33590a3a090fc025&q=3D1&e=3D335774f9= -c4e0-4694-8b93-b789516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fma= terials%2FFAQ-xml2rfcv3.html%23q_sourcecode).
 b) = review each artwork element. Specifically, should any artwork element
    be tagged as sourcecode or another = element?
 c) update the XML if you would like to = take advantage of any of the
    new = features allowed in XML v3 (e.g., superscript and bold).
4) = If your document contains an SVG image, please be aware that the
 RFC Editor will ask you to make any necessary changes = to that file.
 Revisions to SVG are most easily done = in the tool used to create
 the file.  Please = use svgcheck to validate your SVG file
 before = submission (see https://pypi.org/project/svgcheck/).
5) = Review changes submitted by your coauthors (if any).  We assume = that
 you will speak up if you do not agree with the = proposed changes.
 That is, your silence is your = assent to changes submitted by your
 coauthors. Note = that any changes that are beyond editorial will be
=  sent to the relevant body for approval.
6) Please = reply, as the document will not be published until we receive
 approvals from each author.  The details of the = AUTH48 status of your
 document are here:
=  https://protect2.fireeye.com/v1/url?k=3Dd67237e1-88d2f448-d672777a-8= 6959e472243-35fa6ecd41a800ca&q=3D1&e=3D335774f9-c4e0-4694-8b93-b78= 9516ad792&u=3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC8903 = (draft-ietf-dots-use-cases-25)
Title =            : Use = cases for DDoS Open Threat Signaling
Author(s) =        : R. Dobbins, D. Migault, R. = Moskowitz, N. Teague, L. Xia, K. Nishizuka
WG Chair(s) =      : Liang Xia, Valery Smyslov
Area Director(s) : Roman Danyliw, Benjamin Kaduk



The information contained in this email message and its = attachments is intended only for the private and confidential use of the = recipient(s) named above, unless the sender expressly agrees otherwise. = Transmission of email over the Internet is not a secure communications = medium. If you are requesting or have requested the transmittal of = personal data, as defined in applicable privacy laws by means of email = or in an attachment to email, you must select a more secure alternate = means of transmittal that supports your obligations to protect such = personal data.

If the reader of this = message is not the intended recipient and/or you have received this = email in error, you must take no action based on the information in this = email and you are hereby notified that any dissemination, misuse or = copying or disclosure of this communication is strictly prohibited. If = you have received this communication in error, please notify us = immediately by email and delete the original message.






= --Apple-Mail=_A64B540C-0104-4F40-84CD-53D582EDF474-- --------------000301A2CE74169FBE736DD7-- From nobody Mon Jan 4 17:59:44 2021 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 98C573A0CDD; Mon, 4 Jan 2021 17:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 3OjH1kmjQzzw; Mon, 4 Jan 2021 17:59:41 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 DC0BE3A0CDB; Mon, 4 Jan 2021 17:59:40 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id f29so9789019uab.0; Mon, 04 Jan 2021 17:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kcT2gtLgsHLIgoW0fhXiE6B0veZGAsn6bDY2KVougKU=; b=mgTx2OHY/p9uaFLDWua1Jhu7FgOnQ8BppAzXa1c77OrJgVgBfA3NqE1R9j5sffFnE7 vqgZ4CtCR/JM5Q9TuafqSQoKVbXn5SmIRZZFM7I4BgIsMVjHQP1krqBeu+WX9Wo9i4Ih cicT32iz8ex+TzrQrWSC+VW0oUzr5lLU3k9YZQ/FCneJTA4bmdnulhGQxoCiZHHY+F4i nAvuBD9PaOodJTuirXLwwsWdbLaNmo3WCXniYjv6UQ9ZS7MgaQ8xbWtN5dsnHijKj03U a3jcybTO9+4Tt4zzeoh0KUYuO19ofgEyosuadxB/prOv6AmFMG8kGCKOeoIDyQpuSUrq +3Fg== 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=kcT2gtLgsHLIgoW0fhXiE6B0veZGAsn6bDY2KVougKU=; b=uOyL4tyPQBuLAoePrbCR1jmspz0bmbDRr+9J71E30SwcV2l6ek8dUMti8w7C7qV1rs FxPcIWNl6EQOkIvTWHT99zrwGPFZCidbbPAvRshgpQU1bXebcx5MWDeqAXhmnSquFqg1 SGIKRfZOfTRB3n+yPmIq5CkL+YNpkJfr+jPMKAyU1hYJzqoB5kUjNhsJNJ0NHaMAG8op SqnsDdZe7FQOAe5+rYROK9Q7gOUI6+zQLeoKfZDrVe6YFCRrbma+MY+8i1eGrebgi9Jf 44Z7DeR+Qz1xtk+OYDGyfkrJdf9j36xLuw2f5f9La9Jz5Epekmf6YhPR314IpoIgeu9N EtMA== X-Gm-Message-State: AOAM5314yx9gcdN6G1XnDuMX1sKMg7VLqxOaFwOoSB6BvFBFq/v6317z TM6H9GHfteJxW8RVTkDQeGsfk9+9WlkO+huFzeg= X-Google-Smtp-Source: ABdhPJw7+IPYeLUUn+L9vdgJvCxdqnNa58SHIsN7NnkqaXsdeBEKjj9P4MfzauSNo9NMe+hcH9WgaJSbEJMHQgD/c2g= X-Received: by 2002:ab0:244f:: with SMTP id g15mr46232230uan.80.1609811979928; Mon, 04 Jan 2021 17:59:39 -0800 (PST) MIME-Version: 1.0 References: <5008_1609751917_5FF2DD6D_5008_29_10_787AE7BB302AE849A7480A190F8B9330315A67BC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6d9bb032-dc51-1190-ad3d-729ed899e8b6@nttv6.jp> In-Reply-To: <6d9bb032-dc51-1190-ad3d-729ed899e8b6@nttv6.jp> From: Daniel Migault Date: Mon, 4 Jan 2021 20:59:29 -0500 Message-ID: To: kaname nishizuka Cc: Mohamed Boucadair , "dots@ietf.org" , "draft-ietf-dots-use-cases@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" Content-Type: multipart/alternative; boundary="0000000000003809ca05b81d8f99" Archived-At: Subject: Re: [Dots] Any reason why RFC8903 is stale since 09/20? 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, 05 Jan 2021 01:59:43 -0000 --0000000000003809ca05b81d8f99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Here is the complete status of the document: https://www.rfc-editor.org/auth48/rfc8903 Yours, Daniel On Mon, Jan 4, 2021 at 8:42 PM kaname nishizuka wrote: > Hi, > > Attached is the latest status. > Yes, it's because some authors are not responding. > I hope ADs will make it move forward. > > thanks, > Kaname > > On 2021/01/04 18:18, mohamed.boucadair@orange.com wrote: > > Hi all, > > > > This document is in AUTH48 for too long. > > > > It would be appreciated if the authors can share an update of the blockin= g > issues, if any. > > > > If this is stale just because some authors didn=E2=80=99t reply, I guess = this > statement can be followed: > > > > https://ietf.org/about/groups/iesg/statements/auth48/ > > > > Cheers, > > Med > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > _______________________________________________ > Dots mailing listDots@ietf.orghttps://www.ietf.org/mailman/listinfo/dots > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --=20 Daniel Migault Ericsson --0000000000003809ca05b81d8f99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Here is the comple= te status of the document:=C2=A0
https://www.rfc-editor.org/auth48/rfc8903

=
Yours,=C2=A0
Daniel

On Mon, Jan 4, 2021 at 8:42 PM kanam= e nishizuka <kaname@nttv6.jp> = wrote:
=20 =20 =20
Hi,

Attached is the latest status.
Yes, it's because some authors are not responding.
I hope ADs will make it move forward.

thanks,
Kaname

On 2021/01/04 18:18, moh= amed.boucadair@orange.com wrote:
=20 =20 =20

Hi all,

=C2=A0

This document is in AUT= H48 for too long.

=C2=A0

It would be appreciated= if the authors can share an update of the blocking issues, if any.

=C2=A0

If this is stale just b= ecause some authors didn=E2=80=99t reply, I guess this statement can be followed:

=C2=A0

https://ietf.o= rg/about/groups/iesg/statements/auth48/

=C2=A0

Cheers,

Med =C2=A0

________________________________________________________________=
_________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


_______________________________________________
Dots mailing list
Dots@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/dots

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


--
Daniel Migault
Ericsson
--0000000000003809ca05b81d8f99-- From nobody Wed Jan 6 07:24:39 2021 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 CDCF83A0FD0 for ; Wed, 6 Jan 2021 07:24:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 lF-ooiWHLDXO for ; Wed, 6 Jan 2021 07:24:18 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 9E65A3A0FB9 for ; Wed, 6 Jan 2021 07:24:18 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kxAfW-0001ZA-N2; Wed, 06 Jan 2021 15:24:14 +0000 From: To: , Cc: , Date: Wed, 6 Jan 2021 15:24:29 -0000 Message-ID: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdbkP95w26IDeT0/RXqAAvtrJTaBNg== Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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 Jan 2021 15:24:29 -0000 Hi Christian, Once again, thank you for the comprehensive review. Responses part 2. A new version (-04) of the draft has been published and can be found at https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ Part 1 responses were covered in the main by version -03, so you may want to look at the -02 to -04 differences. The Congestion Control section has been re-written to simplify how things work and has a new set of definitions. There is a separation of Confirmable and Non-Confirmable Congestion Control with the stated assumption that all of a body is sent as Non-Confirmable or Confirmable. Otherwise, see inline. Regards Jon > > * The list of pros and cons (with the cons being almost trivial) does > not explain to the reader why these are not a replacement; I suggest > to add: [Jon] Another disadvantage addition NEW To reduce the transmission times for CON transmission of large bodies, NSTART needs to be increased from 1, but this affects congestion control where other parameters need to be tuned (Section 4.7 of [RFC7252]). Such tuning is out of scope of this document. > > * "If the client transmits a new body of data with a new Request-Tag > to": Processing parallel requests is something Request-Tag opens up. I > don't see why there's a MUST to that; the server certainly MAY drop > the old request, but it may just as well process them in parallel. [Jon] The intent here was that garbage collection would take place sooner than later - especially when running in a lossy environment and the client has updated information to transmit. I agree that Request-Tag enables the possibility of sending multiple block requests with different payloads, and so there is a possibility that the client starts sending body A, then decides to send body B and terminate A, but a packet from B arrives before a packet from body A is received and so things fail as A does not complete. OLD If the client transmits a new body of data with a new Request-Tag to the same resource on a server, the server MUST remove any partially received body held for a previous Request-Tag for that resource. NEW If a server receives payloads with different Request-Tags for the same resource, it should continue to process all the bodies as it has no way of determining which is the latest version, or which body, if any, the client is terminating the transmission for. If the client elects to stop the transmission of a complete body, it SHOULD "forget" all tracked tokens associated with the body's Request-Tag so that a reset message is generated for the invalid token in the 4.08 (Request Entity Incomplete) response. The server on receipt of the reset message SHOULD delete the partial body. END > > * "If the server receives a duplicate block with the same Request-Tag": > Why? Being silent is the default on nonterminal blocks alredy, but in > a situation like figure 5 if the 2.04 is lost, that rule would make > it impossible for the client to ever get a successful response. > > A better rule here may be to say that it processes it all the same > (and if the payload is distinct from the first transmission's payload, > it should err out.) [Jon] Fair point OLD If the server receives a duplicate block with the same Request-Tag, it SHOULD silently ignore the packet. NEW If the server receives a duplicate block with the same Request-Tag, it SHOULD ignore the payload of the packet, but MUST still respond as if the block was received for the first time. > > * "If the server receives multiple requests (implied or otherwise) for > the same block, it MUST only send back one instance of that block.": > This might be read as "ever" rather than "per incoming request", where > probably the latter is meant. [Jon] This text has already been updated following another review "OLD If the server receives multiple requests (implied or otherwise) for the same block, it MUST only send back one instance of that block. NEW If the request includes multiple Q-Block2 Options and these options overlap (e.g., combination of M being set (this and all the later blocks) and being unset (this individual block)) resulting in an individual block being requested multiple times, the server MUST only send back one instance of that block. This behavior is meant to prevent amplification attacks." > > * "The ETag Option MUST NOT be used": This is more a factural than a > normative statement; it *can* not be used there as the server would > respond thusly. It may be used, but then that indicates that the > client is trying to verify a freshness. (However, the client should > not *start* sending an ETag once it learned the current resource's > ETag when still attempting to pull out more blocks, but that's also not > a normative requirement but a consequence of those two requests not > being matchable any more.) [Jon] OK OLD The ETag Option MUST NOT be used in the request as the server could respond with a 2.03 (Valid Response) with no payload. If the server responds with a different ETag Option value (as the resource representation has changed), then the client SHOULD drop all the payloads for the current body that are no longer valid. NEW The ETag Option should not be used in the request for missing blocks as the server could respond with a 2.03 (Valid Response) with no payload. It can be used in the request if the client wants to check the freshness of the currently cached body response. If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the old data, then the body response SHOULD be restarted with a different ETag Option value. Any subsequent missing block requests MUST respond using the latest ETag Option value. If the server responds during a body update with a different ETag Option value (as the resource representation has changed), then the client should treat the partial body with the old ETag as no longer being fresh. END > > * "then the client SHOULD drop all the payloads for the current body": > "Drop" is overly prescriptive; the client may well keep them, but > just can't consider them fresh any more. (If the client has ample > caching abilities, they might come in handy if the resource goes back > to that ETag state). Same for later "the client MUST remove any > partially received". [Jon] See previous response, otherwise OLD If the server transmits a new body of data (e.g., a triggered Observe) with a new ETag to the same client as an additional response, the client MUST remove any partially received body held for a previous ETag. NEW If the server transmits a new body of data (e.g., a triggered Observe) with a new ETag to the same client as an additional response, the client should remove any partially received body held for a previous ETag for that resource as it is unlikely the missing blocks can be retrieved. > > * "For Confirmable transmission, the client SHOULD continue to": As > above in the other direction, that's not news. [Jon] Again, we are not looking for a response (well, a request in this case as needed by Block2), just an ACK OLD For Confirmable transmission, the client SHOULD continue to acknowledge each packet as well as issuing a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for the missing blocks. NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body or, if some of the payloads are sent as Non-confirmable and have not arrived, a retransmit missing payloads response is needed. > > * "If there is insufficient space to create a response PDU": I don't > understand what that means. (Where are request options reflected > back?). [Jon] This was triggered by a question by Michael Richardson " So, given a Christmas-Tree-Packet (largest packet, every possible option space used, every extension turned on...) how much data can I get back? :-)" and not fully thought through. It could happen though with Location-Path, Location-Query, Q-Block2, ETag, Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in response to a POST. OLD If there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to reflect back all the request options as appropriate, a 4.13 (Request Entity Too Large) is returned without the Size2 Option. NEW If there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to send back all the response options as appropriate, a 4.13 (Request Entity Too Large) is returned without the Size1 Option. > > * "If the client requests missing blocks, this is treated as a new > request.": I don't think the client should even make these follow-up > requests Observe, as it already has an ongoing observation. They'd be > sent on a different token too, so setting Observe would be opening > observation up on that token, which AFAIU is not intended. (Figure 7 > example looks good to me in that respect.) > > (It may make sense to ask the client to keep Observe to make the > requests matchable just for the sake of staying in atomic-request > mode. Either way, the server should then not accept that observation > as it's not for a block 0.) [Jon] The intent here was that just a new Token should be used. OLD If the client requests missing blocks, this is treated as a new request. The Observe value may change but MUST still be reported. If the ETag value changes then the previously received partial body should be destroyed and the whole body re-requested. NEW If the client requests missing blocks, this is treated as a new Request and the Observe Option MUST NOT be included. If the ETag value changes, then the previously received partial body should be considered as not fresh and the whole body re-requested. > > * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can be > matched by the token to a unique request that already had a > Request-Tag, and the client needs to have kept that token around > matched to the transfer to make sense of it. > > No need to move that value around between subsystems, and just > dropping it from here would also remove the need for the "If the > client does not recognize the Request-Tag" clause (which would > otherwise need clarification as to what it'd mean if it recognizes it > but it doesn't match what the request was for). [Jon] Good question - it does make sense for the Request-Tag to be tracked alongside the Token in the client. OLD The data payload of the 4.08 (Request Entity Incomplete) Response Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded Request-Tag followed by 1 or more missing CBOR encoded missing block numbers. NEW The data payload of the 4.08 (Request Entity Incomplete) response is encoded as a CBOR Sequence [RFC8742]. There are one or more missing CBOR encoded missing block numbers. OLD ; This defines an array, the elements of which are to be used ; in a CBOR Sequence: payload = [request-tag, + missing-block-number] request-tag = bstr ; A unique block number not received: missing-block-number = uint NEW ; This defines an array, the elements of which are to be used ; in a CBOR Sequence: payload = [+ missing-block-number] request-tag = bstr ; A unique block number not received: missing-block-number = uint OLD A 4.08 (Request Entity Incomplete) Response Code returned with Content-Type "application/missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then re-transmits the missing payloads using the Request-Tag and Q-Block1 to specify the block number, SZX, and M bit as appropriate. The Request-Tag value to use is determined from the payload of the 4.08 (Request Entity Incomplete) Response Code. If the client does not recognize the Request-Tag, the client can ignore this response. NEW (option presentation has been reformatted) 4.08 (Request Entity Incomplete) This Response Code returned with Content-Type "application/ missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then retransmits the missing payloads using the same Request-Tag, Size1 and Q-Block1 to specify the block number, SZX, and M bit as appropriate. The Request-Tag value to use is determined from the token in the 4.08 (Request Entity Incomplete) response and then finding the matching client request which contains the Request-Tag that is being used for this Q-Block1 body. END > > * "limit the array count to 23 (Undefined value)": 23 is the maximum > length of a zero-byte length indication, not indefinite-length (31). > Both using 23 and 31 here makes sense (up to 23 to have definite > length that can be updated in-place, or exceeding that switch to > indefinite length if they still fit), but the paragraph seems to be > mixing them up. [Jon] OK OLD Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23 (Undefined value) so that the array data byte can be updated with the overall length once the payload length is confirmed or limited to MAX_PAYLOADS count. NEW Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the array count to 23 so that the initial byte with the array major type and data length in the additional information can be updated with the overall count once the payload count is confirmed. Further restricting the count to MAX_PAYLOADS means that congestion control is less likely to be invoked on the server. > > * "Each new request MUST use a unique token": Like above, this is > stating something that's not intended to be changed. [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token values are acceptable. Hence this statement. > > Congestion Control: > > * "Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected > to PROBING_RATE.": That is unexpected here. At most one such > response is sent to each request message, so why is additional > congestion control needed? [Jon] The intention here was that in the previous paragraph that it was not the individual packets that are subject to PROBING_RATE, but a single body comprising of multiple packets is subject to PROBRING_RATE - and hence limiting any individual responses to PROBING_RATE rather than the potentially full set of responses OLD PROBING_RATE parameter in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. The body of blocks will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]). NEW PROBING_RATE parameter in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. The single body of blocks will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. If the wait time between sending bodies that are not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the gap time is limited to NON_PROBING_WAIT. Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customized defaults as discussed in Section 4.5.2 of [RFC8782]. END > > On the other hand, *ever* NON request is subject to PROBING_RATE, so > why point out the body of blocks and "GET or similar" particularly? [Jon] It is only GET or FETCH. The intention here is to not request bodies of data at too high a rate. OLD Each NON GET or similar request using Q-Block2 Option is subjected to PROBING_RATE. NEW Each NON GET or FETCH request using Q-Block2 Option is subjected to PROBING_RATE. > > * "a delay is introduced of ACK_TIMEOUT": As I understand MAX_PAYLOADS, > this is (rather implicitly) introduced as the package count up to > which it is OK to exceed PROBING_RATE temporarily (but after that it > kicks in all the harder by requiring to wait until complete-sent-bytes > over PROBING_RATE has expired). If that holds, at that time a much > larger delay than just ACK_TIMEOUT is needed to get a response from > the server: About 3 hours (see later note on parameters). [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write of Congestion Control section. > > This is the crucial point in the document, and for it a recommendation > alone is not good enough. The protocol can be run with a vastly > increased PROBING_RATE (however externally determined) and from the > point of MAX_PAYLOADS just observe it. Or it has to get feedback from > the server; a single 4.08 is probably enough to kick off another > vollley of blocks. (How many? MAX_PAYLOADS for every response?). > Both can be permitted, but just waiting ACK_TIMEOUT isn't doing any > good. [Jon] See re-write of Congestion Control section where things should now be simpler and more logical. There is an introduction of new variable definitions. > > * "For NON transmissions": This seems to imply that the full exchange of > a body is either NON or CON; I don't see where that'd come from. I'd > have expected to read something like "Each individual request can be > NON or CON independent of the others. In particular, it can be > convenient to send the ultimate payload...". [Jon]The DOTS environment will only be using NON. To make Congestion Control simple, the expectation is that all transmissions are NON or (not recommended) are all CON. The draft now generally records this expectation. > > * "If a Confirmable packet is used, then the transmitting peer MUST wait > for the ACK": Why? A NSTART > 1 would give it leisure to still > transmit. [Jon] Text has been removed in the clean-up. > > * General on congestion control: It may help implementors if this were > split up into newly introduced rules and concepts (that is, > MAX_PAYLOADS and the answer to whether you may send MAX_PAYLOADS > en > block again after having only even one response from the last round, > and probably the recommended parameters of the "Also on parameters" > comment), and another subsection on how Q-Block behaves well when > observing these. [Jon] Should now be covered in the updated Congestion Control section. > > Caching: > > * "are not part of the cache key": How about "are removed as part of the > block assembly and thus do not reach the cache"? [Jon] OK. OLD As the entire body is being cached in the proxy, the Q-Block1 and Q-Block2 Options are not part of the cache key. NEW As the entire body is being cached in the proxy, the Q-Block1 and Q-Block2 Options are removed as part of the block assembly and thus do not reach the cache. > > * "When the next client completes building the body": If the proxy > chooses not to let them happen in parallel (which it may, see above on > parallel requests, although the server might still not support it and > cancel one of them), why bother letting the first finish just to abort > it? (IOW: If the proxy does not intend to see both through, which it > could if it held back the second until the first is through on the > uplink, it could just as well err out of one of them early, but it may > also rather see both through.) [Jon] It has to be assumed that traffic to/from the origin client and origin server may not both support Q-Blockx and potentially may have a different SZX. Thus passing a request or a response through at the block level introduces a new set of challenges (but not impossible to fix). To keep this simple, my thinking was that the passing through can only take place at the body level. Again, the arrival of packets is not necessarily sequential, so client A's body may start transmitting to the origin server first, but client B's body starts to arrive first - the same being true for the proxy as a client may stop transmitting for whatever reason (restart, network loss etc.). However this is covered by the above update " If a server receives payloads with different Request-Tags for the same resource, it should continue to process all the bodies". OLD and the new body representation transmission starts with a new Request-Tag value. NEW and the new body representation transmission starts with a new Request-Tag value. Note that it cannot be assumed that the proxy will always receive a complete body from a client. > > * Examples: > > * Figure 5: The ... between e3 request and response indicate the > MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose there > should be the same kind of delay between the failed e5 transmission > and the e4 response. [Jon] Agreed and added in > > * If the second burst had 3 requests out of which 2 made it, is there > any guidance for which of them the 4.08 would come back on? (In the > end, none of them is terminal). [Jon] The client should tracking all Tokens of the burst (hence implementation note about bottom 32bits unique and top 32 bits matching block number for ease of tracking) for a response and so it will make no difference at to which token is used for the 4.08 response. From an implementation perspective, it probably is easier to track the last opaque token that has the same Request-Tag. OLD missing ones in one go (Figure 5). It does so by indicating which blocks have been received in the data portion of the response. NEW missing ones in one go (Figure 5). It does so by indicating which blocks have been received in the data portion of the response. The Token just needs to be one of those that have been received for this Request-Tag , so the client can derive the Request-Tag. > > * If that e4 response gets lost, does the whole mechanism recover from > it in any way? [Jon] In this example, if e4 and e5 get lost, there will be no 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to whether it sends the request again or gives up. See 9.1 "Under high levels of traffic loss, the client can elect not to retry sending missing blocks of data. This decision is implementation specific." > > Generally, the all-NON and all-CON examples don't look to me like > what I'd be doing with this spec; the mixed "a CON every > MAX_PAYLOADS" appears much more realistic. [Jon] It is unsafe to use CON in the (potentially lossy) DOTS environment (up to 93 secs timeout per payload with the defaults). Hence why we are separating out the NON / CON usage. > > * Figure X: The request ahs M unset and thus indicats a request for > just that block. If more than one is expected, it should say > QB2:0/1/1024. [Jon] With Figure 7, with the M bit set, block 3 would get returned for a second time. Draft-ietf-core-new-block-03 also has a Figure 8 which does exactly what you describe. > > * New Content Format: I think this needs a media type registration to go > with it first; based on that, a content format can be registered. [Jon] Med has responded to this and draft updated. > > * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not > sure > they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is defined > in terms of reliable transmission, but used for NONs as well. (So is > the alternative ot 2x ACK_TIMEOUT). [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT in a NON environment. Hence re-write of Congestion Control section defining new variables that can be used for NON. > > For the purpose of delaying a 4.08 or a follow-up GET, it may make > more sense to define a new parameter based on MAX_LATENCY and the > time > it takes the sender to pump out the options (which I don't think we > have a good factor for, but may even be negligible here). > > Could read like this: > > > The timing parameter MAX_BLOCK_JITTER is introduced, and by default > > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / BANDWIDTH. [Jon] Lets plug in some numbers here. MAX_LATENCY = 100, MAX_PAYLOADS = 10, MTU = 1280bytes and BANDWIDTH = 1Mbps. [Jon] MAX_BLOCK_JITTER = 100 + (10 * 1280 * 8)/(1 000 000) = 100.1. So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps makes MAX_BLOCK_JITTER 200 seconds. > > > > With Q-Block2, a client can ask for any missing blocks after not > > having received any further response for the duration of > > MAX_BLOCK_JITTER. [Jon] 100+ seconds delay is way too much time to wait for any missing blocks in my opinion. [Jon] RFC7252 also states (and the intention is that recovery works well) " as MAX_LATENCY is not intended to describe a situation when the protocol works well, but the worst-case situation against which the protocol has to guard." > > > > With Q-Block1, a server holds off any response for MAX_BLOCK_JITTER > > unless all blocks have been received. Only then it evaluates whether > > to respond with a 2.0x code, a 4.08 with payload, or not at all > > (because it responded to a later request). [Jon] I am not convinced that this is necessarily the way to go. The new Congestion Control more cleanly handles this. > > This also brings me back to the earlier matter of 2.31: What is a > server supposed to send when no packages were lost, but it's pasing > the timeout and wants to help the client flush out more packages by > confirming something? It says 4.08 in 3.3, but it's not like there's a > hole in the contiguous range. Does it need to send 4.08 enumerating > all (or at least some) numbers between the first unreceived and what's > indicated by Size1? Or can it just send 2.31 and the client knows all > it needs to know b/c the response came to the largest block that was > sent and 2.31 indicates that everything is good up to that point? [Jon] The previous draft states (under Congestion Control) that the client waits for ACK_TIMEOUT before transmitting the next set of MAX_PAYLOADS blocks. The server should wait for "two times ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps having a new name for ACK_TIMOUT I think that these are reasonable values for Non-Confirmable - and are used in the new Congestion Control section. [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a signal to say that all of the current MAX_PAYLOADS payloads of a body have been received, so allowing the client to continue transmitting the next set of MAX_PAYLOADS payloads without the need to wait any longer. > > * Also on parameters: This document is describing flow control stuff > around a situation CoAP was not originally designed for. Wouldn't it > make sense to include a set of parameters (PROBING_RATE, MAX_LATENCY, > ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > PROBING_RATE will be left to 1 byte/second for any DOTS application > using this (for sending 10KiB in the initial 10-package MAX_PAYLOADS > burst would mark that connection as unusable for about 3 hours if they > all get lost), so better give justifiable numbers here than rely on > implemnetors to come up with unreviewed numbers or disregard > PROBING_RATE altogether. [Jon] Answered by Med, and some new text added. > > I don't know if it needs additional justification, but an increased > N_START may be justifiable there. [Jon] It may be, but tuning the other associated parameters is really out of the cope of this draft. This text has been added NEW Congestion control for CON requests and responses is specified in Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will need to be increased from 1. However, the other CON congestion control parameters will need to be tuned to cover this change. This tuning is out of scope of this document as it is expected that all requests and responses using Q-Block1 and Q-Block2 will be Non- confirmable. > > * Somewhere (never comes up but I think it should): When CONs are used, > a 4.08 (or 2.31?) response to a later request can indicate to the > client that an earlier CON request has been processed successfully. If > the client can match that up (and it should be able to), then it can > (and should) cancel that particular CON request. [Jon] I think that this is covered by my update above with the text " NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body or, if some of the payloads are sent as Non-confirmable and have not arrived, a retransmit missing payloads response is needed." And in my previous part 1 response (updated) NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body or, if some of the payloads are sent as Non-confirmable and have not arrived, a retransmit missing payloads response is needed. > > Best regards > Christian > > -- > There's always a bigger fish. > -- Qui-Gon Jinn From nobody Wed Jan 6 07:40:06 2021 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 27A453A0EF4; Wed, 6 Jan 2021 07:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 Hkqw9PJTQ_-3; Wed, 6 Jan 2021 07:39:58 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 AB5BB3A0EF1; Wed, 6 Jan 2021 07:39:58 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4D9tpj35CPz108b; Wed, 6 Jan 2021 16:39:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1609947597; bh=qDHmM5ZBqpbDJZLBovXBj8VW8BoLtNixcZ/ZS09EAaU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=QG+RkbVp9AYDKgg4uF4nv4Zdgf29lfhIRSflEPrVbFQDGZ3HLMpnl6mo5wLP0ngJC nPqbC8PTGjdVMWBClcf0OD9KIEU+ivO0GaGJ/TyAj4hBEW3Pl3QOlLrziSR5YyDNhY YH9kXP81COJgPaQcWWx2eUWFeUEbANsc+xfAmDJDlZt2Ce/93uIvzRlyHvYnqUGmQd pD3xwbu50yjGqUxoVg5+nEZh6vsQaJSkhxpQtCh1dNxmVMM50kR5Iyyxgq2E/Dq9kI +xXHKq216Dmz9P/nuXGu2CXhMBrqnOECd+RkvdYl+NFVfEoYNPtPpItAZGULdc4eUp uIK3R7sjq3iGg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4D9tpj2Lk2zFpWX; Wed, 6 Jan 2021 16:39:57 +0100 (CET) From: To: "supjps-ietf@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AdbkP95w26IDeT0/RXqAAvtrJTaBNgAAX/ig Date: Wed, 6 Jan 2021 15:39:56 +0000 Message-ID: <16435_1609947597_5FF5D9CD_16435_116_1_787AE7BB302AE849A7480A190F8B9330315A8410@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> In-Reply-To: <022401d6e440$06763ba0$1362b2e0$@jpshallow.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] [core] WG Last Call on draft-ietf-core-new-block 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 Jan 2021 15:40:00 -0000 Hi all,=20 One clarification below.=20 Cheers, Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de supjps- > ietf@jpshallow.com > Envoy=E9=A0: mercredi 6 janvier 2021 16:24 > =C0=A0: christian@amsuess.com; draft-ietf-core-new-block@ietf.org > Cc=A0: dots@ietf.org; core@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Christian, >=20 > Once again, thank you for the comprehensive review. >=20 > Responses part 2. A new version (-04) of the draft has been > published and can be found at > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ >=20 >=20 > Part 1 responses were covered in the main by version -03, so you may > want to look at the -02 to -04 differences. [Med] Actually, -03 addresses the WGLC comments from Marco while -04 addres= ses those from Christian. A diff against -03 is thus sufficient to track th= e changes based on Christian's review. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jan 7 04:17:39 2021 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 124DE3A101A; Thu, 7 Jan 2021 04:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 GUw824Y6V6EY; Thu, 7 Jan 2021 04:17:28 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2075.outbound.protection.outlook.com [40.107.21.75]) (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 C0EAA3A1016; Thu, 7 Jan 2021 04:17:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Topt65UAr+x/V8ddD3+CEudq5jU6RvORh55RMk2ZJyrm4dFjMop7rb4Nuk0oDu/RSZ+iRIzLrfiWCX84AoGITi4fNbutxMYcHkYp+F4w2IfygkU2qaaQABrhljbncxU3s+482fpzfFLbStxNBTDU0kH8x3IwifSDpICzXvJN2kpAnPh8nHaY6XHSh4+LWglHTptkXePHs/+spt98pjm/QFoYBIrjg5cG58338mNPHUnfpyFDSd6ksPVZ7ziG1B8Ng/3HJ0VZMTQoN1CFLwoCwOtisrjgaYcGiL9RQqclaHjKbCuVGDOAmYY42dEwweUUL1+4ZJUVtM2KW+VMRLfqLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U9Thpby5E1uOeHIcoKpDqDQ7cv794g3zTjAwe+Kiyz0=; b=km4oJcX8pIUsnsgAWoEb1u/kfXHQ1QAKm6cbfCDL0Edelaz6XxMyv3Qbg5l/AWmLOR4VVhQshv9FajBsK1B6YrOVUw3FRzfwWUnc++gRlZe0DG/LFzQorG5Y8onQZG4aBJVh3Y+1WbSqq/iK6p5lG/XLR2h1p4I7dKWmV0xSpMn4XvTwi6e66KQ9980OIqrHTjlAHJdr9DL14SKlpNSWKSCPl4VD/iL/oamVe5+pKnonlbLmijYOoAmhoOfWTBmh1YscwWRZfVolTmb7aYtMpCvcTaBgD6N05wy34KqW5C8wVLrLR4plevwzyZgpWrgo6QXgzAmd/u5M8x1zjgnHiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U9Thpby5E1uOeHIcoKpDqDQ7cv794g3zTjAwe+Kiyz0=; b=ckrQjdQ1EVFfaqXnYWAF3SyuW+cz6hQyBkrnocy5X/rt9EyvRD3V+OSNHyoebIAQn2LR56rhd6j7lkyjFsZBC+dgs6xsub05ci48qSIshqKd1o7FIAfvupuLOXlFsp6P0NfQduCRxNT+BEi3q5e/1r6gJajmdzRF/cSq2w/BhNU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0935.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:165::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Thu, 7 Jan 2021 12:17:23 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.006; Thu, 7 Jan 2021 12:17:22 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Thu, 7 Jan 2021 13:17:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP" X-Originating-IP: [185.236.42.27] X-ClientProxiedBy: HE1PR09CA0063.eurprd09.prod.outlook.com (2603:10a6:7:3c::31) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.2] (185.236.42.27) by HE1PR09CA0063.eurprd09.prod.outlook.com (2603:10a6:7:3c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Thu, 7 Jan 2021 12:17:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: eaf8be0f-eecc-44f9-20a6-08d8b3062ffd X-MS-TrafficTypeDiagnostic: DB8P189MB0935: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +MT1Vtc4grRiYz84SQKdmy7p8JVnwQt2PtefMMB9x4iHz/tW/BVVztUV81EOr875P5nFwxLvjcxUydoojkDVEkG3IiGSggz8BnFk90E2wjrh8vrv1xU8kbwo7iA87ubyMMWdpU3jz25tpCR7DXAPzlyuFXb4pCTx2Sg+rJ12R8g7Z4HIqCVuRHNcWoR3Qbie0cdp+27/TfnCAuHArBXy65kjIS16DRXU/youO/Wp1Xig/vCoKVnhB+Tcyu0FfXJLHFsobFQd8FWkoXN5JMMo/QKCsUiiCZOyzmn8V0ti7q6ymflRKY4C/DBDUxwrcFs3b//q4Nzdd9S0SwrByuzj2ThTZ1DbEkHz2K7ntYZSaGE0nov31hjfJWwKe99wnvAFRn5cRGABdx6VdbcrbOVrm47I/yXJHubKMPH5gDnN4Mw6KxE36tLR//cMYxIFlK0pLkvpVfEDKCZGJeeuBoUTYjDswZRvSxUT/R/DiLKdy8b3W96N+5//+5n6/G/AAKFBIAaFsdKG7IyGFMfhKdITg7jFbZuF/lFs+riLZEhGwBqLmZgsZrgZZYfrDaSDiRfu X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(396003)(346002)(136003)(376002)(366004)(31686004)(66946007)(44832011)(66556008)(66476007)(966005)(53546011)(66574015)(6486002)(45080400002)(33964004)(52116002)(478600001)(8676002)(2616005)(235185007)(956004)(16576012)(2906002)(31696002)(36756003)(6666004)(4326008)(5660300002)(86362001)(16526019)(186003)(26005)(83380400001)(8936002)(30864003)(21480400003)(316002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?VkNlRTdjVlVlKzNPREJGTHFEZ2wwZ1M4VWFnQ2g5UktlY1ZhelN2NlBwZmw2?= =?utf-8?B?SzFKQ3IzdWoyLzRmeXF4U1RHT1piUDREMHZuVUl0QkpyRFFDOHF6T2xoVTFs?= =?utf-8?B?bXRNWFFVR29GNTc0cHNZSGd1M0VUcU1CMy9waWxXQThjbHhISDFkRjlsOUJW?= =?utf-8?B?S0hBZHVmeUpzVHpLa3E3RnlqQWVxUGwzN0trVWpacjBIelZsUkpDMElmNUlB?= =?utf-8?B?aHVhM3FSNFhuV1BDUElNclRZQ2kxSGpKZmNTRVBweCtqM1YwWWI5VzJyc0NY?= =?utf-8?B?aERwdUdHTTY2OGFEeEF0YnZBZXlEaUg1cUhlNVd2QWc0U0lJQmMrV25HZEZU?= =?utf-8?B?ek5UNXJTd0podUpUa2dCeWRiSDBlL0FjcXNOUm5BTnhhdGgxaGhaRktXRzhp?= =?utf-8?B?dGhXOXR3VjFXL2dVa3ZnQ3pSMnR0QTEvSUZWU0srZGt1aUwzUjlEYTRrdmh6?= =?utf-8?B?MG1obkszT0NOMlF6VVhwNnViendvMnNiZXFCZ1E0UWJydlZrYWFKKzFoQkZE?= =?utf-8?B?clUyU216L25GMlkzNHJRaEMzWXNrM0lWaHc2S2pKRExhVmxjVUhXcmlmb2VF?= =?utf-8?B?NnFMKzFnOW5vN1V1Ri9yWmZMbE93WDg1RzBvMmJPRzRJM2FWSjd2bDJsN242?= =?utf-8?B?aS9TMElOL1NhVE4xY3BnSHI1eHhYcS9BZ2lsUXU1Wm0yVWJKSXdETmNhUExt?= =?utf-8?B?ZU8xUXUzSjIwcjJ3eXc2L3pyN2VTMU5uaUJDa293a2o2VmhSS29aVnppTXVi?= =?utf-8?B?MFdYMzVDVE90RS9GejlRWGNLSEZoYTdtdHR4VGN6Rm80amR1TjNzQVBzSE1T?= =?utf-8?B?dHJEUDk0azY1YVBUc3AyZnpIY2tUd1RsQnYxZXk1c28zaFNRVEVDNGZ0VFRo?= =?utf-8?B?RS8zVDEybGN2cUpVSEdiTm0vR3VFTC9GQWVZZC9FeStOd1BneW1YUnpCekVF?= =?utf-8?B?Ym9EUTJvMGFOSlBPTHFlckRLcHoxdE5xRDllc3VDV3hVYjVSR1pYWjlvT0xx?= =?utf-8?B?K1BQOUhXMnhTbzJyUUxRa2VZaXdZVGxocDhqc3JzNENQQUhOYTV6WXUrcldL?= =?utf-8?B?WHFuWWQzb0l0Q0tOVVcvYjlPQ2dnbFhVL2pIenVxRlVVeVpLTmY5ZktWVDBU?= =?utf-8?B?WnRWRTZDb2R0YnlDTWlYTFBHWld2eDY5Ui9DOEdnN2EzTFJQdk13azVpdUJV?= =?utf-8?B?dnZLQmRZcnFYV09CRGxPYzhZZ1R2dnFGRCtSMXd5VWxNdkZnYThUOERLeXV0?= =?utf-8?B?anVaMU05cUY3TkgzY3ZJZEorUGlKdzBwWGZDUVZHUEFHYXBvSFBmaEMrNmpY?= =?utf-8?Q?yYgTyDxrN02VXBR42JM325oiKnOtL1Ym5y?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2021 12:17:22.8173 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: eaf8be0f-eecc-44f9-20a6-08d8b3062ffd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rczuPEYztmzlmc2AZ+nwBX7cswGaqYg8rAbI8dn43ym6Lu3zoa2BCaLPGmYCK0HfBhJ7toH0Xsz3HMltVNM3Cw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0935 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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 Jan 2021 12:17:33 -0000 --dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP Content-Type: multipart/mixed; boundary="6NBo78rvo9ddgGch7u9vPyzQZAAono3DS" --6NBo78rvo9ddgGch7u9vPyzQZAAono3DS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, Thanks for this revision and for addressing my comments already in version=C2=A0 -03. Please, see below some more comments on this version -04. Best, /Marco * s/There are one or more missing CBOR encoded missing block numbers./There are one or more CBOR encoded missing block numbers. *=C2=A0 Section 4 now includes the new paragraph: "The token to use for t= he response SHOULD be the token that was used in the highest block number received payload.=C2=A0 The Q-Block1 Option from the same packet SHOULD b= e included." =C2=A0=C2=A0 Consistently, the example in Figure 5 should also have QB1:3= /0/1024 in the 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 response with Token T:0xe4. =C2=A0=C2=A0 Since "SHOULD" is used, when is it still fine or expected to= not include Q-Block1 in a 4.08 response? * When commenting the example in Figure 5, Section 9.1 reads: "The Token just needs to be one of those that have been received for this Request-Tag, so the client can derive the Request-Tag." =C2=A0=C2=A0 Should this not be aligned with the SHOULD used in Section 4= about using the Token from the same packet conveying the highest block number? =C2=A0=C2=A0 =C2=A0=C2=A0 You explained in your mail that the client keeps tracking al= l Tokens in the burst anyway, so maybe it's better to rather align the text in Section 4 with what suggested here in Section 9.1, i.e. responding with any of those Token values is just fine. =C2=A0=C2=A0 =C2=A0=C2=A0 In such a case, the Q-Block1 option included in the 4.08 res= ponse has still to be the one from the request conveying the highest block number. Correct? * The new text in Section 6.2 says: "... and the situation re-evaluated for another 24 hour period until there is no report of missing payloads under normal operating conditions." =C2=A0=C2=A0 When that happens, I suppose MAX_PAYLOADS is right away rest= ored to the intended value, i.e. it is not incremented by 1 to start another 24-hour period evaluation. Correct? * Section 6.2 says: "The request that the client sends to acknowledge the receipt of all the current set of MAX_PAYLOADS payloads SHOULD contain a special case Q-Block2 Option with NUM set to the first block of the next set of MAX_PAYLOADS payloads and the M bit set to 1." =C2=A0 Is it possible to reflect this in the example of Figure 6? It woul= d require the body to have more than MAX_PAYLOADS blocks thus resulting in more bursts, which would be inherited by the examples in Figure 7 and Figure 8. * In Section 9, it would be good to have the parameters defined in Section 6.2 and their values reflected in the examples, when applicable. E.g., MAX_PAYLOADS is at least 4 in these examples; the asked retransmissions are presumably due sometimes to MAX_PAYLOADS compared against the value of the latest received Q-Block1/Q-Block2, while sometimes to NON_RECEIVE_TIMEOUT. * In the example in Figure 6, shouldn't the first request from the client have the M bit set to 1 in the Q-Block2 option, i.e. as QB2:0/1/1024 ? As per Section 3.4, that would indicate that the request is in fact for the block 0 and for all of the remaining blocks within the body. On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > Hi Christian, > > Once again, thank you for the comprehensive review. > > Responses part 2. A new version (-04) of the draft has been published = and > can be found at https://eur02.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&am= p;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b257478= 0%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7jgTY= %3D&reserved=3D0 > > > Part 1 responses were covered in the main by version -03, so you may wa= nt to > look at the -02 to -04 differences. > > The Congestion Control section has been re-written to simplify how thin= gs > work and has a new set of definitions. There is a separation of Confirm= able > and Non-Confirmable Congestion Control with the stated assumption that = all > of a body is sent as Non-Confirmable or Confirmable. > > Otherwise, see inline. > > Regards > > Jon > >> * The list of pros and cons (with the cons being almost trivial) does >> not explain to the reader why these are not a replacement; I suggest= >> to add: > [Jon] Another disadvantage addition > NEW > To reduce the transmission times for CON transmission of large bodies, > NSTART needs to be increased from 1, but this affects congestion contro= l > where other parameters need to be tuned (Section 4.7 of [RFC7252]). S= uch > tuning is out of scope of this document. > >> * "If the client transmits a new body of data with a new Request-Tag >> to": Processing parallel requests is something Request-Tag opens up.= I >> don't see why there's a MUST to that; the server certainly MAY drop >> the old request, but it may just as well process them in parallel. > [Jon] The intent here was that garbage collection would take place soon= er > than later - especially when running in a lossy environment and the cli= ent > has updated information to transmit. I agree that Request-Tag enables t= he > possibility of sending multiple block requests with different payloads,= and > so there is a possibility that the client starts sending body A, then > decides to send body B and terminate A, but a packet from B arrives bef= ore a > packet from body A is received and so things fail as A does not complet= e. > > OLD > If the client transmits a new body of data with a new Request-Tag to= > the same resource on a server, the server MUST remove any partially > received body held for a previous Request-Tag for that resource. > NEW > If a server receives payloads with different Request-Tags for the sam= e > resource, it should continue to process all the bodies as it has no way= of > determining which is the latest version, or which body, if any, the cli= ent > is terminating the transmission for. > > If the client elects to stop the transmission of a complete body, it = > SHOULD "forget" all tracked tokens associated with the body's=09 > Request-Tag so that a reset message is generated for the invalid=09 > token in the 4.08 (Request Entity Incomplete) response. The server=09 > on receipt of the reset message SHOULD delete the partial body. > END > >> * "If the server receives a duplicate block with the same Request-Tag"= : >> Why? Being silent is the default on nonterminal blocks alredy, but i= n >> a situation like figure 5 if the 2.04 is lost, that rule would make >> it impossible for the client to ever get a successful response. >> >> A better rule here may be to say that it processes it all the same >> (and if the payload is distinct from the first transmission's payloa= d, >> it should err out.) > [Jon] Fair point > OLD > If the server receives a duplicate block with the same Request-Tag, > it SHOULD silently ignore the packet. > NEW > If the server receives a duplicate block with the same Request-Tag, > it SHOULD ignore the payload of the packet, but MUST still respond = as if > the block was received for the first time. >> * "If the server receives multiple requests (implied or otherwise) for= >> the same block, it MUST only send back one instance of that block.":= >> This might be read as "ever" rather than "per incoming request", whe= re >> probably the latter is meant. > [Jon] This text has already been updated following another review > "OLD > If the server receives multiple requests > (implied or otherwise) for the same block, it MUST only send back on= e > instance of that block. > NEW > If the request includes multiple Q-Block2 > Options and these options overlap (e.g., combination of M being set > (this and all the later blocks) and being unset (this individual > block)) resulting in an individual block being requested multiple > times, the server MUST only send back one instance of that block. > This behavior is meant to prevent amplification attacks." > >> * "The ETag Option MUST NOT be used": This is more a factural than a >> normative statement; it *can* not be used there as the server would >> respond thusly. It may be used, but then that indicates that the >> client is trying to verify a freshness. (However, the client should >> not *start* sending an ETag once it learned the current resource's >> ETag when still attempting to pull out more blocks, but that's also = not >> a normative requirement but a consequence of those two requests not >> being matchable any more.) > [Jon] OK > OLD > The ETag Option MUST NOT be used in the request as the server could > respond with a 2.03 (Valid Response) with no payload. If the server= > responds with a different ETag Option value (as the resource > representation has changed), then the client SHOULD drop all the > payloads for the current body that are no longer valid.=20 > NEW > The ETag Option should not be used in the request for missing blocks= as > the server could respond with a 2.03 (Valid Response) with no payload. = It > can be used in the request if the client wants to check the freshness o= f the > currently cached body response. > > If the server detects part way through a body transfer that the resourc= e > data has changed and the server is not maintaining a cached copy of the= old > data, then the body response SHOULD be restarted with a different ETag > Option value. Any subsequent missing block requests MUST respond using = the > latest ETag Option value. > > If the server responds during a body update with a different ETag Opti= on > value (as the resource representation has changed), then the client sho= uld > treat the partial body with the old ETag as no longer being fresh.=20 > END >> * "then the client SHOULD drop all the payloads for the current body":= >> "Drop" is overly prescriptive; the client may well keep them, but >> just can't consider them fresh any more. (If the client has ample >> caching abilities, they might come in handy if the resource goes bac= k >> to that ETag state). Same for later "the client MUST remove any >> partially received". > [Jon] See previous response, otherwise > OLD > If the server transmits a new body of data (e.g., a triggered > Observe) with a new ETag to the same client as an additional > response, the client MUST remove any partially received body held fo= r > a previous ETag. > NEW > If the server transmits a new body of data (e.g., a triggered > Observe) with a new ETag to the same client as an additional > response, the client should remove any partially received body held = for > a previous ETag for that resource as it is unlikely the missing bloc= ks > can be retrieved. >> * "For Confirmable transmission, the client SHOULD continue to": As >> above in the other direction, that's not news. > [Jon] Again, we are not looking for a response (well, a request in this= case > as needed by Block2), just an ACK > OLD > For Confirmable transmission, the client SHOULD continue to > acknowledge each packet as well as issuing a separate GET, POST, PUT= , > FETCH, PATCH, or iPATCH for the missing blocks. > NEW > For Confirmable transmission, the server continues to acknowledge=09 > each packet, but a response is not required (whether separate or=09 > piggybacked) until successful receipt of the body or, if some of the = > payloads are sent as Non-confirmable and have not arrived, a=09 > retransmit missing payloads response is needed. >> * "If there is insufficient space to create a response PDU": I don't >> understand what that means. (Where are request options reflected >> back?). > [Jon] This was triggered by a question by Michael Richardson " So, give= n a > Christmas-Tree-Packet (largest packet, every possible option space used= , > every extension turned on...) how much data can I get back? :-)" and no= t > fully thought through. > It could happen though with Location-Path, Location-Query, Q-Block2, ET= ag, > Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in respon= se to > a POST. > OLD > If there is insufficient space to create a response PDU with a block= > size of 16 bytes (SZX =3D 0) to reflect back all the request options= as > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size2 Option. > NEW > If there is insufficient space to create a response PDU with a block= > size of 16 bytes (SZX =3D 0) to send back all the response options a= s > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size1 Option. > >> * "If the client requests missing blocks, this is treated as a new >> request.": I don't think the client should even make these follow-u= p >> requests Observe, as it already has an ongoing observation. They'd = be >> sent on a different token too, so setting Observe would be opening >> observation up on that token, which AFAIU is not intended. (Figure = 7 >> example looks good to me in that respect.) >> >> (It may make sense to ask the client to keep Observe to make the >> requests matchable just for the sake of staying in atomic-request >> mode. Either way, the server should then not accept that observatio= n >> as it's not for a block 0.) > [Jon] The intent here was that just a new Token should be used. > OLD > If the client requests missing blocks, this is treated as a new > request. The Observe value may change but MUST still be reported. > If the ETag value changes then the previously received partial body > should be destroyed and the whole body re-requested. > NEW > If the client requests missing blocks, this is treated as a new > Request and the Observe Option MUST NOT be included. If the ETag v= alue > changes, then the previously received partial body > should be considered as not fresh and the whole body re-requested. > >> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can be >> matched by the token to a unique request that already had a >> Request-Tag, and the client needs to have kept that token around >> matched to the transfer to make sense of it. >> >> No need to move that value around between subsystems, and just >> dropping it from here would also remove the need for the "If the >> client does not recognize the Request-Tag" clause (which would >> otherwise need clarification as to what it'd mean if it recognizes i= t >> but it doesn't match what the request was for). > [Jon] Good question - it does make sense for the Request-Tag to be trac= ked > alongside the Token in the client. > OLD > The data payload of the 4.08 (Request Entity Incomplete) Response > Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded= > Request-Tag followed by 1 or more missing CBOR encoded missing block= > numbers. > NEW > The data payload of the 4.08 (Request Entity Incomplete) response > is encoded as a CBOR Sequence [RFC8742]. There are one or more miss= ing > CBOR encoded missing block numbers. > > OLD > ; This defines an array, the elements of which are to be used > ; in a CBOR Sequence: > payload =3D [request-tag, + missing-block-number] > request-tag =3D bstr > ; A unique block number not received: > missing-block-number =3D uint > NEW > ; This defines an array, the elements of which are to be used > ; in a CBOR Sequence: > payload =3D [+ missing-block-number] > request-tag =3D bstr > ; A unique block number not received: > missing-block-number =3D uint=20 > > OLD > A 4.08 (Request Entity Incomplete) Response Code returned with > Content-Type "application/missing-blocks+cbor-seq" indicates that > some of the payloads are missing and need to be resent. The client > then re-transmits the missing payloads using the Request-Tag and > Q-Block1 to specify the block number, SZX, and M bit as appropriate.= > The Request-Tag value to use is determined from the payload of the > 4.08 (Request Entity Incomplete) Response Code. If the client does > not recognize the Request-Tag, the client can ignore this response. > NEW (option presentation has been reformatted) > 4.08 (Request Entity Incomplete) > > This Response Code returned with Content-Type "application/=09 > missing-blocks+cbor-seq" indicates that some of the payloads are=09 > missing and need to be resent. The client then retransmits the=09 > missing payloads using the same Request-Tag, Size1 and Q-Block1 to=09 > specify the block number, SZX, and M bit as appropriate.=09 > =20 > > The Request-Tag value to use is determined from the token in the=09 > 4.08 (Request Entity Incomplete) response and then finding the=09 > matching client request which contains the Request-Tag that is=09 > being used for this Q-Block1 body. END >> * "limit the array count to 23 (Undefined value)": 23 is the maximum >> length of a zero-byte length indication, not indefinite-length (31).= >> Both using 23 and 31 here makes sense (up to 23 to have definite >> length that can be updated in-place, or exceeding that switch to >> indefinite length if they still fit), but the paragraph seems to be >> mixing them up. > [Jon] OK > OLD > Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23 > (Undefined value) so that the array data byte can be updated with= > the overall length once the payload length is confirmed or limite= d > to MAX_PAYLOADS count. > NEW > Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the a= rray > count to > 23 so that the initial byte with the array major type and data le= ngth > in the additional information can be updated with the overall count onc= e the > payload count is confirmed. Further restricting the count to MAX_PAYLO= ADS > means that congestion control is less likely to be invoked on the serve= r. > >> * "Each new request MUST use a unique token": Like above, this is >> stating something that's not intended to be changed. > [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token v= alues > are acceptable. Hence this statement. >> Congestion Control: >> >> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is subject= ed >> to PROBING_RATE.": That is unexpected here. At most one such >> response is sent to each request message, so why is additional >> congestion control needed? > [Jon] The intention here was that in the previous paragraph that it was= not > the individual packets that are subject to PROBING_RATE, but a single b= ody > comprising of multiple packets is subject to PROBRING_RATE - and hence > limiting any individual responses to PROBING_RATE rather than the > potentially full set of responses > OLD > PROBING_RATE parameter in CoAP indicates the average data rate that > must not be exceeded by a CoAP endpoint in sending to a peer endpoin= t > that does not respond. The body of blocks will be subjected to > PROBING_RATE (Section 4.7 of [RFC7252]). > NEW > PROBING_RATE parameter in CoAP indicates the average data rate that > must not be exceeded by a CoAP endpoint in sending to a peer endpoin= t > that does not respond. The single body of blocks will be subjected = to > PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.= > If the wait time between sending bodies that are not being=09 > responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the = > gap time is limited to NON_PROBING_WAIT. > > Note: For the particular DOTS application, PROBING_RATE and other > transmission parameters are negotiated between peers. Even when=09 > not negotiated, the DOTS application uses customized defaults as=09 > discussed in Section 4.5.2 of [RFC8782]. > END >> On the other hand, *ever* NON request is subject to PROBING_RATE, s= o >> why point out the body of blocks and "GET or similar" particularly?= > [Jon] It is only GET or FETCH. The intention here is to not request bo= dies > of data at too high a rate. > OLD > Each NON GET or similar request using Q-Block2 Option is subjected t= o > PROBING_RATE. > NEW > Each NON GET or FETCH request using Q-Block2 Option is subjected to > PROBING_RATE. >> * "a delay is introduced of ACK_TIMEOUT": As I understand MAX_PAYLOADS= , >> this is (rather implicitly) introduced as the package count up to >> which it is OK to exceed PROBING_RATE temporarily (but after that it= >> kicks in all the harder by requiring to wait until complete-sent-byt= es >> over PROBING_RATE has expired). If that holds, at that time a much >> larger delay than just ACK_TIMEOUT is needed to get a response from >> the server: About 3 hours (see later note on parameters). > [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write of > Congestion Control section. >> This is the crucial point in the document, and for it a recommendati= on >> alone is not good enough. The protocol can be run with a vastly >> increased PROBING_RATE (however externally determined) and from the >> point of MAX_PAYLOADS just observe it. Or it has to get feedback fro= m >> the server; a single 4.08 is probably enough to kick off another >> vollley of blocks. (How many? MAX_PAYLOADS for every response?). >> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing any >> good. > [Jon] See re-write of Congestion Control section where things should no= w be > simpler and more logical. There is an introduction of new variable > definitions. >> * "For NON transmissions": This seems to imply that the full exchange = of >> a body is either NON or CON; I don't see where that'd come from. I'd= >> have expected to read something like "Each individual request can be= >> NON or CON independent of the others. In particular, it can be >> convenient to send the ultimate payload...". > [Jon]The DOTS environment will only be using NON. To make Congestion > Control simple, > the expectation is that all transmissions are NON or (not recommended) = are > all CON. The draft now generally records this expectation. >> * "If a Confirmable packet is used, then the transmitting peer MUST wa= it >> for the ACK": Why? A NSTART > 1 would give it leisure to still >> transmit. > [Jon] Text has been removed in the clean-up. >> * General on congestion control: It may help implementors if this were= >> split up into newly introduced rules and concepts (that is, >> MAX_PAYLOADS and the answer to whether you may send MAX_PAYLOADS >> en >> block again after having only even one response from the last round,= >> and probably the recommended parameters of the "Also on parameters" >> comment), and another subsection on how Q-Block behaves well when >> observing these. > [Jon] Should now be covered in the updated Congestion Control section. >> Caching: >> >> * "are not part of the cache key": How about "are removed as part of t= he >> block assembly and thus do not reach the cache"? > [Jon] OK. > OLD > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are not part of the cache key. > NEW > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are removed as part of the > block assembly and thus do not reach the cache. >> * "When the next client completes building the body": If the proxy >> chooses not to let them happen in parallel (which it may, see above = on >> parallel requests, although the server might still not support it an= d >> cancel one of them), why bother letting the first finish just to abo= rt >> it? (IOW: If the proxy does not intend to see both through, which it= >> could if it held back the second until the first is through on the >> uplink, it could just as well err out of one of them early, but it m= ay >> also rather see both through.) > [Jon] It has to be assumed that traffic to/from the origin client and o= rigin > server may not both support Q-Blockx and potentially may have a differe= nt > SZX. Thus passing a request or a response through at the block level > introduces a new set of challenges (but not impossible to fix). To kee= p > this simple, my thinking was that the passing through can only take pla= ce at > the body level. Again, the arrival of packets is not necessarily > sequential, so client A's body may start transmitting to the origin ser= ver > first, but client B's body starts to arrive first - the same being true= for > the proxy as a client may stop transmitting for whatever reason (restar= t, > network loss etc.). However this is covered by the above update " If = a > server receives payloads with different Request-Tags for the same resou= rce, > it should continue to process all the bodies". > > OLD > and the new body representation transmission starts with a new > Request-Tag value. > NEW > and the new body representation transmission starts with a new > Request-Tag value. Note that it cannot be assumed that the proxy wi= ll > always receive a complete body from a client. >> * Examples: >> >> * Figure 5: The ... between e3 request and response indicate the >> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose ther= e >> should be the same kind of delay between the failed e5 transmissio= n >> and the e4 response. > [Jon] Agreed and added in >> * If the second burst had 3 requests out of which 2 made it, is ther= e >> any guidance for which of them the 4.08 would come back on? (In th= e >> end, none of them is terminal). > [Jon] The client should tracking all Tokens of the burst (hence > implementation note about bottom 32bits unique and top 32 bits matching= > block number for ease of tracking) for a response and so it will make n= o > difference at to which token is used for the 4.08 response. From an > implementation perspective, it probably is easier to track the last opa= que > token that has the same Request-Tag.=20 > OLD > missing ones in one go (Figure 5). It does so by indicating which > blocks have been received in the data portion of the response. > NEW > missing ones in one go (Figure 5). It does so by indicating which > blocks have been received in the data portion of the response. The T= oken > just needs to be one of those that have been received for this Request-= Tag , > so the client can derive the Request-Tag. >> * If that e4 response gets lost, does the whole mechanism recover fr= om >> it in any way? > [Jon] In this example, if e4 and e5 get lost, there will be no > 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to whet= her > it sends the request again or gives up. See 9.1 > "Under high levels of traffic loss, the client can elect not to retry= > sending missing blocks of data. This decision is implementation > specific." >> Generally, the all-NON and all-CON examples don't look to me like >> what I'd be doing with this spec; the mixed "a CON every >> MAX_PAYLOADS" appears much more realistic. > [Jon] It is unsafe to use CON in the (potentially lossy) DOTS environm= ent > (up to 93 secs timeout per payload with the defaults). Hence why we ar= e > separating out the NON / CON usage. >> * Figure X: The request ahs M unset and thus indicats a request for >> just that block. If more than one is expected, it should say >> QB2:0/1/1024. > [Jon] With Figure 7, with the M bit set, block 3 would get returned for= a > second time. Draft-ietf-core-new-block-03 also has a Figure 8 which do= es > exactly what you describe. >> * New Content Format: I think this needs a media type registration to = go >> with it first; based on that, a content format can be registered. > [Jon] Med has responded to this and draft updated. >> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not >> sure >> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is defin= ed >> in terms of reliable transmission, but used for NONs as well. (So is= >> the alternative ot 2x ACK_TIMEOUT). > [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT in = a NON > environment. Hence re-write of Congestion Control section defining new > variables that can be used for NON. >> For the purpose of delaying a 4.08 or a follow-up GET, it may make >> more sense to define a new parameter based on MAX_LATENCY and the >> time >> it takes the sender to pump out the options (which I don't think we >> have a good factor for, but may even be negligible here). >> >> Could read like this: >> >> > The timing parameter MAX_BLOCK_JITTER is introduced, and by defaul= t >> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / BANDWIDTH. > [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, MAX_PAYLOA= DS =3D > 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > > [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D 100.1.= So > BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps makes= > MAX_BLOCK_JITTER 200 seconds. >> > >> > With Q-Block2, a client can ask for any missing blocks after not >> > having received any further response for the duration of >> > MAX_BLOCK_JITTER. > [Jon] 100+ seconds delay is way too much time to wait for any missing b= locks > in my opinion. > > [Jon] RFC7252 also states (and the intention is that recovery works wel= l) > " as MAX_LATENCY is not > intended to describe a situation when the protocol works well, bu= t > the worst-case situation against which the protocol has to guard.= " >> > >> > With Q-Block1, a server holds off any response for MAX_BLOCK_JITTE= R >> > unless all blocks have been received. Only then it evaluates wheth= er >> > to respond with a 2.0x code, a 4.08 with payload, or not at all >> > (because it responded to a later request). > [Jon] I am not convinced that this is necessarily the way to go. The n= ew > Congestion Control more cleanly handles this. >> This also brings me back to the earlier matter of 2.31: What is a >> server supposed to send when no packages were lost, but it's pasing >> the timeout and wants to help the client flush out more packages by >> confirming something? It says 4.08 in 3.3, but it's not like there's= a >> hole in the contiguous range. Does it need to send 4.08 enumerating >> all (or at least some) numbers between the first unreceived and what= 's >> indicated by Size1? Or can it just send 2.31 and the client knows al= l >> it needs to know b/c the response came to the largest block that was= =20 >> sent and 2.31 indicates that everything is good up to that point? > [Jon] The previous draft states (under Congestion Control) that the cli= ent > waits for ACK_TIMEOUT before transmitting the next set of MAX_PAYLOADS > blocks. The server should wait for "two times ACK_TIMEOUT " (3.3) befo= re > indicating issue. Apart from perhaps having a new name for ACK_TIMOUT = I > think that these are reasonable values for Non-Confirmable - and are us= ed in > the new Congestion Control section. > > [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a si= gnal > to say that all of the current MAX_PAYLOADS payloads of a body have bee= n > received, so allowing the client to continue transmitting the next set = of > MAX_PAYLOADS payloads without the need to wait any longer. >> * Also on parameters: This document is describing flow control stuff >> around a situation CoAP was not originally designed for. Wouldn't it= >> make sense to include a set of parameters (PROBING_RATE, MAX_LATENCY= , >> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that >> PROBING_RATE will be left to 1 byte/second for any DOTS application >> using this (for sending 10KiB in the initial 10-package MAX_PAYLOADS= >> burst would mark that connection as unusable for about 3 hours if th= ey >> all get lost), so better give justifiable numbers here than rely on >> implemnetors to come up with unreviewed numbers or disregard >> PROBING_RATE altogether. > [Jon] Answered by Med, and some new text added. >> I don't know if it needs additional justification, but an increased >> N_START may be justifiable there. > [Jon] It may be, but tuning the other associated parameters is really o= ut of > the cope of this draft. This text has been added > NEW > Congestion control for CON requests and responses is specified in=09 > Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will = > need to be increased from 1. However, the other CON congestion=09 > control parameters will need to be tuned to cover this change. This = > tuning is out of scope of this document as it is expected that all=09 > requests and responses using Q-Block1 and Q-Block2 will be Non-=09 > confirmable. >> * Somewhere (never comes up but I think it should): When CONs are used= , >> a 4.08 (or 2.31?) response to a later request can indicate to the >> client that an earlier CON request has been processed successfully. = If >> the client can match that up (and it should be able to), then it can= >> (and should) cancel that particular CON request. > [Jon] I think that this is covered by my update above with the text > " NEW > For Confirmable transmission, the server continues to acknowledge=09 > each packet, but a response is not required (whether separate or=09 > piggybacked) until successful receipt of the body or, if some of the = > payloads are sent as Non-confirmable and have not arrived, a=09 > retransmit missing payloads response is needed." > > And in my previous part 1 response (updated) > NEW > For Confirmable transmission, the server continues to acknowledge=09 > each packet, but a response is not required (whether separate or=09 > piggybacked) until successful receipt of the body or, if some of the=09 > payloads are sent as Non-confirmable and have not arrived, a=09 > retransmit missing payloads response is needed. >> Best regards >> Christian >> >> -- >> There's always a bigger fish. >> -- Qui-Gon Jinn > _______________________________________________ > core mailing list > core@ietf.org > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca= %40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09ecc40= cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dt= EJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --6NBo78rvo9ddgGch7u9vPyzQZAAono3DS-- --dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/2+9AACgkQ7iZktA5Y 2kPUoAf/caC/91pj2BAIzRdnSoEonWnndXUwoMCPtT8QB9rHGfKZnhLJBAWQ8bZb z7YcRZvNyAn6X8T4A5oZGnkxCDOfvr9Fpo0RV/E5j+/zfMKdW35PtvlGtqvx77U4 nZZfEC3sI+zYNVqgrOPh97FYP1X0ZFf7NHekkY2bYWzHXTZ+H7DJ2p08XTDCUOJ/ qSn/FuH0fc93e/ajCyCYvn5gATAus2+rGnc9O4uLx9l8dW5vpTfB219p9PsyEU7Z uKqOspeQj0d0k4WwbnurPXMP51Kc18r/n++LLSP6Uywc0/mkV3XFnPsUJxBj6fqy 4KKLc+h84npR0+ebH/ONF4vRhPNjwg== =ZSr9 -----END PGP SIGNATURE----- --dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP-- From nobody Thu Jan 7 06:46:05 2021 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 B5D313A11C1; Thu, 7 Jan 2021 06:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FSL_HAS_TINYURL=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 Nms_7A1kM-Ku; Thu, 7 Jan 2021 06:46:02 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 87DE03A11A2; Thu, 7 Jan 2021 06:46:02 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4DBTZ05HZyz1yV9; Thu, 7 Jan 2021 15:46:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610030760; bh=YBiYJgvSw7h3dR4oDugtVLD0CMECL3KwXNY8tqYV7/o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=s9aiLAAuwu3G7c4uqlAjeuRncZcmdunTd80WwsoOkEuAOG2AF3ocBzkwIjjoKBZJU 2wyETQMaELJ+O35UMwnOfy4ZZl/Ze8QlJf6M30V8Hhocym5pSfonYM0d6WvapY6BSr LxkN0YuiSsdB2qCips08TSMLC1PupXjBFy+qh+xw2LJkLdCHPjVO2asMeLqok3oIrs CLHxW+YYf4DV8Uq9scznTjxPMhiLmnTadaCvu6l3CT4Gs26pcjgIhNEnkYfmFCZbht bbGfC5Ysx+X1oZE2+VBkzTb5M7re9rlC3W0X9y/Q23OfDKGDSVgO4p1oduh3xMIwK9 ohssLEZQoxrGQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4DBTZ04JNtzDq86; Thu, 7 Jan 2021 15:46:00 +0100 (CET) From: To: "Rob Wilton (rwilton)" , Roman Danyliw , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , Valery Smyslov , "dots@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x04GhVUrubF9E6Ldzi/FU9PuKn5Pw6AgAPYoACAB6gWgIAS/RdggAAHj4CAAAWsAIAElk6A Date: Thu, 7 Jan 2021 14:45:59 +0000 Message-ID: <25331_1610030760_5FF71EA8_25331_128_2_787AE7BB302AE849A7480A190F8B9330315B4512@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <703969fb11df49a39c6241bb32934ff6@cert.org> <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21867_1609777571_5FF341A3_21867_195_25_787AE7BB302AE849A7480A190F8B9330315A6CFB@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.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (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: Thu, 07 Jan 2021 14:46:05 -0000 SGkgUm9iLCANCg0KVGhhbmsgeW91IGZvciB0aGUgaW5wdXRzLiANCg0KV2UgcHJlcGFyZWQgYSB0 ZXh0IHByb3Bvc2FsIHRoYXQgeW91IGNhbiBzZWUgYXQ6IGh0dHBzOi8vdGlueXVybC5jb20vZG90 cy1jYWxsLWhvbWUtbGF0ZXN0Lg0KDQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgYW55IGZ1cnRoZXIg bW9kaWZpY2F0aW9uIGlzIG5lZWRlZC4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBSb2IgV2lsdG9uIChyd2lsdG9uKSBbbWFpbHRvOnJ3 aWx0b25AY2lzY28uY29tXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDQgamFudmllciAyMDIxIDE3OjU2 DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+OyBSb21hbg0KPiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0 Zi5vcmc7IGRvdHMtDQo+IGNoYWlyc0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBz bXlzbG92Lm5ldD47IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUkU6IFJvbWFuIERhbnlsaXcn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4gaG9tZS0xMTogKHdp dGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhpIE1lZCwNCj4gDQo+IFBsZWFzZSBzZWUg aW5saW5lIC4uLg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+DQo+ID4gU2VudDogMDQgSmFudWFyeSAyMDIxIDE2OjI2DQo+ID4gVG86IFJvYiBXaWx0b24g KHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IFJvbWFuIERhbnlsaXcNCj4gPiA8cmRkQGNl cnQub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IGRyYWZ0LWlldGYtZG90 cy1zaWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3RzLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7DQo+ ID4gVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47IGRvdHNAaWV0Zi5vcmcNCj4g PiBTdWJqZWN0OiBSRTogUm9tYW4gRGFueWxpdydzIERpc2N1c3Mgb24NCj4gPiBkcmFmdC1pZXRm LWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0NCj4gPiAxMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCj4gPg0KPiA+IEhpIFJvYiwNCj4gPg0KPiA+IFdlIHRob3VnaHQgdGhpcyB3YXMgY292ZXJl ZCBieSB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gICAgT3RoZXIgbW90aXZhdGlvbnMgZm9yIGlu dHJvZHVjaW5nIHRoZSBDYWxsIEhvbWUgZnVuY3Rpb24gYXJlDQo+ID4gICAgZGlzY3Vzc2VkIGlu IFNlY3Rpb24gMS4xIG9mIFtSRkM4MDcxXS4NCj4gW1JXXQ0KPiANCj4gSSBoYWQgbWlzc2VkIHRo ZSByZWZlcmVuY2UuDQo+IA0KPiA+DQo+ID4gV2UgcHJlZmVycmVkIHRoYXQgY2l0YXRpb24gdnMg ZHVwbGljYXRpbmcgdGhlIDYgaXRlbXMgaW4gdGhpcw0KPiBkb2N1bWVudA0KPiA+IGFzIHdlbGwg KHMvbWFuYWdlbWVudCBzeXN0ZW0vbWl0aWdhdGlvbiBzeXN0ZW0pLg0KPiBbUlddDQo+IA0KPiBJ IGFncmVlIHRoYXQgYSByZWZlcmVuY2UgaXMgYmV0dGVyIHRoYW4gY29weWluZyB0aGVtIGFsbCBv dXQgYWdhaW4NCj4gaGVyZS4NCj4gDQo+ID4NCj4gPiBJIHVuZGVyc3RhbmQgZnJvbSB5b3VyIGNv bW1lbnQgdGhhdCB0aGUgbGluayB3YXMgbm90IGV2aWRlbnQuIElmDQo+IHNvLA0KPiA+IHdpbGwg c2VlIGhvdyB0byBtYWtlIHRoaW5ncyBiZXR0ZXIuDQo+IFtSV10NCj4gDQo+IFNvLCB0aGUgZGVz aXJlIHRvIHdhbnQgdG8gYmUgYWJsZSB0byBzdG9wIERET1MgdHJhZmZpYyBhdCBzb3VyY2UgaXMN Cj4gY2xlYXIsIGJ1dCBpdCB3YXNuJ3QgY2xlYXIgd2h5IENhbGwgSG9tZSBpcyB0aGUgbWVjaGFu aXNtIG5lZWRlZCB0bw0KPiBhY2hpZXZlIHRoYXQuICBQZXJoYXBzIHlvdXIgc2VudGVuY2UgY291 bGQgYmUgZXhwYW5kZWQgYSBiaXQgd2l0aG91dA0KPiBjb3B5aW5nIGFsbCB0aGUgcmVhc29ucy4g IEUuZy4sIG1heWJlIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YNCj4gLi4uDQo+IA0KPiBB bHRob3VnaCBDYWxsIEhvbWUgZnVuY3Rpb25hbGl0eSBpcyBub3QgYWx3YXlzIG5lY2Vzc2FyeSB0 bw0KPiBmYWNpbGl0YXRlIERPVFMgRERPUyBtaXRpZ2F0aW9uIGluIHRoZSBzb3VyY2UgbmV0d29y aywgdGhlcmUgYXJlDQo+IHZhcmlvdXMgbWFuYWdlbWVudCBhbmQgZGVwbG95bWVudCBjb25zaWRl cmF0aW9ucyB0aGF0IG1ha2UgQ2FsbCBIb21lDQo+IGZ1bmN0aW9uYWxpdHkgZGVzaXJhYmxlIG9y IHJlcXVpcmVkIGluIHNvbWUgY2FzZXMsIGUuZy4sIGFzDQo+IGRpc2N1c3NlZCBpbiBTZWN0aW9u IDEuMSBvZiBbUkZDODA3MV0uDQo+IA0KPiBSZWdhcmRzLA0KPiBSb2INCj4gDQo+DQoNCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Jan 7 14:11:59 2021 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 72CBC3A0813; Thu, 7 Jan 2021 14:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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 ujH97P2Ho1ms; Thu, 7 Jan 2021 14:11:54 -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 981E93A0475; Thu, 7 Jan 2021 14:11:54 -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 107MBqib011872; Thu, 7 Jan 2021 17:11:52 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 107MBqib011872 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1610057512; bh=QEBWTxSNkfypALFrYNymH7+e75QKn6PLzcvyZmNgQe0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=aRn8oTUplY3jPQoCmrKKR/FQ0XJ1eDbw90Y1k/gVx7V8Q4hR2ns4BHZ/HFnNiHFnm OQOwU2uqCFixgho12/harp3OMXO64ai2UtVBbNtaZt672Y8Mrm1t1L8KZTLKOyYasZ aAq1J5kxYh25MpJps2fi1dRYfiFkSmcR0KxDq3P4= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 107MBkLA006608; Thu, 7 Jan 2021 17:11:46 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 7 Jan 2021 17:11:46 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Thu, 7 Jan 2021 17:11:46 -0500 From: Roman Danyliw To: "mohamed.boucadair@orange.com" , "Robert Wilton" , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , Valery Smyslov , "dots@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x04jnFavtZsS0e2FxL8H2KIVKn5kt+AgAN5G1CAB7E8YIAYH/ig Date: Thu, 7 Jan 2021 22:11:46 +0000 Message-ID: References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <703969fb11df49a39c6241bb32934ff6@cert.org> <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (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: Thu, 07 Jan 2021 22:11:57 -0000 SGkgTWVkIQ0KDQpUaGUgbmV3IGxhbmd1YWdlIGFib3V0ICJtYW5hZ2VkIENQRXMiIGFuZCB0aGUg bW9yZSBnZW5lcmFsaXplIHNjb3BlIGluIFNlY3Rpb24gMSBiZXR0ZXIgY29udGV4dHVhbGl6ZXMg dGhlIHZhcmlvdXMgaW50ZXJhY3Rpb25zIEkgaGFkIHJhaXNlZCBjb25jZXJucyBhYm91dCBiZWxv dy4gIFRoYW5rcyBmb3IgcHVibGlzaGluZyBpdCAtMTIuICBJJ3ZlIGNsZWFyZWQgbXkgYmFsbG90 Lg0KDQpSZWdhcmRzLA0KUm9tYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDIzLCAyMDIwIDg6NTQgQU0NCj4g VG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFJvYmVydCBXaWx0b24gPHJ3aWx0b25A Y2lzY28uY29tPjsgVGhlDQo+IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRm LWRvdHMtc2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9yZzsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7IFZh bGVyeQ0KPiBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+OyBkb3RzQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJFOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2ln bmFsLWNhbGwtaG9tZS0xMToNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhp IFJvbWFuLCBhbGwsDQo+IA0KPiBXZSB1cGRhdGVkIHRoZSBkcmFmdCB0byB0YWtlIGludG8gYWNj b3VudCB5b3VyIHN1Z2dlc3Rpb25zLiBUaGUgaW50cm9kdWN0aW9uDQo+IGFuZCBhcHBsaWNhYmls aXR5IHNlY3Rpb25zIHdlcmUgcmV3b3JrZWQgYWNjb3JkaW5nbHkuIFdlIGFsc28ga2VwdCBpbiBt aW5kDQo+IFJvYidzIGNvbW1lbnQgd2hlbiB1cGRhdGluZyB0aGVzZSB0d28gc2VjdGlvbnMuDQo+ IA0KPiBUaGUgbmV3IHZlcnNpb24gYW5kIGEgZGlmZiBjYW4gYmUgZm91bmQgYXQ6DQo+IA0KPiBI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90 cy1zaWduYWwtY2FsbC1ob21lLTEyDQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWUtMTINCj4g DQo+IFBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGlzIHZlcnNpb24gYWRkcmVzc2VzIHlvdXIgRElT Q1VTUy4NCj4gDQo+IEFsc28sIHRoaXMgdmVyc2lvbiBpbnRlZ3JhdGVzIHRoZSBpbnB1dHMgZnJv bSB0aGUgQmFycnkvRXJpYy9FcmlrIGFuZCBkaXJlY3RvcmF0ZQ0KPiByZXZpZXdzLg0KPiANCj4g Q2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4g RGXCoDogUm9tYW4gRGFueWxpdyBbbWFpbHRvOnJkZEBjZXJ0Lm9yZ10gRW52b3nDqcKgOiB2ZW5k cmVkaSAxOCBkw6ljZW1icmUNCj4gPiAyMDIwIDE3OjU4IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVk IFRHSS9PTE4NCj4gPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPiBDY8KgOg0KPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21l QGlldGYub3JnOyBkb3RzLSBjaGFpcnNAaWV0Zi5vcmc7DQo+ID4gVmFsZXJ5IFNteXNsb3YgPHZh bGVyeUBzbXlzbG92Lm5ldD47IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUkU6IFJvbWFuDQo+ID4g RGFueWxpdydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLQ0KPiA+IGhv bWUtMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4gPiBIaSBNZWQhDQo+ID4N Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBEb3RzIDxkb3Rz LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZg0KPiA+ID4gbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAyMCAxOjE0 IEFNDQo+ID4gPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+DQo+ID4gPiBDYzogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVA aWV0Zi5vcmc7IGRvdHMtDQo+ID4gY2hhaXJzQGlldGYub3JnOw0KPiA+ID4gVmFsZXJ5IFNteXNs b3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47IGRvdHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJl OiBbRG90c10gUm9tYW4gRGFueWxpdydzIERpc2N1c3Mgb24NCj4gPiA+IGRyYWZ0LWlldGYtZG90 cy1zaWduYWwtY2FsbC0NCj4gPiA+IGhvbWUtMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQp DQo+ID4gPg0KPiA+ID4gSGkgUm9tYW4sDQo+ID4gPg0KPiA+ID4gVGhhbmsgeW91IGZvciB0aGUg cmV2aWV3Lg0KPiA+ID4NCj4gPiA+IFBsZWFzZSBzZWUgaW5saW5lIGZvciB0aGUgRElTQ1VTUyBw YXJ0LiBXaWxsIHNlZSBpZi93aGF0IGNoYW5nZXMNCj4gPiBhcmUNCj4gPiA+IG5lZWRlZCBmb3Ig dGhlIENPTU1FTlQgcGFydC4NCj4gPiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiBNZWQNCj4gPiA+ DQo+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPiBEZcKgOiBSb21h biBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ID4g RW52b3nDqcKgOg0KPiA+ID4gPiBtYXJkaSAxNSBkw6ljZW1icmUgMjAyMCAyMTowMSDDgMKgOiBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4gQ2PCoDoNCj4gPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNp Z25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtDQo+ID4gY2hhaXJzQGlldGYub3JnOw0KPiA+ ID4gPiBkb3RzQGlldGYub3JnOyBWYWxlcnkgU215c2xvdiA8dmFsZXJ5QHNteXNsb3YubmV0PjsN Cj4gPiA+ID4gdmFsZXJ5QHNteXNsb3YubmV0IE9iamV0wqA6IFJvbWFuIERhbnlsaXcncyBEaXNj dXNzIG9uDQo+ID4gPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLQ0KPiA+ID4g PiAxMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPiA+ID4NCj4gPiA+ID4gUm9tYW4g RGFueWxpdyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4g PiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWUtMTE6IERpc2N1c3MNCj4gPiA+ ID4NCj4gPiA+ID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l IGludGFjdCBhbmQgcmVwbHkNCj4gPiB0bw0KPiA+ID4gPiBhbGwgZW1haWwgYWRkcmVzc2VzIGlu Y2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUNCj4gPiB0bw0KPiA+ID4g PiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPiA+ID4NCj4g PiA+ID4NCj4gPiA+ID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtDQo+ID4gPiA+IGNyaXRlcmlhLmh0bWwNCj4gPiA+ID4gZm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4N Cj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZA0KPiA+IGhlcmU6DQo+ID4gPiA+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0N Cj4gPiBob21lLw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gLS0tLQ0KPiA+ID4gPiAtLQ0KPiA+ID4gPiBESVNDVVNTOg0KPiA+ID4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gLS0tLQ0KPiA+ID4gPiAtLQ0KPiA+ID4gPg0KPiA+ID4gPiBJdCBzZWVtcyB0byBtZSB0aGVy ZSBpcyBhIG1pc3Npbmcgb3BlcmF0aW9uYWwgZ3VpZGFuY2Ugb3INCj4gPiA+ID4gdW5kb2N1bWVu dGVkIGRlcGxveW1lbnQgYXNzdW1wdGlvbnMuICBTaW5jZSB0aGUgbW90aXZhdGlvbmFsIHVzZQ0K PiA+ID4gPiBjYXNlIHNlZW1zIHRvIGJlIGhvbWUgbmV0d29ya3MgKHBlciBTZWN0aW9uIDEuMSks IEkgYXNzdW1lZCB0aGF0DQo+ID4gdGhlDQo+ID4gPiA+IGNhbGwgaG9tZSBzZXJ2ZXJzIGFyZSBy dW5uaW5nIHByaW1hcmlseSBjb25zdW1lciBncmFkZSByb3V0ZXJzDQo+ID4gbm90DQo+ID4gPiA+ IG1hbmFnZWQgYnkgcHJvZmVzc2lvbmFsIElUIGV4cGVydGlzZS4NCj4gPiA+DQo+ID4gPiBbTWVk XSBUaGUgZ2VuZXJhbGl6ZWQgYXBwbGljYWJpbGl0eSBzY29wZSBpcyB3aGF0IGlzIHNrZXRjaGVk IGluDQo+ID4gPiBTZWN0aW9uIDMuIFRoZSBzb2x1dGlvbiBpcyBtZWFudCB0byBibG9jayBhdHRh Y2tzIGNsb3NlIHRvIHRoZWlyDQo+ID4gc291cmNlLiBUaGlzIGNhbiBiZToNCj4gPiA+IC0gdGhl IGhvbWUgY2FzZSwNCj4gPiA+IC0gYW4gZW50ZXJwcmlzZSBuZXR3b3JrLA0KPiA+ID4gLSBhIHRy YW5zaXQgcHJvdmlkZXIgZmlsdGVyaW5nIGF0dGFja3MgZnJvbSBsZWFmIG5ldHdvcmtzLA0KPiA+ ID4gLSBhIHByb3ZpZGVyIGZpbHRlcmluZyBhdHRhY2tzIGZyb20gZGF0YSBjZW50ZXJzLA0KPiA+ ID4gLSBldGMuDQo+ID4gPg0KPiA+ID4gRm9yIHRoZSBwYXJ0aWN1bGFyIGNhc2Ugb2YgaG9tZSBu ZXR3b3JrcywgdGhpcyBjYW4gYmUgcGFydCBvZg0KPiA+IHNlcnZpY2VzDQo+ID4gPiBzdXBwb3J0 ZWQgYnkgYSBJU1AtbWFuYWdlZCBDUEUgb3IgYSBtYW5hZ2VkIHNlY3VyaXR5IHNlcnZpY2UNCj4g PiBzdWJzY3JpYmVkIGJ5IHRoZSB1c2VyLg0KPiA+ID4NCj4gPiA+IFdlIGNvdWxkIG1lbnRpb24g dGhhdCBpbiB0aGUgZG9jdW1lbnQsIGJ1dCB3ZSBkaWRuJ3QgYmVjYXVzZSB0aGlzDQo+ID4gYXJl DQo+ID4gPiBkZXBsb3ltZW50LXNwZWNpZmljLiBSZWFsbHkuDQo+ID4gPg0KPiA+ID4gT3RoZXIg dGhhbiB0aGUgaW50cm9kdWN0aW9uLCB3ZSBkb24ndCB3YW50IHRvIG92ZXJsb2FkIHRoZQ0KPiA+ IGRvY3VtZW50DQo+ID4gPiB3aXRoIGhvbWUtc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMuDQo+ID4N Cj4gPiBJIHN0aWxsIHRoaW5rIHdlIG5lZWQgYSBiaXQgbW9yZSBwcmVjaXNpb24uICBJIGRvbid0 IGRpc3B1dGUgdGhlDQo+ID4gZ2VuZXJhbCB1dGlsaXR5IG9mIHRoaXMgYXBwcm9hY2ggdG8gYSB2 YXJpZXR5IG9mIGVudmlyb25tZW50cy4gIEkgZG8NCj4gPiBzZWUgdGhlIHR3byBzZW50ZW5jZXMg aW4gdGhlIGVudGlyZSBkb2N1bWVudCB3aGljaCBzYXkgdGhhdCB0aGlzIGlzIGENCj4gPiBnZW5l cmFsIHB1cnBvc2UgYXBwcm9hY2g6DQo+ID4NCj4gPiBBYnN0cmFjdDogVGhlIERPVFMgc2lnbmFs IGNoYW5uZWwgQ2FsbCBIb21lIGlzIG5vdCBzcGVjaWZpYyB0byBob21lDQo+ID4gbmV0d29ya3M7 DQo+ID4gICAgdGhlIHNvbHV0aW9uIHRhcmdldHMgYW55IGRlcGxveW1lbnQgaW4gd2hpY2ggaXQg aXMgcmVxdWlyZWQgdG8NCj4gPiBibG9jaw0KPiA+ICAgIEREb1MgYXR0YWNrIHRyYWZmaWMgY2xv c2VyIHRvIHRoZSBzb3VyY2Uocykgb2YgYSBERG9TIGF0dGFjay4NCj4gPg0KPiA+IFNlY3Rpb24g MzogIlRoZSBhZm9yZW1lbnRpb25lZCBwcm9ibGVtcyBtYXkgYmUgZW5jb3VudGVyZWQgaW4gb3Ro ZXINCj4gPiBkZXBsb3ltZW50cw0KPiA+ICAgIHRoYW4gdGhvc2UgZGlzY3Vzc2VkIGluIFNlY3Rp b24gMS4xIChlLmcuLCBkYXRhIGNlbnRlcnMsIGVudGVycHJpc2UNCj4gPiAgICBuZXR3b3Jrcyku Ig0KPiA+DQo+ID4gSG93ZXZlciwgSSB3aWxsIHJlaXRlcmF0ZSB0aGF0IGFsbW9zdCBubyBjb25z aWRlcmF0aW9uIGlzIG1hZGUgdG8NCj4gPiBkaXN0aW5ndWlzaCB0aGVzZSB1c2UgY2FzZXMgaW4g dGhlIG5hcnJhdGl2ZSB0ZXh0LiAgVGhlIGVudGlyZQ0KPiA+IG1vdGl2YXRpb24gZm9yIHRoZSB3 b3JrIGluIFNlY3Rpb24gMS4wIGlzIHRocm91Z2ggdGhlIGxlbnMgb2YgbmV0d29ya3MNCj4gPiBu b3QgbWFuYWdlZCBieSBwcm9mZXNzaW9uYWxzIChob21lIG5ldHdvcmtzKS4gIEZ1cnRoZXJtb3Jl LCB0aGUNCj4gPiBleHBsYW5hdGlvbiBvZiB0aGUgc29sdXRpb24gaW4gU2VjdGlvbiAxLjEsIDUu MSBhbmQgQXBwZW5kaXggQSBpcyBkb25lDQo+ID4gdGhyb3VnaCB0aGUgbGVucyBvZiBhICJob21l IG5ldHdvcmsiLiAgRm9yIHRoaXMgcmVhc29uLCBJJ20gcHVzaGluZyB0bw0KPiA+IG1ha2Ugc3Vy ZSB0aGUgZWRnZXMgb2YgdGhhdCBkZXBsb3ltZW50IGVudmlyb25tZW50IGFyZSBjb3ZlcmVkLg0K PiA+DQo+ID4gSSB3b3VsZCBhc3NlcnQgdGhhdCBtb3N0IG9mIHRoZSBiZWhhdmlvciBkZXNjcmli ZWQgYmVsb3cgcmVxdWlyZXMgdGhhdA0KPiA+IHByb2Zlc3Npb25hbCBJVCBleHBlcnRpc2UgKGxl dCBtZSBrbm93IGlmIHlvdSB0aGluayBJIGhhdmUgaXQgd3JvbmcpLg0KPiA+IEknbSBsb29raW5n IHByaW1hcmlseSBmb3IgYSBmZXcgcGllY2VzIG9mIGNsYXJpZnlpbmcgdGV4dDoNCj4gPiAoMSkg YSBzdWdnZXN0aW9uL2Fja25vd2xlZGdlbWVudCB0aGF0IENQRXMgdXNpbmcgdGhpcyBzcGVjIGlu IHRoZSBob21lDQo+ID4gZW52aXJvbm1lbnQgYXJlIGxpa2VseSB0byBiZSBtYW5hZ2VkLCBwcm92 aXNpb25lZCwgaXNzdWVkICg/KSBieSBhbg0KPiA+IElTUCAodGhpcyBhZGRyZXNzZXMgd2hlcmUg dGhlcmUgcHJvZmVzc2lvbmFsIElUIGV4cGVydGlzZSBpcyBjb21pbmcNCj4gPiBmcm9tKQ0KPiA+ ICgyKSBhc3N1bWluZyAoMSkgaXMgdHJ1ZSwgZGlzdGluZ3Vpc2hpbmcgdGhlIHZhcmlvdXMgTVVT VC9TSE9VTEQvTUFZcw0KPiA+IGFkbWluIGJlaGF2aW9ycyB0aGF0IGludm9sdmUgdGhlIElTUCB2 cy4gdGhlIGFjdHVhbCBodW1hbnMgb24gdGhlIGhvbWUNCj4gPiBuZXR3b3JrDQo+ID4NCj4gPiBO b3RlOiBldmVyeXRoaW5nIGVsc2UgYmVsb3cgaXMganVzdCBtb3JlIGRldGFpbGVkIGNvbW1lbnRh cnkgb24gdGhpcw0KPiA+IHRoZW1lIGFib3ZlLiAgSSdkIHN1bW1hcml6ZSBldmVyeXRoaW5nIEkn dmUgc2FpZCBoZXJlIGJ5IHNheWluZyBJDQo+ID4gdGhpbmsgd2UgbmVlZCBtb3JlIGZpbmVzc2Ug aW4gZGVzY3JpYmluZyB0aGUgb3BlcmF0aW9uYWwNCj4gPiBjb25zaWRlcmF0aW9ucyBhbmQgd2hv IGlzIGV4cGVjdGVkIHRvIHRha2UgcmVzcG9uc2liaWxpdHkgZm9yIHRoZW0NCj4gPiAocmVhbGl6 aW5nIHRoZXJlIHdpbGwgYmUgYSBkaXZlcnNpdHkgb2YgZW52aXJvbm1lbnRzKS4gIEhvd2V2ZXIs IHNpbmNlDQo+ID4gdGhlcmUgYXJlIG11bHRpcGxlIHVzZSBjYXNlcywgSU1PLCB0aGV5IGRlc2Vy dmUgdW5pcXVlIGNvbnNpZGVyYXRpb24NCj4gPiB3aGVuIHRoZXkgYXJlIGRpZmZlcmVudCBmcm9t IGVhY2ggb3RoZXIuDQo+ID4NCj4gPiA+ICAgSWYgdGhhdCBhc3N1bXB0aW9uIGlzIHRydWUNCj4g PiA+ID4gKGFuZCBpdCBzaG91bGQgYmUgZG9jdW1lbnRlZCBpZiB0aGF0IGlzIHRoZSBjYXNlKSwg dGhlbiBJIGZpbmQNCj4gPiBtYW55DQo+ID4gPiA+IG9mIHRoZSBvcGVyYXRpb25hbCByZWNvbW1l bmRhdGlvbnMgbm90IGNvbmdydWVudCB3aXRoIHRoYXQNCj4gPiBlbnZpcm9ubWVudC4NCj4gPiA+ ID4gU3BlY2lmaWNhbGx5LCB0aGUgZGVncmVlIG9mIGludGVyYWN0aW9uIGFuZCB0dW5pbmcgc2Vl bXMgb3V0c2lkZQ0KPiA+IHRoZQ0KPiA+ID4gPiByZWFsbSBvZiBleHBlcnRpc2Ugb2Ygc29tZW9u ZSB3aXRob3V0IElUIHRyYWluaW5nIGFuZA0KPiA+IGNhcGFiaWxpdGllcw0KPiA+ID4gPiBvZiBo b21lIG5ldHdvcmsgZWNvc3lzdGVtLiAgSW4gcGFydGljdWxhcjoNCj4gPiA+ID4NCj4gPiA+ID4g LS0gU2VjdGlvbiAxLjINCj4gPiA+ID4gVGhlIENhbGwgSG9tZSBET1RTIHNlcnZlciB1c2VzIHRo ZSBERG9TIGF0dGFjayB0cmFmZmljDQo+ID4gaW5mb3JtYXRpb24gdG8NCj4gPiA+ID4gICAgaWRl bnRpZnkgdGhlIGNvbXByb21pc2VkIGRldmljZSBpbiBpdHMgZG9tYWluIHRoYXQgaXMNCj4gPiBy ZXNwb25zaWJsZQ0KPiA+ID4gPiBmb3INCj4gPiA+ID4gICAgbGF1bmNoaW5nIHRoZSBERG9TIGF0 dGFjaywgb3B0aW9uYWxseSBub3RpZmllcyBhIG5ldHdvcmsNCj4gPiA+ID4gICAgYWRtaW5pc3Ry YXRvciwgYW5kIHRha2VzIGFwcHJvcHJpYXRlIG1pdGlnYXRpb24gYWN0aW9uKHMpLg0KPiA+ID4g Pg0KPiA+ID4gPiBIb3cgd291bGQgc3VjaCBub3RpZmljYXRpb24gd29yaz8NCj4gPiA+DQo+ID4g PiBbTWVkXSBUaGlzIHdpbGwgZGVwZW5kIG9uIHRoZSBkZXBsb3ltZW50IChob21lLCBlbnRlcnBy aXNlLCBEQywNCj4gPiBhY2Nlc3MNCj4gPiA+IHByb3ZpZGVyLCBwZWVyIHRyYW5zaXQgcHJvdmlk ZXIsIGV0Yy4pLiBUaGlzIGNhbiBiZSB1c2luZyBET1RTDQo+ID4gKHRoZQ0KPiA+ID4gYWRtaW5p c3RyYXRvciBoYXMgYSBjYWxsIGhvbWUgZG90cyBzZXJ2ZXIgYXBwKSwgYSBwdXNoIGZyb20gdGhl DQo+ID4gYXBwDQo+ID4gPiB1c2UgZm9yIG1hbmFnaW5nIHRoZSBDUEUsIHN5c2xvZywgc25tcCwg bmV0Y29uZiwgYW4gU01TLCBldGMuDQo+ID4NCj4gPiBJIHVuZGVyc3RhbmQgdGhpcyBhbnN3ZXIg aW4gdGhlIGNvbnRleHQgb2YgdGhlIGVudGVycHJpc2UgdXNlIGNhc2UuDQo+ID4gSG93IHdvdWxk IHRoaXMgaGFwcGVuIGZvciB0aGUgaG9tZSB1c2VyIChub24tcHJvZmVzc2lvbmFsIElUIHBlcnNv bik/DQo+ID4NCj4gPiBJZiB0aGlzIGFuIGluc3RhbmNlIHdoZXJlIGlmIHRoZSBDUEUgaXMgbWFu YWdlZCBvbiBiZWhhbGYgYSB0aGUgdXNlciwNCj4gPiBwZXJoYXBzIHNheWluZyBhbiBvdXQtb2Yt c2NvcGUgbWVjaGFuaXNtcyAoYXBwLCBTTVMpIG5lZWRzIHRvIGJlDQo+ID4gcHJvdmlkZWQgZm9y IHRoZSBlbmQtdXNlciAoaG9tZSB1c2VyKT8NCj4gPg0KPiA+ID4gQXMgeW91IGNhbiBzZWUgYSB2 YXJpZXR5IG9mIHRvb2xzIGNhbiBiZSBjb25zaWRlcmVkIGFzIGEgZnVuY3Rpb24NCj4gPiBvZg0K PiA+ID4gdGhlIGxvY2FsIGRlcGxveW1lbnQgY2FzZS4gTm9uZSBvZiB0aGVtIGlzIGNhbGxlZCBv dXQgaW4gdGhlIHRleHQNCj4gPiBhcw0KPiA+ID4gdGhpcyBpcyBkZXBsb3ltZW50LSBzcGVjaWZp Yy4gTm90IGFsbCBvZiB0aGVtIGFyZSBhcHBsaWNhYmxlIGZvcg0KPiA+IGVhY2ggZGVwbG95bWVu dCBjYXNlLg0KPiA+DQo+ID4gTWFrZSBzZW5zZS4gIFBlcmhhcHMgc29tZSBkZXRhaWxzIGRpc3Rp bmd1aXNoaW5nIHRoZSBndWlkYW5jZSBwZXIgdGhlDQo+ID4gdXNlIGNhc2VzIGNvdWxkIGhlbHAu DQo+ID4NCj4gPiA+ID4NCj4gPiA+ID4gLS0gU2VjdGlvbiAxLjIgYW5kIDUuMS4gIExlYXZlcyBj cmVkZW50aWFscyBjb25maWd1cmF0aW9uIGFzIG91dA0KPiA+IG9mDQo+ID4gPiA+IHNjb3BlLg0K PiA+ID4NCj4gPiA+IFtNZWRdIFRoYXQgaXMgYWxpZ25lZCB3aXRoIGhvdyBjcmVkZW50aWFscyBh cmUgaGFuZGxlZCBpbiB0aGUgYmFzZQ0KPiA+ID4gc3BlYyAoUkZDODc4MikuDQo+ID4gPg0KPiA+ ID4gPiBTZWN0aW9uIDEuMiByZWZlcmVuY2VzIFtJLUQuaWV0Zi1kb3RzLXNlcnZlci1kaXNjb3Zl cnldIGZvcg0KPiA+ID4gPiBwcm92aXNpb25pbmcuICBJbiB0dXJuLCBTZWN0aW9uIDEgb2YgW0kt RC5pZXRmLnNlcnZlci1kaXNjb3ZlcnldDQo+ID4gPiA+IGFsc28gZGVjbGFyZXMgdGhpcyBwcm9i bGVtIG91dCBvZiBzY29wZSBieSBzYXlpbmcg4oCcVGhpcyBkb2N1bWVudA0KPiA+ID4gPiBhc3N1 bWVzIHRoYXQgc2VjdXJpdHkgY3JlZGVudGlhbHMgdG8gYXV0aGVudGljYXRlIERPVFMgc2VydmVy KHMpDQo+ID4gYXJlDQo+ID4gPiA+IHByZS1wcm92aXNpb25lZCB0byBhIERPVFMgY2xpZW50IHVz aW5nIGEgbWVjaGFuaXNtIHN1Y2ggYXMgKGJ1dA0KPiA+IG5vdA0KPiA+ID4gPiBsaW1pdGVkIHRv KSB0aG9zZSBkaXNjdXNzZWQgaW4gW1JGQzg1NzJdIG9yIFtJLUQuaWV0Zi1hbmltYS0NCj4gPiA+ ID4gYm9vdHN0cmFwcGluZy1rZXlpbmZyYV3igJ0uICBIb3dldmVyLCBSRkM4NTcyIHNlZW1zIHRv IHJlbHkgb24NCj4gPiBORVRDT05GDQo+ID4gPiA+IGFuZCBSRVNUQ09ORiB3aGljaCBzZWVtcyBs aWtlIGEgcmF0aGVyIHVuY29tbW9uIGZlYXR1cmUgb2YgaG9tZQ0KPiA+ID4gPiByb3V0ZXJzLiAg QlJLU0kgcmVsaWVzIG9uIGEgbWFudWZhY3R1cmVyIHN1cHBsaWVkL2NvbnRyYWN0ZWQNCj4gPiA+ ID4gaW5mcmFzdHJ1Y3R1cmUgYW5kIGtleXN0b3JlcyB0aGF0IGFsc28gc2VlbSB1bmNvbW1vbiBm b3INCj4gPiBjb25zdW1lcg0KPiA+ID4gPiBncmFkZSBlcXVpcG1lbnQuDQo+ID4gPg0KPiA+ID4g W01lZF0gVGhlc2UgYXJlIG5vdCBtZWFudCB0byBiZSByZWNvbW1lbmRhdGlvbnMuIFRoZXNlIGV4 YW1wbGVzDQo+ID4gbWF5IGJlDQo+ID4gPiBPSyBmb3Igc29tZSBkZXBsb3ltZW50cywgYnV0IG5v dCBhcHByb3ByaWF0ZSBmb3Igb3RoZXJzLg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gLS0gU2Vj dGlvbiA1LjMuMS4NCj4gPiA+ID4gVGhlIENhbGwgSG9tZSBET1RTIHNlcnZlciBkb21haW4gYWRt aW5pc3RyYXRvciBjb25zZW50IE1BWSBiZQ0KPiA+ID4gPiAgICByZXF1aXJlZCB0byBibG9jayB0 aGUgdHJhZmZpYyBmcm9tIHRoZSBjb21wcm9taXNlZCBkZXZpY2UgdG8NCj4gPiB0aGUNCj4gPiA+ ID4gICAgYXR0YWNrIHRhcmdldC4gIEFuIGltcGxlbWVudGF0aW9uIE1BWSBoYXZlIGEgY29uZmln dXJhdGlvbg0KPiA+IGtub2IgdG8NCj4gPiA+ID4gICAgYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0 aGUgY29tcHJvbWlzZWQgZGV2aWNlIHRvIHRoZSBhdHRhY2sNCj4gPiB0YXJnZXQNCj4gPiA+ID4g ICAgd2l0aCBvciB3aXRob3V0IERPVFMgc2VydmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIGNvbnNl bnQuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBzdWdnZXN0aW9uIGhlcmUgc2VlbXMgdG8gYmUgdGhh dCBjb25zdW1lcnMgYXJlIGFjcXVpcmluZw0KPiA+IGRldmljZXMNCj4gPiA+ID4gdGhhdCBjYW4g YmUgcmVtb3RlbHkgcmVjb25maWd1cmVkIHdpdGggb3V0IGEgZGVmaW5lZCB0cnVzdA0KPiA+IG1v ZGVsPw0KPiA+ID4NCj4gPiA+IFtNZWRdIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkgd2hpY2ggc3Vn Z2VzdGlvbiBhcmUgeW91IHJlZmVycmluZw0KPiA+IHRvPw0KPiA+DQo+ID4gSSdtIHdvbmRlcmlu ZyB3aG8gdGhlICJzZXJ2ZXIgZG9tYWluIGFkbWluaXN0cmF0b3IiIGlzIGFuZCBob3cgdGhleQ0K PiA+IGFyZSBleHBlY3RlZCB0byBjb25zZW50IGluIHRoZSBob21lIHVzZXIgc2NlbmFyaW8/DQo+ ID4NCj4gPiA+IFRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgcmVmZXJyaW5nIHRvIGJsb2NraW5nIHRy YWZmaWMgZnJvbSBkZXZpY2VzDQo+ID4gdGhhdA0KPiA+ID4gYXJlIGluamVjdGluZyBERG9TIHRy YWZmaWMgZnJvbSB3aXRoaW4gYSBkb21haW4uIFRoZXNlIGRldmljZXMgY2FuDQo+ID4gYmUNCj4g PiA+IGFuIElQIGNhbWVyYSwgYW4gaW5mZWN0ZWQgUEMsIGV0Yy4NCj4gPiA+DQo+ID4gPiA+IFNv bWUgcG9saWN5IG9yIG9wZXJhdGlvbmFsIGNvbnRleHQgc2VlbXMgYXBwcm9wcmlhdGUgaGVyZS4N Cj4gPiA+ID4NCj4gPiA+ID4gLS0gU2VjdGlvbiA1LjMuMQ0KPiA+ID4gPiAuLi4gbm90aWZpZXMg dGhlIENQRQ0KPiA+ID4gPiAgICBhZG1pbmlzdHJhdG9yIGFib3V0IHRoZSBjb21wcm9taXNlZCBk ZXZpY2UNCj4gPiA+ID4NCj4gPiA+ID4gTm90aWZ5IGhvdz8NCj4gPiA+DQo+ID4gPiBbTWVkXSBT ZWUgYWJvdmUuDQo+ID4NCj4gPiBMaWtlIEkgbm90ZWQgYWJvdmUsIGlmIEknbSBhIGhvbWUgdXNl ciwgaG93IGFtIEkgbGlrZWx5IHRvIGdldCB0aGF0DQo+ID4gbm90aWZpY2F0aW9uPw0KPiA+DQo+ ID4gPiA+DQo+ID4gPiA+IC0tIFNlY3Rpb24gOC4NCj4gPiA+ID4gQXBwcm9wcmlhdGUNCj4gPiA+ ID4gICAgZmlsdGVycyAoZS5nLiwgYWNjZXNzIGNvbnRyb2wgbGlzdHMpIGNhbiBiZSBpbnN0YWxs ZWQgb24gdGhlDQo+ID4gQ2FsbA0KPiA+ID4gPiAgICBIb21lIERPVFMgc2VydmVyIGFuZCBuZXR3 b3JrIGJldHdlZW4gdGhlIENhbGwgSG9tZSBET1RTDQo+ID4gYWdlbnRzIHNvDQo+ID4gPiA+ICAg IHRoYXQgb25seSBjb21tdW5pY2F0aW9ucyBmcm9tIGEgdHJ1c3RlZCBDYWxsIEhvbWUgRE9UUyBj bGllbnQNCj4gPiB0bw0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gICAgQ2FsbCBIb21lIERPVFMgc2Vy dmVyIGFyZSBhbGxvd2VkLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIHNlZW1zIGxpa2UgYSBsZXZl bCBvZiBzb3BoaXN0aWNhdGlvbiBiZXlvbmQgeW91ciBhdmVyYWdlDQo+ID4gaG9tZQ0KPiA+ID4g PiByb3V0ZXIgdXNlciBhbmQgYSBwbGFjZSB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGNv bnNpZGVyIGENCj4gPiA+ID4gc2VjdXJlIGRlZmF1bHRzLg0KPiA+ID4NCj4gPiA+IFtNZWRdIFRo aXMgZmlsdGVyaW5nIGNhbiBiZSBhdXRvbWF0aWNhbGx5IHNldCBiYXNlZCBvbiB0aGUNCj4gPiBj b25maWd1cmVkDQo+ID4gPiBsaXN0IG9mIENhbGwgSG9tZSBET1RTIGNsaWVudHMuIFRoaXMgaXMg YSB3aWRlbHkgdXNlZCBwcmFjdGljZQ0KPiA+ICh0aGluaw0KPiA+ID4gYWJvdXQgU0lQIHByb3h5 IHNlcnZlcnMsIGV4YW1wbGUpLiBObyBpbnRlcnZlbnRpb24gbWF5IGJlIHJlcXVpcmVkDQo+ID4g ZnJvbSB0aGUgdXNlci4NCj4gPg0KPiA+IEFncmVlZC4gIEhvd2V2ZXIsIHRoaXMgaXMgYXNzdW1p bmcgdGhhdCBzb21lb25lIGlzIG1hbmFnaW5nIHRoYXQNCj4gPiBjb25maWd1cmF0aW9uLiAgTXkg cG9pbnQgaXMgdGhhdCBpbiB0aGUgaG9tZSB1c2VyIHNwYWNlIHRoYXQgaXMgbW9zdA0KPiA+IGxp a2VseSB0aGUgSVNQLCBzbyBsZXQncyBqdXN0IHNheSB0aGF0Lg0KPiA+DQo+ID4gPiA+DQo+ID4g PiA+IC0tIFNlY3Rpb24gOC4NCj4gPiA+ID4gQ2FsbCBIb21lIERPVFMgc2VydmVycyBjYW4gYWxz byBzZWVrIHRoZSBjb25zZW50IG9mIERPVFMNCj4gPiA+ID4gICAgc2VydmVyIGRvbWFpbiBhZG1p bmlzdHJhdG9yIHRvIGJsb2NrIHRoZSB0cmFmZmljIGZyb20gdGhlDQo+ID4gPiA+IHBvdGVudGlh bGx5DQo+ID4gPiA+ICAgIGNvbXByb21pc2VkIGRldmljZSB0byB0aGUgdGFyZ2V0IChzZWUgU2Vj dGlvbiA1LjMuMSkuDQo+ID4gPiA+DQo+ID4gPiA+IFdoYXQgd291bGQgYmUgdGhlIG1lYW5zIHRv IGdhaW4gc3VjaCBjb25zZW50Pw0KPiA+ID4NCj4gPiA+IFtNZWRdIFRoaXMgd2lsbCBkZXBlbmQg b24gdGhlIGRlcGxveW1lbnQgY2FzZTogdGhpcyBjYW4gYmUgYW4NCj4gPiBhY3Rpb24NCj4gPiA+ IGV4ZWN1dGVkIHVzaW5nIGFuIGFwcCwgYSBjb25maXJtYXRpb24gdG8gYSBub3RpZmljYXRpb24g bWVzc2FnZSwNCj4gPiBldGMuDQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLSBTZWN0aW9uIDku DQo+ID4gPiA+IE5vdGUgdGhhdCBhIENhbGwgSG9tZSBET1RTIHNlcnZlciBjYW4gc2VlayBhbiBh ZG1pbmlzdHJhdG9yJ3MNCj4gPiA+ID4gICAgY29uc2VudCwgdmFsaWRhdGUgdGhlIHJlcXVlc3Qg YnkgaW5zcGVjdGluZyB0aGUgcmVsZXZhbnQNCj4gPiB0cmFmZmljDQo+ID4gPiA+IGZvcg0KPiA+ ID4gPiAgICBhdHRhY2sgc2lnbmF0dXJlcywgb3IgcHJvY2VlZCB3aXRoIGJvdGggY291cnNlcyBv ZiBhY3Rpb24uDQo+ID4gPiA+DQo+ID4gPiA+IEFzIGFib3ZlLg0KPiA+ID4NCj4gPiA+IFtNZWRd IEFzIGFib3ZlIDotKQ0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gLS0gU2VjdGlvbiA5Lg0KPiA+ ID4gPg0KPiA+ID4gPiAgICAgVGhlIERPVFMgQ2FsbCBIb21lIGlzIG9ubHkgYWR2aXNvcnkgaW4g bmF0dXJlLiAgQ29uY3JldGVseSwNCj4gPiB0aGUNCj4gPiA+ID4gRE9UUw0KPiA+ID4gPiAgICBD YWxsIEhvbWUgZG9lcyBub3QgaW1wb3NlIGFueSBhY3Rpb24gdG8gYmUgZW5mb3JjZWQgd2l0aGlu DQo+ID4gdGhlDQo+ID4gPiA+ICAgIG5ldHdvcmsgaG9zdGluZyBhbiBhdHRhY2sgc291cmNlOyBp dCBpcyB1cCB0byB0aGUgQ2FsbCBIb21lDQo+ID4gRE9UUw0KPiA+ID4gPiAgICBzZXJ2ZXIgKGFu ZC9vciBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIHRvIGRlY2lkZSB3aGV0aGVyIGFuZA0KPiA+IHdo aWNoDQo+ID4gPiA+ICAgIGFjdGlvbnMgYXJlIHJlcXVpcmVkLg0KPiA+ID4gPg0KPiA+ID4gPiBT dWNoIGEgZGVjaXNpb25zIHNlZW1zIG91dCBiZXlvbmQgdGhlIGFiaWxpdHkgb2YgeW91ciBhdmVy YWdlDQo+ID4gaG9tZQ0KPiA+ID4gPiByb3V0ZXIgdXNlci4NCj4gPiA+DQo+ID4gPiBbTWVkXSBX ZSBkb24ndCBoYXZlIHRoZSBub3Rpb24gb2YgImF2ZXJhZ2UgaG9tZSByb3V0ZXIgdXNlciIgOy0p DQo+ID4NCj4gPiBBZ3JlZWQuICBQcm9iYWJseSBub3QgdXMgdGhvdWdoIDotKS4gIE15IGludGVu dCB3YXMgdG8gc2F5IHRoYXQgd2hlbg0KPiA+IHRoZSBhY3Rpb25zL2RlY2lzaW9ucyBhcmUgYmVp bmcgZnJhbWVkIGFzIGJlaW5nIGZvciBhICJuZXR3b3JrIGFkbWluIiwNCj4gPiB0aGF0IHRvIG1l IHN1Z2dlc3RzIGEgbGV2ZWwgZXhwZXJ0aXNlIG91dHNpZGUgb2YgdGhlIGNhcGFiaWxpdHkgb2YN Cj4gPiB0eXBpY2FsIGVuZCBjb25zdW1lciB3aXRob3V0IHByb2Zlc3Npb25hbCBJVCBkZWNpc2lv bnMuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFJvbWFuDQo+ID4NCj4gPiA+ID4NCj4gPiA+ID4g LS0gU2VjdGlvbiA4ICDigJwuLi4gZXhwbGljaXQgcG9saWN5IChlLmcuLCB0aGUgQ2FsbCBIb21l IERPVFMNCj4gPiBjbGllbnQNCj4gPiA+ID4gYW5kIHNlcnZlciBhcmUgbWFuYWdlZCBieSB0aGUg c2FtZSBhZG1pbmlzdHJhdGl2ZSBlbnRpdHkpLA0KPiA+ID4gPg0KPiA+ID4gPiBJcyB0aGVyZSBh biB1bmRlcmx5aW5nIGFzc3VtcHRpb24gdGhhdCB0aGUgSVNQIGlzIG1hbmFnaW5nIHRoZQ0KPiA+ IGRldmljZT8NCj4gPiA+DQo+ID4gPiBbTWVkXSBJU1AgbWFuYWdlZCBkZXZpY2VzIGlzIG9uZSB0 eXBpY2FsIGRlcGxveW1lbnQgY2FzZS4NCj4gPiA+DQo+ID4gPiBUaGF0J3Mgc2FpZCwgdGhlIHRl eHQgeW91IHF1b3RlZCBpcyBub3Qgc3BlY2lmaWMgdG8gSVNQcy4gSXQNCj4gPiBhcHBsaWVzLA0K PiA+ID4gZm9yIGV4YW1wbGUsIHdoZW4gZ2F0ZXdheXMgYXJlIG9uIHRoZSBwYXRoIGFuZCBib3Ro IHRoZSBDYWxsIEhvbWUNCj4gPiBET1RTDQo+ID4gPiBzZXJ2ZXIgYW5kIENhbGwgSG9tZSBET1RT IGNsaWVudCB3aWxsIHRodXMgYmUgbWFuYWdlZCBieSB0aGUgREMNCj4gPiA+IHByb3ZpZGVyLCB0 aGUgZW50ZXJwcmlzZSBhZG1pbmlzdHJhdG9yLCB0aGUgYWNjZXNzIHByb3ZpZGVyLCBldGMuDQo+ ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPg0KPiA+ID4g Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zDQo+ID4gPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYyBwYXMgZXRyZQ0KPiA+IGRpZmZ1c2VzLA0KPiA+ID4gZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UNCj4gPiBtZXNzYWdl DQo+ID4gPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZQ0KPiA+IGFpbnNpDQo+ID4gPiBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudA0KPiA+IHN1c2NlcHRpYmxlcw0KPiA+ID4g ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGENCj4gPiBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4g PiA+DQo+ID4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3INCj4gPiA+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQNCj4gPiBub3QNCj4gPiA+IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gPiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXINCj4gPiBhbmQNCj4gPiA+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCj4gPiA+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQNCj4gPiBoYXZlDQo+ID4gPiBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4gPiA+IFRoYW5rIHlvdS4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRG90cyBtYWlsaW5n IGxpc3QNCj4gPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IENlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0K PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91DQo+IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZQ0KPiBz aWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMNCj4gZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZQ0KPiByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ IA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZA0KPiBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQNCj4gb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcw0KPiBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuDQo+IG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KDQo= From nobody Fri Jan 8 04:30:53 2021 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 96D8C3A0C2A; Fri, 8 Jan 2021 04:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Hb_vyQ0tHVja; Fri, 8 Jan 2021 04:30:43 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2069.outbound.protection.outlook.com [40.107.22.69]) (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 CDF663A0C29; Fri, 8 Jan 2021 04:30:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QEL/W4oLQuC6tetXOeRCFyfOlm4ftzzjnJtNnR8ucH6o6ytRXqGGeqLBc4nrQKWEJopCW5E65HaO2JWMGCRRlIrusHR9G25ZWNM0IcHqiDVWYcokR+kXtL6u+w6atwWvNRA6NHXUd3DXah26/rmSuW8VnCEazXai8kxCKzm9U8r+XHGJh+gy2iQwS28u6kB5UMH5+vvZZQuHH8e0rEhr/YQKDhqfFi2ukGTOF/kD4ZJ84DBdIRUNnrjp0OsJrd3PIpk2LBfE+/lmnRzXeXCu5hHcAqPEAlAFG4D8FC8M0SVmXwvQoKJi5Q4bRiNKZhyM1w7Ya9/IpnCaIImDNoI/Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zY3zR955OxlOHuLU6CrPpmwVYYSQWTnP8kMiCqU2mxA=; b=PuMzFYU48/V4rolKx8wK1M6l2L6HcL4dlpivTMxqcq9r4+vGOA8Jv17U0aYoUNMcuLH0v2XwfexYtZjAo7IGwjYJPVeR6UQqCHA3ptW5AwQucCBh31mmdAxpDNkZzlQcNhNL8Ybh87Q9J4yUYrxbH2YBuqakZort8eAq1nU7spXZ+bh2pUYiIIaHDQJ4a+UKwkuoETLvKhxX68tbREy2nfrZHX/rcWVsLuY0jJ9wDwvoyrJUw1sZ98el22Yi861A9QofVsoTSaYnz7zx5e3hPRMbyNb7SKO1d7XjkjCip1xG3IBcgUcnzxMhNcUobW2Hbm9iB/e8Nc5c2z4tnBXYdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zY3zR955OxlOHuLU6CrPpmwVYYSQWTnP8kMiCqU2mxA=; b=RGRxaWE6MGdCVhLiArsRP73Wug+27aZ4g0jFft3iMcrHxLuQNbhMKFxwR5UDOZ0jh7UDRvKNwJoZLfntIFFNkE71E9pML7Ntu49whNV9VjutAFLHFw3DljIEUnKsfS4lMvCFxLiw0JSKHEYMBpD8XTjPdmqPI475mE4KJdMjNUg= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2266.eurprd07.prod.outlook.com (2603:10a6:3:2c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.5; Fri, 8 Jan 2021 12:30:34 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%6]) with mapi id 15.20.3742.006; Fri, 8 Jan 2021 12:30:34 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "mohamed.boucadair@orange.com" , "supjps-ietf@jpshallow.com" CC: "valery@smyslov.net" , "dots@ietf.org" , "dots-chairs@ietf.org" , "draft-ietf-dots-signal-call-home@ietf.org" Thread-Topic: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS) Thread-Index: AQHW1IEMs9vsdNy1dUKXFtQUcezc5qn7Z94AgAAI8ICAABFlgIAACniAgABCigCAAM7vgIABuBMAgAMSigCAAAn2YIAcWGSA Date: Fri, 8 Jan 2021 12:30:34 +0000 Message-ID: References: <160821536495.8335.5498062431481972966@ietfa.amsl.com> <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <83fe6f11ec1cfcfd1f4c4493854c8ce6eaa542f4.camel@ericsson.com> <135d01d6d495$9b1b94e0$d152bea0$@jpshallow.com> <75351574777c1f8100f15474ff5c755f6334645a.camel@ericsson.com> <13d001d6d4bc$1c543870$54fca950$@jpshallow.com> <9a304e2ec6886de19ec54d2d56309442db652a02.camel@ericsson.com> <154a01d6d5ff$9d022ab0$d7068010$@jpshallow.com> <6d2f00810b5bc9ec3e8ab10fa7e75b824e0f9003.camel@ericsson.com> <14908_1608555829_5FE09D35_14908_286_4_787AE7BB302AE849A7480A190F8B9330315A056A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <14908_1608555829_5FE09D35_14908_286_4_787AE7BB302AE849A7480A190F8B9330315A056A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.130.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1fe38d0d-4f95-474f-a156-08d8b3d1327b x-ms-traffictypediagnostic: HE1PR0701MB2266: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bdboSd8o3NiK+nhR5kYzXYYtwPr2V3yEtFdESF3DdcpstknqoOosQR+9vgPgIYzeaoK4K5k6xCaKawCV1asKhv5ZiERj0hSq9053LmNp7v1Qmw7GWO1lQTPzWUcEmMBDFdWfqCS1A9y+94HYt/Pi4AbWmZNZ6yu8Jw0/VEr+WzpG26wMJ3ZGjAGKI+fAMwOfPckwYAL21jauprru/iSo4iTMVKUXgrIMFZoyaaT+wznPuxnjO+E5n2bEtLz01OsyBeaShNMNg2WMfZXagAEtr/x/nQh0K8KR6ol0rmtoygMUcYkntV97UbkAnIszTzXnay4XlGLhRIcj1fzDvm0l0wz7NxNU3ypgC/6EVGugb/DHFGS/oIvxhIP24nG7kYOWQrQP4nbDF+j9CadIaPOjky0rrIL4r6UmWdFkN+gbZ/pewy5z6KjPx4UR/xdN5L52xStbNKLDTpgNaXbp5iOWsautbuLaVUwqedPJQtiJXJqtwhcmOFlXfXFwNfC+r5ksfEJKGiG+ZVmt14QwCoLHrA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(396003)(346002)(39860400002)(110136005)(316002)(6512007)(86362001)(54906003)(53546011)(66574015)(30864003)(4001150100001)(966005)(83380400001)(64756008)(44832011)(478600001)(6486002)(6506007)(36756003)(66616009)(186003)(66556008)(8936002)(66946007)(2906002)(2616005)(66476007)(8676002)(4326008)(26005)(99936003)(5660300002)(71200400001)(66446008)(76116006)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SmtPRW81eGdDOHRYM3l5OFVScjdDTWZ1OXROeGlFY1JkR3RKNGRXWHc5UW1j?= =?utf-8?B?eFVkaEhyeWtwam54blV5QWlveXgzUTdqT1ErZlNNeitOQ2wzaWJvRkVqdVlk?= =?utf-8?B?SUJHR0xxUXh0b25nZFlCdW9YcHVxUEFIcHVXbG5aR0tYb3dTcUwzTFlsQUhy?= =?utf-8?B?TjNaTEZwVmZqOHJlZzBBSWVrNW9UQzR2MWF3aENmYktTVWVqN0VwRit3ckU1?= =?utf-8?B?Y3lrN2doZkpvV2VHQ3IwK3Q0MjhzRUdiZXM3RTNSR2VpS0lWTTFRQnRuMzdM?= =?utf-8?B?Qm93S1JTSWNBcmx1dXQ2dWZjTmZiTmNuZlNzSTZkZnBCczAyeEFHUktzc1ZI?= =?utf-8?B?c1A5SHBjMlVyNVYwbERQdnQ0cGZuRHZ5WWNnaUs5aWdSYjZSSGMzUGRSdk40?= =?utf-8?B?S0FCM0Q0aUpRUFhPb0pzOE4xLzFhSXpGaTJKNktRcHhEOS9kT0hlYjJPeXlz?= =?utf-8?B?MTBqeTBaYWtGbmhTZ1R0NmpJRGRRVkpobmtOZHlWbEVXTnVEM3lKaXhFWmY5?= =?utf-8?B?TG1hQUNTMGZKZzNIbE1YYWgyRU9YL0tsVVlGSGx4WWJpbm4zNWdzRjJVRU10?= =?utf-8?B?L0ZXOVJVVTdhcENKbGpHdmZaY2p6SXR4RnNQalMzVkVWNlZrME1ZMnFqaEdh?= =?utf-8?B?N1FuaG1MWTYrVzlpT3dndU5JUzBzSXdSSzZ0ampHUXNTOWptOExUMDFsUjUz?= =?utf-8?B?YUVjYVdKc2QwaEMwbUl2UjN1ek14UjZTamVxTURSWVFGbWczNkU0aTdSNktv?= =?utf-8?B?Rjc1RTNJeTcwSGpCVDZyZ1ZPZ2dFNzF1eUNJaWVpTThPVjZsUnA3S01vYW5X?= =?utf-8?B?WEFWR1VyS3BwYXIrTDM0VUJ2SHYvZDFJQkdBTFdvckgxcGR3Szkxd0lYTit6?= =?utf-8?B?SnhVM25ZWEk5ODg1Z2E5Ym5Yc0pPaDI3VXZnRG5RTklrK2U0SmMrU09GdTdh?= =?utf-8?B?WjhiTjBqSEpUcFFsM2VjR1FuRzN0RGhNTXVxL2x5dFVTckIrSHhrZWhGcDFO?= =?utf-8?B?U1Q5ckJxVlE0MmFGTjlRU21XTTNOcEVJS0VKcW1BZjZlemxSbmZpbFpqWEJ2?= =?utf-8?B?OCtldWRGTmVhL2FyRXoxdDcvUEl6ZmFaSkNrTjdJL2lVU21UdUtmN3I1UlBi?= =?utf-8?B?bTJuNWVsWlMvYzFleldiNy9NajR6NmduY0hPanJUSC8wdW1GNjdSRFpsaSsr?= =?utf-8?B?SW85eVBCenRaZFFXY0RvWTRvaEVoWGo2Vkt1eHdlWC9leXhnWGJsQ1ZIVU5q?= =?utf-8?B?YlZ3Sm4wdWx0Qlc3NFN1bSs3WnJqQVdPOWtZT2h2UGNXeTV0MVhhVGUrbGJE?= =?utf-8?Q?2AQZSm52fBiRlJshCEETanvUzvS8txOqN2?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-jXMWW1XVZntAf+jNIS+t" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fe38d0d-4f95-474f-a156-08d8b3d1327b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2021 12:30:34.8045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: E37GqtqDd7fpJR3hHTh9fyM5ZuV4fjtmGzQGEQLNvWrgJCxKt6W/ThZUP4MoiGFJhjUyXBzhtf08NYSzcrhV77fooUYEsroL2uUoz1U7iqY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2266 Archived-At: Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS) 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, 08 Jan 2021 12:30:48 -0000 --=-jXMWW1XVZntAf+jNIS+t Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I don't think restconf/netconf is particular relevant precedences for assignment. These are older protocols, they are not based on COAP and don't= have the same facilities that would make additional port assignments unnecessary= . If you had designed how Dots signal call home from the start with the assum= ption that they would share port, I don't think you would have had any issues. Th= ere are sufficient mechanism in DTLS/COAP to ensure that this would not have be= en an issue. We are where we are based on decisions the WG made along the way, an= d also the implementation choices done in the current implementations.=20 When it comes to guidance, I do think more should be written on the options= to avoid the need for additional ports and what to think about such designs in= the beginning. I might spend some cycles on this after my AD term is over.=20 I do understand to make co-location easy you should have designed the name = space differently so that one would separate the call home usages in for example = the URI namespace. Or used a header field etc.=20 So we are in an sort of impasse here. You don't want to change your protoco= l and your implementations. I would prefer to not approve this assignment as it i= sn't a necessary one and it sends a very wrong message to the community.=20 Note, I am supportive in that DOTS in general got its first port, based on = the potential need for in network identification of the DOTS flow based on 5-tu= ple. Which in itself is a double-edged sword as an attacker that is smart will u= se the DOTS ports for its attack traffic.=20 I intended to discuss this with the other ADs next Thursday. I think from m= y perspective the main issue is how we reduce the number of unencessary port request from IETF protocol work in the future.=20 So what would you have needed to make the right choice earlier? Would a bet= ter document about things to consider around ports and their usage in protocol design helped you? Yes. I will go to an abstain.=20 Regards Magnus On Mon, 2020-12-21 at 13:03 +0000, mohamed.boucadair@orange.com wrote: > Hi Magnus, >=20 > Thank you for sharing your thoughts.=20 >=20 > We considered seriously the use of a distinct port vs. using the one that= is > already assigned to dots-signal. We documented the rationale in an append= ix > and also provided a detailed answer to why we think reusing the existing = port > is not that straightforward. We already answered why SRV records are not > sufficient. Please refer to the message we shared with you early in this > thread:=20 > https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/ (= (4) > Why not using a dynamic port number following, e.g., draft-ietf-dots-serv= er- > discovery?).=20 >=20 > Also, we are familiar with existing BCPs. Please trust me, if dots-call-h= ome > was the same service as dots-signal, we wouldn't make the request. "DOTS > server" and "DOTS client" are distinct and fully decoupled services.=20 > dots-call-home is a distinct service vs dots-signal in the same way > netconf/restconf-call-home is a distinct service vs netconf/restocnf. As = a > reminder, *** three (3) *** additional port numbers were assigned in > rfc8071#section-6 for the call-home in addition to the already assigned *= ** > four (4) *** port numbers for NETCONF. >=20 > The proposal to define a (DTLS) dispatcher and the internal machinery to = steer > the traffic to a specific service is, if it works, a ** new service ** pe= r se, > that it is worth to be assigned a dedicated port on it owns: "One service= , one > port". Yet, we don't have evidence that service is feasible/works. What w= ould > be helpful for the community in the future, is that tsv area provides a s= pec > of such service and evidence that it works without side effects. With tha= t > service defined, protocols running on DTLS can be muxed on that port numb= er. > Nevertheless, we need to remind that the dispatcher service might be simi= lar > in its goals to TCPMUX, which is *** obsoleted *** for reasons documented= in > RFC7805. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Envoy=C3=A9 : lundi 21 d=C3=A9cembre 2020 12:03 > > =C3=80 : iesg@ietf.org; magnus.westerlund=3D40ericsson.com@dmarc.ietf.o= rg; > > supjps-ietf@jpshallow.com; BOUCADAIR Mohamed TGI/OLN > > > > Cc : valery@smyslov.net; dots@ietf.org; dots-chairs@ietf.org; draft- > > ietf-dots-signal-call-home@ietf.org > > Objet : Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots- > > signal-call-home-11: (with DISCUSS) > >=20 > > Hi, > >=20 > > I will start my Christmas vacation tomorrow, so don't expect any > > more responses > > until after the 7th of December. > >=20 > > I am hearing what you are saying about implementability. However, I > > have the > > feeling that the WG design process have failed to take into account > > some > > relevant aspects here. > >=20 > > 1. You are using COAP which do share high level semantics with HTTP. > > Thus, > > different functionalites can easily be defined to work in parallel > > on a server. > > Thus it could have been easy to ensure that individual or coloated > > dots-signal > > and dots-call-home could be co-locate. Especially as you do have it > > part of what > > is considered. > >=20 > > 2. You got a port for dots-signal to enable firewalls and routers > > etc to > > identify and handle this traffic, otherwise I think dots-signal > > would have been > > leaned hard on using the default COAP port. Expecting to consume > > another port > > just because you didn't consider the constraints, which RFC6335 is > > clear with I > > think is tough for me to swallow. > >=20 > > 3. You have several ways of designing yourself out of these issues > > that has been > > raised. I understand this might be considered a late surprise, but > > it shouldn't > > if you had read the in force BCP. > >=20 > > My next question, do you actually need a fixed port at all for this. > > The service > > name enables you to do SRV look ups to find port and IP address for > > the service. > > Isn't that sufficient if you still want to run it on dedicated port > > compared to > > DOTS-signal? > >=20 > > Cheers > >=20 > > Magnus Westerlund > >=20 > >=20 > >=20 > > On Sat, 2020-12-19 at 12:08 +0000, supjps-ietf@jpshallow.com wrote: > > > Hi Magnus, > > >=20 > > > Please see inline. > > >=20 > > > Regards > > >=20 > > > Jon > > >=20 > > > > -----Original Message----- > > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > > Sent: 18 December 2020 09:53 > > > > To: iesg@ietf.org; > >=20 > > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org; supjps- > > > > ietf@jpshallow.com; mohamed.boucadair@orange.com > > > > Cc: valery@smyslov.net; dots@ietf.org; dots-chairs@ietf.org; > >=20 > > draft-ietf- > > > > dots- > > > > signal-call-home@ietf.org > > > > Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf- > >=20 > > dots-signal- > > > > call- > > > > home-11: (with DISCUSS) > > > >=20 > > >=20 > > > ... > > > > > > So I think there are several possible implementation paths > >=20 > > for this. I > > > > > > see > > > > > > at least > > > > > > two. > > > > > >=20 > > > > > > First, do a 5-tuple connect on UDP to filter that particular > >=20 > > UDP flow, > > > > > > process the > > > > > > DTLS handshake for this socket and then based on ALPN decide > >=20 > > on target > > > > > > process and then hand over the socket and the DTLS state to > >=20 > > the right > > > > > > process. > > > > >=20 > > > > > [Jon] UDP has no concept of accept(). If you do a connect() > >=20 > > on a socket > > > > > that > > > > > you have just received data on, then that updates the 5 tuple > >=20 > > and then > > > > > only > > > > > receives traffic matching the tuple as expected. However, it > >=20 > > appears not > > > > > possible to leave the original socket ready for the next > >=20 > > packet (from > > > > > different IP etc.) and set up a new socket to specifically > >=20 > > handle the > > > > > stream > > > > > matching the packet just received, bind(same_port), do the > >=20 > > connect() on it > > > > > etc. (the bind(same_port)fails in my test). > > > >=20 > > > > So I don't have a code exmample for this available, but I > >=20 > > thought you can > > > > make > > > > it work with so_reuseport/so_reuseaddr. There are some downside > >=20 > > in that the > > > > new > > > > socket can receive packets prior to the connect that just > >=20 > > arrive. > > > >=20 > > >=20 > > > [Jon] I was using SO_REUSEADDR, but have found a bug in my test > >=20 > > code so I now > > > able to bind(same_port). While a new socket and connect() can be > >=20 > > done to > > > match a new UDP client, it needs to be thought through when this > >=20 > > is done - the > > > arrival of the first UDP packet, when the DTLS APLN is known, or > >=20 > > when the DTLS > > > handshake is complete. The DOTS stack we have is > > > https://tools.ietf.org/html/rfc8782#section-3 Figure 3 > > >=20 > > > DOTS > > > CoAP > > > DTLS > > > UDP > > > IP > > >=20 > > > [Jon] It is unclear to me as to how you can hand off a DTLS > >=20 > > context to a > > > different, non identical process along with its socket (this may > >=20 > > be possible > > > with OpenSSL, not sure about other TLS libraries - there is > >=20 > > limited kernel > > > AF_KTLS support which may help). DTLS session resumption then > >=20 > > also gets a lot > > > more complicated. > > >=20 > > > [Jon] Then there is the challenge of how the received DTLS context > >=20 > > + socket > > > are integrated into the CoAP & DTLS stack on the receiving > >=20 > > application so that > > > things keep working. In my port, it is the CoAP library that > >=20 > > handles the > > > sockets, not the DOTS application which would mean having > >=20 > > customized code for > > > the CoAP library - not ideal for maintenance long term. > > >=20 > > > [Jon] My surmise would be that implementors would say "forget this > >=20 > > complexity > > > with its inherent risks and just use a non-standard port" > > >=20 > > > > >=20 > > > > > >=20 > > > > > > Secondly, is to run some type of front end dispatcher that > >=20 > > processes the > > > > > > packets > > > > > > and tracks all the different DTLS connection and have secure > >=20 > > message > > > >=20 > > > > passing > > > > > > between the front end dispatcher and the different servers. > >=20 > > But this do > > > > > > requie > > > > > > another security model and trust relationship between the > >=20 > > dispatcher and > > > >=20 > > > > the > > > > > > servers. > > > > >=20 > > > > > [Jon] This does complicate things. The DOTS signal channel > >=20 > > requires > > > > > mutual > > > > > authentication of the agents and introducing some sort of man- > >=20 > > in-middle > > > > > that > > > > > changes the network flow IP addresses etc. and potentially > >=20 > > changes > > > > > encryption > > > > > characteristics breaks this mutual authentication. It is not > >=20 > > easy to > > > > > change > > > > > how the base DOTS signal works. > > > >=20 > > > > Sorry, I don't understand why you bring in changes to network > >=20 > > flow IP > > > > address. I > > > > said secure communication here, and I mean internal to the > >=20 > > server software > > > > between processes. > > >=20 > > > [Jon] I latched on to "different servers" as possibly having > >=20 > > different backend > > > IPs. Here, we actually have a DOTS server (sends responses) and a > >=20 > > DOTS client > > > (generates requests) that traffic needs to be steered to. > > >=20 > > > > Basic interprocess communication here. Also, it might be > > > > that > > > > you can start the DTLS processing in the dispatcher and then > >=20 > > hand over the > > > > DTLS > > > > state and only have encrypted UDP payloads being dispatached. > > >=20 > > > [Jon] As above, it is unclear to me as to how you can hand off a > >=20 > > DTLS context > > > to a different, non identical, process along with its socket and > >=20 > > then > > > integrate the received DTLS context into the different > >=20 > > application. > > >=20 > > > >=20 > > > > I would note that I think a lot of this dicsussion comes from > >=20 > > that the > > > > implementation you made so far has been done based on the > >=20 > > assumption that > > > > there > > > > would be a new port and separation rather than designing for > >=20 > > coloaction. If > > > > we > > > > take the step beyond your current implenentation from a protocol > >=20 > > perspective > > > > in > > > > an implementation built for co-location is there really any > >=20 > > significant > > > > issues > > > > here? > > >=20 > > > [Jon] I am the sort of person that needs to implement something to > >=20 > > prove > > > something is practically feasible, find what the issues are and > >=20 > > what needs to > > > be changed based on a specification and then debate how the spec > >=20 > > needs to be > > > updated to make it usable. > > >=20 > > > [Jon] DOTS call home did come later to the table after the initial > >=20 > > DOTS was > > > done which created the DOTS client and DOTS server as different > >=20 > > applications > > > in the implementations done to date. Adding in the DOTS call home > >=20 > > logic was > > > very simple (with different port) - simple addition of accepting > >=20 > > new > > > connections on the call home DOTS client which triggered the > >=20 > > client logic > > > start up and initiating connections on the call home DOTS server > >=20 > > and > > > associated configuration logic. > > >=20 > > > [Jon] While it is only software and hence not impossible, it is > >=20 > > significant > > > work to merge the client and server into a single application as > >=20 > > well as > > > having to maintain separate applications for running on limited > >=20 > > resource > > > devices. We do not want to put in barriers to implementation of > >=20 > > this draft by > > > making it complex to implement. Hence using a different port for > >=20 > > the client > > > service and the server service. > > >=20 > > > >=20 > > > >=20 > > > > Cheers > > > >=20 > > > > Magnus Westerlund > > >=20 > > >=20 >=20 > _________________________________________________________________________= _____ > ___________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 --=-jXMWW1XVZntAf+jNIS+t Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCErYw ggX0MIID3KADAgECAg8BdlE9InYZOYLl1zGep4IwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYzMB4XDTIwMTIxMTA5NTg0OVoXDTIzMTIxMjA5NTg0OVowXjERMA8GA1UECgwIRXJpY3Nzb24x GjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCIT6U9ddUp UCEryIA27xtF8WsRAIfc5jBavfu0OGDmwITYYRD2PaMEdEK+I4dqz0f6xcCrDnBk2Xj+JxjhaRkq TAifJZima9WE2JoI/uq8UsS2HJWlhspAwKx1osARgtRiMjRZZyyfiRZLbgXHWYpnTt3i9QsuX/uo 9oZFWpDCbZee4Il9uldsUcuBLZx2PyZvBvC8KCUaBXsZX6bwV7hssRVn+BgFCuEievJMx0khTRVh i9goObxu5Jl44RtwbZNYB1UE1IzRWEZw+b3cEvXiQjPl2e3ytMZSmhy+IaKmjxES6ODiuh51KAcm PZfZIaX2djmD76YGi+ETmnb8Xm3dAgMBAAGjggHEMIIBwDAfBgNVHSMEGDAWgBQcexmel5x2rCA9 2NzjkWrj2y2mUzAdBgNVHQ4EFgQUICO/88T0EQvEUm5+HVt/d9Mm+Z8wDgYDVR0PAQH/BAQDAgWg MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3Qu dGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2Vy aWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQADggIBANRZXQy+lUW97uaL uApOixnDKLpUoz+N/5Owd/9illmbxQDEY1/pPs4KJSvw88p+F3bmOzb+fLUNa6Mi/2Tw83FzEVmO 3RqzKtca+I9GDpRQ8oWL7hrUPJoNacidSZLmAP4L4kwHIhvGNX4f1c/oB4fAkP/xZsAAxYi7nKxd XA2n/KMWNkezyB9BSsD8ZOS4pWU8UaZjd5r0fzqM5zQbU4EPqHa8jFMSMz1UrYXPKKxl6E4WA3TE w1oLjcli0NWGQHyQ+3Kh7fe6zPoXfLd/2EQjr2o76ssgoqd2V1Mx5TRHdUyxjIMPEOVYpvcerNUB hEBkaOQ9FugYcMhMc8BF7nQZq+hsL/T7idg4gE2sEfNdK9RBf/EVH10GMrmbadqTycztD1gUL3dV Qxik4TCMxIctt9XqtTGHaMewZLQAXp/sHWlU/vmz9brcuzYQ9YVd5hTendGMUyGhWPV/KvxouKPK zdrGeEqUQCeBwWgQASQNOrpTzMJwZAV/Ww3ExQCjHvflvUQzVuU0sC6AEVkgqMATIXS6h6rjLL31 pjt2JV84XRjF5afYkcRIHTsrtcoWeFtOu/GpZNhtq+tde0QvnkSsjczMWU0gKk0hXBmXwEGUimuD Vq/Wvr0mr18d9mKA6xPNQOfn/VL5CWXa11OtOjj8WsTy3XUpyJ6dc9Z72TmKMIIF9DCCA9ygAwIB AgIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEy MTEwOTU4NDlaFw0yMzEyMTIwOTU4NDlaMF4xETAPBgNVBAoMCEVyaWNzc29uMRowGAYDVQQDDBFN YWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz b24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiE+lPXXVKVAhK8iANu8bRfFr EQCH3OYwWr37tDhg5sCE2GEQ9j2jBHRCviOHas9H+sXAqw5wZNl4/icY4WkZKkwInyWYpmvVhNia CP7qvFLEthyVpYbKQMCsdaLAEYLUYjI0WWcsn4kWS24Fx1mKZ07d4vULLl/7qPaGRVqQwm2XnuCJ fbpXbFHLgS2cdj8mbwbwvCglGgV7GV+m8Fe4bLEVZ/gYBQrhInryTMdJIU0VYYvYKDm8buSZeOEb cG2TWAdVBNSM0VhGcPm93BL14kIz5dnt8rTGUpocviGipo8REujg4roedSgHJj2X2SGl9nY5g++m BovhE5p2/F5t3QIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMw HQYDVR0OBBYEFCAjv/PE9BELxFJufh1bf3fTJvmfMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzApBgNVHREEIjAggR5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwgYIG CCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBI BggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQDUWV0MvpVFve7mi7gKTosZwyi6VKM/ jf+TsHf/YpZZm8UAxGNf6T7OCiUr8PPKfhd25js2/ny1DWujIv9k8PNxcxFZjt0asyrXGviPRg6U UPKFi+4a1DyaDWnInUmS5gD+C+JMByIbxjV+H9XP6AeHwJD/8WbAAMWIu5ysXVwNp/yjFjZHs8gf QUrA/GTkuKVlPFGmY3ea9H86jOc0G1OBD6h2vIxTEjM9VK2FzyisZehOFgN0xMNaC43JYtDVhkB8 kPtyoe33usz6F3y3f9hEI69qO+rLIKKndldTMeU0R3VMsYyDDxDlWKb3HqzVAYRAZGjkPRboGHDI THPARe50GavobC/0+4nYOIBNrBHzXSvUQX/xFR9dBjK5m2nak8nM7Q9YFC93VUMYpOEwjMSHLbfV 6rUxh2jHsGS0AF6f7B1pVP75s/W63Ls2EPWFXeYU3p3RjFMhoVj1fyr8aLijys3axnhKlEAngcFo EAEkDTq6U8zCcGQFf1sNxMUAox735b1EM1blNLAugBFZIKjAEyF0uoeq4yy99aY7diVfOF0YxeWn 2JHESB07K7XKFnhbTrvxqWTYbavrXXtEL55ErI3MzFlNICpNIVwZl8BBlIprg1av1r69Jq9fHfZi gOsTzUDn5/1S+Qll2tdTrTo4/FrE8t11KcienXPWe9k5ijCCBsIwggSqoAMCAQICEFO4foPhnJko k7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8AALhQ8qe7 2FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh /VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98M vWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmd vkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7 zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP 1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3s p0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25a EvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUU kBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCC AbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFz b25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUAA4IC AQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNHCZ7mmSNM Vek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7 m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HT CIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNM MbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7 DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPN mJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKa kDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i 0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+W kDGCAsowggLGAgEBMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwDQYJYIZIAWUD BAIBBQCgggFBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDEw ODEyMzAzM1owLwYJKoZIhvcNAQkEMSIEIE074lekPvIvkH7MoabBlak98pFLl53gq3GcCnDH1gx7 MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwawYLKoZI hvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEB AQUABIIBAA4glv2Zj80TxYJKDaXyF0SgxMC/umCyer4zBLuSItF6IlJcAVqiicFhetBxPsqJJTqh s83PSWIUK3SkB9iiaFUt9By5mwmZ2RD8tmS3hixO130udbDR0RJrO2Q5bOTeqN8DhDREsHLOt+10 Viw2/N0MbGE/g23ggwE05xg+9NVMuMYLDTsEsNnpVVBiZnlEDMzN0IqAQiaN/3yDko5S+dKOya/w 6SPxFV4NMNKKEYK7lEeH4KBEz6t86/n00Ka7qGMF/gllIE9D3LYjfNqpU8gaTWBpPzmrDA2jDbqf 8GldDq6+ctBYkOtD9sog6+zWAEkQKlS2OmCENTiGCfygufEAAAAAAAA= --=-jXMWW1XVZntAf+jNIS+t-- From nobody Fri Jan 8 05:33:44 2021 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 1EB7B3A0E88 for ; Fri, 8 Jan 2021 05:33:39 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 EH8hANhvD5k3 for ; Fri, 8 Jan 2021 05:33:35 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3C7B83A0E8A for ; Fri, 8 Jan 2021 05:33:34 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kxrtR-0003h2-G2; Fri, 08 Jan 2021 13:33:29 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> In-Reply-To: Date: Fri, 8 Jan 2021 13:33:42 -0000 Message-ID: <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxqLCg4/A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 13:33:39 -0000 Hi Marco, Thanks for this - and it is good to have another set of eyes checking = things through. Updates have been pushed to https://github.com/core-wg/new-block and the = differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt=20 Otherwise, please see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 07 January 2021 12:17 > To: supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi, >=20 > Thanks for this revision and for addressing my comments already in > version -03. >=20 > Please, see below some more comments on this version -04. >=20 > Best, > /Marco >=20 >=20 > * s/There are one or more missing CBOR encoded missing block > numbers./There are one or more CBOR encoded missing block numbers. [Jon] Fixed. >=20 >=20 > * Section 4 now includes the new paragraph: "The token to use for the > response SHOULD be the token that was used in the highest block number > received payload. The Q-Block1 Option from the same packet SHOULD be > included." [Jon] The Q-Block1 option actually is not needed as it can be derived by = the client from the remembered token (which is used to derive the = Request-Tag. OLD The Q-Block1 Option from the same packet SHOULD be included. NEW The client will use the token to match the request to find what = Request-Tag value is currently being used. Providing the highest received block number will aid any troubleshooting. >=20 > Consistently, the example in Figure 5 should also have QB1:3/0/1024 = in the > 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 response > with Token T:0xe4. [Jon] No change now needed. >=20 > Since "SHOULD" is used, when is it still fine or expected to not = include Q- > Block1 in a 4.08 response? [Jon] Q-Block1 is no longer needed. >=20 >=20 > * When commenting the example in Figure 5, Section 9.1 reads: "The = Token > just needs to be one of those that have been received for this = Request-Tag, > so the client can derive the Request-Tag." >=20 > Should this not be aligned with the SHOULD used in Section 4 about = using > the Token from the same packet conveying the highest block number? [Jon] Agreed >=20 > You explained in your mail that the client keeps tracking all = Tokens in the > burst anyway, so maybe it's better to rather align the text in Section = 4 with > what suggested here in Section 9.1, i.e. responding with any of those = Token > values is just fine. [Jon] I think that it is useful for the client to have a hint about what = is the latest block number received even if it does not make use it - it = may help in debugging from packet captures etc. which is why I added in = the SHOULD in section 4. So, I would prefer to align this with section = 4 OLD The Token just needs to be one of those that have been received for this Request-Tag, so the client can derive the Request-Tag. NEW The token used in the response should be the token that was used in the = highest block number received payload. The client can then derive the = Request-Tag by matching the token with the sent request.. >=20 > In such a case, the Q-Block1 option included in the 4.08 response = has still > to be the one from the request conveying the highest block number. > Correct? [Jon] We are now dropping the need for Q-Block1 in the response. >=20 >=20 > * The new text in Section 6.2 says: "... and the situation = re-evaluated for > another 24 hour period until there is no report of missing payloads = under > normal operating conditions." >=20 > When that happens, I suppose MAX_PAYLOADS is right away restored to > the intended value, i.e. it is not incremented by 1 to start another = 24-hour > period evaluation. Correct? [Jon] Updated for clarification OLD report of missing payloads under normal operating conditions. = Note that the CoAP peer will not know about the MAX_PAYLOADS change = until NEW report of missing payloads under normal operating conditions. = The newly derived value for MAX_PAYLOADS should be used for both ends of = this particular CoAP peer link. Note that the CoAP peer will not know about the MAX_PAYLOADS change = until >=20 >=20 > * Section 6.2 says: "The request that the client sends to acknowledge = the > receipt of all the current set of MAX_PAYLOADS payloads SHOULD contain = a > special case Q-Block2 Option with NUM set to the first block of the = next set > of MAX_PAYLOADS payloads and the M bit set to 1." >=20 > Is it possible to reflect this in the example of Figure 6? It would = require the > body to have more than MAX_PAYLOADS blocks thus resulting in more > bursts, which would be inherited by the examples in Figure 7 and = Figure 8. [Jon] Examples updated to include this information >=20 >=20 > * In Section 9, it would be good to have the parameters defined in = Section > 6.2 and their values reflected in the examples, when applicable. > E.g., MAX_PAYLOADS is at least 4 in these examples; the asked > retransmissions are presumably due sometimes to MAX_PAYLOADS > compared against the value of the latest received Q-Block1/Q-Block2, = while > sometimes to NON_RECEIVE_TIMEOUT. [Jon] Examples updated to include this information >=20 >=20 > * In the example in Figure 6, shouldn't the first request from the = client have > the M bit set to 1 in the Q-Block2 option, i.e. as > QB2:0/1/1024 ? As per Section 3.4, that would indicate that the = request is in > fact for the block 0 and for all of the remaining blocks within the = body. =20 [Jon] Good catch - corrected. ~Jon >=20 > On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > > Hi Christian, > > > > Once again, thank you for the comprehensive review. > > > > Responses part 2. A new version (-04) of the draft has been = published > > and can be found at > > > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdata > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- > block%2F&data=3D04%7C01 > > > %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 > 9cf0 > > > bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown > %7CTWFpb > > > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0 > > > %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j > gTY%3D&am > > p;reserved=3D0 > > > > > > Part 1 responses were covered in the main by version -03, so you may > > want to look at the -02 to -04 differences. > > > > The Congestion Control section has been re-written to simplify how > > things work and has a new set of definitions. There is a separation = of > > Confirmable and Non-Confirmable Congestion Control with the stated > > assumption that all of a body is sent as Non-Confirmable or = Confirmable. > > > > Otherwise, see inline. > > > > Regards > > > > Jon > > > >> * The list of pros and cons (with the cons being almost trivial) = does > >> not explain to the reader why these are not a replacement; I = suggest > >> to add: > > [Jon] Another disadvantage addition > > NEW > > To reduce the transmission times for CON transmission of large = bodies, > > NSTART needs to be increased from 1, but this affects congestion > > control where other parameters need to be tuned (Section 4.7 of > > [RFC7252]). Such tuning is out of scope of this document. > > > >> * "If the client transmits a new body of data with a new = Request-Tag > >> to": Processing parallel requests is something Request-Tag opens = up. I > >> don't see why there's a MUST to that; the server certainly MAY = drop > >> the old request, but it may just as well process them in = parallel. > > [Jon] The intent here was that garbage collection would take place > > sooner than later - especially when running in a lossy environment = and > > the client has updated information to transmit. I agree that > > Request-Tag enables the possibility of sending multiple block = requests > > with different payloads, and so there is a possibility that the = client > > starts sending body A, then decides to send body B and terminate A, > > but a packet from B arrives before a packet from body A is received = and so > things fail as A does not complete. > > > > OLD > > If the client transmits a new body of data with a new Request-Tag = to > > the same resource on a server, the server MUST remove any = partially > > received body held for a previous Request-Tag for that resource. > > NEW > > If a server receives payloads with different Request-Tags for the > > same resource, it should continue to process all the bodies as it = has > > no way of determining which is the latest version, or which body, if > > any, the client is terminating the transmission for. > > > > If the client elects to stop the transmission of a complete body, = it > > SHOULD "forget" all tracked tokens associated with the body's > > Request-Tag so that a reset message is generated for the invalid > > token in the 4.08 (Request Entity Incomplete) response. The server > > on receipt of the reset message SHOULD delete the partial body. > > END > > > >> * "If the server receives a duplicate block with the same = Request-Tag": > >> Why? Being silent is the default on nonterminal blocks alredy, = but in > >> a situation like figure 5 if the 2.04 is lost, that rule would = make > >> it impossible for the client to ever get a successful response. > >> > >> A better rule here may be to say that it processes it all the = same > >> (and if the payload is distinct from the first transmission's = payload, > >> it should err out.) > > [Jon] Fair point > > OLD > > If the server receives a duplicate block with the same = Request-Tag, > > it SHOULD silently ignore the packet. > > NEW > > If the server receives a duplicate block with the same = Request-Tag, > > it SHOULD ignore the payload of the packet, but MUST still = respond > > as if the block was received for the first time. > >> * "If the server receives multiple requests (implied or otherwise) = for > >> the same block, it MUST only send back one instance of that = block.": > >> This might be read as "ever" rather than "per incoming request", = where > >> probably the latter is meant. > > [Jon] This text has already been updated following another review = "OLD > > If the server receives multiple requests > > (implied or otherwise) for the same block, it MUST only send back = one > > instance of that block. > > NEW > > If the request includes multiple Q-Block2 > > Options and these options overlap (e.g., combination of M being = set > > (this and all the later blocks) and being unset (this individual > > block)) resulting in an individual block being requested multiple > > times, the server MUST only send back one instance of that block. > > This behavior is meant to prevent amplification attacks." > > > >> * "The ETag Option MUST NOT be used": This is more a factural than = a > >> normative statement; it *can* not be used there as the server = would > >> respond thusly. It may be used, but then that indicates that the > >> client is trying to verify a freshness. (However, the client = should > >> not *start* sending an ETag once it learned the current = resource's > >> ETag when still attempting to pull out more blocks, but that's = also not > >> a normative requirement but a consequence of those two requests = not > >> being matchable any more.) > > [Jon] OK > > OLD > > The ETag Option MUST NOT be used in the request as the server = could > > respond with a 2.03 (Valid Response) with no payload. If the = server > > responds with a different ETag Option value (as the resource > > representation has changed), then the client SHOULD drop all the > > payloads for the current body that are no longer valid. > > NEW > > The ETag Option should not be used in the request for missing > > blocks as the server could respond with a 2.03 (Valid Response) with > > no payload. It can be used in the request if the client wants to = check > > the freshness of the currently cached body response. > > > > If the server detects part way through a body transfer that the > > resource data has changed and the server is not maintaining a cached > > copy of the old data, then the body response SHOULD be restarted = with > > a different ETag Option value. Any subsequent missing block requests > > MUST respond using the latest ETag Option value. > > > > If the server responds during a body update with a different ETag > > Option value (as the resource representation has changed), then the > > client should treat the partial body with the old ETag as no longer = being > fresh. > > END > >> * "then the client SHOULD drop all the payloads for the current = body": > >> "Drop" is overly prescriptive; the client may well keep them, but > >> just can't consider them fresh any more. (If the client has ample > >> caching abilities, they might come in handy if the resource goes = back > >> to that ETag state). Same for later "the client MUST remove any > >> partially received". > > [Jon] See previous response, otherwise OLD > > If the server transmits a new body of data (e.g., a triggered > > Observe) with a new ETag to the same client as an additional > > response, the client MUST remove any partially received body held = for > > a previous ETag. > > NEW > > If the server transmits a new body of data (e.g., a triggered > > Observe) with a new ETag to the same client as an additional > > response, the client should remove any partially received body = held for > > a previous ETag for that resource as it is unlikely the missing > > blocks can be retrieved. > >> * "For Confirmable transmission, the client SHOULD continue to": As > >> above in the other direction, that's not news. > > [Jon] Again, we are not looking for a response (well, a request in > > this case as needed by Block2), just an ACK OLD > > For Confirmable transmission, the client SHOULD continue to > > acknowledge each packet as well as issuing a separate GET, POST, = PUT, > > FETCH, PATCH, or iPATCH for the missing blocks. > > NEW > > For Confirmable transmission, the server continues to acknowledge >=20 > > each packet, but a response is not required (whether separate or > > piggybacked) until successful receipt of the body or, if some of = the > > payloads are sent as Non-confirmable and have not arrived, a > > retransmit missing payloads response is needed. > >> * "If there is insufficient space to create a response PDU": I = don't > >> understand what that means. (Where are request options reflected > >> back?). > > [Jon] This was triggered by a question by Michael Richardson " So, > > given a Christmas-Tree-Packet (largest packet, every possible option > > space used, every extension turned on...) how much data can I get > > back? :-)" and not fully thought through. > > It could happen though with Location-Path, Location-Query, Q-Block2, > > ETag, > > Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in > > response to a POST. > > OLD > > If there is insufficient space to create a response PDU with a = block > > size of 16 bytes (SZX =3D 0) to reflect back all the request = options as > > appropriate, a 4.13 (Request Entity Too Large) is returned = without > > the Size2 Option. > > NEW > > If there is insufficient space to create a response PDU with a = block > > size of 16 bytes (SZX =3D 0) to send back all the response = options as > > appropriate, a 4.13 (Request Entity Too Large) is returned = without > > the Size1 Option. > > > >> * "If the client requests missing blocks, this is treated as a new > >> request.": I don't think the client should even make these = follow-up > >> requests Observe, as it already has an ongoing observation. = They'd be > >> sent on a different token too, so setting Observe would be = opening > >> observation up on that token, which AFAIU is not intended. = (Figure 7 > >> example looks good to me in that respect.) > >> > >> (It may make sense to ask the client to keep Observe to make the > >> requests matchable just for the sake of staying in = atomic-request > >> mode. Either way, the server should then not accept that = observation > >> as it's not for a block 0.) > > [Jon] The intent here was that just a new Token should be used. > > OLD > > If the client requests missing blocks, this is treated as a new > > request. The Observe value may change but MUST still be = reported. > > If the ETag value changes then the previously received partial = body > > should be destroyed and the whole body re-requested. > > NEW > > If the client requests missing blocks, this is treated as a new > > Request and the Observe Option MUST NOT be included. If the = ETag > value > > changes, then the previously received partial body > > should be considered as not fresh and the whole body = re-requested. > > > >> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can = be > >> matched by the token to a unique request that already had a > >> Request-Tag, and the client needs to have kept that token around > >> matched to the transfer to make sense of it. > >> > >> No need to move that value around between subsystems, and just > >> dropping it from here would also remove the need for the "If the > >> client does not recognize the Request-Tag" clause (which would > >> otherwise need clarification as to what it'd mean if it = recognizes it > >> but it doesn't match what the request was for). > > [Jon] Good question - it does make sense for the Request-Tag to be > > tracked alongside the Token in the client. > > OLD > > The data payload of the 4.08 (Request Entity Incomplete) Response > > Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR = encoded > > Request-Tag followed by 1 or more missing CBOR encoded missing = block > > numbers. > > NEW > > The data payload of the 4.08 (Request Entity Incomplete) response > > is encoded as a CBOR Sequence [RFC8742]. There are one or more > missing > > CBOR encoded missing block numbers. > > > > OLD > > ; This defines an array, the elements of which are to be used > > ; in a CBOR Sequence: > > payload =3D [request-tag, + missing-block-number] > > request-tag =3D bstr > > ; A unique block number not received: > > missing-block-number =3D uint > > NEW > > ; This defines an array, the elements of which are to be used > > ; in a CBOR Sequence: > > payload =3D [+ missing-block-number] > > request-tag =3D bstr > > ; A unique block number not received: > > missing-block-number =3D uint > > > > OLD > > A 4.08 (Request Entity Incomplete) Response Code returned with > > Content-Type "application/missing-blocks+cbor-seq" indicates that > > some of the payloads are missing and need to be resent. The = client > > then re-transmits the missing payloads using the Request-Tag and > > Q-Block1 to specify the block number, SZX, and M bit as = appropriate. > > The Request-Tag value to use is determined from the payload of = the > > 4.08 (Request Entity Incomplete) Response Code. If the client = does > > not recognize the Request-Tag, the client can ignore this = response. > > NEW (option presentation has been reformatted) > > 4.08 (Request Entity Incomplete) > > > > This Response Code returned with Content-Type "application/ > > missing-blocks+cbor-seq" indicates that some of the payloads are > > missing and need to be resent. The client then retransmits the > > missing payloads using the same Request-Tag, Size1 and Q-Block1 to >=20 > > specify the block number, SZX, and M bit as appropriate. > > > > > > The Request-Tag value to use is determined from the token in the > > 4.08 (Request Entity Incomplete) response and then finding the > > matching client request which contains the Request-Tag that is > > being used for this Q-Block1 body. END > >> * "limit the array count to 23 (Undefined value)": 23 is the = maximum > >> length of a zero-byte length indication, not indefinite-length = (31). > >> Both using 23 and 31 here makes sense (up to 23 to have definite > >> length that can be updated in-place, or exceeding that switch to > >> indefinite length if they still fit), but the paragraph seems to = be > >> mixing them up. > > [Jon] OK > > OLD > > Arrays (Section 3.2.2 of [RFC8949]), limit the array count to = 23 > > (Undefined value) so that the array data byte can be updated = with > > the overall length once the payload length is confirmed or = limited > > to MAX_PAYLOADS count. > > NEW > > Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit = the > > array count to > > 23 so that the initial byte with the array major type and data > > length in the additional information can be updated with the overall > > count once the payload count is confirmed. Further restricting the > > count to MAX_PAYLOADS means that congestion control is less likely = to be > invoked on the server. > > > >> * "Each new request MUST use a unique token": Like above, this is > >> stating something that's not intended to be changed. > > [Jon] RFC7252 does not require Tokens to be unique - e.g. empty = token > > values are acceptable. Hence this statement. > >> Congestion Control: > >> > >> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is > subjected > >> to PROBING_RATE.": That is unexpected here. At most one such > >> response is sent to each request message, so why is additional > >> congestion control needed? > > [Jon] The intention here was that in the previous paragraph that it > > was not the individual packets that are subject to PROBING_RATE, but = a > > single body comprising of multiple packets is subject to = PROBRING_RATE > > - and hence limiting any individual responses to PROBING_RATE rather > > than the potentially full set of responses OLD > > PROBING_RATE parameter in CoAP indicates the average data rate = that > > must not be exceeded by a CoAP endpoint in sending to a peer = endpoint > > that does not respond. The body of blocks will be subjected to > > PROBING_RATE (Section 4.7 of [RFC7252]). > > NEW > > PROBING_RATE parameter in CoAP indicates the average data rate = that > > must not be exceeded by a CoAP endpoint in sending to a peer = endpoint > > that does not respond. The single body of blocks will be = subjected to > > PROBING_RATE (Section 4.7 of [RFC7252]), not the individual = packets. > > If the wait time between sending bodies that are not being > > responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, > then the > > gap time is limited to NON_PROBING_WAIT. > > > > Note: For the particular DOTS application, PROBING_RATE and other > > transmission parameters are negotiated between peers. Even when >=20 > > not negotiated, the DOTS application uses customized defaults as > > discussed in Section 4.5.2 of [RFC8782]. > > END > >> On the other hand, *ever* NON request is subject to = PROBING_RATE, so > >> why point out the body of blocks and "GET or similar" = particularly? > > [Jon] It is only GET or FETCH. The intention here is to not request > > bodies of data at too high a rate. > > OLD > > Each NON GET or similar request using Q-Block2 Option is = subjected to > > PROBING_RATE. > > NEW > > Each NON GET or FETCH request using Q-Block2 Option is subjected = to > > PROBING_RATE. > >> * "a delay is introduced of ACK_TIMEOUT": As I understand > MAX_PAYLOADS, > >> this is (rather implicitly) introduced as the package count up to > >> which it is OK to exceed PROBING_RATE temporarily (but after that = it > >> kicks in all the harder by requiring to wait until = complete-sent-bytes > >> over PROBING_RATE has expired). If that holds, at that time a = much > >> larger delay than just ACK_TIMEOUT is needed to get a response = from > >> the server: About 3 hours (see later note on parameters). > > [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write = of > > Congestion Control section. > >> This is the crucial point in the document, and for it a = recommendation > >> alone is not good enough. The protocol can be run with a vastly > >> increased PROBING_RATE (however externally determined) and from > the > >> point of MAX_PAYLOADS just observe it. Or it has to get feedback = from > >> the server; a single 4.08 is probably enough to kick off another > >> vollley of blocks. (How many? MAX_PAYLOADS for every response?). > >> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing = any > >> good. > > [Jon] See re-write of Congestion Control section where things should > > now be simpler and more logical. There is an introduction of new > > variable definitions. > >> * "For NON transmissions": This seems to imply that the full = exchange of > >> a body is either NON or CON; I don't see where that'd come from. = I'd > >> have expected to read something like "Each individual request can = be > >> NON or CON independent of the others. In particular, it can be > >> convenient to send the ultimate payload...". > > [Jon]The DOTS environment will only be using NON. To make = Congestion > > Control simple, the expectation is that all transmissions are NON or > > (not recommended) are all CON. The draft now generally records this > > expectation. > >> * "If a Confirmable packet is used, then the transmitting peer MUST = wait > >> for the ACK": Why? A NSTART > 1 would give it leisure to still > >> transmit. > > [Jon] Text has been removed in the clean-up. > >> * General on congestion control: It may help implementors if this = were > >> split up into newly introduced rules and concepts (that is, > >> MAX_PAYLOADS and the answer to whether you may send > MAX_PAYLOADS en > >> block again after having only even one response from the last = round, > >> and probably the recommended parameters of the "Also on > parameters" > >> comment), and another subsection on how Q-Block behaves well when > >> observing these. > > [Jon] Should now be covered in the updated Congestion Control = section. > >> Caching: > >> > >> * "are not part of the cache key": How about "are removed as part = of the > >> block assembly and thus do not reach the cache"? > > [Jon] OK. > > OLD > > As the entire body is being cached in the proxy, the Q-Block1 and > > Q-Block2 Options are not part of the cache key. > > NEW > > As the entire body is being cached in the proxy, the Q-Block1 and > > Q-Block2 Options are removed as part of the block assembly and = thus > > do not reach the cache. > >> * "When the next client completes building the body": If the proxy > >> chooses not to let them happen in parallel (which it may, see = above on > >> parallel requests, although the server might still not support it = and > >> cancel one of them), why bother letting the first finish just to = abort > >> it? (IOW: If the proxy does not intend to see both through, which = it > >> could if it held back the second until the first is through on = the > >> uplink, it could just as well err out of one of them early, but = it may > >> also rather see both through.) > > [Jon] It has to be assumed that traffic to/from the origin client = and > > origin server may not both support Q-Blockx and potentially may have = a > > different SZX. Thus passing a request or a response through at the > > block level introduces a new set of challenges (but not impossible = to > > fix). To keep this simple, my thinking was that the passing through > > can only take place at the body level. Again, the arrival of = packets > > is not necessarily sequential, so client A's body may start > > transmitting to the origin server first, but client B's body starts = to > > arrive first - the same being true for the proxy as a client may = stop > > transmitting for whatever reason (restart, network loss etc.). > > However this is covered by the above update " If a server receives > > payloads with different Request-Tags for the same resource, it = should > continue to process all the bodies". > > > > OLD > > and the new body representation transmission starts with a new > > Request-Tag value. > > NEW > > and the new body representation transmission starts with a new > > Request-Tag value. Note that it cannot be assumed that the proxy > > will always receive a complete body from a client. > >> * Examples: > >> > >> * Figure 5: The ... between e3 request and response indicate the > >> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose > there > >> should be the same kind of delay between the failed e5 = transmission > >> and the e4 response. > > [Jon] Agreed and added in > >> * If the second burst had 3 requests out of which 2 made it, is = there > >> any guidance for which of them the 4.08 would come back on? (In = the > >> end, none of them is terminal). > > [Jon] The client should tracking all Tokens of the burst (hence > > implementation note about bottom 32bits unique and top 32 bits > > matching block number for ease of tracking) for a response and so it > > will make no difference at to which token is used for the 4.08 > > response. From an implementation perspective, it probably is easier > > to track the last opaque token that has the same Request-Tag. > > OLD > > missing ones in one go (Figure 5). It does so by indicating = which > > blocks have been received in the data portion of the response. > > NEW > > missing ones in one go (Figure 5). It does so by indicating = which > > blocks have been received in the data portion of the response. = The > > Token just needs to be one of those that have been received for this > > Request-Tag , so the client can derive the Request-Tag. > >> * If that e4 response gets lost, does the whole mechanism recover = from > >> it in any way? > > [Jon] In this example, if e4 and e5 get lost, there will be no > > 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to > > whether it sends the request again or gives up. See 9.1 > > "Under high levels of traffic loss, the client can elect not to = retry > > sending missing blocks of data. This decision is implementation > > specific." > >> Generally, the all-NON and all-CON examples don't look to me = like > >> what I'd be doing with this spec; the mixed "a CON every > >> MAX_PAYLOADS" appears much more realistic. > > [Jon] It is unsafe to use CON in the (potentially lossy) DOTS > > environment (up to 93 secs timeout per payload with the defaults). > > Hence why we are separating out the NON / CON usage. > >> * Figure X: The request ahs M unset and thus indicats a request = for > >> just that block. If more than one is expected, it should say > >> QB2:0/1/1024. > > [Jon] With Figure 7, with the M bit set, block 3 would get returned > > for a second time. Draft-ietf-core-new-block-03 also has a Figure 8 > > which does exactly what you describe. > >> * New Content Format: I think this needs a media type registration = to go > >> with it first; based on that, a content format can be registered. > > [Jon] Med has responded to this and draft updated. > >> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not > >> sure > >> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is > defined > >> in terms of reliable transmission, but used for NONs as well. (So = is > >> the alternative ot 2x ACK_TIMEOUT). > > [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT > in > > a NON environment. Hence re-write of Congestion Control section > > defining new variables that can be used for NON. > >> For the purpose of delaying a 4.08 or a follow-up GET, it may = make > >> more sense to define a new parameter based on MAX_LATENCY and the > >> time > >> it takes the sender to pump out the options (which I don't think = we > >> have a good factor for, but may even be negligible here). > >> > >> Could read like this: > >> > >> > The timing parameter MAX_BLOCK_JITTER is introduced, and by > default > >> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / > BANDWIDTH. > > [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, > > MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > > > > [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. > > So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps > > makes MAX_BLOCK_JITTER 200 seconds. > >> > > >> > With Q-Block2, a client can ask for any missing blocks after = not > >> > having received any further response for the duration of > >> > MAX_BLOCK_JITTER. > > [Jon] 100+ seconds delay is way too much time to wait for any = missing > > blocks in my opinion. > > > > [Jon] RFC7252 also states (and the intention is that recovery works > > well) " as MAX_LATENCY is not > > intended to describe a situation when the protocol works well, = but > > the worst-case situation against which the protocol has to = guard." > >> > > >> > With Q-Block1, a server holds off any response for = MAX_BLOCK_JITTER > >> > unless all blocks have been received. Only then it evaluates = whether > >> > to respond with a 2.0x code, a 4.08 with payload, or not at all > >> > (because it responded to a later request). > > [Jon] I am not convinced that this is necessarily the way to go. = The > > new Congestion Control more cleanly handles this. > >> This also brings me back to the earlier matter of 2.31: What is a > >> server supposed to send when no packages were lost, but it's = pasing > >> the timeout and wants to help the client flush out more packages = by > >> confirming something? It says 4.08 in 3.3, but it's not like = there's a > >> hole in the contiguous range. Does it need to send 4.08 = enumerating > >> all (or at least some) numbers between the first unreceived and = what's > >> indicated by Size1? Or can it just send 2.31 and the client knows = all > >> it needs to know b/c the response came to the largest block that = was > >> sent and 2.31 indicates that everything is good up to that point? > > [Jon] The previous draft states (under Congestion Control) that the > > client waits for ACK_TIMEOUT before transmitting the next set of > > MAX_PAYLOADS blocks. The server should wait for "two times > > ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps > > having a new name for ACK_TIMOUT I think that these are reasonable > > values for Non-Confirmable - and are used in the new Congestion = Control > section. > > > > [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a > > signal to say that all of the current MAX_PAYLOADS payloads of a = body > > have been received, so allowing the client to continue transmitting > > the next set of MAX_PAYLOADS payloads without the need to wait any > longer. > >> * Also on parameters: This document is describing flow control = stuff > >> around a situation CoAP was not originally designed for. Wouldn't = it > >> make sense to include a set of parameters (PROBING_RATE, > MAX_LATENCY, > >> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > >> PROBING_RATE will be left to 1 byte/second for any DOTS = application > >> using this (for sending 10KiB in the initial 10-package = MAX_PAYLOADS > >> burst would mark that connection as unusable for about 3 hours if = they > >> all get lost), so better give justifiable numbers here than rely = on > >> implemnetors to come up with unreviewed numbers or disregard > >> PROBING_RATE altogether. > > [Jon] Answered by Med, and some new text added. > >> I don't know if it needs additional justification, but an = increased > >> N_START may be justifiable there. > > [Jon] It may be, but tuning the other associated parameters is = really > > out of the cope of this draft. This text has been added NEW > > Congestion control for CON requests and responses is specified in > > Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will > > need to be increased from 1. However, the other CON congestion > > control parameters will need to be tuned to cover this change. = This >=20 > > tuning is out of scope of this document as it is expected that all > > requests and responses using Q-Block1 and Q-Block2 will be Non- > > confirmable. > >> * Somewhere (never comes up but I think it should): When CONs are > used, > >> a 4.08 (or 2.31?) response to a later request can indicate to the > >> client that an earlier CON request has been processed = successfully. If > >> the client can match that up (and it should be able to), then it = can > >> (and should) cancel that particular CON request. > > [Jon] I think that this is covered by my update above with the text = " > > NEW > > For Confirmable transmission, the server continues to acknowledge >=20 > > each packet, but a response is not required (whether separate or > > piggybacked) until successful receipt of the body or, if some of = the > > payloads are sent as Non-confirmable and have not arrived, a > > retransmit missing payloads response is needed." > > > > And in my previous part 1 response (updated) NEW > > For Confirmable transmission, the server continues to acknowledge > > each packet, but a response is not required (whether separate or > > piggybacked) until successful receipt of the body or, if some of = the > > payloads are sent as Non-confirmable and have not arrived, a > > retransmit missing payloads response is needed. > >> Best regards > >> Christian > >> > >> -- > >> There's always a bigger fish. > >> -- Qui-Gon Jinn > > _______________________________________________ > > core mailing list > > core@ietf.org > > > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w. > > > ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc > a%4 > > > 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 > ecc4 > > > 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 > eyJWIjoiMC > > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& > amp;sd > > > ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Fri Jan 8 07:58:10 2021 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 9D0B23A109F; Fri, 8 Jan 2021 07:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 IQXIbtvqseSP; Fri, 8 Jan 2021 07:57:58 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130043.outbound.protection.outlook.com [40.107.13.43]) (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 AAE1A3A121E; Fri, 8 Jan 2021 07:57:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T+/f8x+7GbvsC1QXShYxA/mCbAa4g/lfME9O+STx/mVRmAlaJ79NJWsFhD7qmHzGPGBra36UaxXtvCzoHwRpwHZVmyI3HwwE/laqJoC0ntUbL05RqOCH9WKS7fS1N52C1jEYd5L0c3gbG0V0dbulx/+6khqvmLiID5LpsZOmYsxysEhghtgh7Rgp6QX7hk+WCIg4WryHjKCMvzfBYeO3D2ERic7fMGqiglZ+E9IB0GqgR3cnb8g74gHHkxipLvDPwtXx+y0payMIQY0zI30eucQFsmUHszwep7LrfLfew7jsjkzAWvCCm48adNwt+amE616Zt2VBbFF1uxOx9fLfrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NnbJYLnuDk2llz+Z7iRcEdJ3K8lKHpbIPafgy48nZEQ=; b=oFtfhApBzmBMIklRW0xf2oX+7aKXZNeVqmCybYqe20WCSy0bDitcay2K0vevAfON80b6JAhRaTeGRIf/6CbJ96zsl9dwu4gpnA5hVdF7sj1uxrScV1Ho+l4NFTY4aXNBOj6t3EoIzoyZvf9oc0a3LJOB/RgcHCRZEo1ExiojXMt90N0E/CerZGO2rkjfkqIS8tOIEqz1pfFBYkd9OARM/G7AEJBPkx++l9Cjm83jlIF/uGye02iTTyqD5qqLfOmVOp+1ZAvxMeaEFz9jcTba8qRW40uHjkDkXfkBIoQOEAtuc3t/9NDY88OBHvB2Z/uL3JG1T+0MQ4irTECbM5odlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NnbJYLnuDk2llz+Z7iRcEdJ3K8lKHpbIPafgy48nZEQ=; b=fwmqD9v9S0eAPIKsR8gxiG0+T/d1Ll9lUwfua3cACvNpJ29Ra/5DGGg642N3b8AS7YRj1d4043qBHqvZ8NqgEt37aIU4LNe3EChF0+Kl9ANx9CesXBlr1XyFiXxEtDS+8+BWqd6qg6zyJyPK5+MxFYHbZ0CBrLnP3GNHnqMJGOU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0763.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Fri, 8 Jan 2021 15:57:31 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.010; Fri, 8 Jan 2021 15:57:31 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Fri, 8 Jan 2021 16:57:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ" X-Originating-IP: [37.120.209.204] X-ClientProxiedBy: HE1PR05CA0152.eurprd05.prod.outlook.com (2603:10a6:7:28::39) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.7] (37.120.209.204) by HE1PR05CA0152.eurprd05.prod.outlook.com (2603:10a6:7:28::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Fri, 8 Jan 2021 15:57:30 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7302a62d-5f80-4e3e-ce25-08d8b3ee1b1b X-MS-TrafficTypeDiagnostic: DB8P189MB0763: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JTpMaOkNmhWD1hdTHyTMAY4tYb7W0/wlCZBNZe/NxsKZWW+GXL8Dh7D+gIc/C91flfi1hk5ayjNv3MBKsJe0pceflqELqHqPCLrUcrSynvPWC0cQ0MpBR9Puiom/cn1Nbj4+qWTZM8ht0Cr7OAGaByKOW9jCa98wExbZrd6BtNQiSAHngXcr2HSqmsAMI8/2f80H8hLtiI+dt5JsVgUQ6PH4kf3yaAUAZbVQ8Uq3MN2s76cfgBxHGSOkHPxhRmZ1D7fAe9M+9CCTtDDB/FbafZo2QjYsEIur17nWbVuWfH50LMMiW5kBGkMWrkK2/utw2Giqmwo3xmQBIblV9QvuHJuFSCALiORGBZ87vt0PmPXBx7gR7B0zH3BGMsBiQyfbOnInil2Eua32Ngob8umRagwgfJPHLAqzIPUgAtNVwfH9sZdG1fCVVBIL2ow/bSWh4jUgorbUu1Yp5ePYWnvB+Y9t8fZ0mX+nqumg1btqnFqHAGnOv2hGj3HAw1EFuSpN+xFhxAxGSjI1Cf4w8CrkGHujSXSwkzFTbNaAoheCC6uzg48TibmTvZrIFmOUioQa X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39850400004)(136003)(376002)(366004)(396003)(2616005)(8676002)(86362001)(316002)(31686004)(956004)(52116002)(33964004)(2906002)(4326008)(8936002)(31696002)(45080400002)(16576012)(66946007)(966005)(66476007)(66556008)(30864003)(5660300002)(6486002)(53546011)(21480400003)(66574015)(36756003)(235185007)(478600001)(6666004)(44832011)(16526019)(186003)(83380400001)(26005)(45980500001)(43740500002)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?UW9JTXdCWVluUnhZajVQZmxVeXlPeTZETW5pSU1SemZySnloNjFBTVl3SmxI?= =?utf-8?B?ZEZhM0hsRXZ0Mm9WeE5YYzFpZW5mZGhaL1lrNERNbGs4VExMcXk5TUZlOGFH?= =?utf-8?B?YnRqWjgyUmFtNWVkR0F1Vk9pRUNpTnZ0amVxWkdWWTh5VWRSR0ZKUkdJRjlV?= =?utf-8?B?cStCbGpmdzMyaWptajBHRUc3RWdUWVp4bW5HNWlucDNHV01aSzNjVUNxaVlJ?= =?utf-8?B?emVkYnZ1Z3Y4bitLUWorL3lWYTE3NEtvU0JXdnFqWHVOV29zSm1GMXV6RWtp?= =?utf-8?B?bmJKV1VsRVJyTFRCeDJwZ1ZkbDB6MGNrbjIyRjhlZHdVMTJrVmhHM2dDU3Nt?= =?utf-8?B?SWFKSHNEVHdyY0tobFlvMGlIdGRMeXFKRW1za2FiNE9kR3FyaTNZVm4xWlFv?= =?utf-8?B?cU9mVjU5dUJqWGI1RnI3S3hKMHhqaUpra3lWZm8rTnZKL2h4SUpVQ3VSMnRR?= =?utf-8?B?VTBYeXNEUEZsWm8wUGx3WHFIMmRUdWxXWG0zZFQ1c0ZhL0MrOFZyeU1QUWxZ?= =?utf-8?B?cW5YM0h3cW1VVml4U0JjTFNYY3Q0Zy9yNHJRb05Mei9TeEtDQzVDMEFpMStx?= =?utf-8?B?VUozaStibjdTc1VoTHhnOEREODUrQUtpOUpnSzJNL3NOKzM1M1d3cys4STAv?= =?utf-8?B?OUlQc1B4L2xHWkJtUjQ5U1NLZklqWmFEbnMwaVJFSEZrMFRtQzhwN2lhYjV4?= =?utf-8?B?aWw3ZHVCUkRnTjJOeWNHS1Rua21KaDU5amVnZldpRi9pbk8yVVoxa3lRQVcz?= =?utf-8?B?anZXdnVwZFJZUlowaXlYbmZ2d3o4aUFKM3BVUk9EMHFjbElNN2J0eDRvMjM4?= =?utf-8?B?RXZxU0hBMFlrdEVtSUV2Y2RrdTdpcmF3R2kwUjNVOGdqQVF6WTczMGozTEp0?= =?utf-8?B?RmVJbFhHbTd5SE55NVNsOUNHVUJ2WHBHSE1IMUtEd1NtT2hUYnRZQ2s2VENE?= =?utf-8?B?bHlxbElLR1d5RTZIaGlLSHhnVGFVb0Q5SmpIVmtMeDQvTFNqU1ZLcmN6SEdm?= =?utf-8?B?MytSazh6SDNrSzJQMlVFTnFuMldGalg1L1pFRStrQUdMaHI4RFZPdm05UjhC?= =?utf-8?B?N1BRbGRTRjBrdVE5ZW1JMlBuWnFVT2JDZCs5eXFmUGg3ajdFN21kNWJ0eW5z?= =?utf-8?B?c3BnVTM3RTBIRStvMGIwQVdxTXdGTndHbU5BNHFvOFpRdEhQWDA2bVVRM1hP?= =?utf-8?B?NjhqTVVqN0pGTXJMclZHSlJvU3F2RU9oREJodGR6d0s1cDIwQ2E2aHNVMmhC?= =?utf-8?B?a1ZISGRFTGorRnhab2FWQm9MV05QamtJQmdmRnJXUExWWHlEbVN6eFRqQmJo?= =?utf-8?Q?KYDCEornwY1xJrV2s30kwHJv2Z1tyWVN53?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2021 15:57:30.9956 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 7302a62d-5f80-4e3e-ce25-08d8b3ee1b1b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WQdoTyAwAErHd78A0Tym5Cb1YcTLKTH+CaKqUJohEevQaYzd8yt0BWByQUAyXItAEp8eG/o4cgKIRTOz86IJnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0763 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 15:58:05 -0000 --bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ Content-Type: multipart/mixed; boundary="GFQ5741qHBUqJHRDRYN8yYKowe2dLM2NN" --GFQ5741qHBUqJHRDRYN8yYKowe2dLM2NN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks, the changes look good. Just a few minor things. * In Section 3.4, about the second case: =C2=A0 - s/can continue to sent/can continue to send =C2=A0 - It should be as explicit as in Section 6.2, i.e. "... 'NUM modul= o MAX_PAYLOADS' is zero, while NUM is not zero: ..." =C2=A0 - The word "current" can be misleading, if its relation with the v= alue of NUM in the Q-Block2 option is not clarified. Based on the new example in Figure 8, I think you mean the latest set completely transferred to the client, whose last block has block number (NUM - 1). A possible overall rephrasing can be: =C2=A0 =C2=A0 "This is used to confirm that the current set of MAX_PAYLOADS payl= oads (the latest one having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next set of payloads (the first one having block number NUM). This is the 'Continue' Q-Block-2." * In Section 3.4, about the third case: I guess you mean: "This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS set." * Section 4 says: "The token to use ... any troubleshooting." =C2=A0=C2=A0 Do you actually mean the highest block number received so fa= r under that Request-Tag, or the highest within the current set of MAX_PAYLOADS payloads for which the server is requesting some missing blocks? =C2=A0=C2=A0 =C2=A0=C2=A0 The new example in Section 5 seems to cover the latter, whic= h I guess is what you intend. =C2=A0=C2=A0 * In Section 9.2: =C2=A0 - Figure 7, the request should have the M bit set, i.e. QB2:0/1/10= 24 =C2=A0=C2=A0 =C2=A0 - Figure 8, the last response should have block number 10, i.e. QB2:10/0/1024 =C2=A0=C2=A0 =C2=A0 - Figure 10, all responses should have ET=3D24 Best, /Marco On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > Thanks for this - and it is good to have another set of eyes checking t= hings through. > > Updates have been pushed to https://eur02.safelinks.protection.outlook.= com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&data=3D04%7= C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0= bcb413a838a09ecc40cc9e8%7C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZs= b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 2000&sdata=3DLN79Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&res= erved=3D0 and the differences with the draft can be found at https://eur0= 2.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Frf= cdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githu= busercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-blo= ck.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81f608= d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63745709666645206= 9%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1= haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc2vkC1XGtyGb17WSmby%2FO9wzA2bMax= DUsl3jmOAL4%3D&reserved=3D0=20 > > Otherwise, please see inline. > > Regards > > Jon > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 07 January 2021 12:17 >> To: supjps-ietf@jpshallow.com; christian@amsuess.com; draft-ietf-core-= new- >> block@ietf.org >> Cc: dots@ietf.org; core@ietf.org >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >> >> Hi, >> >> Thanks for this revision and for addressing my comments already in >> version -03. >> >> Please, see below some more comments on this version -04. >> >> Best, >> /Marco >> >> >> * s/There are one or more missing CBOR encoded missing block >> numbers./There are one or more CBOR encoded missing block numbers. > [Jon] Fixed. >> >> * Section 4 now includes the new paragraph: "The token to use for the= >> response SHOULD be the token that was used in the highest block number= >> received payload. The Q-Block1 Option from the same packet SHOULD be >> included." > [Jon] The Q-Block1 option actually is not needed as it can be derived b= y the client from the remembered token (which is used to derive the Reque= st-Tag. > OLD > The Q-Block1 Option from the same packet SHOULD be included. > NEW > The client will use the token to match the request to find what Request= -Tag value is > currently being used. Providing the highest received block number > will aid any troubleshooting. > >> Consistently, the example in Figure 5 should also have QB1:3/0/1024= in the >> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 response= >> with Token T:0xe4. > [Jon] No change now needed. >> Since "SHOULD" is used, when is it still fine or expected to not in= clude Q- >> Block1 in a 4.08 response? > [Jon] Q-Block1 is no longer needed. >> >> * When commenting the example in Figure 5, Section 9.1 reads: "The Tok= en >> just needs to be one of those that have been received for this Request= -Tag, >> so the client can derive the Request-Tag." >> >> Should this not be aligned with the SHOULD used in Section 4 about = using >> the Token from the same packet conveying the highest block number? > [Jon] Agreed >> You explained in your mail that the client keeps tracking all Token= s in the >> burst anyway, so maybe it's better to rather align the text in Section= 4 with >> what suggested here in Section 9.1, i.e. responding with any of those = Token >> values is just fine. > [Jon] I think that it is useful for the client to have a hint about wha= t is the latest block number received even if it does not make use it - i= t may help in debugging from packet captures etc. which is why I added in= the SHOULD in section 4. So, I would prefer to align this with section = 4 > OLD > The Token just needs to be one of those that have been received for thi= s > Request-Tag, so the client can derive the Request-Tag. > NEW > The token used in the response should be the token that was used in the= highest block number received payload. The client can then derive the Re= quest-Tag by matching the token with the sent request.. > >> In such a case, the Q-Block1 option included in the 4.08 response h= as still >> to be the one from the request conveying the highest block number. >> Correct? > [Jon] We are now dropping the need for Q-Block1 in the response. >> >> * The new text in Section 6.2 says: "... and the situation re-evaluate= d for >> another 24 hour period until there is no report of missing payloads un= der >> normal operating conditions." >> >> When that happens, I suppose MAX_PAYLOADS is right away restored to= >> the intended value, i.e. it is not incremented by 1 to start another 2= 4-hour >> period evaluation. Correct? > [Jon] Updated for clarification > OLD > report of missing payloads under normal operating conditions. N= ote > that the CoAP peer will not know about the MAX_PAYLOADS change = until > NEW > report of missing payloads under normal operating conditions. T= he newly > derived value for MAX_PAYLOADS should be used for both ends of = this > particular CoAP peer link. Note > that the CoAP peer will not know about the MAX_PAYLOADS change = until >> >> * Section 6.2 says: "The request that the client sends to acknowledge = the >> receipt of all the current set of MAX_PAYLOADS payloads SHOULD contain= a >> special case Q-Block2 Option with NUM set to the first block of the ne= xt set >> of MAX_PAYLOADS payloads and the M bit set to 1." >> >> Is it possible to reflect this in the example of Figure 6? It would = require the >> body to have more than MAX_PAYLOADS blocks thus resulting in more >> bursts, which would be inherited by the examples in Figure 7 and Figur= e 8. > [Jon] Examples updated to include this information >> >> * In Section 9, it would be good to have the parameters defined in Sec= tion >> 6.2 and their values reflected in the examples, when applicable. >> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked >> retransmissions are presumably due sometimes to MAX_PAYLOADS >> compared against the value of the latest received Q-Block1/Q-Block2, w= hile >> sometimes to NON_RECEIVE_TIMEOUT. > [Jon] Examples updated to include this information >> >> * In the example in Figure 6, shouldn't the first request from the cli= ent have >> the M bit set to 1 in the Q-Block2 option, i.e. as >> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the reques= t is in >> fact for the block 0 and for all of the remaining blocks within the bo= dy. > =20 > [Jon] Good catch - corrected. > > ~Jon >> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: >>> Hi Christian, >>> >>> Once again, thank you for the comprehensive review. >>> >>> Responses part 2. A new version (-04) of the draft has been publishe= d >>> and can be found at >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= ta >>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- >> block%2F&data=3D04%7C01 >> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 >> 9cf0 >> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown >> %7CTWFpb >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >> 6Mn0 >> %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j >> gTY%3D&am >>> p;reserved=3D0 >>> >>> >>> Part 1 responses were covered in the main by version -03, so you may >>> want to look at the -02 to -04 differences. >>> >>> The Congestion Control section has been re-written to simplify how >>> things work and has a new set of definitions. There is a separation o= f >>> Confirmable and Non-Confirmable Congestion Control with the stated >>> assumption that all of a body is sent as Non-Confirmable or Confirmab= le. >>> >>> Otherwise, see inline. >>> >>> Regards >>> >>> Jon >>> >>>> * The list of pros and cons (with the cons being almost trivial) doe= s >>>> not explain to the reader why these are not a replacement; I sugge= st >>>> to add: >>> [Jon] Another disadvantage addition >>> NEW >>> To reduce the transmission times for CON transmission of large bodies= , >>> NSTART needs to be increased from 1, but this affects congestion >>> control where other parameters need to be tuned (Section 4.7 of >>> [RFC7252]). Such tuning is out of scope of this document. >>> >>>> * "If the client transmits a new body of data with a new Request-Tag= >>>> to": Processing parallel requests is something Request-Tag opens u= p. I >>>> don't see why there's a MUST to that; the server certainly MAY dro= p >>>> the old request, but it may just as well process them in parallel.= >>> [Jon] The intent here was that garbage collection would take place >>> sooner than later - especially when running in a lossy environment an= d >>> the client has updated information to transmit. I agree that >>> Request-Tag enables the possibility of sending multiple block request= s >>> with different payloads, and so there is a possibility that the clien= t >>> starts sending body A, then decides to send body B and terminate A, >>> but a packet from B arrives before a packet from body A is received a= nd so >> things fail as A does not complete. >>> OLD >>> If the client transmits a new body of data with a new Request-Tag = to >>> the same resource on a server, the server MUST remove any partiall= y >>> received body held for a previous Request-Tag for that resource. >>> NEW >>> If a server receives payloads with different Request-Tags for the >>> same resource, it should continue to process all the bodies as it has= >>> no way of determining which is the latest version, or which body, if >>> any, the client is terminating the transmission for. >>> >>> If the client elects to stop the transmission of a complete body, i= t >>> SHOULD "forget" all tracked tokens associated with the body's >>> Request-Tag so that a reset message is generated for the invalid >>> token in the 4.08 (Request Entity Incomplete) response. The server >>> on receipt of the reset message SHOULD delete the partial body. >>> END >>> >>>> * "If the server receives a duplicate block with the same Request-Ta= g": >>>> Why? Being silent is the default on nonterminal blocks alredy, but= in >>>> a situation like figure 5 if the 2.04 is lost, that rule would mak= e >>>> it impossible for the client to ever get a successful response. >>>> >>>> A better rule here may be to say that it processes it all the same= >>>> (and if the payload is distinct from the first transmission's payl= oad, >>>> it should err out.) >>> [Jon] Fair point >>> OLD >>> If the server receives a duplicate block with the same Request-Tag= , >>> it SHOULD silently ignore the packet. >>> NEW >>> If the server receives a duplicate block with the same Request-Tag= , >>> it SHOULD ignore the payload of the packet, but MUST still respon= d >>> as if the block was received for the first time. >>>> * "If the server receives multiple requests (implied or otherwise) f= or >>>> the same block, it MUST only send back one instance of that block.= ": >>>> This might be read as "ever" rather than "per incoming request", w= here >>>> probably the latter is meant. >>> [Jon] This text has already been updated following another review "OL= D >>> If the server receives multiple requests >>> (implied or otherwise) for the same block, it MUST only send back = one >>> instance of that block. >>> NEW >>> If the request includes multiple Q-Block2 >>> Options and these options overlap (e.g., combination of M being se= t >>> (this and all the later blocks) and being unset (this individual >>> block)) resulting in an individual block being requested multiple >>> times, the server MUST only send back one instance of that block. >>> This behavior is meant to prevent amplification attacks." >>> >>>> * "The ETag Option MUST NOT be used": This is more a factural than a= >>>> normative statement; it *can* not be used there as the server woul= d >>>> respond thusly. It may be used, but then that indicates that the >>>> client is trying to verify a freshness. (However, the client shoul= d >>>> not *start* sending an ETag once it learned the current resource's= >>>> ETag when still attempting to pull out more blocks, but that's als= o not >>>> a normative requirement but a consequence of those two requests no= t >>>> being matchable any more.) >>> [Jon] OK >>> OLD >>> The ETag Option MUST NOT be used in the request as the server coul= d >>> respond with a 2.03 (Valid Response) with no payload. If the serv= er >>> responds with a different ETag Option value (as the resource >>> representation has changed), then the client SHOULD drop all the >>> payloads for the current body that are no longer valid. >>> NEW >>> The ETag Option should not be used in the request for missing >>> blocks as the server could respond with a 2.03 (Valid Response) with >>> no payload. It can be used in the request if the client wants to chec= k >>> the freshness of the currently cached body response. >>> >>> If the server detects part way through a body transfer that the >>> resource data has changed and the server is not maintaining a cached >>> copy of the old data, then the body response SHOULD be restarted with= >>> a different ETag Option value. Any subsequent missing block requests >>> MUST respond using the latest ETag Option value. >>> >>> If the server responds during a body update with a different ETag >>> Option value (as the resource representation has changed), then the >>> client should treat the partial body with the old ETag as no longer b= eing >> fresh. >>> END >>>> * "then the client SHOULD drop all the payloads for the current body= ": >>>> "Drop" is overly prescriptive; the client may well keep them, but >>>> just can't consider them fresh any more. (If the client has ample >>>> caching abilities, they might come in handy if the resource goes b= ack >>>> to that ETag state). Same for later "the client MUST remove any >>>> partially received". >>> [Jon] See previous response, otherwise OLD >>> If the server transmits a new body of data (e.g., a triggered >>> Observe) with a new ETag to the same client as an additional >>> response, the client MUST remove any partially received body held = for >>> a previous ETag. >>> NEW >>> If the server transmits a new body of data (e.g., a triggered >>> Observe) with a new ETag to the same client as an additional >>> response, the client should remove any partially received body hel= d for >>> a previous ETag for that resource as it is unlikely the missing >>> blocks can be retrieved. >>>> * "For Confirmable transmission, the client SHOULD continue to": As >>>> above in the other direction, that's not news. >>> [Jon] Again, we are not looking for a response (well, a request in >>> this case as needed by Block2), just an ACK OLD >>> For Confirmable transmission, the client SHOULD continue to >>> acknowledge each packet as well as issuing a separate GET, POST, P= UT, >>> FETCH, PATCH, or iPATCH for the missing blocks. >>> NEW >>> For Confirmable transmission, the server continues to acknowledge >>> each packet, but a response is not required (whether separate or >>> piggybacked) until successful receipt of the body or, if some of th= e >>> payloads are sent as Non-confirmable and have not arrived, a >>> retransmit missing payloads response is needed. >>>> * "If there is insufficient space to create a response PDU": I don't= >>>> understand what that means. (Where are request options reflected >>>> back?). >>> [Jon] This was triggered by a question by Michael Richardson " So, >>> given a Christmas-Tree-Packet (largest packet, every possible option >>> space used, every extension turned on...) how much data can I get >>> back? :-)" and not fully thought through. >>> It could happen though with Location-Path, Location-Query, Q-Block2, >>> ETag, >>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in >>> response to a POST. >>> OLD >>> If there is insufficient space to create a response PDU with a blo= ck >>> size of 16 bytes (SZX =3D 0) to reflect back all the request optio= ns as >>> appropriate, a 4.13 (Request Entity Too Large) is returned without= >>> the Size2 Option. >>> NEW >>> If there is insufficient space to create a response PDU with a blo= ck >>> size of 16 bytes (SZX =3D 0) to send back all the response options= as >>> appropriate, a 4.13 (Request Entity Too Large) is returned without= >>> the Size1 Option. >>> >>>> * "If the client requests missing blocks, this is treated as a new >>>> request.": I don't think the client should even make these follow= -up >>>> requests Observe, as it already has an ongoing observation. They'= d be >>>> sent on a different token too, so setting Observe would be openin= g >>>> observation up on that token, which AFAIU is not intended. (Figur= e 7 >>>> example looks good to me in that respect.) >>>> >>>> (It may make sense to ask the client to keep Observe to make the >>>> requests matchable just for the sake of staying in atomic-request= >>>> mode. Either way, the server should then not accept that observat= ion >>>> as it's not for a block 0.) >>> [Jon] The intent here was that just a new Token should be used. >>> OLD >>> If the client requests missing blocks, this is treated as a new >>> request. The Observe value may change but MUST still be reported.= >>> If the ETag value changes then the previously received partial bod= y >>> should be destroyed and the whole body re-requested. >>> NEW >>> If the client requests missing blocks, this is treated as a new >>> Request and the Observe Option MUST NOT be included. If the ETag= >> value >>> changes, then the previously received partial body >>> should be considered as not fresh and the whole body re-requested.= >>> >>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can b= e >>>> matched by the token to a unique request that already had a >>>> Request-Tag, and the client needs to have kept that token around >>>> matched to the transfer to make sense of it. >>>> >>>> No need to move that value around between subsystems, and just >>>> dropping it from here would also remove the need for the "If the >>>> client does not recognize the Request-Tag" clause (which would >>>> otherwise need clarification as to what it'd mean if it recognizes= it >>>> but it doesn't match what the request was for). >>> [Jon] Good question - it does make sense for the Request-Tag to be >>> tracked alongside the Token in the client. >>> OLD >>> The data payload of the 4.08 (Request Entity Incomplete) Response >>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encod= ed >>> Request-Tag followed by 1 or more missing CBOR encoded missing blo= ck >>> numbers. >>> NEW >>> The data payload of the 4.08 (Request Entity Incomplete) response >>> is encoded as a CBOR Sequence [RFC8742]. There are one or more >> missing >>> CBOR encoded missing block numbers. >>> >>> OLD >>> ; This defines an array, the elements of which are to be used >>> ; in a CBOR Sequence: >>> payload =3D [request-tag, + missing-block-number] >>> request-tag =3D bstr >>> ; A unique block number not received: >>> missing-block-number =3D uint >>> NEW >>> ; This defines an array, the elements of which are to be used >>> ; in a CBOR Sequence: >>> payload =3D [+ missing-block-number] >>> request-tag =3D bstr >>> ; A unique block number not received: >>> missing-block-number =3D uint >>> >>> OLD >>> A 4.08 (Request Entity Incomplete) Response Code returned with >>> Content-Type "application/missing-blocks+cbor-seq" indicates that >>> some of the payloads are missing and need to be resent. The clien= t >>> then re-transmits the missing payloads using the Request-Tag and >>> Q-Block1 to specify the block number, SZX, and M bit as appropriat= e. >>> The Request-Tag value to use is determined from the payload of the= >>> 4.08 (Request Entity Incomplete) Response Code. If the client doe= s >>> not recognize the Request-Tag, the client can ignore this response= =2E >>> NEW (option presentation has been reformatted) >>> 4.08 (Request Entity Incomplete) >>> >>> This Response Code returned with Content-Type "application/ >>> missing-blocks+cbor-seq" indicates that some of the payloads are >>> missing and need to be resent. The client then retransmits the >>> missing payloads using the same Request-Tag, Size1 and Q-Block1 to >>> specify the block number, SZX, and M bit as appropriate. >>> >>> >>> The Request-Tag value to use is determined from the token in the >>> 4.08 (Request Entity Incomplete) response and then finding the >>> matching client request which contains the Request-Tag that is >>> being used for this Q-Block1 body. END >>>> * "limit the array count to 23 (Undefined value)": 23 is the maximum= >>>> length of a zero-byte length indication, not indefinite-length (31= ). >>>> Both using 23 and 31 here makes sense (up to 23 to have definite >>>> length that can be updated in-place, or exceeding that switch to >>>> indefinite length if they still fit), but the paragraph seems to b= e >>>> mixing them up. >>> [Jon] OK >>> OLD >>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 2= 3 >>> (Undefined value) so that the array data byte can be updated wi= th >>> the overall length once the payload length is confirmed or limi= ted >>> to MAX_PAYLOADS count. >>> NEW >>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the= >>> array count to >>> 23 so that the initial byte with the array major type and data >>> length in the additional information can be updated with the overall >>> count once the payload count is confirmed. Further restricting the >>> count to MAX_PAYLOADS means that congestion control is less likely to= be >> invoked on the server. >>>> * "Each new request MUST use a unique token": Like above, this is >>>> stating something that's not intended to be changed. >>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token= >>> values are acceptable. Hence this statement. >>>> Congestion Control: >>>> >>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is >> subjected >>>> to PROBING_RATE.": That is unexpected here. At most one such >>>> response is sent to each request message, so why is additional >>>> congestion control needed? >>> [Jon] The intention here was that in the previous paragraph that it >>> was not the individual packets that are subject to PROBING_RATE, but = a >>> single body comprising of multiple packets is subject to PROBRING_RAT= E >>> - and hence limiting any individual responses to PROBING_RATE rather >>> than the potentially full set of responses OLD >>> PROBING_RATE parameter in CoAP indicates the average data rate tha= t >>> must not be exceeded by a CoAP endpoint in sending to a peer endpo= int >>> that does not respond. The body of blocks will be subjected to >>> PROBING_RATE (Section 4.7 of [RFC7252]). >>> NEW >>> PROBING_RATE parameter in CoAP indicates the average data rate tha= t >>> must not be exceeded by a CoAP endpoint in sending to a peer endpo= int >>> that does not respond. The single body of blocks will be subjecte= d to >>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packet= s. >>> If the wait time between sending bodies that are not being >>> responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, >> then the >>> gap time is limited to NON_PROBING_WAIT. >>> >>> Note: For the particular DOTS application, PROBING_RATE and other >>> transmission parameters are negotiated between peers. Even when >>> not negotiated, the DOTS application uses customized defaults as >>> discussed in Section 4.5.2 of [RFC8782]. >>> END >>>> On the other hand, *ever* NON request is subject to PROBING_RATE,= so >>>> why point out the body of blocks and "GET or similar" particularl= y? >>> [Jon] It is only GET or FETCH. The intention here is to not request >>> bodies of data at too high a rate. >>> OLD >>> Each NON GET or similar request using Q-Block2 Option is subjected= to >>> PROBING_RATE. >>> NEW >>> Each NON GET or FETCH request using Q-Block2 Option is subjected t= o >>> PROBING_RATE. >>>> * "a delay is introduced of ACK_TIMEOUT": As I understand >> MAX_PAYLOADS, >>>> this is (rather implicitly) introduced as the package count up to >>>> which it is OK to exceed PROBING_RATE temporarily (but after that = it >>>> kicks in all the harder by requiring to wait until complete-sent-b= ytes >>>> over PROBING_RATE has expired). If that holds, at that time a much= >>>> larger delay than just ACK_TIMEOUT is needed to get a response fro= m >>>> the server: About 3 hours (see later note on parameters). >>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write of= >>> Congestion Control section. >>>> This is the crucial point in the document, and for it a recommenda= tion >>>> alone is not good enough. The protocol can be run with a vastly >>>> increased PROBING_RATE (however externally determined) and from >> the >>>> point of MAX_PAYLOADS just observe it. Or it has to get feedback f= rom >>>> the server; a single 4.08 is probably enough to kick off another >>>> vollley of blocks. (How many? MAX_PAYLOADS for every response?). >>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing an= y >>>> good. >>> [Jon] See re-write of Congestion Control section where things should >>> now be simpler and more logical. There is an introduction of new >>> variable definitions. >>>> * "For NON transmissions": This seems to imply that the full exchang= e of >>>> a body is either NON or CON; I don't see where that'd come from. I= 'd >>>> have expected to read something like "Each individual request can = be >>>> NON or CON independent of the others. In particular, it can be >>>> convenient to send the ultimate payload...". >>> [Jon]The DOTS environment will only be using NON. To make Congestion= >>> Control simple, the expectation is that all transmissions are NON or >>> (not recommended) are all CON. The draft now generally records this >>> expectation. >>>> * "If a Confirmable packet is used, then the transmitting peer MUST = wait >>>> for the ACK": Why? A NSTART > 1 would give it leisure to still >>>> transmit. >>> [Jon] Text has been removed in the clean-up. >>>> * General on congestion control: It may help implementors if this we= re >>>> split up into newly introduced rules and concepts (that is, >>>> MAX_PAYLOADS and the answer to whether you may send >> MAX_PAYLOADS en >>>> block again after having only even one response from the last roun= d, >>>> and probably the recommended parameters of the "Also on >> parameters" >>>> comment), and another subsection on how Q-Block behaves well when >>>> observing these. >>> [Jon] Should now be covered in the updated Congestion Control section= =2E >>>> Caching: >>>> >>>> * "are not part of the cache key": How about "are removed as part of= the >>>> block assembly and thus do not reach the cache"? >>> [Jon] OK. >>> OLD >>> As the entire body is being cached in the proxy, the Q-Block1 and >>> Q-Block2 Options are not part of the cache key. >>> NEW >>> As the entire body is being cached in the proxy, the Q-Block1 and >>> Q-Block2 Options are removed as part of the block assembly and thu= s >>> do not reach the cache. >>>> * "When the next client completes building the body": If the proxy >>>> chooses not to let them happen in parallel (which it may, see abov= e on >>>> parallel requests, although the server might still not support it = and >>>> cancel one of them), why bother letting the first finish just to a= bort >>>> it? (IOW: If the proxy does not intend to see both through, which = it >>>> could if it held back the second until the first is through on the= >>>> uplink, it could just as well err out of one of them early, but it= may >>>> also rather see both through.) >>> [Jon] It has to be assumed that traffic to/from the origin client and= >>> origin server may not both support Q-Blockx and potentially may have = a >>> different SZX. Thus passing a request or a response through at the >>> block level introduces a new set of challenges (but not impossible to= >>> fix). To keep this simple, my thinking was that the passing through >>> can only take place at the body level. Again, the arrival of packets= >>> is not necessarily sequential, so client A's body may start >>> transmitting to the origin server first, but client B's body starts t= o >>> arrive first - the same being true for the proxy as a client may stop= >>> transmitting for whatever reason (restart, network loss etc.). >>> However this is covered by the above update " If a server receives >>> payloads with different Request-Tags for the same resource, it should= >> continue to process all the bodies". >>> OLD >>> and the new body representation transmission starts with a new >>> Request-Tag value. >>> NEW >>> and the new body representation transmission starts with a new >>> Request-Tag value. Note that it cannot be assumed that the proxy >>> will always receive a complete body from a client. >>>> * Examples: >>>> >>>> * Figure 5: The ... between e3 request and response indicate the >>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose >> there >>>> should be the same kind of delay between the failed e5 transmiss= ion >>>> and the e4 response. >>> [Jon] Agreed and added in >>>> * If the second burst had 3 requests out of which 2 made it, is th= ere >>>> any guidance for which of them the 4.08 would come back on? (In = the >>>> end, none of them is terminal). >>> [Jon] The client should tracking all Tokens of the burst (hence >>> implementation note about bottom 32bits unique and top 32 bits >>> matching block number for ease of tracking) for a response and so it >>> will make no difference at to which token is used for the 4.08 >>> response. From an implementation perspective, it probably is easier >>> to track the last opaque token that has the same Request-Tag. >>> OLD >>> missing ones in one go (Figure 5). It does so by indicating which= >>> blocks have been received in the data portion of the response. >>> NEW >>> missing ones in one go (Figure 5). It does so by indicating which= >>> blocks have been received in the data portion of the response. The= >>> Token just needs to be one of those that have been received for this >>> Request-Tag , so the client can derive the Request-Tag. >>>> * If that e4 response gets lost, does the whole mechanism recover = from >>>> it in any way? >>> [Jon] In this example, if e4 and e5 get lost, there will be no >>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to >>> whether it sends the request again or gives up. See 9.1 >>> "Under high levels of traffic loss, the client can elect not to ret= ry >>> sending missing blocks of data. This decision is implementation >>> specific." >>>> Generally, the all-NON and all-CON examples don't look to me lik= e >>>> what I'd be doing with this spec; the mixed "a CON every >>>> MAX_PAYLOADS" appears much more realistic. >>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS >>> environment (up to 93 secs timeout per payload with the defaults). >>> Hence why we are separating out the NON / CON usage. >>>> * Figure X: The request ahs M unset and thus indicats a request fo= r >>>> just that block. If more than one is expected, it should say >>>> QB2:0/1/1024. >>> [Jon] With Figure 7, with the M bit set, block 3 would get returned >>> for a second time. Draft-ietf-core-new-block-03 also has a Figure 8 >>> which does exactly what you describe. >>>> * New Content Format: I think this needs a media type registration t= o go >>>> with it first; based on that, a content format can be registered. >>> [Jon] Med has responded to this and draft updated. >>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not >>>> sure >>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is >> defined >>>> in terms of reliable transmission, but used for NONs as well. (So = is >>>> the alternative ot 2x ACK_TIMEOUT). >>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT >> in >>> a NON environment. Hence re-write of Congestion Control section >>> defining new variables that can be used for NON. >>>> For the purpose of delaying a 4.08 or a follow-up GET, it may make= >>>> more sense to define a new parameter based on MAX_LATENCY and the >>>> time >>>> it takes the sender to pump out the options (which I don't think w= e >>>> have a good factor for, but may even be negligible here). >>>> >>>> Could read like this: >>>> >>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by >> default >>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / >> BANDWIDTH. >>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, >>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. >>> >>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D 100.= 1. >>> So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps >>> makes MAX_BLOCK_JITTER 200 seconds. >>>> > >>>> > With Q-Block2, a client can ask for any missing blocks after not= >>>> > having received any further response for the duration of >>>> > MAX_BLOCK_JITTER. >>> [Jon] 100+ seconds delay is way too much time to wait for any missing= >>> blocks in my opinion. >>> >>> [Jon] RFC7252 also states (and the intention is that recovery works >>> well) " as MAX_LATENCY is not >>> intended to describe a situation when the protocol works well, = but >>> the worst-case situation against which the protocol has to guar= d." >>>> > >>>> > With Q-Block1, a server holds off any response for MAX_BLOCK_JIT= TER >>>> > unless all blocks have been received. Only then it evaluates whe= ther >>>> > to respond with a 2.0x code, a 4.08 with payload, or not at all >>>> > (because it responded to a later request). >>> [Jon] I am not convinced that this is necessarily the way to go. The= >>> new Congestion Control more cleanly handles this. >>>> This also brings me back to the earlier matter of 2.31: What is a >>>> server supposed to send when no packages were lost, but it's pasin= g >>>> the timeout and wants to help the client flush out more packages b= y >>>> confirming something? It says 4.08 in 3.3, but it's not like there= 's a >>>> hole in the contiguous range. Does it need to send 4.08 enumeratin= g >>>> all (or at least some) numbers between the first unreceived and wh= at's >>>> indicated by Size1? Or can it just send 2.31 and the client knows = all >>>> it needs to know b/c the response came to the largest block that w= as >>>> sent and 2.31 indicates that everything is good up to that point? >>> [Jon] The previous draft states (under Congestion Control) that the >>> client waits for ACK_TIMEOUT before transmitting the next set of >>> MAX_PAYLOADS blocks. The server should wait for "two times >>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps >>> having a new name for ACK_TIMOUT I think that these are reasonable >>> values for Non-Confirmable - and are used in the new Congestion Contr= ol >> section. >>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a >>> signal to say that all of the current MAX_PAYLOADS payloads of a body= >>> have been received, so allowing the client to continue transmitting >>> the next set of MAX_PAYLOADS payloads without the need to wait any >> longer. >>>> * Also on parameters: This document is describing flow control stuff= >>>> around a situation CoAP was not originally designed for. Wouldn't = it >>>> make sense to include a set of parameters (PROBING_RATE, >> MAX_LATENCY, >>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that >>>> PROBING_RATE will be left to 1 byte/second for any DOTS applicatio= n >>>> using this (for sending 10KiB in the initial 10-package MAX_PAYLOA= DS >>>> burst would mark that connection as unusable for about 3 hours if = they >>>> all get lost), so better give justifiable numbers here than rely o= n >>>> implemnetors to come up with unreviewed numbers or disregard >>>> PROBING_RATE altogether. >>> [Jon] Answered by Med, and some new text added. >>>> I don't know if it needs additional justification, but an increase= d >>>> N_START may be justifiable there. >>> [Jon] It may be, but tuning the other associated parameters is really= >>> out of the cope of this draft. This text has been added NEW >>> Congestion control for CON requests and responses is specified in >>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART wil= l >>> need to be increased from 1. However, the other CON congestion >>> control parameters will need to be tuned to cover this change. Thi= s >>> tuning is out of scope of this document as it is expected that all >>> requests and responses using Q-Block1 and Q-Block2 will be Non- >>> confirmable. >>>> * Somewhere (never comes up but I think it should): When CONs are >> used, >>>> a 4.08 (or 2.31?) response to a later request can indicate to the >>>> client that an earlier CON request has been processed successfully= =2E If >>>> the client can match that up (and it should be able to), then it c= an >>>> (and should) cancel that particular CON request. >>> [Jon] I think that this is covered by my update above with the text "= >>> NEW >>> For Confirmable transmission, the server continues to acknowledge >>> each packet, but a response is not required (whether separate or >>> piggybacked) until successful receipt of the body or, if some of th= e >>> payloads are sent as Non-confirmable and have not arrived, a >>> retransmit missing payloads response is needed." >>> >>> And in my previous part 1 response (updated) NEW >>> For Confirmable transmission, the server continues to acknowledge >>> each packet, but a response is not required (whether separate or >>> piggybacked) until successful receipt of the body or, if some of the= >>> payloads are sent as Non-confirmable and have not arrived, a >>> retransmit missing payloads response is needed. >>>> Best regards >>>> Christian >>>> >>>> -- >>>> There's always a bigger fish. >>>> -- Qui-Gon Jinn >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w. >> ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc >> a%4 >> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 >> ecc4 >> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& >> amp;sd >> ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >> >> -- >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81= f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374570966664= 57035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrbmzIuzSjezxDRq47w= wWcNvFC7ox8bw%3D&reserved=3D0 >> > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --GFQ5741qHBUqJHRDRYN8yYKowe2dLM2NN-- --bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/4gOgACgkQ7iZktA5Y 2kOdEwf/TxPU/VfnDDU69aLztTcjrPXrWxQTY7sfyL2MpIozC53KvROuNFJGL1ic yOOOaAZbF5QJ89/pWoNRxh/bZcy3r7THge92JkakPR0S/ZMuHUogBAShTWT5VJk0 mB2fwa/74g/38NZTxzh86HTHXF6nFnpobUVlj2Xb+kHpgdNno/xvrZqQcsq6oyxB GyuoruQEShBrdGpuMLN/F/6rbUdUM1nA5JIwYkMHPB42sVhgpcc6NvLpBC5nllKl qCNukSClguxyCtnlxDRwO2KrAspsUd5Brldu6d9+G0gM/LQtYSmGQe4ZaiFawcUa fxX2iL9o0V24x+t/2pL1mRWXEPmNgA== =hMlF -----END PGP SIGNATURE----- --bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ-- From nobody Fri Jan 8 09:17:25 2021 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 218B03A1167 for ; Fri, 8 Jan 2021 09:17:21 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7vfbl2xa2lKo for ; Fri, 8 Jan 2021 09:17:16 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 2F30C3A116F for ; Fri, 8 Jan 2021 09:17:16 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kxvNu-0003r5-Mp; Fri, 08 Jan 2021 17:17:10 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> In-Reply-To: Date: Fri, 8 Jan 2021 17:17:23 -0000 Message-ID: <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVaiVik3w Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 17:17:21 -0000 Hi Marco, Thanks for this. The new updates have been pushed to https://github.com/core-wg/new-block = and the differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt The PR for the responses below can be found at = https://github.com/core-wg/new-block/pull/11=20 Otherwise see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 08 January 2021 15:57 > To: supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > Thanks, the changes look good. Just a few minor things. >=20 >=20 > * In Section 3.4, about the second case: >=20 > - s/can continue to sent/can continue to send [Jon] Fixed >=20 > - It should be as explicit as in Section 6.2, i.e. "... 'NUM modulo > MAX_PAYLOADS' is zero, while NUM is not zero: ..." [Jon] Updated to be more explicit. >=20 > - The word "current" can be misleading, if its relation with the = value of > NUM in the Q-Block2 option is not clarified. Based on the new example = in > Figure 8, I think you mean the latest set completely transferred to = the > client, whose last block has block number (NUM - 1). A possible = overall > rephrasing can be: >=20 > "This is used to confirm that the current set of MAX_PAYLOADS = payloads > (the latest one having block number NUM-1) has been successfully = received > and that, upon receipt of this request, the server can continue to = send the > next set of payloads (the first one having block number NUM). This is = the > 'Continue' Q-Block-2." [Jon] Thanks - gone with your suggestion >=20 >=20 > * In Section 3.4, about the third case: I guess you mean: "This is a = request for > that block and for all of the remaining blocks in the current = MAX_PAYLOADS > set." [Jon] Yes, updated. >=20 >=20 > * Section 4 says: "The token to use ... any troubleshooting." >=20 > Do you actually mean the highest block number received so far under = that > Request-Tag, or the highest within the current set of MAX_PAYLOADS > payloads for which the server is requesting some missing blocks? >=20 > The new example in Section 5 seems to cover the latter, which I = guess is > what you intend. [Jon] Not sure that it really makes any difference. Have updated the = text to try to clarify OLD The token to use for the response SHOULD be the token that was used in = the highest block number received payload. Note that the use of any = received token would work, but providing the one used in the highest = received block number will aid any troubleshooting. The client will use = the token to match the request to find what Request-Tag value is = currently being used. NEW The token to use for the response SHOULD be the token that was used in = the highest block number received so far with the same Request-Tag = value. Note that the use of any received token with the same Request-Tag = would work, but providing the one used in the highest received block = number will aid any troubleshooting. The client will use the token to = determine what is the previously sent request to obtain the Request-Tag = value to be used. >=20 >=20 > * In Section 9.2: >=20 > - Figure 7, the request should have the M bit set, i.e. QB2:0/1/1024 [Jon] Fixed - you spotted this before and I broke it again with a cut 'n = paste. >=20 > - Figure 8, the last response should have block number 10, i.e. > QB2:10/0/1024 [Jon] Fixed >=20 > - Figure 10, all responses should have ET=3D24 [Jon] Fixed (I only found one) ~Jon >=20 >=20 > Best, > /Marco >=20 >=20 > On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: > > Hi Marco, > > > > Thanks for this - and it is good to have another set of eyes = checking things > through. > > > > Updates have been pushed to > > > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgith > > ub.com%2Fcore-wg%2Fnew- > block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 > > > C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e > 8%7 > > > C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMD > > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D > LN79 > > > Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 > and the > > differences with the draft can be found at > > > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w. > > ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- > block%26url2%3Dhttps%3 > > A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- > block%2Fmaster%2Fdraf > > t-ietf-core-new- > block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 > > > 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% > 7C0% > > > 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiL > > > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc > 2vkC > > 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 > > > > Otherwise, please see inline. > > > > Regards > > > > Jon > > > >> -----Original Message----- > >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] > >> Sent: 07 January 2021 12:17 > >> To: supjps-ietf@jpshallow.com; christian@amsuess.com; > >> draft-ietf-core-new- block@ietf.org > >> Cc: dots@ietf.org; core@ietf.org > >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > >> > >> Hi, > >> > >> Thanks for this revision and for addressing my comments already in > >> version -03. > >> > >> Please, see below some more comments on this version -04. > >> > >> Best, > >> /Marco > >> > >> > >> * s/There are one or more missing CBOR encoded missing block > >> numbers./There are one or more CBOR encoded missing block numbers. > > [Jon] Fixed. > >> > >> * Section 4 now includes the new paragraph: "The token to use for > >> the response SHOULD be the token that was used in the highest block > >> number received payload. The Q-Block1 Option from the same packet > >> SHOULD be included." > > [Jon] The Q-Block1 option actually is not needed as it can be = derived by > the client from the remembered token (which is used to derive the > Request-Tag. > > OLD > > The Q-Block1 Option from the same packet SHOULD be included. > > NEW > > The client will use the token to match the request to find what > > Request-Tag value is currently being used. Providing the highest > > received block number will aid any troubleshooting. > > > >> Consistently, the example in Figure 5 should also have > >> QB1:3/0/1024 in the > >> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 > >> response with Token T:0xe4. > > [Jon] No change now needed. > >> Since "SHOULD" is used, when is it still fine or expected to not > >> include Q- > >> Block1 in a 4.08 response? > > [Jon] Q-Block1 is no longer needed. > >> > >> * When commenting the example in Figure 5, Section 9.1 reads: "The > >> Token just needs to be one of those that have been received for = this > >> Request-Tag, so the client can derive the Request-Tag." > >> > >> Should this not be aligned with the SHOULD used in Section 4 = about > >> using the Token from the same packet conveying the highest block > number? > > [Jon] Agreed > >> You explained in your mail that the client keeps tracking all > >> Tokens in the burst anyway, so maybe it's better to rather align = the > >> text in Section 4 with what suggested here in Section 9.1, i.e. > >> responding with any of those Token values is just fine. > > [Jon] I think that it is useful for the client to have a hint about > > what is the latest block number received even if it does not make = use > > it - it may help in debugging from packet captures etc. which is why = I > added in the SHOULD in section 4. So, I would prefer to align this = with > section 4 OLD The Token just needs to be one of those that have been > received for this > > Request-Tag, so the client can derive the Request-Tag. > > NEW > > The token used in the response should be the token that was used in = the > highest block number received payload. The client can then derive the > Request-Tag by matching the token with the sent request.. > > > >> In such a case, the Q-Block1 option included in the 4.08 = response > >> has still to be the one from the request conveying the highest = block > number. > >> Correct? > > [Jon] We are now dropping the need for Q-Block1 in the response. > >> > >> * The new text in Section 6.2 says: "... and the situation > >> re-evaluated for another 24 hour period until there is no report of > >> missing payloads under normal operating conditions." > >> > >> When that happens, I suppose MAX_PAYLOADS is right away restored > >> to the intended value, i.e. it is not incremented by 1 to start > >> another 24-hour period evaluation. Correct? > > [Jon] Updated for clarification > > OLD > > report of missing payloads under normal operating = conditions. Note > > that the CoAP peer will not know about the MAX_PAYLOADS = change > > until NEW > > report of missing payloads under normal operating = conditions. The > newly > > derived value for MAX_PAYLOADS should be used for both ends = of this > > particular CoAP peer link. Note > > that the CoAP peer will not know about the MAX_PAYLOADS = change > > until > >> > >> * Section 6.2 says: "The request that the client sends to = acknowledge > >> the receipt of all the current set of MAX_PAYLOADS payloads SHOULD > >> contain a special case Q-Block2 Option with NUM set to the first > >> block of the next set of MAX_PAYLOADS payloads and the M bit set to = 1." > >> > >> Is it possible to reflect this in the example of Figure 6? It = would > >> require the body to have more than MAX_PAYLOADS blocks thus > resulting > >> in more bursts, which would be inherited by the examples in Figure = 7 and > Figure 8. > > [Jon] Examples updated to include this information > >> > >> * In Section 9, it would be good to have the parameters defined in > >> Section > >> 6.2 and their values reflected in the examples, when applicable. > >> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked > >> retransmissions are presumably due sometimes to MAX_PAYLOADS > compared > >> against the value of the latest received Q-Block1/Q-Block2, while > >> sometimes to NON_RECEIVE_TIMEOUT. > > [Jon] Examples updated to include this information > >> > >> * In the example in Figure 6, shouldn't the first request from the > >> client have the M bit set to 1 in the Q-Block2 option, i.e. as > >> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the > >> request is in fact for the block 0 and for all of the remaining = blocks within > the body. > > > > [Jon] Good catch - corrected. > > > > ~Jon > >> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > >>> Hi Christian, > >>> > >>> Once again, thank you for the comprehensive review. > >>> > >>> Responses part 2. A new version (-04) of the draft has been > >>> published and can be found at > >>> > >> > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat > >> a > >>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- > >> block%2F&data=3D04%7C01 > >> > %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 > >> 9cf0 > >> > bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown > >> %7CTWFpb > >> > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > >> 6Mn0 > >> > %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j > >> gTY%3D&am > >>> p;reserved=3D0 > >>> > >>> > >>> Part 1 responses were covered in the main by version -03, so you = may > >>> want to look at the -02 to -04 differences. > >>> > >>> The Congestion Control section has been re-written to simplify how > >>> things work and has a new set of definitions. There is a = separation > >>> of Confirmable and Non-Confirmable Congestion Control with the > >>> stated assumption that all of a body is sent as Non-Confirmable or > Confirmable. > >>> > >>> Otherwise, see inline. > >>> > >>> Regards > >>> > >>> Jon > >>> > >>>> * The list of pros and cons (with the cons being almost trivial) = does > >>>> not explain to the reader why these are not a replacement; I = suggest > >>>> to add: > >>> [Jon] Another disadvantage addition > >>> NEW > >>> To reduce the transmission times for CON transmission of large > >>> bodies, NSTART needs to be increased from 1, but this affects > >>> congestion control where other parameters need to be tuned = (Section > >>> 4.7 of [RFC7252]). Such tuning is out of scope of this document. > >>> > >>>> * "If the client transmits a new body of data with a new = Request-Tag > >>>> to": Processing parallel requests is something Request-Tag = opens up. I > >>>> don't see why there's a MUST to that; the server certainly MAY = drop > >>>> the old request, but it may just as well process them in = parallel. > >>> [Jon] The intent here was that garbage collection would take place > >>> sooner than later - especially when running in a lossy environment > >>> and the client has updated information to transmit. I agree that > >>> Request-Tag enables the possibility of sending multiple block > >>> requests with different payloads, and so there is a possibility = that > >>> the client starts sending body A, then decides to send body B and > >>> terminate A, but a packet from B arrives before a packet from body = A > >>> is received and so > >> things fail as A does not complete. > >>> OLD > >>> If the client transmits a new body of data with a new = Request-Tag to > >>> the same resource on a server, the server MUST remove any = partially > >>> received body held for a previous Request-Tag for that = resource. > >>> NEW > >>> If a server receives payloads with different Request-Tags for = the > >>> same resource, it should continue to process all the bodies as it > >>> has no way of determining which is the latest version, or which > >>> body, if any, the client is terminating the transmission for. > >>> > >>> If the client elects to stop the transmission of a complete = body, it > >>> SHOULD "forget" all tracked tokens associated with the body's > >>> Request-Tag so that a reset message is generated for the invalid > >>> token in the 4.08 (Request Entity Incomplete) response. The = server > >>> on receipt of the reset message SHOULD delete the partial body. > >>> END > >>> > >>>> * "If the server receives a duplicate block with the same = Request-Tag": > >>>> Why? Being silent is the default on nonterminal blocks alredy, = but in > >>>> a situation like figure 5 if the 2.04 is lost, that rule would = make > >>>> it impossible for the client to ever get a successful response. > >>>> > >>>> A better rule here may be to say that it processes it all the = same > >>>> (and if the payload is distinct from the first transmission's = payload, > >>>> it should err out.) > >>> [Jon] Fair point > >>> OLD > >>> If the server receives a duplicate block with the same = Request-Tag, > >>> it SHOULD silently ignore the packet. > >>> NEW > >>> If the server receives a duplicate block with the same = Request-Tag, > >>> it SHOULD ignore the payload of the packet, but MUST still > >>> respond as if the block was received for the first time. > >>>> * "If the server receives multiple requests (implied or = otherwise) for > >>>> the same block, it MUST only send back one instance of that = block.": > >>>> This might be read as "ever" rather than "per incoming = request", > where > >>>> probably the latter is meant. > >>> [Jon] This text has already been updated following another review > >>> "OLD If the server receives multiple requests > >>> (implied or otherwise) for the same block, it MUST only send = back one > >>> instance of that block. > >>> NEW > >>> If the request includes multiple Q-Block2 > >>> Options and these options overlap (e.g., combination of M being = set > >>> (this and all the later blocks) and being unset (this = individual > >>> block)) resulting in an individual block being requested = multiple > >>> times, the server MUST only send back one instance of that = block. > >>> This behavior is meant to prevent amplification attacks." > >>> > >>>> * "The ETag Option MUST NOT be used": This is more a factural = than a > >>>> normative statement; it *can* not be used there as the server = would > >>>> respond thusly. It may be used, but then that indicates that = the > >>>> client is trying to verify a freshness. (However, the client = should > >>>> not *start* sending an ETag once it learned the current = resource's > >>>> ETag when still attempting to pull out more blocks, but that's = also not > >>>> a normative requirement but a consequence of those two requests > not > >>>> being matchable any more.) > >>> [Jon] OK > >>> OLD > >>> The ETag Option MUST NOT be used in the request as the server = could > >>> respond with a 2.03 (Valid Response) with no payload. If the = server > >>> responds with a different ETag Option value (as the resource > >>> representation has changed), then the client SHOULD drop all = the > >>> payloads for the current body that are no longer valid. > >>> NEW > >>> The ETag Option should not be used in the request for missing > >>> blocks as the server could respond with a 2.03 (Valid Response) = with > >>> no payload. It can be used in the request if the client wants to > >>> check the freshness of the currently cached body response. > >>> > >>> If the server detects part way through a body transfer that the > >>> resource data has changed and the server is not maintaining a = cached > >>> copy of the old data, then the body response SHOULD be restarted > >>> with a different ETag Option value. Any subsequent missing block > >>> requests MUST respond using the latest ETag Option value. > >>> > >>> If the server responds during a body update with a different ETag > >>> Option value (as the resource representation has changed), then = the > >>> client should treat the partial body with the old ETag as no = longer > >>> being > >> fresh. > >>> END > >>>> * "then the client SHOULD drop all the payloads for the current = body": > >>>> "Drop" is overly prescriptive; the client may well keep them, = but > >>>> just can't consider them fresh any more. (If the client has = ample > >>>> caching abilities, they might come in handy if the resource = goes back > >>>> to that ETag state). Same for later "the client MUST remove any > >>>> partially received". > >>> [Jon] See previous response, otherwise OLD > >>> If the server transmits a new body of data (e.g., a triggered > >>> Observe) with a new ETag to the same client as an additional > >>> response, the client MUST remove any partially received body = held for > >>> a previous ETag. > >>> NEW > >>> If the server transmits a new body of data (e.g., a triggered > >>> Observe) with a new ETag to the same client as an additional > >>> response, the client should remove any partially received body = held > for > >>> a previous ETag for that resource as it is unlikely the missing > >>> blocks can be retrieved. > >>>> * "For Confirmable transmission, the client SHOULD continue to": = As > >>>> above in the other direction, that's not news. > >>> [Jon] Again, we are not looking for a response (well, a request in > >>> this case as needed by Block2), just an ACK OLD > >>> For Confirmable transmission, the client SHOULD continue to > >>> acknowledge each packet as well as issuing a separate GET, = POST, PUT, > >>> FETCH, PATCH, or iPATCH for the missing blocks. > >>> NEW > >>> For Confirmable transmission, the server continues to = acknowledge > >>> each packet, but a response is not required (whether separate or > >>> piggybacked) until successful receipt of the body or, if some of = the > >>> payloads are sent as Non-confirmable and have not arrived, a > >>> retransmit missing payloads response is needed. > >>>> * "If there is insufficient space to create a response PDU": I = don't > >>>> understand what that means. (Where are request options = reflected > >>>> back?). > >>> [Jon] This was triggered by a question by Michael Richardson " So, > >>> given a Christmas-Tree-Packet (largest packet, every possible = option > >>> space used, every extension turned on...) how much data can I get > >>> back? :-)" and not fully thought through. > >>> It could happen though with Location-Path, Location-Query, = Q-Block2, > >>> ETag, > >>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in > >>> response to a POST. > >>> OLD > >>> If there is insufficient space to create a response PDU with a = block > >>> size of 16 bytes (SZX =3D 0) to reflect back all the request = options as > >>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>> the Size2 Option. > >>> NEW > >>> If there is insufficient space to create a response PDU with a = block > >>> size of 16 bytes (SZX =3D 0) to send back all the response = options as > >>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>> the Size1 Option. > >>> > >>>> * "If the client requests missing blocks, this is treated as a = new > >>>> request.": I don't think the client should even make these = follow-up > >>>> requests Observe, as it already has an ongoing observation. = They'd be > >>>> sent on a different token too, so setting Observe would be = opening > >>>> observation up on that token, which AFAIU is not intended. = (Figure 7 > >>>> example looks good to me in that respect.) > >>>> > >>>> (It may make sense to ask the client to keep Observe to make = the > >>>> requests matchable just for the sake of staying in = atomic-request > >>>> mode. Either way, the server should then not accept that = observation > >>>> as it's not for a block 0.) > >>> [Jon] The intent here was that just a new Token should be used. > >>> OLD > >>> If the client requests missing blocks, this is treated as a new > >>> request. The Observe value may change but MUST still be = reported. > >>> If the ETag value changes then the previously received partial = body > >>> should be destroyed and the whole body re-requested. > >>> NEW > >>> If the client requests missing blocks, this is treated as a new > >>> Request and the Observe Option MUST NOT be included. If the = ETag > >> value > >>> changes, then the previously received partial body > >>> should be considered as not fresh and the whole body = re-requested. > >>> > >>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response = can > be > >>>> matched by the token to a unique request that already had a > >>>> Request-Tag, and the client needs to have kept that token = around > >>>> matched to the transfer to make sense of it. > >>>> > >>>> No need to move that value around between subsystems, and just > >>>> dropping it from here would also remove the need for the "If = the > >>>> client does not recognize the Request-Tag" clause (which would > >>>> otherwise need clarification as to what it'd mean if it = recognizes it > >>>> but it doesn't match what the request was for). > >>> [Jon] Good question - it does make sense for the Request-Tag to be > >>> tracked alongside the Token in the client. > >>> OLD > >>> The data payload of the 4.08 (Request Entity Incomplete) = Response > >>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR = encoded > >>> Request-Tag followed by 1 or more missing CBOR encoded missing > block > >>> numbers. > >>> NEW > >>> The data payload of the 4.08 (Request Entity Incomplete) = response > >>> is encoded as a CBOR Sequence [RFC8742]. There are one or more > >> missing > >>> CBOR encoded missing block numbers. > >>> > >>> OLD > >>> ; This defines an array, the elements of which are to be = used > >>> ; in a CBOR Sequence: > >>> payload =3D [request-tag, + missing-block-number] > >>> request-tag =3D bstr > >>> ; A unique block number not received: > >>> missing-block-number =3D uint > >>> NEW > >>> ; This defines an array, the elements of which are to be = used > >>> ; in a CBOR Sequence: > >>> payload =3D [+ missing-block-number] > >>> request-tag =3D bstr > >>> ; A unique block number not received: > >>> missing-block-number =3D uint > >>> > >>> OLD > >>> A 4.08 (Request Entity Incomplete) Response Code returned with > >>> Content-Type "application/missing-blocks+cbor-seq" indicates = that > >>> some of the payloads are missing and need to be resent. The = client > >>> then re-transmits the missing payloads using the Request-Tag = and > >>> Q-Block1 to specify the block number, SZX, and M bit as = appropriate. > >>> The Request-Tag value to use is determined from the payload of = the > >>> 4.08 (Request Entity Incomplete) Response Code. If the client = does > >>> not recognize the Request-Tag, the client can ignore this = response. > >>> NEW (option presentation has been reformatted) > >>> 4.08 (Request Entity Incomplete) > >>> > >>> This Response Code returned with Content-Type "application/ > >>> missing-blocks+cbor-seq" indicates that some of the payloads are > >>> missing and need to be resent. The client then retransmits the > >>> missing payloads using the same Request-Tag, Size1 and Q-Block1 = to > >>> specify the block number, SZX, and M bit as appropriate. > >>> > >>> > >>> The Request-Tag value to use is determined from the token in the > >>> 4.08 (Request Entity Incomplete) response and then finding the > >>> matching client request which contains the Request-Tag that is > >>> being used for this Q-Block1 body. END > >>>> * "limit the array count to 23 (Undefined value)": 23 is the = maximum > >>>> length of a zero-byte length indication, not indefinite-length = (31). > >>>> Both using 23 and 31 here makes sense (up to 23 to have = definite > >>>> length that can be updated in-place, or exceeding that switch = to > >>>> indefinite length if they still fit), but the paragraph seems = to be > >>>> mixing them up. > >>> [Jon] OK > >>> OLD > >>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count = to 23 > >>> (Undefined value) so that the array data byte can be updated = with > >>> the overall length once the payload length is confirmed or = limited > >>> to MAX_PAYLOADS count. > >>> NEW > >>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit > >>> the array count to > >>> 23 so that the initial byte with the array major type and = data > >>> length in the additional information can be updated with the = overall > >>> count once the payload count is confirmed. Further restricting = the > >>> count to MAX_PAYLOADS means that congestion control is less likely > >>> to be > >> invoked on the server. > >>>> * "Each new request MUST use a unique token": Like above, this is > >>>> stating something that's not intended to be changed. > >>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty > >>> token values are acceptable. Hence this statement. > >>>> Congestion Control: > >>>> > >>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is > >> subjected > >>>> to PROBING_RATE.": That is unexpected here. At most one such > >>>> response is sent to each request message, so why is additional > >>>> congestion control needed? > >>> [Jon] The intention here was that in the previous paragraph that = it > >>> was not the individual packets that are subject to PROBING_RATE, = but > >>> a single body comprising of multiple packets is subject to > >>> PROBRING_RATE > >>> - and hence limiting any individual responses to PROBING_RATE = rather > >>> than the potentially full set of responses OLD > >>> PROBING_RATE parameter in CoAP indicates the average data rate = that > >>> must not be exceeded by a CoAP endpoint in sending to a peer > endpoint > >>> that does not respond. The body of blocks will be subjected to > >>> PROBING_RATE (Section 4.7 of [RFC7252]). > >>> NEW > >>> PROBING_RATE parameter in CoAP indicates the average data rate = that > >>> must not be exceeded by a CoAP endpoint in sending to a peer > endpoint > >>> that does not respond. The single body of blocks will be = subjected to > >>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual = packets. > >>> If the wait time between sending bodies that are not being > >>> responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, > >> then the > >>> gap time is limited to NON_PROBING_WAIT. > >>> > >>> Note: For the particular DOTS application, PROBING_RATE and other > >>> transmission parameters are negotiated between peers. Even when > >>> not negotiated, the DOTS application uses customized defaults as > >>> discussed in Section 4.5.2 of [RFC8782]. > >>> END > >>>> On the other hand, *ever* NON request is subject to = PROBING_RATE, > so > >>>> why point out the body of blocks and "GET or similar" = particularly? > >>> [Jon] It is only GET or FETCH. The intention here is to not = request > >>> bodies of data at too high a rate. > >>> OLD > >>> Each NON GET or similar request using Q-Block2 Option is = subjected to > >>> PROBING_RATE. > >>> NEW > >>> Each NON GET or FETCH request using Q-Block2 Option is = subjected > >>> to PROBING_RATE. > >>>> * "a delay is introduced of ACK_TIMEOUT": As I understand > >> MAX_PAYLOADS, > >>>> this is (rather implicitly) introduced as the package count up = to > >>>> which it is OK to exceed PROBING_RATE temporarily (but after = that it > >>>> kicks in all the harder by requiring to wait until = complete-sent-bytes > >>>> over PROBING_RATE has expired). If that holds, at that time a = much > >>>> larger delay than just ACK_TIMEOUT is needed to get a response = from > >>>> the server: About 3 hours (see later note on parameters). > >>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write > >>> of Congestion Control section. > >>>> This is the crucial point in the document, and for it a = recommendation > >>>> alone is not good enough. The protocol can be run with a vastly > >>>> increased PROBING_RATE (however externally determined) and from > >> the > >>>> point of MAX_PAYLOADS just observe it. Or it has to get = feedback > from > >>>> the server; a single 4.08 is probably enough to kick off = another > >>>> vollley of blocks. (How many? MAX_PAYLOADS for every = response?). > >>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing = any > >>>> good. > >>> [Jon] See re-write of Congestion Control section where things = should > >>> now be simpler and more logical. There is an introduction of new > >>> variable definitions. > >>>> * "For NON transmissions": This seems to imply that the full = exchange > of > >>>> a body is either NON or CON; I don't see where that'd come = from. I'd > >>>> have expected to read something like "Each individual request = can be > >>>> NON or CON independent of the others. In particular, it can be > >>>> convenient to send the ultimate payload...". > >>> [Jon]The DOTS environment will only be using NON. To make > >>> Congestion Control simple, the expectation is that all = transmissions > >>> are NON or (not recommended) are all CON. The draft now generally > >>> records this expectation. > >>>> * "If a Confirmable packet is used, then the transmitting peer = MUST > wait > >>>> for the ACK": Why? A NSTART > 1 would give it leisure to still > >>>> transmit. > >>> [Jon] Text has been removed in the clean-up. > >>>> * General on congestion control: It may help implementors if this = were > >>>> split up into newly introduced rules and concepts (that is, > >>>> MAX_PAYLOADS and the answer to whether you may send > >> MAX_PAYLOADS en > >>>> block again after having only even one response from the last = round, > >>>> and probably the recommended parameters of the "Also on > >> parameters" > >>>> comment), and another subsection on how Q-Block behaves well > when > >>>> observing these. > >>> [Jon] Should now be covered in the updated Congestion Control > section. > >>>> Caching: > >>>> > >>>> * "are not part of the cache key": How about "are removed as part = of > the > >>>> block assembly and thus do not reach the cache"? > >>> [Jon] OK. > >>> OLD > >>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>> Q-Block2 Options are not part of the cache key. > >>> NEW > >>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>> Q-Block2 Options are removed as part of the block assembly and > >>> thus do not reach the cache. > >>>> * "When the next client completes building the body": If the = proxy > >>>> chooses not to let them happen in parallel (which it may, see = above > on > >>>> parallel requests, although the server might still not support = it and > >>>> cancel one of them), why bother letting the first finish just = to abort > >>>> it? (IOW: If the proxy does not intend to see both through, = which it > >>>> could if it held back the second until the first is through on = the > >>>> uplink, it could just as well err out of one of them early, but = it may > >>>> also rather see both through.) > >>> [Jon] It has to be assumed that traffic to/from the origin client > >>> and origin server may not both support Q-Blockx and potentially = may > >>> have a different SZX. Thus passing a request or a response = through > >>> at the block level introduces a new set of challenges (but not > >>> impossible to fix). To keep this simple, my thinking was that the > >>> passing through can only take place at the body level. Again, the > >>> arrival of packets is not necessarily sequential, so client A's = body > >>> may start transmitting to the origin server first, but client B's > >>> body starts to arrive first - the same being true for the proxy as = a > >>> client may stop transmitting for whatever reason (restart, network = loss > etc.). > >>> However this is covered by the above update " If a server = receives > >>> payloads with different Request-Tags for the same resource, it > >>> should > >> continue to process all the bodies". > >>> OLD > >>> and the new body representation transmission starts with a new > >>> Request-Tag value. > >>> NEW > >>> and the new body representation transmission starts with a new > >>> Request-Tag value. Note that it cannot be assumed that the = proxy > >>> will always receive a complete body from a client. > >>>> * Examples: > >>>> > >>>> * Figure 5: The ... between e3 request and response indicate = the > >>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose > >> there > >>>> should be the same kind of delay between the failed e5 = transmission > >>>> and the e4 response. > >>> [Jon] Agreed and added in > >>>> * If the second burst had 3 requests out of which 2 made it, is = there > >>>> any guidance for which of them the 4.08 would come back on? = (In the > >>>> end, none of them is terminal). > >>> [Jon] The client should tracking all Tokens of the burst (hence > >>> implementation note about bottom 32bits unique and top 32 bits > >>> matching block number for ease of tracking) for a response and so = it > >>> will make no difference at to which token is used for the 4.08 > >>> response. From an implementation perspective, it probably is = easier > >>> to track the last opaque token that has the same Request-Tag. > >>> OLD > >>> missing ones in one go (Figure 5). It does so by indicating = which > >>> blocks have been received in the data portion of the response. > >>> NEW > >>> missing ones in one go (Figure 5). It does so by indicating = which > >>> blocks have been received in the data portion of the response. > >>> The Token just needs to be one of those that have been received = for > >>> this Request-Tag , so the client can derive the Request-Tag. > >>>> * If that e4 response gets lost, does the whole mechanism = recover > from > >>>> it in any way? > >>> [Jon] In this example, if e4 and e5 get lost, there will be no > >>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to > >>> whether it sends the request again or gives up. See 9.1 > >>> "Under high levels of traffic loss, the client can elect not to = retry > >>> sending missing blocks of data. This decision is = implementation > >>> specific." > >>>> Generally, the all-NON and all-CON examples don't look to me = like > >>>> what I'd be doing with this spec; the mixed "a CON every > >>>> MAX_PAYLOADS" appears much more realistic. > >>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS > >>> environment (up to 93 secs timeout per payload with the defaults). > >>> Hence why we are separating out the NON / CON usage. > >>>> * Figure X: The request ahs M unset and thus indicats a request = for > >>>> just that block. If more than one is expected, it should say > >>>> QB2:0/1/1024. > >>> [Jon] With Figure 7, with the M bit set, block 3 would get = returned > >>> for a second time. Draft-ietf-core-new-block-03 also has a Figure = 8 > >>> which does exactly what you describe. > >>>> * New Content Format: I think this needs a media type = registration to > go > >>>> with it first; based on that, a content format can be = registered. > >>> [Jon] Med has responded to this and draft updated. > >>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm > not > >>>> sure > >>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is > >> defined > >>>> in terms of reliable transmission, but used for NONs as well. = (So is > >>>> the alternative ot 2x ACK_TIMEOUT). > >>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and > ACK_TIMEOUT > >> in > >>> a NON environment. Hence re-write of Congestion Control section > >>> defining new variables that can be used for NON. > >>>> For the purpose of delaying a 4.08 or a follow-up GET, it may = make > >>>> more sense to define a new parameter based on MAX_LATENCY and > the > >>>> time > >>>> it takes the sender to pump out the options (which I don't = think we > >>>> have a good factor for, but may even be negligible here). > >>>> > >>>> Could read like this: > >>>> > >>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by > >> default > >>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / > >> BANDWIDTH. > >>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, > >>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > >>> > >>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. > >>> So BANDWITH of 1Mbps has negligible effect on the calculation. = 1Kbps > >>> makes MAX_BLOCK_JITTER 200 seconds. > >>>> > > >>>> > With Q-Block2, a client can ask for any missing blocks after = not > >>>> > having received any further response for the duration of > >>>> > MAX_BLOCK_JITTER. > >>> [Jon] 100+ seconds delay is way too much time to wait for any > >>> missing blocks in my opinion. > >>> > >>> [Jon] RFC7252 also states (and the intention is that recovery = works > >>> well) " as MAX_LATENCY is not > >>> intended to describe a situation when the protocol works = well, but > >>> the worst-case situation against which the protocol has to = guard." > >>>> > > >>>> > With Q-Block1, a server holds off any response for > MAX_BLOCK_JITTER > >>>> > unless all blocks have been received. Only then it evaluates > whether > >>>> > to respond with a 2.0x code, a 4.08 with payload, or not at = all > >>>> > (because it responded to a later request). > >>> [Jon] I am not convinced that this is necessarily the way to go. > >>> The new Congestion Control more cleanly handles this. > >>>> This also brings me back to the earlier matter of 2.31: What is = a > >>>> server supposed to send when no packages were lost, but it's = pasing > >>>> the timeout and wants to help the client flush out more = packages by > >>>> confirming something? It says 4.08 in 3.3, but it's not like = there's a > >>>> hole in the contiguous range. Does it need to send 4.08 = enumerating > >>>> all (or at least some) numbers between the first unreceived and > what's > >>>> indicated by Size1? Or can it just send 2.31 and the client = knows all > >>>> it needs to know b/c the response came to the largest block = that was > >>>> sent and 2.31 indicates that everything is good up to that = point? > >>> [Jon] The previous draft states (under Congestion Control) that = the > >>> client waits for ACK_TIMEOUT before transmitting the next set of > >>> MAX_PAYLOADS blocks. The server should wait for "two times > >>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps > >>> having a new name for ACK_TIMOUT I think that these are reasonable > >>> values for Non-Confirmable - and are used in the new Congestion > >>> Control > >> section. > >>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) as = a > >>> signal to say that all of the current MAX_PAYLOADS payloads of a > >>> body have been received, so allowing the client to continue > >>> transmitting the next set of MAX_PAYLOADS payloads without the = need > >>> to wait any > >> longer. > >>>> * Also on parameters: This document is describing flow control = stuff > >>>> around a situation CoAP was not originally designed for. = Wouldn't it > >>>> make sense to include a set of parameters (PROBING_RATE, > >> MAX_LATENCY, > >>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt = that > >>>> PROBING_RATE will be left to 1 byte/second for any DOTS = application > >>>> using this (for sending 10KiB in the initial 10-package = MAX_PAYLOADS > >>>> burst would mark that connection as unusable for about 3 hours = if > they > >>>> all get lost), so better give justifiable numbers here than = rely on > >>>> implemnetors to come up with unreviewed numbers or disregard > >>>> PROBING_RATE altogether. > >>> [Jon] Answered by Med, and some new text added. > >>>> I don't know if it needs additional justification, but an = increased > >>>> N_START may be justifiable there. > >>> [Jon] It may be, but tuning the other associated parameters is > >>> really out of the cope of this draft. This text has been added NEW > >>> Congestion control for CON requests and responses is specified in > >>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will > >>> need to be increased from 1. However, the other CON congestion > >>> control parameters will need to be tuned to cover this change. = This > >>> tuning is out of scope of this document as it is expected that = all > >>> requests and responses using Q-Block1 and Q-Block2 will be Non- > >>> confirmable. > >>>> * Somewhere (never comes up but I think it should): When CONs are > >> used, > >>>> a 4.08 (or 2.31?) response to a later request can indicate to = the > >>>> client that an earlier CON request has been processed = successfully. If > >>>> the client can match that up (and it should be able to), then = it can > >>>> (and should) cancel that particular CON request. > >>> [Jon] I think that this is covered by my update above with the = text " > >>> NEW > >>> For Confirmable transmission, the server continues to = acknowledge > >>> each packet, but a response is not required (whether separate or > >>> piggybacked) until successful receipt of the body or, if some of = the > >>> payloads are sent as Non-confirmable and have not arrived, a > >>> retransmit missing payloads response is needed." > >>> > >>> And in my previous part 1 response (updated) NEW For Confirmable > >>> transmission, the server continues to acknowledge each packet, = but > >>> a response is not required (whether separate or > >>> piggybacked) until successful receipt of the body or, if some of = the > >>> payloads are sent as Non-confirmable and have not arrived, a > >>> retransmit missing payloads response is needed. > >>>> Best regards > >>>> Christian > >>>> > >>>> -- > >>>> There's always a bigger fish. > >>>> -- Qui-Gon Jinn > >>> _______________________________________________ > >>> core mailing list > >>> core@ietf.org > >>> > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >> w. > >> > ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc > >> a%4 > >> > 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 > >> ecc4 > >> > 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 > >> eyJWIjoiMC > >> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& > >> amp;sd > >> > ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 > >> > >> -- > >> Marco Tiloca > >> Ph.D., Senior Researcher > >> > >> RISE Research Institutes of Sweden > >> Division ICT > >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > >> SE-164 40 Kista (Sweden) > >> > >> Phone: +46 (0)70 60 46 501 > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w > >> > .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 > c8 > >> > 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 > 45709 > >> > 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV2luMz > >> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb > mzIuz > >> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 > >> > > >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Fri Jan 8 10:18:54 2021 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 81FFE3A0AB9; Fri, 8 Jan 2021 10:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 09MHehrSX0hM; Fri, 8 Jan 2021 10:18:47 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150080.outbound.protection.outlook.com [40.107.15.80]) (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 0DED33A0A26; Fri, 8 Jan 2021 10:18:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q/JWxxrkGfitb/EIfnsu8F0qV+SyIBzCGroILgvdweRNocuTz3k38LnsOaFZ9QEoVzmLq6EenHcWo4EGZCV1Y7aGL1IcjW2SPVUJ0JPt9HA/mvFmo5jgDi7f4vaVntiPk3eUXVdZs8fW1PHxYqsxdfztTWERAmVENwQKb3R8JqTLBKPeCKdw/Tj4MtMhB0pvVoaoF+zYsSNtBtJuv3XenkniZRassWoEi8AG4axGd6hy0g9aZDo82hMYlAt/lEg6FuJm7Fw+m+CEfW05tQLrORzJkI7z2DJlZAlTmP0j7WZZVw5bQqKFUGveNu0LQxxVlzR6ctDJnaIttrPjoqXCCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4iV1gUxMb3ULTpjWyCuvaHWelEXekJ8Gqil7by7e9A=; b=YktrSCQtt2zTKmwXAqNChxQDhoJDXvyyexfFwPu+v7RmU/2FxWBDBkCsVtwo3WKmJxm6m7W+FItxvlmGaEaeESwLJSiF/4K0AFD9j2DV36Ka4g3mf5kZIh5pae7t3OHt8gSFnQtwSGrnSCJHz6kC1h+tlNJe43bROhFdrmgrVgTJ9BfJzGIr9WA+ND5PejO0ko+8STq+IOdnJGmD5NU+4v+1RRjYjMOM5yn8gNbESsSWkGKUqXnxaw5dzUFaDCVwQsY++LLc/iCKT+Mj3st1mYoNoPgmqLeuaP3fHBnzKbu9ukMesiuH8MkQpPrnjhTokTsIIlLuhDQ7SupIRcz1+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4iV1gUxMb3ULTpjWyCuvaHWelEXekJ8Gqil7by7e9A=; b=iIFCYVWyazl0NgngtPHfG+HcJVsKl0Xdropi1guwWFQCJQodT1Rte1MResKW1RwGaiOn3txnhvefzUIx7qBBVB0cq/D7mEowrfLN0iJhbr2V2rRzFBm3bSsMWS7vLSSiwOwUCkhjEZpWAbGBWAuWd7av9EdUKS+HHVH3czQfcoI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0840.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Fri, 8 Jan 2021 18:18:37 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.010; Fri, 8 Jan 2021 18:18:37 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Fri, 8 Jan 2021 19:18:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz" X-Originating-IP: [37.120.209.204] X-ClientProxiedBy: HE1PR0502CA0024.eurprd05.prod.outlook.com (2603:10a6:3:e3::34) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.7] (37.120.209.204) by HE1PR0502CA0024.eurprd05.prod.outlook.com (2603:10a6:3:e3::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Fri, 8 Jan 2021 18:18:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b98f1ee2-a104-4378-de6f-08d8b401d1aa X-MS-TrafficTypeDiagnostic: DB8P189MB0840: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I/vfODuCxu9gIBYb0JvehLft1nS6mo1r0xjsOOZAOjD8Ath5Jwkr3IRVWdRSZvD8Y4TsaVW03/vc6aWYqX41CLKGuGTYN7hw+QRWe4yHNUxSZM33AbPCMrn7ZrRxaXfjdNIjB1EXXZf6l7K3oRWJmKdjCV1FjjITmLSnfY/mVvqB1HcVcoZnsBUhxkiaS0OHw+rjGrG4DeINlxJKevbnWThSIBmqimkkUHpTUXhxPt38kFdHzN45ArZDN4GcC0Aw1Wl35J2uaQFYOpSbfff3g8WcVyqEnX6ruev5/wEXcLF9xUqMYvjR8lxjvd2kxgOT7b8YPS+FvkyOpEl/6Y09FRPxZjvlIgpGTE5FLTFh8dktxh5H1NG8cpqTbsg3UcxxAIDb2cWdofOREPuirLJ0TxdWS6FhvlNkH6HdA0tumHsgr2o2Ii/9S2GKWc5dNykB0GTDmwvE+okoR02xRRWtpdzyLOXpgbtAHseB+nE0rkMln7qmyV4IyTSEggdn6BhlGnHGGFBP8/yBV4vcPiqJpbmlFVr7xCG06u4o+1RrqI4F43E5j8pwGGPJZZ70qUtM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(396003)(136003)(346002)(376002)(31686004)(8936002)(52116002)(33964004)(66476007)(83380400001)(16576012)(2616005)(316002)(6666004)(235185007)(66946007)(2906002)(5660300002)(21480400003)(44832011)(66556008)(30864003)(8676002)(16526019)(86362001)(6486002)(186003)(26005)(66574015)(4326008)(45080400002)(36756003)(956004)(478600001)(53546011)(966005)(31696002)(45980500001)(43740500002)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Rm8yS2krSVVBZjZ0WStRQVJwbldEYVpFQWhGWlVSRFIvWGNVNFd2Nk8vTXBR?= =?utf-8?B?cEdZeDByS3V2TFFhK1ZhV0drdmZzWkV3dCtkck16eFRnMVFUK1BJNlBCcmdm?= =?utf-8?B?SE5LMWF4RUZ5UksyOGpvblUwSUFUUFV4dDlHaHZGNWJteHdFTXlLakc1cUJK?= =?utf-8?B?YkgzY3RBNlVsVFI4OW5XWkRzV3RWL0lkU0J3aGxJTEhMSUhROXZmUjkzc2Uy?= =?utf-8?B?VVdUWFZRQXlWRFRPeUR6WWZZdXJSV3dZRS9kVS9MemtFNmxkbHlBUGxySXdp?= =?utf-8?B?T2k4UXNEU2JTQytIcjJWQlhzb1JlbjVxbmNsQlk1NVJ2bVoyd2drejZIZWdp?= =?utf-8?B?a2xZZmw2THVhZzdLMCtWMDhrQTF3WkpFYXFHelZHQ1pBd202RW1pUFZQeDh3?= =?utf-8?B?L2pXRXRLRjN3YktGQVc4TmZkV0I3VlcvQTQ5dW4zWVRPdXZ3TmlrdDhwNFRU?= =?utf-8?B?UGJCY0NUSHBtb0xKVE1ReDlURXpQeXBZYytUbndTNiswcFhDN1hSS3hMUGpt?= =?utf-8?B?d2tDZkUwVnNYVkVOQWg1ODMxVFdZYVc1N0RlRVlVVkJXd1JqMitUUE82aEdv?= =?utf-8?B?SDVhQitHdTZKMGtHYXE2MTVMY3NQd25wTHpQcXg5VGpobmNjbkRUY05Gakxw?= =?utf-8?B?Y1p1bEVjVjMxdm51T1RCWk9FaUJZMkdrWXlyL1UxTUp5ZzY0cWhXeS9tNEts?= =?utf-8?B?QmlUMW1IeW5uMUIxTEt2QTRTY2Q0NmFTTHcwRlZpdENHaGFSUFdianpuU2tR?= =?utf-8?B?SWY3Z3BVUzFkZ0lwZnJOS3F6S3ZONU9pRXBTSWZKZnQ1NEVtclJMK0hpZHg3?= =?utf-8?B?cUswNG5mNnIycm00bUl2Rm1OVmw0SXNvcThVWllJZWVzd0Y2Y1lhTDFvSEpG?= =?utf-8?B?VUdiRW8xelBnQ21WbHU2SW05Z05OSllFTnZqTzVyc2ZNUWpHeWdOc2JxWFpt?= =?utf-8?B?V2FOWE5keWxFUmdDSWErQmhMVE9TUWtlSHV4Sng3VGpMeG5TRHZpdnVVYkl2?= =?utf-8?B?VkQ4SXc4NThjVVR6VVQvZ2c1RlVuVVJhY2R3OWNER0IrM3I1ZktIUDhtbWFR?= =?utf-8?B?WmsvWXQzK20wRDlZUzg1K2FCV0d5LzJ6dDVDRTlpZkpOMFJoNTk0ZHBVYnFj?= =?utf-8?B?dmxuZ0RjSE0zMjBYSHVOQXdSazlvMkpHVUw0MW4zcVcyZWpRbXlDazkya09W?= =?utf-8?B?dmZEMmIwNnVCdnhqd05HVHErQTN1T0pvQUVIQms5WTJ1K3FSeC80ZVlpRERh?= =?utf-8?B?SmxzdDVLQmczandaMzhld01xcDN2QXFJd2cva1F6Wi9iQ2NUcEd2dWtXTk55?= =?utf-8?Q?Bp7f43kAu6yA8lLqud9TtVG0AA6uKMu2WA?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2021 18:18:37.8224 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: b98f1ee2-a104-4378-de6f-08d8b401d1aa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y3mUITpRRS4dfnKJ5a6FGAn32HFNsuRVDfUWhFRaVmC9KxYoSFFS9Y/hKM7LVtvHTiP3HiEkD4CWZxrIGsktow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0840 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 18:18:53 -0000 --hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz Content-Type: multipart/mixed; boundary="eTGCNrk7azIPvB4yMHNEpBOBF0S2n2hNo" --eTGCNrk7azIPvB4yMHNEpBOBF0S2n2hNo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, On 2021-01-08 18:17, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > Thanks for this. ~snips >> >> * Section 4 says: "The token to use ... any troubleshooting." >> >> Do you actually mean the highest block number received so far under= that >> Request-Tag, or the highest within the current set of MAX_PAYLOADS >> payloads for which the server is requesting some missing blocks? >> >> The new example in Section 5 seems to cover the latter, which I gue= ss is >> what you intend. > [Jon] Not sure that it really makes any difference. Have updated the t= ext to try to clarify > OLD > The token to use for the response SHOULD be the token that was used in = the highest block number received payload. Note that the use of any recei= ved token would work, but providing the one used in the highest received = block number will aid any troubleshooting. The client will use the token = to match the request to find what Request-Tag value is currently being us= ed. > NEW > The token to use for the response SHOULD be the token that was used in = the highest block number received so far with the same Request-Tag value.= Note that the use of any received token with the same Request-Tag would = work, but providing the one used in the highest received block number wil= l aid any troubleshooting. The client will use the token to determine wha= t is the previously sent request to obtain the Request-Tag value to be us= ed. =3D=3D>MT Looks better. To clarify, I meant Figure 5 (not Section 5), where the response with Message ID M:0x91 uses Token T:0xe0. That's matching with the request with Message ID M:0x19, i.e. the received payload with the highest block number *in the current MAX_PAYLOADS payload set* to be still completed. If the SHOULD above was followed, that response would have Token T:0xeb, to match with the one used in "the highest block number received so far", i.e. block number 10 in the request with Message ID M:0x1b. But as per the text above, either Token value is fine to use in the response, so the example is correct anyway. <=3D=3D >> - Figure 10, all responses should have ET=3D24 > [Jon] Fixed (I only found one) =3D=3D>MT The other occurrence is the very last response, with Message ID M:0x9b :-= ) Otherwise, it looks good to me. Thank you! Best, /Marco <=3D=3D > ~Jon >> >> Best, >> /Marco >> >> >> On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> Thanks for this - and it is good to have another set of eyes checking= things >> through. >>> Updates have been pushed to >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi= th >>> ub.com%2Fcore-wg%2Fnew- >> block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 >> C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e >> 8%7 >> C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi >> MC4wLjAwMD >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D >> LN79 >> Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 >> and the >>> differences with the draft can be found at >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w. >>> ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- >> block%26url2%3Dhttps%3 >>> A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- >> block%2Fmaster%2Fdraf >>> t-ietf-core-new- >> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 >> 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% >> 7C0% >> 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 >> wLjAwMDAiL >> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc >> 2vkC >>> 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 >>> >>> Otherwise, please see inline. >>> >>> Regards >>> >>> Jon >>> >>>> -----Original Message----- >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>> Sent: 07 January 2021 12:17 >>>> To: supjps-ietf@jpshallow.com; christian@amsuess.com; >>>> draft-ietf-core-new- block@ietf.org >>>> Cc: dots@ietf.org; core@ietf.org >>>> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >>>> >>>> Hi, >>>> >>>> Thanks for this revision and for addressing my comments already in >>>> version -03. >>>> >>>> Please, see below some more comments on this version -04. >>>> >>>> Best, >>>> /Marco >>>> >>>> >>>> * s/There are one or more missing CBOR encoded missing block >>>> numbers./There are one or more CBOR encoded missing block numbers. >>> [Jon] Fixed. >>>> * Section 4 now includes the new paragraph: "The token to use for >>>> the response SHOULD be the token that was used in the highest block >>>> number received payload. The Q-Block1 Option from the same packet >>>> SHOULD be included." >>> [Jon] The Q-Block1 option actually is not needed as it can be derived= by >> the client from the remembered token (which is used to derive the >> Request-Tag. >>> OLD >>> The Q-Block1 Option from the same packet SHOULD be included. >>> NEW >>> The client will use the token to match the request to find what >>> Request-Tag value is currently being used. Providing the highest >>> received block number will aid any troubleshooting. >>> >>>> Consistently, the example in Figure 5 should also have >>>> QB1:3/0/1024 in the >>>> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 >>>> response with Token T:0xe4. >>> [Jon] No change now needed. >>>> Since "SHOULD" is used, when is it still fine or expected to not >>>> include Q- >>>> Block1 in a 4.08 response? >>> [Jon] Q-Block1 is no longer needed. >>>> * When commenting the example in Figure 5, Section 9.1 reads: "The >>>> Token just needs to be one of those that have been received for this= >>>> Request-Tag, so the client can derive the Request-Tag." >>>> >>>> Should this not be aligned with the SHOULD used in Section 4 abou= t >>>> using the Token from the same packet conveying the highest block >> number? >>> [Jon] Agreed >>>> You explained in your mail that the client keeps tracking all >>>> Tokens in the burst anyway, so maybe it's better to rather align the= >>>> text in Section 4 with what suggested here in Section 9.1, i.e. >>>> responding with any of those Token values is just fine. >>> [Jon] I think that it is useful for the client to have a hint about >>> what is the latest block number received even if it does not make use= >>> it - it may help in debugging from packet captures etc. which is why = I >> added in the SHOULD in section 4. So, I would prefer to align this wi= th >> section 4 OLD The Token just needs to be one of those that have been >> received for this >>> Request-Tag, so the client can derive the Request-Tag. >>> NEW >>> The token used in the response should be the token that was used in t= he >> highest block number received payload. The client can then derive the >> Request-Tag by matching the token with the sent request.. >>>> In such a case, the Q-Block1 option included in the 4.08 response= >>>> has still to be the one from the request conveying the highest block= >> number. >>>> Correct? >>> [Jon] We are now dropping the need for Q-Block1 in the response. >>>> * The new text in Section 6.2 says: "... and the situation >>>> re-evaluated for another 24 hour period until there is no report of >>>> missing payloads under normal operating conditions." >>>> >>>> When that happens, I suppose MAX_PAYLOADS is right away restored >>>> to the intended value, i.e. it is not incremented by 1 to start >>>> another 24-hour period evaluation. Correct? >>> [Jon] Updated for clarification >>> OLD >>> report of missing payloads under normal operating conditions.= Note >>> that the CoAP peer will not know about the MAX_PAYLOADS chang= e >>> until NEW >>> report of missing payloads under normal operating conditions.= The >> newly >>> derived value for MAX_PAYLOADS should be used for both ends o= f this >>> particular CoAP peer link. Note >>> that the CoAP peer will not know about the MAX_PAYLOADS chang= e >>> until >>>> * Section 6.2 says: "The request that the client sends to acknowledg= e >>>> the receipt of all the current set of MAX_PAYLOADS payloads SHOULD >>>> contain a special case Q-Block2 Option with NUM set to the first >>>> block of the next set of MAX_PAYLOADS payloads and the M bit set to = 1." >>>> >>>> Is it possible to reflect this in the example of Figure 6? It woul= d >>>> require the body to have more than MAX_PAYLOADS blocks thus >> resulting >>>> in more bursts, which would be inherited by the examples in Figure 7= and >> Figure 8. >>> [Jon] Examples updated to include this information >>>> * In Section 9, it would be good to have the parameters defined in >>>> Section >>>> 6.2 and their values reflected in the examples, when applicable. >>>> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked >>>> retransmissions are presumably due sometimes to MAX_PAYLOADS >> compared >>>> against the value of the latest received Q-Block1/Q-Block2, while >>>> sometimes to NON_RECEIVE_TIMEOUT. >>> [Jon] Examples updated to include this information >>>> * In the example in Figure 6, shouldn't the first request from the >>>> client have the M bit set to 1 in the Q-Block2 option, i.e. as >>>> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the >>>> request is in fact for the block 0 and for all of the remaining bloc= ks within >> the body. >>> [Jon] Good catch - corrected. >>> >>> ~Jon >>>> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: >>>>> Hi Christian, >>>>> >>>>> Once again, thank you for the comprehensive review. >>>>> >>>>> Responses part 2. A new version (-04) of the draft has been >>>>> published and can be found at >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= t >>>> a >>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- >>>> block%2F&data=3D04%7C01 >>>> >> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 >>>> 9cf0 >>>> >> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown >>>> %7CTWFpb >>>> >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >>>> 6Mn0 >>>> >> %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j >>>> gTY%3D&am >>>>> p;reserved=3D0 >>>>> >>>>> >>>>> Part 1 responses were covered in the main by version -03, so you ma= y >>>>> want to look at the -02 to -04 differences. >>>>> >>>>> The Congestion Control section has been re-written to simplify how >>>>> things work and has a new set of definitions. There is a separation= >>>>> of Confirmable and Non-Confirmable Congestion Control with the >>>>> stated assumption that all of a body is sent as Non-Confirmable or >> Confirmable. >>>>> Otherwise, see inline. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>> >>>>>> * The list of pros and cons (with the cons being almost trivial) d= oes >>>>>> not explain to the reader why these are not a replacement; I sug= gest >>>>>> to add: >>>>> [Jon] Another disadvantage addition >>>>> NEW >>>>> To reduce the transmission times for CON transmission of large >>>>> bodies, NSTART needs to be increased from 1, but this affects >>>>> congestion control where other parameters need to be tuned (Sectio= n >>>>> 4.7 of [RFC7252]). Such tuning is out of scope of this document. >>>>> >>>>>> * "If the client transmits a new body of data with a new Request-T= ag >>>>>> to": Processing parallel requests is something Request-Tag opens= up. I >>>>>> don't see why there's a MUST to that; the server certainly MAY d= rop >>>>>> the old request, but it may just as well process them in paralle= l. >>>>> [Jon] The intent here was that garbage collection would take place >>>>> sooner than later - especially when running in a lossy environment >>>>> and the client has updated information to transmit. I agree that >>>>> Request-Tag enables the possibility of sending multiple block >>>>> requests with different payloads, and so there is a possibility tha= t >>>>> the client starts sending body A, then decides to send body B and >>>>> terminate A, but a packet from B arrives before a packet from body = A >>>>> is received and so >>>> things fail as A does not complete. >>>>> OLD >>>>> If the client transmits a new body of data with a new Request-Ta= g to >>>>> the same resource on a server, the server MUST remove any partia= lly >>>>> received body held for a previous Request-Tag for that resource.= >>>>> NEW >>>>> If a server receives payloads with different Request-Tags for the= >>>>> same resource, it should continue to process all the bodies as it >>>>> has no way of determining which is the latest version, or which >>>>> body, if any, the client is terminating the transmission for. >>>>> >>>>> If the client elects to stop the transmission of a complete body,= it >>>>> SHOULD "forget" all tracked tokens associated with the body's >>>>> Request-Tag so that a reset message is generated for the invalid >>>>> token in the 4.08 (Request Entity Incomplete) response. The server= >>>>> on receipt of the reset message SHOULD delete the partial body. >>>>> END >>>>> >>>>>> * "If the server receives a duplicate block with the same Request-= Tag": >>>>>> Why? Being silent is the default on nonterminal blocks alredy, b= ut in >>>>>> a situation like figure 5 if the 2.04 is lost, that rule would m= ake >>>>>> it impossible for the client to ever get a successful response. >>>>>> >>>>>> A better rule here may be to say that it processes it all the sa= me >>>>>> (and if the payload is distinct from the first transmission's pa= yload, >>>>>> it should err out.) >>>>> [Jon] Fair point >>>>> OLD >>>>> If the server receives a duplicate block with the same Request-T= ag, >>>>> it SHOULD silently ignore the packet. >>>>> NEW >>>>> If the server receives a duplicate block with the same Request-T= ag, >>>>> it SHOULD ignore the payload of the packet, but MUST still >>>>> respond as if the block was received for the first time. >>>>>> * "If the server receives multiple requests (implied or otherwise)= for >>>>>> the same block, it MUST only send back one instance of that bloc= k.": >>>>>> This might be read as "ever" rather than "per incoming request",= >> where >>>>>> probably the latter is meant. >>>>> [Jon] This text has already been updated following another review >>>>> "OLD If the server receives multiple requests >>>>> (implied or otherwise) for the same block, it MUST only send bac= k one >>>>> instance of that block. >>>>> NEW >>>>> If the request includes multiple Q-Block2 >>>>> Options and these options overlap (e.g., combination of M being = set >>>>> (this and all the later blocks) and being unset (this individual= >>>>> block)) resulting in an individual block being requested multipl= e >>>>> times, the server MUST only send back one instance of that block= =2E >>>>> This behavior is meant to prevent amplification attacks." >>>>> >>>>>> * "The ETag Option MUST NOT be used": This is more a factural than= a >>>>>> normative statement; it *can* not be used there as the server wo= uld >>>>>> respond thusly. It may be used, but then that indicates that the= >>>>>> client is trying to verify a freshness. (However, the client sho= uld >>>>>> not *start* sending an ETag once it learned the current resource= 's >>>>>> ETag when still attempting to pull out more blocks, but that's a= lso not >>>>>> a normative requirement but a consequence of those two requests >> not >>>>>> being matchable any more.) >>>>> [Jon] OK >>>>> OLD >>>>> The ETag Option MUST NOT be used in the request as the server co= uld >>>>> respond with a 2.03 (Valid Response) with no payload. If the se= rver >>>>> responds with a different ETag Option value (as the resource >>>>> representation has changed), then the client SHOULD drop all the= >>>>> payloads for the current body that are no longer valid. >>>>> NEW >>>>> The ETag Option should not be used in the request for missing >>>>> blocks as the server could respond with a 2.03 (Valid Response) wit= h >>>>> no payload. It can be used in the request if the client wants to >>>>> check the freshness of the currently cached body response. >>>>> >>>>> If the server detects part way through a body transfer that the >>>>> resource data has changed and the server is not maintaining a cache= d >>>>> copy of the old data, then the body response SHOULD be restarted >>>>> with a different ETag Option value. Any subsequent missing block >>>>> requests MUST respond using the latest ETag Option value. >>>>> >>>>> If the server responds during a body update with a different ETag >>>>> Option value (as the resource representation has changed), then the= >>>>> client should treat the partial body with the old ETag as no longer= >>>>> being >>>> fresh. >>>>> END >>>>>> * "then the client SHOULD drop all the payloads for the current bo= dy": >>>>>> "Drop" is overly prescriptive; the client may well keep them, bu= t >>>>>> just can't consider them fresh any more. (If the client has ampl= e >>>>>> caching abilities, they might come in handy if the resource goes= back >>>>>> to that ETag state). Same for later "the client MUST remove any >>>>>> partially received". >>>>> [Jon] See previous response, otherwise OLD >>>>> If the server transmits a new body of data (e.g., a triggered >>>>> Observe) with a new ETag to the same client as an additional >>>>> response, the client MUST remove any partially received body hel= d for >>>>> a previous ETag. >>>>> NEW >>>>> If the server transmits a new body of data (e.g., a triggered >>>>> Observe) with a new ETag to the same client as an additional >>>>> response, the client should remove any partially received body h= eld >> for >>>>> a previous ETag for that resource as it is unlikely the missing >>>>> blocks can be retrieved. >>>>>> * "For Confirmable transmission, the client SHOULD continue to": A= s >>>>>> above in the other direction, that's not news. >>>>> [Jon] Again, we are not looking for a response (well, a request in >>>>> this case as needed by Block2), just an ACK OLD >>>>> For Confirmable transmission, the client SHOULD continue to >>>>> acknowledge each packet as well as issuing a separate GET, POST,= PUT, >>>>> FETCH, PATCH, or iPATCH for the missing blocks. >>>>> NEW >>>>> For Confirmable transmission, the server continues to acknowledg= e >>>>> each packet, but a response is not required (whether separate or >>>>> piggybacked) until successful receipt of the body or, if some of = the >>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>> retransmit missing payloads response is needed. >>>>>> * "If there is insufficient space to create a response PDU": I don= 't >>>>>> understand what that means. (Where are request options reflected= >>>>>> back?). >>>>> [Jon] This was triggered by a question by Michael Richardson " So, >>>>> given a Christmas-Tree-Packet (largest packet, every possible optio= n >>>>> space used, every extension turned on...) how much data can I get >>>>> back? :-)" and not fully thought through. >>>>> It could happen though with Location-Path, Location-Query, Q-Block2= , >>>>> ETag, >>>>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in >>>>> response to a POST. >>>>> OLD >>>>> If there is insufficient space to create a response PDU with a b= lock >>>>> size of 16 bytes (SZX =3D 0) to reflect back all the request opt= ions as >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned witho= ut >>>>> the Size2 Option. >>>>> NEW >>>>> If there is insufficient space to create a response PDU with a b= lock >>>>> size of 16 bytes (SZX =3D 0) to send back all the response optio= ns as >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned witho= ut >>>>> the Size1 Option. >>>>> >>>>>> * "If the client requests missing blocks, this is treated as a new= >>>>>> request.": I don't think the client should even make these foll= ow-up >>>>>> requests Observe, as it already has an ongoing observation. The= y'd be >>>>>> sent on a different token too, so setting Observe would be open= ing >>>>>> observation up on that token, which AFAIU is not intended. (Fig= ure 7 >>>>>> example looks good to me in that respect.) >>>>>> >>>>>> (It may make sense to ask the client to keep Observe to make th= e >>>>>> requests matchable just for the sake of staying in atomic-reque= st >>>>>> mode. Either way, the server should then not accept that observ= ation >>>>>> as it's not for a block 0.) >>>>> [Jon] The intent here was that just a new Token should be used. >>>>> OLD >>>>> If the client requests missing blocks, this is treated as a new >>>>> request. The Observe value may change but MUST still be reporte= d. >>>>> If the ETag value changes then the previously received partial b= ody >>>>> should be destroyed and the whole body re-requested. >>>>> NEW >>>>> If the client requests missing blocks, this is treated as a new >>>>> Request and the Observe Option MUST NOT be included. If the ET= ag >>>> value >>>>> changes, then the previously received partial body >>>>> should be considered as not fresh and the whole body re-requeste= d. >>>>> >>>>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can= >> be >>>>>> matched by the token to a unique request that already had a >>>>>> Request-Tag, and the client needs to have kept that token around= >>>>>> matched to the transfer to make sense of it. >>>>>> >>>>>> No need to move that value around between subsystems, and just >>>>>> dropping it from here would also remove the need for the "If the= >>>>>> client does not recognize the Request-Tag" clause (which would >>>>>> otherwise need clarification as to what it'd mean if it recogniz= es it >>>>>> but it doesn't match what the request was for). >>>>> [Jon] Good question - it does make sense for the Request-Tag to be >>>>> tracked alongside the Token in the client. >>>>> OLD >>>>> The data payload of the 4.08 (Request Entity Incomplete) Respons= e >>>>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR enc= oded >>>>> Request-Tag followed by 1 or more missing CBOR encoded missing >> block >>>>> numbers. >>>>> NEW >>>>> The data payload of the 4.08 (Request Entity Incomplete) respons= e >>>>> is encoded as a CBOR Sequence [RFC8742]. There are one or more >>>> missing >>>>> CBOR encoded missing block numbers. >>>>> >>>>> OLD >>>>> ; This defines an array, the elements of which are to be use= d >>>>> ; in a CBOR Sequence: >>>>> payload =3D [request-tag, + missing-block-number] >>>>> request-tag =3D bstr >>>>> ; A unique block number not received: >>>>> missing-block-number =3D uint >>>>> NEW >>>>> ; This defines an array, the elements of which are to be use= d >>>>> ; in a CBOR Sequence: >>>>> payload =3D [+ missing-block-number] >>>>> request-tag =3D bstr >>>>> ; A unique block number not received: >>>>> missing-block-number =3D uint >>>>> >>>>> OLD >>>>> A 4.08 (Request Entity Incomplete) Response Code returned with >>>>> Content-Type "application/missing-blocks+cbor-seq" indicates tha= t >>>>> some of the payloads are missing and need to be resent. The cli= ent >>>>> then re-transmits the missing payloads using the Request-Tag and= >>>>> Q-Block1 to specify the block number, SZX, and M bit as appropri= ate. >>>>> The Request-Tag value to use is determined from the payload of t= he >>>>> 4.08 (Request Entity Incomplete) Response Code. If the client d= oes >>>>> not recognize the Request-Tag, the client can ignore this respon= se. >>>>> NEW (option presentation has been reformatted) >>>>> 4.08 (Request Entity Incomplete) >>>>> >>>>> This Response Code returned with Content-Type "application/ >>>>> missing-blocks+cbor-seq" indicates that some of the payloads are >>>>> missing and need to be resent. The client then retransmits the >>>>> missing payloads using the same Request-Tag, Size1 and Q-Block1 t= o >>>>> specify the block number, SZX, and M bit as appropriate. >>>>> >>>>> >>>>> The Request-Tag value to use is determined from the token in the >>>>> 4.08 (Request Entity Incomplete) response and then finding the >>>>> matching client request which contains the Request-Tag that is >>>>> being used for this Q-Block1 body. END >>>>>> * "limit the array count to 23 (Undefined value)": 23 is the maxim= um >>>>>> length of a zero-byte length indication, not indefinite-length (= 31). >>>>>> Both using 23 and 31 here makes sense (up to 23 to have definite= >>>>>> length that can be updated in-place, or exceeding that switch to= >>>>>> indefinite length if they still fit), but the paragraph seems to= be >>>>>> mixing them up. >>>>> [Jon] OK >>>>> OLD >>>>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count to= 23 >>>>> (Undefined value) so that the array data byte can be updated = with >>>>> the overall length once the payload length is confirmed or li= mited >>>>> to MAX_PAYLOADS count. >>>>> NEW >>>>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit >>>>> the array count to >>>>> 23 so that the initial byte with the array major type and dat= a >>>>> length in the additional information can be updated with the overal= l >>>>> count once the payload count is confirmed. Further restricting the= >>>>> count to MAX_PAYLOADS means that congestion control is less likely >>>>> to be >>>> invoked on the server. >>>>>> * "Each new request MUST use a unique token": Like above, this is >>>>>> stating something that's not intended to be changed. >>>>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty >>>>> token values are acceptable. Hence this statement. >>>>>> Congestion Control: >>>>>> >>>>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is >>>> subjected >>>>>> to PROBING_RATE.": That is unexpected here. At most one such >>>>>> response is sent to each request message, so why is additional >>>>>> congestion control needed? >>>>> [Jon] The intention here was that in the previous paragraph that it= >>>>> was not the individual packets that are subject to PROBING_RATE, bu= t >>>>> a single body comprising of multiple packets is subject to >>>>> PROBRING_RATE >>>>> - and hence limiting any individual responses to PROBING_RATE rathe= r >>>>> than the potentially full set of responses OLD >>>>> PROBING_RATE parameter in CoAP indicates the average data rate t= hat >>>>> must not be exceeded by a CoAP endpoint in sending to a peer >> endpoint >>>>> that does not respond. The body of blocks will be subjected to >>>>> PROBING_RATE (Section 4.7 of [RFC7252]). >>>>> NEW >>>>> PROBING_RATE parameter in CoAP indicates the average data rate t= hat >>>>> must not be exceeded by a CoAP endpoint in sending to a peer >> endpoint >>>>> that does not respond. The single body of blocks will be subjec= ted to >>>>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual pack= ets. >>>>> If the wait time between sending bodies that are not being >>>>> responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, >>>> then the >>>>> gap time is limited to NON_PROBING_WAIT. >>>>> >>>>> Note: For the particular DOTS application, PROBING_RATE and other >>>>> transmission parameters are negotiated between peers. Even when >>>>> not negotiated, the DOTS application uses customized defaults as >>>>> discussed in Section 4.5.2 of [RFC8782]. >>>>> END >>>>>> On the other hand, *ever* NON request is subject to PROBING_RAT= E, >> so >>>>>> why point out the body of blocks and "GET or similar" particula= rly? >>>>> [Jon] It is only GET or FETCH. The intention here is to not reques= t >>>>> bodies of data at too high a rate. >>>>> OLD >>>>> Each NON GET or similar request using Q-Block2 Option is subject= ed to >>>>> PROBING_RATE. >>>>> NEW >>>>> Each NON GET or FETCH request using Q-Block2 Option is subjected= >>>>> to PROBING_RATE. >>>>>> * "a delay is introduced of ACK_TIMEOUT": As I understand >>>> MAX_PAYLOADS, >>>>>> this is (rather implicitly) introduced as the package count up t= o >>>>>> which it is OK to exceed PROBING_RATE temporarily (but after tha= t it >>>>>> kicks in all the harder by requiring to wait until complete-sent= -bytes >>>>>> over PROBING_RATE has expired). If that holds, at that time a mu= ch >>>>>> larger delay than just ACK_TIMEOUT is needed to get a response f= rom >>>>>> the server: About 3 hours (see later note on parameters). >>>>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write >>>>> of Congestion Control section. >>>>>> This is the crucial point in the document, and for it a recommen= dation >>>>>> alone is not good enough. The protocol can be run with a vastly >>>>>> increased PROBING_RATE (however externally determined) and from >>>> the >>>>>> point of MAX_PAYLOADS just observe it. Or it has to get feedback= >> from >>>>>> the server; a single 4.08 is probably enough to kick off another= >>>>>> vollley of blocks. (How many? MAX_PAYLOADS for every response?).= >>>>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing = any >>>>>> good. >>>>> [Jon] See re-write of Congestion Control section where things shoul= d >>>>> now be simpler and more logical. There is an introduction of new >>>>> variable definitions. >>>>>> * "For NON transmissions": This seems to imply that the full excha= nge >> of >>>>>> a body is either NON or CON; I don't see where that'd come from.= I'd >>>>>> have expected to read something like "Each individual request ca= n be >>>>>> NON or CON independent of the others. In particular, it can be >>>>>> convenient to send the ultimate payload...". >>>>> [Jon]The DOTS environment will only be using NON. To make >>>>> Congestion Control simple, the expectation is that all transmission= s >>>>> are NON or (not recommended) are all CON. The draft now generally >>>>> records this expectation. >>>>>> * "If a Confirmable packet is used, then the transmitting peer MUS= T >> wait >>>>>> for the ACK": Why? A NSTART > 1 would give it leisure to still >>>>>> transmit. >>>>> [Jon] Text has been removed in the clean-up. >>>>>> * General on congestion control: It may help implementors if this = were >>>>>> split up into newly introduced rules and concepts (that is, >>>>>> MAX_PAYLOADS and the answer to whether you may send >>>> MAX_PAYLOADS en >>>>>> block again after having only even one response from the last ro= und, >>>>>> and probably the recommended parameters of the "Also on >>>> parameters" >>>>>> comment), and another subsection on how Q-Block behaves well >> when >>>>>> observing these. >>>>> [Jon] Should now be covered in the updated Congestion Control >> section. >>>>>> Caching: >>>>>> >>>>>> * "are not part of the cache key": How about "are removed as part = of >> the >>>>>> block assembly and thus do not reach the cache"? >>>>> [Jon] OK. >>>>> OLD >>>>> As the entire body is being cached in the proxy, the Q-Block1 an= d >>>>> Q-Block2 Options are not part of the cache key. >>>>> NEW >>>>> As the entire body is being cached in the proxy, the Q-Block1 an= d >>>>> Q-Block2 Options are removed as part of the block assembly and >>>>> thus do not reach the cache. >>>>>> * "When the next client completes building the body": If the proxy= >>>>>> chooses not to let them happen in parallel (which it may, see ab= ove >> on >>>>>> parallel requests, although the server might still not support i= t and >>>>>> cancel one of them), why bother letting the first finish just to= abort >>>>>> it? (IOW: If the proxy does not intend to see both through, whic= h it >>>>>> could if it held back the second until the first is through on t= he >>>>>> uplink, it could just as well err out of one of them early, but = it may >>>>>> also rather see both through.) >>>>> [Jon] It has to be assumed that traffic to/from the origin client >>>>> and origin server may not both support Q-Blockx and potentially may= >>>>> have a different SZX. Thus passing a request or a response through= >>>>> at the block level introduces a new set of challenges (but not >>>>> impossible to fix). To keep this simple, my thinking was that the >>>>> passing through can only take place at the body level. Again, the >>>>> arrival of packets is not necessarily sequential, so client A's bod= y >>>>> may start transmitting to the origin server first, but client B's >>>>> body starts to arrive first - the same being true for the proxy as = a >>>>> client may stop transmitting for whatever reason (restart, network = loss >> etc.). >>>>> However this is covered by the above update " If a server receives= >>>>> payloads with different Request-Tags for the same resource, it >>>>> should >>>> continue to process all the bodies". >>>>> OLD >>>>> and the new body representation transmission starts with a new >>>>> Request-Tag value. >>>>> NEW >>>>> and the new body representation transmission starts with a new >>>>> Request-Tag value. Note that it cannot be assumed that the prox= y >>>>> will always receive a complete body from a client. >>>>>> * Examples: >>>>>> >>>>>> * Figure 5: The ... between e3 request and response indicate the= >>>>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose >>>> there >>>>>> should be the same kind of delay between the failed e5 transmi= ssion >>>>>> and the e4 response. >>>>> [Jon] Agreed and added in >>>>>> * If the second burst had 3 requests out of which 2 made it, is = there >>>>>> any guidance for which of them the 4.08 would come back on? (I= n the >>>>>> end, none of them is terminal). >>>>> [Jon] The client should tracking all Tokens of the burst (hence >>>>> implementation note about bottom 32bits unique and top 32 bits >>>>> matching block number for ease of tracking) for a response and so i= t >>>>> will make no difference at to which token is used for the 4.08 >>>>> response. From an implementation perspective, it probably is easie= r >>>>> to track the last opaque token that has the same Request-Tag. >>>>> OLD >>>>> missing ones in one go (Figure 5). It does so by indicating whi= ch >>>>> blocks have been received in the data portion of the response. >>>>> NEW >>>>> missing ones in one go (Figure 5). It does so by indicating whi= ch >>>>> blocks have been received in the data portion of the response. >>>>> The Token just needs to be one of those that have been received for= >>>>> this Request-Tag , so the client can derive the Request-Tag. >>>>>> * If that e4 response gets lost, does the whole mechanism recove= r >> from >>>>>> it in any way? >>>>> [Jon] In this example, if e4 and e5 get lost, there will be no >>>>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to >>>>> whether it sends the request again or gives up. See 9.1 >>>>> "Under high levels of traffic loss, the client can elect not to r= etry >>>>> sending missing blocks of data. This decision is implementation= >>>>> specific." >>>>>> Generally, the all-NON and all-CON examples don't look to me l= ike >>>>>> what I'd be doing with this spec; the mixed "a CON every >>>>>> MAX_PAYLOADS" appears much more realistic. >>>>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS >>>>> environment (up to 93 secs timeout per payload with the defaults). >>>>> Hence why we are separating out the NON / CON usage. >>>>>> * Figure X: The request ahs M unset and thus indicats a request = for >>>>>> just that block. If more than one is expected, it should say >>>>>> QB2:0/1/1024. >>>>> [Jon] With Figure 7, with the M bit set, block 3 would get returned= >>>>> for a second time. Draft-ietf-core-new-block-03 also has a Figure = 8 >>>>> which does exactly what you describe. >>>>>> * New Content Format: I think this needs a media type registration= to >> go >>>>>> with it first; based on that, a content format can be registered= =2E >>>>> [Jon] Med has responded to this and draft updated. >>>>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm >> not >>>>>> sure >>>>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is >>>> defined >>>>>> in terms of reliable transmission, but used for NONs as well. (S= o is >>>>>> the alternative ot 2x ACK_TIMEOUT). >>>>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and >> ACK_TIMEOUT >>>> in >>>>> a NON environment. Hence re-write of Congestion Control section >>>>> defining new variables that can be used for NON. >>>>>> For the purpose of delaying a 4.08 or a follow-up GET, it may ma= ke >>>>>> more sense to define a new parameter based on MAX_LATENCY and >> the >>>>>> time >>>>>> it takes the sender to pump out the options (which I don't think= we >>>>>> have a good factor for, but may even be negligible here). >>>>>> >>>>>> Could read like this: >>>>>> >>>>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by >>>> default >>>>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / >>>> BANDWIDTH. >>>>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, >>>>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. >>>>> >>>>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D 10= 0.1. >>>>> So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbp= s >>>>> makes MAX_BLOCK_JITTER 200 seconds. >>>>>> > >>>>>> > With Q-Block2, a client can ask for any missing blocks after n= ot >>>>>> > having received any further response for the duration of >>>>>> > MAX_BLOCK_JITTER. >>>>> [Jon] 100+ seconds delay is way too much time to wait for any >>>>> missing blocks in my opinion. >>>>> >>>>> [Jon] RFC7252 also states (and the intention is that recovery works= >>>>> well) " as MAX_LATENCY is not >>>>> intended to describe a situation when the protocol works well= , but >>>>> the worst-case situation against which the protocol has to gu= ard." >>>>>> > >>>>>> > With Q-Block1, a server holds off any response for >> MAX_BLOCK_JITTER >>>>>> > unless all blocks have been received. Only then it evaluates >> whether >>>>>> > to respond with a 2.0x code, a 4.08 with payload, or not at al= l >>>>>> > (because it responded to a later request). >>>>> [Jon] I am not convinced that this is necessarily the way to go. >>>>> The new Congestion Control more cleanly handles this. >>>>>> This also brings me back to the earlier matter of 2.31: What is = a >>>>>> server supposed to send when no packages were lost, but it's pas= ing >>>>>> the timeout and wants to help the client flush out more packages= by >>>>>> confirming something? It says 4.08 in 3.3, but it's not like the= re's a >>>>>> hole in the contiguous range. Does it need to send 4.08 enumerat= ing >>>>>> all (or at least some) numbers between the first unreceived and >> what's >>>>>> indicated by Size1? Or can it just send 2.31 and the client know= s all >>>>>> it needs to know b/c the response came to the largest block that= was >>>>>> sent and 2.31 indicates that everything is good up to that point= ? >>>>> [Jon] The previous draft states (under Congestion Control) that the= >>>>> client waits for ACK_TIMEOUT before transmitting the next set of >>>>> MAX_PAYLOADS blocks. The server should wait for "two times >>>>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps >>>>> having a new name for ACK_TIMOUT I think that these are reasonable >>>>> values for Non-Confirmable - and are used in the new Congestion >>>>> Control >>>> section. >>>>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) as = a >>>>> signal to say that all of the current MAX_PAYLOADS payloads of a >>>>> body have been received, so allowing the client to continue >>>>> transmitting the next set of MAX_PAYLOADS payloads without the need= >>>>> to wait any >>>> longer. >>>>>> * Also on parameters: This document is describing flow control stu= ff >>>>>> around a situation CoAP was not originally designed for. Wouldn'= t it >>>>>> make sense to include a set of parameters (PROBING_RATE, >>>> MAX_LATENCY, >>>>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that= >>>>>> PROBING_RATE will be left to 1 byte/second for any DOTS applicat= ion >>>>>> using this (for sending 10KiB in the initial 10-package MAX_PAYL= OADS >>>>>> burst would mark that connection as unusable for about 3 hours i= f >> they >>>>>> all get lost), so better give justifiable numbers here than rely= on >>>>>> implemnetors to come up with unreviewed numbers or disregard >>>>>> PROBING_RATE altogether. >>>>> [Jon] Answered by Med, and some new text added. >>>>>> I don't know if it needs additional justification, but an increa= sed >>>>>> N_START may be justifiable there. >>>>> [Jon] It may be, but tuning the other associated parameters is >>>>> really out of the cope of this draft. This text has been added NEW >>>>> Congestion control for CON requests and responses is specified in >>>>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART wi= ll >>>>> need to be increased from 1. However, the other CON congestion >>>>> control parameters will need to be tuned to cover this change. T= his >>>>> tuning is out of scope of this document as it is expected that al= l >>>>> requests and responses using Q-Block1 and Q-Block2 will be Non- >>>>> confirmable. >>>>>> * Somewhere (never comes up but I think it should): When CONs are >>>> used, >>>>>> a 4.08 (or 2.31?) response to a later request can indicate to th= e >>>>>> client that an earlier CON request has been processed successful= ly. If >>>>>> the client can match that up (and it should be able to), then it= can >>>>>> (and should) cancel that particular CON request. >>>>> [Jon] I think that this is covered by my update above with the text= " >>>>> NEW >>>>> For Confirmable transmission, the server continues to acknowledg= e >>>>> each packet, but a response is not required (whether separate or >>>>> piggybacked) until successful receipt of the body or, if some of = the >>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>> retransmit missing payloads response is needed." >>>>> >>>>> And in my previous part 1 response (updated) NEW For Confirmable >>>>> transmission, the server continues to acknowledge each packet, but= >>>>> a response is not required (whether separate or >>>>> piggybacked) until successful receipt of the body or, if some of t= he >>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>> retransmit missing payloads response is needed. >>>>>> Best regards >>>>>> Christian >>>>>> >>>>>> -- >>>>>> There's always a bigger fish. >>>>>> -- Qui-Gon Jinn >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>> w. >>>> >> ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc >>>> a%4 >>>> >> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 >>>> ecc4 >>>> >> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 >>>> eyJWIjoiMC >>>> >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& >>>> amp;sd >>>> >> ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >>>> -- >>>> Marco Tiloca >>>> Ph.D., Senior Researcher >>>> >>>> RISE Research Institutes of Sweden >>>> Division ICT >>>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >>>> SE-164 40 Kista (Sweden) >>>> >>>> Phone: +46 (0)70 60 46 501 >>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 >> c8 >> 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 >> 45709 >> 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >> oiV2luMz >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb >> mzIuz >>>> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 >>>> >> -- >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C8651a6788136434842= 2608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374572308622= 39405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dpo%2BnNJAbUW7Jf9cMFxoP8VXDd1%2= FfS%2BsyTl4dePY5A9o%3D&reserved=3D0 >> > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --eTGCNrk7azIPvB4yMHNEpBOBF0S2n2hNo-- --hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/4ofYACgkQ7iZktA5Y 2kM74QgAoiIMg+FOMHyDlHjlnsv/HX8jjxPKYfllQhH215i3LbuGKpnXH9DSQibk 4lsffuJVpBf4q0ZdRYcBeYF2XOHqlf+GmEk5q12zrN5ZuLZLBszXdIO1QUtBZKqj gSkii3Yg3buKqF7jS/s/jEvFQWzfGKx2ojmBBhFhD8Gp6EHUbet4LUFDNE2v4qCl h5FoOA0mXJuHr5kwfz6bEW2bYaklYIJ8yfr2i1fS+uLf+kCWvvKfc9r8YLQzOpCf 6j/9BgFFmDu8yn0i5gcCBUqqMpVdghdOixkVvJL5u8jQy0zxMXNJlzVwhZCQUOJf i0HVEULA967NhiZS5JMCnuRNrfY+Ag== =OSUY -----END PGP SIGNATURE----- --hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz-- From nobody Sun Jan 10 10:16:53 2021 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 55C443A1188; Sun, 10 Jan 2021 10:16:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dots-chairs@ietf.org, dots@ietf.org, kaduk@mit.edu, valery@smyslov.net X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161030261127.9566.17566918124883105195@ietfa.amsl.com> Date: Sun, 10 Jan 2021 10:16:51 -0800 Archived-At: Subject: [Dots] dots - Not having a session at IETF 110 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: Sun, 10 Jan 2021 18:16:51 -0000 Valery Smyslov, a chair of the dots working group, indicated that the dots working group does not plan to hold a session at IETF 110. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Jan 11 00:37:04 2021 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 68A793A16FF; Mon, 11 Jan 2021 00:37:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-dots-signal-call-home@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , valery@smyslov.net X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <161035422240.18652.17693628862790494424@ietfa.amsl.com> Date: Mon, 11 Jan 2021 00:37:02 -0800 Archived-At: Subject: [Dots] Magnus Westerlund's Abstain on draft-ietf-dots-signal-call-home-12: (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: Mon, 11 Jan 2021 08:37:03 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-dots-signal-call-home-12: Abstain 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-signal-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This protocol could have early on taken the decision to adhere to RFC6335 intention to preserve ports and thus been designed to share the port with the regular DOTS. As it is based on COAP and DTLS there are several mechanism one could have been using for demultiplexing that would have had little impact on the protocol and allowed it to be co-located on the same port. I really like to avoid this type of unnecessary assignments in the future. From nobody Mon Jan 11 02:33:13 2021 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 E5A0B3A09B7 for ; Mon, 11 Jan 2021 02:33:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ulLGepBZPqi1 for ; Mon, 11 Jan 2021 02:33:05 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 0EC753A09B9 for ; Mon, 11 Jan 2021 02:33:04 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kyuVP-0006MA-Ra; Mon, 11 Jan 2021 10:33:00 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> In-Reply-To: Date: Mon, 11 Jan 2021 10:33:10 -0000 Message-ID: <065301d6e805$286163c0$79242b40$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVQGW5zMSAr51FjWocxRxUA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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 Jan 2021 10:33:10 -0000 Hi Marco, The new updates have been pushed to https://github.com/core-wg/new-block = and the differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt The PR for the responses below can be found at = https://github.com/core-wg/new-block/pull/12 (a couple of minor nits = fixed since then which are in master) Otherwise lease see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 08 January 2021 18:19 > To:supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > On 2021-01-08 18:17, supjps-ietf@jpshallow.com wrote: > > Hi Marco, > > > > Thanks for this. >=20 > ~snips >=20 > >> > >> * Section 4 says: "The token to use ... any troubleshooting." > >> > >> Do you actually mean the highest block number received so far > >> under that Request-Tag, or the highest within the current set of > >> MAX_PAYLOADS payloads for which the server is requesting some > missing blocks? > >> > >> The new example in Section 5 seems to cover the latter, which I > >> guess is what you intend. > > [Jon] Not sure that it really makes any difference. Have updated = the > > text to try to clarify OLD The token to use for the response SHOULD = be > > the token that was used in the highest block number received = payload. > Note that the use of any received token would work, but providing the = one > used in the highest received block number will aid any = troubleshooting. The > client will use the token to match the request to find what = Request-Tag > value is currently being used. > > NEW > > The token to use for the response SHOULD be the token that was used = in > the highest block number received so far with the same Request-Tag = value. > Note that the use of any received token with the same Request-Tag = would > work, but providing the one used in the highest received block number = will > aid any troubleshooting. The client will use the token to determine = what is > the previously sent request to obtain the Request-Tag value to be = used. >=20 > =3D=3D>MT > Looks better. >=20 > To clarify, I meant Figure 5 (not Section 5), where the response with > Message ID M:0x91 uses Token T:0xe0. That's matching with the request > with Message ID M:0x19, i.e. the received payload with the highest = block > number *in the current MAX_PAYLOADS payload set* to be still = completed. >=20 > If the SHOULD above was followed, that response would have Token = T:0xeb, > to match with the one used in "the highest block number received so = far", > i.e. block number 10 in the request with Message ID M:0x1b. >=20 > But as per the text above, either Token value is fine to use in the = response, > so the example is correct anyway. [Jon] Changed highest to last (to simplify things), updated the examples = accordingly. Updated 2.01,2.04 and 2.31 code with which token to use. > <=3D=3D >=20 > >> - Figure 10, all responses should have ET=3D24 > > [Jon] Fixed (I only found one) >=20 > =3D=3D>MT > The other occurrence is the very last response, with Message ID M:0x9b = :-) [Jon] Got it - And M:0x9b updated to M:0xc3 to be consistent. ~Jon >=20 >=20 > Otherwise, it looks good to me. Thank you! >=20 > Best, > /Marco > <=3D=3D >=20 > > ~Jon > >> > >> Best, > >> /Marco > >> > >> > >> On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: > >>> Hi Marco, > >>> > >>> Thanks for this - and it is good to have another set of eyes > >>> checking things > >> through. > >>> Updates have been pushed to > >>> > >> > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit > >> h > >>> ub.com%2Fcore-wg%2Fnew- > >> block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 > >> > C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e > >> 8%7 > >> > C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > >> MC4wLjAwMD > >> > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D > >> LN79 > >> > Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 > >> and the > >>> differences with the draft can be found at > >>> > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >> w. > >>> ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- > >> block%26url2%3Dhttps%3 > >>> A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- > >> block%2Fmaster%2Fdraf > >>> t-ietf-core-new- > >> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 > >> > 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% > >> 7C0% > >> > 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > >> wLjAwMDAiL > >> > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc > >> 2vkC > >>> 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 > >>> > >>> Otherwise, please see inline. > >>> > >>> Regards > >>> > >>> Jon > >>> > >>>> -----Original Message----- > >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] > >>>> Sent: 07 January 2021 12:17 > >>>> To: supjps-ietf@jpshallow.com; christian@amsuess.com; > >>>> draft-ietf-core-new- block@ietf.org > >>>> Cc: dots@ietf.org; core@ietf.org > >>>> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > >>>> > >>>> Hi, > >>>> > >>>> Thanks for this revision and for addressing my comments already = in > >>>> version -03. > >>>> > >>>> Please, see below some more comments on this version -04. > >>>> > >>>> Best, > >>>> /Marco > >>>> > >>>> > >>>> * s/There are one or more missing CBOR encoded missing block > >>>> numbers./There are one or more CBOR encoded missing block > numbers. > >>> [Jon] Fixed. > >>>> * Section 4 now includes the new paragraph: "The token to use = for > >>>> the response SHOULD be the token that was used in the highest = block > >>>> number received payload. The Q-Block1 Option from the same = packet > >>>> SHOULD be included." > >>> [Jon] The Q-Block1 option actually is not needed as it can be > >>> derived by > >> the client from the remembered token (which is used to derive the > >> Request-Tag. > >>> OLD > >>> The Q-Block1 Option from the same packet SHOULD be included. > >>> NEW > >>> The client will use the token to match the request to find what > >>> Request-Tag value is currently being used. Providing the highest > >>> received block number will aid any troubleshooting. > >>> > >>>> Consistently, the example in Figure 5 should also have > >>>> QB1:3/0/1024 in the > >>>> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 > >>>> response with Token T:0xe4. > >>> [Jon] No change now needed. > >>>> Since "SHOULD" is used, when is it still fine or expected to = not > >>>> include Q- > >>>> Block1 in a 4.08 response? > >>> [Jon] Q-Block1 is no longer needed. > >>>> * When commenting the example in Figure 5, Section 9.1 reads: = "The > >>>> Token just needs to be one of those that have been received for > >>>> this Request-Tag, so the client can derive the Request-Tag." > >>>> > >>>> Should this not be aligned with the SHOULD used in Section 4 > >>>> about using the Token from the same packet conveying the highest > >>>> block > >> number? > >>> [Jon] Agreed > >>>> You explained in your mail that the client keeps tracking all > >>>> Tokens in the burst anyway, so maybe it's better to rather align > >>>> the text in Section 4 with what suggested here in Section 9.1, = i.e. > >>>> responding with any of those Token values is just fine. > >>> [Jon] I think that it is useful for the client to have a hint = about > >>> what is the latest block number received even if it does not make > >>> use it - it may help in debugging from packet captures etc. which = is > >>> why I > >> added in the SHOULD in section 4. So, I would prefer to align this > >> with section 4 OLD The Token just needs to be one of those that = have > >> been received for this > >>> Request-Tag, so the client can derive the Request-Tag. > >>> NEW > >>> The token used in the response should be the token that was used = in > >>> the > >> highest block number received payload. The client can then derive = the > >> Request-Tag by matching the token with the sent request.. > >>>> In such a case, the Q-Block1 option included in the 4.08 > >>>> response has still to be the one from the request conveying the > >>>> highest block > >> number. > >>>> Correct? > >>> [Jon] We are now dropping the need for Q-Block1 in the response. > >>>> * The new text in Section 6.2 says: "... and the situation > >>>> re-evaluated for another 24 hour period until there is no report = of > >>>> missing payloads under normal operating conditions." > >>>> > >>>> When that happens, I suppose MAX_PAYLOADS is right away = restored > >>>> to the intended value, i.e. it is not incremented by 1 to start > >>>> another 24-hour period evaluation. Correct? > >>> [Jon] Updated for clarification > >>> OLD > >>> report of missing payloads under normal operating = conditions. Note > >>> that the CoAP peer will not know about the MAX_PAYLOADS > >>> change until NEW > >>> report of missing payloads under normal operating > >>> conditions. The > >> newly > >>> derived value for MAX_PAYLOADS should be used for both = ends of > this > >>> particular CoAP peer link. Note > >>> that the CoAP peer will not know about the MAX_PAYLOADS > >>> change until > >>>> * Section 6.2 says: "The request that the client sends to > >>>> acknowledge the receipt of all the current set of MAX_PAYLOADS > >>>> payloads SHOULD contain a special case Q-Block2 Option with NUM = set > >>>> to the first block of the next set of MAX_PAYLOADS payloads and = the M > bit set to 1." > >>>> > >>>> Is it possible to reflect this in the example of Figure 6? It > >>>> would require the body to have more than MAX_PAYLOADS blocks thus > >> resulting > >>>> in more bursts, which would be inherited by the examples in = Figure > >>>> 7 and > >> Figure 8. > >>> [Jon] Examples updated to include this information > >>>> * In Section 9, it would be good to have the parameters defined = in > >>>> Section > >>>> 6.2 and their values reflected in the examples, when applicable. > >>>> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked > >>>> retransmissions are presumably due sometimes to MAX_PAYLOADS > >> compared > >>>> against the value of the latest received Q-Block1/Q-Block2, while > >>>> sometimes to NON_RECEIVE_TIMEOUT. > >>> [Jon] Examples updated to include this information > >>>> * In the example in Figure 6, shouldn't the first request from = the > >>>> client have the M bit set to 1 in the Q-Block2 option, i.e. as > >>>> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the > >>>> request is in fact for the block 0 and for all of the remaining > >>>> blocks within > >> the body. > >>> [Jon] Good catch - corrected. > >>> > >>> ~Jon > >>>> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > >>>>> Hi Christian, > >>>>> > >>>>> Once again, thank you for the comprehensive review. > >>>>> > >>>>> Responses part 2. A new version (-04) of the draft has been > >>>>> published and can be found at > >>>>> > >> > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat > >>>> a > >>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- > >>>> block%2F&data=3D04%7C01 > >>>> > >> > %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 > >>>> 9cf0 > >>>> > >> > bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown > >>>> %7CTWFpb > >>>> > >> > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > >>>> 6Mn0 > >>>> > >> > %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j > >>>> gTY%3D&am > >>>>> p;reserved=3D0 > >>>>> > >>>>> > >>>>> Part 1 responses were covered in the main by version -03, so you > >>>>> may want to look at the -02 to -04 differences. > >>>>> > >>>>> The Congestion Control section has been re-written to simplify = how > >>>>> things work and has a new set of definitions. There is a > >>>>> separation of Confirmable and Non-Confirmable Congestion Control > >>>>> with the stated assumption that all of a body is sent as > >>>>> Non-Confirmable or > >> Confirmable. > >>>>> Otherwise, see inline. > >>>>> > >>>>> Regards > >>>>> > >>>>> Jon > >>>>> > >>>>>> * The list of pros and cons (with the cons being almost = trivial) does > >>>>>> not explain to the reader why these are not a replacement; I > suggest > >>>>>> to add: > >>>>> [Jon] Another disadvantage addition NEW To reduce the = transmission > >>>>> times for CON transmission of large bodies, NSTART needs to be > >>>>> increased from 1, but this affects congestion control where = other > >>>>> parameters need to be tuned (Section > >>>>> 4.7 of [RFC7252]). Such tuning is out of scope of this = document. > >>>>> > >>>>>> * "If the client transmits a new body of data with a new = Request-Tag > >>>>>> to": Processing parallel requests is something Request-Tag = opens > up. I > >>>>>> don't see why there's a MUST to that; the server certainly = MAY drop > >>>>>> the old request, but it may just as well process them in = parallel. > >>>>> [Jon] The intent here was that garbage collection would take = place > >>>>> sooner than later - especially when running in a lossy = environment > >>>>> and the client has updated information to transmit. I agree that > >>>>> Request-Tag enables the possibility of sending multiple block > >>>>> requests with different payloads, and so there is a possibility > >>>>> that the client starts sending body A, then decides to send body = B > >>>>> and terminate A, but a packet from B arrives before a packet = from > >>>>> body A is received and so > >>>> things fail as A does not complete. > >>>>> OLD > >>>>> If the client transmits a new body of data with a new = Request-Tag to > >>>>> the same resource on a server, the server MUST remove any = partially > >>>>> received body held for a previous Request-Tag for that = resource. > >>>>> NEW > >>>>> If a server receives payloads with different Request-Tags for > >>>>> the same resource, it should continue to process all the bodies = as > >>>>> it has no way of determining which is the latest version, or = which > >>>>> body, if any, the client is terminating the transmission for. > >>>>> > >>>>> If the client elects to stop the transmission of a complete = body, it > >>>>> SHOULD "forget" all tracked tokens associated with the body's > >>>>> Request-Tag so that a reset message is generated for the invalid > >>>>> token in the 4.08 (Request Entity Incomplete) response. The > >>>>> server on receipt of the reset message SHOULD delete the partial > body. > >>>>> END > >>>>> > >>>>>> * "If the server receives a duplicate block with the same = Request- > Tag": > >>>>>> Why? Being silent is the default on nonterminal blocks = alredy, but > in > >>>>>> a situation like figure 5 if the 2.04 is lost, that rule = would make > >>>>>> it impossible for the client to ever get a successful = response. > >>>>>> > >>>>>> A better rule here may be to say that it processes it all the = same > >>>>>> (and if the payload is distinct from the first transmission's = payload, > >>>>>> it should err out.) > >>>>> [Jon] Fair point > >>>>> OLD > >>>>> If the server receives a duplicate block with the same = Request-Tag, > >>>>> it SHOULD silently ignore the packet. > >>>>> NEW > >>>>> If the server receives a duplicate block with the same = Request-Tag, > >>>>> it SHOULD ignore the payload of the packet, but MUST still > >>>>> respond as if the block was received for the first time. > >>>>>> * "If the server receives multiple requests (implied or = otherwise) for > >>>>>> the same block, it MUST only send back one instance of that = block.": > >>>>>> This might be read as "ever" rather than "per incoming > >>>>>> request", > >> where > >>>>>> probably the latter is meant. > >>>>> [Jon] This text has already been updated following another = review > >>>>> "OLD If the server receives multiple requests > >>>>> (implied or otherwise) for the same block, it MUST only send = back > one > >>>>> instance of that block. > >>>>> NEW > >>>>> If the request includes multiple Q-Block2 > >>>>> Options and these options overlap (e.g., combination of M = being set > >>>>> (this and all the later blocks) and being unset (this = individual > >>>>> block)) resulting in an individual block being requested = multiple > >>>>> times, the server MUST only send back one instance of that = block. > >>>>> This behavior is meant to prevent amplification attacks." > >>>>> > >>>>>> * "The ETag Option MUST NOT be used": This is more a factural = than a > >>>>>> normative statement; it *can* not be used there as the server > would > >>>>>> respond thusly. It may be used, but then that indicates that = the > >>>>>> client is trying to verify a freshness. (However, the client = should > >>>>>> not *start* sending an ETag once it learned the current = resource's > >>>>>> ETag when still attempting to pull out more blocks, but = that's also > not > >>>>>> a normative requirement but a consequence of those two = requests > >> not > >>>>>> being matchable any more.) > >>>>> [Jon] OK > >>>>> OLD > >>>>> The ETag Option MUST NOT be used in the request as the server > could > >>>>> respond with a 2.03 (Valid Response) with no payload. If the = server > >>>>> responds with a different ETag Option value (as the resource > >>>>> representation has changed), then the client SHOULD drop all = the > >>>>> payloads for the current body that are no longer valid. > >>>>> NEW > >>>>> The ETag Option should not be used in the request for missing > >>>>> blocks as the server could respond with a 2.03 (Valid Response) > >>>>> with no payload. It can be used in the request if the client = wants > >>>>> to check the freshness of the currently cached body response. > >>>>> > >>>>> If the server detects part way through a body transfer that the > >>>>> resource data has changed and the server is not maintaining a > >>>>> cached copy of the old data, then the body response SHOULD be > >>>>> restarted with a different ETag Option value. Any subsequent > >>>>> missing block requests MUST respond using the latest ETag Option > value. > >>>>> > >>>>> If the server responds during a body update with a different = ETag > >>>>> Option value (as the resource representation has changed), then > >>>>> the client should treat the partial body with the old ETag as no > >>>>> longer being > >>>> fresh. > >>>>> END > >>>>>> * "then the client SHOULD drop all the payloads for the current > body": > >>>>>> "Drop" is overly prescriptive; the client may well keep them, = but > >>>>>> just can't consider them fresh any more. (If the client has = ample > >>>>>> caching abilities, they might come in handy if the resource = goes > back > >>>>>> to that ETag state). Same for later "the client MUST remove = any > >>>>>> partially received". > >>>>> [Jon] See previous response, otherwise OLD > >>>>> If the server transmits a new body of data (e.g., a triggered > >>>>> Observe) with a new ETag to the same client as an additional > >>>>> response, the client MUST remove any partially received body = held > for > >>>>> a previous ETag. > >>>>> NEW > >>>>> If the server transmits a new body of data (e.g., a triggered > >>>>> Observe) with a new ETag to the same client as an additional > >>>>> response, the client should remove any partially received = body > >>>>> held > >> for > >>>>> a previous ETag for that resource as it is unlikely the = missing > >>>>> blocks can be retrieved. > >>>>>> * "For Confirmable transmission, the client SHOULD continue = to": As > >>>>>> above in the other direction, that's not news. > >>>>> [Jon] Again, we are not looking for a response (well, a request = in > >>>>> this case as needed by Block2), just an ACK OLD > >>>>> For Confirmable transmission, the client SHOULD continue to > >>>>> acknowledge each packet as well as issuing a separate GET, = POST, > PUT, > >>>>> FETCH, PATCH, or iPATCH for the missing blocks. > >>>>> NEW > >>>>> For Confirmable transmission, the server continues to = acknowledge > >>>>> each packet, but a response is not required (whether separate = or > >>>>> piggybacked) until successful receipt of the body or, if some = of the > >>>>> payloads are sent as Non-confirmable and have not arrived, a > >>>>> retransmit missing payloads response is needed. > >>>>>> * "If there is insufficient space to create a response PDU": I = don't > >>>>>> understand what that means. (Where are request options = reflected > >>>>>> back?). > >>>>> [Jon] This was triggered by a question by Michael Richardson " = So, > >>>>> given a Christmas-Tree-Packet (largest packet, every possible > >>>>> option space used, every extension turned on...) how much data = can > >>>>> I get back? :-)" and not fully thought through. > >>>>> It could happen though with Location-Path, Location-Query, > >>>>> Q-Block2, ETag, > >>>>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in > >>>>> response to a POST. > >>>>> OLD > >>>>> If there is insufficient space to create a response PDU with = a block > >>>>> size of 16 bytes (SZX =3D 0) to reflect back all the request = options as > >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>>>> the Size2 Option. > >>>>> NEW > >>>>> If there is insufficient space to create a response PDU with = a block > >>>>> size of 16 bytes (SZX =3D 0) to send back all the response = options as > >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>>>> the Size1 Option. > >>>>> > >>>>>> * "If the client requests missing blocks, this is treated as a = new > >>>>>> request.": I don't think the client should even make these = follow- > up > >>>>>> requests Observe, as it already has an ongoing observation. = They'd > be > >>>>>> sent on a different token too, so setting Observe would be = opening > >>>>>> observation up on that token, which AFAIU is not intended. = (Figure > 7 > >>>>>> example looks good to me in that respect.) > >>>>>> > >>>>>> (It may make sense to ask the client to keep Observe to make = the > >>>>>> requests matchable just for the sake of staying in = atomic-request > >>>>>> mode. Either way, the server should then not accept that > observation > >>>>>> as it's not for a block 0.) > >>>>> [Jon] The intent here was that just a new Token should be used. > >>>>> OLD > >>>>> If the client requests missing blocks, this is treated as a = new > >>>>> request. The Observe value may change but MUST still be = reported. > >>>>> If the ETag value changes then the previously received = partial body > >>>>> should be destroyed and the whole body re-requested. > >>>>> NEW > >>>>> If the client requests missing blocks, this is treated as a = new > >>>>> Request and the Observe Option MUST NOT be included. If the = ETag > >>>> value > >>>>> changes, then the previously received partial body > >>>>> should be considered as not fresh and the whole body = re-requested. > >>>>> > >>>>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response > >>>>>> can > >> be > >>>>>> matched by the token to a unique request that already had a > >>>>>> Request-Tag, and the client needs to have kept that token = around > >>>>>> matched to the transfer to make sense of it. > >>>>>> > >>>>>> No need to move that value around between subsystems, and = just > >>>>>> dropping it from here would also remove the need for the "If = the > >>>>>> client does not recognize the Request-Tag" clause (which = would > >>>>>> otherwise need clarification as to what it'd mean if it = recognizes it > >>>>>> but it doesn't match what the request was for). > >>>>> [Jon] Good question - it does make sense for the Request-Tag to = be > >>>>> tracked alongside the Token in the client. > >>>>> OLD > >>>>> The data payload of the 4.08 (Request Entity Incomplete) = Response > >>>>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR > encoded > >>>>> Request-Tag followed by 1 or more missing CBOR encoded = missing > >> block > >>>>> numbers. > >>>>> NEW > >>>>> The data payload of the 4.08 (Request Entity Incomplete) = response > >>>>> is encoded as a CBOR Sequence [RFC8742]. There are one or = more > >>>> missing > >>>>> CBOR encoded missing block numbers. > >>>>> > >>>>> OLD > >>>>> ; This defines an array, the elements of which are to be = used > >>>>> ; in a CBOR Sequence: > >>>>> payload =3D [request-tag, + missing-block-number] > >>>>> request-tag =3D bstr > >>>>> ; A unique block number not received: > >>>>> missing-block-number =3D uint NEW > >>>>> ; This defines an array, the elements of which are to be = used > >>>>> ; in a CBOR Sequence: > >>>>> payload =3D [+ missing-block-number] > >>>>> request-tag =3D bstr > >>>>> ; A unique block number not received: > >>>>> missing-block-number =3D uint > >>>>> > >>>>> OLD > >>>>> A 4.08 (Request Entity Incomplete) Response Code returned = with > >>>>> Content-Type "application/missing-blocks+cbor-seq" indicates = that > >>>>> some of the payloads are missing and need to be resent. The = client > >>>>> then re-transmits the missing payloads using the Request-Tag = and > >>>>> Q-Block1 to specify the block number, SZX, and M bit as = appropriate. > >>>>> The Request-Tag value to use is determined from the payload = of the > >>>>> 4.08 (Request Entity Incomplete) Response Code. If the = client does > >>>>> not recognize the Request-Tag, the client can ignore this = response. > >>>>> NEW (option presentation has been reformatted) > >>>>> 4.08 (Request Entity Incomplete) > >>>>> > >>>>> This Response Code returned with Content-Type "application/ > >>>>> missing-blocks+cbor-seq" indicates that some of the payloads = are > >>>>> missing and need to be resent. The client then retransmits the > >>>>> missing payloads using the same Request-Tag, Size1 and = Q-Block1 > >>>>> to specify the block number, SZX, and M bit as appropriate. > >>>>> > >>>>> > >>>>> The Request-Tag value to use is determined from the token in = the > >>>>> 4.08 (Request Entity Incomplete) response and then finding the > >>>>> matching client request which contains the Request-Tag that is > >>>>> being used for this Q-Block1 body. END > >>>>>> * "limit the array count to 23 (Undefined value)": 23 is the = maximum > >>>>>> length of a zero-byte length indication, not = indefinite-length (31). > >>>>>> Both using 23 and 31 here makes sense (up to 23 to have = definite > >>>>>> length that can be updated in-place, or exceeding that switch = to > >>>>>> indefinite length if they still fit), but the paragraph seems = to be > >>>>>> mixing them up. > >>>>> [Jon] OK > >>>>> OLD > >>>>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count = to 23 > >>>>> (Undefined value) so that the array data byte can be = updated with > >>>>> the overall length once the payload length is confirmed or = limited > >>>>> to MAX_PAYLOADS count. > >>>>> NEW > >>>>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively = limit > >>>>> the array count to > >>>>> 23 so that the initial byte with the array major type and > >>>>> data length in the additional information can be updated with = the > >>>>> overall count once the payload count is confirmed. Further > >>>>> restricting the count to MAX_PAYLOADS means that congestion > >>>>> control is less likely to be > >>>> invoked on the server. > >>>>>> * "Each new request MUST use a unique token": Like above, this = is > >>>>>> stating something that's not intended to be changed. > >>>>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty > >>>>> token values are acceptable. Hence this statement. > >>>>>> Congestion Control: > >>>>>> > >>>>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is > >>>> subjected > >>>>>> to PROBING_RATE.": That is unexpected here. At most one such > >>>>>> response is sent to each request message, so why is = additional > >>>>>> congestion control needed? > >>>>> [Jon] The intention here was that in the previous paragraph that > >>>>> it was not the individual packets that are subject to > >>>>> PROBING_RATE, but a single body comprising of multiple packets = is > >>>>> subject to PROBRING_RATE > >>>>> - and hence limiting any individual responses to PROBING_RATE > >>>>> rather than the potentially full set of responses OLD > >>>>> PROBING_RATE parameter in CoAP indicates the average data = rate > that > >>>>> must not be exceeded by a CoAP endpoint in sending to a peer > >> endpoint > >>>>> that does not respond. The body of blocks will be subjected = to > >>>>> PROBING_RATE (Section 4.7 of [RFC7252]). > >>>>> NEW > >>>>> PROBING_RATE parameter in CoAP indicates the average data = rate > that > >>>>> must not be exceeded by a CoAP endpoint in sending to a peer > >> endpoint > >>>>> that does not respond. The single body of blocks will be = subjected > to > >>>>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual > packets. > >>>>> If the wait time between sending bodies that are not being > >>>>> responded to based on PROBING_RATE exceeds > NON_PROBING_WAIT, > >>>> then the > >>>>> gap time is limited to NON_PROBING_WAIT. > >>>>> > >>>>> Note: For the particular DOTS application, PROBING_RATE and = other > >>>>> transmission parameters are negotiated between peers. Even when > >>>>> not negotiated, the DOTS application uses customized defaults as > >>>>> discussed in Section 4.5.2 of [RFC8782]. > >>>>> END > >>>>>> On the other hand, *ever* NON request is subject to > >>>>>> PROBING_RATE, > >> so > >>>>>> why point out the body of blocks and "GET or similar" = particularly? > >>>>> [Jon] It is only GET or FETCH. The intention here is to not > >>>>> request bodies of data at too high a rate. > >>>>> OLD > >>>>> Each NON GET or similar request using Q-Block2 Option is = subjected > to > >>>>> PROBING_RATE. > >>>>> NEW > >>>>> Each NON GET or FETCH request using Q-Block2 Option is > >>>>> subjected to PROBING_RATE. > >>>>>> * "a delay is introduced of ACK_TIMEOUT": As I understand > >>>> MAX_PAYLOADS, > >>>>>> this is (rather implicitly) introduced as the package count = up to > >>>>>> which it is OK to exceed PROBING_RATE temporarily (but after = that > it > >>>>>> kicks in all the harder by requiring to wait until = complete-sent- > bytes > >>>>>> over PROBING_RATE has expired). If that holds, at that time a = much > >>>>>> larger delay than just ACK_TIMEOUT is needed to get a = response > from > >>>>>> the server: About 3 hours (see later note on parameters). > >>>>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re- > write > >>>>> of Congestion Control section. > >>>>>> This is the crucial point in the document, and for it a > recommendation > >>>>>> alone is not good enough. The protocol can be run with a = vastly > >>>>>> increased PROBING_RATE (however externally determined) and > from > >>>> the > >>>>>> point of MAX_PAYLOADS just observe it. Or it has to get > >>>>>> feedback > >> from > >>>>>> the server; a single 4.08 is probably enough to kick off = another > >>>>>> vollley of blocks. (How many? MAX_PAYLOADS for every > response?). > >>>>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't = doing > any > >>>>>> good. > >>>>> [Jon] See re-write of Congestion Control section where things > >>>>> should now be simpler and more logical. There is an = introduction > >>>>> of new variable definitions. > >>>>>> * "For NON transmissions": This seems to imply that the full > >>>>>> exchange > >> of > >>>>>> a body is either NON or CON; I don't see where that'd come = from. > I'd > >>>>>> have expected to read something like "Each individual request = can > be > >>>>>> NON or CON independent of the others. In particular, it can = be > >>>>>> convenient to send the ultimate payload...". > >>>>> [Jon]The DOTS environment will only be using NON. To make > >>>>> Congestion Control simple, the expectation is that all > >>>>> transmissions are NON or (not recommended) are all CON. The = draft > >>>>> now generally records this expectation. > >>>>>> * "If a Confirmable packet is used, then the transmitting peer > >>>>>> MUST > >> wait > >>>>>> for the ACK": Why? A NSTART > 1 would give it leisure to = still > >>>>>> transmit. > >>>>> [Jon] Text has been removed in the clean-up. > >>>>>> * General on congestion control: It may help implementors if = this > were > >>>>>> split up into newly introduced rules and concepts (that is, > >>>>>> MAX_PAYLOADS and the answer to whether you may send > >>>> MAX_PAYLOADS en > >>>>>> block again after having only even one response from the last > round, > >>>>>> and probably the recommended parameters of the "Also on > >>>> parameters" > >>>>>> comment), and another subsection on how Q-Block behaves well > >> when > >>>>>> observing these. > >>>>> [Jon] Should now be covered in the updated Congestion Control > >> section. > >>>>>> Caching: > >>>>>> > >>>>>> * "are not part of the cache key": How about "are removed as = part > >>>>>> of > >> the > >>>>>> block assembly and thus do not reach the cache"? > >>>>> [Jon] OK. > >>>>> OLD > >>>>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>>>> Q-Block2 Options are not part of the cache key. > >>>>> NEW > >>>>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>>>> Q-Block2 Options are removed as part of the block assembly = and > >>>>> thus do not reach the cache. > >>>>>> * "When the next client completes building the body": If the = proxy > >>>>>> chooses not to let them happen in parallel (which it may, see > >>>>>> above > >> on > >>>>>> parallel requests, although the server might still not = support it and > >>>>>> cancel one of them), why bother letting the first finish just = to abort > >>>>>> it? (IOW: If the proxy does not intend to see both through, = which it > >>>>>> could if it held back the second until the first is through = on the > >>>>>> uplink, it could just as well err out of one of them early, = but it may > >>>>>> also rather see both through.) > >>>>> [Jon] It has to be assumed that traffic to/from the origin = client > >>>>> and origin server may not both support Q-Blockx and potentially > >>>>> may have a different SZX. Thus passing a request or a response > >>>>> through at the block level introduces a new set of challenges = (but > >>>>> not impossible to fix). To keep this simple, my thinking was = that > >>>>> the passing through can only take place at the body level. = Again, > >>>>> the arrival of packets is not necessarily sequential, so client > >>>>> A's body may start transmitting to the origin server first, but > >>>>> client B's body starts to arrive first - the same being true for > >>>>> the proxy as a client may stop transmitting for whatever reason > >>>>> (restart, network loss > >> etc.). > >>>>> However this is covered by the above update " If a server > >>>>> receives payloads with different Request-Tags for the same > >>>>> resource, it should > >>>> continue to process all the bodies". > >>>>> OLD > >>>>> and the new body representation transmission starts with a = new > >>>>> Request-Tag value. > >>>>> NEW > >>>>> and the new body representation transmission starts with a = new > >>>>> Request-Tag value. Note that it cannot be assumed that the > >>>>> proxy will always receive a complete body from a client. > >>>>>> * Examples: > >>>>>> > >>>>>> * Figure 5: The ... between e3 request and response indicate = the > >>>>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I > suppose > >>>> there > >>>>>> should be the same kind of delay between the failed e5 > transmission > >>>>>> and the e4 response. > >>>>> [Jon] Agreed and added in > >>>>>> * If the second burst had 3 requests out of which 2 made it, = is there > >>>>>> any guidance for which of them the 4.08 would come back on? = (In > the > >>>>>> end, none of them is terminal). > >>>>> [Jon] The client should tracking all Tokens of the burst (hence > >>>>> implementation note about bottom 32bits unique and top 32 bits > >>>>> matching block number for ease of tracking) for a response and = so > >>>>> it will make no difference at to which token is used for the = 4.08 > >>>>> response. From an implementation perspective, it probably is > >>>>> easier to track the last opaque token that has the same = Request-Tag. > >>>>> OLD > >>>>> missing ones in one go (Figure 5). It does so by indicating = which > >>>>> blocks have been received in the data portion of the = response. > >>>>> NEW > >>>>> missing ones in one go (Figure 5). It does so by indicating = which > >>>>> blocks have been received in the data portion of the = response. > >>>>> The Token just needs to be one of those that have been received > >>>>> for this Request-Tag , so the client can derive the Request-Tag. > >>>>>> * If that e4 response gets lost, does the whole mechanism > >>>>>> recover > >> from > >>>>>> it in any way? > >>>>> [Jon] In this example, if e4 and e5 get lost, there will be no > >>>>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as = to > >>>>> whether it sends the request again or gives up. See 9.1 > >>>>> "Under high levels of traffic loss, the client can elect not = to retry > >>>>> sending missing blocks of data. This decision is = implementation > >>>>> specific." > >>>>>> Generally, the all-NON and all-CON examples don't look to = me like > >>>>>> what I'd be doing with this spec; the mixed "a CON every > >>>>>> MAX_PAYLOADS" appears much more realistic. > >>>>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS > >>>>> environment (up to 93 secs timeout per payload with the = defaults). > >>>>> Hence why we are separating out the NON / CON usage. > >>>>>> * Figure X: The request ahs M unset and thus indicats a = request for > >>>>>> just that block. If more than one is expected, it should = say > >>>>>> QB2:0/1/1024. > >>>>> [Jon] With Figure 7, with the M bit set, block 3 would get > >>>>> returned for a second time. Draft-ietf-core-new-block-03 also = has > >>>>> a Figure 8 which does exactly what you describe. > >>>>>> * New Content Format: I think this needs a media type > >>>>>> registration to > >> go > >>>>>> with it first; based on that, a content format can be = registered. > >>>>> [Jon] Med has responded to this and draft updated. > >>>>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: > I'm > >> not > >>>>>> sure > >>>>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN = is > >>>> defined > >>>>>> in terms of reliable transmission, but used for NONs as well. = (So is > >>>>>> the alternative ot 2x ACK_TIMEOUT). > >>>>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and > >> ACK_TIMEOUT > >>>> in > >>>>> a NON environment. Hence re-write of Congestion Control section > >>>>> defining new variables that can be used for NON. > >>>>>> For the purpose of delaying a 4.08 or a follow-up GET, it may = make > >>>>>> more sense to define a new parameter based on MAX_LATENCY and > >> the > >>>>>> time > >>>>>> it takes the sender to pump out the options (which I don't = think we > >>>>>> have a good factor for, but may even be negligible here). > >>>>>> > >>>>>> Could read like this: > >>>>>> > >>>>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by > >>>> default > >>>>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / > >>>> BANDWIDTH. > >>>>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, > >>>>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > >>>>> > >>>>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. > >>>>> So BANDWITH of 1Mbps has negligible effect on the calculation. > >>>>> 1Kbps makes MAX_BLOCK_JITTER 200 seconds. > >>>>>> > > >>>>>> > With Q-Block2, a client can ask for any missing blocks = after not > >>>>>> > having received any further response for the duration of > >>>>>> > MAX_BLOCK_JITTER. > >>>>> [Jon] 100+ seconds delay is way too much time to wait for any > >>>>> missing blocks in my opinion. > >>>>> > >>>>> [Jon] RFC7252 also states (and the intention is that recovery > >>>>> works > >>>>> well) " as MAX_LATENCY is not > >>>>> intended to describe a situation when the protocol works = well, but > >>>>> the worst-case situation against which the protocol has to = guard." > >>>>>> > > >>>>>> > With Q-Block1, a server holds off any response for > >> MAX_BLOCK_JITTER > >>>>>> > unless all blocks have been received. Only then it = evaluates > >> whether > >>>>>> > to respond with a 2.0x code, a 4.08 with payload, or not at = all > >>>>>> > (because it responded to a later request). > >>>>> [Jon] I am not convinced that this is necessarily the way to go. > >>>>> The new Congestion Control more cleanly handles this. > >>>>>> This also brings me back to the earlier matter of 2.31: What = is a > >>>>>> server supposed to send when no packages were lost, but it's > pasing > >>>>>> the timeout and wants to help the client flush out more = packages > by > >>>>>> confirming something? It says 4.08 in 3.3, but it's not like = there's a > >>>>>> hole in the contiguous range. Does it need to send 4.08 > enumerating > >>>>>> all (or at least some) numbers between the first unreceived = and > >> what's > >>>>>> indicated by Size1? Or can it just send 2.31 and the client = knows all > >>>>>> it needs to know b/c the response came to the largest block = that > was > >>>>>> sent and 2.31 indicates that everything is good up to that = point? > >>>>> [Jon] The previous draft states (under Congestion Control) that > >>>>> the client waits for ACK_TIMEOUT before transmitting the next = set > >>>>> of MAX_PAYLOADS blocks. The server should wait for "two times > >>>>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps > >>>>> having a new name for ACK_TIMOUT I think that these are = reasonable > >>>>> values for Non-Confirmable - and are used in the new Congestion > >>>>> Control > >>>> section. > >>>>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) = as > >>>>> a signal to say that all of the current MAX_PAYLOADS payloads of = a > >>>>> body have been received, so allowing the client to continue > >>>>> transmitting the next set of MAX_PAYLOADS payloads without the > >>>>> need to wait any > >>>> longer. > >>>>>> * Also on parameters: This document is describing flow control = stuff > >>>>>> around a situation CoAP was not originally designed for. = Wouldn't it > >>>>>> make sense to include a set of parameters (PROBING_RATE, > >>>> MAX_LATENCY, > >>>>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt = that > >>>>>> PROBING_RATE will be left to 1 byte/second for any DOTS > application > >>>>>> using this (for sending 10KiB in the initial 10-package > MAX_PAYLOADS > >>>>>> burst would mark that connection as unusable for about 3 = hours > >>>>>> if > >> they > >>>>>> all get lost), so better give justifiable numbers here than = rely on > >>>>>> implemnetors to come up with unreviewed numbers or disregard > >>>>>> PROBING_RATE altogether. > >>>>> [Jon] Answered by Med, and some new text added. > >>>>>> I don't know if it needs additional justification, but an = increased > >>>>>> N_START may be justifiable there. > >>>>> [Jon] It may be, but tuning the other associated parameters is > >>>>> really out of the cope of this draft. This text has been added = NEW > >>>>> Congestion control for CON requests and responses is specified = in > >>>>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will > >>>>> need to be increased from 1. However, the other CON = congestion > >>>>> control parameters will need to be tuned to cover this change. = This > >>>>> tuning is out of scope of this document as it is expected that = all > >>>>> requests and responses using Q-Block1 and Q-Block2 will be = Non- > >>>>> confirmable. > >>>>>> * Somewhere (never comes up but I think it should): When CONs = are > >>>> used, > >>>>>> a 4.08 (or 2.31?) response to a later request can indicate to = the > >>>>>> client that an earlier CON request has been processed = successfully. > If > >>>>>> the client can match that up (and it should be able to), then = it can > >>>>>> (and should) cancel that particular CON request. > >>>>> [Jon] I think that this is covered by my update above with the = text " > >>>>> NEW > >>>>> For Confirmable transmission, the server continues to = acknowledge > >>>>> each packet, but a response is not required (whether separate = or > >>>>> piggybacked) until successful receipt of the body or, if some = of the > >>>>> payloads are sent as Non-confirmable and have not arrived, a > >>>>> retransmit missing payloads response is needed." > >>>>> > >>>>> And in my previous part 1 response (updated) NEW For Confirmable > >>>>> transmission, the server continues to acknowledge each packet, > >>>>> but a response is not required (whether separate or > >>>>> piggybacked) until successful receipt of the body or, if some = of the > >>>>> payloads are sent as Non-confirmable and have not arrived, a > >>>>> retransmit missing payloads response is needed. > >>>>>> Best regards > >>>>>> Christian > >>>>>> > >>>>>> -- > >>>>>> There's always a bigger fish. > >>>>>> -- Qui-Gon Jinn > >>>>> _______________________________________________ > >>>>> core mailing list > >>>>> core@ietf.org > >>>>> > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >>>> w. > >>>> > >> > ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc > >>>> a%4 > >>>> > >> > 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 > >>>> ecc4 > >>>> > >> > 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 > >>>> eyJWIjoiMC > >>>> > >> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& > >>>> amp;sd > >>>> > >> > ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 > >>>> -- > >>>> Marco Tiloca > >>>> Ph.D., Senior Researcher > >>>> > >>>> RISE Research Institutes of Sweden > >>>> Division ICT > >>>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > >>>> SE-164 40 Kista (Sweden) > >>>> > >>>> Phone: +46 (0)70 60 46 501 > >>>> > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >> w > >> > .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 > >> c8 > >> > 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 > >> 45709 > >> > 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > >> oiV2luMz > >> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb > >> mzIuz > >>>> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 > >>>> > >> -- > >> Marco Tiloca > >> Ph.D., Senior Researcher > >> > >> RISE Research Institutes of Sweden > >> Division ICT > >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > >> SE-164 40 Kista (Sweden) > >> > >> Phone: +46 (0)70 60 46 501 > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w > >> > .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C8651a6788136434 > 84 > >> > 22608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 > 45723 > >> > 0862239405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV2luMz > >> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dpo%2BnNJAbUW > 7Jf9cMF > >> xoP8VXDd1%2FfS%2BsyTl4dePY5A9o%3D&reserved=3D0 > >> > > >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Mon Jan 11 03:39:11 2021 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 336313A0977; Mon, 11 Jan 2021 03:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 wPGftPSnkYLB; Mon, 11 Jan 2021 03:39:00 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70071.outbound.protection.outlook.com [40.107.7.71]) (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 05A1A3A0AEC; Mon, 11 Jan 2021 03:38:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mj3TQ63lLmGR4IRjfVJRLj6iM43yhGLNW8TdMEQQ5cvRir2FN6eCUgYmLyNoaNXUjVL3yPZ+a9HTCLlXLlOXVGkg3IIBX1OhHJ6TwFasB9cf6n1Fjen59mM6iZPHI3y7Cse1iszgArkzP9sGPLFLvA2pCkqAI8YqAGakNZ+Lz/qU7W+h0pDjvXRWaF83zsHynYSeM3H7Zp9iWotNPx/Mufiiz1VM84gCm6mp7awFCK9lMLSV7GFA5d7+6ZnuscgGp5xo+GxxlHI8c30t/O+1w/rqoIC7qxWoQgLLspSljqFfU36R0cDkcdMUzwk9H5XPG+61+m6eEO+YBIpOsassVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IN63M7vsSKJYadjsJ0QnnXhqPcy7JwJ7RMwtSH97r3Q=; b=EJ9NhHpx8GGfujLeFstj6pIaE45Y6wkC4eKYv7dxtvwGuE+7gWV6T+KJALLg3o9wbawCNHiwRJrqDXTqegNfdugZN7qssNboPFeNBvprJ0PdqmMdvwWSFn8VzPQsE4lKeYZksSvLwIEP/xJSo/FW0OjFHWU/+vtTaRiCve5cysYpuOBB+mehRlaINu41iLq1HE/ywC6uwxqMHUnrlI1gLZz+bRz287b55lxHXc8S9JliD3L9oSsaIrrxSM2/PYOfYjNxsaaVSrXvzieFGivKVCGpwZ+elvzvlZ3LymXwPow2gzYrbg+UNw17s/h7S/26UPxXA+zLhpg0JagKlS0rEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IN63M7vsSKJYadjsJ0QnnXhqPcy7JwJ7RMwtSH97r3Q=; b=Q9xL+aOnHEEuQvgzabyNB6j2qSdHl5+GbUyK14A3qH2qLLZPw6fqj/aTXmwIcvbwmnG8eTkcYzlu3LwVLz5qyHsd2SZhil/tkMM7yrL9HO3Rp7hQEidzz+FuGeLmD533R1HJxIIu6pgA/s3pRTHhdIcLs0nZcNx0DEdvoFTTTwk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DBBP189MB1403.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e2::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.8; Mon, 11 Jan 2021 11:38:54 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 11:38:54 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Mon, 11 Jan 2021 12:38:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <065301d6e805$286163c0$79242b40$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7" X-Originating-IP: [185.236.42.23] X-ClientProxiedBy: HE1PR0401CA0104.eurprd04.prod.outlook.com (2603:10a6:7:54::33) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.3] (185.236.42.23) by HE1PR0401CA0104.eurprd04.prod.outlook.com (2603:10a6:7:54::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Mon, 11 Jan 2021 11:38:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6737cfa9-071f-4c2c-327d-08d8b62579d3 X-MS-TrafficTypeDiagnostic: DBBP189MB1403: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lQ+N3hPEHQSwcZhImjw26y0WJGROyvzc/z4EG85O9I+pC0e00MJS1IQX6BfZWTIpuBVsdn51q+8k1XPujuRMbgwZkk7ZAVvn3NKtn8GIKCWTnTbxYeDV9xthCv5F6aGKpVOG1xrcdlciOyC9LDvy5AvyHFx3TE+PDAcBbBZYNoaeSaKUDJBK5M6UPw3YOExW7MRYfQ4FiWPKP9YDsmy1gAOkqVWiRzVwybFJ1+kEriq8fP9xy8xKeHmJ0XdjpD+q6PulSgSXmr1A3syeZgV7eafOnc8cidP0DFWF765oeD59H1Flb0zIF1kVzM8KKapS/zwTZ6zP0SGF2lcZhUIwBPw6KBUO5mnCethoGVWEB7n7P+9h83g8+CSFgQYbmYubp1zlyHMObbGYLm8v8MUOwogE2c188GWcZTgQfPgs+9/Gb/Zc5o6LlCldW3hzyZe/jGv0fWc4v2Llxb62jT0qj7qxvoXOi5L++5U+kGH7xm5Qlw6VJuM4Ihq2q8QUBPfg52ijGyfYsqjwyCxOeqVMQR6QVcNqEsl1Lh8QwlCKiHYoelSbeafF7XCvDOe3oAFM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(346002)(366004)(136003)(376002)(235185007)(5660300002)(30864003)(4326008)(31686004)(52116002)(6666004)(316002)(16576012)(36756003)(8936002)(21480400003)(33964004)(44832011)(6486002)(66556008)(8676002)(26005)(83380400001)(956004)(966005)(66574015)(53546011)(45080400002)(186003)(16526019)(66946007)(31696002)(86362001)(2906002)(478600001)(66476007)(2616005)(45980500001)(43740500002)(579004)(559001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bEh0bUNWT0JhOUo2QllVQXRWb1M3QkhtZlQ3bXVVZU9XZFdPS2lTa2NVSklU?= =?utf-8?B?aDJLOEdvQWJzOGJ5T2FkMElMc3Evd0hZdWtIc2NCendWRU9yMHFXeTRYTlp5?= =?utf-8?B?MVA5dXo2OHlCWmtEVzExSWwrSGhlMVVEVTYyMlR5MHc4bGM5c2E2YXA1SmZM?= =?utf-8?B?dTFTeE81MGwrcy9MUjRqZXVNdTRvTzA2bElVWVlXdHpvWEdJQ1JsNDdidHha?= =?utf-8?B?b2VnMUhLNmJUR2xpZEs3Vjh4SFdGaXpsZks5aExPNnEyajVISnY1S0tXUm1V?= =?utf-8?B?SmJzdzViSTlXaHFFaGhQb2h3Qk1ELzZ6ajRRTk9MbkI0c3lXV0pBU0Q0cThy?= =?utf-8?B?TUMvR1hsM1dlTWNuZFdLek1DMld4U1BxNFozczdjeGVnRFRLZnZPZU5zam1K?= =?utf-8?B?ZWoxWmM1dzJHcHJvSU10alBzc2ZPanhaS05rMGpwMWJ4RXdTR1M0TFRtalY1?= =?utf-8?B?Tm8xbXUxOUR5Nks4bkpkUmp1dmJwNG1hNlRacm02Zm9pK1NKRHV3eEltTDRI?= =?utf-8?B?bmNIczhScy90Wmw4ejRKR3M5Y1h5ZkE3a3ZQRmJTR1ZIbnhrWTBEdCtDU2ZQ?= =?utf-8?B?ZklZeXVYUkl1UmpHL1dkYXd6anE4djVkSis4WnplY3RBblQ2RHU0UVA1Vkp6?= =?utf-8?B?YnRIMy8wcHMxelNiQ2VXRWpoWE1LWEtkcSs4ZGh4cU51ZVIyVXBzcXhqcU9X?= =?utf-8?B?NVN2OGMyYzYvamd3VmNwaGxVbk8xMzdDTEt4VDg3NWdzUGlCMU56UmpDVDNK?= =?utf-8?B?cGc1dXRRMWdUb0Ezc0dhalFuZlVUTW1oaHRlc1NmZTgwYUFNMStNYlVGUGta?= =?utf-8?B?emgrY1JSR2lUMTdmQm8rTjU4ZVUwZEp4Vmk2cGxpaVg3blZwRmtjYStvOS9v?= =?utf-8?B?OEZQdWZVd3JNUzh3d2lnY1QreFdEYnVDdTNxckZETStCaHI1cnBWMWcvL3Zz?= =?utf-8?B?VityenIzeFlyT043bERCbmRvcnAvYXBWNFM1NEtvZ0UyZWJFTDBHenA4KzBD?= =?utf-8?B?Q20rL2MrOEFCcERZY1lmbmhad1RyVVFvVzNUOFdhaGxPeDZWbEJTdyttSzdi?= =?utf-8?B?SXRMTW9Db0ZsbldJR25wUUVmeE9yY2FxdkR4NE9SRitYZWJ3TUQ3YzE5Rzhi?= =?utf-8?B?K2Z4amlxUVozbXZKZVhDbktsbFM2SWlRN29PNXRKRXNmRFR2Qy9PTlBYK2E5?= =?utf-8?B?dERPVjJBdk1OL0t6NGRsdG4zOFpQV3Bsb0ptS2pPeDlaRElnaEUvSXIxb3Nj?= =?utf-8?B?clgxOWdkdUg2ZW8zR05VNU90NzNUeWdJYThWSW1IbklhM0VzYVVQcUF2c0JI?= =?utf-8?Q?DmeKz6s5PCiGGPqX0zxUSXLYsg85qBCnJt?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2021 11:38:54.6107 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 6737cfa9-071f-4c2c-327d-08d8b62579d3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PqQnxgSOM7/A3nlSnpTkp7btiB7dXa4iLgkCcii5ngiYQKGXwRkKHNHxrWh6M8yNzic4bFX9Q5sZU2D7+wf7ew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1403 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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 Jan 2021 11:39:06 -0000 --WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7 Content-Type: multipart/mixed; boundary="AZUxISfTlovYtzMUqTfbBCRvG9nzs4NNW" --AZUxISfTlovYtzMUqTfbBCRvG9nzs4NNW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks, the updates look good. As to the response codes in Section 3.3 "Using the Q-Block1 Option",=C2=A0= wouldn't it make sense to mention also 2.05 (Content) ? Think of a FETCH request with a big body, which is actually mentioned at the beginning of Section 3.3 and in Section 3.1 (though missing the 2.05 response code beside it). Also, more in general, think of an observe registration, for which the server eventually sends back a first notification (possibly split into multiple payloads) with Q-Block2, with a certain Token value. If the observation request used FETCH and was fragmented into several payloads with Q-Block1, each of which with a different Token, it's still true that the notifications can all have any of those Token values and should have the one of the last received request payload. However, later on the client has to retain that Token value as the one associated to the observation, to match future notifications to come. In this case, there is a deviation from the claim used for other response codes, i.e. "The client should then release all of the tokens used for this body." This should concern only 2.01 notifications (hence including the Observe option) in response to observation requests with FETCH, so it can be limited to the context of this section about Q-Block1. Best, /Marco On 2021-01-11 11:33, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > The new updates have been pushed to https://eur02.safelinks.protection.= outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d89808d8b61c4788%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580455245128%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C2000&sdata=3Dost7IW3KRdzPcvhj6NWjtypuEBpTlLQYYprW2T0tekk%3D&a= mp;reserved=3D0 and the differences with the draft can be found at https:= //eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.or= g%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw= =2Egithubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core= -new-block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945= b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580= 455250109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ= BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dh%2FG4febnGfQJJzEJFXCXEuBw= AGNPlDPzub32L%2FLceUI%3D&reserved=3D0 > > The PR for the responses below can be found at https://eur02.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-bl= ock%2Fpull%2F12&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef594= 5b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63745958= 0455250109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DjUmBoUDRubJVXoq2jcvvgZJ1Z= VPtJUhKMX%2BEeZ0gtT4%3D&reserved=3D0 (a couple of minor nits fixed si= nce then which are in master) > > Otherwise lease see inline. > > Regards > > Jon > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 08 January 2021 18:19 >> To:supjps-ietf@jpshallow.com; christian@amsuess.com; draft-ietf-core-n= ew- >> block@ietf.org >> Cc: dots@ietf.org; core@ietf.org >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >> >> Hi Jon, >> >> On 2021-01-08 18:17, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> Thanks for this. >> ~snips >> >>>> * Section 4 says: "The token to use ... any troubleshooting." >>>> >>>> Do you actually mean the highest block number received so far >>>> under that Request-Tag, or the highest within the current set of >>>> MAX_PAYLOADS payloads for which the server is requesting some >> missing blocks? >>>> The new example in Section 5 seems to cover the latter, which I >>>> guess is what you intend. >>> [Jon] Not sure that it really makes any difference. Have updated the= >>> text to try to clarify OLD The token to use for the response SHOULD b= e >>> the token that was used in the highest block number received payload.= >> Note that the use of any received token would work, but providing the = one >> used in the highest received block number will aid any troubleshooting= =2E The >> client will use the token to match the request to find what Request-Ta= g >> value is currently being used. >>> NEW >>> The token to use for the response SHOULD be the token that was used i= n >> the highest block number received so far with the same Request-Tag val= ue. >> Note that the use of any received token with the same Request-Tag woul= d >> work, but providing the one used in the highest received block number = will >> aid any troubleshooting. The client will use the token to determine wh= at is >> the previously sent request to obtain the Request-Tag value to be used= =2E >> >> =3D=3D>MT >> Looks better. >> >> To clarify, I meant Figure 5 (not Section 5), where the response with >> Message ID M:0x91 uses Token T:0xe0. That's matching with the request >> with Message ID M:0x19, i.e. the received payload with the highest blo= ck >> number *in the current MAX_PAYLOADS payload set* to be still completed= =2E >> >> If the SHOULD above was followed, that response would have Token T:0xe= b, >> to match with the one used in "the highest block number received so fa= r", >> i.e. block number 10 in the request with Message ID M:0x1b. >> >> But as per the text above, either Token value is fine to use in the re= sponse, >> so the example is correct anyway. > [Jon] Changed highest to last (to simplify things), updated the example= s accordingly. Updated 2.01,2.04 and 2.31 code with which token to use. >> <=3D=3D >> >>>> - Figure 10, all responses should have ET=3D24 >>> [Jon] Fixed (I only found one) >> =3D=3D>MT >> The other occurrence is the very last response, with Message ID M:0x9b= :-) > [Jon] Got it - And M:0x9b updated to M:0xc3 to be consistent. > ~Jon >> >> Otherwise, it looks good to me. Thank you! >> >> Best, >> /Marco >> <=3D=3D >> >>> ~Jon >>>> Best, >>>> /Marco >>>> >>>> >>>> On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: >>>>> Hi Marco, >>>>> >>>>> Thanks for this - and it is good to have another set of eyes >>>>> checking things >>>> through. >>>>> Updates have been pushed to >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi= t >>>> h >>>>> ub.com%2Fcore-wg%2Fnew- >>>> block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 >>>> >> C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e >>>> 8%7 >>>> >> C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi >>>> MC4wLjAwMD >>>> >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D >>>> LN79 >>>> >> Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 >>>> and the >>>>> differences with the draft can be found at >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>> w. >>>>> ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- >>>> block%26url2%3Dhttps%3 >>>>> A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- >>>> block%2Fmaster%2Fdraf >>>>> t-ietf-core-new- >>>> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 >>>> >> 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% >>>> 7C0% >>>> >> 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 >>>> wLjAwMDAiL >>>> >> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc >>>> 2vkC >>>>> 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 >>>>> >>>>> Otherwise, please see inline. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>> >>>>>> -----Original Message----- >>>>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>>>> Sent: 07 January 2021 12:17 >>>>>> To: supjps-ietf@jpshallow.com; christian@amsuess.com; >>>>>> draft-ietf-core-new- block@ietf.org >>>>>> Cc: dots@ietf.org; core@ietf.org >>>>>> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for this revision and for addressing my comments already in= >>>>>> version -03. >>>>>> >>>>>> Please, see below some more comments on this version -04. >>>>>> >>>>>> Best, >>>>>> /Marco >>>>>> >>>>>> >>>>>> * s/There are one or more missing CBOR encoded missing block >>>>>> numbers./There are one or more CBOR encoded missing block >> numbers. >>>>> [Jon] Fixed. >>>>>> * Section 4 now includes the new paragraph: "The token to use for= >>>>>> the response SHOULD be the token that was used in the highest bloc= k >>>>>> number received payload. The Q-Block1 Option from the same packet= >>>>>> SHOULD be included." >>>>> [Jon] The Q-Block1 option actually is not needed as it can be >>>>> derived by >>>> the client from the remembered token (which is used to derive the >>>> Request-Tag. >>>>> OLD >>>>> The Q-Block1 Option from the same packet SHOULD be included. >>>>> NEW >>>>> The client will use the token to match the request to find what >>>>> Request-Tag value is currently being used. Providing the highest >>>>> received block number will aid any troubleshooting. >>>>> >>>>>> Consistently, the example in Figure 5 should also have >>>>>> QB1:3/0/1024 in the >>>>>> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 >>>>>> response with Token T:0xe4. >>>>> [Jon] No change now needed. >>>>>> Since "SHOULD" is used, when is it still fine or expected to no= t >>>>>> include Q- >>>>>> Block1 in a 4.08 response? >>>>> [Jon] Q-Block1 is no longer needed. >>>>>> * When commenting the example in Figure 5, Section 9.1 reads: "The= >>>>>> Token just needs to be one of those that have been received for >>>>>> this Request-Tag, so the client can derive the Request-Tag." >>>>>> >>>>>> Should this not be aligned with the SHOULD used in Section 4 >>>>>> about using the Token from the same packet conveying the highest >>>>>> block >>>> number? >>>>> [Jon] Agreed >>>>>> You explained in your mail that the client keeps tracking all >>>>>> Tokens in the burst anyway, so maybe it's better to rather align >>>>>> the text in Section 4 with what suggested here in Section 9.1, i.e= =2E >>>>>> responding with any of those Token values is just fine. >>>>> [Jon] I think that it is useful for the client to have a hint about= >>>>> what is the latest block number received even if it does not make >>>>> use it - it may help in debugging from packet captures etc. which i= s >>>>> why I >>>> added in the SHOULD in section 4. So, I would prefer to align this >>>> with section 4 OLD The Token just needs to be one of those that have= >>>> been received for this >>>>> Request-Tag, so the client can derive the Request-Tag. >>>>> NEW >>>>> The token used in the response should be the token that was used in= >>>>> the >>>> highest block number received payload. The client can then derive th= e >>>> Request-Tag by matching the token with the sent request.. >>>>>> In such a case, the Q-Block1 option included in the 4.08 >>>>>> response has still to be the one from the request conveying the >>>>>> highest block >>>> number. >>>>>> Correct? >>>>> [Jon] We are now dropping the need for Q-Block1 in the response. >>>>>> * The new text in Section 6.2 says: "... and the situation >>>>>> re-evaluated for another 24 hour period until there is no report o= f >>>>>> missing payloads under normal operating conditions." >>>>>> >>>>>> When that happens, I suppose MAX_PAYLOADS is right away restore= d >>>>>> to the intended value, i.e. it is not incremented by 1 to start >>>>>> another 24-hour period evaluation. Correct? >>>>> [Jon] Updated for clarification >>>>> OLD >>>>> report of missing payloads under normal operating condition= s. Note >>>>> that the CoAP peer will not know about the MAX_PAYLOADS >>>>> change until NEW >>>>> report of missing payloads under normal operating >>>>> conditions. The >>>> newly >>>>> derived value for MAX_PAYLOADS should be used for both ends= of >> this >>>>> particular CoAP peer link. Note >>>>> that the CoAP peer will not know about the MAX_PAYLOADS >>>>> change until >>>>>> * Section 6.2 says: "The request that the client sends to >>>>>> acknowledge the receipt of all the current set of MAX_PAYLOADS >>>>>> payloads SHOULD contain a special case Q-Block2 Option with NUM se= t >>>>>> to the first block of the next set of MAX_PAYLOADS payloads and th= e M >> bit set to 1." >>>>>> Is it possible to reflect this in the example of Figure 6? It >>>>>> would require the body to have more than MAX_PAYLOADS blocks thus >>>> resulting >>>>>> in more bursts, which would be inherited by the examples in Figure= >>>>>> 7 and >>>> Figure 8. >>>>> [Jon] Examples updated to include this information >>>>>> * In Section 9, it would be good to have the parameters defined in= >>>>>> Section >>>>>> 6.2 and their values reflected in the examples, when applicable. >>>>>> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked >>>>>> retransmissions are presumably due sometimes to MAX_PAYLOADS >>>> compared >>>>>> against the value of the latest received Q-Block1/Q-Block2, while >>>>>> sometimes to NON_RECEIVE_TIMEOUT. >>>>> [Jon] Examples updated to include this information >>>>>> * In the example in Figure 6, shouldn't the first request from the= >>>>>> client have the M bit set to 1 in the Q-Block2 option, i.e. as >>>>>> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the >>>>>> request is in fact for the block 0 and for all of the remaining >>>>>> blocks within >>>> the body. >>>>> [Jon] Good catch - corrected. >>>>> >>>>> ~Jon >>>>>> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> Once again, thank you for the comprehensive review. >>>>>>> >>>>>>> Responses part 2. A new version (-04) of the draft has been >>>>>>> published and can be found at >>>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= t >>>>>> a >>>>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- >>>>>> block%2F&data=3D04%7C01 >>>>>> >> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 >>>>>> 9cf0 >>>>>> >> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown >>>>>> %7CTWFpb >>>>>> >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >>>>>> 6Mn0 >>>>>> >> %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j >>>>>> gTY%3D&am >>>>>>> p;reserved=3D0 >>>>>>> >>>>>>> >>>>>>> Part 1 responses were covered in the main by version -03, so you >>>>>>> may want to look at the -02 to -04 differences. >>>>>>> >>>>>>> The Congestion Control section has been re-written to simplify ho= w >>>>>>> things work and has a new set of definitions. There is a >>>>>>> separation of Confirmable and Non-Confirmable Congestion Control >>>>>>> with the stated assumption that all of a body is sent as >>>>>>> Non-Confirmable or >>>> Confirmable. >>>>>>> Otherwise, see inline. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>>> * The list of pros and cons (with the cons being almost trivial)= does >>>>>>>> not explain to the reader why these are not a replacement; I >> suggest >>>>>>>> to add: >>>>>>> [Jon] Another disadvantage addition NEW To reduce the transmissio= n >>>>>>> times for CON transmission of large bodies, NSTART needs to be >>>>>>> increased from 1, but this affects congestion control where other= >>>>>>> parameters need to be tuned (Section >>>>>>> 4.7 of [RFC7252]). Such tuning is out of scope of this document.= >>>>>>> >>>>>>>> * "If the client transmits a new body of data with a new Request= -Tag >>>>>>>> to": Processing parallel requests is something Request-Tag ope= ns >> up. I >>>>>>>> don't see why there's a MUST to that; the server certainly MAY= drop >>>>>>>> the old request, but it may just as well process them in paral= lel. >>>>>>> [Jon] The intent here was that garbage collection would take plac= e >>>>>>> sooner than later - especially when running in a lossy environmen= t >>>>>>> and the client has updated information to transmit. I agree that >>>>>>> Request-Tag enables the possibility of sending multiple block >>>>>>> requests with different payloads, and so there is a possibility >>>>>>> that the client starts sending body A, then decides to send body = B >>>>>>> and terminate A, but a packet from B arrives before a packet from= >>>>>>> body A is received and so >>>>>> things fail as A does not complete. >>>>>>> OLD >>>>>>> If the client transmits a new body of data with a new Request-= Tag to >>>>>>> the same resource on a server, the server MUST remove any part= ially >>>>>>> received body held for a previous Request-Tag for that resourc= e. >>>>>>> NEW >>>>>>> If a server receives payloads with different Request-Tags for >>>>>>> the same resource, it should continue to process all the bodies a= s >>>>>>> it has no way of determining which is the latest version, or whic= h >>>>>>> body, if any, the client is terminating the transmission for. >>>>>>> >>>>>>> If the client elects to stop the transmission of a complete bod= y, it >>>>>>> SHOULD "forget" all tracked tokens associated with the body's >>>>>>> Request-Tag so that a reset message is generated for the invalid >>>>>>> token in the 4.08 (Request Entity Incomplete) response. The >>>>>>> server on receipt of the reset message SHOULD delete the partial >> body. >>>>>>> END >>>>>>> >>>>>>>> * "If the server receives a duplicate block with the same Reques= t- >> Tag": >>>>>>>> Why? Being silent is the default on nonterminal blocks alredy,= but >> in >>>>>>>> a situation like figure 5 if the 2.04 is lost, that rule would= make >>>>>>>> it impossible for the client to ever get a successful response= =2E >>>>>>>> >>>>>>>> A better rule here may be to say that it processes it all the = same >>>>>>>> (and if the payload is distinct from the first transmission's = payload, >>>>>>>> it should err out.) >>>>>>> [Jon] Fair point >>>>>>> OLD >>>>>>> If the server receives a duplicate block with the same Request= -Tag, >>>>>>> it SHOULD silently ignore the packet. >>>>>>> NEW >>>>>>> If the server receives a duplicate block with the same Request= -Tag, >>>>>>> it SHOULD ignore the payload of the packet, but MUST still >>>>>>> respond as if the block was received for the first time. >>>>>>>> * "If the server receives multiple requests (implied or otherwis= e) for >>>>>>>> the same block, it MUST only send back one instance of that bl= ock.": >>>>>>>> This might be read as "ever" rather than "per incoming >>>>>>>> request", >>>> where >>>>>>>> probably the latter is meant. >>>>>>> [Jon] This text has already been updated following another review= >>>>>>> "OLD If the server receives multiple requests >>>>>>> (implied or otherwise) for the same block, it MUST only send b= ack >> one >>>>>>> instance of that block. >>>>>>> NEW >>>>>>> If the request includes multiple Q-Block2 >>>>>>> Options and these options overlap (e.g., combination of M bein= g set >>>>>>> (this and all the later blocks) and being unset (this individu= al >>>>>>> block)) resulting in an individual block being requested multi= ple >>>>>>> times, the server MUST only send back one instance of that blo= ck. >>>>>>> This behavior is meant to prevent amplification attacks." >>>>>>> >>>>>>>> * "The ETag Option MUST NOT be used": This is more a factural th= an a >>>>>>>> normative statement; it *can* not be used there as the server >> would >>>>>>>> respond thusly. It may be used, but then that indicates that t= he >>>>>>>> client is trying to verify a freshness. (However, the client s= hould >>>>>>>> not *start* sending an ETag once it learned the current resour= ce's >>>>>>>> ETag when still attempting to pull out more blocks, but that's= also >> not >>>>>>>> a normative requirement but a consequence of those two request= s >>>> not >>>>>>>> being matchable any more.) >>>>>>> [Jon] OK >>>>>>> OLD >>>>>>> The ETag Option MUST NOT be used in the request as the server >> could >>>>>>> respond with a 2.03 (Valid Response) with no payload. If the = server >>>>>>> responds with a different ETag Option value (as the resource >>>>>>> representation has changed), then the client SHOULD drop all t= he >>>>>>> payloads for the current body that are no longer valid. >>>>>>> NEW >>>>>>> The ETag Option should not be used in the request for missing >>>>>>> blocks as the server could respond with a 2.03 (Valid Response) >>>>>>> with no payload. It can be used in the request if the client want= s >>>>>>> to check the freshness of the currently cached body response. >>>>>>> >>>>>>> If the server detects part way through a body transfer that the >>>>>>> resource data has changed and the server is not maintaining a >>>>>>> cached copy of the old data, then the body response SHOULD be >>>>>>> restarted with a different ETag Option value. Any subsequent >>>>>>> missing block requests MUST respond using the latest ETag Option >> value. >>>>>>> If the server responds during a body update with a different ETa= g >>>>>>> Option value (as the resource representation has changed), then >>>>>>> the client should treat the partial body with the old ETag as no >>>>>>> longer being >>>>>> fresh. >>>>>>> END >>>>>>>> * "then the client SHOULD drop all the payloads for the current >> body": >>>>>>>> "Drop" is overly prescriptive; the client may well keep them, = but >>>>>>>> just can't consider them fresh any more. (If the client has am= ple >>>>>>>> caching abilities, they might come in handy if the resource go= es >> back >>>>>>>> to that ETag state). Same for later "the client MUST remove an= y >>>>>>>> partially received". >>>>>>> [Jon] See previous response, otherwise OLD >>>>>>> If the server transmits a new body of data (e.g., a triggered >>>>>>> Observe) with a new ETag to the same client as an additional >>>>>>> response, the client MUST remove any partially received body h= eld >> for >>>>>>> a previous ETag. >>>>>>> NEW >>>>>>> If the server transmits a new body of data (e.g., a triggered >>>>>>> Observe) with a new ETag to the same client as an additional >>>>>>> response, the client should remove any partially received body= >>>>>>> held >>>> for >>>>>>> a previous ETag for that resource as it is unlikely the missin= g >>>>>>> blocks can be retrieved. >>>>>>>> * "For Confirmable transmission, the client SHOULD continue to":= As >>>>>>>> above in the other direction, that's not news. >>>>>>> [Jon] Again, we are not looking for a response (well, a request i= n >>>>>>> this case as needed by Block2), just an ACK OLD >>>>>>> For Confirmable transmission, the client SHOULD continue to >>>>>>> acknowledge each packet as well as issuing a separate GET, POS= T, >> PUT, >>>>>>> FETCH, PATCH, or iPATCH for the missing blocks. >>>>>>> NEW >>>>>>> For Confirmable transmission, the server continues to acknowle= dge >>>>>>> each packet, but a response is not required (whether separate o= r >>>>>>> piggybacked) until successful receipt of the body or, if some o= f the >>>>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>>>> retransmit missing payloads response is needed. >>>>>>>> * "If there is insufficient space to create a response PDU": I d= on't >>>>>>>> understand what that means. (Where are request options reflect= ed >>>>>>>> back?). >>>>>>> [Jon] This was triggered by a question by Michael Richardson " So= , >>>>>>> given a Christmas-Tree-Packet (largest packet, every possible >>>>>>> option space used, every extension turned on...) how much data ca= n >>>>>>> I get back? :-)" and not fully thought through. >>>>>>> It could happen though with Location-Path, Location-Query, >>>>>>> Q-Block2, ETag, >>>>>>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in >>>>>>> response to a POST. >>>>>>> OLD >>>>>>> If there is insufficient space to create a response PDU with a= block >>>>>>> size of 16 bytes (SZX =3D 0) to reflect back all the request o= ptions as >>>>>>> appropriate, a 4.13 (Request Entity Too Large) is returned wit= hout >>>>>>> the Size2 Option. >>>>>>> NEW >>>>>>> If there is insufficient space to create a response PDU with a= block >>>>>>> size of 16 bytes (SZX =3D 0) to send back all the response opt= ions as >>>>>>> appropriate, a 4.13 (Request Entity Too Large) is returned wit= hout >>>>>>> the Size1 Option. >>>>>>> >>>>>>>> * "If the client requests missing blocks, this is treated as a n= ew >>>>>>>> request.": I don't think the client should even make these fo= llow- >> up >>>>>>>> requests Observe, as it already has an ongoing observation. T= hey'd >> be >>>>>>>> sent on a different token too, so setting Observe would be op= ening >>>>>>>> observation up on that token, which AFAIU is not intended. (F= igure >> 7 >>>>>>>> example looks good to me in that respect.) >>>>>>>> >>>>>>>> (It may make sense to ask the client to keep Observe to make = the >>>>>>>> requests matchable just for the sake of staying in atomic-req= uest >>>>>>>> mode. Either way, the server should then not accept that >> observation >>>>>>>> as it's not for a block 0.) >>>>>>> [Jon] The intent here was that just a new Token should be used. >>>>>>> OLD >>>>>>> If the client requests missing blocks, this is treated as a ne= w >>>>>>> request. The Observe value may change but MUST still be repor= ted. >>>>>>> If the ETag value changes then the previously received partial= body >>>>>>> should be destroyed and the whole body re-requested. >>>>>>> NEW >>>>>>> If the client requests missing blocks, this is treated as a ne= w >>>>>>> Request and the Observe Option MUST NOT be included. If the = ETag >>>>>> value >>>>>>> changes, then the previously received partial body >>>>>>> should be considered as not fresh and the whole body re-reques= ted. >>>>>>> >>>>>>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response >>>>>>>> can >>>> be >>>>>>>> matched by the token to a unique request that already had a >>>>>>>> Request-Tag, and the client needs to have kept that token arou= nd >>>>>>>> matched to the transfer to make sense of it. >>>>>>>> >>>>>>>> No need to move that value around between subsystems, and just= >>>>>>>> dropping it from here would also remove the need for the "If t= he >>>>>>>> client does not recognize the Request-Tag" clause (which would= >>>>>>>> otherwise need clarification as to what it'd mean if it recogn= izes it >>>>>>>> but it doesn't match what the request was for). >>>>>>> [Jon] Good question - it does make sense for the Request-Tag to b= e >>>>>>> tracked alongside the Token in the client. >>>>>>> OLD >>>>>>> The data payload of the 4.08 (Request Entity Incomplete) Respo= nse >>>>>>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR >> encoded >>>>>>> Request-Tag followed by 1 or more missing CBOR encoded missing= >>>> block >>>>>>> numbers. >>>>>>> NEW >>>>>>> The data payload of the 4.08 (Request Entity Incomplete) respo= nse >>>>>>> is encoded as a CBOR Sequence [RFC8742]. There are one or mor= e >>>>>> missing >>>>>>> CBOR encoded missing block numbers. >>>>>>> >>>>>>> OLD >>>>>>> ; This defines an array, the elements of which are to be u= sed >>>>>>> ; in a CBOR Sequence: >>>>>>> payload =3D [request-tag, + missing-block-number] >>>>>>> request-tag =3D bstr >>>>>>> ; A unique block number not received: >>>>>>> missing-block-number =3D uint NEW >>>>>>> ; This defines an array, the elements of which are to be u= sed >>>>>>> ; in a CBOR Sequence: >>>>>>> payload =3D [+ missing-block-number] >>>>>>> request-tag =3D bstr >>>>>>> ; A unique block number not received: >>>>>>> missing-block-number =3D uint >>>>>>> >>>>>>> OLD >>>>>>> A 4.08 (Request Entity Incomplete) Response Code returned with= >>>>>>> Content-Type "application/missing-blocks+cbor-seq" indicates t= hat >>>>>>> some of the payloads are missing and need to be resent. The c= lient >>>>>>> then re-transmits the missing payloads using the Request-Tag a= nd >>>>>>> Q-Block1 to specify the block number, SZX, and M bit as approp= riate. >>>>>>> The Request-Tag value to use is determined from the payload of= the >>>>>>> 4.08 (Request Entity Incomplete) Response Code. If the client= does >>>>>>> not recognize the Request-Tag, the client can ignore this resp= onse. >>>>>>> NEW (option presentation has been reformatted) >>>>>>> 4.08 (Request Entity Incomplete) >>>>>>> >>>>>>> This Response Code returned with Content-Type "application/ >>>>>>> missing-blocks+cbor-seq" indicates that some of the payloads ar= e >>>>>>> missing and need to be resent. The client then retransmits the >>>>>>> missing payloads using the same Request-Tag, Size1 and Q-Block1= >>>>>>> to specify the block number, SZX, and M bit as appropriate. >>>>>>> >>>>>>> >>>>>>> The Request-Tag value to use is determined from the token in the= >>>>>>> 4.08 (Request Entity Incomplete) response and then finding the >>>>>>> matching client request which contains the Request-Tag that is >>>>>>> being used for this Q-Block1 body. END >>>>>>>> * "limit the array count to 23 (Undefined value)": 23 is the max= imum >>>>>>>> length of a zero-byte length indication, not indefinite-length= (31). >>>>>>>> Both using 23 and 31 here makes sense (up to 23 to have defini= te >>>>>>>> length that can be updated in-place, or exceeding that switch = to >>>>>>>> indefinite length if they still fit), but the paragraph seems = to be >>>>>>>> mixing them up. >>>>>>> [Jon] OK >>>>>>> OLD >>>>>>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count = to 23 >>>>>>> (Undefined value) so that the array data byte can be update= d with >>>>>>> the overall length once the payload length is confirmed or = limited >>>>>>> to MAX_PAYLOADS count. >>>>>>> NEW >>>>>>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit= >>>>>>> the array count to >>>>>>> 23 so that the initial byte with the array major type and >>>>>>> data length in the additional information can be updated with the= >>>>>>> overall count once the payload count is confirmed. Further >>>>>>> restricting the count to MAX_PAYLOADS means that congestion >>>>>>> control is less likely to be >>>>>> invoked on the server. >>>>>>>> * "Each new request MUST use a unique token": Like above, this i= s >>>>>>>> stating something that's not intended to be changed. >>>>>>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty >>>>>>> token values are acceptable. Hence this statement. >>>>>>>> Congestion Control: >>>>>>>> >>>>>>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is >>>>>> subjected >>>>>>>> to PROBING_RATE.": That is unexpected here. At most one such >>>>>>>> response is sent to each request message, so why is additiona= l >>>>>>>> congestion control needed? >>>>>>> [Jon] The intention here was that in the previous paragraph that >>>>>>> it was not the individual packets that are subject to >>>>>>> PROBING_RATE, but a single body comprising of multiple packets is= >>>>>>> subject to PROBRING_RATE >>>>>>> - and hence limiting any individual responses to PROBING_RATE >>>>>>> rather than the potentially full set of responses OLD >>>>>>> PROBING_RATE parameter in CoAP indicates the average data rate= >> that >>>>>>> must not be exceeded by a CoAP endpoint in sending to a peer >>>> endpoint >>>>>>> that does not respond. The body of blocks will be subjected t= o >>>>>>> PROBING_RATE (Section 4.7 of [RFC7252]). >>>>>>> NEW >>>>>>> PROBING_RATE parameter in CoAP indicates the average data rate= >> that >>>>>>> must not be exceeded by a CoAP endpoint in sending to a peer >>>> endpoint >>>>>>> that does not respond. The single body of blocks will be subj= ected >> to >>>>>>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual >> packets. >>>>>>> If the wait time between sending bodies that are not being >>>>>>> responded to based on PROBING_RATE exceeds >> NON_PROBING_WAIT, >>>>>> then the >>>>>>> gap time is limited to NON_PROBING_WAIT. >>>>>>> >>>>>>> Note: For the particular DOTS application, PROBING_RATE and other= >>>>>>> transmission parameters are negotiated between peers. Even when >>>>>>> not negotiated, the DOTS application uses customized defaults as >>>>>>> discussed in Section 4.5.2 of [RFC8782]. >>>>>>> END >>>>>>>> On the other hand, *ever* NON request is subject to >>>>>>>> PROBING_RATE, >>>> so >>>>>>>> why point out the body of blocks and "GET or similar" particu= larly? >>>>>>> [Jon] It is only GET or FETCH. The intention here is to not >>>>>>> request bodies of data at too high a rate. >>>>>>> OLD >>>>>>> Each NON GET or similar request using Q-Block2 Option is subje= cted >> to >>>>>>> PROBING_RATE. >>>>>>> NEW >>>>>>> Each NON GET or FETCH request using Q-Block2 Option is >>>>>>> subjected to PROBING_RATE. >>>>>>>> * "a delay is introduced of ACK_TIMEOUT": As I understand >>>>>> MAX_PAYLOADS, >>>>>>>> this is (rather implicitly) introduced as the package count up= to >>>>>>>> which it is OK to exceed PROBING_RATE temporarily (but after t= hat >> it >>>>>>>> kicks in all the harder by requiring to wait until complete-se= nt- >> bytes >>>>>>>> over PROBING_RATE has expired). If that holds, at that time a = much >>>>>>>> larger delay than just ACK_TIMEOUT is needed to get a response= >> from >>>>>>>> the server: About 3 hours (see later note on parameters). >>>>>>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re- >> write >>>>>>> of Congestion Control section. >>>>>>>> This is the crucial point in the document, and for it a >> recommendation >>>>>>>> alone is not good enough. The protocol can be run with a vastl= y >>>>>>>> increased PROBING_RATE (however externally determined) and >> from >>>>>> the >>>>>>>> point of MAX_PAYLOADS just observe it. Or it has to get >>>>>>>> feedback >>>> from >>>>>>>> the server; a single 4.08 is probably enough to kick off anoth= er >>>>>>>> vollley of blocks. (How many? MAX_PAYLOADS for every >> response?). >>>>>>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doin= g >> any >>>>>>>> good. >>>>>>> [Jon] See re-write of Congestion Control section where things >>>>>>> should now be simpler and more logical. There is an introduction= >>>>>>> of new variable definitions. >>>>>>>> * "For NON transmissions": This seems to imply that the full >>>>>>>> exchange >>>> of >>>>>>>> a body is either NON or CON; I don't see where that'd come fro= m. >> I'd >>>>>>>> have expected to read something like "Each individual request = can >> be >>>>>>>> NON or CON independent of the others. In particular, it can be= >>>>>>>> convenient to send the ultimate payload...". >>>>>>> [Jon]The DOTS environment will only be using NON. To make >>>>>>> Congestion Control simple, the expectation is that all >>>>>>> transmissions are NON or (not recommended) are all CON. The draft= >>>>>>> now generally records this expectation. >>>>>>>> * "If a Confirmable packet is used, then the transmitting peer >>>>>>>> MUST >>>> wait >>>>>>>> for the ACK": Why? A NSTART > 1 would give it leisure to still= >>>>>>>> transmit. >>>>>>> [Jon] Text has been removed in the clean-up. >>>>>>>> * General on congestion control: It may help implementors if thi= s >> were >>>>>>>> split up into newly introduced rules and concepts (that is, >>>>>>>> MAX_PAYLOADS and the answer to whether you may send >>>>>> MAX_PAYLOADS en >>>>>>>> block again after having only even one response from the last >> round, >>>>>>>> and probably the recommended parameters of the "Also on >>>>>> parameters" >>>>>>>> comment), and another subsection on how Q-Block behaves well >>>> when >>>>>>>> observing these. >>>>>>> [Jon] Should now be covered in the updated Congestion Control >>>> section. >>>>>>>> Caching: >>>>>>>> >>>>>>>> * "are not part of the cache key": How about "are removed as par= t >>>>>>>> of >>>> the >>>>>>>> block assembly and thus do not reach the cache"? >>>>>>> [Jon] OK. >>>>>>> OLD >>>>>>> As the entire body is being cached in the proxy, the Q-Block1 = and >>>>>>> Q-Block2 Options are not part of the cache key. >>>>>>> NEW >>>>>>> As the entire body is being cached in the proxy, the Q-Block1 = and >>>>>>> Q-Block2 Options are removed as part of the block assembly and= >>>>>>> thus do not reach the cache. >>>>>>>> * "When the next client completes building the body": If the pro= xy >>>>>>>> chooses not to let them happen in parallel (which it may, see >>>>>>>> above >>>> on >>>>>>>> parallel requests, although the server might still not support= it and >>>>>>>> cancel one of them), why bother letting the first finish just = to abort >>>>>>>> it? (IOW: If the proxy does not intend to see both through, wh= ich it >>>>>>>> could if it held back the second until the first is through on= the >>>>>>>> uplink, it could just as well err out of one of them early, bu= t it may >>>>>>>> also rather see both through.) >>>>>>> [Jon] It has to be assumed that traffic to/from the origin client= >>>>>>> and origin server may not both support Q-Blockx and potentially >>>>>>> may have a different SZX. Thus passing a request or a response >>>>>>> through at the block level introduces a new set of challenges (bu= t >>>>>>> not impossible to fix). To keep this simple, my thinking was tha= t >>>>>>> the passing through can only take place at the body level. Again= , >>>>>>> the arrival of packets is not necessarily sequential, so client >>>>>>> A's body may start transmitting to the origin server first, but >>>>>>> client B's body starts to arrive first - the same being true for >>>>>>> the proxy as a client may stop transmitting for whatever reason >>>>>>> (restart, network loss >>>> etc.). >>>>>>> However this is covered by the above update " If a server >>>>>>> receives payloads with different Request-Tags for the same >>>>>>> resource, it should >>>>>> continue to process all the bodies". >>>>>>> OLD >>>>>>> and the new body representation transmission starts with a new= >>>>>>> Request-Tag value. >>>>>>> NEW >>>>>>> and the new body representation transmission starts with a new= >>>>>>> Request-Tag value. Note that it cannot be assumed that the >>>>>>> proxy will always receive a complete body from a client. >>>>>>>> * Examples: >>>>>>>> >>>>>>>> * Figure 5: The ... between e3 request and response indicate t= he >>>>>>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I >> suppose >>>>>> there >>>>>>>> should be the same kind of delay between the failed e5 >> transmission >>>>>>>> and the e4 response. >>>>>>> [Jon] Agreed and added in >>>>>>>> * If the second burst had 3 requests out of which 2 made it, i= s there >>>>>>>> any guidance for which of them the 4.08 would come back on? = (In >> the >>>>>>>> end, none of them is terminal). >>>>>>> [Jon] The client should tracking all Tokens of the burst (hence >>>>>>> implementation note about bottom 32bits unique and top 32 bits >>>>>>> matching block number for ease of tracking) for a response and so= >>>>>>> it will make no difference at to which token is used for the 4.08= >>>>>>> response. From an implementation perspective, it probably is >>>>>>> easier to track the last opaque token that has the same Request-T= ag. >>>>>>> OLD >>>>>>> missing ones in one go (Figure 5). It does so by indicating w= hich >>>>>>> blocks have been received in the data portion of the response.= >>>>>>> NEW >>>>>>> missing ones in one go (Figure 5). It does so by indicating w= hich >>>>>>> blocks have been received in the data portion of the response.= >>>>>>> The Token just needs to be one of those that have been received >>>>>>> for this Request-Tag , so the client can derive the Request-Tag. >>>>>>>> * If that e4 response gets lost, does the whole mechanism >>>>>>>> recover >>>> from >>>>>>>> it in any way? >>>>>>> [Jon] In this example, if e4 and e5 get lost, there will be no >>>>>>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as t= o >>>>>>> whether it sends the request again or gives up. See 9.1 >>>>>>> "Under high levels of traffic loss, the client can elect not to= retry >>>>>>> sending missing blocks of data. This decision is implementati= on >>>>>>> specific." >>>>>>>> Generally, the all-NON and all-CON examples don't look to me= like >>>>>>>> what I'd be doing with this spec; the mixed "a CON every >>>>>>>> MAX_PAYLOADS" appears much more realistic. >>>>>>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS >>>>>>> environment (up to 93 secs timeout per payload with the defaults)= =2E >>>>>>> Hence why we are separating out the NON / CON usage. >>>>>>>> * Figure X: The request ahs M unset and thus indicats a reques= t for >>>>>>>> just that block. If more than one is expected, it should say= >>>>>>>> QB2:0/1/1024. >>>>>>> [Jon] With Figure 7, with the M bit set, block 3 would get >>>>>>> returned for a second time. Draft-ietf-core-new-block-03 also ha= s >>>>>>> a Figure 8 which does exactly what you describe. >>>>>>>> * New Content Format: I think this needs a media type >>>>>>>> registration to >>>> go >>>>>>>> with it first; based on that, a content format can be register= ed. >>>>>>> [Jon] Med has responded to this and draft updated. >>>>>>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: >> I'm >>>> not >>>>>>>> sure >>>>>>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is= >>>>>> defined >>>>>>>> in terms of reliable transmission, but used for NONs as well. = (So is >>>>>>>> the alternative ot 2x ACK_TIMEOUT). >>>>>>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and >>>> ACK_TIMEOUT >>>>>> in >>>>>>> a NON environment. Hence re-write of Congestion Control section >>>>>>> defining new variables that can be used for NON. >>>>>>>> For the purpose of delaying a 4.08 or a follow-up GET, it may = make >>>>>>>> more sense to define a new parameter based on MAX_LATENCY and >>>> the >>>>>>>> time >>>>>>>> it takes the sender to pump out the options (which I don't thi= nk we >>>>>>>> have a good factor for, but may even be negligible here). >>>>>>>> >>>>>>>> Could read like this: >>>>>>>> >>>>>>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by >>>>>> default >>>>>>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / >>>>>> BANDWIDTH. >>>>>>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, >>>>>>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. >>>>>>> >>>>>>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. >>>>>>> So BANDWITH of 1Mbps has negligible effect on the calculation. >>>>>>> 1Kbps makes MAX_BLOCK_JITTER 200 seconds. >>>>>>>> > >>>>>>>> > With Q-Block2, a client can ask for any missing blocks after= not >>>>>>>> > having received any further response for the duration of >>>>>>>> > MAX_BLOCK_JITTER. >>>>>>> [Jon] 100+ seconds delay is way too much time to wait for any >>>>>>> missing blocks in my opinion. >>>>>>> >>>>>>> [Jon] RFC7252 also states (and the intention is that recovery >>>>>>> works >>>>>>> well) " as MAX_LATENCY is not >>>>>>> intended to describe a situation when the protocol works we= ll, but >>>>>>> the worst-case situation against which the protocol has to = guard." >>>>>>>> > >>>>>>>> > With Q-Block1, a server holds off any response for >>>> MAX_BLOCK_JITTER >>>>>>>> > unless all blocks have been received. Only then it evaluates= >>>> whether >>>>>>>> > to respond with a 2.0x code, a 4.08 with payload, or not at = all >>>>>>>> > (because it responded to a later request). >>>>>>> [Jon] I am not convinced that this is necessarily the way to go. >>>>>>> The new Congestion Control more cleanly handles this. >>>>>>>> This also brings me back to the earlier matter of 2.31: What i= s a >>>>>>>> server supposed to send when no packages were lost, but it's >> pasing >>>>>>>> the timeout and wants to help the client flush out more packag= es >> by >>>>>>>> confirming something? It says 4.08 in 3.3, but it's not like t= here's a >>>>>>>> hole in the contiguous range. Does it need to send 4.08 >> enumerating >>>>>>>> all (or at least some) numbers between the first unreceived an= d >>>> what's >>>>>>>> indicated by Size1? Or can it just send 2.31 and the client kn= ows all >>>>>>>> it needs to know b/c the response came to the largest block th= at >> was >>>>>>>> sent and 2.31 indicates that everything is good up to that poi= nt? >>>>>>> [Jon] The previous draft states (under Congestion Control) that >>>>>>> the client waits for ACK_TIMEOUT before transmitting the next set= >>>>>>> of MAX_PAYLOADS blocks. The server should wait for "two times >>>>>>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps >>>>>>> having a new name for ACK_TIMOUT I think that these are reasonabl= e >>>>>>> values for Non-Confirmable - and are used in the new Congestion >>>>>>> Control >>>>>> section. >>>>>>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) a= s >>>>>>> a signal to say that all of the current MAX_PAYLOADS payloads of = a >>>>>>> body have been received, so allowing the client to continue >>>>>>> transmitting the next set of MAX_PAYLOADS payloads without the >>>>>>> need to wait any >>>>>> longer. >>>>>>>> * Also on parameters: This document is describing flow control s= tuff >>>>>>>> around a situation CoAP was not originally designed for. Would= n't it >>>>>>>> make sense to include a set of parameters (PROBING_RATE, >>>>>> MAX_LATENCY, >>>>>>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt th= at >>>>>>>> PROBING_RATE will be left to 1 byte/second for any DOTS >> application >>>>>>>> using this (for sending 10KiB in the initial 10-package >> MAX_PAYLOADS >>>>>>>> burst would mark that connection as unusable for about 3 hours= >>>>>>>> if >>>> they >>>>>>>> all get lost), so better give justifiable numbers here than re= ly on >>>>>>>> implemnetors to come up with unreviewed numbers or disregard >>>>>>>> PROBING_RATE altogether. >>>>>>> [Jon] Answered by Med, and some new text added. >>>>>>>> I don't know if it needs additional justification, but an incr= eased >>>>>>>> N_START may be justifiable there. >>>>>>> [Jon] It may be, but tuning the other associated parameters is >>>>>>> really out of the cope of this draft. This text has been added NE= W >>>>>>> Congestion control for CON requests and responses is specified in= >>>>>>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will >>>>>>> need to be increased from 1. However, the other CON congestion= >>>>>>> control parameters will need to be tuned to cover this change. = This >>>>>>> tuning is out of scope of this document as it is expected that = all >>>>>>> requests and responses using Q-Block1 and Q-Block2 will be Non-= >>>>>>> confirmable. >>>>>>>> * Somewhere (never comes up but I think it should): When CONs ar= e >>>>>> used, >>>>>>>> a 4.08 (or 2.31?) response to a later request can indicate to = the >>>>>>>> client that an earlier CON request has been processed successf= ully. >> If >>>>>>>> the client can match that up (and it should be able to), then = it can >>>>>>>> (and should) cancel that particular CON request. >>>>>>> [Jon] I think that this is covered by my update above with the te= xt " >>>>>>> NEW >>>>>>> For Confirmable transmission, the server continues to acknowle= dge >>>>>>> each packet, but a response is not required (whether separate o= r >>>>>>> piggybacked) until successful receipt of the body or, if some o= f the >>>>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>>>> retransmit missing payloads response is needed." >>>>>>> >>>>>>> And in my previous part 1 response (updated) NEW For Confirmable >>>>>>> transmission, the server continues to acknowledge each packet, >>>>>>> but a response is not required (whether separate or >>>>>>> piggybacked) until successful receipt of the body or, if some of= the >>>>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>>>> retransmit missing payloads response is needed. >>>>>>>> Best regards >>>>>>>> Christian >>>>>>>> >>>>>>>> -- >>>>>>>> There's always a bigger fish. >>>>>>>> -- Qui-Gon Jinn >>>>>>> _______________________________________________ >>>>>>> core mailing list >>>>>>> core@ietf.org >>>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>>>> w. >>>>>> >> ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc >>>>>> a%4 >>>>>> >> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 >>>>>> ecc4 >>>>>> >> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 >>>>>> eyJWIjoiMC >>>>>> >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& >>>>>> amp;sd >>>>>> >> ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >>>>>> -- >>>>>> Marco Tiloca >>>>>> Ph.D., Senior Researcher >>>>>> >>>>>> RISE Research Institutes of Sweden >>>>>> Division ICT >>>>>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >>>>>> SE-164 40 Kista (Sweden) >>>>>> >>>>>> Phone: +46 (0)70 60 46 501 >>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>> w >>>> >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 >>>> c8 >>>> >> 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 >>>> 45709 >>>> >> 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >>>> oiV2luMz >>>> >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb >>>> mzIuz >>>>>> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 >>>>>> >>>> -- >>>> Marco Tiloca >>>> Ph.D., Senior Researcher >>>> >>>> RISE Research Institutes of Sweden >>>> Division ICT >>>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >>>> SE-164 40 Kista (Sweden) >>>> >>>> Phone: +46 (0)70 60 46 501 >>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C8651a6788136434 >> 84 >> 22608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 >> 45723 >> 0862239405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >> oiV2luMz >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dpo%2BnNJAbUW >> 7Jf9cMF >>>> xoP8VXDd1%2FfS%2BsyTl4dePY5A9o%3D&reserved=3D0 >>>> >> -- >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d8= 9808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374595804552= 50109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DQKcdNBcFq%2BaG5omNRN1UjaRJ2E5E= V%2FRiw0%2BQ%2FfuSyK0%3D&reserved=3D0 >> > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --AZUxISfTlovYtzMUqTfbBCRvG9nzs4NNW-- --WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/8OMcACgkQ7iZktA5Y 2kPrVgf/Yp7AlY52Vs2tWEAdwOocUd/ER+IohY61nSQcCo4MAy6caQDoeVScMwEw 2TlDKt8rZkXtJKvCf6cVA8L21DpCBw7pLKG1gIpxVOR8SnY2rOW4Fuyn0vsYJRzS /YdtHCnehBVYmhKGsaw2pif9Ixw56BXOPyErzUV5sSZ1DEzfUptGoBGhKEue2/hJ oquL2yJr6pbj/u7qY+Sb/mH3Di16U9+m1cQCI00wCultGMN9Cp77zRGTxFDUluIe zhLHTaHJYwYcwEHkYpRRSacu1tlnrvZtVw3IGW7Huq+8aGOFu7imbXct1JvCwX4P AQHLsCOPqOqSL6tar6WZhc0YuTPIww== =GW3k -----END PGP SIGNATURE----- --WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7-- From nobody Mon Jan 11 04:06:52 2021 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 D08D83A0C2A for ; Mon, 11 Jan 2021 04:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 jtv1FjZGFpRL for ; Mon, 11 Jan 2021 04:06:49 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 025DC3A0C85 for ; Mon, 11 Jan 2021 04:06:32 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4DDsr71ndjz1yKf for ; Mon, 11 Jan 2021 13:06:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610366791; bh=qsXw4/PQhwUmWr2qZcenvoto2seaCLYzEju00FjbQ84=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=xIr54HQRAYRHVwCUQk8PmyZjnDGwZzYUBVm7b+8oAMlfqxe3cp0UKP9vP2XXX4tDl nS5tgYnNlO7lEd5jU+mJDdmFFPV7cNNL+hL69a2zMgBzSNCu2yudtotQkpm2hOpRi9 KalGpeQwcrjThvNrZYKZiwSs62BqqCyN4KQA+90EaQiqAc+5tGYUO1RxSPm/NzGGUp NcI3VH5czijhFKl/htBZftNqKOkhrSxuBGkrHz+KXDomj903AG/hsCyjTcfjmAcFxA yJQ3nByfaRLFtlQPrIBAwocL28XlwxCPs8anMMnQwRbtBEEuUCp8VFqw9Wx0EaSdLB scAMM+iHgoyuA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4DDsr711gJzyQh for ; Mon, 11 Jan 2021 13:06:31 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-bosh-dots-quick-blocks-00.txt Thread-Index: AQHW6BE+e4a7glWno0iUb+SxdUBAEKoiUnHw Date: Mon, 11 Jan 2021 12:06:30 +0000 Message-ID: <30749_1610366791_5FFC3F47_30749_168_2_787AE7BB302AE849A7480A190F8B9330315B71FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161036637813.11527.15818091495971687767@ietfa.amsl.com> In-Reply-To: <161036637813.11527.15818091495971687767@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: [Dots] TR: New Version Notification for draft-bosh-dots-quick-blocks-00.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 Jan 2021 12:06:51 -0000 SGkgYWxsLCANCg0KKENjaSdpbmcgY29yZSBXRyB3aGVyZSB0aGUgbmV3IGJsb2NrcyBhcmUgZGVm aW5lZCkNCg0KVGhpcyBzcGVjIGRlZmluZXMgbmV3IGF0dHJpYnV0ZXMgdGhhdCBjYW4gYmUgbmVn b3RpYXRlZCBiZXR3ZWVuIERPVFMgYWdlbnRzIHRoYXQgc3VwcG9ydCBRLUJsb2NrMS8yLiBBcyBh IHJlbWluZGVyLCB0aGVzZSBvcHRpb25zIGFyZSBkZXNpZ25lZCB0byBhbGxvdyBmb3IgZmFzdGVy IHRyYW5zbWlzc2lvbiBpbiBET1RTLWxpa2UgZW52aXJvbm1lbnRzLiANCg0KQ29tbWVudHMgYXJl IHdlbGNvbWUuIA0KDQpDaGVlcnMsDQpKb24gJiBNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQpEZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBsdW5kaSAxMSBqYW52aWVyIDIwMjEgMTM6MDAN CsOAwqA6IEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPjsgQk9VQ0FEQUlS IE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCk9iamV0wqA6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nr cy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9zaC1kb3RzLXF1aWNr LWJsb2Nrcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1l ZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcw0KUmV2aXNpb246CTAwDQpUaXRsZToJCURpc3Ry aWJ1dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgU2ln bmFsIENoYW5uZWwgQ29uZmlndXJhdGlvbiBBdHRyaWJ1dGVzIGZvciBGYXN0ZXIgQmxvY2sgVHJh bnNtaXNzaW9uDQpEb2N1bWVudCBkYXRlOgkyMDIxLTAxLTExDQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkxNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcy0wMC50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3NoLWRv dHMtcXVpY2stYmxvY2tzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3NoLWRvdHMtcXVpY2stYmxv Y2tzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBuZXcgRE9U UyBzaWduYWwgY2hhbm5lbCBjb25maWd1cmF0aW9uDQogICBwYXJhbWV0ZXJzIHRoYXQgYXJlIG5l Z290aWF0ZWQgYmV0d2VlbiBET1RTIHBlZXJzIHRvIGVuYWJsZSB0aGUgdXNlDQogICBvZiBRLUJs b2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucy4gIFRoZXNlIG9wdGlvbnMgZW5hYmxlIGZhc3Rlcg0K ICAgdHJhbnNtaXNzaW9uIHJhdGVzIGZvciBsYXJnZSBhbW91bnRzIG9mIGRhdGEgd2l0aCBsZXNz IHBhY2tldA0KICAgaW50ZXJjaGFuZ2VzIGFzIHdlbGwgYXMgc3VwcG9ydGluZyBmYXN0ZXIgcmVj b3Zlcnkgc2hvdWxkIGFueSBvZiB0aGUNCiAgIGJsb2NrcyBnZXQgbG9zdCBpbiB0cmFuc21pc3Np b24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK From nobody Mon Jan 11 04:18:40 2021 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 C28CB3A03EE; Mon, 11 Jan 2021 04:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=smyslov.net 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 Mx9c5dTG6z6t; Mon, 11 Jan 2021 04:18:35 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 779703A03F4; Mon, 11 Jan 2021 04:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=POQdEdpZaF3ZQbfcoFKF2F82P7/gbFA4K8LTBN4orUE=; b=f49/sfW7swrvgsS+VSccDbjien niPHZjjL5qnl1FPnKyRcCQPFg1s/rt/k0ddWeV/B4UgQaxBPuGuMAsRQQ2x3oUZD2aF/B8Fy6YYQm yD7kbn/KlzLxMSrzcggDeBMkW7uipcIZmarTUB99U32/hxSL+t2mUtmyoVu613C+KxcTznDhaFhXY aQrDvQZft24HjjptL8za1EOQnQ6E1IvQosk6dpssBUfD6F17JbW/g65IR2tuwr67eqNPghDqr+ML5 njqFM5x72EdnWTP5UAz3xGiyO4INO3l3sh3LNCsvDuO3C8m2+/l8fpIxQ2WcdxGt/JntsLG62dMKT SnKLDYPQ==; Received: from [93.188.44.203] (port=61025 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kyw9Y-00085Y-Vn; Mon, 11 Jan 2021 07:18:33 -0500 From: "Valery Smyslov" To: Cc: , Date: Mon, 11 Jan 2021 15:18:30 +0300 Message-ID: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdboExmPFEy9rbFYSuuk7Fj0p4nv4A== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 12:18:38 -0000 Hi authors, while preparing shepherd write-up for draft-ietf-dots-telemetry-15, in accordance with BCP78 and BCP79 I have to ask all authors and contributors whether they are aware of any IPR regarding this document. Can you please confirm that you are not aware of any IPR or disclose any IPR you are aware of that are concerned with this draft. I'd also like to ask authors about implementation status of the draft. Are there any implementations you are aware of? Regards, Valery. From nobody Mon Jan 11 04:22:48 2021 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 D04623A03FC; Mon, 11 Jan 2021 04:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 nzJ6QPO1rN56; Mon, 11 Jan 2021 04:22:45 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 646D13A03F5; Mon, 11 Jan 2021 04:22:45 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DDtBr0j5lzyxF; Mon, 11 Jan 2021 13:22:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610367764; bh=iyshFOEt8zfydW2gBHth00vMTXmAobAdApO3/K9eelU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=lrMPAVcwOIlHvC7jwoWlQEA6aBtDYcXmkugki0/are8rVcW/Q9EyzWVdh21G0kvEC AIfIkzZz1Lp67GY3d3VL9oIvBa03yAfFZhw0WWXt6YAb59aHLxBp4lMTwoJovN50Zn Jdm0whBet0/IpdmVyqyKNK+xxcSag1/3RlJoSKpTd6N2AsnsUFYTiduXR41flnlOcQ uy/5uIPIkFjWdorNeDmIjX8iShRVBOdbo6CfuqVs3sUt2suQwlK5vWWUirhHmQBHkB WZmhULtBFVStF58+X7rPMBPei0vZFj2y9EgT8I2KADQqTAgmKKH9LEQwIanSaNW1gd dUYOF6oWGO0xA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4DDtBq71RwzyQ9; Mon, 11 Jan 2021 13:22:43 +0100 (CET) From: To: Valery Smyslov , "draft-ietf-dots-telemetry@ietf.org" , kaname nishizuka CC: "dots-chairs@ietf.org" , "dots@ietf.org" Thread-Topic: IPR confirmation for draft-ietf-dots-telemetry-15 Thread-Index: AdboExmPFEy9rbFYSuuk7Fj0p4nv4AAASARA Date: Mon, 11 Jan 2021 12:22:42 +0000 Message-ID: <1642_1610367764_5FFC4314_1642_489_1_787AE7BB302AE849A7480A190F8B9330315B725E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> In-Reply-To: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 12:22:47 -0000 Hi Valery, all,=20 I don't have any IPR nor I'm aware of any related to this draft.=20 I let Jon and Kaname further comment on the implementation status. Cheers, Med > -----Message d'origine----- > De=A0: Valery Smyslov [mailto:valery@smyslov.net] > Envoy=E9=A0: lundi 11 janvier 2021 13:19 > =C0=A0: draft-ietf-dots-telemetry@ietf.org > Cc=A0: dots-chairs@ietf.org; dots@ietf.org > Objet=A0: IPR confirmation for draft-ietf-dots-telemetry-15 >=20 > Hi authors, >=20 > while preparing shepherd write-up for draft-ietf-dots-telemetry-15, > in accordance with BCP78 and BCP79 I have to ask all authors and > contributors whether they are aware of any IPR regarding this > document. > Can you please confirm that you are not aware of any IPR or disclose > any IPR you are aware of that are concerned with this draft. >=20 > I'd also like to ask authors about implementation status of the > draft. > Are there any implementations you are aware of? >=20 > Regards, > Valery. >=20 >

___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Jan 11 04:35:12 2021 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 BDE933A0825 for ; Mon, 11 Jan 2021 04:35:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 bWfZSekAgQxE for ; Mon, 11 Jan 2021 04:35:08 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 1DE9E3A0858 for ; Mon, 11 Jan 2021 04:35:07 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kywPZ-0006S9-P6; Mon, 11 Jan 2021 12:35:05 +0000 From: To: "Valery Smyslov" , Cc: , References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> In-Reply-To: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> Date: Mon, 11 Jan 2021 12:35:16 -0000 Message-ID: <069401d6e816$36edb180$a4c91480$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJShx4a4atxs/TYiTG3ltSr2CDVO6krGiJA Content-Language: en-gb Archived-At: Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 12:35:10 -0000 Hi Valery, I do not hold, or know of any IPR associated with this draft. Both go-dots and my proprietary implementations have implemented this draft. Regards Jon > -----Original Message----- > From: Valery Smyslov [mailto: valery@smyslov.net] > Sent: 11 January 2021 12:19 > To: draft-ietf-dots-telemetry@ietf.org > Cc: dots-chairs@ietf.org; dots@ietf.org > Subject: IPR confirmation for draft-ietf-dots-telemetry-15 > > Hi authors, > > while preparing shepherd write-up for draft-ietf-dots-telemetry-15, > in accordance with BCP78 and BCP79 I have to ask all authors and > contributors whether > they are aware of any IPR regarding this document. > Can you please confirm that you are not aware of any IPR > or disclose any IPR you are aware of that are concerned with this draft. > > I'd also like to ask authors about implementation status of the draft. > Are there any implementations you are aware of? > > Regards, > Valery. From nobody Mon Jan 11 04:47:55 2021 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 18AD63A095E; Mon, 11 Jan 2021 04:47:53 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id milY0RiFmCYd; Mon, 11 Jan 2021 04:47:51 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBFF3A0957; Mon, 11 Jan 2021 04:47:51 -0800 (PST) Received: from fraeml713-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DDtdz5tWNz67Zp1; Mon, 11 Jan 2021 20:42:47 +0800 (CST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 11 Jan 2021 13:47:49 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 11 Jan 2021 20:47:47 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.2106.002; Mon, 11 Jan 2021 20:47:47 +0800 From: "Panwei (William)" To: Valery Smyslov , "draft-ietf-dots-telemetry@ietf.org" CC: "dots-chairs@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 Thread-Index: AdboExmPFEy9rbFYSuuk7Fj0p4nv4AABLgOg Date: Mon, 11 Jan 2021 12:47:47 +0000 Message-ID: References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> In-Reply-To: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.99.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 12:47:53 -0000 Hi Valery, all,=20 I don't have any IPR nor I'm aware of any related to this draft.=20 Regards & Thanks! Wei Pan > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Valery Smyslov > Sent: Monday, January 11, 2021 8:19 PM > To: draft-ietf-dots-telemetry@ietf.org > Cc: dots-chairs@ietf.org; dots@ietf.org > Subject: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 >=20 > Hi authors, >=20 > while preparing shepherd write-up for draft-ietf-dots-telemetry-15, in > accordance with BCP78 and BCP79 I have to ask all authors and contributor= s > whether they are aware of any IPR regarding this document. > Can you please confirm that you are not aware of any IPR or disclose any = IPR > you are aware of that are concerned with this draft. >=20 > I'd also like to ask authors about implementation status of the draft. > Are there any implementations you are aware of? >=20 > Regards, > Valery. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Jan 11 05:04:37 2021 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 1C32A3A09C0; Mon, 11 Jan 2021 05:04:31 -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: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <161037027105.15834.255075233056658139@ietfa.amsl.com> Date: Mon, 11 Jan 2021 05:04:31 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-call-home-13.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, 11 Jan 2021 13:04:31 -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 Call Home Authors : Tirumaleswar Reddy Mohamed Boucadair Jon Shallow Filename : draft-ietf-dots-signal-call-home-13.txt Pages : 44 Date : 2021-01-11 Abstract: This document specifies the DOTS signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client, and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack. 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 Call Home"; 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) Signal Channel Specification" (used to be I-D.ietf-dots- rfc8782-bis) Please update TBD/TBA statements with the assignments made by IANA to DOTS Signal Channel Call Home. Also, 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-signal-call-home/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-13 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call-home-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-13 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 Jan 11 05:59:16 2021 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 B854D3A0CCC for ; Mon, 11 Jan 2021 05:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 gEDv-r1wM4kF for ; Mon, 11 Jan 2021 05:59:11 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED64F3A0CC7 for ; Mon, 11 Jan 2021 05:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1610373549; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QjXBJeAkEonn6WGjGNYqZvM871dXmsNZteHhogiQiYk=; b=TJqtxAUuFxpyvu0xqx/HoTa/Xdw6hdEv9aDiDnyjqnhWWLkXtSNrAZEyrHCiKTwuS+XLbL wXglucfRKkxRsGGcyc0mo0RDeKmtOEaLc48p2/GYSpSbuxZOl7aXN+WzqlV9CKbMZGohLh PH3wnBWeug21atd36OLky52wc1p/9SI= Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-444-besestGFNqSLOTH-S7Al_w-1; Mon, 11 Jan 2021 08:58:02 -0500 X-MC-Unique: besestGFNqSLOTH-S7Al_w-1 Received: from PH0PR16MB4118.namprd16.prod.outlook.com (2603:10b6:510:59::7) by PH0PR16MB4294.namprd16.prod.outlook.com (2603:10b6:510:5f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 13:57:59 +0000 Received: from PH0PR16MB4118.namprd16.prod.outlook.com ([fe80::3df7:7a84:7e67:7316]) by PH0PR16MB4118.namprd16.prod.outlook.com ([fe80::3df7:7a84:7e67:7316%3]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 13:57:58 +0000 From: "Konda, Tirumaleswar Reddy" To: "Panwei (William)" , Valery Smyslov , "draft-ietf-dots-telemetry@ietf.org" CC: "dots-chairs@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 Thread-Index: AdboExmPFEy9rbFYSuuk7Fj0p4nv4AABLgOgAAJ3X0A= Date: Mon, 11 Jan 2021 13:57:58 +0000 Message-ID: References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.0.76 dlp-reaction: no-action x-originating-ip: [49.37.166.161] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d43d7f03-0529-49cb-d428-08d8b638e75a x-ms-traffictypediagnostic: PH0PR16MB4294: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: 2/Cz4YKoAy/UPSTgZmPeOqJyg+8+4Pi2xYvw56lIbVFdwzYu1hkRE3AV1RbSM62N7SmDoB3qpILyBklRgcq05rHroMMsIU34oiTNgdKzEpyZCA9w0zTXNPudVCwRS1mr/HROHixlerNTEsKLyfq3cPmOn5EK7RodE56J08rw8woi3cMW4J8Gc0ZV5SjBUpgiCoxOyz8scTp04+3nyrL2tek8WkXwFuBDkpmf403fGDjuPCMqcpxN7gPp3o3/I3hLtAhWarTb+Wx2u7Nh9E5wiVlULIVLjdsWKLmazWUbE/moQMsdxFRPGcXgyLf4u4kP+paTgB3lkiVF/QMFQl+0V0RKtnt39ibqK/FROhw55aTEydYbHaia9/YF1m5IerZeonyDiVgym5XtWz4dNFEbTHrY7L3mlcqPzfTG1VUFz66RaCKdZzKWox31EUvci0MGUQgn9OZqG6emIzO5XbNTlk++TaGRFi95hsGJoehNgfaPS0iRuOn1zw6cKTrxSeg4HClyfDCR7EuyEemAIzru5LpbPmi9rQYTcHxIpdC/MnA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR16MB4118.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(32952001)(4326008)(186003)(86362001)(26005)(7696005)(64756008)(316002)(66556008)(54906003)(52536014)(66446008)(83380400001)(8936002)(66946007)(66476007)(478600001)(2906002)(966005)(110136005)(71200400001)(9686003)(8676002)(55016002)(6506007)(53546011)(5660300002)(33656002)(76116006)(85282002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?us-ascii?Q?kA2tC+DLrpfOUbwtdbqkn1d9BnnSvdslGCwW1Pc2FzoDCkRmhFktZaViMROO?= =?us-ascii?Q?V7DunYdWoGzIJs94YPZaWhwUa6XJZ9OaQX2y39P4+qZ0AchLIJF/g2bFq3EU?= =?us-ascii?Q?EChxkUQ0HRykiKg/4YQ9eJj/K9L2HK+7MI4oHcL2VIwY/JPt1T3uS+i1EeO5?= =?us-ascii?Q?CJ7ZbengS9Xu2rAUTZ+HOdx2RowEHhg5b7TMuT441B9OV8Fps0VrtAwjuLPD?= =?us-ascii?Q?hZ2oVU1XDkCQofjJvnpfSkCqGbTwJpO0+HuGGXDXa2YRQhWqTsSCJ9sO+gPz?= =?us-ascii?Q?PLtMuSfnBIdn8wK71s3vsoHgE2BhIYmnZSWVDU/dWgE6mCvvYdO0Kkj2CmXq?= =?us-ascii?Q?nK6GMzjAHGQJdfKEJw3nxMV1+mrT0y2QhW4jqh0LNyvJ3xYnQh7OLjpoQ/u3?= =?us-ascii?Q?GEawxf7jBj2wuEIdd9gsrw2LISc1NSikTtIqEnwn40q1YCdYJ3l5COzvavKm?= =?us-ascii?Q?YWo+YJmE9AhejOV2LZXV69Dw7R6vMPNt9KbKLUdFMOyQc1mwMRNdgwy9Qolh?= =?us-ascii?Q?sNVP9pv4MQHJqjiIBlQcaN/Yj3MHxtgX0xSRBUu0KaMsVHNlaerzvohZFeaG?= =?us-ascii?Q?4xmu0mpDETsMshUbz8Th2Zdj3B7qOIEopO8Gr6EvXk/nf2odYkDscgPwrybr?= =?us-ascii?Q?roCArg5ui6yF7W2cJMEiiAZWvA/ggo3n3xJZ8OeSTE1XwD+OeTxwB13BUw32?= =?us-ascii?Q?btDl6ZNMHOaXMXwtC8UsQiefTul5KBR7aIQIe754iWk5CBgoHn/CJC4d53oi?= =?us-ascii?Q?8SMqUg5SRBniR36taeOxO1bjFZJvvXCopen10Duo4SzIksRVC6gkajv0gs1N?= =?us-ascii?Q?9d0CE585EG/IAuBnRIsJHWdJ1fDjnjre2lSz+lLhUgBBAVrEqj6wUl4majNc?= =?us-ascii?Q?fOaLFz4rzkS22q1OEDF3Wuv0AR0lVS3nZczy1YJAFr7xZKiSGtPVMnmkrG3b?= =?us-ascii?Q?Up3fNnIfzNh+Zhqc2AzGXjFkQzSo11BzGRz0q1FWzcM=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR16MB4118.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d43d7f03-0529-49cb-d428-08d8b638e75a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 13:57:58.8081 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sgi+bcDiWQzW29TMeRKmecqZY4bto3Ex5vcExMNcgBjT9vIdtLVRiaGE85UpQe6Ue5hJ7/OD2SGsbXZSXyFIgz2nUyvY13xAAMTHO4DNmsqM7XVZnXHaVW5sx/CAqybx X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR16MB4294 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA40A35 smtp.mailfrom=tirumaleswarreddy_konda@mcafee.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 13:59:14 -0000 I am not aware of any IPR related to this draft. -Tiru > -----Original Message----- > From: Dots On Behalf Of Panwei (William) > Sent: Monday, January 11, 2021 6:18 PM > To: Valery Smyslov ; draft-ietf-dots- > telemetry@ietf.org > Cc: dots-chairs@ietf.org; dots@ietf.org > Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Hi Valery, all, >=20 > I don't have any IPR nor I'm aware of any related to this draft. >=20 > Regards & Thanks! > Wei Pan >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Valery Smyslov > > Sent: Monday, January 11, 2021 8:19 PM > > To: draft-ietf-dots-telemetry@ietf.org > > Cc: dots-chairs@ietf.org; dots@ietf.org > > Subject: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 > > > > Hi authors, > > > > while preparing shepherd write-up for draft-ietf-dots-telemetry-15, in > > accordance with BCP78 and BCP79 I have to ask all authors and > > contributors whether they are aware of any IPR regarding this document. > > Can you please confirm that you are not aware of any IPR or disclose > > any IPR you are aware of that are concerned with this draft. > > > > I'd also like to ask authors about implementation status of the draft. > > Are there any implementations you are aware of? > > > > Regards, > > Valery. > > > > _______________________________________________ > > 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 Mon Jan 11 07:38:03 2021 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 9B41B3A0F48; Mon, 11 Jan 2021 07:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FSL_HAS_TINYURL=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=YAEOslJT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mXZVbQfh 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 H7Mw8fvIDkNt; Mon, 11 Jan 2021 07:37:59 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA363A0F3D; Mon, 11 Jan 2021 07:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5880; q=dns/txt; s=iport; t=1610379479; x=1611589079; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xNjLspMgvxX5tCOJupJ2hdQD1Ja9q4Guimef+ByPxhI=; b=YAEOslJTFFmXjAL/j6P1IizinAzfbkc/fKljd48/g4XrRSNKM85hPDLF z9uBQ+B3RQtaUv+axnr5yjfyBE9tqpDCUnWsbSlqV4/C57oI9OMvdz8UQ uOB95kcdDDNSwKLezgEt42SDPxaviyommWgJwmfPYldsu3Rh3FP/XZFvV Q=; X-IPAS-Result: =?us-ascii?q?A0BUAABXb/xfkIQNJK1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?T0FAQELAYFSUX1bLy4KhDWDSAONdAOZEoEuFIERA1QLAQEBDQEBHwoEAgQBA?= =?us-ascii?q?YRKAheBWgIlNgcOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhjgMhXMBA?= =?us-ascii?q?QEEIxEMAQE3AQsEAgEIEQQBAQMCIwMCAgIwFAEICAIEAQ0FCIMeAYJVAy4BA?= =?us-ascii?q?6JiAooldoEygwQBAQaFGxiCEAMGgQ4qAYJ0g36CTIJrgQcmG4FBP4ERQ4JWP?= =?us-ascii?q?oQJARIBI4MWNIIsgWlgXwQULxANQyMQFDsQH5AVg0ilIQqCd4krklaDKYovl?= =?us-ascii?q?QiUEokfgXeWKgIEAgQFAg4BAQaBXQYraXBwFYMkIS8XAg2BFo0LGh2DOopYd?= =?us-ascii?q?BoBHAIGAQkBAQMJfItOAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AWy9gyBbjT2j4AlRCn0+qziv/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD4LB4vRLhqzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutYEfbpHK/qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,338,1602547200"; d="scan'208";a="665442991" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jan 2021 15:37:58 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 10BFbvkH009441 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2021 15:37:58 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 Jan 2021 09:37:57 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 11 Jan 2021 10:37:56 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 11 Jan 2021 10:37:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ed6g5jUmndMzeCR747u1SH/EMDDHDB/JzFruyIzsK+DK4wopQO3OIqrvePVYJgN6J1JvW+5LV4b0pFQ6hC3mEBris7CcyYtmJIT6x90/lpu/gMQaxFlFVU+hz5/yTyF5kM9IOThR6TPk0lVCiyk8Gfxzu+iJgydY17/Tuc1HprsB7HDyricVsWTd6B+bAceIkt+N1Zg1R9hhPgtKxT3MF6wZa+lSHn0ymYK8NKUUgtGBfABoRYniQq4LbOD1UBN7oYznmsRewM7uvv6KnEGY8Y6IuYOYV6oj2FTg5yOvKLCP/uzEfY39JQzhn//kkRcZri0zJIWCwvFrTLAOt8LmPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xNjLspMgvxX5tCOJupJ2hdQD1Ja9q4Guimef+ByPxhI=; b=etiljOzGIvSYohMh3SkhdWXHSKoetkVa7Wmd+0royBVpOJKUxvsT+TzUjE1zXOHPspqpjA5TAVMuigkNSgXyYH/Vr1WXsnpkBBhyHeS/ZKYpDWUnzPtGf1vf5UobLC+uAJbE9LUcIQJQEwhci6Xnr0cVcINrUGWjHVsWJX/113KUtMQ7J8YvLZUQwFEXNglV9YHr1xIHbZW40hiFjrjcEk2nQyVZLXnv0ttRksYlJ5R1b2mUxUOrKZuvUsjhLE/UNd+RU4um9+Xt8pKBptMnRV05BuTBxov8j0nY1yfODHQya8S8UbDZuAN7F/XeNufQBDGBtlcUAbADlqeoa/HjHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xNjLspMgvxX5tCOJupJ2hdQD1Ja9q4Guimef+ByPxhI=; b=mXZVbQfhAHh3h6nU0qK9wOEChkgGYKrs8Xg5w7IrC06EfdLTKeuq1I6BCHPlTnNXQI3pL1wP14A8poj9LBQJs7AvY1JpntXqjluriBuQ1JQfWK+CdlAfirZWDDrXz/N3OIaWhNtQ9uwEkoqPo9ndqQ6YXaf1PClrYJZL7CnGPR0= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3361.namprd11.prod.outlook.com (2603:10b6:208:6d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 15:37:55 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3c82:1fa3:2b18:3afb%6]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 15:37:54 +0000 From: "Rob Wilton (rwilton)" To: "mohamed.boucadair@orange.com" , "Roman Danyliw" , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , Valery Smyslov , "dots@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x04GhVUrubF9E6Ldzi/FU9PuKn5Pw6AgAPYoACAB6gWgIAS/RdggAAHj4CAAAWsAIAElk6AgAZYsdA= Date: Mon, 11 Jan 2021 15:37:54 +0000 Message-ID: References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <703969fb11df49a39c6241bb32934ff6@cert.org> <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21867_1609777571_5FF341A3_21867_195_25_787AE7BB302AE849A7480A190F8B9330315A6CFB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <25331_1610030760_5FF71EA8_25331_128_2_787AE7BB302AE849A7480A190F8B9330315B4512@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <25331_1610030760_5FF71EA8_25331_128_2_787AE7BB302AE849A7480A190F8B9330315B4512@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ccd2c266-2eff-41a6-abae-08d8b646dd4e x-ms-traffictypediagnostic: BL0PR11MB3361: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5080bci5/goXNyy1BOjB8T+C9UFhrBwaLlg83Tb6nowhfu0mwNSvGN8NnnYd0fuhr+RoNVnFcuf+Q0i3PuYE1Xw2PNch60SQEAH/edWYvVnK9fvWnBLeM/JZ8PZK0dgDQAevI1laLbIMg/m5KYaaNVxl+toFYldEBobvvu0rgnOuX+VY/w9BEH3jgH84ost0WO47rsnt1ckQdOeYYiOXOlwy+WG8Xrm1T2yTfou5k5HnfYcE1WUq45Lh8kjUpO4VgExrcyyOF40/SxJqam/4Y4zwGG6LrYDY/pFI24rZHDIv20dwrVm71qWluk6PQZP5dyjZi2BP3+aOCI21UDIxpe6dbz8oEpkfUr6uABC+jMwY1Toppb09YtPnFr8HQKNxuOxRZm2jeRpLpnPKMsDF28opZ21/J3E/yiv1Ivo4XWkTnSH/FsOLeT7BIFea3+8+VhePRyhYiiNm6A1vi2B8Uw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(366004)(376002)(39860400002)(2906002)(54906003)(186003)(4326008)(8676002)(7696005)(110136005)(64756008)(478600001)(76116006)(966005)(5660300002)(26005)(33656002)(53546011)(86362001)(66446008)(316002)(66556008)(66476007)(83380400001)(66946007)(6506007)(9686003)(52536014)(55016002)(71200400001)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UHFFbnFRZDJqN2h1NTUyTHg4UUgreDhMQnJSOWpjQXhienIxVS9hUlNHZitW?= =?utf-8?B?RWdMY1lGRkE5TWE2elpqZGZKbzNwSFh2WVM0b2hkcUtJL051c281SlRiMlM3?= =?utf-8?B?aHBtY3FrNXRiUGtzaFpRZTY2SXBXZUNDTE9WYzNtZ2ZCS0t4L3VnU3FjV2VG?= =?utf-8?B?dmh6dURITTJKenZBTThVcjh5TnB5OHlTOStuUEZtaW1ydzJaMHVPejByMDR5?= =?utf-8?B?ekhqMXhLWnRXbENTOWNXZUE2aVpkT0JZeVhHaVdUMnc4Vmw0djE4NklVR0N0?= =?utf-8?B?MGZmUEdIbitBQ281L2luN3ZsVG03eExwR2NzaFNieDAwa1NMVGJWUWxWU3Zp?= =?utf-8?B?MHMzTWN1QWQ0MWI5WWVoVEtCalNWcGlTK2UyYlJjaHpVMEFQcWl4ak0xM0Yr?= =?utf-8?B?dVE1VFpjM21GcDQ0bmdhbVc0QjM2Q0Q2RHdWczVBZmt0bnR5cVZvM3c1T2Fv?= =?utf-8?B?RldET3dHY0g3WCtqQ3lzS2thMi9oVkVaV1ZXdHJHT0VmZVovUDN4SjhLaE1u?= =?utf-8?B?em5QVnJoU2ZJMlNkNFJZeWo1Qmg5aHRsS3ZxY3pSZ0wvOUkzbVlGNEJBMWkx?= =?utf-8?B?eGFhbXc1NnR6UXJZZ3pSejZ3a0laLzNrYjFpZWZ4NnRoRU45YkNEYmlxdG84?= =?utf-8?B?TXVpMS92cTNkM2ZxL0ZhR1UzdVJqN3luZzdLdjRXbDNSS3FNOTNYNkhnM1RK?= =?utf-8?B?VEoydjFpbXdqcTlWSG5UTWdpZjRzZ2lnT2dqb0g3TkgxY1JRQW1QMnl6VkdO?= =?utf-8?B?Skx5K0g0Zmh5VHdSUzdoOEQ2YjhtNWV5SGdiYmgxbHNaaEZ2S1l5RXlZMlN4?= =?utf-8?B?c2VPcDFBa2V0Zzl2REw3NXNHcjJlM1ZDTUUyRWtySC8xVVRkWkNJWlRPYmxu?= =?utf-8?B?R1oveURZVUxGeUNsanJUUmRxUDFBbm9wekRKbzgyUHB0SkZMM0FLZlBlVHI3?= =?utf-8?B?NUdESGFmZ0ErakJQN1ZBWUxnV0NTaDl4UzU4SmtoZEswWW0rUytQaFR4c0I0?= =?utf-8?B?NmVpaVJqUUYwcGU0b3dTdWxXeGplb3RZclZoRjhKN01GU2pLN0svRFRCTzdI?= =?utf-8?B?NSs3K2w4VUQvaVNzL1l1SkVSVXJad2NQK01vcHI5bVRHK2ZEQUNRTUorU3Ur?= =?utf-8?B?UFYxQ3V4NG9kRFRSQ2dxWStEQkxaQWwrYndzV2FZUm1ETEVnN204QjVITGsz?= =?utf-8?B?bG82NmtjQUVXK2JMUHFaR21Bc2MzdjB3Rmo2TjFuQytlZVRXaGFFTTZxRFcz?= =?utf-8?B?MnQ4MndEa29adHF2M0Z6Um92UElJL0wzeWp1eVhSVFQzL005cXJhbnB3amlD?= =?utf-8?Q?pG7xt4X27ORM0=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ccd2c266-2eff-41a6-abae-08d8b646dd4e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 15:37:54.8852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yVAj2R1IHUxK0IqkAryDGNI5RnBKSWLLWMEQrPvk6kYHA8EsKbUMwnMSQyCwi/VpiTbDa96kj94zNuwAyMz8UQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3361 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (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: Mon, 11 Jan 2021 15:38:02 -0000 SGkgTWVkLA0KDQpZZXMsIEkgdGhpbmsgdGhhdCB0ZXh0IGlzIGhlbHBmdWwgYW5kIGxvb2tzIGdv b2QuICBUaGFua3MgZm9yIGFjY29tbW9kYXRpbmcuDQoNClJlZ2FyZHMsDQpSb2INCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IFNlbnQ6IDA3IEphbnVhcnkg MjAyMSAxNDo0Ng0KPiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29t PjsgUm9tYW4gRGFueWxpdw0KPiA8cmRkQGNlcnQub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5v cmc+DQo+IENjOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9yZzsgZG90 cy1jaGFpcnNAaWV0Zi5vcmc7DQo+IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+ OyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0NCj4gMTE6ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpDQo+IA0KPiBIaSBSb2IsDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSBpbnB1 dHMuDQo+IA0KPiBXZSBwcmVwYXJlZCBhIHRleHQgcHJvcG9zYWwgdGhhdCB5b3UgY2FuIHNlZSBh dDogaHR0cHM6Ly90aW55dXJsLmNvbS9kb3RzLQ0KPiBjYWxsLWhvbWUtbGF0ZXN0Lg0KPiANCj4g UGxlYXNlIGxldCB1cyBrbm93IGlmIGFueSBmdXJ0aGVyIG1vZGlmaWNhdGlvbiBpcyBuZWVkZWQu DQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gPiBEZcKgOiBSb2IgV2lsdG9uIChyd2lsdG9uKSBbbWFpbHRvOnJ3aWx0b25AY2lzY28u Y29tXQ0KPiA+IEVudm95w6nCoDogbHVuZGkgNCBqYW52aWVyIDIwMjEgMTc6NTYNCj4gPiDDgMKg OiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PjsgUm9tYW4NCj4gPiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz4NCj4gPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9y ZzsgZG90cy0NCj4gPiBjaGFpcnNAaWV0Zi5vcmc7IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215 c2xvdi5uZXQ+OyBkb3RzQGlldGYub3JnDQo+ID4gT2JqZXTCoDogUkU6IFJvbWFuIERhbnlsaXcn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4gPiBob21lLTExOiAo d2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gSGkgTWVkLA0KPiA+DQo+ID4gUGxl YXNlIHNlZSBpbmxpbmUgLi4uDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPg0KPiA+ID4gU2VudDogMDQgSmFudWFyeSAyMDIxIDE2OjI2DQo+ID4g PiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgUm9tYW4gRGFu eWxpdw0KPiA+ID4gPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiA+ ID4gQ2M6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3RzLQ0K PiA+IGNoYWlyc0BpZXRmLm9yZzsNCj4gPiA+IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xv di5uZXQ+OyBkb3RzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogUm9tYW4gRGFueWxpdydz IERpc2N1c3Mgb24NCj4gPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLQ0KPiA+ ID4gMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4gPg0KPiA+ID4gSGkgUm9iLA0K PiA+ID4NCj4gPiA+IFdlIHRob3VnaHQgdGhpcyB3YXMgY292ZXJlZCBieSB0aGUgZm9sbG93aW5n Og0KPiA+ID4NCj4gPiA+ICAgIE90aGVyIG1vdGl2YXRpb25zIGZvciBpbnRyb2R1Y2luZyB0aGUg Q2FsbCBIb21lIGZ1bmN0aW9uIGFyZQ0KPiA+ID4gICAgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMS4x IG9mIFtSRkM4MDcxXS4NCj4gPiBbUlddDQo+ID4NCj4gPiBJIGhhZCBtaXNzZWQgdGhlIHJlZmVy ZW5jZS4NCj4gPg0KPiA+ID4NCj4gPiA+IFdlIHByZWZlcnJlZCB0aGF0IGNpdGF0aW9uIHZzIGR1 cGxpY2F0aW5nIHRoZSA2IGl0ZW1zIGluIHRoaXMNCj4gPiBkb2N1bWVudA0KPiA+ID4gYXMgd2Vs bCAocy9tYW5hZ2VtZW50IHN5c3RlbS9taXRpZ2F0aW9uIHN5c3RlbSkuDQo+ID4gW1JXXQ0KPiA+ DQo+ID4gSSBhZ3JlZSB0aGF0IGEgcmVmZXJlbmNlIGlzIGJldHRlciB0aGFuIGNvcHlpbmcgdGhl bSBhbGwgb3V0IGFnYWluDQo+ID4gaGVyZS4NCj4gPg0KPiA+ID4NCj4gPiA+IEkgdW5kZXJzdGFu ZCBmcm9tIHlvdXIgY29tbWVudCB0aGF0IHRoZSBsaW5rIHdhcyBub3QgZXZpZGVudC4gSWYNCj4g PiBzbywNCj4gPiA+IHdpbGwgc2VlIGhvdyB0byBtYWtlIHRoaW5ncyBiZXR0ZXIuDQo+ID4gW1JX XQ0KPiA+DQo+ID4gU28sIHRoZSBkZXNpcmUgdG8gd2FudCB0byBiZSBhYmxlIHRvIHN0b3AgRERP UyB0cmFmZmljIGF0IHNvdXJjZSBpcw0KPiA+IGNsZWFyLCBidXQgaXQgd2Fzbid0IGNsZWFyIHdo eSBDYWxsIEhvbWUgaXMgdGhlIG1lY2hhbmlzbSBuZWVkZWQgdG8NCj4gPiBhY2hpZXZlIHRoYXQu ICBQZXJoYXBzIHlvdXIgc2VudGVuY2UgY291bGQgYmUgZXhwYW5kZWQgYSBiaXQgd2l0aG91dA0K PiA+IGNvcHlpbmcgYWxsIHRoZSByZWFzb25zLiAgRS5nLiwgbWF5YmUgc29tZXRoaW5nIGFsb25n IHRoZSBsaW5lcyBvZg0KPiA+IC4uLg0KPiA+DQo+ID4gQWx0aG91Z2ggQ2FsbCBIb21lIGZ1bmN0 aW9uYWxpdHkgaXMgbm90IGFsd2F5cyBuZWNlc3NhcnkgdG8NCj4gPiBmYWNpbGl0YXRlIERPVFMg RERPUyBtaXRpZ2F0aW9uIGluIHRoZSBzb3VyY2UgbmV0d29yaywgdGhlcmUgYXJlDQo+ID4gdmFy aW91cyBtYW5hZ2VtZW50IGFuZCBkZXBsb3ltZW50IGNvbnNpZGVyYXRpb25zIHRoYXQgbWFrZSBD YWxsIEhvbWUNCj4gPiBmdW5jdGlvbmFsaXR5IGRlc2lyYWJsZSBvciByZXF1aXJlZCBpbiBzb21l IGNhc2VzLCBlLmcuLCBhcw0KPiA+IGRpc2N1c3NlZCBpbiBTZWN0aW9uIDEuMSBvZiBbUkZDODA3 MV0uDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFJvYg0KPiA+DQo+ID4NCj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiANCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoNCj4gcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+IGEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPiBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+IE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91DQo+IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkDQo+IGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+IHRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0K PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kDQo+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4NCj4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KPiBUaGFuayB5b3UuDQoNCg== From nobody Mon Jan 11 08:39:15 2021 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 56E7C3A103A for ; Mon, 11 Jan 2021 08:39:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Y1id73Wk6PWv for ; Mon, 11 Jan 2021 08:39:07 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 636333A1043 for ; Mon, 11 Jan 2021 08:39:07 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kz0Df-0006d3-Vx; Mon, 11 Jan 2021 16:39:04 +0000 From: To: "Marco Tiloca" , , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> In-Reply-To: Date: Mon, 11 Jan 2021 16:39:14 -0000 Message-ID: <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVQGW5zMSAr51FjUBa6IWcAGdmCj+qF8iPgA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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 Jan 2021 16:39:09 -0000 Hi Marco, It is good that you are thinking this properly through. FETCH was added = later into this draft and the consequences were not properly thought = through. The new updates have been pushed to https://github.com/core-wg/new-block = and the differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt The PR for the responses below can be found at = https://github.com/core-wg/new-block/pull/13=20 Otherwise, see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 11 January 2021 11:39 > To:supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > Thanks, the updates look good. [Jon] Thanks >=20 > As to the response codes in Section 3.3 "Using the Q-Block1 Option", > wouldn't it make sense to mention also 2.05 (Content) ? Think of a = FETCH > request with a big body, which is actually mentioned at the beginning = of > Section 3.3 and in Section 3.1 (though missing the 2.05 response code > beside it). [Jon] Thanks - added. Also added in 2.02 and 2.05 as being expected = response codes in 3.3. [Jon] For the 2.02, I struggle with why anyone would want to use a POST = with a large payload to cause the resource to get deleted (instead of = using DELETE) , but RFC7252 allows this to happen. OLD Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests and their responses (2.01 and 2.04). NEW Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, = PATCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and = 2.05). [Jon] And added into 3.3 (2.05 is done further into this discussion) NEW 2.02 (Deleted) This Response Code indicates successful receipt of the entire body and = the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). = The token used SHOULD be from the last received payload. The client = should then release all of the tokens used for this body. >=20 > Also, more in general, think of an observe registration, for which the > server eventually sends back a first notification (possibly split into > multiple payloads) with Q-Block2, with a certain Token value. [Jon] OK >=20 > If the observation request used FETCH and was fragmented into several > payloads with Q-Block1, each of which with a different Token, it's = still > true that the notifications can all have any of those Token values and > should have the one of the last received request payload. Jon[OK] >=20 > However, later on the client has to retain that Token value as the one > associated to the observation, to match future notifications to come. = In > this case, there is a deviation from the claim used for other response > codes, i.e. "The client should then release all of the tokens used for > this body." This should concern only 2.01 notifications (hence = including > the Observe option) in response to observation requests with FETCH, so > it can be limited to the context of this section about Q-Block1. [Jon] I was not aware that FETCH could return 2.01 or 2.04. GET does = not return these codes and it is only GET and FETCH that can Observe. = However, it is true what you say for 2.05, so I have added that the = tracked Observe token must be the (if Q-Block1) the one used for = Q-Block1 that has the M bit unset. I have added in some FETCH examples = into the draft. NEW 2.05 (Content) This Response Code indicates successful receipt of the entire FETCH = request body (See Section 2 [RFC8132]) and the appropriate = representation of the resource has been returned. The token used in the = response MUST be the one in the FETCH request that has the Q-Block1 with = the M bit unset. If the FETCH request includes the Observe Option, then = the server MUST use the same token for returning any Observe triggered = responses. The client should then release all of the tokens used for = this body unless a resource is being observed. ~jon >=20 > Best, > /Marco >=20 From nobody Mon Jan 11 11:01:49 2021 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 831913A10E5; Mon, 11 Jan 2021 11:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_BTC_ID=0.498, 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=pass (1024-bit key) header.d=radwareil.onmicrosoft.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 cwiLJdcQUPX8; Mon, 11 Jan 2021 11:01:46 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.1]) (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 0B48B3A1101; Mon, 11 Jan 2021 11:01:45 -0800 (PST) Received: from [100.112.194.26] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-a.eu-west-1.aws.symcld.net id 23/E6-56778-290ACFF5; Mon, 11 Jan 2021 19:01:38 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKJsWRWlGSWpSXmKPExsUi9LZnk+7EBX/ iDdpXCFjcnDGR0WLtmyOsFgt+u1n8PniezaJt+Vdmi3MnpjM6sHm0HHnL6rFkyU8mj+bND1k8 7l3/wBLAEsWamZeUX5HAmrHj/0Hmgs0iFQcnXGBqYLwo2MXIxcEosJRZ4vS3x0wQzjEWiYWta 1ghnM2MEv/e/GYHcVgENjNLbP95hxHEERJYxSRx5dwpNgjnJaPEtDN/gMo4OdgEVCRWfZ3LCG KLCDxjlOh7KA9iMwsES6y80g0WFxZwlfi08TJzFyMHUI2bxKUTSRDlThKXZp8GK2ERUJXo+76 bBaSEVyBJYkVjJcSqXYwSyzs/MoHUcArESez/1QC2llFATOL7qTVMEKvEJW49mQ9mSwgISCzZ c54ZwhaVePn4H9RrvYwSh+90sIMskBBQkFgxTQ2iRlbi0nyIMyUEfCV2LlwI1asl8aF/JiuEX SixdMkyNghbTeLqp6MsELacxKreh1C2jMSDG9vB4SMh8IdZYvqhu1DON2aJzrk/GSGcPg6J6f faWCYwGsxCcjmErSOxYPcnNghbW2LZwtfMIDavgKDEyZlPWBYwsqxitEgqykzPKMlNzMzRNTQ w0DU0NNI1tARiIzO9xCrdRL3UUt3y1OISXUO9xPJiveLK3OScFL281JJNjMCUlVJwoG4H44PX H/QOMUpyMCmJ8rKY/4kX4kvKT6nMSCzOiC8qzUktPsQow8GhJMFbMgkoJ1iUmp5akZaZA0yfM GkJDh4lEV7LuUBp3uKCxNzizHSI1ClGV44JL+cuYua4umoJkFyyEUTefA8imz4ASSGWvPy8VC lx3k3zgZoFQJozSvPgRsNS/yVGWSlhXkYGBgYhnoLUotzMElT5V4ziHIxKwrwqwEwixJOZVwJ 3wSug45iAjmN1+A1yXEkiQkqqgckrhFd0dtm8HWz2eu+2/xL+nv/3lL7PT5eqya+/RcTdVl+v sTiw//vx8KeJlvPCtu/j1X6vvoJH9q+Szt61/q+v/FpkeyxAQn/mr62PjKVCg2bJ+IioqsXde btZ+WWqvf2sqP0FrC6MDe8sO2KKdFfz1X6KEtUvK3V+aF/It+zpjNiuDzec9LX/Ocacrl268e 3lGfPL13I8cGDuX6ppJPRidk7vtbyj/bbXmXOPOKoHLRWWflOs72Xro/52j69yl3DZ+xz1qF6 /4sUsAV2/7unYiTtkvU57v4zfUi5ASnvH7PfJihmnKie/57q7RaMpu1VDje1jWEL488Vp8x0M 5W9tNLnU85fH4eHi5gIlJZbijERDLeai4kQAxsGMh3gEAAA= X-Env-Sender: EhudD@Radware.com X-Msg-Ref: server-26.tower-261.messagelabs.com!1610391694!582230!1 X-Originating-IP: [18.237.140.178] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.60.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9956 invoked from network); 11 Jan 2021 19:01:36 -0000 Received: from p01c.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.178) by server-26.tower-261.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 11 Jan 2021 19:01:36 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FQagCe7qC/9auhdpyfYrvt//Tw8zkeUrX4iGpEvxZZyyP1i7RQ5aTmwy8vuQAohE//WUBrGs2+HEMOjvD50MudOr17wk85KraUVXO4b2yCAk4FM0V8y1eszTcFgyybn6y4quTz/wwms0XN6UtZi5/OaKkb+7i3OtjKNNH1lUrQiwD8UiMU5igWVhnLlgGBfRpjjecFJiUxatN8OFwB1hfM3d9q2XR5VGIxaoMGahgIYzTELZkJn2AI+TCHvg5XWTg28poFxgnrRgMDLKEfwIX8LQMccQP7r6+g70FwMkLbSH9l8ooL7LSH4iLAYUGRjjOebLCJEodBmPpi+8I55onQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FHX7V81eDMwlMKJ1QEPN6aafRpxP0JiappQUxXTkFbM=; b=a7+Ey+bwEHIuGwLBueiQEvqGZMiwqoTK3GjMphWHo6SY/zOOYzI4wNwui72Kvk92eKsOf5E641HFqj8G0esVEzkaBCrvk5M4b8uAY+WwWy8uVnwWDO8G7oiO+XuexjX5Dm8s+EPqMM/yxULRyfv1aKDp2KBs00wyZZKFRPd7S/RxW6SSDx17UKrodBf0PclIPLsx4AieJe/NRvtA2CuY0ZMstyHlHmveqWIkYeYXxEXqfjwoolVyXRAXs0xGdY4d78Sb2UArav93DiE60xH8ssxOXfFyKDwP45U8wWADdoFRHtN/i7nccyp5ZSLTOO8Q90XbEk/UDGP71LMHSxyGlw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=radware.com; dmarc=pass action=none header.from=radware.com; dkim=pass header.d=radware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radwareil.onmicrosoft.com; s=selector1-radwareil-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FHX7V81eDMwlMKJ1QEPN6aafRpxP0JiappQUxXTkFbM=; b=vBcDjzpydwt8A3Zxiu4oa7P93AR+aOQQFOCVuyVIi/WSDiOvGy9DrzLrW/cnUWtIejtIlvyFL9/MgEhZTk0/fMEwKl6idpXnAjIMkuXLTvpZEIn4PXNTqqFJKW34Xl7Z76M9Kxb507HuLtAH6x+kEbGz+3VPfQhE4Bea3VEBZgo= Received: from VI1PR01MB7101.eurprd01.prod.exchangelabs.com (2603:10a6:800:19a::18) by VE1PR01MB6143.eurprd01.prod.exchangelabs.com (2603:10a6:803:113::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 19:01:29 +0000 Received: from VI1PR01MB7101.eurprd01.prod.exchangelabs.com ([fe80::5dcb:dabb:d0eb:7349]) by VI1PR01MB7101.eurprd01.prod.exchangelabs.com ([fe80::5dcb:dabb:d0eb:7349%6]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 19:01:29 +0000 From: Ehud Doron To: "Konda, Tirumaleswar Reddy" , "Panwei (William)" , Valery Smyslov , "draft-ietf-dots-telemetry@ietf.org" CC: "dots-chairs@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 Thread-Index: AdboExmPFEy9rbFYSuuk7Fj0p4nv4AABLgOgAAJ3X0AACouGwA== Date: Mon, 11 Jan 2021 19:01:29 +0000 Message-ID: References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.250.62.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e610a87d-d743-405f-15ef-08d8b6634df7 x-ms-traffictypediagnostic: VE1PR01MB6143: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f64vBRSYARo4AP54/+7C/7rV0bRA9PW+WAgk0yQXs/hel0SJBei+6HxKqHWi2hvhnIog1+0VhnAM6n24tlqv4w8x2Zcs5IXDYwTPRnP+8ocxo/EAIqiGgfhti4CAZAdGdcd9CP+ENAEYGJ3Z3x9CqU6zuhjDClj6Q9bdLUn/98aKGtsEkBh1d6htdPYwdF1re5+9PO2Zhr8KjqrRRRVJBTQCfYUwNjQ+FtACGi+tQ1o8QzS/QcqXpphbQYzWr+eP6eonat6TrBZEIisB0jljHHh0qAKTpLFY8ll82umqjVdtx4YqdAGgfXykBJZkTyctvNg/2Ar/U3cNvpk+MYrZ6dLoV3oyA+nIj4XCN4j1Udud59sxf9ZomeXSHyigP1yF27V8vrU1+GICdnS1Ei85yJwt+VSrwybYCnWPORc2g/C1F5kZ3dqOjfJe4rXr5t3974fFHLaUU7pRB5pOr+A5lg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB7101.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(39850400004)(376002)(396003)(71200400001)(966005)(5660300002)(7696005)(86362001)(26005)(2906002)(4326008)(186003)(316002)(52536014)(53546011)(76116006)(66446008)(9686003)(6506007)(54906003)(64756008)(8936002)(110136005)(33656002)(8676002)(66476007)(66946007)(66556008)(478600001)(55016002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?iA1nod2QGbRviWp6uOPhQ8NdNRWGSYpCSLW+HVX1mncsVQCKA9z58LH70XwD?= =?us-ascii?Q?ab8bNqFz3ST7TGkmZDXxt3KeHCo4gIvM3UffwCiaqtO/Ebh7TZO2n1R9aZFc?= =?us-ascii?Q?w2wK+jKtbse9hg4z0w/r3/kW9UD0vh6ap+89DxlFpTvkW5XNYi5TZFk90ZJQ?= =?us-ascii?Q?C+bwPKdQuWZMRyR+YPzzyjIojsLbyWqVXmwCag8hYbrsDHfhXWKgl6Jb3MJV?= =?us-ascii?Q?Q72Cpi5u6BHm3W6d5PQlXfAu11hqx1nC65sKhok9zPJ9YOBGb3cjd7IHhIgy?= =?us-ascii?Q?CuyZKy9iMAJd/TfEB5u5eEmBhx6ZtdmMRpvcl1n6ADIji9df739cbkm3QvoJ?= =?us-ascii?Q?dyBythv5n+9jgSJYt3VgdoQ3vmdeEI5kwy4vz/lYkNS+wE7gyz/3QQs4mqKU?= =?us-ascii?Q?CdR/EG9yDuPaVih/2soEh5/OeIDf80WcXujcnCOC/jEFn2RVMriBHHQ4G5Eq?= =?us-ascii?Q?PGkof5VgAJUX5NrRiVYm4k9wpNZhoVjvIYYbQnFtLXCfYShB215Wbqux+ODI?= =?us-ascii?Q?QvTdqsjxYUDj/eFT0mJpa84F3fq4hUmXAiMQQEzZwDgSNoRGHBtYtzPRbiHj?= =?us-ascii?Q?a4zTnPK/FBIx/ez1y9cmKPLcdE0blp5g3XAjy72zY15oPyonfwKt3BtkA+CE?= =?us-ascii?Q?yDzdwAuAgAXWcdjs2mIALJc7iZWn8zklHyFWSdmDk/XeY/LepDzGSdN5KzkR?= =?us-ascii?Q?StVXqnGOWVWwd1YlHR8LxUqcPGZiKMNBfMkGn/3cJ2e3tbGNdI5vZt6stke0?= =?us-ascii?Q?o191OHejKzB7lIVM54F59PxqcCnBiLvs5noQbh2R8jIOth0V2vWJN0irQ+QU?= =?us-ascii?Q?2yW+Cm0n9nMOZnupOA3ci9bi2h6pcdy+9IIeLYU/Fsio+e1f7keQLp9oFL6V?= =?us-ascii?Q?Aq9IWNQdX2RxxVl6jd0tW8cGlrhKqSQGt8a/09X4hrZbPOhtagDOhbB6UBhL?= =?us-ascii?Q?2hKX5bj05S954brJ8SmNIuSFjVJbTS8pz9bmKywxHpI=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: radware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR01MB7101.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: e610a87d-d743-405f-15ef-08d8b6634df7 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 19:01:29.7955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ae4e000-b5d0-4f48-a766-402d46119b76 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1BpyViyQV+fnoLPSC79E9gscK0CmmT+jl0cABKdH4gAH18uC39UOuLDrvGDmC4VZKU4MbFQI6xqvHIwv+AKlog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR01MB6143 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 19:01:49 -0000 Hi I am not aware of any IPR related to this draft. Best wishes, Ehud=20 -----Original Message----- From: Dots On Behalf Of Konda, Tirumaleswar Reddy Sent: Monday, January 11, 2021 3:58 PM To: Panwei (William) ; Valery Smyslov ; draft-ietf-dots-telemetry@ietf.org Cc: dots-chairs@ietf.org; dots@ietf.org Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 I am not aware of any IPR related to this draft. -Tiru > -----Original Message----- > From: Dots On Behalf Of Panwei (William) > Sent: Monday, January 11, 2021 6:18 PM > To: Valery Smyslov ; draft-ietf-dots-=20 > telemetry@ietf.org > Cc: dots-chairs@ietf.org; dots@ietf.org > Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 >=20 > CAUTION: External email. Do not click links or open attachments unless=20 > you recognize the sender and know the content is safe. >=20 > Hi Valery, all, >=20 > I don't have any IPR nor I'm aware of any related to this draft. >=20 > Regards & Thanks! > Wei Pan >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Valery=20 > > Smyslov > > Sent: Monday, January 11, 2021 8:19 PM > > To: draft-ietf-dots-telemetry@ietf.org > > Cc: dots-chairs@ietf.org; dots@ietf.org > > Subject: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 > > > > Hi authors, > > > > while preparing shepherd write-up for draft-ietf-dots-telemetry-15,=20 > > in accordance with BCP78 and BCP79 I have to ask all authors and=20 > > contributors whether they are aware of any IPR regarding this document. > > Can you please confirm that you are not aware of any IPR or disclose=20 > > any IPR you are aware of that are concerned with this draft. > > > > I'd also like to ask authors about implementation status of the draft. > > Are there any implementations you are aware of? > > > > Regards, > > Valery. > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://clicktime.symantec.com/3VRJhjKnSs7jvBQFrEuXj436H2?u=3Dhttps%3A > > %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://clicktime.symantec.com/3VRJhjKnSs7jvBQFrEuXj436H2?u=3Dhttps%3A%2 > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdots _______________________________________________ Dots mailing list Dots@ietf.org https://clicktime.symantec.com/3VRJhjKnSs7jvBQFrEuXj436H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdots From nobody Mon Jan 11 11:23:25 2021 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 BB96F3A10E6; Mon, 11 Jan 2021 11:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 2yn2-haQ7WPo; Mon, 11 Jan 2021 11:23:20 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150049.outbound.protection.outlook.com [40.107.15.49]) (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 3B9353A10DF; Mon, 11 Jan 2021 11:23:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eW+evJa9PqzwqaY7Fq7+olx2f3/irw2j43A9w+68YR2FxvYWkr97Oyc2/26oLGadsoE3O5VUbWhjkFc79FY561K9RqWSyUVuR3lx4JcGpEiIt9B6SdJ+N3u6CPA7B+HRDfNNbitrHu+inLLr9z8m7JhxXbxVtHi5EaF1EkbptwPkr1ynOHuNwBSc5A71hn83AFEkIl3Ct5/UHRGfpo/Fzawny2iZuy/rxUtur13R/l8Wja2erNiu5UxYw6LJOLYsjl/wccKqLQ9ZOaGFDI8tpQcUFCMDQfg0iFSLHxy8S29cylBDQkmCNNCdHwKU9xI0uV+TH/AalDRM6bFUL+ArJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6LSligQpzMUYWntm2/EfhNzk0t0QNU49hV2nZM0/J58=; b=Us6mf6UWEnIFEMIbpsvfjNiLtzQmk7WMCcB+AUJr7vzWrbSlD7jmbPj589FdltMOEdI1AqA2dzq2Lg+gbNhs5I+W/MYTPzkz4JEpmE+nB/RUfzDTzDwggmhV8gM/zNKAxcRMmBwIVRsizyeWD3XG9+koCYZXq1AlSTw5AWBKjGCV9fre8heBbpfPSRa5umuRLli+dfC0w0NeudmTtU/HV39Xk/Ovc42qAwJppEYKafXvC54nAMgwVY2PCa8olEm+Ylmxe4tHg1DVHZmhQ5giJZK5y5WTKkgm+90L7qHlIV2qY68FkMusNN9Qi8ytwz/EYubV9H/JlH53nlJIhTdluw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6LSligQpzMUYWntm2/EfhNzk0t0QNU49hV2nZM0/J58=; b=GDec57LWJ/kT49HN2wzBuGcSLoUxpHaNWzO0eSMhH3wgmAh6AY2SrJ7pY20OClNRcFHEOYIj/k2Clv0dZhpKKtkjX4JvnJg7SvpNvaWt11EQOTPbrVzYmRLtgGFDwVaXA3n8drQ3RK3f03e1VR4flETFpxJ4blvblH9xi6nrfks= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DBBP189MB1308.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 19:23:15 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 19:23:15 +0000 To: supjps-ietf@jpshallow.com, jon@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> Date: Mon, 11 Jan 2021 20:23:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hxzk1jEBL79PhTWI869EybVhEy2uxce8U" X-Originating-IP: [185.236.42.23] X-ClientProxiedBy: HE1PR0402CA0016.eurprd04.prod.outlook.com (2603:10a6:3:d0::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.3] (185.236.42.23) by HE1PR0402CA0016.eurprd04.prod.outlook.com (2603:10a6:3:d0::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Mon, 11 Jan 2021 19:23:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cce4698b-0904-4e90-f51e-08d8b6665845 X-MS-TrafficTypeDiagnostic: DBBP189MB1308: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7pJrLyWeM87AYO4FOQKjq7UKQ1Ir034nKrQciy5POAOXvBggxz0RPd7K5CII1PL3Y9ZLAB8t51njd6GCCWvn2XFMJeYn+Ee9IVyOzj1oo6zM1QNZ+Rram0cSUp9b5h+GNnoCyI+ImH3i+RKYLh0ma8Br4uK3V7+vJ+UiDQhz7CEqGOEH+lZVGaVeJvYWj0777gSNJiPYk4UZ9fX3jzTAUFP88nInMUS25J5FpD1czGBqPG6hnEORm4jiAAUK+HkupIrhYuPC81mNt9d83Z9nMQOXMRv9mLu1EDC0uIcnYjmvpGIoXvEqfQJWrKpbEM3phTDRLwFBKQRD7H97HOUnxNXLgeE8EAARZciDWc8XboLUI5F7HLVVudEXs61Ek0UxWp8rqWMVK7ZZ1eY4gNSN34hfCGy/WpZD9V1Q0/i+swuP8Um3VJnBNEXRfCbdptzGVmtQN1iXf3LlOWm02IAM05ypGYZWqzeMGaHCC9nouL1CQRbhz1ofjAcxCFhBYDMcwmkFM0OPd6nlGPEVmrS1yQaJYSb9mI0A4muIwE9CyAp8GrB1abHeCmq9zzwaqLtD X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(396003)(39840400004)(136003)(4326008)(66556008)(186003)(66476007)(16526019)(36756003)(8676002)(33964004)(66946007)(5660300002)(44832011)(26005)(956004)(83380400001)(2906002)(235185007)(316002)(2616005)(6666004)(6486002)(31686004)(52116002)(16576012)(31696002)(45080400002)(53546011)(86362001)(8936002)(966005)(21480400003)(66574015)(478600001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RC9KQmltWVpqVFY3dnd1VkV3WGRpemFZRlJXTnYydzdCZUdFYWJuc0hDU29B?= =?utf-8?B?RUZSM3BRQWk4a29HQWxXT3VXNmRLSFVFUFJVNnVvaEx2bmxPa05QY2ZtcTNq?= =?utf-8?B?dXI3OHFrZGlTeCttSWJHcWx1KzhHTXJ0aHgvK0l5UUcvWGdQaEU1dFBndEdO?= =?utf-8?B?UHRQd0s5YUFHZkdGclFLTjVVTGpib3RBditFcFpySklXRWdEaGVRSFJmWjZs?= =?utf-8?B?bzBHaGRHYjRMbVBmaExHdGluMkw2TEg3VEl6ZWMrRkZPZTZkQ3pRcEYxOEdK?= =?utf-8?B?YkRSa1BMZUpPeVpvSmZBbEhiS0NaWFZ0Q2dJOXpGYXpVSG95c05YaVZGaUV5?= =?utf-8?B?NVNlbXZseWZ1bWJDdUxVRVdFRDdsZFVWSmdobVZ6RlBITUx0dkFmaldXZDA5?= =?utf-8?B?NzF5TjUzZ0c0YUpFdDdiREVWazBKUCt0d2VrUkc5YzhKTm1aREFyd2NSVk9r?= =?utf-8?B?NjNKUWJSUWUvRWxnbTBVS0VQNFZHNzVtYVhuWHFjMXlLTjZNVlJsUUkxSVQ2?= =?utf-8?B?Tk5MMXZsTnc0QnZJcUhLZ29wY1YzQmErZzJsUXVVM1YzMmtwV2NZbVE1aExi?= =?utf-8?B?MHROTGpWNCtLNzFOSkwxUWdTeEcyemM5cVpGeTB1SzQrMW1aZzVpOGJiSEhs?= =?utf-8?B?ZkJKbzFSdTdvNXF6dHcwQ2VQVXNneW9mUzk0N2E0bDg4cUlzNkxNRW96ZStY?= =?utf-8?B?YkhNWWZYZ0VGWFRTbVdCUTVyRS9UWWQxODMvcUF6WStHaU9jWG5wUWZ0cmdR?= =?utf-8?B?M0lzVjVvQXJxTXQydEFRaVk5SmloWWp4THcxOExobk8yTml5dzdaRzB2QWYr?= =?utf-8?B?Tnh2akdpM3RkTGc2ckRQdTRSTjNJMjhhTTlpaGVHbkhCVkFERkFVd3NZSm9I?= =?utf-8?B?V3VZbGk5d0c5NGR4VmRrWmpVaU1xa2twaUdBTWFNVnRBNHJ1Uk9wOUdzQU13?= =?utf-8?B?VkVlUDlrYTg0V1RyQWZkU3NrTzU0anZla0doQzM5SFlDSklQSnlnTjNwcFB0?= =?utf-8?B?WUU2aDcxK0JoY0NhY295MjNuVEhvL0ZubjZlT2lBQlpFQkd3UEgvK0tpUlUw?= =?utf-8?B?RDlPZUxCN3YrWWdXTHluTDNLbWN0UUtXWGF1SEhLNmxzV205czFZc1lQT0J1?= =?utf-8?B?eHRUY2UwalJxOFR2OENxK2x6RnRIODRJbGh0REhCVWI4R0tybXViaEJ6TTZN?= =?utf-8?B?MmVsY2NaM0syYndVSE4yekhrSVZFaUZGZ2ZpSUhIQjBNYytrWlZ5K0Q2WUc5?= =?utf-8?B?VzJvdkZkekNJU2Jvc01xNk9WRmNPdkVOdVJGa0NYTENUOEs4dURBVDM0dGZF?= =?utf-8?Q?tnoNbnxvYsC34NHQu73+h8Xxw75xsKR7ID?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2021 19:23:15.5530 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: cce4698b-0904-4e90-f51e-08d8b6665845 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y8P9kyK2cQQ9CuSGg4sDmnpa5DyjPXBmBJozpJIlvNC+eurj1XULDXgH2p4bEw3Wc1+NwoRiSJujQdL1sxP6Mw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1308 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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 Jan 2021 19:23:24 -0000 --hxzk1jEBL79PhTWI869EybVhEy2uxce8U Content-Type: multipart/mixed; boundary="OLwVIjACIILRUNsZ1hXisG5HFD58OKExz" --OLwVIjACIILRUNsZ1hXisG5HFD58OKExz Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks for the fast reaction. Please, see inline. Best, /Marco On 2021-01-11 17:39, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > It is good that you are thinking this properly through. FETCH was adde= d later into this draft and the consequences were not properly thought th= rough. > > The new updates have been pushed to https://eur02.safelinks.protection.= outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554192170%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&sdata=3DP5eiQyl8meRhZX9t6gtNqwc29ryqLRGnOUwmFQxAydo%3D&a= mp;reserved=3D0 and the differences with the draft can be found at https:= //eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.or= g%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw= =2Egithubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core= -new-block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344= ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799= 554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ= BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DIYKVrC1a56Cva5mR4xoM0VM5y6= dhjtQ7M6L5PwlCqzA%3D&reserved=3D0 > > The PR for the responses below can be found at https://eur02.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-bl= ock%2Fpull%2F13&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd36534= 4ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63745979= 9554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3Db9hq1V5X136oGB65e9Ni12V0w= eXoNa%2FY1DT8QtzFRqQ%3D&reserved=3D0=20 > > Otherwise, see inline. > > Regards > > Jon > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 11 January 2021 11:39 >> To:supjps-ietf@jpshallow.com; christian@amsuess.com; draft-ietf-core-n= ew- >> block@ietf.org >> Cc: dots@ietf.org; core@ietf.org >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >> >> Hi Jon, >> >> Thanks, the updates look good. > [Jon] Thanks >> As to the response codes in Section 3.3 "Using the Q-Block1 Option", >> wouldn't it make sense to mention also 2.05 (Content) ? Think of a FET= CH >> request with a big body, which is actually mentioned at the beginning = of >> Section 3.3 and in Section 3.1 (though missing the 2.05 response code >> beside it). > [Jon] Thanks - added. Also added in 2.02 and 2.05 as being expected re= sponse codes in 3.3. =3D=3D>MT Looks good. <=3D=3D > > [Jon] For the 2.02, I struggle with why anyone would want to use a POS= T with a large payload to cause the resource to get deleted (instead of u= sing DELETE) , but RFC7252 allows this to happen. =3D=3D>MT If it's really about the client just asking to delete a resource, then a DELETE is more efficient. But, the client might just be asking the server to process its POST payload, and it's the server that eventually takes the decision to delete the resource, as a possible side-effect following the request processing. I think that's what the "if" wanted to suggest in RFC 7252, Section 5.8.2: "If the POST succeeds and results in the target resource being deleted, the response SHOULD have a 2.02 (Deleted) Response Code." Alternatively, the client may actually want to delete the resource as somehow indicated in the payload, only following the processing of the rest of the payload. This would not be possible with a DELETE (that has no payload) and if supported by the application it is more efficient than sending first a POST and then a DELETE. <=3D=3D > > OLD > Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,= > PATCH, and iPATCH requests and their responses (2.01 and 2.04). > NEW > Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PA= TCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and 2.05)= =2E =3D=3D>MT Looks good. <=3D=3D > [Jon] And added into 3.3 (2.05 is done further into this discussion) > > NEW > 2.02 (Deleted) > > This Response Code indicates successful receipt of the entire body and = the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). T= he token used SHOULD be from the last received payload. The client should= then release all of the tokens used for this body. =3D=3D>MT Looks good. <=3D=3D > >> Also, more in general, think of an observe registration, for which the= >> server eventually sends back a first notification (possibly split into= >> multiple payloads) with Q-Block2, with a certain Token value. > [Jon] OK >> If the observation request used FETCH and was fragmented into several >> payloads with Q-Block1, each of which with a different Token, it's sti= ll >> true that the notifications can all have any of those Token values and= >> should have the one of the last received request payload. > Jon[OK] >> However, later on the client has to retain that Token value as the one= >> associated to the observation, to match future notifications to come. = In >> this case, there is a deviation from the claim used for other response= >> codes, i.e. "The client should then release all of the tokens used for= >> this body." This should concern only 2.01 notifications (hence includi= ng >> the Observe option) in response to observation requests with FETCH, so= >> it can be limited to the context of this section about Q-Block1. > [Jon] I was not aware that FETCH could return 2.01 or 2.04. GET does n= ot return these codes and it is only GET and FETCH that can Observe. =20 =3D=3D>MT Oops, I actually meant 2.05 in the paragraph above. Sorry for the confusi= on. <=3D=3D > However, it is true what you say for 2.05, so I have added that the tra= cked Observe token must be the (if Q-Block1) the one used for Q-Block1 th= at has the M bit unset. I have added in some FETCH examples into the dra= ft. > > NEW > 2.05 (Content) > > This Response Code indicates successful receipt of the entire FETCH req= uest body (See Section 2 [RFC8132]) and the appropriate representation of= the resource has been returned. The token used in the response MUST be t= he one in the FETCH request that has the Q-Block1 with the M bit unset. I= f the FETCH request includes the Observe Option, then the server MUST use= the same token for returning any Observe triggered responses. The client= should then release all of the tokens used for this body unless a resour= ce is being observed. =3D=3D>MT Looks good. As to the two new examples in Figures 11 and 12, please add the Observe option with value 0 to the requests from the client, i.e. O:0, just like you do in Figures 7 and 8. Best, /Marco <=3D=3D > ~jon >> Best, >> /Marco >> > > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --OLwVIjACIILRUNsZ1hXisG5HFD58OKExz-- --hxzk1jEBL79PhTWI869EybVhEy2uxce8U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/8pZsACgkQ7iZktA5Y 2kNyoQf9EAd17qSgsyQn5RtP94nJn360gJRO3CQCvLWDxAG7pKtozJIjQWte+M+5 s9VDr+wX1SjvgRih95Yw/t1mtKeE9zHzyPOSzl48NY/UZN+jt3JoVeUiK7PMt2OR QhRmdxwSJ9S90VzzuGxwnUyXgig0JOKtWLHaVbaHEZrEVZe3ng6iAsXOUvh6f1OB p6tidf6MJ0sypRTY6zMQuFha+bJsM1TfRjsurRgYjy8sso/heKWZ1Umcda+FPRZ5 AqvF6SgQcVrqHIxENxEIv90FGNzSftrZtRQOVodQEUMOqeN9NvEqzGTkUWmM+hMx B2Ao9kG9zjulwMItOs2hx3K9wBWORQ== =ap2p -----END PGP SIGNATURE----- --hxzk1jEBL79PhTWI869EybVhEy2uxce8U-- From nobody Mon Jan 11 20:04:58 2021 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 CBE443A0DEB; Mon, 11 Jan 2021 20:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 nT5VLVCGpH6t; Mon, 11 Jan 2021 20:04:55 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179593A0DF3; Mon, 11 Jan 2021 20:04:54 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10C44kb5025621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Jan 2021 23:04:52 -0500 Date: Mon, 11 Jan 2021 20:04:46 -0800 From: Benjamin Kaduk To: kaname nishizuka Cc: mohamed.boucadair@orange.com, "dots@ietf.org" , "draft-ietf-dots-use-cases@ietf.org" Message-ID: <20210112040446.GP161@kduck.mit.edu> References: <5008_1609751917_5FF2DD6D_5008_29_10_787AE7BB302AE849A7480A190F8B9330315A67BC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6d9bb032-dc51-1190-ad3d-729ed899e8b6@nttv6.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d9bb032-dc51-1190-ad3d-729ed899e8b6@nttv6.jp> Archived-At: Subject: Re: [Dots] Any reason why RFC8903 is stale since 09/20? 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, 12 Jan 2021 04:04:58 -0000 Hi Kaname, On Tue, Jan 05, 2021 at 10:41:50AM +0900, kaname nishizuka wrote: > Hi, > > Attached is the latest status. > Yes, it's because some authors are not responding. > I hope ADs will make it move forward. It's on my list to look at. I've heard from Bob on other topics recently, so should be able to get some kind of update from him. -Ben From nobody Mon Jan 11 23:21:53 2021 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 4829A3A118E; Mon, 11 Jan 2021 23:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 XBd6s8-k3_Sk; Mon, 11 Jan 2021 23:21:46 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 C415E3A0EF0; Mon, 11 Jan 2021 23:21:45 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4DFMT32M6Sz7tHK; Tue, 12 Jan 2021 08:21:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610436103; bh=dCJGAGcA9stvRc1OmBmMzVWkvwpgGHeac9+psHA00Mo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=YpY0pq8InpV+dJFUt6t01395z9c5N4ZeO6b8zGvRos2a3bbgz1IwIzjT5xT1nBOL8 yHJQ/tR2g710afkYdfwAIk7OYqeEdH3FVHtoLOVNsAvjxHopsnGP/UpQB/MKusRQS7 YkbhjskeZdmej+O5AOTl+umguEQ7D6u2DLvX/RybGpaVJ5vjByncBbSMm42+jeI2WF /c1EqAgyH+BYEuo0vx8xxaI5aRQs3O9eUgNPUHNK0VwK53fRpdsH51m3i8Fp8jQq/t xSGlBXEks0QAcyvu5qW+/e9TiMB0Ngy076+PXhBZNYuyIyETMFCUj+FJTOjKYiYCMN zEF4KXC0LaXWQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4DFMT30kLjz2xCZ; Tue, 12 Jan 2021 08:21:43 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "jon@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [Dots] [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQHW6E9Bzk5nyR9aqEaF1vgDuALPQKojhhSA Date: Tue, 12 Jan 2021 07:21:42 +0000 Message-ID: <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> In-Reply-To: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> 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] [core] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 07:21:47 -0000 SGkgTWFyY28sIGFsbCwgDQoNCldpdGggcmVnYXJkcyB0byAyLjAyLCBSRkM3OTU5IHNheXMgdGhl IGZvbGxvd2luZzogDQoNCiAgIEhlbmNlLCBmb3IgdGhlIG1ldGhvZHMgZGVmaW5lZCBpbiBbUkZD NzI1Ml0sIEJsb2NrMSBpcyB1c2VmdWwgd2l0aA0KICAgdGhlIHBheWxvYWQtYmVhcmluZyBQT1NU IGFuZCBQVVQgcmVxdWVzdHMgYW5kIHRoZWlyIHJlc3BvbnNlcy4NCiAgIEJsb2NrMiBpcyB1c2Vm dWwgd2l0aCBHRVQsIFBPU1QsIGFuZCBQVVQgcmVxdWVzdHMgYW5kIHRoZWlyIHBheWxvYWQtDQog ICBeXl5eXl4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF5eXl5eXl5eDQogICBiZWFyaW5nIHJlc3BvbnNlcyAoMi4wMSwgMi4wMiwgMi4wNCwgYW5k IDIuMDUgLS0gc2VlIFNlY3Rpb24gNS41IG9mDQogICBeXl5eXl5eXiAgICAgICAgICAgICAgICAg Xl5eXg0KICAgW1JGQzcyNTJdKS4NCg0KV2hpY2ggd2UgdGhpbmsgaXMgYnJva2VuLiANCg0KV2Ug ZG9uJ3QgZWNobyB0aGF0IHBhcnQgaW4gdGhlIG5ldy1ibG9jay4gDQoNClNob3VsZCB3ZSBmaWxs IGFuIGVycmF0YSBhZ2FpbnN0IHRoaXM/DQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmNvIFRpbG9jYQ0KPiBFbnZvecOpwqA6IGx1bmRpIDExIGph bnZpZXIgMjAyMSAyMDoyMw0KPiDDgMKgOiBzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tOyBqb25A anBzaGFsbG93LmNvbTsNCj4gY2hyaXN0aWFuQGFtc3Vlc3MuY29tOyBkcmFmdC1pZXRmLWNvcmUt bmV3LWJsb2NrQGlldGYub3JnDQo+IENjwqA6IGRvdHNAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmcN Cj4gT2JqZXTCoDogUmU6IFtEb3RzXSBbY29yZV0gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYt Y29yZS1uZXctYmxvY2sNCj4gDQo+IEhpIEpvbiwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGZhc3Qg cmVhY3Rpb24uIFBsZWFzZSwgc2VlIGlubGluZS4NCj4gDQo+IEJlc3QsDQo+IC9NYXJjbw0KPiAN Cj4gT24gMjAyMS0wMS0xMSAxNzozOSwgc3VwanBzLWlldGZAanBzaGFsbG93LmNvbSB3cm90ZToN Cj4gPiBIaSBNYXJjbywNCj4gPg0KPiA+PiByZXNwb25zZSBjb2RlIGJlc2lkZSBpdCkuDQo+ID4g W0pvbl0gVGhhbmtzIC0gYWRkZWQuICBBbHNvIGFkZGVkIGluIDIuMDIgYW5kIDIuMDUgYXMgYmVp bmcNCj4gZXhwZWN0ZWQgcmVzcG9uc2UgY29kZXMgaW4gMy4zLg0KPiANCj4gPT0+TVQNCj4gTG9v a3MgZ29vZC4NCj4gPD09DQo+IA0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Jan 12 01:10:04 2021 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 D9E393A0D45; Tue, 12 Jan 2021 01:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 zzscaFowUzMK; Tue, 12 Jan 2021 01:09:52 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2042.outbound.protection.outlook.com [40.107.21.42]) (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 D44C53A0D3D; Tue, 12 Jan 2021 01:09:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y2Y403bADcJShA5TNUppmXYcr7rYFKWTS73W2oLhbd+/4Wl7e2tHZkgW9cmasR1pgCNjUidcNxJSUrcuYLK23K7ab+XHR3dvkCHIvYwsYStabcO8Cbx/wW5ROxrqbe9QBCw0dLzS1S7NmjaBBiE/h9T+N4BAlyETg07qljgjlFbc6P/yyzQEa2QHY6cbndCvfY18bDDwNaKBCM7pCIHoVH7DcxCaEBiY9J6i5m9M9ByYmCDfmpfwwvIzuQYMneXjo/CZe1YlMmUl+7JVVGLURFdTxsi4dylQS+xSJV01NwNo6d4cGWFZnkQjRGzaKSG0zc1VcQ5GwSN7iIYt/6pMuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mccrExbGWLTvHPG0rVwJDuGexcvejtlhSsjRpq7b8yc=; b=KCs4t2lrcO0e8h5rlF46FCBXYBm2hG630xIoGWjDFYO8Vyr3aJQZbZPQTy0ZNcjm3jIB8CE7yqhv1i7EpqZ8nTGQSthbYlr/ohN4XZ1mP0VlJW328db2Y+Cdifa0ofSjvlrY1lYIj/P9xKR3gxcu2Pth6Ahdmk4M3bidKbi/MbEnVhosK3hzXw5SRdWj6QV851WZcqpAOAztMNTkU9qRKFYEDDbfSScx3mvJFYpXsMf4oqCPRybQqVekeN1Gv04obilWAGBuJz97p9fJ9QjOxV1vIOBgHgM0n3KFBY87Td9iqc1vflMy/Qe+vrQSX9Qih8rBxyd6+np2VsEzr8j7yA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mccrExbGWLTvHPG0rVwJDuGexcvejtlhSsjRpq7b8yc=; b=DOQtSDpneCxjUS1MTS/3dH5ymjiJgBA3HWnDj18vooue76Dx3zjOqljTRCNdlGsP394O6PXapnOlA6kQJxedoEhyC5jSJSZRXJGkw43lJFN0jbl+svB6tqIpSIBxJIqZHx/0aFSzaV0aP/Gr0Yyx+I/j5NgIqbIG11AoiOGKmVs= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0469.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Tue, 12 Jan 2021 09:09:48 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 09:09:48 +0000 To: mohamed.boucadair@orange.com, "supjps-ietf@jpshallow.com" , "jon@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" Cc: "dots@ietf.org" , "core@ietf.org" References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Tue, 12 Jan 2021 10:09:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk" X-Originating-IP: [45.12.220.164] X-ClientProxiedBy: HE1PR1001CA0024.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::34) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.5] (45.12.220.164) by HE1PR1001CA0024.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9 via Frontend Transport; Tue, 12 Jan 2021 09:09:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 271690d5-9948-45fd-bff1-08d8b6d9cfa4 X-MS-TrafficTypeDiagnostic: DB6P189MB0469: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wtMTKq6N43SAaVb6ayk/XXgdhHsee0SFxtltBNYeCHlrALflbnsC5HviyVAoNyTPulB5VIR9vmjIWeZMh8tFLzEa6KNwIQfgjDVKVz2h9yZeN41f+D712GyM1oCqzKRzVSfHSMKTqF5c0TA8LQxHQOrdAbDgBiD8kBXPMBlHRh/AepHcdign8kuBiVCcBIkSagxZT/6tY2wZxV3Tb7HP4KnvngWpDKbuPpLK21MYrux/otGmvCgN/9ciXaOuonEjnJCwyJlN9tE03QdeG3fEnYQ7cM4K1u5iRNU5UM8PPuPnHga7YO+g74YAmX6bHS6nHLdWEVicvKK/vJ7Vmmp/fWXd9i8Fs0OGCdJjxUDd/66z6AL/8gEl8lxAStoWUgKuUsZ8TaAHwptPLmsJ4Xi80ym3v1igy1OUPYWpDo0QESxLaoRmllAAqJc/TfZKljbrCXD0ylLqo15TOanKCusg4Icxzvviiu3qBv7YN80PIGpWLovUJmQo8iozDl8XAQ1Hhh3C4XEPH4MM3K7qf9GIBAsHxhcBTJ8tJqH7g8dprtUFIe4DsbYTvoBobPKcIiAd X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(39850400004)(136003)(396003)(376002)(31686004)(33964004)(2906002)(16576012)(31696002)(53546011)(52116002)(4326008)(44832011)(6666004)(66574015)(316002)(45954011)(110136005)(26005)(16526019)(86362001)(186003)(8936002)(66946007)(66476007)(8676002)(6486002)(83380400001)(21480400003)(36756003)(956004)(66556008)(235185007)(5660300002)(966005)(54906003)(2616005)(478600001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?OHFzK1FYazFXR2VFZkVtdjZqdDF4ajNkSE03U2c1Zno1U1ZKekpaOEZUQmVW?= =?utf-8?B?Qy81TjJnR05TWXhrdFNWdTN4RWw1aHcrQzFNSk9LUFAxYTJrY0JrSHA1b1FW?= =?utf-8?B?dUpkTTdKVVBhMXRwL2prMG5WOERyMjJXVzUxZ2g2MlFVU2kyaWpBNmdvSTlo?= =?utf-8?B?c3J1L2t6dDVGaVNPNWdHaWdRTlVTSUtZK3FYR2FtSHoxTk9FdUFuR3FNeGtF?= =?utf-8?B?bXBycVNEZ202K2ZOM2FEZHRzSlNhOEorSmlOVVBoSVkwSVBqR1U0WE5DR1Fn?= =?utf-8?B?QVRneXVRYytwT2h6eFZUTG9qNmdDTFVidEc2cjNUSGtPUnQvemk3L3VyNHV4?= =?utf-8?B?OWRobGVxQ3p2U0lkblowRWJXZExFWEcyOVhGdVNlcTJqYWtuVFpWUmJWL2Zn?= =?utf-8?B?RkpOM0lXSGtxSTQ4VlhPUXVHU2ZpV0xZZ0dHM24yUHl3cnRIMVhiNVFkcjRs?= =?utf-8?B?MmpScTNKdm5uUzJHTDU3UXNWdjZFb3hscytidEhobldPalBIK3NadVV3Y0FG?= =?utf-8?B?WW4yc21IS0tEdHVJZGEyRVFvemtCbVFXcGNqbFVGSks0OUtoT1l5aldVZUYz?= =?utf-8?B?Sno1bGcwbWhFS0x2cFd3UzcxYkYwczZVNnFvRkxFTElNZ1EwNHA0OWVRQ2FQ?= =?utf-8?B?a2VNQnJiakpwNUNSU20wVzdPQ1VrZ3pyWCtkTGpCL1hvK1Y3QXBDd0dLV1Jj?= =?utf-8?B?YXptZEw5d1ZSd2dYNmZFSzZyRHFreVNUTkQxZGQ1SFhXWW13TVVSVVB4ek5Z?= =?utf-8?B?UUdWbHhFcjdneEQvdTB6dG1wem9hSzErZmk3bUFTRnFLelVuT3NrT2lRcTJo?= =?utf-8?B?YWkwRDlhUWU1RExtVHdKdGxoRVVtWTFzL0pqNEhmdGJXNXR2WDNobWE3ZFFR?= =?utf-8?B?bTNIb09JUnE5dHdNK3Y5NWRwRmlmQlMvWlBJVHJyd1hPSEkybXA5SnpOamg0?= =?utf-8?B?Nnpqb244Z2pnQXpLS1R0VTIxOERYRVFidWhwY1MzLzRRbGUwUGthWk1WL1pD?= =?utf-8?B?ckF2b3prdUdkZW0xRHBodTBnaUx3VHV6YTZYU0QxVEp2bStpckRPZ3FldklN?= =?utf-8?B?YTI3R0l1RXV5anRuWk9aVXJLd3FRNmlVOW1DSVg4d204eVA2cGhlTWFLUTFV?= =?utf-8?B?L0p5T1JzbFRHeDYxaUlZbnNFVGxPVXg1bEQrVmMzWEI3Yzh4TVlneGpPS1dk?= =?utf-8?B?QThnUm8xNDJabCtPQk9DRExWdkdidnpjK2Q5V2tNTFEwTVQvVkhxdVhkb3lk?= =?utf-8?B?YWFrSmRWTm96Qm1VN2hYdHVLTlN6MzltQk02bFlOYjdteHlqck1YVEhuTEdM?= =?utf-8?Q?uqswHTl5LeT2ApaaPj58BWCuUe19PPROpP?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2021 09:09:48.0057 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 271690d5-9948-45fd-bff1-08d8b6d9cfa4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mPypXRY0vtVG4ypUV5Ur9b2QvUNxBtEBb15etZb4Y5rjlyDmfFmKERlGeir8HQhdsdrSpMe1Jp1tZkTkvPtmlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0469 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 09:09:56 -0000 --YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk Content-Type: multipart/mixed; boundary="LCvih2BaWdcJaGoxpFKHvBJTEuGpEdTSq" --LCvih2BaWdcJaGoxpFKHvBJTEuGpEdTSq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Med, Could you clarify why that part is broken? =46rom RFC 7252, Section 5.9.1.2=C2=A0 "2.02 Deleted" says: =C2=A0=C2=A0 "This Response Code is like HTTP 204 "No Content" but only u= sed in response to requests that cause the resource to cease being available, such as DELETE and, in certain circumstances, POST. The payload returned with the response, if any, is a representation of the action result." So, a 2.02 response can follow a POST request, and it can have a payload, which might be split using Block2. Best, /Marco On 2021-01-12 08:21, mohamed.boucadair@orange.com wrote: > Hi Marco, all,=20 > > With regards to 2.02, RFC7959 says the following:=20 > > Hence, for the methods defined in [RFC7252], Block1 is useful with > the payload-bearing POST and PUT requests and their responses. > Block2 is useful with GET, POST, and PUT requests and their payload-= > ^^^^^^ ^^^^^^^^ > bearing responses (2.01, 2.02, 2.04, and 2.05 -- see Section 5.5 of > ^^^^^^^^ ^^^^ > [RFC7252]). > > Which we think is broken.=20 > > We don't echo that part in the new-block.=20 > > Should we fill an errata against this? > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Marco Tilo= ca >> Envoy=C3=A9=C2=A0: lundi 11 janvier 2021 20:23 >> =C3=80=C2=A0: supjps-ietf@jpshallow.com; jon@jpshallow.com; >> christian@amsuess.com; draft-ietf-core-new-block@ietf.org >> Cc=C2=A0: dots@ietf.org; core@ietf.org >> Objet=C2=A0: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-blo= ck >> >> Hi Jon, >> >> Thanks for the fast reaction. Please, see inline. >> >> Best, >> /Marco >> >> On 2021-01-11 17:39, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>>> response code beside it). >>> [Jon] Thanks - added. Also added in 2.02 and 2.05 as being >> expected response codes in 3.3. >> >> =3D=3D>MT >> Looks good. >> <=3D=3D >> > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --LCvih2BaWdcJaGoxpFKHvBJTEuGpEdTSq-- --YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/9Z1MACgkQ7iZktA5Y 2kPGtQf/UKa2lohUgNa3rmkzU4m2ig0Wr/TYszZH4tNj1gFWFmq57xzznLyqpQWy 3t48HtehFYmekaACxkPhbTxfGv/ngcgMAeWk5XmapyQ2l430geNzc22952pcI9hG UOdLC71DvbxBH1VI367Cn+BPIl8JevqgZ9azWGKWAZk6S8xFtI9Feq7GzZAXWpFB hXwdtn9nsGIc13zaoDf6CrclummvJvDhuBLVsYuTAt5z4yzNYYQQXBog2vCBcijd UO9hgzjAKOUrSXQ8LjqpH6gbfqu5LNP1vkuP3xMv5eymUE1pSBFqqgMj4W5RG0WK Hi7Cmk94wnaHTbrmwiqWFtLFJd28dw== =g7LA -----END PGP SIGNATURE----- --YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk-- From nobody Tue Jan 12 01:27:17 2021 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 811D83A0E05; Tue, 12 Jan 2021 01:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 SGN_SmDCAxza; Tue, 12 Jan 2021 01:27:09 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 525843A0E04; Tue, 12 Jan 2021 01:27:09 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4DFQFk68DYz2xNs; Tue, 12 Jan 2021 10:27:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610443626; bh=CgOGAj2FBRazfmI011YvZbuA/JVbR0Ape1JyKYxcWss=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=WUTPnjZoIkbHMPMEm29BPqgiZetOp4443OPY8dQH76yV2v8mj0WLt7UBhXHB5ss33 xUCXZAqPKvaxQ9ltOExLwF4ApSLdSHnVEI/e/IOQ6vSrW7KXJYz7sodwcd9Ax/XMSc D2Kk7P3LJeZ48QsM61x6Cu38LGYJ3iLB9lNTev1mdtM5qcYilQQaM9gcie6Z9yj8PP PJ3HGUyUDWnrI94w5jXzGsriPU7DNPvGN6n8T4GbRbjKYS7iXX+h3piF2EYkgWPEaC TU2GCU3defyXOrKU5QdkvgiKEQASPMN0cRhW8R94gOF7qHPiFiJcrYp1uGVCms16Ie uWSmi9TN0N6IQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4DFQFk4SQJz2xCF; Tue, 12 Jan 2021 10:27:06 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "jon@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [Dots] [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQHW6MKuBUGUqFPLqk+vRyAaxhyBTKojuDjA Date: Tue, 12 Jan 2021 09:27:05 +0000 Message-ID: <14775_1610443626_5FFD6B6A_14775_483_1_787AE7BB302AE849A7480A190F8B9330315B7C8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@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.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 09:27:12 -0000 UmUtLA0KDQpUaGUgY29uY2VybiBpcyB3aGF0IHRvIHB1dCBpbiB0aGF0IHBheWxhb2QgaWYgdGhl IHJlc291cmNlIGRvZXMgbm90IGV4aXN0Og0KDQogICBJZiB0aGUgUE9TVCBzdWNjZWVkcyBhbmQg cmVzdWx0cyBpbiB0aGUgdGFyZ2V0IHJlc291cmNlIGJlaW5nDQogICBkZWxldGVkLCB0aGUgcmVz cG9uc2UgU0hPVUxEIGhhdmUgYSAyLjAyIChEZWxldGVkKSBSZXNwb25zZSBDb2RlLg0KDQpDaGVl cnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogTWFyY28g VGlsb2NhIFttYWlsdG86bWFyY28udGlsb2NhQHJpLnNlXQ0KPiBFbnZvecOpwqA6IG1hcmRpIDEy IGphbnZpZXIgMjAyMSAxMDoxMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsNCj4gc3VwanBzLWlldGZAanBzaGFsbG93LmNv bTsgam9uQGpwc2hhbGxvdy5jb207IGNocmlzdGlhbkBhbXN1ZXNzLmNvbTsNCj4gZHJhZnQtaWV0 Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZw0KPiBDY8KgOiBkb3RzQGlldGYub3JnOyBjb3JlQGll dGYub3JnDQo+IE9iamV0wqA6IFJlOiBbRG90c10gW2NvcmVdIFdHIExhc3QgQ2FsbCBvbiBkcmFm dC1pZXRmLWNvcmUtbmV3LWJsb2NrDQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBDb3VsZCB5b3UgY2xh cmlmeSB3aHkgdGhhdCBwYXJ0IGlzIGJyb2tlbj8NCj4gDQo+IEZyb20gUkZDIDcyNTIsIFNlY3Rp b24gNS45LjEuMsKgICIyLjAyIERlbGV0ZWQiIHNheXM6DQo+IA0KPiDCoMKgICJUaGlzIFJlc3Bv bnNlIENvZGUgaXMgbGlrZSBIVFRQIDIwNCAiTm8gQ29udGVudCIgYnV0IG9ubHkgdXNlZA0KPiBp biByZXNwb25zZSB0byByZXF1ZXN0cyB0aGF0IGNhdXNlIHRoZSByZXNvdXJjZSB0byBjZWFzZSBi ZWluZw0KPiBhdmFpbGFibGUsIHN1Y2ggYXMgREVMRVRFIGFuZCwgaW4gY2VydGFpbiBjaXJjdW1z dGFuY2VzLCBQT1NULiBUaGUNCj4gcGF5bG9hZCByZXR1cm5lZCB3aXRoIHRoZSByZXNwb25zZSwg aWYgYW55LCBpcyBhIHJlcHJlc2VudGF0aW9uIG9mDQo+IHRoZSBhY3Rpb24gcmVzdWx0LiINCj4g DQo+IFNvLCBhIDIuMDIgcmVzcG9uc2UgY2FuIGZvbGxvdyBhIFBPU1QgcmVxdWVzdCwgYW5kIGl0 IGNhbiBoYXZlIGENCj4gcGF5bG9hZCwgd2hpY2ggbWlnaHQgYmUgc3BsaXQgdXNpbmcgQmxvY2sy Lg0KPiANCj4gQmVzdCwNCj4gL01hcmNvDQo+IA0KPiBPbiAyMDIxLTAxLTEyIDA4OjIxLCBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+IEhpIE1hcmNvLCBhbGwsDQo+ID4N Cj4gPiBXaXRoIHJlZ2FyZHMgdG8gMi4wMiwgUkZDNzk1OSBzYXlzIHRoZSBmb2xsb3dpbmc6DQo+ ID4NCj4gPiAgICBIZW5jZSwgZm9yIHRoZSBtZXRob2RzIGRlZmluZWQgaW4gW1JGQzcyNTJdLCBC bG9jazEgaXMgdXNlZnVsDQo+IHdpdGgNCj4gPiAgICB0aGUgcGF5bG9hZC1iZWFyaW5nIFBPU1Qg YW5kIFBVVCByZXF1ZXN0cyBhbmQgdGhlaXIgcmVzcG9uc2VzLg0KPiA+ICAgIEJsb2NrMiBpcyB1 c2VmdWwgd2l0aCBHRVQsIFBPU1QsIGFuZCBQVVQgcmVxdWVzdHMgYW5kIHRoZWlyDQo+IHBheWxv YWQtDQo+ID4gICAgXl5eXl5eDQo+IF5eXl5eXl5eDQo+ID4gICAgYmVhcmluZyByZXNwb25zZXMg KDIuMDEsIDIuMDIsIDIuMDQsIGFuZCAyLjA1IC0tIHNlZSBTZWN0aW9uDQo+IDUuNSBvZg0KPiA+ ICAgIF5eXl5eXl5eICAgICAgICAgICAgICAgICBeXl5eDQo+ID4gICAgW1JGQzcyNTJdKS4NCj4g Pg0KPiA+IFdoaWNoIHdlIHRoaW5rIGlzIGJyb2tlbi4NCj4gPg0KPiA+IFdlIGRvbid0IGVjaG8g dGhhdCBwYXJ0IGluIHRoZSBuZXctYmxvY2suDQo+ID4NCj4gPiBTaG91bGQgd2UgZmlsbCBhbiBl cnJhdGEgYWdhaW5zdCB0aGlzPw0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBEb3RzIFttYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmNvDQo+IFRpbG9jYQ0KPiA+PiBF bnZvecOpwqA6IGx1bmRpIDExIGphbnZpZXIgMjAyMSAyMDoyMyDDgMKgOiBzdXBqcHMtDQo+IGll dGZAanBzaGFsbG93LmNvbTsNCj4gPj4gam9uQGpwc2hhbGxvdy5jb207IGNocmlzdGlhbkBhbXN1 ZXNzLmNvbTsNCj4gPj4gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZw0KPiA+PiBD Y8KgOiBkb3RzQGlldGYub3JnOyBjb3JlQGlldGYub3JnDQo+ID4+IE9iamV0wqA6IFJlOiBbRG90 c10gW2NvcmVdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWNvcmUtbmV3LQ0KPiBibG9jaw0K PiA+Pg0KPiA+PiBIaSBKb24sDQo+ID4+DQo+ID4+IFRoYW5rcyBmb3IgdGhlIGZhc3QgcmVhY3Rp b24uIFBsZWFzZSwgc2VlIGlubGluZS4NCj4gPj4NCj4gPj4gQmVzdCwNCj4gPj4gL01hcmNvDQo+ ID4+DQo+ID4+IE9uIDIwMjEtMDEtMTEgMTc6MzksIHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20g d3JvdGU6DQo+ID4+PiBIaSBNYXJjbywNCj4gPj4+DQo+ID4+Pj4gcmVzcG9uc2UgY29kZSBiZXNp ZGUgaXQpLg0KPiA+Pj4gW0pvbl0gVGhhbmtzIC0gYWRkZWQuICBBbHNvIGFkZGVkIGluIDIuMDIg YW5kIDIuMDUgYXMgYmVpbmcNCj4gPj4gZXhwZWN0ZWQgcmVzcG9uc2UgY29kZXMgaW4gMy4zLg0K PiA+Pg0KPiA+PiA9PT5NVA0KPiA+PiBMb29rcyBnb29kLg0KPiA+PiA8PT0NCj4gPj4NCj4gPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBfXw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ID4gY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUNCj4gZGlmZnVz ZXMsDQo+ID4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UNCj4gbWVzc2FnZQ0KPiA+IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlDQo+IGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50DQo+IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl DQo+IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4g Pg0KPiA+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvcg0KPiA+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsgdGhleSBzaG91bGQNCj4gbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+IFRoYW5rIHlvdS4NCj4gPg0K PiANCj4gLS0NCj4gTWFyY28gVGlsb2NhDQo+IFBoLkQuLCBTZW5pb3IgUmVzZWFyY2hlcg0KPiAN Cj4gUklTRSBSZXNlYXJjaCBJbnN0aXR1dGVzIG9mIFN3ZWRlbg0KPiBEaXZpc2lvbiBJQ1QNCj4g SXNhZmpvcmRzZ2F0YW4gMjIgLyBLaXN0YWfDpW5nZW4gMTYNCj4gU0UtMTY0IDQwIEtpc3RhIChT d2VkZW4pDQo+IA0KPiBQaG9uZTogKzQ2ICgwKTcwIDYwIDQ2IDUwMQ0KPiBodHRwczovL3d3dy5y aS5zZQ0KPiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Jan 12 07:26:12 2021 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 9DB7A3A00C9 for ; Tue, 12 Jan 2021 07:26:07 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 6eA931qZDYjj for ; Tue, 12 Jan 2021 07:26:05 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 F09B03A00D2 for ; Tue, 12 Jan 2021 07:26:04 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kzLYW-0007jN-Nw; Tue, 12 Jan 2021 15:26:00 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> In-Reply-To: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> Date: Tue, 12 Jan 2021 15:26:10 -0000 Message-ID: <083c01d6e8f7$4137a420$c3a6ec60$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVQGW5zMSAr51FjUBa6IWcAGdmCj+Al0VD5oCSzuKDKg7hFnQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 15:26:08 -0000 Hi Marco and all, Need clarity on how to do a (Q-)Block2 request for a specific block when = the request needs (Q-)Block1. Adding in the Observe option into Figures 11 & 12 caused other things to = be updated (text is being updated) - e.g. the Observe option needs to be = set on all of the Q-Block1 payloads making up the body. However, I have run into not being sure what to do when a request needs = Q-Block1 and the response needs Q-Block2 - and then we need to recover a = missing Q-Block2 block. Med and I have been discussing this offline.=20 In the case of Q-Block1/Q-Block2 it is about what is the request needed = to get a missing Q-Block2 block. In the case of Block1/Block2 it is all = about the request needed to get the next Block2 block. For whatever reason, a (Q-)Block2 block needs to be requested. Given = that the request has used (Q-)Block1 to handle the large body, do we = just need to use the request method and matching options (with = appropriate (Q-)Block2 NUM) without the payload, or do we have to use = the payload as well and hence use multiple packets for the complete = request? If the server is caching the response, then a match can just be done on = the cache-key if formed right. If the server does not cache the response, then when using a FETCH, the = FETCH will need to have the body to regenerate the response. The closest I can find to this is in 2.7 rfc7959 which has " In PUT and particularly in POST exchanges, both the request body and the response body may be large enough to require the use of block- wise transfers. First, the Block1 transfer of the request body proceeds as usual. In the exchange of the last slice of this block- wise transfer, the response carries the first slice of the Block2 transfer (NUM is zero). To continue this Block2 transfer, the client continues to send requests similar to the requests in the Block1 phase, but leaves out the Block1 Options and includes a Block2 request option with non-zero NUM." In particular note the occurrence of the second "requests" is plural in = this line. " continues to send requests similar to the requests in the Block1 phase" This implies to me that there are multiple requests needed to make up = the request with a full body to ask for a single block and that is the = way to go - correct? Secondly, For a FETCH to cancel an Observe, again I can find no text giving = clarity (as there are no references to payload), but have to assume that = FETCH needs to be identical (apart from message id and Observe value = which is now 1) including the payload - correct? Regards Jon PS - We have worked out the wording for the 2.02 response. > -----Original Message----- > From: Marco Tiloca [mailto:marco.tiloca@ri.se] > Sent: 11 January 2021 19:23 > To: supjps-ietf@jpshallow.com; christian@amsuess.com; > draft-ietf-core-new-block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > Thanks for the fast reaction. Please, see inline. >=20 > Best, > /Marco >=20 >=20 > As to the two new examples in Figures 11 and 12, please add the = Observe > option with value 0 to the requests from the client, i.e. O:0, just = like you do > in Figures 7 and 8. >=20 > Best, > /Marco > <=3D=3D >=20 From nobody Tue Jan 12 22:51:11 2021 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 381C93A0C6B; Tue, 12 Jan 2021 22:51:09 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhGhyVjATm9K; Tue, 12 Jan 2021 22:51:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29373A0C57; Tue, 12 Jan 2021 22:51:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D00EBF40738; Tue, 12 Jan 2021 22:50:56 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dots@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210113065056.D00EBF40738@rfc-editor.org> Date: Tue, 12 Jan 2021 22:50:56 -0800 (PST) Archived-At: Subject: [Dots] =?utf-8?q?RFC_8973_on_DDoS_Open_Threat_Signaling_=28DOTS?= =?utf-8?q?=29_Agent_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: Wed, 13 Jan 2021 06:51:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8973 Title: DDoS Open Threat Signaling (DOTS) Agent Discovery Author: M. Boucadair, T. Reddy.K Status: Standards Track Stream: IETF Date: January 2021 Mailbox: mohamed.boucadair@orange.com, tirumaleswarreddy_konda@mcafee.com Pages: 22 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dots-server-discovery-15.txt URL: https://www.rfc-editor.org/info/rfc8973 DOI: 10.17487/RFC8973 This document specifies mechanisms to configure DDoS Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call Home. It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions. This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed. This document is a product of the DDoS Open Threat Signaling Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jan 12 23:02:53 2021 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 871263A0C8B; Tue, 12 Jan 2021 23:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC3p8scmyn13; Tue, 12 Jan 2021 23:02:50 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 257193A0C88; Tue, 12 Jan 2021 23:02:46 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.11]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee85ffe9b07bad-fce81; Wed, 13 Jan 2021 15:02:32 +0800 (CST) X-RM-TRANSID: 2ee85ffe9b07bad-fce81 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[10.2.54.47]) by rmsmtp-syy-appsvr06-12006 (RichMail) with SMTP id 2ee65ffe9b06327-dd97b; Wed, 13 Jan 2021 15:02:31 +0800 (CST) X-RM-TRANSID: 2ee65ffe9b06327-dd97b Date: Wed, 13 Jan 2021 15:02:36 +0800 From: "Meiling Chen" To: "Valery Smyslov" , "draft-ietf-dots-telemetry@ietf.org" Cc: dots-chairs , dots References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.115[cn] Mime-Version: 1.0 Message-ID: <202101131502356787292@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart405516152065_=----" Archived-At: Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 07:02:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart405516152065_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgVmFsZXJ5LCBhbGwsDQoNCkkgZG9uJ3QgaGF2ZSBhbnkgSVBSIG5vciBJJ20gYXdhcmUgb2Yg YW55IHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NCg0KVGhhbmtzLA0KTWVpbGluZy4NCkZyb206IFZh bGVyeSBTbXlzbG92DQpEYXRlOiAyMDIxLTAxLTExIDIwOjE4DQpUbzogZHJhZnQtaWV0Zi1kb3Rz LXRlbGVtZXRyeUBpZXRmLm9yZw0KQ0M6IGRvdHMtY2hhaXJzQGlldGYub3JnOyBkb3RzQGlldGYu b3JnDQpTdWJqZWN0OiBJUFIgY29uZmlybWF0aW9uIGZvciBkcmFmdC1pZXRmLWRvdHMtdGVsZW1l dHJ5LTE1DQpIaSBhdXRob3JzLA0KIA0Kd2hpbGUgcHJlcGFyaW5nIHNoZXBoZXJkIHdyaXRlLXVw IGZvciBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTE1LCANCmluIGFjY29yZGFuY2Ugd2l0aCBC Q1A3OCBhbmQgQkNQNzkgSSBoYXZlIHRvIGFzayBhbGwgYXV0aG9ycyBhbmQgY29udHJpYnV0b3Jz IHdoZXRoZXIgDQp0aGV5IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHJlZ2FyZGluZyB0aGlzIGRvY3Vt ZW50Lg0KQ2FuIHlvdSBwbGVhc2UgY29uZmlybSB0aGF0IHlvdSBhcmUgbm90IGF3YXJlIG9mIGFu eSBJUFIgDQpvciBkaXNjbG9zZSBhbnkgSVBSIHlvdSBhcmUgYXdhcmUgb2YgdGhhdCBhcmUgY29u Y2VybmVkIHdpdGggdGhpcyBkcmFmdC4NCiANCkknZCBhbHNvIGxpa2UgdG8gYXNrIGF1dGhvcnMg YWJvdXQgaW1wbGVtZW50YXRpb24gc3RhdHVzIG9mIHRoZSBkcmFmdC4NCkFyZSB0aGVyZSBhbnkg aW1wbGVtZW50YXRpb25zIHlvdSBhcmUgYXdhcmUgb2Y/DQogDQpSZWdhcmRzLA0KVmFsZXJ5Lg0K IA0KIA0K ------=_001_NextPart405516152065_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi Valery, all,

I don't have any IPR nor I'm aware of any re= lated to this draft.

Thanks,
Meiling.
Date: 2021-01-11 20:18
To: dra= ft-ietf-dots-telemetry@ietf.org
Subject: IPR confirma= tion for draft-ietf-dots-telemetry-15
Hi author= s,
=0A
 
=0A
while preparing shepherd write-up for = draft-ietf-dots-telemetry-15,
=0A
in accordance with BCP78 and B= CP79 I have to ask all authors and contributors whether
=0A
they= are aware of any IPR regarding this document.
=0A
Can you please= confirm that you are not aware of any IPR
=0A
or disclose any I= PR you are aware of that are concerned with this draft.
=0A
 = ;
=0A
I'd also like to ask authors about implementation status of= the draft.
=0A
Are there any implementations you are aware of?=0A
 
=0A
Regards,
=0A
Valery.
=0A 
=0A
 
=0A
------=_001_NextPart405516152065_=------ From nobody Wed Jan 13 02:15:27 2021 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 0471A3A0C10 for ; Wed, 13 Jan 2021 02:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 2s8HIyxLZ3hW for ; Wed, 13 Jan 2021 02:15:24 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 C1CD93A0C0F for ; Wed, 13 Jan 2021 02:15:23 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4DG3Gy04v3z1yYv for ; Wed, 13 Jan 2021 11:15:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610532922; bh=mk9umxm0PlUr6A/kSoaXViTvFGCD+woZk/p1yyGWM0k=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cn0fRkGrVkYfED/GXP73XzRaA3jX2LFw/s8RV/tnqzYqdisQVltrSsOZxb0QCGRcF VXU0Kzo/WuezZ37qyuVLM6jAa7vyV9dCbkPgkmJd6EFn6uAaPC1zhUYxFysE3hECHg 2kcTPjLgTIOn3zTdJObPkR8cMQxK0ZyhRfTA2DRvY2FaTCM0Q/iaYpOJvh7ZuEQ5rS kc02+2R1EGREVZTtl7aHmjEcYcHYvT2WStMpsuTr9mnQrhLA80igPrjog0LygoYl1m jiCPxmGVNxSCkA7pWdpQsxClLhN0YHClPukNSRrbOpNPPoLjYCifAeK1C6CJG4mQ5C 8bCo5QfmuOBAw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4DG3Gx6RBkz1xq6 for ; Wed, 13 Jan 2021 11:15:21 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-bosh-dots-quick-blocks-00.txt Thread-Index: AQHW6BE+e4a7glWno0iUb+SxdUBAEKoiUnHwgAMGbtA= Date: Wed, 13 Jan 2021 10:15:21 +0000 Message-ID: <10787_1610532921_5FFEC839_10787_48_1_787AE7BB302AE849A7480A190F8B9330315B8A2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161036637813.11527.15818091495971687767@ietfa.amsl.com> <30749_1610366791_5FFC3F47_30749_168_2_787AE7BB302AE849A7480A190F8B9330315B71FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <30749_1610366791_5FFC3F47_30749_168_2_787AE7BB302AE849A7480A190F8B9330315B71FE@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] New Version Notification for draft-bosh-dots-quick-blocks-00.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, 13 Jan 2021 10:15:26 -0000 SGkgYWxsLCANCg0KQW4gdXBkYXRlZCB2ZXJzaW9uIHdpdGggYW4gZXhhbXBsZSBhbmQgYSBuZXcg YXR0cmlidXRlIGlzIGF2YWlsYWJsZToNCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3NoLWRvdHMtcXVpY2stYmxvY2tzLTAxIA0KRGlmZjogICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3NoLWRvdHMt cXVpY2stYmxvY2tzLTAxIA0KDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUu IA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXC oDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IEVudm95w6nCoDogbHVuZGkgMTEgamFudmll ciAyMDIxIDEzOjA3DQo+IMOAwqA6IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogW0RvdHNdIFRS OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvc2gtZG90cy0NCj4gcXVpY2st YmxvY2tzLTAwLnR4dA0KPiANCj4gSGkgYWxsLA0KPiANCj4gKENjaSdpbmcgY29yZSBXRyB3aGVy ZSB0aGUgbmV3IGJsb2NrcyBhcmUgZGVmaW5lZCkNCj4gDQo+IFRoaXMgc3BlYyBkZWZpbmVzIG5l dyBhdHRyaWJ1dGVzIHRoYXQgY2FuIGJlIG5lZ290aWF0ZWQgYmV0d2VlbiBET1RTDQo+IGFnZW50 cyB0aGF0IHN1cHBvcnQgUS1CbG9jazEvMi4gQXMgYSByZW1pbmRlciwgdGhlc2Ugb3B0aW9ucyBh cmUNCj4gZGVzaWduZWQgdG8gYWxsb3cgZm9yIGZhc3RlciB0cmFuc21pc3Npb24gaW4gRE9UUy1s aWtlIGVudmlyb25tZW50cy4NCj4gDQo+IENvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiANCj4gQ2hl ZXJzLA0KPiBKb24gJiBNZWQNCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddDQo+IEVudm95w6nCoDogbHVuZGkgMTEgamFudmllciAyMDIxIDEzOjAwIMOAwqA6IEpv biBTaGFsbG93IDxzdXBqcHMtDQo+IGlldGZAanBzaGFsbG93LmNvbT47IEJPVUNBREFJUiBNb2hh bWVkIFRHSS9PTE4NCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IE9iamV0wqA6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nr cy0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9zaC1kb3Rz LXF1aWNrLWJsb2Nrcy0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvDQo+IHRoZSBJRVRGIHJlcG9zaXRvcnku DQo+IA0KPiBOYW1lOgkJZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcw0KPiBSZXZpc2lvbjoJ MDANCj4gVGl0bGU6CQlEaXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdCBT aWduYWxpbmcNCj4gKERPVFMpIFNpZ25hbCBDaGFubmVsIENvbmZpZ3VyYXRpb24gQXR0cmlidXRl cyBmb3IgRmFzdGVyIEJsb2NrDQo+IFRyYW5zbWlzc2lvbg0KPiBEb2N1bWVudCBkYXRlOgkyMDIx LTAxLTExDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTQNCj4g VVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYm9z aC1kb3RzLQ0KPiBxdWljay1ibG9ja3MtMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3NoLWRvdHMtDQo+IHF1aWNrLWJsb2Nr cy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtYm9zaC0NCj4gZG90cy1xdWljay1ibG9ja3MNCj4gSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3NoLWRvdHMtcXVpY2stDQo+IGJsb2Nr cy0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBu ZXcgRE9UUyBzaWduYWwgY2hhbm5lbCBjb25maWd1cmF0aW9uDQo+ICAgIHBhcmFtZXRlcnMgdGhh dCBhcmUgbmVnb3RpYXRlZCBiZXR3ZWVuIERPVFMgcGVlcnMgdG8gZW5hYmxlIHRoZQ0KPiB1c2UN Cj4gICAgb2YgUS1CbG9jazEgYW5kIFEtQmxvY2syIE9wdGlvbnMuICBUaGVzZSBvcHRpb25zIGVu YWJsZSBmYXN0ZXINCj4gICAgdHJhbnNtaXNzaW9uIHJhdGVzIGZvciBsYXJnZSBhbW91bnRzIG9m IGRhdGEgd2l0aCBsZXNzIHBhY2tldA0KPiAgICBpbnRlcmNoYW5nZXMgYXMgd2VsbCBhcyBzdXBw b3J0aW5nIGZhc3RlciByZWNvdmVyeSBzaG91bGQgYW55IG9mDQo+IHRoZQ0KPiAgICBibG9ja3Mg Z2V0IGxvc3QgaW4gdHJhbnNtaXNzaW9uLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4g c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4g DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiBwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cw0KPiBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiBhIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMNCj4gbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLA0KPiBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwNCj4gZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IN Cj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K PiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQN Cj4gYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4gaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4g RG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rv dHMNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Jan 13 10:13:52 2021 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 D96C33A125F; Wed, 13 Jan 2021 10:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 5t8ijWi_1JYz; Wed, 13 Jan 2021 10:13:43 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 CAB743A125E; Wed, 13 Jan 2021 10:13:42 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DGFts0l1Cz101V; Wed, 13 Jan 2021 19:13:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610561621; bh=SzzxzxwiyeNXRblEFSUltBDxcOdHxRm2yUsMRunlJbw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=buBQs+8khYXk1hGNBS7EctrvME6i5UEZ1UyRf/Q4bJYSAbZe4NRZDiodQGmp2xzay d90NuHclgm91Sd+ajHg+vVf98pk/AZy+9gFeFzUCGmPi2r+5HMAqsSlHv2voOQMa4p OCPbrLWt6PzpQDDbZBMZ7y41DOsNsERATiYl5IHvVlJ1j0+BRsB0TI0MQuqz/oYCtj qU7upCiaJdxHAh4YTvLgfNFwMMCBJFvj6uc3+PLBMPZEpRh/TXbnEOWsLpby9HjStT In4KghBa7KnkKdtsG5vr/zxjHv2rcou1MNKBoEOGTbML7YDYNvpRlhA72dYDxAfPzt 5ryurb/An+oQw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4DGFtr72Rdz1xpt; Wed, 13 Jan 2021 19:13:40 +0100 (CET) From: To: "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-core-new-block-05.txt Thread-Index: AQHW6dbZ1lvpcRxOKUGdJpg2sLRLP6ol2h/g Date: Wed, 13 Jan 2021 18:13:40 +0000 Message-ID: <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> In-Reply-To: <161056117925.23400.10291073677288718681@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.245] 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-core-new-block-05.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, 13 Jan 2021 18:13:46 -0000 Hi all,=20 This version integrates the latest comments from Marco, especially the hand= ling of FETCH. New examples were also added to illustrate the intended beha= vior.=20 If there are still any pending issues, please let us know.=20 Cheers, Jon & 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: mercredi 13 janvier 2021 19:06 > =C0=A0: i-d-announce@ietf.org > Cc=A0: core@ietf.org > Objet=A0: I-D Action: draft-ietf-core-new-block-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Constrained RESTful Environments WG > of the IETF. >=20 > Title : Constrained Application Protocol (CoAP) > Block-Wise Transfer Options for Faster Transmission > Authors : Mohamed Boucadair > Jon Shallow > Filename : draft-ietf-core-new-block-05.txt > Pages : 42 > Date : 2021-01-13 >=20 > Abstract: > This document specifies alternative Constrained Application > Protocol > (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 > Options. >=20 > These options are similar to the CoAP Block1 and Block2 Options, > not > a replacement for them, but do enable faster transmission rates > for > large amounts of data with less packet interchanges as well as > supporting faster recovery should any of the blocks get lost in > transmission. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-new-block-05 > https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-new-block-05 >=20 >=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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jan 14 11:57:52 2021 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 ABA813A134F; Thu, 14 Jan 2021 11:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 7MupuMjtnehZ; Thu, 14 Jan 2021 11:57:43 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60087.outbound.protection.outlook.com [40.107.6.87]) (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 5E5893A14C1; Thu, 14 Jan 2021 11:57:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DKF3Cl/isVlbqa4bVMbwerYfx3hduDINWHuwl0zMf3I68JWXQP4F/nHw/9bfxe5a94gTT9VpcEJ8Dx8ENzrokQg/9/0cVTJMc+yfD14w8U+lndDvLXL+XB029HtZATLPLUel0RETmkJCH9ozzSICZRN6FRwht8AaPE4mfbFGn0qSyQ4tj7PgtEEuun0JfIPVi/v7CdMVBmWZ86ZzyBVaZCJn3rApS8NAdqmC2MoFgbNp9dXlDKFz2Vb8zSEoZlfSjrRXzRIA58hc+zB4TF+b+xr2OBSS69XEi3pYuSBk9LO3wslemahlGOzpdTqef783g68xIDvbdyVdtYLFR9n4mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mfEO524lE6lu5AA+CHSm+Y+cbgzmZO7ConU9sKajKE8=; b=R26KUO8wy1seBy307dwnJJMEqX2qlXbQa1smY6lg3yypXRmobzmwVJ6ZJlyYTwYFaUXlsvFnIzPgoiXph3QZxAXjfCcvm4gJkvg393E1lAb9fmBBJaM/9ddCovHFG+uYNalp0OkvjTmIEx0Pq2Bg+B+XHHtG6l/n0fPj2ENyCwQonCbOEyMpQFK6gVokM6jGCQex/BMVleA77MLENvWGmFPsDOtUr/Jy9MTxIUdF2AGHYTQB+6M28for8lMWMyD6cGqRXK5Byxzi/sktyd8+kRSt47VfURe9FlO79dqPHi4JRIDc7yC169bivmGiN3d7mlFt82gvf1iqd1g9nS20Tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mfEO524lE6lu5AA+CHSm+Y+cbgzmZO7ConU9sKajKE8=; b=MSsT1OROBbNjlfVVsrs+XgAEgHHj8xiwRg6qVNLYcVZULY3J5f+EtKYAc8sX3/28wC3Lk/ZSOUew9x97RaMoluqvzpGcex8F3Y53TT0QeQqic5IZaxgewnaiFvgvr/6phitDTYLiR+43HGxaHCI9rBqU/7JDUO/IKLz+ENTURM8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0280.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:35::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.9; Thu, 14 Jan 2021 19:57:39 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.010; Thu, 14 Jan 2021 19:57:39 +0000 To: mohamed.boucadair@orange.com, "core@ietf.org" Cc: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> Date: Thu, 14 Jan 2021 20:57:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu" X-Originating-IP: [185.236.42.208] X-ClientProxiedBy: HE1PR05CA0274.eurprd05.prod.outlook.com (2603:10a6:3:fc::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.4] (185.236.42.208) by HE1PR05CA0274.eurprd05.prod.outlook.com (2603:10a6:3:fc::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10 via Frontend Transport; Thu, 14 Jan 2021 19:57:38 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5f793365-31d3-4fce-9d82-08d8b8c6a5a3 X-MS-TrafficTypeDiagnostic: DB6P189MB0280: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GACXpp29RGJcjMoipfMTe87CLg2/u2ofBi/Ei9ohjYPnfWG3h/QvPU1Y5l3CX/uZ0p3UhXtCKtzD94RwGJ7IoLTs+DFsZq6+2cpyEn7pdvSHbu+3EOmCdC7jM4NlyCA6M0o4vMxEVkZL48OjfmUeSXMot5mHTyUaIN2za4xkrjl0lpVTALJMEheTpKNqbyn7tqv2uG37sfJqgIBq7JuT4Id9Yzls08vbmSnXJBnLuIbf++ISeUXfULmRiD4V0qXqB1Ii3uGylCl1bqXvug6bKeHvN4uARcD0UAKtywv5NHrwK9k8TQk6fcHK1kj5DfzKISK/AOZ28N45MDPczYqFaQZzyxEAeR9tO9ZJnRcND7EJO4du5B3F+4yWeTwlmiO+AhQv5ylBxt8p7KL/dmLpHf1r5f16Zc2ONWIkVkpguTKPAX0HRYaekAlKw7KcLbwWL//ekhTZnv0DFyUNuOXUch0py4UG4ptofuSQNAUUP0l10Qv5yq3QL2eY4o19d5k7C67SUPDoQHVpN95uvJJ8H0KA94LKg9DUCsXz1bPwNtg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(396003)(136003)(39850400004)(2906002)(478600001)(4326008)(54906003)(16576012)(16526019)(5660300002)(66556008)(31696002)(26005)(8676002)(53546011)(8936002)(6486002)(2616005)(36756003)(316002)(86362001)(6916009)(31686004)(186003)(44832011)(52116002)(45080400002)(33964004)(6666004)(21480400003)(66946007)(66574015)(83380400001)(235185007)(66476007)(966005)(956004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bXJXZjZTNWtsTDhLS25XUGMzU1kxczUzNGlhUWZCbnh2a1NnbVZWcVplbzRN?= =?utf-8?B?S0xvSlFyVkFIenkrOHYrTmhTOGpqaG94aHZQZW1kZzJaWDZsUmNVWStLSml2?= =?utf-8?B?VGJtZVgzMkE0cERtdDdpNnBMZHR1NCthMzA2NnlqcE83bHFWbWQ2YXhBSXFF?= =?utf-8?B?QWpxekpZeEVpV2VBY050bGk2REtVTXE2czR5MTNQb2pjTXIxcUdybnpjajRZ?= =?utf-8?B?YjdYYkVzTnFYdFYvcjR6WGlSWk9pWHBCQnZMZzF4QkRMZ0VmbFBMMWs2c1Zp?= =?utf-8?B?bmVlS2R1WWloclZ1UjFRdFNTeS8vQml0VzdnVFE5YnVaTWR0NHd1NndHTTlk?= =?utf-8?B?RUdPTm05RFFkdE1xYnl2dHdqc2NWV09EOXBqMjA4a3IzWTczWXBydVo4L2Yy?= =?utf-8?B?Q2Ryd0dKa2hHU0VUUjFJRWVPa2MxcUlrcko3S1hsdWFOYlJFcmF3K1FJYVVa?= =?utf-8?B?Vk1KK1dIalE1cEhJUHp3NW1mNlhGRlNXYXJFKzlGcWJjWFdpU1VTNm9uaFk0?= =?utf-8?B?RXMvVmFjVzB1ajdXcmJiQVBTeFF1UWh3SUFiS3pCY211WTRHb3ViRVBLZDBT?= =?utf-8?B?UnRMUXFVdTlqc3JEQmQva0xHTkNZRVI2L284enpld2kycE9nQ2lUR0twUUN0?= =?utf-8?B?NmRpUDZsK2N6YjY5K1lKb29MRXI3OWk2WWVzaHFKalRyQXRFR2s4VVA2Z25P?= =?utf-8?B?VVlpbE04WHgzZ0JKN2QzalRZRCtIZUo0V1hsTDJ4TTB1dWFDVmJidi9PYlVz?= =?utf-8?B?bG5LMW8wN0s4UmExQ0c5SDY2WHg2dkJXaE9DbkIvOGEzMWxEeFBhTEJsM1E4?= =?utf-8?B?QTdqZGtwbU9nK2lMYjFMV2Q5d2FFanA4S0ZjeVZ3RndHZFA5a1RiVWFxM2Mr?= =?utf-8?B?cjRjSklhK1JTR3FDYUUxVStTRnpQb3VYcjltVGQ3YndOam9KRmFjUFpzMlk3?= =?utf-8?B?ZEF2Nk4vaEE0OWJBTkZJeVp5bkNIK1VNNnZZcnNTRzBvR0x5MWhPTG9EZE5T?= =?utf-8?B?VVVEYm8rcW9xUlE4d3FPNVZNT09Va204Z2IwNW12TzhENDUrb1lWYWY5YkFS?= =?utf-8?B?ZTl1Ky94SVc1TGxvL1Q3U3duemUzSUxtUHkyK2IwWDZ4andGcURkMUxLRlc2?= =?utf-8?B?NnlPNkxNTkNjWWVXZXI4U280NFFCTFM1OGhtVzFsNHdvZkxOTTY5cEsvblVG?= =?utf-8?B?TzREUGpXT0U2Ti9GRVJVa3R1L0pTWFFTdzdmREJVZEZVU1RPQTk5RWR4WkNI?= =?utf-8?B?SlJ4SVhhRmpaWEUrb2tibzdQUlFUQ1RvNTFGQzRPaFdLa3UzUlpDZWc0SkZ3?= =?utf-8?Q?mNqkxZX40sfxkRu1IJCQ5W0IwOW7cfbDAr?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2021 19:57:39.3808 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 5f793365-31d3-4fce-9d82-08d8b8c6a5a3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ppQAdfHsDXCrtgWErLX2jWIzRQNKI/Bdm2Tm/r6LEFPDjBYpMCvBNExqPCMCFOgw17MllyNcnOPwtqPFOS34kA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0280 Archived-At: Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.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, 14 Jan 2021 19:57:47 -0000 --AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu Content-Type: multipart/mixed; boundary="ytG8UItc3Uci9JrV0nQLqKNvvqAqH5IdD" --ytG8UItc3Uci9JrV0nQLqKNvvqAqH5IdD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Med, Thanks for the new document version. Please, see below some comments on the latest additions, also related to what Jon raised at [1]. Best, /Marco [1] https://mailarchive.ietf.org/arch/msg/core/Orr8a1WlSu3Dk-gtPQZloDT9_1= E/ * Section 3.5 - This seems to mix aspects specific to Observe, with more general aspects applicable to requests with a payload, i.e. FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. =C2=A0 What is specific of Observe is the first paragraph; and the usage = of the Observe option in the second and third paragraph. Anything else seems generic and applicable to requests with payload, so it might be moved up to some earlier section. * Section 3.5 - In the third paragraph, I'm not sure you necessarily need a payload to be present in the requests asking for missing response payloads. For instance, consider: =C2=A0 =C2=A0 - The examples in Figure 10 and Figure 11 of RFC 7959, with the no= te "(no payload for requests with Block2 with NUM !=3D 0)" , during the phas= e where the client consecutively asks for the next response payload. =C2=A0 - The examples in Figure 2 and Figure 3 of [2], where each request= for the next response payload using Block2 has no payload of its own. This would of course affect the example in Figure 15. =C2=A0 [2] https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 * Section 3.5 - About the last sentence regarding the Observe option, there seems to be an exception to this rule (at least based on the later examples), where the server actually does include the Observe option in the response. =C2=A0=C2=A0 That is, consider the example in Figure 10, where the respon= se with M:0xba is lost. Later on, the client asks for that response payload by sending the request with M:0x87, which correctly does not include the Observe option. =C2=A0=C2=A0 =C2=A0=C2=A0 However, the following response with M:oxc3 and (from the po= int of view of the server) retransmitting that response payload with block number 10 does include the Observe option. =C2=A0=C2=A0 =C2=A0=C2=A0 The exception seems due to the fact that the retransmission = request from the client is specifically what you call 'Continue' Q-Block-2 in Section 3.4. The Observe option is in fact not included for the previously retransmitted response payloads with M:0xbb ... M:0xc2, as still part of the current payload set. * Section 3.6 - Part of the first sentence in the second paragraph seems to repeat what already said in the third paragraph of Section 3.5. On 2021-01-13 19:13, mohamed.boucadair@orange.com wrote: > Hi all,=20 > > This version integrates the latest comments from Marco, especially the = handling of FETCH. New examples were also added to illustrate the intende= d behavior.=20 > > If there are still any pending issues, please let us know.=20 > > Cheers, > Jon & Med > >> -----Message d'origine----- >> De=C2=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la pa= rt >> de internet-drafts@ietf.org >> Envoy=C3=A9=C2=A0: mercredi 13 janvier 2021 19:06 >> =C3=80=C2=A0: i-d-announce@ietf.org >> Cc=C2=A0: core@ietf.org >> Objet=C2=A0: I-D Action: draft-ietf-core-new-block-05.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Constrained RESTful Environments WG >> of the IETF. >> >> Title : Constrained Application Protocol (CoAP) >> Block-Wise Transfer Options for Faster Transmission >> Authors : Mohamed Boucadair >> Jon Shallow >> Filename : draft-ietf-core-new-block-05.txt >> Pages : 42 >> Date : 2021-01-13 >> >> Abstract: >> This document specifies alternative Constrained Application >> Protocol >> (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 >> Options. >> >> These options are similar to the CoAP Block1 and Block2 Options, >> not >> a replacement for them, but do enable faster transmission rates >> for >> large amounts of data with less packet interchanges as well as >> supporting faster recovery should any of the blocks get lost in >> transmission. >> >> >> The IETF datatracker status page for this draft is: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&data=3D04%7C0= 1%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bc= b413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3= d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C20= 00&sdata=3Dud1P4lktmZSE6bfK3Z1IvqZdjSG6aZJNUNwAfUEliFQ%3D&reserve= d=3D0 >> >> There are also htmlized versions available at: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto= ols.ietf.org%2Fhtml%2Fdraft-ietf-core-new-block-05&data=3D04%7C01%7Cm= arco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a= 838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&am= p;sdata=3DJ4zJlB0x1WpQosEH3R0WBg2hoHuRpKiQVPpfwTk82n4%3D&reserved=3D0= >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-new-block-05&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C2000&sdata=3DXzJsVE4fc8Bj8aoKqmVTjSztTnTqsr42QY3u3Fhu4BY%3D&r= eserved=3D0 >> >> A diff from the previous version is available at: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-new-block-05&data=3D04%= 7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf= 0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C2000&sdata=3DXfWCRY89NGPI%2BOH6rmg9BuJHjwIpsWAHadSIglqnDDE%3D&re= served=3D0 >> >> >> 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: >> https://eur02.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.= ietf.org%2Finternet-drafts%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7= Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%= 7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ= IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DnDdHKBvQpuw= nSsPvGghajJsaBKTXk295O%2BNDXEri9V4%3D&reserved=3D0 >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&data=3D04%7C01%7Cmarco= =2Etiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a83= 8a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&= sdata=3D%2F3GBuD%2Fc2uCE9bAdXWxAy0bYvLIPMczzffzKYKv6Zc4%3D&reserved=3D= 0 >> Internet-Draft directories: https://eur02.safelinks.protection.outlook= =2Ecom/?url=3Dhttp%3A%2F%2Fwww.ietf.org%2Fshadow.html&data=3D04%7C01%= 7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb4= 13a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8= eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000= &sdata=3D%2BEoWyGAyhlY0NmwyMvoe2vOeuXciF7kdnsZe1dIIHP0%3D&reserve= d=3D0 or >> https://eur02.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.= ietf.org%2Fietf%2F1shadow-sites.txt&data=3D04%7C01%7Cmarco.tiloca%40r= i.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e= 8%7C0%7C0%7C637461584588465405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DLDcmi= 9fJAgtoqVsl4AUpt0Xm8K1XEFguDVmCXg6we88%3D&reserved=3D0 > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > > _______________________________________________ > core mailing list > core@ietf.org > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca= %40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40= cc9e8%7C0%7C0%7C637461584588465405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dz= F09t2u3ZkjRw1eRfzIMegbOZRTIVRGGUVKE9TZp0oY%3D&reserved=3D0 --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --ytG8UItc3Uci9JrV0nQLqKNvvqAqH5IdD-- --AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAAoisACgkQ7iZktA5Y 2kO1Dgf+LJj1eu1cO9hC1KCqfJx7+VMvvXocc2PHlku+E35frwlNBY24EFJd/eua i677jBfu9fvmGNZKOEKCXWEENz8M3J3tg4ww/FL4G+0teBI0g3plL88bU/wXpJkm 1tlxh3vFA5SbYPBSrZc0zgylEEKUsbGGzIaaYMvVdZde+tqhDM/tbP2vW0T0yP+a MBO2duNp7/9PnoZM31Y3XDi3iv23h03GNZ+PRgzNKbhvcrfdNYBOc/3FSTvmc3R+ af3mscNWmFoGlEU32kAEf2INvcGn658qPxLCCbcztd15U1lNHb8lBe5p2H6ZVI/Y qMXpUzAcSd16UYtgh3DYEToWxUcSug== =G0w8 -----END PGP SIGNATURE----- --AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu-- From nobody Fri Jan 15 03:24:36 2021 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 D5D4F3A0B18 for ; Fri, 15 Jan 2021 03:24:31 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 nGQ73dnoHF4d for ; Fri, 15 Jan 2021 03:24:29 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 CC4EE3A0B12 for ; Fri, 15 Jan 2021 03:24:28 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1l0NDN-0001xi-3g; Fri, 15 Jan 2021 11:24:25 +0000 From: To: "Marco Tiloca" , , Cc: , References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> In-Reply-To: <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> Date: Fri, 15 Jan 2021 11:24:44 -0000 Message-ID: <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINhJL1nc88GwsEKn+AjV1kVr7Y4AGmsrCNATjbviqppE6oUA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.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 Jan 2021 11:24:32 -0000 Hi Marco, Thanks from this. So moving forward, requests for missing Q-Block2 blocks will follow = Section 2.7 RFC7959 being modelled on (assuming the request was using = Q-Block1) " To continue this Block2 transfer, the client continues to send requests similar to the requests in the Block1 phase, but leaves out the Block1 Options and includes a Block2 request option with non-zero NUM." Otherwise, please see inline which has a couple of questions. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 14 January 2021 19:58 > To: mohamed.boucadair@orange.com; core@ietf.org > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >=20 > Hi Med, >=20 > Thanks for the new document version. >=20 > Please, see below some comments on the latest additions, also related = to what > Jon raised at [1]. >=20 > Best, > /Marco >=20 > [1] = https://mailarchive.ietf.org/arch/msg/core/Orr8a1WlSu3Dk-gtPQZloDT9_1E/ >=20 >=20 > * Section 3.5 - This seems to mix aspects specific to Observe, with = more general > aspects applicable to requests with a payload, i.e. FETCH (with or = without > Observe), PUT, POST and PATCH/iPATCH. [Jon] Now that we understand what needs to be done with requesting = missing Q-Block2 blocks, working with Observe can be simplified. [Jon] Requesting Observe is only valid for GET and FETCH. Hence Observe = request/cancellation setting when using Q-Block1 is only appropriate for = FETCH. [Jon] Unfortunately, RFC8132 does not specify in which of the payloads = of as Block1 based FETCH request should contain the Observe option = assuming observe is required (The first, the last or all of the = payloads). So, here, I believe the safest way to go is with all the = payloads carry the observe option if observe is being requested or = cancelled. Thus any missing payloads should be resent with the observe = configured to be consistent with all the other payloads. Are you happy = with this? >=20 > What is specific of Observe is the first paragraph; and the usage of = the Observe > option in the second and third paragraph. Anything else seems generic = and > applicable to requests with payload, so it might be moved up to some = earlier > section. >=20 [Jon] Sure - will be updated in the simplification tidy up. >=20 > * Section 3.5 - In the third paragraph, I'm not sure you necessarily = need a > payload to be present in the requests asking for missing response = payloads. For > instance, consider: [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 and = payload are not included. >=20 > - The examples in Figure 10 and Figure 11 of RFC 7959, with the note = "(no > payload for requests with Block2 with NUM !=3D 0)" , during the phase = where the > client consecutively asks for the next response payload. >=20 > - The examples in Figure 2 and Figure 3 of [2], where each request = for the next > response payload using Block2 has no payload of its own. >=20 > This would of course affect the example in Figure 15. [Jon] Yes, will be updated. >=20 > [2] https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 >=20 >=20 > * Section 3.5 - About the last sentence regarding the Observe option, = there > seems to be an exception to this rule (at least based on the later = examples), > where the server actually does include the Observe option in the = response. [Jon] If the Observe option is just included with the first payload (NUM = =3D 0) as RFC7959, there is a recovery special case should the first = payload not arrive, but subsequent ones do. In the general case, blocks = that are missing are re-requested by the client and the server responds = with the appropriate block, but without the Observe option. For the = special case when the client requests missing payload with NUM =3D 0 the = server needs to know that it must include the Observe in the response so = that the client following the body re-assembly knows that it is a = Observe triggered additional response. [Jon] I had gone with the Observe should be in all the payloads in the = response apart from specifically re-requested blocks (including NUM =3D = 0). The 'Continue' Q-Block2 was just to indicate a continue so the = server can send the remaining payloads without delay - hence why = remaining payloads had Observe set. =20 [Jon] I am beginning to lean to having it in the first payload and = special case the response to re-request of NUM =3D 0. What do you = think? >=20 > That is, consider the example in Figure 10, where the response with = M:0xba is > lost. Later on, the client asks for that response payload by sending = the request > with M:0x87, which correctly does not include the Observe option. >=20 [Jon] Yes > However, the following response with M:oxc3 and (from the point of = view of > the server) retransmitting that response payload with block number 10 = does > include the Observe option. >=20 > The exception seems due to the fact that the retransmission request = from the > client is specifically what you call 'Continue' Q-Block-2 in Section = 3.4. The > Observe option is in fact not included for the previously = retransmitted response > payloads with M:0xbb ... M:0xc2, as still part of the current payload = set. [Jon] Correct, but obviously not obvious from the text. >=20 >=20 > * Section 3.6 - Part of the first sentence in the second paragraph = seems to > repeat what already said in the third paragraph of Section 3.5. >=20 [Jon] Will clean up in the simplification. ~Jon >=20 From nobody Fri Jan 15 05:58:22 2021 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 4BE313A00C9; Fri, 15 Jan 2021 05:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 TSCnfFYtpMYj; Fri, 15 Jan 2021 05:58:14 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2063.outbound.protection.outlook.com [40.107.21.63]) (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 C05883A005F; Fri, 15 Jan 2021 05:58:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mw8ds/q/Ca8dYhLZiMLx+PoXJncrTbCaCWJdMbW6EIJEWW9moeRUmPCJLrr83okvkQxr2o/bHQCC1DIhnQmNqPv3a/Ss/MoHamiu4DakBrAJjoB8MIWoi9gJAa2In6k7ClAoqRyw8ROgZfUbLe+gcpkg+Sp/kHRsDjVbBmPClKQz12+f0CpxIhu2rOM0L17MgXTJvWKCz5JFLpIFRDfcMqZRLzKSgC4WBw4B4hya10tRu1ZYcBtA1J2j9wIP1ePFZ8rdlvWBGLb8hcK2qjAqmj06mfwxn5I4NDzq50icNi8Mxct7WMuu6fgu0xbzOjMVsfuyspODvKwzJT4YfTrmLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JsbE/EWoSwbOmlGjEHkfhOFJ1xCMQBh9ePpJsS4nxn4=; b=at038UC/2n93QfGM+OEV39zeAsHbW4BdntzomFcPzdozf10/voXzjjFJxRPpAvW46w75pNSJ5W/vA6VliYZT4w0Vrx1AlLxc/2qJhu7+4sNqon5lFHODG6F1Nabr5seBd7Ny3PEJcc8fMoeX/qiq4Mp35gDJLmpuCTjVYrkK6Uzyv0yGrNHxiVkSCHGJAfjK5Y4ao6sajUKlDEkhVfNkN1AQQLNHo4hLo8IAmIYJNPD59rz6bYtKeAedFAB4pyq8GKu1xKY7NkYdBfb+Qw7bou+fhQGVNmxmU/p1vRam70dIf6ze5YPkLBXOgdWeQGiU1252c0/qvMvHRABmnqrO7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JsbE/EWoSwbOmlGjEHkfhOFJ1xCMQBh9ePpJsS4nxn4=; b=UbV9Pb2G1m83g1S1Phua2X62TbWn6ZHY0WA5/h4ORCyOnbbnFSMmKCVK9RpXjqPhFkifliTZifLL4yrdTlWXpWci1ZvcooRjO6NJPDLpoYDuBKv7IGgTckdZV+HVFqd8WIPh/Xhh2qmAEKPC6DdjV5hUWvLJLm9jBg8CnXtd11g= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0840.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10; Fri, 15 Jan 2021 13:58:10 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.012; Fri, 15 Jan 2021 13:58:10 +0000 To: supjps-ietf@jpshallow.com, mohamed.boucadair@orange.com, core@ietf.org Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <4feb5743-4193-97f1-5231-038b1838b934@ri.se> Date: Fri, 15 Jan 2021 14:57:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX" X-Originating-IP: [92.34.27.84] X-ClientProxiedBy: BL1PR13CA0411.namprd13.prod.outlook.com (2603:10b6:208:2c2::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.68] (92.34.27.84) by BL1PR13CA0411.namprd13.prod.outlook.com (2603:10b6:208:2c2::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.7 via Frontend Transport; Fri, 15 Jan 2021 13:58:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 76ae1081-b806-489e-3b92-08d8b95d97ca X-MS-TrafficTypeDiagnostic: DB8P189MB0840: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3lmUuUjqVy7cYTaSI6bOMb4ppl/4KpC+OWdNigvQHRuo+4M1EvpjkginsZQvmh/ypoSNY7N6jjupp5124G4Tazre+SruauAjuCBR0AeDXO4MRARFWFE5T1JJvBQ8aQxPFjuJqavmez+IZue/SUE2rlRfLHrZw3GRul8dWWMc6QVg91EO3W7DqztcgA10UHG0V9qQ6g0npt0jCnz2sxKx+aRvdipHG4bVkj0tKElpUB2lkySO1sC9CcJelSfVeBVVWM5oQIaVvFpDtpioj40sVwALxvSUa0WvxBRLsg33pKS+8LkTuc7xKtwW2EPMC53jCZkEUThszLLWYgyEeyUQoKUBHZ48v/qmWVfrwnQh0UDT7onuDarhD1bcoWdKfFwtjEq/Fu9y3gM1QO8UdqpVGKCMwTto3irmeNG3sp4WXM3dyknMuo/SJaKo9l2dJBmfRqNM8zMldK/rJt8/WpKEgVc8vl/2sU6k4+9iUgBm8Oh5PwMn0DdhUIKNiQH8zUpYKMIRHXeDU2suxd72PlywAVzam9Je8g3XshJ5VqM4e4GODn0thWE8e9UWjKMIvwKq X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(376002)(39850400004)(346002)(8676002)(53546011)(44832011)(4326008)(45080400002)(6486002)(66476007)(316002)(66946007)(66574015)(2906002)(6666004)(235185007)(66556008)(5660300002)(16526019)(36756003)(16576012)(956004)(86362001)(31686004)(966005)(33964004)(26005)(52116002)(478600001)(31696002)(21480400003)(8936002)(83380400001)(2616005)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ZmJSeDh3bGVJdk55YVdBTlNvOFJwWTBJVFZvQnFOUGw4Yno1M1U3NkVLYlJl?= =?utf-8?B?K3JFMml3V0E2OVFJWkxFcjlIQnpicURhRzMxUlRHZ0N1bFVxNzgxc3Q3cXlH?= =?utf-8?B?NU1pRGo3KzJ4bEkzSDBKTm9MMnNTcDc3bmVIWEpjUDJPb1dvckhaaHd1VGtn?= =?utf-8?B?YUJaTmNQR21HalZvL1hQN1pIUlg2ZFhoRDRrSUxUaHpWc1N2dW5RMndqZmsy?= =?utf-8?B?cjlzYVppNVo0ZzBERHl5UExOQjdXSGNOWjFuYjBJckdlR2Yyelpwb3BHVENR?= =?utf-8?B?dlR3Ritjam9Zc2JEbjdxUXVBbzhzenFKTVl6cUhvajVxVUFIbThsMW5wQU5Y?= =?utf-8?B?aTFtMnpsNHZUN3drV3dvK1ZXdXFzOGRuK2U5b3JCYnBhNmRkMFVnY3l5U0c0?= =?utf-8?B?NGhmbzhzNWtLUTNQajZNZ0M0MktJU3IyQk9ycEthQ2pWSTZDWjZ5SFQrSlhR?= =?utf-8?B?ajhxMXl4UmVMcjVvT2VBekZ5UnNQQktEWmY0aVJCUUxWTEQrQVN1ZlU0N25M?= =?utf-8?B?UUxGTk9pV0RzMFZoRGo2SFdPWHlpN3VkNUtqRHdMK1hIU3g0UHdseEVkeGtw?= =?utf-8?B?MldWMmc0M000SHB3Q2hEWTN0czRWeENxaHlOMEwrQW83eGhITTV1WEM3NzM2?= =?utf-8?B?TWZuQVV5MkxKaENuNzFqZjRoQWRaQXh3OTlwaEVxamgxbEdYNlFjRVgzKzRu?= =?utf-8?B?WXlsMjdwdC9BbWZtSExnWGtpT2dZVUxQLzZ2cm5sZ3FUSXpNSFpUVnZIa1NY?= =?utf-8?B?RGY2ZDVHdHNvaGN5dVFvMW9FSFlzQllZNUltdkQybTMrUHNEYndObFNyN1BZ?= =?utf-8?B?NFF2TGlhZTdkOGxoVjFGV1hqMlZ4bWJtbHRrbU1MR3kyWUc0K2RZaVJqRjBq?= =?utf-8?B?S2Rvald1MmhGNnk1Y09SL1MvREsrcXF5dENEZFBpWnJENlF6T29ZR1FjdWpz?= =?utf-8?B?VVZBeFNDdnNuMFFMd3FIbWE4dGh3ei9aMHIzaGprdmVhNDZHTXBFVXJrME5t?= =?utf-8?B?WDRtUTZ3YVhQU3VpOGYvN01XcmE5dGxJaFBXaDdtcUVETDAwelhyQTVwWTVs?= =?utf-8?B?V0drbmE4NW5qc2F2ZmEzQ09EYnZDQVlhcDFUUmw4Z1E5b1lzRzZRQXVySlRB?= =?utf-8?B?Z1RsK3FVeGIwZ2tpM25MMVRTL0NFcVluMFRxQnZKNWlSdldVY3AzbHo0ZVlO?= =?utf-8?B?alY1V0lhODduNVNWL2NxdHo5enA1dEhuMHB3QTg0YlpwNXo3VmUyZ2NWTTl3?= =?utf-8?B?bnpkTE1VUG5taWVXQjhPWlZuQ3d1WWtvMmxRK21XN3FGUExMTU83YjFDcjI5?= =?utf-8?Q?Q+ba4JHIOGQxk=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 76ae1081-b806-489e-3b92-08d8b95d97ca X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2021 13:58:10.5074 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HmRhbXH0zVTQfxUrti853mUAwI6j0yQWi/6FHoRoRt6qQty+baeT2P1+bIypSIcJ7D7gxZEFpRY2FBOFKF39jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0840 Archived-At: Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.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 Jan 2021 13:58:18 -0000 --Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX Content-Type: multipart/mixed; boundary="wUpSmJEIzsn19Uee57mQ44RnnwmCrPesO" --wUpSmJEIzsn19Uee57mQ44RnnwmCrPesO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > Thanks from this. > > So moving forward, requests for missing Q-Block2 blocks will follow Sec= tion 2.7 RFC7959 being modelled on (assuming the request was using Q-Bloc= k1) > " To continue this Block2 transfer, the client > continues to send requests similar to the requests in the Block1 > phase, but leaves out the Block1 Options and includes a Block2 > request option with non-zero NUM." > > Otherwise, please see inline which has a couple of questions. > > Regards > > Jon >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 14 January 2021 19:58 >> To: mohamed.boucadair@orange.com; core@ietf.org >> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >> >> Hi Med, >> >> Thanks for the new document version. >> >> Please, see below some comments on the latest additions, also related = to what >> Jon raised at [1]. >> >> Best, >> /Marco >> >> [1] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk-gtPQZloDT9_1E%= 2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b9= 48202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7C= Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw= iLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70hU6BuxRrzAQoZH= nZt%2B8%3D&reserved=3D0 >> >> >> * Section 3.5 - This seems to mix aspects specific to Observe, with mo= re general >> aspects applicable to requests with a payload, i.e. FETCH (with or wit= hout >> Observe), PUT, POST and PATCH/iPATCH. > [Jon] Now that we understand what needs to be done with requesting miss= ing Q-Block2 blocks, working with Observe can be simplified. > > [Jon] Requesting Observe is only valid for GET and FETCH. Hence Observ= e request/cancellation setting when using Q-Block1 is only appropriate fo= r FETCH. > > [Jon] Unfortunately, RFC8132 does not specify in which of the payloads= of as Block1 based FETCH request should contain the Observe option assu= ming observe is required (The first, the last or all of the payloads). So= , here, I believe the safest way to go is with all the payloads carry the= observe option if observe is being requested or cancelled. Thus any mis= sing payloads should be resent with the observe configured to be consiste= nt with all the other payloads. Are you happy with this? =3D=3D>MT It makes sense to me. <=3D=3D > >> What is specific of Observe is the first paragraph; and the usage of= the Observe >> option in the second and third paragraph. Anything else seems generic = and >> applicable to requests with payload, so it might be moved up to some e= arlier >> section. >> > [Jon] Sure - will be updated in the simplification tidy up. >> * Section 3.5 - In the third paragraph, I'm not sure you necessarily n= eed a >> payload to be present in the requests asking for missing response payl= oads. For >> instance, consider: > [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 and= payload are not included. >> - The examples in Figure 10 and Figure 11 of RFC 7959, with the note= "(no >> payload for requests with Block2 with NUM !=3D 0)" , during the phase = where the >> client consecutively asks for the next response payload. >> >> - The examples in Figure 2 and Figure 3 of [2], where each request f= or the next >> response payload using Block2 has no payload of its own. >> >> This would of course affect the example in Figure 15. > [Jon] Yes, will be updated. >> [2] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est-18&data=3D04%7C01%7= Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb41= 3a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CTWFpbGZsb3d8e= yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7O7%2BQ%3D&re= served=3D0 >> >> >> * Section 3.5 - About the last sentence regarding the Observe option, = there >> seems to be an exception to this rule (at least based on the later exa= mples), >> where the server actually does include the Observe option in the respo= nse. > [Jon] If the Observe option is just included with the first payload (NU= M =3D 0) as RFC7959, there is a recovery special case should the first pa= yload not arrive, but subsequent ones do. In the general case, blocks th= at are missing are re-requested by the client and the server responds wit= h the appropriate block, but without the Observe option. For the special = case when the client requests missing payload with NUM =3D 0 the server n= eeds to know that it must include the Observe in the response so that the= client following the body re-assembly knows that it is a Observe trigger= ed additional response. > > [Jon] I had gone with the Observe should be in all the payloads in the = response apart from specifically re-requested blocks (including NUM =3D 0= ). The 'Continue' Q-Block2 was just to indicate a continue so the server= can send the remaining payloads without delay - hence why remaining payl= oads had Observe set. =20 > > [Jon] I am beginning to lean to having it in the first payload and spec= ial case the response to re-request of NUM =3D 0. What do you think? =3D=3D>MT Ok, I didn't think also of the case for NUM =3D 0, but that makes sense t= oo. Then it's certainly something better to clarify in the main text and also to show/comment in the example of Figure 10. <=3D=3D > >> That is, consider the example in Figure 10, where the response with= M:0xba is >> lost. Later on, the client asks for that response payload by sending t= he request >> with M:0x87, which correctly does not include the Observe option. >> > [Jon] Yes >> However, the following response with M:oxc3 and (from the point of = view of >> the server) retransmitting that response payload with block number 10 = does >> include the Observe option. >> >> The exception seems due to the fact that the retransmission request= from the >> client is specifically what you call 'Continue' Q-Block-2 in Section 3= =2E4. The >> Observe option is in fact not included for the previously retransmitte= d response >> payloads with M:0xbb ... M:0xc2, as still part of the current payload = set. > [Jon] Correct, but obviously not obvious from the text. =3D=3D>MT Right, I mostly focused on that. I think it's worth clarifying in the main text what the normal case is for the server (client) to include (expect) the Observe option in a response payload; and then highlight the exceptions for the re-request with NUM=3D0 (see above) and for the 'Continue' Q-Block2. Best, /Marco <=3D=3D >> >> * Section 3.6 - Part of the first sentence in the second paragraph see= ms to >> repeat what already said in the third paragraph of Section 3.5. >> > [Jon] Will clean up in the simplification. > ~Jon --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --wUpSmJEIzsn19Uee57mQ44RnnwmCrPesO-- --Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmABn2YACgkQ7iZktA5Y 2kO1Sgf+MXtZ0/eUcU8GCt0bA2wHCNka5/4yV6o4iU9Hh9AW0EldPaW7adsRoSvO yldlSvDFLZmsu8yWtkJkJx6G9l5EMdULFPkTUYzRekQwDPo9ywjm/JPAhT43WjP6 FhSgLttuCNqUi1CyUJ9hDN0Ym72nP0YmyaXAjXfZHlvO1wQQ9N4IItv99IeDAtQT T4S+Dkzy7y6A9/2dRXR7u2IMPY12TRSYEXvStgiR9K2rEERzM3rj8lUtbNpR+prr sP5ONyGJ9WcrVlXci9ZuciQSRUaXhkYDQlfeYIaRT2wBJQ2s4n+RJbW6N2dNoHlH +0exSSZ/nrtGSZAe0CSfEbkw2WNNHA== =8qpT -----END PGP SIGNATURE----- --Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX-- From nobody Sun Jan 17 22:29:50 2021 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 E6FD83A109E; Sun, 17 Jan 2021 22:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, 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 k2WcXOWsNesM; Sun, 17 Jan 2021 22:29:47 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id C802C3A109D; Sun, 17 Jan 2021 22:29:46 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 4BDFB25F6C3; Mon, 18 Jan 2021 15:29:44 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1610951384; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+1oW8t0CoqfzscS57xm1ObIV6BWQTqnrBJBoJP5ullA=; b=pdX8xb/GivYzBphpIYKVthdLSAUKn7YNMYybFmAgliqjQw/0K/xXHSe/8tofn5/AkVRJLN dsN18ca3axCeNFZbhk1y2xWnkabr9+rsfaTBvvEFv31tFE2QbDYwjjiQjNScZt0ouHPWOx VYp/M2vR2tpmPoLNPudyfeK/ubFR4ao= Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id D6DFB7633F8; Mon, 18 Jan 2021 15:29:43 +0900 (JST) To: supjps-ietf@jpshallow.com, Valery Smyslov , draft-ietf-dots-telemetry@ietf.org Cc: dots-chairs@ietf.org, dots@ietf.org References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> <069401d6e816$36edb180$a4c91480$@jpshallow.com> From: kaname nishizuka Message-ID: Date: Mon, 18 Jan 2021 15:29:43 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <069401d6e816$36edb180$a4c91480$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 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 Jan 2021 06:29:49 -0000 Hi Valery, I don't have any IPR, or know of any related to this draft. The implementation status of go-dots is exactly as Jon said. thanks, Kaname On 2021/01/11 21:35, supjps-ietf@jpshallow.com wrote: > Hi Valery, > > I do not hold, or know of any IPR associated with this draft. > > Both go-dots and my proprietary implementations have implemented this draft. > > Regards > > Jon > >> -----Original Message----- >> From: Valery Smyslov [mailto: valery@smyslov.net] >> Sent: 11 January 2021 12:19 >> To: draft-ietf-dots-telemetry@ietf.org >> Cc: dots-chairs@ietf.org; dots@ietf.org >> Subject: IPR confirmation for draft-ietf-dots-telemetry-15 >> >> Hi authors, >> >> while preparing shepherd write-up for draft-ietf-dots-telemetry-15, >> in accordance with BCP78 and BCP79 I have to ask all authors and >> contributors whether >> they are aware of any IPR regarding this document. >> Can you please confirm that you are not aware of any IPR >> or disclose any IPR you are aware of that are concerned with this draft. >> >> I'd also like to ask authors about implementation status of the draft. >> Are there any implementations you are aware of? >> >> Regards, >> Valery. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Jan 18 06:16:14 2021 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 78F083A1367 for ; Mon, 18 Jan 2021 06:16:12 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk0tNQz1ixDE for ; Mon, 18 Jan 2021 06:16:10 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 07AF63A1311 for ; Mon, 18 Jan 2021 06:16:09 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1l1VKA-0005K0-UZ; Mon, 18 Jan 2021 14:16:07 +0000 From: To: "Marco Tiloca" , , Cc: , References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> In-Reply-To: <4feb5743-4193-97f1-5231-038b1838b934@ri.se> Date: Mon, 18 Jan 2021 14:16:23 -0000 Message-ID: <033b01d6eda4$8013a980$803afc80$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINhJL1nc88GwsEKn+AjV1kVr7Y4AGmsrCNATjbvioB8R1SgQKCeaN3qYWl4aA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.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 Jan 2021 14:16:13 -0000 Hi Marco, We have updated github [1] to take account of your latest comments for = your review. Regards Jon [1]https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dh= ttps://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core= -new-block.txt > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 15 January 2021 13:58 > To: jon@jpshallow.com; mohamed.boucadair@orange.com; core@ietf.org > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >=20 > Hi Jon, >=20 > On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: > > Hi Marco, > > > > Thanks from this. > > > > So moving forward, requests for missing Q-Block2 blocks will follow > > Section 2.7 RFC7959 being modelled on (assuming the request was = using Q- > Block1) " To continue this Block2 transfer, the client > > continues to send requests similar to the requests in the Block1 > > phase, but leaves out the Block1 Options and includes a Block2 > > request option with non-zero NUM." > > > > Otherwise, please see inline which has a couple of questions. > > > > Regards > > > > Jon > >> -----Original Message----- > >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] > >> Sent: 14 January 2021 19:58 > >> To: mohamed.boucadair@orange.com; core@ietf.org > >> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org > >> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt > >> > >> Hi Med, > >> > >> Thanks for the new document version. > >> > >> Please, see below some comments on the latest additions, also = related > >> to what Jon raised at [1]. > >> > >> Best, > >> /Marco > >> > >> [1] > >> = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmai > >> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk- > gtPQZloDT9_1E%2 > >> > F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d > 8b > >> > 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674 > 04024 > >> > 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTi > >> > I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70 > hU6 > >> BuxRrzAQoZHnZt%2B8%3D&reserved=3D0 > >> > >> > >> * Section 3.5 - This seems to mix aspects specific to Observe, with > >> more general aspects applicable to requests with a payload, i.e. > >> FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. > > [Jon] Now that we understand what needs to be done with requesting = missing > Q-Block2 blocks, working with Observe can be simplified. > > > > [Jon] Requesting Observe is only valid for GET and FETCH. Hence = Observe > request/cancellation setting when using Q-Block1 is only appropriate = for FETCH. > > > > [Jon] Unfortunately, RFC8132 does not specify in which of the = payloads of as > Block1 based FETCH request should contain the Observe option assuming > observe is required (The first, the last or all of the payloads). So, = here, I believe > the safest way to go is with all the payloads carry the observe option = if observe > is being requested or cancelled. Thus any missing payloads should be = resent with > the observe configured to be consistent with all the other payloads. = Are you > happy with this? >=20 > =3D=3D>MT > It makes sense to me. > <=3D=3D >=20 > > > >> What is specific of Observe is the first paragraph; and the usage > >> of the Observe option in the second and third paragraph. Anything > >> else seems generic and applicable to requests with payload, so it > >> might be moved up to some earlier section. > >> > > [Jon] Sure - will be updated in the simplification tidy up. > >> * Section 3.5 - In the third paragraph, I'm not sure you = necessarily > >> need a payload to be present in the requests asking for missing > >> response payloads. For instance, consider: > > [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 = and > payload are not included. > >> - The examples in Figure 10 and Figure 11 of RFC 7959, with the > >> note "(no payload for requests with Block2 with NUM !=3D 0)" , = during > >> the phase where the client consecutively asks for the next response = payload. > >> > >> - The examples in Figure 2 and Figure 3 of [2], where each = request > >> for the next response payload using Block2 has no payload of its = own. > >> > >> This would of course affect the example in Figure 15. > > [Jon] Yes, will be updated. > >> [2] > >> = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo > >> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est- > 18&data=3D04%7C01%7Cma > >> > rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb > 4 > >> > 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT > WFpbGZs > >> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3 > >> > D%7C1000&sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7 > O7%2B > >> Q%3D&reserved=3D0 > >> > >> > >> * Section 3.5 - About the last sentence regarding the Observe = option, > >> there seems to be an exception to this rule (at least based on the > >> later examples), where the server actually does include the Observe = option in > the response. > > [Jon] If the Observe option is just included with the first payload = (NUM =3D 0) as > RFC7959, there is a recovery special case should the first payload not = arrive, but > subsequent ones do. In the general case, blocks that are missing are = re- > requested by the client and the server responds with the appropriate = block, but > without the Observe option. For the special case when the client = requests > missing payload with NUM =3D 0 the server needs to know that it must = include the > Observe in the response so that the client following the body = re-assembly knows > that it is a Observe triggered additional response. > > > > [Jon] I had gone with the Observe should be in all the payloads in = the response > apart from specifically re-requested blocks (including NUM =3D 0). = The 'Continue' > Q-Block2 was just to indicate a continue so the server can send the = remaining > payloads without delay - hence why remaining payloads had Observe set. > > > > [Jon] I am beginning to lean to having it in the first payload and = special case > the response to re-request of NUM =3D 0. What do you think? >=20 > =3D=3D>MT > Ok, I didn't think also of the case for NUM =3D 0, but that makes = sense too. >=20 > Then it's certainly something better to clarify in the main text and = also to > show/comment in the example of Figure 10. > <=3D=3D >=20 > > > >> That is, consider the example in Figure 10, where the response > >> with M:0xba is lost. Later on, the client asks for that response > >> payload by sending the request with M:0x87, which correctly does = not include > the Observe option. > >> > > [Jon] Yes > >> However, the following response with M:oxc3 and (from the point = of > >> view of the server) retransmitting that response payload with block > >> number 10 does include the Observe option. > >> > >> The exception seems due to the fact that the retransmission > >> request from the client is specifically what you call 'Continue' > >> Q-Block-2 in Section 3.4. The Observe option is in fact not = included > >> for the previously retransmitted response payloads with M:0xbb ... = M:0xc2, > as still part of the current payload set. > > [Jon] Correct, but obviously not obvious from the text. >=20 > =3D=3D>MT > Right, I mostly focused on that. >=20 > I think it's worth clarifying in the main text what the normal case is = for the server > (client) to include (expect) the Observe option in a response payload; = and then > highlight the exceptions for the re-request with NUM=3D0 (see above) = and for the > 'Continue' Q-Block2. >=20 > Best, > /Marco > <=3D=3D >=20 > >> > >> * Section 3.6 - Part of the first sentence in the second paragraph > >> seems to repeat what already said in the third paragraph of Section = 3.5. > >> > > [Jon] Will clean up in the simplification. > > ~Jon >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Tue Jan 19 03:50:36 2021 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 834683A147B; Tue, 19 Jan 2021 03:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 W_A_w4YigIZQ; Tue, 19 Jan 2021 03:50:30 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 DE4C63A1479; Tue, 19 Jan 2021 03:50:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZUeiHvxfrDraXKzg5H+4KuQgGL7rRTjdEgilvKdHl2mBG1Eae8Q59LflnpxKFJ5YKPREhy3X7iAPUd3OEAEl8DXrLVLK1UFGR01XfbdWFY8/Ykun+5DJ/dh7UapPxDpWFMfkbNM45/lLQdk26i/UWl8Be0Ebt3iOqTnGjSjgKK3K3Zv5hQpv+8Lt48ooMAV2OWhVKjFcaEOcec3xv90Ynfjid4UD6uBBT1D6+qTyboEn+IVoXntQQJqwo3B/vPKjPSaBN6jBXskPEMzS3ic4t0LsekV753/F5hUMOHycBGusPqG9KgbO56izw3ZwTIDwgVWc54tYv8/gXiTVDxgTuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mx9sNUqorWwCfXMhg7RmeUZaqXxbJJ/c+5LUG7sCH4Y=; b=W4s3k3oBbFk58VFRc9ACsuHrTpPjXpe5dBWJfl1Au3gFCvF1D8FrwmogHo4fO88IgRVg+1TyusASCoYGakroOLVpAgm+Io66khrohG7MHI0PfEsHWDLdXdKQNj8U+LKRKnKvZ6oM7Y86/9xKZHKRbuoXgiBOdELK8s/u9nqJ1kyb+ySjaK62zYFOG2GQXaexZhaL/+Y7Zo0XkmDwe5NPLu/K3kp16vItuQRmp+wecrw1Usenl+oKrtRpfvHygd95OPAkeWhxQvStd4UY4M1E9QdN7M//IuD6PYfBMSumzU9a1UUwhJZTBz30jsKgKcZt8xIO4gq/MlKDXJ5VgzFo6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mx9sNUqorWwCfXMhg7RmeUZaqXxbJJ/c+5LUG7sCH4Y=; b=ZuRA+79a9emH/FPLDcj4u/dbPt5/DF58a035+/zeMhrLpJYPVvPpj+0Eyu+8w3oLGPnd5MsfpRFoA7v1CQMwDq2ilB7udov0RxKNw9Haf8Bd08+KEZbtyFV02563wL9enn3thXVjxESsQJHt87ntWhtuDCE3rsLHJodNtwOQzG4= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0135.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:26::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Tue, 19 Jan 2021 11:50:26 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 11:50:26 +0000 To: supjps-ietf@jpshallow.com, mohamed.boucadair@orange.com, core@ietf.org Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> Date: Tue, 19 Jan 2021 12:50:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <033b01d6eda4$8013a980$803afc80$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO" X-Originating-IP: [37.120.209.212] X-ClientProxiedBy: HE1PR1001CA0003.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::13) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.7] (37.120.209.212) by HE1PR1001CA0003.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10 via Frontend Transport; Tue, 19 Jan 2021 11:50:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 977831cd-f3b8-4318-e8b9-08d8bc70694d X-MS-TrafficTypeDiagnostic: DB6P18901MB0135: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oIGW6v3Aa6L4SzkIvDO4n6x2YTLRB3cLOxVWWfsgRmq4FUciL4mTX3D3cNb33j9HTpPkwuQpyrY0W3eyMc29IdKemmp4fCDwZVA2AoIp8dQ3IKY1MwkS9SvBL/TJ9NBz4v+Je66Of1n0pXnKZxqUAJMwhVykY3Wn50ZBt+3ZWd9b26ig9S5/JISA5aXcyUX3avpTSSd/9kzojHqMtR/7GnhaAroYSQw01VcgtZ82SXHJBRg+LTMhXexWzRXMoV/wlEpKC4MPl2NMoGyG7A/ltlsL9WZ1tUDzadrX9BtIEjn0S0qgZqcHqD98eYOayBjyzzQ2LtqB6G0eq2CXRtPK4mrMLeD+sAJSgVEVuUMysRNBxdJfDKQfOTIRBSbrHNZt49ogGyCAImUUm8hZHZCW4i2bHHCqzDszJh9vA5tT3+e8XIfurC/shTaJfUnVEM7ORBr+xwjVa+k1J4+uX8z3AR7mS+VuCuU0GPFOQs08I6dqtiJ8mdw3VU3P2xOmGdcW2EpFNl+SUQQFYwfizAqCw195q9E/jtSfMQ5kLVTtd64VnGZm+OmRWIjzUg3jjAi+tW/0XCDbwWxG7WxxbMXY6y7XD23t+7n8BcgbqRCEBsqrj7W4BlqLMu6nxgl0ijuYt1MxfUV7EoWUIeYPX9l9SrM9ntO0gG1ID+rXqq4GD3UJCmAGJ4gAupOVW2VCUOM7 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(376002)(396003)(366004)(136003)(66574015)(30864003)(5660300002)(235185007)(16526019)(2906002)(6666004)(186003)(83380400001)(36756003)(86362001)(8676002)(53546011)(26005)(8936002)(45080400002)(44832011)(4326008)(31696002)(31686004)(956004)(966005)(52116002)(66556008)(66476007)(33964004)(478600001)(66946007)(21480400003)(6486002)(316002)(16576012)(2616005)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bjkxcDlSZFk4Q3NBbmtLYzI3Tzg5N1JudzFDNmJSUnFENFIrTFVZRFJpcFht?= =?utf-8?B?eDB1Yis0WVMyRm5ranBlMWhXMUpYRFlwVnBhajF2YiszakVOSnFWUDM5dkhy?= =?utf-8?B?b3BvaGtiTVJYTWhuTkxwa2NTTjkzK3dncmpwVW1UbGdOY2ZMTmxrRnhBUzh6?= =?utf-8?B?WHdPZytDWWhHUVJKSnhiUjdka09tT2R1dTFLcTFOMXV1K0FJZi9EK3lPS3Zn?= =?utf-8?B?NnNEbnFlR1Y1elBlTFBnL1N1ZjRFMXNNZUpwdUtxcmNSNFpWNkRySGoxRHdH?= =?utf-8?B?RGMzOXFCbnVGd2xNdmsxemxDTHRkWVMvNHlucFlCaDNlMzljcG5JWS9GbHl4?= =?utf-8?B?d0piOFg1WEkzaE5HNkY0T3NGWTJwUENkTmJObmZVRE85R3U4ZkxmV0t5a3By?= =?utf-8?B?OFEyQ1lZa0FSVnFLeTIzSWZuQnVqaHNVK3FVSkw0aTBGZGpHaC80MVhoWGN3?= =?utf-8?B?VEh0ZjBTRzIwMXI1eGJUV3RHTW5aazNOWGJ5d0JwM0t5SDZ2UGxKQXdRaWwz?= =?utf-8?B?aDlzaGFSS0IxZFdYL3VsNnkvREJQcE5wYllVUExLc0lLbllqUDFVNFJQYmJq?= =?utf-8?B?QjhCMlNTdjAwVlBpSW90Q0RNeGJMZkVvRng3cFFHRVZYdlVQdTZCajRKUm5z?= =?utf-8?B?cDJOT1VsQXJBaS8wQWM4REZ3SXJVajVvQkV1aElzMmIzTVFkeGFkRGtKdkQx?= =?utf-8?B?UUIwclM2SUJVdDYwRTFzT0E4cnExZEVGWFducnZYZHdzcUhobUdVaWtwY0tC?= =?utf-8?B?ME5LYXlNNFAyTGlUQy9nck5STGVqcEl4NVl0MzlxUlY5OUE1TFJhakM0ZGJo?= =?utf-8?B?L0ZUWUJFeVhJKzBpUmQvVmVFRzNEaWVoM3lPbForQS84Y2VJdjdMTE4yL1RL?= =?utf-8?B?R3MzWTZNU1lneUJyQUpqY3dGajVkWVJXTmJMZmZsN1l0enhWMWRnZ2FZQ2F2?= =?utf-8?B?dnF2cUdCdjdYcWZNSTY5NFRLZnJRUWIrajhxSy9GWkJMSURtMHF2OUpXUFlm?= =?utf-8?B?NEYvenpQaGpRd25YQVV6RnE4dGEvOG8wS0V4SHNFSm5WbWNLWkRIRURYeHFs?= =?utf-8?B?MTJVVEhoY2pSdmFzY1JPMkg1TnlpUlJqUWZ4Uk1FZWQxOTE1UjZDOUloTWZy?= =?utf-8?B?bitoR2l4aW5jWVd0UVVQV0xtY25GdUNNSVRLeEhaTlNnVWtldnZVUWJHMm56?= =?utf-8?B?YldoR0NlUzRML0NqNDl5NFJaMWh4RkZZaHltWnBFd2lIdjRQQW1lMm9LZHFJ?= =?utf-8?B?c1FvcFlicUlQSDdZMmhqeWVKNXdSckZUd00vOFJ6Mm85QWVzSDVKdHZLMzJu?= =?utf-8?B?ZUhGU3VoZVBrOFNIalIvSkhXdFBTS0wvcUJrN1BBRVlzdm9aOFpqdFg0Z0lZ?= =?utf-8?B?eHo0VDljRDVJR1QrUXllUVhtRFRybWwwbHdBUjlUazhJaU9WbG4ycFdTaXpS?= =?utf-8?B?SGY0MkRZeTVmOEdIR1RNa2QySFVlSE53NzI2VE1nPT0=?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 977831cd-f3b8-4318-e8b9-08d8bc70694d X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 11:50:26.3650 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zEf4i4Ye5ObjJgXoxHHEkHMu7NwI6WPxwRfS+lGzq0rh4uxECyA468hwdppIETibvGdPibZq0+nuFncMUqnJlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0135 Archived-At: Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.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 Jan 2021 11:50:35 -0000 --jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO Content-Type: multipart/mixed; boundary="JdrJAfKLJ5abR0X1dLmV51vh0hqLli0WH" --JdrJAfKLJ5abR0X1dLmV51vh0hqLli0WH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks, please see below some minor points, otherwise it looks good to me= =2E Best, /Marco * Section 3.1 - In the paragraph right above Table 2, s/with CoAP over TCP/with CoAP over reliable transports. * Section 3.1 - I think that the new final paragraph "Note that if Q-Block1 (or Q-Block2) ... MUST NOT be included." fits better before the paragraph discussing the use of OSCORE, i.e. "The Q-Block1 and ... fragmentation of requests." * Section 3.3 - "For Non-confirmable transmission, no response is required until the successful receipt of the body by the server or some of the payloads have not arrived after a timeout and a retransmit missing payloads response is needed." =C2=A0=C2=A0 Shouldn't this also mention the case where the server sends = a 2.31 response to have the client continue sending the next MAX_PAYLOADS payloa= ds? * Section 3.3 - Proposed clarification for the 4.02 response code: =C2=A0=C2=A0=C2=A0 "Either this Response Code (in case of Confirmable req= uest) or a reset message (in case of Non-confirmable request) MUST be returned if the server does not support the Q-Block1 Option." On 2021-01-18 15:16, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > We have updated github [1] to take account of your latest comments for = your review. > > Regards > > Jon > > > [1]https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%= 3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-= ietf-core-new-block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C98040= 4e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C= 637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DuGB%2BGu0PztRvMh4= hUFutHMItkR5AJXCJqpt440nphj4%3D&reserved=3D0 > > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 15 January 2021 13:58 >> To: jon@jpshallow.com; mohamed.boucadair@orange.com; core@ietf.org >> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >> >> Hi Jon, >> >> On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> Thanks from this. >>> >>> So moving forward, requests for missing Q-Block2 blocks will follow >>> Section 2.7 RFC7959 being modelled on (assuming the request was using= Q- >> Block1) " To continue this Block2 transfer, the client >>> continues to send requests similar to the requests in the Block1 >>> phase, but leaves out the Block1 Options and includes a Block2 >>> request option with non-zero NUM." >>> >>> Otherwise, please see inline which has a couple of questions. >>> >>> Regards >>> >>> Jon >>>> -----Original Message----- >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>> Sent: 14 January 2021 19:58 >>>> To: mohamed.boucadair@orange.com; core@ietf.org >>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >>>> >>>> Hi Med, >>>> >>>> Thanks for the new document version. >>>> >>>> Please, see below some comments on the latest additions, also relate= d >>>> to what Jon raised at [1]. >>>> >>>> Best, >>>> /Marco >>>> >>>> [1] >>>> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= mai >>>> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk- >> gtPQZloDT9_1E%2 >> F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d >> 8b >> 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674 >> 04024 >> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL >> CJBTi >> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70 >> hU6 >>>> BuxRrzAQoZHnZt%2B8%3D&reserved=3D0 >>>> >>>> >>>> * Section 3.5 - This seems to mix aspects specific to Observe, with >>>> more general aspects applicable to requests with a payload, i.e. >>>> FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. >>> [Jon] Now that we understand what needs to be done with requesting mi= ssing >> Q-Block2 blocks, working with Observe can be simplified. >>> [Jon] Requesting Observe is only valid for GET and FETCH. Hence Obse= rve >> request/cancellation setting when using Q-Block1 is only appropriate f= or FETCH. >>> [Jon] Unfortunately, RFC8132 does not specify in which of the payloa= ds of as >> Block1 based FETCH request should contain the Observe option assuming= >> observe is required (The first, the last or all of the payloads). So, = here, I believe >> the safest way to go is with all the payloads carry the observe option= if observe >> is being requested or cancelled. Thus any missing payloads should be = resent with >> the observe configured to be consistent with all the other payloads. A= re you >> happy with this? >> >> =3D=3D>MT >> It makes sense to me. >> <=3D=3D >> >>>> What is specific of Observe is the first paragraph; and the usage >>>> of the Observe option in the second and third paragraph. Anything >>>> else seems generic and applicable to requests with payload, so it >>>> might be moved up to some earlier section. >>>> >>> [Jon] Sure - will be updated in the simplification tidy up. >>>> * Section 3.5 - In the third paragraph, I'm not sure you necessarily= >>>> need a payload to be present in the requests asking for missing >>>> response payloads. For instance, consider: >>> [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 a= nd >> payload are not included. >>>> - The examples in Figure 10 and Figure 11 of RFC 7959, with the >>>> note "(no payload for requests with Block2 with NUM !=3D 0)" , durin= g >>>> the phase where the client consecutively asks for the next response = payload. >>>> >>>> - The examples in Figure 2 and Figure 3 of [2], where each request= >>>> for the next response payload using Block2 has no payload of its own= =2E >>>> >>>> This would of course affect the example in Figure 15. >>> [Jon] Yes, will be updated. >>>> [2] >>>> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= too >>>> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est- >> 18&data=3D04%7C01%7Cma >> rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb >> 4 >> 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT >> WFpbGZs >> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3 >> D%7C1000&sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7 >> O7%2B >>>> Q%3D&reserved=3D0 >>>> >>>> >>>> * Section 3.5 - About the last sentence regarding the Observe option= , >>>> there seems to be an exception to this rule (at least based on the >>>> later examples), where the server actually does include the Observe = option in >> the response. >>> [Jon] If the Observe option is just included with the first payload (= NUM =3D 0) as >> RFC7959, there is a recovery special case should the first payload not= arrive, but >> subsequent ones do. In the general case, blocks that are missing are = re- >> requested by the client and the server responds with the appropriate b= lock, but >> without the Observe option. For the special case when the client reque= sts >> missing payload with NUM =3D 0 the server needs to know that it must i= nclude the >> Observe in the response so that the client following the body re-assem= bly knows >> that it is a Observe triggered additional response. >>> [Jon] I had gone with the Observe should be in all the payloads in th= e response >> apart from specifically re-requested blocks (including NUM =3D 0). Th= e 'Continue' >> Q-Block2 was just to indicate a continue so the server can send the re= maining >> payloads without delay - hence why remaining payloads had Observe set.= >>> [Jon] I am beginning to lean to having it in the first payload and sp= ecial case >> the response to re-request of NUM =3D 0. What do you think? >> >> =3D=3D>MT >> Ok, I didn't think also of the case for NUM =3D 0, but that makes sens= e too. >> >> Then it's certainly something better to clarify in the main text and a= lso to >> show/comment in the example of Figure 10. >> <=3D=3D >> >>>> That is, consider the example in Figure 10, where the response >>>> with M:0xba is lost. Later on, the client asks for that response >>>> payload by sending the request with M:0x87, which correctly does not= include >> the Observe option. >>> [Jon] Yes >>>> However, the following response with M:oxc3 and (from the point o= f >>>> view of the server) retransmitting that response payload with block >>>> number 10 does include the Observe option. >>>> >>>> The exception seems due to the fact that the retransmission >>>> request from the client is specifically what you call 'Continue' >>>> Q-Block-2 in Section 3.4. The Observe option is in fact not included= >>>> for the previously retransmitted response payloads with M:0xbb ... M= :0xc2, >> as still part of the current payload set. >>> [Jon] Correct, but obviously not obvious from the text. >> =3D=3D>MT >> Right, I mostly focused on that. >> >> I think it's worth clarifying in the main text what the normal case is= for the server >> (client) to include (expect) the Observe option in a response payload;= and then >> highlight the exceptions for the re-request with NUM=3D0 (see above) a= nd for the >> 'Continue' Q-Block2. >> >> Best, >> /Marco >> <=3D=3D >> >>>> * Section 3.6 - Part of the first sentence in the second paragraph >>>> seems to repeat what already said in the third paragraph of Section = 3.5. >>>> >>> [Jon] Will clean up in the simplification. >>> ~Jon >> -- >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d6a= 2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374657617387= 75081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DLE%2FKQOOUq5aEBbgVRdtqmLiOz8n%= 2Bt60OuEYgM%2FwCrJg%3D&reserved=3D0 >> > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --JdrJAfKLJ5abR0X1dLmV51vh0hqLli0WH-- --jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAGx3gACgkQ7iZktA5Y 2kNSYQgAswuS3zzIR3mg0uEOtzmWqszybfRwO/BCoXpYVxjShyX69Y1SRl+uo5XL 5aDNxGa21LUiYfrqw1yRYtq+ApkKhJMSqBe6B2cH6U2V3I4/58CtCCBNvjb25+vk y2q7NWI4ttLHXZRow3yl9XnGzjPqiX8IfuHCOvaY2IUGuAKGw2/jR4o5b1GBDOKb 2qHoK/hCWBZrn5XZrPllr7cXvgVaAZpe3EakgvmVjeMefns1gxpkX673fCuuVW1W UrVIHJFFCI05mY03CLynkOTjJgYaOFnztXLGRkUsrfIDbSKvqul/dMXUHAioHyL7 xL1jaVeN/WPoWfcAyN7BP3XtYohmTw== =ChkD -----END PGP SIGNATURE----- --jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO-- From nobody Tue Jan 19 04:24:08 2021 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 216E03A1425; Tue, 19 Jan 2021 04:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 OtBSPhGlk86Z; Tue, 19 Jan 2021 04:24:05 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 A4A463A140E; Tue, 19 Jan 2021 04:24:04 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DKnrf2CT1z103D; Tue, 19 Jan 2021 13:24:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1611059042; bh=BokdKAvqhyOGTAWvuYhGZqIUBTpW1/tCK8NcPA10z0E=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=p2ksKPB+iJmwhWO9Ppmx5ppWPpHFx7MLeGAlEvgh8E0Sdq4Zbk/xyp7cXOKDNCnTK VyXILmjytTGYemhdA1o89KtbTUndjEdCOV6OxBd/WUCuQsrWpYBGJ9Z/yLxBr69CXD nQogAM4Qt4K/KFZ8xRqpG6k0VyjD890MhntN4dlZihgooP4hr4czNUmBewuz01PeoU 7ROOw0KJgabQT2cZy2ICI10wErwap1ArnWQWAVACH0MdkD3KN9BJn0E4ivvwv/Y1Td Q5OazPC4gi8NNN9y2PcSJif3zmYGrvhdyebJ8RGjRI0h0SITJheb1n8PltIJCw9MuC 0yRourc36wIvw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4DKnrf1MVDz1xpr; Tue, 19 Jan 2021 13:24:02 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-new-block-05.txt Thread-Index: AQHW7llKlYyGci3BiUKLfs7WuizUBKou3GxA Date: Tue, 19 Jan 2021 12:24:01 +0000 Message-ID: <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> In-Reply-To: <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> 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] [core] I-D Action: draft-ietf-core-new-block-05.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 Jan 2021 12:24:07 -0000 SGkgTWFyY28sIA0KDQpUaGUgcHJvcG9zZWQgZWRpdHMgbG9vayBnb29kIHRvIG1lLiBXaWxsIGJl IGZpeGVkIGluIHRoZSBnaXRodWIuIA0KDQoyLjMxIGlzIG5vdCBtZW50aW9uZWQgaW4gaW4gdGhl IGV4Y2VycHQgeW91IHF1b3RlZCBmcm9tIFNlY3Rpb24gMy4zIGJlY2F1c2UgMi4zMSBpcyBub3Qg KipyZXF1aXJlZCoqLiBBIHNlcnZlciBtYXkgZGVjaWRlIHRvIG5vdCByZXBseSB3aXRoIDIuMzEg YXMgYSBmdW5jdGlvbiBvZiBpdHMgb3ZlcmFsbCBsb2FkIGFuZCBwcmVmZXIgdG8gb2JzZXJ2ZSBh IHBhdXNlIGJlZm9yZSBoYW5kbGluZyB0aGUgbmV4dCBibG9jay4gVGhhdOKAmXMgaXMgd2h5IHdl IGRvIGhhdmUgU0hPVUxELCBub3QgYSBNVVNULiAgICANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1hcmNvIFRpbG9jYSBbbWFpbHRvOm1h cmNvLnRpbG9jYUByaS5zZV0NCj4gRW52b3nDqcKgOiBtYXJkaSAxOSBqYW52aWVyIDIwMjEgMTI6 NTANCj4gw4DCoDogc3VwanBzLWlldGZAanBzaGFsbG93LmNvbTsgQk9VQ0FEQUlSIE1vaGFtZWQg VEdJL09MTg0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGNvcmVAaWV0Zi5vcmcN Cj4gQ2PCoDogZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgZG90c0BpZXRmLm9y Zw0KPiBPYmpldMKgOiBSZTogW2NvcmVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXct YmxvY2stMDUudHh0DQo+IA0KPiBIaSBKb24sDQo+IA0KPiBUaGFua3MsIHBsZWFzZSBzZWUgYmVs b3cgc29tZSBtaW5vciBwb2ludHMsIG90aGVyd2lzZSBpdCBsb29rcyBnb29kDQo+IHRvIG1lLg0K PiANCj4gQmVzdCwNCj4gL01hcmNvDQo+IA0KPiAqIFNlY3Rpb24gMy4xIC0gSW4gdGhlIHBhcmFn cmFwaCByaWdodCBhYm92ZSBUYWJsZSAyLCBzL3dpdGggQ29BUA0KPiBvdmVyIFRDUC93aXRoIENv QVAgb3ZlciByZWxpYWJsZSB0cmFuc3BvcnRzLg0KPiANCj4gKiBTZWN0aW9uIDMuMSAtIEkgdGhp bmsgdGhhdCB0aGUgbmV3IGZpbmFsIHBhcmFncmFwaCAiTm90ZSB0aGF0IGlmDQo+IFEtQmxvY2sx IChvciBRLUJsb2NrMikgLi4uIE1VU1QgTk9UIGJlIGluY2x1ZGVkLiIgZml0cyBiZXR0ZXIgYmVm b3JlDQo+IHRoZSBwYXJhZ3JhcGggZGlzY3Vzc2luZyB0aGUgdXNlIG9mIE9TQ09SRSwgaS5lLiAi VGhlIFEtQmxvY2sxIGFuZA0KPiAuLi4NCj4gZnJhZ21lbnRhdGlvbiBvZiByZXF1ZXN0cy4iDQo+ IA0KPiAqIFNlY3Rpb24gMy4zIC0gIkZvciBOb24tY29uZmlybWFibGUgdHJhbnNtaXNzaW9uLCBu byByZXNwb25zZSBpcw0KPiByZXF1aXJlZCB1bnRpbCB0aGUgc3VjY2Vzc2Z1bCByZWNlaXB0IG9m IHRoZSBib2R5IGJ5IHRoZSBzZXJ2ZXIgb3INCj4gc29tZSBvZiB0aGUgcGF5bG9hZHMgaGF2ZSBu b3QgYXJyaXZlZCBhZnRlciBhIHRpbWVvdXQgYW5kIGENCj4gcmV0cmFuc21pdCBtaXNzaW5nIHBh eWxvYWRzIHJlc3BvbnNlIGlzIG5lZWRlZC4iDQo+IA0KPiDCoMKgIFNob3VsZG4ndCB0aGlzIGFs c28gbWVudGlvbiB0aGUgY2FzZSB3aGVyZSB0aGUgc2VydmVyIHNlbmRzIGENCj4gMi4zMSByZXNw b25zZSB0byBoYXZlIHRoZSBjbGllbnQgY29udGludWUgc2VuZGluZyB0aGUgbmV4dA0KPiBNQVhf UEFZTE9BRFMgcGF5bG9hZHM/DQo+IA0KPiAqIFNlY3Rpb24gMy4zIC0gUHJvcG9zZWQgY2xhcmlm aWNhdGlvbiBmb3IgdGhlIDQuMDIgcmVzcG9uc2UgY29kZToNCj4gDQo+IMKgwqDCoCAiRWl0aGVy IHRoaXMgUmVzcG9uc2UgQ29kZSAoaW4gY2FzZSBvZiBDb25maXJtYWJsZSByZXF1ZXN0KSBvciBh DQo+IHJlc2V0IG1lc3NhZ2UgKGluIGNhc2Ugb2YgTm9uLWNvbmZpcm1hYmxlIHJlcXVlc3QpIE1V U1QgYmUgcmV0dXJuZWQNCj4gaWYgdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBRLUJs b2NrMSBPcHRpb24uIg0KPiANCj4gDQo+IE9uIDIwMjEtMDEtMTggMTU6MTYsIHN1cGpwcy1pZXRm QGpwc2hhbGxvdy5jb20gd3JvdGU6DQo+ID4gSGkgTWFyY28sDQo+ID4NCj4gPiBXZSBoYXZlIHVw ZGF0ZWQgZ2l0aHViIFsxXSB0byB0YWtlIGFjY291bnQgb2YgeW91ciBsYXRlc3QgY29tbWVudHMN Cj4gZm9yIHlvdXIgcmV2aWV3Lg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+DQo+ID4gSm9uDQo+ID4N Cj4gPg0KPiA+DQo+IFsxXWh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyDQo+IEZ3DQo+ID4gd3cuaWV0Zi5vcmclMkZyZmNkaWZm JTNGdXJsMSUzRGRyYWZ0LWlldGYtY29yZS1uZXctDQo+IGJsb2NrJTI2dXJsMiUzRGh0dHANCj4g PiBzJTNBJTJGJTJGcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSUyRmNvcmUtd2clMkZuZXctDQo+ IGJsb2NrJTJGbWFzdGVyJTJGZA0KPiA+IHJhZnQtaWV0Zi1jb3JlLW5ldy0NCj4gYmxvY2sudHh0 JmFtcDtkYXRhPTA0JTdDMDElN0NtYXJjby50aWxvY2ElNDByaS5zZSU3DQo+ID4NCj4gQzk4MDQw NGU1Yjk3YTRmN2Q2YTI3MDhkOGJiYmI5YjA1JTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQw Y2M5ZTgNCj4gJTcNCj4gPg0KPiBDMCU3QzAlN0M2Mzc0NjU3NjE3Mzg3NzUwODElN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBdw0KPiBNRA0KPiA+DQo+IEFpTENKUUlqb2lW Mmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPXVH DQo+IEIlDQo+ID4gMkJHdTBQenRSdk1oNGhVRnV0SE1JdGtSNUFKWENKcXB0NDQwbnBoajQlM0Qm YW1wO3Jlc2VydmVkPTANCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IE1hcmNvIFRpbG9jYSBbbWFpbHRvOiBtYXJjby50aWxvY2FAcmkuc2VdDQo+ ID4+IFNlbnQ6IDE1IEphbnVhcnkgMjAyMSAxMzo1OA0KPiA+PiBUbzogam9uQGpwc2hhbGxvdy5j b207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+IGNvcmVAaWV0Zi5vcmcNCj4gPj4g Q2M6IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4g Pj4gU3ViamVjdDogUmU6IFtjb3JlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJs b2NrLTA1LnR4dA0KPiA+Pg0KPiA+PiBIaSBKb24sDQo+ID4+DQo+ID4+IE9uIDIwMjEtMDEtMTUg MTI6MjQsIHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20gd3JvdGU6DQo+ID4+PiBIaSBNYXJjbywN Cj4gPj4+DQo+ID4+PiBUaGFua3MgZnJvbSB0aGlzLg0KPiA+Pj4NCj4gPj4+IFNvIG1vdmluZyBm b3J3YXJkLCByZXF1ZXN0cyBmb3IgbWlzc2luZyBRLUJsb2NrMiBibG9ja3Mgd2lsbA0KPiBmb2xs b3cNCj4gPj4+IFNlY3Rpb24gMi43IFJGQzc5NTkgYmVpbmcgbW9kZWxsZWQgb24gKGFzc3VtaW5n IHRoZSByZXF1ZXN0IHdhcw0KPiA+Pj4gdXNpbmcgUS0NCj4gPj4gQmxvY2sxKSAiIFRvIGNvbnRp bnVlIHRoaXMgQmxvY2syIHRyYW5zZmVyLCB0aGUgY2xpZW50DQo+ID4+PiAgICBjb250aW51ZXMg dG8gc2VuZCByZXF1ZXN0cyBzaW1pbGFyIHRvIHRoZSByZXF1ZXN0cyBpbiB0aGUNCj4gQmxvY2sx DQo+ID4+PiAgICBwaGFzZSwgYnV0IGxlYXZlcyBvdXQgdGhlIEJsb2NrMSBPcHRpb25zIGFuZCBp bmNsdWRlcyBhDQo+IEJsb2NrMg0KPiA+Pj4gICAgcmVxdWVzdCBvcHRpb24gd2l0aCBub24temVy byBOVU0uIg0KPiA+Pj4NCj4gPj4+IE90aGVyd2lzZSwgcGxlYXNlIHNlZSBpbmxpbmUgd2hpY2gg aGFzIGEgY291cGxlIG9mIHF1ZXN0aW9ucy4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzDQo+ID4+Pg0K PiA+Pj4gSm9uDQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9t OiBNYXJjbyBUaWxvY2EgW21haWx0bzogbWFyY28udGlsb2NhQHJpLnNlXQ0KPiA+Pj4+IFNlbnQ6 IDE0IEphbnVhcnkgMjAyMSAxOTo1OA0KPiA+Pj4+IFRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBjb3JlQGlldGYub3JnDQo+ID4+Pj4gQ2M6IGRyYWZ0LWlldGYtY29yZS1uZXctYmxv Y2tAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW2NvcmVdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stDQo+IDA1LnR4dA0KPiA+Pj4+DQo+ ID4+Pj4gSGkgTWVkLA0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIGZvciB0aGUgbmV3IGRvY3VtZW50 IHZlcnNpb24uDQo+ID4+Pj4NCj4gPj4+PiBQbGVhc2UsIHNlZSBiZWxvdyBzb21lIGNvbW1lbnRz IG9uIHRoZSBsYXRlc3QgYWRkaXRpb25zLCBhbHNvDQo+ID4+Pj4gcmVsYXRlZCB0byB3aGF0IEpv biByYWlzZWQgYXQgWzFdLg0KPiA+Pj4+DQo+ID4+Pj4gQmVzdCwNCj4gPj4+PiAvTWFyY28NCj4g Pj4+Pg0KPiA+Pj4+IFsxXQ0KPiA+Pj4+DQo+IGh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm0NCj4gPj4+PiBhaQ0KPiA+Pj4+ IGxhcmNoaXZlLmlldGYub3JnJTJGYXJjaCUyRm1zZyUyRmNvcmUlMkZPcnI4YTFXbFN1M0RrLQ0K PiA+PiBndFBRWmxvRFQ5XzFFJTINCj4gPj4NCj4gRiZhbXA7ZGF0YT0wNCU3QzAxJTdDbWFyY28u dGlsb2NhJTQwcmkuc2UlN0NmMzAxNjc0MTJjZjE0Mjc5NjE2NzA4ZA0KPiA+PiA4Yg0KPiA+PiA5 NDgyMDJhJTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzQ2 MzA2Njc0DQo+ID4+IDA0MDI0DQo+ID4+IDIxJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJ am9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUwNCj4gPj4gQ0pCVGkNCj4gPj4NCj4gSTZJ azFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9RTRsSWNjd1lReVZHSHh4bDl2 OWlCcjcwDQo+ID4+IGhVNg0KPiA+Pj4+IEJ1eFJyekFRb1pIblp0JTJCOCUzRCZhbXA7cmVzZXJ2 ZWQ9MA0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAqIFNlY3Rpb24gMy41IC0gVGhpcyBzZWVtcyB0 byBtaXggYXNwZWN0cyBzcGVjaWZpYyB0byBPYnNlcnZlLA0KPiB3aXRoDQo+ID4+Pj4gbW9yZSBn ZW5lcmFsIGFzcGVjdHMgYXBwbGljYWJsZSB0byByZXF1ZXN0cyB3aXRoIGEgcGF5bG9hZCwNCj4g aS5lLg0KPiA+Pj4+IEZFVENIICh3aXRoIG9yIHdpdGhvdXQgT2JzZXJ2ZSksIFBVVCwgUE9TVCBh bmQgUEFUQ0gvaVBBVENILg0KPiA+Pj4gW0pvbl0gTm93IHRoYXQgd2UgdW5kZXJzdGFuZCB3aGF0 IG5lZWRzIHRvIGJlIGRvbmUgd2l0aA0KPiByZXF1ZXN0aW5nDQo+ID4+PiBtaXNzaW5nDQo+ID4+ IFEtQmxvY2syIGJsb2Nrcywgd29ya2luZyB3aXRoIE9ic2VydmUgY2FuIGJlIHNpbXBsaWZpZWQu DQo+ID4+PiBbSm9uXSBSZXF1ZXN0aW5nIE9ic2VydmUgaXMgb25seSB2YWxpZCBmb3IgR0VUIGFu ZCBGRVRDSC4gIEhlbmNlDQo+ID4+PiBPYnNlcnZlDQo+ID4+IHJlcXVlc3QvY2FuY2VsbGF0aW9u IHNldHRpbmcgd2hlbiB1c2luZyBRLUJsb2NrMSBpcyBvbmx5DQo+IGFwcHJvcHJpYXRlIGZvciBG RVRDSC4NCj4gPj4+IFtKb25dICBVbmZvcnR1bmF0ZWx5LCBSRkM4MTMyIGRvZXMgbm90IHNwZWNp ZnkgaW4gd2hpY2ggb2YgdGhlDQo+ID4+PiBwYXlsb2FkcyBvZiBhcw0KPiA+PiBCbG9jazEgYmFz ZWQgRkVUQ0ggcmVxdWVzdCAgc2hvdWxkIGNvbnRhaW4gdGhlIE9ic2VydmUgb3B0aW9uDQo+ID4+ IGFzc3VtaW5nIG9ic2VydmUgaXMgcmVxdWlyZWQgKFRoZSBmaXJzdCwgdGhlIGxhc3Qgb3IgYWxs IG9mIHRoZQ0KPiA+PiBwYXlsb2FkcykuIFNvLCBoZXJlLCBJIGJlbGlldmUgdGhlIHNhZmVzdCB3 YXkgdG8gZ28gaXMgd2l0aCBhbGwNCj4gdGhlDQo+ID4+IHBheWxvYWRzIGNhcnJ5IHRoZSBvYnNl cnZlIG9wdGlvbiBpZiBvYnNlcnZlIGlzIGJlaW5nIHJlcXVlc3RlZA0KPiBvcg0KPiA+PiBjYW5j ZWxsZWQuICBUaHVzIGFueSBtaXNzaW5nIHBheWxvYWRzIHNob3VsZCBiZSByZXNlbnQgd2l0aCB0 aGUNCj4gPj4gb2JzZXJ2ZSBjb25maWd1cmVkIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBhbGwgdGhl IG90aGVyIHBheWxvYWRzLg0KPiBBcmUgeW91IGhhcHB5IHdpdGggdGhpcz8NCj4gPj4NCj4gPj4g PT0+TVQNCj4gPj4gSXQgbWFrZXMgc2Vuc2UgdG8gbWUuDQo+ID4+IDw9PQ0KPiA+Pg0KPiA+Pj4+ ICAgV2hhdCBpcyBzcGVjaWZpYyBvZiBPYnNlcnZlIGlzIHRoZSBmaXJzdCBwYXJhZ3JhcGg7IGFu ZCB0aGUNCj4gdXNhZ2UNCj4gPj4+PiBvZiB0aGUgT2JzZXJ2ZSBvcHRpb24gaW4gdGhlIHNlY29u ZCBhbmQgdGhpcmQgcGFyYWdyYXBoLg0KPiBBbnl0aGluZw0KPiA+Pj4+IGVsc2Ugc2VlbXMgZ2Vu ZXJpYyBhbmQgYXBwbGljYWJsZSB0byByZXF1ZXN0cyB3aXRoIHBheWxvYWQsIHNvDQo+IGl0DQo+ ID4+Pj4gbWlnaHQgYmUgbW92ZWQgdXAgdG8gc29tZSBlYXJsaWVyIHNlY3Rpb24uDQo+ID4+Pj4N Cj4gPj4+IFtKb25dIFN1cmUgLSB3aWxsIGJlIHVwZGF0ZWQgaW4gdGhlIHNpbXBsaWZpY2F0aW9u IHRpZHkgdXAuDQo+ID4+Pj4gKiBTZWN0aW9uIDMuNSAtIEluIHRoZSB0aGlyZCBwYXJhZ3JhcGgs IEknbSBub3Qgc3VyZSB5b3UNCj4gPj4+PiBuZWNlc3NhcmlseSBuZWVkIGEgcGF5bG9hZCB0byBi ZSBwcmVzZW50IGluIHRoZSByZXF1ZXN0cyBhc2tpbmcNCj4gZm9yDQo+ID4+Pj4gbWlzc2luZyBy ZXNwb25zZSBwYXlsb2Fkcy4gRm9yIGluc3RhbmNlLCBjb25zaWRlcjoNCj4gPj4+IFtKb25dIEFn cmVlZC4gIE5vdyBnb2luZyB3aXRoIFNlY3Rpb24gMi43IFJGQzc5NTkgd2hlcmUgYm90aA0KPiBC bG9jazENCj4gPj4+IGFuZA0KPiA+PiBwYXlsb2FkIGFyZSBub3QgaW5jbHVkZWQuDQo+ID4+Pj4g ICAtIFRoZSBleGFtcGxlcyBpbiBGaWd1cmUgMTAgYW5kIEZpZ3VyZSAxMSBvZiBSRkMgNzk1OSwg d2l0aA0KPiB0aGUNCj4gPj4+PiBub3RlICIobm8gcGF5bG9hZCBmb3IgcmVxdWVzdHMgd2l0aCBC bG9jazIgd2l0aCBOVU0gIT0gMCkiICwNCj4gZHVyaW5nDQo+ID4+Pj4gdGhlIHBoYXNlIHdoZXJl IHRoZSBjbGllbnQgY29uc2VjdXRpdmVseSBhc2tzIGZvciB0aGUgbmV4dA0KPiByZXNwb25zZSBw YXlsb2FkLg0KPiA+Pj4+DQo+ID4+Pj4gICAtIFRoZSBleGFtcGxlcyBpbiBGaWd1cmUgMiBhbmQg RmlndXJlIDMgb2YgWzJdLCB3aGVyZSBlYWNoDQo+ID4+Pj4gcmVxdWVzdCBmb3IgdGhlIG5leHQg cmVzcG9uc2UgcGF5bG9hZCB1c2luZyBCbG9jazIgaGFzIG5vDQo+IHBheWxvYWQgb2YgaXRzIG93 bi4NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgd291bGQgb2YgY291cnNlIGFmZmVjdCB0aGUgZXhhbXBs ZSBpbiBGaWd1cmUgMTUuDQo+ID4+PiBbSm9uXSBZZXMsIHdpbGwgYmUgdXBkYXRlZC4NCj4gPj4+ PiBbMl0NCj4gPj4+Pg0KPiBodHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0DQo+ID4+Pj4gb28NCj4gPj4+PiBscy5pZXRmLm9y ZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWFjZS1jb2FwLWVzdC0NCj4gPj4gMTgmYW1wO2RhdGE9MDQl N0MwMSU3Q21hDQo+ID4+DQo+IHJjby50aWxvY2ElNDByaS5zZSU3Q2YzMDE2NzQxMmNmMTQyNzk2 MTY3MDhkOGI5NDgyMDJhJTdDNWE5ODA5Y2YwYmNiDQo+ID4+IDQNCj4gPj4gMTNhODM4YTA5ZWNj NDBjYzllOCU3QzAlN0MwJTdDNjM3NDYzMDY2NzQwNDAyNDIxJTdDVW5rbm93biU3Q1QNCj4gPj4g V0ZwYkdacw0KPiA+Pg0KPiBiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp TENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wDQo+ID4+ICUzDQo+ID4+IEQlN0MxMDAwJmFtcDtz ZGF0YT1jU09PdUNCRVAyakNSekVDckplTGxpNlolMkJ1JTJGVWxEJTJGMUh6VldJTTcNCj4gPj4g TzclMkINCj4gPj4+PiBRJTNEJmFtcDtyZXNlcnZlZD0wDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ ICogU2VjdGlvbiAzLjUgLSBBYm91dCB0aGUgbGFzdCBzZW50ZW5jZSByZWdhcmRpbmcgdGhlIE9i c2VydmUNCj4gPj4+PiBvcHRpb24sIHRoZXJlIHNlZW1zIHRvIGJlIGFuIGV4Y2VwdGlvbiB0byB0 aGlzIHJ1bGUgKGF0IGxlYXN0DQo+IGJhc2VkDQo+ID4+Pj4gb24gdGhlIGxhdGVyIGV4YW1wbGVz KSwgd2hlcmUgdGhlIHNlcnZlciBhY3R1YWxseSBkb2VzIGluY2x1ZGUNCj4gdGhlDQo+ID4+Pj4g T2JzZXJ2ZSBvcHRpb24gaW4NCj4gPj4gdGhlIHJlc3BvbnNlLg0KPiA+Pj4gW0pvbl0gSWYgdGhl IE9ic2VydmUgb3B0aW9uIGlzIGp1c3QgaW5jbHVkZWQgd2l0aCB0aGUgZmlyc3QNCj4gcGF5bG9h ZA0KPiA+Pj4gKE5VTSA9IDApIGFzDQo+ID4+IFJGQzc5NTksIHRoZXJlIGlzIGEgcmVjb3Zlcnkg c3BlY2lhbCBjYXNlIHNob3VsZCB0aGUgZmlyc3QNCj4gcGF5bG9hZA0KPiA+PiBub3QgYXJyaXZl LCBidXQgc3Vic2VxdWVudCBvbmVzIGRvLiAgSW4gdGhlIGdlbmVyYWwgY2FzZSwgYmxvY2tzDQo+ IHRoYXQNCj4gPj4gYXJlIG1pc3NpbmcgYXJlIHJlLSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCBh bmQgdGhlIHNlcnZlcg0KPiByZXNwb25kcw0KPiA+PiB3aXRoIHRoZSBhcHByb3ByaWF0ZSBibG9j aywgYnV0IHdpdGhvdXQgdGhlIE9ic2VydmUgb3B0aW9uLiBGb3INCj4gdGhlDQo+ID4+IHNwZWNp YWwgY2FzZSB3aGVuIHRoZSBjbGllbnQgcmVxdWVzdHMgbWlzc2luZyBwYXlsb2FkIHdpdGggTlVN ID0NCj4gMA0KPiA+PiB0aGUgc2VydmVyIG5lZWRzIHRvIGtub3cgdGhhdCBpdCBtdXN0IGluY2x1 ZGUgdGhlIE9ic2VydmUgaW4gdGhlDQo+ID4+IHJlc3BvbnNlIHNvIHRoYXQgdGhlIGNsaWVudCBm b2xsb3dpbmcgdGhlIGJvZHkgcmUtYXNzZW1ibHkga25vd3MNCj4gdGhhdCBpdCBpcyBhIE9ic2Vy dmUgdHJpZ2dlcmVkIGFkZGl0aW9uYWwgcmVzcG9uc2UuDQo+ID4+PiBbSm9uXSBJIGhhZCBnb25l IHdpdGggdGhlIE9ic2VydmUgc2hvdWxkIGJlIGluIGFsbCB0aGUgcGF5bG9hZHMNCj4gaW4NCj4g Pj4+IHRoZSByZXNwb25zZQ0KPiA+PiBhcGFydCBmcm9tIHNwZWNpZmljYWxseSByZS1yZXF1ZXN0 ZWQgYmxvY2tzIChpbmNsdWRpbmcgTlVNID0gMCkuDQo+IFRoZSAnQ29udGludWUnDQo+ID4+IFEt QmxvY2syIHdhcyBqdXN0IHRvIGluZGljYXRlIGEgY29udGludWUgc28gdGhlIHNlcnZlciBjYW4g c2VuZA0KPiB0aGUNCj4gPj4gcmVtYWluaW5nIHBheWxvYWRzIHdpdGhvdXQgZGVsYXkgLSBoZW5j ZSB3aHkgcmVtYWluaW5nIHBheWxvYWRzDQo+IGhhZCBPYnNlcnZlIHNldC4NCj4gPj4+IFtKb25d IEkgYW0gYmVnaW5uaW5nIHRvIGxlYW4gdG8gaGF2aW5nIGl0IGluIHRoZSBmaXJzdCBwYXlsb2Fk DQo+IGFuZA0KPiA+Pj4gc3BlY2lhbCBjYXNlDQo+ID4+IHRoZSByZXNwb25zZSB0byByZS1yZXF1 ZXN0IG9mIE5VTSA9IDAuICBXaGF0IGRvIHlvdSB0aGluaz8NCj4gPj4NCj4gPj4gPT0+TVQNCj4g Pj4gT2ssIEkgZGlkbid0IHRoaW5rIGFsc28gb2YgdGhlIGNhc2UgZm9yIE5VTSA9IDAsIGJ1dCB0 aGF0IG1ha2VzDQo+IHNlbnNlIHRvby4NCj4gPj4NCj4gPj4gVGhlbiBpdCdzIGNlcnRhaW5seSBz b21ldGhpbmcgYmV0dGVyIHRvIGNsYXJpZnkgaW4gdGhlIG1haW4gdGV4dA0KPiBhbmQNCj4gPj4g YWxzbyB0byBzaG93L2NvbW1lbnQgaW4gdGhlIGV4YW1wbGUgb2YgRmlndXJlIDEwLg0KPiA+PiA8 PT0NCj4gPj4NCj4gPj4+PiAgICBUaGF0IGlzLCBjb25zaWRlciB0aGUgZXhhbXBsZSBpbiBGaWd1 cmUgMTAsIHdoZXJlIHRoZQ0KPiByZXNwb25zZQ0KPiA+Pj4+IHdpdGggTToweGJhIGlzIGxvc3Qu IExhdGVyIG9uLCB0aGUgY2xpZW50IGFza3MgZm9yIHRoYXQNCj4gcmVzcG9uc2UNCj4gPj4+PiBw YXlsb2FkIGJ5IHNlbmRpbmcgdGhlIHJlcXVlc3Qgd2l0aCBNOjB4ODcsIHdoaWNoIGNvcnJlY3Rs eQ0KPiBkb2VzDQo+ID4+Pj4gbm90IGluY2x1ZGUNCj4gPj4gdGhlIE9ic2VydmUgb3B0aW9uLg0K PiA+Pj4gW0pvbl0gWWVzDQo+ID4+Pj4gICAgSG93ZXZlciwgdGhlIGZvbGxvd2luZyByZXNwb25z ZSB3aXRoIE06b3hjMyBhbmQgKGZyb20gdGhlDQo+IHBvaW50DQo+ID4+Pj4gb2YgdmlldyBvZiB0 aGUgc2VydmVyKSByZXRyYW5zbWl0dGluZyB0aGF0IHJlc3BvbnNlIHBheWxvYWQNCj4gd2l0aA0K PiA+Pj4+IGJsb2NrIG51bWJlciAxMCBkb2VzIGluY2x1ZGUgdGhlIE9ic2VydmUgb3B0aW9uLg0K PiA+Pj4+DQo+ID4+Pj4gICAgVGhlIGV4Y2VwdGlvbiBzZWVtcyBkdWUgdG8gdGhlIGZhY3QgdGhh dCB0aGUgcmV0cmFuc21pc3Npb24NCj4gPj4+PiByZXF1ZXN0IGZyb20gdGhlIGNsaWVudCBpcyBz cGVjaWZpY2FsbHkgd2hhdCB5b3UgY2FsbA0KPiAnQ29udGludWUnDQo+ID4+Pj4gUS1CbG9jay0y IGluIFNlY3Rpb24gMy40LiBUaGUgT2JzZXJ2ZSBvcHRpb24gaXMgaW4gZmFjdCBub3QNCj4gPj4+ PiBpbmNsdWRlZCBmb3IgdGhlIHByZXZpb3VzbHkgcmV0cmFuc21pdHRlZCByZXNwb25zZSBwYXls b2Fkcw0KPiB3aXRoDQo+ID4+Pj4gTToweGJiIC4uLiBNOjB4YzIsDQo+ID4+IGFzIHN0aWxsIHBh cnQgb2YgdGhlIGN1cnJlbnQgcGF5bG9hZCBzZXQuDQo+ID4+PiBbSm9uXSBDb3JyZWN0LCBidXQg b2J2aW91c2x5IG5vdCBvYnZpb3VzIGZyb20gdGhlIHRleHQuDQo+ID4+ID09Pk1UDQo+ID4+IFJp Z2h0LCBJIG1vc3RseSBmb2N1c2VkIG9uIHRoYXQuDQo+ID4+DQo+ID4+IEkgdGhpbmsgaXQncyB3 b3J0aCBjbGFyaWZ5aW5nIGluIHRoZSBtYWluIHRleHQgd2hhdCB0aGUgbm9ybWFsDQo+IGNhc2UN Cj4gPj4gaXMgZm9yIHRoZSBzZXJ2ZXINCj4gPj4gKGNsaWVudCkgdG8gaW5jbHVkZSAoZXhwZWN0 KSB0aGUgT2JzZXJ2ZSBvcHRpb24gaW4gYSByZXNwb25zZQ0KPiA+PiBwYXlsb2FkOyBhbmQgdGhl biBoaWdobGlnaHQgdGhlIGV4Y2VwdGlvbnMgZm9yIHRoZSByZS1yZXF1ZXN0DQo+IHdpdGgNCj4g Pj4gTlVNPTAgKHNlZSBhYm92ZSkgYW5kIGZvciB0aGUgJ0NvbnRpbnVlJyBRLUJsb2NrMi4NCj4g Pj4NCj4gPj4gQmVzdCwNCj4gPj4gL01hcmNvDQo+ID4+IDw9PQ0KPiA+Pg0KPiA+Pj4+ICogU2Vj dGlvbiAzLjYgLSBQYXJ0IG9mIHRoZSBmaXJzdCBzZW50ZW5jZSBpbiB0aGUgc2Vjb25kDQo+IHBh cmFncmFwaA0KPiA+Pj4+IHNlZW1zIHRvIHJlcGVhdCB3aGF0IGFscmVhZHkgc2FpZCBpbiB0aGUg dGhpcmQgcGFyYWdyYXBoIG9mDQo+IFNlY3Rpb24gMy41Lg0KPiA+Pj4+DQo+ID4+PiBbSm9uXSBX aWxsIGNsZWFuIHVwIGluIHRoZSBzaW1wbGlmaWNhdGlvbi4NCj4gPj4+IH5Kb24NCj4gPj4gLS0N Cj4gPj4gTWFyY28gVGlsb2NhDQo+ID4+IFBoLkQuLCBTZW5pb3IgUmVzZWFyY2hlcg0KPiA+Pg0K PiA+PiBSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuDQo+ID4+IERpdmlzaW9uIElD VA0KPiA+PiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KPiA+PiBTRS0xNjQg NDAgS2lzdGEgKFN3ZWRlbikNCj4gPj4NCj4gPj4gUGhvbmU6ICs0NiAoMCk3MCA2MCA0NiA1MDEN Cj4gPj4NCj4gaHR0cHM6Ly9ldXIwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3cNCj4gdw0KPiA+Pg0KPiAucmkuc2UlMkYmYW1wO2RhdGE9MDQl N0MwMSU3Q21hcmNvLnRpbG9jYSU0MHJpLnNlJTdDOTgwNDA0ZTViOTdhNGY3ZA0KPiA2DQo+ID4+ DQo+IGEyNzA4ZDhiYmJiOWIwNSU3QzVhOTgwOWNmMGJjYjQxM2E4MzhhMDllY2M0MGNjOWU4JTdD MCU3QzAlN0M2Mzc0NjU3DQo+IDYNCj4gPj4NCj4gMTczODc3NTA4MSU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU0NCj4geg0KPiA+Pg0KPiBJ aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPUxFJTJGS1FP T1VxNWFFQmJnVg0KPiBSDQo+ID4+IGR0cW1MaU96OG4lMkJ0NjBPdUVZZ00lMkZ3Q3JKZyUzRCZh bXA7cmVzZXJ2ZWQ9MA0KPiA+Pg0KPiA+DQo+IA0KPiAtLQ0KPiBNYXJjbyBUaWxvY2ENCj4gUGgu RC4sIFNlbmlvciBSZXNlYXJjaGVyDQo+IA0KPiBSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2Yg U3dlZGVuDQo+IERpdmlzaW9uIElDVA0KPiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8Olbmdl biAxNg0KPiBTRS0xNjQgNDAgS2lzdGEgKFN3ZWRlbikNCj4gDQo+IFBob25lOiArNDYgKDApNzAg NjAgNDYgNTAxDQo+IGh0dHBzOi8vd3d3LnJpLnNlDQo+IA0KDQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cgo= From nobody Tue Jan 19 06:10:08 2021 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 500F63A151B; Tue, 19 Jan 2021 06:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 FDEbq55iUHIG; Tue, 19 Jan 2021 06:10:02 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140042.outbound.protection.outlook.com [40.107.14.42]) (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 447B23A151A; Tue, 19 Jan 2021 06:10:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q3keTZ29EZSj+e36mtBYS2VzmW5InxtMMiK/OFIHc2CL3vzNG2REY8wifp8HkRB9fR2OLdqBWQazN4B5z2L1hdON+aOtmg4Ds+uc8JDE+SYhzApJmE4YlQG6g+cX6BEQdin+iH42o9G/fFl6AyhkPfm1/Lp0Lq4VPg3D1tlKNF6yr8tbcM7cR2DFSlKBTuH8r0TOqwWmPL9WWfauK2mCmQfbFglxLB5QyQ62+7qKTslRhIPI/dpYWiBA5J4DJy3MGwfY/4P/cugth0DZNAAnA0/3c//JYhcHMqaKs/eWxOezSKZMExEyM/iAQGFRLtIsNe4gRlc0VbxtMW/cXsYEgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Dx2St47nNbUmZLZSLX3SSDqNeIi9nN/5XUMRjQvA4o=; b=k4za+Zi1ZFrcTzPRtZ8cacID+JzB4baTQIeTt7C+pTB2Kl9VMX5yFh7JNFRTIMYnVyU+QtyPpWwo8M/aggG/L344M3F6X1y5YVAHqIYRtI2Brjx10m7ZJJqnM9dyMSCQtgrI6mewf0lZBiXtKJS3q8ioGiwRyEO2DWWpwrkgZyNXY92EsH0A0uv0+4xvzh54pONIAwAuIEeQ6eJd6L/DL1jKLqb3ZjqZbDsZjfjuUSCGyn/ycBGOXvGmPk0AUF3FhuDymdGpUtAU+e7H1mxc2ya8QpoAy5mypgnv2SZYKdenhdudJgqQeNaAxttyqxiU3JPUCjxMmDAdBw9zARlVYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Dx2St47nNbUmZLZSLX3SSDqNeIi9nN/5XUMRjQvA4o=; b=AA+r4VmAvTr9Iu8DVfLy7KmGo02dfG1oFGZKT+X5ZKJ5tlk7Mfnt/phrJLAuUzIuYCZVIFs6ir8p1tg1ir52sllPjXRw/ncdSWPMq5DBoMuK7k3ueWYx+MZXRif1vfvC/eLn0GY5lSgSPZJRLLz+7xH7uNHUDb9FsnO24Yq2Z7o= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1080.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11; Tue, 19 Jan 2021 14:09:54 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 14:09:54 +0000 To: mohamed.boucadair@orange.com, "supjps-ietf@jpshallow.com" , "core@ietf.org" Cc: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Tue, 19 Jan 2021 15:09:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic" X-Originating-IP: [37.120.209.212] X-ClientProxiedBy: HE1P192CA0006.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::16) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.7] (37.120.209.212) by HE1P192CA0006.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Tue, 19 Jan 2021 14:09:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c82628d3-253c-4ab2-022a-08d8bc83e4ee X-MS-TrafficTypeDiagnostic: DB8P189MB1080: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pk6XJU1fDKFg+IErAh3KrWGPjyiq5fV8Q0LlxBkHHsvm9Z7opY1aq85bx8/KUaVKUf4Kn+65U5XgLJ3pypMfwsSpjIM9SfecaJ32kFye0uvuyOnY4SfsX7LRMEzQMym+Orpt4IljUo58mg6mpAOxwks+yOw0Papi6SDCh4+c2r9tjWhsag5ilbvtSGjBE7YWEppkuvvKjgEpn5sllTyGmqzpcm6jP3GpTcCJr80HSgndnBaD8U6bP52fz5m3cv+6N9YVPms7q0JsQEAqHDFEyEtZOh+pKlqovzpSlbRB33zFFxTcy6AavzVH5joWobrRY2WtnW5TXzkC4tuTn4bZ7ZEeSBBI9ZPh2YQ+Mcehd1qO58k2DrO+tKN1TzfaOd5+lW+ICOzQCrppGtEfCyxfBRSOTZ+f6+6WG43lLqbA3GyTqVj63gUFbeLEnI2JtMEXjBR7nD2pyen5W96ux8SjRecMIPdpBUqhhN1EjIClKK7OKRlc+lteeXFVWS81bSFQ5GykA/J7wKxcEHIdd9JrAPoTZOK2bfPt2/EnzocS1A4TvaNCdN80QcNe4rU+yDKx X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(136003)(39840400004)(366004)(6486002)(31696002)(2906002)(52116002)(21480400003)(30864003)(44832011)(16576012)(110136005)(316002)(54906003)(5660300002)(45080400002)(478600001)(31686004)(8676002)(4326008)(966005)(235185007)(186003)(956004)(66574015)(66556008)(6666004)(16526019)(26005)(66476007)(86362001)(36756003)(33964004)(8936002)(53546011)(2616005)(66946007)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?cEZoWHlxdW9GZXdWV1U0eE1NYVJmSEQyQW1YOVM5bHVIYmZUblBBM290TDlq?= =?utf-8?B?ZktWckdvMzQ1RlZxNHI4aG1USjh4cWlySzMrZm5CQW05WWZJZ1UvNERkRjZP?= =?utf-8?B?c0dseDNIUW9sY1B6bElLRmtxZnBHR1NEbVBtZEx4bWd1eTFWMGZOYmh1OENB?= =?utf-8?B?MHJ4NkNDQUd3QnhhZ1drZkVXaUF5SDdlU2lkZkY0MlpKTXJTL214QW4xL3Yw?= =?utf-8?B?b3JiZDZKTi9UM1pDVm9GYUcxWWlvcEdTSndiMldNb2hhVFZOSGp4M2RUTW1K?= =?utf-8?B?K29Bd0FZT2NyZWVrOUErZVhCSjg4MFpmRFpHZVhtbDdmNnpGbmU4UDhtV21q?= =?utf-8?B?K29Qalp4aGg2T21mK3dSbnZvb2lJNVZqeEZQTCtNRFNOQmVPbDYrNmFpemVp?= =?utf-8?B?czMxRG02ODVWVm9MbGJJb08vd0p5ZWZnd1E0UUZDNjRMWFNQY1FuOHVnajlK?= =?utf-8?B?MTlKUUthYzF3UXlwSmpsL1ljMXh5Qjc3Kzc4M3NYNzVDVDM1cDVQWEs2UzdY?= =?utf-8?B?ZnRoU285Sm5uUzVCcHBTTk5uNTREQ3gyeFNGeWV5dHdJZm5tNytHVU5wZHRu?= =?utf-8?B?OHhNMDVWZEpCeHBFdk5sdGkySStib2V1SXBXdVV1RUlGbElwL3hmMDRPbWQ1?= =?utf-8?B?RWZYQlhsUHB1Z3F2M0V5WGI3dHBPTVF0bEhPR3RUZjJwa28rYnlTaEhNZHl3?= =?utf-8?B?ZGx5TVpHZ3hZdnBOZDRUNUFody9yU21oQXFncUFDNUV4ZXUzR3dUbmJ2WUNW?= =?utf-8?B?Z1h2RVkybE5nSExDWnNIWnJRNUQ0ZVp0NWFYSjdLV3h2eURwWFRNM3JGUHZp?= =?utf-8?B?Y25PbEhydC80OW1Nb2V4TVJpcUxVN3NTOGdSd0dKY2pjYjQ2Z2l6RnJSdUEx?= =?utf-8?B?N3RGQiszdE1MOGtFY2dkTEttR25MS3ZXWnhtdDJXVnMxdGZycUJaaE14V3hh?= =?utf-8?B?OXZ6T3F1U3BiNUNZalhpUGY3alh5T2pyWUJNZE5TTC9YeWVOU3FLSXdKUkRH?= =?utf-8?B?MFFUTVUvbTF4QXdiT1hFaWZhc0FONktnbnkvTlVDWjFwS0Zqak1MZFNSVDNU?= =?utf-8?B?TGRsYnJ6TkFReCs2UTlOc2lwOW5qU3lqcmRvR0lFVjFHYlBkd0JEalR0TkZ5?= =?utf-8?B?cUpGbkFvaEhHRE5YcHhLMFZJRnNIc3djYjM1MlU2MzdUcndEUHR0NjJaM1Vw?= =?utf-8?B?N0dod21tM1pJbis1TFhUNmx0bDMvV0tBZzIrV0xPVUNlbkJwa2FtQkNTZ3A1?= =?utf-8?B?UzBRWHFFU0FyRXFSRnl5blZkd2w5QVFvWm01dWlqZUd1TTdES2NtR0IyTkVV?= =?utf-8?B?VFhuYUk3dk1tZHBPcVRsYnpvdzJ2ZEREcElFNnBOUVZ3Sk4xLzZjN3RZQ0dt?= =?utf-8?B?dHZveW1kR1JndlBET1Nxa1Z1by9LOUZMc2kxNnpOb01COFhiRjA2QlBHVnFN?= =?utf-8?Q?Wlhtu09C?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: c82628d3-253c-4ab2-022a-08d8bc83e4ee X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 14:09:54.2756 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WbWxjTtSWFD+TdkGavyRvjn7qi6fNBeHlA6N+C/5YZfl4uRktOsONuRpchtxPGed1n8FE5Jn/ZigSQiWayeuFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1080 Archived-At: Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.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 Jan 2021 14:10:06 -0000 --JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic Content-Type: multipart/mixed; boundary="LGEEhWQZN5PxIGxBMw1EEjciIUGhrkI50" --LGEEhWQZN5PxIGxBMw1EEjciIUGhrkI50 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Got it, thanks. Best, /Marco On 2021-01-19 13:24, mohamed.boucadair@orange.com wrote: > Hi Marco,=20 > > The proposed edits look good to me. Will be fixed in the github.=20 > > 2.31 is not mentioned in in the excerpt you quoted from Section 3.3 bec= ause 2.31 is not **required**. A server may decide to not reply with 2.31= as a function of its overall load and prefer to observe a pause before h= andling the next block. That=E2=80=99s is why we do have SHOULD, not a MU= ST. =20 > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: Marco Tiloca [mailto:marco.tiloca@ri.se] >> Envoy=C3=A9=C2=A0: mardi 19 janvier 2021 12:50 >> =C3=80=C2=A0: supjps-ietf@jpshallow.com; BOUCADAIR Mohamed TGI/OLN >> ; core@ietf.org >> Cc=C2=A0: draft-ietf-core-new-block@ietf.org; dots@ietf.org >> Objet=C2=A0: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >> >> Hi Jon, >> >> Thanks, please see below some minor points, otherwise it looks good >> to me. >> >> Best, >> /Marco >> >> * Section 3.1 - In the paragraph right above Table 2, s/with CoAP >> over TCP/with CoAP over reliable transports. >> >> * Section 3.1 - I think that the new final paragraph "Note that if >> Q-Block1 (or Q-Block2) ... MUST NOT be included." fits better before >> the paragraph discussing the use of OSCORE, i.e. "The Q-Block1 and >> ... >> fragmentation of requests." >> >> * Section 3.3 - "For Non-confirmable transmission, no response is >> required until the successful receipt of the body by the server or >> some of the payloads have not arrived after a timeout and a >> retransmit missing payloads response is needed." >> >> =C2=A0=C2=A0 Shouldn't this also mention the case where the server sen= ds a >> 2.31 response to have the client continue sending the next >> MAX_PAYLOADS payloads? >> >> * Section 3.3 - Proposed clarification for the 4.02 response code: >> >> =C2=A0=C2=A0=C2=A0 "Either this Response Code (in case of Confirmable = request) or a >> reset message (in case of Non-confirmable request) MUST be returned >> if the server does not support the Q-Block1 Option." >> >> >> On 2021-01-18 15:16, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> We have updated github [1] to take account of your latest comments >> for your review. >>> Regards >>> >>> Jon >>> >>> >>> >> [1]https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= 52 >> Fw >>> ww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- >> block%26url2%3Dhttp >>> s%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- >> block%2Fmaster%2Fd >>> raft-ietf-core-new- >> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 >> C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8 >> %7 >> C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw >> MD >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DuG= >> B% >>> 2BGu0PztRvMh4hUFutHMItkR5AJXCJqpt440nphj4%3D&reserved=3D0 >>> >>> >>>> -----Original Message----- >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>> Sent: 15 January 2021 13:58 >>>> To: jon@jpshallow.com; mohamed.boucadair@orange.com; >> core@ietf.org >>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >>>> >>>> Hi Jon, >>>> >>>> On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: >>>>> Hi Marco, >>>>> >>>>> Thanks from this. >>>>> >>>>> So moving forward, requests for missing Q-Block2 blocks will >> follow >>>>> Section 2.7 RFC7959 being modelled on (assuming the request was >>>>> using Q- >>>> Block1) " To continue this Block2 transfer, the client >>>>> continues to send requests similar to the requests in the >> Block1 >>>>> phase, but leaves out the Block1 Options and includes a >> Block2 >>>>> request option with non-zero NUM." >>>>> >>>>> Otherwise, please see inline which has a couple of questions. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>>> -----Original Message----- >>>>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>>>> Sent: 14 January 2021 19:58 >>>>>> To: mohamed.boucadair@orange.com; core@ietf.org >>>>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >>>>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block- >> 05.txt >>>>>> Hi Med, >>>>>> >>>>>> Thanks for the new document version. >>>>>> >>>>>> Please, see below some comments on the latest additions, also >>>>>> related to what Jon raised at [1]. >>>>>> >>>>>> Best, >>>>>> /Marco >>>>>> >>>>>> [1] >>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fm >>>>>> ai >>>>>> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk- >>>> gtPQZloDT9_1E%2 >>>> >> F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d >>>> 8b >>>> 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674 >>>> 04024 >>>> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL >>>> CJBTi >>>> >> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70 >>>> hU6 >>>>>> BuxRrzAQoZHnZt%2B8%3D&reserved=3D0 >>>>>> >>>>>> >>>>>> * Section 3.5 - This seems to mix aspects specific to Observe, >> with >>>>>> more general aspects applicable to requests with a payload, >> i.e. >>>>>> FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. >>>>> [Jon] Now that we understand what needs to be done with >> requesting >>>>> missing >>>> Q-Block2 blocks, working with Observe can be simplified. >>>>> [Jon] Requesting Observe is only valid for GET and FETCH. Hence >>>>> Observe >>>> request/cancellation setting when using Q-Block1 is only >> appropriate for FETCH. >>>>> [Jon] Unfortunately, RFC8132 does not specify in which of the >>>>> payloads of as >>>> Block1 based FETCH request should contain the Observe option >>>> assuming observe is required (The first, the last or all of the >>>> payloads). So, here, I believe the safest way to go is with all >> the >>>> payloads carry the observe option if observe is being requested >> or >>>> cancelled. Thus any missing payloads should be resent with the >>>> observe configured to be consistent with all the other payloads. >> Are you happy with this? >>>> =3D=3D>MT >>>> It makes sense to me. >>>> <=3D=3D >>>> >>>>>> What is specific of Observe is the first paragraph; and the >> usage >>>>>> of the Observe option in the second and third paragraph. >> Anything >>>>>> else seems generic and applicable to requests with payload, so >> it >>>>>> might be moved up to some earlier section. >>>>>> >>>>> [Jon] Sure - will be updated in the simplification tidy up. >>>>>> * Section 3.5 - In the third paragraph, I'm not sure you >>>>>> necessarily need a payload to be present in the requests asking >> for >>>>>> missing response payloads. For instance, consider: >>>>> [Jon] Agreed. Now going with Section 2.7 RFC7959 where both >> Block1 >>>>> and >>>> payload are not included. >>>>>> - The examples in Figure 10 and Figure 11 of RFC 7959, with >> the >>>>>> note "(no payload for requests with Block2 with NUM !=3D 0)" , >> during >>>>>> the phase where the client consecutively asks for the next >> response payload. >>>>>> - The examples in Figure 2 and Figure 3 of [2], where each >>>>>> request for the next response payload using Block2 has no >> payload of its own. >>>>>> This would of course affect the example in Figure 15. >>>>> [Jon] Yes, will be updated. >>>>>> [2] >>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ft >>>>>> oo >>>>>> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est- >>>> 18&data=3D04%7C01%7Cma >>>> >> rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb >>>> 4 >>>> 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT >>>> WFpbGZs >>>> >> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>>> %3 >>>> D%7C1000&sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7 >>>> O7%2B >>>>>> Q%3D&reserved=3D0 >>>>>> >>>>>> >>>>>> * Section 3.5 - About the last sentence regarding the Observe >>>>>> option, there seems to be an exception to this rule (at least >> based >>>>>> on the later examples), where the server actually does include >> the >>>>>> Observe option in >>>> the response. >>>>> [Jon] If the Observe option is just included with the first >> payload >>>>> (NUM =3D 0) as >>>> RFC7959, there is a recovery special case should the first >> payload >>>> not arrive, but subsequent ones do. In the general case, blocks >> that >>>> are missing are re- requested by the client and the server >> responds >>>> with the appropriate block, but without the Observe option. For >> the >>>> special case when the client requests missing payload with NUM =3D >> 0 >>>> the server needs to know that it must include the Observe in the >>>> response so that the client following the body re-assembly knows >> that it is a Observe triggered additional response. >>>>> [Jon] I had gone with the Observe should be in all the payloads >> in >>>>> the response >>>> apart from specifically re-requested blocks (including NUM =3D 0). >> The 'Continue' >>>> Q-Block2 was just to indicate a continue so the server can send >> the >>>> remaining payloads without delay - hence why remaining payloads >> had Observe set. >>>>> [Jon] I am beginning to lean to having it in the first payload >> and >>>>> special case >>>> the response to re-request of NUM =3D 0. What do you think? >>>> >>>> =3D=3D>MT >>>> Ok, I didn't think also of the case for NUM =3D 0, but that makes >> sense too. >>>> Then it's certainly something better to clarify in the main text >> and >>>> also to show/comment in the example of Figure 10. >>>> <=3D=3D >>>> >>>>>> That is, consider the example in Figure 10, where the >> response >>>>>> with M:0xba is lost. Later on, the client asks for that >> response >>>>>> payload by sending the request with M:0x87, which correctly >> does >>>>>> not include >>>> the Observe option. >>>>> [Jon] Yes >>>>>> However, the following response with M:oxc3 and (from the >> point >>>>>> of view of the server) retransmitting that response payload >> with >>>>>> block number 10 does include the Observe option. >>>>>> >>>>>> The exception seems due to the fact that the retransmission >>>>>> request from the client is specifically what you call >> 'Continue' >>>>>> Q-Block-2 in Section 3.4. The Observe option is in fact not >>>>>> included for the previously retransmitted response payloads >> with >>>>>> M:0xbb ... M:0xc2, >>>> as still part of the current payload set. >>>>> [Jon] Correct, but obviously not obvious from the text. >>>> =3D=3D>MT >>>> Right, I mostly focused on that. >>>> >>>> I think it's worth clarifying in the main text what the normal >> case >>>> is for the server >>>> (client) to include (expect) the Observe option in a response >>>> payload; and then highlight the exceptions for the re-request >> with >>>> NUM=3D0 (see above) and for the 'Continue' Q-Block2. >>>> >>>> Best, >>>> /Marco >>>> <=3D=3D >>>> >>>>>> * Section 3.6 - Part of the first sentence in the second >> paragraph >>>>>> seems to repeat what already said in the third paragraph of >> Section 3.5. >>>>> [Jon] Will clean up in the simplification. >>>>> ~Jon >>>> -- >>>> Marco Tiloca >>>> Ph.D., Senior Researcher >>>> >>>> RISE Research Institutes of Sweden >>>> Division ICT >>>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >>>> SE-164 40 Kista (Sweden) >>>> >>>> Phone: +46 (0)70 60 46 501 >>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d= >> 6 >> a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374657 >> 6 >> 1738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM >> z >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DLE%2FKQOOUq5aEBbgV= >> R >>>> dtqmLiOz8n%2Bt60OuEYgM%2FwCrJg%3D&reserved=3D0 >>>> >> -- >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C21a30f35d4534262c3= 8c08d8bc751b7c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374665585176= 29762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D5npricMtOuyVskAU%2FpP%2BnvzjAc= %2Bazs%2BQ1G54jPNW6Wo%3D&reserved=3D0 >> > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --LGEEhWQZN5PxIGxBMw1EEjciIUGhrkI50-- --JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAG6CsACgkQ7iZktA5Y 2kNwhAf+KjYPcq/SWgt9faaPezWe1pN+pjCEvqBxq5FVKqFiG0PoszY+Qpck/pNP l8Yf08SUl6tl3tdvl+jfonZLWDUnfbGRRUwmcil+1TWGNq8+7n4RDW73WLnQWOAI z9ZxINLUFkyAi7mMDE7yJfF4l5W1yeUOeOqun3Ww5m5ztyyfQFaX1+SM4RyOAsLe 79ELbFhwa/ycqyYpMaW2c17CP74nKkirg5cJqHW06ZXfNYbCpGIYJKk3Sa2C/rsA YHlLwjC8PScdL6XMswbukqLzjHOKzBVkfPxqhkq4f+vJk/fAlQ0TxpqufNzDJPIE LX+jCdfOJRXS/5QLrvOZvHMnCNOqAw== =Pesm -----END PGP SIGNATURE----- --JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic-- From nobody Tue Jan 19 07:21:13 2021 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 261243A159C; Tue, 19 Jan 2021 07:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 mdI9BRFTLhim; Tue, 19 Jan 2021 07:21:05 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 60E153A159E; Tue, 19 Jan 2021 07:21:05 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4DKsmw0rwCzCrKv; Tue, 19 Jan 2021 16:21:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1611069664; bh=J+XLJtYvfQpZGTGjjEwmDePktNGMWhuwcFIqlgGYi5A=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ervHUfef+/pF3mB4XbmnalB+bvYUzG+xBCG26WKzA+76QacjnLq9Kue+axlajXEsN 4G00C08eNuuB7EyVTshiCXa4c/XW8Egls6B0tTtSTSPPzA3siK6YBuLWo0mwU8f9/g lDxbLwxbVSmbQgkD/Atg87nG74EZdHaNco5VNbSkbi1VHWybjbfySmQ/LEZrUk+sZD rIcaQyj326D/urcoyQ/EHz3kbnW3dLC42QvuSEeVeA8MXs8QjqrerdZufaFBgFHVA+ oCUISwVaTThIb2Ixqh5hLtV1kwXruBw8eh/v1AXsnD3sqbF5pouiTgpwcTjq+GMwZd hj4WuYewzM0Hg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4DKsmw04jjz8sZq; Tue, 19 Jan 2021 16:21:04 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-new-block-05.txt Thread-Index: AQHW7mzEKkNbbrzxCk+23dClOwj886ovEB+A Date: Tue, 19 Jan 2021 15:21:03 +0000 Message-ID: <11344_1611069664_6006F8E0_11344_455_1_787AE7BB302AE849A7480A190F8B9330315BD0BE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@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] [core] I-D Action: draft-ietf-core-new-block-05.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 Jan 2021 15:21:07 -0000 UmUtLA0KDQpHcmVhdC4gVGhhbmtzLiANCg0KQSB2ZXJzaW9uIHdpdGggdGhlIGFncmVlZCBjaGFu Z2VzIGlzIG5vdyBwdWJsaWM6IA0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTA2LnR4dCANClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUt bmV3LWJsb2NrLyANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtY29yZS1uZXctYmxvY2sgDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMDYgDQpE aWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtY29yZS1uZXctYmxvY2stMDYNCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+IERlwqA6IE1hcmNvIFRpbG9jYSBbbWFpbHRvOm1hcmNvLnRpbG9jYUBy aS5zZV0NCj4gRW52b3nDqcKgOiBtYXJkaSAxOSBqYW52aWVyIDIwMjEgMTU6MTANCj4gw4DCoDog Qk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 DQo+IHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb207IGNvcmVAaWV0Zi5vcmcNCj4gQ2PCoDogZHJh ZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKg OiBSZTogW2NvcmVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMDUudHh0 DQo+IA0KPiBHb3QgaXQsIHRoYW5rcy4NCj4gDQo+IEJlc3QsDQo+IC9NYXJjbw0KPiANCj4gT24g MjAyMS0wMS0xOSAxMzoyNCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4g PiBIaSBNYXJjbywNCj4gPg0KPiA+IFRoZSBwcm9wb3NlZCBlZGl0cyBsb29rIGdvb2QgdG8gbWUu IFdpbGwgYmUgZml4ZWQgaW4gdGhlIGdpdGh1Yi4NCj4gPg0KPiA+IDIuMzEgaXMgbm90IG1lbnRp b25lZCBpbiBpbiB0aGUgZXhjZXJwdCB5b3UgcXVvdGVkIGZyb20gU2VjdGlvbg0KPiAzLjMgYmVj YXVzZSAyLjMxIGlzIG5vdCAqKnJlcXVpcmVkKiouIEEgc2VydmVyIG1heSBkZWNpZGUgdG8gbm90 DQo+IHJlcGx5IHdpdGggMi4zMSBhcyBhIGZ1bmN0aW9uIG9mIGl0cyBvdmVyYWxsIGxvYWQgYW5k IHByZWZlciB0bw0KPiBvYnNlcnZlIGEgcGF1c2UgYmVmb3JlIGhhbmRsaW5nIHRoZSBuZXh0IGJs b2NrLiBUaGF04oCZcyBpcyB3aHkgd2UgZG8NCj4gaGF2ZSBTSE9VTEQsIG5vdCBhIE1VU1QuDQo+ ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+ID4+IERlwqA6IE1hcmNvIFRpbG9jYSBbbWFpbHRvOm1hcmNvLnRpbG9jYUByaS5z ZV0gRW52b3nDqcKgOiBtYXJkaSAxOQ0KPiA+PiBqYW52aWVyIDIwMjEgMTI6NTAgw4DCoDogc3Vw anBzLWlldGZAanBzaGFsbG93LmNvbTsgQk9VQ0FEQUlSDQo+IE1vaGFtZWQNCj4gPj4gVEdJL09M TiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGNvcmVAaWV0Zi5vcmcgQ2PCoDoNCj4g Pj4gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZyBPYmpl dMKgOiBSZToNCj4gW2NvcmVdDQo+ID4+IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXct YmxvY2stMDUudHh0DQo+ID4+DQo+ID4+IEhpIEpvbiwNCj4gPj4NCj4gPj4gVGhhbmtzLCBwbGVh c2Ugc2VlIGJlbG93IHNvbWUgbWlub3IgcG9pbnRzLCBvdGhlcndpc2UgaXQgbG9va3MNCj4gZ29v ZA0KPiA+PiB0byBtZS4NCj4gPj4NCj4gPj4gQmVzdCwNCj4gPj4gL01hcmNvDQo+ID4+DQo+ID4+ ICogU2VjdGlvbiAzLjEgLSBJbiB0aGUgcGFyYWdyYXBoIHJpZ2h0IGFib3ZlIFRhYmxlIDIsIHMv d2l0aCBDb0FQDQo+ID4+IG92ZXIgVENQL3dpdGggQ29BUCBvdmVyIHJlbGlhYmxlIHRyYW5zcG9y dHMuDQo+ID4+DQo+ID4+ICogU2VjdGlvbiAzLjEgLSBJIHRoaW5rIHRoYXQgdGhlIG5ldyBmaW5h bCBwYXJhZ3JhcGggIk5vdGUgdGhhdA0KPiBpZg0KPiA+PiBRLUJsb2NrMSAob3IgUS1CbG9jazIp IC4uLiBNVVNUIE5PVCBiZSBpbmNsdWRlZC4iIGZpdHMgYmV0dGVyDQo+IGJlZm9yZQ0KPiA+PiB0 aGUgcGFyYWdyYXBoIGRpc2N1c3NpbmcgdGhlIHVzZSBvZiBPU0NPUkUsIGkuZS4gIlRoZSBRLUJs b2NrMQ0KPiBhbmQNCj4gPj4gLi4uDQo+ID4+IGZyYWdtZW50YXRpb24gb2YgcmVxdWVzdHMuIg0K PiA+Pg0KPiA+PiAqIFNlY3Rpb24gMy4zIC0gIkZvciBOb24tY29uZmlybWFibGUgdHJhbnNtaXNz aW9uLCBubyByZXNwb25zZSBpcw0KPiA+PiByZXF1aXJlZCB1bnRpbCB0aGUgc3VjY2Vzc2Z1bCBy ZWNlaXB0IG9mIHRoZSBib2R5IGJ5IHRoZSBzZXJ2ZXINCj4gb3INCj4gPj4gc29tZSBvZiB0aGUg cGF5bG9hZHMgaGF2ZSBub3QgYXJyaXZlZCBhZnRlciBhIHRpbWVvdXQgYW5kIGENCj4gPj4gcmV0 cmFuc21pdCBtaXNzaW5nIHBheWxvYWRzIHJlc3BvbnNlIGlzIG5lZWRlZC4iDQo+ID4+DQo+ID4+ IMKgwqAgU2hvdWxkbid0IHRoaXMgYWxzbyBtZW50aW9uIHRoZSBjYXNlIHdoZXJlIHRoZSBzZXJ2 ZXIgc2VuZHMgYQ0KPiA+PiAyLjMxIHJlc3BvbnNlIHRvIGhhdmUgdGhlIGNsaWVudCBjb250aW51 ZSBzZW5kaW5nIHRoZSBuZXh0DQo+ID4+IE1BWF9QQVlMT0FEUyBwYXlsb2Fkcz8NCj4gPj4NCj4g Pj4gKiBTZWN0aW9uIDMuMyAtIFByb3Bvc2VkIGNsYXJpZmljYXRpb24gZm9yIHRoZSA0LjAyIHJl c3BvbnNlDQo+IGNvZGU6DQo+ID4+DQo+ID4+IMKgwqDCoCAiRWl0aGVyIHRoaXMgUmVzcG9uc2Ug Q29kZSAoaW4gY2FzZSBvZiBDb25maXJtYWJsZSByZXF1ZXN0KQ0KPiBvciBhDQo+ID4+IHJlc2V0 IG1lc3NhZ2UgKGluIGNhc2Ugb2YgTm9uLWNvbmZpcm1hYmxlIHJlcXVlc3QpIE1VU1QgYmUNCj4g cmV0dXJuZWQNCj4gPj4gaWYgdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBRLUJsb2Nr MSBPcHRpb24uIg0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiAyMDIxLTAxLTE4IDE1OjE2LCBzdXBqcHMt aWV0ZkBqcHNoYWxsb3cuY29tIHdyb3RlOg0KPiA+Pj4gSGkgTWFyY28sDQo+ID4+Pg0KPiA+Pj4g V2UgaGF2ZSB1cGRhdGVkIGdpdGh1YiBbMV0gdG8gdGFrZSBhY2NvdW50IG9mIHlvdXIgbGF0ZXN0 DQo+IGNvbW1lbnRzDQo+ID4+IGZvciB5b3VyIHJldmlldy4NCj4gPj4+IFJlZ2FyZHMNCj4gPj4+ DQo+ID4+PiBKb24NCj4gPj4+IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Jan 19 22:22:16 2021 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 F249C3A07C8; Tue, 19 Jan 2021 22:22:13 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmYL_VkA7Pfr; Tue, 19 Jan 2021 22:22:11 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6D13A0408; Tue, 19 Jan 2021 22:22:03 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee66007cbfe996-88ec8; Wed, 20 Jan 2021 14:21:50 +0800 (CST) X-RM-TRANSID: 2ee66007cbfe996-88ec8 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.51.51]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee16007cbfd5ba-500c5; Wed, 20 Jan 2021 14:21:50 +0800 (CST) X-RM-TRANSID: 2ee16007cbfd5ba-500c5 From: "SuLi" To: "'Valery Smyslov'" , Cc: , References: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> In-Reply-To: <0b4201d6e813$e191cde0$a4b569a0$@smyslov.net> Date: Wed, 20 Jan 2021 14:21:50 +0800 Message-ID: <007e01d6eef4$89ff7720$9dfe6560$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdboExmPFEy9rbFYSuuk7Fj0p4nv4AG4W4Tg Content-Language: zh-cn Archived-At: Subject: [Dots] =?gb2312?b?tPC4tDogIElQUiBjb25maXJtYXRpb24gZm9yIGRyYWZ0?= =?gb2312?b?LWlldGYtZG90cy10ZWxlbWV0cnktMTU=?= 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 Jan 2021 06:22:14 -0000 I don't have any IPR nor I'm aware of any IPR related to this draft. Thank you. Best Regards! Su Li(=CB=DA=C0=F5) -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Dots [mailto:dots-bounces@ietf.org] =B4=FA=B1=ED = Valery Smyslov =B7=A2=CB=CD=CA=B1=BC=E4: 2021=C4=EA1=D4=C211=C8=D5 20:19 =CA=D5=BC=FE=C8=CB: draft-ietf-dots-telemetry@ietf.org =B3=AD=CB=CD: dots-chairs@ietf.org; dots@ietf.org =D6=F7=CC=E2: [Dots] IPR confirmation for draft-ietf-dots-telemetry-15 Hi authors, while preparing shepherd write-up for draft-ietf-dots-telemetry-15,=20 in accordance with BCP78 and BCP79 I have to ask all authors and contributors whether=20 they are aware of any IPR regarding this document. Can you please confirm that you are not aware of any IPR=20 or disclose any IPR you are aware of that are concerned with this draft. I'd also like to ask authors about implementation status of the draft. Are there any implementations you are aware of? Regards, Valery. _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 19 22:51:39 2021 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 4276C3A0C17; Tue, 19 Jan 2021 22:51:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Cc: dots-chairs@ietf.org, dots@ietf.org, iesg-secretary@ietf.org, valery@smyslov.net Message-ID: <161112548625.28112.10453863673560177950@ietfa.amsl.com> Date: Tue, 19 Jan 2021 22:51:26 -0800 Archived-At: Subject: [Dots] Publication has been requested for draft-ietf-dots-telemetry-15 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 Jan 2021 06:51:34 -0000 Valery Smyslov has requested publication of draft-ietf-dots-telemetry-15 as Proposed Standard on behalf of the DOTS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/