From nobody Tue Sep 1 07:19:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E2D3A08EB; Tue, 1 Sep 2020 07:19:43 -0700 (PDT) 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 G3Cfl3IrgEtl; Tue, 1 Sep 2020 07:19:42 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00047.outbound.protection.outlook.com [40.107.0.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 8FA553A0907; Tue, 1 Sep 2020 07:19:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eHmJPqGzTYShSBRz8pBjdhxFAZmBpDYdjZBNZlbY26uS9Z6jXtDU4+3f2/oPmxmGpcQcDTjstu8yHFynoZq1LUCDViaob/IZL4LuLW2GOMa/LFUKg2aFr4yKVD98xEWoaYDF84qXxMM3fR5ga/C+sCNjSR6+Dv5asRoM+R13k7c3CjuU02Jnkaol01jNz4TZzK0S3kRFq9Q7CBOj5KrE+btIQdqqXF90t32hcLoJyJvTBI429c8M98S8cnTylEtmQXEH4F+9j5JMMiCb1zuczHbl53dAoAv1uJOSM/f/atb5Y2LH28JpNfkUfHCY6jFhpYJ/jo+9wvBzdDvTD/Vj2Q== 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=Yp1mRuGHFSahJE07raFcXad+qli7I14xmcDmAKSvScc=; b=d0GuN0Z9NDN7PMXqH5kHq+nbh28CnSuFK5BYr5YL4TSJy31rAL6PhFGoZ1NKPn33DwH/Eyf/rMDnDwbWGpk1Clu29AZWoGJpMVhRoGvWLCoR/pWLjVzuJfuAIdAECGpQHP+0h9XjGgRdhavNnIRLuoAXGwSEo2SuNLt570hwCGh22747vlF7o6/ey8W1yH9+NgYGt5e5lW+yfPc4r88Tv6YUmRBCta0AugJdjFoYARv29hEEBEeiYqDUhEllE5LBvllKEKGk21Ff9a6OUfRqCXV7q8jIQUX3ajYBFkwDu1M82BoCOETa6m/FXfX0onGgvpGAXusLIXN7dJHTsQkmMQ== 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=Yp1mRuGHFSahJE07raFcXad+qli7I14xmcDmAKSvScc=; b=eIHtgpciwTKNoza0PXbFlSi2M4MPa8wbK0qAt4vJ1xb1rqgfS6A8cTU9KnW889Kvw6cH5iYgbEU1WspUKOdVJD7LOHPk4s9Y8oxyWsiHiwbqfK4tEhv8Lfqe08d0eXCShEikzITrLV4OT/sh5Xr5j4fCVpDyk+PsPw5enIAlVf8= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR0701MB2634.eurprd07.prod.outlook.com (2603:10a6:3:98::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Tue, 1 Sep 2020 14:19:38 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3348.014; Tue, 1 Sep 2020 14:19:38 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Barry Leiba , "draft-ietf-core-echo-request-tag.all@ietf.org" CC: "core@ietf.org" Thread-Topic: AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWag2783ig3eTTLEWqbjvVPkqoAKlTipYA Date: Tue, 1 Sep 2020 14:19:38 +0000 Message-ID: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61c62f4f-758c-4d21-2742-08d84e820f7d x-ms-traffictypediagnostic: HE1PR0701MB2634: 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: 0F+gKpLmFK1vh4fsRMQqCeRrwy2H6CznghNEfba9oNEKFBVX3NqP81BcbIFYZVG3K20fLCidOMa/OnakfIrNDfS5O1jGT40jeKHy5bLEPmxFCgaTwnSEsp1IF+DnO288YaqETpMYP+sYZxpFptMxEEu3jUjkvNY3jZpVXPZk51vOqTG04oPGWSm5l8v8JMMo5vMOsHah1r1nL8brF96mUgYn1jE/V//1byb2oZJhiDKklUubcnFCN4/hL3rCwCuLJ2HuMnxk0qChi4e248SzjuPbvm+wmIrJnWHXLBcUw8d25IkEdewGg6OmztfYoqUXoTwu6tyRD2KiNlv6o8G02FN0a4Ou4hWU/P9QlJsyMVyIqjn4xc8LlG2wNaSP2CHA4PlavwIlYKiGf5arskQVQg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(366004)(346002)(39860400002)(6506007)(85202003)(478600001)(186003)(33656002)(26005)(8676002)(18074004)(6486002)(6512007)(2616005)(966005)(8936002)(5660300002)(76116006)(66476007)(2906002)(4326008)(36756003)(86362001)(66446008)(110136005)(66946007)(64756008)(66556008)(316002)(71200400001)(66574015)(83380400001)(85182001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VtfGh7824HsX0SZq8UiWlZl5QLAZfRR+6QIf0b6/Wa/8jhh0qxFiJw8RnzpnCCw9iVZz8I+x18/qh7aZNXZGToIwjypPhKS4rzefqOZBS3qaIMX8OvZeplxfRYJy7inc8FCUbMaafSBSjhwW5GPn7oKcp6hZry2+mvPEl09TSOoFJTPZW5Q3GwUvapl+Ja6Q0/dTYhAf8Y3diwskRgpYdwGhznfGZoS7ZadFhh+eIgPgSAIPp/g6bT/kVFJD/wdpRFaTHVKDr4pCeOb/E8XsjVXmGqDIcRj85kfo09M6OaWR0y2ePczpliDEn9uNBdy0Iagt+Lsj4/JHNGD6xv230M0Ux+YjDeu89Dvx90/Y9XOlltFHnLOXhzkf3QGiE9gL8pFA29sxAu/OQS7OPARUH+ohBvdXTS4eHXPK14r4ymqX8BCLdZOG6WloImiPzpfsEemrmHP9Wh/TKtos5v2A1iyGX53ZhnYwz55oTnqnhaMas91iT7kTX6Cu2wXhhJqtWzP3na1Kk3McF+RyauRnx7x2Dwr0Tdl2tRDJCQkWrprALt4cNx6mZ+UEfx2lZbYxEWci1PDEw9H9Oo9R86b5fhkr9cEP0u+efMo17sCcVJLfQVGH5YVnVELz099L8j6/ItZwrdvuYnlkfgHJuAceeQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8CDFFFBD2FA6EB468BE4731FBF3AC21F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61c62f4f-758c-4d21-2742-08d84e820f7d X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 14:19:38.4221 (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: wq+lrvhrTd2rx9M4GH6dR+PlW1BwtiaHWQLJ4m8VDLdlioTAOv5Kcwv1XDBxlfRXUh1GX/jvicsRkt/YB8i2NaoABCLaYIvkNeClIK2IL9s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2634 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 14:19:44 -0000 SGkgQmFycnksDQoNClNvcnJ5IGZvciB0aGUgc2xvdyByZXNwb25zZS4gSSBtaXNzZWQgdGhpcyBt YWlsIGluIHRoZSBwaWxlIHdhaXRpbmcgYWZ0ZXIgdmFjYXRpb24uIA0KDQpUaGFua3MgZm9yIHlv dXIgY29tbWVudHMsIHJlc3BvbnNlcyBpbmxpbmUgYmVsb3cuIEkgbWFkZSBhIGNvbW1pdCBvdXQg b2YgbXkgcmVzcG9uc2VzOg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvZWNoby1yZXF1ZXN0 LXRhZy9jb21taXQvZDM3ZmY2NA0KDQpNeSBjby1hdXRob3JzIGhhdmUgbm90IHJlYWQgdGhpcyBz byBtYXkgYWxzbyBoYXZlIHNvbWUgaW5wdXQuIFdoZW4gdGhlcmUgYXJlIG5vIGZ1cnRoZXIgY29t bWVudHMgb24gdGhpcyBwYXJ0IHdlIHdpbGwgc3VibWl0IC0xMS4NCg0K77u/T24gMjAyMC0wOC0w NCwgMDU6MTcsICJCYXJyeSBMZWliYSIgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPiB3cm90ZToN Cg0KICAgIFRoYW5rcyBmb3IgdGhlIHdvcmsgb24gdGhpcyBkb2N1bWVudC4gIEkgaGF2ZSBhIG51 bWJlciBvZiBjb21tZW50cyBhYm91dA0KICAgIHRoaW5ncyB0aGF0IEkgdGhpbmsgbmVlZCBjbGFy aWZpY2F0aW9uIG9yIHJld29yZGluZyBpbiBteSByZXZpZXcgYmVsb3csIHNvDQogICAgSeKAmW0g c2V0dGluZyB0aGUgc3RhdGUgb24gdGhlIGRvY3VtZW50IHRvIOKAnHJldmlzZWQgSS1EIG5lZWRl ZC7igJ0gIFBsZWFzZSBhc2sNCiAgICBpZiB5b3UgaGF2ZSBxdWVzdGlvbnMgb3IgZGlzYWdyZWVt ZW50cyB3aXRoIGFueXRoaW5nIGJlbG93LCBhbmQgbGV04oCZcw0KICAgIGRpc2N1c3MgYW55dGhp bmcgdGhhdCBuZWVkcyBkaXNjdXNzaW9uLg0KDQogICAgSSB3b3VsZCBwcmVmZXIgaXQgaWYgdGhl IGRvY3VtZW50IHdlcmUgc3BlY2lmaWMgYWJvdXQgd2hhdCDigJx3aGVuIENvQVAgaXMNCiAgICB1 c2VkIHdpdGggc2VjdXJpdHnigJ0gbWVhbnMsIGlkZWFsbHkgbm90IHVzaW5nIHRoYXQgcGhyYXNl IGF0IGFsbCwgYXMNCiAgICDigJxzZWN1cml0eeKAnSB3aXRob3V0IGV4cGxhbmF0aW9uIGlzbuKA mXQgbWVhbmluZ2Z1bC4gIElmIHlvdSBtZWFuIOKAnG92ZXIgYW4NCiAgICBlbmNyeXB0ZWQgY2hh bm5lbOKAnSwgcGxlYXNlIHNheSB0aGF0LiAgT3Igc29tZXRoaW5nIGVsc2U/DQoNCltHU10gSXMg dGhlIGZvcm11bGF0aW9uIG9mIHNlY3Rpb24gNC4yIGJldHRlciwgaS5lLiAid2hlbiBDb0FQIGlz IHVzZWQgd2l0aCBhIHNlY3VyaXR5IHByb3RvY29sIj8NClRoZSB0ZXh0IGluIHRoZSBhYnN0cmFj dCB3b3VsZCB0aGVuIHJlYWQ6DQoiVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzcyNTIgd2l0aCBy ZXNwZWN0IHRvIHRoZSBjbGllbnQgVG9rZW4gcHJvY2Vzc2luZyByZXF1aXJlbWVudHMsIGZvcmJp ZGRpbmcgbm9uLXNlY3VyZSByZXVzZSBvZiBUb2tlbnMgdG8gZW5zdXJlIGJpbmRpbmcgb2YgcmVz cG9uc2UgdG8gcmVxdWVzdCB3aGVuIENvQVAgaXMgdXNlZCB3aXRoIGEgc2VjdXJpdHkgcHJvdG9j b2wsICINClRoZSByYXRpb25hbGUgdG8gbWVudGlvbiAid2hlbiBDb0FQIGlzIHVzZWQgd2l0aCBh IHNlY3VyaXR5IHByb3RvY29sICIgaGVyZSBpcyB0aGF0IGEgbGF5bWFuIHdvdWxkIGV4cGVjdCBh IGJpbmRpbmcgYmV0d2VlbiByZXNwb25zZSBhbmQgcmVxdWVzdCB0byBob2xkIHdoZW4gQ29BUCBp cyB1c2VkIHdpdGggYSBzZWN1cml0eSBwcm90b2NvbCAoaW4gY29udHJhc3QgdG8gd2hlbiBDb0FQ IGlzIHVzZWQgd2l0aG91dCBhIHNlY3VyaXR5IHByb3RvY29sLCB3aGVuIG5vIGJpbmRpbmcgaXMg ZXhwZWN0ZWQpIGFuZCB3b3VsZCB0aGVyZWJ5IGJlIHN1cnByaXNlZCB0aGF0IHRoZSBwcm9wZXJ0 eSBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IGhvbGQsIGUuZy4sIGZvciBDb0FQIHdpdGggRFRMUywg YnV0IGFkZGl0aW9uYWxseSByZXF1aXJlcyByZXN0cmljdGVkIHVzZSBvZiBUb2tlbnMuDQoNCg0K ICAgIOKAlCBTZWN0aW9uIDEuMSDigJQNCg0KICAgICAgIFVubGVzcyBvdGhlcndpc2Ugc3BlY2lm aWVkLCB0aGUgdGVybXMgImNsaWVudCIgYW5kICJzZXJ2ZXIiIHJlZmVycyB0bw0KDQogICAgTml0 OiDigJxyZWZlciB0b+KAnSwgcGx1cmFsLg0KDQpbR1NdIERvbmUuDQoNCiAgICAgICBUaGUgY29t cGxldGUgaW50ZXJjaGFuZ2Ugb2YgYSByZXF1ZXN0IGFuZCBhIHJlc3BvbnNlIGJvZHkgaXMgY2Fs bGVkIGENCiAgICAgICAoUkVTVCkgIm9wZXJhdGlvbiIuDQoNCiAgICDigJxSRVNU4oCdIHdpbGwg bmVlZCBleHBhbnNpb24gYW5kIGEgcmVmZXJlbmNlLiAgWW91IGNhbiBjb3B5IHRoZXNlIGZyb20g NzI1Mi4NCg0KW0dTXSBEb25lLg0KDQogICAgICAgVHdvIHJlcXVlc3QgbWVzc2FnZXMgYXJlIHNh aWQgdG8gYmUgIm1hdGNoYWJsZSIgaWYgdGhleSBvY2N1ciBiZXR3ZWVuDQogICAgICAgdGhlIHNh bWUgZW5kcG9pbnQgcGFpciwgaGF2ZSB0aGUgc2FtZSBjb2RlIGFuZCB0aGUgc2FtZSBzZXQgb2YN CiAgICAgICBvcHRpb25zIGV4Y2VwdCBmb3IgZWxlY3RpdmUgTm9DYWNoZUtleSBvcHRpb25zIGFu ZCBvcHRpb25zIGludm9sdmVkDQogICAgICAgaW4gYmxvY2std2lzZSB0cmFuc2ZlciAoQmxvY2sx LCBCbG9jazIgYW5kIFJlcXVlc3QtVGFnKS4NCg0KICAgIFRoZXJl4oCZcyBzb21ldGhpbmcgbWlz c2luZyBoZXJlOiB0aGlzIHNheXMsIOKAnFggaXMgdHJ1ZSBpZiBBLCBCLuKAnSAgSXQgbmVlZHMN CiAgICBhbiDigJxhbmTigJ0gb3IgYW4g4oCcb3LigJ0gaW5zdGVhZCBvZiB0aGUgY29tbWEsIG5v Pw0KDQpbR1NdIFRoZSBpbnRlbnRpb24gd2FzIOKAnFggaXMgdHJ1ZSBpZiBBLCBCLCBhbmQgQy7i gJ0gIERvZXMgdGhpcyByZWFkIGJldHRlcj8NCiJUd28gcmVxdWVzdCBtZXNzYWdlcyBhcmUgc2Fp ZCB0byBiZSAibWF0Y2hhYmxlIiBpZiB0aGV5IG9jY3VyIGJldHdlZW4gdGhlIHNhbWUgZW5kcG9p bnQgcGFpciwgaGF2ZSB0aGUgc2FtZSBjb2RlLCBhbmQgdGhlIHNhbWUgc2V0IG9mIG9wdGlvbnMg d2l0aCB0aGUgZm9sbG93aW5nIGV4Y2VwdGlvbjogZWxlY3RpdmUgTm9DYWNoZUtleSBvcHRpb25z IGFuZCBvcHRpb25zIGludm9sdmVkIGluIGJsb2NrLXdpc2UgdHJhbnNmZXIgKEJsb2NrMSwgQmxv Y2syIGFuZCBSZXF1ZXN0LVRhZykgbmVlZCBub3QgYmUgdGhlIHNhbWUuIg0KDQogICAgICAgVHdv IG1hdGNoYWJsZSBibG9jay13aXNlIG9wZXJhdGlvbnMgYXJlIHNhaWQgdG8gYmUgImNvbmN1cnJl bnQiIGlmIGENCiAgICAgICBibG9jayBvZiB0aGUgc2Vjb25kIHJlcXVlc3QgaXMgZXhjaGFuZ2Vk IGV2ZW4gdGhvdWdoIHRoZSBjbGllbnQgc3RpbGwNCiAgICAgICBpbnRlbmRzIHRvIGV4Y2hhbmdl IGZ1cnRoZXIgYmxvY2tzIGluIHRoZSBmaXJzdCBvcGVyYXRpb24uDQoNCiAgICBUaGlzIGFwcGVh cnMgdG8gZGVzY3JpYmUgY29uY3VycmVudCBibG9jay13aXNlIHJlcXVlc3Qgb3BlcmF0aW9ucy4g IENhbg0KICAgIHRoZXJlIGFsc28gYmUgY29uY3VycmVudCBibG9jay13aXNlIHJlc3BvbnNlIG9w ZXJhdGlvbnM/DQoNCltHU10gVGhlIG9ubHkgYXNwZWN0IG9mIGNvbmN1cnJlbmN5IHdlIG5lZWQg dG8gYWRkcmVzcyBoZXJlIGFyZSB0aG9zZSBvZiBjb25jdXJyZW50IHJlcXVlc3RzLiBUaGUgQ29B UCBvcHRpb24gRVRhZyBjYW4gaGFuZGxlIGRpc3RpbmN0aW9uIGJldHdlZW4gcmVzcG9uc2VzIGFz IGlzIGRlc2NyaWJlZCBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gMy4xIGFuZCBiZWdpbm5pbmcgb2Yg c2VjdGlvbiAzLjIuDQoNCg0KICAgIOKAlCBTZWN0aW9uIDIuMiDigJQNCg0KICAgICAgIGJ1dCBh bHNvIGluIGdlbmVyYWwgZm9yIHN5bmNocm9uaXppbmcgc3RhdGUgYmV0d2VlbiBDb0FQDQogICAg ICAgY2xpZW50IGFuZCBzZXJ2ZXIsIGNyeXB0b2dyYXBoaWNhbGx5IHZlcmlmeSB0aGUgYWxpdmVu ZXNzIG9mIHRoZQ0KICAgICAgIGNsaWVudCwgb3IgZm9yY2UgYSBjbGllbnQgdG8gZGVtb25zdHJh dGUgcmVhY2hhYmlsaXR5IGF0IGl0cyBjbGFpbWVkDQoNCiAgICBOaXQ6IFRoaXMgaXNu4oCZdCBw YXJhbGxlbDogdGhlIGZpcnN0IGl0ZW0gdXNlcyDigJxzeW5jaHJvbml6aW5n4oCdLCBzbyB0aGUN CiAgICBzZWNvbmQgc2hvdWxkIHVzZSDigJx2ZXJpZnlpbmfigJ0gYW5kIHRoZSB0aGlyZCBzaG91 bGQgdXNlIOKAnGZvcmNpbmfigJ0uDQoNCltHU10gRG9uZS4NCg0KICAgIOKAlCBTZWN0aW9uIDIu MyDigJQNCg0KICAgICAgIE9uZSB3YXkgZm9yIHRoZSBzZXJ2ZXIgdG8gdmVyaWZ5IGZyZXNobmVz cyBpcyB0aGF0IHRvIGJpbmQgdGhlIEVjaG8NCg0KICAgIE5pdDogVGhlcmUgYXBwZWFycyB0byBi ZSBhbiBleHRyYSB3b3JkLCDigJx0aGF04oCdLg0KDQpbR1NdIERvbmUuDQoNCiAgICAgICAoSW4g bW9zdCBjYXNlcywgdGhpcyBtZWFucyB0aGF0IHRoZSBwcm94eQ0KICAgICAgIG5lZWRzIHRvIGFz ayB0aGUgY2xpZW50IHRvIHJlcGVhdCB0aGUgcmVxdWVzdCB3aXRoIGEgbmV3IEVjaG8gdmFsdWUp Lg0KDQogICAgTml0OiB0aGUg4oCcLuKAnSBuZWVkcyB0byBiZSBpbnNpZGUgdGhlIHBhcmVudGhl c2VzLg0KDQpbR1NdIERvbmUuDQoNCiAgICDigJQgU2VjdGlvbiAzLjMg4oCUDQoNCiAgICAgICBy ZXN1bHRzIGluIHRoZSBuZXcgbWVzc2FnZSBub3QgYmVpbmcgcGFydCBvZiBoZSBvbGQgb3BlcmF0 aW9uLg0KDQogICAgVHlwbzog4oCcdGhlIG9sZOKAnQ0KDQpbR1NdIERvbmUuDQoNCiAgICDigJQg U2VjdGlvbiAzLjQg4oCUDQoNCiAgICAgICBXaGF0IGNvbnN0aXR1dGVzIGEgY29uY2x1ZGVkIG9w ZXJhdGlvbg0KICAgICAgIGRlcGVuZHMgb24gdGhhdCBwdXJwb3NlLCBhbmQgaXMgZGVmaW5lZCB0 aGVyZS4NCg0KICAgIEnigJltIG1pc3NpbmcgdGhlIGFudGVjZWRlbnQgdG8g4oCcdGhlcmXigJ0u ICBXaGVyZT8NCg0KW0dTXSBJIHJlcGxhY2VkICJ0aGVyZSIgd2l0aCAiYWNjb3JkaW5nbHkiIGFu ZCByZXBlYXRlZCB0aGUgcmVmZXJlbmNlIHRvIHRoZSBhcHBsaWNhdGlvbnM6DQoiV2hhdCBjb25z dGl0dXRlcyBhIGNvbmNsdWRlZCBvcGVyYXRpb24gZGVwZW5kcyBvbiB0aGUgcHVycG9zZSwgYW5k IGlzIGRlZmluZWQgYWNjb3JkaW5nbHksIHNlZSBleGFtcGxlcyBpbiBTZWN0aW9uIDMuNS4iDQoN Cg0KICAgICAgIFRoZSBSZXF1ZXN0LVRhZyBvcHRpb25zIE1BWSBiZSBwcmVzZW50IGluIHJlcXVl c3QgbWVzc2FnZXMgdGhhdCBjYXJyeQ0KICAgICAgIG5vIEJsb2NrIG9wdGlvbiAoZm9yIGV4YW1w bGUsIGJlY2F1c2UgYSBSZXF1ZXN0LVRhZyB1bmF3YXJlIHByb3h5DQogICAgICAgcmVhc3NlbWJs ZWQgdGhlbSksIGFuZCBNVVNUIGJlIGlnbm9yZWQgaW4gdGhvc2UuDQoNCiAgICBJIHRoaW5rIHRo aXMgc2hvdWxkIGJlIOKAnG1heeKAnSAob3Ig4oCcbWlnaHTigJ0pLCBub3Qg4oCcTUFZ4oCdLiAg WW914oCZcmUgbm90DQogICAgc3VnZ2VzdGluZyBpdCBhcyBhbiBvcHRpb24gdG8gZG8sIGJ1dCBh cmUgaW5zdGVhZCB3YXJuaW5nIGFib3V0IHNvbWV0aGluZw0KICAgIHRoYXQgbWlnaHQgaGFwcGVu Lg0KDQpbR1NdIENoYW5nZWQgdG86DQoiTm90ZSB0aGF0IFJlcXVlc3QtVGFnIG9wdGlvbnMgY2Fu IGJlIHByZXNlbnQgaW4gcmVxdWVzdCBtZXNzYWdlcyB0aGF0IGNhcnJ5IG5vIEJsb2NrIG9wdGlv bg0KKGZvciBleGFtcGxlLCBiZWNhdXNlIGEgUmVxdWVzdC1UYWcgdW5hd2FyZSBwcm94eSByZWFz c2VtYmxlZCB0aGVtKSwNCmFuZCBNVVNUIGJlIGlnbm9yZWQgaW4gdGhvc2UuIg0KDQogICAg4oCU IFNlY3Rpb24gMy41LjEg4oCUDQoNCiAgICAgICBpcyBzdGlsbCBwb3NzaWJsZSBmb3IgYSBtYW4t aW4tdGhlLW1pZGRsZSB0byBtYWxpY2lvdXNseSByZXBsYWNlIGENCiAgICAgICBsYXRlciBvcGVy YXRpb24ncyBibG9ja3Mgd2l0aCBhbiBlYXJsaWVyIG9wZXJhdGlvbidzIGJsb2Nrcw0KDQogICAg Tm90IGEgcmVxdWlyZW1lbnQgaGVyZSwgYW5kIEkgd2lsbCBhY2NlcHQgeW91ciBiZXN0IGp1ZGdt ZW50OiAgaW4gdGhlDQogICAgc3Bpcml0IG9mIHJlY2VudCBkaXNjdXNzaW9uIG9uIGluY2x1c2l2 ZSB2cyBleGNsdXNpb25hcnkgbGFuZ3VhZ2UsIEkgYXNrDQogICAgeW91IHRvIGNvbnNpZGVyIGNo YW5naW5nIOKAnGEgbWFuLWluLXRoZS1taWRkbGXigJ0gdG8g4oCcYW4gb24tcGF0aCBhdHRhY2tl cuKAnS4NCg0KW0dTXSBJIHRob3VnaHQgdGhlcmUgd2FzIGEgc2xpZ2h0IGRpZmZlcmVuY2UgYmV0 d2VlbiAib24tcGF0aCBhdHRhY2tlciIgYW5kICJtYW4taW4tdGhlLW1pZGRsZeKAnSwgaW4gdGhh dCB0aGUgbGF0dGVyIGhhcyBhY2Nlc3MgdG8gdGhlIG1lc3NhZ2UgZmxvdyB3aGVyZWFzIHRoZSBm b3JtZXIgbmVlZCBub3QgaGF2ZS4gRm9yIGV4YW1wbGUsIGFuIG9uLXBhdGggYXR0YWNrZXIgbWF5 IG9ubHkgYmUgYWJsZSB0byBpbmplY3QgbWVzc2FnZXMuIEluIHRoaXMgY2FzZSAoInJlcGxhY2Ui KSB0aGUgbGF0dGVyIHdvdWxkIHRoZW4gYmUgbW9yZSBwcmVjaXNlLiBJZiBJJ20gcmlnaHQgdGhl biBJIHByb3Bvc2Ugd2UgdXNlIGF2YWlsYWJsZSBkaXN0aW5jdGlvbnMgcGVuZGluZyBhIG5ldyBk aWN0aW9uYXJ5LCBvdGhlcndpc2UgSSdtIGZpbmUgd2l0aCBjaGFuZ2luZy4NCg0KICAgICAgICAg IGNoYW5nZWQsIHRoZW4gdGhlIGNsaWVudCBNVVNUIGNvbnNpZGVyIG1lc3NhZ2VzIHNlbnQgdG8g X2FueV8NCiAgICAgICAgICBlbmRwb2ludCBhZGRyZXNzIHdpdGhpbiB0aGUgbmV3IG9wZXJhdGlv bidzIHNlY3VyaXR5IGNvbnRleHQuDQoNCg0KICAgIFRoaXMgaXMgYW1iaWd1b3VzLiAgSSB0aGlu ayB5b3UgbWVhbiDigJx0byBiZSB3aXRoaW7igJ0sIHllcz8NCg0KW0dTXSBUbyBtZSwgdGhpcyBy ZWFkcyBiZXR0ZXIgYnkgcmVwbGFjaW5nICJ3aXRoaW4iIHdpdGggInVzaW5nIjoNCiAiSWYgYW55 IGZ1dHVyZSBzZWN1cml0eSBtZWNoYW5pc21zIGFsbG93IGEgYmxvY2std2lzZSB0cmFuc2ZlciB0 byBjb250aW51ZSBhZnRlciBhbiBlbmRwb2ludCdzIGRldGFpbHMgKGxpa2UgdGhlIElQIGFkZHJl c3MpIGhhdmUgY2hhbmdlZCwgdGhlbiB0aGUgY2xpZW50IE1VU1QgY29uc2lkZXIgbWVzc2FnZXMg c2VudCB0byAqYW55KiBlbmRwb2ludCBhZGRyZXNzIHVzaW5nIHRoZSBuZXcgb3BlcmF0aW9uJ3Mg c2VjdXJpdHkgY29udGV4dC4iDQpUaGUgcG9pbnQgaGVyZSBpcyB0aGF0IGEgbmVjZXNzYXJ5IGNv bmRpdGlvbiBmb3IgYSBtYWxpY2lvdXMgcmVwbGFjZW1lbnQgb2YgYmxvY2tzIHRvIHdvcmsgaXMg dGhhdCB0aGUgc2FtZSBzZWN1cml0eSBjb250ZXh0IGlzIHVzZWQsIHNpbmNlIG90aGVyd2lzZSB0 aGUgaW50ZWdyaXR5IHZlcmlmaWNhdGlvbiB3aWxsIGRldGVjdCB0aGUgY2hhbmdlLiBOb3csIGlm IGEgZnV0dXJlIHNwZWNpZmljYXRpb24gYWxsb3dzIHRoZSBzYW1lIHNlY3VyaXR5IGNvbnRleHQg dG8gYmUgdXNlZCBtb3JlIHdpZGVseSwgc2F5LCBldmVuIGlmIElQIGFkZHJlc3MgaGFzIGNoYW5n ZWQsIHRoZW4gdGhlIElQIGFkZHJlc3MgaXMgbm90IHN1ZmZpY2llbnQgdG8gZGV0ZXJtaW5lIHdo YXQgbWVzc2FnZSBleGNoYW5nZXMgdGhhdCBuZWVkcyB0byBiZSBhc3Nlc3MgYXMgY29uY2x1ZGVk IHdoZW4gcmVjeWNsaW5nIGEgUmVxdWVzdC1UYWcgdmFsdWUuIERvZXMgdGhhdCBtYWtlIG1vcmUg c2Vuc2U/DQoNCg0KDQogICAgICAgbyAgVGhlIGNsaWVudCBNVVNUIE5PVCByZWdhcmQgYSBibG9j ay13aXNlIHJlcXVlc3Qgb3BlcmF0aW9uIGFzDQogICAgICAgICAgY29uY2x1ZGVkIHVubGVzcyBh bGwgb2YgdGhlIG1lc3NhZ2VzIHRoZSBjbGllbnQgcHJldmlvdXNseSBzZW50IGluDQogICAgICAg ICAgdGhlIG9wZXJhdGlvbiBoYXZlIGJlZW4gY29uZmlybWVkIGJ5IHRoZSBtZXNzYWdlIGludGVn cml0eQ0KICAgICAgICAgIHByb3RlY3Rpb24gbWVjaGFuaXNtLCBvciBhcmUgY29uc2lkZXJlZCBp bnZhbGlkIGJ5IHRoZSBzZXJ2ZXIgaWYNCiAgICAgICAgICByZXBsYXllZC4NCg0KICAgIEl04oCZ cyBub3QgY2xlYXIgdG8gbWUgaG93IGEgY2xpZW50IGNhbiBjb21wbHkgd2l0aCB0aGlzOiBob3cg Y2FuIHRoZSBjbGllbnQNCiAgICBwb3NzaWJseSBrbm93IHdoZXRoZXIgdGhlIG1lc3NhZ2VzIGl0 IGhhcyBzZW50IHdvdWxkIGJlIGNvbnNpZGVyZWQgaW52YWxpZA0KICAgIGJ5IHRoZSBzZXJ2ZXIg aWYgdGhleSB3ZXJlIHJlcGxheWVkPyAgT3IgaXMgdGhlcmUgc29tZXRoaW5nIEnigJltIG5vdA0K ICAgIHVuZGVyc3RhbmRpbmc/DQoNCltHU10gVGhlIHNpemUgb2YgdGhlIHJlcGxheSBidWZmZXIg d2luZG93IG1heSBiZSBmaXhlZCBieSB0aGUgYXBwbGljYXRpb24gYW5kIGtub3duIHRvIHRoZSBj bGllbnQuIFRoZSB3aW5kb3cgY291bGQgcG90ZW50aWFsbHkgYmUgc2V0IHNtYWxsLCBlLmcuIGlm IHRyYW5zcG9ydGVkIG1lc3NhZ2VzIGFyZSByYXJlbHkgZXJyb25lb3VzLiBJZiB0aGUgY2xpZW50 IHJlY2VpdmVzIGFuIGludGVncml0eSBwcm90ZWN0ZWQgcmVzcG9uc2UgKG5vdCBuZWNlc3Nhcmls eSByZWxhdGVkIHRvIHRoZSBvcGVyYXRpb24gaW4gcXVlc3Rpb24pIGl0IGNvdWxkIGRlZHVjZSB0 aGF0IHRoZSByZXBsYXkgd2luZG93IGhhdmUgc2xpZGVkIHBhc3QgYWxsIG1lc3NhZ2VzIHJlbGF0 ZWQgdG8gdGhlIG9wZXJhdGlvbiBpbiBxdWVzdGlvbiwgYW5kIHRoZXJlZm9yZSB0aGUgc2VydmVy IHdvdWxkIG5vdCBhY2NlcHQgcmVwbGF5IG9mIG1lc3NhZ2VzIG9mIHRoaXMgb3BlcmF0aW9uLg0K DQpXaGlsZSB0aGlzIG1heSBub3QgYmUgYSBjb21tb24gbWV0aG9kLCBpdCBpcyBwb3NzaWJsZSB0 byBpbmZlciBzdWNoIGluZm9ybWF0aW9uIGFuZCBjb25zaWRlcmluZyB0aGlzIGlzIGEgIk1VU1Qg Tk9UIiByZXF1aXJlbWVudCB3ZSB3YW50ZWQgdG8gYWxsb3cgZm9yIHRoYXQuDQoNCiAgICBIb25l c3RseSwgSeKAmW0gaGF2aW5nIHRyb3VibGUgZm9sbG93aW5nIHRoZSBleHBsYW5hdGlvbnMgaW4g dGhpcyBzZWN0aW9uLCBpbg0KICAgIGdlbmVyYWwsIHNvIHRoZXJl4oCZcyBhIHJlYXNvbmFibGUg Y2hhbmNlIHRoYXQgSSBhbSBtaXNzaW5nIHNvbWV0aGluZw0KDQpbR1NdwqBJdCBpcyBwb3NzaWJs ZSB0byBleHBhbmQgbW9yZSBpZiB5b3UgdGhpbmsgdGhhdCBpcyBuZWNlc3NhcnkuIFBsZWFzZSBs ZXQgdXMga25vdy4NCg0KDQpUaGFua3MNCkfDtnJhbg0KDQo= From nobody Tue Sep 1 09:40:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570A53A0975; Tue, 1 Sep 2020 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyTa-SDCiwDe; Tue, 1 Sep 2020 09:40:47 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740C63A0965; Tue, 1 Sep 2020 09:40:47 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Bgt9T3qp7zybs; Tue, 1 Sep 2020 18:40:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> Date: Tue, 1 Sep 2020 18:40:45 +0200 Cc: Barry Leiba , "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 620671244.99362-9a273ba2c1ae6c67fd70db5b205b4498 Content-Transfer-Encoding: quoted-printable Message-Id: <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 16:40:50 -0000 On 2020-09-01, at 16:19, G=C3=B6ran Selander = wrote: >=20 >=20 > =E2=80=94 Section 3.5.1 =E2=80=94 >=20 > is still possible for a man-in-the-middle to maliciously replace = a > later operation's blocks with an earlier operation's blocks >=20 > Not a requirement here, and I will accept your best judgment: in = the > spirit of recent discussion on inclusive vs exclusionary language, = I ask > you to consider changing =E2=80=9Ca man-in-the-middle=E2=80=9D to = =E2=80=9Can on-path attacker=E2=80=9D. >=20 > [GS] I thought there was a slight difference between "on-path = attacker" and "man-in-the-middle=E2=80=9D, in that the latter has access = to the message flow whereas the former need not have. For example, an = on-path attacker may only be able to inject messages. In this case = ("replace") the latter would then be more precise. If I'm right then I = propose we use available distinctions pending a new dictionary, = otherwise I'm fine with changing. Oh, so we are getting to have this fun discussion on *this* draft. A MITM can read, inject, delete, and modify data. An on-path attacker can read and inject, but not necessarily delete or = modify data. I would not use the latter as a synonym for the former. The other proposal in https://github.com/ietf/terminology is even more = broken: An impersonation attacker doesn=E2=80=99t even have to be = on-path. (See also my comment on https://github.com/ietf/terminology/pull/1, = which fell by the wayside in the recent lull on this topic.) In the mid-2000s, there was an attempt to replace MITM attack by = =E2=80=9Cmiddleperson attack=E2=80=9D. That utterly failed, a simple = Google search says =E2=80=9Cman-in-the-middle=E2=80=9D (54100 hits on = dl.acm.org) is overwhelmingly still the term of art and not = =E2=80=9Cmiddleperson=E2=80=9D (31 hits on dl.acm.org). Wikipedia at least knows about the other established word for MITM, = Janus attack = https://en.wikipedia.org/w/index.php?title=3DJanus_attack&redirect=3Dno = =E2=80=94 not very successful either (9 hits on dl.acm.org). One word that already has the right semantics and does not require the = cultural background of =E2=80=9CJanus attack=E2=80=9D is =E2=80=9CInterpos= er attack=E2=80=9D. 0 hits on dl.acm.org, but has all the right = properties. So in the above we would replace MITM by =E2=80=9Cinterposer=E2= =80=9D: > is still possible for an interposer to maliciously replace a > later operation's blocks with an earlier operation's blocks WFM, even if this is blazing a new trail. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Sep 1 12:13:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB23A0F6F; Tue, 1 Sep 2020 12:13:50 -0700 (PDT) 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 2i6Dx9XhG7xu; Tue, 1 Sep 2020 12:13:47 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150059.outbound.protection.outlook.com [40.107.15.59]) (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 9A8483A0F6B; Tue, 1 Sep 2020 12:13:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HOAuW282UFi3q0OBhnnDkLQxbPQcPpvyR21rB0HkywkBGTDbRdAdeZbvZ7cAOTQf55i8PZmuL0CmbL+ObAgxg5hrl0ZFhtv0If9ZajeQCp2kf0+aYE7/vmJ3DcT2yRMPMRtgBqhPjvlVFFWJ9ya2WZh59uB+C16m8dj8EWfJtC9RAlYXnHPnAe4lfMH0JDhiW+1JJ2ohnZgjhYHAc6CvQIU3hXZHYzF6B2VgZo3llnUUTlU4LKh3c7+MVnY+cBJMVIVt4pybE0PZnNYK4PhM8r7NGVbvw77VZhpLeKhcofdqyQQrLojlpLVm2kvaoe48EgTONh7J80ZztlvxKAHkwQ== 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=iI+iMjH4jwoqO58jY9ISZ5HAsO7U8qTxqkg1i3vNkZ4=; b=ew42PA7T8aC2/sQ6XQ1bOhs04LzjAOjKS4hY7NDfeLrMhFy5PxIUoycfKSVvVzVZQ8lvuc6QTlSDObANOkHFlwIzTt791EomQJIu1er3AO8wqkU7iUmni6utToPxQgz0wWnEzyIkGPaQk7HebB2BSxg4Xi47CvtOZv8LkR5Zq7TAl+1KQ9NvQKrjqeIzqYH/IGGdEs0Au0L7aZklh0tSQWvC8vHSURekgHjCMKdYfZ+JyqGZsaHS5+2West2Jz7S8aCM8un+qJ8SYvoDsrsPv3no4bidSejpYXutzgZDryUQjuZ9ITDziZJbJHdAdZxlf9K6iU73+fSXnk7FUG8CCg== 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=iI+iMjH4jwoqO58jY9ISZ5HAsO7U8qTxqkg1i3vNkZ4=; b=lt9++i7Lro7qA0n4kBm4WgbAYWsTQ916I3w2beaCgsr9moVXak/IVTnYz8zFDB0bNxRJ7RgtG89zOU/Ke4TsjyosZjQ577akUTm2f/344azhtggKB6GjUBKJzahXzLEI6A4SUVSwTDPb1W8IultxDJKOCLRn9l4EGJ0NeYhiPQY= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (2603:10a6:20b:17::24) by AM6PR07MB5025.eurprd07.prod.outlook.com (2603:10a6:20b:5e::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Tue, 1 Sep 2020 19:13:45 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::4027:7312:e764:73eb]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::4027:7312:e764:73eb%2]) with mapi id 15.20.3348.013; Tue, 1 Sep 2020 19:13:45 +0000 From: John Mattsson To: Carsten Bormann , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= CC: Barry Leiba , "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Thread-Topic: [core] AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWag27rQ//I2rI/E6zrjGMnBRICalUAb0AgAAnboCAAExGgA== Date: Tue, 1 Sep 2020 19:13:45 +0000 Message-ID: <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> In-Reply-To: <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1b704a8-08d7-4aa9-90ca-08d84eab25d9 x-ms-traffictypediagnostic: AM6PR07MB5025: 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: cYQ0Zj2n+jsLnyoS30l5ZxPZAi45k4GtlcIjWTZ9o4qsSfv/dKqdD1b3ue1LJ2t33ZGTqz+/J+040fj3ut9q1bYr+jtjp3BeHzBwGBn8YOr9HwCEzLm5MiuGBAcLCmMOaXTIAoNZMkh4CRxuENC4CC4HywIXisiOdyIC6BB1X6GW+80KEoolmdW7J9X7Z+OkCzbLXI5LWXaLKVETxXQbQ+1aUkEWYTLpMpBxzfhGemsYRcf2E5I5/RiJBYpBI6zMVkCzeXDdpMwm39deD8QUIQIe9VumygibojsQUh/HQBtkQzW+7pEmwz/K1XQOh6SZcj8XqlZolRkwasKwFuKY9WZxTIaQaSs3g2L0iDupkdAZX4bO/u+odW7Dx+u3wS91LrHVz0dPPnL87WDONBpt0Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(39860400002)(136003)(366004)(8676002)(33656002)(91956017)(44832011)(66556008)(66476007)(2616005)(16799955002)(66946007)(86362001)(5660300002)(966005)(64756008)(66446008)(186003)(2906002)(26005)(71200400001)(53546011)(6506007)(478600001)(66574015)(83380400001)(6486002)(76116006)(110136005)(8936002)(6512007)(4326008)(54906003)(36756003)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +E/i7l0Cb8PFBDmC7/ZQ673HEIUIWDjcJdY9rWroyEk+yIvrWaoqNKh5LnmElCSSYywfFWIY954QZcgPUUzIDkx0AqLLqPoG3lrGuHttft6SPK8AYuROT95H6suRhJ/wFoJZyT71hJdX2Q/BjspML9AWxTmK6DhwdsZ6ackQoYlFwDmb421PNOJOkS23JonMJxFIMzMif4qn9s16bsm5C2Baxt1nv7uE/GLa4odmq0P191VnS3Z9Kp35byyg6m8t29OPwUK2i6rpW+xH0c6UvJKSGHaYGR/HDwi2Infq9kfWH9ND/aw5411GJyJNmXER/57pi9mc5SfD3uAj/40rWlhP8CkTO94r5bRDNlnqsAFz4gcCc7r5THJ4VDKDDLXGDTai2+DKJi4NiOOVi0sag3wnnmCZ8TPZTYeExshEXxbCGbFObVEyUTdc3SbL5OKZT+r15EGvITOqZBJN03OG3RmiwiB+S08+NEpJqsMNsGVxQsxCOqmxeFEpCYDycW2VzjvTlLi8dAi9VINDRJvsuD8oej38U24XQSkh2Fbefx4+WXG60OJnlDJnvgV9+LkvRiqDz/Dh34L/B/l43OSzA2ATAWJbIpc+8YrzUPa8ufvhsi04tzAqY6tI5iXLDYaB3wbaBFb9fL7p46D7wKtffQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB4584.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1b704a8-08d7-4aa9-90ca-08d84eab25d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 19:13:45.3844 (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: CqcQSmAYZXSGfFVirNIacCG/f2mNjo8Nkn32IgWtXr+BBPfFTfmxmGs4yoNv+AF1BLqrE5Fq4zr4Z4yb3777hliXk74BciqUl0ReCCSjXts= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5025 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 19:13:50 -0000 SW4gdGhpcyBzZW50ZW5jZSBJIHRoaW5rIG9uLXBhdGggYXR0YWNrZXIgd29ya3MgcXVpdGUgd2Vs bCBvciBldmVuIGJldHRlci4gSXQgYWxyZWFkeSBmb2xsb3dzIGZyb20gdGhlIHNlbnRlbmNlIHRo YXQgdGhlIGF0dGFja2VyIGlzIGFibGUgdG8gcmVwbGFjZSBvbmUgYmxvY2sgd2l0aCBhbm90aGVy LiBUaGUgYXR0YWNrZXIgaW4gdGhpcyBjYXNlIGRvZXMgb25seSBuZWVkcyB0byBiZSBhYmxlIHRv IHJlb3JkZXIgcGFja2V0cyBmbG93aW5nIGluIG9uZSBkaXJlY3Rpb24gb2YgdGhlIGNvbW11bmlj YXRpb24uDQoNCldlIGNvdWxkIGFsc28ganVzdCB1c2UgdGhlIHdvcmQgYXR0YWNrZXIsIGUuZy4N Cg0KIml0IGlzIHN0aWxsIHBvc3NpYmxlIGZvciBhbiBhdHRhY2tlciBhYmxlIHRvIHJlb3JkZXIg cGFja2V0cyBvbiB0aGUgcGF0aCBmcm9tIGNsaWVudCB0byBzZXJ2ZXIgdG8gbWFsaWNpb3VzbHkg cmVwbGFjZSBhIGxhdGVyIG9wZXJhdGlvbidzIGJsb2NrcyB3aXRoIGFuIGVhcmxpZXIgb3BlcmF0 aW9uJ3MgYmxvY2tzLiINCg0KQ2hlZXJzLA0KSm9obg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpEYXRlOiBUdWVz ZGF5LCAxIFNlcHRlbWJlciAyMDIwIGF0IDE4OjQwDQpUbzogR8O2cmFuIFNlbGFuZGVyIDxnb3Jh bi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBCYXJyeSBMZWli YSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+LCAiZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVz dC10YWcuYWxsQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWcuYWxs QGlldGYub3JnPiwgImNvcmVAaWV0Zi5vcmciIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtjb3JlXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWctMTAN ClJlc2VudCBmcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2VudCB0bzogPGNocmlz dGlhbkBhbXN1ZXNzLmNvbT4sIEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24u Y29tPiwgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4sIDxqYWltZUBpa2kuZmk+LCA8bWFy Y28udGlsb2NhQHJpLnNlPiwgPGJhcnJ5bGVpYmFAZ21haWwuY29tPiwgPHN1cGVydXNlckBnbWFp bC5jb20+LCA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+LCBNYXJjbyBUaWxvY2EgPG1hcmNvLnRp bG9jYUByaS5zZT4NClJlc2VudCBkYXRlOiBUdWVzZGF5LCAxIFNlcHRlbWJlciAyMDIwIGF0IDE4 OjQwDQoNCiAgICBPbiAyMDIwLTA5LTAxLCBhdCAxNjoxOSwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jh bi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPiAN CiAgICA+IA0KICAgID4gICAg4oCUIFNlY3Rpb24gMy41LjEg4oCUDQogICAgPiANCiAgICA+ICAg ICAgIGlzIHN0aWxsIHBvc3NpYmxlIGZvciBhIG1hbi1pbi10aGUtbWlkZGxlIHRvIG1hbGljaW91 c2x5IHJlcGxhY2UgYQ0KICAgID4gICAgICAgbGF0ZXIgb3BlcmF0aW9uJ3MgYmxvY2tzIHdpdGgg YW4gZWFybGllciBvcGVyYXRpb24ncyBibG9ja3MNCiAgICA+IA0KICAgID4gICAgTm90IGEgcmVx dWlyZW1lbnQgaGVyZSwgYW5kIEkgd2lsbCBhY2NlcHQgeW91ciBiZXN0IGp1ZGdtZW50OiAgaW4g dGhlDQogICAgPiAgICBzcGlyaXQgb2YgcmVjZW50IGRpc2N1c3Npb24gb24gaW5jbHVzaXZlIHZz IGV4Y2x1c2lvbmFyeSBsYW5ndWFnZSwgSSBhc2sNCiAgICA+ICAgIHlvdSB0byBjb25zaWRlciBj aGFuZ2luZyDigJxhIG1hbi1pbi10aGUtbWlkZGxl4oCdIHRvIOKAnGFuIG9uLXBhdGggYXR0YWNr ZXLigJ0uDQogICAgPiANCiAgICA+IFtHU10gSSB0aG91Z2h0IHRoZXJlIHdhcyBhIHNsaWdodCBk aWZmZXJlbmNlIGJldHdlZW4gIm9uLXBhdGggYXR0YWNrZXIiIGFuZCAibWFuLWluLXRoZS1taWRk bGXigJ0sIGluIHRoYXQgdGhlIGxhdHRlciBoYXMgYWNjZXNzIHRvIHRoZSBtZXNzYWdlIGZsb3cg d2hlcmVhcyB0aGUgZm9ybWVyIG5lZWQgbm90IGhhdmUuIEZvciBleGFtcGxlLCBhbiBvbi1wYXRo IGF0dGFja2VyIG1heSBvbmx5IGJlIGFibGUgdG8gaW5qZWN0IG1lc3NhZ2VzLiBJbiB0aGlzIGNh c2UgKCJyZXBsYWNlIikgdGhlIGxhdHRlciB3b3VsZCB0aGVuIGJlIG1vcmUgcHJlY2lzZS4gSWYg SSdtIHJpZ2h0IHRoZW4gSSBwcm9wb3NlIHdlIHVzZSBhdmFpbGFibGUgZGlzdGluY3Rpb25zIHBl bmRpbmcgYSBuZXcgZGljdGlvbmFyeSwgb3RoZXJ3aXNlIEknbSBmaW5lIHdpdGggY2hhbmdpbmcu DQoNCiAgICBPaCwgc28gd2UgYXJlIGdldHRpbmcgdG8gaGF2ZSB0aGlzIGZ1biBkaXNjdXNzaW9u IG9uICp0aGlzKiBkcmFmdC4NCg0KICAgIEEgTUlUTSBjYW4gcmVhZCwgaW5qZWN0LCBkZWxldGUs IGFuZCBtb2RpZnkgZGF0YS4NCg0KICAgIEFuIG9uLXBhdGggYXR0YWNrZXIgY2FuIHJlYWQgYW5k IGluamVjdCwgYnV0IG5vdCBuZWNlc3NhcmlseSBkZWxldGUgb3IgbW9kaWZ5IGRhdGEuDQoNCiAg ICBJIHdvdWxkIG5vdCB1c2UgdGhlIGxhdHRlciBhcyBhIHN5bm9ueW0gZm9yIHRoZSBmb3JtZXIu DQoNCiAgICBUaGUgb3RoZXIgcHJvcG9zYWwgaW4gaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNv bS92MS91cmw/az04YmM4YmEyMS1kNTc4MjdiOS04YmM4ZmFiYS04NjFmY2I5NzJiZmMtYWZlMjBi MmQ4OWJiZDY2NyZxPTEmZT00MDZmYmI3Mi1iMmYwLTQ4NDQtYmQxMS0zZmY1NzBlZGFmMGYmdT1o dHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZpZXRmJTJGdGVybWlub2xvZ3kgaXMgZXZlbiBtb3Jl IGJyb2tlbjogQW4gaW1wZXJzb25hdGlvbiBhdHRhY2tlciBkb2VzbuKAmXQgZXZlbiBoYXZlIHRv IGJlIG9uLXBhdGguDQoNCiAgICAoU2VlIGFsc28gbXkgY29tbWVudCBvbiBodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3YxL3VybD9rPWExMTAxODJjLWZmYTA4NWI0LWExMTA1OGI3LTg2MWZj Yjk3MmJmYy0yODkwOTk5ZTYxNGIwODcwJnE9MSZlPTQwNmZiYjcyLWIyZjAtNDg0NC1iZDExLTNm ZjU3MGVkYWYwZiZ1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmlldGYlMkZ0ZXJtaW5vbG9n eSUyRnB1bGwlMkYxLCB3aGljaCBmZWxsIGJ5IHRoZSB3YXlzaWRlIGluIHRoZSByZWNlbnQgbHVs bCBvbiB0aGlzIHRvcGljLikNCg0KICAgIEluIHRoZSBtaWQtMjAwMHMsIHRoZXJlIHdhcyBhbiBh dHRlbXB0IHRvIHJlcGxhY2UgTUlUTSBhdHRhY2sgYnkg4oCcbWlkZGxlcGVyc29uIGF0dGFja+KA nS4gIFRoYXQgdXR0ZXJseSBmYWlsZWQsIGEgc2ltcGxlIEdvb2dsZSBzZWFyY2ggc2F5cyDigJxt YW4taW4tdGhlLW1pZGRsZeKAnSAoNTQxMDAgaGl0cyBvbiBkbC5hY20ub3JnKSBpcyBvdmVyd2hl bG1pbmdseSBzdGlsbCB0aGUgdGVybSBvZiBhcnQgYW5kIG5vdCDigJxtaWRkbGVwZXJzb27igJ0g KDMxIGhpdHMgb24gZGwuYWNtLm9yZykuDQoNCiAgICBXaWtpcGVkaWEgYXQgbGVhc3Qga25vd3Mg YWJvdXQgdGhlIG90aGVyIGVzdGFibGlzaGVkIHdvcmQgZm9yIE1JVE0sIEphbnVzIGF0dGFjayBo dHRwczovL2VuLndpa2lwZWRpYS5vcmcvdy9pbmRleC5waHA/dGl0bGU9SmFudXNfYXR0YWNrJnJl ZGlyZWN0PW5vIOKAlCBub3QgdmVyeSBzdWNjZXNzZnVsIGVpdGhlciAoOSBoaXRzIG9uIGRsLmFj bS5vcmcpLg0KDQogICAgT25lIHdvcmQgdGhhdCBhbHJlYWR5IGhhcyB0aGUgcmlnaHQgc2VtYW50 aWNzIGFuZCBkb2VzIG5vdCByZXF1aXJlIHRoZSBjdWx0dXJhbCBiYWNrZ3JvdW5kIG9mIOKAnEph bnVzIGF0dGFja+KAnSBpcyDigJxJbnRlcnBvc2VyIGF0dGFja+KAnS4gIDAgaGl0cyBvbiBkbC5h Y20ub3JnLCBidXQgaGFzIGFsbCB0aGUgcmlnaHQgcHJvcGVydGllcy4gIFNvIGluIHRoZSBhYm92 ZSB3ZSB3b3VsZCByZXBsYWNlIE1JVE0gYnkg4oCcaW50ZXJwb3NlcuKAnToNCg0KICAgID4gICAg ICAgaXMgc3RpbGwgcG9zc2libGUgZm9yIGFuIGludGVycG9zZXIgdG8gbWFsaWNpb3VzbHkgcmVw bGFjZSBhDQogICAgPiAgICAgICBsYXRlciBvcGVyYXRpb24ncyBibG9ja3Mgd2l0aCBhbiBlYXJs aWVyIG9wZXJhdGlvbidzIGJsb2Nrcw0KDQogICAgV0ZNLCBldmVuIGlmIHRoaXMgaXMgYmxhemlu ZyBhIG5ldyB0cmFpbC4NCg0KICAgIEdyw7zDn2UsIENhcnN0ZW4NCg0KDQoNCg0K From nobody Tue Sep 1 12:29:18 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780B63A0F9F; Tue, 1 Sep 2020 12:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 rMqIXPgUdInv; Tue, 1 Sep 2020 12:29:16 -0700 (PDT) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (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 C1B583A0FA3; Tue, 1 Sep 2020 12:29:15 -0700 (PDT) Received: by mail-il1-f176.google.com with SMTP id m1so2419344ilj.10; Tue, 01 Sep 2020 12:29:15 -0700 (PDT) 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=c2CeglQOSkpEIK4ZrcKxO9aatyqzAxxupXofq/uaTh0=; b=qGI9dnuaFRQDJmzeG0apBG0PFX37yHbZ0TSt4h9RtGOLQfMehCq7Kl8kdS+pn3WMtJ XxearOIqA6GjjZJVaWuzkTMoc5GdNarWq8TP1g5dksnPbRxj6SLllj3nyeUxbBCYewVF I9ry1PY35gqpVuKQZ2DAA8t6horWGB+CDM1+8KGYW158qzs+67991x2cCnL8LEXO0w2o z/BzSH5BBl00FCC2oh/zY/UnXUFhm7Tnqd3s3zJzeVITAqRLNkvwEJDxT+Z/TcHBrdor 6Gv+7AMvnsMu5Z0RrmXrv/Wc5Kdk8y66bsywR+goCY+SDoZ6iwozjJ06k+d4jS3fHnrN Z7RQ== X-Gm-Message-State: AOAM533PR0HeRq24g95zwNo5iqJ3Hbd6amiflYI2w8NBZMxX2D7VusvH ch69QSEqzmcP1mwjsLX+0O+mt5tqc4OOb9miXQA= X-Google-Smtp-Source: ABdhPJwTE/sAZeJUeCAhZW1SsPs4jgDn6l7vcUxjw6K7MzzluEdaPcjt/xBQHfTB4Lg2MJFMKNwW57IfpkOG2H1a0hk= X-Received: by 2002:a92:2810:: with SMTP id l16mr557271ilf.9.1598988554901; Tue, 01 Sep 2020 12:29:14 -0700 (PDT) MIME-Version: 1.0 References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> In-Reply-To: <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> From: Barry Leiba Date: Tue, 1 Sep 2020 15:29:04 -0400 Message-ID: To: John Mattsson Cc: Carsten Bormann , =?UTF-8?Q?G=C3=B6ran_Selander?= , "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 19:29:18 -0000 John has a good point here, and I support his proposal. That said, remember: I did say that it's not a big deal and I'm leaving it to y'all's best judgment. All I wanted was for you to consider the issue... not to rehash "fun" discussions from elsewhere. And whichever way you choose isn't going to block this document. Barry On Tue, Sep 1, 2020 at 3:13 PM John Mattsson w= rote: > > In this sentence I think on-path attacker works quite well or even better= . It already follows from the sentence that the attacker is able to replace= one block with another. The attacker in this case does only needs to be ab= le to reorder packets flowing in one direction of the communication. > > We could also just use the word attacker, e.g. > > "it is still possible for an attacker able to reorder packets on the path= from client to server to maliciously replace a later operation's blocks wi= th an earlier operation's blocks." > > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: Carsten Bormann > Date: Tuesday, 1 September 2020 at 18:40 > To: G=C3=B6ran Selander > Cc: Barry Leiba , "draft-ietf-core-echo-request-= tag.all@ietf.org" , "core@ie= tf.org" > Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 > Resent from: > Resent to: , John Mattsson , , , ,= , , , = Marco Tiloca > Resent date: Tuesday, 1 September 2020 at 18:40 > > On 2020-09-01, at 16:19, G=C3=B6ran Selander wrote: > > > > > > =E2=80=94 Section 3.5.1 =E2=80=94 > > > > is still possible for a man-in-the-middle to maliciously repl= ace a > > later operation's blocks with an earlier operation's blocks > > > > Not a requirement here, and I will accept your best judgment: i= n the > > spirit of recent discussion on inclusive vs exclusionary languag= e, I ask > > you to consider changing =E2=80=9Ca man-in-the-middle=E2=80=9D t= o =E2=80=9Can on-path attacker=E2=80=9D. > > > > [GS] I thought there was a slight difference between "on-path attac= ker" and "man-in-the-middle=E2=80=9D, in that the latter has access to the = message flow whereas the former need not have. For example, an on-path atta= cker may only be able to inject messages. In this case ("replace") the latt= er would then be more precise. If I'm right then I propose we use available= distinctions pending a new dictionary, otherwise I'm fine with changing. > > Oh, so we are getting to have this fun discussion on *this* draft. > > A MITM can read, inject, delete, and modify data. > > An on-path attacker can read and inject, but not necessarily delete o= r modify data. > > I would not use the latter as a synonym for the former. > > The other proposal in https://protect2.fireeye.com/v1/url?k=3D8bc8ba2= 1-d57827b9-8bc8faba-861fcb972bfc-afe20b2d89bbd667&q=3D1&e=3D406fbb72-b2f0-4= 844-bd11-3ff570edaf0f&u=3Dhttps%3A%2F%2Fgithub.com%2Fietf%2Fterminology is = even more broken: An impersonation attacker doesn=E2=80=99t even have to be= on-path. > > (See also my comment on https://protect2.fireeye.com/v1/url?k=3Da1101= 82c-ffa085b4-a11058b7-861fcb972bfc-2890999e614b0870&q=3D1&e=3D406fbb72-b2f0= -4844-bd11-3ff570edaf0f&u=3Dhttps%3A%2F%2Fgithub.com%2Fietf%2Fterminology%2= Fpull%2F1, which fell by the wayside in the recent lull on this topic.) > > In the mid-2000s, there was an attempt to replace MITM attack by =E2= =80=9Cmiddleperson attack=E2=80=9D. That utterly failed, a simple Google s= earch says =E2=80=9Cman-in-the-middle=E2=80=9D (54100 hits on dl.acm.org) i= s overwhelmingly still the term of art and not =E2=80=9Cmiddleperson=E2=80= =9D (31 hits on dl.acm.org). > > Wikipedia at least knows about the other established word for MITM, J= anus attack https://en.wikipedia.org/w/index.php?title=3DJanus_attack&redir= ect=3Dno =E2=80=94 not very successful either (9 hits on dl.acm.org). > > One word that already has the right semantics and does not require th= e cultural background of =E2=80=9CJanus attack=E2=80=9D is =E2=80=9CInterpo= ser attack=E2=80=9D. 0 hits on dl.acm.org, but has all the right propertie= s. So in the above we would replace MITM by =E2=80=9Cinterposer=E2=80=9D: > > > is still possible for an interposer to maliciously replace a > > later operation's blocks with an earlier operation's blocks > > WFM, even if this is blazing a new trail. > > Gr=C3=BC=C3=9Fe, Carsten > > > > From nobody Wed Sep 2 05:52:09 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DB03A0C6B; Wed, 2 Sep 2020 05:52:08 -0700 (PDT) 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 nkjYHKMd6d1W; Wed, 2 Sep 2020 05:52:06 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00043.outbound.protection.outlook.com [40.107.0.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A27A3A0C68; Wed, 2 Sep 2020 05:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CmFRxs/5a7RSKxPygc+HyrmywbuqcNqX7H5/iGD4CzOguPsPDZOdvumc0keRNpkS0VzPT39cceOG5ygtj7NHVU8T4sf58N0TG46iTFqKorxCSLKi0O99/764N16nhcEWvBJt/s39RfOEoNH7NbDhco+dn4NMwdbNxkWxlLsKD6xDj+w4BoPSD0XZ5OboOmsPxgpwmz/fKRDwa2AZjXWnhorzhl5q9l984TC4N/cGWw8+fJOls7dH30eH2RBfIn80BJ/grdBaGDNUTGe+29m1UdYXXeFixJMf26AX88s5HVMTDT2JkSTMM349cW6XfCZgHfBksxs21oKubEdgkltbvA== 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=vksudDmPSYVQI+yc1dsFCf8hxpfoCkB2sjZzbieexp4=; b=jKDHKg/dCr2jLbhvC/fkA0oQeSgBOjN7u0Rb9ksBLrefqZYeWvvfUF2+bD3mExZf+X7389J1Ii19yQMcji/24LcIpU8b95ApjAW/Vdy5DNspjk7EQFuSgJ2Biv6zwZFtXH46DX5QBlTbbX/lunj+8rZfUyrG8P07AhUGfsS0SeCu9Bf5pg9buAd1RMSW6xWBQxvoSSVgkKxEzy26KmUXj0/QZa0vBEirn63uI+qBV655J4llrjxtyAVMRredFBZgBSWc2MAeYz7FOM0nWCC3033wmRg5/cdq2lq+WJmyFBu4J1ARppFvW3J9JqpCMO+K8n2nCGXfuXO8H8ed+fJI/Q== 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=vksudDmPSYVQI+yc1dsFCf8hxpfoCkB2sjZzbieexp4=; b=B1hMYsuaA/Fko14dfgTiOPKc4rsCZXmAnP/iIL5FbgTaJEn0uAq2B0ME8BGyQlGRlhR/NCEaDASfQGhY1YXmXvtFOf4xaluueDQ8qMaI8Mf8C4IwwM4MbK86KsrSgwqJgFeULipdkUOErrseMLS50nmO5QC9h0iZJQswxuf2Gsg= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR07MB3068.eurprd07.prod.outlook.com (2603:10a6:7:32::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Wed, 2 Sep 2020 12:52:02 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3348.015; Wed, 2 Sep 2020 12:52:02 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Barry Leiba , John Mattsson , Carsten Bormann , "core@ietf.org" CC: "draft-ietf-core-echo-request-tag.all@ietf.org" Thread-Topic: [core] AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWag2783ig3eTTLEWqbjvVPkqoAKlTipYAgACelYCAACq/gIAABEgAgAFE7gA= Date: Wed, 2 Sep 2020 12:52:02 +0000 Message-ID: References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b44dd7d2-94c9-48fa-f23e-08d84f3efd42 x-ms-traffictypediagnostic: HE1PR07MB3068: x-ms-exchange-transport-forked: True 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: 434tLTfjDEBq5vvjVueXtS0Ds+FOn9W7u5iU2JeRMID49mI4FlEoA1nqn1b8f+WAXBdPPFS5wEGizFi3HWNg++mlNCTrQmPjnRZDcDoM26dxk4EhwGIa8KMVSqF2e8qVIkFWobeMjVWBg7rXU0SG1vlBwOr+IQqJeU/l3CVHD4MiSFtXaAZONSaO62v8+u9Ko1CslrgozF/46HhzF6FgQlUZetqxUQCshC4q2SeAyM38ubjll2Rt8QmIYLQSOrOGnmbs7sOVn6wD0oRPFOF52hp2Mqx0rjbWhUGFCp8Qtj2WOPY86ycYgt/lfRTa9kDcaUngSDTRR7tLMD4xYqw1w9D3S5XUafn5DvaC/By1zGE0va9I7d5ltQbLPkB5GRyt9KryU9fW5qSRV4Av9F5nsA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(39860400002)(396003)(376002)(36756003)(85202003)(6486002)(66446008)(16799955002)(53546011)(64756008)(91956017)(6512007)(66946007)(2616005)(66476007)(66556008)(4326008)(76116006)(5660300002)(85182001)(66574015)(478600001)(186003)(8676002)(6506007)(86362001)(8936002)(2906002)(71200400001)(26005)(83380400001)(110136005)(316002)(966005)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: a0L3MhIArzaEcO8iI5fD5W0m4lRVYLbgJd7BnUIdKeMrcmgkfs3E1RpWVPnA7oBZE/otedLhAXQyBqDaitoZMluZeeTzwAAl2vjaiZ5NYLWPu6EupnJH5WBe5s5RC9XPwwc01OCX0QpSH+6cbmRf/30L83mqhbHEmVw1JWgT7vn8Ukz0gqv/AI0OF902gQQaDw/ts9JnvZWHJ/qth1JzjD2dwWKFkUOje25lRRJ0N59ZPqLH5L35xexjfuU8kL/5l4DPkZ9DMkGIouZboHdkjqn3rfDX1Js9xJa2CP+SAoRd/3p1K356tUkuA442RAIuBSblSoiYQpCnlq4xsyxBYyHq6j3bhy3mPyVulWyR/3/wLSqN40dEydUWuvWxmk9R6CHWapjGpQcJ1K8wdEioTQ1fQQlB2TecYweI+4m9E7a7dMFZAmXHs/ink3EsC09RgmT2yqKYNyj/40vBxvL6Atbui5aocNOYdoE8+UKlYKW03yAcYj71rKIyNodc3O3LG5dRTxd7RzrJbdW36Z3gbtUPPamDYD6AsDXCpsxhwxV12VAm1N+TCSQFMN0Ivzwi8m3HLSeVDXkIHrvt8qP8DZSCT530yOg205gU7BXguoB4tnBWG3CRjwFoldW+Lihp95Ewgyf7vCHNQyvMgnmvCw== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b44dd7d2-94c9-48fa-f23e-08d84f3efd42 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2020 12:52:02.7085 (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: GGPLsRVuw1S34lvKfjiCRaCnTruvHTBTxV1nuApyN+PxGzK1oYGxypVZB/2GXdc5J0TPRbG6lTFFmtmDAbZDYNpufFIbJA6PzVpJce9aq7Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3068 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 12:52:08 -0000 SGksDQoNCkFzIEkgdW5kZXJzdGFuZCAicmVwbGFjZSIgYW5kIENhcnN0ZW4ncyBwcm92aWRlZCBk ZWZpbml0aW9ucywgYW4gb24tcGF0aCBhdHRhY2tlciBkb2VzIG5vdCBuZWNlc3NhcmlseSBoYXZl IHRoYXQgY2FwYWJpbGl0eS4gQnV0IEkgYWdyZWUgd2l0aCBKb2huJ3MgcHJvcG9zYWwgYW5kIHVw ZGF0ZWQgdGhlIGdpdGh1YiB2ZXJzaW9uIGFjY29yZGluZ2x5LiBJbiB0aGUgc2FtZSB3YXkgSSBh bHNvIHJlcGxhY2VkIHRoZSBvbmx5IHVzZSBvZiAib24tcGF0aCBhdHRhY2tlciIgaW4gdGhlIGRy YWZ0IHdpdGggImF0dGFja2VyIi4gVGhlIGNvbW1pdCBpcyBoZXJlOg0KDQpodHRwczovL2dpdGh1 Yi5jb20vY29yZS13Zy9lY2hvLXJlcXVlc3QtdGFnL2NvbW1pdC8yOTk2OWM0DQoNCkFueSBvdGhl ciBjb21tZW50cyBvbiB0aGUgcmVjZW50IGNoYW5nZXM/IFdlIHBsYW4gdG8gc3VibWl0IGEgbmV3 IHZlcnNpb24gb24gRnJpZGF5Lg0KDQpHw7ZyYW4NCg0KDQrvu79PbiAyMDIwLTA5LTAxLCAyMToy OSwgIkJhcnJ5IExlaWJhIiA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+IHdyb3RlOg0KDQogICAg Sm9obiBoYXMgYSBnb29kIHBvaW50IGhlcmUsIGFuZCBJIHN1cHBvcnQgaGlzIHByb3Bvc2FsLg0K DQogICAgVGhhdCBzYWlkLCByZW1lbWJlcjogSSBkaWQgc2F5IHRoYXQgaXQncyBub3QgYSBiaWcg ZGVhbCBhbmQgSSdtDQogICAgbGVhdmluZyBpdCB0byB5J2FsbCdzIGJlc3QganVkZ21lbnQuICBB bGwgSSB3YW50ZWQgd2FzIGZvciB5b3UgdG8NCiAgICBjb25zaWRlciB0aGUgaXNzdWUuLi4gbm90 IHRvIHJlaGFzaCAiZnVuIiBkaXNjdXNzaW9ucyBmcm9tIGVsc2V3aGVyZS4NCiAgICBBbmQgd2hp Y2hldmVyIHdheSB5b3UgY2hvb3NlIGlzbid0IGdvaW5nIHRvIGJsb2NrIHRoaXMgZG9jdW1lbnQu DQoNCiAgICBCYXJyeQ0KDQogICAgT24gVHVlLCBTZXAgMSwgMjAyMCBhdCAzOjEzIFBNIEpvaG4g TWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPiB3cm90ZToNCiAgICA+DQogICAg PiBJbiB0aGlzIHNlbnRlbmNlIEkgdGhpbmsgb24tcGF0aCBhdHRhY2tlciB3b3JrcyBxdWl0ZSB3 ZWxsIG9yIGV2ZW4gYmV0dGVyLiBJdCBhbHJlYWR5IGZvbGxvd3MgZnJvbSB0aGUgc2VudGVuY2Ug dGhhdCB0aGUgYXR0YWNrZXIgaXMgYWJsZSB0byByZXBsYWNlIG9uZSBibG9jayB3aXRoIGFub3Ro ZXIuIFRoZSBhdHRhY2tlciBpbiB0aGlzIGNhc2UgZG9lcyBvbmx5IG5lZWRzIHRvIGJlIGFibGUg dG8gcmVvcmRlciBwYWNrZXRzIGZsb3dpbmcgaW4gb25lIGRpcmVjdGlvbiBvZiB0aGUgY29tbXVu aWNhdGlvbi4NCiAgICA+DQogICAgPiBXZSBjb3VsZCBhbHNvIGp1c3QgdXNlIHRoZSB3b3JkIGF0 dGFja2VyLCBlLmcuDQogICAgPg0KICAgID4gIml0IGlzIHN0aWxsIHBvc3NpYmxlIGZvciBhbiBh dHRhY2tlciBhYmxlIHRvIHJlb3JkZXIgcGFja2V0cyBvbiB0aGUgcGF0aCBmcm9tIGNsaWVudCB0 byBzZXJ2ZXIgdG8gbWFsaWNpb3VzbHkgcmVwbGFjZSBhIGxhdGVyIG9wZXJhdGlvbidzIGJsb2Nr cyB3aXRoIGFuIGVhcmxpZXIgb3BlcmF0aW9uJ3MgYmxvY2tzLiINCiAgICA+DQogICAgPiBDaGVl cnMsDQogICAgPiBKb2huDQogICAgPg0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CiAgICA+IEZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KICAgID4gRGF0ZTog VHVlc2RheSwgMSBTZXB0ZW1iZXIgMjAyMCBhdCAxODo0MA0KICAgID4gVG86IEfDtnJhbiBTZWxh bmRlciA8Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQogICAg PiBDYzogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPiwgImRyYWZ0LWlldGYt Y29yZS1lY2hvLXJlcXVlc3QtdGFnLmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtY29yZS1lY2hv LXJlcXVlc3QtdGFnLmFsbEBpZXRmLm9yZz4sICJjb3JlQGlldGYub3JnIiA8Y29yZUBpZXRmLm9y Zz4NCiAgICA+IFN1YmplY3Q6IFJlOiBbY29yZV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29y ZS1lY2hvLXJlcXVlc3QtdGFnLTEwDQogICAgPiBSZXNlbnQgZnJvbTogPGFsaWFzLWJvdW5jZXNA aWV0Zi5vcmc+DQogICAgPiBSZXNlbnQgdG86IDxjaHJpc3RpYW5AYW1zdWVzcy5jb20+LCBKb2hu IE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4sIDxnb3Jhbi5zZWxhbmRlckBl cmljc3Nvbi5jb20+LCA8amFpbWVAaWtpLmZpPiwgPG1hcmNvLnRpbG9jYUByaS5zZT4sIDxiYXJy eWxlaWJhQGdtYWlsLmNvbT4sIDxzdXBlcnVzZXJAZ21haWwuY29tPiwgPGJhcnJ5bGVpYmFAY29t cHV0ZXIub3JnPiwgTWFyY28gVGlsb2NhIDxtYXJjby50aWxvY2FAcmkuc2U+DQogICAgPiBSZXNl bnQgZGF0ZTogVHVlc2RheSwgMSBTZXB0ZW1iZXIgMjAyMCBhdCAxODo0MA0KICAgID4NCiAgICA+ ICAgICBPbiAyMDIwLTA5LTAxLCBhdCAxNjoxOSwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxh bmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPiAgICAgPg0K ICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgIOKAlCBTZWN0aW9uIDMuNS4xIOKAlA0KICAgID4g ICAgID4NCiAgICA+ICAgICA+ICAgICAgIGlzIHN0aWxsIHBvc3NpYmxlIGZvciBhIG1hbi1pbi10 aGUtbWlkZGxlIHRvIG1hbGljaW91c2x5IHJlcGxhY2UgYQ0KICAgID4gICAgID4gICAgICAgbGF0 ZXIgb3BlcmF0aW9uJ3MgYmxvY2tzIHdpdGggYW4gZWFybGllciBvcGVyYXRpb24ncyBibG9ja3MN CiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICBOb3QgYSByZXF1aXJlbWVudCBoZXJlLCBhbmQg SSB3aWxsIGFjY2VwdCB5b3VyIGJlc3QganVkZ21lbnQ6ICBpbiB0aGUNCiAgICA+ICAgICA+ICAg IHNwaXJpdCBvZiByZWNlbnQgZGlzY3Vzc2lvbiBvbiBpbmNsdXNpdmUgdnMgZXhjbHVzaW9uYXJ5 IGxhbmd1YWdlLCBJIGFzaw0KICAgID4gICAgID4gICAgeW91IHRvIGNvbnNpZGVyIGNoYW5naW5n IOKAnGEgbWFuLWluLXRoZS1taWRkbGXigJ0gdG8g4oCcYW4gb24tcGF0aCBhdHRhY2tlcuKAnS4N CiAgICA+ICAgICA+DQogICAgPiAgICAgPiBbR1NdIEkgdGhvdWdodCB0aGVyZSB3YXMgYSBzbGln aHQgZGlmZmVyZW5jZSBiZXR3ZWVuICJvbi1wYXRoIGF0dGFja2VyIiBhbmQgIm1hbi1pbi10aGUt bWlkZGxl4oCdLCBpbiB0aGF0IHRoZSBsYXR0ZXIgaGFzIGFjY2VzcyB0byB0aGUgbWVzc2FnZSBm bG93IHdoZXJlYXMgdGhlIGZvcm1lciBuZWVkIG5vdCBoYXZlLiBGb3IgZXhhbXBsZSwgYW4gb24t cGF0aCBhdHRhY2tlciBtYXkgb25seSBiZSBhYmxlIHRvIGluamVjdCBtZXNzYWdlcy4gSW4gdGhp cyBjYXNlICgicmVwbGFjZSIpIHRoZSBsYXR0ZXIgd291bGQgdGhlbiBiZSBtb3JlIHByZWNpc2Uu IElmIEknbSByaWdodCB0aGVuIEkgcHJvcG9zZSB3ZSB1c2UgYXZhaWxhYmxlIGRpc3RpbmN0aW9u cyBwZW5kaW5nIGEgbmV3IGRpY3Rpb25hcnksIG90aGVyd2lzZSBJJ20gZmluZSB3aXRoIGNoYW5n aW5nLg0KICAgID4NCiAgICA+ICAgICBPaCwgc28gd2UgYXJlIGdldHRpbmcgdG8gaGF2ZSB0aGlz IGZ1biBkaXNjdXNzaW9uIG9uICp0aGlzKiBkcmFmdC4NCiAgICA+DQogICAgPiAgICAgQSBNSVRN IGNhbiByZWFkLCBpbmplY3QsIGRlbGV0ZSwgYW5kIG1vZGlmeSBkYXRhLg0KICAgID4NCiAgICA+ ICAgICBBbiBvbi1wYXRoIGF0dGFja2VyIGNhbiByZWFkIGFuZCBpbmplY3QsIGJ1dCBub3QgbmVj ZXNzYXJpbHkgZGVsZXRlIG9yIG1vZGlmeSBkYXRhLg0KICAgID4NCiAgICA+ICAgICBJIHdvdWxk IG5vdCB1c2UgdGhlIGxhdHRlciBhcyBhIHN5bm9ueW0gZm9yIHRoZSBmb3JtZXIuDQogICAgPg0K ICAgID4gICAgIFRoZSBvdGhlciBwcm9wb3NhbCBpbiBodHRwczovL3Byb3RlY3QyLmZpcmVleWUu Y29tL3YxL3VybD9rPThiYzhiYTIxLWQ1NzgyN2I5LThiYzhmYWJhLTg2MWZjYjk3MmJmYy1hZmUy MGIyZDg5YmJkNjY3JnE9MSZlPTQwNmZiYjcyLWIyZjAtNDg0NC1iZDExLTNmZjU3MGVkYWYwZiZ1 PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmlldGYlMkZ0ZXJtaW5vbG9neSBpcyBldmVuIG1v cmUgYnJva2VuOiBBbiBpbXBlcnNvbmF0aW9uIGF0dGFja2VyIGRvZXNu4oCZdCBldmVuIGhhdmUg dG8gYmUgb24tcGF0aC4NCiAgICA+DQogICAgPiAgICAgKFNlZSBhbHNvIG15IGNvbW1lbnQgb24g aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az1hMTEwMTgyYy1mZmEwODViNC1h MTEwNThiNy04NjFmY2I5NzJiZmMtMjg5MDk5OWU2MTRiMDg3MCZxPTEmZT00MDZmYmI3Mi1iMmYw LTQ4NDQtYmQxMS0zZmY1NzBlZGFmMGYmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZpZXRm JTJGdGVybWlub2xvZ3klMkZwdWxsJTJGMSwgd2hpY2ggZmVsbCBieSB0aGUgd2F5c2lkZSBpbiB0 aGUgcmVjZW50IGx1bGwgb24gdGhpcyB0b3BpYy4pDQogICAgPg0KICAgID4gICAgIEluIHRoZSBt aWQtMjAwMHMsIHRoZXJlIHdhcyBhbiBhdHRlbXB0IHRvIHJlcGxhY2UgTUlUTSBhdHRhY2sgYnkg 4oCcbWlkZGxlcGVyc29uIGF0dGFja+KAnS4gIFRoYXQgdXR0ZXJseSBmYWlsZWQsIGEgc2ltcGxl IEdvb2dsZSBzZWFyY2ggc2F5cyDigJxtYW4taW4tdGhlLW1pZGRsZeKAnSAoNTQxMDAgaGl0cyBv biBkbC5hY20ub3JnKSBpcyBvdmVyd2hlbG1pbmdseSBzdGlsbCB0aGUgdGVybSBvZiBhcnQgYW5k IG5vdCDigJxtaWRkbGVwZXJzb27igJ0gKDMxIGhpdHMgb24gZGwuYWNtLm9yZykuDQogICAgPg0K ICAgID4gICAgIFdpa2lwZWRpYSBhdCBsZWFzdCBrbm93cyBhYm91dCB0aGUgb3RoZXIgZXN0YWJs aXNoZWQgd29yZCBmb3IgTUlUTSwgSmFudXMgYXR0YWNrIGh0dHBzOi8vZW4ud2lraXBlZGlhLm9y Zy93L2luZGV4LnBocD90aXRsZT1KYW51c19hdHRhY2smcmVkaXJlY3Q9bm8g4oCUIG5vdCB2ZXJ5 IHN1Y2Nlc3NmdWwgZWl0aGVyICg5IGhpdHMgb24gZGwuYWNtLm9yZykuDQogICAgPg0KICAgID4g ICAgIE9uZSB3b3JkIHRoYXQgYWxyZWFkeSBoYXMgdGhlIHJpZ2h0IHNlbWFudGljcyBhbmQgZG9l cyBub3QgcmVxdWlyZSB0aGUgY3VsdHVyYWwgYmFja2dyb3VuZCBvZiDigJxKYW51cyBhdHRhY2vi gJ0gaXMg4oCcSW50ZXJwb3NlciBhdHRhY2vigJ0uICAwIGhpdHMgb24gZGwuYWNtLm9yZywgYnV0 IGhhcyBhbGwgdGhlIHJpZ2h0IHByb3BlcnRpZXMuICBTbyBpbiB0aGUgYWJvdmUgd2Ugd291bGQg cmVwbGFjZSBNSVRNIGJ5IOKAnGludGVycG9zZXLigJ06DQogICAgPg0KICAgID4gICAgID4gICAg ICAgaXMgc3RpbGwgcG9zc2libGUgZm9yIGFuIGludGVycG9zZXIgdG8gbWFsaWNpb3VzbHkgcmVw bGFjZSBhDQogICAgPiAgICAgPiAgICAgICBsYXRlciBvcGVyYXRpb24ncyBibG9ja3Mgd2l0aCBh biBlYXJsaWVyIG9wZXJhdGlvbidzIGJsb2Nrcw0KICAgID4NCiAgICA+ICAgICBXRk0sIGV2ZW4g aWYgdGhpcyBpcyBibGF6aW5nIGEgbmV3IHRyYWlsLg0KICAgID4NCiAgICA+ICAgICBHcsO8w59l LCBDYXJzdGVuDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KDQo= From nobody Wed Sep 2 05:56:43 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4A3A0C9C; Wed, 2 Sep 2020 05:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 nNLV8mn3PE0r; Wed, 2 Sep 2020 05:56:40 -0700 (PDT) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (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 A33C83A0C9B; Wed, 2 Sep 2020 05:56:40 -0700 (PDT) Received: by mail-il1-f169.google.com with SMTP id w3so4852367ilh.5; Wed, 02 Sep 2020 05:56:40 -0700 (PDT) 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=SimXlO7t7809u+EDO+BGdjtLRtdqVgtuES2IBeZR+Ns=; b=RN6gkEkoATQQgJa+l8C8f1XW0mGrbjwJ2QIyjn+ogGWh+h6K42XbGP7GdpWxxHrcr5 IqezvKgD7TuznAm2OWSWZLuxV1JVLmXaCZNWbeuF4g6QQKqiw2UDPkJEDEXA0+0OHutx LvKpuMKB5buvb8R3ZUYh3CnsfiiwBdwcDeQFOM8qgxE9vaYZs9/QT4Ux/L4AE1QMOBkh piAetcrgGJFwkJyoxkgWxw2bygrjSbjTCrbeFUtEAONaW7dKvSx6hueKJkGjpYh6kOrU C/7Hk6EUWdUiVRFEkbl1hn/Q3Kr3K3lhvyiVG+kDigAwtCBWf9hLMIGjUxy7oOlSlWZB qfcg== X-Gm-Message-State: AOAM531ClNXUlLPUkwkOkAmA2x6F1FePbavc7EzxxDBR01AK9rs6bOfu 6PWO0UbBKhgsXS+vtypScnbVckajKLHzWPo2nhA= X-Google-Smtp-Source: ABdhPJwSpeji4S2EJia9Ve3dOEn0eApAFVpM2ZVDOEg84U9767S6XOioZ34JYSTABCzMrht+WNETc64KVwrtjA2Cz0w= X-Received: by 2002:a92:dc03:: with SMTP id t3mr3301438iln.59.1599051399568; Wed, 02 Sep 2020 05:56:39 -0700 (PDT) MIME-Version: 1.0 References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> In-Reply-To: From: Barry Leiba Date: Wed, 2 Sep 2020 08:56:28 -0400 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: John Mattsson , Carsten Bormann , "core@ietf.org" , "draft-ietf-core-echo-request-tag.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 12:56:42 -0000 For what it's worth, I just reviewed a routing document that uses the phrase "an attacker in the middle of the network", which is another option. Barry On Wed, Sep 2, 2020 at 8:52 AM G=C3=B6ran Selander wrote: > > Hi, > > As I understand "replace" and Carsten's provided definitions, an on-path = attacker does not necessarily have that capability. But I agree with John's= proposal and updated the github version accordingly. In the same way I als= o replaced the only use of "on-path attacker" in the draft with "attacker".= The commit is here: > > https://github.com/core-wg/echo-request-tag/commit/29969c4 > > Any other comments on the recent changes? We plan to submit a new version= on Friday. > > G=C3=B6ran > > > =EF=BB=BFOn 2020-09-01, 21:29, "Barry Leiba" wr= ote: > > John has a good point here, and I support his proposal. > > That said, remember: I did say that it's not a big deal and I'm > leaving it to y'all's best judgment. All I wanted was for you to > consider the issue... not to rehash "fun" discussions from elsewhere. > And whichever way you choose isn't going to block this document. > > Barry > > On Tue, Sep 1, 2020 at 3:13 PM John Mattsson wrote: > > > > In this sentence I think on-path attacker works quite well or even = better. It already follows from the sentence that the attacker is able to r= eplace one block with another. The attacker in this case does only needs to= be able to reorder packets flowing in one direction of the communication. > > > > We could also just use the word attacker, e.g. > > > > "it is still possible for an attacker able to reorder packets on th= e path from client to server to maliciously replace a later operation's blo= cks with an earlier operation's blocks." > > > > Cheers, > > John > > > > -----Original Message----- > > From: Carsten Bormann > > Date: Tuesday, 1 September 2020 at 18:40 > > To: G=C3=B6ran Selander > > Cc: Barry Leiba , "draft-ietf-core-echo-re= quest-tag.all@ietf.org" , "c= ore@ietf.org" > > Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-1= 0 > > Resent from: > > Resent to: , John Mattsson , , , , , , , Marco Tiloca > > Resent date: Tuesday, 1 September 2020 at 18:40 > > > > On 2020-09-01, at 16:19, G=C3=B6ran Selander wrote: > > > > > > > > > =E2=80=94 Section 3.5.1 =E2=80=94 > > > > > > is still possible for a man-in-the-middle to maliciousl= y replace a > > > later operation's blocks with an earlier operation's bl= ocks > > > > > > Not a requirement here, and I will accept your best judgme= nt: in the > > > spirit of recent discussion on inclusive vs exclusionary l= anguage, I ask > > > you to consider changing =E2=80=9Ca man-in-the-middle=E2= =80=9D to =E2=80=9Can on-path attacker=E2=80=9D. > > > > > > [GS] I thought there was a slight difference between "on-path= attacker" and "man-in-the-middle=E2=80=9D, in that the latter has access t= o the message flow whereas the former need not have. For example, an on-pat= h attacker may only be able to inject messages. In this case ("replace") th= e latter would then be more precise. If I'm right then I propose we use ava= ilable distinctions pending a new dictionary, otherwise I'm fine with chang= ing. > > > > Oh, so we are getting to have this fun discussion on *this* dra= ft. > > > > A MITM can read, inject, delete, and modify data. > > > > An on-path attacker can read and inject, but not necessarily de= lete or modify data. > > > > I would not use the latter as a synonym for the former. > > > > The other proposal in https://protect2.fireeye.com/v1/url?k=3D8= bc8ba21-d57827b9-8bc8faba-861fcb972bfc-afe20b2d89bbd667&q=3D1&e=3D406fbb72-= b2f0-4844-bd11-3ff570edaf0f&u=3Dhttps%3A%2F%2Fgithub.com%2Fietf%2Fterminolo= gy is even more broken: An impersonation attacker doesn=E2=80=99t even have= to be on-path. > > > > (See also my comment on https://protect2.fireeye.com/v1/url?k= =3Da110182c-ffa085b4-a11058b7-861fcb972bfc-2890999e614b0870&q=3D1&e=3D406fb= b72-b2f0-4844-bd11-3ff570edaf0f&u=3Dhttps%3A%2F%2Fgithub.com%2Fietf%2Ftermi= nology%2Fpull%2F1, which fell by the wayside in the recent lull on this top= ic.) > > > > In the mid-2000s, there was an attempt to replace MITM attack b= y =E2=80=9Cmiddleperson attack=E2=80=9D. That utterly failed, a simple Goo= gle search says =E2=80=9Cman-in-the-middle=E2=80=9D (54100 hits on dl.acm.o= rg) is overwhelmingly still the term of art and not =E2=80=9Cmiddleperson= =E2=80=9D (31 hits on dl.acm.org). > > > > Wikipedia at least knows about the other established word for M= ITM, Janus attack https://en.wikipedia.org/w/index.php?title=3DJanus_attack= &redirect=3Dno =E2=80=94 not very successful either (9 hits on dl.acm.org). > > > > One word that already has the right semantics and does not requ= ire the cultural background of =E2=80=9CJanus attack=E2=80=9D is =E2=80=9CI= nterposer attack=E2=80=9D. 0 hits on dl.acm.org, but has all the right pro= perties. So in the above we would replace MITM by =E2=80=9Cinterposer=E2= =80=9D: > > > > > is still possible for an interposer to maliciously repl= ace a > > > later operation's blocks with an earlier operation's bl= ocks > > > > WFM, even if this is blazing a new trail. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > > From nobody Wed Sep 2 06:26:01 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF373A0C26; Wed, 2 Sep 2020 06:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 SuwUp7h2SK1V; Wed, 2 Sep 2020 06:25:58 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 431973A0BE9; Wed, 2 Sep 2020 06:25:58 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id g128so5689533iof.11; Wed, 02 Sep 2020 06:25:58 -0700 (PDT) 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=A072CeB57jwtOcq7aruLK92JBhFIbx9LGZUQTPDjYz4=; b=Ac0L43950nspMh38B1VyX+pK2RHJ40ekj0N6KLS4MogbLTRqcI4BgojtRDIdZ32cwx vkR5qXukcnJW1DkdUSr5Sb36e8CyfMhnSn71XX5+HGOJxORPGAaP7YdXvRW274XNIJ/w w1jC2YwfxLjRWQsmRzBSXa4sZkTjjI//2mxEIPClljr6DhdetCvEJl+84MPv/dDn9SRT bgXTSwQ+yspPwAghOyXugzgtyun1NnYd2x0lgyfoIblxeXIHCUHlYWVgkJJb8pAB53oO ICEU/EH87QSeP2EqzU9NISBeh6KkqbGOx8YaD3AwnE2MOFwjBVof8w67H89tWRxWGyo5 cVrQ== X-Gm-Message-State: AOAM532OkjuTpETL1irWGZY9bK8KWlnxoPyGKkC/f7l0agt3M26FwJW6 ps/6FMzWvAdvbZTjHQu8aJqRIYSwUo6U9C5dfRpjjW2TPaoUxA== X-Google-Smtp-Source: ABdhPJwWyGsMriv6mieWtI1AuadEZSW73m55RACInODQ+fARdoGOsl+fKJbCjD7++J00QOkMpvXuqvuPaUinpps6/vg= X-Received: by 2002:a5d:9701:: with SMTP id h1mr3540395iol.36.1599053157150; Wed, 02 Sep 2020 06:25:57 -0700 (PDT) MIME-Version: 1.0 References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> In-Reply-To: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> From: Barry Leiba Date: Wed, 2 Sep 2020 09:25:45 -0400 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 13:26:00 -0000 Thanks, G=C3=B6ran, for the responses. I'm leaving only the ones that need further discussion; consider the rest handled. > I would prefer it if the document were specific about what =E2=80=9Cw= hen CoAP is > used with security=E2=80=9D means, ideally not using that phrase at a= ll, as > =E2=80=9Csecurity=E2=80=9D without explanation isn=E2=80=99t meaningf= ul. If you mean =E2=80=9Cover an > encrypted channel=E2=80=9D, please say that. Or something else? > > [GS] Is the formulation of section 4.2 better, i.e. "when CoAP is used wi= th a security protocol"? > The text in the abstract would then read: > "This document updates RFC7252 with respect to the client Token > processing requirements, forbidding non-secure reuse of Tokens to > ensure binding of response to request when CoAP is used with a security > protocol, " > > The rationale to mention "when CoAP is used with a security protocol " > here is that a layman would expect a binding between response and > request to hold when CoAP is used with a security protocol (in contrast > to when CoAP is used without a security protocol, when no binding is > expected) and would thereby be surprised that the property does not > automatically hold, e.g., for CoAP with DTLS, but additionally requires > restricted use of Tokens. I think that "a security protocol" suffers from the same problem: what does "security" mean here, and what is "a security protocol". Again: if you mean "an encryption protocol", that's clear. But, for example, OAuth is a security protocol. EAP is a security protocol. DOTS is a security protocol. You don't mean those kinds of security protocols. We use "security" in so many related but different ways that the word "security" by itself doesn't explain much. > Two request messages are said to be "matchable" if they occur betw= een > the same endpoint pair, have the same code and the same set of > options except for elective NoCacheKey options and options involve= d > in block-wise transfer (Block1, Block2 and Request-Tag). > > There=E2=80=99s something missing here: this says, =E2=80=9CX is true= if A, B.=E2=80=9D It needs > an =E2=80=9Cand=E2=80=9D or an =E2=80=9Cor=E2=80=9D instead of the co= mma, no? > > [GS] The intention was =E2=80=9CX is true if A, B, and C.=E2=80=9D Does = this read better? > "Two request messages are said to be "matchable" if they occur between > the same endpoint pair, have the same code, and the same set of options > with the following exception: elective NoCacheKey options and options > involved in block-wise transfer (Block1, Block2 and Request-Tag) need > not be the same." Ah, I see the point... and this is why it's important to make list items parallel. Now that I get what you mean I can suggest a fix: NEW Two request messages are said to be "matchable" if they occur between the same endpoint pair, have the same code, and have the same set of options, with the exception that elective NoCacheKey options and options involved in block-wise transfer (Block1, Block2 and Request-Tag) need not be the same. END (The extra "have" is needed in the third list item to make the list parallel. Otherwise, the third item lacks the verb that the other two items each have.) > =E2=80=94 Section 3.4 =E2=80=94 > > What constitutes a concluded operation > depends on that purpose, and is defined there. > > I=E2=80=99m missing the antecedent to =E2=80=9Cthere=E2=80=9D. Where= ? > > [GS] I replaced "there" with "accordingly" and repeated the reference to = the applications: > "What constitutes a concluded operation depends on the purpose, and is de= fined accordingly, > see examples in Section 3.5." That's clear, thanks. Just please change the comma after "accordingly" to a semicolon. > changed, then the client MUST consider messages sent to _any_ > endpoint address within the new operation's security context. > > > This is ambiguous. I think you mean =E2=80=9Cto be within=E2=80=9D, = yes? > > [GS] To me, this reads better by replacing "within" with "using": > "If any future security mechanisms allow a block-wise transfer to > continue after an endpoint's details (like the IP address) have > changed, then the client MUST consider messages sent to *any* endpoint > address using the new operation's security context." > > The point here is that a necessary condition for a malicious > replacement of blocks to work is that the same security context is > used, since otherwise the integrity verification will detect the > change. Now, if a future specification allows the same security > context to be used more widely, say, even if IP address has changed, > then the IP address is not sufficient to determine what message > exchanges that needs to be assess as concluded when recycling a > Request-Tag value. Does that make more sense? I understand the point; thanks. I still think you need something other than the single word "within" or "using" to make the grammar work right... it's just a small thing. So tweaking the new text: NEW If any future security mechanisms allow a block-wise transfer to continue after an endpoint's details (such as the IP address) have changed, then the client MUST consider messages sent to *any* endpoint address to be using the new operation's security context. END Or "as using" also works. Without something there, one reads "messages using the new security context" and parses that as a compound noun... and then says, "must consider them... how?" > o The client MUST NOT regard a block-wise request operation as > concluded unless all of the messages the client previously sent= in > the operation have been confirmed by the message integrity > protection mechanism, or are considered invalid by the server i= f > replayed. > > It=E2=80=99s not clear to me how a client can comply with this: how c= an the client > possibly know whether the messages it has sent would be considered in= valid > by the server if they were replayed? Or is there something I=E2=80= =99m not > understanding? > > [GS] The size of the replay buffer window may be fixed by the > application and known to the client. The window could potentially be > set small, e.g. if transported messages are rarely erroneous. If the > client receives an integrity protected response (not necessarily > related to the operation in question) it could deduce that the replay > window have slided past all messages related to the operation in > question, and therefore the server would not accept replay of messages > of this operation. Ah, I see; thanks. So maybe putting it in active voice would make it better?: NEW o The client MUST NOT regard a block-wise request operation as concluded unless all of the messages the client previously sent in the operation have been confirmed by the message integrity protection mechanism, or the client can determine that the server would not consider the messages to be valid if they were replayed. END Barry From nobody Wed Sep 2 06:37:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D780C3A0D5A; Wed, 2 Sep 2020 06:37:46 -0700 (PDT) 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 fxdGVsUq-mot; Wed, 2 Sep 2020 06:37:44 -0700 (PDT) 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 B9D533A0D55; Wed, 2 Sep 2020 06:37:44 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 082DbekC014406; Wed, 2 Sep 2020 09:37:40 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 082DbekC014406 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1599053860; bh=c0Tlwf44inseE9h8asy/GtkSlWkTfsR6LTQSy96Xmkk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=CQJO5GZCDfT5cqxCmR/r3sBTi+Alvlb8mR2E0OdlZuyWkvHClIPTI6760WRmMGRE4 dNSyKfYvbBLg/3oC4A0Q5YWug+1RI2DFLtrZp4YwYqKBAg5X5u4Ech3V8aLel8FEa2 loCxjzHFCYw+GlBw8aQ7ABSu+B7QcnVBCeWF7KjA= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 082Dbc9i019263; Wed, 2 Sep 2020 09:37:39 -0400 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.1979.3; Wed, 2 Sep 2020 09:37:38 -0400 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.1979.003; Wed, 2 Sep 2020 09:37:38 -0400 From: Roman Danyliw To: Barry Leiba , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= CC: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Thread-Topic: [core] AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWgGr6HdwxyxOIZEyKRawBPBcjNalUP3+AgAAqv4CAAARHAIABI2cAgAABPQD//77GEA== Date: Wed, 2 Sep 2020 13:37:37 +0000 Message-ID: <0c496ec8d63a439684ccdb3489fd541f@cert.org> References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.220] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 13:37:47 -0000 SGkhDQoNClRoZSBub3Rpb24gb2YgZGVmaW5pbmcsIGxhYmVsbGluZyBhbmQgZGlzY3Vzc2luZyB0 aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBhdHRhY2tlcnMgd2hvIGNhbiByZWFkLCBpbmplY3QsIGRl bGV0ZSwgYW5kIG1vZGlmeSBkYXRhIHZzLiByZWFkIGFuZCBpbmplY3QsIGJ1dCBub3QgbmVjZXNz YXJpbHkgZGVsZXRlIG9uIG1vZGlmeSBkYXRhLCBzZWVtcyBsaWtlIGhlbHBmdWwgcHJlY2lzaW9u LiAgVGhhbmtzIGZvciBkb2luZyBpdC4gIA0KDQpUbyBtYWtlIGEgZmV3IGdlbmVyYWwgY29tbWVu dHMgLi4uDQoNCkZvciBtZSwgIm9uLXBhdGgiIHNwZWFrcyB0byB3aGVyZSBhbiBhdHRhY2tlciBp cyBsb2NhdGVkIHRvcG9sb2dpY2FsbHksIG5vdCB3aGF0IGNhcGFiaWxpdGllcyB0aGUgYXR0YWNr ZXIgd2lsbCBfYWx3YXlzXyBoYXZlIC0tIHRoZXJlIGNhbiBiZSBtaXRpZ2F0aW5nIGZhY3RvcnMg YmFzZWQgb24gdGhlIHBhcnRpY3VsYXIgZGV0YWlscyBvZiB0aGUgcHJvdG9jb2wgb3Igb3BlcmF0 aW9uYWwgY29uZmlndXJhdGlvbnMuICBJJ2QgYWxzbyBzYXkgdGhlIHNhbWUgZm9yICJNaVRNIiB0 b28uICBGdXJ0aGVybW9yZSwgSSBkb27igJl0IHRoaW5rIHRoYXQgaW4gdGhlIGFic3RyYWN0IHRo YXQgd2UgaGF2ZSBhIGFuIGNvbW1vbmx5IGFjY2VwdGVkIGRlZmluaXRpb24gcHJlY2lzZSBlbm91 Z2ggd2l0aCBNaVRNIHZzLiBvbi1wYXRoIGF0dGFja2VyIHRvIHRoZSBkZWdyZWUgIHRoYXQgd2Ug Y2FuIG1ha2UgdGhlIGRpc3RpbmN0aW9uIHRoYXQgdGhlIGxhdHRlciAoYWdhaW4gaW4gdGhlIGFi c3RyYWN0KSBoYXMgbGVzcyBjYXBhYmlsaXRpZXMgdGhhbiB0aGUgZm9ybWVyIChvciB2aWNlIHZl cnNhKS4gIA0KDQpJbiB0ZXJtcyBvZiBwcmlvciBkZWZpbml0aW9ucywgY29uc3VsdGluZyBTZWN0 aW9uIDMuNSBvZiBSRkMzNTUyOg0KDQozLjUuIE9uLXBhdGggdmVyc3VzIG9mZi1wYXRoDQoNCiAg IEluIG9yZGVyIGZvciBhIGRhdGFncmFtIHRvIGJlIHRyYW5zbWl0dGVkIGZyb20gb25lIGhvc3Qg dG8gYW5vdGhlciwNCiAgIGl0IGdlbmVyYWxseSBtdXN0IHRyYXZlcnNlIHNvbWUgc2V0IG9mIGlu dGVybWVkaWF0ZSBsaW5rcyBhbmQNCiAgIGdhdGV3YXlzLiAgU3VjaCBnYXRld2F5cyBhcmUgbmF0 dXJhbGx5IGFibGUgdG8gcmVhZCwgbW9kaWZ5LCBvcg0KICAgcmVtb3ZlIGFueSBkYXRhZ3JhbSB0 cmFuc21pdHRlZCBhbG9uZyB0aGF0IHBhdGguICBUaGlzIG1ha2VzIGl0IG11Y2gNCiAgIGVhc2ll ciB0byBtb3VudCBhIHdpZGUgdmFyaWV0eSBvZiBhdHRhY2tzIGlmIHlvdSBhcmUgb24tcGF0aC4N Cg0KVGhpcyBzdWdnZXN0cyB0aGF0IGFuICJvbi1wYXRoIGF0dGFja2VyIiBjYW4gaW5kZWVkIHJl YWQsIG1vZGlmeSBhbmQgcmVtb3ZlIGRhdGFncmFtcy4NCg0KQmFjayB0byB0aGlzIHNwZWNpZmlj IGRvY3VtZW50LCBlbnVtZXJhdGluZyB0aGUgc3BlY2lmaWMgY29sbGVjdGlvbiBvZiBhdHRhY2tl ciBjYXBhYmlsaXRpZXMgX3dpdGhfIGEgZGVzY3JpcHRpb24gb2Ygd2hlcmUgdGhpcyBhZHZlcnNh cnkgd291bGQgbmVlZCB0byBiZSB0b3BvbG9naWNhbGx5IHNlZW1zIGxpa2UgdGhlIHJpZ2h0IGVk aXRvcmlhbCBhcHByb2FjaC4gIEFnYWluLCB0aGFua3MgZm9yIHRyeWluZyB0byBiZSBzbyBjbGVh ci4NCg0KUmVnYXJkcywNClJvbWFuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJhcnJ5IExl aWJhDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDIsIDIwMjAgODo1NiBBTQ0KPiBUbzog R8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+DQo+IENjOiBkcmFm dC1pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZy5hbGxAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtjb3JlXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWVjaG8t cmVxdWVzdC10YWctMTANCj4gDQo+IEZvciB3aGF0IGl0J3Mgd29ydGgsIEkganVzdCByZXZpZXdl ZCBhIHJvdXRpbmcgZG9jdW1lbnQgdGhhdCB1c2VzIHRoZSBwaHJhc2UNCj4gImFuIGF0dGFja2Vy IGluIHRoZSBtaWRkbGUgb2YgdGhlIG5ldHdvcmsiLCB3aGljaCBpcyBhbm90aGVyIG9wdGlvbi4N Cj4gDQo+IEJhcnJ5DQo+IA0KPiBPbiBXZWQsIFNlcCAyLCAyMDIwIGF0IDg6NTIgQU0gR8O2cmFu IFNlbGFuZGVyDQo+IDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiA+DQo+ ID4gSGksDQo+ID4NCj4gPiBBcyBJIHVuZGVyc3RhbmQgInJlcGxhY2UiIGFuZCBDYXJzdGVuJ3Mg cHJvdmlkZWQgZGVmaW5pdGlvbnMsIGFuIG9uLXBhdGgNCj4gYXR0YWNrZXIgZG9lcyBub3QgbmVj ZXNzYXJpbHkgaGF2ZSB0aGF0IGNhcGFiaWxpdHkuIEJ1dCBJIGFncmVlIHdpdGggSm9obidzDQo+ IHByb3Bvc2FsIGFuZCB1cGRhdGVkIHRoZSBnaXRodWIgdmVyc2lvbiBhY2NvcmRpbmdseS4gSW4g dGhlIHNhbWUgd2F5IEkgYWxzbw0KPiByZXBsYWNlZCB0aGUgb25seSB1c2Ugb2YgIm9uLXBhdGgg YXR0YWNrZXIiIGluIHRoZSBkcmFmdCB3aXRoICJhdHRhY2tlciIuIFRoZQ0KPiBjb21taXQgaXMg aGVyZToNCj4gPg0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2VjaG8tcmVxdWVzdC10 YWcvY29tbWl0LzI5OTY5YzQNCj4gPg0KPiA+IEFueSBvdGhlciBjb21tZW50cyBvbiB0aGUgcmVj ZW50IGNoYW5nZXM/IFdlIHBsYW4gdG8gc3VibWl0IGEgbmV3DQo+IHZlcnNpb24gb24gRnJpZGF5 Lg0KPiA+DQo+ID4gR8O2cmFuDQo+ID4NCj4gPg0KPiA+IO+7v09uIDIwMjAtMDktMDEsIDIxOjI5 LCAiQmFycnkgTGVpYmEiIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gd3JvdGU6DQo+ID4NCj4g PiAgICAgSm9obiBoYXMgYSBnb29kIHBvaW50IGhlcmUsIGFuZCBJIHN1cHBvcnQgaGlzIHByb3Bv c2FsLg0KPiA+DQo+ID4gICAgIFRoYXQgc2FpZCwgcmVtZW1iZXI6IEkgZGlkIHNheSB0aGF0IGl0 J3Mgbm90IGEgYmlnIGRlYWwgYW5kIEknbQ0KPiA+ICAgICBsZWF2aW5nIGl0IHRvIHknYWxsJ3Mg YmVzdCBqdWRnbWVudC4gIEFsbCBJIHdhbnRlZCB3YXMgZm9yIHlvdSB0bw0KPiA+ICAgICBjb25z aWRlciB0aGUgaXNzdWUuLi4gbm90IHRvIHJlaGFzaCAiZnVuIiBkaXNjdXNzaW9ucyBmcm9tIGVs c2V3aGVyZS4NCj4gPiAgICAgQW5kIHdoaWNoZXZlciB3YXkgeW91IGNob29zZSBpc24ndCBnb2lu ZyB0byBibG9jayB0aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4gICAgIEJhcnJ5DQo+ID4NCj4gPiAg ICAgT24gVHVlLCBTZXAgMSwgMjAyMCBhdCAzOjEzIFBNIEpvaG4gTWF0dHNzb24NCj4gPGpvaG4u bWF0dHNzb25AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gPiAgICAgPg0KPiA+ICAgICA+IEluIHRo aXMgc2VudGVuY2UgSSB0aGluayBvbi1wYXRoIGF0dGFja2VyIHdvcmtzIHF1aXRlIHdlbGwgb3Ig ZXZlbiBiZXR0ZXIuDQo+IEl0IGFscmVhZHkgZm9sbG93cyBmcm9tIHRoZSBzZW50ZW5jZSB0aGF0 IHRoZSBhdHRhY2tlciBpcyBhYmxlIHRvIHJlcGxhY2Ugb25lDQo+IGJsb2NrIHdpdGggYW5vdGhl ci4gVGhlIGF0dGFja2VyIGluIHRoaXMgY2FzZSBkb2VzIG9ubHkgbmVlZHMgdG8gYmUgYWJsZSB0 bw0KPiByZW9yZGVyIHBhY2tldHMgZmxvd2luZyBpbiBvbmUgZGlyZWN0aW9uIG9mIHRoZSBjb21t dW5pY2F0aW9uLg0KPiA+ICAgICA+DQo+ID4gICAgID4gV2UgY291bGQgYWxzbyBqdXN0IHVzZSB0 aGUgd29yZCBhdHRhY2tlciwgZS5nLg0KPiA+ICAgICA+DQo+ID4gICAgID4gIml0IGlzIHN0aWxs IHBvc3NpYmxlIGZvciBhbiBhdHRhY2tlciBhYmxlIHRvIHJlb3JkZXIgcGFja2V0cyBvbiB0aGUg cGF0aA0KPiBmcm9tIGNsaWVudCB0byBzZXJ2ZXIgdG8gbWFsaWNpb3VzbHkgcmVwbGFjZSBhIGxh dGVyIG9wZXJhdGlvbidzIGJsb2NrcyB3aXRoIGFuDQo+IGVhcmxpZXIgb3BlcmF0aW9uJ3MgYmxv Y2tzLiINCj4gPiAgICAgPg0KPiA+ICAgICA+IENoZWVycywNCj4gPiAgICAgPiBKb2huDQo+ID4g ICAgID4NCj4gPiAgICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ICAgICA+IEZy b206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KPiA+ICAgICA+IERhdGU6IFR1ZXNk YXksIDEgU2VwdGVtYmVyIDIwMjAgYXQgMTg6NDANCj4gPiAgICAgPiBUbzogR8O2cmFuIFNlbGFu ZGVyIDxnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4gPiAg ICAgPiBDYzogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPiwgImRyYWZ0LWll dGYtY29yZS1lY2hvLQ0KPiByZXF1ZXN0LXRhZy5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWNv cmUtZWNoby1yZXF1ZXN0LXRhZy5hbGxAaWV0Zi5vcmc+LA0KPiAiY29yZUBpZXRmLm9yZyIgPGNv cmVAaWV0Zi5vcmc+DQo+ID4gICAgID4gU3ViamVjdDogUmU6IFtjb3JlXSBBRCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWctMTANCj4gPiAgICAgPiBSZXNlbnQgZnJv bTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ID4gICAgID4gUmVzZW50IHRvOiA8Y2hyaXN0 aWFuQGFtc3Vlc3MuY29tPiwgSm9obiBNYXR0c3Nvbg0KPiA8am9obi5tYXR0c3NvbkBlcmljc3Nv bi5jb20+LCA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiwNCj4gPGphaW1lQGlraS5maT4s IDxtYXJjby50aWxvY2FAcmkuc2U+LCA8YmFycnlsZWliYUBnbWFpbC5jb20+LA0KPiA8c3VwZXJ1 c2VyQGdtYWlsLmNvbT4sIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4sIE1hcmNvIFRpbG9jYQ0K PiA8bWFyY28udGlsb2NhQHJpLnNlPg0KPiA+ICAgICA+IFJlc2VudCBkYXRlOiBUdWVzZGF5LCAx IFNlcHRlbWJlciAyMDIwIGF0IDE4OjQwDQo+ID4gICAgID4NCj4gPiAgICAgPiAgICAgT24gMjAy MC0wOS0wMSwgYXQgMTY6MTksIEfDtnJhbiBTZWxhbmRlcg0KPiA8Z29yYW4uc2VsYW5kZXI9NDBl cmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ICAgICA+ICAgICA+DQo+ID4g ICAgID4gICAgID4NCj4gPiAgICAgPiAgICAgPiAgICDigJQgU2VjdGlvbiAzLjUuMSDigJQNCj4g PiAgICAgPiAgICAgPg0KPiA+ICAgICA+ICAgICA+ICAgICAgIGlzIHN0aWxsIHBvc3NpYmxlIGZv ciBhIG1hbi1pbi10aGUtbWlkZGxlIHRvIG1hbGljaW91c2x5IHJlcGxhY2UgYQ0KPiA+ICAgICA+ ICAgICA+ICAgICAgIGxhdGVyIG9wZXJhdGlvbidzIGJsb2NrcyB3aXRoIGFuIGVhcmxpZXIgb3Bl cmF0aW9uJ3MgYmxvY2tzDQo+ID4gICAgID4gICAgID4NCj4gPiAgICAgPiAgICAgPiAgICBOb3Qg YSByZXF1aXJlbWVudCBoZXJlLCBhbmQgSSB3aWxsIGFjY2VwdCB5b3VyIGJlc3QganVkZ21lbnQ6 ICBpbg0KPiB0aGUNCj4gPiAgICAgPiAgICAgPiAgICBzcGlyaXQgb2YgcmVjZW50IGRpc2N1c3Np b24gb24gaW5jbHVzaXZlIHZzIGV4Y2x1c2lvbmFyeSBsYW5ndWFnZSwgSQ0KPiBhc2sNCj4gPiAg ICAgPiAgICAgPiAgICB5b3UgdG8gY29uc2lkZXIgY2hhbmdpbmcg4oCcYSBtYW4taW4tdGhlLW1p ZGRsZeKAnSB0byDigJxhbiBvbi1wYXRoDQo+IGF0dGFja2Vy4oCdLg0KPiA+ICAgICA+ICAgICA+ DQo+ID4gICAgID4gICAgID4gW0dTXSBJIHRob3VnaHQgdGhlcmUgd2FzIGEgc2xpZ2h0IGRpZmZl cmVuY2UgYmV0d2VlbiAib24tcGF0aA0KPiBhdHRhY2tlciIgYW5kICJtYW4taW4tdGhlLW1pZGRs ZeKAnSwgaW4gdGhhdCB0aGUgbGF0dGVyIGhhcyBhY2Nlc3MgdG8gdGhlIG1lc3NhZ2UNCj4gZmxv dyB3aGVyZWFzIHRoZSBmb3JtZXIgbmVlZCBub3QgaGF2ZS4gRm9yIGV4YW1wbGUsIGFuIG9uLXBh dGggYXR0YWNrZXIgbWF5DQo+IG9ubHkgYmUgYWJsZSB0byBpbmplY3QgbWVzc2FnZXMuIEluIHRo aXMgY2FzZSAoInJlcGxhY2UiKSB0aGUgbGF0dGVyIHdvdWxkIHRoZW4gYmUNCj4gbW9yZSBwcmVj aXNlLiBJZiBJJ20gcmlnaHQgdGhlbiBJIHByb3Bvc2Ugd2UgdXNlIGF2YWlsYWJsZSBkaXN0aW5j dGlvbnMgcGVuZGluZyBhDQo+IG5ldyBkaWN0aW9uYXJ5LCBvdGhlcndpc2UgSSdtIGZpbmUgd2l0 aCBjaGFuZ2luZy4NCj4gPiAgICAgPg0KPiA+ICAgICA+ICAgICBPaCwgc28gd2UgYXJlIGdldHRp bmcgdG8gaGF2ZSB0aGlzIGZ1biBkaXNjdXNzaW9uIG9uICp0aGlzKiBkcmFmdC4NCj4gPiAgICAg Pg0KPiA+ICAgICA+ICAgICBBIE1JVE0gY2FuIHJlYWQsIGluamVjdCwgZGVsZXRlLCBhbmQgbW9k aWZ5IGRhdGEuDQo+ID4gICAgID4NCj4gPiAgICAgPiAgICAgQW4gb24tcGF0aCBhdHRhY2tlciBj YW4gcmVhZCBhbmQgaW5qZWN0LCBidXQgbm90IG5lY2Vzc2FyaWx5IGRlbGV0ZSBvcg0KPiBtb2Rp ZnkgZGF0YS4NCj4gPiAgICAgPg0KPiA+ICAgICA+ICAgICBJIHdvdWxkIG5vdCB1c2UgdGhlIGxh dHRlciBhcyBhIHN5bm9ueW0gZm9yIHRoZSBmb3JtZXIuDQo+ID4gICAgID4NCj4gPiAgICAgPiAg ICAgVGhlIG90aGVyIHByb3Bvc2FsIGluDQo+IGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20v djEvdXJsP2s9OGJjOGJhMjEtZDU3ODI3YjktOGJjOGZhYmEtDQo+IDg2MWZjYjk3MmJmYy1hZmUy MGIyZDg5YmJkNjY3JnE9MSZlPTQwNmZiYjcyLWIyZjAtNDg0NC1iZDExLQ0KPiAzZmY1NzBlZGFm MGYmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZpZXRmJTJGdGVybWlub2xvZ3kgaXMgZXZl bg0KPiBtb3JlIGJyb2tlbjogQW4gaW1wZXJzb25hdGlvbiBhdHRhY2tlciBkb2VzbuKAmXQgZXZl biBoYXZlIHRvIGJlIG9uLXBhdGguDQo+ID4gICAgID4NCj4gPiAgICAgPiAgICAgKFNlZSBhbHNv IG15IGNvbW1lbnQgb24NCj4gaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az1h MTEwMTgyYy1mZmEwODViNC1hMTEwNThiNy0NCj4gODYxZmNiOTcyYmZjLTI4OTA5OTllNjE0YjA4 NzAmcT0xJmU9NDA2ZmJiNzItYjJmMC00ODQ0LWJkMTEtDQo+IDNmZjU3MGVkYWYwZiZ1PWh0dHBz JTNBJTJGJTJGZ2l0aHViLmNvbSUyRmlldGYlMkZ0ZXJtaW5vbG9neSUyRnB1bGwNCj4gJTJGMSwg d2hpY2ggZmVsbCBieSB0aGUgd2F5c2lkZSBpbiB0aGUgcmVjZW50IGx1bGwgb24gdGhpcyB0b3Bp Yy4pDQo+ID4gICAgID4NCj4gPiAgICAgPiAgICAgSW4gdGhlIG1pZC0yMDAwcywgdGhlcmUgd2Fz IGFuIGF0dGVtcHQgdG8gcmVwbGFjZSBNSVRNIGF0dGFjayBieQ0KPiDigJxtaWRkbGVwZXJzb24g YXR0YWNr4oCdLiAgVGhhdCB1dHRlcmx5IGZhaWxlZCwgYSBzaW1wbGUgR29vZ2xlIHNlYXJjaCBz YXlzIOKAnG1hbi0NCj4gaW4tdGhlLW1pZGRsZeKAnSAoNTQxMDAgaGl0cyBvbiBkbC5hY20ub3Jn KSBpcyBvdmVyd2hlbG1pbmdseSBzdGlsbCB0aGUgdGVybSBvZg0KPiBhcnQgYW5kIG5vdCDigJxt aWRkbGVwZXJzb27igJ0gKDMxIGhpdHMgb24gZGwuYWNtLm9yZykuDQo+ID4gICAgID4NCj4gPiAg ICAgPiAgICAgV2lraXBlZGlhIGF0IGxlYXN0IGtub3dzIGFib3V0IHRoZSBvdGhlciBlc3RhYmxp c2hlZCB3b3JkIGZvciBNSVRNLA0KPiBKYW51cyBhdHRhY2sNCj4gaHR0cHM6Ly9lbi53aWtpcGVk aWEub3JnL3cvaW5kZXgucGhwP3RpdGxlPUphbnVzX2F0dGFjayZyZWRpcmVjdD1ubyDigJQgbm90 DQo+IHZlcnkgc3VjY2Vzc2Z1bCBlaXRoZXIgKDkgaGl0cyBvbiBkbC5hY20ub3JnKS4NCj4gPiAg ICAgPg0KPiA+ICAgICA+ICAgICBPbmUgd29yZCB0aGF0IGFscmVhZHkgaGFzIHRoZSByaWdodCBz ZW1hbnRpY3MgYW5kIGRvZXMgbm90IHJlcXVpcmUNCj4gdGhlIGN1bHR1cmFsIGJhY2tncm91bmQg b2Yg4oCcSmFudXMgYXR0YWNr4oCdIGlzIOKAnEludGVycG9zZXIgYXR0YWNr4oCdLiAgMCBoaXRz IG9uDQo+IGRsLmFjbS5vcmcsIGJ1dCBoYXMgYWxsIHRoZSByaWdodCBwcm9wZXJ0aWVzLiAgU28g aW4gdGhlIGFib3ZlIHdlIHdvdWxkIHJlcGxhY2UNCj4gTUlUTSBieSDigJxpbnRlcnBvc2Vy4oCd Og0KPiA+ICAgICA+DQo+ID4gICAgID4gICAgID4gICAgICAgaXMgc3RpbGwgcG9zc2libGUgZm9y IGFuIGludGVycG9zZXIgdG8gbWFsaWNpb3VzbHkgcmVwbGFjZSBhDQo+ID4gICAgID4gICAgID4g ICAgICAgbGF0ZXIgb3BlcmF0aW9uJ3MgYmxvY2tzIHdpdGggYW4gZWFybGllciBvcGVyYXRpb24n cyBibG9ja3MNCj4gPiAgICAgPg0KPiA+ICAgICA+ICAgICBXRk0sIGV2ZW4gaWYgdGhpcyBpcyBi bGF6aW5nIGEgbmV3IHRyYWlsLg0KPiA+ICAgICA+DQo+ID4gICAgID4gICAgIEdyw7zDn2UsIENh cnN0ZW4NCj4gPiAgICAgPg0KPiA+ICAgICA+DQo+ID4gICAgID4NCj4gPiAgICAgPg0KPiA+DQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBj b3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Wed Sep 2 10:47:13 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB85C3A0C1E; Wed, 2 Sep 2020 10:47:11 -0700 (PDT) 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 WCpHhyj5lgFi; Wed, 2 Sep 2020 10:47:09 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130047.outbound.protection.outlook.com [40.107.13.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 210B83A0B45; Wed, 2 Sep 2020 10:47:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TDB+2/+75TaDSRS2qImP31HdqA/41oOuoHKmROGd19igVnYWlFVu8ppRnX04nvru9m8fimHvMdcrnY5Gj2zd9G5QLisDa3Ey/2V51x2cskHndlNvfEHzEejLfuY4oz0CSdr/MaU4Gd+aw9JuQbvWVM6058GHgAnTnG+zeA28Mwgsy5tMOFIY5ZJx31c1xhE1YJy408LaV/pFsRh+valbWivv8Z6OBppLW+RCe++QrvjwvRGgIIBgj+kY7ZBmMzpnfogGYjIvqVvNaVuUJF42YIsKxKLRP5/TzeCXZpjWl676Vb/d7BGG7d72OXe/H64Tw0slPj53jAtgwWN4Bn6Xvg== 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=mrIMkO5liiKDU59EV3wJBPqb/6eEc7MVp66arTh8Xv4=; b=f3oJvjdWC013xwXH0pkz0Nli7fOg0rK87hIWCu3Wtt3YL4YN6SRO2rbH2jhdFpB79CihXYYYdYp1bwdEI0DXjhwhg1v3vPDhXh2jV3n/5goSdjEmmtlLbznMC1T3q019/5EQCBQHW4XeM1WXOx3eiHtpjy6lLZYVxg4BSBYPpv1cIdnGa6lCzlQupMqRLcFoRHvL+M6E05knc93IxgoEaHMR/06Rrpsy0VXcBip55F4Nctm5YXV2NCHaa+ISV2bse7UN4u5qomhnTmZdgmP3PJQHxyexM2buHz11uLM0pPf/bVKGXH4SQSRQ6tJO68P4esNlK9OjolKct2H0Aky21w== 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=mrIMkO5liiKDU59EV3wJBPqb/6eEc7MVp66arTh8Xv4=; b=TpOzpR+PCy0aEXmNwvQOxq+3nJ9QXiWeahIeawlCHoR7KA3VYeKY049yoJy8xO/PtKUeO7tT0iuFaVUXfEMlDVwFArHPoUvskrBNP6Acsp6CDBAqZND17vBsWAUJe5ssnvizDHSnZ56q/olkg7iVRQDzX2wqCHvZw+wtGRIcu1k= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR0702MB3609.eurprd07.prod.outlook.com (2603:10a6:7:83::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Wed, 2 Sep 2020 17:47:05 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3348.015; Wed, 2 Sep 2020 17:47:05 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Roman Danyliw , Barry Leiba CC: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Thread-Topic: [core] AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWag2783ig3eTTLEWqbjvVPkqoAKlTipYAgACelYCAACq/gIAABEgAgAFE7gD//9+2AIAAC3+AgABnOoA= Date: Wed, 2 Sep 2020 17:47:05 +0000 Message-ID: References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> <0c496ec8d63a439684ccdb3489fd541f@cert.org> In-Reply-To: <0c496ec8d63a439684ccdb3489fd541f@cert.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: cert.org; dkim=none (message not signed) header.d=none;cert.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 893ed501-bd5a-4aa3-6cc9-08d84f6834f1 x-ms-traffictypediagnostic: HE1PR0702MB3609: 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: buJYwAXqDYVy7Q+0CBjUc6odtF/oC7mnmqyEZ38xtMYZIod5dQ7G+f55quLqF5tTBKAsBc7ZZKCBBFbIRSnpK0Zfj3B75bTo+zPtkT26cgbS806zS0JeTWU4OvqYKAeos1JYMoeU1HxV01Fg8TSk6Yek7t4xn7QJ/NSpelRCCEc5xY1cJIKGTTJ4v1puR92KKflUe/yKvZpoYdPOrEPsWzcWJ/3WjDxriHVMd2Hpv3XW81yW39ECEnigfJ8AzGfE1iCIObjAzvwPX0/oako8IKNvE+gtLLqLCgrKTmoQWqluWxGdIDxErKIyleQIiPkZutJOrtbYskZUIqyzKtOqgiZ1AiXRqZbetEosK8gTRSkMpOxV+MEgF8md6S3d+3dTCybaT2J1lEHGtpQ7KSHbQw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(53546011)(2906002)(6506007)(4326008)(186003)(8936002)(36756003)(5660300002)(16799955002)(26005)(6512007)(85182001)(71200400001)(8676002)(2616005)(66556008)(6486002)(66446008)(83380400001)(478600001)(66574015)(86362001)(64756008)(33656002)(66476007)(966005)(76116006)(66946007)(54906003)(316002)(85202003)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: givtomXsBdoUetTSyNYDOjWZh4rmaI7DgiMYd4ygLx/B8D83kiBjYfIlC7SFECHyT4yWlt3xaNes8KcqVXe0M6pZWh+NePbF5oBl6qQDhO0pV0WwUhHYivVLgoOymEYuMAy26+bSaFg3ZBGzM2/M12NVGgTsUtZWfCCD+s1tJ+eC7K8UeTa3Ohzr+NFfFayP6wnC2ufYRRvHi1N5A6+p6ULrFU0zG1Ex2fm06poy391tEW1sk/Z8LCpfT+cbTazQY/qrYqTuRKxVT4IY0T2wK8JuvOLKaXZbkuZwAcs5uwqY5mh/5Rhp9xqo06OVHY+CukapqJqFepPf0Cu1D4+SrboTIxJjQytjzxXtW/ZvYQo771RIjiNR4gUpira10OBPfp0IGjm5gG+bx/V7Pfg6pZY8Q3z1oAUMwFa8d7tW0R9qcOt48zgh7RoFjSbRX97w88ThknszakPtM42mYE8e/I1RwKa/0CV+16SCLBXAErmLFPzGHJ+zSjR+XJNMO8IWtW5F7kcB6vp+hjc07kZNQKAFAafmPHmJlhpmMY2YBJco4+3KFk4Z4YRrrvNy086DbizWkEoLI0UhnV/l1rbrXX7Ve3iWlm0sVD6l0A4bUB4aO3btUlGTTGFsZqyrywVph1cJ7h+piRkYwwDZDwdZaA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <42B744623D92D84A95F1EEC6FF92B515@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 893ed501-bd5a-4aa3-6cc9-08d84f6834f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2020 17:47:05.5236 (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: TMR6fhB1BOID54qNVjX1rOwvEwsbpqdK8leZTEjJFRBryfjUdGR/dbc6fHiWhvqu+PdOgzt00lrA+mAI+kwVbOraFuo7w3URYumcajKw+mY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3609 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 17:47:12 -0000 SGkgUm9tYW4hDQoNClRoYW5rcyBmb3IgeW91ciBpbnB1dCBvbiBsb2NhdGlvbiBhbmQgY2FwYWJp bGl0eSEgDQoNCkZvciB0aGUgYXJndW1lbnRzIHByZXNlbnRlZCBpbiB0aGlzIGRyYWZ0IEkgYmVs aWV2ZSB0aGF0IHRoZSBsb2NhdGlvbiBvZiB0aGUgYXR0YWNrZXIgaXMgbm90IHJlYWxseSByZWxl dmFudC4gRXZlbiBpZiBzb21lIGF0dGFja3MgcmVxdWlyZSB0aGUgYXR0YWNrZXIgdG8gYmUgaW4g YSBjZXJ0YWluIGxvY2F0aW9uLCBpdCBpcyB0aGUgZmFjdCB0aGF0IGFuIGF0dGFjayBpcyBwb3Nz aWJsZSB0aGF0IGlzIHByb3ZpZGluZyB0aGUgbW90aXZhdGlvbiBmb3IgYSByZXF1aXJlZCBzZWN1 cml0eSBmZWF0dXJlLCBub3Qgd2hlcmUgdGhlIGF0dGFja2VyIGlzIGxvY2F0ZWQuIEFuZCBzaW5j ZSB0aGVyZSBpcyBubyBjb21tb25seSBhY2NlcHRlZCBkZWZpbml0aW9uIHByZWNpc2UgZW5vdWdo IGFib3V0IGRpc3RpbmN0aW9uIG9mIGNhcGFiaWxpdGllcyBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQg cXVhbGlmaWVkIGF0dGFja2VyIHJvbGVzLCAgaXQgc2VlbXMgcmVhc29uYWJsZSB0byBsZWF2ZSBv dXQgdGhhdCBxdWFsaWZpY2F0aW9uIGFsdG9nZXRoZXIuIFRoaXMgaXMgd2hhdCB3ZSBkbyBpbiB0 aGUgbGF0ZXN0IHZlcnNpb24gb24gZ2l0aHViIFsxXSwgd2hlcmUgb25seSB0aGUgY2FwYWJpbGl0 aWVzIG9mIHRoZSBhdHRhY2tlciBhcmUgYmVpbmcgZGVzY3JpYmVkLiBEb2VzIHRoaXMgbWF0Y2gg eW91ciBleHBlY3RhdGlvbnM/IA0KDQpUaGFua3MNCkfDtnJhbg0KDQpbMV0gRWRpdG9yJ3MgY29w eTogaHR0cHM6Ly9jb3JlLXdnLmdpdGh1Yi5pby9lY2hvLXJlcXVlc3QtdGFnL2RyYWZ0LWlldGYt Y29yZS1lY2hvLXJlcXVlc3QtdGFnLmh0bWwNCg0KDQrvu79PbiAyMDIwLTA5LTAyLCAxNTozNywg IlJvbWFuIERhbnlsaXciIDxyZGRAY2VydC5vcmc+IHdyb3RlOg0KDQogICAgSGkhDQoNCiAgICBU aGUgbm90aW9uIG9mIGRlZmluaW5nLCBsYWJlbGxpbmcgYW5kIGRpc2N1c3NpbmcgdGhlIGRpc3Rp bmN0aW9uIGJldHdlZW4gYXR0YWNrZXJzIHdobyBjYW4gcmVhZCwgaW5qZWN0LCBkZWxldGUsIGFu ZCBtb2RpZnkgZGF0YSB2cy4gcmVhZCBhbmQgaW5qZWN0LCBidXQgbm90IG5lY2Vzc2FyaWx5IGRl bGV0ZSBvbiBtb2RpZnkgZGF0YSwgc2VlbXMgbGlrZSBoZWxwZnVsIHByZWNpc2lvbi4gIFRoYW5r cyBmb3IgZG9pbmcgaXQuICANCg0KICAgIFRvIG1ha2UgYSBmZXcgZ2VuZXJhbCBjb21tZW50cyAu Li4NCg0KICAgIEZvciBtZSwgIm9uLXBhdGgiIHNwZWFrcyB0byB3aGVyZSBhbiBhdHRhY2tlciBp cyBsb2NhdGVkIHRvcG9sb2dpY2FsbHksIG5vdCB3aGF0IGNhcGFiaWxpdGllcyB0aGUgYXR0YWNr ZXIgd2lsbCBfYWx3YXlzXyBoYXZlIC0tIHRoZXJlIGNhbiBiZSBtaXRpZ2F0aW5nIGZhY3RvcnMg YmFzZWQgb24gdGhlIHBhcnRpY3VsYXIgZGV0YWlscyBvZiB0aGUgcHJvdG9jb2wgb3Igb3BlcmF0 aW9uYWwgY29uZmlndXJhdGlvbnMuICBJJ2QgYWxzbyBzYXkgdGhlIHNhbWUgZm9yICJNaVRNIiB0 b28uICBGdXJ0aGVybW9yZSwgSSBkb27igJl0IHRoaW5rIHRoYXQgaW4gdGhlIGFic3RyYWN0IHRo YXQgd2UgaGF2ZSBhIGFuIGNvbW1vbmx5IGFjY2VwdGVkIGRlZmluaXRpb24gcHJlY2lzZSBlbm91 Z2ggd2l0aCBNaVRNIHZzLiBvbi1wYXRoIGF0dGFja2VyIHRvIHRoZSBkZWdyZWUgIHRoYXQgd2Ug Y2FuIG1ha2UgdGhlIGRpc3RpbmN0aW9uIHRoYXQgdGhlIGxhdHRlciAoYWdhaW4gaW4gdGhlIGFi c3RyYWN0KSBoYXMgbGVzcyBjYXBhYmlsaXRpZXMgdGhhbiB0aGUgZm9ybWVyIChvciB2aWNlIHZl cnNhKS4gIA0KDQogICAgSW4gdGVybXMgb2YgcHJpb3IgZGVmaW5pdGlvbnMsIGNvbnN1bHRpbmcg U2VjdGlvbiAzLjUgb2YgUkZDMzU1MjoNCg0KICAgIDMuNS4gT24tcGF0aCB2ZXJzdXMgb2ZmLXBh dGgNCg0KICAgICAgIEluIG9yZGVyIGZvciBhIGRhdGFncmFtIHRvIGJlIHRyYW5zbWl0dGVkIGZy b20gb25lIGhvc3QgdG8gYW5vdGhlciwNCiAgICAgICBpdCBnZW5lcmFsbHkgbXVzdCB0cmF2ZXJz ZSBzb21lIHNldCBvZiBpbnRlcm1lZGlhdGUgbGlua3MgYW5kDQogICAgICAgZ2F0ZXdheXMuICBT dWNoIGdhdGV3YXlzIGFyZSBuYXR1cmFsbHkgYWJsZSB0byByZWFkLCBtb2RpZnksIG9yDQogICAg ICAgcmVtb3ZlIGFueSBkYXRhZ3JhbSB0cmFuc21pdHRlZCBhbG9uZyB0aGF0IHBhdGguICBUaGlz IG1ha2VzIGl0IG11Y2gNCiAgICAgICBlYXNpZXIgdG8gbW91bnQgYSB3aWRlIHZhcmlldHkgb2Yg YXR0YWNrcyBpZiB5b3UgYXJlIG9uLXBhdGguDQoNCiAgICBUaGlzIHN1Z2dlc3RzIHRoYXQgYW4g Im9uLXBhdGggYXR0YWNrZXIiIGNhbiBpbmRlZWQgcmVhZCwgbW9kaWZ5IGFuZCByZW1vdmUgZGF0 YWdyYW1zLg0KDQogICAgQmFjayB0byB0aGlzIHNwZWNpZmljIGRvY3VtZW50LCBlbnVtZXJhdGlu ZyB0aGUgc3BlY2lmaWMgY29sbGVjdGlvbiBvZiBhdHRhY2tlciBjYXBhYmlsaXRpZXMgX3dpdGhf IGEgZGVzY3JpcHRpb24gb2Ygd2hlcmUgdGhpcyBhZHZlcnNhcnkgd291bGQgbmVlZCB0byBiZSB0 b3BvbG9naWNhbGx5IHNlZW1zIGxpa2UgdGhlIHJpZ2h0IGVkaXRvcmlhbCBhcHByb2FjaC4gIEFn YWluLCB0aGFua3MgZm9yIHRyeWluZyB0byBiZSBzbyBjbGVhci4NCg0KICAgIFJlZ2FyZHMsDQog ICAgUm9tYW4gDQoNCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9t OiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCYXJyeSBMZWliYQ0K ICAgID4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMiwgMjAyMCA4OjU2IEFNDQogICAgPiBU bzogR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+DQogICAgPiBD YzogZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWcuYWxsQGlldGYub3JnOyBjb3JlQGll dGYub3JnDQogICAgPiBTdWJqZWN0OiBSZTogW2NvcmVdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRm LWNvcmUtZWNoby1yZXF1ZXN0LXRhZy0xMA0KICAgID4gDQogICAgPiBGb3Igd2hhdCBpdCdzIHdv cnRoLCBJIGp1c3QgcmV2aWV3ZWQgYSByb3V0aW5nIGRvY3VtZW50IHRoYXQgdXNlcyB0aGUgcGhy YXNlDQogICAgPiAiYW4gYXR0YWNrZXIgaW4gdGhlIG1pZGRsZSBvZiB0aGUgbmV0d29yayIsIHdo aWNoIGlzIGFub3RoZXIgb3B0aW9uLg0KICAgID4gDQogICAgPiBCYXJyeQ0KICAgID4gDQogICAg PiBPbiBXZWQsIFNlcCAyLCAyMDIwIGF0IDg6NTIgQU0gR8O2cmFuIFNlbGFuZGVyDQogICAgPiA8 Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiB3cm90ZToNCiAgICA+ID4NCiAgICA+ID4gSGks DQogICAgPiA+DQogICAgPiA+IEFzIEkgdW5kZXJzdGFuZCAicmVwbGFjZSIgYW5kIENhcnN0ZW4n cyBwcm92aWRlZCBkZWZpbml0aW9ucywgYW4gb24tcGF0aA0KICAgID4gYXR0YWNrZXIgZG9lcyBu b3QgbmVjZXNzYXJpbHkgaGF2ZSB0aGF0IGNhcGFiaWxpdHkuIEJ1dCBJIGFncmVlIHdpdGggSm9o bidzDQogICAgPiBwcm9wb3NhbCBhbmQgdXBkYXRlZCB0aGUgZ2l0aHViIHZlcnNpb24gYWNjb3Jk aW5nbHkuIEluIHRoZSBzYW1lIHdheSBJIGFsc28NCiAgICA+IHJlcGxhY2VkIHRoZSBvbmx5IHVz ZSBvZiAib24tcGF0aCBhdHRhY2tlciIgaW4gdGhlIGRyYWZ0IHdpdGggImF0dGFja2VyIi4gVGhl DQogICAgPiBjb21taXQgaXMgaGVyZToNCiAgICA+ID4NCiAgICA+ID4gaHR0cHM6Ly9wcm90ZWN0 Mi5maXJlZXllLmNvbS92MS91cmw/az02ZGIwMTNlYi0zMzAwOGU3My02ZGIwNTM3MC04NjFmY2I5 NzJiZmMtYzk3ZDAwMGE5MzAzZDUyZSZxPTEmZT0zNjcxMjU0YS1mOThjLTRiZDQtYWU3NC1hNzRh NTZjNDFkZjUmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJGZWNoby1yZXF1 ZXN0LXRhZyUyRmNvbW1pdCUyRjI5OTY5YzQNCiAgICA+ID4NCiAgICA+ID4gQW55IG90aGVyIGNv bW1lbnRzIG9uIHRoZSByZWNlbnQgY2hhbmdlcz8gV2UgcGxhbiB0byBzdWJtaXQgYSBuZXcNCiAg ICA+IHZlcnNpb24gb24gRnJpZGF5Lg0KICAgID4gPg0KICAgID4gPiBHw7ZyYW4NCiAgICA+ID4N CiAgICA+ID4NCiAgICA+ID4gT24gMjAyMC0wOS0wMSwgMjE6MjksICJCYXJyeSBMZWliYSIgPGJh cnJ5bGVpYmFAY29tcHV0ZXIub3JnPiB3cm90ZToNCiAgICA+ID4NCiAgICA+ID4gICAgIEpvaG4g aGFzIGEgZ29vZCBwb2ludCBoZXJlLCBhbmQgSSBzdXBwb3J0IGhpcyBwcm9wb3NhbC4NCiAgICA+ ID4NCiAgICA+ID4gICAgIFRoYXQgc2FpZCwgcmVtZW1iZXI6IEkgZGlkIHNheSB0aGF0IGl0J3Mg bm90IGEgYmlnIGRlYWwgYW5kIEknbQ0KICAgID4gPiAgICAgbGVhdmluZyBpdCB0byB5J2FsbCdz IGJlc3QganVkZ21lbnQuICBBbGwgSSB3YW50ZWQgd2FzIGZvciB5b3UgdG8NCiAgICA+ID4gICAg IGNvbnNpZGVyIHRoZSBpc3N1ZS4uLiBub3QgdG8gcmVoYXNoICJmdW4iIGRpc2N1c3Npb25zIGZy b20gZWxzZXdoZXJlLg0KICAgID4gPiAgICAgQW5kIHdoaWNoZXZlciB3YXkgeW91IGNob29zZSBp c24ndCBnb2luZyB0byBibG9jayB0aGlzIGRvY3VtZW50Lg0KICAgID4gPg0KICAgID4gPiAgICAg QmFycnkNCiAgICA+ID4NCiAgICA+ID4gICAgIE9uIFR1ZSwgU2VwIDEsIDIwMjAgYXQgMzoxMyBQ TSBKb2huIE1hdHRzc29uDQogICAgPiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+IHdyb3Rl Og0KICAgID4gPiAgICAgPg0KICAgID4gPiAgICAgPiBJbiB0aGlzIHNlbnRlbmNlIEkgdGhpbmsg b24tcGF0aCBhdHRhY2tlciB3b3JrcyBxdWl0ZSB3ZWxsIG9yIGV2ZW4gYmV0dGVyLg0KICAgID4g SXQgYWxyZWFkeSBmb2xsb3dzIGZyb20gdGhlIHNlbnRlbmNlIHRoYXQgdGhlIGF0dGFja2VyIGlz IGFibGUgdG8gcmVwbGFjZSBvbmUNCiAgICA+IGJsb2NrIHdpdGggYW5vdGhlci4gVGhlIGF0dGFj a2VyIGluIHRoaXMgY2FzZSBkb2VzIG9ubHkgbmVlZHMgdG8gYmUgYWJsZSB0bw0KICAgID4gcmVv cmRlciBwYWNrZXRzIGZsb3dpbmcgaW4gb25lIGRpcmVjdGlvbiBvZiB0aGUgY29tbXVuaWNhdGlv bi4NCiAgICA+ID4gICAgID4NCiAgICA+ID4gICAgID4gV2UgY291bGQgYWxzbyBqdXN0IHVzZSB0 aGUgd29yZCBhdHRhY2tlciwgZS5nLg0KICAgID4gPiAgICAgPg0KICAgID4gPiAgICAgPiAiaXQg aXMgc3RpbGwgcG9zc2libGUgZm9yIGFuIGF0dGFja2VyIGFibGUgdG8gcmVvcmRlciBwYWNrZXRz IG9uIHRoZSBwYXRoDQogICAgPiBmcm9tIGNsaWVudCB0byBzZXJ2ZXIgdG8gbWFsaWNpb3VzbHkg cmVwbGFjZSBhIGxhdGVyIG9wZXJhdGlvbidzIGJsb2NrcyB3aXRoIGFuDQogICAgPiBlYXJsaWVy IG9wZXJhdGlvbidzIGJsb2Nrcy4iDQogICAgPiA+ICAgICA+DQogICAgPiA+ICAgICA+IENoZWVy cywNCiAgICA+ID4gICAgID4gSm9obg0KICAgID4gPiAgICAgPg0KICAgID4gPiAgICAgPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gPiAgICAgPiBGcm9tOiBDYXJzdGVuIEJvcm1h bm4gPGNhYm9AdHppLm9yZz4NCiAgICA+ID4gICAgID4gRGF0ZTogVHVlc2RheSwgMSBTZXB0ZW1i ZXIgMjAyMCBhdCAxODo0MA0KICAgID4gPiAgICAgPiBUbzogR8O2cmFuIFNlbGFuZGVyIDxnb3Jh bi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCiAgICA+ID4gICAgID4g Q2M6IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4sICJkcmFmdC1pZXRmLWNv cmUtZWNoby0NCiAgICA+IHJlcXVlc3QtdGFnLmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtY29y ZS1lY2hvLXJlcXVlc3QtdGFnLmFsbEBpZXRmLm9yZz4sDQogICAgPiAiY29yZUBpZXRmLm9yZyIg PGNvcmVAaWV0Zi5vcmc+DQogICAgPiA+ICAgICA+IFN1YmplY3Q6IFJlOiBbY29yZV0gQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnLTEwDQogICAgPiA+ICAgICA+ IFJlc2VudCBmcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NCiAgICA+ID4gICAgID4gUmVz ZW50IHRvOiA8Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPiwgSm9obiBNYXR0c3Nvbg0KICAgID4gPGpv aG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPiwgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4s DQogICAgPiA8amFpbWVAaWtpLmZpPiwgPG1hcmNvLnRpbG9jYUByaS5zZT4sIDxiYXJyeWxlaWJh QGdtYWlsLmNvbT4sDQogICAgPiA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4sIDxiYXJyeWxlaWJhQGNv bXB1dGVyLm9yZz4sIE1hcmNvIFRpbG9jYQ0KICAgID4gPG1hcmNvLnRpbG9jYUByaS5zZT4NCiAg ICA+ID4gICAgID4gUmVzZW50IGRhdGU6IFR1ZXNkYXksIDEgU2VwdGVtYmVyIDIwMjAgYXQgMTg6 NDANCiAgICA+ID4gICAgID4NCiAgICA+ID4gICAgID4gICAgIE9uIDIwMjAtMDktMDEsIGF0IDE2 OjE5LCBHw7ZyYW4gU2VsYW5kZXINCiAgICA+IDxnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNv bUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPiA+ICAgICA+ICAgICA+DQogICAgPiA+ICAg ICA+ICAgICA+DQogICAgPiA+ICAgICA+ICAgICA+ICAgIOKAlCBTZWN0aW9uIDMuNS4xIOKAlA0K ICAgID4gPiAgICAgPiAgICAgPg0KICAgID4gPiAgICAgPiAgICAgPiAgICAgICBpcyBzdGlsbCBw b3NzaWJsZSBmb3IgYSBtYW4taW4tdGhlLW1pZGRsZSB0byBtYWxpY2lvdXNseSByZXBsYWNlIGEN CiAgICA+ID4gICAgID4gICAgID4gICAgICAgbGF0ZXIgb3BlcmF0aW9uJ3MgYmxvY2tzIHdpdGgg YW4gZWFybGllciBvcGVyYXRpb24ncyBibG9ja3MNCiAgICA+ID4gICAgID4gICAgID4NCiAgICA+ ID4gICAgID4gICAgID4gICAgTm90IGEgcmVxdWlyZW1lbnQgaGVyZSwgYW5kIEkgd2lsbCBhY2Nl cHQgeW91ciBiZXN0IGp1ZGdtZW50OiAgaW4NCiAgICA+IHRoZQ0KICAgID4gPiAgICAgPiAgICAg PiAgICBzcGlyaXQgb2YgcmVjZW50IGRpc2N1c3Npb24gb24gaW5jbHVzaXZlIHZzIGV4Y2x1c2lv bmFyeSBsYW5ndWFnZSwgSQ0KICAgID4gYXNrDQogICAgPiA+ICAgICA+ICAgICA+ICAgIHlvdSB0 byBjb25zaWRlciBjaGFuZ2luZyDigJxhIG1hbi1pbi10aGUtbWlkZGxl4oCdIHRvIOKAnGFuIG9u LXBhdGgNCiAgICA+IGF0dGFja2Vy4oCdLg0KICAgID4gPiAgICAgPiAgICAgPg0KICAgID4gPiAg ICAgPiAgICAgPiBbR1NdIEkgdGhvdWdodCB0aGVyZSB3YXMgYSBzbGlnaHQgZGlmZmVyZW5jZSBi ZXR3ZWVuICJvbi1wYXRoDQogICAgPiBhdHRhY2tlciIgYW5kICJtYW4taW4tdGhlLW1pZGRsZeKA nSwgaW4gdGhhdCB0aGUgbGF0dGVyIGhhcyBhY2Nlc3MgdG8gdGhlIG1lc3NhZ2UNCiAgICA+IGZs b3cgd2hlcmVhcyB0aGUgZm9ybWVyIG5lZWQgbm90IGhhdmUuIEZvciBleGFtcGxlLCBhbiBvbi1w YXRoIGF0dGFja2VyIG1heQ0KICAgID4gb25seSBiZSBhYmxlIHRvIGluamVjdCBtZXNzYWdlcy4g SW4gdGhpcyBjYXNlICgicmVwbGFjZSIpIHRoZSBsYXR0ZXIgd291bGQgdGhlbiBiZQ0KICAgID4g bW9yZSBwcmVjaXNlLiBJZiBJJ20gcmlnaHQgdGhlbiBJIHByb3Bvc2Ugd2UgdXNlIGF2YWlsYWJs ZSBkaXN0aW5jdGlvbnMgcGVuZGluZyBhDQogICAgPiBuZXcgZGljdGlvbmFyeSwgb3RoZXJ3aXNl IEknbSBmaW5lIHdpdGggY2hhbmdpbmcuDQogICAgPiA+ICAgICA+DQogICAgPiA+ICAgICA+ICAg ICBPaCwgc28gd2UgYXJlIGdldHRpbmcgdG8gaGF2ZSB0aGlzIGZ1biBkaXNjdXNzaW9uIG9uICp0 aGlzKiBkcmFmdC4NCiAgICA+ID4gICAgID4NCiAgICA+ID4gICAgID4gICAgIEEgTUlUTSBjYW4g cmVhZCwgaW5qZWN0LCBkZWxldGUsIGFuZCBtb2RpZnkgZGF0YS4NCiAgICA+ID4gICAgID4NCiAg ICA+ID4gICAgID4gICAgIEFuIG9uLXBhdGggYXR0YWNrZXIgY2FuIHJlYWQgYW5kIGluamVjdCwg YnV0IG5vdCBuZWNlc3NhcmlseSBkZWxldGUgb3INCiAgICA+IG1vZGlmeSBkYXRhLg0KICAgID4g PiAgICAgPg0KICAgID4gPiAgICAgPiAgICAgSSB3b3VsZCBub3QgdXNlIHRoZSBsYXR0ZXIgYXMg YSBzeW5vbnltIGZvciB0aGUgZm9ybWVyLg0KICAgID4gPiAgICAgPg0KICAgID4gPiAgICAgPiAg ICAgVGhlIG90aGVyIHByb3Bvc2FsIGluDQogICAgPiBodHRwczovL3Byb3RlY3QyLmZpcmVleWUu Y29tL3YxL3VybD9rPThiYzhiYTIxLWQ1NzgyN2I5LThiYzhmYWJhLQ0KICAgID4gODYxZmNiOTcy YmZjLWFmZTIwYjJkODliYmQ2NjcmcT0xJmU9NDA2ZmJiNzItYjJmMC00ODQ0LWJkMTEtDQogICAg PiAzZmY1NzBlZGFmMGYmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZpZXRmJTJGdGVybWlu b2xvZ3kgaXMgZXZlbg0KICAgID4gbW9yZSBicm9rZW46IEFuIGltcGVyc29uYXRpb24gYXR0YWNr ZXIgZG9lc27igJl0IGV2ZW4gaGF2ZSB0byBiZSBvbi1wYXRoLg0KICAgID4gPiAgICAgPg0KICAg ID4gPiAgICAgPiAgICAgKFNlZSBhbHNvIG15IGNvbW1lbnQgb24NCiAgICA+IGh0dHBzOi8vcHJv dGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9YTExMDE4MmMtZmZhMDg1YjQtYTExMDU4YjctDQog ICAgPiA4NjFmY2I5NzJiZmMtMjg5MDk5OWU2MTRiMDg3MCZxPTEmZT00MDZmYmI3Mi1iMmYwLTQ4 NDQtYmQxMS0NCiAgICA+IDNmZjU3MGVkYWYwZiZ1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUy RmlldGYlMkZ0ZXJtaW5vbG9neSUyRnB1bGwNCiAgICA+ICUyRjEsIHdoaWNoIGZlbGwgYnkgdGhl IHdheXNpZGUgaW4gdGhlIHJlY2VudCBsdWxsIG9uIHRoaXMgdG9waWMuKQ0KICAgID4gPiAgICAg Pg0KICAgID4gPiAgICAgPiAgICAgSW4gdGhlIG1pZC0yMDAwcywgdGhlcmUgd2FzIGFuIGF0dGVt cHQgdG8gcmVwbGFjZSBNSVRNIGF0dGFjayBieQ0KICAgID4g4oCcbWlkZGxlcGVyc29uIGF0dGFj a+KAnS4gIFRoYXQgdXR0ZXJseSBmYWlsZWQsIGEgc2ltcGxlIEdvb2dsZSBzZWFyY2ggc2F5cyDi gJxtYW4tDQogICAgPiBpbi10aGUtbWlkZGxl4oCdICg1NDEwMCBoaXRzIG9uIGRsLmFjbS5vcmcp IGlzIG92ZXJ3aGVsbWluZ2x5IHN0aWxsIHRoZSB0ZXJtIG9mDQogICAgPiBhcnQgYW5kIG5vdCDi gJxtaWRkbGVwZXJzb27igJ0gKDMxIGhpdHMgb24gZGwuYWNtLm9yZykuDQogICAgPiA+ICAgICA+ DQogICAgPiA+ICAgICA+ICAgICBXaWtpcGVkaWEgYXQgbGVhc3Qga25vd3MgYWJvdXQgdGhlIG90 aGVyIGVzdGFibGlzaGVkIHdvcmQgZm9yIE1JVE0sDQogICAgPiBKYW51cyBhdHRhY2sNCiAgICA+ IGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93L2luZGV4LnBocD90aXRsZT1KYW51c19hdHRhY2sm cmVkaXJlY3Q9bm8g4oCUIG5vdA0KICAgID4gdmVyeSBzdWNjZXNzZnVsIGVpdGhlciAoOSBoaXRz IG9uIGRsLmFjbS5vcmcpLg0KICAgID4gPiAgICAgPg0KICAgID4gPiAgICAgPiAgICAgT25lIHdv cmQgdGhhdCBhbHJlYWR5IGhhcyB0aGUgcmlnaHQgc2VtYW50aWNzIGFuZCBkb2VzIG5vdCByZXF1 aXJlDQogICAgPiB0aGUgY3VsdHVyYWwgYmFja2dyb3VuZCBvZiDigJxKYW51cyBhdHRhY2vigJ0g aXMg4oCcSW50ZXJwb3NlciBhdHRhY2vigJ0uICAwIGhpdHMgb24NCiAgICA+IGRsLmFjbS5vcmcs IGJ1dCBoYXMgYWxsIHRoZSByaWdodCBwcm9wZXJ0aWVzLiAgU28gaW4gdGhlIGFib3ZlIHdlIHdv dWxkIHJlcGxhY2UNCiAgICA+IE1JVE0gYnkg4oCcaW50ZXJwb3NlcuKAnToNCiAgICA+ID4gICAg ID4NCiAgICA+ID4gICAgID4gICAgID4gICAgICAgaXMgc3RpbGwgcG9zc2libGUgZm9yIGFuIGlu dGVycG9zZXIgdG8gbWFsaWNpb3VzbHkgcmVwbGFjZSBhDQogICAgPiA+ICAgICA+ICAgICA+ICAg ICAgIGxhdGVyIG9wZXJhdGlvbidzIGJsb2NrcyB3aXRoIGFuIGVhcmxpZXIgb3BlcmF0aW9uJ3Mg YmxvY2tzDQogICAgPiA+ICAgICA+DQogICAgPiA+ICAgICA+ICAgICBXRk0sIGV2ZW4gaWYgdGhp cyBpcyBibGF6aW5nIGEgbmV3IHRyYWlsLg0KICAgID4gPiAgICAgPg0KICAgID4gPiAgICAgPiAg ICAgR3LDvMOfZSwgQ2Fyc3Rlbg0KICAgID4gPiAgICAgPg0KICAgID4gPiAgICAgPg0KICAgID4g PiAgICAgPg0KICAgID4gPiAgICAgPg0KICAgID4gPg0KICAgID4gDQogICAgPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gY29yZSBtYWlsaW5n IGxpc3QNCiAgICA+IGNvcmVAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY29yZQ0KDQo= From nobody Wed Sep 2 15:41:52 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695FA3A1215 for ; Wed, 2 Sep 2020 15:41:51 -0700 (PDT) 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 ox-wWidl_u4J for ; Wed, 2 Sep 2020 15:41:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E764A3A1212 for ; Wed, 2 Sep 2020 15:41:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 61912389AB for ; Wed, 2 Sep 2020 18:20:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WuO2JFYM6WZf for ; Wed, 2 Sep 2020 18:20:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BB755389AA for ; Wed, 2 Sep 2020 18:20:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 59790B50 for ; Wed, 2 Sep 2020 18:41:47 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] draft-ietf-core-sid progress X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 22:41:51 -0000 --=-=-= Content-Type: text/plain Hi, I think that all of the issues with ietf-core-sid have been dealt with. Can the document go through WGLC now, and advance? Along with draft-ietf-core-yang-cbor-13, I think. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9QH6sACgkQgItw+93Q 3WVVpQgAuHGRHIkWqmBs0pglaK6VYSDItcTrI1+2Lyhq/wahjYaAVVGHs4ZQO8Xk c9tQK9Y3iP+hRsJSto3u4dS2jJzWEJ9peE3Q1k/tdvecIVoVAJpLJL8jN4hdUPVm ilIB0r9e3SB0m3FzqRqBKM5A7NNfKVFY8UB3jZLku4OSTMKg2JsMBkzvws25kGAQ 5Fp2OSV8nRbnt7FiEmjGnKUQZuiU5A7g/DFMWrDLMap0b7bT4UpDXpBRsP3EZsVr YSkc0QKv64IpENkDhhZEX+lfVqpJhyCtAYqKKECcMnti0bPPOlyuyMa21szNCp8c d1zb+rCFS0fFQaFz2iuAiNAQt0aYMg== =cJ/F -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 3 00:59:15 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E17B3A0BAC; Thu, 3 Sep 2020 00:59:13 -0700 (PDT) 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 Z4BfJD6IwrjH; Thu, 3 Sep 2020 00:59:11 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2053.outbound.protection.outlook.com [40.107.22.53]) (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 C45323A0BA5; Thu, 3 Sep 2020 00:59:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TZndow66m5P7GnEZ/h2MmMfyVLUkAbftkQs+PwI3Jxz+6dT3A28W0WJwj5j7JXfug0X6ALpNGqBZQE5xSSydO3zxJc+iGB0pnosrfJWokMzopk5afqP2VFGHixClT1pFz9bU+61dH2oHHsGO4e6E/NPg9wenVxo7wmDHC7N/hzPMAOjNEWOuML9/OEF8qYNJkL/+iqb0SnBUnBmg3O8GG/GphN03pYqwTYKnfjjUyrpz+mVctk7MMIsgMDf7/eOan+6e432hMCXEgx3HiHjmz2s9CaKGldkkI0F+Xu8W+Wkrc2RD2TX7xfwpvnuwuovtBCkUZKHc26NXekwGukcwsQ== 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=lXjc5cgINb3ZWwRglTnZWAeydorBG0QaikPctmTOal0=; b=cLdCf84GzaVdMpD07dU45Jbx7Lb183P4E/0pSfuYaJGSA0jFRJLcc6KEdfvp8msjYFkqZtzcdS/0XHpEsF8QdGydP1hlcoUIvV8eojV+48urAS5QoILXpQFh+zAD7aIAHBUDEuVh/ydsVfNmVGHSbhs1X6XZ267im4uqNCyGuj4FCGU+rKMWSJK5W39EVvoao18I49z0Qn6SAPSPT/WQfVPI2BgdjHNBwqYrDw5ywGC3w9UbLhBRpq/+PF4aKTg6IWo3Enn8P3SAq1Da/R++k5MUYeBpFw9+xaAcaqbW6/lOvJcoijoK9hwQXiGhRPVMlFvmg7YvKzCWJwmSsGwCKQ== 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=lXjc5cgINb3ZWwRglTnZWAeydorBG0QaikPctmTOal0=; b=NNMnBlwQtUDXR2qzomUDRA1twtMK+/u06GNQaR5aMf8DjLt2ZFobzJAAzLWYK2qdea5vX03TlM3PMEDyqC+z3lmaymbiQbZ9F09FE7+hFI9bH6J+0iEUaEg8orw2h7aTZfyUkq84osQWuAcV1MpWn9piRK7q0qdl8kBenVbSpc0= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR0701MB2956.eurprd07.prod.outlook.com (2603:10a6:3:4c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Thu, 3 Sep 2020 07:59:08 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3348.015; Thu, 3 Sep 2020 07:59:07 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Barry Leiba CC: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Thread-Topic: AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWag2783ig3eTTLEWqbjvVPkqoAKlTipYAgAH6boCAAViZgA== Date: Thu, 3 Sep 2020 07:59:07 +0000 Message-ID: References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5bc8ff40-9daf-4fdc-f9a3-08d84fdf3c3c x-ms-traffictypediagnostic: HE1PR0701MB2956: 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: 77ouaRknrzbRNrXwlYCQpWhqsgi9HykXzD27UPyAPVLGyPYWGZRHEny5AjrEGsSIjYeBCExJkYhMwCzyNx222EfQR9i1D7XfJv6vs31Nfv2/8B8Tl72hslviQ7IApYlFQGj5CdZYafylh1tvCdY7nKB2vuwldxhvhDQt59Bw7ojpDDrty5WaCAxC9c94gIsGajdnquwMS0Hpxuviuaf/e6Lyx/go+RS+cJA9cPyBZGH7YKToNjLwMLC52I4HlUfW7JBAZqt/gTwykaMAmnITqmaXUsm4yZbylTta/lMrivfEIrOBdAMDkpdw9eTP8UJySJUfnPXTFxqzO43b9MifaIgRdiYFtBp0JoVyZhW6gk8ErZeg/6Tr1Bup/7C+nXLQ4kkncdMloQriJqHcWOAfHg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(39860400002)(136003)(376002)(366004)(33656002)(54906003)(2906002)(6506007)(478600001)(2616005)(83380400001)(316002)(26005)(6512007)(5660300002)(85182001)(186003)(66574015)(6486002)(36756003)(30864003)(66556008)(85202003)(71200400001)(8936002)(76116006)(66446008)(966005)(86362001)(6916009)(66946007)(66476007)(8676002)(4326008)(91956017)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 4xrZShDsOA5q/9y6i6gwY+ZOh6QHBNVIM8qZslMfDetjdRv6pkYk4qNkn1yavhCa7pIQnRn1aH/ybqzIyZa5zkipLls/XVJytPlsUrS4/dXTlsKt78f+nmyFEMo3cm1tfvzr52gjL1B2JTt8Ne8q7qptl20eEYlYdqXVuc/h/AXHd9gjaoFnu82zzWrBVi+5rB2vDv4n7ybc0x14VvNkDsuNOc590SeM3ztNe1QdxLdazW00XOllBdSmKtG8Ot3uoeHrCDkPWCLMW7/ScBWGGSRksbGR90clJMyzzpBaTesg4kbNxKrvH3CqOacn69lIpLLe1uvZHZ5+wuK7McD59rtRZPStE0mZrHdkDCxiW0yxXTZ52DkhqjqA8IEGMcWYgO/kMaOQOZETiXxzo1gGj0+YXbB7MBetXzbmUahAmO8WNYFSh5E5eNdcgePrG82mHYNBb08Ev9sglLhVbIjHmEDUg1PYmsomtzPS3nX26ZF/xfHp0OQaMzj/t06pS2iUZVExEUYZsKIjKM4yMMkD6wLh/bUSWydiHHoRTcwtXvnwihV/Iq8TjLjKNhLm+gaya20Uh8d79k2UYE/51o0nDMEdTRLLvOrhZZVtBaDC9azAaAPRtTZmbA+aAxv+dAL1xZxhi2HJcCmH/cphl/xlmw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5bc8ff40-9daf-4fdc-f9a3-08d84fdf3c3c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2020 07:59:07.9155 (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: e3wbXatkyeMsWvuGbOFEqHAhk2tzdeIupB13vn7BiwbA0AXP50YoZaJ3tGnwBDmHuyBwYXMJa3ze64mgjAN6CbtUFnb9xmcVr1ExUApkeyY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2956 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 07:59:14 -0000 SGkgQmFycnksIA0KDQpUaGFua3MgZm9yIGZ1cnRoZXIgZXhwbGFuYXRpb25zLCBtb3JlIGNvbW1l bnRzIGJlbG93LiANCg0KSSByZXN0cnVjdHVyZWQgdGhlIG1haWwsIHRoZSB0d28gb3BlbiBpdGVt cyBmaXJzdCBhbmQgdGhlIGNsb3NlZCBpdGVtcyBhdCB0aGUgZW5kICh3aGljaCBhcmUgcmVzbG92 ZWQgaW4gdGhpcyBjb21taXQ6DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9lY2hvLXJlcXVl c3QtdGFnL2NvbW1pdC9hZmI5YWZkKQ0KDQoNCu+7v09uIDIwMjAtMDktMDIsIDE1OjI2LCAiQmFy cnkgTGVpYmEiIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4gd3JvdGU6DQoNCk9QRU4gSVRFTSAx DQoNCiAgICA+ICAgICBJIHdvdWxkIHByZWZlciBpdCBpZiB0aGUgZG9jdW1lbnQgd2VyZSBzcGVj aWZpYyBhYm91dCB3aGF0IOKAnHdoZW4gQ29BUCBpcw0KICAgID4gICAgIHVzZWQgd2l0aCBzZWN1 cml0eeKAnSBtZWFucywgaWRlYWxseSBub3QgdXNpbmcgdGhhdCBwaHJhc2UgYXQgYWxsLCBhcw0K ICAgID4gICAgIOKAnHNlY3VyaXR54oCdIHdpdGhvdXQgZXhwbGFuYXRpb24gaXNu4oCZdCBtZWFu aW5nZnVsLiAgSWYgeW91IG1lYW4g4oCcb3ZlciBhbg0KICAgID4gICAgIGVuY3J5cHRlZCBjaGFu bmVs4oCdLCBwbGVhc2Ugc2F5IHRoYXQuICBPciBzb21ldGhpbmcgZWxzZT8NCiAgICA+DQogICAg PiBbR1NdIElzIHRoZSBmb3JtdWxhdGlvbiBvZiBzZWN0aW9uIDQuMiBiZXR0ZXIsIGkuZS4gIndo ZW4gQ29BUCBpcyB1c2VkIHdpdGggYSBzZWN1cml0eSBwcm90b2NvbCI/DQogICAgPiBUaGUgdGV4 dCBpbiB0aGUgYWJzdHJhY3Qgd291bGQgdGhlbiByZWFkOg0KICAgID4gIlRoaXMgZG9jdW1lbnQg dXBkYXRlcyBSRkM3MjUyIHdpdGggcmVzcGVjdCB0byB0aGUgY2xpZW50IFRva2VuDQogICAgPiBw cm9jZXNzaW5nIHJlcXVpcmVtZW50cywgZm9yYmlkZGluZyBub24tc2VjdXJlIHJldXNlIG9mIFRv a2VucyB0bw0KICAgID4gZW5zdXJlIGJpbmRpbmcgb2YgcmVzcG9uc2UgdG8gcmVxdWVzdCB3aGVu IENvQVAgaXMgdXNlZCB3aXRoIGEgc2VjdXJpdHkNCiAgICA+IHByb3RvY29sLCAiDQogICAgPg0K ICAgID4gVGhlIHJhdGlvbmFsZSB0byBtZW50aW9uICJ3aGVuIENvQVAgaXMgdXNlZCB3aXRoIGEg c2VjdXJpdHkgcHJvdG9jb2wgIg0KICAgID4gaGVyZSBpcyB0aGF0IGEgbGF5bWFuIHdvdWxkIGV4 cGVjdCBhIGJpbmRpbmcgYmV0d2VlbiByZXNwb25zZSBhbmQNCiAgICA+IHJlcXVlc3QgdG8gaG9s ZCB3aGVuIENvQVAgaXMgdXNlZCB3aXRoIGEgc2VjdXJpdHkgcHJvdG9jb2wgKGluIGNvbnRyYXN0 DQogICAgPiB0byB3aGVuIENvQVAgaXMgdXNlZCB3aXRob3V0IGEgc2VjdXJpdHkgcHJvdG9jb2ws IHdoZW4gbm8gYmluZGluZyBpcw0KICAgID4gZXhwZWN0ZWQpIGFuZCB3b3VsZCB0aGVyZWJ5IGJl IHN1cnByaXNlZCB0aGF0IHRoZSBwcm9wZXJ0eSBkb2VzIG5vdA0KICAgID4gYXV0b21hdGljYWxs eSBob2xkLCBlLmcuLCBmb3IgQ29BUCB3aXRoIERUTFMsIGJ1dCBhZGRpdGlvbmFsbHkgcmVxdWly ZXMNCiAgICA+IHJlc3RyaWN0ZWQgdXNlIG9mIFRva2Vucy4NCg0KICAgIEkgdGhpbmsgdGhhdCAi YSBzZWN1cml0eSBwcm90b2NvbCIgc3VmZmVycyBmcm9tIHRoZSBzYW1lIHByb2JsZW06IHdoYXQN CiAgICBkb2VzICJzZWN1cml0eSIgbWVhbiBoZXJlLCBhbmQgd2hhdCBpcyAiYSBzZWN1cml0eSBw cm90b2NvbCIuICBBZ2FpbjoNCiAgICBpZiB5b3UgbWVhbiAiYW4gZW5jcnlwdGlvbiBwcm90b2Nv bCIsIHRoYXQncyBjbGVhci4gIEJ1dCwgZm9yIGV4YW1wbGUsDQogICAgT0F1dGggaXMgYSBzZWN1 cml0eSBwcm90b2NvbC4gIEVBUCBpcyBhIHNlY3VyaXR5IHByb3RvY29sLiAgRE9UUyBpcyBhDQog ICAgc2VjdXJpdHkgcHJvdG9jb2wuICBZb3UgZG9uJ3QgbWVhbiB0aG9zZSBraW5kcyBvZiBzZWN1 cml0eSBwcm90b2NvbHMuDQogICAgV2UgdXNlICJzZWN1cml0eSIgaW4gc28gbWFueSByZWxhdGVk IGJ1dCBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSB3b3JkDQogICAgInNlY3VyaXR5IiBieSBpdHNl bGYgZG9lc24ndCBleHBsYWluIG11Y2guDQoNCltHU10gT0ssIEkgc2VlLiBZb3UgcmVhZCAiQ29B UCBpcyB1c2VkIHdpdGggYSBzZWN1cml0eSBwcm90b2NvbCIgYXMgYW55IGNvbWJpbmF0aW9uIG9m IENvQVAgYW5kIGEgc2VjdXJpdHkgcHJvdG9jb2wsIHdoZXJlYXMgdGhlIGludGVudGlvbiBpcyAN CiJjb21tdW5pY2F0aW9uIHNlY3VyaXR5IGZvciBDb0FQIG1lc3NhZ2VzIGlzIHByb3ZpZGVkIGJ5 IGEgc2VjdXJpdHkgcHJvdG9jb2wiLCB3aGljaCB0eXBpY2FsbHkgbWVhbnMgQ29BUCB3aXRoIERU TFMsIFRMUyBvciBPU0NPUkUsIGJ1dCB0aGUgc2FtZSBwcm9ibGVtIHN0YXRlbWVudCBpcyByZWxl dmFudCB3aXRoIGUuZy4gSVBzZWMsIG9yIHNvbWUgbGluayBsYXllciBwcm92aWRpbmcgaW50ZWdy aXR5IHByb3RlY3Rpb24uDQoNCldlIG1heSBoYXZlIGEgY29tcGxldGVseSBkaWZmZXJlbnQgZm9y bXVsYXRpb24gb2YgdGhpcyB0ZXh0IChzZWUgYmVsb3cpLCB3aGljaCBhcHBlYXJzIGluIHRoZSBh YnN0cmFjdCwgYnV0IHRoZXJlIGFyZSBhIG51bWJlciBvZiBvdGhlciBvY2N1cnJlbmNlcyBvZiAi c2VjdXJpdHkgcHJvdG9jb2wiIGluIHRoZSBkcmFmdCB3aGVyZSB3ZSBkbyBuZWVkIHRvIHRhbGsg YWJvdXQgdGhlIHByb3RvY29sIHByb3ZpZGluZyBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IGZvciBD b0FQIG1lc3NhZ2VzLCBmb3IgZXhhbXBsZToNCg0KIkNvQVAgc2VydmVyIHJlY2VpdmluZyBhIHJl cXVlc3QgaXMgaW4gZ2VuZXJhbCBub3QgYWJsZSB0byB2ZXJpZnkgd2hlbiB0aGUgcmVxdWVzdCB3 YXMgc2VudCBieSB0aGUgQ29BUCBjbGllbnQuIFRoaXMgcmVtYWlucyB0cnVlIGV2ZW4gaWYgdGhl IHJlcXVlc3Qgd2FzIHByb3RlY3RlZCB3aXRoIGEgc2VjdXJpdHkgcHJvdG9jb2wsIHN1Y2ggYXMg RFRMUy4iDQoNCiJUaGlzIHJlbWFpbnMgdHJ1ZSBldmVuIHdoZW4gQ29BUCBpcyB1c2VkIHRvZ2V0 aGVyIHdpdGggYSBzZWN1cml0eSBwcm90b2NvbCBzdWNoIGFzIERUTFMgb3IgT1NDT1JFLCINCg0K IklmIHVzZWQgd2l0aCBhIHNlY3VyaXR5IHByb3RvY29sIG5vdCBwcm92aWRpbmcgYmluZGluZ3Mg YmV0d2VlbiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIChlLmcuIERUTFMgYW5kIFRMUykgVG9rZW4g cmV1c2UgbWF5IHJlc3VsdCBpbiBzaXR1YXRpb25zIHdoZXJlIGEgY2xpZW50IG1hdGNoZXMgYSBy ZXNwb25zZSB0byB0aGUgd3JvbmcgcmVxdWVzdC4iDQoNCiJUaGUgdXNlIG9mIGEgc2VxdWVuY2Ug bnVtYmVyIGlzIHRoZXJlZm9yZSByZWNvbW1lbmRlZCB3aGVuIENvQVAgaXMgdXNlZCB3aXRoIGEg c2VjdXJpdHkgcHJvdG9jb2wgdGhhdCBkb2VzIG5vdCBwcm92aWRlIGJpbmRpbmdzIGJldHdlZW4g cmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBzdWNoIGFzIERUTFMgb3IgVExTLiINCg0KIlRoZSBzZWN1 cml0eSBwcm92aWRlZCBieSB0aGUgRWNobyBhbmQgUmVxdWVzdC1UYWcgb3B0aW9ucyBkZXBlbmRz IG9uIHRoZSBzZWN1cml0eSBwcm90b2NvbCB1c2VkLiINCg0KRG8geW91IHRoaW5rIHRoZSBzYW1l IHByb2JsZW0gYXBwbHkgYWxzbyB0byB0aGVzZSBzZW50ZW5jZXM/DQoNClR3byBwcm9wb3NhbHM6 DQoNCkEuIFdlIGNoYW5nZSAidXNlZCIgdG8gInByb3RlY3RlZCINCiJDb0FQIG1lc3NhZ2VzIGFy ZSBwcm90ZWN0ZWQgd2l0aCBhIHNlY3VyaXR5IHByb3RvY29sIg0KDQpCLiBGb3IgdGhlIGFic3Ry YWN0LCBhbiBhbHRlcm5hdGl2ZSBpcyB0byBuZWdhdGUgYW5kIHR1cm4gInByZXZlbnQiIGludG8g ImVuc3VyZSI6DQoNCk9MRA0KVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzcyNTIgd2l0aCByZXNw ZWN0IHRvIHRoZSBjbGllbnQgVG9rZW4gcHJvY2Vzc2luZyByZXF1aXJlbWVudHMsIGZvcmJpZGRp bmcgbm9uLXNlY3VyZSByZXVzZSBvZiBUb2tlbnMgdG8gZW5zdXJlIGJpbmRpbmcgb2YgcmVzcG9u c2UgdG8gcmVxdWVzdCB3aGVuIENvQVAgaXMgdXNlZCB3aXRoIGEgc2VjdXJpdHkgcHJvdG9jb2ws IA0KYW5kIHdpdGggcmVzcGVjdCB0byBhbXBsaWZpY2F0aW9uIG1pdGlnYXRpb24sIHdoZXJlIHRo ZSB1c2Ugb2YgRWNobyBpcyBub3cgcmVjb21tZW5kZWQuDQpORVcNClRoaXMgZG9jdW1lbnQgdXBk YXRlcyBSRkM3MjUyIHdpdGggcmVzcGVjdCB0byB0aGUgY2xpZW50IFRva2VuIHByb2Nlc3Npbmcg cmVxdWlyZW1lbnRzLCB0byBtYWtlIHN1cmUgdGhhdCBUb2tlbnMgYXJlIG5vdCB1c2VkIGluIGEg d2F5ICB0aGF0IHJlc3BvbnNlcyByaXNrIGJlaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUgd3Jvbmcg cmVxdWVzdCwgDQphbmQgd2l0aCByZXNwZWN0IHRvIGFtcGxpZmljYXRpb24gbWl0aWdhdGlvbiwg d2hlcmUgdGhlIHVzZSBvZiBFY2hvIGlzIG5vdyByZWNvbW1lbmRlZC4NCg0KSXMgdGhhdCBiZXR0 ZXI/DQoNCg0KDQpPUEVOIElURU0gMg0KDQogICAgPiAgICAgICAgICAgY2hhbmdlZCwgdGhlbiB0 aGUgY2xpZW50IE1VU1QgY29uc2lkZXIgbWVzc2FnZXMgc2VudCB0byBfYW55Xw0KICAgID4gICAg ICAgICAgIGVuZHBvaW50IGFkZHJlc3Mgd2l0aGluIHRoZSBuZXcgb3BlcmF0aW9uJ3Mgc2VjdXJp dHkgY29udGV4dC4NCiAgICA+DQogICAgPg0KICAgID4gICAgIFRoaXMgaXMgYW1iaWd1b3VzLiAg SSB0aGluayB5b3UgbWVhbiDigJx0byBiZSB3aXRoaW7igJ0sIHllcz8NCiAgICA+DQogICAgPiBb R1NdIFRvIG1lLCB0aGlzIHJlYWRzIGJldHRlciBieSByZXBsYWNpbmcgIndpdGhpbiIgd2l0aCAi dXNpbmciOg0KICAgID4gICJJZiBhbnkgZnV0dXJlIHNlY3VyaXR5IG1lY2hhbmlzbXMgYWxsb3cg YSBibG9jay13aXNlIHRyYW5zZmVyIHRvDQogICAgPiBjb250aW51ZSBhZnRlciBhbiBlbmRwb2lu dCdzIGRldGFpbHMgKGxpa2UgdGhlIElQIGFkZHJlc3MpIGhhdmUNCiAgICA+IGNoYW5nZWQsIHRo ZW4gdGhlIGNsaWVudCBNVVNUIGNvbnNpZGVyIG1lc3NhZ2VzIHNlbnQgdG8gKmFueSogZW5kcG9p bnQNCiAgICA+IGFkZHJlc3MgdXNpbmcgdGhlIG5ldyBvcGVyYXRpb24ncyBzZWN1cml0eSBjb250 ZXh0LiINCiAgICA+DQogICAgPiBUaGUgcG9pbnQgaGVyZSBpcyB0aGF0IGEgbmVjZXNzYXJ5IGNv bmRpdGlvbiBmb3IgYSBtYWxpY2lvdXMNCiAgICA+IHJlcGxhY2VtZW50IG9mIGJsb2NrcyB0byB3 b3JrIGlzIHRoYXQgdGhlIHNhbWUgc2VjdXJpdHkgY29udGV4dCBpcw0KICAgID4gdXNlZCwgc2lu Y2Ugb3RoZXJ3aXNlIHRoZSBpbnRlZ3JpdHkgdmVyaWZpY2F0aW9uIHdpbGwgZGV0ZWN0IHRoZQ0K ICAgID4gY2hhbmdlLiBOb3csIGlmIGEgZnV0dXJlIHNwZWNpZmljYXRpb24gYWxsb3dzIHRoZSBz YW1lIHNlY3VyaXR5DQogICAgPiBjb250ZXh0IHRvIGJlIHVzZWQgbW9yZSB3aWRlbHksIHNheSwg ZXZlbiBpZiBJUCBhZGRyZXNzIGhhcyBjaGFuZ2VkLA0KICAgID4gdGhlbiB0aGUgSVAgYWRkcmVz cyBpcyBub3Qgc3VmZmljaWVudCB0byBkZXRlcm1pbmUgd2hhdCBtZXNzYWdlDQogICAgPiBleGNo YW5nZXMgdGhhdCBuZWVkcyB0byBiZSBhc3Nlc3MgYXMgY29uY2x1ZGVkIHdoZW4gcmVjeWNsaW5n IGENCiAgICA+IFJlcXVlc3QtVGFnIHZhbHVlLiBEb2VzIHRoYXQgbWFrZSBtb3JlIHNlbnNlPw0K DQogICAgSSB1bmRlcnN0YW5kIHRoZSBwb2ludDsgdGhhbmtzLiAgSSBzdGlsbCB0aGluayB5b3Ug bmVlZCBzb21ldGhpbmcNCiAgICBvdGhlciB0aGFuIHRoZSBzaW5nbGUgd29yZCAid2l0aGluIiBv ciAidXNpbmciIHRvIG1ha2UgdGhlIGdyYW1tYXINCiAgICB3b3JrIHJpZ2h0Li4uIGl0J3MganVz dCBhIHNtYWxsIHRoaW5nLiAgU28gdHdlYWtpbmcgdGhlIG5ldyB0ZXh0Og0KDQogICAgTkVXDQog ICAgSWYgYW55IGZ1dHVyZSBzZWN1cml0eSBtZWNoYW5pc21zIGFsbG93IGEgYmxvY2std2lzZSB0 cmFuc2Zlcg0KICAgIHRvIGNvbnRpbnVlIGFmdGVyIGFuIGVuZHBvaW50J3MgZGV0YWlscyAoc3Vj aCBhcyB0aGUgSVAgYWRkcmVzcykNCiAgICBoYXZlIGNoYW5nZWQsIHRoZW4gdGhlIGNsaWVudCBN VVNUIGNvbnNpZGVyIG1lc3NhZ2VzIHNlbnQgdG8gKmFueSoNCiAgICBlbmRwb2ludCBhZGRyZXNz IHRvIGJlIHVzaW5nIHRoZSBuZXcgb3BlcmF0aW9uJ3Mgc2VjdXJpdHkgY29udGV4dC4NCiAgICBF TkQNCg0KICAgIE9yICJhcyB1c2luZyIgYWxzbyB3b3Jrcy4gIFdpdGhvdXQgc29tZXRoaW5nIHRo ZXJlLCBvbmUgcmVhZHMNCiAgICAibWVzc2FnZXMgdXNpbmcgdGhlIG5ldyBzZWN1cml0eSBjb250 ZXh0IiBhbmQgcGFyc2VzIHRoYXQgYXMgYQ0KICAgIGNvbXBvdW5kIG5vdW4uLi4gYW5kIHRoZW4g c2F5cywgIm11c3QgY29uc2lkZXIgdGhlbS4uLiBob3c/Ig0KDQpbR1NdIFRoZSBleHBsYW5hdGlv biBmb3IgaG93IHRvIGNvbnNpZGVyIGlzIGluIHRoZSB0ZXh0IHByZWNlZGluZyB0aGlzIGV4Y2Vy cHQsIHNvIEkgbWF5YmUgd2UgbmVlZCB0byBpbnZvbHZlIHRoYXQgdG8gbWFrZSB0aGlzIG1vcmUg Y2xlYXI/IEZvciBleGFtcGxlIGxpa2UgdGhpczoNCg0KT0xEDQoqIFRoZSBjbGllbnQgTVVTVCBO T1QgcmVjeWNsZSBhIHJlcXVlc3QgdGFnIGluIGEgbmV3IG9wZXJhdGlvbiB1bmxlc3MgdGhlIHBy ZXZpb3VzIG9wZXJhdGlvbiBtYXRjaGFibGUgdG8gdGhlIG5ldyBvbmUgaGFzIGNvbmNsdWRlZC4N Cg0KSWYgYW55IGZ1dHVyZSBzZWN1cml0eSBtZWNoYW5pc21zIGFsbG93IGEgYmxvY2std2lzZSB0 cmFuc2ZlciB0byBjb250aW51ZSBhZnRlciBhbiBlbmRwb2ludCdzIGRldGFpbHMgKGxpa2UgdGhl IElQIGFkZHJlc3MpIGhhdmUgY2hhbmdlZCwgdGhlbiAgdGhlIGNsaWVudCBNVVNUIGNvbnNpZGVy IG1lc3NhZ2VzIHNlbnQgdG8gKmFueSogZW5kcG9pbnQgYWRkcmVzcyB1c2luZyB0aGUgbmV3IG9w ZXJhdGlvbidzIHNlY3VyaXR5IGNvbnRleHQuDQoNCk5FVw0KKiBUaGUgY2xpZW50IE1VU1QgTk9U IHJlY3ljbGUgYSByZXF1ZXN0IHRhZyBpbiBhIG5ldyBvcGVyYXRpb24gdW5sZXNzIHRoZSBwcmV2 aW91cyBvcGVyYXRpb24gbWF0Y2hhYmxlIHRvIHRoZSBuZXcgb25lIGhhcyBjb25jbHVkZWQuDQoN CklmIGFueSBmdXR1cmUgc2VjdXJpdHkgbWVjaGFuaXNtcyBhbGxvdyBhIGJsb2NrLXdpc2UgdHJh bnNmZXIgdG8gY29udGludWUgYWZ0ZXIgYW4gZW5kcG9pbnQncyBkZXRhaWxzIChsaWtlIHRoZSBJ UCBhZGRyZXNzKSBoYXZlIGNoYW5nZWQsIHRoZW4gIHdoZW4gYXNzZXNzaW5nIG1hdGNoYWJsZSBv cGVyYXRpb25zIGZvciB0aGUgcHVycG9zZSBvZiByZWN5Y2xpbmcgYSByZXF1ZXN0IHRhZyB0aGUg Y2xpZW50IE1VU1QgY29uc2lkZXIgbWVzc2FnZXMgc2VudCB0byAqYW55KiBlbmRwb2ludCBhZGRy ZXNzIHVzaW5nIHRoZSBuZXcgb3BlcmF0aW9uJ3Mgc2VjdXJpdHkgY29udGV4dC4NCkVORA0KDQpT bywgdGhpcyBpcyBhYm91dCBkZWNpZGluZyB3aGV0aGVyIGEgcGFydGljdWxhciByZXF1ZXN0IHRh ZyBjYW4gYmUgdXNlZCBpbiBhIG5ldyBvcGVyYXRpb24gYnkgY29uc2lkZXJpbmcgYWxsIG1lc3Nh Z2VzIGhhdmluZyB1c2VkIHRoZSBzYW1lIHNlY3VyaXR5IGNvbnRleHQgYXMgd2lsbCBiZSB1c2Vk IGluIHRoZSBuZXcgb3BlcmF0aW9uLCBhbmQgbWFrZSBzdXJlIHRoYXQgdGhleSBhcmUgY29uY2x1 ZGVkLCBpbmNsdWRpbmcgdGhvc2Ugd2hlcmUgZW5kcG9pbnQgZGV0YWlscyBoYXZlIGNoYW5nZWQg KGxpa2UgdGhlIElQIGFkZHJlc3MpDQoNCkRvZXMgdGhhdCBtYWtlIG1vcmUgc2Vuc2U/IENhbiBp dCBiZSBmb3JtdWxhdGVkIGJldHRlcj8NCg0KDQoNCkNMT1NFRCBJVEVNUw0KDQogICAgPiAgICAg ICAgVHdvIHJlcXVlc3QgbWVzc2FnZXMgYXJlIHNhaWQgdG8gYmUgIm1hdGNoYWJsZSIgaWYgdGhl eSBvY2N1ciBiZXR3ZWVuDQogICAgPiAgICAgICAgdGhlIHNhbWUgZW5kcG9pbnQgcGFpciwgaGF2 ZSB0aGUgc2FtZSBjb2RlIGFuZCB0aGUgc2FtZSBzZXQgb2YNCiAgICA+ICAgICAgICBvcHRpb25z IGV4Y2VwdCBmb3IgZWxlY3RpdmUgTm9DYWNoZUtleSBvcHRpb25zIGFuZCBvcHRpb25zIGludm9s dmVkDQogICAgPiAgICAgICAgaW4gYmxvY2std2lzZSB0cmFuc2ZlciAoQmxvY2sxLCBCbG9jazIg YW5kIFJlcXVlc3QtVGFnKS4NCiAgICA+DQogICAgPiAgICAgVGhlcmXigJlzIHNvbWV0aGluZyBt aXNzaW5nIGhlcmU6IHRoaXMgc2F5cywg4oCcWCBpcyB0cnVlIGlmIEEsIEIu4oCdICBJdCBuZWVk cw0KICAgID4gICAgIGFuIOKAnGFuZOKAnSBvciBhbiDigJxvcuKAnSBpbnN0ZWFkIG9mIHRoZSBj b21tYSwgbm8/DQogICAgPg0KICAgID4gW0dTXSBUaGUgaW50ZW50aW9uIHdhcyDigJxYIGlzIHRy dWUgaWYgQSwgQiwgYW5kIEMu4oCdICBEb2VzIHRoaXMgcmVhZCBiZXR0ZXI/DQogICAgPiAiVHdv IHJlcXVlc3QgbWVzc2FnZXMgYXJlIHNhaWQgdG8gYmUgIm1hdGNoYWJsZSIgaWYgdGhleSBvY2N1 ciBiZXR3ZWVuDQogICAgPiB0aGUgc2FtZSBlbmRwb2ludCBwYWlyLCBoYXZlIHRoZSBzYW1lIGNv ZGUsIGFuZCB0aGUgc2FtZSBzZXQgb2Ygb3B0aW9ucw0KICAgID4gd2l0aCB0aGUgZm9sbG93aW5n IGV4Y2VwdGlvbjogZWxlY3RpdmUgTm9DYWNoZUtleSBvcHRpb25zIGFuZCBvcHRpb25zDQogICAg PiBpbnZvbHZlZCBpbiBibG9jay13aXNlIHRyYW5zZmVyIChCbG9jazEsIEJsb2NrMiBhbmQgUmVx dWVzdC1UYWcpIG5lZWQNCiAgICA+IG5vdCBiZSB0aGUgc2FtZS4iDQoNCiAgICBBaCwgSSBzZWUg dGhlIHBvaW50Li4uIGFuZCB0aGlzIGlzIHdoeSBpdCdzIGltcG9ydGFudCB0byBtYWtlIGxpc3QN CiAgICBpdGVtcyBwYXJhbGxlbC4gIE5vdyB0aGF0IEkgZ2V0IHdoYXQgeW91IG1lYW4gSSBjYW4g c3VnZ2VzdCBhIGZpeDoNCg0KICAgIE5FVw0KICAgICAgIFR3byByZXF1ZXN0IG1lc3NhZ2VzIGFy ZSBzYWlkIHRvIGJlICJtYXRjaGFibGUiIGlmIHRoZXkgb2NjdXIgYmV0d2Vlbg0KICAgICAgIHRo ZSBzYW1lIGVuZHBvaW50IHBhaXIsIGhhdmUgdGhlIHNhbWUgY29kZSwgYW5kIGhhdmUgdGhlIHNh bWUgc2V0IG9mDQogICAgICAgb3B0aW9ucywgd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgZWxlY3Rp dmUgTm9DYWNoZUtleSBvcHRpb25zIGFuZA0KICAgICAgIG9wdGlvbnMgaW52b2x2ZWQgaW4gYmxv Y2std2lzZSB0cmFuc2ZlciAoQmxvY2sxLCBCbG9jazIgYW5kDQogICAgICAgUmVxdWVzdC1UYWcp IG5lZWQgbm90IGJlIHRoZSBzYW1lLg0KICAgIEVORA0KDQogICAgKFRoZSBleHRyYSAiaGF2ZSIg aXMgbmVlZGVkIGluIHRoZSB0aGlyZCBsaXN0IGl0ZW0gdG8gbWFrZSB0aGUgbGlzdA0KICAgIHBh cmFsbGVsLiAgT3RoZXJ3aXNlLCB0aGUgdGhpcmQgaXRlbSBsYWNrcyB0aGUgdmVyYiB0aGF0IHRo ZSBvdGhlciB0d28NCiAgICBpdGVtcyBlYWNoIGhhdmUuKQ0KDQpbR1NdwqBUaGFua3MgZm9yIGV4 cGxhaW5pbmchIEZpeGVkLg0KDQogICAgPiAgICAg4oCUIFNlY3Rpb24gMy40IOKAlA0KICAgID4N CiAgICA+ICAgICAgICBXaGF0IGNvbnN0aXR1dGVzIGEgY29uY2x1ZGVkIG9wZXJhdGlvbg0KICAg ID4gICAgICAgIGRlcGVuZHMgb24gdGhhdCBwdXJwb3NlLCBhbmQgaXMgZGVmaW5lZCB0aGVyZS4N CiAgICA+DQogICAgPiAgICAgSeKAmW0gbWlzc2luZyB0aGUgYW50ZWNlZGVudCB0byDigJx0aGVy ZeKAnS4gIFdoZXJlPw0KICAgID4NCiAgICA+IFtHU10gSSByZXBsYWNlZCAidGhlcmUiIHdpdGgg ImFjY29yZGluZ2x5IiBhbmQgcmVwZWF0ZWQgdGhlIHJlZmVyZW5jZSB0byB0aGUgYXBwbGljYXRp b25zOg0KICAgID4gIldoYXQgY29uc3RpdHV0ZXMgYSBjb25jbHVkZWQgb3BlcmF0aW9uIGRlcGVu ZHMgb24gdGhlIHB1cnBvc2UsIGFuZCBpcyBkZWZpbmVkIGFjY29yZGluZ2x5LA0KICAgID4gc2Vl IGV4YW1wbGVzIGluIFNlY3Rpb24gMy41LiINCg0KICAgIFRoYXQncyBjbGVhciwgdGhhbmtzLiAg SnVzdCBwbGVhc2UgY2hhbmdlIHRoZSBjb21tYSBhZnRlcg0KICAgICJhY2NvcmRpbmdseSIgdG8g YSBzZW1pY29sb24uDQoNCltHU10gRG9uZS4NCg0KDQoNCiAgICA+ICAgICAgICBvICBUaGUgY2xp ZW50IE1VU1QgTk9UIHJlZ2FyZCBhIGJsb2NrLXdpc2UgcmVxdWVzdCBvcGVyYXRpb24gYXMNCiAg ICA+ICAgICAgICAgICBjb25jbHVkZWQgdW5sZXNzIGFsbCBvZiB0aGUgbWVzc2FnZXMgdGhlIGNs aWVudCBwcmV2aW91c2x5IHNlbnQgaW4NCiAgICA+ICAgICAgICAgICB0aGUgb3BlcmF0aW9uIGhh dmUgYmVlbiBjb25maXJtZWQgYnkgdGhlIG1lc3NhZ2UgaW50ZWdyaXR5DQogICAgPiAgICAgICAg ICAgcHJvdGVjdGlvbiBtZWNoYW5pc20sIG9yIGFyZSBjb25zaWRlcmVkIGludmFsaWQgYnkgdGhl IHNlcnZlciBpZg0KICAgID4gICAgICAgICAgIHJlcGxheWVkLg0KICAgID4NCiAgICA+ICAgICBJ dOKAmXMgbm90IGNsZWFyIHRvIG1lIGhvdyBhIGNsaWVudCBjYW4gY29tcGx5IHdpdGggdGhpczog aG93IGNhbiB0aGUgY2xpZW50DQogICAgPiAgICAgcG9zc2libHkga25vdyB3aGV0aGVyIHRoZSBt ZXNzYWdlcyBpdCBoYXMgc2VudCB3b3VsZCBiZSBjb25zaWRlcmVkIGludmFsaWQNCiAgICA+ICAg ICBieSB0aGUgc2VydmVyIGlmIHRoZXkgd2VyZSByZXBsYXllZD8gIE9yIGlzIHRoZXJlIHNvbWV0 aGluZyBJ4oCZbSBub3QNCiAgICA+ICAgICB1bmRlcnN0YW5kaW5nPw0KICAgID4NCiAgICA+IFtH U10gVGhlIHNpemUgb2YgdGhlIHJlcGxheSBidWZmZXIgd2luZG93IG1heSBiZSBmaXhlZCBieSB0 aGUNCiAgICA+IGFwcGxpY2F0aW9uIGFuZCBrbm93biB0byB0aGUgY2xpZW50LiBUaGUgd2luZG93 IGNvdWxkIHBvdGVudGlhbGx5IGJlDQogICAgPiBzZXQgc21hbGwsIGUuZy4gaWYgdHJhbnNwb3J0 ZWQgbWVzc2FnZXMgYXJlIHJhcmVseSBlcnJvbmVvdXMuIElmIHRoZQ0KICAgID4gY2xpZW50IHJl Y2VpdmVzIGFuIGludGVncml0eSBwcm90ZWN0ZWQgcmVzcG9uc2UgKG5vdCBuZWNlc3NhcmlseQ0K ICAgID4gcmVsYXRlZCB0byB0aGUgb3BlcmF0aW9uIGluIHF1ZXN0aW9uKSBpdCBjb3VsZCBkZWR1 Y2UgdGhhdCB0aGUgcmVwbGF5DQogICAgPiB3aW5kb3cgaGF2ZSBzbGlkZWQgcGFzdCBhbGwgbWVz c2FnZXMgcmVsYXRlZCB0byB0aGUgb3BlcmF0aW9uIGluDQogICAgPiBxdWVzdGlvbiwgYW5kIHRo ZXJlZm9yZSB0aGUgc2VydmVyIHdvdWxkIG5vdCBhY2NlcHQgcmVwbGF5IG9mIG1lc3NhZ2VzDQog ICAgPiBvZiB0aGlzIG9wZXJhdGlvbi4NCg0KICAgIEFoLCBJIHNlZTsgdGhhbmtzLg0KICAgIFNv IG1heWJlIHB1dHRpbmcgaXQgaW4gYWN0aXZlIHZvaWNlIHdvdWxkIG1ha2UgaXQgYmV0dGVyPzoN Cg0KICAgIE5FVw0KICAgIG8gIFRoZSBjbGllbnQgTVVTVCBOT1QgcmVnYXJkIGEgYmxvY2std2lz ZSByZXF1ZXN0IG9wZXJhdGlvbiBhcw0KICAgIGNvbmNsdWRlZCB1bmxlc3MgYWxsIG9mIHRoZSBt ZXNzYWdlcyB0aGUgY2xpZW50IHByZXZpb3VzbHkgc2VudCBpbiB0aGUNCiAgICBvcGVyYXRpb24g aGF2ZSBiZWVuIGNvbmZpcm1lZCBieSB0aGUgbWVzc2FnZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbg0K ICAgIG1lY2hhbmlzbSwgb3IgdGhlIGNsaWVudCBjYW4gZGV0ZXJtaW5lIHRoYXQgdGhlIHNlcnZl ciB3b3VsZCBub3QNCiAgICBjb25zaWRlciB0aGUgbWVzc2FnZXMgdG8gYmUgdmFsaWQgaWYgdGhl eSB3ZXJlIHJlcGxheWVkLg0KICAgIEVORA0KDQpbR1NdIEZpeGVkLg0KDQpHw7ZyYW4NCg0K From nobody Thu Sep 3 01:07:31 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E908A3A0BB6 for ; Thu, 3 Sep 2020 01:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8G26pmgaWDo for ; Thu, 3 Sep 2020 01:07:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6733A0B9D for ; Thu, 3 Sep 2020 01:07:25 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BhthB5Tt7zyT7; Thu, 3 Sep 2020 10:07:22 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_FE63BF98-7B15-4BEB-A585-67D5EF9EFB14" X-Mao-Original-Outgoing-Id: 620813242.285077-d87e00b058ca9a75ad82d21b0db1d25e Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 3 Sep 2020 10:07:22 +0200 Message-Id: <0FE2DC02-AB29-4865-86A0-68D6DE1BAC41@tzi.org> References: <9E8A2DB5-DEAE-4642-93E4-5D764F20D469@mnot.net> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [core] Fwd: New Version Notification for draft-snell-search-method-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 08:07:30 -0000 --Apple-Mail=_FE63BF98-7B15-4BEB-A585-67D5EF9EFB14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The httpbis WG seems to wake up again to the need of a GET-equivalent = with request payload. Of course, CoAP has such a method in RFC 8132; we call it FETCH. So those of us working on CoAP-HTTP gateways will be interested in = following that work on the HTTP side. Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Mark Nottingham > Subject: Re: New Version Notification for = draft-snell-search-method-02.txt > Date: 2020-09-03 at 06:52:25 CEST > To: HTTP Working Group > Resent-From: ietf-http-wg@w3.org > Archived-At: = > Message-Id: <9E8A2DB5-DEAE-4642-93E4-5D764F20D469@mnot.net> >=20 > Everyone - >=20 > =46rom what I can see, we last talked about this draft at IETF93, in = 2015. There, we considered issuing a Call for Adoption, but that didn't = ever happen. >=20 > I've seen continued interest in it from a variety of people (mostly = outside the WG). >=20 > What do people think about it -- is it worthwhile? Are there any = problems? Consider this a prelude to a CfA... >=20 > Cheers, >=20 >=20 >> On 3 Sep 2020, at 2:00 pm, Julian Reschke = wrote: >>=20 >> (FYI) >>=20 >>=20 >> -------- Weitergeleitete Nachricht -------- >> Betreff: New Version Notification for = draft-snell-search-method-02.txt >> Datum: Wed, 02 Sep 2020 04:00:11 -0700 >> Von: internet-drafts@ietf.org >> An: Ashok Malhotra , James Snell >> , James M Snell , Julian = Reschke >> >>=20 >>=20 >> A new version of I-D, draft-snell-search-method-02.txt >> has been successfully submitted by Julian Reschke and posted to the >> IETF repository. >>=20 >> Name: draft-snell-search-method >> Revision: 02 >> Title: HTTP SEARCH Method >> Document date: 2020-09-02 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-snell-search-method-02.txt >> Status: = https://datatracker.ietf.org/doc/draft-snell-search-method/ >> Htmlized: = https://tools.ietf.org/html/draft-snell-search-method-02 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-snell-search-method >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-snell-search-method-02 >>=20 >> Abstract: >> This specification updates the definition and semantics of the HTTP >> SEARCH request method originally defined by RFC 5323. >>=20 >>=20 >>=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 >> The IETF Secretariat >>=20 >>=20 >>=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 --Apple-Mail=_FE63BF98-7B15-4BEB-A585-67D5EF9EFB14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The httpbis WG seems to wake up again to the need of a = GET-equivalent with request payload.
Of course, CoAP has such a = method in RFC 8132; we call it FETCH.
So those of us = working on CoAP-HTTP gateways will be interested in following that work = on the HTTP side.

Gr=C3=BC=C3=9Fe, Carsten


Begin forwarded = message:

From: = Mark Nottingham <mnot@mnot.net>
Subject: = Re: New Version = Notification for draft-snell-search-method-02.txt
Date: = 2020-09-03 at 06:52:25 CEST
To: = HTTP Working Group <ietf-http-wg@w3.org>
Resent-From: = ietf-http-wg@w3.org
Archived-At: <https://www.w3.org/mid/9E8A2DB5-DEAE-4642-93E4-5D764F20D469@mno= t.net>
Message-Id: <9E8A2DB5-DEAE-4642-93E4-5D764F20D469@mnot.net>

Everyone -

=46rom what I can = see, we last talked about this draft at IETF93, in 2015. There, we = considered issuing a Call for Adoption, but that didn't ever happen.

I've seen continued interest in it from a = variety of people (mostly outside the WG).

What do people think about it -- is it worthwhile? Are there = any problems? Consider this a prelude to a CfA...

Cheers,


On 3 Sep 2020, at 2:00 pm, Julian Reschke = <julian.reschke@gmx.de> wrote:

(FYI)


-------- = Weitergeleitete Nachricht --------
Betreff: New Version = Notification for draft-snell-search-method-02.txt
Datum: = Wed, 02 Sep 2020 04:00:11 -0700
Von: internet-drafts@ietf.org
An: Ashok Malhotra = <malhotrasahib@gmail.com>, James Snell
<jasnell@gmail.com>, James M Snell <jasnell@gmail.com>, = Julian Reschke
<julian.reschke@greenbytes.de>


A new version of I-D, = draft-snell-search-method-02.txt
has been successfully = submitted by Julian Reschke and posted to the
IETF = repository.

Name: = draft-snell-search-method
Revision: 02
Title:= = HTTP SEARCH Method
Document date: = 2020-09-02
Group: Individual Submission
Pages:= = 8
URL:
https://www.ietf.org/internet-drafts/draft-snell-search-method-= 02.txt
Status: =         https://datatracker.ietf.o= rg/doc/draft-snell-search-method/
Htmlized: =       https://tools.ietf.org/html/draft-snel= l-search-method-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-snell-search-method=
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-snell-search-method-0= 2

Abstract:
 This = specification updates the definition and semantics of the HTTP
 SEARCH request method originally defined by RFC = 5323.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat




--
Mark Nottingham =   https://www.mnot.net/



= --Apple-Mail=_FE63BF98-7B15-4BEB-A585-67D5EF9EFB14-- From nobody Fri Sep 4 01:05:09 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B27D3A10EA; Fri, 4 Sep 2020 01:05:06 -0700 (PDT) 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 tGFpUKyk31kq; Fri, 4 Sep 2020 01:05:04 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4423A10E6; Fri, 4 Sep 2020 01:05:03 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0D33B407CF; Fri, 4 Sep 2020 10:05:01 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C49BB74; Fri, 4 Sep 2020 10:04:59 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:752e:5530:91d4:ca87]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E138314B; Fri, 4 Sep 2020 10:04:58 +0200 (CEST) Received: (nullmailer pid 3696986 invoked by uid 1000); Fri, 04 Sep 2020 08:04:58 -0000 Date: Fri, 4 Sep 2020 10:04:58 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?G=F6ran?= Selander , Barry Leiba Cc: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Message-ID: <20200904080458.GA3696849@hephaistos.amsuess.com> References: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 08:05:07 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello G=C3=B6ran, thanks for handling the comments. On the topics in this sub-thread, I'm happy with all the changes, and there's only a single remark left for me to make: > > It=E2=80=99s not clear to me how a client can comply with this: how can= the client > > possibly know whether the messages it has sent would be considered inva= lid > > by the server if they were replayed? Or is there something I=E2=80=99m= not > > understanding? In OSCORE, the size (or style) of the replay window *is* fixed for each security context (and where protocols for establishing an OSCORE context lack the terminology to express it, defaults to 32 messages). That was added precisely for this reason. I've noted that there are a few points in the original mail that have not been taken up, I'm just going through them and will follow up shortly (as I don't suppose they fall under the "consider the rest handled"). Kind regards Christian --=20 There's always a bigger fish. -- Qui-Gon Jinn --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl9R9ScACgkQOY0REtOk veEpZhAAxXpdOme+bdGpw3Ya6XXC6lvmoDGo0POCBQU4U3Z0Si8CR9kZOb39/s7S uNQkIQb4/46LIbD8tFPgQbobfzUKq3wLfSAXyvYWhlGjtN9uGQIBjDJq5QHVjV4h ONXp0rPUQsXfukJy0lVuPH4wNgCvsli61kJ4m8SBUhYGxtsu0HVWwDs66aLPMBfu FAnEz/ZTE26wKPNuZceNwY/M+WSqBVWvzTor6Mma+tD98GFTbTyZ0BWxiddLN4jw KeRFRiP9ttTXScg6eTaRhi/g8p7L7VqHRx0+Hn+V5bljHkbTlHRaBrSce76rQFXQ jOK6uJAZRJrxwO3nHLUcnDWLfLqHG8BGTVTIqWvr9EVTVBScJAfJX35qneQLKxYF GyWl0/ruHH2YyEuUN7iYiJWgRGy3nPlOb8VHNJywwOL0hQyctC3cADKMBzEIi7OK QTeaZ4xzReASXWynizgyknKZMtGep0iGASVZT5B4+qBDUYj4Hp0izSdmLfNAo6j4 7N7EnWgIpShw4cRieuAkqJSdQwM7XRiTniTcqwmOUB1B7MXsH8XpVTPODmYAhjnm 19XPV6tAQxJlITw7WngH7UL1LGecn+3oiirKjaYGGkJY3EbVqQ+rJ389R2aagfJv kgZluR6xgSrz0CpFh1/z+JSHiS+seSiw5Nt7mprBl2o2dAzJnDk= =o0lz -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From nobody Fri Sep 4 01:47:39 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CD93A1179 for ; Fri, 4 Sep 2020 01:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVdrtZVxI8Z8 for ; Fri, 4 Sep 2020 01:47:35 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB5C3A10C7 for ; Fri, 4 Sep 2020 01:47:35 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BjWX525hWzyt0; Fri, 4 Sep 2020 10:47:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <31441.1599086507@localhost> Date: Fri, 4 Sep 2020 10:47:27 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 620902047.2626621-549fdc7549e03e19e9ce4f94e4d16353 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7B3828-F8E4-4099-A018-E49F9FB3E37A@tzi.org> References: <31441.1599086507@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [core] draft-ietf-core-sid progress X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 08:47:38 -0000 Hi Michael, On 2020-09-03, at 00:41, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Hi, I think that all of the issues with ietf-core-sid have been dealt = with. > Can the document go through WGLC now, and advance? > Along with draft-ietf-core-yang-cbor-13, I think. Those documents (the whole CoRECONF cluster) passed 2nd WGLC on = Wednesday, 29th of July. However, we got little in the way of actual reviews, or other feedback = that the changes from the first WGLC are fine and do address the = comments. Maybe I have been a bit too feeble asking for this feedback in August; I = was planning to get some feedback by mid-August = (https://mailarchive.ietf.org/arch/msg/core/SeL1drwM3O3zgbzQb2Ltwj5Voy4). It doesn=E2=80=99t help that I=E2=80=99m now mostly offline till = 2020-09-09. I=E2=80=99m planning to have the shepherd report available by = Mid-September, so we can submit to the IESG. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Sep 4 02:19:50 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DED3A0C23 for ; Fri, 4 Sep 2020 02:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=bbhmail.nl 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 oqJ8QBZACFdK for ; Fri, 4 Sep 2020 02:19:46 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EEF3A10E2 for ; Fri, 4 Sep 2020 02:19:45 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 6A192182CED34; Fri, 4 Sep 2020 09:19:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=UDDv6EIZBO49x/3qi2 5t3+o79f0AC2qp2aRl1ag+udg=; b=fnE4Z96jo/43jZtJMbva3i0XEaQ7S4gakk 87o1IsVfvq30FLKcjoRAMsEZ98iDwaQA/gI2tSMkt7vsOmjBK1CFf8eFjVZfHM7y MbuYNoCvpXdVGLIfnxPyt6aA5ZIvY5RbXT+EAXSP7DCgy+wqCUxTx81z4EO2j8Sc aBY1GBJqQ= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, , RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1534:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2551:2553:2566:2682:2685:2734:2827:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3352:3865:3866:3867:3868:3870:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4362:4860:5007:6117:6119:6248:6261:6657:6659:6678:7903:8603:9010:9025:9036:9177:10004:10400:10848:11232:11658:11783:11914:12043:12050:12109:12291:12379:12438:12663:12683:12740:12895:13139:13618:13846:14093:14095:14096:14180:14181:14721:14819:21060:21080:21433:21451:21627:21939:30003:30054:30060:30070:30090:30091, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, LUA_SUMMARY:none X-HE-Tag: sun67_4801a11270b1 X-Filterd-Recvd-Size: 4650 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Fri, 4 Sep 2020 09:19:44 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c10d4c1b7fd7b03c114fee0c66d471e9" Date: Fri, 04 Sep 2020 11:19:43 +0200 From: Peter van der Stok To: Carsten Bormann Cc: Michael Richardson , core@ietf.org Reply-To: consultancy@vanderstok.org In-Reply-To: <8D7B3828-F8E4-4099-A018-E49F9FB3E37A@tzi.org> References: <31441.1599086507@localhost> <8D7B3828-F8E4-4099-A018-E49F9FB3E37A@tzi.org> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: <10f3dc851ead140b7f3776b2e1710911@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [176.180.82.15] Archived-At: Subject: Re: [core] draft-ietf-core-sid progress X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 09:19:49 -0000 --=_c10d4c1b7fd7b03c114fee0c66d471e9 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed I want to express my full support (once again) thanks and cheerio, Peter Carsten Bormann schreef op 2020-09-04 10:47: > Hi Michael, > > On 2020-09-03, at 00:41, Michael Richardson wrote: > >> Signed PGP part >> >> Hi, I think that all of the issues with ietf-core-sid have been dealt with. >> Can the document go through WGLC now, and advance? >> Along with draft-ietf-core-yang-cbor-13, I think. > > Those documents (the whole CoRECONF cluster) passed 2nd WGLC on Wednesday, 29th of July. > However, we got little in the way of actual reviews, or other feedback that the changes from the first WGLC are fine and do address the comments. > Maybe I have been a bit too feeble asking for this feedback in August; I was planning to get some feedback by mid-August (https://mailarchive.ietf.org/arch/msg/core/SeL1drwM3O3zgbzQb2Ltwj5Voy4). > It doesn't help that I'm now mostly offline till 2020-09-09. > I'm planning to have the shepherd report available by Mid-September, so we can submit to the IESG. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=_c10d4c1b7fd7b03c114fee0c66d471e9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 I want to express my full support (once again)

thanks and cheeri= o,

Peter

Carsten Bormann schreef op 2020-09-04 10:47:

= Hi Michael,

On 2020-09-03, at 00:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Signed PGP part

Hi, I think that all = of the issues with ietf-core-sid have been dealt with.
Can the documen= t go through WGLC now, and advance?
Along with draft-ietf-core-yang-cb= or-13, I think.

Those documents (the whole CoRECONF cluster) passed 2nd WGLC on Wedne= sday, 29th of July.
However, we got little in the way of actual review= s, or other feedback that the changes from the first WGLC are fine and do a= ddress the comments.
Maybe I have been a bit too feeble asking for thi= s feedback in August; I was planning to get some feedback by mid-August (https://mailarchive.iet= f.org/arch/msg/core/SeL1drwM3O3zgbzQb2Ltwj5Voy4).
It doesn’t= help that I’m now mostly offline till 2020-09-09.
I’m pla= nning to have the shepherd report available by Mid-September, so we can sub= mit to the IESG.

Grüße, Carsten

__________= _____________________________________
core mailing list
core@ietf.org
= https://www.ietf.org/mailman/listinfo/core
--=_c10d4c1b7fd7b03c114fee0c66d471e9-- From nobody Fri Sep 4 04:26:28 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1D43A0D6D; Fri, 4 Sep 2020 04:26:26 -0700 (PDT) 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 JsKiVaC7-eJB; Fri, 4 Sep 2020 04:26:23 -0700 (PDT) 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 9E4243A0D51; Fri, 4 Sep 2020 04:26:21 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7700A407CF; Fri, 4 Sep 2020 13:26:18 +0200 (CEST) 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 3FBAA74; Fri, 4 Sep 2020 13:26:15 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:752e:5530:91d4:ca87]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C7591121; Fri, 4 Sep 2020 13:26:14 +0200 (CEST) Received: (nullmailer pid 3719615 invoked by uid 1000); Fri, 04 Sep 2020 11:26:14 -0000 Date: Fri, 4 Sep 2020 13:26:14 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Barry Leiba Cc: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Message-ID: <20200904112614.GA3682231@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 11:26:26 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Barry, thanks for all your comments. Some points went unhandled due to a very curious glitch that had your mail truncated mid-body when it went through the draft mail forwarder but n= ot when it went through the list; here's addressing the tail, grouped by "done", "explained" and "better answered by G=C3=B6ran or John": Done =3D=3D=3D=3D=3D > Nit: [various] Thanks, fixed. > The Request-Tag option is repeatable because this easily allows > stateless proxies to "chain" their origin address. They can perform > the steps of Section 3.5.3 without the need to create an option value > that is the concatenation of the received option and their own value, > and can simply add a new Request-Tag option unconditionally. >=20 > I don=E2=80=99t know what =E2=80=98=E2=80=9Cchain=E2=80=9D their origin a= ddress=E2=80=99 means, and I don=E2=80=99t know > what =E2=80=98their own value=E2=80=99 means. Can you clarify this? Yes that's hard to parse without the mindset I was in when writing it; replaced with [...] because this easily allows several cascaded stateless proxies to ea= ch put in an origin address. > =E2=80=94 Section 3.8 =E2=80=94 >=20 > The threat model here is not an > attacker (because the response is made sure to belong to the current > request by the security layer), but blocks in the client's cache. >=20 > I don=E2=80=99t understand =E2=80=9CThe threat model is blocks in the cli= ent=E2=80=99s cache.=E2=80=9D I > think this needs some rewording to explain better what you mean. Clarified to: The threat model here does not depend on an attacker: a client can construct a wrong representation by assembling it from blocks from different resource states. That can happen when a resource is modified during a transfer, or when some blocks are still valid in the client's cache. > =E2=80=94 Section 4.1 =E2=80=94 >=20 > The wrong response may be an old response for the same > resource or for a completely different resource >=20 > Are you referring to an old response for a completely different resource > (which is what this says as written), or to any response for a completely > different resource (which is what I think you mean)? If the latter, it > should say, =E2=80=9C...or a response for a completely different resource= =E2=80=9D. It does now. > A straightforward mitigation is to mandate clients to not reuse > Tokens until the traffic keys have been replaced. One easy way to > accomplish this is to implement the Token as a counter starting at > zero for each new or rekeyed secure connection. >=20 > This is essentially repeated in the next section. Can you avoid that, > probably by rewording this to say that the next section privides a > mitigation? That indeed sounds like the way to go for that paragraph (although we might just drop it as well); changed to: A straightforward mitigation is to mandate clients to not reuse Tokens until the traffic keys have been replaced. The following section formalizes that. > =E2=80=94 Section 4.2 =E2=80=94 >=20 > One easy way to accomplish this is to implement the Token (or part of > the Token) as a sequence number starting at zero for each new or > rekeyed secure connection, this approach SHOULD be followed. >=20 > This is not a proper sentence: I think it=E2=80=99s two sentences splicd = together, > but it might be that it needs rewording instead. I think it works now that the comma is replaced with a full stop, and the former sentence is put on a paragraph of its own to clearly separate what is mandated and what is recommended. > =E2=80=94 Section 5 =E2=80=94 >=20 > As each pseudoranom number must only be used once, > an implementation need to get a new truly random seed after reboot, > or continously store state in nonvolatile memory, see ([RFC8613], > Appendix B.1.1) for issues and solution approaches for writing to > nonvolatile memory. >=20 > And this also looks like two sentences spliced together. Yes, changed to two sentences. > They MUST only be > used when the request Echo values are integrity protected. >=20 > I think this is a tricky way to word it, and that it invites > misunderstanding. I suggest that it might be better said as, =E2=80=9CTh= ey MUST > NOT be used unless the request Echo values are integrity protected.=E2=80= =9D Agreed and taken verbatim. > =E2=80=94 Section 5.1 =E2=80=94 >=20 > Reusing Tokens in a way so that responses are guaranteed to not be > associated with the wrong request is not trivial as on-path attackers > may block, delay, and reorder messages, requests may be sent to > several servers, and servers may process requests in any order and > send many responses to the same request. >=20 > This is a complicated sentence and it has a lot of cascaded negatives. > Please try rewording it, and consider splitting it up. One way is to sta= rt > with =E2=80=9COn-path=E2=80=9D to the end of the sentence, and then have = another sentence > that says, =E2=80=9CThat makes it non-trivial to reuse tokens...=E2=80=9D I've removed the "to several servers" part as it doesn't really contribute (it can, but not using security protocols other than OSCORE), and reordered it to "it's difficult: this already happens regularly. an attacker may do that. therefore...". Now reads as: Reusing Tokens in a way so that responses are guaranteed to not be associated with the wrong request is not trivial: The server may process requests in any order, and send multiple responses to the same request. An attacker may block, delay, and reorder messages. The use of a sequence number is therefore recommended when CoAP is used with a security protocol that does not provide bindings between requests and responses such as DTLS or TLS. > Unencrypted timestamps MAY > reveal information about the server >=20 > This needs to be =E2=80=9Cmay=E2=80=9D (or =E2=80=9Ccould=E2=80=9D), as i= t=E2=80=99s a statement, not a directive. Agreed, changed to "could". > Like HTTP cookies, the Echo option could potentially be abused as a > tracking mechanism to link to different requests to the same client. >=20 > I can=E2=80=99t follow this sentence, particularly the part with the word= =E2=80=9Cto=E2=80=9D > repeated three times. Please reword it. Reworded to: [...] the Echo option could potentially be abused as a tracking mechanism that identifies a client across requests. > Clients only send Echo to the same > server from which they were received. >=20 > The only possible antecedent to =E2=80=9Cthey=E2=80=9D here is =E2=80=9Cc= lients=E2=80=9D, which is clearly > wrong: you mean =E2=80=9CEcho=E2=80=9D. So this needs rewording. Maybe = use =E2=80=9CEcho > options=E2=80=9D, or something like that. Changed: Clients send Echo values to the same server from which the values were received. > =E2=80=94 Section 8.2 =E2=80=94 > I=E2=80=99m having a hard time deciding whether some of these references = should be > normative, especially 8613. Please give these another review with that in > mind and see if you think any of them should be moved. You can find some > guidance in the relevant IESG Statement < > https://www.ietf.org/about/groups/iesg/statements/normative-informative-r= eferences/>, > keeping in mind the general rule that something that needs to be fully > understood should be normative, while something that just adds extra > enlightenment can be informative. Most of the document can be applied with either DTLS or OSCORE. But given that "[e]ven references that are relevant only for optional features must be classified as normative", Given that we specify behaviors for token handling over transport security (mentioning rekeyings) and body protection for OSCORE, after reading the guidance I'm promoting RFC 6347 DTLS and RFC8613 OSCORE to normative. (CoAP-over-TLS can stay informative as it's only used in "all is fine, move on" context). > A server MAY want to encrypt its timestamps >=20 > I suggest that a server doesn=E2=80=99t =E2=80=9Cwant=E2=80=9D to do anyt= hing. Perhaps it=E2=80=99s better > to say, =E2=80=9CIt might be important to encrypt a server=E2=80=99s time= stamps (see > Section 6)=E2=80=9D. As much as I'd enjoy discussing the concept of "the server" as an overarching entity encompassing its operator, implementer and implementation, I'm taking up the suggestion as not to distract the reader. > repeated transmission failure; in DTLS, if no packages are lost) >=20 > Should that be =E2=80=9Cpackets=E2=80=9D? Yes, fixed. No changes needed IMO =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In those situations, no message has any Request-Tag option set, and > that can be recycled indefinitely. >=20 > I don=E2=80=99t understand what is being =E2=80=9Crecycled=E2=80=9D if yo= u=E2=80=99re not using he > Request-Tag option (also applies to the subsequent sentence). There's an explicit note where request tag recycling is introduced that for the purpose of recycling, the absence of an option is just another "value" for that purpose. > In draft versions of this document, the Request-Tag option used to be > critical and unsafe to forward. That design was based on an > erroneous understanding of which blocks could be composed according > to [RFC7959]. >=20 > It makes sense that this was here during working group discussion. Is > there value in having it in the published RFC? If so, why? It's included that way (and not as a to-be-removed-before-publication) because seeing that there used to be now-considered-wrong interpretations around is valuable information to readers. (Not that I'd insist, but maybe it makes sense that way) > =E2=80=94 Appendix A =E2=80=94 >=20 > security against an attacker guessing echo values is given by s =3D bit > length of r - log2(n). >=20 > What is =E2=80=9Cr=E2=80=9D? Added a "called r" to the introduction of "a (pseudo-)random byte string" at the start of the paragraph. Deferred to the other authors =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Unless a counting Echo value is used, the Echo > option value MUST contain 32 (pseudo-)random bits that are not > predictable for any other party than the server, and SHOULD contain > 64 (pseudo-)random bits. >=20 > What=E2=80=99s the reason for not just using MUST for 64 bits and being d= one with > it? I'd suppose that it's to allow for applications with well controlled power cycles and Echo value changes to reduce their message sizes -- G=C3=B6ran, could you say a bit more here? > Servers MAY use the time since reboot measured in some unit of time. >=20 > For what? It=E2=80=99s not clear to me what this refers to. John, G=C3=B6ran, could this be a leftover from the later changes around server / wall time? Kind regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl9SJFMACgkQOY0REtOk veEykQ//bjBPXV9JUNHNM0VKFpclTCc54zLn4mAjitLo9lFPs+GqTcPm3bElvA6O W9Tx2hBzBelPq35/aEKfhS3OH/A+upfXGFfGUI+/Nh4FRBAfV5OaLxDRrJkiBO5T CYn+Rxwsa5tr7UeeNqe6v20C9+yRE6ZcdN9rwHWo+2C15GZTtvH+IkxsRH50JQr/ BqerXmv8nEf51j0G+71qpxLJ36HK4+ysuEdyZtfA5Bk6g97dQeNCayPysBWixw/n LMi6lAbbARbLMzl2EVIa/lrDsMlh+R1QxNR/jg3CeQKPy82Vr880H388l+EGjHgw ItPv5jnEbOcSPxPm+Gl4vqhaB83jNCyEpt4qXbz06a/Z96woZgs4tH819jZ4gTzp IWE3vAwvOS+y1EgdL1TvIHzWIamppnxxhSvIiz3ZrAsxqguv8rE0Y1NHVhJIVAMq GBJCz9NTHc52b2T1sSJMuxeEsrb8R0bIF3K03tkmVAx8Y7ovfKJ9OzCBgjo5nPCA jbaqxAtnw8cQf7VGjxtQr1YSodfwokPmzJjExcwkpahuna4uPtYGsjmMLJUryW8A Z7spCRvZekmk4tP3Htzlco6qSAHnfdAREgVeF4gQ5/ZK9CGrId66jX4w//1AxnLL l928XPtWDo4XkqBDCcV+aQ45xnLPbSryig1lAo493UHNvQtSrYk= =ATt6 -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From nobody Fri Sep 4 05:12:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7B3A053F; Fri, 4 Sep 2020 05:12:54 -0700 (PDT) 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 07_f2pzMqB8W; Fri, 4 Sep 2020 05:12:53 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70083.outbound.protection.outlook.com [40.107.7.83]) (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 684B83A048A; Fri, 4 Sep 2020 05:12:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O7HuIUTL3CUKbxjdKPsGlYfyE/iEVFL/vYp1b4hI4rIkSj9yPBzhOMZyrtrm9p8b5MlKP+UgbGl2SAAF6afHUwc0xQfYop/ZRbc/KAEGBUP6gPiosayX8Db/poM9Co0z+OAnOf/yo656KaIc4R9s/5McIcehVhQuDqTE7WSQjo3mA0Gd5lbk86HmLp/H91Ev0YQR/gNVaMwoDoYSS1EiFgBaEfBHzKe7iT/nvjvIN+p3VK2zuV0wp4oV2NNPf0fKdSj1WwAdZhqWKZALUMn23PC2JEEeC9d6VEk24L+EXCpdKKUv9IZB3Nlw3R+4eUOfdDFWZB2YotduvRXbnbcHSQ== 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=eR4gtn4OVzc16il1o7YdnSPEiGmbYV/Ur9gMCVFn1hM=; b=Y3Zr33/bH4qD+uZxGAaMdXGsfN4wv2sXgHTh3UnPtAzofh+IRrvNcTsClkl2q9Gd2M1zwBRuk+sBA9+Kzro9FdOxEph8ymQz/Rw7IZdFYzXH3mWXddpt/UIBDJX8y1DHTVQ0n910EK82vOPPLFyXoo3xqdqlyLTVct+cEZsr6TBkcEFpISZrPbCo/LDa9wOUELAv04aAOO1Q19VPLLZ7OwXCBc7CJcQ3zSaYweuW043yIKyJn6NjTA1B7WKFIRe3O4x/kIx2a1UYBel/XqY2bgKcMZj516fUnjNtZwmy6NtpSueLBToFhmSFrbV8j/1VPdUb+0SJsOAkqzKJ4T48BQ== 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=eR4gtn4OVzc16il1o7YdnSPEiGmbYV/Ur9gMCVFn1hM=; b=LQQDg3d0ZwRol+/kxHW26360d7PU5P7/he/KRgV14HohGquTfgVYlSOjdtwGcH+7/ybkFptzjNoutuPr+yYeSrU1Idu8RYGwxVcRV1RjMzAY+e7Yq79KQiJ1FS4xRsgv9ROBa1gY5J95gbNpsI5ImChaNRh7yKY0zk4NN9kOcDc= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR07MB3180.eurprd07.prod.outlook.com (2603:10a6:7:38::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Fri, 4 Sep 2020 12:12:48 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3348.015; Fri, 4 Sep 2020 12:12:48 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Barry Leiba CC: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Thread-Topic: [core] AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWag2783ig3eTTLEWqbjvVPkqoAKlYiEkAgAAuigA= Date: Fri, 4 Sep 2020 12:12:48 +0000 Message-ID: References: <20200904112614.GA3682231@hephaistos.amsuess.com> In-Reply-To: <20200904112614.GA3682231@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4279a95-2652-4471-3cb1-08d850cbd6e4 x-ms-traffictypediagnostic: HE1PR07MB3180: 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: fcbrifwrPDQkCsDiATuz8QCuXtOpMmXFjwTBjUuH7hDbe+z2kLExF9R2KTYikuOKbj4oarmWed5dR+4c87xRDgTIY9d9KNfjxwZlqoiuAoRC5r+/LUme7CO/xeeT5LovPnEKADPqFwAWTKPMDuWhpeQo+L+7vttt58aTajW2KMpTM280HBsS6qRa51kMAxbOclXDZzEDSPKMlTbzgxRJodh6Qr8t7nw7J0ifScR88sKWalCKkmKAh4evss2iEhF2SK5lVaoZXskjzuMxRx7qyjA/dgzVDFTfK4Yzbvar7V8nv+GtEAmQR+jgP8tXkQVSPLlId4mdIkZrb1Z2ai220bL5fsfWVk3XC91mzonjX2LrYohKnUM3QF4q1ZzEYlSD7wjFgHnFrstoP41ML/S1HA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(4326008)(6506007)(54906003)(966005)(316002)(71200400001)(6512007)(36756003)(186003)(26005)(2906002)(83380400001)(85202003)(33656002)(110136005)(86362001)(4744005)(66556008)(91956017)(8676002)(66946007)(85182001)(478600001)(64756008)(66446008)(76116006)(66476007)(5660300002)(2616005)(6486002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rllncuovC9Ko+4o68pgANEQeeYBbLS5RlFNx9mqWuCn51QEKuRuQkCYRpXU+jKdayvWoSXjlXusu04Gk9XdWMrrBON/aQpkRfyKLmP1ZRLQ2hoXsMnu/gCAzfULHEK8g/yTUgWJvAFxV/gQPrfF8V3dGNMqWRfK0oYBZ2wxFl0WYZbk9WQ9U0aJ7NnO+vpK3yv50K3nExrx4pkf07POj0AfCA76IErmfNaeXdBrsyQlZ9Pv+18yWF+tC36Dg38xezC2hHgySXVKzLaASTH6gUUEF+jSJoxx6heeil35oqVTKV8GguZYKj7Vvcx1wK7MoWYnpLsr8d3oDQv/N3L/wGEp5I4ErhuG28woMkvyNNiyBzlBGvu1gDU4rDMI3wQpOLYH9qMmvyMFWV0+S4Hve4tbaXNAuHCjwkRsNMfCsC3PrfBuDsJuq2DCImvpbFIJ6UfnhNILVy7cF2AChWwKyA/9TlWJFMUgteTQFRVFNnTbT49SpwubVRCQ8Dehl/Ppd48C9GKZs3V3hEMdMKQ3vBpeyeAwuNIR5uQ/Cpn92gEH7c90dKAZadUmme96Pa+q6MS8aWgL00CgDjbmpTXMKvXPafZCPvmzjR1D1zqCOwF7iIJI0RAwENUDx0HcpjvB9JTfTFkrCNMgJYec2om+heg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3EFE0EAE3007474C970C566A8107D5CE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4279a95-2652-4471-3cb1-08d850cbd6e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2020 12:12:48.5870 (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: iwZGlQ6a8g8el7sE/3cfCdNAOQGLtgFLA4xeUxLeLcTDgBSb+FRm7dt0S17741Bkq/KnE/IVhyoI03pdTRdrOMQtEzMkjKcVjeihrqaZT0k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3180 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 12:12:55 -0000 DQoNCu+7v09uIDIwMjAtMDktMDQsIDEzOjI2LCAiQ2hyaXN0aWFuIEFtc8O8c3MiIDxjaHJpc3Rp YW5AYW1zdWVzcy5jb20+IHdyb3RlOg0KDQogICAgSGVsbG8gQmFycnksDQoNCiAgICB0aGFua3Mg Zm9yIGFsbCB5b3VyIGNvbW1lbnRzLg0KDQogICAgU29tZSBwb2ludHMgd2VudCB1bmhhbmRsZWQg ZHVlIHRvIGEgdmVyeSBjdXJpb3VzIGdsaXRjaCB0aGF0IGhhZCB5b3VyDQogICAgbWFpbCB0cnVu Y2F0ZWQgbWlkLWJvZHkgd2hlbiBpdCB3ZW50IHRocm91Z2ggdGhlIGRyYWZ0IG1haWwgZm9yd2Fy ZGVyIGJ1dCBub3QNCiAgICB3aGVuIGl0IHdlbnQgdGhyb3VnaCB0aGUgbGlzdDsgDQoNCltHU10g U28sIHRoZSBtYWlsIGZyb20gQmFycnkgZGF0ZWQgVHVlLCAwNCBBdWd1c3QgMjAyMCAwMzoxNiBV VEMgaW4gbXkgbWFpbGJveCAoYW5kIGluIG90aGVyJ3MpIGVuZHMgd2l0aA0KDQoiSG9uZXN0bHks IEnigJltIGhhdmluZyB0cm91YmxlIGZvbGxvd2luZyB0aGUgZXhwbGFuYXRpb25zIGluIHRoaXMg c2VjdGlvbiwgaW4NCmdlbmVyYWwsIHNvIHRoZXJl4oCZcyBhIHJlYXNvbmFibGUgY2hhbmNlIHRo YXQgSSBhbSBtaXNzaW5nIHNvbWV0aGluZy4iDQoNCndoaWNoIHNlZW1lZCB0byBtZSBhdCB0aGUg dGltZSBsaWtlIGEgcmVhc29uYWJsZSBlbmRpbmcgb2YgYSByZXZpZXcgbWFpbCwgYnV0IHRoZXJl IHdhcyBtb3JlOg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3JlL0I2 aHdCRUNjS3E1UVRCVjRuRXI1c0duSUpIQS8NCg0KVGhhbmtzLCBDaHJpc3RpYW4sIGZvciBkZXRl Y3RpbmcgYW5kIHJlc3BvbmRpbmcgdG8gdGhlIHJlbWFpbmluZyBjb21tZW50cyENCg0KR8O2cmFu DQoNCg0KDQo= From nobody Fri Sep 4 13:06:16 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4363A0FA5 for ; Fri, 4 Sep 2020 13:06:13 -0700 (PDT) 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 cFlrg3dEpIAv for ; Fri, 4 Sep 2020 13:06:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F123A0FA1 for ; Fri, 4 Sep 2020 13:06:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C9EE389AF; Fri, 4 Sep 2020 15:45:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iEDyX0fC2HWZ; Fri, 4 Sep 2020 15:45:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 43B6C389AD; Fri, 4 Sep 2020 15:45:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8A3D51AA; Fri, 4 Sep 2020 16:06:07 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , core@ietf.org In-Reply-To: <8D7B3828-F8E4-4099-A018-E49F9FB3E37A@tzi.org> References: <31441.1599086507@localhost> <8D7B3828-F8E4-4099-A018-E49F9FB3E37A@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] draft-ietf-core-sid progress X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 20:06:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2020-09-03, at 00:41, Michael Richardson w= rote: >> >> Signed PGP part >> >> Hi, I think that all of the issues with ietf-core-sid have been deal= t with. >> Can the document go through WGLC now, and advance? >> Along with draft-ietf-core-yang-cbor-13, I think. > Those documents (the whole CoRECONF cluster) passed 2nd WGLC on > Wednesday, 29th of July. Okay, the DT state does not reflect that there was a WGLC! > However, we got little in the way of actual reviews, or other feedback > that the changes from the first WGLC are fine and do address the > comments. okay, I have been through the SID/YANG-CBOR documents many times, and provided extensive comments since last summer. I really hate a +1 process. I wish we could do this some other way. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9Sni4ACgkQgItw+93Q 3WVRVAf8DAJVm06J8ArvkQHSsXRjWGVFTeyl+YZ0eboR91BXfERNaMEtfRgVCFru IOY2GtSv/5jhNq6GebmWrZdUdy3PF+veRJf9dONsAIrUVKSBydxf1WLC1woBYqE5 vKdagUwyLr6ipk6xAka0ta0tR04jYJg7UOCzyivtWD0lNqvv85IBTJinTBnBZYJG rSveEP+5vZIQiNs3ibnyN+T9XXvWgutS4dXUVGV2dl0Si9zwdjJ/uC76jR4/a3NJ ZXqs3NBGP3zPXLgY6ixu9oVGqdGEgEBrUOQBseNmTOrn2Yr74aO8C4STHpY1QHwB QiXaQVi05p3nRk37gPWIBiUli/2FHA== =I8wa -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Sep 5 00:57:11 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220B23A0955 for ; Sat, 5 Sep 2020 00:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mrk41eEgAtH for ; Sat, 5 Sep 2020 00:57:07 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 0C35D3A08CF for ; Sat, 5 Sep 2020 00:57:06 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id j2so9350507ioj.7 for ; Sat, 05 Sep 2020 00:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jhPgVeBNj90obhO7C5FxpNNlt3LonqlRiCazQOhWsnw=; b=BbI5oVp7X3dMNJB6q35QsA1RtJEqOslRFKvKJc2Jz6Mal9f0GodUI/bEuNjYyGo1XE DTf8u7Nc4SoNfi5Dp5TxIOnARLkYIIh+uKI74XKd67/FA1bwpPkp1lfw/cQnESdI6n1f BfclF16iyR2WgyXLs8UlsXv8fADhCg+JUfuRKqyUHNKJLlNSKCdR8jXQM0K0+euF9dZm /UEmHDKyTa9T1O/7Xx0rUANuNY4e7j2/0sfGhvzJpm8462hSkxaphJ56bdSbUTh6MW+5 vmPGxU3hntHIN1FXvr0SGBo3geEPoM4mFpLLRwi7tjFxd0S+MpPt/MLivISt6ZKPBKng Yqfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jhPgVeBNj90obhO7C5FxpNNlt3LonqlRiCazQOhWsnw=; b=Qxso7q5DTxU1r2uS6Wepm9rFkv/9Ny+e/kwWuf5cJHjWQ+dObb335RQC1Bv9+XtL7D HUv1vz7sUlfUaOsPkTP8IX8eynEyQ973Lzan+jKr3BTnSMWZPquzCazsp6oWZvzWR5E1 1NtBNC2c500EKKWgmBkwg1aKywvs+9rE+6xNDUCa8KHcx/llrizb5DXp6reL5JoOEqPP +dWvIqUc5Xdg9RZyaqC/5GEONhr2r3WLU/n7MIssk+A76mgh8NWBKS7hfsp7PyrV1QhK 1MN687xihE4LdP/9gJkmgHaXIqtkos5+VNi6wOT7GjQooCdEDTTYL2EVP3s5XW6Yo56a odww== X-Gm-Message-State: AOAM5306o0X7TsMXvt935I0UaGo7aMn4rlO5+qat4NYCzTobEGkAH5KN jYvV1Mjf3pzFLxznZd2vE4Vq1CZg4PWn+qZWKBiwbg== X-Google-Smtp-Source: ABdhPJyTm0030bvAboD8DEFIIS2h83Zaqj9LEl5WVUbOrnM+BHfwRgp1RLdC3/Bty4790kQZ4dcNqdmhJGJJGKcx5RU= X-Received: by 2002:a6b:680f:: with SMTP id d15mr10427173ioc.198.1599292625725; Sat, 05 Sep 2020 00:57:05 -0700 (PDT) MIME-Version: 1.0 References: <31441.1599086507@localhost> <8D7B3828-F8E4-4099-A018-E49F9FB3E37A@tzi.org> <27349.1599249967@localhost> In-Reply-To: <27349.1599249967@localhost> From: Alexander Pelov Date: Sat, 5 Sep 2020 09:56:54 +0200 Message-ID: To: Michael Richardson Cc: Carsten Bormann , "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="000000000000d9432005ae8c54e2" Archived-At: Subject: Re: [core] draft-ietf-core-sid progress X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 07:57:09 -0000 --000000000000d9432005ae8c54e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, all, As Peter and Michael, +1 on the documents. Best regards, Alexander On Fri, Sep 4, 2020, 22:06 Michael Richardson wrote= : > > Carsten Bormann wrote: > > On 2020-09-03, at 00:41, Michael Richardson > wrote: > >> > >> Signed PGP part > >> > >> Hi, I think that all of the issues with ietf-core-sid have been > dealt with. > >> Can the document go through WGLC now, and advance? > >> Along with draft-ietf-core-yang-cbor-13, I think. > > > Those documents (the whole CoRECONF cluster) passed 2nd WGLC on > > Wednesday, 29th of July. > > Okay, the DT state does not reflect that there was a WGLC! > > > However, we got little in the way of actual reviews, or other > feedback > > that the changes from the first WGLC are fine and do address the > > comments. > > okay, I have been through the SID/YANG-CBOR documents many times, and > provided extensive comments since last summer. > I really hate a +1 process. I wish we could do this some other way. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000d9432005ae8c54e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten, all,

As Peter and Michael, +1 on the documents.

=
Best regards,
Alexander



On Fri, Sep 4, 2020, 22:06 Michael = Richardson <mcr+ietf@sandelma= n.ca> wrote:

Carsten Bormann <cabo@tzi.org> wrote:
=C2=A0 =C2=A0 > On 2020-09-03, at 00:41, Michael Richardson <mc= r+ietf@sandelman.ca> wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Signed PGP part
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Hi, I think that all of the issues with ietf-core-si= d have been dealt with.
=C2=A0 =C2=A0 >> Can the document go through WGLC now, and advance? =C2=A0 =C2=A0 >> Along with draft-ietf-core-yang-cbor-13, I think.
=C2=A0 =C2=A0 > Those documents (the whole CoRECONF cluster) passed 2nd = WGLC on
=C2=A0 =C2=A0 > Wednesday, 29th of July.

Okay, the DT state does not reflect that there was a WGLC!

=C2=A0 =C2=A0 > However, we got little in the way of actual reviews, or = other feedback
=C2=A0 =C2=A0 > that the changes from the first WGLC are fine and do add= ress the
=C2=A0 =C2=A0 > comments.

okay, I have been through the SID/YANG-CBOR documents many times, and
provided extensive comments since last summer.
I really hate a +1 process.=C2=A0 I wish we could do this some other way.
--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O= ( IPv6 I=C3=B8T consulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
_______________________________________________
core mailing list
core@= ietf.org
https://www.ietf.org/mailman/listinfo/core<= br>
--000000000000d9432005ae8c54e2-- From nobody Wed Sep 9 05:20:58 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EBD3A0901 for ; Wed, 9 Sep 2020 05:20:57 -0700 (PDT) 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 Z3RZAUppOtVj for ; Wed, 9 Sep 2020 05:20:54 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150043.outbound.protection.outlook.com [40.107.15.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44ADD3A093B for ; Wed, 9 Sep 2020 05:20:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OUVJ/HRlGHmP2xKRg60XelksyvaTaM61ZCSmkgLC8m/tAH3MpLoW5smPWgTHTfOxCrIEQ3qO24P2m7U01/vjs6D0HNm4v4hZUJx1JBdndy/IQm4/EbslxPNVLVBaKJwiBajDg40n0Okz8MvyyndUSmOwcLXm9fsVnccq+E+JA3aco+afLmx1XC0bKey3mdFpmf5Jhj+brDDf2wBHRVwZrTgAcOyoKHxDVL0fyNbJMxRmP5kcDOyEwAh5+7Cyb/Anh4t3cxwhr7LkVwZJHm+f+b/kpT/+o/To1c6bmy/1uGSKeCBlETzRM0jpzhi9yV5xaSuGhZkLBtzHTz/xLXiPCQ== 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=W/ZQnUVoqd7JDnTpDhCcVmO/0xr/GERzsruyDKMOc5g=; b=iAbT2Q1rjy/rNcsum1CTCuFcvG9HPp/RU2fImsbtgRT7vyyNKJLpJLFMfZ4Yik3OzWdrSJgSQq0ZDaCM5yDxCyRl16YYP/srogyTSNJhM4hkHkNAQ1UwgXi5j5MC8mch7uCnB1rWpk+eQfsXqCrQW5igRbkGTV5U2v1W5ohuxm3eineu1DbpCiJ6TGlMkjDxOHbLr9o//ZkAHQqDhi3AnWWhy08DiOopQnZ3oT/sA+SlLbF/YbBkqhWte/aDKP3Lxcd+UCJpExAVvTZ5CcDnQueqklTLW3wUxazxb3H6yoD6VGe4G7Xq8wwWm6IL261rUPeE8OTv8xtGcMjh2VTbTw== 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=W/ZQnUVoqd7JDnTpDhCcVmO/0xr/GERzsruyDKMOc5g=; b=dhnV4P4YMNfy/9pBeLJ7asAZE3o/ZOZdDsq38mgbw71QA/dbD4pKF7Z9RO15OAT47rQ1GEzNOjkYWDh2hs/zAlzgN1poSi7Oes0SJmS5SrQesbVBImfwFMWiG43L0Z4CcVZ1gVWeinDRNwIqGAPyy6irNm/LoM1iLZCLpBiXo9k= 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 DB8P189MB0917.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:14b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Wed, 9 Sep 2020 12:20:51 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157%8]) with mapi id 15.20.3370.016; Wed, 9 Sep 2020 12:20:51 +0000 To: "core@ietf.org WG (core@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: <524255d7-2e18-4534-5dad-d242bb526202@ri.se> Date: Wed, 9 Sep 2020 14:20:43 +0200 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="4bDq55hBusY3m5xzvh7Xic11TVW1gx4yN" X-ClientProxiedBy: HE1PR09CA0044.eurprd09.prod.outlook.com (2603:10a6:7:3c::12) 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] (86.106.103.236) by HE1PR09CA0044.eurprd09.prod.outlook.com (2603:10a6:7:3c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16 via Frontend Transport; Wed, 9 Sep 2020 12:20:50 +0000 X-Originating-IP: [86.106.103.236] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 14ab1119-aa6b-4dfe-e0ef-08d854baca7c X-MS-TrafficTypeDiagnostic: DB8P189MB0917: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rPBoGe3GsT0xcy76erVrr7jF59k6EmnHe66Gw/h7znFUMuxXJ4T6GzM/hNGuRZQuCCsuhwydlhrmXXr8qZuDnC20BxfpiCc4azKxDlrhO2hSF3+TPcpZ9XKPfWXwztgEweFwkXeNN5bRc0G6IOuyimIp3K5aqCtjmZ4k3U8OiBCUQdc12RxyvXPyPF2AnzUeYohN5tmDCz+/GnF7ltx5xiTjwr6M8bIj7X4vSvkO+Yx1FZItxgTxNnjgHvqw0bAQ4eYV+eQZARNmDlOi8LwlJ4Z/+X4A/z4+j4UP1QaeqMy9GKZqmXVwOGdyX/B//9SAKkwYtqftno4CERlU0NHrLZAgvIALdzty6J8g97NydmE11cHdxQ8qJg5Ylcu80qUKwcz520f1H7bn+xdPWBH8YBxo8gL68kZWtQc31riWzFt1Vq9DY0SAfDyaOCvA7xJOYvmJKZ+91DDa7kHCfv4YZw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(376002)(39860400002)(346002)(396003)(44832011)(31686004)(6486002)(26005)(16526019)(8676002)(186003)(16799955002)(66574015)(478600001)(52116002)(86362001)(83380400001)(33964004)(66946007)(66556008)(66476007)(36756003)(956004)(2616005)(2906002)(6916009)(5660300002)(16576012)(21480400003)(6666004)(8936002)(316002)(31696002)(235185007)(966005)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: lJfB1PtAHs46HVhupAvZPuMUf2Q7HqNIJqQ7FJr7LlZR/k6zIYiPsdkIdvrAzZsbP6Drv9M8T0OQwSNHGMbHHwjdPsdyfInOnQMZJVUmlGBrvw/2YZg8tKeZW/4FeUeg7nmHnals6ELl3/P7HdIU03vK5o9PrCxGw6sWIcvwh2fy86DU+jZjR300akVc9YN9PQJnUR717Mjxej5ecrosOW/z9paLWa/v8teqeOicdnzPb+g8tOgGEorMWIbjjeCcAxmDz+XlOexUkdJLxtazJzaPs2rCNfIL5Y1bMg5rWt36jUjXBNpRaoOZMHhQ3uplO+zR955i5h/SxzEh3xPUvejeCMNpx+JRJwFIJH6AdUQMOgbgSC/zWZr5X7INh4I2VLr49zKvooX2hRzDRJLF/xVgFApba8m6XM5VQxTacHqdCG0H0kZCq6tecZUCS72I67GsK2b2M7Pfmh7z9eOQ1GnasG6mNsy4Kk5xHvjyd7S+rvM1aK1MS1MAGjYjCbZ3Nbt/Yi6tGfonghIziVBf/bsz1RLlAPhkYscPfXW0o8tyLLywkFOTshYFinN1zbZVrJz/dofbL2v88OiFAFSmiiigO9bznozDeRCnPly7erm0WaIicdEkWBcU8fiAUnmdzE8GyW3+/6ljpB2Av9WBGA== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 14ab1119-aa6b-4dfe-e0ef-08d854baca7c X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2020 12:20:51.3813 (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: cZrNi5MazO6C0PxCSe6vVeXGKf5okPIPlBo3oD9PgtSeOW/wbJOfIpyr5es7scSdg+3CvFyKX1DcfbURdud7Lw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0917 Archived-At: Subject: [core] CoRE WG Virtual Interim 2020-09-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 12:20:57 -0000 --4bDq55hBusY3m5xzvh7Xic11TVW1gx4yN Content-Type: multipart/mixed; boundary="rYvqqoOjfsj03j5CqV4EmZIIdYoJOy9OW" --rYvqqoOjfsj03j5CqV4EmZIIdYoJOy9OW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that tomorrow (Thursday) at 14:00 UTC we'll have a virtual interim via Webex. The agenda is to discuss the recently received comments for the Resource Directory document, and their ongoing processing. Please, find below the information to join the meeting. Best, Marco and Jaime =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2020-core-08-core Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dmb93d5310059df95f1f25734c1b973f5= d Meeting number: 171 360 2755 Password: constrained More ways to join Join by video system Dial 1713602755@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in number (US/Canada) Access code: 171 360 2755 --=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 --rYvqqoOjfsj03j5CqV4EmZIIdYoJOy9OW-- --4bDq55hBusY3m5xzvh7Xic11TVW1gx4yN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl9YyKEACgkQ7iZktA5Y 2kNd6gf+LlOyLNujevDd1TjxeEvPO/rVlj3rfNGlRNxJvA2vyFDMRGi2zW1hvuyC zIvh0xHiEX5b5BQfLtKjb4ttQd628acIT1AIymGzxWjhyP6D1ygahcBo2bNll7wY bNfc0m1iy7DRCIhtN4l0Ozw1RGsJFF/u1/LK0G74q9PjHKC5U7yVl9O7MuLJU0r9 o5cZoIILMr/Q3fPkyZV92YhcJl4ydQ5OQGYclYC/3u6yzb5q/cByBVliY1M4sgR/ D6D+jGnXU80f8IxQN2pQcUnV6HVbZ1K47UBdeb0Gde+FB/v61yVSmBC6TInt8F9v AJvwt51XULjAvzeuRBJKu1wZAnVVXg== =IvV2 -----END PGP SIGNATURE----- --4bDq55hBusY3m5xzvh7Xic11TVW1gx4yN-- From nobody Wed Sep 9 23:59:28 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7103A0FDA for ; Wed, 9 Sep 2020 23:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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.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 v2DPTiZLhPy4 for ; Wed, 9 Sep 2020 23:59:24 -0700 (PDT) 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 2AB1C3A0FB5 for ; Wed, 9 Sep 2020 23:59:24 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4Bn8rV2tv5z10Y0; Thu, 10 Sep 2020 08:59:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1599721162; bh=CM+/9qi0grJ1bmPbUHNRTUZLtgeDmWgbxhCyQgL7DSs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UGNAw31sQsn9aQKoaQwXS9U+v2PW7tckX9mnEH0AWGdjNWkJohym6A0leB9n5RQjO ym5dnbOvzh3i56mZahbMyUsPoOEwRiFRh5f3uvfo63mox2Nahul8hgg8s8fcbm3GRN FdB0bmW+Zi1AkCHCKY8G+2inaYZ5nR2bU/CBeVIzblk1Lg4+ZjyNoVqY8WWiiKwiCO bSTrRC6uej91ctNsB+v7+fo312aczQWeDABPkqpURBwYVyXQtmrXr3tgxRu98/cdYr 3Gh/cqK1U140Qwkth3JRtU/3GBaTn37J6VKA/yAzAfenuI4R4rDxw1v9qJ9o6AdM7/ W8YnPihmxY3VQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4Bn8rV1sGqz8sYk; Thu, 10 Sep 2020 08:59:22 +0200 (CEST) From: To: "supjps-ietf@jpshallow.com" , "christian@amsuess.com" , "core@ietf.org" Thread-Topic: core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt Thread-Index: AQHWazQlvA4HUPH8rE2dC1hQ5X7Dmakpzm6AgDfVT5A= Date: Thu, 10 Sep 2020 06:59:21 +0000 Message-ID: <13262_1599721162_5F59CECA_13262_371_5_787AE7BB302AE849A7480A190F8B93303153E110@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <26993_1595950051_5F2043D8_26993_392_1_787AE7BB302AE849A7480A190F8B93303150608A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29030_1593429656_5EF9CE98_29030_149_1_787AE7BB302AE849A7480A190F8B9330314E8C6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200805142431.GB3480705@hephaistos.amsuess.com> <390001d66b63$2f8a3790$8e9ea6b0$@jpshallow.com> In-Reply-To: <390001d66b63$2f8a3790$8e9ea6b0$@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: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 06:59:27 -0000 Hi Christian, all,=20 We finally managed to prepare a candidate -01 of the draft that hopefully a= ddresses your review. The main changes are: * Update the Applicability Scope=20 * Remove the TBA3 (Missing Payloads), but use 4.08 instead * The options are marked as unsafe. The caching behaviour is updated * Move the CC text to a (new) dedicated section * Avoid the normative language for the usage of Tokens. A new (short) secti= on is added for the token discussion. * Rename the options to Quick-Block1/2 We made other edits to enhance the readability of the document.=20 The candidate version is available at: https://core-wg.github.io/new-block/= draft-ietf-core-new-block.txt=20 A diff to track the changes can be seen here: https://tools.ietf.org/rfcdif= f?url1=3Dhttps://tools.ietf.org/id/draft-ietf-core-new-block.txt&url2=3Dhtt= ps://core-wg.github.io/new-block/draft-ietf-core-new-block.txt=20 Please check the candidate version.=20 Thank you.=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: supjps-ietf@jpshallow.com [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 5 ao=FBt 2020 22:01 > =C0=A0: christian@amsuess.com; BOUCADAIR Mohamed TGI/OLN > ; core@ietf.org > Objet=A0: RE: core-block-04: Applicability and general remarks draft- > bosh-core-new-block-04.txt >=20 > Hi Christian, >=20 > Thanks for this review. Med and I will update the draft as > appropriate. >=20 > Otherwise, comments inline >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: christian@amsuess.com [mailto:christian@amsuess.com] > > Sent: 05 August 2020 15:25 > > To: mohamed.boucadair@orange.com; Jon Shallow (supjps- > > ietf@jpshallow.com); core@ietf.org > > Subject: core-block-04: Applicability and general remarks > > draft-bosh-core- new-block-04.txt > > > > Hello Med, hello Jon, > > > > here's a few concrete points I'd like to suggest for new-block: > > > > * Applicability: I'd have expected to read something like this in > the > > introduction: > > > > > The block-wise transfer of [RFC7959] covers the general case, > but > > > falls short in situations where packet loss is highly > asymmetrical. > > > > > > The new options introduced here provide roughly similar > features to > > > the Block1/Block2 options. They provide additional properties > that > > > are tailored towards the intended use case, and leave out > mechanisms > > > like non-atomic access and proxy support that would complicate > their > > > description. > > > > > > They are not intended for general CoAP usage, and any use > outside > > > the DOTS use case should be carefully weighed against the loss > of > > > interoperability with generic CoAP applications. It is hoped > that > > > experience gained with these options can go into future > extensions > > > of the block-wise mechanism that are both generally applicable > and > > > serve this particular use case. >=20 > Jon> Thanks for the suggestions > > > > * Separation of layers, sub-topic "congestion control": It should > be > > possible to phrase all congestion control parts of this in a > dedicated > > section (which may also make sense as an appendix). >=20 > Jon> Good idea >=20 > > > > I'd avoid all other mentions of things like PROBING_RATE: For > example, > > Section 3.4 right in the middle of a paragraph on re-requesting > > missing blocks states that > > > > > The rate of requests for missing blocks is subject to > PROBING_RATE. > > > > Yes it is, but so is every single CoAP request until the client > hears > > back from the server. Repeating these things in places where are > not a > > new requirement may make it easier for some implementers that > try to > > build the whole stack in a single go, but even for them is prone > to > > the authors missing a spot -- and for everyone else this will > each > > time trigger the question of "is this new here or isn't this > already > > handled by a component two layers down the stack?". >=20 > Jon> OK > > > > I haven't tracked every single retransmission and rate limiting > > statement throughout the document, but I expect that this > section > > could boil down to something like > > > > > For the DOTS use case, the following default CoAP parameters > are > > > updated to better reflect the typical deployments: > > > > > > * PROBING_RATE: 10 kilobyte/second > > > > > > The averaging process mentioned in RFC7252 Section 4.7 after > which > > > PROBING_RATE applies is not fully defined there. For the above > > > applications, a new parameter PROBING_RATE_WINDOW is > introduced. > > > Messages up to a total size of PROBING_RATE_WINDOW may be sent > > > before PROBING_RATE is considered, and the probing rate may > > > generally be exceeded by that amount of data in short term. > > > > > > * PROBING_RATE_WINDOW: 15 kilobyte > > > > (The latter replaces MAX_PAYLOADS, and I'm not sure whether it > is > > better to express this in terms of package count or bytes on the > wire, > > just giving an example here. All numbers in the above were > pulled out > > of uninformed air.) >=20 > Jon> My leaning is towards packet count - circuit speeds cover a > Jon> significant > range. I need to think this through. > Jon> The default RFC7252 PROBING_RATE is too low in my humble > estimation > Jon> - a > large packet can cause long inter-packet gaps (300 bytes is a 5 > minute > delay) > > > > * Separation of layers, sub-topic "Tokens": Same thing, next > layer. > > > > Whenever you're tempted to talk of a token, consider some of > these > > replacement phrases as a first step: > > > > * "MUST be sent with a new token" -> "is a new request". > > * "Tokens MUST be included" -> (nothing -- transports use tokens > by > > construction) > > * "MUST be sent with the same token as the response" -> "is sent > as a > > response to" / "is sent as an additional response to that > request". > > (Here it may make sense to refer to the tokens in an > additional " > > (which means it uses the same token, the same way an > observation > > response uses the requests's token for multiple responses)"). >=20 > Jon> Agreed - Token references needs to be tidied up. Will work on > this. > "additional" may help us here to clarify which token 'value' should > be used where. > > > > * Naming: It's technically a minor thing, but people have already > > complained to me about how hard the Block[12] names are to > > comprehend, > > and introducing these options as Block[34] would not help here. > > > > I'd like to suggest QuickBlock-Block[12]. >=20 > Jon> Certainly Block[34] are likely to transfer data more quickly > than > Block[12]. However xxxx [12] implies a replacement for Block[12] > which I am not so sure about. >=20 > > > > (I know that this part of designing a new option is annoying. In > the > > interest of winding up with something that can be learned > easily, it > > is unfortunately essential). > > > > In connection with that, it may make sense to briefly think > about a > > draft name before it is submitted as a WG draft. new-block > sounds like > > a 7959bis, which in my understanding this does not aim to be. >=20 > Jon> Good idea. > > > > * 4.TBA3 Missing Payloads: I don't quite see why this needs a > distinct > > code. 4.08 Request Entity Incomplete sounds perfectly suitable > to me. >=20 > Jon> As we have to define the diagnostic payload as containing the > Jon> missing > blocks, we did not want to change the semantics of how 4.08 is used > - hence TBA3. >=20 > Jon> That said, a 4.08 response could contain 1 or more Block3 > options > Jon> but > that would take up more space. > > > > If you think that sending an existing 4.xx code in the middle of > a > > block-wise transfer would cancel the transfer, there's still two > ways > > out of this: >=20 > Jon> I was concerned about the 4.08 diagnostic payload changing > format, > Jon> but > yes, an 'unexpected' error code could terminate the transfer. > > > > * You're just defining what a block-wise transfer is; just allow > it. > > > > (In a RFC7959 block-wise transfer that runs over a proxy, the > proxy > > may be currently incapable of doing any forwarding and return > 5.03 > > Service Unavailable Max-Age:5. The client would then just > pause 5 > > seconds and send the latest block again.) > > > > * For all but the last block, it may also be an option to send > it as a > > payload to a 2.31 code -- I don't think that would be outright > > forbidden (and at any rate, all involved clients speak the > protocol > > anyway). >=20 > Jon> I have an issue with changing the 2.31 reporting on the last > Jon> successful > block received - this currently fails if block num of 0 is missing > as we cannot indicate block num =3D -1 has been received. > Jon> If the last block is received, but a previous one was not, a > 2.31 > Jon> could > be used to re-request the missing block, but a 2.01/2.04 would need > to be held back for the final block acknowledgement. > > > > * The draft describes this all as "just working through a proxy" - > - > > original block-wise does not, and I'd like to hear how this is > hoping > > to get away without the options being proxy-unsafe. >=20 > Jon> I was not aware of CoAP to CoAP proxy issues with BLOCK[12] > when > Jon> this > was written, but your comment implies that there is. Certainly CoAP > to other protocol proxies could run into issues. >=20 > Jon> I was thinking of block by block proxying working and hence > could > Jon> be > proxy unsafe. > > > > Is there any point at all in using block-by-block proxying for > these > > use cases? Unless a proxy is sitting right inside the link under > > attack, and unless the bodies get huge, it may be way easier for > this > > to be purely hop-by-hop. Proxies would reassemble the full > bodies and, > > for the next hop, just decide what works best there (be it > regular > > block-wise, Block34 or BERT). >=20 > Jon> Yes, there could be full body re-assembly and the full body > held in > cache if needed. This would add in a bit of latency. However this > would restrict a Block[34] possibility of supporting streaming of > data should that be required. > > > > (If there's a point in allowing block-by-block forwarding, we > can talk > > it through and work through the initial ideas that will come up > like > > "We use large enough Request-Tag values so they are unique", > "how > > large does that need to be", "why do we end up having a Request- > Tag in > > every request now" and "why do we not want that", but my gut > feeling > > is we won't need to go there.) >=20 > Jon> For Block3 which would use Request-Tag, I would expect that for > a > specific body of data for a specific resource the Request-Tag to > remain the same - and if the body changes a new Request-Tag is used. > Jon> As this is the same Request-Tag for whether the whole body is > Jon> cached, > or individual blocks of the body the Request-Tag usage will not > change. > 2^32 should be large enough - 2^64 even better - but re-usage has to > be generally considered. >=20 > ~Jon > > > > Kind regards > > Christian > > > > -- > > 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 Sep 10 02:46:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EB43A1197; Thu, 10 Sep 2020 02:46:56 -0700 (PDT) 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 c8hx1tq9xxBJ; Thu, 10 Sep 2020 02:46:53 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60068.outbound.protection.outlook.com [40.107.6.68]) (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 42BBB3A119A; Thu, 10 Sep 2020 02:46:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G7JUi5Z6SDNIDdc1Nvhk89RdlEV7wYsg/YF8tH620Pnovyr+JLdXs/OJgMtKEzEf5vH5vWlKt1LD4J6c2pm7zhxqmKbmzWRB9yNWpe0RcV7hUJ1iZrZBoF1emWqKzBM6mpcGYfdMHJi9yQ+cbDbfuLxB8CxEfMqdyfVNaUP3UKcG3KS5Z6MD0h/O16k31uoVC9WV4ya5erHnDQAcGspgGBjHqNVRo1qrLF1CsdTneyahQw6aDAuRFfZu052NF8s2NyLYy0s3CESlArryUzX85p517mP81tj953sOye0af+SNVZB1PkVBNP1M9t9mN+uaBaLkRFYTICo8tUVs6vRngQ== 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=66m1LyXHxU3UIXDc6re55pZCLlbr8ljFuLvUcXjxiYU=; b=aiu91y6kh3lXhtt6rO2esBlrx0aVnRJ+ScabS1gCggicJnI0H4gXGfXp0AFbsE7KRtZCbsEScjXlIwz3mbqZ8DL/cmWqe/gOorn8lfiSCDdEtjpqh6zdbIuyiBR1JduFpxPZT13/Za/vg+Ne0HlaIE5icz6atsI97Rj1FibRfw2/pHsOWtQhwnhQ4iowtLfVhCIvcSuPvSG9OQbZ+cOna+xoC3EwwemSVil+5Xu40EoqBmnED+UPUhsLVIYMFI9R4TBjIVnsv1QK24MuzByeHuvaGEOYeXJB/AUdTioh7+pYRse4gbaG6EJhvhIPr4Va3vN7dRDgS+z23Dz8Xt9emQ== 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=66m1LyXHxU3UIXDc6re55pZCLlbr8ljFuLvUcXjxiYU=; b=elO9WGoMEiD3+TrbnD5oEjoaLilWLSj28WLeqVmxJ1xDmU3rAgUeX8DX8oV0IyFUqY/Fyhm/VY2fL8cmD1qOpyKfkAu5vaiRadrbO9wjZ/OpFdNTCZReHmNU5UsUsuEj8PNS7dBbhoyFKT3yrq2YMGfzO00A5hk8WHQ7ujxqfqo= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR07MB4347.eurprd07.prod.outlook.com (2603:10a6:7:a3::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.15; Thu, 10 Sep 2020 09:46:39 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3370.016; Thu, 10 Sep 2020 09:46:39 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Barry Leiba CC: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Thread-Topic: [core] AD review of draft-ietf-core-echo-request-tag-10 Thread-Index: AQHWag2783ig3eTTLEWqbjvVPkqoAKlYiEkAgAlzsoA= Date: Thu, 10 Sep 2020 09:46:39 +0000 Message-ID: <791F308F-A64E-400B-BAC0-B5E45C633048@ericsson.com> References: <20200904112614.GA3682231@hephaistos.amsuess.com> In-Reply-To: <20200904112614.GA3682231@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8855cc6-678b-4d50-956a-08d8556e6a91 x-ms-traffictypediagnostic: HE1PR07MB4347: 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: AxgNh+Pzx5c0u73Bfx4flBwDCbpFYErYUNz+cxlJYZ7rdDUXDbunT7LNgk1KU8n/BBHlnzYSYkLRpJDGDQtyQOQgWLgyhF4XSV6LPrp3NjTIKJQHQOIV21iYEM+cvqycj4cKNclv5RSrXav761Zy7HklIKTGedYuiId4V0vBRivbsPbivqddHIujrKaipId4Wwba3WLJqMTd3Abxp6pMkGl9e+nrNfBjNrnRT5bwrKWwyIuCb1uGsfd5g7dw19K0TgPvVrjsMlzW53H0nvElxXhhT6OwL/JDAZQ2iLCEjW67pReU9uCWWO8zDXzTBeKuCEheP3xaK+BneMax+m8Qtngam9IFr4VjJG7khADzqfHpm5LzEDOZrgLMrToOfeHzoSEAKUNK5BB8mjztkDIDZtCoMxlQJmgPTV1uMfKOBkJGeErfymyhC1rZ5Oft2GhBcjnqsKUNq4+ua7H5cg/CdA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(478600001)(54906003)(186003)(66556008)(85202003)(26005)(110136005)(33656002)(6486002)(6506007)(30864003)(76116006)(966005)(66946007)(8936002)(8676002)(4326008)(6512007)(66476007)(5660300002)(71200400001)(316002)(36756003)(66574015)(83380400001)(86362001)(2616005)(64756008)(85182001)(2906002)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Yp9mdO0zu7rPAyyoiFpgKHR2gQD8lN1iJ1mrXv1HYP46Cmc7ujdbHlxGcOCWsma11S66vOTFrTTJmGYIusMX1mtX5CsE29Vj+FgUO3HIliK6AeUXrtzX7+hyBMCgp295IggUgUXCwbqHcvXD/wtjDxDRbg1OdK191mhAdADF1975n1Ph7tnaHAHh4yRgbytHqCyq1/9NY0qWtIu5VSg4S5PtiTP6vbbki0Y66ryPl55hqwZx1GeykQGAs55i4B1Gz5QfUjtlLvtvMWadxCGZi9gOD4Ia672p3jUtB/UwpW+ClSwKcLIX+Yen0f6qrkodbhHt38jMwV9nLtou5UsLrGxPx0hzk4tE7LZ0EWFiOIto1R7duMtIf/FJSv5MEdrvHZvVZaTquS0D4Ig2TtynuDyBDiExk9X3mD3I2snkMvgGKFOzuOwCor9boxDsNicRRtdZG0oYJj+3CcHmCE6O3dL8iRBPhCnIcOI4TDZKk8b0vdhds0CmhqSMOfS2yq4taOMN+keS/T8aWcZHmQvJK4Eoc5AVObefzvHwpPR6/DZLeSgw+UDvdJkjwNr9fyqzWKBLMXGQ912gEGxkCeqbS6N+gygjkEYB6XUqKwe3JDfjcAtGt0dRrqVsrxm0/nRBRIqDKB61e2vVLsGoCoEqtA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0EA4C6B50B474F4C9088EAF16861812E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8855cc6-678b-4d50-956a-08d8556e6a91 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2020 09:46:39.4954 (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: FoDyIcJyZ+HsY24HOBzFd9u7DOUARR5EAVkwCA1E3724CyOUHSxhva0VYUXOnU2Bg/W5YxRze53hm5HVLWnvhch5+VkoGHi7c4IcG22owbI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4347 Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 09:46:56 -0000 SGkgQmFycnksDQoNCkhlcmUgYXJlIHJlc3BvbnNlcyB0byB0aGUgdHdvIGNvbW1lbnRzIG9mIHlv dXIgcmV2aWV3IHdoaWNoIENocmlzdGlhbiByZWRpcmVjdGVkLg0KDQogICAgRGVmZXJyZWQgdG8g dGhlIG90aGVyIGF1dGhvcnMNCiAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQog ICAgPiAgICBVbmxlc3MgYSBjb3VudGluZyBFY2hvIHZhbHVlIGlzIHVzZWQsIHRoZSBFY2hvDQog ICAgPiAgICBvcHRpb24gdmFsdWUgTVVTVCBjb250YWluIDMyIChwc2V1ZG8tKXJhbmRvbSBiaXRz IHRoYXQgYXJlIG5vdA0KICAgID4gICAgcHJlZGljdGFibGUgZm9yIGFueSBvdGhlciBwYXJ0eSB0 aGFuIHRoZSBzZXJ2ZXIsIGFuZCBTSE9VTEQgY29udGFpbg0KICAgID4gICAgNjQgKHBzZXVkby0p cmFuZG9tIGJpdHMuDQogICAgPiANCiAgICA+IFdoYXTigJlzIHRoZSByZWFzb24gZm9yIG5vdCBq dXN0IHVzaW5nIE1VU1QgZm9yIDY0IGJpdHMgYW5kIGJlaW5nIGRvbmUgd2l0aA0KICAgID4gaXQ/ DQoNCiAgICBJJ2Qgc3VwcG9zZSB0aGF0IGl0J3MgdG8gYWxsb3cgZm9yIGFwcGxpY2F0aW9ucyB3 aXRoIHdlbGwgY29udHJvbGxlZA0KICAgIHBvd2VyIGN5Y2xlcyBhbmQgRWNobyB2YWx1ZSBjaGFu Z2VzIHRvIHJlZHVjZSB0aGVpciBtZXNzYWdlIHNpemVzIC0tDQogICAgR8O2cmFuLCBjb3VsZCB5 b3Ugc2F5IGEgYml0IG1vcmUgaGVyZT8NCg0KW0dTXSBUaGUgcmVjb21tZW5kYXRpb24gb2YgNjQg Yml0cyBpcyBtb3RpdmF0ZWQgYnkgdGhlIGNvbXBhcmlzb24gd2l0aCA2NCBiaXRzIE1BQyBpbiB0 aGUgYmVnaW5uaW5nIG9mIHRoaXMgcGFyYWdyYXBoLCBidXQgdGhlIHJlcXVpcmVtZW50cyBvZiAz MiBiaXRzIGRlcGVuZHMgb24gYXBwbGljYXRpb24gc28gd2UgcmVwbGFjZWQgdGhhdCB3aXRoIGFu IGFwcGxpY2F0aW9uLWRlcGVuZGVudCByZXF1aXJlbWVudCB0byBtaXRpZ2F0ZSBhZ2FpbnN0IHJl dXNlLCBzZWU6DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9lY2hvLXJlcXVlc3QtdGFnL3B1 bGwvNjEvY29tbWl0cy9kOGJhMGY1DQoNCg0KICAgID4gICAgU2VydmVycyBNQVkgdXNlIHRoZSB0 aW1lIHNpbmNlIHJlYm9vdCBtZWFzdXJlZCBpbiBzb21lIHVuaXQgb2YgdGltZS4NCiAgICA+IA0K ICAgID4gRm9yIHdoYXQ/ICBJdOKAmXMgbm90IGNsZWFyIHRvIG1lIHdoYXQgdGhpcyByZWZlcnMg dG8uDQoNCiAgICBKb2huLCBHw7ZyYW4sIGNvdWxkIHRoaXMgYmUgYSBsZWZ0b3ZlciBmcm9tIHRo ZSBsYXRlciBjaGFuZ2VzIGFyb3VuZA0KICAgIHNlcnZlciAvIHdhbGwgdGltZT8NCg0KDQpbR1Nd IFRoaXMgdGV4dCBpcyBpbnRlbmRlZCB0byBiZSByZWFkIGluIGNvbnRleHQgb2Ygb3RoZXIgdGV4 dCBwcmV2aW91c2x5IGluIHRoaXMgc2VjdGlvbi4gSSB0cmllZCB0byByZXBocmFzZSB0byBtYWtl IGl0IG1vcmUgY2xlYXIsIHNlZToNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2VjaG8tcmVx dWVzdC10YWcvcHVsbC82MS9jb21taXRzLzRkM2NhOTMNCg0KDQpCb3RoIHRoZXNlIGNvbW1pdHMg YXJlIHBhcnQgb2YgUFIjNjEgd2hpY2ggbWFrZXMgYWRkaXRpb25hbCBjbGFyaWZpY2F0aW9ucyBv biBFY2hvLCB0aGUgY3VycmVudCBjaGFuZ2VzIGFyZSBoZXJlOg0KaHR0cHM6Ly9naXRodWIuY29t L2NvcmUtd2cvZWNoby1yZXF1ZXN0LXRhZy9wdWxsLzYxL2ZpbGVzDQoNCg0KUGxlYXNlIGxldCB1 cyBrbm93IGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLg0KDQpUaGFua3MsDQpHw7Zy YW4NCg0KDQrvu79PbiAyMDIwLTA5LTA0LCAxMzoyNiwgIkNocmlzdGlhbiBBbXPDvHNzIiA8Y2hy aXN0aWFuQGFtc3Vlc3MuY29tPiB3cm90ZToNCg0KICAgIEhlbGxvIEJhcnJ5LA0KDQogICAgdGhh bmtzIGZvciBhbGwgeW91ciBjb21tZW50cy4NCg0KICAgIFNvbWUgcG9pbnRzIHdlbnQgdW5oYW5k bGVkIGR1ZSB0byBhIHZlcnkgY3VyaW91cyBnbGl0Y2ggdGhhdCBoYWQgeW91cg0KICAgIG1haWwg dHJ1bmNhdGVkIG1pZC1ib2R5IHdoZW4gaXQgd2VudCB0aHJvdWdoIHRoZSBkcmFmdCBtYWlsIGZv cndhcmRlciBidXQgbm90DQogICAgd2hlbiBpdCB3ZW50IHRocm91Z2ggdGhlIGxpc3Q7IGhlcmUn cyBhZGRyZXNzaW5nIHRoZSB0YWlsLCBncm91cGVkIGJ5DQogICAgImRvbmUiLCAiZXhwbGFpbmVk IiBhbmQgImJldHRlciBhbnN3ZXJlZCBieSBHw7ZyYW4gb3IgSm9obiI6DQoNCiAgICBEb25lDQog ICAgPT09PT0NCg0KICAgID4gTml0OiBbdmFyaW91c10NCg0KICAgIFRoYW5rcywgZml4ZWQuDQoN CiAgICA+ICAgIFRoZSBSZXF1ZXN0LVRhZyBvcHRpb24gaXMgcmVwZWF0YWJsZSBiZWNhdXNlIHRo aXMgZWFzaWx5IGFsbG93cw0KICAgID4gICAgc3RhdGVsZXNzIHByb3hpZXMgdG8gImNoYWluIiB0 aGVpciBvcmlnaW4gYWRkcmVzcy4gIFRoZXkgY2FuIHBlcmZvcm0NCiAgICA+ICAgIHRoZSBzdGVw cyBvZiBTZWN0aW9uIDMuNS4zIHdpdGhvdXQgdGhlIG5lZWQgdG8gY3JlYXRlIGFuIG9wdGlvbiB2 YWx1ZQ0KICAgID4gICAgdGhhdCBpcyB0aGUgY29uY2F0ZW5hdGlvbiBvZiB0aGUgcmVjZWl2ZWQg b3B0aW9uIGFuZCB0aGVpciBvd24gdmFsdWUsDQogICAgPiAgICBhbmQgY2FuIHNpbXBseSBhZGQg YSBuZXcgUmVxdWVzdC1UYWcgb3B0aW9uIHVuY29uZGl0aW9uYWxseS4NCiAgICA+IA0KICAgID4g SSBkb27igJl0IGtub3cgd2hhdCDigJjigJxjaGFpbuKAnSB0aGVpciBvcmlnaW4gYWRkcmVzc+KA mSBtZWFucywgYW5kIEkgZG9u4oCZdCBrbm93DQogICAgPiB3aGF0IOKAmHRoZWlyIG93biB2YWx1 ZeKAmSBtZWFucy4gIENhbiB5b3UgY2xhcmlmeSB0aGlzPw0KDQogICAgWWVzIHRoYXQncyBoYXJk IHRvIHBhcnNlIHdpdGhvdXQgdGhlIG1pbmRzZXQgSSB3YXMgaW4gd2hlbiB3cml0aW5nIGl0Ow0K ICAgIHJlcGxhY2VkIHdpdGgNCg0KICAgICAgWy4uLl0gYmVjYXVzZSB0aGlzIGVhc2lseSBhbGxv d3Mgc2V2ZXJhbCBjYXNjYWRlZCBzdGF0ZWxlc3MgcHJveGllcyB0byBlYWNoIHB1dCBpbiBhbg0K ICAgICAgb3JpZ2luIGFkZHJlc3MuDQoNCiAgICA+IOKAlCBTZWN0aW9uIDMuOCDigJQNCiAgICA+ IA0KICAgID4gICAgVGhlIHRocmVhdCBtb2RlbCBoZXJlIGlzIG5vdCBhbg0KICAgID4gICAgYXR0 YWNrZXIgKGJlY2F1c2UgdGhlIHJlc3BvbnNlIGlzIG1hZGUgc3VyZSB0byBiZWxvbmcgdG8gdGhl IGN1cnJlbnQNCiAgICA+ICAgIHJlcXVlc3QgYnkgdGhlIHNlY3VyaXR5IGxheWVyKSwgYnV0IGJs b2NrcyBpbiB0aGUgY2xpZW50J3MgY2FjaGUuDQogICAgPiANCiAgICA+IEkgZG9u4oCZdCB1bmRl cnN0YW5kIOKAnFRoZSB0aHJlYXQgbW9kZWwgaXMgYmxvY2tzIGluIHRoZSBjbGllbnTigJlzIGNh Y2hlLuKAnSAgSQ0KICAgID4gdGhpbmsgdGhpcyBuZWVkcyBzb21lIHJld29yZGluZyB0byBleHBs YWluIGJldHRlciB3aGF0IHlvdSBtZWFuLg0KDQogICAgQ2xhcmlmaWVkIHRvOg0KDQogICAgICBU aGUgdGhyZWF0IG1vZGVsIGhlcmUgZG9lcyBub3QgZGVwZW5kIG9uIGFuIGF0dGFja2VyOiBhIGNs aWVudCBjYW4NCiAgICAgIGNvbnN0cnVjdCBhIHdyb25nIHJlcHJlc2VudGF0aW9uIGJ5IGFzc2Vt YmxpbmcgaXQgZnJvbSBibG9ja3MgZnJvbQ0KICAgICAgZGlmZmVyZW50IHJlc291cmNlIHN0YXRl cy4gIFRoYXQgY2FuIGhhcHBlbiB3aGVuIGEgcmVzb3VyY2UgaXMNCiAgICAgIG1vZGlmaWVkIGR1 cmluZyBhIHRyYW5zZmVyLCBvciB3aGVuIHNvbWUgYmxvY2tzIGFyZSBzdGlsbCB2YWxpZCBpbiB0 aGUNCiAgICAgIGNsaWVudCdzIGNhY2hlLg0KDQogICAgPiDigJQgU2VjdGlvbiA0LjEg4oCUDQog ICAgPiANCiAgICA+ICAgIFRoZSB3cm9uZyByZXNwb25zZSBtYXkgYmUgYW4gb2xkIHJlc3BvbnNl IGZvciB0aGUgc2FtZQ0KICAgID4gICAgcmVzb3VyY2Ugb3IgZm9yIGEgY29tcGxldGVseSBkaWZm ZXJlbnQgcmVzb3VyY2UNCiAgICA+IA0KICAgID4gQXJlIHlvdSByZWZlcnJpbmcgdG8gYW4gb2xk IHJlc3BvbnNlIGZvciBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHJlc291cmNlDQogICAgPiAod2hp Y2ggaXMgd2hhdCB0aGlzIHNheXMgYXMgd3JpdHRlbiksIG9yIHRvIGFueSByZXNwb25zZSBmb3Ig YSBjb21wbGV0ZWx5DQogICAgPiBkaWZmZXJlbnQgcmVzb3VyY2UgKHdoaWNoIGlzIHdoYXQgSSB0 aGluayB5b3UgbWVhbik/ICBJZiB0aGUgbGF0dGVyLCBpdA0KICAgID4gc2hvdWxkIHNheSwg4oCc Li4ub3IgYSByZXNwb25zZSBmb3IgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCByZXNvdXJjZeKAnS4N Cg0KICAgIEl0IGRvZXMgbm93Lg0KDQogICAgPiAgICBBIHN0cmFpZ2h0Zm9yd2FyZCBtaXRpZ2F0 aW9uIGlzIHRvIG1hbmRhdGUgY2xpZW50cyB0byBub3QgcmV1c2UNCiAgICA+ICAgIFRva2VucyB1 bnRpbCB0aGUgdHJhZmZpYyBrZXlzIGhhdmUgYmVlbiByZXBsYWNlZC4gIE9uZSBlYXN5IHdheSB0 bw0KICAgID4gICAgYWNjb21wbGlzaCB0aGlzIGlzIHRvIGltcGxlbWVudCB0aGUgVG9rZW4gYXMg YSBjb3VudGVyIHN0YXJ0aW5nIGF0DQogICAgPiAgICB6ZXJvIGZvciBlYWNoIG5ldyBvciByZWtl eWVkIHNlY3VyZSBjb25uZWN0aW9uLg0KICAgID4gDQogICAgPiBUaGlzIGlzIGVzc2VudGlhbGx5 IHJlcGVhdGVkIGluIHRoZSBuZXh0IHNlY3Rpb24uICBDYW4geW91IGF2b2lkIHRoYXQsDQogICAg PiBwcm9iYWJseSBieSByZXdvcmRpbmcgdGhpcyB0byBzYXkgdGhhdCB0aGUgbmV4dCBzZWN0aW9u IHByaXZpZGVzIGENCiAgICA+IG1pdGlnYXRpb24/DQoNCiAgICBUaGF0IGluZGVlZCBzb3VuZHMg bGlrZSB0aGUgd2F5IHRvIGdvIGZvciB0aGF0IHBhcmFncmFwaCAoYWx0aG91Z2ggd2UNCiAgICBt aWdodCBqdXN0IGRyb3AgaXQgYXMgd2VsbCk7IGNoYW5nZWQgdG86DQoNCiAgICAgIEEgc3RyYWln aHRmb3J3YXJkIG1pdGlnYXRpb24gaXMgdG8gbWFuZGF0ZSBjbGllbnRzIHRvIG5vdCByZXVzZQ0K ICAgICAgVG9rZW5zIHVudGlsIHRoZSB0cmFmZmljIGtleXMgaGF2ZSBiZWVuIHJlcGxhY2VkLiBU aGUgZm9sbG93aW5nDQogICAgICBzZWN0aW9uIGZvcm1hbGl6ZXMgdGhhdC4NCg0KICAgID4g4oCU IFNlY3Rpb24gNC4yIOKAlA0KICAgID4gDQogICAgPiAgICBPbmUgZWFzeSB3YXkgdG8gYWNjb21w bGlzaCB0aGlzIGlzIHRvIGltcGxlbWVudCB0aGUgVG9rZW4gKG9yIHBhcnQgb2YNCiAgICA+ICAg IHRoZSBUb2tlbikgYXMgYSBzZXF1ZW5jZSBudW1iZXIgc3RhcnRpbmcgYXQgemVybyBmb3IgZWFj aCBuZXcgb3INCiAgICA+ICAgIHJla2V5ZWQgc2VjdXJlIGNvbm5lY3Rpb24sIHRoaXMgYXBwcm9h Y2ggU0hPVUxEIGJlIGZvbGxvd2VkLg0KICAgID4gDQogICAgPiBUaGlzIGlzIG5vdCBhIHByb3Bl ciBzZW50ZW5jZTogSSB0aGluayBpdOKAmXMgdHdvIHNlbnRlbmNlcyBzcGxpY2QgdG9nZXRoZXIs DQogICAgPiBidXQgaXQgbWlnaHQgYmUgdGhhdCBpdCBuZWVkcyByZXdvcmRpbmcgaW5zdGVhZC4N Cg0KICAgIEkgdGhpbmsgaXQgd29ya3Mgbm93IHRoYXQgdGhlIGNvbW1hIGlzIHJlcGxhY2VkIHdp dGggYSBmdWxsIHN0b3AsIGFuZA0KICAgIHRoZSBmb3JtZXIgc2VudGVuY2UgaXMgcHV0IG9uIGEg cGFyYWdyYXBoIG9mIGl0cyBvd24gdG8gY2xlYXJseSBzZXBhcmF0ZQ0KICAgIHdoYXQgaXMgbWFu ZGF0ZWQgYW5kIHdoYXQgaXMgcmVjb21tZW5kZWQuDQoNCiAgICA+IOKAlCBTZWN0aW9uIDUg4oCU DQogICAgPiANCiAgICA+ICAgIEFzIGVhY2ggcHNldWRvcmFub20gbnVtYmVyIG11c3Qgb25seSBi ZSB1c2VkIG9uY2UsDQogICAgPiAgICBhbiBpbXBsZW1lbnRhdGlvbiBuZWVkIHRvIGdldCBhIG5l dyB0cnVseSByYW5kb20gc2VlZCBhZnRlciByZWJvb3QsDQogICAgPiAgICBvciBjb250aW5vdXNs eSBzdG9yZSBzdGF0ZSBpbiBub252b2xhdGlsZSBtZW1vcnksIHNlZSAoW1JGQzg2MTNdLA0KICAg ID4gICAgQXBwZW5kaXggQi4xLjEpIGZvciBpc3N1ZXMgYW5kIHNvbHV0aW9uIGFwcHJvYWNoZXMg Zm9yIHdyaXRpbmcgdG8NCiAgICA+ICAgIG5vbnZvbGF0aWxlIG1lbW9yeS4NCiAgICA+IA0KICAg ID4gQW5kIHRoaXMgYWxzbyBsb29rcyBsaWtlIHR3byBzZW50ZW5jZXMgc3BsaWNlZCB0b2dldGhl ci4NCg0KICAgIFllcywgY2hhbmdlZCB0byB0d28gc2VudGVuY2VzLg0KDQogICAgPiAgICBUaGV5 IE1VU1Qgb25seSBiZQ0KICAgID4gICAgdXNlZCB3aGVuIHRoZSByZXF1ZXN0IEVjaG8gdmFsdWVz IGFyZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLg0KICAgID4gDQogICAgPiBJIHRoaW5rIHRoaXMgaXMg YSB0cmlja3kgd2F5IHRvIHdvcmQgaXQsIGFuZCB0aGF0IGl0IGludml0ZXMNCiAgICA+IG1pc3Vu ZGVyc3RhbmRpbmcuICBJIHN1Z2dlc3QgdGhhdCBpdCBtaWdodCBiZSBiZXR0ZXIgc2FpZCBhcywg 4oCcVGhleSBNVVNUDQogICAgPiBOT1QgYmUgdXNlZCB1bmxlc3MgdGhlIHJlcXVlc3QgRWNobyB2 YWx1ZXMgYXJlIGludGVncml0eSBwcm90ZWN0ZWQu4oCdDQoNCiAgICBBZ3JlZWQgYW5kIHRha2Vu IHZlcmJhdGltLg0KDQogICAgPiDigJQgU2VjdGlvbiA1LjEg4oCUDQogICAgPiANCiAgICA+ICAg IFJldXNpbmcgVG9rZW5zIGluIGEgd2F5IHNvIHRoYXQgcmVzcG9uc2VzIGFyZSBndWFyYW50ZWVk IHRvIG5vdCBiZQ0KICAgID4gICAgYXNzb2NpYXRlZCB3aXRoIHRoZSB3cm9uZyByZXF1ZXN0IGlz IG5vdCB0cml2aWFsIGFzIG9uLXBhdGggYXR0YWNrZXJzDQogICAgPiAgICBtYXkgYmxvY2ssIGRl bGF5LCBhbmQgcmVvcmRlciBtZXNzYWdlcywgcmVxdWVzdHMgbWF5IGJlIHNlbnQgdG8NCiAgICA+ ICAgIHNldmVyYWwgc2VydmVycywgYW5kIHNlcnZlcnMgbWF5IHByb2Nlc3MgcmVxdWVzdHMgaW4g YW55IG9yZGVyIGFuZA0KICAgID4gICAgc2VuZCBtYW55IHJlc3BvbnNlcyB0byB0aGUgc2FtZSBy ZXF1ZXN0Lg0KICAgID4gDQogICAgPiBUaGlzIGlzIGEgY29tcGxpY2F0ZWQgc2VudGVuY2UgYW5k IGl0IGhhcyBhIGxvdCBvZiBjYXNjYWRlZCBuZWdhdGl2ZXMuDQogICAgPiBQbGVhc2UgdHJ5IHJl d29yZGluZyBpdCwgYW5kIGNvbnNpZGVyIHNwbGl0dGluZyBpdCB1cC4gIE9uZSB3YXkgaXMgdG8g c3RhcnQNCiAgICA+IHdpdGgg4oCcT24tcGF0aOKAnSB0byB0aGUgZW5kIG9mIHRoZSBzZW50ZW5j ZSwgYW5kIHRoZW4gaGF2ZSBhbm90aGVyIHNlbnRlbmNlDQogICAgPiB0aGF0IHNheXMsIOKAnFRo YXQgbWFrZXMgaXQgbm9uLXRyaXZpYWwgdG8gcmV1c2UgdG9rZW5zLi4u4oCdDQoNCiAgICBJJ3Zl IHJlbW92ZWQgdGhlICJ0byBzZXZlcmFsIHNlcnZlcnMiIHBhcnQgYXMgaXQgZG9lc24ndCByZWFs bHkNCiAgICBjb250cmlidXRlIChpdCBjYW4sIGJ1dCBub3QgdXNpbmcgc2VjdXJpdHkgcHJvdG9j b2xzIG90aGVyIHRoYW4gT1NDT1JFKSwNCiAgICBhbmQgcmVvcmRlcmVkIGl0IHRvICJpdCdzIGRp ZmZpY3VsdDogdGhpcyBhbHJlYWR5IGhhcHBlbnMgcmVndWxhcmx5LiBhbg0KICAgIGF0dGFja2Vy IG1heSBkbyB0aGF0LiB0aGVyZWZvcmUuLi4iLiBOb3cgcmVhZHMgYXM6DQoNCiAgICAgIFJldXNp bmcgVG9rZW5zIGluIGEgd2F5IHNvIHRoYXQgcmVzcG9uc2VzIGFyZSBndWFyYW50ZWVkIHRvIG5v dCBiZQ0KICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSB3cm9uZyByZXF1ZXN0IGlzIG5vdCB0cml2 aWFsOiBUaGUgc2VydmVyIG1heQ0KICAgICAgcHJvY2VzcyByZXF1ZXN0cyBpbiBhbnkgb3JkZXIs IGFuZCBzZW5kIG11bHRpcGxlIHJlc3BvbnNlcyB0byB0aGUgc2FtZQ0KICAgICAgcmVxdWVzdC4g QW4gYXR0YWNrZXIgbWF5IGJsb2NrLCBkZWxheSwgYW5kIHJlb3JkZXIgbWVzc2FnZXMuIFRoZSB1 c2UNCiAgICAgIG9mIGEgc2VxdWVuY2UgbnVtYmVyIGlzIHRoZXJlZm9yZSByZWNvbW1lbmRlZCB3 aGVuIENvQVAgaXMgdXNlZCB3aXRoIGENCiAgICAgIHNlY3VyaXR5IHByb3RvY29sIHRoYXQgZG9l cyBub3QgcHJvdmlkZSBiaW5kaW5ncyBiZXR3ZWVuIHJlcXVlc3RzIGFuZA0KICAgICAgcmVzcG9u c2VzIHN1Y2ggYXMgRFRMUyBvciBUTFMuDQoNCiAgICA+ICAgIFVuZW5jcnlwdGVkIHRpbWVzdGFt cHMgTUFZDQogICAgPiAgICByZXZlYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNlcnZlcg0KICAg ID4gDQogICAgPiBUaGlzIG5lZWRzIHRvIGJlIOKAnG1heeKAnSAob3Ig4oCcY291bGTigJ0pLCBh cyBpdOKAmXMgYSBzdGF0ZW1lbnQsIG5vdCBhIGRpcmVjdGl2ZS4NCg0KICAgIEFncmVlZCwgY2hh bmdlZCB0byAiY291bGQiLg0KDQogICAgPiAgICBMaWtlIEhUVFAgY29va2llcywgdGhlIEVjaG8g b3B0aW9uIGNvdWxkIHBvdGVudGlhbGx5IGJlIGFidXNlZCBhcyBhDQogICAgPiAgICB0cmFja2lu ZyBtZWNoYW5pc20gdG8gbGluayB0byBkaWZmZXJlbnQgcmVxdWVzdHMgdG8gdGhlIHNhbWUgY2xp ZW50Lg0KICAgID4gDQogICAgPiBJIGNhbuKAmXQgZm9sbG93IHRoaXMgc2VudGVuY2UsIHBhcnRp Y3VsYXJseSB0aGUgcGFydCB3aXRoIHRoZSB3b3JkIOKAnHRv4oCdDQogICAgPiByZXBlYXRlZCB0 aHJlZSB0aW1lcy4gIFBsZWFzZSByZXdvcmQgaXQuDQoNCiAgICBSZXdvcmRlZCB0bzoNCg0KICAg ICAgWy4uLl0gdGhlIEVjaG8gb3B0aW9uIGNvdWxkIHBvdGVudGlhbGx5IGJlIGFidXNlZCBhcyBh IHRyYWNraW5nDQogICAgICBtZWNoYW5pc20gdGhhdCBpZGVudGlmaWVzIGEgY2xpZW50IGFjcm9z cyByZXF1ZXN0cy4NCg0KICAgID4gICAgQ2xpZW50cyBvbmx5IHNlbmQgRWNobyB0byB0aGUgc2Ft ZQ0KICAgID4gICAgc2VydmVyIGZyb20gd2hpY2ggdGhleSB3ZXJlIHJlY2VpdmVkLg0KICAgID4g DQogICAgPiBUaGUgb25seSBwb3NzaWJsZSBhbnRlY2VkZW50IHRvIOKAnHRoZXnigJ0gaGVyZSBp cyDigJxjbGllbnRz4oCdLCB3aGljaCBpcyBjbGVhcmx5DQogICAgPiB3cm9uZzogeW91IG1lYW4g 4oCcRWNob+KAnS4gIFNvIHRoaXMgbmVlZHMgcmV3b3JkaW5nLiAgTWF5YmUgdXNlIOKAnEVjaG8N CiAgICA+IG9wdGlvbnPigJ0sIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuDQoNCiAgICBDaGFuZ2Vk Og0KDQogICAgICBDbGllbnRzIHNlbmQgRWNobyB2YWx1ZXMgdG8gdGhlIHNhbWUgc2VydmVyIGZy b20gd2hpY2ggdGhlIHZhbHVlcyB3ZXJlDQogICAgICByZWNlaXZlZC4NCg0KICAgID4g4oCUIFNl Y3Rpb24gOC4yIOKAlA0KICAgID4gSeKAmW0gaGF2aW5nIGEgaGFyZCB0aW1lIGRlY2lkaW5nIHdo ZXRoZXIgc29tZSBvZiB0aGVzZSByZWZlcmVuY2VzIHNob3VsZCBiZQ0KICAgID4gbm9ybWF0aXZl LCBlc3BlY2lhbGx5IDg2MTMuICBQbGVhc2UgZ2l2ZSB0aGVzZSBhbm90aGVyIHJldmlldyB3aXRo IHRoYXQgaW4NCiAgICA+IG1pbmQgYW5kIHNlZSBpZiB5b3UgdGhpbmsgYW55IG9mIHRoZW0gc2hv dWxkIGJlIG1vdmVkLiAgWW91IGNhbiBmaW5kIHNvbWUNCiAgICA+IGd1aWRhbmNlIGluIHRoZSBy ZWxldmFudCBJRVNHIFN0YXRlbWVudCA8DQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9hYm91 dC9ncm91cHMvaWVzZy9zdGF0ZW1lbnRzL25vcm1hdGl2ZS1pbmZvcm1hdGl2ZS1yZWZlcmVuY2Vz Lz4sDQogICAgPiBrZWVwaW5nIGluIG1pbmQgdGhlIGdlbmVyYWwgcnVsZSB0aGF0IHNvbWV0aGlu ZyB0aGF0IG5lZWRzIHRvIGJlIGZ1bGx5DQogICAgPiB1bmRlcnN0b29kIHNob3VsZCBiZSBub3Jt YXRpdmUsIHdoaWxlIHNvbWV0aGluZyB0aGF0IGp1c3QgYWRkcyBleHRyYQ0KICAgID4gZW5saWdo dGVubWVudCBjYW4gYmUgaW5mb3JtYXRpdmUuDQoNCiAgICBNb3N0IG9mIHRoZSBkb2N1bWVudCBj YW4gYmUgYXBwbGllZCB3aXRoIGVpdGhlciBEVExTIG9yIE9TQ09SRS4gQnV0DQogICAgZ2l2ZW4g dGhhdCAiW2VddmVuIHJlZmVyZW5jZXMgdGhhdCBhcmUgcmVsZXZhbnQgb25seSBmb3Igb3B0aW9u YWwNCiAgICBmZWF0dXJlcyBtdXN0IGJlIGNsYXNzaWZpZWQgYXMgbm9ybWF0aXZlIiwNCg0KICAg IEdpdmVuIHRoYXQgd2Ugc3BlY2lmeSBiZWhhdmlvcnMgZm9yIHRva2VuIGhhbmRsaW5nIG92ZXIg dHJhbnNwb3J0DQogICAgc2VjdXJpdHkgKG1lbnRpb25pbmcgcmVrZXlpbmdzKSBhbmQgYm9keSBw cm90ZWN0aW9uIGZvciBPU0NPUkUsIGFmdGVyDQogICAgcmVhZGluZyB0aGUgZ3VpZGFuY2UgSSdt IHByb21vdGluZyBSRkMgNjM0NyBEVExTIGFuZCBSRkM4NjEzIE9TQ09SRSB0bw0KICAgIG5vcm1h dGl2ZS4NCg0KICAgIChDb0FQLW92ZXItVExTIGNhbiBzdGF5IGluZm9ybWF0aXZlIGFzIGl0J3Mg b25seSB1c2VkIGluICJhbGwgaXMgZmluZSwNCiAgICBtb3ZlIG9uIiBjb250ZXh0KS4NCg0KICAg ID4gICAgQSBzZXJ2ZXIgTUFZIHdhbnQgdG8gZW5jcnlwdCBpdHMgdGltZXN0YW1wcw0KICAgID4g DQogICAgPiBJIHN1Z2dlc3QgdGhhdCBhIHNlcnZlciBkb2VzbuKAmXQg4oCcd2FudOKAnSB0byBk byBhbnl0aGluZy4gIFBlcmhhcHMgaXTigJlzIGJldHRlcg0KICAgID4gdG8gc2F5LCDigJxJdCBt aWdodCBiZSBpbXBvcnRhbnQgdG8gZW5jcnlwdCBhIHNlcnZlcuKAmXMgdGltZXN0YW1wcyAoc2Vl DQogICAgPiBTZWN0aW9uIDYp4oCdLg0KDQogICAgQXMgbXVjaCBhcyBJJ2QgZW5qb3kgZGlzY3Vz c2luZyB0aGUgY29uY2VwdCBvZiAidGhlIHNlcnZlciIgYXMgYW4NCiAgICBvdmVyYXJjaGluZyBl bnRpdHkgZW5jb21wYXNzaW5nIGl0cyBvcGVyYXRvciwgaW1wbGVtZW50ZXIgYW5kDQogICAgaW1w bGVtZW50YXRpb24sIEknbSB0YWtpbmcgdXAgdGhlIHN1Z2dlc3Rpb24gYXMgbm90IHRvIGRpc3Ry YWN0IHRoZQ0KICAgIHJlYWRlci4NCg0KICAgID4gICAgcmVwZWF0ZWQgdHJhbnNtaXNzaW9uIGZh aWx1cmU7IGluIERUTFMsIGlmIG5vIHBhY2thZ2VzIGFyZSBsb3N0KQ0KICAgID4gDQogICAgPiBT aG91bGQgdGhhdCBiZSDigJxwYWNrZXRz4oCdPw0KDQogICAgWWVzLCBmaXhlZC4NCg0KICAgIE5v IGNoYW5nZXMgbmVlZGVkIElNTw0KICAgID09PT09PT09PT09PT09PT09PT09PQ0KDQogICAgPiAg ICBJbiB0aG9zZSBzaXR1YXRpb25zLCBubyBtZXNzYWdlIGhhcyBhbnkgUmVxdWVzdC1UYWcgb3B0 aW9uIHNldCwgYW5kDQogICAgPiAgICB0aGF0IGNhbiBiZSByZWN5Y2xlZCBpbmRlZmluaXRlbHku DQogICAgPiANCiAgICA+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoYXQgaXMgYmVpbmcg4oCccmVj eWNsZWTigJ0gaWYgeW914oCZcmUgbm90IHVzaW5nIGhlDQogICAgPiBSZXF1ZXN0LVRhZyBvcHRp b24gKGFsc28gYXBwbGllcyB0byB0aGUgc3Vic2VxdWVudCBzZW50ZW5jZSkuDQoNCiAgICBUaGVy ZSdzIGFuIGV4cGxpY2l0IG5vdGUgd2hlcmUgcmVxdWVzdCB0YWcgcmVjeWNsaW5nIGlzIGludHJv ZHVjZWQgdGhhdA0KICAgIGZvciB0aGUgcHVycG9zZSBvZiByZWN5Y2xpbmcsIHRoZSBhYnNlbmNl IG9mIGFuIG9wdGlvbiBpcyBqdXN0IGFub3RoZXINCiAgICAidmFsdWUiIGZvciB0aGF0IHB1cnBv c2UuDQoNCiAgICA+ICAgIEluIGRyYWZ0IHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQsIHRoZSBS ZXF1ZXN0LVRhZyBvcHRpb24gdXNlZCB0byBiZQ0KICAgID4gICAgY3JpdGljYWwgYW5kIHVuc2Fm ZSB0byBmb3J3YXJkLiAgVGhhdCBkZXNpZ24gd2FzIGJhc2VkIG9uIGFuDQogICAgPiAgICBlcnJv bmVvdXMgdW5kZXJzdGFuZGluZyBvZiB3aGljaCBibG9ja3MgY291bGQgYmUgY29tcG9zZWQgYWNj b3JkaW5nDQogICAgPiAgICB0byBbUkZDNzk1OV0uDQogICAgPiANCiAgICA+IEl0IG1ha2VzIHNl bnNlIHRoYXQgdGhpcyB3YXMgaGVyZSBkdXJpbmcgd29ya2luZyBncm91cCBkaXNjdXNzaW9uLiAg SXMNCiAgICA+IHRoZXJlIHZhbHVlIGluIGhhdmluZyBpdCBpbiB0aGUgcHVibGlzaGVkIFJGQz8g IElmIHNvLCB3aHk/DQoNCiAgICBJdCdzIGluY2x1ZGVkIHRoYXQgd2F5IChhbmQgbm90IGFzIGEg dG8tYmUtcmVtb3ZlZC1iZWZvcmUtcHVibGljYXRpb24pDQogICAgYmVjYXVzZSBzZWVpbmcgdGhh dCB0aGVyZSB1c2VkIHRvIGJlIG5vdy1jb25zaWRlcmVkLXdyb25nDQogICAgaW50ZXJwcmV0YXRp b25zIGFyb3VuZCBpcyB2YWx1YWJsZSBpbmZvcm1hdGlvbiB0byByZWFkZXJzLiAoTm90IHRoYXQg SSdkDQogICAgaW5zaXN0LCBidXQgbWF5YmUgaXQgbWFrZXMgc2Vuc2UgdGhhdCB3YXkpDQoNCiAg ICA+IOKAlCBBcHBlbmRpeCBBIOKAlA0KICAgID4gDQogICAgPiAgICBzZWN1cml0eSBhZ2FpbnN0 IGFuIGF0dGFja2VyIGd1ZXNzaW5nIGVjaG8gdmFsdWVzIGlzIGdpdmVuIGJ5IHMgPSBiaXQNCiAg ICA+ICAgIGxlbmd0aCBvZiByIC0gbG9nMihuKS4NCiAgICA+IA0KICAgID4gV2hhdCBpcyDigJxy 4oCdPw0KDQogICAgQWRkZWQgYSAiY2FsbGVkIHIiIHRvIHRoZSBpbnRyb2R1Y3Rpb24gb2YgImEg KHBzZXVkby0pcmFuZG9tIGJ5dGUNCiAgICBzdHJpbmciIGF0IHRoZSBzdGFydCBvZiB0aGUgcGFy YWdyYXBoLg0KDQogICAgRGVmZXJyZWQgdG8gdGhlIG90aGVyIGF1dGhvcnMNCiAgICA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQogICAgPiAgICBVbmxlc3MgYSBjb3VudGluZyBFY2hv IHZhbHVlIGlzIHVzZWQsIHRoZSBFY2hvDQogICAgPiAgICBvcHRpb24gdmFsdWUgTVVTVCBjb250 YWluIDMyIChwc2V1ZG8tKXJhbmRvbSBiaXRzIHRoYXQgYXJlIG5vdA0KICAgID4gICAgcHJlZGlj dGFibGUgZm9yIGFueSBvdGhlciBwYXJ0eSB0aGFuIHRoZSBzZXJ2ZXIsIGFuZCBTSE9VTEQgY29u dGFpbg0KICAgID4gICAgNjQgKHBzZXVkby0pcmFuZG9tIGJpdHMuDQogICAgPiANCiAgICA+IFdo YXTigJlzIHRoZSByZWFzb24gZm9yIG5vdCBqdXN0IHVzaW5nIE1VU1QgZm9yIDY0IGJpdHMgYW5k IGJlaW5nIGRvbmUgd2l0aA0KICAgID4gaXQ/DQoNCiAgICBJJ2Qgc3VwcG9zZSB0aGF0IGl0J3Mg dG8gYWxsb3cgZm9yIGFwcGxpY2F0aW9ucyB3aXRoIHdlbGwgY29udHJvbGxlZA0KICAgIHBvd2Vy IGN5Y2xlcyBhbmQgRWNobyB2YWx1ZSBjaGFuZ2VzIHRvIHJlZHVjZSB0aGVpciBtZXNzYWdlIHNp emVzIC0tDQogICAgR8O2cmFuLCBjb3VsZCB5b3Ugc2F5IGEgYml0IG1vcmUgaGVyZT8NCg0KDQog ICAgPiAgICBTZXJ2ZXJzIE1BWSB1c2UgdGhlIHRpbWUgc2luY2UgcmVib290IG1lYXN1cmVkIGlu IHNvbWUgdW5pdCBvZiB0aW1lLg0KICAgID4gDQogICAgPiBGb3Igd2hhdD8gIEl04oCZcyBub3Qg Y2xlYXIgdG8gbWUgd2hhdCB0aGlzIHJlZmVycyB0by4NCg0KICAgIEpvaG4sIEfDtnJhbiwgY291 bGQgdGhpcyBiZSBhIGxlZnRvdmVyIGZyb20gdGhlIGxhdGVyIGNoYW5nZXMgYXJvdW5kDQogICAg c2VydmVyIC8gd2FsbCB0aW1lPw0KDQogICAgS2luZCByZWdhcmRzDQogICAgQ2hyaXN0aWFuDQoN CiAgICAtLSANCiAgICBUbyB1c2UgcmF3IHBvd2VyIGlzIHRvIG1ha2UgeW91cnNlbGYgaW5maW5p dGVseSB2dWxuZXJhYmxlIHRvIGdyZWF0ZXIgcG93ZXJzLg0KICAgICAgLS0gQmVuZSBHZXNzZXJp dCBheGlvbQ0KDQo= From nobody Wed Sep 23 06:11:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1A53A1192 for ; Wed, 23 Sep 2020 06:10:58 -0700 (PDT) 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 cgvtvwnuvQAN for ; Wed, 23 Sep 2020 06:10:55 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30088.outbound.protection.outlook.com [40.107.3.88]) (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 A74FA3A11AA for ; Wed, 23 Sep 2020 06:10:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=melrX0NJIdGf0as3tDpoE7pVkNQidZv3cKQuxwXxUDXOtRaHKqPoO8d010c5vk8k2XBriwkvJ7+ZYc+WPeDFTIXC3yXyrHwQAJMKUl0/aJ/sGNb+ytseQao6Ex+Bdc3lX7OrVjONxhqCkQgXqBTFrmuHQSbJYk/qgI7HSUQpjkCSn7OhYPTUTKSeytBpONmD8yfSECIJJYKuVSOWTXPWvtas81xa1XW+/pi3wmJ5NqqfiirMI78ZAimviYHQpzfnbvL5Cj4iTKTnBRGgt25YHslF4Tp3AoDzoU/M3Kj7Jy6c2gGyvis0UNH0XjkqASJYe8l11o/tkOoqigeHEKjEkw== 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=T9d6kXXViSaJK8qFbBqiLmQZ7bMjnOCsIE/pBDwFa10=; b=H4TcXu2voDLUl3fkkGbHzpz6l1hBhT6alk5TWwlEaiLRS0n3jQSWyRImRGFR7cd2umq4ZkIeJbHd04ER4LleA/Eqfdu2M9zvGZKKvzY1BzEnU/Jxf2VR9CObqqzc9ikIJra1F/Py8QCTwETwen/wmzvJ5oi5AQjMTT/cCkW8aDVbT6ztYyp8QF6N6bEibO7VG0Z0qPvdBdy4aQw5gMVwPe4sOy9v6/4BEEyQZLQ1WnOoAKhqXjHWq32XQD2X5wv7gtdf6Y84XxCgIyORg5v+9g6M/oDjEmiGGBE15BnTHUh094uN8JrHhCEtPbfGwgFApQPTMcWGDJSqoea+E6FeSg== 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=T9d6kXXViSaJK8qFbBqiLmQZ7bMjnOCsIE/pBDwFa10=; b=d+SF5xQetoh4dMziYR+emHG0JBbwtr7A2cTbXSXPI8l0qvyEcIPEUWz+E5sqzlMMj5nwRrCIKnQ6bX4qYxgRwbxFO2ek4HYc/xAgyA3EoZnhyKhjgtfMO24+YsqJHn/6aHvAgcTSIuYwx+ryb4dfcpS7WfORgh84Tk3nNKPI4oY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0935.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:165::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Wed, 23 Sep 2020 13:10:52 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::a11e:4abe:4099:5157%9]) with mapi id 15.20.3391.026; Wed, 23 Sep 2020 13:10:51 +0000 To: "core@ietf.org WG (core@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: <9a6e6a43-c6c0-fa05-f99e-6160b2b9cd54@ri.se> Date: Wed, 23 Sep 2020 15:10:44 +0200 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="nrlhr9nQo7qTy1KbXJTYwHGO7xL4a9Etb" X-ClientProxiedBy: HE1PR0401CA0097.eurprd04.prod.outlook.com (2603:10a6:7:54::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.6] (185.247.71.60) by HE1PR0401CA0097.eurprd04.prod.outlook.com (2603:10a6:7:54::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Wed, 23 Sep 2020 13:10:51 +0000 X-Originating-IP: [185.247.71.60] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 635c0bc8-886f-4218-02d4-08d85fc218a2 X-MS-TrafficTypeDiagnostic: DB8P189MB0935: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: itFV/qUuPl05E3fKV3LnT9bVy2kjPenYUZM/8WY1YUhENTKgM2ubXTrV9YzUUY0A59bZ/oex/KIo1rLG4T5tcNrY5Ewnm/0e82XKv7GsChzbJKD/z1BrW04Zqni6pwjnXf14w9EckajLhwu8IL7KVZk4h40CpvVnMeFhBD5A+Os/jwBfltgIDwROpCeAAIhW8b0TuHuO4ZYZE1C5LTpUWnPVFOLO0AcmzAllSn8cInz7hHfmqK7BGjUK2m3ppwmHd3PwaXX48rHeiFnfNaUVqpL6k6n12eZaTs0TFeaVYRrV+EQbpJcobIflJRH8bYMsJdvVN3jAnb/o+vm5zQLV9TdounmL7iPy8NL/e1qdRQAgPNMWKWfSJ/I5H3XuOcDbB92A79EDihH42iJLe2silQV/cHQRn87csgpMOV1Q+tDN9T2XGuYYzeVqQ5C2frw7vxjPIUeASjHILTwGfe+PPUPgoAC+34GYJ7d/mkG1RbSBKsFPhgkabog8LFTfNB5K 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)(346002)(39860400002)(366004)(396003)(136003)(6916009)(5660300002)(44832011)(86362001)(6666004)(26005)(33964004)(316002)(52116002)(186003)(16576012)(956004)(31686004)(478600001)(66574015)(83380400001)(16526019)(8676002)(16799955002)(966005)(235185007)(2906002)(66946007)(66476007)(8936002)(66556008)(2616005)(21480400003)(36756003)(6486002)(31696002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: +lSdDxxCXCvzAZM6PTYBEk252bF37xo7aL3HXEDanxlYqOKYdi1uDkdVxJbhpm0TWdTUZYtjgaRpePpbSlUNhmu8CpXXCw6JU+/xNj4oWbZZBTAOpTJOknTfOJwpY20YzfsxChQe1WjpSyUcdKkSioj1bLxixQSf+k3f2iB5wu/M4hJTyxVwofqAm3+QQ1sLiQ3SxiZn9zmGVLY48zTEbr4Ga95hc0NDUQ/H6VlSj7GSuFeiUv/1cfu3jtCPOaSy81T3Bx1ukVKY1c6hjeFoU78gy5zzB9sP3M8RLviq31tmaa8mub3/iO65DN3ApFViEVu+GEXiSVT0KU99AHKv0KDiDq94UEBjdqWBcO3mF8JfFxY/MUlPo8GuTaza9MpwFa5Km5tejbmHpnk/IPaFfo6xNF4lP3zkFtBmsiR3AhDDkUn6dfkhR8A/NJSo2PmVoB29wDUy27zC3qsLyhzCS/P/vt/cS/cz6eEf9P8QpbA+0F+II0LQbx9c9DZNRHl8jY7JlxXLjCfX0PadcBtfz5AXY4SmFOX7wZR109QhqpJmIIRgeFyOJw7AlEHHzJT5up7Yu3gKDLLRgx/L4AQAWtP5hzb3/63P1hrn4mCNrn4jeJfIKz92Ov6AcNWB9xwRJEhYoVedW9gH9clfwjYJgw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 635c0bc8-886f-4218-02d4-08d85fc218a2 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 13:10:51.7686 (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: kybhXOFf2Q2dQ+u4p5/urHyz4I5Logna94aqZfT5iGiwiXRQPPz3yYyiOIqrcVFr0EQB7GhWouGq3EeurI2DBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0935 Archived-At: Subject: [core] CoRE WG Virtual Interim 2020-09-24 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 13:10:58 -0000 --nrlhr9nQo7qTy1KbXJTYwHGO7xL4a9Etb Content-Type: multipart/mixed; boundary="IDqN4QVYSbFr3i4GsK2r9Syk8bJboxJVQ" --IDqN4QVYSbFr3i4GsK2r9Syk8bJboxJVQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that tomorrow (Thursday) at 14:00 UTC we'll have a virtual interim via Webex. The agenda is to check and discuss: - The processing of comments for the Resource Directory document. - The status, open points and way forward for the Dynlink document. Please, find below the information to join the meeting. Best, Marco and Jaime =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2020-core-09-core Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm77b4ee5ef9869f87a24a3aa57f2c30f= 5 Meeting number: 171 924 7334 Password: constrained More ways to join Join by video system Dial 1719247334@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in number (US/Canada) Access code: 171 924 7334 --=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 --IDqN4QVYSbFr3i4GsK2r9Syk8bJboxJVQ-- --nrlhr9nQo7qTy1KbXJTYwHGO7xL4a9Etb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl9rSVUACgkQ7iZktA5Y 2kMPqQf/dmWeV9ZsUuqt09D77T7MM8P3hG8H6Jq38MHbD1qyPd397QA079zrhJ2y M577BNq5K8a+z0QK19KrQHBi/Dm0h7PdMILjPeR3V+kKUzu4iCNQseOvZN1Z77Ma sDuV8Hhvdemuf5P579wTAFYNcvi3XqbeVHwfTqsgCzHdTR0IBwB3zL8qWl5VuNEE 7U+11VCE30gGP2RzDD6itm2SVZQuViqhIusK9PcfJKRnN2/6Vkidj4jgsdfbcT14 M4kmPu6Jnpskz3IoWkNwNP83QikpQ1E0Ur6Zx/q2eS1Zv4teJT50ZrP/AjISkPVx VhqxiaIbOQAjhZVrE1B7veSLu0B+IA== =xpgh -----END PGP SIGNATURE----- --nrlhr9nQo7qTy1KbXJTYwHGO7xL4a9Etb-- From nobody Wed Sep 23 08:35:14 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 414AC3A10E8; Wed, 23 Sep 2020 08:35:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160087531222.19112.14519373252604980147@ietfa.amsl.com> Date: Wed, 23 Sep 2020 08:35:12 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 15:35:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-01.txt Pages : 24 Date : 2020-09-23 Abstract: This document specifies alternate Constrained Application Protocol (CoAP) Block-Wise transfer options: Quick-Block1 and Quick-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-01 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 Sep 23 08:40:17 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A90C3A0FB8 for ; Wed, 23 Sep 2020 08:40:14 -0700 (PDT) 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 I-gB96imM1Xi for ; Wed, 23 Sep 2020 08:40:12 -0700 (PDT) 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 075F53A1192 for ; Wed, 23 Sep 2020 08:40:09 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4BxMnN1bgfz7vmQ; Wed, 23 Sep 2020 17:40:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1600875608; bh=L5DPxD+YgSWVDjAOFca4UD8OMhzK3ekjyJ2p5dzR9eE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=PoRK3zWRUlaZBaJQMM4KIl2L1lWc194vP1QYoAOVQqlfTObKw7k86OgOkWwkxUC5l egg4RSvLEYRT/nU3qGz2PYdy1iwejLZ3yqSEu7YDSKCrX9+xdVFcaJonuv+OSFGY5u hFjbBxHpT0p+T3C6cNowX0RzRGbL3rYkfosGvUKrXiDuSroBxvPyNMlqP+fPL9z+g3 IMMIfYWzqJtd//wdSYbkcV/PsziJ0l3LYatJQVj3nuqclFARPm2sYvnbDsKxZ9lkYk bOBnfG8OswGxREvfmNJL9rwbQsrdxWjkkF5itwnmpXw078mFbfJWFSP8uPjtsUxHrp sAGjyOtTger8Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4BxMnN0dGnz2xC7; Wed, 23 Sep 2020 17:40:08 +0200 (CEST) From: To: "supjps-ietf@jpshallow.com" , "christian@amsuess.com" , "core@ietf.org" Thread-Topic: core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt Thread-Index: AQHWazQlvA4HUPH8rE2dC1hQ5X7Dmakpzm6AgDfVT5CAFQRwwA== Date: Wed, 23 Sep 2020 15:40:07 +0000 Message-ID: <18446_1600875608_5F6B6C58_18446_133_1_787AE7BB302AE849A7480A190F8B933031545430@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <26993_1595950051_5F2043D8_26993_392_1_787AE7BB302AE849A7480A190F8B93303150608A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29030_1593429656_5EF9CE98_29030_149_1_787AE7BB302AE849A7480A190F8B9330314E8C6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200805142431.GB3480705@hephaistos.amsuess.com> <390001d66b63$2f8a3790$8e9ea6b0$@jpshallow.com> <13262_1599721162_5F59CECA_13262_371_5_787AE7BB302AE849A7480A190F8B93303153E110@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <13262_1599721162_5F59CECA_13262_371_5_787AE7BB302AE849A7480A190F8B93303153E110@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: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 15:40:14 -0000 Hi all,=20 We proceeded with the publication of the candidate version: A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-new-block-01=20=20 FYI, Jon has now an implementation following this latest version of the spe= cification. I let him share more feedback on the implementation. Comments and suggestion are more than welcome, as usual.=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: jeudi 10 septembre 2020 08:59 > =C0=A0: supjps-ietf@jpshallow.com; christian@amsuess.com; core@ietf.org > Objet=A0: Re: [core] core-block-04: Applicability and general remarks > draft-bosh-core-new-block-04.txt >=20 > Hi Christian, all, >=20 > We finally managed to prepare a candidate -01 of the draft that > hopefully addresses your review. The main changes are: >=20 > * Update the Applicability Scope > * Remove the TBA3 (Missing Payloads), but use 4.08 instead > * The options are marked as unsafe. The caching behaviour is updated > * Move the CC text to a (new) dedicated section > * Avoid the normative language for the usage of Tokens. A new > (short) section is added for the token discussion. > * Rename the options to Quick-Block1/2 >=20 > We made other edits to enhance the readability of the document. >=20 > The candidate version is available at: https://core- > wg.github.io/new-block/draft-ietf-core-new-block.txt >=20 > A diff to track the changes can be seen here: > https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft- > ietf-core-new-block.txt&url2=3Dhttps://core-wg.github.io/new- > block/draft-ietf-core-new-block.txt >=20 > Please check the candidate version. >=20 > Thank you. >=20 > Cheers, > Jon & Med >=20 > > -----Message d'origine----- > > De=A0: supjps-ietf@jpshallow.com [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 5 ao=FBt 2020 22:01 > > =C0=A0: christian@amsuess.com; BOUCADAIR Mohamed TGI/OLN > > ; core@ietf.org Objet=A0: RE: > > core-block-04: Applicability and general remarks draft- > > bosh-core-new-block-04.txt > > > > Hi Christian, > > > > Thanks for this review. Med and I will update the draft as > > appropriate. > > > > Otherwise, comments inline > > > > Regards > > > > Jon > > > > > -----Original Message----- > > > From: christian@amsuess.com [mailto:christian@amsuess.com] > > > Sent: 05 August 2020 15:25 > > > To: mohamed.boucadair@orange.com; Jon Shallow (supjps- > > > ietf@jpshallow.com); core@ietf.org > > > Subject: core-block-04: Applicability and general remarks > > > draft-bosh-core- new-block-04.txt > > > > > > Hello Med, hello Jon, > > > > > > here's a few concrete points I'd like to suggest for new-block: > > > > > > * Applicability: I'd have expected to read something like this > in > > the > > > introduction: > > > > > > > The block-wise transfer of [RFC7959] covers the general > case, > > but > > > > falls short in situations where packet loss is highly > > asymmetrical. > > > > > > > > The new options introduced here provide roughly similar > > features to > > > > the Block1/Block2 options. They provide additional > properties > > that > > > > are tailored towards the intended use case, and leave out > > mechanisms > > > > like non-atomic access and proxy support that would > complicate > > their > > > > description. > > > > > > > > They are not intended for general CoAP usage, and any use > > outside > > > > the DOTS use case should be carefully weighed against the > loss > > of > > > > interoperability with generic CoAP applications. It is hoped > > that > > > > experience gained with these options can go into future > > extensions > > > > of the block-wise mechanism that are both generally > applicable > > and > > > > serve this particular use case. > > > > Jon> Thanks for the suggestions > > > > > > * Separation of layers, sub-topic "congestion control": It > should > > be > > > possible to phrase all congestion control parts of this in a > > dedicated > > > section (which may also make sense as an appendix). > > > > Jon> Good idea > > > > > > > > I'd avoid all other mentions of things like PROBING_RATE: For > > example, > > > Section 3.4 right in the middle of a paragraph on re- > requesting > > > missing blocks states that > > > > > > > The rate of requests for missing blocks is subject to > > PROBING_RATE. > > > > > > Yes it is, but so is every single CoAP request until the > client > > hears > > > back from the server. Repeating these things in places where > are > > not a > > > new requirement may make it easier for some implementers that > > try to > > > build the whole stack in a single go, but even for them is > prone > > to > > > the authors missing a spot -- and for everyone else this will > > each > > > time trigger the question of "is this new here or isn't this > > already > > > handled by a component two layers down the stack?". > > > > Jon> OK > > > > > > I haven't tracked every single retransmission and rate > limiting > > > statement throughout the document, but I expect that this > > section > > > could boil down to something like > > > > > > > For the DOTS use case, the following default CoAP parameters > > are > > > > updated to better reflect the typical deployments: > > > > > > > > * PROBING_RATE: 10 kilobyte/second > > > > > > > > The averaging process mentioned in RFC7252 Section 4.7 after > > which > > > > PROBING_RATE applies is not fully defined there. For the > above > > > > applications, a new parameter PROBING_RATE_WINDOW is > > introduced. > > > > Messages up to a total size of PROBING_RATE_WINDOW may be > sent > > > > before PROBING_RATE is considered, and the probing rate may > > > > generally be exceeded by that amount of data in short term. > > > > > > > > * PROBING_RATE_WINDOW: 15 kilobyte > > > > > > (The latter replaces MAX_PAYLOADS, and I'm not sure whether it > > is > > > better to express this in terms of package count or bytes on > the > > wire, > > > just giving an example here. All numbers in the above were > > pulled out > > > of uninformed air.) > > > > Jon> My leaning is towards packet count - circuit speeds cover a > > Jon> significant > > range. I need to think this through. > > Jon> The default RFC7252 PROBING_RATE is too low in my humble > > estimation > > Jon> - a > > large packet can cause long inter-packet gaps (300 bytes is a 5 > minute > > delay) > > > > > > * Separation of layers, sub-topic "Tokens": Same thing, next > > layer. > > > > > > Whenever you're tempted to talk of a token, consider some of > > these > > > replacement phrases as a first step: > > > > > > * "MUST be sent with a new token" -> "is a new request". > > > * "Tokens MUST be included" -> (nothing -- transports use > tokens > > by > > > construction) > > > * "MUST be sent with the same token as the response" -> "is > sent > > as a > > > response to" / "is sent as an additional response to that > > request". > > > (Here it may make sense to refer to the tokens in an > > additional " > > > (which means it uses the same token, the same way an > > observation > > > response uses the requests's token for multiple > responses)"). > > > > Jon> Agreed - Token references needs to be tidied up. Will work > on > > this. > > "additional" may help us here to clarify which token 'value' > should be > > used where. > > > > > > * Naming: It's technically a minor thing, but people have > already > > > complained to me about how hard the Block[12] names are to > > > comprehend, > > > and introducing these options as Block[34] would not help > here. > > > > > > I'd like to suggest QuickBlock-Block[12]. > > > > Jon> Certainly Block[34] are likely to transfer data more quickly > > than > > Block[12]. However xxxx [12] implies a replacement for Block[12] > > which I am not so sure about. > > > > > > > > (I know that this part of designing a new option is annoying. > In > > the > > > interest of winding up with something that can be learned > > easily, it > > > is unfortunately essential). > > > > > > In connection with that, it may make sense to briefly think > > about a > > > draft name before it is submitted as a WG draft. new-block > > sounds like > > > a 7959bis, which in my understanding this does not aim to be. > > > > Jon> Good idea. > > > > > > * 4.TBA3 Missing Payloads: I don't quite see why this needs a > > distinct > > > code. 4.08 Request Entity Incomplete sounds perfectly suitable > > to me. > > > > Jon> As we have to define the diagnostic payload as containing the > > Jon> missing > > blocks, we did not want to change the semantics of how 4.08 is > used > > - hence TBA3. > > > > Jon> That said, a 4.08 response could contain 1 or more Block3 > > options > > Jon> but > > that would take up more space. > > > > > > If you think that sending an existing 4.xx code in the middle > of > > a > > > block-wise transfer would cancel the transfer, there's still > two > > ways > > > out of this: > > > > Jon> I was concerned about the 4.08 diagnostic payload changing > > format, > > Jon> but > > yes, an 'unexpected' error code could terminate the transfer. > > > > > > * You're just defining what a block-wise transfer is; just > allow > > it. > > > > > > (In a RFC7959 block-wise transfer that runs over a proxy, > the > > proxy > > > may be currently incapable of doing any forwarding and > return > > 5.03 > > > Service Unavailable Max-Age:5. The client would then just > > pause 5 > > > seconds and send the latest block again.) > > > > > > * For all but the last block, it may also be an option to send > > it as a > > > payload to a 2.31 code -- I don't think that would be > outright > > > forbidden (and at any rate, all involved clients speak the > > protocol > > > anyway). > > > > Jon> I have an issue with changing the 2.31 reporting on the last > > Jon> successful > > block received - this currently fails if block num of 0 is missing > as > > we cannot indicate block num =3D -1 has been received. > > Jon> If the last block is received, but a previous one was not, a > > 2.31 > > Jon> could > > be used to re-request the missing block, but a 2.01/2.04 would > need to > > be held back for the final block acknowledgement. > > > > > > * The draft describes this all as "just working through a proxy" > - > > - > > > original block-wise does not, and I'd like to hear how this is > > hoping > > > to get away without the options being proxy-unsafe. > > > > Jon> I was not aware of CoAP to CoAP proxy issues with BLOCK[12] > > when > > Jon> this > > was written, but your comment implies that there is. Certainly > CoAP > > to other protocol proxies could run into issues. > > > > Jon> I was thinking of block by block proxying working and hence > > could > > Jon> be > > proxy unsafe. > > > > > > Is there any point at all in using block-by-block proxying for > > these > > > use cases? Unless a proxy is sitting right inside the link > under > > > attack, and unless the bodies get huge, it may be way easier > for > > this > > > to be purely hop-by-hop. Proxies would reassemble the full > > bodies and, > > > for the next hop, just decide what works best there (be it > > regular > > > block-wise, Block34 or BERT). > > > > Jon> Yes, there could be full body re-assembly and the full body > > held in > > cache if needed. This would add in a bit of latency. However > this > > would restrict a Block[34] possibility of supporting streaming of > data > > should that be required. > > > > > > (If there's a point in allowing block-by-block forwarding, we > > can talk > > > it through and work through the initial ideas that will come > up > > like > > > "We use large enough Request-Tag values so they are unique", > > "how > > > large does that need to be", "why do we end up having a > Request- > > Tag in > > > every request now" and "why do we not want that", but my gut > > feeling > > > is we won't need to go there.) > > > > Jon> For Block3 which would use Request-Tag, I would expect that > for > > a > > specific body of data for a specific resource the Request-Tag to > > remain the same - and if the body changes a new Request-Tag is > used. > > Jon> As this is the same Request-Tag for whether the whole body is > > Jon> cached, > > or individual blocks of the body the Request-Tag usage will not > > change. > > 2^32 should be large enough - 2^64 even better - but re-usage has > to > > be generally considered. > > > > ~Jon > > > > > > Kind regards > > > Christian > > > > > > -- > > > To use raw power is to make yourself infinitely vulnerable to > > greater > > > powers. > > > -- Bene Gesserit axiom >=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 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. >=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 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. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core ___________________________________________________________________________= ______________________________________________ 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 Sep 24 14:28:14 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE23A12E3 for ; Thu, 24 Sep 2020 14:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75m_bOYnfAZU for ; Thu, 24 Sep 2020 14:28:11 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 577073A12E1 for ; Thu, 24 Sep 2020 14:28:11 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id c2so322341otp.7 for ; Thu, 24 Sep 2020 14:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=peTgd/MiSpjs6rIC8SWt4lGNACW/56lpd3FcK0JePy4=; b=EFFbn1ylVve4AzVsJigkPzoA/2U2qsxVpmHdT5UbvV8PUxHzOJNwCNOrPbrGcAD2zE 9xau7VucPviexJrnh67qs5wEW+sKrMmJtL5OjXomDcpojoQtdSNvIwb19qfCb522aX5W qk5FfcfdKlk5wCebcSgtfMLxqVpv+aPRMYHDHeJarNJKjIZSBbAoasHB5zT4c4m3Sue/ Eq4uUcO1YD1w+Xt2xRGL8w6jOtJx+ZK8XSbinTA7dJl1r2x5dCXBYYjGokBxvhUKTBcS lzWnogzJKaY8V/SyuEhmZRNeEh6RxuCGH4R9Dpd3IFbs6k32M3KAtuhoQt9wZqLweWfh K+cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=peTgd/MiSpjs6rIC8SWt4lGNACW/56lpd3FcK0JePy4=; b=HELi1UsHArp5rv/2IU7Oj0QJTen53bJtEO78G8vhZS0YRnHXGjyJ5oZeMedKSYviE4 4qVWsUh0PB+hHEi9rcfqkY6sL80Y/rU+AG8tgrP/7ydhp5jGot4vnVywyDF7Hk91bDfY z8SHGN6V/rE+CXDRRfK993BZexLlMomZVteUvPbq+WM7uayH79xZxa5ETjA1ukjY6ucf BrgD0nmOOKyWvpVDFYUkZhwo3GGK+HUkQegLfkurAiALuauroB8rT+w2vKRdj21VTQlk mSHL6qhDBfIorEWF1eLHkRCFl2pcAoZDnpdiKmYQrNTJOQwtfnYdCavxJyZl5TzUawnQ POvg== X-Gm-Message-State: AOAM532i7rhjE1po96W5JJNmGZOvExiaO4/YnX2jt7ilRz5RcquQwLp0 SIO6agv7zfqBU1SR8Jj4EdRUmyak52JYdnElMA9Gz6UJUysq7w== X-Google-Smtp-Source: ABdhPJzWnQWe8BvfsbF+edhK65Cn7c6t9E2utMcjEASORhDQBih68Gv03EEUped6At62Wt14hLVhuLRrplmiVM7/VZM= X-Received: by 2002:a9d:6b16:: with SMTP id g22mr782261otp.42.1600982890380; Thu, 24 Sep 2020 14:28:10 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Beri Date: Thu, 24 Sep 2020 14:27:34 -0700 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="00000000000079020205b015e0eb" Archived-At: Subject: [core] Mini series on CoAP for developers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 21:28:13 -0000 --00000000000079020205b015e0eb Content-Type: text/plain; charset="UTF-8" https://medium.com/@jonathanberi/a-field-guide-to-coap-part-1-75576d3c768b Hi folks! I've started to blog about CoAP to raise awareness among application developers. The first post is out and I'm planning at least 3 more. Any feedback would be appreciated! Please do note that I've taken some liberties as the audience is application developers and not implementers, so expect some generalization. That said, please let me know of anything you feel is incorrect, misleading...or you think should be included! Cheers. -- Jonathan Beri linkedin.com/in/jonathanberi --00000000000079020205b015e0eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://medium.com/@jonathanberi/a-field-guide= -to-coap-part-1-75576d3c768b

Hi folks! I've star= ted to blog about CoAP to raise awareness=C2=A0among application developers= . The first post is out and I'm planning at least 3 more. Any feedback = would=C2=A0be appreciated! Please do note that I've taken some libertie= s as the audience is application developers and not implementers, so expect= some generalization. That said, please let me know of anything you feel is= incorrect, misleading...or you think should be included!

Cheers.

--
=
--00000000000079020205b015e0eb-- From nobody Mon Sep 28 01:38:10 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 257053A0EFD; Mon, 28 Sep 2020 01:38:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: core-chairs@ietf.org, marco.tiloca@ri.se, barryleiba@computer.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160128228878.31532.5718875575152289910@ietfa.amsl.com> Date: Mon, 28 Sep 2020 01:38:09 -0700 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 109 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 08:38:09 -0000 A new meeting session request has just been submitted by Marco Tiloca, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: ace cbor t2trg cose lake artarea Technology Overlap: teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw Key Participant Conflict: irtfopen rats suit dnssd netconf netmod emu dots anima asdf People who must be present: Barry Leiba Jaime Jimenez Marco Tiloca Resources Requested: Special Requests: Plse also avd any potntlly IoT reltd BOFs&amp;PRGs tht mght cme up. Prefer some time between the two meetings (48 h or more). Second meeting often is 40 people. --------------------------------------------------------- From nobody Mon Sep 28 07:58:25 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B03A0F83 for ; Mon, 28 Sep 2020 07:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHlAtZXf2QWb for ; Mon, 28 Sep 2020 07:58:21 -0700 (PDT) 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 B427D3A0F62 for ; Mon, 28 Sep 2020 07:58:20 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kMubZ-0000bP-5p; Mon, 28 Sep 2020 15:58:17 +0100 From: To: , References: <26993_1595950051_5F2043D8_26993_392_1_787AE7BB302AE849A7480A190F8B93303150608A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29030_1593429656_5EF9CE98_29030_149_1_787AE7BB302AE849A7480A190F8B9330314E8C6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200805142431.GB3480705@hephaistos.amsuess.com> <390001d66b63$2f8a3790$8e9ea6b0$@jpshallow.com> <13262_1599721162_5F59CECA_13262_371_5_787AE7BB302AE849A7480A190F8B93303153E110@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18446_1600875608_5F6B6C58_18446_133_1_787AE7BB302AE849A7480A190F8B933031545430@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <18446_1600875608_5F6B6C58_18446_133_1_787AE7BB302AE849A7480A190F8B933031545430@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 28 Sep 2020 15:58:17 +0100 Message-ID: <01e001d695a7$cc736540$655a2fc0$@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: AQGl2PHGagr8ajIDOm+hwI37uALRBQLImF6uAZuB0AoBNeUyLAGJYejjAn6RrVapkkcSMA== Content-Language: en-gb Archived-At: Subject: Re: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 14:58:24 -0000 Hi All, Some implementation notes on getting Quick-Block(1/2) up and running. The implementation has been done using libcoap - where a lot of the = RFC7959 block-wise handling was done by the application. All the block handling = has now been moved down into libcoap (code not yet a part of libcoap, but = will be a PR) as a starting point for the draft-ietf-core-new-block implementation. Support of both Q-Block1 and Q-Block2 Currently, Q-Block1 and Q-Block2 can independently be supported (i.e. = client or server need only support one of them). This made the detection of whether the peer supported these options a bit more complicated - if the client used both in a NON request, the resultant (optional) RST did not indicate which option was not supported. With a CON request, the 4.02 response is not clearly defined "5.4.1 This response SHOULD include a diagnostic payload describing the unrecognized option(s)" as to how you = can determine which critical option it refers to. Libcoap happens to return = the critical option(s) as options in the response, but I do not think that = this is universal. For other implementations, it may be easier to mandate that both or none = of the options are supported by a CoAP agent (and would remove unnecessary = code in libcoap). MAX_PAYLOADS A design goal is that when using NON, it does not matter whether the = body fits in a single or requires multiple packets, the unidirectional = sending of the information does not require a response and it is recognized that = there may be some loss of receipt of the body. With the current specification there is an ACK_TIMEOUT wait (2s) every MAX_PAYLOADS (10) transmissions. This works fine - large bodies are just bursty in their transmission. Use of CON for the last of the MAX_PAYLOADS packet relies on there not = being an asymmetric traffic loss. Use of CON every last of the MAX_PAYLOADS packet does make the traffic considerably less bursty. A thought moving forward for Q-Block1 is that on receipt of a NON MAX_PAYLOADS packet that there is a 2.31 response (if all packets = received) or a 4.08 response indicating any missing packets (and possibly the next packet in the sequence) so that the transmission of the next = MAX_PAYLOADS worth of packets is not delayed if response is received by the client. = If the response does not get through, the ACK_TIMEOUT wait still stands. Moving forward with Q-Block2 to reduce this burstiness is that if all = the packets have been received to date that the next packet in the sequence = is requested, else missing packets are reported on. If the new request = does not get through, then the ACK_TIMEOUT wait still stands. Q-Block2 implementation The Q-Block2 was the easiest to implement. However, working out how = many Q-Block2 can be fitted into a request packet for the missing blocks is = not that straight forward as the options with bigger block.num may require = more space. A suggestion is to limit the number of missing Q-Block2 options to MAX_PAYLOADS. This also then ties in nicely with what a server can send = at once. Q-Block1 implementation a) I really struggled with the CDDL definition for the payload of the 4.08 response and making sure that It was correct. The cddl tool referred = to in RFC8610 is more focussed on JSON type structures (insisting that each = object is named) than pure CBOR. The RFC8610 examples are JSON based - there = is reference to other RFCs that are CBOR based and their examples, but = these predate RFC8610 and (to me) of limited help. It is still unclear to me = that the first line of the definition should use curly braces (as cddl tool insists) or normal parentheses. As an example, I am expecting the CBOR = to look something like a2; map(2) 41; byte(1)=20 01; opaque request-tag - just happens to be 0x01 in this case 83; array(3) 01; uint missing-block-number 02; uint missing-block-number 03; uint missing-block-number We also state "4. The data payload of the 4.08 (Request Entity = Incomplete) Response Code is encoded as a CBOR Sequence [RFC8742]". The array is certainly a CBOR sequence, but is all of this structure a CBOR sequence? As for Q-Block2, I think the array size of the CBOR should be limited to MAX_PAYLOADS to ease the determination of the size of the payload, and = make it easier for the client to limit the number of packets sent at once. b) Using CBOR in the 4.08 payload means that libcoap needs to have some knowledge about CBOR so I had to code in some simple code to cover this = use case. c) There are a lot of tokens to track. With the current draft assuming = that each of the MAX_PAYLOADS packets is an individual request, this means = that there are MAX_PAYLOADS of tokens per multiple transmission that need to = be tracked. It cannot be assumed that the last packet of the MAX_PAYLOAD = set will be received and that any response is against that last token. In the same way that we have an "associated response" aka Observe that = uses the same token, would it be possible to have an "associated request" = that uses the same token to minimize token tracking and associated garbage collection per singular body? I would still expect any re-requested block (in 4.08 response) to be = sent with a different token and have to track that token as well. Regards Jon > -----Original Message----- > From: mohamed.boucadair@orange.com = [mailto:mohamed.boucadair@orange.com] > Sent: 23 September 2020 16:40 > To: supjps-ietf@jpshallow.com; christian@amsuess.com; core@ietf.org > Subject: RE: core-block-04: Applicability and general remarks draft-bosh-core- > new-block-04.txt >=20 > Hi all, >=20 > We proceeded with the publication of the candidate version: >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-new-block-01 >=20 > FYI, Jon has now an implementation following this latest version of = the > specification. I let him share more feedback on the implementation. >=20 > Comments and suggestion are more than welcome, as usual. >=20 > Cheers, > Jon & Med >=20 > > -----Message d'origine----- > > De=A0: core [mailto:core-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com > > Envoy=E9=A0: jeudi 10 septembre 2020 08:59 > > =C0=A0: supjps-ietf@jpshallow.com; christian@amsuess.com; = core@ietf.org > > Objet=A0: Re: [core] core-block-04: Applicability and general = remarks > > draft-bosh-core-new-block-04.txt > > > > Hi Christian, all, > > > > We finally managed to prepare a candidate -01 of the draft that > > hopefully addresses your review. The main changes are: > > > > * Update the Applicability Scope > > * Remove the TBA3 (Missing Payloads), but use 4.08 instead > > * The options are marked as unsafe. The caching behaviour is updated > > * Move the CC text to a (new) dedicated section > > * Avoid the normative language for the usage of Tokens. A new > > (short) section is added for the token discussion. > > * Rename the options to Quick-Block1/2 > > > > We made other edits to enhance the readability of the document. > > > > The candidate version is available at: https://core- > > wg.github.io/new-block/draft-ietf-core-new-block.txt > > > > A diff to track the changes can be seen here: > > = https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft- > > ietf-core-new-block.txt&url2=3Dhttps://core-wg.github.io/new- > > block/draft-ietf-core-new-block.txt > > > > Please check the candidate version. > > > > Thank you. > > > > Cheers, > > Jon & Med > > > > > -----Message d'origine----- > > > De=A0: supjps-ietf@jpshallow.com = [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: mercredi 5 ao=FBt 2020 22:01 > > > =C0=A0: christian@amsuess.com; BOUCADAIR Mohamed TGI/OLN > > > ; core@ietf.org Objet=A0: RE: > > > core-block-04: Applicability and general remarks draft- > > > bosh-core-new-block-04.txt > > > > > > Hi Christian, > > > > > > Thanks for this review. Med and I will update the draft as > > > appropriate. > > > > > > Otherwise, comments inline > > > > > > Regards > > > > > > Jon > > > > > > > -----Original Message----- > > > > From: christian@amsuess.com [mailto:christian@amsuess.com] > > > > Sent: 05 August 2020 15:25 > > > > To: mohamed.boucadair@orange.com; Jon Shallow (supjps- > > > > ietf@jpshallow.com); core@ietf.org > > > > Subject: core-block-04: Applicability and general remarks > > > > draft-bosh-core- new-block-04.txt > > > > > > > > Hello Med, hello Jon, > > > > > > > > here's a few concrete points I'd like to suggest for new-block: > > > > > > > > * Applicability: I'd have expected to read something like this > > in > > > the > > > > introduction: > > > > > > > > > The block-wise transfer of [RFC7959] covers the general > > case, > > > but > > > > > falls short in situations where packet loss is highly > > > asymmetrical. > > > > > > > > > > The new options introduced here provide roughly similar > > > features to > > > > > the Block1/Block2 options. They provide additional > > properties > > > that > > > > > are tailored towards the intended use case, and leave out > > > mechanisms > > > > > like non-atomic access and proxy support that would > > complicate > > > their > > > > > description. > > > > > > > > > > They are not intended for general CoAP usage, and any use > > > outside > > > > > the DOTS use case should be carefully weighed against the > > loss > > > of > > > > > interoperability with generic CoAP applications. It is hoped > > > that > > > > > experience gained with these options can go into future > > > extensions > > > > > of the block-wise mechanism that are both generally > > applicable > > > and > > > > > serve this particular use case. > > > > > > Jon> Thanks for the suggestions > > > > > > > > * Separation of layers, sub-topic "congestion control": It > > should > > > be > > > > possible to phrase all congestion control parts of this in a > > > dedicated > > > > section (which may also make sense as an appendix). > > > > > > Jon> Good idea > > > > > > > > > > > I'd avoid all other mentions of things like PROBING_RATE: For > > > example, > > > > Section 3.4 right in the middle of a paragraph on re- > > requesting > > > > missing blocks states that > > > > > > > > > The rate of requests for missing blocks is subject to > > > PROBING_RATE. > > > > > > > > Yes it is, but so is every single CoAP request until the > > client > > > hears > > > > back from the server. Repeating these things in places where > > are > > > not a > > > > new requirement may make it easier for some implementers that > > > try to > > > > build the whole stack in a single go, but even for them is > > prone > > > to > > > > the authors missing a spot -- and for everyone else this will > > > each > > > > time trigger the question of "is this new here or isn't this > > > already > > > > handled by a component two layers down the stack?". > > > > > > Jon> OK > > > > > > > > I haven't tracked every single retransmission and rate > > limiting > > > > statement throughout the document, but I expect that this > > > section > > > > could boil down to something like > > > > > > > > > For the DOTS use case, the following default CoAP parameters > > > are > > > > > updated to better reflect the typical deployments: > > > > > > > > > > * PROBING_RATE: 10 kilobyte/second > > > > > > > > > > The averaging process mentioned in RFC7252 Section 4.7 after > > > which > > > > > PROBING_RATE applies is not fully defined there. For the > > above > > > > > applications, a new parameter PROBING_RATE_WINDOW is > > > introduced. > > > > > Messages up to a total size of PROBING_RATE_WINDOW may be > > sent > > > > > before PROBING_RATE is considered, and the probing rate may > > > > > generally be exceeded by that amount of data in short term. > > > > > > > > > > * PROBING_RATE_WINDOW: 15 kilobyte > > > > > > > > (The latter replaces MAX_PAYLOADS, and I'm not sure whether it > > > is > > > > better to express this in terms of package count or bytes on > > the > > > wire, > > > > just giving an example here. All numbers in the above were > > > pulled out > > > > of uninformed air.) > > > > > > Jon> My leaning is towards packet count - circuit speeds cover a > > > Jon> significant > > > range. I need to think this through. > > > Jon> The default RFC7252 PROBING_RATE is too low in my humble > > > estimation > > > Jon> - a > > > large packet can cause long inter-packet gaps (300 bytes is a 5 > > minute > > > delay) > > > > > > > > * Separation of layers, sub-topic "Tokens": Same thing, next > > > layer. > > > > > > > > Whenever you're tempted to talk of a token, consider some of > > > these > > > > replacement phrases as a first step: > > > > > > > > * "MUST be sent with a new token" -> "is a new request". > > > > * "Tokens MUST be included" -> (nothing -- transports use > > tokens > > > by > > > > construction) > > > > * "MUST be sent with the same token as the response" -> "is > > sent > > > as a > > > > response to" / "is sent as an additional response to that > > > request". > > > > (Here it may make sense to refer to the tokens in an > > > additional " > > > > (which means it uses the same token, the same way an > > > observation > > > > response uses the requests's token for multiple > > responses)"). > > > > > > Jon> Agreed - Token references needs to be tidied up. Will work > > on > > > this. > > > "additional" may help us here to clarify which token 'value' > > should be > > > used where. > > > > > > > > * Naming: It's technically a minor thing, but people have > > already > > > > complained to me about how hard the Block[12] names are to > > > > comprehend, > > > > and introducing these options as Block[34] would not help > > here. > > > > > > > > I'd like to suggest QuickBlock-Block[12]. > > > > > > Jon> Certainly Block[34] are likely to transfer data more quickly > > > than > > > Block[12]. However xxxx [12] implies a replacement for Block[12] > > > which I am not so sure about. > > > > > > > > > > > (I know that this part of designing a new option is annoying. > > In > > > the > > > > interest of winding up with something that can be learned > > > easily, it > > > > is unfortunately essential). > > > > > > > > In connection with that, it may make sense to briefly think > > > about a > > > > draft name before it is submitted as a WG draft. new-block > > > sounds like > > > > a 7959bis, which in my understanding this does not aim to be. > > > > > > Jon> Good idea. > > > > > > > > * 4.TBA3 Missing Payloads: I don't quite see why this needs a > > > distinct > > > > code. 4.08 Request Entity Incomplete sounds perfectly suitable > > > to me. > > > > > > Jon> As we have to define the diagnostic payload as containing the > > > Jon> missing > > > blocks, we did not want to change the semantics of how 4.08 is > > used > > > - hence TBA3. > > > > > > Jon> That said, a 4.08 response could contain 1 or more Block3 > > > options > > > Jon> but > > > that would take up more space. > > > > > > > > If you think that sending an existing 4.xx code in the middle > > of > > > a > > > > block-wise transfer would cancel the transfer, there's still > > two > > > ways > > > > out of this: > > > > > > Jon> I was concerned about the 4.08 diagnostic payload changing > > > format, > > > Jon> but > > > yes, an 'unexpected' error code could terminate the transfer. > > > > > > > > * You're just defining what a block-wise transfer is; just > > allow > > > it. > > > > > > > > (In a RFC7959 block-wise transfer that runs over a proxy, > > the > > > proxy > > > > may be currently incapable of doing any forwarding and > > return > > > 5.03 > > > > Service Unavailable Max-Age:5. The client would then just > > > pause 5 > > > > seconds and send the latest block again.) > > > > > > > > * For all but the last block, it may also be an option to send > > > it as a > > > > payload to a 2.31 code -- I don't think that would be > > outright > > > > forbidden (and at any rate, all involved clients speak the > > > protocol > > > > anyway). > > > > > > Jon> I have an issue with changing the 2.31 reporting on the last > > > Jon> successful > > > block received - this currently fails if block num of 0 is missing > > as > > > we cannot indicate block num =3D -1 has been received. > > > Jon> If the last block is received, but a previous one was not, a > > > 2.31 > > > Jon> could > > > be used to re-request the missing block, but a 2.01/2.04 would > > need to > > > be held back for the final block acknowledgement. > > > > > > > > * The draft describes this all as "just working through a proxy" > > - > > > - > > > > original block-wise does not, and I'd like to hear how this is > > > hoping > > > > to get away without the options being proxy-unsafe. > > > > > > Jon> I was not aware of CoAP to CoAP proxy issues with BLOCK[12] > > > when > > > Jon> this > > > was written, but your comment implies that there is. Certainly > > CoAP > > > to other protocol proxies could run into issues. > > > > > > Jon> I was thinking of block by block proxying working and hence > > > could > > > Jon> be > > > proxy unsafe. > > > > > > > > Is there any point at all in using block-by-block proxying for > > > these > > > > use cases? Unless a proxy is sitting right inside the link > > under > > > > attack, and unless the bodies get huge, it may be way easier > > for > > > this > > > > to be purely hop-by-hop. Proxies would reassemble the full > > > bodies and, > > > > for the next hop, just decide what works best there (be it > > > regular > > > > block-wise, Block34 or BERT). > > > > > > Jon> Yes, there could be full body re-assembly and the full body > > > held in > > > cache if needed. This would add in a bit of latency. However > > this > > > would restrict a Block[34] possibility of supporting streaming of > > data > > > should that be required. > > > > > > > > (If there's a point in allowing block-by-block forwarding, we > > > can talk > > > > it through and work through the initial ideas that will come > > up > > > like > > > > "We use large enough Request-Tag values so they are unique", > > > "how > > > > large does that need to be", "why do we end up having a > > Request- > > > Tag in > > > > every request now" and "why do we not want that", but my gut > > > feeling > > > > is we won't need to go there.) > > > > > > Jon> For Block3 which would use Request-Tag, I would expect that > > for > > > a > > > specific body of data for a specific resource the Request-Tag to > > > remain the same - and if the body changes a new Request-Tag is > > used. > > > Jon> As this is the same Request-Tag for whether the whole body is > > > Jon> cached, > > > or individual blocks of the body the Request-Tag usage will not > > > change. > > > 2^32 should be large enough - 2^64 even better - but re-usage has > > to > > > be generally considered. > > > > > > ~Jon > > > > > > > > Kind regards > > > > Christian > > > > > > > > -- > > > > 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 > > 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. > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=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 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. >=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 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 Sep 29 11:14:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF9F3A122F for ; Tue, 29 Sep 2020 11:14:49 -0700 (PDT) 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 4vSMES7Gf6J6 for ; Tue, 29 Sep 2020 11:14:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1964C3A122E for ; Tue, 29 Sep 2020 11:14:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 355D7389D4 for ; Tue, 29 Sep 2020 14:19:40 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LshhVoPVYGg8 for ; Tue, 29 Sep 2020 14:19:35 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C769389CF for ; Tue, 29 Sep 2020 14:19:35 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C6B90AAD for ; Tue, 29 Sep 2020 14:14:41 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] issues for stateless AD review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 18:14:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable With Klaus' blessing, I have turned the remaining DISCUSS points into issue= s. I list them below. I will begin posting them to the list for discussion in an hour or so along with some proposed changed text (pull requests). Barry: Quite a number of points were already dealt with, but we need confir= mation from the AD that they were dealt with. If needed, I can collect tho= se into an email. It seems that all of the comments from Roman were dealt with, possibly with the exception of issue 9 ("look ma, no state"), which seems like a "wontfix= ". Roman had cleared his DISCUSS. The second DISCUSS was from Erik Kline. Here is the list of issues. The titles are mine. #3 is stateless updating 7252 on distinguishing unrecognized vs invalid ex= tension? https://github.com/core-wg/stateless/issues/3 #4 how does freshness window of client/intermediate interact? https://github.com/core-wg/stateless/issues/4 #5 lack of integrity protection results in spoofed responses https://github.com/core-wg/stateless/issues/5 #6 can larger tokens fill responder memory? https://github.com/core-wg/stateless/issues/6 #7 how to size the replay window? https://github.com/core-wg/stateless/issues/7 #8 use automated key management due to AES-CCM/BCP107 https://github.com/core-wg/stateless/issues/8 #9 look ma, no state! https://github.com/core-wg/stateless/issues/9 #10 60 minutes for address change https://github.com/core-wg/stateless/issues/10 =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9zeZEACgkQgItw+93Q 3WUy0Af/YTblkdaX8AZYBzFGD/ZG51eu0ZFVtqU/UBkDgjHBDCnPJbu3lzxvHLhg ZQ/nQTeGXL+zTb7uvurop7FY35kQApWPilUISPOKmzXI7LDrP4VSZ6eBfVng4Gsg XZ8p8dWilGAdwg3pidAV0wj9xcq0bxT43EgrOI4hiy80kjGLioGRadKqgJZzfqQY w7FjcQA2QQq2yqfcpKVsmCZ7+QidFxDycoqiu6xKiLmoTq+65sDZM5TOxgPG5Snw QLn7gJJMqUphDf2aXArorplHS6d4enm+vW/FQqTV0ZLNYxuxaEtgqIk6epuKh1Bk HLev5LuPRAbyI+gyYZ0A8cQXRTCi0w== =I1j7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 29 13:45:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710823A1183; Tue, 29 Sep 2020 13:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 oRL3J4s1aP_o; Tue, 29 Sep 2020 13:45:41 -0700 (PDT) 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 4AF663A1184; Tue, 29 Sep 2020 13:45:39 -0700 (PDT) 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 08TKjX3P026722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Sep 2020 16:45:36 -0400 Date: Tue, 29 Sep 2020 13:45:33 -0700 From: Benjamin Kaduk To: Klaus Hartke Cc: core-chairs@ietf.org, The IESG , "core@ietf.org WG" , draft-ietf-core-stateless@ietf.org Message-ID: <20200929204533.GY89563@kduck.mit.edu> References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> <20200503224625.GF27494@kduck.mit.edu> <20200509020128.GD27494@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200509020128.GD27494@kduck.mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 20:45:44 -0000 Hi Klaus, If I understand correctly, all the remaining discussion threads have come to a resolution. Can you prepare an updated I-D so that the Discuss-holders can confirm on the final text, and the document proceed to publication? Thanks, Ben On Fri, May 08, 2020 at 07:01:28PM -0700, Benjamin Kaduk wrote: > On Mon, May 04, 2020 at 07:40:39PM +0200, Klaus Hartke wrote: > > Benjamin Kaduk wrote: > > > Klaus Hartke wrote: > > > > Benjamin Kaduk wrote: > > > > > Section 3.1 > > > > > > > > > > o A client SHOULD integrity protect the state information serialized > > > > > in a token, unless processing a response does not modify state or > > > > > cause any other significant side effects. > > > > > > > > > > If the intent is that the "does not modify state" clause is the only case > > > > > when one would disregard the need for integrity protection, "MUST [...] > > > > > unless" seems more appropriate. (I would prefer unconditional MUST and am > > > > > not sure I understand the cases where there is a need to skip integrity > > > > > protection.) > > > > > > > > The intent here is that a client must do integrity protection, but > > > > there may exist valid reasons in particular circumstances to ignore > > > > this requirement. In this case, the full implications must be > > > > understood and carefully weighed. > > > > > > > > All of the circumstances that come to my mind here are those where a > > > > modified token doesn't actually hurt. For example, if a client sends a > > > > request to some server at regular intervals, it might only be > > > > interested in whether the response has an error or success code and > > > > not even deserialise the token. > > > > > > > > What's the best way to capture this? > > > > > > Before I get into suggested text, I want to check that I understand the > > > situation properly -- in such a case where the client is not even > > > deserializing the token, why would the client not be able to use a regular > > > token and not look at that token's value? It doesn't seem like the client > > > is gaining anything from having the serialized state available. > > > > > > Your description makes it sound like we may have to just do "SHOULD > > > integrity protect" without the "unless [...]" clause. > > > > Hmm... the top-level section is about clients that avoid keeping > > per-request state, which a client can be regardless of whether it uses > > <=8 byte tokens or >8 byte tokens; but this sub-section talks about > > serialized state, from which indeed the client doesn't get anything if > > it's never deserialized... > > > > Maybe the best way forward is indeed to use SHOULD with the "unless > > [...]" part... If we change to MUST, then I can already anticipate > > people complaining that in their particular use case any integrity > > protection is just wasting precious bytes. The SHOULD would take care > > of that. And maybe we don't have to go into detail under which > > circumstances it might be justified to ignore this SHOULD. > > > > OLD: > > > > o A client SHOULD integrity protect the state information serialized > > in a token, unless processing a response does not modify state or > > cause any other significant side effects. > > > > NEW: > > > > o A client SHOULD integrity protect the state information serialized > > in a token. > > > > > > > o Even when the serialized state is integrity protected, an attacker > > > > > may still replay a response, making the client believe it sent the > > > > > same request twice. For this reason, the client SHOULD implement > > > > > > > > > > (Basically the same comments about "SHOULD".) > > > > > > > > See above. > > > > > > > > This section is about protecting the serialized state, but of course > > > > the requests and responses need to be protected as a whole as well > > > > (e.g., using DTLS or OSCORE). In some circumstances, receiving a > > > > replayed token might not hurt if the client can verify that the > > > > response is coming from the right server. > > > > > > Presumably the same cases where a replayed response from the right server > > > would be tolerable? Such cases are ... rare, in my opinion. > > > > OLD: > > > > o Even when the serialized state is integrity protected, an attacker > > may still replay a response, making the client believe it sent the > > same request twice. For this reason, the client SHOULD implement > > replay protection (e.g., by using sequence numbers and a replay > > window), unless processing a response does not modify state or > > cause other any significant side effects. For replay protection, > > integrity protection is REQUIRED. > > > > NEW: > > > > o Even when the serialized state is integrity protected, an attacker > > may still replay a response, making the client believe it sent the > > same request twice. For this reason, the client SHOULD implement > > replay protection (e.g., by using sequence numbers and a replay > > window). > > > > Does it look OK without the "unless [...]" parts? > > I think so (for both cases), though some note about it being impossible to > implement replay protection without integrity protection (while still > avoiding per-request state) would probably still be in order. > > Thanks, > > Ben > From nobody Tue Sep 29 14:16:46 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5223A11C9 for ; Tue, 29 Sep 2020 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRKkGOq2e5XP for ; Tue, 29 Sep 2020 14:16:42 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0883A0EE0 for ; Tue, 29 Sep 2020 14:16:41 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4C1Byt14SSz101g; Tue, 29 Sep 2020 23:16:38 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_0D4EACF3-51B1-44DC-817F-782BB849DAC1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <30317.1601403281@localhost> Date: Tue, 29 Sep 2020 23:16:37 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 623106996.692935-3308efc051e216e70dc9f79de1506343 Content-Transfer-Encoding: quoted-printable Message-Id: <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> References: <30317.1601403281@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] issues for stateless AD review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 21:16:45 -0000 --Apple-Mail=_0D4EACF3-51B1-44DC-817F-782BB849DAC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2020-09-29, at 20:14, Michael Richardson = wrote: >=20 > With Klaus' blessing, I have turned the remaining DISCUSS points into = issues. (And I sent some comments.) Overall, I think we should generate I-D text for: #10 60 minutes for address change https://github.com/core-wg/stateless/issues/10 #5 lack of integrity protection results in spoofed responses https://github.com/core-wg/stateless/issues/5 We should replace confusing I-D text here: #8 use automated key management due to AES-CCM/BCP107 https://github.com/core-wg/stateless/issues/8 I think we can simply explain a wontfix on: #3 is stateless updating 7252 on distinguishing unrecognized vs invalid = extension? https://github.com/core-wg/stateless/issues/3 #4 how does freshness window of client/intermediate interact? https://github.com/core-wg/stateless/issues/4 #6 can larger tokens fill responder memory? https://github.com/core-wg/stateless/issues/6 #7 how to size the replay window? https://github.com/core-wg/stateless/issues/7 #9 look ma, no state! https://github.com/core-wg/stateless/issues/9 Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_0D4EACF3-51B1-44DC-817F-782BB849DAC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEcr05t4NZlx5Xee/8VkscnDT509sFAl9zpDQACgkQVkscnDT5 09sSdg/9EQcjoPK9zx/wLqDDt3xC+V1wqcj6To984sogEGCv7vaAJqsZS/gbmQwa /Fbitv+/sf1hCcbOemX479Juqw0tz8xMFJ6bN8hA2R9v+JYyWYQ+Q/V7pgUWaXgu /rcIuqv8Cz8qpm4orzMkab9tBN0LaFCQggj/wOlS3t6xiZgZUtwKrpyZ2EGAuKG5 5aeBTokQsK4qfz88YX6o5rTBViQ0bymRfEXSQRPll7HH+WDj5v5l4YbXSwx0cf6a U0ZkOW8RnqQU1NQlEri+RDBaYkev9nvtEfMWc2uVLuNR1iVKSttIZkHmnHpjxIWF TfsE2FjSpr2mn/woAVFbHY95bFhE5HU5wEfMCfuAYeXQGHvNM/oYAosjoyRfVseE WKJDTAf7gdGFc1UIdEZ3P0SmQ2wvR+WqS+8jGS0VUGSpH1uCQ5lq19mIBMLaHEA9 PvIbZGPWCN4RkzuCz88gsUqjjQRxyNZldmY+9T6CkGFFffOBIqRBkFWf+eeXnmR9 Zf8Z6PGtr0ELXA+Z+8A2N5sYB32zOBPaYjnWsOit8oNbecCcHHrOYIcUKSzpLiWd SRP2jTNznWnPoBWkSfq853nmAweIe8vwB8xQ79RD6/YL3Y3ElLfc3A8Q/05gH5bd rl5E+onRL5L775zXS4rA8OIvH28IjwygnSRyhen31kTWJNwnp8s= =P3gM -----END PGP SIGNATURE----- --Apple-Mail=_0D4EACF3-51B1-44DC-817F-782BB849DAC1-- From nobody Wed Sep 30 08:34:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63D53A0ABE for ; Wed, 30 Sep 2020 08:34:32 -0700 (PDT) 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 WWW8XyHTwd54 for ; Wed, 30 Sep 2020 08:34:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E00A3A0AB4 for ; Wed, 30 Sep 2020 08:34:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A2FAB389E7 for ; Wed, 30 Sep 2020 11:39:25 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L0gLxUxr72PW for ; Wed, 30 Sep 2020 11:39:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4B754389E6 for ; Wed, 30 Sep 2020 11:39:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4FFD24CC for ; Wed, 30 Sep 2020 11:34:28 -0400 (EDT) From: Michael Richardson To: core@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [core-wg/stateless] Shorten abbrev (#2) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 15:34:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > https://github.com/core-wg/stateless/pull/2 When I formatted the core document with the latest xml2rfc, it complained that the abbreviation token (which goes on the top of each page, when RFCs = had pagination), was too long. I tried to make up a shorter one. It's real bi= ke shed argument. The RFC editor does not paginate RFCs anymore, btw. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl90pYQACgkQgItw+93Q 3WXilggAvSuAFenE3bQCEIYIwg5AWNqy5MgwAen8oKHz3B36S//JCk2O4WH3KTCt M3+DB4ju1OMGf4SEC+J7lMgiMmDbemEguvLteoeQqAPkLxyS+8/OmxOe6kaMbF27 Bp54wwF6fCGs0lxJ7XLakA/zpJD1JiqBwUXq247Nvu0jh3YDTA0KzdkJK1tPIssg S87b0X5BIpnKs4ZwBFw79fJqOnYslTAFRGzEUwyzV2i0KhvW6au6CyNPyTcC4w7g 76/Kmz2ql02UBxvK9tH9MKmNjLreR0a8MQArhDJ9jF1cqV08Vmp4UMlAYy/O6aYz +CcstWEd2xzidTsSPVSReUpTzCvSkw== =v6r+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 30 08:49:18 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926633A0ABE for ; Wed, 30 Sep 2020 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IewFHVRPEHX5 for ; Wed, 30 Sep 2020 08:49:12 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C3E3A0843 for ; Wed, 30 Sep 2020 08:49:11 -0700 (PDT) Received: from [192.168.217.124] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4C1gfY5VSFzySY; Wed, 30 Sep 2020 17:49:09 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8A26F5C0-0356-4F70-BF93-7B8C02EB2619"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <15780.1601480068@localhost> Date: Wed, 30 Sep 2020 17:49:09 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 623173748.865465-0f38846223c52f130b9fba5c1aecfe51 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15780.1601480068@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [core-wg/stateless] Shorten abbrev (#2) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 15:49:17 -0000 --Apple-Mail=_8A26F5C0-0356-4F70-BF93-7B8C02EB2619 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2020-09-30, at 17:34, Michael Richardson = wrote: >=20 > Signed PGP part >=20 >> https://github.com/core-wg/stateless/pull/2 >=20 > When I formatted the core document with the latest xml2rfc, it = complained > that the abbreviation token (which goes on the top of each page, when = RFCs had > pagination), was too long. I tried to make up a shorter one. It's = real bike > shed argument. I was reacting to =E2=80=9Cstateless client state=E2=80=9D, which is = probably not what Klaus was thinking :-) > The RFC editor does not paginate RFCs anymore, btw. (Only the PDF versions, but there is plenty of space for a header = there.) Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_8A26F5C0-0356-4F70-BF93-7B8C02EB2619 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEcr05t4NZlx5Xee/8VkscnDT509sFAl90qPQACgkQVkscnDT5 09uZjQ//dCj1zeP1SnjUGXc+YX8Xajyy16mSkciXLk6pPCKDhk2bWmXvgLPpPC/6 sabu2UwgApJba4o5T0i7TbwvlBie2p4rFyGzkZ0lahG8MPuZObrlnxgVZVUuybWE UUFmSp6I2s15cRh8F5OyEOXWGZpBm9cIzeSPKXUs/wB74v7QfggzmLsttFSb8I5S Ou+4r6o+NqU3crAe/H7JZaiIytm2cbsLU6rBiXYsz4bECvHw9Hda2PVKgFtqiF6d Ofqp+ZGyyp7ijllrB8XHFeaV7NBaNaMSuAcxBdrxyCjGQS2c4y8WzZBAHO3FfNED S/HLP6EUoz1cV33/MYlI4hqhO6i0N2G3XmAB02l2L/ZGyk/q2DVQHldhQR8JnC9w ES9EDCkHYg/nOMwGgo9BQ4kHZ+MsJttIzVobqoiSupJNUseqMAgJ+la86DggJrp9 XIjcmiL8VB2a4a747HIrwNoYV8Xbuz3i8cQz91TOAix0+K6ATMMy4siNQNP+/PxM AWS0HKIIROLRRViwm7ivYzGLitVlxKVnBWXJh1ynelqM31iqd3b6NE8OBU5Dcn3F VxIN9Eg70TVjJanqf4bzJj1C+fmQzWRyFMBB1HVH0/naTaHEj7dAMgsmbJLKe0/3 IfN4ShtUle0SqbhDRrCph1fX0QxBa28TXF287NLEOEsU7exq4D0= =8Fdj -----END PGP SIGNATURE----- --Apple-Mail=_8A26F5C0-0356-4F70-BF93-7B8C02EB2619-- From nobody Wed Sep 30 09:30:27 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942C93A0B38 for ; Wed, 30 Sep 2020 09:30:16 -0700 (PDT) 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 n-YzHdHv3OPJ for ; Wed, 30 Sep 2020 09:30:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F17F3A0B50 for ; Wed, 30 Sep 2020 09:29:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D061389EA for ; Wed, 30 Sep 2020 12:34:42 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UqBH9EOQfo2h for ; Wed, 30 Sep 2020 12:34:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 841FC389E9 for ; Wed, 30 Sep 2020 12:34:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6A3701D5 for ; Wed, 30 Sep 2020 12:29:44 -0400 (EDT) From: Michael Richardson To: core@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] stateless: pull request #11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 16:30:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think that the reference to RFC4107(BCP107) is in error in my opinion. That document deals with systems like IKEv2/TLS/etc. The key in question never needs to leave the device. The key needs to be rotated, but there is really no need for more than a random number generated. The concern about the nonce-reuse is real. A sleep node that can not maintain a counter to make sure nonces are not reused could generate a new key during each wake cycle, if the responses are not expected to span sleep cycles. (Did the term "drowsy" get into some terminology document? I recall a discu= ssion) https://github.com/core-wg/stateless/pull/11 =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl90sngACgkQgItw+93Q 3WXTPggAjcA54aFs0vMZMkRy6SHOfyIhv+dQ//lry6aaztlbLQ+LH7MNe3GOfEXH o0CwRfWcsNBlJIWLErn3N5Vue1Qv3tegUNpXexQRI+nOkVQ03KV+umqgo3UaSg+b PH9rRyqQs8wWdi0yzXNS+s6BHb9tZPanM9weMzuyOK0MlhArvnqBvo1uWdZVm/Ij uY+zBQCGfVxtg/bg/xIprk3PAhGHSKQp4eIHCm7E1OkkrRA0ilAXtnfcZvfcUIrq e0Vbg5G46II97LKEvbKpD7gW4ZS+hslyd9sv6Xs/XP6MJxE76QQDz6M4XBPgTdxa 8EIAp4wzsschF+ycxeSJBYoOsKahyQ== =GQzV -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 30 11:47:26 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC653A0AB6 for ; Wed, 30 Sep 2020 11:47:25 -0700 (PDT) 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 3D5abQs7ywv9 for ; Wed, 30 Sep 2020 11:47:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D36B3A0AB5 for ; Wed, 30 Sep 2020 11:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C5D5389EA; Wed, 30 Sep 2020 14:52:19 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3wRhniYiptHE; Wed, 30 Sep 2020 14:52:18 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D0A09389E6; Wed, 30 Sep 2020 14:52:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5BF854CC; Wed, 30 Sep 2020 14:47:20 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , core@ietf.org In-Reply-To: <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Wed, 30 Sep 2020 14:47:20 -0400 Message-ID: <29736.1601491640@localhost> Archived-At: Subject: Re: [core] issues for stateless AD review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 18:47:25 -0000 Carsten Bormann wrote: > We should replace confusing I-D text here: > #8 use automated key management due to AES-CCM/BCP107 > https://github.com/core-wg/stateless/issues/8 I have created pull request #11 for this. Please comment > I think we can simply explain a wontfix on: > #3 is stateless updating 7252 on distinguishing unrecognized vs invalid > extension? https://github.com/core-wg/stateless/issues/3 > #4 how does freshness window of client/intermediate interact? > https://github.com/core-wg/stateless/issues/4 > #6 can larger tokens fill responder memory? > https://github.com/core-wg/stateless/issues/6 > #7 how to size the replay window? > https://github.com/core-wg/stateless/issues/7 > #9 look ma, no state! https://github.com/core-wg/stateless/issues/9 -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Sep 30 14:50:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319113A0C1D for ; Wed, 30 Sep 2020 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGXfVd5pRNbg for ; Wed, 30 Sep 2020 14:49:55 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EC23A0BBE for ; Wed, 30 Sep 2020 14:49:55 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4C1qfn2YXyzyTK; Wed, 30 Sep 2020 23:49:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <29736.1601491640@localhost> Date: Wed, 30 Sep 2020 23:49:52 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 623195392.788475-292a88cd757dadbbf2ae3169abd3ab45 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30317.1601403281@localhost> <99764840-E759-40AF-A80D-1E5F4984C334@tzi.org> <29736.1601491640@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] issues for stateless AD review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 21:49:58 -0000 On 2020-09-30, at 20:47, Michael Richardson wrote: >=20 > I have created pull request #11 for this. > Please comment A couple typos (pushed to the PR branch already) and two comments: https://github.com/core-wg/stateless/pull/11/files Gr=C3=BC=C3=9Fe, Carsten