From nobody Tue Dec 1 15:22:15 2020 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 1195D3A0B16; Tue, 1 Dec 2020 15:22:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ebben Aries via Datatracker To: Cc: dots@ietf.org, draft-ietf-dots-rfc8782-bis.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160686493001.17117.9724616300764054197@ietfa.amsl.com> Reply-To: Ebben Aries Date: Tue, 01 Dec 2020 15:22:10 -0800 Archived-At: Subject: [Dots] Yangdoctors last call review of draft-ietf-dots-rfc8782-bis-02 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: Tue, 01 Dec 2020 23:22:10 -0000 Reviewer: Ebben Aries Review result: Ready 2 modules in this draft: - ietf-dots-signal-channel@2020-09-24.yang - iana-dots-signal-channel@2020-09-24.yang YANG compiler errors or warnings (pyang 2.4.0, yanglint 1.9.2) - No compiler errors or warnings however pyang 2.4.0 is currently the only compiler verified to emit YANG sx:structure data in tree format. Instance data could not yet easily be validated given the current linters/compilers. Links to previous relevant reviews: - https://datatracker.ietf.org/doc/review-ietf-dots-rfc8782-bis-00-yangdoctors-early-aries-2020-09-23/ - https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-14-yangdoctors-lc-lindblad-2020-11-26/ Updates/comments since prior review ------------------------------------ While there is a -02 version of the draft posted since the YANG Doctor review request against -01, the updates reflect textual wording of the draft and YANG module contents have not changed thus this review encompasses the latest -02 version as well. Since the -00 version, the following previous review comments have now been addressed: - Textual wording in the draft around IPv4/IPv6 prefix lengths - The prefix for 'ietf-dots-signal-channel' is now updated to a more descriptive 'dots-signal' - Import prefixes are updated to reflect usage of the imported module prefix - Author email address corrections - The prefix for 'iana-dots-signal-channel' is now updated to a more descriptive 'iana-dots-signal' and thus this module now carries with it a revision bump Updated nodes: The 'lifetime' node has now been updated from a single 'int32' value to a union of uint32 and int32 with a range restriction. From a modeling standpoint for the uint32 value, while '0' is invalid in a request, it appears the status retrieval could very well still report '0' for a brief period of time thus assume this is the reason for not implementing a range restriction on the uint32 value as well indicating "1..4294967295"? Now, when this translates into CBOR representation, the wire protocol I will assume (Sorry just briefly researched this re: CBOR) will differentiate 2 separate types here so we don't run into -1 and 4294967295 both representing indefinite lifetime? While I share similar opinions to Jan's review in review-ietf-dots-telemetry-14-yangdoctors-lc-lindblad-2020-11-26 in relation to the draft and data structure definitions, I believe from a YANG doctor review standpoint, we are ready to move forward with this draft/module-set. From nobody Tue Dec 1 18:15:08 2020 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 D3E3C3A0EA8; Tue, 1 Dec 2020 18:15:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ebben Aries via Datatracker To: Cc: last-call@ietf.org, dots@ietf.org, draft-ietf-dots-signal-call-home.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160687530080.19371.6938919650571126245@ietfa.amsl.com> Reply-To: Ebben Aries Date: Tue, 01 Dec 2020 18:15:00 -0800 Archived-At: Subject: [Dots] Yangdoctors last call review of draft-ietf-dots-signal-call-home-11 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, 02 Dec 2020 02:15:01 -0000 Reviewer: Ebben Aries Review result: Almost Ready 1 module in this draft: - ietf-dots-call-home@2020-10-15.yang YANG compiler errors or warnings (pyang 2.4.0, yanglint 1.9.2) - No compiler errors or warnings however pyang 2.4.0 is currently the only compiler verified to emit YANG sx:structure data in tree format. Instance data could not yet easily be validated given the current linters/compilers. General comments/clarifications on the draft/modules: ------------------------------------------------------ - My first thoughts after reading through the draft is some use of terminology that I find confusing or rather need some clarification. This draft reverses the TCP/TLS or DTLS connection initiation but the DOTS roles of client/server remain the same. If that is the case, then I ask why does the terminology need to deviate that of the DOTS signal channel terminology to make use of 'Call Home DOTS client' and 'Call Home DOTS server' (Starting in Section 1.2)? - Regarding 'redirected-signal' for alternate call home clients. What occurs if 'alt-ch-client-record' is populated with a list of IP addresses in addition to the mandatory 'alt-ch-client' FQDN? If DTLS or TLS connections are unable to be satisfied to the client after the PUT request, is there any sort of fallback when the TTL cache expires? From what I gather, the 'alt-ch-client-record' takes precedence over resolving the mandatory FQDN attribute and/or acts like a static host record should both be encapsulated in the PUT request. - Regarding the structure augment of 'source' nodes. It seems to me (and this may be a misinterpretation) that this is not entirely specific to 'call home'. Is there any reason why these nodes do not exist directly in rfc8782-bis or can you help clarify why this is specific to this scenario only? Module ietf-dots-call-home: ------------------------------------------------------ - Node 'alt-ch-client' is targeted to represent a FQDN with a loose string type. Should this rather be of type 'inet:domain-name'? Looking at other usage among dots related modeling is mixed between the 2 types for representing a FQDN so this comment can also apply to my alternate dots YD review. Overall, from a YANG module/structure standpoint it appears on the right track for complementing the 'ietf-dots-signal-channel' module and see no major issues. From nobody Tue Dec 1 22:27:33 2020 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 6C6AE3A1144; Tue, 1 Dec 2020 22:27:24 -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 syq-u1L7ruqm; Tue, 1 Dec 2020 22:27:22 -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 BCBB63A115E; Tue, 1 Dec 2020 22:27:19 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4Cm8CB1pnYz7tTB; Wed, 2 Dec 2020 07:27:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1606890438; bh=/5XkC+MJ7wef2vjj9fOfORzQRB/aKNltrGXWcJWD2Qc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=mS8Hn2ltA1R1wuqZG48FWnfCzSjiU85kTzcFtbD+rsHkSvMp56YFk/9KEKJqO2cnd 028lqnwxHXCK2gSnr/U5hg70ePx/U+DEVIF7bvEHO2N16Ap+5EkxHpusSHJ/UMrxGp 4D49Vgd7jRH5Sg1ZT5d0Fyz2lWVlmYBtfV8Zy0tuLLXCYZf3DG09nRfmYrEWjZKeLV zjYZkDJfWTceIt8mhnHnh1Z75gnvbfeousv0OSxvANznglnU0A2spjGfyPC8qDg2f6 FuK4q/L6VOLXmc1GBSLinQs+bnJHZPVm5e6XixFjPdmIRifHEBzApFEEiOgYA9gP7U zVGHkQOu7nXng== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4Cm8CB0Xl2z3wbD; Wed, 2 Dec 2020 07:27:18 +0100 (CET) From: To: Ebben Aries , "yang-doctors@ietf.org" CC: "dots@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-dots-rfc8782-bis-02 Thread-Index: AQHWyDjM9AmiMrs1DEaAhG8kuNZu16njVGqg Date: Wed, 2 Dec 2020 06:27:17 +0000 Message-ID: <14692_1606890438_5FC733C6_14692_114_1_787AE7BB302AE849A7480A190F8B9330315926BE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160686493001.17117.9724616300764054197@ietfa.amsl.com> In-Reply-To: <160686493001.17117.9724616300764054197@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Yangdoctors last call review of draft-ietf-dots-rfc8782-bis-02 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, 02 Dec 2020 06:27:31 -0000 SGkgRWJiZW4sIA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIA0KDQpQbGVhc2Ugc2VlIGlubGlu ZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZcKgOiBFYmJlbiBBcmllcyB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3Jn XQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDIgZMOpY2VtYnJlIDIwMjAgMDA6MjINCj4gw4DCoDog eWFuZy1kb2N0b3JzQGlldGYub3JnDQo+IENjwqA6IGRvdHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt ZG90cy1yZmM4NzgyLWJpcy5hbGxAaWV0Zi5vcmc7IGxhc3QtDQo+IGNhbGxAaWV0Zi5vcmcNCj4g T2JqZXTCoDogWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMt cmZjODc4Mi1iaXMtDQo+IDAyDQo+IA0KPiBSZXZpZXdlcjogRWJiZW4gQXJpZXMNCj4gUmV2aWV3 IHJlc3VsdDogUmVhZHkNCj4gDQo+IDIgbW9kdWxlcyBpbiB0aGlzIGRyYWZ0Og0KPiAtIGlldGYt ZG90cy1zaWduYWwtY2hhbm5lbEAyMDIwLTA5LTI0LnlhbmcNCj4gLSBpYW5hLWRvdHMtc2lnbmFs LWNoYW5uZWxAMjAyMC0wOS0yNC55YW5nDQo+IA0KPiBZQU5HIGNvbXBpbGVyIGVycm9ycyBvciB3 YXJuaW5ncyAocHlhbmcgMi40LjAsIHlhbmdsaW50IDEuOS4yKQ0KPiAtIE5vIGNvbXBpbGVyIGVy cm9ycyBvciB3YXJuaW5ncyBob3dldmVyIHB5YW5nIDIuNC4wIGlzIGN1cnJlbnRseQ0KPiB0aGUg b25seQ0KPiAgIGNvbXBpbGVyIHZlcmlmaWVkIHRvIGVtaXQgWUFORyBzeDpzdHJ1Y3R1cmUgZGF0 YSBpbiB0cmVlIGZvcm1hdC4NCj4gSW5zdGFuY2UNCj4gICBkYXRhIGNvdWxkIG5vdCB5ZXQgZWFz aWx5IGJlIHZhbGlkYXRlZCBnaXZlbiB0aGUgY3VycmVudA0KPiBsaW50ZXJzL2NvbXBpbGVycy4N Cj4gDQo+IExpbmtzIHRvIHByZXZpb3VzIHJlbGV2YW50IHJldmlld3M6DQo+IA0KPiAtDQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3Jldmlldy1pZXRmLWRvdHMtcmZjODc4Mi1i aXMtMDAtDQo+IHlhbmdkb2N0b3JzLWVhcmx5LWFyaWVzLTIwMjAtMDktMjMvDQo+IC0NCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtZG90cy10ZWxlbWV0cnkt MTQtDQo+IHlhbmdkb2N0b3JzLWxjLWxpbmRibGFkLTIwMjAtMTEtMjYvDQo+IA0KPiBVcGRhdGVz L2NvbW1lbnRzIHNpbmNlIHByaW9yIHJldmlldw0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IFdoaWxlIHRoZXJlIGlzIGEgLTAyIHZlcnNpb24gb2YgdGhlIGRy YWZ0IHBvc3RlZCBzaW5jZSB0aGUgWUFORw0KPiBEb2N0b3IgcmV2aWV3IHJlcXVlc3QgYWdhaW5z dCAtMDEsIHRoZSB1cGRhdGVzIHJlZmxlY3QgdGV4dHVhbA0KPiB3b3JkaW5nIG9mIHRoZSBkcmFm dCBhbmQgWUFORyBtb2R1bGUgY29udGVudHMgaGF2ZSBub3QgY2hhbmdlZCB0aHVzDQo+IHRoaXMg cmV2aWV3IGVuY29tcGFzc2VzIHRoZSBsYXRlc3QgLTAyIHZlcnNpb24gYXMgd2VsbC4NCg0KW01l ZF0gSSBjb25maXJtLiANCg0KPiANCj4gU2luY2UgdGhlIC0wMCB2ZXJzaW9uLCB0aGUgZm9sbG93 aW5nIHByZXZpb3VzIHJldmlldyBjb21tZW50cyBoYXZlDQo+IG5vdyBiZWVuDQo+IGFkZHJlc3Nl ZDoNCj4gDQo+IC0gVGV4dHVhbCB3b3JkaW5nIGluIHRoZSBkcmFmdCBhcm91bmQgSVB2NC9JUHY2 IHByZWZpeCBsZW5ndGhzDQo+IC0gVGhlIHByZWZpeCBmb3IgJ2lldGYtZG90cy1zaWduYWwtY2hh bm5lbCcgaXMgbm93IHVwZGF0ZWQgdG8gYSBtb3JlDQo+ICAgZGVzY3JpcHRpdmUgJ2RvdHMtc2ln bmFsJw0KPiAtIEltcG9ydCBwcmVmaXhlcyBhcmUgdXBkYXRlZCB0byByZWZsZWN0IHVzYWdlIG9m IHRoZSBpbXBvcnRlZA0KPiBtb2R1bGUgcHJlZml4DQo+IC0gQXV0aG9yIGVtYWlsIGFkZHJlc3Mg Y29ycmVjdGlvbnMNCj4gLSBUaGUgcHJlZml4IGZvciAnaWFuYS1kb3RzLXNpZ25hbC1jaGFubmVs JyBpcyBub3cgdXBkYXRlZCB0byBhIG1vcmUNCj4gICBkZXNjcmlwdGl2ZSAnaWFuYS1kb3RzLXNp Z25hbCcgYW5kIHRodXMgdGhpcyBtb2R1bGUgbm93IGNhcnJpZXMNCj4gd2l0aCBpdCBhDQo+ICAg cmV2aXNpb24gYnVtcA0KPiANCj4gVXBkYXRlZCBub2RlczoNCj4gDQo+IFRoZSAnbGlmZXRpbWUn IG5vZGUgaGFzIG5vdyBiZWVuIHVwZGF0ZWQgZnJvbSBhIHNpbmdsZSAnaW50MzInIHZhbHVlDQo+ IHRvIGEgdW5pb24gb2YgdWludDMyIGFuZCBpbnQzMiB3aXRoIGEgcmFuZ2UgcmVzdHJpY3Rpb24u ICBGcm9tIGENCj4gbW9kZWxpbmcgc3RhbmRwb2ludCBmb3IgdGhlIHVpbnQzMiB2YWx1ZSwgd2hp bGUgJzAnIGlzIGludmFsaWQgaW4gYQ0KPiByZXF1ZXN0LCBpdCBhcHBlYXJzIHRoZSBzdGF0dXMg cmV0cmlldmFsIGNvdWxkIHZlcnkgd2VsbCBzdGlsbA0KPiByZXBvcnQgJzAnIGZvciBhIGJyaWVm IHBlcmlvZCBvZiB0aW1lIHRodXMgYXNzdW1lIHRoaXMgaXMgdGhlIHJlYXNvbg0KPiBmb3Igbm90 IGltcGxlbWVudGluZyBhIHJhbmdlIHJlc3RyaWN0aW9uIG9uIHRoZSB1aW50MzIgdmFsdWUgYXMg d2VsbA0KPiBpbmRpY2F0aW5nICIxLi40Mjk0OTY3Mjk1Ij8NCg0KW01lZF0gWWVzLiANCg0KPiAN Cj4gTm93LCB3aGVuIHRoaXMgdHJhbnNsYXRlcyBpbnRvIENCT1IgcmVwcmVzZW50YXRpb24sIHRo ZSB3aXJlDQo+IHByb3RvY29sIEkgd2lsbCBhc3N1bWUgKFNvcnJ5IGp1c3QgYnJpZWZseSByZXNl YXJjaGVkIHRoaXMgcmU6IENCT1IpDQo+IHdpbGwgZGlmZmVyZW50aWF0ZSAyIHNlcGFyYXRlIHR5 cGVzIGhlcmUgc28gd2UgZG9uJ3QgcnVuIGludG8gLTEgYW5kDQo+IDQyOTQ5NjcyOTUgYm90aCBy ZXByZXNlbnRpbmcgaW5kZWZpbml0ZSBsaWZldGltZT8NCg0KW01lZF0gV2hldGhlciB0aGlzIGlz IGFuIGluZGVmaW5pdGUgbGlmZXRpbWUgaXMgZGV0ZXJtaW5lZCBmcm9tIHRoZSBDQk9SIG1ham9y IHR5cGUgKDEgaW4gdGhpcyBjYXNlIGZvciBDQk9SIGtleSAxNCAobGlmZXRpbWUpKS4gICAgDQoN Cj4gDQo+IFdoaWxlIEkgc2hhcmUgc2ltaWxhciBvcGluaW9ucyB0byBKYW4ncyByZXZpZXcgaW4N Cj4gcmV2aWV3LWlldGYtZG90cy10ZWxlbWV0cnktMTQteWFuZ2RvY3RvcnMtbGMtbGluZGJsYWQt MjAyMC0xMS0yNiBpbg0KPiByZWxhdGlvbiB0byB0aGUgZHJhZnQgYW5kIGRhdGEgc3RydWN0dXJl IGRlZmluaXRpb25zLCBJIGJlbGlldmUgZnJvbQ0KPiBhIFlBTkcgZG9jdG9yIHJldmlldyBzdGFu ZHBvaW50LCB3ZSBhcmUgcmVhZHkgdG8gbW92ZSBmb3J3YXJkIHdpdGgNCj4gdGhpcyBkcmFmdC9t b2R1bGUtc2V0Lg0KDQpbTWVkXSBUaGFuayB5b3UuDQoNCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Dec 2 00:24:47 2020 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 4F87A3A0B97; Wed, 2 Dec 2020 00:24:39 -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 4z3zXeFac5Vt; Wed, 2 Dec 2020 00:24:37 -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 5A9F13A09F1; Wed, 2 Dec 2020 00:24:34 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4CmBpS4XRfzCqvZ; Wed, 2 Dec 2020 09:24:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1606897472; bh=NBVT/ryZwCOGXQ3+STQsIc4hqg0EZM74+/8/N+Vim3M=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=AtNAXW1bLcGjT85TF+Mx8rj7L/wFsBqz4KQmqS4vG4uahWkuY0X2r88qazypgc4qK hn1YxiguLfjR0Z628GlztcVxId2EWD0d8+vGoSV0mXZ5+H14gID2PFbZxeIUFeXOCt yLczkNCuAvGMhWeajVlFuVpa/bNBguVF2L6YxQeqktmfNgVTfrszIbxDW7DotGqVHR 3xGyXufrF077Q8ywjvmPW2ORf3W0iRbAMmxd+eIx/Y4+18uf35DYFKdUxhsF+q6kQQ 86vjvZNMVrGRwTCcOVgK3NLG22euy//aRBGNIJUNgvCC5fqvwT+0rcXDjIZxMtnZZd oCRxy6T7V//xA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4CmBpS3DLTzyQN; Wed, 2 Dec 2020 09:24:32 +0100 (CET) From: To: Ebben Aries , "yang-doctors@ietf.org" CC: "last-call@ietf.org" , "dots@ietf.org" , "draft-ietf-dots-signal-call-home.all@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-dots-signal-call-home-11 Thread-Index: AQHWyFDypo2ub2EOoEeUMFmG0Z4QvanjV/ZQ Date: Wed, 2 Dec 2020 08:24:32 +0000 Message-ID: <26007_1606897472_5FC74F40_26007_281_3_787AE7BB302AE849A7480A190F8B9330315947A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160687530080.19371.6938919650571126245@ietfa.amsl.com> In-Reply-To: <160687530080.19371.6938919650571126245@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Yangdoctors last call review of draft-ietf-dots-signal-call-home-11 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, 02 Dec 2020 08:24:40 -0000 SGkgRWJiZW4sIA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiANCg0KUGxlYXNlIHNl ZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gRGXCoDogRWJiZW4gQXJpZXMgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBp ZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAyIGTDqWNlbWJyZSAyMDIwIDAzOjE1DQo+ IMOAwqA6IHlhbmctZG9jdG9yc0BpZXRmLm9yZw0KPiBDY8KgOiBsYXN0LWNhbGxAaWV0Zi5vcmc7 IGRvdHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4gaG9tZS5hbGxA aWV0Zi5vcmcNCj4gT2JqZXTCoDogWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtDQo+IGhvbWUtMTENCj4gDQo+IFJldmlld2VyOiBFYmJl biBBcmllcw0KPiBSZXZpZXcgcmVzdWx0OiBBbG1vc3QgUmVhZHkNCj4gDQo+IDEgbW9kdWxlIGlu IHRoaXMgZHJhZnQ6DQo+IC0gaWV0Zi1kb3RzLWNhbGwtaG9tZUAyMDIwLTEwLTE1LnlhbmcNCj4g DQo+IFlBTkcgY29tcGlsZXIgZXJyb3JzIG9yIHdhcm5pbmdzIChweWFuZyAyLjQuMCwgeWFuZ2xp bnQgMS45LjIpDQo+IC0gTm8gY29tcGlsZXIgZXJyb3JzIG9yIHdhcm5pbmdzIGhvd2V2ZXIgcHlh bmcgMi40LjAgaXMgY3VycmVudGx5DQo+IHRoZSBvbmx5DQo+ICAgY29tcGlsZXIgdmVyaWZpZWQg dG8gZW1pdCBZQU5HIHN4OnN0cnVjdHVyZSBkYXRhIGluIHRyZWUgZm9ybWF0Lg0KPiBJbnN0YW5j ZQ0KPiAgIGRhdGEgY291bGQgbm90IHlldCBlYXNpbHkgYmUgdmFsaWRhdGVkIGdpdmVuIHRoZSBj dXJyZW50DQo+IGxpbnRlcnMvY29tcGlsZXJzLg0KPiANCj4gR2VuZXJhbCBjb21tZW50cy9jbGFy aWZpY2F0aW9ucyBvbiB0aGUgZHJhZnQvbW9kdWxlczoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0gTXkgZmlyc3QgdGhvdWdodHMg YWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSBkcmFmdCBpcyBzb21lIHVzZSBvZg0KPiB0ZXJtaW5v bG9neQ0KPiAgIHRoYXQgSSBmaW5kIGNvbmZ1c2luZyBvciByYXRoZXIgbmVlZCBzb21lIGNsYXJp ZmljYXRpb24uICBUaGlzDQo+IGRyYWZ0DQo+ICAgcmV2ZXJzZXMgdGhlIFRDUC9UTFMgb3IgRFRM UyBjb25uZWN0aW9uIGluaXRpYXRpb24gYnV0IHRoZSBET1RTDQo+IHJvbGVzIG9mDQo+ICAgY2xp ZW50L3NlcnZlciByZW1haW4gdGhlIHNhbWUuICBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGVuIEkg YXNrDQo+IHdoeSBkb2VzIHRoZQ0KPiAgIHRlcm1pbm9sb2d5IG5lZWQgdG8gZGV2aWF0ZSB0aGF0 IG9mIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsDQo+IHRlcm1pbm9sb2d5IHRvDQo+ICAgbWFrZSB1 c2Ugb2YgJ0NhbGwgSG9tZSBET1RTIGNsaWVudCcgYW5kICdDYWxsIEhvbWUgRE9UUyBzZXJ2ZXIn DQo+IChTdGFydGluZyBpbg0KPiAgIFNlY3Rpb24gMS4yKT8NCg0KW01lZF0gV2UgdXNlZCB0byBo YXZlIHRoZSBzYW1lIHRlcm1pbm9sb2d5IGluIHByZXZpb3VzIHZlcnNpb25zIGJ1dCByZXZpZXdl cnMgd2VyZSBjb25mdXNlZCBhYm91dCB0aGF0LCB3aGljaCBpcyBhIGZhaXIgY29tbWVudCBCVFcg Zm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCiogdGhlIGRpZmZlcmVuY2VzIGFib3V0IGhvdyB0 aGUgc2Vzc2lvbnMgYXJlIGVzdGFibGlzaGVkIGFuZCBtYWludGFpbmVkIChoZWFydGJlYXRzKS4g DQoqIHRoZSBiYXNlIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUgaXMgZGlmZmVyZW50IGZyb20gdGhl IG9uIGluIFJGQzg4MTEuDQoqIHRoZSBjYWxsIGhvbWUgY2FuIGJlIHVzZWQgd2l0aCBvciB3aXRo b3V0IHRoZSBiYXNlIHNpZ25hbCBjaGFubmVsLiANCiogdGhlIGNoZWNrcyBkb25lIGJ5IGEgIkRP VFMgY2xpZW50L3NlcnZlciIgaW4gdGhlIGJhc2Ugc3BlYyBhcmUgbm90IHRoZSBzYW1lIGFzIHRo b3NlIGluIHRoZSBjYWxsIGhvbWUuDQoNClRvIGFkZHJlc3MgdGhlc2UgY29tbWVudHMsIHdlIHdl bnQgd2l0aCB0aGUgY3VycmVudCB0ZXJtaW5vbG9neSBpbiB0aGUgZHJhZnQuIFRoaXMgdGVybWlu b2xvZ3kgaGFzIHRoZSBhZHZhbnRhZ2UgdG8gaGVscCB0byBiZXR0ZXIgYXJ0aWN1bGF0ZSB0aGUg Y28tZXhpc3RlbmNlIGNvbnNpZGVyYXRpb25zIChzZWUgU2VjdGlvbiA0KS4gIA0KDQo+IA0KPiAt IFJlZ2FyZGluZyAncmVkaXJlY3RlZC1zaWduYWwnIGZvciBhbHRlcm5hdGUgY2FsbCBob21lIGNs aWVudHMuDQo+IA0KPiAgIFdoYXQgb2NjdXJzIGlmICdhbHQtY2gtY2xpZW50LXJlY29yZCcgaXMg cG9wdWxhdGVkIHdpdGggYSBsaXN0IG9mDQo+IElQDQo+ICAgYWRkcmVzc2VzIGluIGFkZGl0aW9u IHRvIHRoZSBtYW5kYXRvcnkgJ2FsdC1jaC1jbGllbnQnIEZRRE4/DQoNCltNZWRdIFRoZSBvbGQg c2Vzc2lvbiBpcyBjbG9zZWQgYW5kIGEgbmV3IG9uZSBpcyBlc3RhYmxpc2hlZCB3aXRoIHRoZSBh bHRlcm5hdGUgY2FsbCBob21lIGNsaWVudC4NCg0KICBJZg0KPiBEVExTIG9yIFRMUw0KPiAgIGNv bm5lY3Rpb25zIGFyZSB1bmFibGUgdG8gYmUgc2F0aXNmaWVkIHRvIHRoZSBjbGllbnQgYWZ0ZXIg dGhlIFBVVA0KPiByZXF1ZXN0LA0KPiAgIGlzIHRoZXJlIGFueSBzb3J0IG9mIGZhbGxiYWNrIHdo ZW4gdGhlIFRUTCBjYWNoZSBleHBpcmVzPw0KDQpbTWVkXSBZZXMuIFRoaXMgaXMgY292ZXJlZCBi eSB0aGlzIHRleHQ6IA0KIlRoZSBwcm9jZXNzaW5nIG9mIHRoZSBUVEwgaXMgZGVmaW5lZCBpbiBT ZWN0aW9uIDQuNiBvZiBbSS1ELmlldGYtZG90cy1yZmM4NzgyLWJpc10uIg0KDQorIFNlY3Rpb24g NC42IG9mIHJmYzg3ODItYmlzIHNheXMgdGhlIGZvbGxvd2luZzogDQoNCiAgIFRoaXMgZmFsbGJh Y2sgbWVjaGFuaXNtIGlzIHRyaWdnZXJlZCBpbW1lZGlhdGVseSB1cG9uDQogICBleHBpcnkgb2Yg dGhlIFRUTCwgZXhjZXB0IHdoZW4gYSBERG9TIGF0dGFjayBpcyBhY3RpdmUuIA0KDQogIEZyb20N Cj4gd2hhdCBJDQo+ICAgZ2F0aGVyLCB0aGUgJ2FsdC1jaC1jbGllbnQtcmVjb3JkJyB0YWtlcyBw cmVjZWRlbmNlIG92ZXIgcmVzb2x2aW5nDQo+IHRoZQ0KPiAgIG1hbmRhdG9yeSBGUUROIGF0dHJp YnV0ZSBhbmQvb3IgYWN0cyBsaWtlIGEgc3RhdGljIGhvc3QgcmVjb3JkDQo+IHNob3VsZCBib3Ro DQo+ICAgYmUgZW5jYXBzdWxhdGVkIGluIHRoZSBQVVQgcmVxdWVzdC4NCg0KW01lZF0gWWVzLiBP bmUgb2YgdGhlIHJlYXNvbnMgZm9yIHRoaXMgZGVzaWduIGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9u IDQuNiBvZiBbSS1ELmlldGYtZG90cy1yZmM4NzgyLWJpc106DQoNCiAgIER1cmluZyBhIEREb1Mg YXR0YWNrLCB0aGUgRE5TIHNlcnZlciBtYXkgYmUgdGhlIHRhcmdldCBvZiBhbm90aGVyDQogICBE RG9TIGF0dGFjaywgdGhlIGFsdGVybmF0ZSBET1RTIHNlcnZlcidzIElQIGFkZHJlc3NlcyBjb252 ZXllZCBpbiB0aGUNCiAgIDUuMDMgcmVzcG9uc2UgaGVscCB0aGUgRE9UUyBjbGllbnQgc2tpcCB0 aGUgRE5TIGxvb2t1cCBvZiB0aGUNCiAgIGFsdGVybmF0ZSBET1RTIHNlcnZlciwgYXQgdGhlIGNv c3Qgb2YgdHJ1c3RpbmcgdGhlIGZpcnN0IERPVFMgc2VydmVyDQogICB0byBwcm92aWRlIGFjY3Vy YXRlIGluZm9ybWF0aW9uLiANCg0KPiANCj4gLSBSZWdhcmRpbmcgdGhlIHN0cnVjdHVyZSBhdWdt ZW50IG9mICdzb3VyY2UnIG5vZGVzLiAgSXQgc2VlbXMgdG8gbWUNCj4gKGFuZCB0aGlzDQo+ICAg bWF5IGJlIGEgbWlzaW50ZXJwcmV0YXRpb24pIHRoYXQgdGhpcyBpcyBub3QgZW50aXJlbHkgc3Bl Y2lmaWMgdG8NCj4gJ2NhbGwNCj4gICBob21lJy4NCg0KW01lZF0gSSBjb25maXJtLiBUaGlzIGlz IGV4cGxpY2l0bHkgbWVudGlvbmVkIGluIHRoZSBkcmFmdDogDQoNCiJUaGlzIGlzIGFuIG9wdGlv bmFsIGF0dHJpYnV0ZSBmb3IgdGhlIGJhc2UgRE9UUyBzaWduYWwgY2hhbm5lbCBvcGVyYXRpb25z LiINCg0KICBJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB0aGVzZSBub2RlcyBkbyBub3QgZXhpc3Qg ZGlyZWN0bHkNCj4gaW4NCj4gICByZmM4NzgyLWJpcyBvciBjYW4geW91IGhlbHAgY2xhcmlmeSB3 aHkgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGlzDQo+IHNjZW5hcmlvDQo+ICAgb25seT8NCg0KW01l ZF0gVGhpcyB3YXMgb24gcHVycG9zZS4gUkZDODc4MiB3YXMgc2NvcGVkIHRvIGNvbnZleSB0aGUg bWluaW1hbCByZXF1aXJlZCBpbmZvcm1hdGlvbiB0byBzZWVrIGZvciBtaXRpZ2F0aW9uLiBXZSBk b24ndCBjaGFuZ2UgdGhhdCBzY29wZSBpbiA4NzgyLWJpcy4gIA0KDQo+IA0KPiANCj4gTW9kdWxl IGlldGYtZG90cy1jYWxsLWhvbWU6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtIE5vZGUgJ2FsdC1jaC1jbGllbnQnIGlzIHRhcmdl dGVkIHRvIHJlcHJlc2VudCBhIEZRRE4gd2l0aCBhIGxvb3NlDQo+IHN0cmluZw0KPiAgIHR5cGUu ICBTaG91bGQgdGhpcyByYXRoZXIgYmUgb2YgdHlwZSAnaW5ldDpkb21haW4tbmFtZSc/DQoNCltN ZWRdIEdvb2QgY2F0Y2guIFdpbGwgYmUgZml4ZWQuIA0KDQogIExvb2tpbmcNCj4gYXQgb3RoZXIN Cj4gICB1c2FnZSBhbW9uZyBkb3RzIHJlbGF0ZWQgbW9kZWxpbmcgaXMgbWl4ZWQgYmV0d2VlbiB0 aGUgMiB0eXBlcyBmb3INCj4gICByZXByZXNlbnRpbmcgYSBGUUROIHNvIHRoaXMgY29tbWVudCBj YW4gYWxzbyBhcHBseSB0byBteSBhbHRlcm5hdGUNCj4gZG90cyBZRA0KPiAgIHJldmlldy4NCg0K W01lZF0gV2UgYXJlIHVzaW5nIGluZXQ6ZG9tYWluLW5hbWUgZm9yIHRhcmdldC1mcWRuIGJ1dCBu b3QgYWx0LXNlcnZlci4gV2lsbCBmaXggdGhhdCBhcyB3ZWxsLiANCg0KPiANCj4gT3ZlcmFsbCwg ZnJvbSBhIFlBTkcgbW9kdWxlL3N0cnVjdHVyZSBzdGFuZHBvaW50IGl0IGFwcGVhcnMgb24gdGhl DQo+IHJpZ2h0IHRyYWNrIGZvciBjb21wbGVtZW50aW5nIHRoZSAnaWV0Zi1kb3RzLXNpZ25hbC1j aGFubmVsJyBtb2R1bGUNCj4gYW5kIHNlZSBubyBtYWpvciBpc3N1ZXMuDQo+IA0KDQpbTWVkXSBU aGFuayB5b3UgZm9yIHlvdXIgY2FyZWZ1bCByZXZpZXcuIA0KDQoNCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KCg== From nobody Wed Dec 2 00:56:01 2020 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 4EB1A3A0A83; Wed, 2 Dec 2020 00:55:59 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160689935927.23647.9799734636110453185@ietfa.amsl.com> Date: Wed, 02 Dec 2020 00:55:59 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-03.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: Wed, 02 Dec 2020 08:55:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification Authors : Mohamed Boucadair Jon Shallow Tirumaleswar Reddy.K Filename : draft-ietf-dots-rfc8782-bis-03.txt Pages : 120 Date : 2020-12-02 Abstract: This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. This document obsoletes RFC 8782. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-rfc8782-bis-03 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 Wed Dec 2 01:11:22 2020 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 1184D3A121F for ; Wed, 2 Dec 2020 01:11:20 -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 AGM02pK7TX_8 for ; Wed, 2 Dec 2020 01:11:18 -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 436483A121C for ; Wed, 2 Dec 2020 01:11:18 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4CmCrN497Pz1yWF; Wed, 2 Dec 2020 10:11:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1606900276; bh=B2m0N4NiPosph/IPRJtsgpIuHzNNubNNxQnJn45y7E0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JqEQgG9yO8P/8ESMSBARFGcMgWmZMVXUp92qyNaWHeeoN5Zj7UUL0p5xPcPKgeG8y s/8bw4avU/gozWzTWjaT62I6femklPuNxhk2hGPMrPNF8FHcr1UAHSM/rgIH2Aogve A7ScgL6DLn5z/KMIg+1eSHBLDUSDnEs5huurfgYboPgYvjWcVj3tIk2chRWwUL619i am5W3NObPgvu0gGdLLvcRu8uNC823q853Sn7kLZuuFPkDM7Wak6vsbK7lwTQwln/2F AOoBkY9hJ95nA/8lDr2RV1PcKv+T1r3bDRr5zNKAq5JTqb1RjG51qVP13QFVJ3KVNu 1bVUfGYtvOfdg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4CmCrN3FzYz1xpb; Wed, 2 Dec 2020 10:11:16 +0100 (CET) From: To: "dots@ietf.org" , Ebben Aries Thread-Topic: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-03.txt Thread-Index: AQHWyIj6R0aFcR92nEGuCcrutmxMganjg7xA Date: Wed, 2 Dec 2020 09:11:16 +0000 Message-ID: <3628_1606900276_5FC75A34_3628_18_1_787AE7BB302AE849A7480A190F8B933031594812@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160689935927.23647.9799734636110453185@ietfa.amsl.com> In-Reply-To: <160689935927.23647.9799734636110453185@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-03.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, 02 Dec 2020 09:11:20 -0000 Hi all,=20 This version fixes an issue with "alt-server": s/string/inet:domain-name.= =20 Thanks Ebben for catching this.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 2 d=E9cembre 2020 09:56 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of > the IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel Specification > Authors : Mohamed Boucadair > Jon Shallow > Tirumaleswar Reddy.K > Filename : draft-ietf-dots-rfc8782-bis-03.txt > Pages : 120 > Date : 2020-12-02 >=20 > Abstract: > This document specifies the Distributed Denial-of-Service Open > Threat > Signaling (DOTS) signal channel, a protocol for signaling the > need > for protection against Distributed Denial-of-Service (DDoS) > attacks > to a server capable of enabling network traffic mitigation on > behalf > of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and > configuration > purposes. >=20 > This document obsoletes RFC 8782. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-rfc8782-bis-03 >=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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots ___________________________________________________________________________= ______________________________________________ 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 Dec 3 23:56:32 2020 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 2086C3A1414; Thu, 3 Dec 2020 23:56: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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160706859106.25013.3218395596590092512@ietfa.amsl.com> Date: Thu, 03 Dec 2020 23:56:31 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 07:56: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 Specification Authors : Mohamed Boucadair Jon Shallow Tirumaleswar Reddy.K Filename : draft-ietf-dots-rfc8782-bis-04.txt Pages : 120 Date : 2020-12-03 Abstract: This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. This document obsoletes RFC 8782. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-rfc8782-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 3 23:58:26 2020 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 C088D3A1416 for ; Thu, 3 Dec 2020 23:58:23 -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, RCVD_IN_DNSWL_BLOCKED=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 32qB6hh0j7kD for ; Thu, 3 Dec 2020 23:58:21 -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 8CA7B3A1412 for ; Thu, 3 Dec 2020 23:58:21 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4CnQ7J0xrsz5x1D for ; Fri, 4 Dec 2020 08:58:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607068700; bh=sqbJ/X/PU+UO99V6mP0iTHidt+xv2GUJ4CMzHlYDRA8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LTp5/OGZtXRUWzxWTqo9VSmPW4ODWURwVp6EwTeifRCnAerc7XCG9YFwuLjmVEetG 3Ri3dPQEknP7EQlb7mSzRScl54OMwzMkInHaoGHYfKI6C3XShOVWeOctMHkP3MZ+c8 jOSR+ZhX5fXQhmG7z2YN9EBhi8Swl7BHh73MTbinJrgs273dToWt5Ny/WQGBbg0YlP GtUlAlPR9hk2ShqyhHdzt1r2pnECHQiuJac8wwzNUBxZ0eA/TWz6esl0Q/FE31DE3X lj22gPQk220+enaeVv+F/G31PCjVHHKZKGaMRsPoVjWQ+P611/iZw/NEJhqPPGP0tL sJoAvwHJtN1qA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4CnQ7J0CH9zyQM for ; Fri, 4 Dec 2020 08:58:20 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-04.txt Thread-Index: AQHWyhL/JM+1J4Q9hkKWz2v29fSN6anmkfbg Date: Fri, 4 Dec 2020 07:58:18 +0000 Message-ID: <26475_1607068700_5FC9EC1C_26475_138_1_787AE7BB302AE849A7480A190F8B9330315966BE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160706859106.25013.3218395596590092512@ietfa.amsl.com> In-Reply-To: <160706859106.25013.3218395596590092512@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-04.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, 04 Dec 2020 07:58:24 -0000 Hi all,=20 This version fixes some few nits kindly reported by Valery (Thanks).=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: vendredi 4 d=E9cembre 2020 08:57 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of > the IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel Specification > Authors : Mohamed Boucadair > Jon Shallow > Tirumaleswar Reddy.K > Filename : draft-ietf-dots-rfc8782-bis-04.txt > Pages : 120 > Date : 2020-12-03 >=20 > Abstract: > This document specifies the Distributed Denial-of-Service Open > Threat > Signaling (DOTS) signal channel, a protocol for signaling the > need > for protection against Distributed Denial-of-Service (DDoS) > attacks > to a server capable of enabling network traffic mitigation on > behalf > of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and > configuration > purposes. >=20 > This document obsoletes RFC 8782. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-rfc8782-bis-04 >=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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots ___________________________________________________________________________= ______________________________________________ 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 Fri Dec 4 00:21:18 2020 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 1F92C3A15B7; Fri, 4 Dec 2020 00:21:16 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: dots@ietf.org, dots-chairs@ietf.org, iesg-secretary@ietf.org, valery@smyslov.net Message-ID: <160707007611.26300.12697028014596838435@ietfa.amsl.com> Date: Fri, 04 Dec 2020 00:21:16 -0800 Archived-At: Subject: [Dots] Publication has been requested for draft-ietf-dots-rfc8782-bis-04 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 08:21:16 -0000 Valery Smyslov has requested publication of draft-ietf-dots-rfc8782-bis-04 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-rfc8782-bis/ From nobody Fri Dec 4 09:39:00 2020 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 CF8D33A0EA0 for ; Fri, 4 Dec 2020 09:38:52 -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 ftVoktcXN5Jw for ; Fri, 4 Dec 2020 09:38:49 -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 7EF923A0E73 for ; Fri, 4 Dec 2020 09:38:48 -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 1klF2b-0001bf-Jb; Fri, 04 Dec 2020 17:38:45 +0000 From: To: "'Jan Lindblad'" , , , , References: <160639060194.12249.1456224995663816670@ietfa.amsl.com> In-Reply-To: <160639060194.12249.1456224995663816670@ietfa.amsl.com> Date: Fri, 4 Dec 2020 17:38:44 -0000 Message-ID: <07b501d6ca64$50409b40$f0c1d1c0$@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: AQHiFDrMrymD3lYywpOFfmsyN+LrPanQMdZQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] Yangdoctors last call review of draft-ietf-dots-telemetry-14 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, 04 Dec 2020 17:38:59 -0000 Hi Jan, Thanks for the detailed review. As there has been some responses to different parts, I will try to answer the parts not responded to, but indicate what has been responded to. Please see inline. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jan > Lindblad via Datatracker > Sent: 26 November 2020 11:37 > To: yang-doctors@ietf.org > Cc: last-call@ietf.org; draft-ietf-dots-telemetry.all@ietf.org; dots@ietf.org > Subject: [Dots] Yangdoctors last call review of draft-ietf-dots-telemetry-14 > > Reviewer: Jan Lindblad > Review result: Almost Ready > > Dear Dots Authors, NETMOD WG, > > This is my YD LC review of draft-ietf-dots-telemetry-14. This draft contains > two YANG modules, ietf-dots-telemetry and module ietf-dots-mapping. Both > modules are unusual from a YANG perspective in that they consist of solely > typedefs, groupings and sx:structures, and that their purpose is to define > message bodies for a domain specific management protocol. Answered by [Andy] [2] Commented on by [Med] [3] Answered by [Med] [4] More clarifications by [Andy] [5] > > Since my previous review of this module (-09, June 2020) the underpinnings of > the modules have changed significantly with a new RFC in the works, addressing > the fundamental issues pointed out at that time. Very good & impressive. I > still think there are important issues to resolve, so I will call the current > state of -14 "Almost Ready". > > Links to previous relevant reviews: > https://datatracker.ietf.org/doc/review-ietf-dots-rfc8782-bis-00-yangdoctors - > early-aries-2020-09-23/ > https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-09-yangdoctors- > early-lindblad-2020-06-30/ > > Because of this hitherto unusual application of YANG, the usual YD review > procedures are not really applicable. Whoever reads this should feel free to > comment on which perspectives should be included (or not) in an YD review of a > YANG module defining a new protocol. > > I think the YD review should not be expected to cover the > usability/interoperability of the newly defined protocol as a whole. E.g. which > messages are sent when, what is the relevant/reasonable content in each > message, are there any races or scalability issues, etc. IMO, such an analysis > is essential, but too much work for an YD review (and outside my area of > expertise). I have placed my review focus on the clear interpretation of the > YANG modules, since that will be key to interoperability. Answered by [Andy] [2] > > When YANG is mapped to NETCONF or RESTCONF, there are entire RFCs > devoted to > describing how that mapping is done, from what "mandatory" actually means in > the protocol and how keys are sent, all the way to how the XML or JSON > payloads > are constructed and potential error messages. A lot more of that mapping is now > present in this document, but I still find many aspects that are > undefined/unclear. Answered by [Andy] [2] [Jon] The goal in the signal channel was to have the payload in CBOR for packet size optimization, including mapping the CBOR parameter names into integers to further reduce the data size. This channel is run over CoAP over (D)TLS. The CBOR mappings are key here, but YANG is used to describe the different CBOR entities / mappings as far as possible. So, this is not really the classic YANG where other mappings can easily be derived from it. An agent needs to know how to process a particular CBOR parameter/value and whether it can be safely ignored if it is not known. [Jon] The data channel is essentially RESTONF/YANG over HTTPS where the YANG in this draft is simply "augment"ing and hence follows the classic YANG usage. For this draft, the data channel is only used to exchange vendor mapping details (which the signal channel can subsequently use with the information reduced as much as possible in size). > > #1 mandatory true > > A few elements are marked mandatory true in the model. The meaning of this is > not defined in the draft. I would expect this means clients as well as servers > MUST provide a value for the mandatory element in each message if the parent > element exists. This would be like how mandatory elements in YANG > actions/rpcs/notifications work (and different from how mandatory works with > configuration data in NETCONF/YANG). > > Section 7.1 states: "DOTS telemetry attributes are optionally signaled and > therefore MUST NOT be treated as mandatory fields in the DOTS signal channel > protocol." Answered by [Med] [4] > This blanket statement makes things less clear for me. Can I trust > the YANG mandatory and key statements to indicate what has to be included, > and > everything else is optional? If so, I would advise to state just that. [Jon] We have found some mandatory usage which is no longer required - this will be corrected. > > #2 key > > There are many key statements around these modules. The exact meaning of > the > key keyword in this dots-signal protocol is not defined. Are key sets always > unique in a list? Answered by [Med] [4] > Are keys mandatory? Answered by [Med] [4] > Are there any sequencing requirements on > keys, e.g. do keys need to be sent first (as in NETCONF) in a list element? Answered by [Med] [4] > Such a requirement may not be unreasonable for servers with limited resources. > > #3) if-feature > > The ietf-dots-mapping.yang module defines one YANG feature and a few > instances > of model statements conditional on it with an if-feature statement. There is a > description for how a server advertises support for this specific feature (by > including a very particular leaf in one of the messages). From a YANG mapping > perspective, it might have been better to have a general mechanism for > advertising features. With the current specification, no other features can > (ever) be added in a backwards compatible way. Answered by [Med] [4] > > #5) augment or sx:augment-structure > > The draft is using augment (but means sx:augment-structure) and > sx:augment-structure. Are implementors allowed to use augment in their > implementations? If so, how would a client know if an augmented model is in > use? Section 6.1.2 states that servers MUST reject messages when "attribute > values are not acceptable". Does that have any implications for augment? Answered by [Med] [4] > > #6) deviations > > Deviations are never mentioned. Are implementors allowed to deviate from the > protocol in any way, if declared using deviation statements? If so, how would a > client know if a deviated model is in use? Answered by [Med] [4] > > #7) config true|false > > RFC 8791 (which defines sx:structure) expressly states that config true and > false statements have no defined meaning and will be ignored in sx:structure. > Therefore it's very good that this draft defines behavior for the GET operation > with respect to config true and config false elements. Nothing is said about > how the config attribute plays with PUT, POST or DELETE however. Question raised by [Med] [4] [Jon] For the DOTS data channel, the YANG is augment, and so config true|false still stand for this. > > #8) PATCH > > Is the PATCH HTTP operation supported in this context? It is never mentioned. > If so, it's is unclear how it would work in relation to the protocol HTTP > headers, the tsid mechanism and the YANG mandatory concept. If not, that > might > be good to point out somewhere. Answered by [Med] [4] > > #9) Payload encoding references > > As far as I understand, the message payloads are meant to be encoded in JSON > or > CBOR. Answered by [Med] [4] [Jon} CBOR is only used for the signal channel. However, JSON is used for the payload over the data channel when updating the vendor mappings. > This draft has no references to the relevant documents describing these > encodings (https://tools.ietf.org/html/rfc7951 and > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-13). Answered by [Med] [4] > > And now a few minor comments on particular points or wordings. > > #10) The tree diagram in Fig. 30 is not using the correct format (see the other > tree diagrams). Answered by [Med] [1] > > #11) Section 6.3.1 states "The overlapped lower numeric 'tsid' MUST be > automatically deleted and no longer be available." Since this mechanism is a > central part of the protocol, I would think specifying exactly what > "overlapped" means would improve interoperability. Answered by [Med] [1] > > #12) Section 6.3.1 states "If no target clause is included in the request, this > is an indication that the baseline information applies for the DOTS client > domain as a whole." Define "target clause" (= tsid?) Answered by [Med] [1] > > #13) Section 4.5 states "The use of "identities" is thus suboptimal from a > message compactness standpoint." Clearly, but they excel in forward > extensibility. There may be cases where the identities would be better and even > more compact than an alternative solution without them. To rule out all use of > identities based on a blanket statement like this does not seem like a good > design practice. I suggest to remove this sentence. Answered by [Med] [1] > > #14) In the YANG, there is a choice with a single case "case > server-to-client-only". This way of using choice is a little unusual, but it > works. Answered by [Med] [1] > > #15) In the YANG, there is a list telemetry without any key. This is allowed > for config false lists in NETCONF/YANG, and it could be allowed in this > protocol. For a constrained device, however, this situation may not be ideal. > Without a key, the only way for a client to read this information is to read it > all at once. If that is the only reasonable use case for this information, you > kan keep it as is. If this data may be large, a different way of modeling may > be in order so that data could be requested a little at a time. Answered by [Med] [1] > > #16) Section 6.1.1 states " 'server-originated-telemetry' under > 'max-config-values' to 'true' ('false' is used otherwise). If > 'server-originated-telemetry' is not present in a response, this is equivalent > to receiving a request with 'server-originated-telemetry' set to 'false'. " In > YANG, this is usually expressed by adding "default false" to the leaf. Answered by [Med] [1] > > #17) There are many leafs in the models that have no default, no mandatory and > no description which tells what happens if the leaf is not provided. E.g. what > happens if "query-type" is not specified? In part answered by [Med] [1] [Jon] If the server does not indicate that it supports any query-type, then the client will be unable to use any of the potential query-type to reduce the returned data content from the server. > #18) Many lists have "unit" as a key. This can work, but is an unusual choice. > It opens up for sending the same information several times over with different > units. Answered by [Med] [1] > > #19) Section 7.1.1 states "At least one of the attributes 'target-prefix', > 'target-fqdn', 'target-uri', 'alias-name', or 'mid-list' MUST be present in the > target definition." This may be a good thing to add in a must-statement, or at > least in a description statement in the module. Answered by [Med] [1] > > #20) Section 7.1.1 mentions a "optional subattribute" Please define this term, > or change to a defined term. Answered by [Med] [1] > > #21) leaf-list alias-name {type string; description "An alias name that points > to a resource."; Unclear; what is a resource here? What is the format of the > string? Could this be a leafref? Answered by [Med] [1] > > #22) There are typedefs called "unit-type" and "unit". I would suggest changing > at least one of those names so that readers have a chance at understanding how > they differ. Also, some of their content overlaps, so maybe one could > incorporate the other? Answered by [Med] [1] > > #23) Similarly for grouping percentile-config and grouping percentile. Names > that better reflect their content and usage would be good. Answered by [Med] [1] > > #24) There are still a few instances of augment in the model. They should be > sx:augment-stucture. Answered by [Med] [1] > > #25) I didn't go through the entire table in section 11, but I looked at a few > random leafs from the model. A couple seem to be missing in section 11, e.g. > last-updated and rate-limit. Maybe good to go through the latest version to > really check that all relevant elements are listed. > Answered by [Med] [1] [1] https://mailarchive.ietf.org/arch/msg/dots/VbVmlhvao-kk_Z2GzTkV2QN7Qbw/ [2] https://mailarchive.ietf.org/arch/msg/dots/JWg4NYsKXGzj_mGu-TUsMf9E4kM/ [3] https://mailarchive.ietf.org/arch/msg/dots/L5vEwPU5B9d-srruoV26Wq6mQco/ [4] https://mailarchive.ietf.org/arch/msg/dots/qwO96u377lEdzx6G_HL_QppxEGo/ [5] https://mailarchive.ietf.org/arch/msg/dots/1A8z9MiqDOQzPamYdHWqXvwQgrk/ From nobody Mon Dec 7 09:35:44 2020 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 77B073A1623; Mon, 7 Dec 2020 09:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 64AjrE6f3mKl; Mon, 7 Dec 2020 09:35:39 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30087.outbound.protection.outlook.com [40.107.3.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 E72113A1621; Mon, 7 Dec 2020 09:35:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HKCUAi2/5PI7llMsYhmvlIP9lZ3zbfV9qkc9CtpLm8807vr5DynRJ+Mayyb+bvcgs+eqBeaU87DBuCIrW/AxliZiOBQj67763xj1XroreMHN3/nNl91XUy/S0ic/DCwT0MbUciZ0oJOIVy8NJmMh+G26liA/b4RS9NlhaJEs8LptB2s90XmvKXtYXqNpnUBgQyX/L3AGPnw8pcWC/0FfFjLv+Lec4UlK5o1ieslF7DfyUUfzZ+w6zCASX4qyX+fGGYePF/pR2zlXA9IE7SbHG4z5pEoQZYDpcIz2R8GKo7V+dNQHQwMrgn73LHgDZOP4tQCJi77g3xfYM9BinklnRA== 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=3f87YWe2fBKo9/43Z9KbdJav/wBrq3TN5EH95qm/TNo=; b=QihNKB6/sYE+lKQOMyr19aHV4UfZHsuzJGBqWK3zo9e3XjRJkqQGuZIb/E5tBMjHLd2i181qYWs/xHr6OreWRR02KqeKq6eZCSxdtR3/zcGVU/A0XytllgpRJlpiYkTZ+UMUbsPatAe8H6KSsPamghBhjappE+C1zXiwyV7TC6NKDk3pveLMqPwKOROvj2TOCPKcCCczV1i0rzOqmCZrZE/jjvfppA00KqpPQliKBPkMzsDRE5iUlz+NbtUYCFlj2rknfPb8ThbaWm5+pT0NDnyIAivNntrGT33RDjtFSctLKI76pD8PLbsdHeO3Q8/483N7wBZb3UnJxjDfu6jbpQ== 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=3f87YWe2fBKo9/43Z9KbdJav/wBrq3TN5EH95qm/TNo=; b=U+hXHb0Wp4wwvt0F8kx+/aMQYXbFgEJyFR2cOLUGmiaGr3d92Jdnicj5vZuPXqqCawdT92Owuk7ae/qKjMXd/rH9wFDOnrCcw5m6IzoHb/HnQAGqxmJ7lDWrGO0U6sfJQzbwet0YFMFlOl4UcewvIgjt4HvN/QaJty0dKNHhe6E= 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 DB8P189MB0668.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fd::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Mon, 7 Dec 2020 17:35:36 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3632.023; Mon, 7 Dec 2020 17:35:36 +0000 To: "core@ietf.org WG (core@ietf.org)" Cc: dots@ietf.org 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: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> Date: Mon, 7 Dec 2020 18:35:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU" X-Originating-IP: [45.83.91.172] X-ClientProxiedBy: HE1P195CA0012.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::22) 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.6] (45.83.91.172) by HE1P195CA0012.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Mon, 7 Dec 2020 17:35:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c152c4d8-6583-40ef-302c-08d89ad6819b X-MS-TrafficTypeDiagnostic: DB8P189MB0668: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4941; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eo/kp/O1cVAbczPeqlkgc1XDVyUJHWIc7LZLUrKxZhW/JwbI85P42AB4N9+7tSNjMX9XyCQrTiCv+CUaYvk3OY9A7lgox8DziKoCHqZS/R7jdao5yxYTrWzWNm+OwSk3jhulc8KtgBMC5E77ciQ6/aZm+1NRBs2T407huwBlT7TdPoJKXFWB8iR93LbdUeVXywigsn1x0cu2VwYakK+5Cu7LyoBscr39A6j+3jyFnKDOry9K32XrB/0Vw1xwQwBbP40kztxP5WIIOLd3Ini+pH6uBJuLOVEXYEuKux4Br+NToFpA82BXxuVc/1cZxXS/jDq6TLTM/ufS9eTnnKXSXPJdrnJq9/7gbEayELYs6JEJs1NHbuOV8GP+pSt8o2EXiv2/pUxzpl1rkt1571Kk8EY8QfkNbskXpi2dh9F1ZRc8Cm2me6v415rP6fqf0t7u8YFsOOMFIqZmkPOvYkR9+KB6azrpaX1EDkGCeUkxgqo= 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)(376002)(366004)(396003)(39860400002)(136003)(346002)(26005)(66946007)(2616005)(478600001)(44832011)(31696002)(8936002)(235185007)(5660300002)(83380400001)(2906002)(8676002)(66556008)(66476007)(966005)(6916009)(956004)(186003)(33964004)(52116002)(21480400003)(31686004)(16526019)(36756003)(16576012)(6486002)(4326008)(450100002)(86362001)(316002)(6666004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?dkpZUXRObFVkMHk0R0QxWUt6Y2NOTXBKNnhkV1ZId0xjenB6QzYrcW93eUQ4?= =?utf-8?B?WkFXNURrYXN6bTdRb1JIUjJ0NVFFWlk2MXdDWDdrZit6VnVMMzR1RXRadGdT?= =?utf-8?B?M3A5QlBZQnRGSFl3aUQrN3N2dFBPVGpFbDN5V3JwNisxc3dOM2l2Tk1UdEVD?= =?utf-8?B?UHllNzNBVnQyWFVrdDUvcGR0V3JuYlpqd3JsblNuTnYrcmJpZHNmOXAydFZo?= =?utf-8?B?YVI5QXJiTWkwTlhGYnUzY082TC9OZmRieDVsZE9xQVl4Y2dTejcxOFZCUmRU?= =?utf-8?B?Z2NLVEV5cm5zVGJCTzJnZUxuRHNxMjFiSmF5SHFvaHMrR1A0YWF0QTlJeTdU?= =?utf-8?B?dUgyU050WHk4ck5TTDdjRnlUMitkWTVKK3ltSW1vaHpHbzArZ0RETDFONmpY?= =?utf-8?B?bjR3aHQrUE5wTFpCM1YvTDdZTGdqRlR2K3hLQ0Y2MCtFaTIyOCtveWx6UVJl?= =?utf-8?B?bW9FeVU0WCtmRnQwT3JEckNpWHBQc3R6a2ljcHQvZCsvMEF4SEhPd1R3OFJJ?= =?utf-8?B?WXh3S2hzZnduM2Rxakdjd2p3OUV2Rk9XRDhWSk16VlRjUitOT3RJQkV2cGxS?= =?utf-8?B?VWxRdVZlODJvMzc1TS9EU21MdlJNR2t2Wll1LzJUeS9BdnhnZDBiTE9WUFYv?= =?utf-8?B?WU02R2pQR2JnOTNIdE5HYXJlK1FqMmNnWkNEb2xsVkYrOEtqTGNlSldvNDNQ?= =?utf-8?B?UzQxS3FaN0lQWGhRNCtKd2p2TDBrRjNqNTBPRnFVSTRFTWxGdExFRWU1cHpt?= =?utf-8?B?eWZ3ZHFaNTEycVVPL2lXM0ROVW5KdDVaVFB3RFFVK0RJaVVBbG00ZUcwUkRO?= =?utf-8?B?b2xuVUoweWs5ampXU1p0VmhiakVHS2lSOTlraFFjN2dQei9jd2tKVGRKcHZC?= =?utf-8?B?bVJUSUFYZUx1SDVMQ0ZEOUlDbVd2L05UNVp4RWErY2JrVWdUU1p2TjNoSTVZ?= =?utf-8?B?UXdQRFVzKzFvWlFIbzJuZGJjT0tySmpIM3JhenpFWFhsd0I4cE82QWdMQkxE?= =?utf-8?B?UGpNZjJSWnFOcHJkN29wMXV4QUxQYmwzNFZMbEFsQ2lyUXhlYS91TFZSdk8z?= =?utf-8?B?bFhDYVc4aHI2akdiK3pJY1I4NVRuSWJSbU9MWjFtREN0VDVHcCtucm9rVGxR?= =?utf-8?B?WEM2OThEQnlxampiYk5iaHpQc29HM0RwM2prSlNhNjhYYWJndjViczhzalhE?= =?utf-8?B?aER6M3BUWXdlb1lqVWhydlNPUnVhcU13dWdrYVJWQzhTRVhVUTdRM1BXdVpr?= =?utf-8?B?eStyVG03aHR4SHBGWFV1MFFGODMrS0NWRndJMzRvejR6Q0QwTE9xc01IZS9X?= =?utf-8?Q?vjwDqb7nz+6ywXXK18XzNk30rU/FGzvqon?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: c152c4d8-6583-40ef-302c-08d89ad6819b X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2020 17:35:36.2080 (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: HhYWmRz78MTyFTnSbA7NMwqZr+vMAH2ulivs2MlQcOi0yVIdMdonchRyZzhFDKx6D8Tqgmzw1duxB5epfFhLAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0668 Archived-At: Subject: [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, 07 Dec 2020 17:35:43 -0000 --733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU Content-Type: multipart/mixed; boundary="E5Dt77EqPom0sUe5jaq6FcmvQyW8EnuTD" --E5Dt77EqPom0sUe5jaq6FcmvQyW8EnuTD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Following the recent clarifications from the authors [1], this mail starts a Working Group Last Call on: https://tools.ietf.org/html/draft-ietf-core-new-block-02 This WGLC will end on Tuesday, 22nd of December. This WGLC is also copied to the DOTS WG mailing list. Best, Marco and Jaime [1] https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvjiL= I/ --=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 --E5Dt77EqPom0sUe5jaq6FcmvQyW8EnuTD-- --733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/OZ+AACgkQ7iZktA5Y 2kPuXgf/aWufiZvwjVgI+TFEXaA/HQ5R+aWjDkIrjD4IMMo2k/tLdYkqzg4DXI5V S+Gj+63BNae4y0Jc+FxhNFiNWu7fWOlODtSzjFXYfIMSZMI4AafJ7u/yTn2Oz/Vw AAkaZBjJnFYHtTf/nEF6SdSdTo+P2dfRUkXrOutJ5Q5ii3SfOxct3/iT/Mx1N0ip sO8SWNU18+FkhFwUONFgIRcWTihAC/xy+or0rYLBQrxx3krGeG3cOxC6+ocr9MTP 962Q36bKwfOdou2MpaHBwRhe0viawB0Xl1a3sragDoWYSHNzBdZe/i+aJnaFJSYz j7mHyb0pOGBVIuc2tXeBfDub5DyPVg== =UwCw -----END PGP SIGNATURE----- --733nuSFU4JnZFY0A3B6iw1sj3rJGFgSbU-- From nobody Tue Dec 8 06:37:06 2020 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 337393A0F39; Tue, 8 Dec 2020 06:37:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160743822116.18686.13373433603199332190@ietfa.amsl.com> Date: Tue, 08 Dec 2020 06:37:01 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-15.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: Tue, 08 Dec 2020 14:37:01 -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) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Jon Shallow Filename : draft-ietf-dots-telemetry-15.txt Pages : 113 Date : 2020-12-08 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal Distributed Denial-of- Service attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-15 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-15 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 Tue Dec 8 06:47:26 2020 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 EA3C13A0F39; Tue, 8 Dec 2020 06:47:21 -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 iCwlVVt-Z_xE; Tue, 8 Dec 2020 06:47:19 -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 207393A0F3A; Tue, 8 Dec 2020 06:47:19 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4Cr31K5Jf5z2yYP; Tue, 8 Dec 2020 15:47:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607438837; bh=mO4Ku+6CxqsGj/3Nqls0E1O+8i2r5v9gnudz2nSI+Cg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ftDgm+vqKS+N+lyzwsdLmRw9IJiUuDkj88nUC+ZpYuOZ2ACaqs/xO5SfXzCjANGNL eW4WqKbb4XPgxLz2I7W5MTCsxDWWgkq9xS7Doc5RrlkdiEajcNsl8fba+2Rj+hW0hn iyCtxsaUoB69T5GNAj6jQ/wpBxKhTfHlC++tdSzhoe+uxLdHs7GRPrgnrWVaoYTuZG U6CYAHYTgw74Lr2c0qjJbYzxbXcfZG+Bi9LgRYBH/yDRaAOGgtQYyV+sNaFnF8bOZM EBjIkMFCO0Ze0/hDMN8HqgMrtTaQYkzB6DqXqjIGe+tyC2xqVkiuuhs8xXHL8D0RSb 3ahjXnUZ2uV7A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4Cr31K3p4Xz1xpk; Tue, 8 Dec 2020 15:47:17 +0100 (CET) From: To: "supjps-ietf@jpshallow.com" , 'Jan Lindblad' , "yang-doctors@ietf.org" , "last-call@ietf.org" , "draft-ietf-dots-telemetry.all@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] Yangdoctors last call review of draft-ietf-dots-telemetry-14 Thread-Index: AQHiFDrMrymD3lYywpOFfmsyN+LrPanQMdZQgAaFDLA= Date: Tue, 8 Dec 2020 14:47:16 +0000 Message-ID: <10265_1607438837_5FCF91F5_10265_89_1_787AE7BB302AE849A7480A190F8B933031599BC9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160639060194.12249.1456224995663816670@ietfa.amsl.com> <07b501d6ca64$50409b40$f0c1d1c0$@jpshallow.com> In-Reply-To: <07b501d6ca64$50409b40$f0c1d1c0$@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] Yangdoctors last call review of draft-ietf-dots-telemetry-14 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, 08 Dec 2020 14:47:22 -0000 Hi all,=20 FWIW, an updated version of the draft is available online: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dots-telemetry-14&url2=3Ddra= ft-ietf-dots-telemetry-15&difftype=3D--hwdiff This version takes into account Jan's review: * add new text to record why keys are not used for some lists + the meaning= of keys when such statement are used. * add a reminder how mapping works in DOTS * add a warning against deviations for the signal channel + a reminder how = such deviations (and alos features) can be learned for the data channel * further insist on unit auto-scaling * rename some groupings * explain the meaning of "mandatory" use * update some descriptions and some other edits.=20=20 Cheers, Med > -----Message d'origine----- > De=A0: supjps-ietf@jpshallow.com [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: vendredi 4 d=E9cembre 2020 18:39 > =C0=A0: 'Jan Lindblad' ; yang-doctors@ietf.org; last- > call@ietf.org; draft-ietf-dots-telemetry.all@ietf.org; dots@ietf.org > Objet=A0: RE: [Dots] Yangdoctors last call review of draft-ietf-dots- > telemetry-14 >=20 > Hi Jan, >=20 > Thanks for the detailed review. >=20 > As there has been some responses to different parts, I will try to > answer the parts not responded to, but indicate what has been > responded to. >=20 > Please see inline. >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jan > Lindblad > > via Datatracker > > Sent: 26 November 2020 11:37 > > To: yang-doctors@ietf.org > > Cc: last-call@ietf.org; draft-ietf-dots-telemetry.all@ietf.org; > dots@ietf.org > > Subject: [Dots] Yangdoctors last call review of > draft-ietf-dots-telemetry-14 > > > > Reviewer: Jan Lindblad > > Review result: Almost Ready > > > > Dear Dots Authors, NETMOD WG, > > > > This is my YD LC review of draft-ietf-dots-telemetry-14. This > draft > contains > > two YANG modules, ietf-dots-telemetry and module ietf-dots- > mapping. > > Both modules are unusual from a YANG perspective in that they > consist > > of solely typedefs, groupings and sx:structures, and that their > > purpose is to define message bodies for a domain specific > management protocol. >=20 > Answered by [Andy] [2] > Commented on by [Med] [3] > Answered by [Med] [4] > More clarifications by [Andy] [5] > > > > Since my previous review of this module (-09, June 2020) the > > underpinnings > of > > the modules have changed significantly with a new RFC in the > works, > addressing > > the fundamental issues pointed out at that time. Very good & > > impressive. I still think there are important issues to resolve, > so I > > will call the > current > > state of -14 "Almost Ready". > > > > Links to previous relevant reviews: > > > https://datatracker.ietf.org/doc/review-ietf-dots-rfc8782-bis-00- > yangdoctors > - > > early-aries-2020-09-23/ > > > https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-09- > yangdoctors- > > early-lindblad-2020-06-30/ > > > > Because of this hitherto unusual application of YANG, the usual YD > > review procedures are not really applicable. Whoever reads this > should > > feel free > to > > comment on which perspectives should be included (or not) in an YD > > review > of a > > YANG module defining a new protocol. > > > > I think the YD review should not be expected to cover the > > usability/interoperability of the newly defined protocol as a > whole. E.g. > which > > messages are sent when, what is the relevant/reasonable content in > > each message, are there any races or scalability issues, etc. IMO, > > such an > analysis > > is essential, but too much work for an YD review (and outside my > area > > of expertise). I have placed my review focus on the clear > > interpretation of > the > > YANG modules, since that will be key to interoperability. >=20 > Answered by [Andy] [2] > > > > When YANG is mapped to NETCONF or RESTCONF, there are entire RFCs > > devoted to describing how that mapping is done, from what > "mandatory" > > actually means > in > > the protocol and how keys are sent, all the way to how the XML or > JSON > > payloads are constructed and potential error messages. A lot more > of > > that mapping > is now > > present in this document, but I still find many aspects that are > > undefined/unclear. >=20 > Answered by [Andy] [2] >=20 > [Jon] The goal in the signal channel was to have the payload in CBOR > for packet size optimization, including mapping the CBOR parameter > names into integers to further reduce the data size. This channel is > run over CoAP over (D)TLS. The CBOR mappings are key here, but YANG > is used to describe the different CBOR entities / mappings as far as > possible. So, this is not really the classic YANG where other > mappings can easily be derived from it. > An agent needs to know how to process a particular CBOR > parameter/value and whether it can be safely ignored if it is not > known. >=20 > [Jon] The data channel is essentially RESTONF/YANG over HTTPS where > the YANG in this draft is simply "augment"ing and hence follows the > classic YANG usage. For this draft, the data channel is only used > to exchange vendor mapping details (which the signal channel can > subsequently use with the information reduced as much as possible in > size). > > > > #1 mandatory true > > > > A few elements are marked mandatory true in the model. The meaning > of > > this > is > > not defined in the draft. I would expect this means clients as > well as > servers > > MUST provide a value for the mandatory element in each message if > the > parent > > element exists. This would be like how mandatory elements in YANG > > actions/rpcs/notifications work (and different from how mandatory > > works > with > > configuration data in NETCONF/YANG). > > > > Section 7.1 states: "DOTS telemetry attributes are optionally > signaled > > and therefore MUST NOT be treated as mandatory fields in the DOTS > > signal > channel > > protocol." >=20 > Answered by [Med] [4] > > This blanket statement makes things less clear for me. Can I trust > the > > YANG mandatory and key statements to indicate what has to be > included, > > and everything else is optional? If so, I would advise to state > just > > that. >=20 > [Jon] We have found some mandatory usage which is no longer required > - this will be corrected. > > > > #2 key > > > > There are many key statements around these modules. The exact > meaning > > of the key keyword in this dots-signal protocol is not defined. > Are > > key sets > always > > unique in a list? >=20 > Answered by [Med] [4] > > Are keys mandatory? >=20 > Answered by [Med] [4] > > Are there any sequencing requirements on keys, e.g. do keys need > to be > > sent first (as in NETCONF) in a list > element? >=20 > Answered by [Med] [4] > > Such a requirement may not be unreasonable for servers with > limited > resources. > > > > #3) if-feature > > > > The ietf-dots-mapping.yang module defines one YANG feature and a > few > > instances of model statements conditional on it with an if-feature > > statement. There > is a > > description for how a server advertises support for this specific > > feature > (by > > including a very particular leaf in one of the messages). From a > YANG > mapping > > perspective, it might have been better to have a general mechanism > for > > advertising features. With the current specification, no other > > features > can > > (ever) be added in a backwards compatible way. >=20 > Answered by [Med] [4] > > > > #5) augment or sx:augment-structure > > > > The draft is using augment (but means sx:augment-structure) and > > sx:augment-structure. Are implementors allowed to use augment in > their > > implementations? If so, how would a client know if an augmented > model > > is > in > > use? Section 6.1.2 states that servers MUST reject messages when > "attribute > > values are not acceptable". Does that have any implications for > augment? >=20 > Answered by [Med] [4] > > > > #6) deviations > > > > Deviations are never mentioned. Are implementors allowed to > deviate > > from > the > > protocol in any way, if declared using deviation statements? If > so, > > how > would a > > client know if a deviated model is in use? >=20 > Answered by [Med] [4] > > > > #7) config true|false > > > > RFC 8791 (which defines sx:structure) expressly states that config > > true > and > > false statements have no defined meaning and will be ignored in > sx:structure. > > Therefore it's very good that this draft defines behavior for the > GET > operation > > with respect to config true and config false elements. Nothing is > said > about > > how the config attribute plays with PUT, POST or DELETE however. >=20 > Question raised by [Med] [4] > [Jon] For the DOTS data channel, the YANG is augment, and so config > true|false still stand for this. > > > > #8) PATCH > > > > Is the PATCH HTTP operation supported in this context? It is never > mentioned. > > If so, it's is unclear how it would work in relation to the > protocol > > HTTP headers, the tsid mechanism and the YANG mandatory concept. > If > > not, that might be good to point out somewhere. >=20 > Answered by [Med] [4] > > > > #9) Payload encoding references > > > > As far as I understand, the message payloads are meant to be > encoded > > in > JSON > > or > > CBOR. >=20 > Answered by [Med] [4] > [Jon} CBOR is only used for the signal channel. However, JSON is > used for the payload over the data channel when updating the vendor > mappings. >=20 > > This draft has no references to the relevant documents describing > > these encodings (https://tools.ietf.org/html/rfc7951 and > > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-13). >=20 > Answered by [Med] [4] > > > > And now a few minor comments on particular points or wordings. > > > > #10) The tree diagram in Fig. 30 is not using the correct format > (see > > the > other > > tree diagrams). >=20 > Answered by [Med] [1] > > > > #11) Section 6.3.1 states "The overlapped lower numeric 'tsid' > MUST be > > automatically deleted and no longer be available." Since this > > mechanism is > a > > central part of the protocol, I would think specifying exactly > what > > "overlapped" means would improve interoperability. >=20 > Answered by [Med] [1] > > > > #12) Section 6.3.1 states "If no target clause is included in the > > request, > this > > is an indication that the baseline information applies for the > DOTS > > client domain as a whole." Define "target clause" (=3D tsid?) >=20 > Answered by [Med] [1] > > > > #13) Section 4.5 states "The use of "identities" is thus > suboptimal > > from a message compactness standpoint." Clearly, but they excel in > > forward extensibility. There may be cases where the identities > would > > be better and > even > > more compact than an alternative solution without them. To rule > out > > all > use of > > identities based on a blanket statement like this does not seem > like a > good > > design practice. I suggest to remove this sentence. >=20 > Answered by [Med] [1] > > > > #14) In the YANG, there is a choice with a single case "case > > server-to-client-only". This way of using choice is a little > unusual, > > but > it > > works. >=20 > Answered by [Med] [1] > > > > #15) In the YANG, there is a list telemetry without any key. This > is > allowed > > for config false lists in NETCONF/YANG, and it could be allowed in > > this protocol. For a constrained device, however, this situation > may > > not be > ideal. > > Without a key, the only way for a client to read this information > is > > to > read it > > all at once. If that is the only reasonable use case for this > > information, > you > > kan keep it as is. If this data may be large, a different way of > > modeling > may > > be in order so that data could be requested a little at a time. >=20 > Answered by [Med] [1] > > > > #16) Section 6.1.1 states " 'server-originated-telemetry' under > > 'max-config-values' to 'true' ('false' is used otherwise). If > > 'server-originated-telemetry' is not present in a response, this > is > equivalent > > to receiving a request with 'server-originated-telemetry' set to > 'false'. > " In > > YANG, this is usually expressed by adding "default false" to the > leaf. >=20 > Answered by [Med] [1] > > > > #17) There are many leafs in the models that have no default, no > > mandatory > and > > no description which tells what happens if the leaf is not > provided. E.g. > what > > happens if "query-type" is not specified? >=20 > In part answered by [Med] [1] > [Jon] If the server does not indicate that it supports any query- > type, then the client will be unable to use any of the potential > query-type to reduce the returned data content from the server. >=20 > > #18) Many lists have "unit" as a key. This can work, but is an > unusual > choice. > > It opens up for sending the same information several times over > with > different > > units. >=20 > Answered by [Med] [1] > > > > #19) Section 7.1.1 states "At least one of the attributes > > 'target-prefix', 'target-fqdn', 'target-uri', 'alias-name', or > > 'mid-list' MUST be present > in the > > target definition." This may be a good thing to add in a > > must-statement, > or at > > least in a description statement in the module. >=20 > Answered by [Med] [1] > > > > #20) Section 7.1.1 mentions a "optional subattribute" Please > define > > this > term, > > or change to a defined term. >=20 > Answered by [Med] [1] > > > > #21) leaf-list alias-name {type string; description "An alias name > > that > points > > to a resource."; Unclear; what is a resource here? What is the > format > > of > the > > string? Could this be a leafref? >=20 > Answered by [Med] [1] > > > > #22) There are typedefs called "unit-type" and "unit". I would > suggest > changing > > at least one of those names so that readers have a chance at > > understanding > how > > they differ. Also, some of their content overlaps, so maybe one > could > > incorporate the other? >=20 > Answered by [Med] [1] > > > > #23) Similarly for grouping percentile-config and grouping > percentile. > Names > > that better reflect their content and usage would be good. >=20 > Answered by [Med] [1] > > > > #24) There are still a few instances of augment in the model. They > > should > be > > sx:augment-stucture. >=20 > Answered by [Med] [1] > > > > #25) I didn't go through the entire table in section 11, but I > looked > > at a > few > > random leafs from the model. A couple seem to be missing in > section > > 11, > e.g. > > last-updated and rate-limit. Maybe good to go through the latest > > version > to > > really check that all relevant elements are listed. > > >=20 > Answered by [Med] [1] >=20 > [1] https://mailarchive.ietf.org/arch/msg/dots/VbVmlhvao- > kk_Z2GzTkV2QN7Qbw/ > [2] https://mailarchive.ietf.org/arch/msg/dots/JWg4NYsKXGzj_mGu- > TUsMf9E4kM/ > [3] https://mailarchive.ietf.org/arch/msg/dots/L5vEwPU5B9d- > srruoV26Wq6mQco/ > [4] > https://mailarchive.ietf.org/arch/msg/dots/qwO96u377lEdzx6G_HL_QppxE > Go/ > [5] > https://mailarchive.ietf.org/arch/msg/dots/1A8z9MiqDOQzPamYdHWqXvwQg > rk/ >=20 >=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 Tue Dec 8 06:49:59 2020 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 E65C73A0F3D for ; Tue, 8 Dec 2020 06:49:57 -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 8saPsXFnex0L for ; Tue, 8 Dec 2020 06:49:53 -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 1B1E63A0F3A for ; Tue, 8 Dec 2020 06:49:53 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4Cr34H5CHxz8txK for ; Tue, 8 Dec 2020 15:49:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607438991; bh=tMmMH/kbRXvUvHtgfg/dvwX+7YAXqPlpxhQMklFyE+0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=HuUbWLAt7x/7AWdCpiS3kjGnCIVK5R+HDS5/5N1PHdRGhOKNR5hLBglWSYUZpvGwi Evmy3oGUJFpAawyULnbF3CT2rThZuT89LU7VwGZYf25R+Oj246SPtnE0q0JbMA/J2k OstJ+Y/jB2pJSpNl4hNxbJ316fMfRH3X+L3eZ1XsH5YUiwR9757pqsdfL1aRvIgIU7 WcuYHY+F5PXs3GRrk5VeuQPhCwMr3tg8sU1Rr0n0LL8X38bamuZNQ7gbx0D06ikkzG RP3D6FFN0t6wzs6Yd7IFo7Z5YI5TZsVlfRlvtJPkwOukqV4erqPbzQOi7znyXUJbd/ wg2ApeRcVb82w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4Cr34H4Jm5z5vQH for ; Tue, 8 Dec 2020 15:49:51 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-telemetry-15.txt Thread-Index: AQHWzW+iwFLOpiJ76kKsV8nAc6Y81antR0UA Date: Tue, 8 Dec 2020 14:49:50 +0000 Message-ID: <19351_1607438991_5FCF928F_19351_378_3_787AE7BB302AE849A7480A190F8B933031599BE8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160743822116.18686.13373433603199332190@ietfa.amsl.com> In-Reply-To: <160743822116.18686.13373433603199332190@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-15.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, 08 Dec 2020 14:49:58 -0000 Re-, In addition to the changes to address the yangdoctor review, we made the fo= llowing changes: * replace the use of 7049 and companion section citations with the fresh RF= C8949=20 * add more unit and interval values Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part > de internet-drafts@ietf.org > Envoy=E9=A0: mardi 8 d=E9cembre 2020 15:37 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-telemetry-15.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of > the IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Jon Shallow > Filename : draft-ietf-dots-telemetry-15.txt > Pages : 113 > Date : 2020-12-08 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal Distributed Denial- > of- > Service attack mitigation. It specifies the normal traffic > baseline > and attack traffic telemetry attributes a DOTS client can convey > to > its DOTS server in the mitigation request, the mitigation status > telemetry attributes a DOTS server can communicate to a DOTS > client, > and the mitigation efficacy telemetry attributes a DOTS client > can > communicate to a DOTS server. The telemetry attributes can > assist > the mitigator to choose the DDoS mitigation techniques and > perform > optimal DDoS attack mitigation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-telemetry-15 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-15 >=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 Dec 10 05:47:43 2020 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 7696C3A0E05 for ; Thu, 10 Dec 2020 05:47:41 -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 k30g2VNxH1Gs for ; Thu, 10 Dec 2020 05:47:37 -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 37E5C3A0DBD for ; Thu, 10 Dec 2020 05:47:37 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4CsFbV4nDNz8tPR; Thu, 10 Dec 2020 14:47:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607608054; bh=zt9eCeZmqtYz0nTyyxGA4T59rW9wp4qhicfvKz2x1Ao=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gDzrOuJDT7AVy3BwPrJEGQVZ7CVorWrVSpxGfnOq4CPV0zUMWZ4VrnJSa4bgtALLX +wcq7hjnyNp/xkHtLrKgyzZPK4Mx2EFO3A0tm26FqhRB9/6rDEbFyvG/pmOxdfFFtj ouS18Ke3dB2tPKMhRGF52xvKuQ0EehlQSe0zeDgesiiSJRNj3JOJmSWGI14/R2MA6Z wcRR2LJBErS4mVsIoMU59ZHKsm2JLxgBsvI0cA9Az448NdXmbmpn5pQAELHhUU067b o3SQ64TvghfjZcZ6/T8MXPmpLGUvwtiJoSFVLJTIBSXKWGrKkCWFcfzG5QI6jsrGRD vaCXy/HQIo66g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4CsFbV2vLrz2xCF; Thu, 10 Dec 2020 14:47:34 +0100 (CET) From: To: "drafts-expert-review@iana.org" CC: "valery@smyslov.net" , "supjps-ietf@jpshallow.com" , "rdd@cert.org" , "kondtir@gmail.com" , "kaduk@mit.edu" , "frank.xialiang@huawei.com" , "dots@ietf.org" Thread-Topic: [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers) Thread-Index: AQHWwuLkY+Qj0c2wkEKUoOjXl2KQnanwahAQ Date: Thu, 10 Dec 2020 13:47:33 +0000 Message-ID: <7476_1607608054_5FD226F6_7476_116_1_787AE7BB302AE849A7480A190F8B93303159B1FD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: 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] [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers) 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, 10 Dec 2020 13:47:42 -0000 SGkgU2FicmluYSwgDQoNCkFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IHRvIHJlcGx5LCBidXQgd2Ug d2VyZSBhc3Nlc3NpbmcgYW5kIGFuYWx5emluZyB3aGV0aGVyL2hvdyB0byBmb2xsb3cgdGhpcyBz dWdnZXN0aW9uIGZyb20gdGhlIEV4cGVydCByZXZpZXc6ICJ1c2UgdHdvIGRpZmZlcmVudCBtZXNz YWdlcyBvbiB0aGUgc2FtZSBwb3J0Ii4gV2UgYWxzbyBjb250YWN0ZWQgdGhlIGltcGxlbWVudGVy cyB0byBoZWxwIHVzIGluIHRoZSBhc3Nlc3NtZW50LiBXZSBkaXZlZCBhcyB3ZWxsIGludG8gb3Ro ZXIgV0dzIGFyY2hpdmVzIHRvIHNlZSBpZiB3ZSBjYW4gbGV2ZXJhZ2Ugd2hhdGV2ZXIgdHdlYWsg dGhleSBoYXZlIGZvdW5kIHRvIHNvbHZlIHNpbWlsYXIgcHJvYmxlbSBpbiB0aGVpciBjb250ZXh0 LiBJbiBwYXJ0aWN1bGFyLCB3ZSBjaGVja2VkIG5ldGNvbmYgd2cgYXJjaGl2ZXMgdG8gc2VlIGhv dyB0aGV5IGRlYWx0IHdpdGggZGlzYW1iaWd1YXRpbmcgTkVUQ09ORi9SRVNUT05GIHZzLiBORVRD T05GL1JFU1RPTkYgQ2FsbCBIb21lKSAoUkZDODA3MSkuICANCg0KT3VyIGNvbmNsdXNpb24gaXMg dGhhdCB0aGUgYWJvdmUgc3VnZ2VzdGlvbiBjYW4ndCBiZSBmb2xsb3dlZCwgZXNwZWNpYWxseSB0 aGF0IHdlIGRvbid0IGRlZmluZSB0aGUgdHJhbnNwb3J0IGJ1dCByZWx5IHVwb24gZXhpc3Rpbmcg b25lcy4gDQoNClBsZWFzZSBmaW5kIGJlbG93IG1vcmUgYWJvdXQgb3VyIHJhdGlvbmFsZS4gDQoN CigxKSBJcyB0aGlzIGEgbmV3IHNlcnZpY2Ugb3IgY291bGQgYW4gZXhpc3Rpbmcgc2VydmljZSBz dWZmaWNlPw0KDQpET1RTIENhbGwgSG9tZSBpcyBhIG5ldyBzZXJ2aWNlLg0KDQpUaGUgRE9UUyBz aWduYWwgdHJhZmZpYyBpcyBwcmltYXJpbHkgRFRMUy9VRFAgYW5kIHRoZXJlIGFyZSB0d28gZGlz dGluY3Qgc2VydmljZXMgLSBET1RTIGNsaWVudCBhbmQgRE9UUyBzZXJ2ZXIuICBJbiB0aGUgbm9y bWFsIERPVFMgZW52aXJvbm1lbnQsIHRoZSBET1RTIGNsaWVudCBpbml0aWF0ZXMgdGhlIERUTFMg Y29ubmVjdGlvbiB0byB0aGUgRE9UUyBzZXJ2ZXIgd2hvLCBieSBkZWZhdWx0LCBpcyB3YWl0aW5n IGZvciB0cmFmZmljIHRvIGFycml2ZSBvbiA0NjQ2L3VkcC4NCg0KSW4gdGhlIERPVFMgY2FsbC1o b21lIGVudmlyb25tZW50IChpLmUuLCB0aGlzIHNwZWNpZmljYXRpb24pLCB0aGUgRE9UUyBjYWxs LWhvbWUgc2VydmVyIGluaXRpYXRlcyB0aGUgRFRMUyBjb25uZWN0aW9uIHRvIHRoZSBET1RTIGNh bGwtaG9tZSBjbGllbnQgYW5kIHRoZW4gdGhlIERPVFMgKGNhbGwtaG9tZSkgY2xpZW50IGNvbW11 bmljYXRlcyBpbiB0aGUgc2FtZSB3YXkgd2l0aCB0aGUgRE9UUyAoY2FsbC1ob21lKSBzZXJ2ZXIg YXMgZm9yIHRoZSBub3JtYWwgZW52aXJvbm1lbnQgYXBhcnQgZnJvbSBhIGNvdXBsZSBvZiBzcGVj aWZpYyBkaWZmZXJlbmNlcyAodG8gZG8gd2l0aCBzZXNzaW9uIHJlc3RhcnQsIGV0Yy4pLg0KDQoo MikgIElzIHRoaXMgc2VydmljZSBpbmRlcGVuZGVudGx5IHVzZWZ1bD8gIA0KDQpZZXMuIA0KDQpU aGlzIHNlcnZpY2UgaXMgYWJvdXQgbWl0aWdhdGluZyBERG9TIGF0dGFja3MgY2xvc2UgdG8gdGhl aXIgc291cmNlLiBDb25jcmV0ZWx5LCB0aGlzIHNlcnZpY2UgaXMgYWJvdXQgcHJvdGVjdGluZyB0 aGUgSW50ZXJuZXQgZnJvbSBERG9TIGF0dGFja3MgY29taW5nIGZyb20gYSBnaXZlbiBkb21haW4g KG91dGJvdW5kKSwgd2hpbGUgRE9UUyBzaWduYWwgKDQ2NDYvdWRwKSBpcyBhYm91dCBwcm90ZWN0 aW5nIGEgZ2l2ZW4gZG9tYWluIGZyb20gRERvUyBhdHRhY2tzIGNvbWluZyBmcm9tIHRoZSBJbnRl cm5ldCAoSW5ib3VuZCkuDQoNCkJvdGggc2VydmljZXMgKG91dGJvdW5kIHByb3RlY3Rpb24vaW5i b3VuZCBwcm90ZWN0aW9uKSBhcmUgdXNlZnVsLiANCg0KQSBjdXN0b21lciBjYW4gc3Vic2NyaWJl IHRvIGJvdGggb3Igb25seSBvbmUgb2YgdGhlbS4gDQoNCigzKSBXaHkgdHdvIHBvcnQgbnVtYmVy cyBhcmUgbmVlZGVkPw0KDQpJdCBpcyBsaWtlbHkgdGhhdCBhIERPVFMgc2VydmVyIHNlcnZpY2Ug d2lsbCBjby1leGlzdCB3aXRoIGEgRE9UUyBjYWxsLWhvbWUgY2xpZW50IHNlcnZpY2UgYmVoaW5k IHRoZSBzYW1lIElQIGFkZHJlc3MgYW5kIGJlIHJlY2VpdmluZyBib3RoIHR5cGVzIG9mIGluYm91 bmQgdHJhZmZpYyBjb25jdXJyZW50bHkgLSBzb21lIGJlaW5nIERPVFMgc2VydmVyLCBhbmQgc29t ZSBiZWluZyBET1RTIGNhbGwtaG9tZSBjbGllbnQuIEl0IGlzIHBvc3NpYmxlIHRoYXQgYSBET1RT IGNsaWVudCBzZXJ2aWNlIGNhbiBjby1leGlzdCB3aXRoIGEgRE9UUyBjYWxsLWhvbWUgc2VydmVy IHNlcnZpY2Ugb24gYW4gYXBwbGlhbmNlLg0KDQpXaGVuIGEgRFRMUyBjb25uZWN0aW9uIGlzIHJl Y2VpdmVkIGJ5IGEgZGV2aWNlIGhvc3RpbmcgYm90aCBET1RTIHNlcnZlciBzZXJ2aWNlIGFuZCBE T1RTIGNhbGwtaG9tZSBjbGllbnQgc2VydmljZSwgaXQgZG9lcyBub3Qga25vdyB3aGljaCBzZXJ2 aWNlIGlzIGludm9rZWQuICoqIERpc2FtYmlndWF0aW5nIHRoZXNlIHR3byBzZXJ2aWNlcyBpcyB0 aHVzIHJlcXVpcmVkICoqLiAgDQoNCkFzIHRoZXJlIGlzIG5vIHNpbXBsZSB3YXkgdG8gc3RlZXIg aW5ib3VuZCBVRFAvRFRMUyB0cmFmZmljIGdvaW5nIHRvIHRoZSBzYW1lIFVEUCBwb3J0IG9uIHRo ZSBzYW1lIElQIHRvIDIgc2VwYXJhdGUsIGluY29tcGF0aWJsZSBzZXJ2aWNlcywgdGhlIERPVFMg c2VydmVyIGFuZCBET1RTIGNhbGwtaG9tZSBjbGllbnQgaGF2ZSB0byBiZSBsaXN0ZW5pbmcgb24g MiBkaXNjcmV0ZSBwb3J0cy4NCg0KVGhlIG92ZXJoZWFkIG9mIHJlLWRpcmVjdGluZyB0cmFmZmlj IHRvIHVzZSBhIGRpZmZlcmVudCBwb3J0IChEVExTIGhhbmRzaGFrZSBzZXR1cCwgYXBwbGljYXRp b24gcmVkaXJlY3QgcGFja2V0LCBuZXcgRFRMUyBoYW5kc2hha2Ugc2V0dXApIGlzIHVuYWNjZXB0 YWJsZSBnaXZlbiB0aGF0IHRoZSBET1RTIHByb3RvY29scyB3aWxsIGdldCB1c2VkIGluIGVudmly b25tZW50cyB3aGVyZSB0aGVyZSBhcmUgRERvUyBhdHRhY2tzIGFuZCBoZW5jZSB0cmFmZmljIGxv c3MuDQoNClRoaXMgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gQXBwZW5kaXggQSBvZiB0aGUgZHJh ZnQuDQoNCig0KSBXaHkgbm90IHVzaW5nIGEgZHluYW1pYyBwb3J0IG51bWJlciBmb2xsb3dpbmcs IGUuZy4sIGRyYWZ0LWlldGYtZG90cy1zZXJ2ZXItZGlzY292ZXJ5Pw0KDQpUaGF0IG1pZ2h0IGJl IHBvc3NpYmxlIGluIHNvbWUgY29udGV4dHMgKGUuZy4sIHRoZSBtaXRpZ2F0aW9uIHByb3ZpZGVy IGlzIGFsc28gdGhlIGFjY2VzcyBwcm92aWRlciksIG5ldmVydGhlbGVzcyBzdWNoIHRvb2xzIGFy ZSBub3QgdXNlZnVsLCBlLmcuLCB3aGVuIG5vICoqIGV4cGxpY2l0IElQIGFkZHJlc3MgY29uZmln dXJhdGlvbiAqKiBpcyBpbnZvbHZlZCBhbmQgdGhlIGFnZW50IGF1dG8tZGlzY292ZXJzIGl0cy4g VGhpcyBpcyBzaW1pbGFyIHRvIHRoZXNlIGNhc2VzIGRpc2N1c3NlZCBpbiBSRkM4NzgyOg0KDQog ICAgICB8ICBQYXJ0aWN1bGFybHksIHRoZSB1c2Ugb2YgYSBkZWZhdWx0IHBvcnQgbnVtYmVyIGlz IG1lYW50IHRvDQogICAgICB8ICBzaW1wbGlmeSBET1RTIGRlcGxveW1lbnQgaW4gc2NlbmFyaW9z IHdoZXJlIG5vIGV4cGxpY2l0IElQDQogICAgICB8ICBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gaXMg cmVxdWlyZWQuICBGb3IgZXhhbXBsZSwgdGhlIHVzZSBvZiB0aGUNCiAgICAgIHwgIGRlZmF1bHQg cm91dGVyIGFzIHRoZSBET1RTIHNlcnZlciBhaW1zIHRvIGVhc2UgRE9UUyBkZXBsb3ltZW50DQog ICAgICB8ICB3aXRoaW4gTEFOcyAoaW4gd2hpY2ggQ1BFcyBlbWJlZCBhIERPVFMgZ2F0ZXdheSBh cyBpbGx1c3RyYXRlZA0KICAgICAgfCAgaW4gRmlndXJlcyAxIGFuZCAyKSB3aXRob3V0IHJlcXVp cmluZyBhIHNvcGhpc3RpY2F0ZWQgZGlzY292ZXJ5DQogICAgICB8ICBtZXRob2QgYW5kIGNvbmZp Z3VyYXRpb24gdGFza3Mgd2l0aGluIHRoZSBMQU4uICBJdCBpcyBhbHNvDQogICAgICB8ICBwb3Nz aWJsZSB0byB1c2UgYW55Y2FzdCBhZGRyZXNzZXMgZm9yIERPVFMgc2VydmVycyB0byBzaW1wbGlm eQ0KICAgICAgfCAgRE9UUyBjbGllbnQgY29uZmlndXJhdGlvbiwgaW5jbHVkaW5nIHNlcnZpY2Ug ZGlzY292ZXJ5LiAgSW4NCiAgICAgIHwgIHN1Y2ggYW4gYW55Y2FzdC1iYXNlZCBzY2VuYXJpbywg YSBET1RTIGNsaWVudCBpbml0aWF0aW5nIGEgRE9UUw0KICAgICAgfCAgc2Vzc2lvbiB0byB0aGUg RE9UUyBzZXJ2ZXIgYW55Y2FzdCBhZGRyZXNzIG1heSwgZm9yIGV4YW1wbGUsIGJlDQogICAgICB8 ICAoMSkgcmVkaXJlY3RlZCB0byB0aGUgRE9UUyBzZXJ2ZXIgdW5pY2FzdCBhZGRyZXNzIHRvIGJl IHVzZWQgYnkNCiAgICAgIHwgIHRoZSBET1RTIGNsaWVudCBmb2xsb3dpbmcgdGhlIHByb2NlZHVy ZSBkaXNjdXNzZWQgaW4NCiAgICAgIHwgIFNlY3Rpb24gNC42IG9yICgyKSByZWxheWVkIHRvIGEg dW5pY2FzdCBET1RTIHNlcnZlci4NCg0KRXZlbiBmb3IgY2FzZXMgd2hlcmUgZHJhZnQtaWV0Zi1k b3RzLXNlcnZlci1kaXNjb3ZlcnkgY2FuIGJlIHVzZWQsIGxlYXJuaW5nIHRoZSBwb3J0IG51bWJl ciB3aWxsIHJlcXVpcmUgdG8gcGFzcyB0aGUgZGlzY292ZXJlZCByZWZlcmVuY2UgdG8gYSBETlMg bGlicmFyeSAoRE5TLVNEIG9yIFMtTkFQVFIpLiBJZiBhIEREb1MgYXR0YWNrIGlzIG9jY3Vycmlu ZywgRE5TIHNlcnZpY2VzIG1heSBub3QgYmUgYXZhaWxhYmxlIGZvciB0aGUgY2FsbC1ob21lIERP VFMgc2VydmVyIHRvIHVzZS4gV2hpY2ggaXMgcHJvYmxlbWF0aWMgdG8gcHJvdmlkZSB0aGUgc2Vy dmljZSBpZiB0aGUgc2Vzc2lvbiBpcyBub3QgZXN0YWJsaXNoZWQgcHJpb3IgdG8gYW4gYXR0YWNr IGlzIGRldGVjdGVkLiBPYnZpb3VzbHksIG5vIGlzc3VlIGlzIGVuY291bnRlcmVkIGlmIHRoZSBz ZXNzaW9uIGlzIGVzdGFibGlzaGVkIGRpbiBpZGxlIHRpbWUuIA0KDQpPZiBjb3Vyc2UsIGlmIG1h bnVhbCBjb25maWd1cmF0aW9uIGlzIHVzZWQgZm9yIElQIGFkZHJlc3MgY29uZmlndXJhdGlvbiwg dGhlIHBvcnQgbnVtYmVyIGNhbiBiZSBzdXBwbGllZCBhcyB3ZWxsLiANCg0KKDUpIFdoeSBub3Qg bWFuZGF0aW5nIHJ1bm5pbmcgdGhlIHNlcnZpY2VzIG9uIGRpc3RpbmN0IGRldmljZXM/ICANCg0K QXMgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCwgYSBkZXBsb3ltZW50IG9wdGlvbiBpcyB0byBydW4g dGhlIHNlcnZpY2VzIHVzaW5nIGRpc3RpbmN0IElQIGFkZHJlc3Nlcy4gSW4gc3VjaCBjYXNlLCBu byBwcm9ibGVtIGlzIGVuY291bnRlcmVkIGV2ZW4gaWYgdGhlIHNhbWUgcG9ydCBudW1iZXIgaXMg dXNlZCBmb3IgYm90aCBzZXJ2aWNlcy4gDQoNCk5ldmVydGhlbGVzcywgd2UgY2FuJ3QgbWFuZGF0 ZSB0aGlzIGRlcGxveW1lbnQgb3B0aW9uIGFuZCBpdCBpcyB1cCB0byB0aGUgdGFzdGUgb2Ygb3Bl cmF0b3IgdG8gZGVjaWRlIHdoZXRoZXIgdG8gcnVuIHRoZSBzZXJ2aWNlcyBvbiB0aGUgc2FtZSBv ciBkaXN0aW5jdCBtYWNoaW5lcy4gDQoNCig2KSBEaXNhbWJpZ3VhdGluZyBhdCBET1RTIEdhdGV3 YXlzDQoNClRoZSBwcmVzZW5jZSBvZiBnYXRld2F5cyBvbiB0aGUgcGF0aCBpcyBhbHNvIGNoYWxs ZW5naW5nIGV2ZW4gaWYgdGhlIHVsdGltYXRlIHNlcnZpY2VzIGFyZSBydW5uaW5nIG9uIGRpc3Rp bmN0IElQIGFkZHJlc3Nlcy4gR2F0ZXdheXMgbXVzdCBoYXZlIG1lYW5zIHRvIGRlY2lkZSB3aGV0 aGVyIGEgbWVzc2FnZSBpcyB0byBiZSBkZXN0aW5lZCB0byBET1RTIHNlcnZlciBzZXJ2aWNlIG9y IERPVFMgY2FsbC1ob21lIERPVFMgY2xpZW50IHNlcnZpY2UuIA0KDQpSZXF1aXJpbmcgc2VncmVn YXRpbmcgZ2F0ZXdheXMgZm9yIGVhY2ggb2YgdGhlIHNlcnZpY2VzIGlzIG5vdCB2aWFibGUuDQoN Cig3KSBJbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IA0KDQpMZXQncyBhc3N1bWUgdGhhdCBieSBz b21lICJtYWdpYyIgd2UgY2FuIGRlbXV4IHRoZSB0d28gc2VydmljZXMuIA0KIA0KQWZ0ZXIgdGhl IHJlY2VpdmluZyB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgRXhwZXJ0LCB0aGUgYXV0aG9ycyBoYXZl IGNoZWNrZWQgd2l0aCB0aGUgdHdvIG1haW4gZGVzaWduZXJzIG9mIHRoZSB0d28gZGlmZmVyZW50 IERPVFMgaW1wbGVtZW50YXRpb25zIChvbmUgcHJvcHJpZXRhcnkgYW5kIG9uZSBvcGVuIHNvdXJj ZSkgYW5kIGJvdGggb2YgdGhlbSBoYXZlIHNhaWQgdGhhdCBpdCB3b3VsZCB0YWtlIHNpZ25pZmlj YW50IHdvcmsgdG8gbWVyZ2UgdGhlIERPVFMgY2xpZW50IGFuZCBzZXJ2ZXIgc2VydmljZSBsb2dp YyBpbnRvIGEgc2luZ2xlIGVudGl0eS4gIFRoZXkgYXJlIGFsc28gY29uY2VybmVkIHdpdGggY29t YmluZWQgc2VydmVyL2NsaWVudCBzZXJ2aWNlIGZ1bmN0aW9uYWxpdHkgcnVubmluZyBvbiBjb25z dHJhaW5lZCBkZXZpY2VzIHdoZXJlIHRoZXJlIGFyZSBSQU0gc3BhY2UgbGltaXRhdGlvbnMsIGV0 Yy4NCg0KQ2hlZXJzLA0KSm9uLCBUaXJ1LCBhbmQgTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+IERlwqA6IFNhYnJpbmEgVGFuYW1hbCB2aWEgUlQgW21haWx0bzpkcmFmdHMt ZXhwZXJ0LXJldmlld0BpYW5hLm9yZ10NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAyNSBub3ZlbWJy ZSAyMDIwIDA1OjI1DQo+IENjwqA6IHZhbGVyeUBzbXlzbG92Lm5ldDsgc3VwanBzLWlldGZAanBz aGFsbG93LmNvbTsgcmRkQGNlcnQub3JnOw0KPiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsNCj4ga29uZHRpckBnbWFpbC5jb207IGthZHVr QG1pdC5lZHU7IGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20NCj4gT2JqZXTCoDogW0lBTkEgIzEx ODE4OTddIGV4cGVydCByZXZpZXcgZm9yIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtDQo+IGNhbGwt aG9tZSAoc2VydmljZS1uYW1lcy1wb3J0LW51bWJlcnMpDQo+IA0KPiBEZWFyIEF1dGhvcnMsDQo+ IA0KPiBIYXZlIHlvdSBoYWQgYSBjaGFuY2UgdG8gcmV2aWV3IHRoZSBleHBlcnQncyBjb21tZW50 cyBiZWxvdz8NCj4gTGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1lbnRzL3F1ZXN0aW9u cyBmb3IgdGhlIGV4cGVydC4NCj4gDQo+IFRoYW5rIHlvdSwNCj4gDQo+IFNhYnJpbmEgVGFuYW1h bA0KPiBTZW5pb3IgSUFOQSBTZXJ2aWNlcyBTcGVjaWFsaXN0DQo+IA0KPiBPbiBUaHUgTm92IDEy IDIyOjQyOjQ4IDIwMjAsIHNhYnJpbmEudGFuYW1hbCB3cm90ZToNCj4gPiBEZWFyIEF1dGhvcnMs DQo+ID4NCj4gPiBXZSBoYXZlIGEgcmVzcG9uc2UgZnJvbSB0aGUgSUVTRy1kZXNpZ25hdGVkIHBv cnQgZXhwZXJ0Og0KPiA+DQo+ID4gSSBkbyBub3Qgc2VlIHN1ZmZpY2llbnQgcmVhc29uIGZvciBh IHNlY29uZCBwb3J0IGFzc2lnbm1lbnQgdG8gYmUNCj4gbWFkZQ0KPiA+IGZvciB0aGlzIHNpbmds ZSBzeXN0ZW0uIEF0IGJlc3QsIHRoZXkgc2hvdWxkIGp1c3QgdXNlIHR3bw0KPiBkaWZmZXJlbnQN Cj4gPiBtZXNzYWdlcyBvbiB0aGUgc2FtZSBwb3J0Lg0KPiA+DQo+ID4gVGhpcyByZXF1ZXN0IHNo b3VsZCBub3QgYmUgY29uc2lkZXJlZCBpbiBpc29sYXRpb247IGl0IGlzIGNvdXBsZWQNCj4gdG8N Cj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci1k aXNjb3ZlcnkuDQo+ID4NCj4gPiBPbmUgc2VydmljZSwgb25lIHBvcnQuDQo+ID4NCj4gPiA9PT0N Cj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPg0KPiA+IFNhYnJpbmEgVGFuYW1hbA0KPiA+IFNl bmlvciBJQU5BIFNlcnZpY2VzIFNwZWNpYWxpc3QNCg0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Dec 14 02:40:50 2020 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 259613A0F2F; Mon, 14 Dec 2020 02:40:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160794244713.23722.10716414184806475697@ietfa.amsl.com> Date: Mon, 14 Dec 2020 02:40:47 -0800 Archived-At: Subject: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-call-home-11=3A_=28with_COMMENT=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 10:40:47 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dots-signal-call-home-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Congratulations for the many nice ASCII artworks ;-) Using the SVG alternate artwork could have even been nicer ;-) Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I will let the transport AD to decide on the IANA point. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- I wonder whether the 2nd paragraph is really useful. -- Section 1.1 -- Should the DOTS acronym be expanded before first use ? Please add a reference to "Slowloris" Did the authors/WG consider mentioning MUD in this lengthy discussion about IoT @ Home ? -- Section 5.2.1 -- "When an outgoing attack that saturates the outgoing link", but, what about an "incoming attack" ? -- Section 5.2.2 -- Thank you for using an IPv6-only example ! -- Section 5.3.1 -- Can source-prefix be a link-local address (normally not forwarded by a router but what if the CPE is a layer-2 node) ? In figure 9, while "2001:db8:123::/128" is a valid node address but it looks like a prefix, may I suggest to use "2001:db8:123::1/128" that better suggest a host address ? -- Section 5.3.2 -- Congratulations to the authors for describing the NAT64/MAP behaviors. -- Section 8 -- "The DOTS Call Home can be misused " should probably include "server". -- Section 9 -- How is the privacy among DOTS servers enforced ? E.g., how can the DOTS client only send mitigation information about subscriber A prefix(es) and not subscriber B prefix(es)? There could obviously be a link to RADIUS and DHCP servers but I did not read anything about this. Or is 'common sense' / implicit ? == NITS == s/Figure 10 depictes/Figure 10 depicts/ From nobody Mon Dec 14 06:12:49 2020 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 694EC3A0D9B; Mon, 14 Dec 2020 06:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 eTdukF-HgbNS; Mon, 14 Dec 2020 06:12:45 -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 79A683A0D94; Mon, 14 Dec 2020 06:12:45 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4Cvjyh1Yx3z8sxK; Mon, 14 Dec 2020 15:12:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607955164; bh=poDmQgKMyX6hjjMx453TF23/phvXt65BquxE8LYIVSM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=TIdyvcCmvhX/ACKEK+vpVTrDRKtmcLWm8Txchdd16MUX6rLXWlApT4mjXphfa3foc 2d5Y1DOQ2KsUHSMf+eSgg8PhcXRMuh0Rthb6mu9ZsNj3Lk9M3O6GDsY6lEpng98VH8 IcuR0Vg68Tn1u1WOfg8R8lJv2DOlzsOFVEdPuovmI7I8MvM9kHOhcxcnrPFv01YJyR coRBdwIcyGh7awJ9a4E98ZOy6OEk8hpZB1gSMyTpsjx7YE3/V48Z+HmX0lE9r4xc59 t0oXvzwMOKDrTqJd33GKBCbLcLrPxKOkPPt4jsZxBa1lLQGJPFmoN3uW9eGUmD599r Wnl+DKJf/pmBw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4Cvjyg4c0DzCqkg; Mon, 14 Dec 2020 15:12:43 +0100 (CET) From: To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-signal-call-home-11:_(with_COMMENT)?= Thread-Index: AQHW0gb2F2CsS7KuKEauwPnuMJJUj6n2lc/Q Date: Mon, 14 Dec 2020 14:11:21 +0000 Message-ID: <18281_1607955163_5FD772DB_18281_56_1_787AE7BB302AE849A7480A190F8B93303159CF56@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160794244713.23722.10716414184806475697@ietfa.amsl.com> In-Reply-To: <160794244713.23722.10716414184806475697@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-call-home-11=3A_=28with_COMMENT=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 14:12:47 -0000 UmUtYm9uam91ciBFcmljLCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNl IHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBs eUBpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBsdW5kaSAxNCBkw6ljZW1icmUgMjAyMCAxMTo0MQ0K PiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtDQo+IGNoYWlyc0BpZXRmLm9yZzsgZG90 c0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47DQo+IHZhbGVy eUBzbXlzbG92Lm5ldA0KPiBPYmpldMKgOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24g ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLQ0KPiBob21lLTExOiAod2l0aCBDT01NRU5UKQ0K PiANCj4gw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0xMTogTm8gT2JqZWN0 aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0bw0KPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLw0KPiANCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiAtLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiANCj4g VGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50LiBDb25ncmF0dWxh dGlvbnMgZm9yDQo+IHRoZSBtYW55IG5pY2UgQVNDSUkgYXJ0d29ya3MgOy0pIFVzaW5nIHRoZSBT VkcgYWx0ZXJuYXRlIGFydHdvcmsNCj4gY291bGQgaGF2ZSBldmVuIGJlZW4gbmljZXIgOy0pDQo+ IA0KPiBQbGVhc2UgZmluZCBiZWxvdyAgc29tZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMg KGJ1dCByZXBsaWVzDQo+IHdvdWxkIGJlIGFwcHJlY2lhdGVkKSwgYW5kIHNvbWUgbml0cy4NCj4g DQo+IEkgd2lsbCBsZXQgdGhlIHRyYW5zcG9ydCBBRCB0byBkZWNpZGUgb24gdGhlIElBTkEgcG9p bnQuDQoNCltNZWRdIEZXSVcsIHRoZSByYXRpb25hbGUgZm9yIHRoZSByZXF1ZXN0IGNhbiBiZSBm b3VuZCBhdDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kb3RzL0dRUC1R Q21DLTRYdEpIUG1zUFJfcXV1eU8wYy8gDQoNCj4gDQo+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMg dG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gLcOpcmljDQo+ IA0KPiA9PSBDT01NRU5UUyA9PQ0KPiAtLSBBYnN0cmFjdCAtLQ0KPiBJIHdvbmRlciB3aGV0aGVy IHRoZSAybmQgcGFyYWdyYXBoIGlzIHJlYWxseSB1c2VmdWwuDQoNCltNZWRdIFdlIGFkZGVkIHRo YXQgdGV4dCB0byBhZGRyZXNzIGEgY29tbWVudCB3ZSByZWNlaXZlZCBpbiB0aGUgcGFzdDogdGhl ICJjYWxsIGhvbWUiIHdhcyBtaXNpbnRlcnByZXRlZCBhcyBpZiB0aGlzIGlzIHNwZWNpZmljIHRv IGhvbWUgbmV0d29ya3MuIEkgc3VnZ2VzdCB0byBtYWludGFpbiB0aGlzIHNlbnRlbmNlLiBUaGFu a3MuDQoNCj4gDQo+IC0tIFNlY3Rpb24gMS4xIC0tDQo+IFNob3VsZCB0aGUgRE9UUyBhY3Jvbnlt IGJlIGV4cGFuZGVkIGJlZm9yZSBmaXJzdCB1c2UgPw0KDQpbTWVkXSBEb25lLiBQbGVhc2Ugc2Vl IGh0dHBzOi8vdGlueXVybC5jb20vZG90cy1jYWxsLWhvbWUtbGF0ZXN0IA0KDQo+IA0KPiBQbGVh c2UgYWRkIGEgcmVmZXJlbmNlIHRvICJTbG93bG9yaXMiDQoNCltNZWRdIFN1cmUuIFBsZWFzZSBz ZWUgdGhlIGRpZmYuICAgDQoNCj4gDQo+IERpZCB0aGUgYXV0aG9ycy9XRyBjb25zaWRlciBtZW50 aW9uaW5nIE1VRCBpbiB0aGlzIGxlbmd0aHkNCj4gZGlzY3Vzc2lvbiBhYm91dCBJb1QgQCBIb21l ID8NCg0KW01lZF0gV2UgZG8gY2l0ZSBSRkM4NTc2LCB3aGljaCBkaXNjdXNzZXMgTVVELiBOb3Qg c3VyZSB0aGVyZSBpcyBhIHZhbHVlIGluIGNpdGluZyBpdCBoZXJlLiAgIA0KDQo+IA0KPiAtLSBT ZWN0aW9uIDUuMi4xIC0tDQo+ICJXaGVuIGFuIG91dGdvaW5nIGF0dGFjayB0aGF0IHNhdHVyYXRl cyB0aGUgb3V0Z29pbmcgbGluayIsIGJ1dCwNCj4gd2hhdCBhYm91dCBhbiAiaW5jb21pbmcgYXR0 YWNrIiA/DQoNCltNZWRdIFRoYXQgb25lIGlzIGNvdmVyZWQgYnkgdGhlIGZvbGxvd2luZyB0d28g cGFyYWdyYXBocy4gVGhlIGZhY3QgdGhhdCB0aGUgbG9zcyBpcyBkdWUgdG8gYW4gaW5jb21pbmcg YXR0YWNrIGlzIG5vdCB1c2VkIGZvciBzZXNzaW9uIG1hbmFnZW1lbnQgcHVycG9zZXMuIFRoZSBE T1RTIENhbGwgSG9tZSBTZXJ2ZXIgZG9lcyBub3QgaGF2ZSB0aGUgdmlzaWJpbGl0eSBvbiB0aGUg aW5jb21pbmcgYXR0YWNrcyAoc2VlIHRoZSByZWZlcmVuY2UgYXJjaGl0ZWN0dXJlKTsgdGhhdCBp cyB2aXNpYmxlIHRvIGEgRE9UUyBjbGllbnQgKGJhc2Ugc2lnbmFsIGNoYW5uZWwpLCBpZiBhbnku IA0KDQo+IA0KPiAtLSBTZWN0aW9uIDUuMi4yIC0tDQo+IFRoYW5rIHlvdSBmb3IgdXNpbmcgYW4g SVB2Ni1vbmx5IGV4YW1wbGUgIQ0KPiANCj4gLS0gU2VjdGlvbiA1LjMuMSAtLQ0KPiBDYW4gc291 cmNlLXByZWZpeCBiZSBhIGxpbmstbG9jYWwgYWRkcmVzcyAobm9ybWFsbHkgbm90IGZvcndhcmRl ZCBieQ0KPiBhIHJvdXRlciBidXQgd2hhdCBpZiB0aGUgQ1BFIGlzIGEgbGF5ZXItMiBub2RlKSA/ DQoNCltNZWRdIFByaXZhdGUgKGZvciBJUHY0KSwgbGluay1sb2NhbCwgb3IgVUxBcyBhcmUgbm90 IGZvcmJpZGRlbi4gT25seSBsb29wYmFjaywgYnJvYWRjYXN0LCBhbmQgbXVsdGljYXN0IGFkZHJl c3NlcyBhcmUgbm90IGFsbG93ZWQuDQoNCj4gDQo+IEluIGZpZ3VyZSA5LCB3aGlsZSAiMjAwMTpk Yjg6MTIzOjovMTI4IiBpcyBhIHZhbGlkIG5vZGUgYWRkcmVzcyBidXQNCj4gaXQgbG9va3MgbGlr ZSBhIHByZWZpeCwgbWF5IEkgc3VnZ2VzdCB0byB1c2UgIjIwMDE6ZGI4OjEyMzo6MS8xMjgiDQo+ IHRoYXQgYmV0dGVyIHN1Z2dlc3QgYSBob3N0IGFkZHJlc3MgPw0KDQpbTWVkXSBObyBwcm9ibGVt LiBTZWUgdGhlIGRpZmYuIA0KDQo+IA0KPiAtLSBTZWN0aW9uIDUuMy4yIC0tDQo+IENvbmdyYXR1 bGF0aW9ucyB0byB0aGUgYXV0aG9ycyBmb3IgZGVzY3JpYmluZyB0aGUgTkFUNjQvTUFQDQo+IGJl aGF2aW9ycy4NCj4gDQo+IC0tIFNlY3Rpb24gOCAtLQ0KPiAiVGhlIERPVFMgQ2FsbCBIb21lIGNh biBiZSBtaXN1c2VkICIgc2hvdWxkIHByb2JhYmx5IGluY2x1ZGUNCj4gInNlcnZlciIuDQo+IA0K DQpbTWVkXSBBcyB5b3UgY2FuIHNlZSBpbiB0aGUgZGlmZiwgY2hhbmdlZCB0byAiVGhlIERPVFMg Q2FsbCBIb21lIHNpZ25hbCBjaGFubmVsIGNhbiBiZSBtaXN1c2VkIi4NCg0KPiAtLSBTZWN0aW9u IDkgLS0NCj4gSG93IGlzIHRoZSBwcml2YWN5IGFtb25nIERPVFMgc2VydmVycyBlbmZvcmNlZCA/ IEUuZy4sIGhvdyBjYW4gdGhlDQo+IERPVFMgY2xpZW50IG9ubHkgc2VuZCBtaXRpZ2F0aW9uIGlu Zm9ybWF0aW9uIGFib3V0IHN1YnNjcmliZXIgQQ0KPiBwcmVmaXgoZXMpIGFuZCBub3Qgc3Vic2Ny aWJlciBCIHByZWZpeChlcyk/IFRoZXJlIGNvdWxkIG9idmlvdXNseSBiZQ0KPiBhIGxpbmsgdG8g UkFESVVTIGFuZCBESENQIHNlcnZlcnMgYnV0IEkgZGlkIG5vdCByZWFkIGFueXRoaW5nIGFib3V0 DQo+IHRoaXMuIE9yIGlzICdjb21tb24gc2Vuc2UnIC8gaW1wbGljaXQgPw0KDQpbTWVkXSBXZSBm b2N1cyBvbiB0aGUgZXh0ZXJuYWwgYmVoYXZpb3I6IA0KDQogICAgICB0aGUgQ2FsbCBIb21lIERP VFMgY2xpZW50IE1VU1QgdmFsaWRhdGUgdGhhdCBhdHRhY2tlcg0KICAgICAgcHJlZml4ZXMgYXJl IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIENhbGwgSG9tZSBET1RTIHNlcnZlciBkb21haW4NCiAg ICAgIChlLmcuLCBwcmVmaXhlcyBhc3NpZ25lZCB0byB0aGUgQ2FsbCBIb21lIERPVFMgc2VydmVy IGRvbWFpbiBvcg0KICAgICAgbmV0d29ya3MgaXQgc2VydmljZXMpLg0KDQpIb3cgdGhpcyBpcyBl bmZvcmNlZCBpcyBkZXBsb3ltZW50LXNwZWNpZmljLiANCg0KRG8geW91IHByZWZlciB0byBzZWUg REhDUC9SQURJVVMgY2l0ZWQ/IA0KDQo+IA0KPiA9PSBOSVRTID09DQo+IA0KPiBzL0ZpZ3VyZSAx MCBkZXBpY3Rlcy9GaWd1cmUgMTAgZGVwaWN0cy8NCg0KW01lZF0gRml4ZWQuIFRoYW5rcy4NCg0K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Dec 14 07:32:57 2020 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 127183A0D05; Mon, 14 Dec 2020 07:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 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_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=Xttc9Cop; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e9hf67iL 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 FZxgkY6400U8; Mon, 14 Dec 2020 07:32:48 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BEF3A0E29; Mon, 14 Dec 2020 07:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9472; q=dns/txt; s=iport; t=1607959967; x=1609169567; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WP2BbtK+eqaPHYZPLdgFhXW4zzzhXPPZIwkUuWJOIjs=; b=Xttc9CopIg7Yrwu/aP8+9CWlMBmYZiFF1+fhGZAZrx4jGc5LhPJfsn1s yDHvAm0WFAbnrRnxveHh+aQLehDoffqOwWTEVjp2BYJYazdj8LLbk1w/N 4OhuaPvjOh9Xv1sBONb9567GqmPcu5kKoJ1/p3ILX7MS4KbZfMA3le27J E=; X-IPAS-Result: =?us-ascii?q?A0AcAwBphNdfkJNdJa1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BUlF8Wy8uhD6DSAONLiUDjwuJf4FCgREDVAsBAQENAQEjBgQCBAEBhEoCF?= =?us-ascii?q?4FqAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAYY4DIVyAQEBAwESE?= =?us-ascii?q?REMAQE3AQsEAgEIEQECAQIDAiMDAgICMBQBAgMDCAIEAQ0FIoMEAYJVAw4gA?= =?us-ascii?q?Q6gSAKBPIhpdoEygwQBAQWBR0GDDBiCEAMGgQ4qgnWDeYIpgWWBLYEeG4FBP?= =?us-ascii?q?4ERJwwQglU+gl0CAwGBJgESAQkYgxczgiyBWW9fBBQOFgMICAYCDUIHBiIEF?= =?us-ascii?q?CsQLREfBQMQKY8THIMqk1WRNgqCdIkijQ6FGAMfgyaKJgSFVY8XhGmPGosMk?= =?us-ascii?q?U8YhDMCBAIEBQIOAQEFgW0haVgRB3AVZQGCCgEBMiEvFwINjiEMDgkUgzqFF?= =?us-ascii?q?IVEdBoBHAIGAQkBAQMJAXuHLi2CFwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AiIitWxf+JYi6oCa0jOjZdWnilGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQA9fc8ftChOeQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFrIq3u94HgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,420,1599523200"; d="scan'208";a="633799876" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Dec 2020 15:32:46 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BEFWkSe013705 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Dec 2020 15:32:46 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Dec 2020 09:32:46 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Dec 2020 09:32:45 -0600 Received: from NAM10-DM6-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, 14 Dec 2020 10:32:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LhMCQZXmdAGNHFnPOUx52rYl0SlL79b5o6vxvSfkDIsOc1HcavBrXr78NLz1Fjf7oMkPACmeCCZFZFogww3boTgc4EIRJDUzwKK4fJCAKpccfaNHyI/p+YzRrjRPz9OEx/XhqG+L3IJ0fgyd81Q+nJaM5bmZagoWjdO1F4dOfJ/4oVA1PsmPPJ49DOyBoirqlN25vdKMT1HOSUS+BeZFVCeEuu+gOzvyHMmX7I7Aw2ei/ZjCVphYpcQ/xnjbf+pIlmem+uKsOwyP9JV1jzSl8xbBZQZ6RxzUERmjgMiZ8ja8ztLmJfoopXR2DDHzgD2N2cMNuJed0xWeUqosTZUWPQ== 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=WP2BbtK+eqaPHYZPLdgFhXW4zzzhXPPZIwkUuWJOIjs=; b=GWhOd6+R4Zg/mWE0HXeHkB9noi+p+tIb7nnCFsNDXhurG65qY14jlznpBGguNyyloI0fk16WkJW7fKGsbXKrRLovSLlhS8ONcGsQAmsa89YQo8ap4vSwtWh8RA+TlyHPBEHAMiA85SMC2btUZLG0wgIG6rwz8I5sc1F2080NZ9NzG0IRZ/cp9QqS7QSavWVoQfh4Q28+QxtL3DOkNt+wR1RI8k8iYqYkzTq60YY+8wuvB1I3VStoDmDApJIKlwifdNwqr5Ap4cDk+c38f1WZmHwDRtYPi0pk9ewDOKXRdXoRkA/YFg+H67Crv0tq6OWFyiD4BmavVHRgES7Q15aDhg== 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=WP2BbtK+eqaPHYZPLdgFhXW4zzzhXPPZIwkUuWJOIjs=; b=e9hf67iLBKpDZeA9co+sGlF5JIhH9STddjGeMBfnPQIUwc4VPVBoZaSMEt45FmSV3k3e82ss7sAkWnXi+5TQYUsZWYlEyr5UbvwZSuhSCSi8X+kc29Sbcr6/EOawrzccUXbF0yXP99Z5mffyybHMRojjnQonPSpWaL9yFtFW0PU= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5094.namprd11.prod.outlook.com (2603:10b6:510:3f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Mon, 14 Dec 2020 15:32:44 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::65a1:e6a9:7932:e680]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::65a1:e6a9:7932:e680%2]) with mapi id 15.20.3632.021; Mon, 14 Dec 2020 15:32:44 +0000 From: "Eric Vyncke (evyncke)" To: "mohamed.boucadair@orange.com" , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-signal-call-home-11:_(with_COMMENT)?= Thread-Index: AQHW0gb2F2CsS7KuKEauwPnuMJJUj6n2lc/QgAAzoYA= Date: Mon, 14 Dec 2020 15:32:44 +0000 Message-ID: <9070C3BA-0560-42F3-9A76-3B107804FB0E@cisco.com> References: <160794244713.23722.10716414184806475697@ietfa.amsl.com> <18281_1607955163_5FD772DB_18281_56_1_787AE7BB302AE849A7480A190F8B93303159CF56@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <18281_1607955163_5FD772DB_18281_56_1_787AE7BB302AE849A7480A190F8B93303159CF56@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 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: [2001:420:c0c1:36:b5db:edb:3a0f:efc8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b708ae5-5d4f-4346-b8d3-08d8a0458097 x-ms-traffictypediagnostic: PH0PR11MB5094: 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: hT8iiewXRKaeMFE1K/tTc2KcTl7S8PTLOfV6y9SmLeDbwzUcGfcZ8+3m3f2M2R0pZiKfDyL+ikNRELWku0LNIMNZXmqAlM+A1ZbvFM5wS25WJb3oBeSlP3X1DVfwF1qjj/POhAtdvYQbcIwVWEVCoj34QmkJYAOL7+kd4v6MZ26FHY6055p7zbvh0nBWQTxyhvhwN547LEou4Cv0hsPHij3snLIX44o1exachAA5X8r9TdKCn1WXJHCtXqBLQLDX+jGDZSJzdNn05u2mQj47AgUiNGwHwGxXFoOOKWF7+jHrf5jKkmVuannHnGS/kj8z58jtxZRvw1VQPfUr1HQiyCtFj5+89opxXp+TAbmcdMQjFJtYPFBFCO9fEWpxL77PiejT/E9Wwv0bhItQaSsqAHMYTfOa/gHLdX0/2RW5/z6aI3Bl4JRHn+zisbzuY3m7h+KoKeG2UaPEmulB6s4IGA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(8936002)(6512007)(54906003)(83380400001)(110136005)(224303003)(966005)(4326008)(53546011)(6486002)(66574015)(6506007)(2616005)(186003)(33656002)(66946007)(86362001)(66556008)(508600001)(64756008)(5660300002)(91956017)(76116006)(71200400001)(36756003)(2906002)(66446008)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eE1IdVZ3NEQwWS9HYWJtREZPazBLUHl2djRIRnM1QzV3WmZwWlNZL25YYjBx?= =?utf-8?B?TnA4SlJBVTkzMXBTRWRSeXRXbnVvT3JvY084V0p2ZGJTR2duN0VlTks0QTFu?= =?utf-8?B?eWdKcjd4bW9QeWVsZUdmaHRkNms2RzZLSkpqL0QwM2FMa2RnclFxYWFMQStH?= =?utf-8?B?OTBhQWtqU3JIQTRtQ3NPK245ZHdCVHdUNEF4ZjZ1bzFhUWE1WGswSXRaRXBT?= =?utf-8?B?eUtCTG1ocjdvaVN4c05MdFhXSUpuNDFXVXhIc2VLVUUzSnJOb2s0aFJFL1cx?= =?utf-8?B?VzJzQzJ4dHNid095VmdranY0QThnaitRUndoN2lWSzhlVElrdE45YTM0aldM?= =?utf-8?B?c2FxTTZuV1hjY2JYRXdya3FxVHhzLzZwakZTVXNMcTA2cGpmR0cyOUdydXkz?= =?utf-8?B?VnFEL1kwKzlIcFM0R0dkcEErcWZFay9FSldtRFdYZ0p5cmx0bDhFK3l5a3NJ?= =?utf-8?B?ZEZNSVZCazBSNE02SkRZSEVCTklCMlJjMGJURjE2c3haTzd2NHYrTkJsazMv?= =?utf-8?B?QXY4Zmp1UHZsaXVHUzBkMHo0TTE0R0NxKytyRVB6QnpzVitueEFVQjl6c3JX?= =?utf-8?B?K0x2VzBtRDBETlpPQ3BtWlNDNEtubHQzeW9DWS9PMlF1cWY2VkFnSkdOaHNC?= =?utf-8?B?aFlHWHhCL05tTzlhVURwZHZwbUJhNkV2bVUxQnJzazRoa2ltVitsTFJ1TVZu?= =?utf-8?B?ZEJqeEY5eEJFOGkxbmR1NzJxekJ5VUhFQStUdlpPdHNad0xDQ2hCbjBuWkFL?= =?utf-8?B?NSthZ1dyTlQzZk9Pb3RtamU2end2clNQZVlJNC83bzgrN3dUTkZPK3huSnBX?= =?utf-8?B?dHVnWmkxR24vZzE2Tm1ielJTRjRhK2x1NFhCTzZPUmhrYmwyQXIzdXhNMDFU?= =?utf-8?B?K0pMU04xWWMrY01XWFMvYTIrSVhPNFFHZHlXZ3hqYVN4YzQwMXpENlE5MElk?= =?utf-8?B?aFFQNnA4K2JEMTZjbHdZVU9GZjJIdmlDUGYxY3E1RG9xTE0xU1huV095cTRy?= =?utf-8?B?Y29ucFMvMklMQ3VPcUxEby9nTWt1YlY0S0ZUUnFhYkhWWjBzVm9Cc0IzUFJl?= =?utf-8?B?RjZlNm9IUEs1MmtkV2VWNTFacTg2RjFXWFV1dVN2RW1yYldoS0lNT0FEUVVu?= =?utf-8?B?RE5CaUV5YUE1cm1kbXorR2UzNmdKYk9qM1dWVWt5MVlqRGUvRWQ5OXFaeVJo?= =?utf-8?B?N1lReVh3eWFsVXpEaXo5R1dDTUNEWkt0Vzlub1poejduYmI1ME5PWHdQUlo0?= =?utf-8?B?NE4rd1A1K05zL0JYZlpmMXBQUGJ4R0V1b2VwLzFobmYyekxiTFdkL1o3TmZW?= =?utf-8?B?Nk5QYWNXc0YvUVk0SDRrQWk4dXhRUUJWZG9wT1IwYlh2Q0lZVHFTZ2tWVzMy?= =?utf-8?B?WTA5UGtXMEgyZVk3MFQ4cjlyWjIrREZQMGpZV2dLRG5jZCtwT1VlLzk5QmRC?= =?utf-8?Q?9vAWkbuI?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0F7F3CA8E0407A4BBDE29EEFDE749D41@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b708ae5-5d4f-4346-b8d3-08d8a0458097 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2020 15:32:44.2036 (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: 1KxF/N8Q07ubESiOsMFhE+uybnLOAcV4xt1i7iunwNgqeji899k7S3tgUTqdMLhogdECRhGky6IE1xxmnf51RA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5094 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-call-home-11=3A_=28with_COMMENT=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 15:32:53 -0000 UmUtcmUtYm9uam91ciBNZWQsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBwcm9tcHQgcmVwbHksIGFs bCB5b3VyIHJlcGxpZXMgYXJlIGdvb2QgZm9yIG1lIA0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQrv u78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KRGF0ZTogTW9uZGF5LCAx NCBEZWNlbWJlciAyMDIwIGF0IDE1OjEyDQpUbzogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28u Y29tPiwgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtZG90cy1zaWdu YWwtY2FsbC1ob21lQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVA aWV0Zi5vcmc+LCAiZG90cy1jaGFpcnNAaWV0Zi5vcmciIDxkb3RzLWNoYWlyc0BpZXRmLm9yZz4s ICJkb3RzQGlldGYub3JnIiA8ZG90c0BpZXRmLm9yZz4sIFZhbGVyeSBTbXlzbG92IDx2YWxlcnlA c215c2xvdi5uZXQ+DQpTdWJqZWN0OiBSRTogw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9u IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLTExOiAod2l0aCBDT01NRU5UKQ0KDQog ICAgUmUtYm9uam91ciBFcmljLCANCg0KICAgIFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gDQoN CiAgICBQbGVhc2Ugc2VlIGlubGluZS4NCg0KICAgIENoZWVycywNCiAgICBNZWQNCg0KICAgID4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQogICAgPiBEZSA6IMOJcmljIFZ5bmNrZSB2aWEg RGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0KICAgID4gRW52b3nDqSA6IGx1 bmRpIDE0IGTDqWNlbWJyZSAyMDIwIDExOjQxDQogICAgPiDDgCA6IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KICAgID4gQ2MgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZUBpZXRm Lm9yZzsgZG90cy0NCiAgICA+IGNoYWlyc0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgVmFsZXJ5 IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47DQogICAgPiB2YWxlcnlAc215c2xvdi5uZXQN CiAgICA+IE9iamV0IDogw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt ZG90cy1zaWduYWwtY2FsbC0NCiAgICA+IGhvbWUtMTE6ICh3aXRoIENPTU1FTlQpDQogICAgPiAN CiAgICA+IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCiAgICA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLTExOiBObyBP YmplY3Rpb24NCiAgICA+IA0KICAgID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8NCiAgICA+IGFsbCBlbWFpbCBhZGRyZXNz ZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KICAgID4g Y3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQogICAgPiANCiAgICA+ IA0KICAgID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtDQogICAgPiBjcml0ZXJpYS5odG1sDQogICAgPiBmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KICAgID4gDQog ICAgPiANCiAgICA+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLw0KICAgID4gDQogICAgPiAN CiAgICA+IA0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IC0tDQogICAgPiBDT01NRU5UOg0KICAg ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICA+IC0tDQogICAgPiANCiAgICA+IFRoYW5rIHlvdSBmb3IgdGhl IHdvcmsgcHV0IGludG8gdGhpcyBkb2N1bWVudC4gQ29uZ3JhdHVsYXRpb25zIGZvcg0KICAgID4g dGhlIG1hbnkgbmljZSBBU0NJSSBhcnR3b3JrcyA7LSkgVXNpbmcgdGhlIFNWRyBhbHRlcm5hdGUg YXJ0d29yaw0KICAgID4gY291bGQgaGF2ZSBldmVuIGJlZW4gbmljZXIgOy0pDQogICAgPiANCiAg ICA+IFBsZWFzZSBmaW5kIGJlbG93ICBzb21lIG5vbi1ibG9ja2luZyBDT01NRU5UIHBvaW50cyAo YnV0IHJlcGxpZXMNCiAgICA+IHdvdWxkIGJlIGFwcHJlY2lhdGVkKSwgYW5kIHNvbWUgbml0cy4N CiAgICA+IA0KICAgID4gSSB3aWxsIGxldCB0aGUgdHJhbnNwb3J0IEFEIHRvIGRlY2lkZSBvbiB0 aGUgSUFOQSBwb2ludC4NCg0KICAgIFtNZWRdIEZXSVcsIHRoZSByYXRpb25hbGUgZm9yIHRoZSBy ZXF1ZXN0IGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9kb3RzL0dRUC1RQ21DLTRYdEpIUG1zUFJfcXV1eU8wYy8gDQoNCiAgICA+IA0KICAgID4g SSBob3BlIHRoYXQgdGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwNCiAgICA+IA0K ICAgID4gUmVnYXJkcywNCiAgICA+IA0KICAgID4gLcOpcmljDQogICAgPiANCiAgICA+ID09IENP TU1FTlRTID09DQogICAgPiAtLSBBYnN0cmFjdCAtLQ0KICAgID4gSSB3b25kZXIgd2hldGhlciB0 aGUgMm5kIHBhcmFncmFwaCBpcyByZWFsbHkgdXNlZnVsLg0KDQogICAgW01lZF0gV2UgYWRkZWQg dGhhdCB0ZXh0IHRvIGFkZHJlc3MgYSBjb21tZW50IHdlIHJlY2VpdmVkIGluIHRoZSBwYXN0OiB0 aGUgImNhbGwgaG9tZSIgd2FzIG1pc2ludGVycHJldGVkIGFzIGlmIHRoaXMgaXMgc3BlY2lmaWMg dG8gaG9tZSBuZXR3b3Jrcy4gSSBzdWdnZXN0IHRvIG1haW50YWluIHRoaXMgc2VudGVuY2UuIFRo YW5rcy4NCg0KICAgID4gDQogICAgPiAtLSBTZWN0aW9uIDEuMSAtLQ0KICAgID4gU2hvdWxkIHRo ZSBET1RTIGFjcm9ueW0gYmUgZXhwYW5kZWQgYmVmb3JlIGZpcnN0IHVzZSA/DQoNCiAgICBbTWVk XSBEb25lLiBQbGVhc2Ugc2VlIGh0dHBzOi8vdGlueXVybC5jb20vZG90cy1jYWxsLWhvbWUtbGF0 ZXN0IA0KDQogICAgPiANCiAgICA+IFBsZWFzZSBhZGQgYSByZWZlcmVuY2UgdG8gIlNsb3dsb3Jp cyINCg0KICAgIFtNZWRdIFN1cmUuIFBsZWFzZSBzZWUgdGhlIGRpZmYuICAgDQoNCiAgICA+IA0K ICAgID4gRGlkIHRoZSBhdXRob3JzL1dHIGNvbnNpZGVyIG1lbnRpb25pbmcgTVVEIGluIHRoaXMg bGVuZ3RoeQ0KICAgID4gZGlzY3Vzc2lvbiBhYm91dCBJb1QgQCBIb21lID8NCg0KICAgIFtNZWRd IFdlIGRvIGNpdGUgUkZDODU3Niwgd2hpY2ggZGlzY3Vzc2VzIE1VRC4gTm90IHN1cmUgdGhlcmUg aXMgYSB2YWx1ZSBpbiBjaXRpbmcgaXQgaGVyZS4gICANCg0KICAgID4gDQogICAgPiAtLSBTZWN0 aW9uIDUuMi4xIC0tDQogICAgPiAiV2hlbiBhbiBvdXRnb2luZyBhdHRhY2sgdGhhdCBzYXR1cmF0 ZXMgdGhlIG91dGdvaW5nIGxpbmsiLCBidXQsDQogICAgPiB3aGF0IGFib3V0IGFuICJpbmNvbWlu ZyBhdHRhY2siID8NCg0KICAgIFtNZWRdIFRoYXQgb25lIGlzIGNvdmVyZWQgYnkgdGhlIGZvbGxv d2luZyB0d28gcGFyYWdyYXBocy4gVGhlIGZhY3QgdGhhdCB0aGUgbG9zcyBpcyBkdWUgdG8gYW4g aW5jb21pbmcgYXR0YWNrIGlzIG5vdCB1c2VkIGZvciBzZXNzaW9uIG1hbmFnZW1lbnQgcHVycG9z ZXMuIFRoZSBET1RTIENhbGwgSG9tZSBTZXJ2ZXIgZG9lcyBub3QgaGF2ZSB0aGUgdmlzaWJpbGl0 eSBvbiB0aGUgaW5jb21pbmcgYXR0YWNrcyAoc2VlIHRoZSByZWZlcmVuY2UgYXJjaGl0ZWN0dXJl KTsgdGhhdCBpcyB2aXNpYmxlIHRvIGEgRE9UUyBjbGllbnQgKGJhc2Ugc2lnbmFsIGNoYW5uZWwp LCBpZiBhbnkuIA0KDQogICAgPiANCiAgICA+IC0tIFNlY3Rpb24gNS4yLjIgLS0NCiAgICA+IFRo YW5rIHlvdSBmb3IgdXNpbmcgYW4gSVB2Ni1vbmx5IGV4YW1wbGUgIQ0KICAgID4gDQogICAgPiAt LSBTZWN0aW9uIDUuMy4xIC0tDQogICAgPiBDYW4gc291cmNlLXByZWZpeCBiZSBhIGxpbmstbG9j YWwgYWRkcmVzcyAobm9ybWFsbHkgbm90IGZvcndhcmRlZCBieQ0KICAgID4gYSByb3V0ZXIgYnV0 IHdoYXQgaWYgdGhlIENQRSBpcyBhIGxheWVyLTIgbm9kZSkgPw0KDQogICAgW01lZF0gUHJpdmF0 ZSAoZm9yIElQdjQpLCBsaW5rLWxvY2FsLCBvciBVTEFzIGFyZSBub3QgZm9yYmlkZGVuLiBPbmx5 IGxvb3BiYWNrLCBicm9hZGNhc3QsIGFuZCBtdWx0aWNhc3QgYWRkcmVzc2VzIGFyZSBub3QgYWxs b3dlZC4NCg0KICAgID4gDQogICAgPiBJbiBmaWd1cmUgOSwgd2hpbGUgIjIwMDE6ZGI4OjEyMzo6 LzEyOCIgaXMgYSB2YWxpZCBub2RlIGFkZHJlc3MgYnV0DQogICAgPiBpdCBsb29rcyBsaWtlIGEg cHJlZml4LCBtYXkgSSBzdWdnZXN0IHRvIHVzZSAiMjAwMTpkYjg6MTIzOjoxLzEyOCINCiAgICA+ IHRoYXQgYmV0dGVyIHN1Z2dlc3QgYSBob3N0IGFkZHJlc3MgPw0KDQogICAgW01lZF0gTm8gcHJv YmxlbS4gU2VlIHRoZSBkaWZmLiANCg0KICAgID4gDQogICAgPiAtLSBTZWN0aW9uIDUuMy4yIC0t DQogICAgPiBDb25ncmF0dWxhdGlvbnMgdG8gdGhlIGF1dGhvcnMgZm9yIGRlc2NyaWJpbmcgdGhl IE5BVDY0L01BUA0KICAgID4gYmVoYXZpb3JzLg0KICAgID4gDQogICAgPiAtLSBTZWN0aW9uIDgg LS0NCiAgICA+ICJUaGUgRE9UUyBDYWxsIEhvbWUgY2FuIGJlIG1pc3VzZWQgIiBzaG91bGQgcHJv YmFibHkgaW5jbHVkZQ0KICAgID4gInNlcnZlciIuDQogICAgPiANCg0KICAgIFtNZWRdIEFzIHlv dSBjYW4gc2VlIGluIHRoZSBkaWZmLCBjaGFuZ2VkIHRvICJUaGUgRE9UUyBDYWxsIEhvbWUgc2ln bmFsIGNoYW5uZWwgY2FuIGJlIG1pc3VzZWQiLg0KDQogICAgPiAtLSBTZWN0aW9uIDkgLS0NCiAg ICA+IEhvdyBpcyB0aGUgcHJpdmFjeSBhbW9uZyBET1RTIHNlcnZlcnMgZW5mb3JjZWQgPyBFLmcu LCBob3cgY2FuIHRoZQ0KICAgID4gRE9UUyBjbGllbnQgb25seSBzZW5kIG1pdGlnYXRpb24gaW5m b3JtYXRpb24gYWJvdXQgc3Vic2NyaWJlciBBDQogICAgPiBwcmVmaXgoZXMpIGFuZCBub3Qgc3Vi c2NyaWJlciBCIHByZWZpeChlcyk/IFRoZXJlIGNvdWxkIG9idmlvdXNseSBiZQ0KICAgID4gYSBs aW5rIHRvIFJBRElVUyBhbmQgREhDUCBzZXJ2ZXJzIGJ1dCBJIGRpZCBub3QgcmVhZCBhbnl0aGlu ZyBhYm91dA0KICAgID4gdGhpcy4gT3IgaXMgJ2NvbW1vbiBzZW5zZScgLyBpbXBsaWNpdCA/DQoN CiAgICBbTWVkXSBXZSBmb2N1cyBvbiB0aGUgZXh0ZXJuYWwgYmVoYXZpb3I6IA0KDQogICAgICAg ICAgdGhlIENhbGwgSG9tZSBET1RTIGNsaWVudCBNVVNUIHZhbGlkYXRlIHRoYXQgYXR0YWNrZXIN CiAgICAgICAgICBwcmVmaXhlcyBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgQ2FsbCBIb21l IERPVFMgc2VydmVyIGRvbWFpbg0KICAgICAgICAgIChlLmcuLCBwcmVmaXhlcyBhc3NpZ25lZCB0 byB0aGUgQ2FsbCBIb21lIERPVFMgc2VydmVyIGRvbWFpbiBvcg0KICAgICAgICAgIG5ldHdvcmtz IGl0IHNlcnZpY2VzKS4NCg0KICAgIEhvdyB0aGlzIGlzIGVuZm9yY2VkIGlzIGRlcGxveW1lbnQt c3BlY2lmaWMuIA0KDQogICAgRG8geW91IHByZWZlciB0byBzZWUgREhDUC9SQURJVVMgY2l0ZWQ/ IA0KDQogICAgPiANCiAgICA+ID09IE5JVFMgPT0NCiAgICA+IA0KICAgID4gcy9GaWd1cmUgMTAg ZGVwaWN0ZXMvRmlndXJlIDEwIGRlcGljdHMvDQoNCiAgICBbTWVkXSBGaXhlZC4gVGhhbmtzLg0K DQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCiAgICBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCiAgICBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KICAgIGEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQogICAgT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQogICAgVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCiAgICB0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N CiAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCiAgICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQogICAgVGhhbmsgeW91Lg0KDQoNCg== From nobody Tue Dec 15 12:00:51 2020 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 954043A17FD; Tue, 15 Dec 2020 12:00:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <160806244514.15552.2884622118358344184@ietfa.amsl.com> Date: Tue, 15 Dec 2020 12:00:45 -0800 Archived-At: Subject: [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 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, 15 Dec 2020 20:00:50 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-dots-signal-call-home-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It seems to me there is a missing operational guidance or undocumented deployment assumptions. Since the motivational use case seems to be home networks (per Section 1.1), I assumed that the call home servers are running primarily consumer grade routers not managed by professional IT expertise. If that assumption is true (and it should be documented if that is the case), then I find many of the operational recommendations not congruent with that environment. Specifically, the degree of interaction and tuning seems outside the realm of expertise of someone without IT training and capabilities of home network ecosystem. In particular: -- Section 1.2 The Call Home DOTS server uses the DDoS attack traffic information to identify the compromised device in its domain that is responsible for launching the DDoS attack, optionally notifies a network administrator, and takes appropriate mitigation action(s). How would such notification work? -- Section 1.2 and 5.1. Leaves credentials configuration as out of scope. Section 1.2 references [I-D.ietf-dots-server-discovery] for provisioning. In turn, Section 1 of [I-D.ietf.server-discovery] also declares this problem out of scope by saying “This document assumes that security credentials to authenticate DOTS server(s) are pre-provisioned to a DOTS client using a mechanism such as (but not limited to) those discussed in [RFC8572] or [I-D.ietf-anima-bootstrapping-keyinfra]”. However, RFC8572 seems to rely on NETCONF and RESTCONF which seems like a rather uncommon feature of home routers. BRKSI relies on a manufacturer supplied/contracted infrastructure and keystores that also seem uncommon for consumer grade equipment. -- Section 5.3.1. The Call Home DOTS server domain administrator consent MAY be required to block the traffic from the compromised device to the attack target. An implementation MAY have a configuration knob to block the traffic from the compromised device to the attack target with or without DOTS server domain administrator consent. The suggestion here seems to be that consumers are acquiring devices that can be remotely reconfigured with out a defined trust model? Some policy or operational context seems appropriate here. -- Section 5.3.1 ... notifies the CPE administrator about the compromised device Notify how? -- Section 8. Appropriate filters (e.g., access control lists) can be installed on the Call Home DOTS server and network between the Call Home DOTS agents so that only communications from a trusted Call Home DOTS client to the Call Home DOTS server are allowed. This seems like a level of sophistication beyond your average home router user and a place where implementations should consider a secure defaults. -- Section 8. Call Home DOTS servers can also seek the consent of DOTS server domain administrator to block the traffic from the potentially compromised device to the target (see Section 5.3.1). What would be the means to gain such consent? -- Section 9. Note that a Call Home DOTS server can seek an administrator's consent, validate the request by inspecting the relevant traffic for attack signatures, or proceed with both courses of action. As above. -- Section 9. The DOTS Call Home is only advisory in nature. Concretely, the DOTS Call Home does not impose any action to be enforced within the network hosting an attack source; it is up to the Call Home DOTS server (and/or network administrator) to decide whether and which actions are required. Such a decisions seems out beyond the ability of your average home router user. -- Section 8 “... explicit policy (e.g., the Call Home DOTS client and server are managed by the same administrative entity), Is there an underlying assumption that the ISP is managing the device? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Radia Perlman for the SECDIR review. ** Section 1.1. The motivation for this protocol in the “home network device” ecosystem could use a bit more focus. (a) network devices in a home network can offer network security functions (e.g., firewall [RFC4949] or Intrusion Protection System (IPS) service [I-D.ietf-i2nsf-terminology] on a home router) (b) Hence, it is not possible to detect various DDoS attacks in the slow path ... (c) a full-fledged DPI to detect these type of DDoS attacks is functionally or operationally not possible for all the devices If IPS is done per (a), (b) and (c) don’t seem like issues. Certainly, NOT all devices support (a), but not ALL devices or limited by (b) and (c). The abstract is also clear that “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", but that fairly large other use cases doesn’t seem acknowledged here. Bottom-line, I had difficulty following the motivation. ** Section 1.1 presents an incomplete view of the problem to motivate the solution. It notes that ISPs can already detect a DDoS attack down to the individual home network, but not the device (because of NATs). The problem of what happens next remains unsaid. It seems to me that options are the ISP shapes the traffic of that home network (affecting all of its devices) which is likely undesirable/blunt or the ISP tries to gain cooperation of the home network edge router to do something (which is the point of this document). ** Section 1.1. Existing approaches are still suffering from misused access network resources by abusive devices; the support of means for blocking such attacks close to the sources are missing. I didn’t understand what this means. What “existing approaches”? ** Section 1.2. For the home network case, the text seems to be missing text saying that this “Call Home DOTS” solution needs to be deployed on a CPE capable of some degree of mitigation per the kinds of features DOTS can express (and the details of this integration is out of scope). From nobody Tue Dec 15 15:35:36 2020 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 5D22A3A0896 for ; Tue, 15 Dec 2020 15:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9K9kTJWNgxsS for ; Tue, 15 Dec 2020 15:35:31 -0800 (PST) Received: from smtp.lax.icann.org (smtp.lax.icann.org [192.0.33.81]) (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 69FD73A0888 for ; Tue, 15 Dec 2020 15:35:31 -0800 (PST) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 37148E06FB; Tue, 15 Dec 2020 23:35:31 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 3106020EE9; Tue, 15 Dec 2020 23:35:31 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" Reply-To: drafts-expert-review@iana.org In-Reply-To: References: <7476_1607608054_5FD226F6_7476_116_1_787AE7BB302AE849A7480A190F8B93303159B1FD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1181897 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org CC: mohamed.boucadair@orange.com, valery@smyslov.net, supjps-ietf@jpshallow.com, rdd@cert.org, kondtir@gmail.com, kaduk@mit.edu, frank.xialiang@huawei.com, dots@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 15 Dec 2020 23:35:31 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dots] [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers) 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: Tue, 15 Dec 2020 23:35:33 -0000 Hi Med, all, We have a response from the IESG-designated port expert: This doesn’t look like a new service; it appears more like a reverse version of the existing service. IMO, if that’s the case, they should use the existing assignment because the two services would not be fully decoupled. === Please let us know if you have any further comments/questions for the expert. Best regards, Sabrina Tanamal Senior IANA Services Specialist On Thu Dec 10 13:47:58 2020, mohamed.boucadair@orange.com wrote: > Hi Sabrina, > > Apologies for the delay to reply, but we were assessing and analyzing > whether/how to follow this suggestion from the Expert review: "use two > different messages on the same port". We also contacted the > implementers to help us in the assessment. We dived as well into other > WGs archives to see if we can leverage whatever tweak they have found > to solve similar problem in their context. In particular, we checked > netconf wg archives to see how they dealt with disambiguating > NETCONF/RESTONF vs. NETCONF/RESTONF Call Home) (RFC8071). > > Our conclusion is that the above suggestion can't be followed, > especially that we don't define the transport but rely upon existing > ones. > > Please find below more about our rationale. > > (1) Is this a new service or could an existing service suffice? > > DOTS Call Home is a new service. > > The DOTS signal traffic is primarily DTLS/UDP and there are two > distinct services - DOTS client and DOTS server. In the normal DOTS > environment, the DOTS client initiates the DTLS connection to the DOTS > server who, by default, is waiting for traffic to arrive on 4646/udp. > > In the DOTS call-home environment (i.e., this specification), the DOTS > call-home server initiates the DTLS connection to the DOTS call-home > client and then the DOTS (call-home) client communicates in the same > way with the DOTS (call-home) server as for the normal environment > apart from a couple of specific differences (to do with session > restart, etc.). > > (2) Is this service independently useful? > > Yes. > > This service is about mitigating DDoS attacks close to their source. > Concretely, this service is about protecting the Internet from DDoS > attacks coming from a given domain (outbound), while DOTS signal > (4646/udp) is about protecting a given domain from DDoS attacks coming > from the Internet (Inbound). > > Both services (outbound protection/inbound protection) are useful. > > A customer can subscribe to both or only one of them. > > (3) Why two port numbers are needed? > > It is likely that a DOTS server service will co-exist with a DOTS > call-home client service behind the same IP address and be receiving > both types of inbound traffic concurrently - some being DOTS server, > and some being DOTS call-home client. It is possible that a DOTS > client service can co-exist with a DOTS call-home server service on an > appliance. > > When a DTLS connection is received by a device hosting both DOTS > server service and DOTS call-home client service, it does not know > which service is invoked. ** Disambiguating these two services is thus > required **. > > As there is no simple way to steer inbound UDP/DTLS traffic going to > the same UDP port on the same IP to 2 separate, incompatible services, > the DOTS server and DOTS call-home client have to be listening on 2 > discrete ports. > > The overhead of re-directing traffic to use a different port (DTLS > handshake setup, application redirect packet, new DTLS handshake > setup) is unacceptable given that the DOTS protocols will get used in > environments where there are DDoS attacks and hence traffic loss. > > This is already discussed in Appendix A of the draft. > > (4) Why not using a dynamic port number following, e.g., draft-ietf- > dots-server-discovery? > > That might be possible in some contexts (e.g., the mitigation provider > is also the access provider), nevertheless such tools are not useful, > e.g., when no ** explicit IP address configuration ** is involved and > the agent auto-discovers its. This is similar to these cases discussed > in RFC8782: > > | Particularly, the use of a default port number is meant to > | simplify DOTS deployment in scenarios where no explicit IP > | address configuration is required. For example, the use of the > | default router as the DOTS server aims to ease DOTS deployment > | within LANs (in which CPEs embed a DOTS gateway as illustrated > | in Figures 1 and 2) without requiring a sophisticated discovery > | method and configuration tasks within the LAN. It is also > | possible to use anycast addresses for DOTS servers to simplify > | DOTS client configuration, including service discovery. In > | such an anycast-based scenario, a DOTS client initiating a DOTS > | session to the DOTS server anycast address may, for example, be > | (1) redirected to the DOTS server unicast address to be used by > | the DOTS client following the procedure discussed in > | Section 4.6 or (2) relayed to a unicast DOTS server. > > Even for cases where draft-ietf-dots-server-discovery can be used, > learning the port number will require to pass the discovered reference > to a DNS library (DNS-SD or S-NAPTR). If a DDoS attack is occurring, > DNS services may not be available for the call-home DOTS server to > use. Which is problematic to provide the service if the session is not > established prior to an attack is detected. Obviously, no issue is > encountered if the session is established din idle time. > > Of course, if manual configuration is used for IP address > configuration, the port number can be supplied as well. > > (5) Why not mandating running the services on distinct devices? > > As discussed in the draft, a deployment option is to run the services > using distinct IP addresses. In such case, no problem is encountered > even if the same port number is used for both services. > > Nevertheless, we can't mandate this deployment option and it is up to > the taste of operator to decide whether to run the services on the > same or distinct machines. > > (6) Disambiguating at DOTS Gateways > > The presence of gateways on the path is also challenging even if the > ultimate services are running on distinct IP addresses. Gateways must > have means to decide whether a message is to be destined to DOTS > server service or DOTS call-home DOTS client service. > > Requiring segregating gateways for each of the services is not viable. > > (7) Implementation complexity > > Let's assume that by some "magic" we can demux the two services. > > After the receiving the response from the Expert, the authors have > checked with the two main designers of the two different DOTS > implementations (one proprietary and one open source) and both of them > have said that it would take significant work to merge the DOTS client > and server service logic into a single entity. They are also > concerned with combined server/client service functionality running on > constrained devices where there are RAM space limitations, etc. > > Cheers, > Jon, Tiru, and Med > > > -----Message d'origine----- > > De : Sabrina Tanamal via RT [mailto:drafts-expert-review@iana.org] > > Envoyé : mercredi 25 novembre 2020 05:25 > > Cc : valery@smyslov.net; supjps-ietf@jpshallow.com; rdd@cert.org; > > BOUCADAIR Mohamed TGI/OLN ; > > kondtir@gmail.com; kaduk@mit.edu; frank.xialiang@huawei.com > > Objet : [IANA #1181897] expert review for draft-ietf-dots-signal- > > call-home (service-names-port-numbers) > > > > Dear Authors, > > > > Have you had a chance to review the expert's comments below? > > Let us know if you have any comments/questions for the expert. > > > > Thank you, > > > > Sabrina Tanamal > > Senior IANA Services Specialist > > > > On Thu Nov 12 22:42:48 2020, sabrina.tanamal wrote: > > > Dear Authors, > > > > > > We have a response from the IESG-designated port expert: > > > > > > I do not see sufficient reason for a second port assignment to be > > made > > > for this single system. At best, they should just use two > > different > > > messages on the same port. > > > > > > This request should not be considered in isolation; it is coupled > > to > > > https://tools.ietf.org/html/draft-ietf-dots-server-discovery. > > > > > > One service, one port. > > > > > > === > > > > > > Best regards, > > > > > > Sabrina Tanamal > > > Senior IANA Services Specialist > > > _________________________________________________________________________________________________________________________ > > 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. From nobody Tue Dec 15 20:15:27 2020 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 F09B53A0E7B; Tue, 15 Dec 2020 20:15:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160809212550.20134.6936347432271392947@ietfa.amsl.com> Date: Tue, 15 Dec 2020 20:15:25 -0800 Archived-At: Subject: [Dots] Barry Leiba's No Objection on draft-ietf-dots-signal-call-home-11: (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: Wed, 16 Dec 2020 04:15:26 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dots-signal-call-home-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for an easy-to-read document. I understand Roman’s points, but conclude that while a primary use case is for home networks, it’s expected that the server for this will be a router that’s managed by the home user’s ISP, not by the average home user. That setup is increasingly common, at least in the U.S., and it’s enabled many such functions that were not practical when users had to provide and manage their own routers. I just have a few very minor comments: — Section 1.1 — Such misbehaviors will have both a collateral damage that affects end users, and can harm the reputation of an Internet Service Provider (ISP) for being a source of attack traffic. Nit: This sentence isn’t properly formed, as the two pieces of the “both” construction aren’t parallel. I suggest this: NEW Such misbehaviors can cause collateral damage that will affect end users, and can also harm the reputation of an Internet Service Provider (ISP) for being a source of attack traffic. END — Section 5.1 — enabling means for automating the provisioning of credentials on Call Home DOTS servers to authenticate to the Call Home DOTS client are encouraged. Nit: the subject of this is the singular “enabling”, so “enabling is encouraged,” not “are”. — Section 7 — Throughout the IANA Considerations, please make the contact points and change controller be “IETF” (not IESG nor IETF Chair), and use the email address . That’s what the IESG considers the best way to refer to items where the IETF has change control. From nobody Tue Dec 15 22:14:09 2020 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 189403A0FD3; Tue, 15 Dec 2020 22:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 WU4c6Rg3Ov1U; Tue, 15 Dec 2020 22:14:02 -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 B78133A0FD0; Tue, 15 Dec 2020 22:14:01 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4CwlFM6W9Xz5vV3; Wed, 16 Dec 2020 07:13:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608099239; bh=HEp7mPBxwUmjnrKYu37s7ZxJHGurVJyK48vo+bsCsDo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=fbSCAJAqKXkL/R9DN117w53sZFx7y1LA3Tz4OjP1ru6Y+huftmWIqrav1wSRmnHpJ oiHVy4shJatQ7KuXj5u1dfr8UEk+lnnrCjnsmjcgEtZP5pvz1UjvBufZKzv00W6QCk fZMrIkxg1VZhCb4K81eFb2UrOqVT/CQczmQ4ZpzxZvCBHvfdEqGeVhB/XBBC3bck0Y gHnydNxc3yeuYnYU7AMd4vHP+CCCvQvRQ6AiZ/S+zf5+k0XQpYurzxgBhC4JvMbW5F Ic9JacKmd70mtbbDLBHEidZ6xu48kVnLA8qRffUJ2CkoyZ3Ak4REW/3UEHi01RvVzB y1UBFGcLxsy6A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4CwlFM53RczDq7Q; Wed, 16 Dec 2020 07:13:59 +0100 (CET) From: To: Roman Danyliw , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x0Nz1nJ7byrgEqtH2KsRT2mc6n5LBRg Date: Wed, 16 Dec 2020 06:13:59 +0000 Message-ID: <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> In-Reply-To: <160806244514.15552.2884622118358344184@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] 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: Wed, 16 Dec 2020 06:14:05 -0000 SGkgUm9tYW4sIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpQbGVhc2Ugc2VlIGlu bGluZSBmb3IgdGhlIERJU0NVU1MgcGFydC4gV2lsbCBzZWUgaWYvd2hhdCBjaGFuZ2VzIGFyZSBu ZWVkZWQgZm9yIHRoZSBDT01NRU5UIHBhcnQuICANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFJvbWFuIERhbnlsaXcgdmlhIERhdGF0cmFj a2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBtYXJkaSAxNSBkw6lj ZW1icmUgMjAyMCAyMTowMQ0KPiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PC oDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtDQo+IGNo YWlyc0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlz bG92Lm5ldD47DQo+IHZhbGVyeUBzbXlzbG92Lm5ldA0KPiBPYmpldMKgOiBSb21hbiBEYW55bGl3 J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0NCj4gMTE6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBSb21hbiBEYW55bGl3IGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWRvdHMtc2ln bmFsLWNhbGwtaG9tZS0xMTogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8NCj4gYWxsIGVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+ IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBs ZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNz LQ0KPiBjcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9u ZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwt aG9tZS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gRElTQ1VTUzoNCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gLS0NCj4gDQo+IEl0IHNlZW1zIHRvIG1lIHRoZXJlIGlzIGEgbWlzc2luZyBv cGVyYXRpb25hbCBndWlkYW5jZSBvcg0KPiB1bmRvY3VtZW50ZWQgZGVwbG95bWVudCBhc3N1bXB0 aW9ucy4gIFNpbmNlIHRoZSBtb3RpdmF0aW9uYWwgdXNlDQo+IGNhc2Ugc2VlbXMgdG8gYmUgaG9t ZSBuZXR3b3JrcyAocGVyIFNlY3Rpb24gMS4xKSwgSSBhc3N1bWVkIHRoYXQgdGhlDQo+IGNhbGwg aG9tZSBzZXJ2ZXJzIGFyZSBydW5uaW5nIHByaW1hcmlseSBjb25zdW1lciBncmFkZSByb3V0ZXJz IG5vdA0KPiBtYW5hZ2VkIGJ5IHByb2Zlc3Npb25hbCBJVCBleHBlcnRpc2UuDQoNCltNZWRdIFRo ZSBnZW5lcmFsaXplZCBhcHBsaWNhYmlsaXR5IHNjb3BlIGlzIHdoYXQgaXMgc2tldGNoZWQgaW4g U2VjdGlvbiAzLiBUaGUgc29sdXRpb24gaXMgbWVhbnQgdG8gYmxvY2sgYXR0YWNrcyBjbG9zZSB0 byB0aGVpciBzb3VyY2UuIFRoaXMgY2FuIGJlOiANCi0gdGhlIGhvbWUgY2FzZSwNCi0gYW4gZW50 ZXJwcmlzZSBuZXR3b3JrLCAgIA0KLSBhIHRyYW5zaXQgcHJvdmlkZXIgZmlsdGVyaW5nIGF0dGFj a3MgZnJvbSBsZWFmIG5ldHdvcmtzLA0KLSBhIHByb3ZpZGVyIGZpbHRlcmluZyBhdHRhY2tzIGZy b20gZGF0YSBjZW50ZXJzLA0KLSBldGMuDQoNCkZvciB0aGUgcGFydGljdWxhciBjYXNlIG9mIGhv bWUgbmV0d29ya3MsIHRoaXMgY2FuIGJlIHBhcnQgb2Ygc2VydmljZXMgc3VwcG9ydGVkIGJ5IGEg SVNQLW1hbmFnZWQgQ1BFIG9yIGEgbWFuYWdlZCBzZWN1cml0eSBzZXJ2aWNlIHN1YnNjcmliZWQg YnkgdGhlIHVzZXIuIA0KDQpXZSBjb3VsZCBtZW50aW9uIHRoYXQgaW4gdGhlIGRvY3VtZW50LCBi dXQgd2UgZGlkbid0IGJlY2F1c2UgdGhpcyBhcmUgZGVwbG95bWVudC1zcGVjaWZpYy4gUmVhbGx5 LiANCg0KT3RoZXIgdGhhbiB0aGUgaW50cm9kdWN0aW9uLCB3ZSBkb24ndCB3YW50IHRvIG92ZXJs b2FkIHRoZSBkb2N1bWVudCB3aXRoIGhvbWUtc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMuICANCg0K ICBJZiB0aGF0IGFzc3VtcHRpb24gaXMgdHJ1ZQ0KPiAoYW5kIGl0IHNob3VsZCBiZSBkb2N1bWVu dGVkIGlmIHRoYXQgaXMgdGhlIGNhc2UpLCB0aGVuIEkgZmluZCBtYW55DQo+IG9mIHRoZSBvcGVy YXRpb25hbCByZWNvbW1lbmRhdGlvbnMgbm90IGNvbmdydWVudCB3aXRoIHRoYXQNCj4gZW52aXJv bm1lbnQuICBTcGVjaWZpY2FsbHksIHRoZSBkZWdyZWUgb2YgaW50ZXJhY3Rpb24gYW5kIHR1bmlu Zw0KPiBzZWVtcyBvdXRzaWRlIHRoZSByZWFsbSBvZiBleHBlcnRpc2Ugb2Ygc29tZW9uZSB3aXRo b3V0IElUIHRyYWluaW5nDQo+IGFuZCBjYXBhYmlsaXRpZXMgb2YgaG9tZSBuZXR3b3JrIGVjb3N5 c3RlbS4gIEluIHBhcnRpY3VsYXI6DQo+IA0KPiAtLSBTZWN0aW9uIDEuMg0KPiBUaGUgQ2FsbCBI b21lIERPVFMgc2VydmVyIHVzZXMgdGhlIEREb1MgYXR0YWNrIHRyYWZmaWMgaW5mb3JtYXRpb24N Cj4gdG8NCj4gICAgaWRlbnRpZnkgdGhlIGNvbXByb21pc2VkIGRldmljZSBpbiBpdHMgZG9tYWlu IHRoYXQgaXMgcmVzcG9uc2libGUNCj4gZm9yDQo+ICAgIGxhdW5jaGluZyB0aGUgRERvUyBhdHRh Y2ssIG9wdGlvbmFsbHkgbm90aWZpZXMgYSBuZXR3b3JrDQo+ICAgIGFkbWluaXN0cmF0b3IsIGFu ZCB0YWtlcyBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9uIGFjdGlvbihzKS4NCj4gDQo+IEhvdyB3b3Vs ZCBzdWNoIG5vdGlmaWNhdGlvbiB3b3JrPw0KDQpbTWVkXSBUaGlzIHdpbGwgZGVwZW5kIG9uIHRo ZSBkZXBsb3ltZW50IChob21lLCBlbnRlcnByaXNlLCBEQywgYWNjZXNzIHByb3ZpZGVyLCBwZWVy IHRyYW5zaXQgcHJvdmlkZXIsIGV0Yy4pLiBUaGlzIGNhbiBiZSB1c2luZyBET1RTICh0aGUgYWRt aW5pc3RyYXRvciBoYXMgYSBjYWxsIGhvbWUgZG90cyBzZXJ2ZXIgYXBwKSwgYSBwdXNoIGZyb20g dGhlIGFwcCB1c2UgZm9yIG1hbmFnaW5nIHRoZSBDUEUsIHN5c2xvZywgc25tcCwgbmV0Y29uZiwg YW4gU01TLCBldGMuIA0KDQpBcyB5b3UgY2FuIHNlZSBhIHZhcmlldHkgb2YgdG9vbHMgY2FuIGJl IGNvbnNpZGVyZWQgYXMgYSBmdW5jdGlvbiBvZiB0aGUgbG9jYWwgZGVwbG95bWVudCBjYXNlLiBO b25lIG9mIHRoZW0gaXMgY2FsbGVkIG91dCBpbiB0aGUgdGV4dCBhcyB0aGlzIGlzIGRlcGxveW1l bnQtc3BlY2lmaWMuIE5vdCBhbGwgb2YgdGhlbSBhcmUgYXBwbGljYWJsZSBmb3IgZWFjaCBkZXBs b3ltZW50IGNhc2UuICAgICAgIA0KDQo+IA0KPiAtLSBTZWN0aW9uIDEuMiBhbmQgNS4xLiAgTGVh dmVzIGNyZWRlbnRpYWxzIGNvbmZpZ3VyYXRpb24gYXMgb3V0IG9mDQo+IHNjb3BlLg0KDQpbTWVk XSBUaGF0IGlzIGFsaWduZWQgd2l0aCBob3cgY3JlZGVudGlhbHMgYXJlIGhhbmRsZWQgaW4gdGhl IGJhc2Ugc3BlYyAoUkZDODc4MikuIA0KDQo+IFNlY3Rpb24gMS4yIHJlZmVyZW5jZXMgW0ktRC5p ZXRmLWRvdHMtc2VydmVyLWRpc2NvdmVyeV0gZm9yDQo+IHByb3Zpc2lvbmluZy4gIEluIHR1cm4s IFNlY3Rpb24gMSBvZiBbSS1ELmlldGYuc2VydmVyLWRpc2NvdmVyeV0NCj4gYWxzbyBkZWNsYXJl cyB0aGlzIHByb2JsZW0gb3V0IG9mIHNjb3BlIGJ5IHNheWluZyDigJxUaGlzIGRvY3VtZW50DQo+ IGFzc3VtZXMgdGhhdCBzZWN1cml0eSBjcmVkZW50aWFscyB0byBhdXRoZW50aWNhdGUgRE9UUyBz ZXJ2ZXIocykgYXJlDQo+IHByZS1wcm92aXNpb25lZCB0byBhIERPVFMgY2xpZW50IHVzaW5nIGEg bWVjaGFuaXNtIHN1Y2ggYXMgKGJ1dCBub3QNCj4gbGltaXRlZCB0bykgdGhvc2UgZGlzY3Vzc2Vk IGluIFtSRkM4NTcyXSBvciBbSS1ELmlldGYtYW5pbWEtDQo+IGJvb3RzdHJhcHBpbmcta2V5aW5m cmFd4oCdLiAgSG93ZXZlciwgUkZDODU3MiBzZWVtcyB0byByZWx5IG9uIE5FVENPTkYNCj4gYW5k IFJFU1RDT05GIHdoaWNoIHNlZW1zIGxpa2UgYSByYXRoZXIgdW5jb21tb24gZmVhdHVyZSBvZiBo b21lDQo+IHJvdXRlcnMuICBCUktTSSByZWxpZXMgb24gYSBtYW51ZmFjdHVyZXIgc3VwcGxpZWQv Y29udHJhY3RlZA0KPiBpbmZyYXN0cnVjdHVyZSBhbmQga2V5c3RvcmVzIHRoYXQgYWxzbyBzZWVt IHVuY29tbW9uIGZvciBjb25zdW1lcg0KPiBncmFkZSBlcXVpcG1lbnQuDQoNCltNZWRdIFRoZXNl IGFyZSBub3QgbWVhbnQgdG8gYmUgcmVjb21tZW5kYXRpb25zLiBUaGVzZSBleGFtcGxlcyBtYXkg YmUgT0sgZm9yIHNvbWUgZGVwbG95bWVudHMsIGJ1dCBub3QgYXBwcm9wcmlhdGUgZm9yIG90aGVy cy4gICANCg0KPiANCj4gLS0gU2VjdGlvbiA1LjMuMS4NCj4gVGhlIENhbGwgSG9tZSBET1RTIHNl cnZlciBkb21haW4gYWRtaW5pc3RyYXRvciBjb25zZW50IE1BWSBiZQ0KPiAgICByZXF1aXJlZCB0 byBibG9jayB0aGUgdHJhZmZpYyBmcm9tIHRoZSBjb21wcm9taXNlZCBkZXZpY2UgdG8gdGhlDQo+ ICAgIGF0dGFjayB0YXJnZXQuICBBbiBpbXBsZW1lbnRhdGlvbiBNQVkgaGF2ZSBhIGNvbmZpZ3Vy YXRpb24ga25vYg0KPiB0bw0KPiAgICBibG9jayB0aGUgdHJhZmZpYyBmcm9tIHRoZSBjb21wcm9t aXNlZCBkZXZpY2UgdG8gdGhlIGF0dGFjaw0KPiB0YXJnZXQNCj4gICAgd2l0aCBvciB3aXRob3V0 IERPVFMgc2VydmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIGNvbnNlbnQuDQo+IA0KPiBUaGUgc3Vn Z2VzdGlvbiBoZXJlIHNlZW1zIHRvIGJlIHRoYXQgY29uc3VtZXJzIGFyZSBhY3F1aXJpbmcgZGV2 aWNlcw0KPiB0aGF0IGNhbiBiZSByZW1vdGVseSByZWNvbmZpZ3VyZWQgd2l0aCBvdXQgYSBkZWZp bmVkIHRydXN0IG1vZGVsPw0KDQpbTWVkXSBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoaWNoIHN1 Z2dlc3Rpb24gYXJlIHlvdSByZWZlcnJpbmcgdG8/IA0KDQpUaGUgdGV4dCB5b3UgcXVvdGVkIGlz IHJlZmVycmluZyB0byBibG9ja2luZyB0cmFmZmljIGZyb20gZGV2aWNlcyB0aGF0IGFyZSBpbmpl Y3RpbmcgRERvUyB0cmFmZmljIGZyb20gd2l0aGluIGEgZG9tYWluLiBUaGVzZSBkZXZpY2VzIGNh biBiZSBhbiBJUCBjYW1lcmEsIGFuIGluZmVjdGVkIFBDLCBldGMuIA0KDQo+IFNvbWUgcG9saWN5 IG9yIG9wZXJhdGlvbmFsIGNvbnRleHQgc2VlbXMgYXBwcm9wcmlhdGUgaGVyZS4NCj4gDQo+IC0t IFNlY3Rpb24gNS4zLjENCj4gLi4uIG5vdGlmaWVzIHRoZSBDUEUNCj4gICAgYWRtaW5pc3RyYXRv ciBhYm91dCB0aGUgY29tcHJvbWlzZWQgZGV2aWNlDQo+IA0KPiBOb3RpZnkgaG93Pw0KDQpbTWVk XSBTZWUgYWJvdmUuIA0KDQo+IA0KPiAtLSBTZWN0aW9uIDguDQo+IEFwcHJvcHJpYXRlDQo+ICAg IGZpbHRlcnMgKGUuZy4sIGFjY2VzcyBjb250cm9sIGxpc3RzKSBjYW4gYmUgaW5zdGFsbGVkIG9u IHRoZSBDYWxsDQo+ICAgIEhvbWUgRE9UUyBzZXJ2ZXIgYW5kIG5ldHdvcmsgYmV0d2VlbiB0aGUg Q2FsbCBIb21lIERPVFMgYWdlbnRzIHNvDQo+ICAgIHRoYXQgb25seSBjb21tdW5pY2F0aW9ucyBm cm9tIGEgdHJ1c3RlZCBDYWxsIEhvbWUgRE9UUyBjbGllbnQgdG8NCj4gdGhlDQo+ICAgIENhbGwg SG9tZSBET1RTIHNlcnZlciBhcmUgYWxsb3dlZC4NCj4gDQo+IFRoaXMgc2VlbXMgbGlrZSBhIGxl dmVsIG9mIHNvcGhpc3RpY2F0aW9uIGJleW9uZCB5b3VyIGF2ZXJhZ2UgaG9tZQ0KPiByb3V0ZXIg dXNlciBhbmQgYSBwbGFjZSB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGNvbnNpZGVyIGEN Cj4gc2VjdXJlIGRlZmF1bHRzLg0KDQpbTWVkXSBUaGlzIGZpbHRlcmluZyBjYW4gYmUgYXV0b21h dGljYWxseSBzZXQgYmFzZWQgb24gdGhlIGNvbmZpZ3VyZWQgbGlzdCBvZiBDYWxsIEhvbWUgRE9U UyBjbGllbnRzLiBUaGlzIGlzIGEgd2lkZWx5IHVzZWQgcHJhY3RpY2UgKHRoaW5rIGFib3V0IFNJ UCBwcm94eSBzZXJ2ZXJzLCBleGFtcGxlKS4gTm8gaW50ZXJ2ZW50aW9uIG1heSBiZSByZXF1aXJl ZCBmcm9tIHRoZSB1c2VyLiANCg0KPiANCj4gLS0gU2VjdGlvbiA4Lg0KPiBDYWxsIEhvbWUgRE9U UyBzZXJ2ZXJzIGNhbiBhbHNvIHNlZWsgdGhlIGNvbnNlbnQgb2YgRE9UUw0KPiAgICBzZXJ2ZXIg ZG9tYWluIGFkbWluaXN0cmF0b3IgdG8gYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0aGUNCj4gcG90 ZW50aWFsbHkNCj4gICAgY29tcHJvbWlzZWQgZGV2aWNlIHRvIHRoZSB0YXJnZXQgKHNlZSBTZWN0 aW9uIDUuMy4xKS4NCj4gDQo+IFdoYXQgd291bGQgYmUgdGhlIG1lYW5zIHRvIGdhaW4gc3VjaCBj b25zZW50Pw0KDQpbTWVkXSBUaGlzIHdpbGwgZGVwZW5kIG9uIHRoZSBkZXBsb3ltZW50IGNhc2U6 IHRoaXMgY2FuIGJlIGFuIGFjdGlvbiBleGVjdXRlZCB1c2luZyBhbiBhcHAsIGEgY29uZmlybWF0 aW9uIHRvIGEgbm90aWZpY2F0aW9uIG1lc3NhZ2UsIGV0Yy4gIA0KDQo+IA0KPiAtLSBTZWN0aW9u IDkuDQo+IE5vdGUgdGhhdCBhIENhbGwgSG9tZSBET1RTIHNlcnZlciBjYW4gc2VlayBhbiBhZG1p bmlzdHJhdG9yJ3MNCj4gICAgY29uc2VudCwgdmFsaWRhdGUgdGhlIHJlcXVlc3QgYnkgaW5zcGVj dGluZyB0aGUgcmVsZXZhbnQgdHJhZmZpYw0KPiBmb3INCj4gICAgYXR0YWNrIHNpZ25hdHVyZXMs IG9yIHByb2NlZWQgd2l0aCBib3RoIGNvdXJzZXMgb2YgYWN0aW9uLg0KPiANCj4gQXMgYWJvdmUu DQoNCltNZWRdIEFzIGFib3ZlIDotKQ0KDQo+IA0KPiAtLSBTZWN0aW9uIDkuDQo+IA0KPiAgICAg VGhlIERPVFMgQ2FsbCBIb21lIGlzIG9ubHkgYWR2aXNvcnkgaW4gbmF0dXJlLiAgQ29uY3JldGVs eSwgdGhlDQo+IERPVFMNCj4gICAgQ2FsbCBIb21lIGRvZXMgbm90IGltcG9zZSBhbnkgYWN0aW9u IHRvIGJlIGVuZm9yY2VkIHdpdGhpbiB0aGUNCj4gICAgbmV0d29yayBob3N0aW5nIGFuIGF0dGFj ayBzb3VyY2U7IGl0IGlzIHVwIHRvIHRoZSBDYWxsIEhvbWUgRE9UUw0KPiAgICBzZXJ2ZXIgKGFu ZC9vciBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIHRvIGRlY2lkZSB3aGV0aGVyIGFuZCB3aGljaA0K PiAgICBhY3Rpb25zIGFyZSByZXF1aXJlZC4NCj4gDQo+IFN1Y2ggYSBkZWNpc2lvbnMgc2VlbXMg b3V0IGJleW9uZCB0aGUgYWJpbGl0eSBvZiB5b3VyIGF2ZXJhZ2UgaG9tZQ0KPiByb3V0ZXIgdXNl ci4NCg0KW01lZF0gV2UgZG9uJ3QgaGF2ZSB0aGUgbm90aW9uIG9mICJhdmVyYWdlIGhvbWUgcm91 dGVyIHVzZXIiIDstKSAgDQoNCj4gDQo+IC0tIFNlY3Rpb24gOCAg4oCcLi4uIGV4cGxpY2l0IHBv bGljeSAoZS5nLiwgdGhlIENhbGwgSG9tZSBET1RTIGNsaWVudA0KPiBhbmQgc2VydmVyIGFyZSBt YW5hZ2VkIGJ5IHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGVudGl0eSksDQo+IA0KPiBJcyB0aGVy ZSBhbiB1bmRlcmx5aW5nIGFzc3VtcHRpb24gdGhhdCB0aGUgSVNQIGlzIG1hbmFnaW5nIHRoZQ0K PiBkZXZpY2U/DQoNCltNZWRdIElTUCBtYW5hZ2VkIGRldmljZXMgaXMgb25lIHR5cGljYWwgZGVw bG95bWVudCBjYXNlLiANCg0KVGhhdCdzIHNhaWQsIHRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgbm90 IHNwZWNpZmljIHRvIElTUHMuIEl0IGFwcGxpZXMsIGZvciBleGFtcGxlLCB3aGVuIGdhdGV3YXlz IGFyZSBvbiB0aGUgcGF0aCBhbmQgYm90aCB0aGUgQ2FsbCBIb21lIERPVFMgc2VydmVyIGFuZCBD YWxsIEhvbWUgRE9UUyBjbGllbnQgd2lsbCB0aHVzIGJlIG1hbmFnZWQgYnkgdGhlIERDIHByb3Zp ZGVyLCB0aGUgZW50ZXJwcmlzZSBhZG1pbmlzdHJhdG9yLCB0aGUgYWNjZXNzIHByb3ZpZGVyLCBl dGMuIA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Dec 15 22:18:41 2020 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 5BD483A0FD7; Tue, 15 Dec 2020 22:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 U-N7_Q02jZIV; Tue, 15 Dec 2020 22:18:32 -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 4BFBA3A0FD6; Tue, 15 Dec 2020 22:18:32 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4CwlLZ4Pynz5vfb; Wed, 16 Dec 2020 07:18:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608099510; bh=nRYXw4oe57TXYGELjmewz0Z7LiNdQFm67nOi8MpVKiw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=On8BbhY7aEAhstpDWXCnXzep0zBC/CB5MVq5wZhKwIU9r471mahUGsdmTwn/Yz/xs XYHQwJcKgE6owMN6tv6D8+R+ezZBNat+bD3DyopHjAYL4VabcvvLFF3UXoxAPYL2Wv Yp+Co9z5ro3oRlH9QxXxCbF/HoSQ+S9A9uZkrDXZXjR4/Bb8Tk7hIAZZtG7zGIUCXl J3SltFfIBH5C1Mk3ImzM9zGua3R4HJtfDL/4jJDXwmJ51zCYzL7IF6rbvvPAFp3JRD 2/AhyLT+tVJBnv99Raz4bWknkM2xndPXljwYXQ9LKrQXWCI4CtSi7UgK0GayCxPNGp 0BSTKQhRNQFBQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4CwlLZ31SQz5vN0; Wed, 16 Dec 2020 07:18:30 +0100 (CET) From: To: Barry Leiba , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: Barry Leiba's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT) Thread-Index: AQHW02IWTm7k2KLrMUCoWaMo+CGk0Kn5PrZQ Date: Wed, 16 Dec 2020 06:18:29 +0000 Message-ID: <32602_1608099510_5FD9A6B6_32602_332_1_787AE7BB302AE849A7480A190F8B93303159E23F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160809212550.20134.6936347432271392947@ietfa.amsl.com> In-Reply-To: <160809212550.20134.6936347432271392947@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 06:18:34 -0000 SGkgQmFycnksIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpBbGwgZ29vZCBwb2lu dHMuIEZpeGVkIGF0OiBodHRwczovL3Rpbnl1cmwuY29tL2RvdHMtY2FsbC1ob21lLWxhdGVzdC4g DQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKg OiBCYXJyeSBMZWliYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0K PiBFbnZvecOpwqA6IG1lcmNyZWRpIDE2IGTDqWNlbWJyZSAyMDIwIDA1OjE1DQo+IMOAwqA6IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNh bGwtaG9tZUBpZXRmLm9yZzsgZG90cy0NCj4gY2hhaXJzQGlldGYub3JnOyBkb3RzQGlldGYub3Jn OyBWYWxlcnkgU215c2xvdiA8dmFsZXJ5QHNteXNsb3YubmV0PjsNCj4gdmFsZXJ5QHNteXNsb3Yu bmV0DQo+IE9iamV0wqA6IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt ZG90cy1zaWduYWwtY2FsbC0NCj4gaG9tZS0xMTogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEJhcnJ5 IExlaWJhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBk cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0xMTogTm8gT2JqZWN0aW9uDQo+IA0KPiBX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0bw0KPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8NCj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwg aG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+ IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAtLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiANCj4gVGhhbmtzIGZvciBh biBlYXN5LXRvLXJlYWQgZG9jdW1lbnQuICBJIHVuZGVyc3RhbmQgUm9tYW7igJlzIHBvaW50cywN Cj4gYnV0IGNvbmNsdWRlIHRoYXQgd2hpbGUgYSBwcmltYXJ5IHVzZSBjYXNlIGlzIGZvciBob21l IG5ldHdvcmtzLA0KPiBpdOKAmXMgZXhwZWN0ZWQgdGhhdCB0aGUgc2VydmVyIGZvciB0aGlzIHdp bGwgYmUgYSByb3V0ZXIgdGhhdOKAmXMNCj4gbWFuYWdlZCBieSB0aGUgaG9tZSB1c2Vy4oCZcyBJ U1AsIG5vdCBieSB0aGUgYXZlcmFnZSBob21lIHVzZXIuICBUaGF0DQo+IHNldHVwIGlzIGluY3Jl YXNpbmdseSBjb21tb24sIGF0IGxlYXN0IGluIHRoZSBVLlMuLCBhbmQgaXTigJlzIGVuYWJsZWQN Cj4gbWFueSBzdWNoIGZ1bmN0aW9ucyB0aGF0IHdlcmUgbm90IHByYWN0aWNhbCB3aGVuIHVzZXJz IGhhZCB0bw0KPiBwcm92aWRlIGFuZCBtYW5hZ2UgdGhlaXIgb3duIHJvdXRlcnMuDQo+IA0KPiBJ IGp1c3QgaGF2ZSBhIGZldyB2ZXJ5IG1pbm9yIGNvbW1lbnRzOg0KPiANCj4g4oCUIFNlY3Rpb24g MS4xIOKAlA0KPiANCj4gICAgU3VjaCBtaXNiZWhhdmlvcnMgd2lsbCBoYXZlIGJvdGggYSBjb2xs YXRlcmFsDQo+ICAgIGRhbWFnZSB0aGF0IGFmZmVjdHMgZW5kIHVzZXJzLCBhbmQgY2FuIGhhcm0g dGhlIHJlcHV0YXRpb24gb2YgYW4NCj4gICAgSW50ZXJuZXQgU2VydmljZSBQcm92aWRlciAoSVNQ KSBmb3IgYmVpbmcgYSBzb3VyY2Ugb2YgYXR0YWNrDQo+IHRyYWZmaWMuDQo+IA0KPiBOaXQ6IFRo aXMgc2VudGVuY2UgaXNu4oCZdCBwcm9wZXJseSBmb3JtZWQsIGFzIHRoZSB0d28gcGllY2VzIG9m IHRoZQ0KPiDigJxib3Ro4oCdDQo+IGNvbnN0cnVjdGlvbiBhcmVu4oCZdCBwYXJhbGxlbC4gIEkg c3VnZ2VzdCB0aGlzOg0KPiANCj4gTkVXDQo+ICAgIFN1Y2ggbWlzYmVoYXZpb3JzIGNhbiBjYXVz ZSBjb2xsYXRlcmFsIGRhbWFnZQ0KPiAgICB0aGF0IHdpbGwgYWZmZWN0IGVuZCB1c2VycywgYW5k IGNhbiBhbHNvIGhhcm0gdGhlIHJlcHV0YXRpb24gb2YNCj4gYW4NCj4gICAgSW50ZXJuZXQgU2Vy dmljZSBQcm92aWRlciAoSVNQKSBmb3IgYmVpbmcgYSBzb3VyY2Ugb2YgYXR0YWNrDQo+IHRyYWZm aWMuDQo+IEVORA0KPiANCj4g4oCUIFNlY3Rpb24gNS4xIOKAlA0KPiANCj4gICAgZW5hYmxpbmcg bWVhbnMgZm9yIGF1dG9tYXRpbmcgdGhlDQo+ICAgIHByb3Zpc2lvbmluZyBvZiBjcmVkZW50aWFs cyBvbiBDYWxsIEhvbWUgRE9UUyBzZXJ2ZXJzIHRvDQo+IGF1dGhlbnRpY2F0ZQ0KPiAgICB0byB0 aGUgQ2FsbCBIb21lIERPVFMgY2xpZW50IGFyZSBlbmNvdXJhZ2VkLg0KPiANCj4gTml0OiB0aGUg c3ViamVjdCBvZiB0aGlzIGlzIHRoZSBzaW5ndWxhciDigJxlbmFibGluZ+KAnSwgc28g4oCcZW5h YmxpbmcNCj4gPHN0dWZmPiBpcyBlbmNvdXJhZ2VkLOKAnSBub3Qg4oCcYXJl4oCdLg0KPiANCj4g 4oCUIFNlY3Rpb24gNyDigJQNCj4gVGhyb3VnaG91dCB0aGUgSUFOQSBDb25zaWRlcmF0aW9ucywg cGxlYXNlIG1ha2UgdGhlIGNvbnRhY3QgcG9pbnRzDQo+IGFuZCBjaGFuZ2UgY29udHJvbGxlciBi ZSDigJxJRVRG4oCdIChub3QgSUVTRyBub3IgSUVURiBDaGFpciksIGFuZCB1c2UNCj4gdGhlIGVt YWlsIGFkZHJlc3MgPGllc2dAaWV0Zi5vcmc+LiAgVGhhdOKAmXMgd2hhdCB0aGUgSUVTRyBjb25z aWRlcnMNCj4gdGhlIGJlc3Qgd2F5IHRvIHJlZmVyIHRvIGl0ZW1zIHdoZXJlIHRoZSBJRVRGIGhh cyBjaGFuZ2UgY29udHJvbC4NCj4gDQo+IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Dec 16 04:24:04 2020 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 930AF3A0A20 for ; Wed, 16 Dec 2020 04:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 Qem8cxdOTa6C for ; Wed, 16 Dec 2020 04:24:01 -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 6E2E33A0982 for ; Wed, 16 Dec 2020 04:24:01 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4CwvSH738qz100x; Wed, 16 Dec 2020 13:23:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608121440; bh=7OyWYeKMqT56Me0irqOZaXlPJbsv3KEFjzplFcEIaHY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tkIO4wSDzYIuLgeBqjOrEFCIxzXIWQJ0nrJXVzsu2znjAJ4+PSXlEgaqkRPGjtXdB sZqNJwRpcJhFf+pQc0YLFgvqTrOhQVMs5q7G75WNyxdjVqbXbY6F4uw0Fjq2qIv0LM y6fYAQ9OlcEkuA8UGU9kYBtpyPrPQhs8dV5uYQTjIVgiVZg3FXa6PA0QLUdQG/r59K 64Zqokqu2okrpKAO0Z36aTiTNansa3xlf59nZNO814UdnKSRalVAVIegHnqFsqpgOI 1acYZjWv2JjyZGcitbPFnj0LwCayAUTZT3bvrsVF5ok4s+vswLKwiGXLVJgQJJcvdB dUO94zSfWJk0A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4CwvSH58pcz8sY5; Wed, 16 Dec 2020 13:23:59 +0100 (CET) From: To: "drafts-expert-review@iana.org" CC: "valery@smyslov.net" , "supjps-ietf@jpshallow.com" , "rdd@cert.org" , "kondtir@gmail.com" , "kaduk@mit.edu" , "frank.xialiang@huawei.com" , "dots@ietf.org" Thread-Topic: [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers) Thread-Index: AQHW0zr8gLkMIzr3t0GyrikoobH2r6n5RDoA Date: Wed, 16 Dec 2020 12:23:59 +0000 Message-ID: <14962_1608121439_5FD9FC5F_14962_229_1_787AE7BB302AE849A7480A190F8B93303159E4A1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <7476_1607608054_5FD226F6_7476_116_1_787AE7BB302AE849A7480A190F8B93303159B1FD@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] [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers) 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, 16 Dec 2020 12:24:04 -0000 SGkgU2FicmluYSwgDQoNClRoYW5rIHlvdSBmb3IgcmVsYXlpbmcgdGhlIHJlc3BvbnNlLiANCg0K RE9UUyBjYWxsIGhvbWUgaXMgbm90IGEgInJldmVyc2Ugc2VydmljZSIgb2YgRE9UUyBzaWduYWwg Y2hhbm5lbCBhbmQgaXMgYSAiZnVsbHkgZGVjb3VwbGVkIiBzZXJ2aWNlLiBGV0lXLCBzaW1wbGlm aWVkIGZsb3cgZXhhbXBsZXMgZm9yIGhvdyB0aGVzZSBzZXJ2aWNlcyBhcmUgYWNjZXNzZWQsIGFy ZSBkZXBpY3RlZCBiZWxvdzogDQoNCigxKSBET1RTIFNpZ25hbCBDaGFubmVsOg0KICAgICAgICAg ICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KICAg ICAgICAgICB8ICAgIERPVFMgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBET1RTICAg fA0KICAgICAgICAgICB8ICAgY2xpZW50ICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHNl cnZlciAgfA0KICAgICAgICAgICArLS0tLS0rLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tKy0tLS0tKw0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgKEQpVExTIGNvbm5l Y3Rpb24gICAgICAgfA0KICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0+fA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAuLi4gICAgICAg ICAgICAgICAgICAgfA0KDQooMikgQ2FsbCBIb21lOiANCiAgICAgICAgICAgKy0tLS0tLS0tLS0t KyAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCiAgICAgICAgICAgfCBDYWxs IEhvbWUgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgQ2FsbCBIb21lIHwNCiAgICAgICAgICAg fCAgICBET1RTICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgRE9UUyAgIHwNCiAgICAg ICAgICAgfCAgIHNlcnZlciAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICBjbGllbnQgIHwN CiAgICAgICAgICAgKy0tLS0tKy0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLSst LS0tLSsNCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIChEKVRMUyBjb25uZWN0aW9uICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwNCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAg ICAgIHwNCg0KV2hlbiBhIERUTFMgY29ubmVjdGlvbiBpcyByZWNlaXZlZCBieSBhIGRldmljZSBl bmFibGluZyBib3RoIHNlcnZpY2VzICgiRE9UUyBzZXJ2ZXIiIHNlcnZpY2UgYW5kICJjYWxsIGhv bWUgRE9UUyBjbGllbnQiKSBvbiB0aGUgc2FtZSBwb3J0LCBiYXNlZCBvbiB3aGljaCBjcml0ZXJp YSB0aGUgcmVxdWVzdCB3aWxsIGJlIHN0ZWVyZWQgdG8gdGhlICJET1RTIHNlcnZlciIgc2Vydmlj ZSBvciB0aGUgImNhbGwgaG9tZSBET1RTIGNsaWVudCIgc2VydmljZT8NCg0KSXQgaXMgYWxsIGFi b3V0IHRoZSAoRClUTFMgc2Vzc2lvbiBpbml0aWF0aW9uIHVzaW5nIFVEUCBjb25uZWN0aW5nIHRv IHR3byBkaWZmZXJlbnQsIGZ1bGx5IGRlY291cGxlZCwgc2VydmljZXMgKGEgc2VydmVyIGFuZCBh IGNsaWVudCkgYW5kIGhvdyByZWNlaXZlZCB0cmFmZmljIGlzIGRldGVybWluZWQgdG8gYmUgZ29p bmcgdG8gdGhlIHNlcnZlciBvciB0aGUgY2xpZW50IHNlcnZpY2UuICBXaXRoIFVEUCwgb25seSBh IHNpbmdsZSBhcHBsaWNhdGlvbiBjYW4gImxpc3RlbiIgb24gYSBuZXR3b3JrIHN0YWNrIGZvciB0 cmFmZmljIGJlaW5nIHJlY2VpdmVkIG9uIGEgZGVkaWNhdGVkIHBvcnQuDQoNCkNoZWVycywNCkpv biwgVGlydSwgYW5kIE1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKg OiBTYWJyaW5hIFRhbmFtYWwgdmlhIFJUIFttYWlsdG86ZHJhZnRzLWV4cGVydC1yZXZpZXdAaWFu YS5vcmddDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTYgZMOpY2VtYnJlIDIwMjAgMDA6MzYNCj4g Q2PCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT47DQo+IHZhbGVyeUBzbXlzbG92Lm5ldDsgc3VwanBzLWlldGZAanBzaGFsbG93LmNvbTsg cmRkQGNlcnQub3JnOw0KPiBrb25kdGlyQGdtYWlsLmNvbTsga2FkdWtAbWl0LmVkdTsgZnJhbmsu eGlhbGlhbmdAaHVhd2VpLmNvbTsNCj4gZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBbSUFOQSAj MTE4MTg5N10gZXhwZXJ0IHJldmlldyBmb3IgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC0NCj4gY2Fs bC1ob21lIChzZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycykNCj4gDQo+IEhpIE1lZCwgYWxsLA0K PiANCj4gV2UgaGF2ZSBhIHJlc3BvbnNlIGZyb20gdGhlIElFU0ctZGVzaWduYXRlZCBwb3J0IGV4 cGVydDoNCj4gDQo+IFRoaXMgZG9lc27igJl0IGxvb2sgbGlrZSBhIG5ldyBzZXJ2aWNlOyBpdCBh cHBlYXJzIG1vcmUgbGlrZSBhIHJldmVyc2UNCj4gdmVyc2lvbiBvZiB0aGUgZXhpc3Rpbmcgc2Vy dmljZS4gSU1PLCBpZiB0aGF04oCZcyB0aGUgY2FzZSwgdGhleQ0KPiBzaG91bGQgdXNlIHRoZSBl eGlzdGluZyBhc3NpZ25tZW50IGJlY2F1c2UgdGhlIHR3byBzZXJ2aWNlcyB3b3VsZA0KPiBub3Qg YmUgZnVsbHkgZGVjb3VwbGVkLg0KPiANCj4gPT09DQo+IA0KPiBQbGVhc2UgbGV0IHVzIGtub3cg aWYgeW91IGhhdmUgYW55IGZ1cnRoZXIgY29tbWVudHMvcXVlc3Rpb25zIGZvcg0KPiB0aGUgZXhw ZXJ0Lg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gU2FicmluYSBUYW5hbWFsDQo+IFNlbmlv ciBJQU5BIFNlcnZpY2VzIFNwZWNpYWxpc3QNCj4gDQo+IE9uIFRodSBEZWMgMTAgMTM6NDc6NTgg MjAyMCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiBIaSBTYWJyaW5h LA0KPiA+DQo+ID4gQXBvbG9naWVzIGZvciB0aGUgZGVsYXkgdG8gcmVwbHksIGJ1dCB3ZSB3ZXJl IGFzc2Vzc2luZyBhbmQNCj4gYW5hbHl6aW5nDQo+ID4gd2hldGhlci9ob3cgdG8gZm9sbG93IHRo aXMgc3VnZ2VzdGlvbiBmcm9tIHRoZSBFeHBlcnQgcmV2aWV3OiAidXNlDQo+IHR3bw0KPiA+IGRp ZmZlcmVudCBtZXNzYWdlcyBvbiB0aGUgc2FtZSBwb3J0Ii4gV2UgYWxzbyBjb250YWN0ZWQgdGhl DQo+ID4gaW1wbGVtZW50ZXJzIHRvIGhlbHAgdXMgaW4gdGhlIGFzc2Vzc21lbnQuIFdlIGRpdmVk IGFzIHdlbGwgaW50bw0KPiBvdGhlcg0KPiA+IFdHcyBhcmNoaXZlcyB0byBzZWUgaWYgd2UgY2Fu IGxldmVyYWdlIHdoYXRldmVyIHR3ZWFrIHRoZXkgaGF2ZQ0KPiBmb3VuZA0KPiA+IHRvIHNvbHZl IHNpbWlsYXIgcHJvYmxlbSBpbiB0aGVpciBjb250ZXh0LiBJbiBwYXJ0aWN1bGFyLCB3ZQ0KPiBj aGVja2VkDQo+ID4gbmV0Y29uZiB3ZyBhcmNoaXZlcyB0byBzZWUgaG93IHRoZXkgZGVhbHQgd2l0 aCBkaXNhbWJpZ3VhdGluZw0KPiA+IE5FVENPTkYvUkVTVE9ORiB2cy4gTkVUQ09ORi9SRVNUT05G IENhbGwgSG9tZSkgKFJGQzgwNzEpLg0KPiA+DQo+ID4gT3VyIGNvbmNsdXNpb24gaXMgdGhhdCB0 aGUgYWJvdmUgc3VnZ2VzdGlvbiBjYW4ndCBiZSBmb2xsb3dlZCwNCj4gPiBlc3BlY2lhbGx5IHRo YXQgd2UgZG9uJ3QgZGVmaW5lIHRoZSB0cmFuc3BvcnQgYnV0IHJlbHkgdXBvbg0KPiBleGlzdGlu Zw0KPiA+IG9uZXMuDQo+ID4NCj4gPiBQbGVhc2UgZmluZCBiZWxvdyBtb3JlIGFib3V0IG91ciBy YXRpb25hbGUuDQo+ID4NCj4gPiAoMSkgSXMgdGhpcyBhIG5ldyBzZXJ2aWNlIG9yIGNvdWxkIGFu IGV4aXN0aW5nIHNlcnZpY2Ugc3VmZmljZT8NCj4gPg0KPiA+IERPVFMgQ2FsbCBIb21lIGlzIGEg bmV3IHNlcnZpY2UuDQo+ID4NCj4gPiBUaGUgRE9UUyBzaWduYWwgdHJhZmZpYyBpcyBwcmltYXJp bHkgRFRMUy9VRFAgYW5kIHRoZXJlIGFyZSB0d28NCj4gPiBkaXN0aW5jdCBzZXJ2aWNlcyAtIERP VFMgY2xpZW50IGFuZCBET1RTIHNlcnZlci4gIEluIHRoZSBub3JtYWwNCj4gRE9UUw0KPiA+IGVu dmlyb25tZW50LCB0aGUgRE9UUyBjbGllbnQgaW5pdGlhdGVzIHRoZSBEVExTIGNvbm5lY3Rpb24g dG8gdGhlDQo+IERPVFMNCj4gPiBzZXJ2ZXIgd2hvLCBieSBkZWZhdWx0LCBpcyB3YWl0aW5nIGZv ciB0cmFmZmljIHRvIGFycml2ZSBvbg0KPiA0NjQ2L3VkcC4NCj4gPg0KPiA+IEluIHRoZSBET1RT IGNhbGwtaG9tZSBlbnZpcm9ubWVudCAoaS5lLiwgdGhpcyBzcGVjaWZpY2F0aW9uKSwgdGhlDQo+ IERPVFMNCj4gPiBjYWxsLWhvbWUgc2VydmVyIGluaXRpYXRlcyB0aGUgRFRMUyBjb25uZWN0aW9u IHRvIHRoZSBET1RTIGNhbGwtDQo+IGhvbWUNCj4gPiBjbGllbnQgYW5kIHRoZW4gdGhlIERPVFMg KGNhbGwtaG9tZSkgY2xpZW50IGNvbW11bmljYXRlcyBpbiB0aGUNCj4gc2FtZQ0KPiA+IHdheSB3 aXRoIHRoZSBET1RTIChjYWxsLWhvbWUpIHNlcnZlciBhcyBmb3IgdGhlIG5vcm1hbCBlbnZpcm9u bWVudA0KPiA+IGFwYXJ0IGZyb20gYSBjb3VwbGUgb2Ygc3BlY2lmaWMgZGlmZmVyZW5jZXMgKHRv IGRvIHdpdGggc2Vzc2lvbg0KPiA+IHJlc3RhcnQsIGV0Yy4pLg0KPiA+DQo+ID4gKDIpICBJcyB0 aGlzIHNlcnZpY2UgaW5kZXBlbmRlbnRseSB1c2VmdWw/DQo+ID4NCj4gPiBZZXMuDQo+ID4NCj4g PiBUaGlzIHNlcnZpY2UgaXMgYWJvdXQgbWl0aWdhdGluZyBERG9TIGF0dGFja3MgY2xvc2UgdG8g dGhlaXINCj4gc291cmNlLg0KPiA+IENvbmNyZXRlbHksIHRoaXMgc2VydmljZSBpcyBhYm91dCBw cm90ZWN0aW5nIHRoZSBJbnRlcm5ldCBmcm9tDQo+IEREb1MNCj4gPiBhdHRhY2tzIGNvbWluZyBm cm9tIGEgZ2l2ZW4gZG9tYWluIChvdXRib3VuZCksIHdoaWxlIERPVFMgc2lnbmFsDQo+ID4gKDQ2 NDYvdWRwKSBpcyBhYm91dCBwcm90ZWN0aW5nIGEgZ2l2ZW4gZG9tYWluIGZyb20gRERvUyBhdHRh Y2tzDQo+IGNvbWluZw0KPiA+IGZyb20gdGhlIEludGVybmV0IChJbmJvdW5kKS4NCj4gPg0KPiA+ IEJvdGggc2VydmljZXMgKG91dGJvdW5kIHByb3RlY3Rpb24vaW5ib3VuZCBwcm90ZWN0aW9uKSBh cmUgdXNlZnVsLg0KPiA+DQo+ID4gQSBjdXN0b21lciBjYW4gc3Vic2NyaWJlIHRvIGJvdGggb3Ig b25seSBvbmUgb2YgdGhlbS4NCj4gPg0KPiA+ICgzKSBXaHkgdHdvIHBvcnQgbnVtYmVycyBhcmUg bmVlZGVkPw0KPiA+DQo+ID4gSXQgaXMgbGlrZWx5IHRoYXQgYSBET1RTIHNlcnZlciBzZXJ2aWNl IHdpbGwgY28tZXhpc3Qgd2l0aCBhIERPVFMNCj4gPiBjYWxsLWhvbWUgY2xpZW50IHNlcnZpY2Ug YmVoaW5kIHRoZSBzYW1lIElQIGFkZHJlc3MgYW5kIGJlDQo+IHJlY2VpdmluZw0KPiA+IGJvdGgg dHlwZXMgb2YgaW5ib3VuZCB0cmFmZmljIGNvbmN1cnJlbnRseSAtIHNvbWUgYmVpbmcgRE9UUw0K PiBzZXJ2ZXIsDQo+ID4gYW5kIHNvbWUgYmVpbmcgRE9UUyBjYWxsLWhvbWUgY2xpZW50LiBJdCBp cyBwb3NzaWJsZSB0aGF0IGEgRE9UUw0KPiA+IGNsaWVudCBzZXJ2aWNlIGNhbiBjby1leGlzdCB3 aXRoIGEgRE9UUyBjYWxsLWhvbWUgc2VydmVyIHNlcnZpY2UNCj4gb24gYW4NCj4gPiBhcHBsaWFu Y2UuDQo+ID4NCj4gPiBXaGVuIGEgRFRMUyBjb25uZWN0aW9uIGlzIHJlY2VpdmVkIGJ5IGEgZGV2 aWNlIGhvc3RpbmcgYm90aCBET1RTDQo+ID4gc2VydmVyIHNlcnZpY2UgYW5kIERPVFMgY2FsbC1o b21lIGNsaWVudCBzZXJ2aWNlLCBpdCBkb2VzIG5vdCBrbm93DQo+ID4gd2hpY2ggc2VydmljZSBp cyBpbnZva2VkLiAqKiBEaXNhbWJpZ3VhdGluZyB0aGVzZSB0d28gc2VydmljZXMgaXMNCj4gdGh1 cw0KPiA+IHJlcXVpcmVkICoqLg0KPiA+DQo+ID4gQXMgdGhlcmUgaXMgbm8gc2ltcGxlIHdheSB0 byBzdGVlciBpbmJvdW5kIFVEUC9EVExTIHRyYWZmaWMgZ29pbmcNCj4gdG8NCj4gPiB0aGUgc2Ft ZSBVRFAgcG9ydCBvbiB0aGUgc2FtZSBJUCB0byAyIHNlcGFyYXRlLCBpbmNvbXBhdGlibGUNCj4g c2VydmljZXMsDQo+ID4gdGhlIERPVFMgc2VydmVyIGFuZCBET1RTIGNhbGwtaG9tZSBjbGllbnQg aGF2ZSB0byBiZSBsaXN0ZW5pbmcgb24NCj4gMg0KPiA+IGRpc2NyZXRlIHBvcnRzLg0KPiA+DQo+ ID4gVGhlIG92ZXJoZWFkIG9mIHJlLWRpcmVjdGluZyB0cmFmZmljIHRvIHVzZSBhIGRpZmZlcmVu dCBwb3J0IChEVExTDQo+ID4gaGFuZHNoYWtlIHNldHVwLCBhcHBsaWNhdGlvbiByZWRpcmVjdCBw YWNrZXQsIG5ldyBEVExTIGhhbmRzaGFrZQ0KPiA+IHNldHVwKSBpcyB1bmFjY2VwdGFibGUgZ2l2 ZW4gdGhhdCB0aGUgRE9UUyBwcm90b2NvbHMgd2lsbCBnZXQgdXNlZA0KPiBpbg0KPiA+IGVudmly b25tZW50cyB3aGVyZSB0aGVyZSBhcmUgRERvUyBhdHRhY2tzIGFuZCBoZW5jZSB0cmFmZmljIGxv c3MuDQo+ID4NCj4gPiBUaGlzIGlzIGFscmVhZHkgZGlzY3Vzc2VkIGluIEFwcGVuZGl4IEEgb2Yg dGhlIGRyYWZ0Lg0KPiA+DQo+ID4gKDQpIFdoeSBub3QgdXNpbmcgYSBkeW5hbWljIHBvcnQgbnVt YmVyIGZvbGxvd2luZywgZS5nLiwgZHJhZnQtDQo+IGlldGYtDQo+ID4gZG90cy1zZXJ2ZXItZGlz Y292ZXJ5Pw0KPiA+DQo+ID4gVGhhdCBtaWdodCBiZSBwb3NzaWJsZSBpbiBzb21lIGNvbnRleHRz IChlLmcuLCB0aGUgbWl0aWdhdGlvbg0KPiBwcm92aWRlcg0KPiA+IGlzIGFsc28gdGhlIGFjY2Vz cyBwcm92aWRlciksIG5ldmVydGhlbGVzcyBzdWNoIHRvb2xzIGFyZSBub3QNCj4gdXNlZnVsLA0K PiA+IGUuZy4sIHdoZW4gbm8gKiogZXhwbGljaXQgSVAgYWRkcmVzcyBjb25maWd1cmF0aW9uICoq IGlzIGludm9sdmVkDQo+IGFuZA0KPiA+IHRoZSBhZ2VudCBhdXRvLWRpc2NvdmVycyBpdHMuIFRo aXMgaXMgc2ltaWxhciB0byB0aGVzZSBjYXNlcw0KPiBkaXNjdXNzZWQNCj4gPiBpbiBSRkM4Nzgy Og0KPiA+DQo+ID4gfCAgUGFydGljdWxhcmx5LCB0aGUgdXNlIG9mIGEgZGVmYXVsdCBwb3J0IG51 bWJlciBpcyBtZWFudCB0bw0KPiA+IHwgc2ltcGxpZnkgRE9UUyBkZXBsb3ltZW50IGluIHNjZW5h cmlvcyB3aGVyZSBubyBleHBsaWNpdCBJUA0KPiBhZGRyZXNzDQo+ID4gfCBjb25maWd1cmF0aW9u IGlzIHJlcXVpcmVkLiAgRm9yIGV4YW1wbGUsIHRoZSB1c2Ugb2YgdGhlICBkZWZhdWx0DQo+ID4g fCByb3V0ZXIgYXMgdGhlIERPVFMgc2VydmVyIGFpbXMgdG8gZWFzZSBET1RTIGRlcGxveW1lbnQg IHdpdGhpbg0KPiBMQU5zDQo+ID4gfCAoaW4gd2hpY2ggQ1BFcyBlbWJlZCBhIERPVFMgZ2F0ZXdh eSBhcyBpbGx1c3RyYXRlZCAgaW4gRmlndXJlcyAxDQo+IGFuZA0KPiA+IHwgMikgd2l0aG91dCBy ZXF1aXJpbmcgYSBzb3BoaXN0aWNhdGVkIGRpc2NvdmVyeSAgbWV0aG9kIGFuZA0KPiA+IHwgY29u ZmlndXJhdGlvbiB0YXNrcyB3aXRoaW4gdGhlIExBTi4gIEl0IGlzIGFsc28gIHBvc3NpYmxlIHRv IHVzZQ0KPiA+IHwgYW55Y2FzdCBhZGRyZXNzZXMgZm9yIERPVFMgc2VydmVycyB0byBzaW1wbGlm eSAgRE9UUyBjbGllbnQNCj4gPiB8IGNvbmZpZ3VyYXRpb24sIGluY2x1ZGluZyBzZXJ2aWNlIGRp c2NvdmVyeS4gIEluICBzdWNoIGFuDQo+ID4gfCBhbnljYXN0LWJhc2VkIHNjZW5hcmlvLCBhIERP VFMgY2xpZW50IGluaXRpYXRpbmcgYSBET1RTICBzZXNzaW9uDQo+IHRvDQo+ID4gfCB0aGUgRE9U UyBzZXJ2ZXIgYW55Y2FzdCBhZGRyZXNzIG1heSwgZm9yIGV4YW1wbGUsIGJlDQo+ID4gfCAgKDEp IHJlZGlyZWN0ZWQgdG8gdGhlIERPVFMgc2VydmVyIHVuaWNhc3QgYWRkcmVzcyB0byBiZSB1c2Vk IGJ5DQo+ID4gfCB0aGUgRE9UUyBjbGllbnQgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgZGlzY3Vz c2VkIGluICBTZWN0aW9uDQo+IDQuNiBvcg0KPiA+IHwgKDIpIHJlbGF5ZWQgdG8gYSB1bmljYXN0 IERPVFMgc2VydmVyLg0KPiA+DQo+ID4gRXZlbiBmb3IgY2FzZXMgd2hlcmUgZHJhZnQtaWV0Zi1k b3RzLXNlcnZlci1kaXNjb3ZlcnkgY2FuIGJlIHVzZWQsDQo+ID4gbGVhcm5pbmcgdGhlIHBvcnQg bnVtYmVyIHdpbGwgcmVxdWlyZSB0byBwYXNzIHRoZSBkaXNjb3ZlcmVkDQo+IHJlZmVyZW5jZQ0K PiA+IHRvIGEgRE5TIGxpYnJhcnkgKEROUy1TRCBvciBTLU5BUFRSKS4gSWYgYSBERG9TIGF0dGFj ayBpcw0KPiBvY2N1cnJpbmcsDQo+ID4gRE5TIHNlcnZpY2VzIG1heSBub3QgYmUgYXZhaWxhYmxl IGZvciB0aGUgY2FsbC1ob21lIERPVFMgc2VydmVyIHRvDQo+ID4gdXNlLiBXaGljaCBpcyBwcm9i bGVtYXRpYyB0byBwcm92aWRlIHRoZSBzZXJ2aWNlIGlmIHRoZSBzZXNzaW9uIGlzDQo+IG5vdA0K PiA+IGVzdGFibGlzaGVkIHByaW9yIHRvIGFuIGF0dGFjayBpcyBkZXRlY3RlZC4gT2J2aW91c2x5 LCBubyBpc3N1ZSBpcw0KPiA+IGVuY291bnRlcmVkIGlmIHRoZSBzZXNzaW9uIGlzIGVzdGFibGlz aGVkIGRpbiBpZGxlIHRpbWUuDQo+ID4NCj4gPiBPZiBjb3Vyc2UsIGlmIG1hbnVhbCBjb25maWd1 cmF0aW9uIGlzIHVzZWQgZm9yIElQIGFkZHJlc3MNCj4gPiBjb25maWd1cmF0aW9uLCB0aGUgcG9y dCBudW1iZXIgY2FuIGJlIHN1cHBsaWVkIGFzIHdlbGwuDQo+ID4NCj4gPiAoNSkgV2h5IG5vdCBt YW5kYXRpbmcgcnVubmluZyB0aGUgc2VydmljZXMgb24gZGlzdGluY3QgZGV2aWNlcz8NCj4gPg0K PiA+IEFzIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQsIGEgZGVwbG95bWVudCBvcHRpb24gaXMgdG8g cnVuIHRoZQ0KPiBzZXJ2aWNlcw0KPiA+IHVzaW5nIGRpc3RpbmN0IElQIGFkZHJlc3Nlcy4gSW4g c3VjaCBjYXNlLCBubyBwcm9ibGVtIGlzDQo+IGVuY291bnRlcmVkDQo+ID4gZXZlbiBpZiB0aGUg c2FtZSBwb3J0IG51bWJlciBpcyB1c2VkIGZvciBib3RoIHNlcnZpY2VzLg0KPiA+DQo+ID4gTmV2 ZXJ0aGVsZXNzLCB3ZSBjYW4ndCBtYW5kYXRlIHRoaXMgZGVwbG95bWVudCBvcHRpb24gYW5kIGl0 IGlzIHVwDQo+IHRvDQo+ID4gdGhlIHRhc3RlIG9mIG9wZXJhdG9yIHRvIGRlY2lkZSB3aGV0aGVy IHRvIHJ1biB0aGUgc2VydmljZXMgb24gdGhlDQo+ID4gc2FtZSBvciBkaXN0aW5jdCBtYWNoaW5l cy4NCj4gPg0KPiA+ICg2KSBEaXNhbWJpZ3VhdGluZyBhdCBET1RTIEdhdGV3YXlzDQo+ID4NCj4g PiBUaGUgcHJlc2VuY2Ugb2YgZ2F0ZXdheXMgb24gdGhlIHBhdGggaXMgYWxzbyBjaGFsbGVuZ2lu ZyBldmVuIGlmDQo+IHRoZQ0KPiA+IHVsdGltYXRlIHNlcnZpY2VzIGFyZSBydW5uaW5nIG9uIGRp c3RpbmN0IElQIGFkZHJlc3Nlcy4gR2F0ZXdheXMNCj4gbXVzdA0KPiA+IGhhdmUgbWVhbnMgdG8g ZGVjaWRlIHdoZXRoZXIgYSBtZXNzYWdlIGlzIHRvIGJlIGRlc3RpbmVkIHRvIERPVFMNCj4gPiBz ZXJ2ZXIgc2VydmljZSBvciBET1RTIGNhbGwtaG9tZSBET1RTIGNsaWVudCBzZXJ2aWNlLg0KPiA+ DQo+ID4gUmVxdWlyaW5nIHNlZ3JlZ2F0aW5nIGdhdGV3YXlzIGZvciBlYWNoIG9mIHRoZSBzZXJ2 aWNlcyBpcyBub3QNCj4gdmlhYmxlLg0KPiA+DQo+ID4gKDcpIEltcGxlbWVudGF0aW9uIGNvbXBs ZXhpdHkNCj4gPg0KPiA+IExldCdzIGFzc3VtZSB0aGF0IGJ5IHNvbWUgIm1hZ2ljIiB3ZSBjYW4g ZGVtdXggdGhlIHR3byBzZXJ2aWNlcy4NCj4gPg0KPiA+IEFmdGVyIHRoZSByZWNlaXZpbmcgdGhl IHJlc3BvbnNlIGZyb20gdGhlIEV4cGVydCwgdGhlIGF1dGhvcnMgaGF2ZQ0KPiA+IGNoZWNrZWQg d2l0aCB0aGUgdHdvIG1haW4gZGVzaWduZXJzIG9mIHRoZSB0d28gZGlmZmVyZW50IERPVFMNCj4g PiBpbXBsZW1lbnRhdGlvbnMgKG9uZSBwcm9wcmlldGFyeSBhbmQgb25lIG9wZW4gc291cmNlKSBh bmQgYm90aCBvZg0KPiB0aGVtDQo+ID4gaGF2ZSBzYWlkIHRoYXQgaXQgd291bGQgdGFrZSBzaWdu aWZpY2FudCB3b3JrIHRvIG1lcmdlIHRoZSBET1RTDQo+IGNsaWVudA0KPiA+IGFuZCBzZXJ2ZXIg c2VydmljZSBsb2dpYyBpbnRvIGEgc2luZ2xlIGVudGl0eS4gIFRoZXkgYXJlIGFsc28NCj4gPiBj b25jZXJuZWQgd2l0aCBjb21iaW5lZCBzZXJ2ZXIvY2xpZW50IHNlcnZpY2UgZnVuY3Rpb25hbGl0 eQ0KPiBydW5uaW5nIG9uDQo+ID4gY29uc3RyYWluZWQgZGV2aWNlcyB3aGVyZSB0aGVyZSBhcmUg UkFNIHNwYWNlIGxpbWl0YXRpb25zLCBldGMuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gSm9uLCBU aXJ1LCBhbmQgTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ ID4gRGXCoDogU2FicmluYSBUYW5hbWFsIHZpYSBSVCBbbWFpbHRvOmRyYWZ0cy1leHBlcnQtDQo+ IHJldmlld0BpYW5hLm9yZ10NCj4gPiA+IEVudm95w6nCoDogbWVyY3JlZGkgMjUgbm92ZW1icmUg MjAyMCAwNToyNSBDY8KgOg0KPiB2YWxlcnlAc215c2xvdi5uZXQ7DQo+ID4gPiBzdXBqcHMtaWV0 ZkBqcHNoYWxsb3cuY29tOyByZGRAY2VydC5vcmc7IEJPVUNBREFJUiBNb2hhbWVkDQo+IFRHSS9P TE4NCj4gPiA+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsga29uZHRpckBnbWFpbC5j b207DQo+IGthZHVrQG1pdC5lZHU7DQo+ID4gPiBmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tIE9i amV0wqA6IFtJQU5BICMxMTgxODk3XSBleHBlcnQgcmV2aWV3DQo+IGZvcg0KPiA+ID4gZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC0gY2FsbC1ob21lIChzZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycykN Cj4gPiA+DQo+ID4gPiBEZWFyIEF1dGhvcnMsDQo+ID4gPg0KPiA+ID4gSGF2ZSB5b3UgaGFkIGEg Y2hhbmNlIHRvIHJldmlldyB0aGUgZXhwZXJ0J3MgY29tbWVudHMgYmVsb3c/DQo+ID4gPiBMZXQg dXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMvcXVlc3Rpb25zIGZvciB0aGUgZXhwZXJ0 Lg0KPiA+ID4NCj4gPiA+IFRoYW5rIHlvdSwNCj4gPiA+DQo+ID4gPiBTYWJyaW5hIFRhbmFtYWwN Cj4gPiA+IFNlbmlvciBJQU5BIFNlcnZpY2VzIFNwZWNpYWxpc3QNCj4gPiA+DQo+ID4gPiBPbiBU aHUgTm92IDEyIDIyOjQyOjQ4IDIwMjAsIHNhYnJpbmEudGFuYW1hbCB3cm90ZToNCj4gPiA+ID4g RGVhciBBdXRob3JzLA0KPiA+ID4gPg0KPiA+ID4gPiBXZSBoYXZlIGEgcmVzcG9uc2UgZnJvbSB0 aGUgSUVTRy1kZXNpZ25hdGVkIHBvcnQgZXhwZXJ0Og0KPiA+ID4gPg0KPiA+ID4gPiBJIGRvIG5v dCBzZWUgc3VmZmljaWVudCByZWFzb24gZm9yIGEgc2Vjb25kIHBvcnQgYXNzaWdubWVudCB0bw0K PiBiZQ0KPiA+ID4gbWFkZQ0KPiA+ID4gPiBmb3IgdGhpcyBzaW5nbGUgc3lzdGVtLiBBdCBiZXN0 LCB0aGV5IHNob3VsZCBqdXN0IHVzZSB0d28NCj4gPiA+IGRpZmZlcmVudA0KPiA+ID4gPiBtZXNz YWdlcyBvbiB0aGUgc2FtZSBwb3J0Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIHJlcXVlc3Qgc2hv dWxkIG5vdCBiZSBjb25zaWRlcmVkIGluIGlzb2xhdGlvbjsgaXQgaXMNCj4gY291cGxlZA0KPiA+ ID4gdG8NCj4gPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90 cy1zZXJ2ZXItZGlzY292ZXJ5Lg0KPiA+ID4gPg0KPiA+ID4gPiBPbmUgc2VydmljZSwgb25lIHBv cnQuDQo+ID4gPiA+DQo+ID4gPiA+ID09PQ0KPiA+ID4gPg0KPiA+ID4gPiBCZXN0IHJlZ2FyZHMs DQo+ID4gPiA+DQo+ID4gPiA+IFNhYnJpbmEgVGFuYW1hbA0KPiA+ID4gPiBTZW5pb3IgSUFOQSBT ZXJ2aWNlcyBTcGVjaWFsaXN0DQo+ID4NCj4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fDQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4NCj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMNCj4gPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0KPiBkaWZmdXNlcywNCj4gPiBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZQ0KPiBtZXNzYWdl DQo+ID4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUNCj4gYWluc2kNCj4gPiBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudA0KPiBzdXNjZXB0aWJsZXMNCj4gPiBkJ2FsdGVyYXRp b24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYQ0K PiBldGUNCj4gPiBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+DQo+ID4g VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OyB0aGV5IHNob3VsZA0KPiBub3QNCj4gPiBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiBhbmQNCj4gPiBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiBoYXZl DQo+ID4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4gVGhhbmsgeW91 Lg0KPiANCj4gPHA+PC9wPg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Dec 16 07:30:10 2020 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 2D35D3A0FB5; Wed, 16 Dec 2020 07:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 NDIBp7NVlcfh; Wed, 16 Dec 2020 07:30:06 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (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 0B1393A0F39; Wed, 16 Dec 2020 07:30:05 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id u18so49343548lfd.9; Wed, 16 Dec 2020 07:30:05 -0800 (PST) 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:content-transfer-encoding; bh=AzjHAjKL9M9OotjSrMy1f2cmtnUJ+zAa2FsVV/IcBpA=; b=bfYtl3ed3RAhkBN6Qe+vQlZVdBEZ8hOuvdfZYsXExWpvcnptDaAULgpOEXOC48burC +6OOcOv5Rg8aMsG5Px2sHBAGrBWug8M96nl7uRLYHGVW5Kw9jF7t00+KwgUOqejKwEDQ GJAeeNLHPn6Ak1CGDDMjc0UJjIWEoAK28nBSp2m0+ylP2q7YKT46nYBdRfTRDMlK3jkf 0Wo30uhKyGxTRSZsyBmaMKUXAVLeBtmgjC+q3phvPrHGfAnreRfTpzWdzbtuz7BIbZ5i jT16I09iOxnWUsScz7+Y0bjT9bUyaa29wG1MO836CCKODR28c6mxMeXK1eh3QnnGwnMl 5OAg== X-Gm-Message-State: AOAM532AJKKPsH1q51poLR2fm8eNMhoTgcI4zRvh6rcmsK2IV7sG1K1A fFgMfGTNQAPOqmCCjdbqiZCC92yzYf43zDSjguc= X-Google-Smtp-Source: ABdhPJyN48Hn90rIO1pzIh/rOqe+iVX0b9F/1m1WOrkNb/rYjQUy6PQsYMKKaBzM4ft7E0YEGgoertYB0/2CB5sls4A= X-Received: by 2002:a05:6512:786:: with SMTP id x6mr12314132lfr.643.1608132603798; Wed, 16 Dec 2020 07:30:03 -0800 (PST) MIME-Version: 1.0 References: <160809212550.20134.6936347432271392947@ietfa.amsl.com> <32602_1608099510_5FD9A6B6_32602_332_1_787AE7BB302AE849A7480A190F8B93303159E23F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <32602_1608099510_5FD9A6B6_32602_332_1_787AE7BB302AE849A7480A190F8B93303159E23F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Barry Leiba Date: Wed, 16 Dec 2020 10:29:52 -0500 Message-ID: To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 15:30:08 -0000 Thanks, Med, for the quick response, as always. Barry On Wed, Dec 16, 2020 at 1:18 AM wrote: > > Hi Barry, > > Thank you for the review. > > All good points. Fixed at: https://tinyurl.com/dots-call-home-latest. > > Cheers, > Med > > > -----Message d'origine----- > > De : Barry Leiba via Datatracker [mailto:noreply@ietf.org] > > Envoy=C3=A9 : mercredi 16 d=C3=A9cembre 2020 05:15 > > =C3=80 : The IESG > > Cc : draft-ietf-dots-signal-call-home@ietf.org; dots- > > chairs@ietf.org; dots@ietf.org; Valery Smyslov ; > > valery@smyslov.net > > Objet : Barry Leiba's No Objection on draft-ietf-dots-signal-call- > > home-11: (with COMMENT) > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-dots-signal-call-home-11: No Objection > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ > > > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Thanks for an easy-to-read document. I understand Roman=E2=80=99s poin= ts, > > but conclude that while a primary use case is for home networks, > > it=E2=80=99s expected that the server for this will be a router that=E2= =80=99s > > managed by the home user=E2=80=99s ISP, not by the average home user. = That > > setup is increasingly common, at least in the U.S., and it=E2=80=99s en= abled > > many such functions that were not practical when users had to > > provide and manage their own routers. > > > > I just have a few very minor comments: > > > > =E2=80=94 Section 1.1 =E2=80=94 > > > > Such misbehaviors will have both a collateral > > damage that affects end users, and can harm the reputation of an > > Internet Service Provider (ISP) for being a source of attack > > traffic. > > > > Nit: This sentence isn=E2=80=99t properly formed, as the two pieces of = the > > =E2=80=9Cboth=E2=80=9D > > construction aren=E2=80=99t parallel. I suggest this: > > > > NEW > > Such misbehaviors can cause collateral damage > > that will affect end users, and can also harm the reputation of > > an > > Internet Service Provider (ISP) for being a source of attack > > traffic. > > END > > > > =E2=80=94 Section 5.1 =E2=80=94 > > > > enabling means for automating the > > provisioning of credentials on Call Home DOTS servers to > > authenticate > > to the Call Home DOTS client are encouraged. > > > > Nit: the subject of this is the singular =E2=80=9Cenabling=E2=80=9D, so= =E2=80=9Cenabling > > is encouraged,=E2=80=9D not =E2=80=9Care=E2=80=9D. > > > > =E2=80=94 Section 7 =E2=80=94 > > Throughout the IANA Considerations, please make the contact points > > and change controller be =E2=80=9CIETF=E2=80=9D (not IESG nor IETF Chai= r), and use > > the email address . That=E2=80=99s what the IESG consid= ers > > the best way to refer to items where the IETF has change control. > > > > > > > _________________________________________________________________________= ________________________________________________ > > 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. > From nobody Wed Dec 16 18:16:37 2020 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 6A4603A1384; Wed, 16 Dec 2020 18:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=42n/q5bs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hiBVcPJ5 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 XjxaYYGJYWDk; Wed, 16 Dec 2020 18:16:32 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FB13A0A4A; Wed, 16 Dec 2020 18:16:32 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4EBCF5C00F0; Wed, 16 Dec 2020 21:16:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 16 Dec 2020 21:16:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=L 7Ch3RmWpGKD2TJX13cALaRG9Feow5G6ZrtiVCs5wcs=; b=42n/q5bsgD9isfNIw esAKSXuO2li1nbJGbeoqo0gAx9lDi/KEP95Eo5Gg2Nzdg47W/sU10/hKZb7r+InH 5nYcOlIRvmfChloefW9waB+GIGA+DBziggJmUG/AMCOrCEHHuyQI90O0ocnOKdLB vEWI1WotGFU92zppkSZvZH+zL3cm8dBkza1MFHZcl4J+eKOq8X16ysuHzLczZlmM tXcH3U++8nvwbjocKjdiW+DAh8TZau0ggP9P2PsZA9O8fnFg4243rGYJC8M+/Y7K M4s9wCJgqzwMMxe2Her32M4wR3Mn0Vdq0VhxspC8ws3GHir7z/x266IlerB+xqvr H+NnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=L7Ch3RmWpGKD2TJX13cALaRG9Feow5G6ZrtiVCs5w cs=; b=hiBVcPJ5tSO2rLuTj7FYIBnKBYt/CcDyf1jHyEh3I1ZpR6QSRZDOBIiq2 HbgXw4pPfGQvaF8as9uwOL/ydDWxca2Rdtici7SesfcvV+iro+7WQNZylpL5eFBR BbpwUmozePu/QHaieGgsV8dINVUzRmKKA6AFyb0m3AhurbCve8cvt893g7d9jWfT E7DrKB9q/vMy22ZWFRuBdBKUrDb9C7JhDy6QzGs87uU+301l+OgMaK9TD8rG0fXc tRHB4w69Oc3vobr+bVz4lS6AGlFp0+CTOTUrxiTrY91CwqEeNBGeeKL+8mdrn+hW 6jSwGrVREUI707tKwJT9g0aeEKIWw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelfedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceorghlihhsshgrsegt ohhophgvrhifrdhinheqnecuggftrfgrthhtvghrnhepfeduhffgtefgtedvvdffiedutd ekffegvdejjedtieehfefgleefuedtledvgffgnecuffhomhgrihhnpehivghtfhdrohhr ghenucfkphepudejfedrfeekrdduudejrdeludenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-vpn4-1171.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 9AD29108005B; Wed, 16 Dec 2020 21:16:29 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <160410062532.4190.5949270228585035968@ietfa.amsl.com> Date: Wed, 16 Dec 2020 21:16:29 -0500 Cc: General Area Review Team , last-call@ietf.org, draft-ietf-dots-signal-call-home.all@ietf.org, dots@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6AAF36FF-E13C-47CA-9CBE-52278768BDAE@cooperw.in> References: <160410062532.4190.5949270228585035968@ietfa.amsl.com> To: David Schinazi X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Dots] [Gen-art] Genart last call review of draft-ietf-dots-signal-call-home-11 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, 17 Dec 2020 02:16:36 -0000 David, thanks for your review. I entered a No Objection ballot. Alissa > On Oct 30, 2020, at 7:30 PM, David Schinazi via Datatracker = wrote: >=20 > Reviewer: David Schinazi > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-dots-signal-call-home-11 > Reviewer: David Schinazi > Review Date: 2020-10-30 > IETF LC End Date: 2020-11-12 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Thanks for a clear document, I didn't see any issues from a = GenART perspective. >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Dec 16 23:57:12 2020 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 0C77D3A1530; Wed, 16 Dec 2020 23:57:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160819182651.13957.11446411934602445362@ietfa.amsl.com> Date: Wed, 16 Dec 2020 23:57:07 -0800 Archived-At: Subject: [Dots] Erik Kline's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 07:57:07 -0000 Erik Kline has entered the following ballot position for draft-ietf-dots-signal-call-home-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ questions ]] [ section 5.3.1 ] * Can the source-prefix include IPv4/IPv6 link-local prefixes? Can the server and client be on the same link (and therefore link-local addresses might have some discernable meaning)? From nobody Thu Dec 17 00:21:13 2020 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 793313A10E9; Thu, 17 Dec 2020 00:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 ItEnXQ1mRGCD; Thu, 17 Dec 2020 00:21:10 -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 3DBCF3A10E5; Thu, 17 Dec 2020 00:21:10 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar27.francetelecom.fr (ESMTP service) with ESMTPS id 4CxQ1b5Hn0z2xkY; Thu, 17 Dec 2020 09:21:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608193267; bh=wxVRcNXAKKKQxL/Kdw1X9XWYizbE7lV0OBbES6tzFqo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rHxBlOggNkpW9xmkbBTKnR6BC9rSuytF0/brNpbgyz4JY8EBGSthcGH+qBLlo2QA7 M+2i3JvIoXNCmhndmQeJsGZKACGSmnZ6anNJi5GUez2aw1vO6Qx1vkt0U1yX+9gG+4 HFqDrR4NHKBz4mwbKoUO9JL2q+YLo/bcxHbL7jv2RmzAL52mSGVO+Nco0199dx5b0b SkP6a1HAcuaiRUMnZLLItQcPaLmPTlzohdEM+TyOJdfoWWqL9P4+omDytIHQUAmU62 2AkG8i+jF9TVZm7c3aitqh8NCxy8Az2j6tvvtsV1beUV8RAsU2e3AKXzE/ANgmL7SA aBHfbJ0U3GzDw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4CxQ1b3ZSxzCqkK; Thu, 17 Dec 2020 09:21:07 +0100 (CET) From: To: Erik Kline , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: Erik Kline's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT) Thread-Index: AQHW1Eo4pwsM62KBjUO7y+DPWy1N76n67OPQ Date: Thu, 17 Dec 2020 08:21:06 +0000 Message-ID: <26526_1608193267_5FDB14F3_26526_36_3_787AE7BB302AE849A7480A190F8B93303159EE7A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160819182651.13957.11446411934602445362@ietfa.amsl.com> In-Reply-To: <160819182651.13957.11446411934602445362@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Erik Kline's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 08:21:13 -0000 SGkgRXJpaywgDQoNCj4gKiBDYW4gdGhlIHNvdXJjZS1wcmVmaXggaW5jbHVkZSBJUHY0L0lQdjYg bGluay1sb2NhbCBwcmVmaXhlcz8NCj4gDQoNClllcy4gT25seSBtdWx0aWNhc3QvYnJvYWRjYXN0 L2xvb3BiYWNrIGFkZHJlc3NlcyBhcmUgbm90IGFsbG93ZWQuIA0KDQo+ICAgQ2FuIHRoZSBzZXJ2 ZXIgYW5kIGNsaWVudCBiZSBvbiB0aGUgc2FtZSBsaW5rIChhbmQgdGhlcmVmb3JlDQo+ICAgbGlu ay1sb2NhbCBhZGRyZXNzZXMgbWlnaHQgaGF2ZSBzb21lIGRpc2Nlcm5hYmxlIG1lYW5pbmcpPw0K DQpZZWFoLiBBIERPVFMgZ2F0ZXdheSBtYXkgYmUgZW1iZWRkZWQgaW4gdGhlIGFjY2VzcyByb3V0 ZXIuIFRoYXTigJlzIHNhaWQsIHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGUgQGVz IHRvIHJlYWNoIHRoZSBET1RTIGFnZW50cyB2cy4gdGhlIG9uZXMgc2lnbmFsZWQgaW4gdGhlIERP VFMgbWVzc2FnZXMgKHdoaWNoIGJlbG9uZyB0byB0aGUgYXR0YWNrIHNvdXJjZXMpLg0KDQpBbiBl eGFtcGxlIG9mIHRoZSB1c2Ugb2YgbGluay1sb2NhbCBAc2VzIGlzIHdoYXQgaXMgaGludGVkIGlu IMOJcmljJ3MgcmV2aWV3OiAiaWYgdGhlIENQRSBpcyBhIGxheWVyLTIgbm9kZSIuDQoNCkNoZWVy cywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBFcmlrIEts aW5lIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nC oDogamV1ZGkgMTcgZMOpY2VtYnJlIDIwMjAgMDg6NTcNCj4gw4DCoDogVGhlIElFU0cgPGllc2dA aWV0Zi5vcmc+DQo+IENjwqA6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lQGlldGYu b3JnOyBkb3RzLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmc7IFZhbGVyeSBTbXlz bG92IDx2YWxlcnlAc215c2xvdi5uZXQ+Ow0KPiB2YWxlcnlAc215c2xvdi5uZXQNCj4gT2JqZXTC oDogRXJpayBLbGluZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNh bGwtDQo+IGhvbWUtMTE6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBFcmlrIEtsaW5lIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWRvdHMt c2lnbmFsLWNhbGwtaG9tZS0xMTogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiBhbGwg ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8NCj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0K PiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWdu YWwtY2FsbC1ob21lLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiBDT01NRU5U Og0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiANCj4gW1sgcXVlc3Rpb25zIF1dDQo+IA0KPiBbIHNl Y3Rpb24gNS4zLjEgXQ0KPiANCj4gKiBDYW4gdGhlIHNvdXJjZS1wcmVmaXggaW5jbHVkZSBJUHY0 L0lQdjYgbGluay1sb2NhbCBwcmVmaXhlcz8NCj4gDQo+ICAgQ2FuIHRoZSBzZXJ2ZXIgYW5kIGNs aWVudCBiZSBvbiB0aGUgc2FtZSBsaW5rIChhbmQgdGhlcmVmb3JlDQo+ICAgbGluay1sb2NhbCBh ZGRyZXNzZXMgbWlnaHQgaGF2ZSBzb21lIGRpc2Nlcm5hYmxlIG1lYW5pbmcpPw0KPiANCj4gDQoN CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Dec 17 02:05:57 2020 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 21C643A15B0 for ; Thu, 17 Dec 2020 02:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx0SdwXv_yZp for ; Thu, 17 Dec 2020 02:05:53 -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 24B183A15AD for ; Thu, 17 Dec 2020 02:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1608199551; 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=gk/hx66YEZSo9DZmbmF/WHkLyEQgCiIoDyYbd+y3Ymg=; b=eT9XYe/VmuKoIgyOGtg1KlvEfh/+MXI4EvBYVp+WKTycdUdricxegUuLQKdVAgKNiyFU39 R9TTRBDBnm58C/1VXqWtgx24wXmg3R4TjektF4MMvMEehIzQw5AoThDGckxOlMBOXSyPiN 0NwJ4EDBvfVP/koSjzD9SDctXsDUgmI= Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2052.outbound.protection.outlook.com [104.47.46.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-173-NRzOipzePyqKGJp43wkcJQ-1; Thu, 17 Dec 2020 05:05:50 -0500 X-MC-Unique: NRzOipzePyqKGJp43wkcJQ-1 Received: from DM6PR16MB3402.namprd16.prod.outlook.com (2603:10b6:5:148::13) by DM5PR16MB1466.namprd16.prod.outlook.com (2603:10b6:3:b9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Thu, 17 Dec 2020 10:05:48 +0000 Received: from DM6PR16MB3402.namprd16.prod.outlook.com ([fe80::dc33:7194:64da:2b21]) by DM6PR16MB3402.namprd16.prod.outlook.com ([fe80::dc33:7194:64da:2b21%6]) with mapi id 15.20.3654.026; Thu, 17 Dec 2020 10:05:48 +0000 From: "Konda, Tirumaleswar Reddy" To: Roman Danyliw , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" Thread-Topic: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHW0x1Lbu6HSCMZbU2f1UBmx3TqlKn7DIBA Date: Thu, 17 Dec 2020 10:05:48 +0000 Message-ID: References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> In-Reply-To: <160806244514.15552.2884622118358344184@ietfa.amsl.com> 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.165.3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bf977103-ea5b-4ba7-5794-08d8a27353cf x-ms-traffictypediagnostic: DM5PR16MB1466: 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: WRzrdNQTAmYPgN2w+nvTzFG3hGFkZvCNeiebNDAm3ZIuWPKpMYsuqA8FjzPDZc1ks4AcYLtIeq+RVMaGm8YZs7feeZ7w2FfLaGRrwva3ShwLoYWQ85U/4e1h7Kky/HrtuF4VLOuWfQmAkPE7shaii1zeaWpYCqkLQisQMHXqHhNuy+10Rx34sdTzRr4nwvghq6uS1rUe0+fdp5S194NmiSvQUAy0o653GctHHRivQG8uWYhVR5VUa00OR5d7DFAPO9pTtU2LVBUKatTL5RX42l5thmivOStbRNJn2Xgvgya1ZDP74Jp3nw+K0B/dgi4HBa99D4+RFVtbFVJjPnP9xrxxbubBKrIpVzkoY6r2kRJlbPsnNlkCUq+Na4tqMBf0ELE5cmHvEUMf4LDTNy79a6iqK1DRCTBqe4hFKwaa9eEyPP7ZCw5LO6oc0mvbo9qM8dCBLwkZUaKurPxLX5Hik3GR4l77GNMK9YQuHtrUUVU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3402.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(32952001)(55016002)(186003)(71200400001)(86362001)(66476007)(5660300002)(52536014)(7696005)(26005)(66556008)(33656002)(316002)(53546011)(64756008)(6506007)(76116006)(110136005)(9686003)(8936002)(966005)(2906002)(66446008)(54906003)(66946007)(4326008)(478600001)(83380400001)(8676002)(66574015)(85282002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?utf-8?B?NllxOFFlYmYwcFpXeW5zYndkY3JpV1IvRmZnVkdtY2FoQ2J1NUtKMGNzWGpI?= =?utf-8?B?VVZtRnNOUWYyMGtxNEEwbHdUeXpjWk1oSzRyT0hNZnBPWGt4L1hHKzdNR1NR?= =?utf-8?B?ZmNrRXVwVm9CZmRuY0RXQ1hUbFdMT0F3a0NTekZuLzB2cDdyalNDVTZSUUlO?= =?utf-8?B?SlpQdEM1ZUVLNkdOcTc4RzVudnJGMjZXSlFXc1NuVzlFdW1HRnMxRmpwMUJo?= =?utf-8?B?dU1GV212Q0dBdXJLdzZ6Z2p1NUhOVWpaNnIrMm9mZVpmU2ZSYjFlWndINW1W?= =?utf-8?B?ekk3M0h2N3RibW9jMjM1VWN5R04yZFk1Q014TWZrMkJNN1hha25OVjR3VzNV?= =?utf-8?B?OExRVFVpL1lVRUI2UzM1cjl3amo3Rm5yMWt5WSsxUTNqMyt5Q0Fqa1ordmRo?= =?utf-8?B?ZjFDWXlzRjBGNCtNZFdyWkFoWVpneWdjU0RKNFowMUNmUFVzMFF0NWdIdUxw?= =?utf-8?B?NFAzQWlBaUZadWZnT25SM1Y4bjdhSWFmbDY2a243aTFHQXRPbTI0L0hQTjJi?= =?utf-8?B?Z2VUNHRZK2VWSHcxRjNBTTNSeHppVFRZUDYrNThvbjVUR1dWcStESGJqY2tN?= =?utf-8?B?ZVJjSHBZS1pPalU0NGFHckN0K1VWcWh5cVRFbWc0bWwwSFNrUlNER3FqQXo2?= =?utf-8?B?czA5TXNkRkptaWhmSWxSRGlBWWRhalo2TDI1WCtTUngxYlJQem0rUnVNYXhU?= =?utf-8?B?Z2g1b3FJRWZadE16dVZ3NTIxTTJtTkVmbXpVTE5ySUZjd0ZFbEkzYm9teU4w?= =?utf-8?B?aitLL0t6MnFjVGRXTEMyUERua1N1K1p4dmc3SDhyUGhFbFZaQnBxZ2ZwR1ov?= =?utf-8?B?Z0xoVFc3V2ltZHpjdU81L1A1Umt0ODNFTEU5TlIvM3RNbG9ZU1pSUWlGZE8r?= =?utf-8?B?d3pBZnZwSlFYRE8zTWltQVA4SUZ2dWlkNXBFVjM0TVB1SFhya0JlSVVVZTE1?= =?utf-8?B?L040a0lBWVpkL05IV0JITzFzZHE0Y1lDTldMTnQ4ekdFaHhLRWp0RGVjUTZy?= =?utf-8?B?TUs1aGEybHFZRDlRaGFqemZmU3Z0NzBPdmw5OGdLRWkrcDhaUVRZUkhTcldy?= =?utf-8?B?Zk42aDdyL2E2NzBwSzVlRWt5bkI0NWs2b1AzdzNNc09pbUxJTUw5Mk4wTmFi?= =?utf-8?B?b2NSMS9ZU1VCZ0x0bGx6KytHZkR0SGdkTEEyN0pvTlppdlJXMzBtSWJKb285?= =?utf-8?B?ODd0RVRNaFd2SmN1cTNDZUZBanZjL2VUYjVWbC9VNnlIZFlZaVZCWVAzU08v?= =?utf-8?B?OGJGbzJSMnJCMEM0NklFdXczOHc2U3VHczVwWGZGeEdvOTcrWlc5ZXA4UTlJ?= =?utf-8?Q?jBa+WOy3vQOok=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: DM6PR16MB3402.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf977103-ea5b-4ba7-5794-08d8a27353cf X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 10:05:48.3171 (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: N/QfMCezcLtWpJVlgPYGuYK5X/HlbcROmV18JDZLRJlzh1b0oQYcKiM45PYrKE6QYKu7P+KNFGUWcM1ufBusuFKSabDKWnG0qf5yBOJoUYyP90SeLFQkiKj9BJjeXGyk X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1466 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=UTF-8 Content-Transfer-Encoding: base64 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, 17 Dec 2020 10:05:56 -0000 SGkgUm9tYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUgZm9y IHJlc3BvbnNlcyB0byBjb21tZW50cy4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb21hbiBE YW55bGl3IHZpYQ0KPiBEYXRhdHJhY2tlcg0KPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE2 LCAyMDIwIDE6MzEgQU0NCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJh ZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtY2hhaXJzQGlldGYu b3JnOw0KPiB2YWxlcnlAc215c2xvdi5uZXQ7IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0Rv dHNdIFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2Fs bC1ob21lLQ0KPiAxMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IENBVVRJT046 IEV4dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1 bmxlc3MgeW91DQo+IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlz IHNhZmUuDQo+IA0KPiBSb21hbiBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0xMTog RGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9y eQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLw0KPiANCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEl0IHNlZW1z IHRvIG1lIHRoZXJlIGlzIGEgbWlzc2luZyBvcGVyYXRpb25hbCBndWlkYW5jZSBvciB1bmRvY3Vt ZW50ZWQNCj4gZGVwbG95bWVudCBhc3N1bXB0aW9ucy4gIFNpbmNlIHRoZSBtb3RpdmF0aW9uYWwg dXNlIGNhc2Ugc2VlbXMgdG8gYmUNCj4gaG9tZSBuZXR3b3JrcyAocGVyIFNlY3Rpb24gMS4xKSwg SSBhc3N1bWVkIHRoYXQgdGhlIGNhbGwgaG9tZSBzZXJ2ZXJzIGFyZQ0KPiBydW5uaW5nIHByaW1h cmlseSBjb25zdW1lciBncmFkZSByb3V0ZXJzIG5vdCBtYW5hZ2VkIGJ5IHByb2Zlc3Npb25hbCBJ VA0KPiBleHBlcnRpc2UuICBJZiB0aGF0IGFzc3VtcHRpb24gaXMgdHJ1ZSAoYW5kIGl0IHNob3Vs ZCBiZSBkb2N1bWVudGVkIGlmIHRoYXQgaXMNCj4gdGhlIGNhc2UpLCB0aGVuIEkgZmluZCBtYW55 IG9mIHRoZSBvcGVyYXRpb25hbCByZWNvbW1lbmRhdGlvbnMgbm90DQo+IGNvbmdydWVudCB3aXRo IHRoYXQgZW52aXJvbm1lbnQuICBTcGVjaWZpY2FsbHksIHRoZSBkZWdyZWUgb2YgaW50ZXJhY3Rp b24gYW5kDQo+IHR1bmluZyBzZWVtcyBvdXRzaWRlIHRoZSByZWFsbSBvZiBleHBlcnRpc2Ugb2Yg c29tZW9uZSB3aXRob3V0IElUIHRyYWluaW5nDQo+IGFuZCBjYXBhYmlsaXRpZXMgb2YgaG9tZSBu ZXR3b3JrIGVjb3N5c3RlbS4gIEluIHBhcnRpY3VsYXI6DQo+IA0KPiAtLSBTZWN0aW9uIDEuMg0K PiBUaGUgQ2FsbCBIb21lIERPVFMgc2VydmVyIHVzZXMgdGhlIEREb1MgYXR0YWNrIHRyYWZmaWMg aW5mb3JtYXRpb24gdG8NCj4gICAgaWRlbnRpZnkgdGhlIGNvbXByb21pc2VkIGRldmljZSBpbiBp dHMgZG9tYWluIHRoYXQgaXMgcmVzcG9uc2libGUgZm9yDQo+ICAgIGxhdW5jaGluZyB0aGUgRERv UyBhdHRhY2ssIG9wdGlvbmFsbHkgbm90aWZpZXMgYSBuZXR3b3JrDQo+ICAgIGFkbWluaXN0cmF0 b3IsIGFuZCB0YWtlcyBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9uIGFjdGlvbihzKS4NCj4gDQo+IEhv dyB3b3VsZCBzdWNoIG5vdGlmaWNhdGlvbiB3b3JrPw0KPiANCj4gLS0gU2VjdGlvbiAxLjIgYW5k IDUuMS4gIExlYXZlcyBjcmVkZW50aWFscyBjb25maWd1cmF0aW9uIGFzIG91dCBvZiBzY29wZS4N Cj4gU2VjdGlvbiAxLjIgcmVmZXJlbmNlcyBbSS1ELmlldGYtZG90cy1zZXJ2ZXItZGlzY292ZXJ5 XSBmb3IgcHJvdmlzaW9uaW5nLiAgSW4NCj4gdHVybiwgU2VjdGlvbiAxIG9mIFtJLUQuaWV0Zi5z ZXJ2ZXItZGlzY292ZXJ5XSBhbHNvIGRlY2xhcmVzIHRoaXMgcHJvYmxlbSBvdXQgb2YNCj4gc2Nv cGUgYnkgc2F5aW5nIOKAnFRoaXMgZG9jdW1lbnQgYXNzdW1lcyB0aGF0IHNlY3VyaXR5IGNyZWRl bnRpYWxzIHRvDQo+IGF1dGhlbnRpY2F0ZSBET1RTIHNlcnZlcihzKSBhcmUgcHJlLXByb3Zpc2lv bmVkIHRvIGEgRE9UUyBjbGllbnQgdXNpbmcgYQ0KPiBtZWNoYW5pc20gc3VjaCBhcyAoYnV0IG5v dCBsaW1pdGVkIHRvKSB0aG9zZSBkaXNjdXNzZWQgaW4gW1JGQzg1NzJdIG9yIFtJLQ0KPiBELmll dGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYV3igJ0uICBIb3dldmVyLCBSRkM4NTcyIHNl ZW1zIHRvIHJlbHkgb24NCj4gTkVUQ09ORiBhbmQgUkVTVENPTkYgd2hpY2ggc2VlbXMgbGlrZSBh IHJhdGhlciB1bmNvbW1vbiBmZWF0dXJlIG9mDQo+IGhvbWUgcm91dGVycy4gIEJSS1NJIHJlbGll cyBvbiBhIG1hbnVmYWN0dXJlciBzdXBwbGllZC9jb250cmFjdGVkDQo+IGluZnJhc3RydWN0dXJl IGFuZCBrZXlzdG9yZXMgdGhhdCBhbHNvIHNlZW0gdW5jb21tb24gZm9yIGNvbnN1bWVyIGdyYWRl DQo+IGVxdWlwbWVudC4NCj4gDQo+IC0tIFNlY3Rpb24gNS4zLjEuDQo+IFRoZSBDYWxsIEhvbWUg RE9UUyBzZXJ2ZXIgZG9tYWluIGFkbWluaXN0cmF0b3IgY29uc2VudCBNQVkgYmUNCj4gICAgcmVx dWlyZWQgdG8gYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0aGUgY29tcHJvbWlzZWQgZGV2aWNlIHRv IHRoZQ0KPiAgICBhdHRhY2sgdGFyZ2V0LiAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGhhdmUgYSBj b25maWd1cmF0aW9uIGtub2IgdG8NCj4gICAgYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0aGUgY29t cHJvbWlzZWQgZGV2aWNlIHRvIHRoZSBhdHRhY2sgdGFyZ2V0DQo+ICAgIHdpdGggb3Igd2l0aG91 dCBET1RTIHNlcnZlciBkb21haW4gYWRtaW5pc3RyYXRvciBjb25zZW50Lg0KPiANCj4gVGhlIHN1 Z2dlc3Rpb24gaGVyZSBzZWVtcyB0byBiZSB0aGF0IGNvbnN1bWVycyBhcmUgYWNxdWlyaW5nIGRl dmljZXMgdGhhdA0KPiBjYW4gYmUgcmVtb3RlbHkgcmVjb25maWd1cmVkIHdpdGggb3V0IGEgZGVm aW5lZCB0cnVzdCBtb2RlbD8gIFNvbWUgcG9saWN5DQo+IG9yIG9wZXJhdGlvbmFsIGNvbnRleHQg c2VlbXMgYXBwcm9wcmlhdGUgaGVyZS4NCj4gDQo+IC0tIFNlY3Rpb24gNS4zLjENCj4gLi4uIG5v dGlmaWVzIHRoZSBDUEUNCj4gICAgYWRtaW5pc3RyYXRvciBhYm91dCB0aGUgY29tcHJvbWlzZWQg ZGV2aWNlDQo+IA0KPiBOb3RpZnkgaG93Pw0KPiANCj4gLS0gU2VjdGlvbiA4Lg0KPiBBcHByb3By aWF0ZQ0KPiAgICBmaWx0ZXJzIChlLmcuLCBhY2Nlc3MgY29udHJvbCBsaXN0cykgY2FuIGJlIGlu c3RhbGxlZCBvbiB0aGUgQ2FsbA0KPiAgICBIb21lIERPVFMgc2VydmVyIGFuZCBuZXR3b3JrIGJl dHdlZW4gdGhlIENhbGwgSG9tZSBET1RTIGFnZW50cyBzbw0KPiAgICB0aGF0IG9ubHkgY29tbXVu aWNhdGlvbnMgZnJvbSBhIHRydXN0ZWQgQ2FsbCBIb21lIERPVFMgY2xpZW50IHRvIHRoZQ0KPiAg ICBDYWxsIEhvbWUgRE9UUyBzZXJ2ZXIgYXJlIGFsbG93ZWQuDQo+IA0KPiBUaGlzIHNlZW1zIGxp a2UgYSBsZXZlbCBvZiBzb3BoaXN0aWNhdGlvbiBiZXlvbmQgeW91ciBhdmVyYWdlIGhvbWUgcm91 dGVyDQo+IHVzZXIgYW5kIGEgcGxhY2Ugd2hlcmUgaW1wbGVtZW50YXRpb25zIHNob3VsZCBjb25z aWRlciBhIHNlY3VyZSBkZWZhdWx0cy4NCj4gDQo+IC0tIFNlY3Rpb24gOC4NCj4gQ2FsbCBIb21l IERPVFMgc2VydmVycyBjYW4gYWxzbyBzZWVrIHRoZSBjb25zZW50IG9mIERPVFMNCj4gICAgc2Vy dmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIHRvIGJsb2NrIHRoZSB0cmFmZmljIGZyb20gdGhlIHBv dGVudGlhbGx5DQo+ICAgIGNvbXByb21pc2VkIGRldmljZSB0byB0aGUgdGFyZ2V0IChzZWUgU2Vj dGlvbiA1LjMuMSkuDQo+IA0KPiBXaGF0IHdvdWxkIGJlIHRoZSBtZWFucyB0byBnYWluIHN1Y2gg Y29uc2VudD8NCj4gDQo+IC0tIFNlY3Rpb24gOS4NCj4gTm90ZSB0aGF0IGEgQ2FsbCBIb21lIERP VFMgc2VydmVyIGNhbiBzZWVrIGFuIGFkbWluaXN0cmF0b3Incw0KPiAgICBjb25zZW50LCB2YWxp ZGF0ZSB0aGUgcmVxdWVzdCBieSBpbnNwZWN0aW5nIHRoZSByZWxldmFudCB0cmFmZmljIGZvcg0K PiAgICBhdHRhY2sgc2lnbmF0dXJlcywgb3IgcHJvY2VlZCB3aXRoIGJvdGggY291cnNlcyBvZiBh Y3Rpb24uDQo+IA0KPiBBcyBhYm92ZS4NCj4gDQo+IC0tIFNlY3Rpb24gOS4NCj4gDQo+ICAgICBU aGUgRE9UUyBDYWxsIEhvbWUgaXMgb25seSBhZHZpc29yeSBpbiBuYXR1cmUuICBDb25jcmV0ZWx5 LCB0aGUgRE9UUw0KPiAgICBDYWxsIEhvbWUgZG9lcyBub3QgaW1wb3NlIGFueSBhY3Rpb24gdG8g YmUgZW5mb3JjZWQgd2l0aGluIHRoZQ0KPiAgICBuZXR3b3JrIGhvc3RpbmcgYW4gYXR0YWNrIHNv dXJjZTsgaXQgaXMgdXAgdG8gdGhlIENhbGwgSG9tZSBET1RTDQo+ICAgIHNlcnZlciAoYW5kL29y IG5ldHdvcmsgYWRtaW5pc3RyYXRvcikgdG8gZGVjaWRlIHdoZXRoZXIgYW5kIHdoaWNoDQo+ICAg IGFjdGlvbnMgYXJlIHJlcXVpcmVkLg0KPiANCj4gU3VjaCBhIGRlY2lzaW9ucyBzZWVtcyBvdXQg YmV5b25kIHRoZSBhYmlsaXR5IG9mIHlvdXIgYXZlcmFnZSBob21lIHJvdXRlcg0KPiB1c2VyLg0K PiANCj4gLS0gU2VjdGlvbiA4ICDigJwuLi4gZXhwbGljaXQgcG9saWN5IChlLmcuLCB0aGUgQ2Fs bCBIb21lIERPVFMgY2xpZW50IGFuZCBzZXJ2ZXIgYXJlDQo+IG1hbmFnZWQgYnkgdGhlIHNhbWUg YWRtaW5pc3RyYXRpdmUgZW50aXR5KSwNCj4gDQo+IElzIHRoZXJlIGFuIHVuZGVybHlpbmcgYXNz dW1wdGlvbiB0aGF0IHRoZSBJU1AgaXMgbWFuYWdpbmcgdGhlIGRldmljZT8NCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rIHlv dSB0byBSYWRpYSBQZXJsbWFuIGZvciB0aGUgU0VDRElSIHJldmlldy4NCj4gDQo+ICoqIFNlY3Rp b24gMS4xLiAgVGhlIG1vdGl2YXRpb24gZm9yIHRoaXMgcHJvdG9jb2wgaW4gdGhlIOKAnGhvbWUg bmV0d29yayBkZXZpY2XigJ0NCj4gZWNvc3lzdGVtIGNvdWxkIHVzZSBhIGJpdCBtb3JlIGZvY3Vz Lg0KPiANCj4gKGEpIG5ldHdvcmsgZGV2aWNlcyBpbiBhIGhvbWUgbmV0d29yayBjYW4gb2ZmZXIg bmV0d29yaw0KPiAgICBzZWN1cml0eSBmdW5jdGlvbnMgKGUuZy4sIGZpcmV3YWxsIFtSRkM0OTQ5 XSBvciBJbnRydXNpb24gUHJvdGVjdGlvbg0KPiAgICBTeXN0ZW0gKElQUykgc2VydmljZSBbSS1E LmlldGYtaTJuc2YtdGVybWlub2xvZ3ldIG9uIGEgaG9tZSByb3V0ZXIpDQo+IA0KPiAoYikgSGVu Y2UsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBkZXRlY3QgdmFyaW91cyBERG9TIGF0dGFja3MgaW4N Cj4gICAgdGhlIHNsb3cgcGF0aCAuLi4NCj4gDQo+IChjKSBhIGZ1bGwtZmxlZGdlZCBEUEkgdG8N Cj4gICAgZGV0ZWN0IHRoZXNlIHR5cGUgb2YgRERvUyBhdHRhY2tzIGlzIGZ1bmN0aW9uYWxseSBv ciBvcGVyYXRpb25hbGx5DQo+ICAgIG5vdCBwb3NzaWJsZSBmb3IgYWxsIHRoZSBkZXZpY2VzDQo+ IA0KPiBJZiBJUFMgaXMgZG9uZSBwZXIgKGEpLCAoYikgYW5kIChjKSBkb27igJl0IHNlZW0gbGlr ZSBpc3N1ZXMuIENlcnRhaW5seSwgTk9UIGFsbA0KPiBkZXZpY2VzIHN1cHBvcnQgKGEpLCBidXQg bm90IEFMTCBkZXZpY2VzIG9yIGxpbWl0ZWQgYnkgKGIpIGFuZCAoYykuDQoNClR5cGljYWxseSBu ZXR3b3JrIHNlY3VyaXR5IHNlcnZpY2VzIGNvLWxvY2F0ZWQgb24gaG9tZSByb3V0ZXJzIGFyZSBs aW1pdGVkIGJ5IChiKSBhbmQgKGMpLiAgSG9tZSByb3V0ZXJzIGFyZSBjb25zdHJhaW5lZCBuZXR3 b3JrIGRldmljZXMgYW5kIG5ldHdvcmsgc2VjdXJpdHkgc2VydmljZSBjby1sb2NhdGVkIG9uIHRo ZSBob21lIHJvdXRlciBjYW5ub3QgcnVuIGEgZnVsbC1mbGVkZ2VkIERQSS4gSW4gYWRkaXRpb24s IG5ldHdvcmsgc2VjdXJpdHkgc2VydmljZXMgaW4gU09ITy9TTUIgbWF5IG9yIG1heSBub3QgYmUg YWJsZSB0byBkZXRlY3QgRERvUyBhdHRhY2tzIHVzaW5nIERQSS4gSVNQcyBvZmZlcmluZyBERG9T IG1pdGlnYXRpb24gc2VydmljZSBoYXZlIEREb1MgRGV0ZWN0aW9uIGNhcGFiaWxpdHkgdXNpbmcg YW5vbWFseSBkZXRlY3Rpb24gKGZvciBleGFtcGxlLCBzZWUgaHR0cHM6Ly93d3cubmV0c2NvdXQu Y29tL3NpdGVzL2RlZmF1bHQvZmlsZXMvMjAxOC0xMC9TRUNQRFNfMDA0X0VOLTE4MDItQXJib3It VGhyZWF0LU1pdGlnYXRpb24tU3lzdGVtLSUyOFRNUyUyOS5wZGYpIHRvIGlkZW50aWZ5IHplcm8g ZGF5IEREb1MgYXR0YWNrcyBhbmQgdG8gZGV0ZWN0IEREb1MgYXR0YWNrcyB0aGF0IGNhbm5vdCBi ZSBkZXRlY3RlZCB1c2luZyBzaWduYXR1cmVzIGFuZCByYXRlLWxpbWl0IHRlY2huaXF1ZXMuIA0K DQo+IA0KPiBUaGUgYWJzdHJhY3QgaXMgYWxzbyBjbGVhciB0aGF0IOKAnFRoZSBET1RTIHNpZ25h bCBjaGFubmVsIENhbGwgSG9tZSBpcyBub3QNCj4gc3BlY2lmaWMgdG8gaG9tZSBuZXR3b3Jrczsg dGhlIHNvbHV0aW9uIHRhcmdldHMgYW55IGRlcGxveW1lbnQgaW4gd2hpY2ggaXQgaXMNCj4gcmVx dWlyZWQgdG8gYmxvY2sgRERvUyBhdHRhY2sgdHJhZmZpYyBjbG9zZXIgdG8gdGhlIHNvdXJjZShz KSBvZiBhIEREb1MgYXR0YWNrIiwNCj4gYnV0IHRoYXQgZmFpcmx5IGxhcmdlIG90aGVyIHVzZSBj YXNlcyBkb2VzbuKAmXQgc2VlbSBhY2tub3dsZWRnZWQgaGVyZS4NCj4gDQo+IEJvdHRvbS1saW5l LCBJIGhhZCBkaWZmaWN1bHR5IGZvbGxvd2luZyB0aGUgbW90aXZhdGlvbi4NCj4gDQo+ICoqIFNl Y3Rpb24gMS4xIHByZXNlbnRzIGFuIGluY29tcGxldGUgdmlldyBvZiB0aGUgcHJvYmxlbSB0byBt b3RpdmF0ZSB0aGUNCj4gc29sdXRpb24uICBJdCBub3RlcyB0aGF0IElTUHMgY2FuIGFscmVhZHkg ZGV0ZWN0IGEgRERvUyBhdHRhY2sgZG93biB0byB0aGUNCj4gaW5kaXZpZHVhbCBob21lIG5ldHdv cmssIGJ1dCBub3QgdGhlIGRldmljZSAoYmVjYXVzZSBvZiBOQVRzKS4gIFRoZQ0KPiBwcm9ibGVt IG9mIHdoYXQgaGFwcGVucyBuZXh0IHJlbWFpbnMgdW5zYWlkLiAgSXQgc2VlbXMgdG8gbWUgdGhh dCBvcHRpb25zDQo+IGFyZSB0aGUgSVNQIHNoYXBlcyB0aGUgdHJhZmZpYyBvZiB0aGF0IGhvbWUg bmV0d29yayAoYWZmZWN0aW5nIGFsbCBvZiBpdHMNCj4gZGV2aWNlcykgd2hpY2ggaXMgbGlrZWx5 IHVuZGVzaXJhYmxlL2JsdW50IG9yIHRoZSBJU1AgdHJpZXMgdG8gZ2FpbiBjb29wZXJhdGlvbg0K PiBvZiB0aGUgaG9tZSBuZXR3b3JrIGVkZ2Ugcm91dGVyIHRvIGRvIHNvbWV0aGluZyAod2hpY2gg aXMgdGhlIHBvaW50IG9mIHRoaXMNCj4gZG9jdW1lbnQpLg0KDQpUaGUgcHJvYmxlbSBpcyBub3Qg c3BlY2lmaWMgdG8gZGV2aWNlcyBiZWhpbmQgTkFULCBJU1AgY2Fubm90IGlkZW50aWZ5IGRldmlj ZXMgdXNpbmcgSVB2NiBhZGRyZXNzZXMgYXR0YWNoZWQgdG8gdGhlIGhvbWUgbmV0d29yayB0byBp c29sYXRlIGFuZCByZW1lZGlhdGUgY29tcHJvbWlzZWQgZGV2aWNlcyBsYXVuY2hpbmcgRERvUyBh dHRhY2suIFdlIGhhdmUgdGhlIGZvbGxvd2luZyB0ZXh0IGluIFNlY3Rpb24gMS4xLg0KDQogICBF dmVuIGluIGNhc2Ugb2YgYW4gSVB2NiBob21lIG5ldHdvcmssIGFsdGhvdWdoIHRoZSBJU1AgY2Fu IGlkZW50aWZ5IHRoZSBpbmZlY3RlZCBkZXZpY2UgaW4gdGhlDQogICBob21lIG5ldHdvcmsgbGF1 bmNoaW5nIHRoZSBERG9TIHRyYWZmaWMgYnkgdHJhY2tpbmcgaXRzIHVuaXF1ZSBJUHY2DQogICBh ZGRyZXNzLCB0aGUgaW5mZWN0ZWQgZGV2aWNlIGNhbiBlYXNpbHkgY2hhbmdlIGl0cyBJUHY2IGFk ZHJlc3MgdG8NCiAgIGV2YWRlIHJlbWVkaWF0aW9uLiAgQSBzZWN1cml0eSBmdW5jdGlvbiBvbiB0 aGUgbG9jYWwgaG9tZSBuZXR3b3JrIGlzDQogICBiZXR0ZXIgcG9zaXRpb25lZCB0byB0cmFjayB0 aGUgY29tcHJvbWlzZWQgZGV2aWNlIGFjcm9zcyBJUHY2IGFkZHJlc3MNCiAgIChhbmQgcG90ZW50 aWFsbHkgZXZlbiBNQUMgYWRkcmVzcykgY2hhbmdlcyBhbmQgdGh1cyBlbnN1cmUgdGhhdA0KICAg cmVtZWRpYXRpb24gcmVtYWlucyBpbiBwbGFjZSBhY3Jvc3Mgc3VjaCBldmVudHMuDQoNCj4gDQo+ ICoqIFNlY3Rpb24gMS4xLg0KPiANCj4gICAgRXhpc3RpbmcgYXBwcm9hY2hlcyBhcmUgc3RpbGwg c3VmZmVyaW5nIGZyb20gbWlzdXNlZCBhY2Nlc3MgbmV0d29yaw0KPiAgICByZXNvdXJjZXMgYnkg YWJ1c2l2ZSBkZXZpY2VzOyB0aGUgc3VwcG9ydCBvZiBtZWFucyBmb3IgYmxvY2tpbmcgc3VjaA0K PiAgICBhdHRhY2tzIGNsb3NlIHRvIHRoZSBzb3VyY2VzIGFyZSBtaXNzaW5nLg0KPiANCj4gSSBk aWRu4oCZdCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBtZWFucy4gIFdoYXQg4oCcZXhpc3RpbmcgYXBw cm9hY2hlc+KAnT8NCg0KVGhhbmtzLCB3aWxsIG1vZGlmeSB0aGUgYWJvdmUgdGV4dCBmb3IgY2xh cml0eToNCg0KICAgRXhpc3RpbmcgYXBwcm9hY2hlcyBkaXNjdXNzZWQgYWJvdmUgc3VmZmVyIGZy b20gbWlzdXNlZCBhY2Nlc3MgbmV0d29yaw0KICAgcmVzb3VyY2VzIGJ5IGFidXNpdmUgZGV2aWNl czsgdGhlIHN1cHBvcnQgb2YgbWVhbnMgZm9yIGJsb2NraW5nIHN1Y2gNCiAgIGF0dGFja3MgY2xv c2UgdG8gdGhlIHNvdXJjZXMgYXJlIG1pc3NpbmcuDQoNCj4gDQo+ICoqIFNlY3Rpb24gMS4yLiAg Rm9yIHRoZSBob21lIG5ldHdvcmsgY2FzZSwgdGhlIHRleHQgc2VlbXMgdG8gYmUgbWlzc2luZw0K PiB0ZXh0IHNheWluZyB0aGF0IHRoaXMg4oCcQ2FsbCBIb21lIERPVFPigJ0gc29sdXRpb24gbmVl ZHMgdG8gYmUgZGVwbG95ZWQgb24gYQ0KPiBDUEUgY2FwYWJsZSBvZiBzb21lIGRlZ3JlZSBvZiBt aXRpZ2F0aW9uIHBlciB0aGUga2luZHMgb2YgZmVhdHVyZXMgRE9UUyBjYW4NCj4gZXhwcmVzcyAo YW5kIHRoZSBkZXRhaWxzIG9mIHRoaXMgaW50ZWdyYXRpb24gaXMgb3V0IG9mIHNjb3BlKS4NCg0K V2UgYWxyZWFkeSBoYXZlIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWN0aW9uIDEuMjoNCkluIGEg dHlwaWNhbCBkZXBsb3ltZW50IHNjZW5hcmlvLCB0aGUgQ2FsbCBIb21lIERPVFMgc2VydmVyIGlz IGVuYWJsZWQgb24gYSBDdXN0b21lciBQcmVtaXNlcyBFcXVpcG1lbnQgKENQRSksIHdoaWNoIGlz IGFsaWduZWQgd2l0aCByZWNlbnQgdHJlbmRzIHRvIGVucmljaCB0aGUgQ1BFIHdpdGggYWR2YW5j ZWQgc2VjdXJpdHkgZmVhdHVyZXMuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBt YWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RvdHMNCg0K From nobody Thu Dec 17 05:09:12 2020 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 509D03A07F7; Thu, 17 Dec 2020 05:09:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160821054930.19434.7342983127042335991@ietfa.amsl.com> Date: Thu, 17 Dec 2020 05:09:09 -0800 Archived-At: Subject: [Dots] Robert Wilton's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 13:09:11 -0000 Robert Wilton has entered the following ballot position for draft-ietf-dots-signal-call-home-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. I support both Roman's DISCUSS and Barry's comment, in the sense that the document could probably benefit from some more guidance about how it is expected to be deployed. Perhaps the Applicability Scope should constrain where it is expected for this protocol to be deployed (e.g. only in an ISP managed device). It might also be beneficial to understand when DOTS Signal Call Home should be deployed instead of the Base DOTS Signal Channel. One other comment: I found the introduction text to section 1.1 to be informative, but it seemed to be a bit of a jump to section 1.2 when it immediately starts describing call-home as the solution. I.e. section 1.1 makes it clear as to why running DDOS mitigation in the source network is beneficial, but doesn't necessarily lead (at least to me) to the reason why that means adding a reverse control channel to DOTS is the solution. Regards, Rob From nobody Thu Dec 17 06:29:31 2020 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 67CEA3A08C3; Thu, 17 Dec 2020 06:29:25 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <160821536495.8335.5498062431481972966@ietfa.amsl.com> Date: Thu, 17 Dec 2020 06:29:25 -0800 Archived-At: Subject: [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 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, 17 Dec 2020 14:29:26 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-dots-signal-call-home-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 7.1: Port request for DOTS signal for home. I think the WG has failed to take the assignment principles in RFC 6335 to heart: >From Section 7: "The basic principle of service name and port number registry management is to conserve use of the port space where possible." o IANA strives to assign only one assigned port number per service or application. Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. o IANA strives to assign only one assigned port number for all variants of a service (e.g., for updated versions of a service). o IANA strives to encourage the deployment of secure protocols. o IANA strives to assign only one assigned port number for all different types of devices using or participating in the same service. o IANA strives to assign port numbers only for the transport protocol(s) explicitly named in an assignment request. o IANA may recover unused port numbers, via the new procedures of de-assignment, revocation, and transfer. After having reviewed Appendix A I think the WG has made the wrong choice and also not considered all the available choices for enabling DOTS signal and call home to be colocated on the same port. Several options exists: - URI name space so that it is the same protocol just making requests with different URIs depending on mode - Use the already existing settings negotiation to determine the mode of operation. - Using ALPN on (D)TLS connection establishment >From my perspective the DOTS WG have multiple choices that are quite simple to solve there colocation issue that would not incur significnat cost or overhead. Using an additional port do incur a cost of consuming a resource that is endless and not easily recoverable. I do share the IANA port experts team's verdict that this port assignment should be denied and alternative solution found as the motivation appears very weak. From nobody Thu Dec 17 07:22:42 2020 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 423563A097C; Thu, 17 Dec 2020 07:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 OMS5C0N6JGZz; Thu, 17 Dec 2020 07:22:34 -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 5FF9A3A0992; Thu, 17 Dec 2020 07:22:34 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4CxbMr5H9BzyZh; Thu, 17 Dec 2020 16:22:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608218552; bh=wWSZuUuK12ijZaC7i0pgk2xVa1oplN0VPLJTyhaEwmg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IgxgaTcP78sOkOcWuYSSxWuBXAOpUqBbcZROUfJ5Yfm9pMsOG8DQrtQgMkP0aak8y nhzchCvq3961NLRsOjHtnOS9bmy8jYt3cWlYhCVsjO+6neQ3OJJhKuE57yz8wU11aV O/rP5SSg/4m1+3LJ0CoQ0pCeEdGeuAdpP0XYOjQgNaGBvSUxdqFX48jQsx2GCVA+LU EK+b5VK2YjAhwh4LmpC0x+/+2QumjfcBmwYuhgrO9TbH/VdrbvoipoGEahf+6elNRR ppMEUyQiBgOo+eERWRQHmSGl9+1KbDT+nXPBwt2v7rVaVjjlIOM3YPoP0895PMufDU pqx9qJWI1h61w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4CxbMr4RH6z8sYH; Thu, 17 Dec 2020 16:22:32 +0100 (CET) From: To: Magnus Westerlund , The IESG CC: "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS) Thread-Index: AQHW1IEG8/aDaVHfFEKHhsf7enK9U6n7Z1VQ Date: Thu, 17 Dec 2020 15:22:32 +0000 Message-ID: <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160821536495.8335.5498062431481972966@ietfa.amsl.com> In-Reply-To: <160821536495.8335.5498062431481972966@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Thu, 17 Dec 2020 15:22:36 -0000 SGkgTWFnbnVzLCANCg0KSSB3b25kZXIgd2hldGhlciB5b3UgaGFkIGEgY2hhbmNlIHRvIHJlYWQg dGhpcyBtZXNzYWdlIHdoZXJlIGV4cGxhaW4gd2h5IHRoaXMgaXMgYSBuZXcgc2VydmljZSwgbm90 IGEgdmFyaWFudCBvZiBhbiBleGlzdGluZyBzZXJ2aWNlOiBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL2RvdHMvR1FQLVFDbUMtNFh0SkhQbXNQUl9xdXV5TzBjLyANCg0KVGhh bmsgeW91LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IE1hZ251cyBXZXN0ZXJsdW5kIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVw bHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogamV1ZGkgMTcgZMOpY2VtYnJlIDIwMjAgMTU6MjkN Cj4gw4DCoDogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjwqA6IGRyYWZ0LWlldGYtZG90 cy1zaWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3RzLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IGRv dHNAaWV0Zi5vcmc7IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+Ow0KPiB2YWxl cnlAc215c2xvdi5uZXQNCj4gT2JqZXTCoDogTWFnbnVzIFdlc3Rlcmx1bmQncyBEaXNjdXNzIG9u IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC0NCj4gaG9tZS0xMTogKHdpdGggRElTQ1VTUykN Cj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0xMTogRGlz Y3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l IGludGFjdCBhbmQgcmVwbHkgdG8NCj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+IGN1dCB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczov L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+ IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3Np dGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS8NCj4gDQo+IA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gDQo+ IFNlY3Rpb24gNy4xOiBQb3J0IHJlcXVlc3QgZm9yIERPVFMgc2lnbmFsIGZvciBob21lLg0KPiAN Cj4gSSB0aGluayB0aGUgV0cgaGFzIGZhaWxlZCB0byB0YWtlIHRoZSBhc3NpZ25tZW50IHByaW5j aXBsZXMgaW4gUkZDDQo+IDYzMzUgdG8NCj4gaGVhcnQ6DQo+IA0KPiA+RnJvbSBTZWN0aW9uIDc6 DQo+IA0KPiAgICAiVGhlIGJhc2ljIHByaW5jaXBsZSBvZiBzZXJ2aWNlIG5hbWUgYW5kIHBvcnQg bnVtYmVyIHJlZ2lzdHJ5DQo+ICAgIG1hbmFnZW1lbnQgaXMgdG8gY29uc2VydmUgdXNlIG9mIHRo ZSBwb3J0IHNwYWNlIHdoZXJlIHBvc3NpYmxlLiINCj4gDQo+ICAgIG8gIElBTkEgc3RyaXZlcyB0 byBhc3NpZ24gb25seSBvbmUgYXNzaWduZWQgcG9ydCBudW1iZXIgcGVyDQo+IHNlcnZpY2UNCj4g ICAgICAgb3IgYXBwbGljYXRpb24uDQo+IA0KPiAgICAgICBOb3RlOiBBdCB0aGUgdGltZSBvZiB3 cml0aW5nIG9mIHRoaXMgZG9jdW1lbnQsIHRoZXJlIGlzIG5vDQo+IElFVEYNCj4gICAgICAgY29u c2Vuc3VzIG9uIHdoZW4gaXQgaXMgYXBwcm9wcmlhdGUgdG8gdXNlIGEgc2Vjb25kIHBvcnQgZm9y DQo+IGFuDQo+ICAgICAgIGluc2VjdXJlIHZlcnNpb24gb2YgYSBwcm90b2NvbC4NCj4gDQo+ICAg IG8gIElBTkEgc3RyaXZlcyB0byBhc3NpZ24gb25seSBvbmUgYXNzaWduZWQgcG9ydCBudW1iZXIg Zm9yIGFsbA0KPiAgICAgICB2YXJpYW50cyBvZiBhIHNlcnZpY2UgKGUuZy4sIGZvciB1cGRhdGVk IHZlcnNpb25zIG9mIGENCj4gc2VydmljZSkuDQo+IA0KPiAgICBvICBJQU5BIHN0cml2ZXMgdG8g ZW5jb3VyYWdlIHRoZSBkZXBsb3ltZW50IG9mIHNlY3VyZSBwcm90b2NvbHMuDQo+IA0KPiAgICBv ICBJQU5BIHN0cml2ZXMgdG8gYXNzaWduIG9ubHkgb25lIGFzc2lnbmVkIHBvcnQgbnVtYmVyIGZv ciBhbGwNCj4gICAgICAgZGlmZmVyZW50IHR5cGVzIG9mIGRldmljZXMgdXNpbmcgb3IgcGFydGlj aXBhdGluZyBpbiB0aGUgc2FtZQ0KPiAgICAgICBzZXJ2aWNlLg0KPiANCj4gICAgbyAgSUFOQSBz dHJpdmVzIHRvIGFzc2lnbiBwb3J0IG51bWJlcnMgb25seSBmb3IgdGhlIHRyYW5zcG9ydA0KPiAg ICAgICBwcm90b2NvbChzKSBleHBsaWNpdGx5IG5hbWVkIGluIGFuIGFzc2lnbm1lbnQgcmVxdWVz dC4NCj4gDQo+ICAgIG8gIElBTkEgbWF5IHJlY292ZXIgdW51c2VkIHBvcnQgbnVtYmVycywgdmlh IHRoZSBuZXcgcHJvY2VkdXJlcw0KPiBvZg0KPiAgICAgICBkZS1hc3NpZ25tZW50LCByZXZvY2F0 aW9uLCBhbmQgdHJhbnNmZXIuDQo+IA0KPiBBZnRlciBoYXZpbmcgcmV2aWV3ZWQgQXBwZW5kaXgg QSBJIHRoaW5rIHRoZSBXRyBoYXMgbWFkZSB0aGUgd3JvbmcNCj4gY2hvaWNlIGFuZCBhbHNvIG5v dCBjb25zaWRlcmVkIGFsbCB0aGUgYXZhaWxhYmxlIGNob2ljZXMgZm9yDQo+IGVuYWJsaW5nIERP VFMgc2lnbmFsIGFuZCBjYWxsIGhvbWUgdG8gYmUgY29sb2NhdGVkIG9uIHRoZSBzYW1lIHBvcnQu DQo+IFNldmVyYWwgb3B0aW9ucyBleGlzdHM6DQo+IA0KPiAgICAgICAgIC0gVVJJIG5hbWUgc3Bh Y2Ugc28gdGhhdCBpdCBpcyB0aGUgc2FtZSBwcm90b2NvbCBqdXN0IG1ha2luZw0KPiByZXF1ZXN0 cw0KPiAgICAgICAgIHdpdGggZGlmZmVyZW50IFVSSXMgZGVwZW5kaW5nIG9uIG1vZGUgLSBVc2Ug dGhlIGFscmVhZHkNCj4gZXhpc3RpbmcNCj4gICAgICAgICBzZXR0aW5ncyBuZWdvdGlhdGlvbiB0 byBkZXRlcm1pbmUgdGhlIG1vZGUgb2Ygb3BlcmF0aW9uLiAtDQo+IFVzaW5nIEFMUE4NCj4gICAg ICAgICBvbiAoRClUTFMgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50DQo+IA0KPiA+RnJvbSBteSBw ZXJzcGVjdGl2ZSB0aGUgRE9UUyBXRyBoYXZlIG11bHRpcGxlIGNob2ljZXMgdGhhdCBhcmUNCj4g cXVpdGUNCj4gPnNpbXBsZSB0bw0KPiBzb2x2ZSB0aGVyZSBjb2xvY2F0aW9uIGlzc3VlIHRoYXQg d291bGQgbm90IGluY3VyIHNpZ25pZmljbmF0IGNvc3QNCj4gb3Igb3ZlcmhlYWQuDQo+IFVzaW5n IGFuIGFkZGl0aW9uYWwgcG9ydCBkbyBpbmN1ciBhIGNvc3Qgb2YgY29uc3VtaW5nIGEgcmVzb3Vy Y2UNCj4gdGhhdCBpcyBlbmRsZXNzIGFuZCBub3QgZWFzaWx5IHJlY292ZXJhYmxlLiBJIGRvIHNo YXJlIHRoZSBJQU5BIHBvcnQNCj4gZXhwZXJ0cyB0ZWFtJ3MgdmVyZGljdCB0aGF0IHRoaXMgcG9y dCBhc3NpZ25tZW50IHNob3VsZCBiZSBkZW5pZWQNCj4gYW5kIGFsdGVybmF0aXZlIHNvbHV0aW9u IGZvdW5kIGFzIHRoZSBtb3RpdmF0aW9uIGFwcGVhcnMgdmVyeSB3ZWFrLg0KPiANCj4gDQo+IA0K PiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu Dec 17 07:54:45 2020 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 903D23A09F4; Thu, 17 Dec 2020 07:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 w2qN6I0BQrMx; Thu, 17 Dec 2020 07:54:37 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2047.outbound.protection.outlook.com [40.107.22.47]) (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 E0F653A09EF; Thu, 17 Dec 2020 07:54:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TeybQWNnhU7cut0jOiIQO9N7dIRfwdM0cjlYAGf+yGwWlhmf/5gxg1B57YZ1hSN9fH/+q7wfH1+d2Qs4Vr2WZdbkvk/owJF4OnOcyqsPPrIA3dT8g978X57lg6sXOqtvD/ZeS/v6ZEu84tI8sumXrkDIQYkUZjk4YF5cVtTfs9bhnJzTZIooJ0LxnEqjppCaAOxHx/5PfZoCwHnKrMh+GHom7TEPW+vdStnmdiRzvGtJtv7h9+B77n3yYfowVrGIJrJnivcDTzO4yxU2RI2uZBoB3zoYSHdio/ty1Gn4AsMIZ06R9+EmRaKkPyrfVDlKVlkXw8NC601wUc67UBiPGw== 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=na2tqeAK9psYelVVrS66UwOVfVUI3sMFSaLJdxAau9c=; b=Nb0q6fkdWv7r17A1AP2vTiALm3gYIFbMlqHMQXanu6RdG3XqirRqKBseA1LrML2SvMJiYWnxAAqZQhKZEzXIK+aGZzBT5ANXyttJOqhBx5ePiScf7PhdzV+z9kprEEFmCrP/lcQq/1fFnIli5/RTUs3S+o27hf6suFUAQ7MV9EwIPVeMG4BW8cZKIzVjK64iCFIkQVj1k+fm0Dh4FUmOgAkdFRXspSpdsHa27JNdPNeyj+gnkaJxSz56zooCqz1aG8cW0vXA8Azum0CYcKEpD7ZuQrgvvCUC/DocVLXyAaOi8i2FumoHtQ11wAvzEUNVr4DCpOSeCBXqG5KN6/mMYw== 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=na2tqeAK9psYelVVrS66UwOVfVUI3sMFSaLJdxAau9c=; b=soGXur+rai62HGGwBNpIXojFjFXJCyo9mP+jyEtleB+HUddqszC81YLyK/HYOYOjFw5myZjs5sEP4TVFrfY56EbiI1wztKd7fZovM5aC+f8EEs43RICn9OObi+RO/T8nYtkoZvqrj2wN8IiRI0tUOEbQShXFVKmbDTvs/W++8FE= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3627.eurprd07.prod.outlook.com (2603:10a6:7:84::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.10; Thu, 17 Dec 2020 15:54:32 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%7]) with mapi id 15.20.3676.011; Thu, 17 Dec 2020 15:54:32 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "mohamed.boucadair@orange.com" CC: "dots@ietf.org" , "valery@smyslov.net" , "dots-chairs@ietf.org" , "draft-ietf-dots-signal-call-home@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS) Thread-Index: AQHW1IEMs9vsdNy1dUKXFtQUcezc5qn7Z94AgAAI8IA= Date: Thu, 17 Dec 2020 15:54:32 +0000 Message-ID: <83fe6f11ec1cfcfd1f4c4493854c8ce6eaa542f4.camel@ericsson.com> References: <160821536495.8335.5498062431481972966@ietfa.amsl.com> <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@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: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08291d80-a547-499a-b57d-08d8a2a40bbb x-ms-traffictypediagnostic: HE1PR0702MB3627: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DH4/QnLEpKdLY2b0udNkjprC/yRiOgD+IMSqomTthdNHtd5SefJtBDoGwY/mM+zJTNO0f3ciJcaUt711pA5QG5uufFKX3J6oh6Pqj5e6JI8v4iIiJo5yAfR7CCa39if2jV9LlClhEJnzlS1Af+NX+1sZxIbd/NsHGUb2JV0vgA7uiw9/G4dhRoSVqjPTFpHX8YLWbptFl0f7UIwb6k/uUBVbBIUYbe6WZv3javrKzbvWCB4H+3s6Fl7JtAsqJ2/5PEr4H1ZDK8Ufj0nw7+uAdTc44Hzn2zmQjE9YzzRzKKKTz0D+9AFtLKWpDHhgZ4NmkQy7nQ8pdg/B7rax5S/VXQOnCv8B/oVp56hqFJB/2sKf9O7w51Nq8fXG9CJDLtC+FqphcocKvhQp3MXiYyJhX9lFtyax+P+/VZZ9IY02hUH91nGaN7tahN+nz8DrpRxCShVHwON7Hkq2e23Y52t2Ru0XoEh9Zas/OHdxEGpzmqeUQGVqaM8VLdl+YbnnhqlZE8OjIiDhZ2FSha6IvDZ/Ng== 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)(376002)(366004)(136003)(396003)(39860400002)(346002)(2906002)(8676002)(83380400001)(5660300002)(4326008)(26005)(6486002)(99936003)(966005)(66574015)(316002)(2616005)(66616009)(54906003)(66476007)(66556008)(71200400001)(66446008)(76116006)(110136005)(66946007)(64756008)(4001150100001)(36756003)(6506007)(86362001)(186003)(44832011)(478600001)(8936002)(6512007)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?MFh2ZU1udkVPTmtlRWk3d0Jzdy9Jczl3ay8rZktlUWc1Q0FzMDNGbExLTlF1?= =?utf-8?B?RzlzVDV2cnpYWnhKOWFhNFhkejhqSGlsaVkyNjBaWUsrd2Q5YXRWUHlIRVBB?= =?utf-8?B?SFRBeGhodjVVS0p6ZWg2SnZGS3d1MFByZ1B5T21xQnNLUlBIaWdmeW9KL21X?= =?utf-8?B?Rkl6bDVlMVg4UWk4K3lraXNHLzhGOTNJUm1RVkRZV01JakdXMnQwNlp2SWhX?= =?utf-8?B?RjM1ZlR3Yjd4SjFwVjI3TlJ0OHhubkpkbUorZm5GbkU0cDJhaVBmT0czTndw?= =?utf-8?B?MGhxUm5Ib1dKa0J3VnpuMk5ZSFNUR2JwNkdnbERaTkFFdWJDWEJrb0MzNFlF?= =?utf-8?B?M0RlWlhFTDg4SDRaKzVzQjFMekxSbjc3VVoyejNYUUpQcDBBQ1VwNVhxNU1J?= =?utf-8?B?N2JLMlBYSWdBN3ltYkJ1UC9hSEhYRWwwV2ljNmEwcHkzWDR4UnJwKzVwdGdY?= =?utf-8?B?TFBsRFp3aGUwd2xjZW1WSGNsZTZYNUZFNkxrZXM2WWlvVzdwNFdDY1FkTkQz?= =?utf-8?B?ZW1ESXJPK20yWS9aKzNUZ1dqbDl0a0MxQzk5NjB2YUMwaktuT01BZUkvTjVJ?= =?utf-8?B?Z0c0TTB5eFFHdDB0V1FCSHZQVzVYOGVhZWtnSmFhMWw0ZU1jSmtJY0pjSHJp?= =?utf-8?B?TWRvbWtFUmhWZlJwL2VsYVJUNk5kWUh5ZndHbDZoTmxyRUp1S0lNeVBaT2JQ?= =?utf-8?B?Slh4OHZlckVuQ25lUGNOTWJ1VjJYeTRCelZoVnM2RXBpK1JnSUZOYmxPNWxh?= =?utf-8?B?dWhyYlFCSmZkSGk1bVpNK2FhQVgyMVhKU1BhaElIRUtvcjU3OG5VeFJ0bnpV?= =?utf-8?B?bi9iSUNYM2lBRGR5cVc5RVh0YVJzOVZDU2JlUFNyQWtuOHhOQXg5WkZmSjdt?= =?utf-8?B?NFdZVnc4K2ViR2dTK2RKWGxBS3Q2czF6dDJxZ05NUmkrRk5XblFaZmhEWFpW?= =?utf-8?B?eUN4em5GODFKakdEUjkzVmJOQ2k1Zk5JRUEzSWZyNGtWdkJOeWFTeGs0T28x?= =?utf-8?B?aUlTQ1JDb1ZNYVpVSG9QY0I1RHhjSmlmUGtSSGRSZWFBdGY1c0RjVVRhMjlx?= =?utf-8?B?c0tsdEt5blc0MGFtK1dVcUIzU3Jib2ZNNkEyRDBzd3gzNEZxdVF5MVhtVktx?= =?utf-8?B?N0JhdGwwbzY2a3o2QnJZcWdUL29EL0lKYXdHYlBiTjlNekoxRUp6UVB4dDNt?= =?utf-8?B?UlFSZW9hRTNTMDEwU0lsTTVvOHk1Z0V2SUZGeExwYmhvaXNPdjhrN1BqbjZn?= =?utf-8?B?Nk5pRXdsc1hIZ3lqL3J1V1JYcmlDSnNFbTg2YUZpK3pWM24xZGhGUFdDRDZn?= =?utf-8?Q?K40uOUtz8vgSE8Gsif0j9RFAWAnyBQiJ12?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-lNQ14JdQfVtHHEsx2ppe" 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: 08291d80-a547-499a-b57d-08d8a2a40bbb X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 15:54:32.6583 (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: UnCAnL/nxCLn3mW8eCebUu7EMsdrk0mMffPh0vzTKbAH2baX13BOS2W6HsTPpnpc0r7nGQzy4wu9OQh1vL53F4JjeRlV0WeEKKXS3nuHc3c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3627 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: Thu, 17 Dec 2020 15:54:40 -0000 --=-lNQ14JdQfVtHHEsx2ppe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I hadn't read this before. But I have now read it and it don't really chang= e my perspective. I think there are several options here that should work for yo= u.=20 Based on what you write in your email to my understanding ALPN in (D)TLS wo= uld work fairly well to dispatch the secured connection to the individual implementation of DOTS-signal and Dots-call home if that is needed. And fut= ure implementation that are combined can simply use that ALPN signal as a basic indication on behavior in common code paths.=20 Cheers Magnus Westerlund On Thu, 2020-12-17 at 15:22 +0000, mohamed.boucadair@orange.com wrote: > Hi Magnus,=20 >=20 > I wonder whether you had a chance to read this message where explain why = this > is a new service, not a variant of an existing service:=20 > https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/= =20 >=20 > Thank you.=20 >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Magnus Westerlund via Datatracker [mailto:noreply@ietf.org] > > Envoy=C3=A9 : jeudi 17 d=C3=A9cembre 2020 15:29 > > =C3=80 : The IESG > > Cc : draft-ietf-dots-signal-call-home@ietf.org; dots- > > chairs@ietf.org; dots@ietf.org; Valery Smyslov ; > > valery@smyslov.net > > Objet : Magnus Westerlund's Discuss on draft-ietf-dots-signal-call- > > home-11: (with DISCUSS) > >=20 > > Magnus Westerlund has entered the following ballot position for > > draft-ietf-dots-signal-call-home-11: Discuss > >=20 > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > >=20 > >=20 > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ > >=20 > >=20 > >=20 > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > >=20 > > Section 7.1: Port request for DOTS signal for home. > >=20 > > I think the WG has failed to take the assignment principles in RFC > > 6335 to > > heart: > >=20 > > > From Section 7: > >=20 > > "The basic principle of service name and port number registry > > management is to conserve use of the port space where possible." > >=20 > > o IANA strives to assign only one assigned port number per > > service > > or application. > >=20 > > Note: At the time of writing of this document, there is no > > IETF > > consensus on when it is appropriate to use a second port for > > an > > insecure version of a protocol. > >=20 > > o IANA strives to assign only one assigned port number for all > > variants of a service (e.g., for updated versions of a > > service). > >=20 > > o IANA strives to encourage the deployment of secure protocols. > >=20 > > o IANA strives to assign only one assigned port number for all > > different types of devices using or participating in the same > > service. > >=20 > > o IANA strives to assign port numbers only for the transport > > protocol(s) explicitly named in an assignment request. > >=20 > > o IANA may recover unused port numbers, via the new procedures > > of > > de-assignment, revocation, and transfer. > >=20 > > After having reviewed Appendix A I think the WG has made the wrong > > choice and also not considered all the available choices for > > enabling DOTS signal and call home to be colocated on the same port. > > Several options exists: > >=20 > > - URI name space so that it is the same protocol just making > > requests > > with different URIs depending on mode - Use the already > > existing > > settings negotiation to determine the mode of operation. - > > Using ALPN > > on (D)TLS connection establishment > >=20 > > > From my perspective the DOTS WG have multiple choices that are > >=20 > > quite > > > simple to > >=20 > > solve there colocation issue that would not incur significnat cost > > or overhead. > > Using an additional port do incur a cost of consuming a resource > > that is endless and not easily recoverable. I do share the IANA port > > experts team's verdict that this port assignment should be denied > > and alternative solution found as the motivation appears very weak. > >=20 > >=20 > >=20 > >=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 --=-lNQ14JdQfVtHHEsx2ppe 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 BAIBBQCgggFBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMTIx NzE1NTQzMVowLwYJKoZIhvcNAQkEMSIEILvK1QrE8WjizePBSUgp2YW0D+8XzqJMJ2ylBbtRoaWZ MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwawYLKoZI hvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEB AQUABIIBAA++JNjq0ToJuNNCmNPvy7PFMrWkaMGZv/POBvQAoqDQJdmFRkbHjxICfAsLPFgz2mhN 4IOMkKtdJ2Y03jjUIE5BaM1LLL7PDtuuHbdLejijtmeN1Ve/8C2pdaLSa4PD1FV8ZPMkqWkUrihP 1E5ng9BRGUAZYC+pezpDtQR3t4N8p14P40Pj0HI369nZH8HgVidr+OsihXr8T6CiRXRFt4RIHGjI xO2nenwrHEV16JUMWAs9kMB4U39suG8hbxKiTCDYxS1h181bFzYarvqFn8DX41KNXY23EqJ1cXFa jsN2VtgX/qqNRdLpRoEx5zqGd+TJ7e9BuR8xtGhD1qALVkEAAAAAAAA= --=-lNQ14JdQfVtHHEsx2ppe-- From nobody Thu Dec 17 08:57:05 2020 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 7E36D3A0DBC for ; Thu, 17 Dec 2020 08:57:03 -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 lD4Rixw9Leli for ; Thu, 17 Dec 2020 08:57:01 -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 7155A3A0D9B for ; Thu, 17 Dec 2020 08:57:01 -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 1kpwaI-0003Gv-QP; Thu, 17 Dec 2020 16:56:58 +0000 From: To: "'Magnus Westerlund'" , , Cc: , , , References: <160821536495.8335.5498062431481972966@ietfa.amsl.com> <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <83fe6f11ec1cfcfd1f4c4493854c8ce6eaa542f4.camel@ericsson.com> In-Reply-To: <83fe6f11ec1cfcfd1f4c4493854c8ce6eaa542f4.camel@ericsson.com> Date: Thu, 17 Dec 2020 16:56:47 -0000 Message-ID: <135d01d6d495$9b1b94e0$d152bea0$@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: AQJ2bnsKEk4cVClsqjQj7jfeJ0e02wFsH/eMAmTmvDqonb1HQA== Content-Language: en-gb 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: Thu, 17 Dec 2020 16:57:04 -0000 Hi Magnus, We had considered using ALPN. While DOTS signal channel can use TLS, given that this DOTS protocol has = to be robust in an Distribute Denial of Service attack environment, its = primary use will be DTLS using UDP. > Based on what you write in your email to my understanding ALPN in = (D)TLS > would work fairly well to dispatch the secured connection to the = individual > implementation of DOTS-signal and Dots-call home if that is needed. When using TCP, it is relatively easy to dispatch a secured connection = and attach it to, say a forked copy of the appropriate application or a = new thread in the application which then does all the network i/o over = that secured connection. However, for UDP from an implementation perspective, I cannot see how = this can be done so the network stack can itself steer each input packet = to the appropriate application when the traffic arrives on the same IP = and port (only one application can receive traffic on a specific udp = port). I welcome any wisdom on how to do this. There is also a minor concern in about exposing the protocol as = https://tools.ietf.org/html/rfc7301#section-5 which states Implementers and document editors who intend to extend the protocol identifier registry by adding new protocol identifiers should consider that in TLS versions 1.2 and below the client sends these identifiers in the clear. They should also consider that, for at least the next decade, it is expected that browsers would normally use these earlier versions of TLS in the initial ClientHello. Care must be taken when such identifiers may leak personally identifiable information, or when such leakage may lead to profiling or to leaking of sensitive information. If any of these apply to this new protocol identifier, the identifier SHOULD NOT be used in TLS configurations where it would be visible in the clear, and documents specifying such protocol identifiers SHOULD recommend against such unsafe use. Even though it is possible to derive things from the fact that a = particular port being used. Regards Jon > -----Original Message----- > From: Magnus Westerlund [mailto:ietf-supjps- > magnus.westerlund@ericsson.com] > Sent: 17 December 2020 15:55 > To: iesg@ietf.org; mohamed.boucadair@orange.com > Cc: dots@ietf.org; valery@smyslov.net; dots-chairs@ietf.org; = draft-ietf-dots- > signal-call-home@ietf.org > Subject: Re: Magnus Westerlund's Discuss on = draft-ietf-dots-signal-call-home- > 11: (with DISCUSS) >=20 > Hi, >=20 > I hadn't read this before. But I have now read it and it don't really = change my > perspective. I think there are several options here that should work = for you. >=20 > Based on what you write in your email to my understanding ALPN in = (D)TLS > would > work fairly well to dispatch the secured connection to the individual > implementation of DOTS-signal and Dots-call home if that is needed. = And future > implementation that are combined can simply use that ALPN signal as a = basic > indication on behavior in common code paths. >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 >=20 >=20 >=20 > On Thu, 2020-12-17 at 15:22 +0000, mohamed.boucadair@orange.com wrote: > > Hi Magnus, > > > > I wonder whether you had a chance to read this message where explain = why > this > > is a new service, not a variant of an existing service: > > https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC- > 4XtJHPmsPR_quuyO0c/ > > > > Thank you. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Magnus Westerlund via Datatracker [mailto:noreply@ietf.org] > > > Envoy=C3=A9 : jeudi 17 d=C3=A9cembre 2020 15:29 > > > =C3=80 : The IESG > > > Cc : draft-ietf-dots-signal-call-home@ietf.org; dots- > > > chairs@ietf.org; dots@ietf.org; Valery Smyslov = ; > > > valery@smyslov.net > > > Objet : Magnus Westerlund's Discuss on = draft-ietf-dots-signal-call- > > > home-11: (with DISCUSS) > > > > > > Magnus Westerlund has entered the following ballot position for > > > draft-ietf-dots-signal-call-home-11: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > > criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ > > > > > > > > > > > > = -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > = -------------------------------------------------------------------- > > > -- > > > > > > Section 7.1: Port request for DOTS signal for home. > > > > > > I think the WG has failed to take the assignment principles in RFC > > > 6335 to > > > heart: > > > > > > > From Section 7: > > > > > > "The basic principle of service name and port number registry > > > management is to conserve use of the port space where = possible." > > > > > > o IANA strives to assign only one assigned port number per > > > service > > > or application. > > > > > > Note: At the time of writing of this document, there is no > > > IETF > > > consensus on when it is appropriate to use a second port for > > > an > > > insecure version of a protocol. > > > > > > o IANA strives to assign only one assigned port number for all > > > variants of a service (e.g., for updated versions of a > > > service). > > > > > > o IANA strives to encourage the deployment of secure = protocols. > > > > > > o IANA strives to assign only one assigned port number for all > > > different types of devices using or participating in the = same > > > service. > > > > > > o IANA strives to assign port numbers only for the transport > > > protocol(s) explicitly named in an assignment request. > > > > > > o IANA may recover unused port numbers, via the new procedures > > > of > > > de-assignment, revocation, and transfer. > > > > > > After having reviewed Appendix A I think the WG has made the wrong > > > choice and also not considered all the available choices for > > > enabling DOTS signal and call home to be colocated on the same = port. > > > Several options exists: > > > > > > - URI name space so that it is the same protocol just = making > > > requests > > > with different URIs depending on mode - Use the already > > > existing > > > settings negotiation to determine the mode of operation. - > > > Using ALPN > > > on (D)TLS connection establishment > > > > > > > From my perspective the DOTS WG have multiple choices that are > > > > > > quite > > > > simple to > > > > > > solve there colocation issue that would not incur significnat cost > > > or overhead. > > > Using an additional port do incur a cost of consuming a resource > > > that is endless and not easily recoverable. I do share the IANA = port > > > experts team's verdict that this port assignment should be denied > > > and alternative solution found as the motivation appears very = weak. > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > _____________ > > ___________________________________________ > > > > 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. > > From nobody Thu Dec 17 09:34:30 2020 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 571383A0E2F; Thu, 17 Dec 2020 09:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 36omI_V11L3B; Thu, 17 Dec 2020 09:34:26 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) (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 37E0C3A0E33; Thu, 17 Dec 2020 09:34:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PpscFo4yZ2UbGOA7jmhYHMDeoRymi7RiecECRPHRDNuPRXz4h/FLKep0UshmJIqaGZEje00sjIMgZDN4joM7vOK1V63xepJTkb2WTs5wUheflxqv/zwistRVh638reRhTfFXJ9zE1YtoN+/ZZlQ8ZZQM8sTLFMaiydbOJewmgswHIvtov7+TkFwUry0PMiYeYbjUFOVvGnud2LD/GVKiDz1NoQ3ohatDb8kXBFtGnCLnlyFARYaSF9mKFYmO100q+M3a2EuKvVFNCYGfb5eTW6vxI62Vg+C9j6UTfEVP8A8eZVm7PpNEbpwyNpHCCUVsxuUknAA5ak/dw/XvA5oyXg== 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=KjpvcITmYGSI5AEYMQmo9s7Z+LxZMGYNmgCRLvIoCcc=; b=Y+os5cpIN5j8KIGuGkhfrNhb7kW61hPAK+h+4qhLQK0MRS9BSrImwE0kH0R5Movvyb2keeGNuIZut0yK1z8+bQ9ljbxNfMESLg+f/4aL8gcVrCS3SgepDkHy9gk6EpIIzVy22g4hLrlkThYTnUGNYpkRDmTExZON5jmLaUZLRxewI6vBhcBi2A/WoUoqtVzxhiSwA8+vlY7lAtUBrjdvWG5BBtJGIy5/g+hfWmICDReYdV3n0aK6prDMYr1tZQ2gXW3j0ed9lRhmk062V12M0TiJ/z1pMCKV2PYFbRlaCl7Itz9i5BH6AkH1Vli8ksy/b855ESId47a2BOvxJSlFAw== 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=KjpvcITmYGSI5AEYMQmo9s7Z+LxZMGYNmgCRLvIoCcc=; b=MH2hxJoXyVuCJQsGA6yIbGM/v8IqPQ4UOtZ7cH/TVZi+tEM1Nv1i7C44Smn2Vkss3iKS511IHPnryNSoJHRw0laAvCevMm5SLFQr2BrVofGpUr9y9uIB1/OZ1XDHardu1fjTevQUcR58pVWAoO16cB7v+z6NpfdzuHZA+l/jzSs= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4172.eurprd07.prod.outlook.com (2603:10a6:7:99::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.12; Thu, 17 Dec 2020 17:34:17 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%7]) with mapi id 15.20.3676.011; Thu, 17 Dec 2020 17:34:16 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "supjps-ietf@jpshallow.com" , "mohamed.boucadair@orange.com" CC: "dots@ietf.org" , "valery@smyslov.net" , "dots-chairs@ietf.org" , "draft-ietf-dots-signal-call-home@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS) Thread-Index: AQHW1IEMs9vsdNy1dUKXFtQUcezc5qn7Z94AgAAI8ICAABFlgIAACniA Date: Thu, 17 Dec 2020 17:34:16 +0000 Message-ID: <75351574777c1f8100f15474ff5c755f6334645a.camel@ericsson.com> 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> In-Reply-To: <135d01d6d495$9b1b94e0$d152bea0$@jpshallow.com> 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: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eaed0d85-5eb7-4637-f7c5-08d8a2b1fa95 x-ms-traffictypediagnostic: HE1PR07MB4172: 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: nbMYGXtiTy5ef7KF6rqqUErCDCzgnqRWE4w6vLSutmETeexYGpLIvO3py2qV4+3xMP5HRlXIsMYJgTg4qUF9TSgT8AgZ416cu2w8FLVB/5bDI+KNBzhl6kFTG+AgmVQoVdtehrlXMboB1M1W4WVjtmCaSc8tSUaESAUqdgorvsBzRuD2lpxD/z5WTgJSjCsDwr7u97JNTCRvPPQwF+SGmQCOr8tSYegozGjJ52V/MzRI36WqTgjcghkXt+MAdyLQCyHu/EUVeXYZJ7aUv15VOTdzgoTQp25cJ1JaG8pHZ/IYSjTQICTJ/JE3avcGB4FOjNDIX0ZrKdGjHnxxSiwX9ikkdpLpRREi9NG7z4RplhFluEWqFi9K92iA1Win0Hnf31Aj6HOt7bSHyMjpykAzVDmCN+MT1ELbaXY0RNA6k5lKlXUtAHSWwhsyN6uJR+PIoSpeF3tFVhZgcqgms7GerX9lrxHfLY/F5jVS68rj7zKBKIqHFJ0Ra/P2U6S1SXyPwppkZYNAcANfEP7iOmOQ/A== 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)(136003)(346002)(366004)(39860400002)(376002)(396003)(54906003)(5660300002)(71200400001)(44832011)(8936002)(64756008)(66616009)(2616005)(76116006)(66946007)(478600001)(110136005)(6506007)(66446008)(6512007)(966005)(316002)(4326008)(186003)(26005)(86362001)(83380400001)(2906002)(6486002)(66556008)(8676002)(36756003)(66476007)(4001150100001)(99936003)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cityLzZnVFB1VHJ0Y0pWMlhiUUUzWkNwem14NHNQdU5ma2N3VkxaZldsTmlP?= =?utf-8?B?d0JOTVUweE90Vkx0UCtjeHJwdVJJTWYzOStBTnJOeXIwMVFSbVA2YjJ0ZzQv?= =?utf-8?B?d0NjNDdDWGN2aktBNXQxRG05MXhraFpRK1A1K01raVFvK25nelF2WmJEeS85?= =?utf-8?B?bC9JOE53L0xEanVJeU8wUUJHVVNyRjJid2J4eUFXclBFNjREK2dVRklYeUtw?= =?utf-8?B?NEt2SkdxVGxKeWs2V2k4cmV0M29iV1VYeVpOcHpyV1dUSWNTb3l2dWxZSDQ4?= =?utf-8?B?Z1ZVSEx2MmlGNnRzc0xpdUYwdFdlZTc1bU9YNlNmV0JuMkJnSjhrcXMvdkhw?= =?utf-8?B?eXhTVDRpaTJ5LzdMNzFKTUZUUzg3TzdBNnVUcXEvTEQxV0dzZzA0YldvcGFB?= =?utf-8?B?SEZaNTF3U2RiTm50dElBVDVXKzJ1TnErbk5pbmhIYmNhYmhUbFRIZ0dGTDJX?= =?utf-8?B?OENHMlg0SzU1UHdlOXNVOHd3a1hDZ0ZiQVNFMjJKNTg5eTNnNTZXY01yRjFD?= =?utf-8?B?djVyMDM3WHBYM3l1WnJlT3N2cW54WUNueUQyeXMrZjk4WXpnOXV3ZkxQSTVM?= =?utf-8?B?SXhlVVVIUUVURC9iUk1XMWh0UEZhdFVuNy9UOWhOQlk1RlVXTUlYM29kblVG?= =?utf-8?B?dXpYd0k3NC9qaE9BNFBFSWl6akRrYVE4REROazUxeHdzUVFtQ24vMFRualRs?= =?utf-8?B?WnBBVnZ4SEx4Vnc3WGtrTmZhcTB1bFJaRWtFaUc0eGFHcjV3N2lsQWNPaGpH?= =?utf-8?B?c3JDK0RJWjVoM1lTYmErUlE5RjIxUkJzYTJMVC9iYlBMcURlLzNCV0NHNXlx?= =?utf-8?B?clJRUlllVUg5c0s1V2grY1lDZG42b0dwckQ2MHhnRUNhVVQramhKRnFmVlc5?= =?utf-8?B?MGZQOFlRSGc4RFJ4dkhRVjF2Y0FkU0RKQ0JMRzVZcnJKdEN1V3NQS1VHd3hL?= =?utf-8?B?aFZVQ0lyTGZuNFBJdEdkVXJqaVlrZHdNa1JDYXVMdnRMSnNBNkdDSEJTZEtn?= =?utf-8?B?U01CakoraG96SkgrbGJXeVZNZ1ZFd1JBcUcxRk5IOHFXSnE1bThVeS9mRk5x?= =?utf-8?B?V0xHaUkvb3Bmayt1S3FTY1cvcnFsV0RDOGtoY216eU1DWjUrUVlKU0w2bXc2?= =?utf-8?B?RnByUGVFbmFmdzVOM09VdjcvN1FHeldjNEMxSWxobmw0RVMrMDdQbG90ODhR?= =?utf-8?B?RitzMHg2K1BhZ0N0Vitrbkl5VTVNeE8rbFNLcFFUcHVtN0x1OVdTbjNJTHQw?= =?utf-8?B?c1E0RGRFL2I1akFZbncyZ0ZUaEc3R3RZMHlKbWRuUFV4UUd2algzL2Npb3Nw?= =?utf-8?Q?V9ehtgWla0Sjgwn8JwNrfMGcax6Bcy0lg0?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-JVlufnpK0xlMWJl24U4G" 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: eaed0d85-5eb7-4637-f7c5-08d8a2b1fa95 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 17:34:16.8769 (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: VveTugpQ6hPhsR680sphDCDFZIYq7ERlCim37fuP9OTOYmktsS8W+s0+Cb1L0x/2dW47aolHCFt6bcDCHvQ25gwbhXsRSLmD5l6ZD/1Bum4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4172 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: Thu, 17 Dec 2020 17:34:28 -0000 --=-JVlufnpK0xlMWJl24U4G Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Thu, 2020-12-17 at 16:56 +0000, supjps-ietf@jpshallow.com wrote: > Hi Magnus, >=20 > We had considered using ALPN. >=20 > While DOTS signal channel can use TLS, given that this DOTS protocol has = to be > robust in an Distribute Denial of Service attack environment, its primary= use > will be DTLS using UDP. To my understanding ALPN is part of the TLS mechansism that applies to both= TLS and DTLS so I don't really understand the above sentence applicability. >=20 > > Based on what you write in your email to my understanding ALPN in (D)TL= S > > would work fairly well to dispatch the secured connection to the indivi= dual > > implementation of DOTS-signal and Dots-call home if that is needed. >=20 > When using TCP, it is relatively easy to dispatch a secured connection an= d > attach it to, say a forked copy of the appropriate application or a new t= hread > in the application which then does all the network i/o over that secured > connection. >=20 > However, for UDP from an implementation perspective, I cannot see how thi= s can > be done so the network stack can itself steer each input packet to the > appropriate application when the traffic arrives on the same IP and port = (only > one application can receive traffic on a specific udp port). I welcome a= ny > wisdom on how to do this. So I think there are several possible implementation paths for this. I see = at least two. First, do a 5-tuple connect on UDP to filter that particular UDP flow, proc= ess the DTLS handshake for this socket and then based on ALPN decide on target process and then hand over the socket and the DTLS state to the right proce= ss.=20 Secondly, is to run some type of front end dispatcher that processes the pa= ckets and tracks all the different DTLS connection and have secure message passin= g between the front end dispatcher and the different servers. But this do req= uie another security model and trust relationship between the dispatcher and th= e servers.=20 >=20 > There is also a minor concern in about exposing the protocol as=20 > https://tools.ietf.org/html/rfc7301#section-5 which states >=20 > Implementers and document editors who intend to extend the protocol > identifier registry by adding new protocol identifiers should > consider that in TLS versions 1.2 and below the client sends these > identifiers in the clear. They should also consider that, for at > least the next decade, it is expected that browsers would normally > use these earlier versions of TLS in the initial ClientHello. >=20 > Care must be taken when such identifiers may leak personally > identifiable information, or when such leakage may lead to profiling > or to leaking of sensitive information. If any of these apply to > this new protocol identifier, the identifier SHOULD NOT be used in > TLS configurations where it would be visible in the clear, and > documents specifying such protocol identifiers SHOULD recommend > against such unsafe use. >=20 > Even though it is possible to derive things from the fact that a particul= ar > port being used. I think the current security properties are basically the same between two = well know ports and one port with unencrypted ALPN. And when you move to DTLS 1.= 3 the alpn extension will be encrypted and you have slightly better security as t= he third party observer can't know if it is DOTS signal or DOTS call home that being used based on the handshake. Cheers Magnus --=-JVlufnpK0xlMWJl24U4G 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 BAIBBQCgggFBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMTIx NzE3MzQxNVowLwYJKoZIhvcNAQkEMSIEIArhzDV56XEsSnlVSOpxOUMnF3lgZPdZErfZw5xWmXyy MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwawYLKoZI hvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEB AQUABIIBADTZyhp+tKyGJ5z3uq6fyMiUaQSh6Sg8dogrP2LjGS1mKrsIQLz5cgfuRVTwBHE+L8/9 Wvk50u/5pEHRnIZcV717xJSrPJ48JNGQpxZSUMbxFFOluJ0CV07bHyewUtKSuIjcgY/ospcbq2QQ grpcHzv/SoV2wrbHF8uCE+nebpv7JMlR2RoEg51GQLGSrQjjVnvGJ112T1t8y9iaCKAMvov5CmHY vM+ytfj6GCFv1q6wJtJeg1OSwv4xaeagWC7/Dh8yhWJiRaocD6VJfj+VoDjchtuKKBT2yd6QbF54 pjR3n+5bMIbhew5M0C6tZwq1L684j+1u/gO/Lv0HsFbHDf8AAAAAAAA= --=-JVlufnpK0xlMWJl24U4G-- From nobody Thu Dec 17 09:46:08 2020 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 B0B263A0E48; Thu, 17 Dec 2020 09:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNhMVre5QlUF; Thu, 17 Dec 2020 09:46:00 -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 45E773A0E49; Thu, 17 Dec 2020 09:45:59 -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 0BHHjp40016971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Dec 2020 12:45:56 -0500 Date: Thu, 17 Dec 2020 09:45:51 -0800 From: Benjamin Kaduk To: Magnus Westerlund Cc: "iesg@ietf.org" , "supjps-ietf@jpshallow.com" , "mohamed.boucadair@orange.com" , "draft-ietf-dots-signal-call-home@ietf.org" , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" Message-ID: <20201217174551.GV64351@kduck.mit.edu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75351574777c1f8100f15474ff5c755f6334645a.camel@ericsson.com> 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: Thu, 17 Dec 2020 17:46:07 -0000 On Thu, Dec 17, 2020 at 05:34:16PM +0000, Magnus Westerlund wrote: > > I think the current security properties are basically the same between two well > know ports and one port with unencrypted ALPN. And when you move to DTLS 1.3 the > alpn extension will be encrypted and you have slightly better security as the > third party observer can't know if it is DOTS signal or DOTS call home that > being used based on the handshake. The ALPN in the CH is still unencrypted, so if you only offer one option, the server's pick being in EE doesn't really gain you anything. -Ben From nobody Thu Dec 17 13:32:43 2020 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 535A93A103F for ; Thu, 17 Dec 2020 13:32:41 -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 bUuU-s6xmeqv for ; Thu, 17 Dec 2020 13:32:39 -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 55D3A3A1038 for ; Thu, 17 Dec 2020 13:32:38 -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 1kq0t2-0003OJ-Ku; Thu, 17 Dec 2020 21:32:36 +0000 From: To: "'Magnus Westerlund'" , , Cc: , , , 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> In-Reply-To: <75351574777c1f8100f15474ff5c755f6334645a.camel@ericsson.com> Date: Thu, 17 Dec 2020 21:32:24 -0000 Message-ID: <13d001d6d4bc$1c543870$54fca950$@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: AQJ2bnsKEk4cVClsqjQj7jfeJ0e02wFsH/eMAmTmvDoCv3IYJgJfyZeWqHTw/oA= Content-Language: en-gb 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: Thu, 17 Dec 2020 21:32:41 -0000 Hi Marcus, Thanks for coming back on this and the suggestions. Please see inline. Regards Jon > -----Original Message----- > From: Magnus Westerlund = [mailto:magnus.westerlund=3D40ericsson.com@dmarc.ietf.org] > Sent: 17 December 2020 17:34 > To: iesg@ietf.org; supjps-ietf@jpshallow.com; > mohamed.boucadair@orange.com > Cc: draft-ietf-dots-signal-call-home@ietf.org; dots-chairs@ietf.org; > valery@smyslov.net; dots@ietf.org > Subject: Re: [Dots] Magnus Westerlund's Discuss on = draft-ietf-dots-signal-call- > home-11: (with DISCUSS) >=20 > Hi, >=20 > On Thu, 2020-12-17 at 16:56 +0000, supjps-ietf@jpshallow.com wrote: > > Hi Magnus, > > > > We had considered using ALPN. > > > > While DOTS signal channel can use TLS, given that this DOTS protocol > > has to be robust in an Distribute Denial of Service attack > > environment, its primary use will be DTLS using UDP. >=20 > To my understanding ALPN is part of the TLS mechansism that applies to = both > TLS and DTLS so I don't really understand the above sentence = applicability. [Jon] Apologies - I was trying to get the focus that UDP is our main = headache here >=20 > > > > > Based on what you write in your email to my understanding ALPN in > > > (D)TLS would work fairly well to dispatch the secured connection = to > > > the individual implementation of DOTS-signal and Dots-call home if = that is > needed. > > > > When using TCP, it is relatively easy to dispatch a secured = connection > > and attach it to, say a forked copy of the appropriate application = or > > a new thread in the application which then does all the network i/o > > over that secured connection. > > > > However, for UDP from an implementation perspective, I cannot see = how > > this can be done so the network stack can itself steer each input > > packet to the appropriate application when the traffic arrives on = the > > same IP and port (only one application can receive traffic on a > > specific udp port). I welcome any wisdom on how to do this. >=20 > So I think there are several possible implementation paths for this. I = see at least > two. >=20 > First, do a 5-tuple connect on UDP to filter that particular UDP flow, = process the > DTLS handshake for this socket and then based on ALPN decide on target > process and then hand over the socket and the DTLS state to the right = process. [Jon] UDP has no concept of accept(). If you do a connect() on a socket = that you have just received data on, then that updates the 5 tuple and = then only receives traffic matching the tuple as expected. However, it = appears not possible to leave the original socket ready for the next = packet (from different IP etc.) and set up a new socket to specifically = handle the stream matching the packet just received, bind(same_port), do = the connect() on it etc. (the bind(same_port)fails in my test). >=20 > Secondly, is to run some type of front end dispatcher that processes = the packets > and tracks all the different DTLS connection and have secure message = passing > between the front end dispatcher and the different servers. But this = do requie > another security model and trust relationship between the dispatcher = and the > servers. [Jon] This does complicate things. The DOTS signal channel requires = mutual authentication of the agents and introducing some sort of = man-in-middle that changes the network flow IP addresses etc. and = potentially changes encryption characteristics breaks this mutual = authentication. It is not easy to change how the base DOTS signal = works. >=20 > > > > There is also a minor concern in about exposing the protocol as > > https://tools.ietf.org/html/rfc7301#section-5 which states > > > > Implementers and document editors who intend to extend the = protocol > > identifier registry by adding new protocol identifiers should > > consider that in TLS versions 1.2 and below the client sends = these > > identifiers in the clear. They should also consider that, for at > > least the next decade, it is expected that browsers would = normally > > use these earlier versions of TLS in the initial ClientHello. > > > > Care must be taken when such identifiers may leak personally > > identifiable information, or when such leakage may lead to = profiling > > or to leaking of sensitive information. If any of these apply to > > this new protocol identifier, the identifier SHOULD NOT be used = in > > TLS configurations where it would be visible in the clear, and > > documents specifying such protocol identifiers SHOULD recommend > > against such unsafe use. > > > > Even though it is possible to derive things from the fact that a > > particular port being used. >=20 > I think the current security properties are basically the same between = two well > know ports and one port with unencrypted ALPN. And when you move to = DTLS > 1.3 the alpn extension will be encrypted and you have slightly better = security as > the third party observer can't know if it is DOTS signal or DOTS call = home that > being used based on the handshake. [Jon] Agreed.=20 >=20 > Cheers >=20 > Magnus From nobody Fri Dec 18 01:53:22 2020 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 060CC3A11EF; Fri, 18 Dec 2020 01:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 97dq-QYYLcav; Fri, 18 Dec 2020 01:53:15 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140041.outbound.protection.outlook.com [40.107.14.41]) (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 5D46F3A11EC; Fri, 18 Dec 2020 01:53:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=goe1HSFN6u+qoKnvdtBs9ZoPu7f+7qbLvgs09/EPwNpRNNkxtTEBzv5IeyroeSWCziBvGxwIezxOSuy4gMWCYhhsSN74+jNKPiFVrwWtiFFRlr6oj+KVyCuSrE5kWD1dRy16DJrJcwoACJ94qTSFCBrTvRLzXcKrJDMhRe+A6gfNQvB+RYLHtXnveJo7U+ymHY8XEvFRjtRqrzdbwHUjEl0qGs10l6ST/OdklUjtMLKMyODFbzY49dwjMMb1gJdurB9Sxc8bkDVJbU9OtDiiMxde5zUrlsyYuuwFFIeq+fq4oYtFYGbDcdYYzCOkx+Q3UOl2PLsmmXkxv2vOOSOgVw== 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=VA+EDY8VXmpKheKbEkKcDcvToLX0mRKAdvzihez210U=; b=Ae7IiOf1ptQE9TqU/kTKTLseWEkaS4Usnu6ZuZKOv3tRnl1XsvGaeaVOnR3Je1pcBuN4oXYzwngCwT+6ByDMfv/+o6AOj7XyvMyZs2FPkFTCgPtSXUVUtTpa1yz5WT7nvXivASe8a4qA/8jSDtjIFVwQ/65W9WgrMrzbqgkC9WQQRGA17q0iY7AeAIHd1IXDV77bJw5NYRr/pDGnnA83ic89LFmPe+u8bvV/LqdG7XnEuAiTiKBkK8IYMelGi/zAHMOO42yS/zHB5bvOkcfP/AhqFkxsmSkLbfBaHox6ZQccRpClB66nV0XJkAeUrTqH+G+31VW1uHw+kQ54qiuTjg== 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=VA+EDY8VXmpKheKbEkKcDcvToLX0mRKAdvzihez210U=; b=cdkpLKCMNg2XtNg4vZnfa9Ka5tkrYsIM8eZospJpO8owvwZQHcptYVpqVDartZ6vSGS8otRmGGlxjsk1n3sSBUSbTI23EPnYqKxI4Axq2OPTd1cjZBgyw/0CeN2HoDUaUQrbeNyN5qbLEbL4sFpzpE5XhqmEB7Q+rLUAHl+NduU= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4443.eurprd07.prod.outlook.com (2603:10a6:7:a1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.12; Fri, 18 Dec 2020 09:53:11 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%7]) with mapi id 15.20.3676.011; Fri, 18 Dec 2020 09:53:11 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "supjps-ietf@jpshallow.com" , "mohamed.boucadair@orange.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: AQHW1IEMs9vsdNy1dUKXFtQUcezc5qn7Z94AgAAI8ICAABFlgIAACniAgABCigCAAM7vgA== Date: Fri, 18 Dec 2020 09:53:11 +0000 Message-ID: <9a304e2ec6886de19ec54d2d56309442db652a02.camel@ericsson.com> 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> In-Reply-To: <13d001d6d4bc$1c543870$54fca950$@jpshallow.com> 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: 3f3bae96-3974-4fc9-5816-08d8a33abaed x-ms-traffictypediagnostic: HE1PR07MB4443: 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: xfDkAc/Pp0RCHyd2Katy/spAOnC6Sv52m3nD8vJoLee7D8imEOnriw0TOwq7q2Ea4JRZZPlbXEpDW0ayv1CjFgaGTzb+8KJpkyUsgRaXFa0+YPto5UhozDoEtyHrrZMvNsGlaSJNUT8kXYg422Jvmes452D0NM7/89E7b3rGSDez1yhiPQwylSu3O436vVl4XABwqyRd5Lz6rvcO0w3iZsZo1IxL8Q1MPtXE2XQOLKCWvReGQ+yzfLBHquuioecIpkU3fGFJCpU2PeWcTzDSR31MTlBijELvVOXs07k9jBjtifBllHRZyJ3iQX0gXUuCULzVwfuR5C1nVBIr4n+bYDqERUnsnp6pdfx+edM8Taxc4rXKQdXxL5tAV91AquSKwMoSFPa85+TwcgniKkbZWBV/5UwhoIIEG66sYjAf9D4cM1KdA1C7qCGaVX1eY2wS 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)(396003)(346002)(136003)(39860400002)(376002)(366004)(478600001)(76116006)(5660300002)(83380400001)(8676002)(71200400001)(186003)(2616005)(2906002)(6512007)(6506007)(44832011)(66616009)(8936002)(26005)(316002)(6486002)(99936003)(66556008)(66476007)(66446008)(66946007)(4326008)(36756003)(86362001)(64756008)(4001150100001)(110136005)(54906003)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?R2VKakducFNyQ2R3ZkU2aTI1SlY2ZlI5dkx6R3g4VUlSaWRpWUpDcWtRV1cw?= =?utf-8?B?VWIvWHB4dFF3VFVialV5ZU9maXI3N0diWmU2SnBaZ0xmWFZKUnlGbXh2MVAr?= =?utf-8?B?ZTVlRnVpS3JjclJNS3ZZVXFnQzNmQ1FBWGNEMitxNkpMQWFWVU1ISzU0SWha?= =?utf-8?B?dUgyd0RRZ093UnA0MWJvcnluWXE1M2U4UlAzT2srWnY4cjEvZWVrcy9UbDJ6?= =?utf-8?B?Z0tFeDZoODB0eTdkWjBPeE1Tdk1Wc2F6bnQvNUp2cE8ydHI2U3FEOW41OEp0?= =?utf-8?B?V2hDSFgxSXFqVDVOMStxTnJMWW4wa25sMHF4M3V6a1FuSUp5eklrdVZ5elFa?= =?utf-8?B?NGk0d2RQRHJKb3JDN0NvSVpSMjlLMHJLTWN6NVczSkIwejBzaUxLSjNKR3Nx?= =?utf-8?B?R1VqQit1ZHZUbG9MRjdQUXBlZnQ2Z0RvdkUyR3Btb2R6MGxhTExWYjFOcGZG?= =?utf-8?B?WFE0d2lBcmF3VGdSN0tkLyt6YVVZalNOcHRUUnI4Q25HaEJ5K28xS091OWxU?= =?utf-8?B?WU5JRm9ZNFFuTERvZGZjbG4rcTVWdHJPVm02Z2pSazU1bVMwTUhITUZERmlT?= =?utf-8?B?UHNvSnIzSjhkK2x6cHNVVFliVHZjWXQ2TWVOSFNPa1ptUm93K1lHdzFJYWhB?= =?utf-8?B?K3VQZjJ6UDd0SXpBb1JvZ1M2bzlkaUxsNnhxZEtKalJEZGxHc1ZoNktMWnk1?= =?utf-8?B?emJxdTB3TVNFZzFVYVpoUCtXczRKRy9IV3JyNk9KWjNuVDlGNm91MWJvVzZL?= =?utf-8?B?YTBjZXBYbWVRYktLYURaQ1JDUGtHV2pYZjFlc0JkNVA5OHRaL0pZZy8wZGlr?= =?utf-8?B?MDV0WEZQWWVTMFFnTncxa1VKTEphSjdCckdJVThySDV3LzVudEZabHRIa0xw?= =?utf-8?B?R3NWSXpFeTlBYmVwSVVsZG9QSzZCREF2VXdPZ2JPOEx4c0NWdUZsTCtXdlph?= =?utf-8?B?NTNhdlJWVGtETjVBaEZVVVN4UGdDVWd3V2MrRTRraG9QWGZBdmppYWVjaUlH?= =?utf-8?B?YzVLcFZHWCtwRlkxNFBaM0NHWk1wSi8yTnFDN2U2VEZZR2ZUcWxxcEpiOEhy?= =?utf-8?B?YUdWZC94OCt2OWMzUmIvelBST0czRjY5TURGejdtNE9WWmtNUmFjMmFBc2E4?= =?utf-8?B?ZENHWWhXNmFBVk9ZaytET1hkTXhqYjNuLzBQOEZTUTEzZjREVmdMN2hrNE5S?= =?utf-8?B?bDlFZnJBaGQrbkJTd0FoU1phTVFVMHB2eWRUeWxLR0JhMUtiTXZ6UWFJNzFs?= =?utf-8?B?VkZKT2R5TmlMOXU1MUc5UVZGV041T1JISDBSV2RYZ0hTNGQ3ZUVuWFhpd1c1?= =?utf-8?Q?CJ/d9j8x0SF+I1UwwQKATnlx1n+hX8+Wcj?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-tsmNiSeGxlyWVGL/FvIH" 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: 3f3bae96-3974-4fc9-5816-08d8a33abaed X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2020 09:53:11.1343 (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: 71DRglcKRCdoZwH+hEfWUfyHxLsPmePj01x6uHO/d6fw1HxVcSdVkV3JOJgNlb6g/ahI6cnOyaDk8Jx95+4IKdltYwwdhJnWYJ19Hbvm8sc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4443 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, 18 Dec 2020 09:53:17 -0000 --=-tsmNiSeGxlyWVGL/FvIH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Please see below On Thu, 2020-12-17 at 21:32 +0000, supjps-ietf@jpshallow.com wrote: > Hi Marcus, >=20 > Thanks for coming back on this and the suggestions. >=20 > Please see inline. >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto: > > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org] > >=20 > >=20 > > >=20 > > > > Based on what you write in your email to my understanding ALPN in > > > > (D)TLS would work fairly well to dispatch the secured connection to > > > > the individual implementation of DOTS-signal and Dots-call home if = that > > > > is > >=20 > > needed. > > >=20 > > > When using TCP, it is relatively easy to dispatch a secured connectio= n > > > and attach it to, say a forked copy of the appropriate application or > > > a new thread in the application which then does all the network i/o > > > over that secured connection. > > >=20 > > > However, for UDP from an implementation perspective, I cannot see how > > > this can be done so the network stack can itself steer each input > > > packet to the appropriate application when the traffic arrives on the > > > same IP and port (only one application can receive traffic on a > > > specific udp port). I welcome any wisdom on how to do this. > >=20 > > So I think there are several possible implementation paths for this. I = see > > at least > > two. > >=20 > > First, do a 5-tuple connect on UDP to filter that particular UDP flow, > > process the > > DTLS handshake for this socket and then based on ALPN decide on target > > process and then hand over the socket and the DTLS state to the right > > process. >=20 > [Jon] UDP has no concept of accept(). If you do a connect() on a socket = that > you have just received data on, then that updates the 5 tuple and then on= ly > receives traffic matching the tuple as expected. However, it appears not > possible to leave the original socket ready for the next packet (from > different IP etc.) and set up a new socket to specifically handle the str= eam > matching the packet just received, bind(same_port), do the connect() on i= t > etc. (the bind(same_port)fails in my test). So I don't have a code exmample for this available, but I thought you can m= ake it work with so_reuseport/so_reuseaddr. There are some downside in that the= new socket can receive packets prior to the connect that just arrive.=20 >=20 > >=20 > > Secondly, is to run some type of front end dispatcher that processes th= e > > packets > > and tracks all the different DTLS connection and have secure message pa= ssing > > between the front end dispatcher and the different servers. But this do > > requie > > another security model and trust relationship between the dispatcher an= d the > > servers. >=20 > [Jon] This does complicate things. The DOTS signal channel requires mutu= al > authentication of the agents and introducing some sort of man-in-middle t= hat > changes the network flow IP addresses etc. and potentially changes encryp= tion > characteristics breaks this mutual authentication. It is not easy to cha= nge > how the base DOTS signal works. Sorry, I don't understand why you bring in changes to network flow IP addre= ss. I said secure communication here, and I mean internal to the server software between processes. Basic interprocess communication here. Also, it might be= that you can start the DTLS processing in the dispatcher and then hand over the = DTLS state and only have encrypted UDP payloads being dispatached. I would note that I think a lot of this dicsussion comes from that the implementation you made so far has been done based on the assumption that t= here would be a new port and separation rather than designing for coloaction. If= we take the step beyond your current implenentation from a protocol perspectiv= e in an implementation built for co-location is there really any significant iss= ues here?=20 Cheers Magnus Westerlund --=-tsmNiSeGxlyWVGL/FvIH 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 BAIBBQCgggFBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMTIx ODA5NTMwOVowLwYJKoZIhvcNAQkEMSIEICZ/aSnDzKM1bVPCaJDMxSrYIP1qNaDBZAPUz3AiJP/y MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwawYLKoZI hvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEB AQUABIIBAA1hlCEYstl8UZ7OcvO4oMGeQjaw7oq/FKTUSpWQ8+kbLjWc7Q9ygsllooc3PJKtV++L FjVoqHNoTY21C4dCLOf7lMhgcOBC4mN3+0P2bIsKgtEouG058ZlpBdXZgxHZhjgl4yVJFRxDucrV 9aTBNoMkEK01ktXKqTQONdODbyAO1lakYldtfWh5WCQnbmkX+5SRr/mn2UoMMiDbdtqzC8iw1mSo D+9xMyWqnC2FA5ifWw3uc6Blk59AkDNT2UPXYdydZXB98YqVcmGT+bYKNL2FhFItzuRR9rEw4U+t I2SSqM64qTgil0/hdMUC8dM2wsTFWyXKi3C2ovwqPvS6H7oAAAAAAAA= --=-tsmNiSeGxlyWVGL/FvIH-- From nobody Fri Dec 18 08:58:26 2020 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 AA4863A0A50; Fri, 18 Dec 2020 08:58:19 -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 HqqIKWONjctt; Fri, 18 Dec 2020 08:58:17 -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 10E023A0A49; Fri, 18 Dec 2020 08:58:16 -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 0BIGwFj2017995; Fri, 18 Dec 2020 11:58:15 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0BIGwFj2017995 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1608310696; bh=nPuaNIOkvSLdccjpzQmM/Q0WMJMEp26GKJxXDZbLbwM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LdX4XAGkHDRIeVeXS/eHEJ1BEzn6IpiLEgL3oCiBPBP8O2A+5cYRIHCZ2+VIVfz9L TqsU+bKH4IHOro9jBJn0D9y/ZL333EsjsjfN3lMoIG2HfX1zqUoR0fnkPRu05EPvhh uAesMhwFnCP4wmubFZDGZMz6pjXP3E1ZysyNv8hQ= 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 0BIGw88b011748; Fri, 18 Dec 2020 11:58:08 -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; Fri, 18 Dec 2020 11:58:08 -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; Fri, 18 Dec 2020 11:58:08 -0500 From: Roman Danyliw To: "mohamed.boucadair@orange.com" , 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+AgAN5G1A= Date: Fri, 18 Dec 2020 16:58:06 +0000 Message-ID: <703969fb11df49a39c6241bb32934ff6@cert.org> References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@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.251] 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: Fri, 18 Dec 2020 16:58:20 -0000 SGkgTWVkIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvdHMgPGRv dHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAyMCAxOjE0IEFNDQo+ IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz4NCj4gQ2M6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3Rz LWNoYWlyc0BpZXRmLm9yZzsgVmFsZXJ5DQo+IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47 IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEb3RzXSBSb21hbiBEYW55bGl3J3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtDQo+IGhvbWUtMTE6ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBSb21hbiwNCj4gDQo+IFRoYW5rIHlvdSBmb3Ig dGhlIHJldmlldy4NCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lIGZvciB0aGUgRElTQ1VTUyBwYXJ0 LiBXaWxsIHNlZSBpZi93aGF0IGNoYW5nZXMgYXJlIG5lZWRlZCBmb3INCj4gdGhlIENPTU1FTlQg cGFydC4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiA+IERlwqA6IFJvbWFuIERhbnlsaXcgdmlhIERhdGF0cmFja2VyIFttYWlsdG86 bm9yZXBseUBpZXRmLm9yZ10gRW52b3nDqcKgOg0KPiA+IG1hcmRpIDE1IGTDqWNlbWJyZSAyMDIw IDIxOjAxIMOAwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDY8KgOg0KPiA+IGRyYWZ0LWll dGYtZG90cy1zaWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3RzLSBjaGFpcnNAaWV0Zi5vcmc7 DQo+ID4gZG90c0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47 IHZhbGVyeUBzbXlzbG92Lm5ldA0KPiA+IE9iamV0wqA6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLQ0KPiA+IDExOiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gUm9tYW4gRGFueWxpdyBoYXMgZW50ZXJlZCB0aGUg Zm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFs LWNhbGwtaG9tZS0xMTogRGlzY3Vzcw0KPiA+DQo+ID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4gZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0DQo+ID4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPg0KPiA+ DQo+ID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtDQo+ID4gY3JpdGVyaWEuaHRtbA0KPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4NCj4gPg0KPiA+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWRvdHMtc2lnbmFsLWNhbGwtaG9tZS8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+IC0tDQo+ID4gRElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4NCj4gPiBJ dCBzZWVtcyB0byBtZSB0aGVyZSBpcyBhIG1pc3Npbmcgb3BlcmF0aW9uYWwgZ3VpZGFuY2Ugb3Ig dW5kb2N1bWVudGVkDQo+ID4gZGVwbG95bWVudCBhc3N1bXB0aW9ucy4gIFNpbmNlIHRoZSBtb3Rp dmF0aW9uYWwgdXNlIGNhc2Ugc2VlbXMgdG8gYmUNCj4gPiBob21lIG5ldHdvcmtzIChwZXIgU2Vj dGlvbiAxLjEpLCBJIGFzc3VtZWQgdGhhdCB0aGUgY2FsbCBob21lIHNlcnZlcnMNCj4gPiBhcmUg cnVubmluZyBwcmltYXJpbHkgY29uc3VtZXIgZ3JhZGUgcm91dGVycyBub3QgbWFuYWdlZCBieQ0K PiA+IHByb2Zlc3Npb25hbCBJVCBleHBlcnRpc2UuDQo+IA0KPiBbTWVkXSBUaGUgZ2VuZXJhbGl6 ZWQgYXBwbGljYWJpbGl0eSBzY29wZSBpcyB3aGF0IGlzIHNrZXRjaGVkIGluIFNlY3Rpb24gMy4g VGhlDQo+IHNvbHV0aW9uIGlzIG1lYW50IHRvIGJsb2NrIGF0dGFja3MgY2xvc2UgdG8gdGhlaXIg c291cmNlLiBUaGlzIGNhbiBiZToNCj4gLSB0aGUgaG9tZSBjYXNlLA0KPiAtIGFuIGVudGVycHJp c2UgbmV0d29yaywNCj4gLSBhIHRyYW5zaXQgcHJvdmlkZXIgZmlsdGVyaW5nIGF0dGFja3MgZnJv bSBsZWFmIG5ldHdvcmtzLA0KPiAtIGEgcHJvdmlkZXIgZmlsdGVyaW5nIGF0dGFja3MgZnJvbSBk YXRhIGNlbnRlcnMsDQo+IC0gZXRjLg0KPg0KPiBGb3IgdGhlIHBhcnRpY3VsYXIgY2FzZSBvZiBo b21lIG5ldHdvcmtzLCB0aGlzIGNhbiBiZSBwYXJ0IG9mIHNlcnZpY2VzIHN1cHBvcnRlZA0KPiBi eSBhIElTUC1tYW5hZ2VkIENQRSBvciBhIG1hbmFnZWQgc2VjdXJpdHkgc2VydmljZSBzdWJzY3Jp YmVkIGJ5IHRoZSB1c2VyLg0KPiANCj4gV2UgY291bGQgbWVudGlvbiB0aGF0IGluIHRoZSBkb2N1 bWVudCwgYnV0IHdlIGRpZG4ndCBiZWNhdXNlIHRoaXMgYXJlDQo+IGRlcGxveW1lbnQtc3BlY2lm aWMuIFJlYWxseS4NCj4gDQo+IE90aGVyIHRoYW4gdGhlIGludHJvZHVjdGlvbiwgd2UgZG9uJ3Qg d2FudCB0byBvdmVybG9hZCB0aGUgZG9jdW1lbnQgd2l0aA0KPiBob21lLXNwZWNpZmljIGNvbnNp ZGVyYXRpb25zLg0KDQpJIHN0aWxsIHRoaW5rIHdlIG5lZWQgYSBiaXQgbW9yZSBwcmVjaXNpb24u ICBJIGRvbid0IGRpc3B1dGUgdGhlIGdlbmVyYWwgdXRpbGl0eSBvZiB0aGlzIGFwcHJvYWNoIHRv IGEgdmFyaWV0eSBvZiBlbnZpcm9ubWVudHMuICBJIGRvIHNlZSB0aGUgdHdvIHNlbnRlbmNlcyBp biB0aGUgZW50aXJlIGRvY3VtZW50IHdoaWNoIHNheSB0aGF0IHRoaXMgaXMgYSBnZW5lcmFsIHB1 cnBvc2UgYXBwcm9hY2g6DQoNCkFic3RyYWN0OiBUaGUgRE9UUyBzaWduYWwgY2hhbm5lbCBDYWxs IEhvbWUgaXMgbm90IHNwZWNpZmljIHRvIGhvbWUgbmV0d29ya3M7DQogICB0aGUgc29sdXRpb24g dGFyZ2V0cyBhbnkgZGVwbG95bWVudCBpbiB3aGljaCBpdCBpcyByZXF1aXJlZCB0byBibG9jaw0K ICAgRERvUyBhdHRhY2sgdHJhZmZpYyBjbG9zZXIgdG8gdGhlIHNvdXJjZShzKSBvZiBhIEREb1Mg YXR0YWNrLg0KDQpTZWN0aW9uIDM6ICJUaGUgYWZvcmVtZW50aW9uZWQgcHJvYmxlbXMgbWF5IGJl IGVuY291bnRlcmVkIGluIG90aGVyIGRlcGxveW1lbnRzDQogICB0aGFuIHRob3NlIGRpc2N1c3Nl ZCBpbiBTZWN0aW9uIDEuMSAoZS5nLiwgZGF0YSBjZW50ZXJzLCBlbnRlcnByaXNlDQogICBuZXR3 b3JrcykuIg0KDQpIb3dldmVyLCBJIHdpbGwgcmVpdGVyYXRlIHRoYXQgYWxtb3N0IG5vIGNvbnNp ZGVyYXRpb24gaXMgbWFkZSB0byBkaXN0aW5ndWlzaCB0aGVzZSB1c2UgY2FzZXMgaW4gdGhlIG5h cnJhdGl2ZSB0ZXh0LiAgVGhlIGVudGlyZSBtb3RpdmF0aW9uIGZvciB0aGUgd29yayBpbiBTZWN0 aW9uIDEuMCBpcyB0aHJvdWdoIHRoZSBsZW5zIG9mIG5ldHdvcmtzIG5vdCBtYW5hZ2VkIGJ5IHBy b2Zlc3Npb25hbHMgKGhvbWUgbmV0d29ya3MpLiAgRnVydGhlcm1vcmUsIHRoZSBleHBsYW5hdGlv biBvZiB0aGUgc29sdXRpb24gaW4gU2VjdGlvbiAxLjEsIDUuMSBhbmQgQXBwZW5kaXggQSBpcyBk b25lIHRocm91Z2ggdGhlIGxlbnMgb2YgYSAiaG9tZSBuZXR3b3JrIi4gIEZvciB0aGlzIHJlYXNv biwgSSdtIHB1c2hpbmcgdG8gbWFrZSBzdXJlIHRoZSBlZGdlcyBvZiB0aGF0IGRlcGxveW1lbnQg ZW52aXJvbm1lbnQgYXJlIGNvdmVyZWQuICANCg0KSSB3b3VsZCBhc3NlcnQgdGhhdCBtb3N0IG9m IHRoZSBiZWhhdmlvciBkZXNjcmliZWQgYmVsb3cgcmVxdWlyZXMgdGhhdCBwcm9mZXNzaW9uYWwg SVQgZXhwZXJ0aXNlIChsZXQgbWUga25vdyBpZiB5b3UgdGhpbmsgSSBoYXZlIGl0IHdyb25nKS4g IEknbSBsb29raW5nIHByaW1hcmlseSBmb3IgYSBmZXcgcGllY2VzIG9mIGNsYXJpZnlpbmcgdGV4 dDoNCigxKSBhIHN1Z2dlc3Rpb24vYWNrbm93bGVkZ2VtZW50IHRoYXQgQ1BFcyB1c2luZyB0aGlz IHNwZWMgaW4gdGhlIGhvbWUgZW52aXJvbm1lbnQgYXJlIGxpa2VseSB0byBiZSBtYW5hZ2VkLCBw cm92aXNpb25lZCwgaXNzdWVkICg/KSBieSBhbiBJU1AgKHRoaXMgYWRkcmVzc2VzIHdoZXJlIHRo ZXJlIHByb2Zlc3Npb25hbCBJVCBleHBlcnRpc2UgaXMgY29taW5nIGZyb20pDQooMikgYXNzdW1p bmcgKDEpIGlzIHRydWUsIGRpc3Rpbmd1aXNoaW5nIHRoZSB2YXJpb3VzIE1VU1QvU0hPVUxEL01B WXMgYWRtaW4gYmVoYXZpb3JzIHRoYXQgaW52b2x2ZSB0aGUgSVNQIHZzLiB0aGUgYWN0dWFsIGh1 bWFucyBvbiB0aGUgaG9tZSBuZXR3b3JrDQoNCk5vdGU6IGV2ZXJ5dGhpbmcgZWxzZSBiZWxvdyBp cyBqdXN0IG1vcmUgZGV0YWlsZWQgY29tbWVudGFyeSBvbiB0aGlzIHRoZW1lIGFib3ZlLiAgSSdk IHN1bW1hcml6ZSBldmVyeXRoaW5nIEkndmUgc2FpZCBoZXJlIGJ5IHNheWluZyBJIHRoaW5rIHdl IG5lZWQgbW9yZSBmaW5lc3NlIGluIGRlc2NyaWJpbmcgdGhlIG9wZXJhdGlvbmFsIGNvbnNpZGVy YXRpb25zIGFuZCB3aG8gaXMgZXhwZWN0ZWQgdG8gdGFrZSByZXNwb25zaWJpbGl0eSBmb3IgdGhl bSAocmVhbGl6aW5nIHRoZXJlIHdpbGwgYmUgYSBkaXZlcnNpdHkgb2YgZW52aXJvbm1lbnRzKS4g IEhvd2V2ZXIsIHNpbmNlIHRoZXJlIGFyZSBtdWx0aXBsZSB1c2UgY2FzZXMsIElNTywgdGhleSBk ZXNlcnZlIHVuaXF1ZSBjb25zaWRlcmF0aW9uIHdoZW4gdGhleSBhcmUgZGlmZmVyZW50IGZyb20g ZWFjaCBvdGhlci4NCg0KPiAgIElmIHRoYXQgYXNzdW1wdGlvbiBpcyB0cnVlDQo+ID4gKGFuZCBp dCBzaG91bGQgYmUgZG9jdW1lbnRlZCBpZiB0aGF0IGlzIHRoZSBjYXNlKSwgdGhlbiBJIGZpbmQg bWFueSBvZg0KPiA+IHRoZSBvcGVyYXRpb25hbCByZWNvbW1lbmRhdGlvbnMgbm90IGNvbmdydWVu dCB3aXRoIHRoYXQgZW52aXJvbm1lbnQuDQo+ID4gU3BlY2lmaWNhbGx5LCB0aGUgZGVncmVlIG9m IGludGVyYWN0aW9uIGFuZCB0dW5pbmcgc2VlbXMgb3V0c2lkZSB0aGUNCj4gPiByZWFsbSBvZiBl eHBlcnRpc2Ugb2Ygc29tZW9uZSB3aXRob3V0IElUIHRyYWluaW5nIGFuZCBjYXBhYmlsaXRpZXMg b2YNCj4gPiBob21lIG5ldHdvcmsgZWNvc3lzdGVtLiAgSW4gcGFydGljdWxhcjoNCj4gPg0KPiA+ IC0tIFNlY3Rpb24gMS4yDQo+ID4gVGhlIENhbGwgSG9tZSBET1RTIHNlcnZlciB1c2VzIHRoZSBE RG9TIGF0dGFjayB0cmFmZmljIGluZm9ybWF0aW9uIHRvDQo+ID4gICAgaWRlbnRpZnkgdGhlIGNv bXByb21pc2VkIGRldmljZSBpbiBpdHMgZG9tYWluIHRoYXQgaXMgcmVzcG9uc2libGUNCj4gPiBm b3INCj4gPiAgICBsYXVuY2hpbmcgdGhlIEREb1MgYXR0YWNrLCBvcHRpb25hbGx5IG5vdGlmaWVz IGEgbmV0d29yaw0KPiA+ICAgIGFkbWluaXN0cmF0b3IsIGFuZCB0YWtlcyBhcHByb3ByaWF0ZSBt aXRpZ2F0aW9uIGFjdGlvbihzKS4NCj4gPg0KPiA+IEhvdyB3b3VsZCBzdWNoIG5vdGlmaWNhdGlv biB3b3JrPw0KPiANCj4gW01lZF0gVGhpcyB3aWxsIGRlcGVuZCBvbiB0aGUgZGVwbG95bWVudCAo aG9tZSwgZW50ZXJwcmlzZSwgREMsIGFjY2Vzcw0KPiBwcm92aWRlciwgcGVlciB0cmFuc2l0IHBy b3ZpZGVyLCBldGMuKS4gVGhpcyBjYW4gYmUgdXNpbmcgRE9UUyAodGhlIGFkbWluaXN0cmF0b3IN Cj4gaGFzIGEgY2FsbCBob21lIGRvdHMgc2VydmVyIGFwcCksIGEgcHVzaCBmcm9tIHRoZSBhcHAg dXNlIGZvciBtYW5hZ2luZyB0aGUNCj4gQ1BFLCBzeXNsb2csIHNubXAsIG5ldGNvbmYsIGFuIFNN UywgZXRjLg0KDQpJIHVuZGVyc3RhbmQgdGhpcyBhbnN3ZXIgaW4gdGhlIGNvbnRleHQgb2YgdGhl IGVudGVycHJpc2UgdXNlIGNhc2UuICBIb3cgd291bGQgdGhpcyBoYXBwZW4gZm9yIHRoZSBob21l IHVzZXIgKG5vbi1wcm9mZXNzaW9uYWwgSVQgcGVyc29uKT8NCg0KSWYgdGhpcyBhbiBpbnN0YW5j ZSB3aGVyZSBpZiB0aGUgQ1BFIGlzIG1hbmFnZWQgb24gYmVoYWxmIGEgdGhlIHVzZXIsIHBlcmhh cHMgc2F5aW5nIGFuIG91dC1vZi1zY29wZSBtZWNoYW5pc21zIChhcHAsIFNNUykgbmVlZHMgdG8g YmUgcHJvdmlkZWQgZm9yIHRoZSBlbmQtdXNlciAoaG9tZSB1c2VyKT8NCg0KPiBBcyB5b3UgY2Fu IHNlZSBhIHZhcmlldHkgb2YgdG9vbHMgY2FuIGJlIGNvbnNpZGVyZWQgYXMgYSBmdW5jdGlvbiBv ZiB0aGUgbG9jYWwNCj4gZGVwbG95bWVudCBjYXNlLiBOb25lIG9mIHRoZW0gaXMgY2FsbGVkIG91 dCBpbiB0aGUgdGV4dCBhcyB0aGlzIGlzIGRlcGxveW1lbnQtDQo+IHNwZWNpZmljLiBOb3QgYWxs IG9mIHRoZW0gYXJlIGFwcGxpY2FibGUgZm9yIGVhY2ggZGVwbG95bWVudCBjYXNlLg0KDQpNYWtl IHNlbnNlLiAgUGVyaGFwcyBzb21lIGRldGFpbHMgZGlzdGluZ3Vpc2hpbmcgdGhlIGd1aWRhbmNl IHBlciB0aGUgdXNlIGNhc2VzIGNvdWxkIGhlbHAuDQoNCj4gPg0KPiA+IC0tIFNlY3Rpb24gMS4y IGFuZCA1LjEuICBMZWF2ZXMgY3JlZGVudGlhbHMgY29uZmlndXJhdGlvbiBhcyBvdXQgb2YNCj4g PiBzY29wZS4NCj4gDQo+IFtNZWRdIFRoYXQgaXMgYWxpZ25lZCB3aXRoIGhvdyBjcmVkZW50aWFs cyBhcmUgaGFuZGxlZCBpbiB0aGUgYmFzZSBzcGVjDQo+IChSRkM4NzgyKS4NCj4gDQo+ID4gU2Vj dGlvbiAxLjIgcmVmZXJlbmNlcyBbSS1ELmlldGYtZG90cy1zZXJ2ZXItZGlzY292ZXJ5XSBmb3IN Cj4gPiBwcm92aXNpb25pbmcuICBJbiB0dXJuLCBTZWN0aW9uIDEgb2YgW0ktRC5pZXRmLnNlcnZl ci1kaXNjb3ZlcnldIGFsc28NCj4gPiBkZWNsYXJlcyB0aGlzIHByb2JsZW0gb3V0IG9mIHNjb3Bl IGJ5IHNheWluZyDigJxUaGlzIGRvY3VtZW50IGFzc3VtZXMNCj4gPiB0aGF0IHNlY3VyaXR5IGNy ZWRlbnRpYWxzIHRvIGF1dGhlbnRpY2F0ZSBET1RTIHNlcnZlcihzKSBhcmUNCj4gPiBwcmUtcHJv dmlzaW9uZWQgdG8gYSBET1RTIGNsaWVudCB1c2luZyBhIG1lY2hhbmlzbSBzdWNoIGFzIChidXQg bm90DQo+ID4gbGltaXRlZCB0bykgdGhvc2UgZGlzY3Vzc2VkIGluIFtSRkM4NTcyXSBvciBbSS1E LmlldGYtYW5pbWEtDQo+ID4gYm9vdHN0cmFwcGluZy1rZXlpbmZyYV3igJ0uICBIb3dldmVyLCBS RkM4NTcyIHNlZW1zIHRvIHJlbHkgb24gTkVUQ09ORg0KPiA+IGFuZCBSRVNUQ09ORiB3aGljaCBz ZWVtcyBsaWtlIGEgcmF0aGVyIHVuY29tbW9uIGZlYXR1cmUgb2YgaG9tZQ0KPiA+IHJvdXRlcnMu ICBCUktTSSByZWxpZXMgb24gYSBtYW51ZmFjdHVyZXIgc3VwcGxpZWQvY29udHJhY3RlZA0KPiA+ IGluZnJhc3RydWN0dXJlIGFuZCBrZXlzdG9yZXMgdGhhdCBhbHNvIHNlZW0gdW5jb21tb24gZm9y IGNvbnN1bWVyDQo+ID4gZ3JhZGUgZXF1aXBtZW50Lg0KPiANCj4gW01lZF0gVGhlc2UgYXJlIG5v dCBtZWFudCB0byBiZSByZWNvbW1lbmRhdGlvbnMuIFRoZXNlIGV4YW1wbGVzIG1heSBiZQ0KPiBP SyBmb3Igc29tZSBkZXBsb3ltZW50cywgYnV0IG5vdCBhcHByb3ByaWF0ZSBmb3Igb3RoZXJzLg0K PiANCj4gPg0KPiA+IC0tIFNlY3Rpb24gNS4zLjEuDQo+ID4gVGhlIENhbGwgSG9tZSBET1RTIHNl cnZlciBkb21haW4gYWRtaW5pc3RyYXRvciBjb25zZW50IE1BWSBiZQ0KPiA+ICAgIHJlcXVpcmVk IHRvIGJsb2NrIHRoZSB0cmFmZmljIGZyb20gdGhlIGNvbXByb21pc2VkIGRldmljZSB0byB0aGUN Cj4gPiAgICBhdHRhY2sgdGFyZ2V0LiAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGhhdmUgYSBjb25m aWd1cmF0aW9uIGtub2IgdG8NCj4gPiAgICBibG9jayB0aGUgdHJhZmZpYyBmcm9tIHRoZSBjb21w cm9taXNlZCBkZXZpY2UgdG8gdGhlIGF0dGFjayB0YXJnZXQNCj4gPiAgICB3aXRoIG9yIHdpdGhv dXQgRE9UUyBzZXJ2ZXIgZG9tYWluIGFkbWluaXN0cmF0b3IgY29uc2VudC4NCj4gPg0KPiA+IFRo ZSBzdWdnZXN0aW9uIGhlcmUgc2VlbXMgdG8gYmUgdGhhdCBjb25zdW1lcnMgYXJlIGFjcXVpcmlu ZyBkZXZpY2VzDQo+ID4gdGhhdCBjYW4gYmUgcmVtb3RlbHkgcmVjb25maWd1cmVkIHdpdGggb3V0 IGEgZGVmaW5lZCB0cnVzdCBtb2RlbD8NCj4gDQo+IFtNZWRdIENhbiB5b3UgcGxlYXNlIGNsYXJp Znkgd2hpY2ggc3VnZ2VzdGlvbiBhcmUgeW91IHJlZmVycmluZyB0bz8NCg0KSSdtIHdvbmRlcmlu ZyB3aG8gdGhlICJzZXJ2ZXIgZG9tYWluIGFkbWluaXN0cmF0b3IiIGlzIGFuZCBob3cgdGhleSBh cmUgZXhwZWN0ZWQgdG8gY29uc2VudCBpbiB0aGUgaG9tZSB1c2VyIHNjZW5hcmlvPw0KDQo+IFRo ZSB0ZXh0IHlvdSBxdW90ZWQgaXMgcmVmZXJyaW5nIHRvIGJsb2NraW5nIHRyYWZmaWMgZnJvbSBk ZXZpY2VzIHRoYXQgYXJlDQo+IGluamVjdGluZyBERG9TIHRyYWZmaWMgZnJvbSB3aXRoaW4gYSBk b21haW4uIFRoZXNlIGRldmljZXMgY2FuIGJlIGFuIElQIGNhbWVyYSwNCj4gYW4gaW5mZWN0ZWQg UEMsIGV0Yy4NCj4gDQo+ID4gU29tZSBwb2xpY3kgb3Igb3BlcmF0aW9uYWwgY29udGV4dCBzZWVt cyBhcHByb3ByaWF0ZSBoZXJlLg0KPiA+DQo+ID4gLS0gU2VjdGlvbiA1LjMuMQ0KPiA+IC4uLiBu b3RpZmllcyB0aGUgQ1BFDQo+ID4gICAgYWRtaW5pc3RyYXRvciBhYm91dCB0aGUgY29tcHJvbWlz ZWQgZGV2aWNlDQo+ID4NCj4gPiBOb3RpZnkgaG93Pw0KPiANCj4gW01lZF0gU2VlIGFib3ZlLg0K DQpMaWtlIEkgbm90ZWQgYWJvdmUsIGlmIEknbSBhIGhvbWUgdXNlciwgaG93IGFtIEkgbGlrZWx5 IHRvIGdldCB0aGF0IG5vdGlmaWNhdGlvbj8NCg0KPiA+DQo+ID4gLS0gU2VjdGlvbiA4Lg0KPiA+ IEFwcHJvcHJpYXRlDQo+ID4gICAgZmlsdGVycyAoZS5nLiwgYWNjZXNzIGNvbnRyb2wgbGlzdHMp IGNhbiBiZSBpbnN0YWxsZWQgb24gdGhlIENhbGwNCj4gPiAgICBIb21lIERPVFMgc2VydmVyIGFu ZCBuZXR3b3JrIGJldHdlZW4gdGhlIENhbGwgSG9tZSBET1RTIGFnZW50cyBzbw0KPiA+ICAgIHRo YXQgb25seSBjb21tdW5pY2F0aW9ucyBmcm9tIGEgdHJ1c3RlZCBDYWxsIEhvbWUgRE9UUyBjbGll bnQgdG8NCj4gPiB0aGUNCj4gPiAgICBDYWxsIEhvbWUgRE9UUyBzZXJ2ZXIgYXJlIGFsbG93ZWQu DQo+ID4NCj4gPiBUaGlzIHNlZW1zIGxpa2UgYSBsZXZlbCBvZiBzb3BoaXN0aWNhdGlvbiBiZXlv bmQgeW91ciBhdmVyYWdlIGhvbWUNCj4gPiByb3V0ZXIgdXNlciBhbmQgYSBwbGFjZSB3aGVyZSBp bXBsZW1lbnRhdGlvbnMgc2hvdWxkIGNvbnNpZGVyIGEgc2VjdXJlDQo+ID4gZGVmYXVsdHMuDQo+ IA0KPiBbTWVkXSBUaGlzIGZpbHRlcmluZyBjYW4gYmUgYXV0b21hdGljYWxseSBzZXQgYmFzZWQg b24gdGhlIGNvbmZpZ3VyZWQgbGlzdCBvZiBDYWxsDQo+IEhvbWUgRE9UUyBjbGllbnRzLiBUaGlz IGlzIGEgd2lkZWx5IHVzZWQgcHJhY3RpY2UgKHRoaW5rIGFib3V0IFNJUCBwcm94eQ0KPiBzZXJ2 ZXJzLCBleGFtcGxlKS4gTm8gaW50ZXJ2ZW50aW9uIG1heSBiZSByZXF1aXJlZCBmcm9tIHRoZSB1 c2VyLg0KDQpBZ3JlZWQuICBIb3dldmVyLCB0aGlzIGlzIGFzc3VtaW5nIHRoYXQgc29tZW9uZSBp cyBtYW5hZ2luZyB0aGF0IGNvbmZpZ3VyYXRpb24uICBNeSBwb2ludCBpcyB0aGF0IGluIHRoZSBo b21lIHVzZXIgc3BhY2UgdGhhdCBpcyBtb3N0IGxpa2VseSB0aGUgSVNQLCBzbyBsZXQncyBqdXN0 IHNheSB0aGF0Lg0KDQo+ID4NCj4gPiAtLSBTZWN0aW9uIDguDQo+ID4gQ2FsbCBIb21lIERPVFMg c2VydmVycyBjYW4gYWxzbyBzZWVrIHRoZSBjb25zZW50IG9mIERPVFMNCj4gPiAgICBzZXJ2ZXIg ZG9tYWluIGFkbWluaXN0cmF0b3IgdG8gYmxvY2sgdGhlIHRyYWZmaWMgZnJvbSB0aGUNCj4gPiBw b3RlbnRpYWxseQ0KPiA+ICAgIGNvbXByb21pc2VkIGRldmljZSB0byB0aGUgdGFyZ2V0IChzZWUg U2VjdGlvbiA1LjMuMSkuDQo+ID4NCj4gPiBXaGF0IHdvdWxkIGJlIHRoZSBtZWFucyB0byBnYWlu IHN1Y2ggY29uc2VudD8NCj4gDQo+IFtNZWRdIFRoaXMgd2lsbCBkZXBlbmQgb24gdGhlIGRlcGxv eW1lbnQgY2FzZTogdGhpcyBjYW4gYmUgYW4gYWN0aW9uIGV4ZWN1dGVkDQo+IHVzaW5nIGFuIGFw cCwgYSBjb25maXJtYXRpb24gdG8gYSBub3RpZmljYXRpb24gbWVzc2FnZSwgZXRjLg0KPiANCj4g Pg0KPiA+IC0tIFNlY3Rpb24gOS4NCj4gPiBOb3RlIHRoYXQgYSBDYWxsIEhvbWUgRE9UUyBzZXJ2 ZXIgY2FuIHNlZWsgYW4gYWRtaW5pc3RyYXRvcidzDQo+ID4gICAgY29uc2VudCwgdmFsaWRhdGUg dGhlIHJlcXVlc3QgYnkgaW5zcGVjdGluZyB0aGUgcmVsZXZhbnQgdHJhZmZpYw0KPiA+IGZvcg0K PiA+ICAgIGF0dGFjayBzaWduYXR1cmVzLCBvciBwcm9jZWVkIHdpdGggYm90aCBjb3Vyc2VzIG9m IGFjdGlvbi4NCj4gPg0KPiA+IEFzIGFib3ZlLg0KPiANCj4gW01lZF0gQXMgYWJvdmUgOi0pDQo+ IA0KPiA+DQo+ID4gLS0gU2VjdGlvbiA5Lg0KPiA+DQo+ID4gICAgIFRoZSBET1RTIENhbGwgSG9t ZSBpcyBvbmx5IGFkdmlzb3J5IGluIG5hdHVyZS4gIENvbmNyZXRlbHksIHRoZQ0KPiA+IERPVFMN Cj4gPiAgICBDYWxsIEhvbWUgZG9lcyBub3QgaW1wb3NlIGFueSBhY3Rpb24gdG8gYmUgZW5mb3Jj ZWQgd2l0aGluIHRoZQ0KPiA+ICAgIG5ldHdvcmsgaG9zdGluZyBhbiBhdHRhY2sgc291cmNlOyBp dCBpcyB1cCB0byB0aGUgQ2FsbCBIb21lIERPVFMNCj4gPiAgICBzZXJ2ZXIgKGFuZC9vciBuZXR3 b3JrIGFkbWluaXN0cmF0b3IpIHRvIGRlY2lkZSB3aGV0aGVyIGFuZCB3aGljaA0KPiA+ICAgIGFj dGlvbnMgYXJlIHJlcXVpcmVkLg0KPiA+DQo+ID4gU3VjaCBhIGRlY2lzaW9ucyBzZWVtcyBvdXQg YmV5b25kIHRoZSBhYmlsaXR5IG9mIHlvdXIgYXZlcmFnZSBob21lDQo+ID4gcm91dGVyIHVzZXIu DQo+IA0KPiBbTWVkXSBXZSBkb24ndCBoYXZlIHRoZSBub3Rpb24gb2YgImF2ZXJhZ2UgaG9tZSBy b3V0ZXIgdXNlciIgOy0pDQoNCkFncmVlZC4gIFByb2JhYmx5IG5vdCB1cyB0aG91Z2ggOi0pLiAg TXkgaW50ZW50IHdhcyB0byBzYXkgdGhhdCB3aGVuIHRoZSBhY3Rpb25zL2RlY2lzaW9ucyBhcmUg YmVpbmcgZnJhbWVkIGFzIGJlaW5nIGZvciBhICJuZXR3b3JrIGFkbWluIiwgdGhhdCB0byBtZSBz dWdnZXN0cyBhIGxldmVsIGV4cGVydGlzZSBvdXRzaWRlIG9mIHRoZSBjYXBhYmlsaXR5IG9mIHR5 cGljYWwgZW5kIGNvbnN1bWVyIHdpdGhvdXQgcHJvZmVzc2lvbmFsIElUIGRlY2lzaW9ucy4NCg0K UmVnYXJkcywNClJvbWFuDQoNCj4gPg0KPiA+IC0tIFNlY3Rpb24gOCAg4oCcLi4uIGV4cGxpY2l0 IHBvbGljeSAoZS5nLiwgdGhlIENhbGwgSG9tZSBET1RTIGNsaWVudA0KPiA+IGFuZCBzZXJ2ZXIg YXJlIG1hbmFnZWQgYnkgdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZW50aXR5KSwNCj4gPg0KPiA+ IElzIHRoZXJlIGFuIHVuZGVybHlpbmcgYXNzdW1wdGlvbiB0aGF0IHRoZSBJU1AgaXMgbWFuYWdp bmcgdGhlIGRldmljZT8NCj4gDQo+IFtNZWRdIElTUCBtYW5hZ2VkIGRldmljZXMgaXMgb25lIHR5 cGljYWwgZGVwbG95bWVudCBjYXNlLg0KPiANCj4gVGhhdCdzIHNhaWQsIHRoZSB0ZXh0IHlvdSBx dW90ZWQgaXMgbm90IHNwZWNpZmljIHRvIElTUHMuIEl0IGFwcGxpZXMsIGZvciBleGFtcGxlLA0K PiB3aGVuIGdhdGV3YXlzIGFyZSBvbiB0aGUgcGF0aCBhbmQgYm90aCB0aGUgQ2FsbCBIb21lIERP VFMgc2VydmVyIGFuZCBDYWxsDQo+IEhvbWUgRE9UUyBjbGllbnQgd2lsbCB0aHVzIGJlIG1hbmFn ZWQgYnkgdGhlIERDIHByb3ZpZGVyLCB0aGUgZW50ZXJwcmlzZQ0KPiBhZG1pbmlzdHJhdG9yLCB0 aGUgYWNjZXNzIHByb3ZpZGVyLCBldGMuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IENl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucw0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91DQo+IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZQ0KPiBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMNCj4gZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZQ0KPiByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQo+IA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPiBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQNCj4g b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcw0KPiBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu DQo+IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBt YWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Sat Dec 19 04:08:29 2020 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 B1C643A0FF2 for ; Sat, 19 Dec 2020 04:08:27 -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 zrGw8ED0fPst for ; Sat, 19 Dec 2020 04:08:24 -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 C3CD43A0F35 for ; Sat, 19 Dec 2020 04:08:24 -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 1kqb25-0004iJ-Aq; Sat, 19 Dec 2020 12:08:21 +0000 From: To: "'Magnus Westerlund'" , , , Cc: , , , 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> In-Reply-To: <9a304e2ec6886de19ec54d2d56309442db652a02.camel@ericsson.com> Date: Sat, 19 Dec 2020 12:08:08 -0000 Message-ID: <154a01d6d5ff$9d022ab0$d7068010$@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: AQJ2bnsKEk4cVClsqjQj7jfeJ0e02wFsH/eMAmTmvDoCv3IYJgJfyZeWApvKKO4BrKO4XKhT8zCQ Content-Language: en-gb 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: Sat, 19 Dec 2020 12:08:28 -0000 Hi Magnus, Please see inline. Regards Jon > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: 18 December 2020 09:53 > To: iesg@ietf.org; 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; = draft-ietf-dots- > signal-call-home@ietf.org > Subject: Re: [Dots] Magnus Westerlund's Discuss on = draft-ietf-dots-signal-call- > home-11: (with DISCUSS) >=20 ... > > > So I think there are several possible implementation paths for = this. I see > > > at least > > > two. > > > > > > First, do a 5-tuple connect on UDP to filter that particular UDP = flow, > > > process the > > > DTLS handshake for this socket and then based on ALPN decide on = target > > > process and then hand over the socket and the DTLS state to the = right > > > process. > > > > [Jon] UDP has no concept of accept(). If you do a connect() on a = socket that > > you have just received data on, then that updates the 5 tuple and = then only > > receives traffic matching the tuple as expected. However, it appears = not > > possible to leave the original socket ready for the next packet = (from > > different IP etc.) and set up a new socket to specifically handle = the stream > > matching the packet just received, bind(same_port), do the 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 thought you = can make > it work with so_reuseport/so_reuseaddr. There are some downside in = that the > new > socket can receive packets prior to the connect that just arrive. >=20 [Jon] I was using SO_REUSEADDR, but have found a bug in my test code so = I now able to bind(same_port). While a new socket and connect() can be = done to match a new UDP client, it needs to be thought through when this = is done - the arrival of the first UDP packet, when the DTLS APLN is = known, or when the DTLS handshake is complete. The DOTS stack we have = is https://tools.ietf.org/html/rfc8782#section-3 Figure 3 DOTS CoAP DTLS UDP IP [Jon] It is unclear to me as to how you can hand off a DTLS context to a = different, non identical process along with its socket (this may be = possible with OpenSSL, not sure about other TLS libraries - there is = limited kernel AF_KTLS support which may help). DTLS session resumption = then also gets a lot more complicated. [Jon] Then there is the challenge of how the received DTLS context + = socket are integrated into the CoAP & DTLS stack on the receiving = application so that things keep working. In my port, it is the CoAP = library that handles the sockets, not the DOTS application which would = mean having customized code for the CoAP library - not ideal for = maintenance long term. [Jon] My surmise would be that implementors would say "forget this = complexity with its inherent risks and just use a non-standard port" > > > > > > > > Secondly, is to run some type of front end dispatcher that = processes the > > > packets > > > and tracks all the different DTLS connection and have secure = message > passing > > > between the front end dispatcher and the different servers. But = this do > > > requie > > > another security model and trust relationship between the = dispatcher and > the > > > servers. > > > > [Jon] This does complicate things. The DOTS signal channel requires = mutual > > authentication of the agents and introducing some sort of = man-in-middle that > > changes the network flow IP addresses etc. and potentially changes = encryption > > characteristics breaks this mutual authentication. It is not easy = to change > > how the base DOTS signal works. >=20 > Sorry, I don't understand why you bring in changes to network flow IP = address. I > said secure communication here, and I mean internal to the server = software > between processes. [Jon] I latched on to "different servers" as possibly having different = backend IPs. Here, we actually have a DOTS server (sends responses) and = a DOTS client (generates requests) that traffic needs to be steered to. > Basic interprocess communication here. Also, it might be > that > you can start the DTLS processing in the dispatcher and then hand over = the DTLS > state and only have encrypted UDP payloads being dispatached. [Jon] As above, it is unclear to me as to how you can hand off a DTLS = context to a different, non identical, process along with its socket and = then integrate the received DTLS context into the different application. >=20 > I would note that I think a lot of this dicsussion comes from that the > implementation you made so far has been done based on the assumption = that > there > would be a new port and separation rather than designing for = coloaction. If we > take the step beyond your current implenentation from a protocol = perspective in > an implementation built for co-location is there really any = significant issues > here? [Jon] I am the sort of person that needs to implement something to prove = something is practically feasible, find what the issues are and what = needs to be changed based on a specification and then debate how the = spec needs to be updated to make it usable. [Jon] DOTS call home did come later to the table after the initial DOTS = was done which created the DOTS client and DOTS server as different = applications in the implementations done to date. Adding in the DOTS = call home logic was very simple (with different port) - simple addition = of accepting new connections on the call home DOTS client which = triggered the client logic start up and initiating connections on the = call home DOTS server and associated configuration logic.=20 [Jon] While it is only software and hence not impossible, it is = significant work to merge the client and server into a single = application as well as having to maintain separate applications for = running on limited resource devices. We do not want to put in barriers = to implementation of this draft by making it complex to implement. = Hence using a different port for the client service and the server = service. >=20 >=20 > Cheers >=20 > Magnus Westerlund From nobody Mon Dec 21 00:10:22 2020 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 2BBE03A0EA0; Mon, 21 Dec 2020 00:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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.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 MDToPBhkKiXD; Mon, 21 Dec 2020 00:10:13 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80073.outbound.protection.outlook.com [40.107.8.73]) (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 491533A0C0D; Mon, 21 Dec 2020 00:10:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CKiBT8mCbYyqchUW38woi+5jUsTilWN3l3noOt0iXf3LANpeaB4EiNumMwhSJE3D1FAXzMN4GCtUZQ/Xr2oQxUMFVVaxEi4quOwvLo0AqxlqRt9Wt+3bvh/5Lg25TAlO+CdkJR3Azh96ruzEHtfNoXSH6d5XWggoCiC3Us5SyH11vfrQw24Ypp4oS5oPdxPvNZx+xVPKFDBZKmYzwBhi54QWrV0j1NAHXRh2Unj8kPlJG3j00b0quMDv+H7XM0KiEvPIyLfBzf6YxSOPFsExq7CHXKdyHN1E+o36suHPb7vtQ66/2shzWTLL2J0e2KeMiU74M10yrMpjsEuGSnvzkw== 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=7GdYByu7o5bRufuk5UNMGoZZWj9C9GCual2Yg6Iubrc=; b=ffDKxgWLSxnZc9Jde//noPkdePHiJLVACGdR9Qksa4KnLIdhTDcRTvw2BM/DMYqv/PI9bYNlhwYVTqBxngzAXgJwWdKg5bGZmEINyMrLQCa52esA7cWqF0HIW4J21Yj75hy90y9WZiBoQCgNjrgg/sQ0rnqUgD1Zs2llOtR1lNQmpZx7qEadxbxcqb69lmkKkgJxqDEEUkHpLTM/vqVi5YvubbVSo5R6yXillE1JJK35aQMWN7M/frKm8fOgopgQ8zpneUY+BhJj/omwtM/FOmil3ZR7y/+f6ibS1iwsJ0pjyCEV3WWUIlgEsHniJ+eKQlwlqPtfWfQuja+sxcDsfw== 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=7GdYByu7o5bRufuk5UNMGoZZWj9C9GCual2Yg6Iubrc=; b=KkF0zPlLK7zBhd/l2LYEFqJVVcKYBE1Bhhjf5nB+ur6enQeEfVQTVJB12A5FMBwhVpI4f6K4P0ORUXyieDPbPjn4B4Ek0Edgx+BkIZYchtr+/Mgt2/hnMfQt/O9ps3qbPEV/m9TcOU/H5dPj9g5CuxPXyvuuD25yV1OKaFlzURQ= 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 DB8P189MB0698.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:127::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.29; Mon, 21 Dec 2020 08:10: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.3676.033; Mon, 21 Dec 2020 08:10:10 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Cc: dots@ietf.org References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> 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, 21 Dec 2020 09:10:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO" X-Originating-IP: [91.132.138.180] X-ClientProxiedBy: HE1PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:7:2a::18) 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.6] (91.132.138.180) by HE1PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:7:2a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.29 via Frontend Transport; Mon, 21 Dec 2020 08:10:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3b5821a5-a691-462e-9457-08d8a587d63a X-MS-TrafficTypeDiagnostic: DB8P189MB0698: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5236; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ugKwGHZHaBrhsljHy4MjpiYDAAJs58hxUSXTOMoEfqBm48opAobMj1v7S0RH4NNbd/Eg6NTP31Wy8PnXkraNYp6pM0ggmtLfE/M+R0O53VWPCXG9qnLbqoNSYf+EmP7GSDM2NzNkQfV41vaR67yEfjq//pO7zlczZ5RrRcKuta8nUOSwcRkKJAciGEkpIVSMk5GzMqe0VAWWeClSy3ipYN9qdSE0Q0abnDLUYbjmDYSglW3KyYoq9kWS9ExBR+VUp52G5T7KuTMVPcXNXkpXLbhFgmTohMUcSrHTGTxU0vSTEax/VlkvgPHrVEPOf203yRY6mfST1pTaRti0A0TANcRsjBjxYjgY00BYTfn7g129BL9exp8UrnFbYrPmcS6HqemrPymfGQMQbtQWQj5OhmBA7Zhy7GHelnNkLK4Wdiz7NVSbqfTPIODHnnANyRWrF4La8zEuQNT2C9RwGazxxHVIfgjTzIcDXLk3MN9icAUPjYOdaNOzqAPiNsceTkm9CCLpKoUemqkAGDu2mBlrzU/duafoEiyyAn987lpV0aBAaq30DFm6PjrHPr9kT19w 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)(376002)(346002)(396003)(136003)(366004)(6666004)(16526019)(21480400003)(186003)(83380400001)(478600001)(86362001)(66946007)(36756003)(16576012)(316002)(966005)(66574015)(31696002)(44832011)(5660300002)(4326008)(450100002)(6916009)(6486002)(956004)(26005)(235185007)(33964004)(2616005)(52116002)(8936002)(8676002)(31686004)(66476007)(66556008)(53546011)(2906002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?U1gxWDBhZjV5M2tqVTFiL1BSUlppUnJjOWtDYVdaVGliN1VxakorcVhYM1Nx?= =?utf-8?B?a01mRDAva0NFeDd2NHR5TmZZazdBOXZmTjZveFdzNEh0ZWVQVkZPdzJlVkxt?= =?utf-8?B?b0xzaVU5VkRSbEVHOElqTHNpWWtpbzZMUnhid3FhTXRaMEpUd1RQVGxuamRV?= =?utf-8?B?S1h1aXdtUlVqMTlQMlpaZ3FmMFhKeE9aODg4SzB4RlN3QlJLWmVqcWI1V1Er?= =?utf-8?B?UkpMdVU0STIrRmtUWFpuTTU0YzgvRjBXbnNlQSthNmw0eXhla0E0TS83YnN5?= =?utf-8?B?dUluWG1TUzNkVlFBc1E1U0l1ZHlUUTYrbW5YRHE0NjRtSlJYMlBNdzZUM2dD?= =?utf-8?B?akpDeWtCK0Rkcit3WXpra2RMUVl0b043U1FUODhXNEF6RE1yU0l1a3lPWEFM?= =?utf-8?B?U3dWNGZBTEhLaW5zRG00eExNR1JGU09hQTNOMElueHh5VHBEd2VUanV6dC85?= =?utf-8?B?TUIrNm1PV2VoQnU3Z3FMSG5qUHJ6M0w4aWtlcFBWSVh6VGUyM2FJRmU5OThx?= =?utf-8?B?UWZ0Y3RrWHphQ3E3NG5LNHcvOXBoNnV5SGUvL2k2L2ZRWHlLb1V0VTNINE5I?= =?utf-8?B?V1EvUE9uTVl0Z3ZDemFPbjdtcHBMTGRVZFgzZ2hRS1ZCMlVVT2dHKzVnLzVX?= =?utf-8?B?ZS9wMFdFRkJKQUNQbCtsWDl1M21WZlBBb1Q5Qk1NbGdvNXhJaXRrL0RRTkpK?= =?utf-8?B?YVFDT0hoWXVVOTcxVmRtd3pKeTRaQTR5Wjd5QmFPLzNnVVZ0NExIZjRtQUx4?= =?utf-8?B?Q1NsUlNOcWUrbUNaMzJPeUVQN014aVVNeWhSQmhJTklPcEVab3ZELzA3M1dl?= =?utf-8?B?NHpZYnA4Mk1iQU41UFJTUGZYMC9GcUhHTzJBTVNpWDFKcnRHNTVqZ3pnQWZl?= =?utf-8?B?ZmZteEVzTnU3ZnJPTXdha2d2VFFEbXdHdjdBYU0xU2U2SWJKb1RrdTJpcnpP?= =?utf-8?B?T24xUWdBMzYzblc2bGJtUUhaU0luN1pjVjFkMjF3QkhaWFZNY3ZlMzNqbXVS?= =?utf-8?B?NTRWc3F1NFp2b2UrYVpyZlF3YTJBK0dmQUJLRUhsRmM0eCtPWU5pdW1sa3hJ?= =?utf-8?B?MmtnVFRMWTRkTm00VVRxbHQrT0gzSlZUTmdFU0ozSDlmMnRLL2tGU0VlaVdN?= =?utf-8?B?TXFXQjNac3g4SHVmZi9TaVIwV2NZRXFFTk44R1RBeVdtdWw5Z0ZTc3NIeFZ6?= =?utf-8?B?L3FQTS9wTFZLckZ6bEU5UmkzUDF4eTh3SklzSklzUThHMEd1TENjRG5DSUg3?= =?utf-8?B?bWhYY1FXSnQyRDVEaTNueVg5dHlLRjU1bFNsakFERzkwcldLSmMybjF2K0xV?= =?utf-8?Q?qUP/LaWqOSzZXPak+Kpe/TJUSHe+lo2hRl?= 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: 21 Dec 2020 08:10:10.5768 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 3b5821a5-a691-462e-9457-08d8a587d63a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tX7Ei2TDzrHJKsixZJtICJGRBqYErbsRr8RpbsPzSnR1FK5y7LQlE5yaRmOAb3HZPHgz/6Xk0nPEwR++63CKhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0698 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, 21 Dec 2020 08:10:17 -0000 --eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO Content-Type: multipart/mixed; boundary="64udCFNJUzVwYHSDGAmrOlwJDpKwn2L8v" --64udCFNJUzVwYHSDGAmrOlwJDpKwn2L8v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, Please, see below some comments for this WGLC. Best, /Marco =C2=A0 [General] * s/CoAP endpoint sender/CoAP sender endpoint * Please, replace the references to RFC 7049 with references to RFC 8949.= * There are six instances of "CoAP session", which is not defined in RFC 7252 or RFC 7959. Do you simply mean "block-wise transfer" ? [Section 1] * I think that the heading of the current Section 1.1 can be removed, so that Section 1 starts simply with "The Constrained Application Protocol .= =2E." * s/and further updated/and was further updated * s/loss; which/loss, which * s/informs the CoAP endpoint sender either successful receipt or/either informs the CoAP sender endpoint of a successful receipt or * s/that have been not yet been received/that have not yet been received * s/will both generally/will both be generally * The last paragraph in Section 1.4 can be expanded to mention OSCORE as an alternative when DTLS is not used. [Section 3.4] * As to "If the server receives multiple requests (implied or otherwise) for the same block ..." , I guess the word "requests" does not mean CoAP requests, since the paragraph is talking about a single actual CoAP request. In fact, it seems to refer to the multiple needed blocks indicated by the multiple Q-Block2 options in a same CoAP request. =C2=A0=C2=A0 If I'm interpreting correctly, this tries to cover a strange= behavior from the client that sends multiple Q-Block2 Options in a same CoAP requests with the M bit set, such as: 2/1/1024 , 3/1/1024, 4/1/1024; but still the server has to send back blocks 2, 3, 4 ... until the last one only once each. =C2=A0=C2=A0 =C2=A0=C2=A0 If this is correct, how about the following rephrasing? =C2=A0=C2=A0 =C2=A0=C2=A0 "If the request includes multiple Q-Block2 Options and asks = for a same block multiple times (e.g., through the M bit set), the server MUST only send back one instance of that block. * s/if this is the case/if this is not the case * s/Option whichever is/Option, whichever is [Section 3.7] * s/and MUST have the same value/and MUST preserve the same value in each of those payloads. (just to avoid reading it as Size1 and Size2 must have the same value) [Section 9] * I suggest to add one more example in the end, where Q-Block2 is used in a request with the M bit set. As a separate continuation of the example in Figure 7, this can be the case where, after observe being triggered one more time, only the first block for a new ET=3D24 reaches the client, which can use a single QB2:1/1/1024. [Section 11] * As mentioned for Section 1, more can be said here for when OSCORE is us= ed. On 2020-12-07 18:35, Marco Tiloca wrote: > Dear all, > > Following the recent clarifications from the authors [1], this mail > starts a Working Group Last Call on: > > https://tools.ietf.org/html/draft-ietf-core-new-block-02 > > This WGLC will end on Tuesday, 22nd of December. > > This WGLC is also copied to the DOTS WG mailing list. > > Best, > Marco and Jaime > > [1] https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvj= iLI/ > --=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 --64udCFNJUzVwYHSDGAmrOlwJDpKwn2L8v-- --eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/gWGAACgkQ7iZktA5Y 2kP8Ygf9F1wUoMx4gvQNIba9Nqlh3toLQW9KtH7H8uiO/FujvVyO0GT/3Wa+VcRd vl9FrSizV8f2gKcFpU2WbZwvGk7HW9ATQfr8nwMrjM6pFMXqwVeaFetr1u5QJDq5 ljksZJEljw5lXYFq6aOMsCWNnBlXs7LIo5PKYhBn9ZSYeoph+R2L6Kh9RIMMY7wi pjXO3MfUp2wqJzhWGb0cDqMNTh5cShhV1/DbLB00gT5dlgqHaE/rpI0cKWbF1hUp x8Dr4BPaEQyHokjTjMTEvc8cXtRiC8F6He4ItIuf9Zr756pYRTWjTZzEKeyBbX23 YVyDtKPHbOON14wrKDVx+w4WXltHQA== =C/zs -----END PGP SIGNATURE----- --eOEMrsvD4dU5YvhOvcvvYZQfVbHbvK1hO-- From nobody Mon Dec 21 03:03:29 2020 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 4A2AB3A10B3; Mon, 21 Dec 2020 03:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Rin-SSBCCkVR; Mon, 21 Dec 2020 03:03:24 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2069.outbound.protection.outlook.com [40.107.21.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 C1C783A10B0; Mon, 21 Dec 2020 03:03:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f77O8CXxLPJ7p+95TsiLnlQZG32oEm9tC9yCa5LRuKUtxXs+mGODBPCalwUKAbFv3Cj4McBO6/Dz1p+VlBu+b8XGXkw8n+nr7gp2mclfWbNrK7qFSc7OADNUaPS4l3cY3hRO7NWrvHPB86PVnVU2R8Rlo/CAYcBC0ksyEYj84MgjB5JyPdeCHZTujd1TDlXUS9zbB0NrzVWDm6MZ5UpGI9OTF3NnBx8ULuwzdUgs69m3k0pFVZzKdzRLa2/q88evcu8XRjmZWXTMg3ADX2VPb1c6BR8axWYJYxroQ5HP6Rw7V+6aJllBI4dhsOOw/NMUlRCs8S1aCVwtplqN9v976A== 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=3u/3fdwWp41gQQoMFlbtnFvDGVCT1LBb6QL+7A5M5qY=; b=PmKEXn8JlwdSflRzlS6Y2SsOm8FhpmD3iLjggSnAJbikkPFX9qMX4BMEX12tExQnvI0R22MsK/+oY63/WSYGDZBeuumwBpiNxX5wbpGgUKGJrzO3+u6uLGigsWxjFyF4FTY0v6oyGbg/Xw2zM+Yzz5b+uFlM6MXxnrzgJdoBillYEBQu5F30dkJVCeOmON6wr4XLAG7bFg7jWqEgHa5ei8Mc4g5l9CzUBQe0WBqqfXeVOUfDAodCIe6gT37SwSGsxf1cy0I0t9BNyNc76t0Cv98pyxP7chhMR2kI9Y8xBIVNbea+mgOZHlOj8kHaLwfP0VFRnRRdlFcUNsTuMWGp4w== 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=3u/3fdwWp41gQQoMFlbtnFvDGVCT1LBb6QL+7A5M5qY=; b=Epgd7zLmUwvUHc48TOEZsTxDLY6uG/2N4vylvc+6PJ0CQ57uIvU3FRf49bNFT0qe3hgx5c9pMpEAMTSo6S9KH4V5z2w4ZOQXzJIQ4cDHVXu+FkQWGMOwws6ZJp+j41VVWZSQqcNZw1tN1VFREx8jU4K5Ed3LoEyx/IKixODFmcs= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4219.eurprd07.prod.outlook.com (2603:10a6:7:9f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.26; Mon, 21 Dec 2020 11:03:18 +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.3676.011; Mon, 21 Dec 2020 11:03:18 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "supjps-ietf@jpshallow.com" , "mohamed.boucadair@orange.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: AQHW1IEMs9vsdNy1dUKXFtQUcezc5qn7Z94AgAAI8ICAABFlgIAACniAgABCigCAAM7vgIABuBMAgAMSigA= Date: Mon, 21 Dec 2020 11:03:18 +0000 Message-ID: <6d2f00810b5bc9ec3e8ab10fa7e75b824e0f9003.camel@ericsson.com> 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> In-Reply-To: <154a01d6d5ff$9d022ab0$d7068010$@jpshallow.com> 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: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0f1f800e-68d1-44fa-3309-08d8a5a005d4 x-ms-traffictypediagnostic: HE1PR07MB4219: 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: v8dthAUsM8AMSY7npPMuryMNTeVWbYVIdJ8A5/ojP/XpiWa9pYZ5L6zjgWrPPlmhzyPdnv33dtDNcfHK4EqxSeJIYonglJuz9S8UOt+BAPg1pxh76Ll2bJMZFoMHRaRKhWqY4f6R9zOSfgck4abx3VyZBvdO10UPiGmKBYxfIyOnodo5Xp60Ttsv0q3xzSe7fRZL7QTemd5tnhmeXbFzAv9C6wRPFj+VqAddcT57Pit2c87n9+euVfUMlO/mxc5JO4aznW2g1lQNH4GBssFwfIS3Nt99jQhPbnm1s5RTe6PsIJBBHOTT3LUe6UNNl28lWvQeaKEWqiqEIiLd8XLFgjviBmCx94m51J0w+0j2mQBnkDG4oczOef5Z0I8ZAjb9xg2acYkfpkE+d7Sj4sEgEZhQxnYTioLNcPtdLTMIY7fscWXmDpd91zODVKEnyXDlDuFhXK7AnmWAEiixxS027ljzhDCKm8OmABFNMN3xI0E1qoZh2BA7mQJ+qD1cNnpypg0eihNqtvRrzn/SKmjFeQ== 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)(346002)(376002)(136003)(39860400002)(366004)(396003)(186003)(99936003)(66476007)(66946007)(6506007)(478600001)(6512007)(66556008)(66616009)(64756008)(66446008)(53546011)(83380400001)(71200400001)(6486002)(26005)(316002)(2906002)(54906003)(110136005)(8936002)(86362001)(4001150100001)(36756003)(76116006)(8676002)(5660300002)(44832011)(4326008)(2616005)(966005)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eng0WTRDaVQ1KzRpenpjNGN4MHJiMjNMZUZsbVZ5VXJxL2txaUR6cjc5RFR2?= =?utf-8?B?TTJzWnVRaENpRktwelFVcXh1TWxSc3RmNFJnNTdMRjhGdVhrYXhzNjFuLysw?= =?utf-8?B?MEtFZlVuRVpYcEMwcUlxQ0Y1ZnpVSjEzcCt5c2pMNmhLeWFnRTl4RHl1VENP?= =?utf-8?B?aEhWV0Z0MzM2a1VpOWJTUTlTSkg2aHZ0UjJyeU9XM2tYMVZSM0hzTUx5RXFM?= =?utf-8?B?STNSdDgycTdlOHU3KzJ0SXR2c2grMS9rTE1kMHlxUjRZWGVuOU5TaENIY1Ez?= =?utf-8?B?ZzJHS2xzVDRTVFBYVDVIeXp0TkJhSzQ5aXpxVGR0b2RGYkRqZVJzOVJhWUNX?= =?utf-8?B?WFBheFBxSzFySHk0cS9tTjdMencvL3dDMmRFOXlsUmMyRjM5SHE5bG4yNXBa?= =?utf-8?B?dVNDVU40RXVLcWpmdVVNenNGa1YvOWl0SkpBNEo0NlU4enZUU3JINnhGbnJn?= =?utf-8?B?TGxzakZwSi9KcC95b1lNc0FyQUFidno5c0FVaERVZ1RkOExGVXBLY2hZWC81?= =?utf-8?B?em5yVWl3L25pbDZlZWwyTmxiSEpqTkhWdXFaeUhNeG9VSGppNFJSc2lHSzds?= =?utf-8?B?WGNCUjBLV1htUTFNUE8wT1FablJlaGVxOWZmeUNiTGRQRkcxWEFOSjU4amds?= =?utf-8?B?eHhuTmsraVJ5NDUvS3pZSFVtcGJtL0RiTDFmUlM5bmVacFJlVGJXaWU5OStO?= =?utf-8?B?bHdzd3F5bklDTDNVREJEZFVaSUk4WURrVlRmdVBCa1RIU2pxMHdla0dxdzM2?= =?utf-8?B?cUhYWGFtckNnWHNkOTdzalV5SHZqcVJWdzVyOUFlSHVaYU5WT3FHajNDOERj?= =?utf-8?B?ck5pRWNwU3VxSkd6enBSZjNIUGgzeU4yaGl5SVh1clpHWUxPb0lieERUT1ln?= =?utf-8?B?c0UxREdtN1ZzMld3aktPNGgyQlhUcm5RY0Y5MXlwc3pGd0VSSm9UMmV1Qmdo?= =?utf-8?B?TGgyNWhQbTBOSWd0a1p3Q3QxOTc1ZllELzh4bU91amNaUTU5bjdBTDRqcFd6?= =?utf-8?B?M2dYcXZPa0lIcjJRcDRKMXNBcDdvK2J3MjB1ZFlmNDRVb2EzRk8yZDVZLzUx?= =?utf-8?B?Z0NQWWI5ZWx3Mk9VR01jQlRUZDdnNlZuem1wa01ad0NZSFdzK1hqVG0zYXAr?= =?utf-8?B?cENIckdoM2FMdVBONjNqYlFhSzZZUUVETk1xbVA2ZU05Uzl3dVZuTkRtM2Q0?= =?utf-8?B?K0RrYStKMlJVQmJGWFVOR1RDbVlrM3lsTE1aSUloWlRlZWlNbW1BUVBtNmJS?= =?utf-8?B?MmdWc0I2M2JHMW9QTCtNbk4weElMbVNrdGJVQkNTdEVSa1E0Qnd4ek5SQmxH?= =?utf-8?Q?6A4+yz9SKnayEj72DPeA2oitJjkUMZ5oJn?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-BXSMWlizRCiW6QBxdMpa" 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: 0f1f800e-68d1-44fa-3309-08d8a5a005d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2020 11:03:18.2649 (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: Qvj8pPluzsWKlnGGeM5ej5TCDI5sIZY4Wcm1BO2Vyylj+ZrrKrgEt1h8Bu1rAQCntljwZVXMgFoKQtRoE7I1aYU5f9+BcX8npKHoSFJfdw0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4219 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: Mon, 21 Dec 2020 11:03:26 -0000 --=-BXSMWlizRCiW6QBxdMpa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I will start my Christmas vacation tomorrow, so don't expect any more respo= nses until after the 7th of December.=20 I am hearing what you are saying about implementability. However, I have th= e feeling that the WG design process have failed to take into account some relevant aspects here. 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 ser= ver. Thus it could have been easy to ensure that individual or coloated dots-sig= nal 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 po= rt just because you didn't consider the constraints, which RFC6335 is clear wi= th 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 shoul= dn'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 se= rvice name enables you to do SRV look ups to find port and IP address for the ser= vice. Isn't that sufficient if you still want to run it on dedicated port compare= d to DOTS-signal?=20 Cheers Magnus Westerlund 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; magnus.westerlund=3D40ericsson.com@dmarc.ietf.org; s= upjps- > > ietf@jpshallow.com; mohamed.boucadair@orange.com > > Cc: valery@smyslov.net; dots@ietf.org; dots-chairs@ietf.org; draft-ietf= - > > dots- > > signal-call-home@ietf.org > > Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-sign= al- > > call- > > home-11: (with DISCUSS) > >=20 >=20 > ... > > > > So I think there are several possible implementation paths for this= . I > > > > see > > > > at least > > > > two. > > > >=20 > > > > First, do a 5-tuple connect on UDP to filter that particular UDP fl= ow, > > > > process the > > > > DTLS handshake for this socket and then based on ALPN decide on tar= get > > > > process and then hand over the socket and the DTLS state to the rig= ht > > > > process. > > >=20 > > > [Jon] UDP has no concept of accept(). If you do a connect() on a soc= ket > > > that > > > you have just received data on, then that updates the 5 tuple and the= n > > > only > > > receives traffic matching the tuple as expected. However, it appears = not > > > possible to leave the original socket ready for the next packet (from > > > different IP etc.) and set up a new socket to specifically handle the > > > stream > > > matching the packet just received, bind(same_port), do the 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 thought you c= an > > make > > it work with so_reuseport/so_reuseaddr. There are some downside in that= the > > new > > socket can receive packets prior to the connect that just arrive. > >=20 >=20 > [Jon] I was using SO_REUSEADDR, but have found a bug in my test code so I= now > able to bind(same_port). While a new socket and connect() can be done to > match a new UDP client, it needs to be thought through when this is done = - the > arrival of the first UDP packet, when the DTLS APLN is known, or when the= DTLS > handshake is complete. The DOTS stack we have is=20 > 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 context to a > different, non identical process along with its socket (this may be possi= ble > with OpenSSL, not sure about other TLS libraries - there is limited kerne= l > AF_KTLS support which may help). DTLS session resumption then also gets = a lot > more complicated. >=20 > [Jon] Then there is the challenge of how the received DTLS context + sock= et > are integrated into the CoAP & DTLS stack on the receiving application so= that > things keep working. In my port, it is the CoAP library that handles the > sockets, not the DOTS application which would mean having customized code= for > the CoAP library - not ideal for maintenance long term. >=20 > [Jon] My surmise would be that implementors would say "forget this comple= xity > 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 processe= s the > > > > packets > > > > and tracks all the different DTLS connection and have secure messag= e > >=20 > > passing > > > > between the front end dispatcher and the different servers. But thi= s do > > > > requie > > > > another security model and trust relationship between the dispatche= r and > >=20 > > the > > > > servers. > > >=20 > > > [Jon] This does complicate things. The DOTS signal channel requires > > > mutual > > > authentication of the agents and introducing some sort of man-in-midd= le > > > that > > > changes the network flow IP addresses etc. and potentially changes > > > encryption > > > characteristics breaks this mutual authentication. It is not easy to > > > change > > > how the base DOTS signal works. > >=20 > > Sorry, I don't understand why you bring in changes to network flow IP > > address. I > > said secure communication here, and I mean internal to the server softw= are > > between processes. >=20 > [Jon] I latched on to "different servers" as possibly having different ba= ckend > IPs. Here, we actually have a DOTS server (sends responses) and a DOTS c= lient > (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 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 DTLS con= text > to a different, non identical, process along with its socket and then > integrate the received DTLS context into the different application. >=20 > >=20 > > I would note that I think a lot of this dicsussion comes from that the > > implementation you made so far has been done based on the assumption th= at > > there > > would be a new port and separation rather than designing for coloaction= . If > > we > > take the step beyond your current implenentation from a protocol perspe= ctive > > in > > an implementation built for co-location is there really any significant > > issues > > here? >=20 > [Jon] I am the sort of person that needs to implement something to prove > something is practically feasible, find what the issues are and what need= s to > be changed based on a specification and then debate how the spec needs to= be > updated to make it usable. >=20 > [Jon] DOTS call home did come later to the table after the initial DOTS w= as > done which created the DOTS client and DOTS server as different applicati= ons > in the implementations done to date. Adding in the DOTS call home logic = was > very simple (with different port) - simple addition of accepting new > connections on the call home DOTS client which triggered the client logic > start up and initiating connections on the call home DOTS server and > associated configuration logic.=20 >=20 > [Jon] While it is only software and hence not impossible, it is significa= nt > work to merge the client and server into a single application as well as > having to maintain separate applications for running on limited resource > devices. We do not want to put in barriers to implementation of this dra= ft by > making it complex to implement. Hence using a different port for the cli= ent > service and the server service. >=20 > >=20 > >=20 > > Cheers > >=20 > > Magnus Westerlund >=20 >=20 --=-BXSMWlizRCiW6QBxdMpa 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 BAIBBQCgggFBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMTIy MTExMDMxNlowLwYJKoZIhvcNAQkEMSIEIO0qFSHJ7FEN0VJ3HoRHhRFak2hwTKnxzJtCm7baE0YP MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwawYLKoZI hvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEB AQUABIIBAHarHYAyFq5On7Z+RZogpjHeZCxr9zIIps1+ySxxlgubAeLccBNrD0tJ0nAubvGHEQA6 v0gGjZrTaPhLRGopOkqBn1Mz5cx5SAQVYDeMHFKupQ9H94D3uKKgLaPqF1MvpUabeiAZ9FXJYjTZ YnPuxtJKcnajveoFfYvvfjBAUBbVNcDaoKbs7gWOyhi1pyf4neEm8kYFb5xNG9jLxSGzEQkj68xn 1TPN09Ps/9lZN3Ybr4S4LFxzvu+N0uvIHI7DlBPlZCFKuKS6gBrFz/4lQrK4vhHhG+HN7C46s+sA 0FknERMo0RAndlVOShV1bkDgfLUjTpWYYtUrY0+vKH5y4FsAAAAAAAA= --=-BXSMWlizRCiW6QBxdMpa-- From nobody Mon Dec 21 05:03:56 2020 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 392DC3A0FB6; Mon, 21 Dec 2020 05:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 TLZkD6E7O1Jr; Mon, 21 Dec 2020 05:03:52 -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 EF8E03A0FCE; Mon, 21 Dec 2020 05:03:51 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4D005y1Jpkz5vZL; Mon, 21 Dec 2020 14:03:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608555830; bh=4RK391EFUKN5qs+ZnUWa97Zke9SwvvTLBY0g3tm2Nc4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jc+6Pxua/YR2LRc/nq1PXozTXOmI5vstt4KSYN07mHVusd4mWBcVsWNqhjk92F2aD uoKGGLTppWjmnbjoHQmHQRZrrDe6hZB6WbBwRiIu4TvrtG021AFecTuFsMIqVLVi2e 6SMCmW2OPdqnMZMDCu3OM86k6KYHiXs3khLfaJAyYvXvU/kiUcxXAPBf8bZ1REBxOE G40mSWqK1q2G1Un+jryiUkqF7t5thEY7sAQf/WnJumeMgCE9wFWHyhTcI3apBgNoK4 EEvsXuq66sFo6XF7OIxAM/NGnC+LGxtv+dy9Cfd+Oh+/fg8RHPMfdAwPSNiqVC1Bbr Ewr9leuTo8JJA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4D005x6Sn9zDq8H; Mon, 21 Dec 2020 14:03:49 +0100 (CET) From: To: Magnus Westerlund , "iesg@ietf.org" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "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: AQHW1IEMs9vsdNy1dUKXFtQUcezc5qn7Z94AgAAI8ICAABFlgIAACniAgABCigCAAM7vgIABuBMAgAMSigCAAAn2YA== Date: Mon, 21 Dec 2020 13:03:49 +0000 Message-ID: <14908_1608555829_5FE09D35_14908_286_4_787AE7BB302AE849A7480A190F8B9330315A056A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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> In-Reply-To: <6d2f00810b5bc9ec3e8ab10fa7e75b824e0f9003.camel@ericsson.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] 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: Mon, 21 Dec 2020 13:03:54 -0000 SGkgTWFnbnVzLA0KDQpUaGFuayB5b3UgZm9yIHNoYXJpbmcgeW91ciB0aG91Z2h0cy4gDQoNCldl IGNvbnNpZGVyZWQgc2VyaW91c2x5IHRoZSB1c2Ugb2YgYSBkaXN0aW5jdCBwb3J0IHZzLiB1c2lu ZyB0aGUgb25lIHRoYXQgaXMgYWxyZWFkeSBhc3NpZ25lZCB0byBkb3RzLXNpZ25hbC4gV2UgZG9j dW1lbnRlZCB0aGUgcmF0aW9uYWxlIGluIGFuIGFwcGVuZGl4IGFuZCBhbHNvIHByb3ZpZGVkIGEg ZGV0YWlsZWQgYW5zd2VyIHRvIHdoeSB3ZSB0aGluayByZXVzaW5nIHRoZSBleGlzdGluZyBwb3J0 IGlzIG5vdCB0aGF0IHN0cmFpZ2h0Zm9yd2FyZC4gV2UgYWxyZWFkeSBhbnN3ZXJlZCB3aHkgU1JW IHJlY29yZHMgYXJlIG5vdCBzdWZmaWNpZW50LiBQbGVhc2UgcmVmZXIgdG8gdGhlIG1lc3NhZ2Ug d2Ugc2hhcmVkIHdpdGggeW91IGVhcmx5IGluIHRoaXMgdGhyZWFkOiBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL2RvdHMvR1FQLVFDbUMtNFh0SkhQbXNQUl9xdXV5TzBjLyAo KDQpIFdoeSBub3QgdXNpbmcgYSBkeW5hbWljIHBvcnQgbnVtYmVyIGZvbGxvd2luZywgZS5nLiwg ZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci1kaXNjb3Zlcnk/KS4gDQoNCkFsc28sIHdlIGFyZSBmYW1p bGlhciB3aXRoIGV4aXN0aW5nIEJDUHMuIFBsZWFzZSB0cnVzdCBtZSwgaWYgZG90cy1jYWxsLWhv bWUgd2FzIHRoZSBzYW1lIHNlcnZpY2UgYXMgZG90cy1zaWduYWwsIHdlIHdvdWxkbid0IG1ha2Ug dGhlIHJlcXVlc3QuICJET1RTIHNlcnZlciIgYW5kICJET1RTIGNsaWVudCIgYXJlIGRpc3RpbmN0 IGFuZCBmdWxseSBkZWNvdXBsZWQgc2VydmljZXMuIA0KZG90cy1jYWxsLWhvbWUgaXMgYSBkaXN0 aW5jdCBzZXJ2aWNlIHZzIGRvdHMtc2lnbmFsIGluIHRoZSBzYW1lIHdheSBuZXRjb25mL3Jlc3Rj b25mLWNhbGwtaG9tZSBpcyBhIGRpc3RpbmN0IHNlcnZpY2UgdnMgbmV0Y29uZi9yZXN0b2NuZi4g QXMgYSByZW1pbmRlciwgKioqIHRocmVlICgzKSAqKiogYWRkaXRpb25hbCBwb3J0IG51bWJlcnMg d2VyZSBhc3NpZ25lZCBpbiByZmM4MDcxI3NlY3Rpb24tNiBmb3IgdGhlIGNhbGwtaG9tZSBpbiBh ZGRpdGlvbiB0byB0aGUgYWxyZWFkeSBhc3NpZ25lZCAqKiogZm91ciAoNCkgKioqIHBvcnQgbnVt YmVycyBmb3IgTkVUQ09ORi4NCg0KVGhlIHByb3Bvc2FsIHRvIGRlZmluZSBhIChEVExTKSBkaXNw YXRjaGVyIGFuZCB0aGUgaW50ZXJuYWwgbWFjaGluZXJ5IHRvIHN0ZWVyIHRoZSB0cmFmZmljIHRv IGEgc3BlY2lmaWMgc2VydmljZSBpcywgaWYgaXQgd29ya3MsIGEgKiogbmV3IHNlcnZpY2UgKiog cGVyIHNlLCB0aGF0IGl0IGlzIHdvcnRoIHRvIGJlIGFzc2lnbmVkIGEgZGVkaWNhdGVkIHBvcnQg b24gaXQgb3duczogIk9uZSBzZXJ2aWNlLCBvbmUgcG9ydCIuIFlldCwgd2UgZG9uJ3QgaGF2ZSBl dmlkZW5jZSB0aGF0IHNlcnZpY2UgaXMgZmVhc2libGUvd29ya3MuIFdoYXQgd291bGQgYmUgaGVs cGZ1bCBmb3IgdGhlIGNvbW11bml0eSBpbiB0aGUgZnV0dXJlLCBpcyB0aGF0IHRzdiBhcmVhIHBy b3ZpZGVzIGEgc3BlYyBvZiBzdWNoIHNlcnZpY2UgYW5kIGV2aWRlbmNlIHRoYXQgaXQgd29ya3Mg d2l0aG91dCBzaWRlIGVmZmVjdHMuIFdpdGggdGhhdCBzZXJ2aWNlIGRlZmluZWQsIHByb3RvY29s cyBydW5uaW5nIG9uIERUTFMgY2FuIGJlIG11eGVkIG9uIHRoYXQgcG9ydCBudW1iZXIuIE5ldmVy dGhlbGVzcywgd2UgbmVlZCB0byByZW1pbmQgdGhhdCB0aGUgZGlzcGF0Y2hlciBzZXJ2aWNlIG1p Z2h0IGJlIHNpbWlsYXIgaW4gaXRzIGdvYWxzIHRvIFRDUE1VWCwgd2hpY2ggaXMgKioqIG9ic29s ZXRlZCAqKiogZm9yIHJlYXNvbnMgZG9jdW1lbnRlZCBpbiBSRkM3ODA1Lg0KDQpDaGVlcnMsDQpN ZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogTWFnbnVzIFdlc3Rl cmx1bmQgW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IEVudm95w6nC oDogbHVuZGkgMjEgZMOpY2VtYnJlIDIwMjAgMTI6MDMNCj4gw4DCoDogaWVzZ0BpZXRmLm9yZzsg bWFnbnVzLndlc3Rlcmx1bmQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc7DQo+IHN1cGpw cy1pZXRmQGpwc2hhbGxvdy5jb207IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IENjwqA6IHZhbGVyeUBzbXlzbG92Lm5ldDsgZG90 c0BpZXRmLm9yZzsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpZXRmLWRvdHMtc2ln bmFsLWNhbGwtaG9tZUBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW0RvdHNdIE1hZ251cyBXZXN0 ZXJsdW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtDQo+IHNpZ25hbC1jYWxsLWhvbWUt MTE6ICh3aXRoIERJU0NVU1MpDQo+IA0KPiBIaSwNCj4gDQo+IEkgd2lsbCBzdGFydCBteSBDaHJp c3RtYXMgdmFjYXRpb24gdG9tb3Jyb3csIHNvIGRvbid0IGV4cGVjdCBhbnkNCj4gbW9yZSByZXNw b25zZXMNCj4gdW50aWwgYWZ0ZXIgdGhlIDd0aCBvZiBEZWNlbWJlci4NCj4gDQo+IEkgYW0gaGVh cmluZyB3aGF0IHlvdSBhcmUgc2F5aW5nIGFib3V0IGltcGxlbWVudGFiaWxpdHkuIEhvd2V2ZXIs IEkNCj4gaGF2ZSB0aGUNCj4gZmVlbGluZyB0aGF0IHRoZSBXRyBkZXNpZ24gcHJvY2VzcyBoYXZl IGZhaWxlZCB0byB0YWtlIGludG8gYWNjb3VudA0KPiBzb21lDQo+IHJlbGV2YW50IGFzcGVjdHMg aGVyZS4NCj4gDQo+IDEuIFlvdSBhcmUgdXNpbmcgQ09BUCB3aGljaCBkbyBzaGFyZSBoaWdoIGxl dmVsIHNlbWFudGljcyB3aXRoIEhUVFAuDQo+IFRodXMsDQo+IGRpZmZlcmVudCBmdW5jdGlvbmFs aXRlcyBjYW4gZWFzaWx5IGJlIGRlZmluZWQgdG8gd29yayBpbiBwYXJhbGxlbA0KPiBvbiBhIHNl cnZlci4NCj4gVGh1cyBpdCBjb3VsZCBoYXZlIGJlZW4gZWFzeSB0byBlbnN1cmUgdGhhdCBpbmRp dmlkdWFsIG9yIGNvbG9hdGVkDQo+IGRvdHMtc2lnbmFsDQo+IGFuZCBkb3RzLWNhbGwtaG9tZSBj b3VsZCBiZSBjby1sb2NhdGUuIEVzcGVjaWFsbHkgYXMgeW91IGRvIGhhdmUgaXQNCj4gcGFydCBv ZiB3aGF0DQo+IGlzIGNvbnNpZGVyZWQuDQo+IA0KPiAyLiBZb3UgZ290IGEgcG9ydCBmb3IgZG90 cy1zaWduYWwgdG8gZW5hYmxlIGZpcmV3YWxscyBhbmQgcm91dGVycw0KPiBldGMgdG8NCj4gaWRl bnRpZnkgYW5kIGhhbmRsZSB0aGlzIHRyYWZmaWMsIG90aGVyd2lzZSBJIHRoaW5rIGRvdHMtc2ln bmFsDQo+IHdvdWxkIGhhdmUgYmVlbg0KPiBsZWFuZWQgaGFyZCBvbiB1c2luZyB0aGUgZGVmYXVs dCBDT0FQIHBvcnQuIEV4cGVjdGluZyB0byBjb25zdW1lDQo+IGFub3RoZXIgcG9ydA0KPiBqdXN0 IGJlY2F1c2UgeW91IGRpZG4ndCBjb25zaWRlciB0aGUgY29uc3RyYWludHMsIHdoaWNoIFJGQzYz MzUgaXMNCj4gY2xlYXIgd2l0aCBJDQo+IHRoaW5rIGlzIHRvdWdoIGZvciBtZSB0byBzd2FsbG93 Lg0KPiANCj4gMy4gWW91IGhhdmUgc2V2ZXJhbCB3YXlzIG9mIGRlc2lnbmluZyB5b3Vyc2VsZiBv dXQgb2YgdGhlc2UgaXNzdWVzDQo+IHRoYXQgaGFzIGJlZW4NCj4gcmFpc2VkLiBJIHVuZGVyc3Rh bmQgdGhpcyBtaWdodCBiZSBjb25zaWRlcmVkIGEgbGF0ZSBzdXJwcmlzZSwgYnV0DQo+IGl0IHNo b3VsZG4ndA0KPiBpZiB5b3UgaGFkIHJlYWQgdGhlIGluIGZvcmNlIEJDUC4NCj4gDQo+IE15IG5l eHQgcXVlc3Rpb24sIGRvIHlvdSBhY3R1YWxseSBuZWVkIGEgZml4ZWQgcG9ydCBhdCBhbGwgZm9y IHRoaXMuDQo+IFRoZSBzZXJ2aWNlDQo+IG5hbWUgZW5hYmxlcyB5b3UgdG8gZG8gU1JWIGxvb2sg dXBzIHRvIGZpbmQgcG9ydCBhbmQgSVAgYWRkcmVzcyBmb3INCj4gdGhlIHNlcnZpY2UuDQo+IElz bid0IHRoYXQgc3VmZmljaWVudCBpZiB5b3Ugc3RpbGwgd2FudCB0byBydW4gaXQgb24gZGVkaWNh dGVkIHBvcnQNCj4gY29tcGFyZWQgdG8NCj4gRE9UUy1zaWduYWw/DQo+IA0KPiBDaGVlcnMNCj4g DQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiANCj4gDQo+IE9uIFNhdCwgMjAyMC0xMi0xOSBh dCAxMjowOCArMDAwMCwgc3VwanBzLWlldGZAanBzaGFsbG93LmNvbSB3cm90ZToNCj4gPiBIaSBN YWdudXMsDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4g Pg0KPiA+IEpvbg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g RnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb21dDQo+ID4gPiBTZW50OiAxOCBEZWNlbWJlciAyMDIwIDA5OjUzDQo+ID4gPiBUbzogaWVz Z0BpZXRmLm9yZzsNCj4gbWFnbnVzLndlc3Rlcmx1bmQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmc7IHN1cGpwcy0NCj4gPiA+IGlldGZAanBzaGFsbG93LmNvbTsgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbQ0KPiA+ID4gQ2M6IHZhbGVyeUBzbXlzbG92Lm5ldDsgZG90c0BpZXRmLm9y ZzsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtDQo+ID4gPiBkb3RzLQ0KPiA+ ID4gc2lnbmFsLWNhbGwtaG9tZUBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtEb3RzXSBN YWdudXMgV2VzdGVybHVuZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi0NCj4gZG90cy1zaWduYWwt DQo+ID4gPiBjYWxsLQ0KPiA+ID4gaG9tZS0xMTogKHdpdGggRElTQ1VTUykNCj4gPiA+DQo+ID4N Cj4gPiAuLi4NCj4gPiA+ID4gPiBTbyBJIHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIHBvc3NpYmxl IGltcGxlbWVudGF0aW9uIHBhdGhzDQo+IGZvciB0aGlzLiBJDQo+ID4gPiA+ID4gc2VlDQo+ID4g PiA+ID4gYXQgbGVhc3QNCj4gPiA+ID4gPiB0d28uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBGaXJz dCwgZG8gYSA1LXR1cGxlIGNvbm5lY3Qgb24gVURQIHRvIGZpbHRlciB0aGF0IHBhcnRpY3VsYXIN Cj4gVURQIGZsb3csDQo+ID4gPiA+ID4gcHJvY2VzcyB0aGUNCj4gPiA+ID4gPiBEVExTIGhhbmRz aGFrZSBmb3IgdGhpcyBzb2NrZXQgYW5kIHRoZW4gYmFzZWQgb24gQUxQTiBkZWNpZGUNCj4gb24g dGFyZ2V0DQo+ID4gPiA+ID4gcHJvY2VzcyBhbmQgdGhlbiBoYW5kIG92ZXIgdGhlIHNvY2tldCBh bmQgdGhlIERUTFMgc3RhdGUgdG8NCj4gdGhlIHJpZ2h0DQo+ID4gPiA+ID4gcHJvY2Vzcy4NCj4g PiA+ID4NCj4gPiA+ID4gW0pvbl0gVURQIGhhcyBubyBjb25jZXB0IG9mIGFjY2VwdCgpLiAgSWYg eW91IGRvIGEgY29ubmVjdCgpDQo+IG9uIGEgc29ja2V0DQo+ID4gPiA+IHRoYXQNCj4gPiA+ID4g eW91IGhhdmUganVzdCByZWNlaXZlZCBkYXRhIG9uLCB0aGVuIHRoYXQgdXBkYXRlcyB0aGUgNSB0 dXBsZQ0KPiBhbmQgdGhlbg0KPiA+ID4gPiBvbmx5DQo+ID4gPiA+IHJlY2VpdmVzIHRyYWZmaWMg bWF0Y2hpbmcgdGhlIHR1cGxlIGFzIGV4cGVjdGVkLiBIb3dldmVyLCBpdA0KPiBhcHBlYXJzIG5v dA0KPiA+ID4gPiBwb3NzaWJsZSB0byBsZWF2ZSB0aGUgb3JpZ2luYWwgc29ja2V0IHJlYWR5IGZv ciB0aGUgbmV4dA0KPiBwYWNrZXQgKGZyb20NCj4gPiA+ID4gZGlmZmVyZW50IElQIGV0Yy4pIGFu ZCBzZXQgdXAgYSBuZXcgc29ja2V0IHRvIHNwZWNpZmljYWxseQ0KPiBoYW5kbGUgdGhlDQo+ID4g PiA+IHN0cmVhbQ0KPiA+ID4gPiBtYXRjaGluZyB0aGUgcGFja2V0IGp1c3QgcmVjZWl2ZWQsIGJp bmQoc2FtZV9wb3J0KSwgZG8gdGhlDQo+IGNvbm5lY3QoKSBvbiBpdA0KPiA+ID4gPiBldGMuICh0 aGUgYmluZChzYW1lX3BvcnQpZmFpbHMgaW4gbXkgdGVzdCkuDQo+ID4gPg0KPiA+ID4gU28gSSBk b24ndCBoYXZlIGEgY29kZSBleG1hbXBsZSBmb3IgdGhpcyBhdmFpbGFibGUsIGJ1dCBJDQo+IHRo b3VnaHQgeW91IGNhbg0KPiA+ID4gbWFrZQ0KPiA+ID4gaXQgd29yayB3aXRoIHNvX3JldXNlcG9y dC9zb19yZXVzZWFkZHIuIFRoZXJlIGFyZSBzb21lIGRvd25zaWRlDQo+IGluIHRoYXQgdGhlDQo+ ID4gPiBuZXcNCj4gPiA+IHNvY2tldCBjYW4gcmVjZWl2ZSBwYWNrZXRzIHByaW9yIHRvIHRoZSBj b25uZWN0IHRoYXQganVzdA0KPiBhcnJpdmUuDQo+ID4gPg0KPiA+DQo+ID4gW0pvbl0gSSB3YXMg dXNpbmcgU09fUkVVU0VBRERSLCBidXQgaGF2ZSBmb3VuZCBhIGJ1ZyBpbiBteSB0ZXN0DQo+IGNv ZGUgc28gSSBub3cNCj4gPiBhYmxlIHRvIGJpbmQoc2FtZV9wb3J0KS4gIFdoaWxlIGEgbmV3IHNv Y2tldCBhbmQgY29ubmVjdCgpIGNhbiBiZQ0KPiBkb25lIHRvDQo+ID4gbWF0Y2ggYSBuZXcgVURQ IGNsaWVudCwgaXQgbmVlZHMgdG8gYmUgdGhvdWdodCB0aHJvdWdoIHdoZW4gdGhpcw0KPiBpcyBk b25lIC0gdGhlDQo+ID4gYXJyaXZhbCBvZiB0aGUgZmlyc3QgVURQIHBhY2tldCwgd2hlbiB0aGUg RFRMUyBBUExOIGlzIGtub3duLCBvcg0KPiB3aGVuIHRoZSBEVExTDQo+ID4gaGFuZHNoYWtlIGlz IGNvbXBsZXRlLiAgVGhlIERPVFMgc3RhY2sgd2UgaGF2ZSBpcw0KPiA+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4NzgyI3NlY3Rpb24tMyBGaWd1cmUgMw0KPiA+DQo+ID4gRE9UUw0K PiA+IENvQVANCj4gPiBEVExTDQo+ID4gVURQDQo+ID4gSVANCj4gPg0KPiA+IFtKb25dIEl0IGlz IHVuY2xlYXIgdG8gbWUgYXMgdG8gaG93IHlvdSBjYW4gaGFuZCBvZmYgYSBEVExTDQo+IGNvbnRl eHQgdG8gYQ0KPiA+IGRpZmZlcmVudCwgbm9uIGlkZW50aWNhbCBwcm9jZXNzIGFsb25nIHdpdGgg aXRzIHNvY2tldCAodGhpcyBtYXkNCj4gYmUgcG9zc2libGUNCj4gPiB3aXRoIE9wZW5TU0wsIG5v dCBzdXJlIGFib3V0IG90aGVyIFRMUyBsaWJyYXJpZXMgLSB0aGVyZSBpcw0KPiBsaW1pdGVkIGtl cm5lbA0KPiA+IEFGX0tUTFMgc3VwcG9ydCB3aGljaCBtYXkgaGVscCkuICBEVExTIHNlc3Npb24g cmVzdW1wdGlvbiB0aGVuDQo+IGFsc28gZ2V0cyBhIGxvdA0KPiA+IG1vcmUgY29tcGxpY2F0ZWQu DQo+ID4NCj4gPiBbSm9uXSBUaGVuIHRoZXJlIGlzIHRoZSBjaGFsbGVuZ2Ugb2YgaG93IHRoZSBy ZWNlaXZlZCBEVExTIGNvbnRleHQNCj4gKyBzb2NrZXQNCj4gPiBhcmUgaW50ZWdyYXRlZCBpbnRv IHRoZSBDb0FQICYgRFRMUyBzdGFjayBvbiB0aGUgcmVjZWl2aW5nDQo+IGFwcGxpY2F0aW9uIHNv IHRoYXQNCj4gPiB0aGluZ3Mga2VlcCB3b3JraW5nLiAgSW4gbXkgcG9ydCwgaXQgaXMgdGhlIENv QVAgbGlicmFyeSB0aGF0DQo+IGhhbmRsZXMgdGhlDQo+ID4gc29ja2V0cywgbm90IHRoZSBET1RT IGFwcGxpY2F0aW9uIHdoaWNoIHdvdWxkIG1lYW4gaGF2aW5nDQo+IGN1c3RvbWl6ZWQgY29kZSBm b3INCj4gPiB0aGUgQ29BUCBsaWJyYXJ5IC0gbm90IGlkZWFsIGZvciBtYWludGVuYW5jZSBsb25n IHRlcm0uDQo+ID4NCj4gPiBbSm9uXSBNeSBzdXJtaXNlIHdvdWxkIGJlIHRoYXQgaW1wbGVtZW50 b3JzIHdvdWxkIHNheSAiZm9yZ2V0IHRoaXMNCj4gY29tcGxleGl0eQ0KPiA+IHdpdGggaXRzIGlu aGVyZW50IHJpc2tzIGFuZCBqdXN0IHVzZSBhIG5vbi1zdGFuZGFyZCBwb3J0Ig0KPiA+DQo+ID4g PiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTZWNvbmRseSwgaXMgdG8gcnVuIHNvbWUgdHlwZSBv ZiBmcm9udCBlbmQgZGlzcGF0Y2hlciB0aGF0DQo+IHByb2Nlc3NlcyB0aGUNCj4gPiA+ID4gPiBw YWNrZXRzDQo+ID4gPiA+ID4gYW5kIHRyYWNrcyBhbGwgdGhlIGRpZmZlcmVudCBEVExTIGNvbm5l Y3Rpb24gYW5kIGhhdmUgc2VjdXJlDQo+IG1lc3NhZ2UNCj4gPiA+DQo+ID4gPiBwYXNzaW5nDQo+ ID4gPiA+ID4gYmV0d2VlbiB0aGUgZnJvbnQgZW5kIGRpc3BhdGNoZXIgYW5kIHRoZSBkaWZmZXJl bnQgc2VydmVycy4NCj4gQnV0IHRoaXMgZG8NCj4gPiA+ID4gPiByZXF1aWUNCj4gPiA+ID4gPiBh bm90aGVyIHNlY3VyaXR5IG1vZGVsIGFuZCB0cnVzdCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUN Cj4gZGlzcGF0Y2hlciBhbmQNCj4gPiA+DQo+ID4gPiB0aGUNCj4gPiA+ID4gPiBzZXJ2ZXJzLg0K PiA+ID4gPg0KPiA+ID4gPiBbSm9uXSBUaGlzIGRvZXMgY29tcGxpY2F0ZSB0aGluZ3MuICBUaGUg RE9UUyBzaWduYWwgY2hhbm5lbA0KPiByZXF1aXJlcw0KPiA+ID4gPiBtdXR1YWwNCj4gPiA+ID4g YXV0aGVudGljYXRpb24gb2YgdGhlIGFnZW50cyBhbmQgaW50cm9kdWNpbmcgc29tZSBzb3J0IG9m IG1hbi0NCj4gaW4tbWlkZGxlDQo+ID4gPiA+IHRoYXQNCj4gPiA+ID4gY2hhbmdlcyB0aGUgbmV0 d29yayBmbG93IElQIGFkZHJlc3NlcyBldGMuIGFuZCBwb3RlbnRpYWxseQ0KPiBjaGFuZ2VzDQo+ ID4gPiA+IGVuY3J5cHRpb24NCj4gPiA+ID4gY2hhcmFjdGVyaXN0aWNzIGJyZWFrcyB0aGlzIG11 dHVhbCBhdXRoZW50aWNhdGlvbi4gIEl0IGlzIG5vdA0KPiBlYXN5IHRvDQo+ID4gPiA+IGNoYW5n ZQ0KPiA+ID4gPiBob3cgdGhlIGJhc2UgRE9UUyBzaWduYWwgd29ya3MuDQo+ID4gPg0KPiA+ID4g U29ycnksIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgeW91IGJyaW5nIGluIGNoYW5nZXMgdG8gbmV0 d29yaw0KPiBmbG93IElQDQo+ID4gPiBhZGRyZXNzLiBJDQo+ID4gPiBzYWlkIHNlY3VyZSBjb21t dW5pY2F0aW9uIGhlcmUsIGFuZCBJIG1lYW4gaW50ZXJuYWwgdG8gdGhlDQo+IHNlcnZlciBzb2Z0 d2FyZQ0KPiA+ID4gYmV0d2VlbiBwcm9jZXNzZXMuDQo+ID4NCj4gPiBbSm9uXSBJIGxhdGNoZWQg b24gdG8gImRpZmZlcmVudCBzZXJ2ZXJzIiBhcyBwb3NzaWJseSBoYXZpbmcNCj4gZGlmZmVyZW50 IGJhY2tlbmQNCj4gPiBJUHMuICBIZXJlLCB3ZSBhY3R1YWxseSBoYXZlIGEgRE9UUyBzZXJ2ZXIg KHNlbmRzIHJlc3BvbnNlcykgYW5kIGENCj4gRE9UUyBjbGllbnQNCj4gPiAoZ2VuZXJhdGVzIHJl cXVlc3RzKSB0aGF0IHRyYWZmaWMgbmVlZHMgdG8gYmUgc3RlZXJlZCB0by4NCj4gPg0KPiA+ID4g QmFzaWMgaW50ZXJwcm9jZXNzIGNvbW11bmljYXRpb24gaGVyZS4gQWxzbywgaXQgbWlnaHQgYmUN Cj4gPiA+IHRoYXQNCj4gPiA+IHlvdSBjYW4gc3RhcnQgdGhlIERUTFMgcHJvY2Vzc2luZyBpbiB0 aGUgZGlzcGF0Y2hlciBhbmQgdGhlbg0KPiBoYW5kIG92ZXIgdGhlDQo+ID4gPiBEVExTDQo+ID4g PiBzdGF0ZSBhbmQgb25seSBoYXZlIGVuY3J5cHRlZCBVRFAgcGF5bG9hZHMgYmVpbmcgZGlzcGF0 YWNoZWQuDQo+ID4NCj4gPiBbSm9uXSBBcyBhYm92ZSwgaXQgaXMgdW5jbGVhciB0byBtZSBhcyB0 byBob3cgeW91IGNhbiBoYW5kIG9mZiBhDQo+IERUTFMgY29udGV4dA0KPiA+IHRvIGEgZGlmZmVy ZW50LCBub24gaWRlbnRpY2FsLCBwcm9jZXNzIGFsb25nIHdpdGggaXRzIHNvY2tldCBhbmQNCj4g dGhlbg0KPiA+IGludGVncmF0ZSB0aGUgcmVjZWl2ZWQgRFRMUyBjb250ZXh0IGludG8gdGhlIGRp ZmZlcmVudA0KPiBhcHBsaWNhdGlvbi4NCj4gPg0KPiA+ID4NCj4gPiA+IEkgd291bGQgbm90ZSB0 aGF0IEkgdGhpbmsgYSBsb3Qgb2YgdGhpcyBkaWNzdXNzaW9uIGNvbWVzIGZyb20NCj4gdGhhdCB0 aGUNCj4gPiA+IGltcGxlbWVudGF0aW9uIHlvdSBtYWRlIHNvIGZhciBoYXMgYmVlbiBkb25lIGJh c2VkIG9uIHRoZQ0KPiBhc3N1bXB0aW9uIHRoYXQNCj4gPiA+IHRoZXJlDQo+ID4gPiB3b3VsZCBi ZSBhIG5ldyBwb3J0IGFuZCBzZXBhcmF0aW9uIHJhdGhlciB0aGFuIGRlc2lnbmluZyBmb3INCj4g Y29sb2FjdGlvbi4gSWYNCj4gPiA+IHdlDQo+ID4gPiB0YWtlIHRoZSBzdGVwIGJleW9uZCB5b3Vy IGN1cnJlbnQgaW1wbGVuZW50YXRpb24gZnJvbSBhIHByb3RvY29sDQo+IHBlcnNwZWN0aXZlDQo+ ID4gPiBpbg0KPiA+ID4gYW4gaW1wbGVtZW50YXRpb24gYnVpbHQgZm9yIGNvLWxvY2F0aW9uIGlz IHRoZXJlIHJlYWxseSBhbnkNCj4gc2lnbmlmaWNhbnQNCj4gPiA+IGlzc3Vlcw0KPiA+ID4gaGVy ZT8NCj4gPg0KPiA+IFtKb25dIEkgYW0gdGhlIHNvcnQgb2YgcGVyc29uIHRoYXQgbmVlZHMgdG8g aW1wbGVtZW50IHNvbWV0aGluZyB0bw0KPiBwcm92ZQ0KPiA+IHNvbWV0aGluZyBpcyBwcmFjdGlj YWxseSBmZWFzaWJsZSwgZmluZCB3aGF0IHRoZSBpc3N1ZXMgYXJlIGFuZA0KPiB3aGF0IG5lZWRz IHRvDQo+ID4gYmUgY2hhbmdlZCBiYXNlZCBvbiBhIHNwZWNpZmljYXRpb24gYW5kIHRoZW4gZGVi YXRlIGhvdyB0aGUgc3BlYw0KPiBuZWVkcyB0byBiZQ0KPiA+IHVwZGF0ZWQgdG8gbWFrZSBpdCB1 c2FibGUuDQo+ID4NCj4gPiBbSm9uXSBET1RTIGNhbGwgaG9tZSBkaWQgY29tZSBsYXRlciB0byB0 aGUgdGFibGUgYWZ0ZXIgdGhlIGluaXRpYWwNCj4gRE9UUyB3YXMNCj4gPiBkb25lIHdoaWNoIGNy ZWF0ZWQgdGhlIERPVFMgY2xpZW50IGFuZCBET1RTIHNlcnZlciBhcyBkaWZmZXJlbnQNCj4gYXBw bGljYXRpb25zDQo+ID4gaW4gdGhlIGltcGxlbWVudGF0aW9ucyBkb25lIHRvIGRhdGUuICBBZGRp bmcgaW4gdGhlIERPVFMgY2FsbCBob21lDQo+IGxvZ2ljIHdhcw0KPiA+IHZlcnkgc2ltcGxlICh3 aXRoIGRpZmZlcmVudCBwb3J0KSAtIHNpbXBsZSBhZGRpdGlvbiBvZiBhY2NlcHRpbmcNCj4gbmV3 DQo+ID4gY29ubmVjdGlvbnMgb24gdGhlIGNhbGwgaG9tZSBET1RTIGNsaWVudCB3aGljaCB0cmln Z2VyZWQgdGhlDQo+IGNsaWVudCBsb2dpYw0KPiA+IHN0YXJ0IHVwIGFuZCBpbml0aWF0aW5nIGNv bm5lY3Rpb25zIG9uIHRoZSBjYWxsIGhvbWUgRE9UUyBzZXJ2ZXINCj4gYW5kDQo+ID4gYXNzb2Np YXRlZCBjb25maWd1cmF0aW9uIGxvZ2ljLg0KPiA+DQo+ID4gW0pvbl0gV2hpbGUgaXQgaXMgb25s eSBzb2Z0d2FyZSBhbmQgaGVuY2Ugbm90IGltcG9zc2libGUsIGl0IGlzDQo+IHNpZ25pZmljYW50 DQo+ID4gd29yayB0byBtZXJnZSB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgaW50byBhIHNpbmdsZSBh cHBsaWNhdGlvbiBhcw0KPiB3ZWxsIGFzDQo+ID4gaGF2aW5nIHRvIG1haW50YWluIHNlcGFyYXRl IGFwcGxpY2F0aW9ucyBmb3IgcnVubmluZyBvbiBsaW1pdGVkDQo+IHJlc291cmNlDQo+ID4gZGV2 aWNlcy4gIFdlIGRvIG5vdCB3YW50IHRvIHB1dCBpbiBiYXJyaWVycyB0byBpbXBsZW1lbnRhdGlv biBvZg0KPiB0aGlzIGRyYWZ0IGJ5DQo+ID4gbWFraW5nIGl0IGNvbXBsZXggdG8gaW1wbGVtZW50 LiAgSGVuY2UgdXNpbmcgYSBkaWZmZXJlbnQgcG9ydCBmb3INCj4gdGhlIGNsaWVudA0KPiA+IHNl cnZpY2UgYW5kIHRoZSBzZXJ2ZXIgc2VydmljZS4NCj4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBD aGVlcnMNCj4gPiA+DQo+ID4gPiBNYWdudXMgV2VzdGVybHVuZA0KPiA+DQo+ID4NCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu ClRoYW5rIHlvdS4KCg== From nobody Tue Dec 22 10:01:32 2020 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 352343A11D6; Tue, 22 Dec 2020 10:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 e8BuP8olZOsP; Tue, 22 Dec 2020 10:01:29 -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 17B293A11D5; Tue, 22 Dec 2020 10:01:29 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4D0kfv4gTkzFqMB; Tue, 22 Dec 2020 19:01:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608660087; bh=zmp05u9SivFw0GjfNhWAxGUfkOvEYio/AXuOtHrfSJU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bwdVuyyXun+Ane5mg1RKLI1jr2YgA3sw7oXSiS/+yXjNhF3P0THzgbHO8WyS5XsAF T6KtpIvCfOFYSFFozhA4g2yfqUWe4JhXPXas39Q+ozU552wySS4+zdanNvBlssYnnf v07VhcaS3p13esPM/0tk9Fdm6Q1YBF28V7+WM10zUrMhj5WQC/j5x/F8IwY6m4bs1k 1q/C4LcGr2IuBpZiQGwwrDcebdKfV1WyEXUJk+aQjoxHmgBRziECzGpvincpZLzdEH QDI4CJDknYaqMAxbufLZ82TUeTjQlDQyMAdJgOhr2aQ5secYc9kSVj1Mrv2mtEujQg EZUouELNJoIJw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4D0kfv3jQfz3wbM; Tue, 22 Dec 2020 19:01:27 +0100 (CET) From: To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" CC: "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQHW13C+BUBsnnzenkGee3873+vLMqoDaUOg Date: Tue, 22 Dec 2020 18:01:26 +0000 Message-ID: <12182_1608660087_5FE23477_12182_65_1_787AE7BB302AE849A7480A190F8B9330315A119C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> 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] 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, 22 Dec 2020 18:01:31 -0000 SGkgTWFyY28sIA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KDQpBbGwgZ29vZCBw b2ludHMuIFdlIHJlbGVhc2VkIGEgbmV3IHZlcnNpb24gdGhhdCBhZGRyZXNzZXMgdGhvc2UuIEEg ZGlmZiB0byB0cmFjayB0aGUgY2hhbmdlcyBjYW4gYmUgc2VlbiBhdDogDQpodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0wMw0KDQpDaGVl cnMsDQpKb24gJiBNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDog Y29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJjbyBU aWxvY2ENCj4gRW52b3nDqcKgOiBsdW5kaSAyMSBkw6ljZW1icmUgMjAyMCAwOToxMA0KPiDDgMKg OiBjb3JlQGlldGYub3JnIFdHIChjb3JlQGlldGYub3JnKSA8Y29yZUBpZXRmLm9yZz4NCj4gQ2PC oDogZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW2NvcmVdIFdHIExhc3QgQ2FsbCBvbiBk cmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBQbGVhc2UsIHNl ZSBiZWxvdyBzb21lIGNvbW1lbnRzIGZvciB0aGlzIFdHTEMuDQo+IA0KPiBCZXN0LA0KPiAvTWFy Y28NCj4gDQo+IA0KPiBbR2VuZXJhbF0NCj4gDQo+ICogcy9Db0FQIGVuZHBvaW50IHNlbmRlci9D b0FQIHNlbmRlciBlbmRwb2ludA0KPiANCj4gKiBQbGVhc2UsIHJlcGxhY2UgdGhlIHJlZmVyZW5j ZXMgdG8gUkZDIDcwNDkgd2l0aCByZWZlcmVuY2VzIHRvIFJGQw0KPiA4OTQ5Lg0KPiANCj4gKiBU aGVyZSBhcmUgc2l4IGluc3RhbmNlcyBvZiAiQ29BUCBzZXNzaW9uIiwgd2hpY2ggaXMgbm90IGRl ZmluZWQgaW4NCj4gUkZDDQo+IDcyNTIgb3IgUkZDIDc5NTkuIERvIHlvdSBzaW1wbHkgbWVhbiAi YmxvY2std2lzZSB0cmFuc2ZlciIgPw0KPiANCj4gDQo+IFtTZWN0aW9uIDFdDQo+IA0KPiAqIEkg dGhpbmsgdGhhdCB0aGUgaGVhZGluZyBvZiB0aGUgY3VycmVudCBTZWN0aW9uIDEuMSBjYW4gYmUN Cj4gcmVtb3ZlZCwgc28gdGhhdCBTZWN0aW9uIDEgc3RhcnRzIHNpbXBseSB3aXRoICJUaGUgQ29u c3RyYWluZWQNCj4gQXBwbGljYXRpb24gUHJvdG9jb2wgLi4uIg0KPiANCj4gKiBzL2FuZCBmdXJ0 aGVyIHVwZGF0ZWQvYW5kIHdhcyBmdXJ0aGVyIHVwZGF0ZWQNCj4gDQo+ICogcy9sb3NzOyB3aGlj aC9sb3NzLCB3aGljaA0KPiANCj4gKiBzL2luZm9ybXMgdGhlIENvQVAgZW5kcG9pbnQgc2VuZGVy IGVpdGhlciBzdWNjZXNzZnVsIHJlY2VpcHQNCj4gb3IvZWl0aGVyIGluZm9ybXMgdGhlIENvQVAg c2VuZGVyIGVuZHBvaW50IG9mIGEgc3VjY2Vzc2Z1bCByZWNlaXB0DQo+IG9yDQo+IA0KPiAqIHMv dGhhdCBoYXZlIGJlZW4gbm90IHlldCBiZWVuIHJlY2VpdmVkL3RoYXQgaGF2ZSBub3QgeWV0IGJl ZW4NCj4gcmVjZWl2ZWQNCj4gDQo+ICogcy93aWxsIGJvdGggZ2VuZXJhbGx5L3dpbGwgYm90aCBi ZSBnZW5lcmFsbHkNCj4gDQo+ICogVGhlIGxhc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24gMS40IGNh biBiZSBleHBhbmRlZCB0byBtZW50aW9uDQo+IE9TQ09SRSBhcyBhbiBhbHRlcm5hdGl2ZSB3aGVu IERUTFMgaXMgbm90IHVzZWQuDQo+IA0KPiANCj4gW1NlY3Rpb24gMy40XQ0KPiANCj4gKiBBcyB0 byAiSWYgdGhlIHNlcnZlciByZWNlaXZlcyBtdWx0aXBsZSByZXF1ZXN0cyAoaW1wbGllZCBvcg0K PiBvdGhlcndpc2UpIGZvciB0aGUgc2FtZSBibG9jayAuLi4iICwgSSBndWVzcyB0aGUgd29yZCAi cmVxdWVzdHMiDQo+IGRvZXMgbm90IG1lYW4gQ29BUCByZXF1ZXN0cywgc2luY2UgdGhlIHBhcmFn cmFwaCBpcyB0YWxraW5nIGFib3V0IGENCj4gc2luZ2xlIGFjdHVhbCBDb0FQIHJlcXVlc3QuIElu IGZhY3QsIGl0IHNlZW1zIHRvIHJlZmVyIHRvIHRoZQ0KPiBtdWx0aXBsZSBuZWVkZWQgYmxvY2tz IGluZGljYXRlZCBieSB0aGUgbXVsdGlwbGUgUS1CbG9jazIgb3B0aW9ucyBpbg0KPiBhIHNhbWUg Q29BUCByZXF1ZXN0Lg0KPiANCj4gwqDCoCBJZiBJJ20gaW50ZXJwcmV0aW5nIGNvcnJlY3RseSwg dGhpcyB0cmllcyB0byBjb3ZlciBhIHN0cmFuZ2UNCj4gYmVoYXZpb3IgZnJvbSB0aGUgY2xpZW50 IHRoYXQgc2VuZHMgbXVsdGlwbGUgUS1CbG9jazIgT3B0aW9ucyBpbiBhDQo+IHNhbWUgQ29BUCBy ZXF1ZXN0cyB3aXRoIHRoZSBNIGJpdCBzZXQsIHN1Y2ggYXM6IDIvMS8xMDI0ICwgMy8xLzEwMjQs DQo+IDQvMS8xMDI0OyBidXQgc3RpbGwgdGhlIHNlcnZlciBoYXMgdG8gc2VuZCBiYWNrIGJsb2Nr cyAyLCAzLCA0IC4uLg0KPiB1bnRpbCB0aGUgbGFzdCBvbmUgb25seSBvbmNlIGVhY2guDQo+IA0K PiDCoMKgIElmIHRoaXMgaXMgY29ycmVjdCwgaG93IGFib3V0IHRoZSBmb2xsb3dpbmcgcmVwaHJh c2luZz8NCj4gDQo+IMKgwqAgIklmIHRoZSByZXF1ZXN0IGluY2x1ZGVzIG11bHRpcGxlIFEtQmxv Y2syIE9wdGlvbnMgYW5kIGFza3MgZm9yIGENCj4gc2FtZSBibG9jayBtdWx0aXBsZSB0aW1lcyAo ZS5nLiwgdGhyb3VnaCB0aGUgTSBiaXQgc2V0KSwgdGhlIHNlcnZlcg0KPiBNVVNUIG9ubHkgc2Vu ZCBiYWNrIG9uZSBpbnN0YW5jZSBvZiB0aGF0IGJsb2NrLg0KPiANCj4gKiBzL2lmIHRoaXMgaXMg dGhlIGNhc2UvaWYgdGhpcyBpcyBub3QgdGhlIGNhc2UNCj4gDQo+ICogcy9PcHRpb24gd2hpY2hl dmVyIGlzL09wdGlvbiwgd2hpY2hldmVyIGlzDQo+IA0KPiANCj4gW1NlY3Rpb24gMy43XQ0KPiAN Cj4gKiBzL2FuZCBNVVNUIGhhdmUgdGhlIHNhbWUgdmFsdWUvYW5kIE1VU1QgcHJlc2VydmUgdGhl IHNhbWUgdmFsdWUgaW4NCj4gZWFjaCBvZiB0aG9zZSBwYXlsb2Fkcy4NCj4gDQo+IChqdXN0IHRv IGF2b2lkIHJlYWRpbmcgaXQgYXMgU2l6ZTEgYW5kIFNpemUyIG11c3QgaGF2ZSB0aGUgc2FtZQ0K PiB2YWx1ZSkNCj4gDQo+IA0KPiBbU2VjdGlvbiA5XQ0KPiANCj4gKiBJIHN1Z2dlc3QgdG8gYWRk IG9uZSBtb3JlIGV4YW1wbGUgaW4gdGhlIGVuZCwgd2hlcmUgUS1CbG9jazIgaXMNCj4gdXNlZCBp biBhIHJlcXVlc3Qgd2l0aCB0aGUgTSBiaXQgc2V0LiBBcyBhIHNlcGFyYXRlIGNvbnRpbnVhdGlv biBvZg0KPiB0aGUgZXhhbXBsZSBpbiBGaWd1cmUgNywgdGhpcyBjYW4gYmUgdGhlIGNhc2Ugd2hl cmUsIGFmdGVyIG9ic2VydmUNCj4gYmVpbmcgdHJpZ2dlcmVkIG9uZSBtb3JlIHRpbWUsIG9ubHkg dGhlIGZpcnN0IGJsb2NrIGZvciBhIG5ldyBFVD0yNA0KPiByZWFjaGVzIHRoZSBjbGllbnQsIHdo aWNoIGNhbiB1c2UgYSBzaW5nbGUgUUIyOjEvMS8xMDI0Lg0KPiANCj4gDQo+IFtTZWN0aW9uIDEx XQ0KPiANCj4gKiBBcyBtZW50aW9uZWQgZm9yIFNlY3Rpb24gMSwgbW9yZSBjYW4gYmUgc2FpZCBo ZXJlIGZvciB3aGVuIE9TQ09SRQ0KPiBpcyB1c2VkLg0KPiANCj4gDQo+IA0KPiBPbiAyMDIwLTEy LTA3IDE4OjM1LCBNYXJjbyBUaWxvY2Egd3JvdGU6DQo+ID4gRGVhciBhbGwsDQo+ID4NCj4gPiBG b2xsb3dpbmcgdGhlIHJlY2VudCBjbGFyaWZpY2F0aW9ucyBmcm9tIHRoZSBhdXRob3JzIFsxXSwg dGhpcw0KPiBtYWlsDQo+ID4gc3RhcnRzIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb246DQo+ ID4NCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW5ldy1i bG9jay0wMg0KPiA+DQo+ID4gVGhpcyBXR0xDIHdpbGwgZW5kIG9uIFR1ZXNkYXksIDIybmQgb2Yg RGVjZW1iZXIuDQo+ID4NCj4gPiBUaGlzIFdHTEMgaXMgYWxzbyBjb3BpZWQgdG8gdGhlIERPVFMg V0cgbWFpbGluZyBsaXN0Lg0KPiA+DQo+ID4gQmVzdCwNCj4gPiBNYXJjbyBhbmQgSmFpbWUNCj4g Pg0KPiA+IFsxXQ0KPiA+DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv Y29yZS9NSlJ4V2xkZWE1RU9jaFlKUkJPbWtkdmppDQo+IExJDQo+ID4gLw0KPiA+DQo+IA0KPiAt LQ0KPiBNYXJjbyBUaWxvY2ENCj4gUGguRC4sIFNlbmlvciBSZXNlYXJjaGVyDQo+IA0KPiBSSVNF IFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuDQo+IERpdmlzaW9uIElDVA0KPiBJc2Fmam9y ZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KPiBTRS0xNjQgNDAgS2lzdGEgKFN3ZWRlbikN Cj4gDQo+IFBob25lOiArNDYgKDApNzAgNjAgNDYgNTAxDQo+IGh0dHBzOi8vd3d3LnJpLnNlDQo+ IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Dec 22 21:01:08 2020 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 841F63A0544; Tue, 22 Dec 2020 21:01:03 -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 aTSH03xlNQX5; Tue, 22 Dec 2020 21:01:00 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31C23A048B; Tue, 22 Dec 2020 21:00:57 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 32021407C1; Wed, 23 Dec 2020 06:00:55 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7F025AB; Wed, 23 Dec 2020 06:00:47 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bd73:2e62:80f9:8152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BCEDA63; Wed, 23 Dec 2020 06:00:44 +0100 (CET) Received: (nullmailer pid 2758466 invoked by uid 1000); Wed, 23 Dec 2020 05:00:42 -0000 Date: Wed, 23 Dec 2020 06:00:42 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-new-block@ietf.org Cc: "core@ietf.org WG (core@ietf.org)" , dots@ietf.org Message-ID: References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EQlrsLUWml5Hqwie" Content-Disposition: inline In-Reply-To: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> 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, 23 Dec 2020 05:01:04 -0000 --EQlrsLUWml5Hqwie Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello new-block authors, hello CoRE, I've finally managed to have another look at the document (and it's still the 22nd *somewhere*...). My over-all summary is that while this document has matured quite a bit (and turned out better than I had expected for the special-purpose blocks it is), I think that the topic of response suppression and congestion control sections still have to be sharpened, and the examples could pick a more realistic balance between going all-NON and all-CON (or explain why that's something that wouldn't be done even though the text reads like that's what's expected to be used but maybe it's just me). Except for the first item (which is coming back to the notes for the WGLC), all should be more or less sequential in the document (with forward/back references as needed). * On the downref to No-Response: I don't see the downref as too big an issue. It's a bit odd that that document didn't go through the CoRE WG, but my impression is that it's widely used (on a "when the library I maintain broke it people filed issues" level), and both OSCORE and groupcomm-bis (which is to replace RFC7390) reference it. It's an informative reference because they don't mechanically depend on it, but it shows how well No-Response has been taken up. (Frankly, I'd support a retroactive adoption. I don't suppose we can do that with "adults"?). From how I understand Q-Block to be intended to work, No-Response does not cover all of the behavior (as it's timeout based); still, that document lays good groundwork for what's done here in a rather precise way (see comment on "For Confirmable transmission, the server MUST continue" later on) where this document needs the examples to be fully understood. Based on the later text on MAX_TRANSMIT_SPAN, why not at least acknowledge the equivalence? Maybe like this: > The behavior of endpoints following this draft can equivalently b > described in terms of the No-Response option {{?RFC7967}}: > > For a message with a Q-Block1 option with M=3D1 that is followed by > another message on the same Request-Tag within MAX_TRANSMIT_SPAN [ > or MAX_BLOCK_JITTER, see later ], the default value for No-Response > is 8 (suppressing the 4.xx code that would be returned due to the > incomplete request); an explicitly set No-Response option would > override that." although I'd still advocate just using No-Response for the whole definition even if No-Response is not typically expressed. (I'm not really sure what the correct response would be for an individual non-terminal request if it were to be answered due to an explicit No-Response:0 -- might be 2.31 Continue that's just not used in this specification because it's always suppressed? I'll come back to that -- but then it'd rather be No-Response: 10). * intro: WebSockets (capitalization) * 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: * The Q-Block options do not support stateless operation / random access. * Proxying of Q-Block is limited to caching full representations. (The latter might be mitigated by additional text around caching, but I doubt it's worth the effort given it's not part of the use case). * "compromises of": I don't understand that sentence. * "the asymmetrical packet loss is not a benefit here": It never is; what is meant here? * "Updated CoAP Response Code": "This document updates" sounds like a formal update to RFC7959, which it neither is nor needs to be. Phrasing it along the lines of "adds a media type that can be used with 4.08" would ease that. * "Only C and U columns are marked": "The Q-Block1 option is critical, and unsafe for proxies to forward" would be easier to read -- which checkboxes are marked is visible alrady from the table. (Or just leave it for the later paragraphs that say that in more detail). * "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using the Q-Block1 option" first paragraph). * "Is opaque in nature, but it is RECOMMENDED" on being a counter and starting off random: Like other similar suggestions (ETag), this is implementation guidance level and not required for interoperability. Maybe phrase this the same way as the recommendations on tokens? * "For Confirmable transmission, the server MUST continue": This reads like new-block could change anything about that, when all it does is do things on the response level. [1] has a good note on that separation topic. [1]: https://tools.ietf.org/html/rfc7967#section-2 * "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.=20 * "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.) * "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. * "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.) * "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". * "For Confirmable transmission, the client SHOULD continue to": As above in the other direction, that's not news. * "If there is insufficient space to create a response PDU": I don't understand what that means. (Where are request options reflected back?). * "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.) * "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). * "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. * "Each new request MUST use a unique token": Like above, this is stating something that's not intended to be changed. 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? 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? * "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). 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. * "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...". * "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. * 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. 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"? * "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.) * 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. * 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). * If that e4 response gets lost, does the whole mechanism recover from it in any way? 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. * 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. * 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. * 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). 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. > > 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. > > 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). 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? * 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. I don't know if it needs additional justification, but an increased N_START may be justifiable there. * 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. Best regards Christian --=20 There's always a bigger fish. -- Qui-Gon Jinn --EQlrsLUWml5Hqwie Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/izvcACgkQOY0REtOk veE7/BAAn4ne/XWB98QEaJT90TfRFzL0YogCC6wSv/+sG473p1WoYAF+bDuvna+O Bl7gOvAGEv++0k3ZpGspvSzg3KfpfW18TsIdW9EXpDdGjO0Jag+dUeAjRtwEYLEG pU7TSQo5m1WHXFvpz+RxokZ7jWLIqvl1u/JC0bC+lvt5C5DJ+lSrw2F/TYk9/ctA rtflXRQgz3zl1MHN+g6IYzChWgUjZVtkGb4yyQ2feu6MUnRqJJizOKJNB3yOtrKH ga4B+/2O63Z/Y6YXPxkCt94ITlC4GEABS0UY6Z+YkO44NEJLqjb73uB8WPq3/7+Y +7NjrgaSSVVLI2rSJF8MjjWVyIVySuun5agxK1ZUf6OSt6SVnR7nSrVKO65byKbR PtbL8zdiOlVCX8zIwht5nCJP0xjv4XpduHvVANUxAxpQ6sTFrL0sYXv8LkWC02Ag grU/ZONtPN1wny5pLz5Du9KSoJ50F3RJu5yK6wBUSme/ZgoXy3riZDDD6kFj16N+ YG9GWg2HrQXMyPMCrpaG3SKre+51//g3SeAq2zOiW5SRhLRVau5YPlaZZd7JKgfI jAKiPcUWd38Bjh7mj3dyujzX3Io32oBab+SKy722Sf5WQOQpzg0yxuDC1JS7RHn1 QA+aUunN9fSza3n5+EpKU9V5zXQG2rOPQECOL7mLOmU7CNFPI0M= =7Vbb -----END PGP SIGNATURE----- --EQlrsLUWml5Hqwie-- From nobody Wed Dec 23 00:51:24 2020 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 66EBF3A0C61; Wed, 23 Dec 2020 00:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 SMNMV631ef8p; Wed, 23 Dec 2020 00:51:21 -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 85DB93A0C36; Wed, 23 Dec 2020 00:51:21 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4D16Pg5ZKTz5w9H; Wed, 23 Dec 2020 09:51:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608713479; bh=dxepGVK25I2mTqu2Xp7n43EmMd7hCeniXY/xAB3g4Gg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tDCpMrqJiqxKw61lgoq4p0F6gw2fk9e9gdghGCa0pnszmvoN1pbATAx1Cynv/9Y7D SIoennn1h2XV1SyeNKCCd1btfRFp38TyCtdFOOzME2rsMJk2xb7S1appbDaPEMfDRX W0Z1sYsFM8Tzy4UG+Qa2k4ZHI+DhcCh97rT7Bv+jZuVyAp95RM+tmP6Tp7kimVdgaO cw0/WQsLq6nfXVpgrZgagXLRW73Xwroo/QvtihATUcqxFFjNVZeHwePwEH3du7B/mw WabCirMeSHABeGjUEw7Vis+GkmyvSKR8eO03LqnJsYU9zSIbAFoez1m+MP2+PxB6A7 k5+IbL8+aDZ1w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4D16Pg4RFPz1xp5; Wed, 23 Dec 2020 09:51:19 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (No-Response) Thread-Index: AdbZCMK38XVdj8FBRcWoH++pQBizgQ== Date: Wed, 23 Dec 2020 08:51:19 +0000 Message-ID: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@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.245] 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 (No-Response) 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, 23 Dec 2020 08:51:23 -0000 Hi Christian,=20 Thank you for the review.=20 Will focus on your first comment in this reply to ease tracking issues.=20 The text we have in the draft does not preclude No-Response (or any solutio= n that will be endorsed by the WG in the future):=20 Note: A delay of ACK_TIMEOUT after every transmission of MAX_PAYLOADS blocks may be observed even if the peer agent is able to handle more blocks without experiencing an overload. This delay can be reduced by using CON for the MAX_PAYLOADS packet to trigger sending the next set of data when the ACK is received. Nevertheless, this behavior is likely to create other timeout issues in a lossy environment (e.g., unidirectional loss as in DDoS pipe flooding). The use of NON is thus superior but requires an additional signal in the MAX_PAYLOADS packet to seek for a 2.31 (Continue) from the peer if it is ready to receive the next set of blocks. If both endpoints support No-Response, they can use it as a "signal in the = MAX_PAYLOADS" to trigger a 2.31 mentioned in the last sentence.=20 As we don't recommend No-Response (for reasons echoed in your message), it = is not worth to include much more details on how No-Response can be used.= =20=20 Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 06:01 > =C0=A0: draft-ietf-core-new-block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello new-block authors, hello CoRE, >=20 > I've finally managed to have another look at the document (and it's > still the 22nd *somewhere*...). >=20 > My over-all summary is that while this document has matured quite a > bit (and turned out better than I had expected for the special- > purpose blocks it is), I think that the topic of response > suppression and congestion control sections still have to be > sharpened, and the examples could pick a more realistic balance > between going all-NON and all-CON (or explain why that's something > that wouldn't be done even though the text reads like that's what's > expected to be used but maybe it's just me). >=20 >=20 > Except for the first item (which is coming back to the notes for the > WGLC), all should be more or less sequential in the document (with > forward/back references as needed). >=20 > * On the downref to No-Response: I don't see the downref as too big > an > issue. It's a bit odd that that document didn't go through the > CoRE > WG, but my impression is that it's widely used (on a "when the > library > I maintain broke it people filed issues" level), and both OSCORE > and > groupcomm-bis (which is to replace RFC7390) reference it. It's an > informative reference because they don't mechanically depend on > it, > but it shows how well No-Response has been taken up. >=20 > (Frankly, I'd support a retroactive adoption. I don't suppose we > can > do that with "adults"?). >=20 > From how I understand Q-Block to be intended to work, No-Response > does > not cover all of the behavior (as it's timeout based); still, that > document lays good groundwork for what's done here in a rather > precise > way (see comment on "For Confirmable transmission, the server MUST > continue" later on) where this document needs the examples to be > fully > understood. >=20 > Based on the later text on MAX_TRANSMIT_SPAN, why not at least > acknowledge the equivalence? Maybe like this: >=20 > > The behavior of endpoints following this draft can equivalently > b > > described in terms of the No-Response option {{?RFC7967}}: > > > > For a message with a Q-Block1 option with M=3D1 that is followed > by > > another message on the same Request-Tag within MAX_TRANSMIT_SPAN > [ > > or MAX_BLOCK_JITTER, see later ], the default value for No- > Response > > is 8 (suppressing the 4.xx code that would be returned due to > the > > incomplete request); an explicitly set No-Response option would > > override that." >=20 > although I'd still advocate just using No-Response for the whole > definition even if No-Response is not typically expressed. >=20 > (I'm not really sure what the correct response would be for an > individual non-terminal request if it were to be answered due to > an > explicit No-Response:0 -- might be 2.31 Continue that's just not > used in this specification because it's always suppressed? I'll > come > back to that -- but then it'd rather be No-Response: 10). >=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 Wed Dec 23 01:14:20 2020 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 EC86E3A0C93; Wed, 23 Dec 2020 01:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 4cKwM_P1PiYM; Wed, 23 Dec 2020 01:14:12 -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 4D6D73A0C90; Wed, 23 Dec 2020 01:14:12 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4D16w15K6Bz2xy2; Wed, 23 Dec 2020 10:14:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608714849; bh=B+OsC9MxQf86njvwnLQF+gtGHn6muw1P/Sz1rkdhhJU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LJX2d6++cNSVeWUD7sNsZviN04gO41RUmJedkOamEfxCnwwoVFFgTWwtJTDMYtKFF bIFISeILFf9dM0iIBOGEpC3r3NGyRVLLI7tKS3gxJ8zk07A7+MwZgH5/wFFJqJRWFm WI5AUkuu4GfrfV6BIRPysyo0BWpyETTaXa7XQVof/xYPunhAf4vTbiOVKveD5bwU9A V0pUCVZqHUBMUI+POLXkALAPn9yv8eKaTa7dcR92Khi/odmrpx2lr+Cmep1p3mhMNP KmRS6gHUFsZnnKqMhQ5fJa0dP+Jw9ejy0NAfmiHBecnd4Tuyuxbnrb3BBZXAD88tO4 IrMLG+8B2IOaQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4D16w14D5tz5vMq; Wed, 23 Dec 2020 10:14:09 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) Thread-Index: AdbZC/aihA0VBDFOQyy3pGY3SL4iaQ== Date: Wed, 23 Dec 2020 09:14:09 +0000 Message-ID: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@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.245] 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 (Congestion Control) 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, 23 Dec 2020 09:14:14 -0000 Re-, You are completely right that the default probing-rate is to be increased f= or the DOTS case. FYI, this is why we went with the following in RFC8782: | Given that the size of the heartbeat request cannot exceed | ('heartbeat-interval' * 'probing-rate') bytes, 'probing-rate' | should be set appropriately to avoid slowing down heartbeat | exchanges. For example, 'probing-rate' may be set to 2 * | ("size of encrypted DOTS heartbeat request"/'heartbeat- | interval') or (("size of encrypted DOTS heartbeat request" + | "average size of an encrypted mitigation request")/'heartbeat- | interval'). Absent any explicit configuration or inability to | dynamically adjust 'probing-rate' values (Section 4.8.1 of | [RFC7252]), DOTS agents use 5 bytes/second as a default | 'probing-rate' value. We also allow DOTS peers to negotiate the transmission parameters (and prob= ing rate) with the following as default:=20 "The RECOMMENDED values of transmission parameter values are 'ack-timeout' (2 seconds), 'max- retransmit' (3), and 'ack-random-factor' (1.5). In addition to those parameters, the RECOMMENDED specific DOTS transmission parameter values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' (15)." We avoided to include a pointer to these details as these are application-s= pecific and that, even if the draft is motivated by the DOTS use case, othe= r applications can make use of the new block functionality.=20 For NSTART, we already have the following:=20 " NSTART will also need to be increased from the default (1) to get faster transmission rates." Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 06:01 > =C0=A0: draft-ietf-core-new-block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > * 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. >=20 > I don't know if it needs additional justification, but an > increased > N_START may be justifiable there. >=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 Wed Dec 23 01:52:09 2020 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 4F2283A0E76; Wed, 23 Dec 2020 01:52:03 -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_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 Q435Khb-I5yl; Wed, 23 Dec 2020 01:52:00 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D84E3A0E74; Wed, 23 Dec 2020 01:51:58 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 645FA407C1; Wed, 23 Dec 2020 10:51:55 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5CB95AB; Wed, 23 Dec 2020 10:51:47 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bd73:2e62:80f9:8152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A1F6663; Wed, 23 Dec 2020 10:51:46 +0100 (CET) Received: (nullmailer pid 2814293 invoked by uid 1000); Wed, 23 Dec 2020 09:51:45 -0000 Date: Wed, 23 Dec 2020 10:51:45 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Message-ID: References: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Hr1RmnxscrfHuEJM" Content-Disposition: inline In-Reply-To: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (No-Response) 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, 23 Dec 2020 09:52:03 -0000 --Hr1RmnxscrfHuEJM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, > The text we have in the draft does not preclude No-Response (or any > solution that will be endorsed by the WG in the future):=20 >=20 > If both endpoints support No-Response, they can use it as a "signal in > the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last sentence.=20 > > As we don't recommend No-Response (for reasons echoed in your > message), it is not worth to include much more details on how > No-Response can be used. =20 The only reason for No-Response I echo in my mail is the downref, and merely showing how these can interoperate does not create a normative reference. It's quite a stretch to assume people would read "requires an additional signal" as "could use No-Response". Working group documents time and again have outward references like "One way of doing this is being explored in [draft-...]", which is clearly non-normative, but at the same time allow the reader to get at least *some* indication of how things are meant to be used. What makes things worse here is that as long as this specification does not mention No-Response at all, it is not ensured that it interoperates well at all with No-Response; thus even if a reader can make the jump, they'd have to figure out on their own that it's probably best if No-Response overrides the response behavior of Q-Block. > The use of NON is thus superior but requires > an additional signal in the MAX_PAYLOADS packet to seek for a 2.31 > (Continue) from the peer if it is ready to receive the next set of > blocks. I missed that in the part where I'm asking for whether 2.31 would be produced. That paragraph really opens more questions than it answers: If Q-Block is intended to be usable with something to signal that now would be a good time for a response, then this almost contradicts the "2.31 (Continue) Response is not used in the current version" statement. Either this is a possibility already planned here, then the 2.31 cases should be properly described, even if it's just with a "but requires additional signaling, which for example can be achieved by combining this with No-Response:0". Or it's not planned out here, then the 2.31 mentioned in the quoted note is more of a note on future updates of Q-Block that would be necessary to leverage that combination (but I don't see any such document happening). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Hr1RmnxscrfHuEJM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/jEy0ACgkQOY0REtOk veHppg/8CcTB5BbUE7h8pOCAmGiEH8BI+tgRPPRSND3nIe/zAkHpc6wOZYTmyJpp OL2t6YH5W4PQl8o8wNFonWyiq0L3hgw67xDv8eCJEKgX6s6s3yucswQs/Rp5MZkj rMqZlfSIoPUeMfq2wWu46quOjb8AifssRSCRN8AUjoI/aZKERukQyKv+MeIOZuzF rOUl1T5RuEsE5uebG0mfT54wtpGqjHMuIzon75LqLN1tunwxujYewafZAZNaL58f RkOyj9TWJqpaxqF1yMq7UPnXtG9cHtzCNyRN3vY7rqrsxbQ2hVpbaX6eyMvyHfQh MFsRraUPv3JNTGES2nb02cFFCyAe83aNVidMLfkR6c4KZAR2sl2usjzQ2o+nLlDq 8T9ByLpnhampZTSa/BNi1bA9uj4TWjbaof1d4lDShhxCkzD1hlw7t91eXHM0XcuC H6BxoS0F4ddLf60ANem4REZoTw0h+DaGkd+9AT/1/oiK2bMIvs+XildM7GANfatj KVdkFuwiPoAtwnSdtGukfSKWTDJRKG4IuJgVfQOh6WlLqbbrwbSRrL3y1+8phzvH hL8uMWVmfGBHv60fq0X1Iymm0DsJW31aFJbOxUNlvMqVAMxeTzG7JGKT0bq2lHBl UB3qjhaFrIdmGYnu6XLu0tDcLCVY2VGowPukPGZtNuBsiSPWTZg= =/b/m -----END PGP SIGNATURE----- --Hr1RmnxscrfHuEJM-- From nobody Wed Dec 23 02:40:00 2020 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 0F0733A0E94; Wed, 23 Dec 2020 02:39:59 -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 dYhsVkWTHPiq; Wed, 23 Dec 2020 02:39:57 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD1C3A0E8F; Wed, 23 Dec 2020 02:39:54 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8289E407C1; Wed, 23 Dec 2020 11:39:49 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 823F7AB; Wed, 23 Dec 2020 11:39:27 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bd73:2e62:80f9:8152]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DFD9E63; Wed, 23 Dec 2020 11:39:26 +0100 (CET) Received: (nullmailer pid 2826684 invoked by uid 1000); Wed, 23 Dec 2020 10:39:25 -0000 Date: Wed, 23 Dec 2020 11:39:25 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Message-ID: References: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xZSAZ4uOpIvUYSpF" Content-Disposition: inline In-Reply-To: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) 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, 23 Dec 2020 10:39:59 -0000 --xZSAZ4uOpIvUYSpF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Wed, Dec 23, 2020 at 09:14:09AM +0000, mohamed.boucadair@orange.com wrot= e: > You are completely right that the default probing-rate is to be > increased for the DOTS case. FYI, this is why we went with the > following in RFC8782: > > We avoided to include a pointer to these details as these are > application-specific and that, even if the draft is motivated by the > DOTS use case, other applications can make use of the new block > functionality.=20 At least a one-line reference into there would be helpful when reading the congestion control section. It can be phrased as an example ("For the particular use case of DOTS, these parameters are negotiated; even when not negotiated, that application uses altered defaults as in [ref-into-dots]") to avoid the impression of general applicability, but some example *should* be given, for without changed parameters the Q-Block mechanism is useless (3 hour wait if all 10 initial messages are lost). > For NSTART, we already have the following:=20 >=20 > "NSTART will also need to be increased from the default > (1) to get faster transmission rates." It would enhance readability if that were mentioned in the congestion control section. It may help to draw the parallel to the MAX_PAYLOADS of the non-confirmable case, or to talk more about the hybrid transmission (CON only after some blocks; does that have a name? see also comment around "seems to imply that the full exchange"). Does DOTS have an altered default here? Without having *anything* about non-1 NSTART, the all-CON case may not even be worth having in an example, as there's nothing even referenced where it could make sense. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --xZSAZ4uOpIvUYSpF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl/jHlkACgkQOY0REtOk veE+7A//aM8shJ7iAezFVfp0L/pW1JVez4Q5BGOR/PXNWo7R11kyySJLvCa5a2Dy G5tod1oEmda+6YevdY8eCH13IBu75vtrXIKohMWUVBV2AbKZNDv7pGSUTpCMMZxl HkCvDDpdPrhcVStvBruPnC9Zu+2J+H9Q+u0WwpIeOWNWZFsMybw97f08PQF9xxDb vyIwMtrsWSbcD916Egz0bADekkVbIJ1OCfR3OOT9xvpq1kIOMX/FsylnJzCW32Po iW4bffFUeYeHXRpBQNFUHwntkzWtUGG4GiafvausK36UX7n+KV1kBYdF1i8N/61z JlRURtD+5GMMHmGqoNRJUgbdLO6hZt8JU9d2Z4xsVAwwCUEIczz5W90OpJXQ9/wZ 5pCNQtmkMeFWPSXkVYY+DK1FPgrkRLDM1bhlY/M5cKRR5Swgw4mwgrAcLNXfG3MG bghXEXToSPHr644h0orJlgs5O5CnE3aTXeyw+x7/3rAaR8gh1RbmVi45lPpFfcQM kMttcwiD6ZmHXhVWzH+aJ7UFfFDAYr3E7WJ7oPJ28U5tVOpQ25iOOqeTmrT/Loru i59quElttXJFrUVBFtr7r7eSjbxA58kh5W1A2qwwAoHVk4Iw8cpEVp0mK5fM7rST dbFfJIt8P491yldp3OtpUzRub39tqih3HmGdf+tEE8g1CvCDlIc= =0zVB -----END PGP SIGNATURE----- --xZSAZ4uOpIvUYSpF-- From nobody Wed Dec 23 05:43:17 2020 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 1D2B23A0FD0; Wed, 23 Dec 2020 05:43:15 -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: <160873099505.25736.2775302821220056861@ietfa.amsl.com> Date: Wed, 23 Dec 2020 05:43:15 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-call-home-12.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 13:43:15 -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-12.txt Pages : 43 Date : 2020-12-23 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call-home-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 23 05:53:43 2020 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 1CD513A0FD5; Wed, 23 Dec 2020 05:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 PjUululkcG5R; Wed, 23 Dec 2020 05:53:34 -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 C11543A0FD1; Wed, 23 Dec 2020 05:53:33 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4D1F6M6nt4z5wCL; Wed, 23 Dec 2020 14:53:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608731612; bh=IsWcC6V9jy5/ZENle47UhjL9OO3x9axXf9Hw51zMKAk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=C93zTTIqKNRh5DaXlWeUoC1byFp9QGRvjQU0EKUM5L8E1V2Ve6pWnK0CDSHzLRfxj QoQY14otLB2TYMnwNsBwoLDHUyXmFY/qSnwDuOi5YT28pokrru1WESyX2kZFAmN8Ks 7C3QPnFv5orw+VWK06nDNZz92BbC9UaQUppTHdeZoFD2HZrV5oXclL3fBJwB1JE4p8 36hHNxg5f1L1T8PxsBB1fGx8aCQcGD0d8s8UBJKCjmsGqYoev17+du0tExH75w6nU+ Kt0LTCDFwUk7twxQDV5naMF6Y0efAiDvZIXW9mAczHXEe9/UoHUIxY9MvOhM44KG0g W1qlHiL0PittA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4D1F6M5xmyz1xpR; Wed, 23 Dec 2020 14:53:31 +0100 (CET) From: To: Roman Danyliw , 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+AgAN5G1CAB7E8YA== Date: Wed, 23 Dec 2020 13:53:31 +0000 Message-ID: <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@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> In-Reply-To: <703969fb11df49a39c6241bb32934ff6@cert.org> 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: Wed, 23 Dec 2020 13:53:37 -0000 SGkgUm9tYW4sIGFsbCwgDQoNCldlIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHRha2UgaW50byBhY2Nv dW50IHlvdXIgc3VnZ2VzdGlvbnMuIFRoZSBpbnRyb2R1Y3Rpb24gYW5kIGFwcGxpY2FiaWxpdHkg c2VjdGlvbnMgd2VyZSByZXdvcmtlZCBhY2NvcmRpbmdseS4gV2UgYWxzbyBrZXB0IGluIG1pbmQg Um9iJ3MgY29tbWVudCB3aGVuIHVwZGF0aW5nIHRoZXNlIHR3byBzZWN0aW9ucy4gDQoNClRoZSBu ZXcgdmVyc2lvbiBhbmQgYSBkaWZmIGNhbiBiZSBmb3VuZCBhdDoNCg0KSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwt aG9tZS0xMiANCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWUtMTIgDQoNClBsZWFzZSBsZXQgdXMg a25vdyBpZiB0aGlzIHZlcnNpb24gYWRkcmVzc2VzIHlvdXIgRElTQ1VTUy4NCg0KQWxzbywgdGhp cyB2ZXJzaW9uIGludGVncmF0ZXMgdGhlIGlucHV0cyBmcm9tIHRoZSBCYXJyeS9FcmljL0VyaWsg YW5kIGRpcmVjdG9yYXRlIHJldmlld3MuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogUm9tYW4gRGFueWxpdyBbbWFpbHRvOnJkZEBjZXJ0 Lm9yZ10NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxOCBkw6ljZW1icmUgMjAyMCAxNzo1OA0KPiDD gMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPjsgVGhlDQo+IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjwqA6IGRyYWZ0LWlldGYtZG90 cy1zaWduYWwtY2FsbC1ob21lQGlldGYub3JnOyBkb3RzLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IFZh bGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+OyBkb3RzQGlldGYub3JnDQo+IE9iamV0 wqA6IFJFOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFs LWNhbGwtDQo+IGhvbWUtMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBN ZWQhDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogRG90cyA8 ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YNCj4gPiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQo+ID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAyMCAxOjE0 IEFNDQo+ID4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPg0KPiA+IENjOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZUBpZXRm Lm9yZzsgZG90cy0NCj4gY2hhaXJzQGlldGYub3JnOw0KPiA+IFZhbGVyeSBTbXlzbG92IDx2YWxl cnlAc215c2xvdi5uZXQ+OyBkb3RzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtEb3RzXSBS b21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbg0KPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2Fs bC0NCj4gPiBob21lLTExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gSGkg Um9tYW4sDQo+ID4NCj4gPiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQo+ID4NCj4gPiBQbGVh c2Ugc2VlIGlubGluZSBmb3IgdGhlIERJU0NVU1MgcGFydC4gV2lsbCBzZWUgaWYvd2hhdCBjaGFu Z2VzDQo+IGFyZQ0KPiA+IG5lZWRlZCBmb3IgdGhlIENPTU1FTlQgcGFydC4NCj4gPg0KPiA+IENo ZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4gPiBEZcKgOiBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlA aWV0Zi5vcmddDQo+IEVudm95w6nCoDoNCj4gPiA+IG1hcmRpIDE1IGTDqWNlbWJyZSAyMDIwIDIx OjAxIMOAwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDY8KgOg0KPiA+ID4gZHJhZnQtaWV0 Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGRvdHMtDQo+IGNoYWlyc0BpZXRmLm9y ZzsNCj4gPiA+IGRvdHNAaWV0Zi5vcmc7IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5u ZXQ+Ow0KPiA+ID4gdmFsZXJ5QHNteXNsb3YubmV0IE9iamV0wqA6IFJvbWFuIERhbnlsaXcncyBE aXNjdXNzIG9uDQo+ID4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0NCj4gPiA+ IDExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+ID4NCj4gPiA+IFJvbWFuIERhbnls aXcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4gPiBk cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0xMTogRGlzY3Vzcw0KPiA+ID4NCj4gPiA+ IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5DQo+IHRvDQo+ID4gPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBU byBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUNCj4gdG8NCj4gPiA+IGN1dCB0aGlzIGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0NCj4gPiA+ IGNyaXRlcmlhLmh0bWwNCj4gPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQNCj4g aGVyZToNCj4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt ZG90cy1zaWduYWwtY2FsbC0NCj4gaG9tZS8NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gLS0tLQ0KPiA+ID4gLS0NCj4gPiA+IERJU0NVU1M6DQo+ID4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IC0tLS0NCj4gPiA+IC0tDQo+ID4gPg0KPiA+ID4gSXQgc2VlbXMgdG8gbWUgdGhlcmUgaXMgYSBt aXNzaW5nIG9wZXJhdGlvbmFsIGd1aWRhbmNlIG9yDQo+ID4gPiB1bmRvY3VtZW50ZWQgZGVwbG95 bWVudCBhc3N1bXB0aW9ucy4gIFNpbmNlIHRoZSBtb3RpdmF0aW9uYWwgdXNlDQo+ID4gPiBjYXNl IHNlZW1zIHRvIGJlIGhvbWUgbmV0d29ya3MgKHBlciBTZWN0aW9uIDEuMSksIEkgYXNzdW1lZCB0 aGF0DQo+IHRoZQ0KPiA+ID4gY2FsbCBob21lIHNlcnZlcnMgYXJlIHJ1bm5pbmcgcHJpbWFyaWx5 IGNvbnN1bWVyIGdyYWRlIHJvdXRlcnMNCj4gbm90DQo+ID4gPiBtYW5hZ2VkIGJ5IHByb2Zlc3Np b25hbCBJVCBleHBlcnRpc2UuDQo+ID4NCj4gPiBbTWVkXSBUaGUgZ2VuZXJhbGl6ZWQgYXBwbGlj YWJpbGl0eSBzY29wZSBpcyB3aGF0IGlzIHNrZXRjaGVkIGluDQo+ID4gU2VjdGlvbiAzLiBUaGUg c29sdXRpb24gaXMgbWVhbnQgdG8gYmxvY2sgYXR0YWNrcyBjbG9zZSB0byB0aGVpcg0KPiBzb3Vy Y2UuIFRoaXMgY2FuIGJlOg0KPiA+IC0gdGhlIGhvbWUgY2FzZSwNCj4gPiAtIGFuIGVudGVycHJp c2UgbmV0d29yaywNCj4gPiAtIGEgdHJhbnNpdCBwcm92aWRlciBmaWx0ZXJpbmcgYXR0YWNrcyBm cm9tIGxlYWYgbmV0d29ya3MsDQo+ID4gLSBhIHByb3ZpZGVyIGZpbHRlcmluZyBhdHRhY2tzIGZy b20gZGF0YSBjZW50ZXJzLA0KPiA+IC0gZXRjLg0KPiA+DQo+ID4gRm9yIHRoZSBwYXJ0aWN1bGFy IGNhc2Ugb2YgaG9tZSBuZXR3b3JrcywgdGhpcyBjYW4gYmUgcGFydCBvZg0KPiBzZXJ2aWNlcw0K PiA+IHN1cHBvcnRlZCBieSBhIElTUC1tYW5hZ2VkIENQRSBvciBhIG1hbmFnZWQgc2VjdXJpdHkg c2VydmljZQ0KPiBzdWJzY3JpYmVkIGJ5IHRoZSB1c2VyLg0KPiA+DQo+ID4gV2UgY291bGQgbWVu dGlvbiB0aGF0IGluIHRoZSBkb2N1bWVudCwgYnV0IHdlIGRpZG4ndCBiZWNhdXNlIHRoaXMNCj4g YXJlDQo+ID4gZGVwbG95bWVudC1zcGVjaWZpYy4gUmVhbGx5Lg0KPiA+DQo+ID4gT3RoZXIgdGhh biB0aGUgaW50cm9kdWN0aW9uLCB3ZSBkb24ndCB3YW50IHRvIG92ZXJsb2FkIHRoZQ0KPiBkb2N1 bWVudA0KPiA+IHdpdGggaG9tZS1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucy4NCj4gDQo+IEkgc3Rp bGwgdGhpbmsgd2UgbmVlZCBhIGJpdCBtb3JlIHByZWNpc2lvbi4gIEkgZG9uJ3QgZGlzcHV0ZSB0 aGUNCj4gZ2VuZXJhbCB1dGlsaXR5IG9mIHRoaXMgYXBwcm9hY2ggdG8gYSB2YXJpZXR5IG9mIGVu dmlyb25tZW50cy4gIEkgZG8NCj4gc2VlIHRoZSB0d28gc2VudGVuY2VzIGluIHRoZSBlbnRpcmUg ZG9jdW1lbnQgd2hpY2ggc2F5IHRoYXQgdGhpcyBpcw0KPiBhIGdlbmVyYWwgcHVycG9zZSBhcHBy b2FjaDoNCj4gDQo+IEFic3RyYWN0OiBUaGUgRE9UUyBzaWduYWwgY2hhbm5lbCBDYWxsIEhvbWUg aXMgbm90IHNwZWNpZmljIHRvIGhvbWUNCj4gbmV0d29ya3M7DQo+ICAgIHRoZSBzb2x1dGlvbiB0 YXJnZXRzIGFueSBkZXBsb3ltZW50IGluIHdoaWNoIGl0IGlzIHJlcXVpcmVkIHRvDQo+IGJsb2Nr DQo+ICAgIEREb1MgYXR0YWNrIHRyYWZmaWMgY2xvc2VyIHRvIHRoZSBzb3VyY2Uocykgb2YgYSBE RG9TIGF0dGFjay4NCj4gDQo+IFNlY3Rpb24gMzogIlRoZSBhZm9yZW1lbnRpb25lZCBwcm9ibGVt cyBtYXkgYmUgZW5jb3VudGVyZWQgaW4gb3RoZXINCj4gZGVwbG95bWVudHMNCj4gICAgdGhhbiB0 aG9zZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiAxLjEgKGUuZy4sIGRhdGEgY2VudGVycywNCj4gZW50 ZXJwcmlzZQ0KPiAgICBuZXR3b3JrcykuIg0KPiANCj4gSG93ZXZlciwgSSB3aWxsIHJlaXRlcmF0 ZSB0aGF0IGFsbW9zdCBubyBjb25zaWRlcmF0aW9uIGlzIG1hZGUgdG8NCj4gZGlzdGluZ3Vpc2gg dGhlc2UgdXNlIGNhc2VzIGluIHRoZSBuYXJyYXRpdmUgdGV4dC4gIFRoZSBlbnRpcmUNCj4gbW90 aXZhdGlvbiBmb3IgdGhlIHdvcmsgaW4gU2VjdGlvbiAxLjAgaXMgdGhyb3VnaCB0aGUgbGVucyBv Zg0KPiBuZXR3b3JrcyBub3QgbWFuYWdlZCBieSBwcm9mZXNzaW9uYWxzIChob21lIG5ldHdvcmtz KS4gIEZ1cnRoZXJtb3JlLA0KPiB0aGUgZXhwbGFuYXRpb24gb2YgdGhlIHNvbHV0aW9uIGluIFNl Y3Rpb24gMS4xLCA1LjEgYW5kIEFwcGVuZGl4IEENCj4gaXMgZG9uZSB0aHJvdWdoIHRoZSBsZW5z IG9mIGEgImhvbWUgbmV0d29yayIuICBGb3IgdGhpcyByZWFzb24sIEknbQ0KPiBwdXNoaW5nIHRv IG1ha2Ugc3VyZSB0aGUgZWRnZXMgb2YgdGhhdCBkZXBsb3ltZW50IGVudmlyb25tZW50IGFyZQ0K PiBjb3ZlcmVkLg0KPiANCj4gSSB3b3VsZCBhc3NlcnQgdGhhdCBtb3N0IG9mIHRoZSBiZWhhdmlv ciBkZXNjcmliZWQgYmVsb3cgcmVxdWlyZXMNCj4gdGhhdCBwcm9mZXNzaW9uYWwgSVQgZXhwZXJ0 aXNlIChsZXQgbWUga25vdyBpZiB5b3UgdGhpbmsgSSBoYXZlIGl0DQo+IHdyb25nKS4gIEknbSBs b29raW5nIHByaW1hcmlseSBmb3IgYSBmZXcgcGllY2VzIG9mIGNsYXJpZnlpbmcgdGV4dDoNCj4g KDEpIGEgc3VnZ2VzdGlvbi9hY2tub3dsZWRnZW1lbnQgdGhhdCBDUEVzIHVzaW5nIHRoaXMgc3Bl YyBpbiB0aGUNCj4gaG9tZSBlbnZpcm9ubWVudCBhcmUgbGlrZWx5IHRvIGJlIG1hbmFnZWQsIHBy b3Zpc2lvbmVkLCBpc3N1ZWQgKD8pDQo+IGJ5IGFuIElTUCAodGhpcyBhZGRyZXNzZXMgd2hlcmUg dGhlcmUgcHJvZmVzc2lvbmFsIElUIGV4cGVydGlzZSBpcw0KPiBjb21pbmcgZnJvbSkNCj4gKDIp IGFzc3VtaW5nICgxKSBpcyB0cnVlLCBkaXN0aW5ndWlzaGluZyB0aGUgdmFyaW91cw0KPiBNVVNU L1NIT1VMRC9NQVlzIGFkbWluIGJlaGF2aW9ycyB0aGF0IGludm9sdmUgdGhlIElTUCB2cy4gdGhl IGFjdHVhbA0KPiBodW1hbnMgb24gdGhlIGhvbWUgbmV0d29yaw0KPiANCj4gTm90ZTogZXZlcnl0 aGluZyBlbHNlIGJlbG93IGlzIGp1c3QgbW9yZSBkZXRhaWxlZCBjb21tZW50YXJ5IG9uIHRoaXMN Cj4gdGhlbWUgYWJvdmUuICBJJ2Qgc3VtbWFyaXplIGV2ZXJ5dGhpbmcgSSd2ZSBzYWlkIGhlcmUg Ynkgc2F5aW5nIEkNCj4gdGhpbmsgd2UgbmVlZCBtb3JlIGZpbmVzc2UgaW4gZGVzY3JpYmluZyB0 aGUgb3BlcmF0aW9uYWwNCj4gY29uc2lkZXJhdGlvbnMgYW5kIHdobyBpcyBleHBlY3RlZCB0byB0 YWtlIHJlc3BvbnNpYmlsaXR5IGZvciB0aGVtDQo+IChyZWFsaXppbmcgdGhlcmUgd2lsbCBiZSBh IGRpdmVyc2l0eSBvZiBlbnZpcm9ubWVudHMpLiAgSG93ZXZlciwNCj4gc2luY2UgdGhlcmUgYXJl IG11bHRpcGxlIHVzZSBjYXNlcywgSU1PLCB0aGV5IGRlc2VydmUgdW5pcXVlDQo+IGNvbnNpZGVy YXRpb24gd2hlbiB0aGV5IGFyZSBkaWZmZXJlbnQgZnJvbSBlYWNoIG90aGVyLg0KPiANCj4gPiAg IElmIHRoYXQgYXNzdW1wdGlvbiBpcyB0cnVlDQo+ID4gPiAoYW5kIGl0IHNob3VsZCBiZSBkb2N1 bWVudGVkIGlmIHRoYXQgaXMgdGhlIGNhc2UpLCB0aGVuIEkgZmluZA0KPiBtYW55DQo+ID4gPiBv ZiB0aGUgb3BlcmF0aW9uYWwgcmVjb21tZW5kYXRpb25zIG5vdCBjb25ncnVlbnQgd2l0aCB0aGF0 DQo+IGVudmlyb25tZW50Lg0KPiA+ID4gU3BlY2lmaWNhbGx5LCB0aGUgZGVncmVlIG9mIGludGVy YWN0aW9uIGFuZCB0dW5pbmcgc2VlbXMgb3V0c2lkZQ0KPiB0aGUNCj4gPiA+IHJlYWxtIG9mIGV4 cGVydGlzZSBvZiBzb21lb25lIHdpdGhvdXQgSVQgdHJhaW5pbmcgYW5kDQo+IGNhcGFiaWxpdGll cw0KPiA+ID4gb2YgaG9tZSBuZXR3b3JrIGVjb3N5c3RlbS4gIEluIHBhcnRpY3VsYXI6DQo+ID4g Pg0KPiA+ID4gLS0gU2VjdGlvbiAxLjINCj4gPiA+IFRoZSBDYWxsIEhvbWUgRE9UUyBzZXJ2ZXIg dXNlcyB0aGUgRERvUyBhdHRhY2sgdHJhZmZpYw0KPiBpbmZvcm1hdGlvbiB0bw0KPiA+ID4gICAg aWRlbnRpZnkgdGhlIGNvbXByb21pc2VkIGRldmljZSBpbiBpdHMgZG9tYWluIHRoYXQgaXMNCj4g cmVzcG9uc2libGUNCj4gPiA+IGZvcg0KPiA+ID4gICAgbGF1bmNoaW5nIHRoZSBERG9TIGF0dGFj aywgb3B0aW9uYWxseSBub3RpZmllcyBhIG5ldHdvcmsNCj4gPiA+ICAgIGFkbWluaXN0cmF0b3Is IGFuZCB0YWtlcyBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9uIGFjdGlvbihzKS4NCj4gPiA+DQo+ID4g PiBIb3cgd291bGQgc3VjaCBub3RpZmljYXRpb24gd29yaz8NCj4gPg0KPiA+IFtNZWRdIFRoaXMg d2lsbCBkZXBlbmQgb24gdGhlIGRlcGxveW1lbnQgKGhvbWUsIGVudGVycHJpc2UsIERDLA0KPiBh Y2Nlc3MNCj4gPiBwcm92aWRlciwgcGVlciB0cmFuc2l0IHByb3ZpZGVyLCBldGMuKS4gVGhpcyBj YW4gYmUgdXNpbmcgRE9UUw0KPiAodGhlDQo+ID4gYWRtaW5pc3RyYXRvciBoYXMgYSBjYWxsIGhv bWUgZG90cyBzZXJ2ZXIgYXBwKSwgYSBwdXNoIGZyb20gdGhlDQo+IGFwcA0KPiA+IHVzZSBmb3Ig bWFuYWdpbmcgdGhlIENQRSwgc3lzbG9nLCBzbm1wLCBuZXRjb25mLCBhbiBTTVMsIGV0Yy4NCj4g DQo+IEkgdW5kZXJzdGFuZCB0aGlzIGFuc3dlciBpbiB0aGUgY29udGV4dCBvZiB0aGUgZW50ZXJw cmlzZSB1c2UgY2FzZS4NCj4gSG93IHdvdWxkIHRoaXMgaGFwcGVuIGZvciB0aGUgaG9tZSB1c2Vy IChub24tcHJvZmVzc2lvbmFsIElUDQo+IHBlcnNvbik/DQo+IA0KPiBJZiB0aGlzIGFuIGluc3Rh bmNlIHdoZXJlIGlmIHRoZSBDUEUgaXMgbWFuYWdlZCBvbiBiZWhhbGYgYSB0aGUNCj4gdXNlciwg cGVyaGFwcyBzYXlpbmcgYW4gb3V0LW9mLXNjb3BlIG1lY2hhbmlzbXMgKGFwcCwgU01TKSBuZWVk cyB0bw0KPiBiZSBwcm92aWRlZCBmb3IgdGhlIGVuZC11c2VyIChob21lIHVzZXIpPw0KPiANCj4g PiBBcyB5b3UgY2FuIHNlZSBhIHZhcmlldHkgb2YgdG9vbHMgY2FuIGJlIGNvbnNpZGVyZWQgYXMg YSBmdW5jdGlvbg0KPiBvZg0KPiA+IHRoZSBsb2NhbCBkZXBsb3ltZW50IGNhc2UuIE5vbmUgb2Yg dGhlbSBpcyBjYWxsZWQgb3V0IGluIHRoZSB0ZXh0DQo+IGFzDQo+ID4gdGhpcyBpcyBkZXBsb3lt ZW50LSBzcGVjaWZpYy4gTm90IGFsbCBvZiB0aGVtIGFyZSBhcHBsaWNhYmxlIGZvcg0KPiBlYWNo IGRlcGxveW1lbnQgY2FzZS4NCj4gDQo+IE1ha2Ugc2Vuc2UuICBQZXJoYXBzIHNvbWUgZGV0YWls cyBkaXN0aW5ndWlzaGluZyB0aGUgZ3VpZGFuY2UgcGVyDQo+IHRoZSB1c2UgY2FzZXMgY291bGQg aGVscC4NCj4gDQo+ID4gPg0KPiA+ID4gLS0gU2VjdGlvbiAxLjIgYW5kIDUuMS4gIExlYXZlcyBj cmVkZW50aWFscyBjb25maWd1cmF0aW9uIGFzIG91dA0KPiBvZg0KPiA+ID4gc2NvcGUuDQo+ID4N Cj4gPiBbTWVkXSBUaGF0IGlzIGFsaWduZWQgd2l0aCBob3cgY3JlZGVudGlhbHMgYXJlIGhhbmRs ZWQgaW4gdGhlIGJhc2UNCj4gPiBzcGVjIChSRkM4NzgyKS4NCj4gPg0KPiA+ID4gU2VjdGlvbiAx LjIgcmVmZXJlbmNlcyBbSS1ELmlldGYtZG90cy1zZXJ2ZXItZGlzY292ZXJ5XSBmb3INCj4gPiA+ IHByb3Zpc2lvbmluZy4gIEluIHR1cm4sIFNlY3Rpb24gMSBvZiBbSS1ELmlldGYuc2VydmVyLWRp c2NvdmVyeV0NCj4gPiA+IGFsc28gZGVjbGFyZXMgdGhpcyBwcm9ibGVtIG91dCBvZiBzY29wZSBi eSBzYXlpbmcg4oCcVGhpcyBkb2N1bWVudA0KPiA+ID4gYXNzdW1lcyB0aGF0IHNlY3VyaXR5IGNy ZWRlbnRpYWxzIHRvIGF1dGhlbnRpY2F0ZSBET1RTIHNlcnZlcihzKQ0KPiBhcmUNCj4gPiA+IHBy ZS1wcm92aXNpb25lZCB0byBhIERPVFMgY2xpZW50IHVzaW5nIGEgbWVjaGFuaXNtIHN1Y2ggYXMg KGJ1dA0KPiBub3QNCj4gPiA+IGxpbWl0ZWQgdG8pIHRob3NlIGRpc2N1c3NlZCBpbiBbUkZDODU3 Ml0gb3IgW0ktRC5pZXRmLWFuaW1hLQ0KPiA+ID4gYm9vdHN0cmFwcGluZy1rZXlpbmZyYV3igJ0u ICBIb3dldmVyLCBSRkM4NTcyIHNlZW1zIHRvIHJlbHkgb24NCj4gTkVUQ09ORg0KPiA+ID4gYW5k IFJFU1RDT05GIHdoaWNoIHNlZW1zIGxpa2UgYSByYXRoZXIgdW5jb21tb24gZmVhdHVyZSBvZiBo b21lDQo+ID4gPiByb3V0ZXJzLiAgQlJLU0kgcmVsaWVzIG9uIGEgbWFudWZhY3R1cmVyIHN1cHBs aWVkL2NvbnRyYWN0ZWQNCj4gPiA+IGluZnJhc3RydWN0dXJlIGFuZCBrZXlzdG9yZXMgdGhhdCBh bHNvIHNlZW0gdW5jb21tb24gZm9yDQo+IGNvbnN1bWVyDQo+ID4gPiBncmFkZSBlcXVpcG1lbnQu DQo+ID4NCj4gPiBbTWVkXSBUaGVzZSBhcmUgbm90IG1lYW50IHRvIGJlIHJlY29tbWVuZGF0aW9u cy4gVGhlc2UgZXhhbXBsZXMNCj4gbWF5IGJlDQo+ID4gT0sgZm9yIHNvbWUgZGVwbG95bWVudHMs IGJ1dCBub3QgYXBwcm9wcmlhdGUgZm9yIG90aGVycy4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tIFNl Y3Rpb24gNS4zLjEuDQo+ID4gPiBUaGUgQ2FsbCBIb21lIERPVFMgc2VydmVyIGRvbWFpbiBhZG1p bmlzdHJhdG9yIGNvbnNlbnQgTUFZIGJlDQo+ID4gPiAgICByZXF1aXJlZCB0byBibG9jayB0aGUg dHJhZmZpYyBmcm9tIHRoZSBjb21wcm9taXNlZCBkZXZpY2UgdG8NCj4gdGhlDQo+ID4gPiAgICBh dHRhY2sgdGFyZ2V0LiAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGhhdmUgYSBjb25maWd1cmF0aW9u DQo+IGtub2IgdG8NCj4gPiA+ICAgIGJsb2NrIHRoZSB0cmFmZmljIGZyb20gdGhlIGNvbXByb21p c2VkIGRldmljZSB0byB0aGUgYXR0YWNrDQo+IHRhcmdldA0KPiA+ID4gICAgd2l0aCBvciB3aXRo b3V0IERPVFMgc2VydmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIGNvbnNlbnQuDQo+ID4gPg0KPiA+ ID4gVGhlIHN1Z2dlc3Rpb24gaGVyZSBzZWVtcyB0byBiZSB0aGF0IGNvbnN1bWVycyBhcmUgYWNx dWlyaW5nDQo+IGRldmljZXMNCj4gPiA+IHRoYXQgY2FuIGJlIHJlbW90ZWx5IHJlY29uZmlndXJl ZCB3aXRoIG91dCBhIGRlZmluZWQgdHJ1c3QNCj4gbW9kZWw/DQo+ID4NCj4gPiBbTWVkXSBDYW4g eW91IHBsZWFzZSBjbGFyaWZ5IHdoaWNoIHN1Z2dlc3Rpb24gYXJlIHlvdSByZWZlcnJpbmcNCj4g dG8/DQo+IA0KPiBJJ20gd29uZGVyaW5nIHdobyB0aGUgInNlcnZlciBkb21haW4gYWRtaW5pc3Ry YXRvciIgaXMgYW5kIGhvdyB0aGV5DQo+IGFyZSBleHBlY3RlZCB0byBjb25zZW50IGluIHRoZSBo b21lIHVzZXIgc2NlbmFyaW8/DQo+IA0KPiA+IFRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgcmVmZXJy aW5nIHRvIGJsb2NraW5nIHRyYWZmaWMgZnJvbSBkZXZpY2VzDQo+IHRoYXQNCj4gPiBhcmUgaW5q ZWN0aW5nIEREb1MgdHJhZmZpYyBmcm9tIHdpdGhpbiBhIGRvbWFpbi4gVGhlc2UgZGV2aWNlcyBj YW4NCj4gYmUNCj4gPiBhbiBJUCBjYW1lcmEsIGFuIGluZmVjdGVkIFBDLCBldGMuDQo+ID4NCj4g PiA+IFNvbWUgcG9saWN5IG9yIG9wZXJhdGlvbmFsIGNvbnRleHQgc2VlbXMgYXBwcm9wcmlhdGUg aGVyZS4NCj4gPiA+DQo+ID4gPiAtLSBTZWN0aW9uIDUuMy4xDQo+ID4gPiAuLi4gbm90aWZpZXMg dGhlIENQRQ0KPiA+ID4gICAgYWRtaW5pc3RyYXRvciBhYm91dCB0aGUgY29tcHJvbWlzZWQgZGV2 aWNlDQo+ID4gPg0KPiA+ID4gTm90aWZ5IGhvdz8NCj4gPg0KPiA+IFtNZWRdIFNlZSBhYm92ZS4N Cj4gDQo+IExpa2UgSSBub3RlZCBhYm92ZSwgaWYgSSdtIGEgaG9tZSB1c2VyLCBob3cgYW0gSSBs aWtlbHkgdG8gZ2V0IHRoYXQNCj4gbm90aWZpY2F0aW9uPw0KPiANCj4gPiA+DQo+ID4gPiAtLSBT ZWN0aW9uIDguDQo+ID4gPiBBcHByb3ByaWF0ZQ0KPiA+ID4gICAgZmlsdGVycyAoZS5nLiwgYWNj ZXNzIGNvbnRyb2wgbGlzdHMpIGNhbiBiZSBpbnN0YWxsZWQgb24gdGhlDQo+IENhbGwNCj4gPiA+ ICAgIEhvbWUgRE9UUyBzZXJ2ZXIgYW5kIG5ldHdvcmsgYmV0d2VlbiB0aGUgQ2FsbCBIb21lIERP VFMNCj4gYWdlbnRzIHNvDQo+ID4gPiAgICB0aGF0IG9ubHkgY29tbXVuaWNhdGlvbnMgZnJvbSBh IHRydXN0ZWQgQ2FsbCBIb21lIERPVFMgY2xpZW50DQo+IHRvDQo+ID4gPiB0aGUNCj4gPiA+ICAg IENhbGwgSG9tZSBET1RTIHNlcnZlciBhcmUgYWxsb3dlZC4NCj4gPiA+DQo+ID4gPiBUaGlzIHNl ZW1zIGxpa2UgYSBsZXZlbCBvZiBzb3BoaXN0aWNhdGlvbiBiZXlvbmQgeW91ciBhdmVyYWdlDQo+ IGhvbWUNCj4gPiA+IHJvdXRlciB1c2VyIGFuZCBhIHBsYWNlIHdoZXJlIGltcGxlbWVudGF0aW9u cyBzaG91bGQgY29uc2lkZXIgYQ0KPiA+ID4gc2VjdXJlIGRlZmF1bHRzLg0KPiA+DQo+ID4gW01l ZF0gVGhpcyBmaWx0ZXJpbmcgY2FuIGJlIGF1dG9tYXRpY2FsbHkgc2V0IGJhc2VkIG9uIHRoZQ0K PiBjb25maWd1cmVkDQo+ID4gbGlzdCBvZiBDYWxsIEhvbWUgRE9UUyBjbGllbnRzLiBUaGlzIGlz IGEgd2lkZWx5IHVzZWQgcHJhY3RpY2UNCj4gKHRoaW5rDQo+ID4gYWJvdXQgU0lQIHByb3h5IHNl cnZlcnMsIGV4YW1wbGUpLiBObyBpbnRlcnZlbnRpb24gbWF5IGJlIHJlcXVpcmVkDQo+IGZyb20g dGhlIHVzZXIuDQo+IA0KPiBBZ3JlZWQuICBIb3dldmVyLCB0aGlzIGlzIGFzc3VtaW5nIHRoYXQg c29tZW9uZSBpcyBtYW5hZ2luZyB0aGF0DQo+IGNvbmZpZ3VyYXRpb24uICBNeSBwb2ludCBpcyB0 aGF0IGluIHRoZSBob21lIHVzZXIgc3BhY2UgdGhhdCBpcyBtb3N0DQo+IGxpa2VseSB0aGUgSVNQ LCBzbyBsZXQncyBqdXN0IHNheSB0aGF0Lg0KPiANCj4gPiA+DQo+ID4gPiAtLSBTZWN0aW9uIDgu DQo+ID4gPiBDYWxsIEhvbWUgRE9UUyBzZXJ2ZXJzIGNhbiBhbHNvIHNlZWsgdGhlIGNvbnNlbnQg b2YgRE9UUw0KPiA+ID4gICAgc2VydmVyIGRvbWFpbiBhZG1pbmlzdHJhdG9yIHRvIGJsb2NrIHRo ZSB0cmFmZmljIGZyb20gdGhlDQo+ID4gPiBwb3RlbnRpYWxseQ0KPiA+ID4gICAgY29tcHJvbWlz ZWQgZGV2aWNlIHRvIHRoZSB0YXJnZXQgKHNlZSBTZWN0aW9uIDUuMy4xKS4NCj4gPiA+DQo+ID4g PiBXaGF0IHdvdWxkIGJlIHRoZSBtZWFucyB0byBnYWluIHN1Y2ggY29uc2VudD8NCj4gPg0KPiA+ IFtNZWRdIFRoaXMgd2lsbCBkZXBlbmQgb24gdGhlIGRlcGxveW1lbnQgY2FzZTogdGhpcyBjYW4g YmUgYW4NCj4gYWN0aW9uDQo+ID4gZXhlY3V0ZWQgdXNpbmcgYW4gYXBwLCBhIGNvbmZpcm1hdGlv biB0byBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlLA0KPiBldGMuDQo+ID4NCj4gPiA+DQo+ID4gPiAt LSBTZWN0aW9uIDkuDQo+ID4gPiBOb3RlIHRoYXQgYSBDYWxsIEhvbWUgRE9UUyBzZXJ2ZXIgY2Fu IHNlZWsgYW4gYWRtaW5pc3RyYXRvcidzDQo+ID4gPiAgICBjb25zZW50LCB2YWxpZGF0ZSB0aGUg cmVxdWVzdCBieSBpbnNwZWN0aW5nIHRoZSByZWxldmFudA0KPiB0cmFmZmljDQo+ID4gPiBmb3IN Cj4gPiA+ICAgIGF0dGFjayBzaWduYXR1cmVzLCBvciBwcm9jZWVkIHdpdGggYm90aCBjb3Vyc2Vz IG9mIGFjdGlvbi4NCj4gPiA+DQo+ID4gPiBBcyBhYm92ZS4NCj4gPg0KPiA+IFtNZWRdIEFzIGFi b3ZlIDotKQ0KPiA+DQo+ID4gPg0KPiA+ID4gLS0gU2VjdGlvbiA5Lg0KPiA+ID4NCj4gPiA+ICAg ICBUaGUgRE9UUyBDYWxsIEhvbWUgaXMgb25seSBhZHZpc29yeSBpbiBuYXR1cmUuICBDb25jcmV0 ZWx5LA0KPiB0aGUNCj4gPiA+IERPVFMNCj4gPiA+ICAgIENhbGwgSG9tZSBkb2VzIG5vdCBpbXBv c2UgYW55IGFjdGlvbiB0byBiZSBlbmZvcmNlZCB3aXRoaW4NCj4gdGhlDQo+ID4gPiAgICBuZXR3 b3JrIGhvc3RpbmcgYW4gYXR0YWNrIHNvdXJjZTsgaXQgaXMgdXAgdG8gdGhlIENhbGwgSG9tZQ0K PiBET1RTDQo+ID4gPiAgICBzZXJ2ZXIgKGFuZC9vciBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIHRv IGRlY2lkZSB3aGV0aGVyIGFuZA0KPiB3aGljaA0KPiA+ID4gICAgYWN0aW9ucyBhcmUgcmVxdWly ZWQuDQo+ID4gPg0KPiA+ID4gU3VjaCBhIGRlY2lzaW9ucyBzZWVtcyBvdXQgYmV5b25kIHRoZSBh YmlsaXR5IG9mIHlvdXIgYXZlcmFnZQ0KPiBob21lDQo+ID4gPiByb3V0ZXIgdXNlci4NCj4gPg0K PiA+IFtNZWRdIFdlIGRvbid0IGhhdmUgdGhlIG5vdGlvbiBvZiAiYXZlcmFnZSBob21lIHJvdXRl ciB1c2VyIiA7LSkNCj4gDQo+IEFncmVlZC4gIFByb2JhYmx5IG5vdCB1cyB0aG91Z2ggOi0pLiAg TXkgaW50ZW50IHdhcyB0byBzYXkgdGhhdCB3aGVuDQo+IHRoZSBhY3Rpb25zL2RlY2lzaW9ucyBh cmUgYmVpbmcgZnJhbWVkIGFzIGJlaW5nIGZvciBhICJuZXR3b3JrDQo+IGFkbWluIiwgdGhhdCB0 byBtZSBzdWdnZXN0cyBhIGxldmVsIGV4cGVydGlzZSBvdXRzaWRlIG9mIHRoZQ0KPiBjYXBhYmls aXR5IG9mIHR5cGljYWwgZW5kIGNvbnN1bWVyIHdpdGhvdXQgcHJvZmVzc2lvbmFsIElUDQo+IGRl Y2lzaW9ucy4NCj4gDQo+IFJlZ2FyZHMsDQo+IFJvbWFuDQo+IA0KPiA+ID4NCj4gPiA+IC0tIFNl Y3Rpb24gOCAg4oCcLi4uIGV4cGxpY2l0IHBvbGljeSAoZS5nLiwgdGhlIENhbGwgSG9tZSBET1RT DQo+IGNsaWVudA0KPiA+ID4gYW5kIHNlcnZlciBhcmUgbWFuYWdlZCBieSB0aGUgc2FtZSBhZG1p bmlzdHJhdGl2ZSBlbnRpdHkpLA0KPiA+ID4NCj4gPiA+IElzIHRoZXJlIGFuIHVuZGVybHlpbmcg YXNzdW1wdGlvbiB0aGF0IHRoZSBJU1AgaXMgbWFuYWdpbmcgdGhlDQo+IGRldmljZT8NCj4gPg0K PiA+IFtNZWRdIElTUCBtYW5hZ2VkIGRldmljZXMgaXMgb25lIHR5cGljYWwgZGVwbG95bWVudCBj YXNlLg0KPiA+DQo+ID4gVGhhdCdzIHNhaWQsIHRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgbm90IHNw ZWNpZmljIHRvIElTUHMuIEl0DQo+IGFwcGxpZXMsDQo+ID4gZm9yIGV4YW1wbGUsIHdoZW4gZ2F0 ZXdheXMgYXJlIG9uIHRoZSBwYXRoIGFuZCBib3RoIHRoZSBDYWxsIEhvbWUNCj4gRE9UUw0KPiA+ IHNlcnZlciBhbmQgQ2FsbCBIb21lIERPVFMgY2xpZW50IHdpbGwgdGh1cyBiZSBtYW5hZ2VkIGJ5 IHRoZSBEQw0KPiA+IHByb3ZpZGVyLCB0aGUgZW50ZXJwcmlzZSBhZG1pbmlzdHJhdG9yLCB0aGUg YWNjZXNzIHByb3ZpZGVyLCBldGMuDQo+ID4NCj4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pg0KPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucw0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+IGRpZmZ1c2VzLA0KPiA+IGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlDQo+IG1lc3NhZ2UN Cj4gPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZQ0KPiBhaW5zaQ0KPiA+IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50DQo+IHN1c2NlcHRpYmxlcw0KPiA+IGQnYWx0ZXJhdGlv biwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhDQo+ IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+DQo+ID4gVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0 aGV5IHNob3VsZA0KPiBub3QNCj4gPiBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiBhbmQNCj4gPiBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiBoYXZlDQo+ID4g YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4gVGhhbmsgeW91Lg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Dec 23 06:09:50 2020 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 D19803A0FE7; Wed, 23 Dec 2020 06:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 mm6RdYQSK0NK; Wed, 23 Dec 2020 06:09:40 -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 106393A0FE2; Wed, 23 Dec 2020 06:09:39 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4D1FSy2VTnz8tHp; Wed, 23 Dec 2020 15:09:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608732578; bh=4d8lkx8uBrL6luYMsr5c2LaeXA6y+OtE+oI9OPJTMTU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Ow5hQKz8gJJJDv2g/zYZIoz7evQY3f9oViQWT6ZCQ8BKrGtICkuJpUtnfvJr+4+jM coiODxyRU4Frkig3SVhyA7+MqfREzBEBkTtFQTOAHxvyjufPwvLH9WriaC+0OOtOTW dbWzShcFdk3OU6YaTG9GyqUs8RPkR+ErDTGcKbzu5F1BoFEwZLEgvyRgycJkT6Nak9 NGou0EC5x5mXS05iDaC+iRvNfQLxdXRah/z6hHK4W38NPfwZR4nlHCAwyAoTXGUfD2 FvNr/LvPvvE8jubZUzx9aMTWHWmKrGINmZKL1qY6dBiWDxw2JkjOb+6QftOQKuFEsT rZaG7oHgzoVnQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4D1FSy1H5qz3wbT; Wed, 23 Dec 2020 15:09:38 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (No-Response) Thread-Index: AQHW2RFADVSDS+77YE2WSWeKTWYPaaoEtA4Q Date: Wed, 23 Dec 2020 14:09:37 +0000 Message-ID: <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@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="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 (No-Response) 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, 23 Dec 2020 14:09:45 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 10:52 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-core-new-block@ietf.org; core@ietf.org WG > (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block (No- > Response) >=20 > Hello Med, >=20 > > The text we have in the draft does not preclude No-Response (or > any > > solution that will be endorsed by the WG in the future): > > > > If both endpoints support No-Response, they can use it as a > "signal in > > the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last > sentence. > > > > As we don't recommend No-Response (for reasons echoed in your > > message), it is not worth to include much more details on how > > No-Response can be used. >=20 > The only reason for No-Response I echo in my mail is the downref, > and merely showing how these can interoperate does not create a > normative reference. It's quite a stretch to assume people would > read "requires an additional signal" as "could use No-Response". >=20 > Working group documents time and again have outward references like > "One way of doing this is being explored in [draft-...]", which is > clearly non-normative, but at the same time allow the reader to get > at least > *some* indication of how things are meant to be used. [Med] Simply adding a pointer would work for me. We can go for the followin= g change:=20 s/an additional signal in the MAX_PAYLOADS packet/an additional signal in t= he MAX_PAYLOADS packet (e.g., [RFC7967]) >=20 > What makes things worse here is that as long as this specification > does not mention No-Response at all, it is not ensured that it > interoperates well at all with No-Response; thus even if a reader > can make the jump, they'd have to figure out on their own that it's > probably best if No-Response overrides the response behavior of Q- > Block. [Med] Here is where I disagree. As we don't recommend any solution (includi= ng No-Response), it is not up to this document to discuss how to graft the = various pieces.=20=20=20=20 >=20 > > The use of NON is thus superior but requires > > an additional signal in the MAX_PAYLOADS packet to seek for > a 2.31 > > (Continue) from the peer if it is ready to receive the next > set of > > blocks. >=20 > I missed that in the part where I'm asking for whether 2.31 would be > produced. That paragraph really opens more questions than it > answers: If Q-Block is intended to be usable with something to > signal that now would be a good time for a response, then this > almost contradicts the "2.31 > (Continue) Response is not used in the current version" statement. [Med] That statement is factual. It is meant to remind that 2.31 is legal a= nd that it is there as a provision for any future optimization that would r= equire it.=20 >=20 > Either this is a possibility already planned here, then the 2.31 > cases should be properly described, even if it's just with a "but > requires additional signaling, which for example can be achieved by > combining this with No-Response:0". Or it's not planned out here, > then the 2.31 mentioned in the quoted note is more of a note on > future updates of Q-Block that would be necessary to leverage that > combination (but I don't see any such document happening). >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to > greater powers. > -- Bene Gesserit axiom ___________________________________________________________________________= ______________________________________________ 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 Wed Dec 23 06:27:28 2020 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 49D483A0FFB; Wed, 23 Dec 2020 06:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 hnOsfdNSS9tu; Wed, 23 Dec 2020 06:27:26 -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 A85373A0FF7; Wed, 23 Dec 2020 06:27:25 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4D1FsR0plkzCr8R; Wed, 23 Dec 2020 15:27:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608733643; bh=I6pd2jrnslqK5SEc4yQC2ixBuUVn3KD08Awrjpmoz5g=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=NrWWBj12Kv0O6RJsUJ8aRxs/NC1j0nmbdW1io4+ayn9tVk4Y6C9Pm+W1G3u9MC0xh TVvN2tfJnmpp4Ec1KYR3tnSP9bVtYp4T5moX6VIA/mEN1h1uIKPp/iSPVkEIS28Ku4 fWkGCGVbgouwVLrcwkc+5LN/YaCkUANHyBUAQR67TauyrTHpUwXt6mZVunIPK45+a+ z8ECzzreKEuWSI4YRBNbOYt6l6mSy7ne7uKQz1JOwr6ezDmLls2nRxr3pQOSLqULbg yTM2at/3TNNjThCpQV4noNfecHAEF5KAxGFYAHTRropZAWeJDblzxBlsPdPnVzFJUl 4Y3Z1YqtoHI+Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4D1FsQ6qVyzFpX6; Wed, 23 Dec 2020 15:27:22 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) Thread-Index: AQHW2Rfx+Vo2GwnatkCDylILiJ0E+aoEusMw Date: Wed, 23 Dec 2020 14:27:22 +0000 Message-ID: <10267_1608733643_5FE353CA_10267_151_1_787AE7BB302AE849A7480A190F8B9330315A1CB6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@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="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 (Congestion Control) 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, 23 Dec 2020 14:27:27 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 11:39 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-core-new-block@ietf.org; core@ietf.org WG > (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block > (Congestion Control) >=20 > Hello, >=20 > On Wed, Dec 23, 2020 at 09:14:09AM +0000, > mohamed.boucadair@orange.com wrote: > > You are completely right that the default probing-rate is to be > > increased for the DOTS case. FYI, this is why we went with the > > following in RFC8782: > > > > We avoided to include a pointer to these details as these are > > application-specific and that, even if the draft is motivated by > the > > DOTS use case, other applications can make use of the new block > > functionality. >=20 > At least a one-line reference into there would be helpful when > reading the congestion control section. It can be phrased as an > example ("For the particular use case of DOTS, these parameters are > negotiated; even when not negotiated, that application uses altered > defaults as in > [ref-into-dots]") to avoid the impression of general applicability, > but some example *should* be given, for without changed parameters > the Q-Block mechanism is useless (3 hour wait if all 10 initial > messages are lost). [Med] OK. I added this note:=20 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]. >=20 > > For NSTART, we already have the following: > > > > "NSTART will also need to be increased from the default > > (1) to get faster transmission rates." >=20 > It would enhance readability if that were mentioned in the > congestion control section. [Med] Good point.=20 >=20 > It may help to draw the parallel to the MAX_PAYLOADS of the non- > confirmable case, or to talk more about the hybrid transmission (CON > only after some blocks; does that have a name? see also comment > around "seems to imply that the full exchange"). >=20 > Does DOTS have an altered default here? [Med] No.=20 Without having *anything* > about > non-1 NSTART, the all-CON case may not even be worth having in an > example, as there's nothing even referenced where it could make > sense. [Med] We do already say the following for the CON examples: "These examples assume NSTART has been increased to at least 4." Again, these examples are here to generalize the procedure rather than keep= ing it DOTS-centric.=20 >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to > greater powers. > -- Bene Gesserit axiom ___________________________________________________________________________= ______________________________________________ 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 Dec 24 00:51:56 2020 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 A1E7B3A10F5; Thu, 24 Dec 2020 00:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 MKCaVyqlR2vz; Thu, 24 Dec 2020 00:51:45 -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 0ADDC3A10FA; Thu, 24 Dec 2020 00:51:45 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4D1kMg25nJz2y3k; Thu, 24 Dec 2020 09:51:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608799903; bh=g/PMt+geeljWMQHwpcpgiJlng07DGrBWRtn/35Lfxlk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Myr1F7TmJZUsSR/GgW+QLGL3NGFrvFPm4CF2S8EGeKS+JNxgTgQAlVceRxB6Qxs7K 89nUHkW/lYP/Qflgj07P/t2MxB6uOF9G7fW/52HXwn6wGhYM+1unHFWpICnCBbBAa9 D/sxJhO/BirbMHVIKX6dJ7nBKUc+7CG0lUD9UJrOWoKFwcetJIHOqnQ6t7xDM0ghpv u0TZ8rmi1q3lXEOxkQHc3RCg70SU4XpBSvrrVRZaSK0izFJ+WaUW74Yi2B0wi0aDCN 9Efem+/qKwnynyLlFPwK0oU3J5Um/vJUeGYCQqRSttzFbrFF2iruDRVjMJs1ICsUZI OwwpzCzM8/Jrw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4D1kMg0fgmz5vNK; Thu, 24 Dec 2020 09:51:43 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-ietf-core-new-block@ietf.org" CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Media type) Thread-Index: AdbZ0f4++PkavJGrTTSydpZLkyGARQ== Date: Thu, 24 Dec 2020 08:51:42 +0000 Message-ID: <13542_1608799903_5FE4569F_13542_412_22_787AE7BB302AE849A7480A190F8B9330315A2233@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (Media type) 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, 24 Dec 2020 08:51:47 -0000 Hi Christian, This one is fixed at: https://github.com/core-wg/new-block/commit/8c3972d3c= 32e2eb9186bb3deb59c865a1a9d37a0=20 For "Applications that use this media type", we used the same generic info = as in RFC 8742.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 06:01 > =C0=A0: draft-ietf-core-new-block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello new-block authors, hello CoRE, >=20 > I've finally managed to have another look at the document (and it's > still the 22nd *somewhere*...). >=20 ... >=20 > * 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. >=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 Thu Dec 24 01:40:17 2020 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 673F63A0C6B for ; Thu, 24 Dec 2020 01:40: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=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 8M6mdR0bilq1 for ; Thu, 24 Dec 2020 01:40: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 2A6833A1127 for ; Thu, 24 Dec 2020 01:40: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 1ksN6L-0000NS-Mx; Thu, 24 Dec 2020 09:40:05 +0000 From: To: , Cc: , References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> In-Reply-To: Date: Thu, 24 Dec 2020 09:40:13 -0000 Message-ID: <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9efsT42/5NWOZF7Ah7uUxJLBzEAIREyNWqyb5urA= 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: Thu, 24 Dec 2020 09:40:12 -0000 Hi Christian, Thanks for this and the time spent thinking about it. Some items have already become separate threads. Otherwise responses inline - part 1. Some of the changes can be seen at https://tinyurl.com/new-block-latest=20 Regards Jon > -----Original Message----- > From: Christian Ams=FCss [mailto: christian@amsuess.com] > Sent: 23 December 2020 05:01 > To: draft-ietf-core-new-block@ietf.org > Cc: dots@ietf.org; core@ietf.org WG (core@ietf.org) > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello new-block authors, hello CoRE, >=20 > I've finally managed to have another look at the document (and it's = still the > 22nd *somewhere*...). >=20 > My over-all summary is that while this document has matured quite a = bit > (and turned out better than I had expected for the special-purpose = blocks it > is), I think that the topic of response suppression and congestion = control > sections still have to be sharpened, and the examples could pick a = more > realistic balance between going all-NON and all-CON (or explain why = that's > something that wouldn't be done even though the text reads like that's > what's expected to be used but maybe it's just me). >=20 >=20 > Except for the first item (which is coming back to the notes for the WGLC), > all should be more or less sequential in the document (with = forward/back > references as needed). >=20 > * On the downref to No-Response: I don't see the downref as too big an > issue. It's a bit odd that that document didn't go through the CoRE > WG, but my impression is that it's widely used (on a "when the = library > I maintain broke it people filed issues" level), and both OSCORE and > groupcomm-bis (which is to replace RFC7390) reference it. It's an > informative reference because they don't mechanically depend on it, > but it shows how well No-Response has been taken up. >=20 > (Frankly, I'd support a retroactive adoption. I don't suppose we can > do that with "adults"?). >=20 > From how I understand Q-Block to be intended to work, No-Response = does > not cover all of the behavior (as it's timeout based); still, that > document lays good groundwork for what's done here in a rather = precise > way (see comment on "For Confirmable transmission, the server MUST > continue" later on) where this document needs the examples to be = fully > understood. >=20 > Based on the later text on MAX_TRANSMIT_SPAN, why not at least > acknowledge the equivalence? Maybe like this: >=20 > > The behavior of endpoints following this draft can equivalently b > > described in terms of the No-Response option {{?RFC7967}}: > > > > For a message with a Q-Block1 option with M=3D1 that is followed = by > > another message on the same Request-Tag within MAX_TRANSMIT_SPAN > [ > > or MAX_BLOCK_JITTER, see later ], the default value for = No-Response > > is 8 (suppressing the 4.xx code that would be returned due to the > > incomplete request); an explicitly set No-Response option would > > override that." >=20 > although I'd still advocate just using No-Response for the whole > definition even if No-Response is not typically expressed. >=20 > (I'm not really sure what the correct response would be for an > individual non-terminal request if it were to be answered due to an > explicit No-Response:0 -- might be 2.31 Continue that's just not > used in this specification because it's always suppressed? I'll come > back to that -- but then it'd rather be No-Response: 10). >=20 > * intro: WebSockets (capitalization) [Jon] OK >=20 > * 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: >=20 > * The Q-Block options do not support stateless operation / random > access. [Jon] Actually Q-Block2 does now support this following the redefinition = of the M bit usage in a previous iteration (with M=3D0 you can ask for any individual block). [Jon] For stateless, Request-Tag is included so this should be fine. https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#sectio= n-4 .2 >=20 > * Proxying of Q-Block is limited to caching full representations. >=20 > (The latter might be mitigated by additional text around caching, = but > I doubt it's worth the effort given it's not part of the use case). [Jon] I am not entirely convinced that Block1/2 have got the caching by block properly sorted out - e.g. what happens when different clients = make requests with different SZX and Block2 is part of the cache key. The limiting to caching full representations is there so that a new can of = worms is not opened up. [Jon] I will see if I can think of any further cons. >=20 > * "compromises of": I don't understand that sentence. [Jon] OK s/compromises of/comprises of/ >=20 > * "the asymmetrical packet loss is not a benefit here": It never is; > what is meant here? [Jon] OK. How about (which is obvious, but a reminder to the = implementer) OLD However, the asymmetrical packet loss is not a benefit here. NEW However, the use of Confirmable messages will not work if there = asymmetrical packet loss.=20 >=20 > * "Updated CoAP Response Code": "This document updates" sounds like a > formal update to RFC7959, which it neither is nor needs to be. > Phrasing it along the lines of "adds a media type that can be used > with 4.08" would ease that. [Jon] OLD 1.2. Updated CoAP Response Code (4.08) This document updates the 4.08 (Request Entity Incomplete) by defining an additional message format for reporting on payloads using the Q-Block1 Option that are not received by the server. NEW 1.2. CoAP Response Code (4.08) Usage This document adds a media type for the 4.08 (Request Entity Incomplete) response defining an additional message format for reporting on payloads using the Q-Block1 Option that are not received=20 by the server. >=20 > * "Only C and U columns are marked": "The Q-Block1 option is critical, = and > unsafe for proxies to forward" would be easier to read -- which > checkboxes are marked is visible alrady from the table. (Or just = leave > it for the later paragraphs that say that in more detail). [Jon] OK. Gone with Critical etc. >=20 > * "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using the > Q-Block1 option" first paragraph). [Jon] OK >=20 > * "Is opaque in nature, but it is RECOMMENDED" on being a counter and > starting off random: Like other similar suggestions (ETag), this is > implementation guidance level and not required for interoperability. > Maybe phrase this the same way as the recommendations on tokens? [Jon] OLD The Request-Tag is opaque in nature, but it is RECOMMENDED that the client treats it as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The server still treats it as an opaque entity. The Request-Tag value MUST be different for distinct bodies or sets of blocks of data and SHOULD be incremented whenever a new body of data is being transmitted between peers. The initial Request-Tag value SHOULD be randomly generated by the client. NEW The Request-Tag is opaque, the server still treats it as opaque but the client SHOULD ensure that it is unique for every different body of transmitted data. Implementation Note: It is suggested that the client treats the = Request-Tag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial Request-Tag value should be randomly generated and then subsequently incremented by the client whenever a new body of data is = being transmitted between peers. OLD The ETag is opaque in nature, but it is RECOMMENDED that the server treats it as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The client still treats it as an opaque entity. The ETag value MUST be different for distinct bodies or sets of blocks of data and SHOULD be incremented whenever a new body of data is being transmitted between peers. The initial ETag value SHOULD be randomly generated by the server. NEW The ETag is opaque, the client still treats it as opaque but the = server SHOULD ensure that it is unique for every different body of transmitted data. Implementation Note: It is suggested that the server treats the ETag as = an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial ETag value should be randomly generated and then = subsequently incremented by the server whenever a new body of data is being transmitted between peers.=20 >=20 > * "For Confirmable transmission, the server MUST continue": This reads > like new-block could change anything about that, when all it does is > do things on the response level. [1] has a good note on that > separation topic. >=20 > [1]: https://tools.ietf.org/html/rfc7967#section-2 [Jon] The intent here was that CON continues to work for each request/response in that the request needs to be acknowledged, but a response (piggybacked or separate) is not required. OLD For Confirmable transmission, the server MUST continue to acknowledge each packet. NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until retransmission or successful receipt of the body. [Jon] To be continued in part 2.