From nobody Mon Feb 1 03:15:06 2021 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 704173A0D95; Mon, 1 Feb 2021 03:15:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <161217810393.10174.7685994113173461096@ietfa.amsl.com> Date: Mon, 01 Feb 2021 03:15:04 -0800 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-resource-directory-26=3A_=28with_COMMENT=29?= 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, 01 Feb 2021 11:15:05 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-resource-directory-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. As you can noticed, I have cleared my 2 DISCUSS points (kept below for archive) thank you also for replying to my comments over email. BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram ! I hope that this helps to improve the document, Regards, -éric == cleared DISCUSS (no more blocking, kept for history) == -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if address is configured via SLAAC, DHCPv6 other-information can be used to configure the Recursive DNS Server (or possibly the RD). -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is this RDAO sent ? I guess unicast Router Advertisement but this MUST be specified.== COMMENTS == In general, I wonder how much interactions and exchanges of ideas have happened in the long history of this document with the DNSSD (DNS Service Discovery) Working Group that has very similar constraints (sleeping nodes) and same objectives. -- Section 2 -- To be honest: I am not too much an APP person; therefore, I was surprised to see "source address (URI)" used to identify the "anchor="... I do not mind too much the use of "destination address (URI)" as it is really a destination but the anchor does not appear to me as a "source address". Is it common terminology ? If so, then ignore my COMMENT, else I suggest to change to "destination URI" and simply "anchor" ? -- Section 3.3 -- Should the lifetime be specified in seconds at first use in the text? -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to use the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited later. Please expand and add reference for 6LBR. Using 'modern' technologies (cfr LP-WAN WG) could also add justification to section 3.5. -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is the value of MCD1 ? The IANA section discuss about it but it may help the reader to give a hint before (or simply use TBDx that is common in I-D). Any reason to use "address" rather than "group" in "When answering a multicast request directed at a link-local address" ? Later "to use one of their own routable addresses for registration." but there can be multiple configured prefixes... Which one should the RD select ? Should this be specified ? As a co-author of RFC 8801, I would have appreciated to read PvD option mentionned to discover the RD. Any reason why PvD Option cannot be used ? -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in order to be able to use a lifetime in units of seconds (to be consistent with other NDP options). -- Section 5 -- May be I missed it, but, can an end-point register multiple base URI ? E.g., multiple IPv6 addresses. -- Section 9.2 -- For information, value 38 is already assigned to RFC 8781. == NITS == -- Section 2 -- The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only. From nobody Mon Feb 1 03:16:17 2021 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 3B2A93A0DC4; Mon, 1 Feb 2021 03:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Mq6ueZGy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CigwjPB9 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 X50tg7nP0HOg; Mon, 1 Feb 2021 03:16:12 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544EC3A0DC2; Mon, 1 Feb 2021 03:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13404; q=dns/txt; s=iport; t=1612178172; x=1613387772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rc7n/biAdqiV0Bu2/kO75y4t19E2I482VyipQgcJfaA=; b=Mq6ueZGylmPq0TBI8NXdVyJZmQj8wuUx1n4u2HanSLj2RthEsg29gPaQ NLydx2LWwmA+eiAaqrnT3qU7KR9cB5d0iZBt0RXQO0ez/hPuT0vWMMyao 9vxKf4qcbL6GzX7S+6u/kuH1XBcPkOxzkciCf0FUouS3ylsHRDuQL2yg4 M=; X-IPAS-Result: =?us-ascii?q?A0D+BADx4RdgkIQNJK1YCh4BPAwCCxWDIlF9WjIxhECDS?= =?us-ascii?q?AOOCwOBBYkYhHaKBoFCgREDVAsBAQENAQEjCgIEAQGESgIXgWECJTgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhgsBBScNhXMBAQEDASMRDAEBNwELB?= =?us-ascii?q?AIBCBEDAQIDAh8HAgICHxEVBQMIAgQOBRSDEgGCVQMOIAEOpQYCiiV2gTKDB?= =?us-ascii?q?QEBBoEzAYNpDQuCEgMGgQ4qgneEBYIyhBAmG4FBP4ERJxyCITU+ghtCAoEqA?= =?us-ascii?q?QcKAgEIgzGCYIFZcQEBPCYEGBcUEAQcAi4IBBcIChN6AmADj1aCZQFApGRaC?= =?us-ascii?q?oJ2iTSHAYUlCHaFJQMWCYMvij2Fao89hHaaWIJ/jnQYAYQ3AgQCBAUCDgEBB?= =?us-ascii?q?oFtIWlwcBVlAYIKAQEyUBcCDYR2hlKCZQ4JFIM6hRSFRHQ3AgYBCQEBAwkBe?= =?us-ascii?q?4o6XwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A5vt39BTKqds7W23ptHotpkh5eNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNWJ4vdflufNqObrXmlTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBq3ip8DMJAV?= =?us-ascii?q?P0Mg8mbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,392,1602547200"; d="scan'208";a="658802333" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Feb 2021 11:16:09 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 111BG8WY004964 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2021 11:16:09 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Feb 2021 05:16:08 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Feb 2021 05:16:08 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 1 Feb 2021 05:16:08 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a6u3OOl9g1pg4jyUve/Vns3VSEh28t7kfYW7Sez8cUIWjSOk8t/5X43BfpVuQq4cPuPkT5iXkqT+p/n4pmUNNj7jW4ypr/eUy8skwMwIhQlEusSme/JbedrCSoVWk0MhB8DeCUNj9MpnHxrbNhyKJqbOLM/4XwS0UY2kwRw356+fQuYujIDFNMALF58O2lQgbgn4KK4TTmlCoJq9ykmNAfOZdEl2SlERRSFAV2KZf6fpQEAgj9D0hfLxurNzeDmW5yvWdU+ts7QjWDtPFSbZU4S0DnsMCR44zznAHRlloejiROe9LAc+BsoCpyy3+TpY9zNsIX04MjJ5Fqltop5MaA== 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=Rc7n/biAdqiV0Bu2/kO75y4t19E2I482VyipQgcJfaA=; b=FT0ILy47JuokFvPaSyEzz/CrvqTEro9AjKESNnqhHmfdfRmLJN0dKhLlb55Kxd4tOlqTOMwzzwFUCGUqKKP96d0fTWKkSOKRVE91Qj+tc45egMEyYxVKEl2f/UF0FeOrRdAkElQweOcAhrQaFj0W1Sav98G4vwAWIZ/1a22JXYwnp3grjd+wB5CNqDLrNTNEZzDUb80At0a2QHLcxIoKwI3QkgJX+RII0VwrChT9+p4Cu4vlIdmXtP1GZCyR8cGevhCuNBeyFnv9/UtXBvesgPaT0E1CxzI2YwBlUA0eRFsXX/1wxAdP5jkkP2Vo9xQNzTqySFFRTanu1FrjWoBjjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rc7n/biAdqiV0Bu2/kO75y4t19E2I482VyipQgcJfaA=; b=CigwjPB9yKYkQT31P9YmDa9Eg/fR1kRTQWxcj3DmiJeSWNmuhpjLhRduz4RVWwW0/t/Nhx56FEIQC+5m4256xn1QYd3D1rGIT71T/cN0EAfzpacpkQzhF1jT26m7WozYjADHTRBd+myjz2ZhRrZeHpcfEINLL5pr9xjJsiU/Zgk= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4855.namprd11.prod.outlook.com (2603:10b6:510:41::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.17; Mon, 1 Feb 2021 11:16:07 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3805.025; Mon, 1 Feb 2021 11:16:07 +0000 From: "Eric Vyncke (evyncke)" To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "jaime.jimenez@ericsson.com" , "core-chairs@ietf.org" , "bob.hinden@gmail.com" , "draft-ietf-core-resource-directory@ietf.org" , "otroan@employees.org" , The IESG , "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1j?= =?utf-8?B?b3JlLXJlc291cmNlLWRpcmVjdG9yeS0yNTogKHdpdGggRElTQ1VTUyBhbmQg?= =?utf-8?Q?COMMENT)?= Thread-Index: AQHWsgch37Pl2Z5gw0GeIHVFjkwUD6pDw/kA Date: Mon, 1 Feb 2021 11:16:06 +0000 Message-ID: References: <159661278180.30518.10421410106159995546@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103173035.GG45088@hephaistos.amsuess.com> In-Reply-To: <20201103173035.GG45088@hephaistos.amsuess.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:5519:2ec5:5fc1:c2e0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38e989bd-82a9-46f5-a09e-08d8c6a2c560 x-ms-traffictypediagnostic: PH0PR11MB4855: 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: QH1bujmmmiTkedw9ItyZqrOTWomnxwWXtKBKhAkj9jmucnYKDvuBCz3sW+VUl2PgM7fGIjylFA8pVeBidzsiuksYx4f+gHZG58n4YUzDXEhompkaJ93AxfDBFuWtD0e4dwSlJ56BYwjXATLS2s2a3Lldqx76R8nS9TNy1qeqTjkov2cy74Z0ufTUd6ECrooLoaLn9gGAcGo4TfXgURmlKhyI8//uJLd31wP8d2ja/RXmU9wDscGrt8z5mjcqVI3pJaeFK7D3dEPdDlfT4OQIK3ofZia4VK1o0Kroxwz+glvXMXw/xA7h+kAI8oMcOBPKwYfRL84Jm9QplEvSvabisFcjPI0VvStcI4ei0jCRS0r5Wi1AXNBGGFJkz/vH9seoYs3nY1sEqRN93kCvr12xocpmuiW4Rc4K6C4XAosVhyeIm5AaijopjoqbqfutnfPqHNMp1ksFCm/oEm/RoJcyLbLs+aou9fEO6TlSJPjE8nJIST73SmclMgD0+hhxdNKqI0MdCaTZHG5sxNhOPu4IfqRjTU6ZVseHayIWiXroX18kJqBeQdqsOabYky31tLIUc3mRoGhZIqyLjYhNYEimSEcAOwGLVQVm62qiwftX9y7rlS4lLXhD3OvH1GfrK4oQjRVOviHoZIbg6y/DuGrhbw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(39860400002)(366004)(396003)(8936002)(33656002)(66446008)(6486002)(64756008)(91956017)(6512007)(6916009)(66556008)(76116006)(66574015)(66476007)(316002)(83380400001)(66946007)(54906003)(5660300002)(71200400001)(966005)(86362001)(4326008)(224303003)(36756003)(2906002)(186003)(53546011)(6506007)(2616005)(478600001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?YkhJZ0o5N09MUUhWekJpNFpOZmwvVDY0M1BTTGVPUGhzRzA3bStsOGZsV1ll?= =?utf-8?B?VWFXTnU2aForMEZ6T0xpRWg3Tkw2OG9meTVnZ3dVTUMrajA1a0tpY2VwMXor?= =?utf-8?B?bjcyVFJTSFh4OFZkcm9acUtCbDRqYkFVWDN3d0pjdytpNFVxME9YY1JMZXd3?= =?utf-8?B?Q3YyaXhMR3VoUWdKUlpneTlEc2xzcWxBWE5EZTZGNnlBM1dxS1Y5ak9QMkQx?= =?utf-8?B?eGRmUVk1b1RmWTdsUmVrQ3RQWE51aXB0eGlvMTNJVk1salFCdDc5Q2haZ3RN?= =?utf-8?B?MjVUK1Y3TE8ybGVpa3dQeTlGait0NWpsK0xPbUxJNXE2UGN3NUU3eU5KVFkz?= =?utf-8?B?aElqWW9EQStsWW5oZzNNeENhVS9FZENiY2VTS1RrRm5QMHpUT2lPdC9GQTkw?= =?utf-8?B?OVFSSzBkL3JEb1p4aEx4Q0hqRWtianVXUUh6WElRMHRWaG1oUEVRYzF3Vklz?= =?utf-8?B?bkRvUGJuR1ZXLzVWaExCWnptOXgvTmo3UkhHQUlvWDlwWlhlRityei9pY2o4?= =?utf-8?B?VkJnTnl5aGVBb1NnY3BIM0lPelRPb0Q4YXhIWEJmcjQ1QWVyQnoxckxvTGpF?= =?utf-8?B?N2tBQmZIT2duRVNSK3Fqenc0VjFjODF6bkJ5TVpsOXlqdkpaNDhqOEh6QUpR?= =?utf-8?B?UHpnY3lPYVVmVDZXZkNYc0tVVHNObkdVZmU0dmZIWVFLZUhWRW15WVluSUw2?= =?utf-8?B?TTZjT1VkblBtb2ZUTUZBK2t6VkUrU1RTSFJjUFVYTzU3eVBoak1UbkY4aUNK?= =?utf-8?B?ZWRHZVBxY2R4V0xVVkVFN1E3bTRsVFVlb2hiSHZzTHhsSngzbEJVbnlzd0E3?= =?utf-8?B?Z2E5RFVFNVU5UGlsNnRoc09VK3g5ck1pZXFlbGtPZ1BGYnZNN3BqZ1UyK0sx?= =?utf-8?B?MHVCcGsvbTFVSlBVcEFhL2dPVWFxcSs2c240RTRXaVVrSkd0M3Z4ZmFuMWNU?= =?utf-8?B?SU5OM1lMdEZtdWJhRnU3aUJHN0pSSzJxYUg4UnUrNnA3bFFPeWZXTW5jNVl2?= =?utf-8?B?S1NmZXFxbmhyU0JMNVpQcE95VmVqUkZzYi9Ic0VNbUV3WGY4SEtueWhOeTdB?= =?utf-8?B?YkZCY3oyaVBEa1hscHFyWFVYendqUkVveG5yMVludXZWRGprM2tVOXRqd3Vp?= =?utf-8?B?NW5NQkE0VHN1cm90ZGFHWklZaDFEcERsZjdGaldya0EvZU82RElNZFV1K2Jj?= =?utf-8?B?YzJqR2UrOEM1T1RwaXBLRHdNcUl6VVJmamxPT0dSSjhiNVZhVWU3SDRQSFhM?= =?utf-8?B?ZWhRUkt1NHU0bnRzYXZLZDdLeUt4WERwQ0ZGMUp6WFAwN0g3UW93Z3FrNmZi?= =?utf-8?B?b2hFd3VGMG1IY3hpcGdUQmdsalkwY0NYSHVLSE9MVVAyNnhVSlA4RDJheW91?= =?utf-8?B?U2gzZ0xacnE0Q2huRFlzZWpzTmdRRld6UGErOVBOWGpXTzQrb3ovcUV3Ti9I?= =?utf-8?B?KzBlbnZjVjRVUEVHVWk0L3FCMnZsSnkxUlYwOEFuMXhXQUFPT1FoZ1Urbk1F?= =?utf-8?B?aENvN01DdmhBWWkzSFF1SjhFaFRFeGxQbFFEQjMxVk5WUC8wcGJEdkk3cjlV?= =?utf-8?B?cmNDdz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 38e989bd-82a9-46f5-a09e-08d8c6a2c560 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2021 11:16:06.9927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GH/7gVMKKhNj4wgv31omtWEvMbOpulFZZIj7rqc75m636dMyBMLa3IgVjgyvtdxHz5wGkWisQX8bYwrt/lK9HA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4855 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-resource-directory-25=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 01 Feb 2021 11:16:15 -0000 Q2hyaXN0aWFuLA0KDQpQbGVhc2UgYWNjZXB0IG15IGFwb2xvZ2llcyBmb3Igbm90IHJlcGx5aW5n IGVhcmxpZXIuLi4gQUQgYXJlIGp1c3QgaHVtYW4gYmVpbmdzIHdpdGggc29tZXRpbWVzIGFuIG92 ZXJib29rZWQgYWdlbmRhID0+IG5ldmVyIGJlIHNoeSB0byBudWRnZSBtZSA7LSkNCg0KSSBoYXZl IGNsZWFyZWQgbXkgRElTQ1VTUyBhbmQgdGhhbmsgeW91IGZvciB0aGUgb3RoZXIgY2hhbmdlcyBh bmQgeW91ciByZXBsaWVzIChldmVuIGlmIEkgYW0gbm90IHRvbyBjb252aW5jZWQgYWJvdXQgUHZE IC4uLmJ1dCB0aGlzIGlzIE9LKQ0KDQpSZWdhcmRzIGFuZCB0aGFuayB5b3UgZm9yIHlvdXIgd29y ayAhDQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVz ZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQ2hyaXN0aWFuIEFtc8O8c3Mg PGNocmlzdGlhbkBhbXN1ZXNzLmNvbT4NCkRhdGU6IFR1ZXNkYXksIDMgTm92ZW1iZXIgMjAyMCBh dCAxODozMQ0KVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4NCkNjOiA8amFpbWUu amltZW5lekBlcmljc3Nvbi5jb20+LCA8Y29yZS1jaGFpcnNAaWV0Zi5vcmc+LCA8Ym9iLmhpbmRl bkBnbWFpbC5jb20+LCA8ZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeUBpZXRmLm9y Zz4sIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4sIFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgPGNv cmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0yNTogKHdpdGggRElTQ1VTUyBh bmQgQ09NTUVOVCkNCg0KICAgIChUaGlzIGlzIG9uZSBvZiB0aGUgcG9pbnQtdG8tcG9pbnQgZm9s bG93LXVwIG1haWxzIG9uIHRoZSBSRCAtMjUNCiAgICByZXZpZXdzOyBmb3IgdGhlIHByZWZhY2Us IHBsZWFzZSBzZWUgdGhlIHByZWNlZGluZyBtYWlsIG9uICJUaGUgdmFyaW91cw0KICAgIHBvc2l0 aW9ucyBvbiBkcmFmdC1pZXRmLWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5LTI1IiBhdA0KICAgIDxo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2NvcmUveFdMb213d2hvdmtVLUNQ R054bnZzNDBCaGFNLz4pLg0KDQogICAgQXMgRElTQ1VTUzoNCg0KICAgID4gVGhhbmsgeW91IGZv ciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50LiBJIGFtIGxpdHRsZSBwdXp6bGVkIGJ5 IHRoZQ0KICAgID4gZG9jdW1lbnQgc2hlcGhlcmQncyB3cml0ZS11cCBkYXRlZCBtb3JlIHRoYW4g b25lIHllYXIgYWdvICh0aGUgcmVzcG9uc2libGUgQUQNCiAgICA+IGhhcyBldmVuIGNoYW5nZWQg YW5kIHRoZSBjaGFuZ2UgaXMgbm90IHJlZmxlY3RlZCBpbiB0aGUgd3JpdGUtdXApLi4uIHdoaWxl DQogICAgPiB3ZWxsLXdyaXR0ZW4gdGhpcyB3cml0ZS11cCBzZWVtcyB0byBpbmRpY2F0ZSBuZWl0 aGVyIGEgbGFyZ2UgY29uc2Vuc3VzIG5vciBhDQogICAgPiBkZWVwIGludGVyZXN0IGJ5IHRoZSBD T1JFIFdHIGNvbW11bml0eS4gQnV0LCBJIGFtIHRydXN0aW5nIHRoZSBwYXN0IGFuZA0KICAgID4g Y3VycmVudCByZXNwb25zaWJsZSBBRHMgb24gdGhpcyBhc3BlY3QuDQoNCiAgICByZXNwb25zZToN Cg0KICAgIFRoZSBzaGVwaGVyZCB3cml0ZS11cCBoYXMgYmVlbiB1cGRhdGVkLg0KDQogICAgPiBE aWQgdGhlIGF1dGhvcnMgY2hlY2sgd2l0aCA2TUFOIFdHIGFib3V0IHRoZSBuZXcgUkRBTyBvcHRp b24gZm9yIElQdjYgTkRQID8gSQ0KICAgID4gd2FzIHVuYWJsZSB0byBmaW5kIGFueSA2TUFOIGVt YWlsIHJlbGF0ZWQgdG8gdGhpcyBuZXcgTkRQIG9wdGlvbiBhbmQsIGFmdGVyDQogICAgPiBjaGVj a2luZyB3aXRoIHRoZSA2TUFOIFdHIGNoYWlycywgdGhleSBhbHNvIGRvIG5vdCByZW1lbWJlciBh bnkgZGlzY3Vzc2lvbi4NCg0KICAgIHJlc3BvbnNlOg0KDQogICAgSnVzdCByZWNlbnRseSAoc2Vl IEdFTkVSSUMtNk1BTikuDQoNCiAgICA+ID09IERJU0NVU1MgPT0NCiAgICA+IA0KICAgID4gLS0g U2VjdGlvbiA0LjEgLS0gSXQgd2lsbCBiZSB0cml2aWFsIHRvIGZpeCwgaW4gSVB2NiBhZGRyZXNz IGNvbmZpZ3VyYXRpb24NCiAgICA+IChTTEFBQyB2cy4gREhDUCkgaXMgb3J0aG9nb25hbCB0byBE SENQICdvdGhlci1pbmZvcm1hdGlvbicuIEUuZy4sIGV2ZW4gaWYNCiAgICA+IGFkZHJlc3MgaXMg Y29uZmlndXJlZCB2aWEgU0xBQUMsIERIQ1B2NiBvdGhlci1pbmZvcm1hdGlvbiBjYW4gYmUgdXNl ZCB0bw0KICAgID4gY29uZmlndXJlIHRoZSBSZWN1cnNpdmUgRE5TIFNlcnZlciAob3IgcG9zc2li bHkgdGhlIFJEKS4NCg0KICAgIHJlc3BvbnNlOg0KDQogICAgVGhhbmtzLCBmaXhlZCBpbiBodHRw czovL2dpdGh1Yi5jb20vY29yZS13Zy9yZXNvdXJjZS1kaXJlY3RvcnkvcHVsbC8yNjMuDQoNCiAg ICBDb252ZXJzZWx5LCB0aGUgUkRBTydzIGFwcGxpY2FiaWxpdHkgaXMgbm93IHBocmFzZWQgbW9y ZSBnZW5lcmFsbHkgYXMgd2VsbC4NCg0KICAgID4gLS0gU2VjdGlvbiA0LjEuMSAtLSBBbm90aGVy IHRyaXZpYWwgRElTQ1VTUyB0byBmaXg6IGluIHdoaWNoIG1lc3NhZ2UgaXMgdGhpcw0KICAgID4g UkRBTyBzZW50ID8gSSBndWVzcyB1bmljYXN0IFJvdXRlciBBZHZlcnRpc2VtZW50IGJ1dCB0aGlz IE1VU1QgYmUgc3BlY2lmaWVkLg0KDQogICAgcmVzcG9uc2U6DQoNCiAgICBJbmRlZWQ7IGZpeGVk IGluIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Jlc291cmNlLWRpcmVjdG9yeS9wdWxsLzI2 Mi4NCg0KICAgIEFzIENPTU1FTlQ6DQoNCiAgICA+ID09IENPTU1FTlRTID09DQogICAgPiANCiAg ICA+IEluIGdlbmVyYWwsIEkgd29uZGVyIGhvdyBtdWNoIGludGVyYWN0aW9ucyBhbmQgZXhjaGFu Z2VzIG9mIGlkZWFzIGhhdmUNCiAgICA+IGhhcHBlbmVkIGluIHRoZSBsb25nIGhpc3Rvcnkgb2Yg dGhpcyBkb2N1bWVudCB3aXRoIHRoZSBETlNTRCAoRE5TIFNlcnZpY2UNCiAgICA+IERpc2NvdmVy eSkgV29ya2luZyBHcm91cCB0aGF0IGhhcyB2ZXJ5IHNpbWlsYXIgY29uc3RyYWludHMgKHNsZWVw aW5nIG5vZGVzKQ0KICAgID4gYW5kIHNhbWUgb2JqZWN0aXZlcy4NCg0KICAgIFdHRi01DQogICAg cmVzcG9uc2U6DQoNCiAgICBEaXNjdXNzaW9uIHdhcyBwcmltYXJpbHkgb24gdGhlIGxldmVsIG9m IGdyYW51bGFyaXR5IG9mIHNlcnZpY2UgZGVzY3JpcHRpb24NCiAgICAod2hhdCBpcyBhbm5vdW5j ZWQgaW4gRE5TLVNEIG9mdGVuIGNvcnJlc3BvbmRzIHRvIG11bHRpcGxlIHJlc291cmNlcyBpbiBh biBSRCksDQogICAgYW5kIG9uIHByb3RvY29sIG5lZ290aWF0aW9uIChpbnB1dCB3aGljaCBpcyBt b3JlIHN1aXRhYmxlIGZvciB0aGUNCiAgICBwcm90b2NvbC1uZWdvdGlhdGlvbiB3b3JrIHRoYW4g aXQgaXMgZ29pbmcgaW50byBSRCkuDQoNCiAgICA+IC0tIFNlY3Rpb24gMiAtLSBUbyBiZSBob25l c3Q6IEkgYW0gbm90IHRvbyBtdWNoIGFuIEFQUCBwZXJzb247IHRoZXJlZm9yZSwgSQ0KICAgID4g d2FzIHN1cnByaXNlZCB0byBzZWUgInNvdXJjZSBhZGRyZXNzIChVUkkpIiB1c2VkIHRvIGlkZW50 aWZ5IHRoZSAiYW5jaG9yPSIuLi4NCiAgICA+IEkgZG8gbm90IG1pbmQgdG9vIG11Y2ggdGhlIHVz ZSBvZiAiZGVzdGluYXRpb24gYWRkcmVzcyAoVVJJKSIgYXMgaXQgaXMgcmVhbGx5DQogICAgPiBh IGRlc3RpbmF0aW9uIGJ1dCB0aGUgYW5jaG9yIGRvZXMgbm90IGFwcGVhciB0byBtZSBhcyBhICJz b3VyY2UgYWRkcmVzcyIuIElzDQogICAgPiBpdCBjb21tb24gdGVybWlub2xvZ3kgPyBJZiBzbywg dGhlbiBpZ25vcmUgbXkgQ09NTUVOVCwgZWxzZSBJIHN1Z2dlc3QgdG8NCiAgICA+IGNoYW5nZSB0 byAiZGVzdGluYXRpb24gVVJJIiBhbmQgc2ltcGx5ICJhbmNob3IiID8NCg0KICAgIHJlc3BvbnNl Og0KDQogICAgIkNvbnRleHQiIGlzIHRoZSB0ZXJtIHRoYXQgUkZDODI4OCB1c2VzLCBhbmQgb3Ro ZXIgdGhhbiB3aGVuIGRlZmluaW5nIHRoZQ0KICAgIENvbnRleHQgd2UgZG9uJ3QgdXNlIHNvdXJj ZSBhZGRyZXNzIGZvciB0aGF0IChhcyB0aGF0IHRlcm0gaXMgdXNlZCBtb3JlDQogICAgY29tbW9u bHkgd2l0aCBDb0FQL1VEUCBtZXNzYWdlcykuDQoNCiAgICBUaGUgInNvdXJjZSIgcGFydCBpbiB0 aGUgZGVmaW5pdGlvbiBoYXMgbm8gY2xlYXIgbGluZWFnZSBpbiBSRkM4Mjg4ICh3aGljaCBkb2Vz DQogICAgbm90IGludHJvZHVjZSB0aGUgdGVybSBmb3JtYWxseSksIGl0IHN0ZW1zIGZyb20gYSBs aW5rIGdvaW5nICJmcm9tIiBzb21ld2hlcmUNCiAgICAodGhlIGNvbnRleHQsIG9yIHNvdXJjZSkg InRvIiBzb21ld2hlcmUgKHRoZSB0YXJnZXQsIG9yIGRlc3RpbmF0aW9uKS4NCg0KICAgID4gLS0g U2VjdGlvbiAzLjMgLS0gU2hvdWxkIHRoZSBsaWZldGltZSBiZSBzcGVjaWZpZWQgaW4gc2Vjb25k cyBhdCBmaXJzdCB1c2UgaW4NCiAgICA+IHRoZSB0ZXh0Pw0KDQogICAgV0dGLTMNCiAgICByZXNw b25zZToNCg0KICAgIFRoZSBsaWZldGltZSBpcyB0aG91Z2h0IG9mIGFzIGEgcXVhbnRpdHkgb2Yg dGltZSwgd2hpY2ggaXMgb25seSBleHByZXNzZWQgaW4NCiAgICBtdWx0aXBsZXMgb2YgYSB1bml0 IHdoZW4gc2VyaWFsaXplZCAoYW5kIHRoZXJlLCBpdCBpcyBjb25zaXN0ZW50bHkgdXNlZCB3aXRo DQogICAgc2Vjb25kcykuDQoNCiAgICA+IC0tIFNlY3Rpb24gMy42IC0tIElzIHRoZSB1c2Ugb2Yg Ik0yTSIgc3RpbGwgY3VycmVudD8gSSB3b3VsZCBzdWdnZXN0IHRvIHVzZQ0KICAgID4gdGhlIHdv cmQgIklvVCIgZXNwIHdoZW4gNkxCUiAoYXNzdW1pbmcgaXQgaXMgNkxPIEJvcmRlciBSb3V0ZXIp IGlzIGNpdGVkDQogICAgPiBsYXRlci4NCg0KICAgIHJlc3BvbnNlOg0KDQogICAgRm9yIEhvbWUg YW5kIEluZHVzdHJpYWwgQXV0b21hdGlvbiwgSW9UIGlzIGluZGVlZCB1c2VkIG1vcmUgY29tbW9u bHkgdGhlc2UNCiAgICBkYXlzLiBVcGRhdGVkIGluIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L3Jlc291cmNlLWRpcmVjdG9yeS9wdWxsLzI5Ny4NCg0KICAgID4gUGxlYXNlIGV4cGFuZCBhbmQg YWRkIHJlZmVyZW5jZSBmb3IgNkxCUi4NCg0KICAgIHJlc3BvbnNlOg0KDQogICAgRG9uZSAoaW4g aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvcmVzb3VyY2UtZGlyZWN0b3J5L3B1bGwvMjk3KS4N Cg0KICAgID4gVXNpbmcgJ21vZGVybicgdGVjaG5vbG9naWVzIChjZnIgTFAtV0FOIFdHKSBjb3Vs ZCBhbHNvIGFkZCBqdXN0aWZpY2F0aW9uIHRvDQogICAgPiBzZWN0aW9uIDMuNS4NCg0KICAgIHJl c3BvbnNlOg0KDQogICAgQXQgbGVhc3Qgd2l0aCB0aGUgY3VycmVudGx5IGF2YWlsYWJsZSBzZXR1 cHMsIHRoZSBjZWxsdWxhciBhcHBsaWNhdGlvbnMgaGF2ZQ0KICAgIHRoZSAiYWR2YW50YWdlIiAo ZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgbW90aXZhdGluZyB0aGUgUkQpIHRoYXQgdGhleSBhcmUg bGVzcw0KICAgIGludGVncmF0ZWQgd2l0aCB0eXBpY2FsIGFwcGxpY2F0aW9uIGRlcGxveW1lbnRz LCBhbmQgdGh1cyBoYXZlIGEgbW9yZQ0KICAgIHByb25vdW5jZWQgbmVlZCBmb3IgZGlzY292ZXJ5 IGluIG5ldHdvcmtzIHRoYXQgYXJlIG5vdCB1bmRlciBmdWxsIGNvbnRyb2wgb2YNCiAgICB0aGUg ZGV2aWNlIG9wZXJhdG9yLg0KDQogICAgPiAtLSBTZWN0aW9uIDQuMSAtLSBBYm91dCAiY29hcDov L1tNQ0QxXS8ud2VsbC1rbm93bi9jb3JlP3J0PWNvcmUucmQqIiwgd2hhdCBpcw0KICAgID4gdGhl IHZhbHVlIG9mIE1DRDEgPyBUaGUgSUFOQSBzZWN0aW9uIGRpc2N1c3MgYWJvdXQgaXQgYnV0IGl0 IG1heSBoZWxwIHRoZQ0KICAgID4gcmVhZGVyIHRvIGdpdmUgYSBoaW50IGJlZm9yZSAob3Igc2lt cGx5IHVzZSBUQkR4IHRoYXQgaXMgY29tbW9uIGluIEktRCkuDQoNCiAgICByZXNwb25zZToNCg0K ICAgIFRCRHggd291bGQgaGF2ZSBiZWVuIGVhc2llciBpbiBoaW5kaWdodCwgYnV0IHRoZXJlJ3Mg aG9wZSB0aGF0IHVudGlsIFJGQyBlZGl0b3INCiAgICByZXBsYWNlcyB0aGF0LCBtb3JlIHBlb3Bs ZSB3aWxsIGJlIHJlYWRpbmcgdGhlIGRpZmZzIHRoYW4gbmV3IHBlb3BsZSB0aGF0IG1pZ2h0DQog ICAgc3R1bWJsZSBoZXJlIHdpbGwgcmVhZCB0aGUgZG9jdW1lbnQsIHNvIGl0J3Mga2VwdCB0aGF0 IHdheS4NCg0KICAgID4gQW55IHJlYXNvbiB0byB1c2UgImFkZHJlc3MiIHJhdGhlciB0aGFuICJn cm91cCIgaW4gIldoZW4gYW5zd2VyaW5nIGENCiAgICA+IG11bHRpY2FzdCByZXF1ZXN0IGRpcmVj dGVkIGF0IGEgbGluay1sb2NhbCBhZGRyZXNzIiA/DQoNCiAgICBObywgYW5kICdncm91cCcgc2hv dWxkIHJlZHVjZSB0aGUgY2hhbmNlcyBvZiByZWFkZXJzIG92ZXJsb29raW5nIHRoYXQgdGhpcyBp cw0KICAgIGFib3V0IG11bHRpY2FzdHMuIChDaGFuZ2VkIGluDQogICAgaHR0cHM6Ly9naXRodWIu Y29tL2NvcmUtd2cvcmVzb3VyY2UtZGlyZWN0b3J5L3B1bGwvMjk3KS4NCg0KICAgID4gTGF0ZXIg InRvIHVzZSBvbmUgb2YgdGhlaXIgb3duIHJvdXRhYmxlIGFkZHJlc3NlcyBmb3IgcmVnaXN0cmF0 aW9uLiIgYnV0DQogICAgPiB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgY29uZmlndXJlZCBwcmVmaXhl cy4uLiBXaGljaCBvbmUgc2hvdWxkIHRoZSBSRCBzZWxlY3QgPw0KICAgID4gU2hvdWxkIHRoaXMg YmUgc3BlY2lmaWVkID8NCg0KICAgIHJlc3BvbnNlOg0KDQogICAgSSBkb24ndCB0aGluayBpdCBu ZWVkcyB0byBiZSBmdWxseSBzcGVjaWZpZWQgb3V0IChlc3BlY2lhbGx5IGFzIHRoaXMgaXMgbWVy ZWx5DQogICAgYSBzdWdnZXN0aW9uKSwgYnV0IHRoZSB0ZXJtcyBvZiBSRkM2NzI0IHNlZW0gdG8g YmUgaGVscGZ1bCBhbmQgd2VyZSBhZGRlZCBpbg0KICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3Jl LXdnL3Jlc291cmNlLWRpcmVjdG9yeS9wdWxsLzI5OC4NCg0KICAgIEEgcmV2aWV3IGZyb20gdGhp cyBoYXMgYmVlbiByZXF1ZXN0ZWQgaW4gdGhlIHJldmlldyByZXF1ZXN0IHRvIDZNQU4gKHNlZQ0K ICAgIEdFTkVSSUMtNk1BTikuDQoNCiAgICA+IEFzIGEgY28tYXV0aG9yIG9mIFJGQyA4ODAxLCBJ IHdvdWxkIGhhdmUgYXBwcmVjaWF0ZWQgdG8gcmVhZCBQdkQgb3B0aW9uDQogICAgPiBtZW50aW9u bmVkIHRvIGRpc2NvdmVyIHRoZSBSRC4gQW55IHJlYXNvbiB3aHkgUHZEIE9wdGlvbiBjYW5ub3Qg YmUgdXNlZCA/DQoNCiAgICByZXNwb25zZToNCg0KICAgIFByb2JhYmx5IGJlY2F1c2UgODgwMSB3 YXMganVzdCBwdWJsaXNoZWQsIGFuZCB0aGUgUkRBTyBwcmVkYXRlcyBldmVuIC1wdmQtMDAgYnkN CiAgICBhIHllYXIuDQoNCiAgICBTYXNzaW5lc3MgYXNpZGUsIGFzIEkgdW5kZXJzdGFuZCB0aGUg UHZEIG9wdGlvbiBmcm9tIGEgc2tpbSBhbmQgdGhlIHZhZ3VlDQogICAgcmVjb2xsZWN0aW9ucyBv ZiBoYXZpbmcgaGFkIGEgbG9vayBhdCB0aGlzIGF0IHNvbWUgZWFybGllciB0aW1lLCB0aGlzIHdv dWxkIGJlDQogICAgb3J0aG9nb25hbCB0byB0aGUgUkRBTzogYSByb3V0ZXIgd2l0aCBtdWx0aXBs ZSBQdkRzIGNvdWxkIGZvcndhcmQgdGhlIFJEQU8gZnJvbQ0KICAgIGVpdGhlciB1cGxpbmsgaW5z aWRlIFB2RCBvcHRpb25zLCBhbmQgcGljayBhIHByaW1hcnkgb25lIHRvIGZvcndhcmQgdG8NCiAg ICBQdkQtdW5hd2FyZSBob3N0cy4NCg0KICAgIEkgZG9uJ3Qgc2VlIGFueSBjb25mbGljdCwgYnV0 IGRvbid0IHNlZSBtdWNoIHBvdGVudGlhbCBlaXRoZXIgKGFyZSB0aGVyZSBtYW55DQogICAgY29u c3RyYWluZWQgZGV2aWNlcyB0aGF0IGJlbmVmaXQgZnJvbSBiZWNvbWluZyBQdkQtYXdhcmU/KSAt LSBzbyBJJ2Qga2VlcCBpdCBhcw0KICAgIHdpdGggYW55IG90aGVyIFJBIG9wdGlvbjogVGhleSBj YW4gYmUgY29tYmluZWQsIGJ1dCB0aGVyZSdzIG5vIHBhcnRpY3VsYXINCiAgICByZWFzb24gdG8g cG9pbnQgdGhhdCBvdXQgb24gZWl0aGVyIHNpZGUuDQoNCiAgICBJZiBzdWNoIGEgY29tYmluYXRp b24gY2FuIGJlIGV4cGVjdGVkLCB0aGlzIGNvdWxkIGJlIGEgZ29vZCBleGFtcGxlIGZvciB0aGUN CiAgICAiTUFZIGtlZXAgY29uY3VycmVudCByZWdpc3RyYXRpb25zIGlmIGV4cGxpY2l0bHkgY29u ZmlndXJlZCB0byBkbyBzbyIgcGFydCwgYnV0DQogICAgdGhhdCB3YXMgbm90IGFkZGVkIGluIHRo aXMgaXRlcmF0aW9uIGZvciBsYWNrIG9mIGtub3duIHVzZSBjYXNlcy4NCg0KICAgIChUaGlzIGlz IHNsaWdodGx5IG1vcmUgaW50ZXJlc3RpbmcgaW4gY2FzZXMgd2hlbiB0aGUgUkQgcGlja3MgdGhl IGFkZHJlc3NlczsgYQ0KICAgIG5vdGUgb24gdGhhdCB3aWxsIGFwcGVhciBpbiB0aGUgbmV4dCB2 ZXJzaW9uIG9mDQogICAgZHJhZnQtYW1zdWVzcy1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS1leHRl bnNpb25zKS4NCg0KICAgID4gLS0gU2VjdGlvbiA0LjEuMSAtLSBJIHN1Z2dlc3QgdG8gc3dhcCB0 aGUgcmVzZXJ2ZWQgYW5kIGxpZmV0aW1lIGZpZWxkcyBpbg0KICAgID4gb3JkZXIgdG8gYmUgYWJs ZSB0byB1c2UgYSBsaWZldGltZSBpbiB1bml0cyBvZiBzZWNvbmRzICh0byBiZSBjb25zaXN0ZW50 IHdpdGgNCiAgICA+IG90aGVyIE5EUCBvcHRpb25zKS4NCg0KICAgIHJlc3BvbnNlOg0KDQogICAg SW1wbGVtZW50b3JzIHdpbGwgYXBwcmVjaWF0ZSB0aGF0OyBkb25lIGluDQogICAgaHR0cHM6Ly9n aXRodWIuY29tL2NvcmUtd2cvcmVzb3VyY2UtZGlyZWN0b3J5L3B1bGwvMjk5Lg0KDQogICAgPiAt LSBTZWN0aW9uIDUgLS0gTWF5IGJlIEkgbWlzc2VkIGl0LCBidXQsIGNhbiBhbiBlbmQtcG9pbnQg cmVnaXN0ZXIgbXVsdGlwbGUNCiAgICA+IGJhc2UgVVJJID8gRS5nLiwgbXVsdGlwbGUgSVB2NiBh ZGRyZXNzZXMuDQoNCiAgICByZXNwb25zZToNCg0KICAgIE5vLCB0aGF0IGlzIGRlZmVycmVkIHRv IHByb3RvY29sLW5lZ290aWF0aW9uICh3aGVyZSB3aGF0ZXZlciBjb21lcyBvdXQgb2YgaXQgaXMN CiAgICBleHBlY3RlZCB0byBkbyBtdWx0aXBsZSBhZGRyZXNzZXMgb24gdGhlIHNhbWUgcHJvdG9j b2wganVzdCBhcyB3ZWxsIGFzDQogICAgZGlmZmVyZW50IHByb3RvY29scykuDQoNCiAgICA+IC0t IFNlY3Rpb24gOS4yIC0tIEZvciBpbmZvcm1hdGlvbiwgdmFsdWUgMzggaXMgYWxyZWFkeSBhc3Np Z25lZCB0byBSRkMgODc4MS4NCg0KICAgIHJlc3BvbnNlOg0KDQogICAgTGVhdmluZyBpdCBpbiB0 aGUgZHJhZnQgYXMtaXMsIGFudGljaXB0aW5nIHRoYXQgSUFOQSBqdXN0IHBpY2tpbmcgdGhlIG5l eHQNCiAgICBhdmFpbGFibGUgbnVtYmVyIHdpbGwgY3JlYXRlIGxlc3MgdG90YWwgY29nbml0aXZl IGxvYWQgdGhhbiBhbm90aGVyIHNldCBjaGFuZ2VkDQogICAgbGluZXMgaW4gdGhlIGRpZmZzLg0K DQogICAgPiA9PSBOSVRTID09DQogICAgPiANCiAgICA+IC0tIFNlY3Rpb24gMiAtLSBUaGUgZXh0 cmEgbmV3IGxpbmVzIHdoZW4gZGVmaW5pbmcgIlNlY3RvciIgYXJlIHNsaWdobHkNCiAgICA+IGNv bmZ1c2luZy4gU2FtZSBhcHBsaWVzIHRvICJUYXJnZXQiIGFuZCAiQ29udGV4dCIuIFRoaXMgaXMg Y29zbWV0aWMgb25seS4NCg0KICAgIHJlc3BvbnNlOg0KDQogICAgV2UncmUgaGF2aW5nIGlzc3Vl cyB3aXRoIHRoZSB0b29saW5nIGhlcmU7IGlmIGl0IGNhbid0IGJlIGlyb25lZCBvdXQgYmVmb3Jl IHRoZQ0KICAgIGZpbmFsIHZlcnNpb24sIHRoaXMgd2lsbCBiZSBmaXhlZCBtYW51YWxseSBkdXJp bmcgdGhlIGhhbmRvdmVyIHRvIFJGQyBlZGl0b3IuDQoNCiAgICBJc3N1ZTogaHR0cHM6Ly9naXRo dWIuY29tL2NvcmUtd2cvcmVzb3VyY2UtZGlyZWN0b3J5L2lzc3Vlcy8yNTINCg0K From nobody Mon Feb 1 10:25:02 2021 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 80B513A138C; Mon, 1 Feb 2021 10:25:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161220390048.4746.17803268647442993812@ietfa.amsl.com> Date: Mon, 01 Feb 2021 10:25:00 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-12.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: Mon, 01 Feb 2021 18:25:01 -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 : CoAP: Echo, Request-Tag, and Token Processing Authors : Christian Amsüss John Preuß Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-12.txt Pages : 34 Date : 2021-02-01 Abstract: This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. 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, and with respect to amplification mitigation, where the use of Echo is now recommended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-echo-request-tag-12.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 1 11:56:20 2021 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 E07E73A148E; Mon, 1 Feb 2021 11:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 DMgHWx68M_mU; Mon, 1 Feb 2021 11:56:10 -0800 (PST) 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 B70AA3A1475; Mon, 1 Feb 2021 11:56:07 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3115C407CF; Mon, 1 Feb 2021 20:56:05 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3B525FD; Mon, 1 Feb 2021 20:56:04 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:7502:722c:4e86:561f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E5D0744; Mon, 1 Feb 2021 20:56:03 +0100 (CET) Received: (nullmailer pid 153824 invoked by uid 1000); Mon, 01 Feb 2021 19:56:03 -0000 Date: Mon, 1 Feb 2021 20:56:03 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-echo-request-tag.all@ietf.org, ops-dir@ietf.org, last-call@ietf.org Cc: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YV7r01fJNTTiIm05" Content-Disposition: inline In-Reply-To: <161220390048.4746.17803268647442993812@ietfa.amsl.com> <20201210083247.obamjgn7sjcu56r2@anna.jacobs.jacobs-university.de> Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-echo-request-tag-12.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, 01 Feb 2021 19:56:19 -0000 --YV7r01fJNTTiIm05 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Barry, hello J=FCrgen, I've just uploaded a -12, and Marco has been very quick to update the write-up. All the points of the reviews have been addressed, and being nits probably don't warrant further mention outside the changelog of the -12 (copied below for convenience). The nontivial point was the lack of explanation about the number given for OK-to-send responses. It has been recalculated with more conservative numbers, experssed in what is hoped to be easier to consume for implementation developers. For the "factor 3" that plays into it it now refers to the WIP QUIC draft. It's giving the numbers as guidance in case there's no better basis for making a more situation-adjusted and more informed decision. With that, the document should be good to go ahead. Best regards, and thanks for all your input Christian --- * Changes since draft-ietf-core-echo-request-tag-11 (addressing GenART, TSVART, OpsDir comments) - Explain the size permissible for responses before amplification mitigation by referring to the QUIC draft for an OK factor, and giving the remaining numbers that led to it. The actual number is reduced from 152 to 136 because the more conservative case of the attacker not sending a token is considered now. - Added a definition for "freshness" - Give more concrete example values in figures 2 and 3 (based on the appendix suggestions), highlighting the differences between the figures by telling how they are processed in the examples. - Figure with option summary: E/U columns removed (for duplicate headers and generally not contributing) - MAY capitalization changed for consistency. - Editorial changes (IV acronym expanded, s/can not/cannot/g) - Draft ietf-core-stateless has become RFC8974 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --YV7r01fJNTTiIm05 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAYXMgACgkQOY0REtOk veGycA//dr2Ot05HTgAty8viiFUaHQ1+RJOZ9DSyIELnNH5mIBx9z3JtVHzGmBgw BGX/SVzcCoxufJsY+afJQEpbMTW+TIElfaqptzwNS1J6c+CngfIDRU7vvK7rC/dN RD8oKgl3gQX1hynqhIqZ45uehN0u6q+OSzhLvq+M/HrWLl6kGcCaBCH0GBzvEEwj Edu+J6a2BxZby9iH+gTl45S8iLY0UJwkz4Yi6wBSYYFrOTBGrgKougD9LKslafQp VolI2NrpOkxy+VTz4Gf1R3uPClBhLF/Cay4XcOQkXzZtPyeHfYJvkfW6SeLLv5uh fEpXNM7nppV5ix8JVn6eC5hNNCwUcO9yodyziJeBe3DWPqABKaNKUTag8b/xCvSg mZitjinES0zbPNef5S47J0hXVj00b7AilAf/hQtwH55i1umsZ82M8x7lEBjapFjm YvTdPd5gsdU5enXql3ZcwAjY/YHy5D8Qsp+jattZMiuct56o2ptKmzQL57twSOEv wj812UUUTK64CgkDBjkgoh8bZxjEHtQogNMfM9R8ISSXCyZLSOFDwVmYv49GvQ90 1OhMukLsTor/zAcvNybDg/cGTsrkJkIKjhe4rSmukBwKP5snpt4hwDpDVarxreXa OrneKeR/Yht6GsjKDZMRQlbYoyIu19l6v0uVDjec/8cFm3dFPWg= =qeBn -----END PGP SIGNATURE----- --YV7r01fJNTTiIm05-- From nobody Mon Feb 1 14:15:23 2021 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 B7CC63A152B; Mon, 1 Feb 2021 14:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, HTML_MESSAGE=0.001, 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 oigEkVAV-vMh; Mon, 1 Feb 2021 14:15:21 -0800 (PST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 CC9F13A1529; Mon, 1 Feb 2021 14:15:20 -0800 (PST) Received: by mail-lf1-f43.google.com with SMTP id h7so25043574lfc.6; Mon, 01 Feb 2021 14:15:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l2HB4JTAEhJNsZ4vC7Mlcuc/dLY/vDKrq70T9U0MmBc=; b=svt7FrGErOUb2c/N0lwAAmTEdMIOhc8/IucJ9QKupOps9GzgI0b3sL0F0687xvDvMj tDnIqd4oMplYNz81lkRe+287RCA/JEzxN361Mbev4lDQvhaf7kBN72Kx6bvhEBCPjjIL w4lW7BloyJAgg5KGYqCnjHM6UWJyr01xk7T6Q5tVppo+IXVah/7SOHURTdn7v2WNiGDs vgowFrnFwQZGK8FG7gVgg9WRwneDdfzGMOfOGfNumCN58hklxggQsUnS33lm2rpH4uLk uo1ZexMq/6rlnC/03hZkAn/FJVF3MiNtizUmeb8qg9tIOdT0cNodPfvb7UW5BXYkXC9B oRXg== X-Gm-Message-State: AOAM533/y5hoDwFR8VgW7EqJkLTwekW82Tf6V+6NujOrPgCrW925fAos 7LBJxxZq0zxiwXMmeVJB8Jb80wyH3iSnHeROtC4= X-Google-Smtp-Source: ABdhPJzzXbJQxQ/0afEs5HhbO544knw93STeKaOvBf+ZWS1q4wPORZKj3KnKisxtoLd5qzKFacv4vqbcB/BOErgMr5g= X-Received: by 2002:a05:6512:31c1:: with SMTP id j1mr9808003lfe.313.1612217718815; Mon, 01 Feb 2021 14:15:18 -0800 (PST) MIME-Version: 1.0 References: <161220390048.4746.17803268647442993812@ietfa.amsl.com> <20201210083247.obamjgn7sjcu56r2@anna.jacobs.jacobs-university.de> In-Reply-To: From: Barry Leiba Date: Mon, 1 Feb 2021 17:15:08 -0500 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org, ops-dir@ietf.org Content-Type: multipart/alternative; boundary="0000000000006e424205ba4db014" Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-echo-request-tag-12.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, 01 Feb 2021 22:15:23 -0000 --0000000000006e424205ba4db014 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Christian. I=E2=80=99ve put it into IESG Evaluation. It=E2=80=99s= too late to have it on this week=E2=80=99s IESG agenda, to it will come up for approval= in two weeks. Barry On Mon, Feb 1, 2021 at 2:56 PM Christian Ams=C3=BCss wrote: > Hello Barry, hello J=C3=BCrgen, > > I've just uploaded a -12, and Marco has been very quick to update the > write-up. > > All the points of the reviews have been addressed, and being nits > probably don't warrant further mention outside the changelog of the -12 > (copied below for convenience). > > The nontivial point was the lack of explanation about the number given > for OK-to-send responses. It has been recalculated with more > conservative numbers, experssed in what is hoped to be easier to consume > for implementation developers. For the "factor 3" that plays into it it > now refers to the WIP QUIC draft. It's giving the numbers as guidance in > case there's no better basis for making a more situation-adjusted and > more informed decision. > > With that, the document should be good to go ahead. > > Best regards, and thanks for all your input > Christian > > --- > > * Changes since draft-ietf-core-echo-request-tag-11 (addressing > GenART, TSVART, OpsDir comments) > > - Explain the size permissible for responses before amplification > mitigation by referring to the QUIC draft for an OK factor, and > giving the remaining numbers that led to it. The actual number > is reduced from 152 to 136 because the more conservative case > of the attacker not sending a token is considered now. > > - Added a definition for "freshness" > > - Give more concrete example values in figures 2 and 3 (based on > the appendix suggestions), highlighting the differences between > the figures by telling how they are processed in the examples. > > - Figure with option summary: E/U columns removed (for duplicate > headers and generally not contributing) > > - MAY capitalization changed for consistency. > > - Editorial changes (IV acronym expanded, s/can not/cannot/g) > > - Draft ietf-core-stateless has become RFC8974 > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom > --0000000000006e424205ba4db014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Christian.=C2=A0 I=E2=80=99ve put it into IESG Ev= aluation.=C2=A0 It=E2=80=99s too late to have it on this week=E2=80=99s IES= G agenda, to it will come up for approval in two weeks.

Barry

On Mon, Feb 1, 2021 at 2:56 PM Ch= ristian Ams=C3=BCss <christian@= amsuess.com> wrote:
Hello Ba= rry, hello J=C3=BCrgen,

I've just uploaded a -12, and Marco has been very quick to update the write-up.

All the points of the reviews have been addressed, and being nits
probably don't warrant further mention outside the changelog of the -12=
(copied below for convenience).

The nontivial point was the lack of explanation about the number given
for OK-to-send responses. It has been recalculated with more
conservative numbers, experssed in what is hoped to be easier to consume for implementation developers. For the "factor 3" that plays into= it it
now refers to the WIP QUIC draft. It's giving the numbers as guidance i= n
case there's no better basis for making a more situation-adjusted and more informed decision.

With that, the document should be good to go ahead.

Best regards, and thanks for all your input
Christian

---

=C2=A0 =C2=A0*=C2=A0 Changes since draft-ietf-core-echo-request-tag-11 (add= ressing
=C2=A0 =C2=A0 =C2=A0 GenART, TSVART, OpsDir comments)

=C2=A0 =C2=A0 =C2=A0 -=C2=A0 Explain the size permissible for responses bef= ore amplification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mitigation by referring to the QUIC draft= for an OK factor, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0giving the remaining numbers that led to = it.=C2=A0 The actual number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is reduced from 152 to 136 because the mo= re conservative case
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the attacker not sending a token is co= nsidered now.

=C2=A0 =C2=A0 =C2=A0 -=C2=A0 Added a definition for "freshness"
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 Give more concrete example values in figures 2= and 3 (based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the appendix suggestions), highlighting t= he differences between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the figures by telling how they are proce= ssed in the examples.

=C2=A0 =C2=A0 =C2=A0 -=C2=A0 Figure with option summary: E/U columns remove= d (for duplicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0headers and generally not contributing)
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 MAY capitalization changed for consistency.
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 Editorial changes (IV acronym expanded, s/can = not/cannot/g)

=C2=A0 =C2=A0 =C2=A0 -=C2=A0 Draft ietf-core-stateless has become RFC8974
--
To use raw power is to make yourself infinitely vulnerable to greater power= s.
=C2=A0 -- Bene Gesserit axiom
--0000000000006e424205ba4db014-- From nobody Wed Feb 3 00:03:58 2021 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 430BF3A1570; Wed, 3 Feb 2021 00:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymCU-aGRtFPk; Wed, 3 Feb 2021 00:03:55 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698003A155E; Wed, 3 Feb 2021 00:03:54 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DVvMX5d5hz1004; Wed, 3 Feb 2021 09:03:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612339432; bh=pXy1N/OpKm7RCWYYA3/F3bl/IuSvocC/QgSoApITk0I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=L2HwINIzCpxpYLb+mYPtOx5ngFxi2iL0YwfkyGABmTAv2tZLrL9crwjmRw1CukAWf H7LEKsYcydbPIUh4CgHCTlzVKmkOHNkJdhBH9ZpoheOLrBnvmMzzLTGhI5VVXO4XYM mb8XzEn27cj9dovduU0RvX9tHWOaEo4bDZQpXjJLvJoNtkd2T50D3rHjlfXyT5TxJC +l5/jSKpMj8CZ48Sh/PfF8x7DpqqFueB1Xna7W9jBN19fdM2A64VC84QnVqLqu5f80 hFCAUV2tfI9xBe5L5mfgoCUc3IOsDBjPRrHqfxOsXlkQtHbZmBhDYHl9t6oguH8vM5 A4QpHg8Obb7RQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4DVvMX4m0YzyQF; Wed, 3 Feb 2021 09:03:52 +0100 (CET) From: To: "supjps-ietf@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQE9efsT42/5NWOZF7Ah7uUxJLBzEAIREyNWqyb5urCAQY0GoA== Date: Wed, 3 Feb 2021 08:03:51 +0000 Message-ID: <32574_1612339432_601A58E8_32574_29_1_787AE7BB302AE849A7480A190F8B9330315C6345@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> In-Reply-To: <04a201d6d9d8$c7919ae0$56b4d0a0$@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.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 03 Feb 2021 08:03:57 -0000 Hi Christian, We would appreciate if you can check the latest version of the spec and let= us know whether your issues were adequately addressed. A diff can be found= at: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block-03&url2= =3Ddraft-ietf-core-new-block-06=20 To ease tracking issues, please see below an update to the initial replies.= =20 Replies to the second part of your review can be seen at:=20 https://mailarchive.ietf.org/arch/msg/core/zTjLyXkjtjEUka44mvD8E4HSke8/=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de supjps- > ietf@jpshallow.com > Envoy=E9=A0: jeudi 24 d=E9cembre 2020 10:40 > =C0=A0: christian@amsuess.com; draft-ietf-core-new-block@ietf.org > Cc=A0: dots@ietf.org; core@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Christian, >=20 > Thanks for this and the time spent thinking about it. Some items > have already become separate threads. >=20 > Otherwise responses inline - part 1. Some of the changes can be seen > at https://tinyurl.com/new-block-latest >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Christian Ams=FCss [mailto: christian@amsuess.com] > > Sent: 23 December 2020 05:01 > > To: draft-ietf-core-new-block@ietf.org > > Cc: dots@ietf.org; core@ietf.org WG (core@ietf.org) > > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > > > > Hello new-block authors, hello CoRE, > > > > I've finally managed to have another look at the document (and it's > > still > the > > 22nd *somewhere*...). > > > > My over-all summary is that while this document has matured quite a > > bit (and turned out better than I had expected for the special- > purpose > > blocks > it > > is), I think that the topic of response suppression and congestion > > control sections still have to be sharpened, and the examples could > > pick a more realistic balance between going all-NON and all-CON (or > > explain why that's something that wouldn't be done even though the > > text reads like that's what's expected to be used but maybe it's > just me). > > > > > > Except for the first item (which is coming back to the notes for > the > WGLC), > > all should be more or less sequential in the document (with > > forward/back references as needed). > > > > * On the downref to No-Response: I don't see the downref as too big > an > > issue. It's a bit odd that that document didn't go through the > CoRE > > WG, but my impression is that it's widely used (on a "when the > library > > I maintain broke it people filed issues" level), and both OSCORE > and > > groupcomm-bis (which is to replace RFC7390) reference it. It's an > > informative reference because they don't mechanically depend on > it, > > but it shows how well No-Response has been taken up. > > > > (Frankly, I'd support a retroactive adoption. I don't suppose we > can > > do that with "adults"?). > > > > From how I understand Q-Block to be intended to work, No-Response > does > > not cover all of the behavior (as it's timeout based); still, > that > > document lays good groundwork for what's done here in a rather > precise > > way (see comment on "For Confirmable transmission, the server > MUST > > continue" later on) where this document needs the examples to be > fully > > understood. > > > > Based on the later text on MAX_TRANSMIT_SPAN, why not at least > > acknowledge the equivalence? Maybe like this: > > > > > The behavior of endpoints following this draft can equivalently > b > > > described in terms of the No-Response option {{?RFC7967}}: > > > > > > For a message with a Q-Block1 option with M=3D1 that is followed > by > > > another message on the same Request-Tag within > MAX_TRANSMIT_SPAN [ > > > or MAX_BLOCK_JITTER, see later ], the default value for No- > Response > > > is 8 (suppressing the 4.xx code that would be returned due to > the > > > incomplete request); an explicitly set No-Response option would > > > override that." > > > > although I'd still advocate just using No-Response for the whole > > definition even if No-Response is not typically expressed. > > > > (I'm not really sure what the correct response would be for an > > individual non-terminal request if it were to be answered due to > an > > explicit No-Response:0 -- might be 2.31 Continue that's just not > > used in this specification because it's always suppressed? I'll > come > > back to that -- but then it'd rather be No-Response: 10). > > > > * intro: WebSockets (capitalization) >=20 > [Jon] OK > > > > * The list of pros and cons (with the cons being almost trivial) > does > > not explain to the reader why these are not a replacement; I > suggest > > to add: > > > > * The Q-Block options do not support stateless operation / random > > access. >=20 > [Jon] Actually Q-Block2 does now support this following the > redefinition of the M bit usage in a previous iteration (with M=3D0 you > can ask for any individual block). >=20 > [Jon] For stateless, Request-Tag is included so this should be fine. > https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless- > 06#section-4 > .2 > > > > * Proxying of Q-Block is limited to caching full representations. > > > > (The latter might be mitigated by additional text around caching, > but > > I doubt it's worth the effort given it's not part of the use > case). > [Jon] I am not entirely convinced that Block1/2 have got the caching > by block properly sorted out - e.g. what happens when different > clients make requests with different SZX and Block2 is part of the > cache key. The limiting to caching full representations is there so > that a new can of worms is not opened up. >=20 > [Jon] I will see if I can think of any further cons. [Med] The following two items were added:=20 o To reduce the transmission times for CON transmission of large=09 bodies, NSTART needs to be increased from 1, but this affects=09 congestion control where other parameters need to be tuned=09 (Section 4.7 of [RFC7252]). Such tuning is out of scope of this=09 document.=09 =09=09=20=09=09 o There is no multicast support. > > > > * "compromises of": I don't understand that sentence. >=20 > [Jon] OK s/compromises of/comprises of/ > > > > * "the asymmetrical packet loss is not a benefit here": It never > is; > > what is meant here? >=20 > [Jon] OK. How about (which is obvious, but a reminder to the > implementer) OLD However, the asymmetrical packet loss is not a > benefit here. > NEW > However, the use of Confirmable messages will not work if there > asymmetrical packet loss. > > > > * "Updated CoAP Response Code": "This document updates" sounds like > a > > formal update to RFC7959, which it neither is nor needs to be. > > Phrasing it along the lines of "adds a media type that can be > used > > with 4.08" would ease that. >=20 > [Jon] > OLD > 1.2. Updated CoAP Response Code (4.08) >=20 > This document updates the 4.08 (Request Entity Incomplete) by > defining an additional message format for reporting on payloads > using > the Q-Block1 Option that are not received by the server. > NEW > 1.2. CoAP Response Code (4.08) Usage >=20 > This document adds a media type for the 4.08 (Request Entity > Incomplete) response defining an additional message format for > reporting on payloads using the Q-Block1 Option that are not received > by the server. > > > > * "Only C and U columns are marked": "The Q-Block1 option is > critical, and > > unsafe for proxies to forward" would be easier to read -- which > > checkboxes are marked is visible alrady from the table. (Or just > leave > > it for the later paragraphs that say that in more detail). >=20 > [Jon] OK. Gone with Critical etc. > > > > * "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using > the > > Q-Block1 option" first paragraph). >=20 > [Jon] OK > > > > * "Is opaque in nature, but it is RECOMMENDED" on being a counter > and > > starting off random: Like other similar suggestions (ETag), this > is > > implementation guidance level and not required for > interoperability. > > Maybe phrase this the same way as the recommendations on tokens? >=20 > [Jon] > OLD > The Request-Tag is opaque > in nature, but it is RECOMMENDED that the client treats it as an > unsigned integer of 8 bytes in length. An implementation may want > to > consider limiting this to 4 bytes to reduce packet overhead size. > The server still treats it as an opaque entity. The Request-Tag > value MUST be different for distinct bodies or sets of blocks of > data > and SHOULD be incremented whenever a new body of data is being > transmitted between peers. The initial Request-Tag value SHOULD > be > randomly generated by the client. > NEW > The Request-Tag is opaque, the server still treats it as opaque but > the client SHOULD ensure that it is unique for every different body > of transmitted data. >=20 > Implementation Note: It is suggested that the client treats the > Request-Tag as an > unsigned integer of 8 bytes in length. An implementation may want > to > consider limiting this to 4 bytes to reduce packet overhead size. > The initial Request-Tag value should be randomly generated and then > subsequently incremented by the client whenever a new body of data > is being > transmitted between peers. >=20 > OLD > The ETag is opaque in nature, but it is RECOMMENDED that the > server > treats it as an unsigned integer of 8 bytes in length. An > implementation may want to consider limiting this to 4 bytes to > reduce packet overhead size. The client still treats it as an > opaque > entity. The ETag value MUST be different for distinct bodies or > sets > of blocks of data and SHOULD be incremented whenever a new body of > data is being transmitted between peers. The initial ETag value > SHOULD be randomly generated by the server. > NEW > The ETag is opaque, the client still treats it as opaque but the > server SHOULD ensure that it is unique for every different body of > transmitted data. >=20 > Implementation Note: It is suggested that the server treats the ETag > as an > unsigned integer of 8 bytes in length. An implementation may want > to > consider limiting this to 4 bytes to reduce packet overhead size. > The initial ETag value should be randomly generated and then > subsequently incremented by the server whenever a new body of data > is being > transmitted between peers. >=20 > > > > * "For Confirmable transmission, the server MUST continue": This > reads > > like new-block could change anything about that, when all it does > is > > do things on the response level. [1] has a good note on that > > separation topic. > > > > [1]: https://tools.ietf.org/html/rfc7967#section-2 >=20 > [Jon] The intent here was that CON continues to work for each > request/response in that the request needs to be acknowledged, but a > response (piggybacked or separate) is not required. > OLD > For Confirmable transmission, the server MUST continue to acknowledge > each packet. > NEW > For Confirmable transmission, the server continues to acknowledge > each packet, but a response is not required (whether separate or > piggybacked) until retransmission or successful receipt of the body. >=20 > [Jon] To be continued in part 2. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Feb 3 00:09:46 2021 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 4966C3A15A8; Wed, 3 Feb 2021 00:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chFjqeneV9ZI; Wed, 3 Feb 2021 00:09:42 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273033A15A7; Wed, 3 Feb 2021 00:09:42 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4DVvVD4dpFz1y9n; Wed, 3 Feb 2021 09:09:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612339780; bh=11yR63W3Lvdvo8F32r+kLY9kxL9WAH+Rk8D/VrlmtT4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=vAnH2aLrcrDx6P2pytLZIpNMNrVPfUpbf63zUS2DTzshTnslXj1pZ2ATSu9XHOee3 l66y5C4xqf/7JKhOga1IstZgJxWu08Z4lzs0oUnVo4r0sa7A5CD/9/Ajmpe/oFlRvy 5PsjC0lpCXGn3kAeCkAzVQyw3VFDQyPpexO0b4tZ4nXnZ7ri1dvkMxDPIapqGx/YmU QybaPZhcZxLW6zCumUDh1HstCoI7CyJ2UfPwBxhMqqlNVMJjIeARcjuCANRTxasvbJ 5UTmdKz3dlbKip9vJfmAbGw1k8uu2uobSQkXwR8X4yyuBQYqOge8yDV3gHmikh3KrW mkqpci0V8B4Qg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4DVvVD3nDhzDq7Q; Wed, 3 Feb 2021 09:09:40 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (No-Response) Thread-Index: AQHW2RFADVSDS+77YE2WSWeKTWYPaaoEtA4QgEGgIIA= Date: Wed, 3 Feb 2021 08:09:40 +0000 Message-ID: <23740_1612339780_601A5A44_23740_98_8_787AE7BB302AE849A7480A190F8B9330315C6374@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@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] WG Last Call on draft-ietf-core-new-block (No-Response) 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, 03 Feb 2021 08:09:44 -0000 Christian,=20 As a follow-up on this issue, we finally went with an approach that does no= t require No-Response. We do have the following to avoid extra delays, e.g.= ,=20 For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. Otherwise the server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload), before sending the 4.08 (Request Entity Incomplete) Response Code for the missing payload(s). If the repeat request count for a missing payload exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and stop requesting the missing payloads. Or=20 For the client receiving NON Q-Block2 responses, it SHOULD send a 'Continue' Q-Block2 request (Section 3.4) for the next set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent the server unnecessarily delaying. Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload), before sending the request for the missing payload(s). If the repeat request count for a missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the partial body and stop requesting the missing payloads. Cheers, Jon & Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 15:10 > =C0=A0: Christian Ams=FCss > Cc=A0: draft-ietf-core-new-block@ietf.org; core@ietf.org WG > (core@ietf.org) ; dots@ietf.org > Objet=A0: RE: [core] WG Last Call on draft-ietf-core-new-block (No- > Response) >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] Envoy=E9=A0: > mercredi > > 23 d=E9cembre 2020 10:52 =C0=A0: BOUCADAIR Mohamed TGI/OLN > > Cc=A0: > > draft-ietf-core-new-block@ietf.org; core@ietf.org WG > > (core@ietf.org) ; dots@ietf.org Objet=A0: Re: [core] > WG > > Last Call on draft-ietf-core-new-block (No- > > Response) > > > > Hello Med, > > > > > The text we have in the draft does not preclude No-Response (or > > any > > > solution that will be endorsed by the WG in the future): > > > > > > If both endpoints support No-Response, they can use it as a > > "signal in > > > the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last > > sentence. > > > > > > As we don't recommend No-Response (for reasons echoed in your > > > message), it is not worth to include much more details on how > > > No-Response can be used. > > > > The only reason for No-Response I echo in my mail is the downref, > and > > merely showing how these can interoperate does not create a > normative > > reference. It's quite a stretch to assume people would read > "requires > > an additional signal" as "could use No-Response". > > > > Working group documents time and again have outward references like > > "One way of doing this is being explored in [draft-...]", which is > > clearly non-normative, but at the same time allow the reader to get > at > > least > > *some* indication of how things are meant to be used. >=20 > [Med] Simply adding a pointer would work for me. We can go for the > following change: >=20 > s/an additional signal in the MAX_PAYLOADS packet/an additional > signal in the MAX_PAYLOADS packet (e.g., [RFC7967]) >=20 > > > > What makes things worse here is that as long as this specification > > does not mention No-Response at all, it is not ensured that it > > interoperates well at all with No-Response; thus even if a reader > can > > make the jump, they'd have to figure out on their own that it's > > probably best if No-Response overrides the response behavior of Q- > > Block. >=20 > [Med] Here is where I disagree. As we don't recommend any solution > (including No-Response), it is not up to this document to discuss how > to graft the various pieces. >=20 > > > > > The use of NON is thus superior but requires > > > an additional signal in the MAX_PAYLOADS packet to seek for > > a 2.31 > > > (Continue) from the peer if it is ready to receive the next > > set of > > > blocks. > > > > I missed that in the part where I'm asking for whether 2.31 would > be > > produced. That paragraph really opens more questions than it > > answers: If Q-Block is intended to be usable with something to > signal > > that now would be a good time for a response, then this almost > > contradicts the "2.31 > > (Continue) Response is not used in the current version" statement. >=20 > [Med] That statement is factual. It is meant to remind that 2.31 is > legal and that it is there as a provision for any future optimization > that would require it. >=20 > > > > Either this is a possibility already planned here, then the 2.31 > cases > > should be properly described, even if it's just with a "but > requires > > additional signaling, which for example can be achieved by > combining > > this with No-Response:0". Or it's not planned out here, then the > 2.31 > > mentioned in the quoted note is more of a note on future updates of > > Q-Block that would be necessary to leverage that combination (but I > > don't see any such document happening). > > > > Best regards > > Christian > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Feb 3 00:15:15 2021 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 0A1E63A15B2; Wed, 3 Feb 2021 00:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBPh3zvDsUOv; Wed, 3 Feb 2021 00:15:12 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C623A15B1; Wed, 3 Feb 2021 00:15:11 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4DVvcZ1g8Rz8spq; Wed, 3 Feb 2021 09:15:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612340110; bh=kNH9nckd/4cQZlExKBuTuBQrThYHC3+e+qbDySLQUFI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UdWZU2VGTiCzpD/DCJ7JhUbOetuxWfuxRAZpeolSVytwV3GzPRu3AogBW+zdGVrcY mszmgHfJFTKdCJR4nEFqvz975G6SYv+Wb7sDpesaTgu2mnmdU7OVE6BGA2Gi8mHdR9 2Ausra0q+fqAH44xkVVdFRLlDQSOfr4vhiaFAUSq0LAyMSOMeTWVvqshdHd9dpzaVP 4S+8BOipRU5f90rg2Bxl3+fVRF6OKENdONQ3mVbuGeezNkAzyUgd7pusK0m12Xsmd7 6mF35/IVq7vf4um7mW2xW/VstBnnVDTJrO7731fkyLzvT9ocZOyKY/CCmd/7GF1NFB kPtlR8HorF1sQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4DVvcZ0VFDzCqm4; Wed, 3 Feb 2021 09:15:10 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" , "draft-ietf-core-new-block@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) Thread-Index: AdbZC/aiJQkTFqGDTZuAOZL1HdyQ6wg+A0MA Date: Wed, 3 Feb 2021 08:15:09 +0000 Message-ID: <15830_1612340110_601A5B8E_15830_95_1_787AE7BB302AE849A7480A190F8B9330315C6397@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) 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, 03 Feb 2021 08:15:14 -0000 Re-, FWIW, we significantly updated the congestion control as you can see in: ht= tps://tools.ietf.org/html/draft-ietf-core-new-block-06#section-6=20 We finally added this text to point to how some parameters can be tweaked b= y an application:=20 Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customized defaults as discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS, NON_MAX_RETRANSMIT, and NON_TIMEOUT can be negotiated between DOTS peers as per [I-D.bosh-dots-quick-blocks]. We believe that we addressed your initial concern, but having an ACK would = be appreciated. Thanks.=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 10:14 > =C0=A0: Christian Ams=FCss ; draft-ietf-core-new- > block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: RE: [core] WG Last Call on draft-ietf-core-new-block > (Congestion Control) >=20 > Re-, >=20 > You are completely right that the default probing-rate is to be > increased for the DOTS case. FYI, this is why we went with the > following in RFC8782: >=20 > | Given that the size of the heartbeat request cannot exceed > | ('heartbeat-interval' * 'probing-rate') bytes, 'probing- > rate' > | should be set appropriately to avoid slowing down heartbeat > | exchanges. For example, 'probing-rate' may be set to 2 * > | ("size of encrypted DOTS heartbeat request"/'heartbeat- > | interval') or (("size of encrypted DOTS heartbeat request" + > | "average size of an encrypted mitigation > request")/'heartbeat- > | interval'). Absent any explicit configuration or inability > to > | dynamically adjust 'probing-rate' values (Section 4.8.1 of > | [RFC7252]), DOTS agents use 5 bytes/second as a default > | 'probing-rate' value. >=20 > We also allow DOTS peers to negotiate the transmission parameters > (and probing rate) with the following as default: >=20 > "The RECOMMENDED values of > transmission parameter values are 'ack-timeout' (2 seconds), 'max- > retransmit' (3), and 'ack-random-factor' (1.5). In addition to > those > parameters, the RECOMMENDED specific DOTS transmission parameter > values are 'heartbeat-interval' (30 seconds) and 'missing-hb- > allowed' > (15)." >=20 > We avoided to include a pointer to these details as these are > application-specific and that, even if the draft is motivated by the > DOTS use case, other applications can make use of the new block > functionality. >=20 > For NSTART, we already have the following: >=20 > " NSTART will also need to be increased from the default > (1) to get faster transmission rates." >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] Envoy=E9=A0: > mercredi > > 23 d=E9cembre 2020 06:01 =C0=A0: draft-ietf-core-new-block@ietf.org > > Cc=A0: core@ietf.org WG (core@ietf.org) ; > dots@ietf.org > > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block > > > > * Also on parameters: This document is describing flow control > stuff > > around a situation CoAP was not originally designed for. Wouldn't > it > > make sense to include a set of parameters (PROBING_RATE, > > MAX_LATENCY, > > ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > > PROBING_RATE will be left to 1 byte/second for any DOTS > application > > using this (for sending 10KiB in the initial 10-package > MAX_PAYLOADS > > burst would mark that connection as unusable for about 3 hours if > > they > > all get lost), so better give justifiable numbers here than rely > on > > implemnetors to come up with unreviewed numbers or disregard > > PROBING_RATE altogether. > > > > I don't know if it needs additional justification, but an > increased > > N_START may be justifiable there. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Feb 3 03:03:08 2021 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 59B0D3A0942 for ; Wed, 3 Feb 2021 03:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC2VTxIhRbri for ; Wed, 3 Feb 2021 03:03:03 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140085.outbound.protection.outlook.com [40.107.14.85]) (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 ADEAA3A093D for ; Wed, 3 Feb 2021 03:03:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iyLzk3SKK8WdQpsPd7kIDAPQJWdsDafTGmzHFVM3AfmBHHjjKUpSm3CYtCxc7+0g6Vp3UsN0jdcDbzgk5lE3L9ohQ3Hzgf0ktRsR/wwMoKe3TchD8MVtk9+jzV2yoEKQKymP+tl0QqitdLKB1dkzdw22ARituw9jjLp/BJRc7tFOkczCuJ6eCLm6iIEnt7AOJhYRKYg8Yo/z44pDW3ArhQXnKPSl0lFM0G8r0QvFYGEfZ5DuqAzGJLGEDuKnXeX2P12OVdlSI4gtjCANvWpAzi/gI0eE/YxNWsA2wux0oXjoGFE9Y9iTWvyq9zQKqvFxpcBuqrVnrFevv66pb2xkgw== 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=DXmDfMRSfi2jrKbmMK8DFZ3R+gLlxyHk7MtgTZwmtBI=; b=QA//7ZS2FJ7l4iPOH4i6d0AHIIxB8KOJQ6r5rECgdYpIeCR40esKSfnACtA5SaWI+a7/QjgcOglFt0CjO13vS8kxYMzqSd47fF0svSvDZGbumgDZ8BAwIuqyoxaVS4w3u88URDo/F1W29ITik95WamxNK6wxID3YdmiMabsy3xwSIzX1CZz5VyIE+tM/gsquRq5HqgyddyH0xlBgQVOVpxgHl13FPTBAy07dzhEZIXISLcoealyXBfjlRnMI6B3aiuyFtrByE13jSJ1qP6+LwcdH49Ac4e7qnUN9zujPAD2fQU7i9uaaKgodZIGlNxR8ypdufoQiwIpNKEs8d0IhZQ== 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=DXmDfMRSfi2jrKbmMK8DFZ3R+gLlxyHk7MtgTZwmtBI=; b=Wvy89LfhuH5Pj9Cbh/BjqZt8/ersUYuRz/Q3fPcZAYQm71tTuNLK3ZD4a4qEukDtbtbb3o3GypAbEKxEOAiJGmMsi0Z6pbpkDNKbG8orM1Z+BaNHml5GCcnW50Q/oxGZYASgqWntSPdQ7dQCVXvWug68Qoo01ZzvnkiNufHODf4= 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 DB8P189MB0747.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:121::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17; Wed, 3 Feb 2021 11:03:00 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%9]) with mapi id 15.20.3825.020; Wed, 3 Feb 2021 11:03:00 +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: Date: Wed, 3 Feb 2021 12:02:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r8yeTdFG1zXt62cYwzlwXML7VBMEKoQAB" X-Originating-IP: [45.12.220.180] X-ClientProxiedBy: HE1PR0802CA0010.eurprd08.prod.outlook.com (2603:10a6:3:bd::20) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.5] (45.12.220.180) by HE1PR0802CA0010.eurprd08.prod.outlook.com (2603:10a6:3:bd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17 via Frontend Transport; Wed, 3 Feb 2021 11:02:59 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 22a87fd1-d5a0-44dc-ed0a-08d8c83344f1 X-MS-TrafficTypeDiagnostic: DB8P189MB0747: 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: qXnEjHI6TmnivmMgr6rY262ndRx1Jt0tkzihVwtqrSPgX0TkLJK5llRwgANqjuQu7fOz02FbDejKKqfcgP0qGpG/ibcdgBWFBHeBG2GOd/wNeYubOVn493nK6BmGFiTe9Xi2Ykr7cVf19q3TlGeEy8PFmqkNlcmZplcc/4WG5oDjQAyfB/B6sYw9Wfnbl0amy90guZ+1+uZ6jITboVl5iFcBiUvCsU/Tlhs8zHX+tdgdz1ILacN9Lg4eALnUj0ehRtaezDNSLt0WBrTicNFKsBop6Aj21bHaWuuIBmFEj+ESfv/qi32GM268zNJU6s/XjXFOgRFDylC9ClZoZZxTqC8PfUiqplBlfOPdtrn4vMOMc6yDmHPi6QZOGSki4LhAmYNwBqXD0rhyqN43znRcb68LTADzVwb1qJGaR8h5kLGkpVrJ0y7azivI/ZE0rOVsbEFwk2uWVYIU6J2CW+xsn05ird7Dvj00QbXjPTfcCdbmQuIl+OrYPc8GTqBRNDH/OEzV66adxyYyL83lydCNcmkbBcdpBF7LCGFcJADS7417RKisS7x1Po/7kt+lAQyKCZ3HpPOXYWdeycb/FG7IoVSODyd2pWOrgP//DiiIyEILq99BB/Rntud8ujbS/qmmp4NqaUXzKGkDhthufHURASV/iIYK5PlAHEaSrmilj0fQ2mX3Get2U0krfAMxV9KJnTw8Ty5Ku5WH2bsDs/1RSA== 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)(376002)(396003)(39830400003)(346002)(36756003)(2616005)(508600001)(26005)(34490700003)(31696002)(16799955002)(186003)(86362001)(6666004)(66946007)(6486002)(33964004)(16576012)(83380400001)(8936002)(16526019)(2906002)(235185007)(52116002)(44832011)(21480400003)(66556008)(6916009)(66476007)(31686004)(5660300002)(956004)(8676002)(966005)(66574015)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?eXRyTHVPa1JiandKSHlBdzhBdnBaL0xlV01MMW1JZXJmSWNaTVczb2hpdi9r?= =?utf-8?B?R3o4T3UwVGpObWZ0MHJNZE1mcEtGZjdIRjZzT3NOK2xHWGFCcVl4M3JEMHdK?= =?utf-8?B?a3ZzekQxRk01clM2T2Y0eWRCeElTdC9aeHZuclZ0RFIxdjhpUjBOcHNHb0lM?= =?utf-8?B?VlRuWHMwOWsyckNZOTlFSXBBeFFSeEkvOHBnbW1CZTRjU1gybGE4R1J6R08x?= =?utf-8?B?VWkxUVJ2YjRZU1d5QWlwdHduaEhKZVdsTVNxK2YxWUFCZFMwRUFEVlBmSWlS?= =?utf-8?B?MlY5TEJVWDFtcXZEeEp3MGx4NEJwOGVRQUdZMzM3QjBnczBnc1d4TE9xZWgy?= =?utf-8?B?dno1VkZLNFF6VEl0em9vMERYYVpsamdseGJNSjFDWFNlM0J2OXplK2JNOVdi?= =?utf-8?B?QlFBaFl0NytHLzE0UTNiUCs2Y1lDMnNaTGpLOGFySlBCdnNlNytJTVVLeW1W?= =?utf-8?B?aC9kQU8vdUlWNnY0c1M1T0xUNmxMRlB5blpSbExDY1RyemhKL1J5K1Y1M3N6?= =?utf-8?B?NnI2Q3BQVWFibnlvWHJNRWUxalJacGtUWjNXOThodXNsM2JRSkdoVVY3N0VZ?= =?utf-8?B?eDloSXVKa0JGSnlpR0dONGxxVzVmWm1DemZtTTkwenVQaS9wdmxCS09YOU9K?= =?utf-8?B?bElITW4vbXp1eG05Njh1ZlFJQ0k3MFFuR1pJakdsRVFiS1ZRekM3RXR6SmU3?= =?utf-8?B?cHdpclZlVU5yUS9MY0EvcmM0bTZDUHhPVklIalo1S2ZhZkpmU3pLOEV5d3pB?= =?utf-8?B?Ym5MUUxPei9WcE9IQkJvbUc2WnNYQXJjcXUweWU2c0xXMmhJRkJGekY1bVlj?= =?utf-8?B?YzF5KzZxdWY1bkUxQlFSSGxmVjR2d2RHS2ZNR3R4SEVTaG9KZWpHRytUY24z?= =?utf-8?B?a2plUVBjblZGTHdUSEpHbklJenY3VVVMOGo5NmI0SmVkZzR6KytsRHNTSldq?= =?utf-8?B?ZFZFY1VxejhjVm5rd2N0UzhzM1hrQ1E3L09VcUJPaDRqSnBVL3lxL3dmSnJM?= =?utf-8?B?MnFoOHZGSHMrMUJsOGpBT2dTMGJIMkhoZVZLTFlmMUVtaXB6bHkrbytUbjhW?= =?utf-8?B?OTdTYnJGWDFPTTlXNDNiSmdJNW16M3orNzE1ODliZUIvRjYvT1dhbFFPbllh?= =?utf-8?B?WS9qNUsrODJNZEhPUUdnVjV4U24ycW83VXNNd25GREpRTmZGZTBTZ3Y3SkdH?= =?utf-8?B?cGZudWxQMktPS0cxOGlTNXFWdllpMDU0cUtOeTgyOWs3WnFEb3gyMEFqYU1k?= =?utf-8?B?OU9oNWJMTmV6UGJaREgzbFIxWll4eUhTYitmVitFUEphSDM4NE80S2ZoTTV0?= =?utf-8?B?N0hNTWtmWW56ZFZQdmxvMjNrcDlyWTBOc0Voa0J6Kyt2aTF3d1pDcFNuREda?= =?utf-8?B?bmROMW13QzFQUVVKd2lsVTgwMG9tTWJKRk55RW56Y09WZUhBL25vQndnVGpq?= =?utf-8?B?Z0ZaNDNJQlFBckFQOGFBYkNkNkROcVc1YzhHRHV5Y3VPaFAyYWpaK3I3Ni9T?= =?utf-8?B?elkxT3NSTFdvK2NoWkZ4ZEtWUk1XRVAxL1VYWlN5amVuVEdaaHpHSHNlWkU3?= =?utf-8?B?NlRmUXBGUTlFaGpHL05iZmx6aEVWWkRQYVNqZ28zY2RBb05NYnZ1L0Z0Rk9M?= =?utf-8?B?WWVqb2QrdXU4d3hkaE55NzFTeGRPbTVOaEVnb1Bna3VuWEhxWk5vdHRGV0FB?= =?utf-8?B?c0d5bHZnZjlYYTJwZ3B4bFJNVlJIMTFYNkJjOTNGVGd0SjlGVlU2TXQ4RHVj?= =?utf-8?Q?hNZ8VbxCT0l3hnJzZG4T3ZN+CuVhwmbsQJ5CbL3?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 22a87fd1-d5a0-44dc-ed0a-08d8c83344f1 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2021 11:03:00.2082 (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: tp5wTxg75+pEEZHFrXyUmQb+GNYqsJwnvGGD7mLLNW5f66D2PqzuDfcNlbCb+8e8XGWglpy/E9Wsgy3zr1Ib2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0747 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-02-04 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, 03 Feb 2021 11:03:06 -0000 --r8yeTdFG1zXt62cYwzlwXML7VBMEKoQAB Content-Type: multipart/mixed; boundary="S3HmKhb1iKtrrWQKG3ErRGFjfaVQp4AhN" --S3HmKhb1iKtrrWQKG3ErRGFjfaVQp4AhN 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 15:00 UTC we'll have a virtual interim via Webex. The agenda is to discuss progress and way forward for the Dynlink document [1], as to new attributes, usage of proxies, and other open issues [2]. Please, find below the information to join the meeting. Best, Marco and Jaime [1] https://tools.ietf.org/html/draft-ietf-core-dynlink-12 [2] https://github.com/core-wg/dynlink/issues =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-02-core?bo= th Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm19b9f925e95745c07e366296aa99a8e= d Meeting number: 178 817 8507 Password: constrained More ways to join Join by video system Dial 1788178507@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: 178 817 8507 --=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 --S3HmKhb1iKtrrWQKG3ErRGFjfaVQp4AhN-- --r8yeTdFG1zXt62cYwzlwXML7VBMEKoQAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAagt0ACgkQ7iZktA5Y 2kOQLwgAiA+KD/9OyOgMSYSmSjais3nMV70YeVuJGa+SR1PnC6ll6/MxZIIOuL+A 9CTN+xyXN7UqMvbAdSFr85BcvbtX5uvJZBkzZAixeQEztaP7sKZ6pTMhd59GOSbR RmaINAkkEPzV6NpZ+dypm2nAjq8zpJ8yWlzG+bWijNNHUEzPu1ei22o/FAdAG9y3 TYJdhh8oDoB71s7v/O0vH55VP6nptTIVqUUCVNY/IM1KGzWxYyoUMCgWPJ9IlpJ4 nvb8zyzf/Q5LdAS+69HQb3WJuygakv44tVCY6mIbF3jPswfHK8Qwdxh0CwzJ5S+M UcQlrmyvDNiNW3y74MZ1cehXeaYZVQ== =i8rD -----END PGP SIGNATURE----- --r8yeTdFG1zXt62cYwzlwXML7VBMEKoQAB-- From nobody Wed Feb 3 20:47:47 2021 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 AB0ED3A0CF6 for ; Wed, 3 Feb 2021 20:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO7np75uByTk for ; Wed, 3 Feb 2021 20:47:42 -0800 (PST) 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 34D643A0CEB for ; Wed, 3 Feb 2021 20:47:41 -0800 (PST) Received: from [192.168.217.152] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DWQyh1hC1zyWH; Thu, 4 Feb 2021 05:47:40 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 4 Feb 2021 05:47:39 +0100 Message-Id: To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: [core] draft-ietf-core-comi-11 shepherd 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: Thu, 04 Feb 2021 04:47:46 -0000 In my shepherd review of draft-ietf-core-comi-11, I have found a few = points that probably need some WG action before we can submit this draft = to IESG. (I also have submitted a PR addressing some nits, = https://github.com/core-wg/comi/pull/1 .) Specifically: # Major *** 5: This whole section is rather disappointing. What does this really do except for pointing at RFC 7959? Is there any recommendation in how to work around the race condition? The recommendation to use indefinite length is not solving any problem (does not work except in very fortuitous cases). *** 6.2.2 How does the pagination work, then? This SHOULD is not actionable. *** 7: This creates confusion between 4.01 and 4.03 # Minor *** 2.2: While it is not clear whether there will be a SID 0, the text seems to imply that this would be encoded in the empty string. Should it rather specify a single "A=E2=80=9D? *** Appendix A: Updated to reference RFC 8949 (see PR). Do we need a new module version after this edit? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 5 09:09:50 2021 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 4E92D3A138C; Fri, 5 Feb 2021 09:09:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eliot Lear via Datatracker To: Cc: core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161254498927.30549.15609771383242038227@ietfa.amsl.com> Reply-To: Eliot Lear Date: Fri, 05 Feb 2021 09:09:49 -0800 Archived-At: Subject: [core] Iotdir telechat review of draft-ietf-core-echo-request-tag-12 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: Fri, 05 Feb 2021 17:09:49 -0000 Reviewer: Eliot Lear Review result: Ready with Issues All in all, a very nice piece of work. I'm not reviewing for other than IoT issues. An issue in Section 2.2.1 (you decide if it's minor or major or really just a question): I do not understand why the Echo option requires opaque data, and why this should not be standardized, as it seems that the behavior you are seeking is standardized. As you give two example methods in the draft, why not reserve a few extra bits to specify which method is in use? This would also allow you to drop the necessary callback routines in libraries. Nit: The last sentence in 2.2: is this meant to be limited to OSCORE or all uses of DTLS? I found the inner/outer text confusing, and that a diagram might actually help. From nobody Fri Feb 5 09:53:15 2021 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 526373A0D9C; Fri, 5 Feb 2021 09:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk2ezgDXJ9cy; Fri, 5 Feb 2021 09:53:07 -0800 (PST) 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 E49963A0DA1; Fri, 5 Feb 2021 09:52:55 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2D40C406FB; Fri, 5 Feb 2021 18:52:53 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DF392FD; Fri, 5 Feb 2021 18:52:50 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:668a:7d9a:cc8d:9b3c]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4DE4444; Fri, 5 Feb 2021 18:52:50 +0100 (CET) Received: (nullmailer pid 2070748 invoked by uid 1000); Fri, 05 Feb 2021 17:52:48 -0000 Date: Fri, 5 Feb 2021 18:52:48 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Eliot Lear Cc: iot-directorate@ietf.org, core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org Message-ID: References: <161254498927.30549.15609771383242038227@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wuXfb5e0uzNMGTly" Content-Disposition: inline In-Reply-To: <161254498927.30549.15609771383242038227@ietfa.amsl.com> Archived-At: Subject: Re: [core] Iotdir telechat review of draft-ietf-core-echo-request-tag-12 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, 05 Feb 2021 17:53:10 -0000 --wuXfb5e0uzNMGTly Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Eliot, On Fri, Feb 05, 2021 at 09:09:49AM -0800, Eliot Lear via Datatracker wrote: > I do not understand why the Echo option requires opaque data, and why this > should not be standardized, as it seems that the behavior you are seeking= is > standardized. As you give two example methods in the draft, why not res= erve a > few extra bits to specify which method is in use? This would also allow = you to > drop the necessary callback routines in libraries. I don't see which callback routines would be involved here. In current implementations, the value is passed around as an opaque buffer to the component that is taking responsibility of the Echo option. If multiple components inside the server produce Echo values and need to tell them apart, the server is of course free to use the few bits as it needs them (a pattern that's also used with similar opaque values like the tokens). But maybe I did not quite get the point about the callbacks, could you elaborate? The behavior we are seeking and standardizing is the client's; servers can use the option as a tool for a variety of applications (those in section 2.4 and more) which can all work using the same generic client behavior. None of the envisioned applications have any data in there that'd be relevant to the client, and worse, if the client were to understand it, it could try to construct values, and all of a sudden the security considerations for applications of this, like server state recovery, would grow *way* more complex: From a simple rule ("Only send an Echo value if you ever received it from that peer before") that the server can rely on the client to obey, it'd grow into requiring the client to understand when it may or may not tamper with the value. If a particular application needs the client to understand a value of an Echo-like value, it should take "the few bits" out of the option number. (For example, I'd be happy to review a draft on sending a realtime timestamp in requests -- but that would cover quite a different set of use cases, and need vastly different security considerations). > The last sentence in 2.2: is this meant to be limited to OSCORE or all us= es of > DTLS? I found the inner/outer text confusing, and that a diagram might > actually help. That sentence is merely illustrating the corner case exception, I'm confident we can enhance readability here a bit by not referring to DTLS. (It is general to DTLS in that in DTLS all proxies always see the CoAP options; it says something about OSCORE is that (DTLS or not), proxies see the outer options only). On the general inner/outer diagram ... hm, we could add something for sure, but I'd be worried that it'd distract by putting focus on a topic that really belongs to OSCORE. I'll leave an issue open in the authors' tracker to revisit this when more reviews have come in. Thank you for your input Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --wuXfb5e0uzNMGTly Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAdhewACgkQOY0REtOk veG02A//YoVuuttNnddqxZ3smUp465qmidvzeD4Pwg/mW+1yc/cXjm2gPxmQiIip SnHUrTpHoHzpMRfKq1lWNlDMdkPQ4/9CnalUJX0r0O5+KT7cjVRAFkNm2T9nK4Tv aelYKDytyYdXqKu7Vly0LSur4p3SkqaJNOFQxwocf9PsuYw5OhSi2WY4beC+V+yB 5fSuVMFtKvvvc1SHnhkf2FO8Kk5/tCubWtUgESDONheGjvHmHWxGLWrJf3zlHTn2 +sBKhdoS41mJOETiLYAQMm531F3/0OToD+LykEF4uJ+oCBszViBB7ictVdkAZPCE DYqfhyAaxuF2nHIcYKE6VPWkgaNSr2FOtZEhLUJEJTbi1CyRs7N0sDYUzL4pvWPt leCCexBeigqhv4MPJyNIpRo4ZdIRUf6NuBgHoztS6zHxca9SEWPqs65oHlonXl9x ik5spKep9lQ9+UOCKuZbdLK6lTncjpkwwnEMZtZkHSLBSpOHlK/5OfbivcOOxd5S P11nt/SOmJLNXVhGtM5kXPVFrg7r/Ernw3VDDuEYihqzw2HDWKVqfEFT0oE+6I0T 8BeHzA7W9Ukme7WdlkDmA3cnLCc7N5JG6I8wqTUz8xWsYm+jVPt0Nc9Vy3aaWC3B nwVyNuglKdZCM9epgVDqiHno47d6EOIsWC/bgKaGTKd3TvnG8Ak= =H+x9 -----END PGP SIGNATURE----- --wuXfb5e0uzNMGTly-- From nobody Fri Feb 5 10:53:38 2021 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 4009C3A0E7F; Fri, 5 Feb 2021 10:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 f49C1XriaB2b; Fri, 5 Feb 2021 10:53:26 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14EF3A0E7E; Fri, 5 Feb 2021 10:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4365; q=dns/txt; s=iport; t=1612551206; x=1613760806; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=WK9d7kYt+slPN+Hz6il8t6momXCjm8xCpEUM7oBnxRs=; b=Vmg0dVjfLv6cwCr0gjxAhmRGX+E5Kox/tynNDOsK25MM8XX3xDBubjV1 uO+1+yQLkjSHD+hJ3LslIyK4rhApAmBemvVIsd38KztMP8motprx/lau2 TVe59sCUL1tWIhj19TMJR0dt0dX9355LxXCDMdqVbhMBI/3/YbQKiPGa+ w=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0D6AAAykx1glxbLJq1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4F8gXsBJxIxhEGJBIhYA5xDBAcBAQEKAwEBLwQBAYRLAoIBJjgTAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGQ4VzAQEBAQIBI1YFCwsYKgICVwYTg?= =?us-ascii?q?yYBgmYgr1t2gTKFWYUCEIE4gVOEFVCHC0GCAIERJxyCVj5rGQGDEAsGgzE0g?= =?us-ascii?q?iwEgkBEKjs4LywKDE0mAQ0CCg0GAUKcT5sugRSDBIMpgTqXIAMfkzWPbbFQI?= =?us-ascii?q?EaDcgIEBgUCFoFtIYFZMxoIGxVlAYI+PhIZDY4tDAIJgQIBDI0ZQAMwNwIGA?= =?us-ascii?q?QkBAQMJiU+CSQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,155,1610409600"; d="asc'?scan'208";a="33246150" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Feb 2021 18:53:21 +0000 Received: from [10.61.205.119] ([10.61.205.119]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 115IrKEg032508 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Feb 2021 18:53:21 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BC0DFABE-46C2-42B4-94E0-3D353F80ECBE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 5 Feb 2021 19:53:17 +0100 In-Reply-To: Cc: iot-directorate@ietf.org, core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org To: =?utf-8?Q?=22Christian_M=2E_Ams=C3=BCss=22?= References: <161254498927.30549.15609771383242038227@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.205.119, [10.61.205.119] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [core] Iotdir telechat review of draft-ietf-core-echo-request-tag-12 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, 05 Feb 2021 18:53:29 -0000 --Apple-Mail=_BC0DFABE-46C2-42B4-94E0-3D353F80ECBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Christian, Thanks. This answers my questions well. Regards, Eliot > On 5 Feb 2021, at 18:52, Christian M. Ams=C3=BCss = wrote: >=20 > Hello Eliot, >=20 > On Fri, Feb 05, 2021 at 09:09:49AM -0800, Eliot Lear via Datatracker = wrote: >> I do not understand why the Echo option requires opaque data, and why = this >> should not be standardized, as it seems that the behavior you are = seeking is >> standardized. As you give two example methods in the draft, why not = reserve a >> few extra bits to specify which method is in use? This would also = allow you to >> drop the necessary callback routines in libraries. >=20 > I don't see which callback routines would be involved here. In current > implementations, the value is passed around as an opaque buffer to the > component that is taking responsibility of the Echo option. If = multiple > components inside the server produce Echo values and need to tell them > apart, the server is of course free to use the few bits as it needs > them (a pattern that's also used with similar opaque values like the > tokens). But maybe I did not quite get the point about the callbacks, > could you elaborate? >=20 > The behavior we are seeking and standardizing is the client's; servers > can use the option as a tool for a variety of applications (those in > section 2.4 and more) which can all work using the same generic client > behavior. >=20 > None of the envisioned applications have any data in there that'd be > relevant to the client, and worse, if the client were to understand = it, > it could try to construct values, and all of a sudden the security > considerations for applications of this, like server state recovery, > would grow *way* more complex: =46rom a simple rule ("Only send an = Echo > value if you ever received it from that peer before") that the server > can rely on the client to obey, it'd grow into requiring the client to > understand when it may or may not tamper with the value. >=20 > If a particular application needs the client to understand a value of = an > Echo-like value, it should take "the few bits" out of the option = number. > (For example, I'd be happy to review a draft on sending a realtime > timestamp in requests -- but that would cover quite a different set of > use cases, and need vastly different security considerations). >=20 >=20 >> The last sentence in 2.2: is this meant to be limited to OSCORE or = all uses of >> DTLS? I found the inner/outer text confusing, and that a diagram = might >> actually help. >=20 > That sentence is merely illustrating the corner case exception, I'm > confident we can enhance readability here a bit by not referring to > DTLS. (It is general to DTLS in that in DTLS all proxies always see = the > CoAP options; it says something about OSCORE is that (DTLS or not), > proxies see the outer options only). >=20 > On the general inner/outer diagram ... hm, we could add something > for sure, but I'd be worried that it'd distract by putting focus on a > topic that really belongs to OSCORE. I'll leave an issue open in the > authors' tracker to revisit this when more reviews have come in. >=20 > Thank you for your input > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom --Apple-Mail=_BC0DFABE-46C2-42B4-94E0-3D353F80ECBE 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAdlB0ACgkQh7ZrRtnS ejNlvQf/fWQF4+/I+IZJiZg3w8WHlYb5cmtebHVT/IgUovKmF14M12sJ4atm9gmk qxq+XrA0eha0bUiy70E46BDy6gEUx7mNth6Eax5JqOv7wsN8gToF7eKDfVkNx+k5 8lULJiq9jCZ+xpM5JV7QbkQq+k1Fbj4j+H7YM7r92GdcYsBJFM5azi8ty/UqFoM7 2+6AwKUxvDfoRS2DEF1RYr9f1zWA8SQLIaIDqY0fZzaGwGbQin52z/QwOXbu8luZ S2YE61WwPh2AkcRcOLdPXi2avPAy3yL+OxFGc/MHKntodIEhTS20H6Itr2y0Tfic Ou82I6AxZ1yqHinxgz/xrsyINbbxZQ== =tVb8 -----END PGP SIGNATURE----- --Apple-Mail=_BC0DFABE-46C2-42B4-94E0-3D353F80ECBE-- From nobody Fri Feb 5 11:50:30 2021 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 22F793A083E; Fri, 5 Feb 2021 11:50:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jaime Jimenez via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Carsten Bormann , cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, iesg-secretary@ietf.org Message-ID: <161255462812.1888.11041116939699519781@ietfa.amsl.com> Date: Fri, 05 Feb 2021 11:50:28 -0800 Archived-At: Subject: [core] Publication has been requested for draft-ietf-core-yang-cbor-15 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: Fri, 05 Feb 2021 19:50:28 -0000 Jaime Jimenez has requested publication of draft-ietf-core-yang-cbor-15 as None on behalf of the CORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ From nobody Fri Feb 5 11:51:59 2021 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 0D78E3A0888; Fri, 5 Feb 2021 11:51:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jaime Jimenez via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Carsten Bormann , cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, iesg-secretary@ietf.org Message-ID: <161255471804.14811.931696889557617467@ietfa.amsl.com> Date: Fri, 05 Feb 2021 11:51:58 -0800 Archived-At: Subject: [core] Publication has been requested for draft-ietf-core-sid-15 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: Fri, 05 Feb 2021 19:51:58 -0000 Jaime Jimenez has requested publication of draft-ietf-core-sid-15 as None on behalf of the CORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-core-sid/ From nobody Fri Feb 5 15:44:52 2021 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 139BB3A0DE6; Fri, 5 Feb 2021 15:44:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <161256869105.2187.18183319486008145082@ietfa.amsl.com> Date: Fri, 05 Feb 2021 15:44:51 -0800 Archived-At: Subject: [core] Martin Duke's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) 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: Fri, 05 Feb 2021 23:44:51 -0000 Martin Duke has entered the following ballot position for draft-ietf-core-echo-request-tag-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 5.1 This is optional, but please replace "blacklisted" with "deny-listed". 6. What is a "preemptive" echo value? From nobody Sat Feb 6 12:08:41 2021 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 F19FC3AACFC; Sat, 6 Feb 2021 12:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZHiV2A_-545; Sat, 6 Feb 2021 12:08:30 -0800 (PST) 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 42ED13AACA9; Sat, 6 Feb 2021 12:08:30 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DY3JD3XcTzyjt; Sat, 6 Feb 2021 21:08:28 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 634334907.926748-17e87a86cffed8238202fae701ff26dc Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 6 Feb 2021 21:08:28 +0100 Message-Id: <6AEEC9C7-5057-41B1-8F4F-3FF467169415@tzi.org> To: Ace Wg , "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF110: DRAFT AGENDA 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, 06 Feb 2021 20:08:33 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF110. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that meet the eye this time are LAKE/RATS, IOTOPS/COSE, CORE/DANISH, in order from hurtful to disastrous (ROLL/SUIT and LPWAN/RATS are probably bearable). All times *on my agenda* are in UTC (the default page is UTC+0100). https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten MONDAY, March 1, 2021 1600-1800 Hackathon Kickoff Rm 1 GEN hackathon Hackathon THURSDAY, March 4, 2021 1700-1900 Technology Deep Dive Rm 1 tdd Technology Deep Dive FRIDAY, March 5, 2021 1600-1800 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, March 8, 2021 1200-1400 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF irtfopen IRTF Open Meeting Rm 6 RTG raw Reliable and Available Wireless WG Rm 8 SEC emu EAP Method Update WG 1430-1530 Session II Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things WG Rm 3 IRTF panrg Path Aware Networking RG Rm 5 RTG detnet Deterministic Networking WG Rm 7 SEC mls Messaging Layer Security WG 1600-1800 Session III Rm 2 ART *** core Constrained RESTful Environments WG Rm 7 SEC tls Transport Layer Security WG Rm 8 TSV tsvwg Transport Area Working Group WG TUESDAY, March 9, 2021 1200-1400 Session I Rm 1 ART webtrans WebTransport WG Rm 3 INT 6man IPv6 Maintenance WG Rm 6 RTG bier Bit Indexed Explicit Replication WG Rm 8 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 9 SEC *** rats Remote ATtestation ProcedureS WG 1430-1530 Session II Rm 3 OPS *** iotops IOT Operations WG Rm 4 RTG babel Babel routing protocol WG Rm 5 RTG detnet Deterministic Networking WG Rm 7 SEC acme Automated Certificate Management = Environment WG Rm 8 SEC *** cose CBOR Object Signing and Encryption WG 1600-1800 Session III Rm 3 INT *** drip Drone Remote ID Protocol WG Rm 5 OPS v6ops IPv6 Operations WG Rm 8 SEC gnap Grant Negotiation and Authorization = Protocol WG WEDNESDAY, March 10, 2021 1200-1400 Session I Rm 1 ART jsonpath JSON Path WG Rm 2 INT intarea Internet Area Working Group WG Rm 3 IRTF icnrg Information-Centric Networking Rm 8 SEC privacypass Privacy Pass WG Rm 9 TSV quic QUIC WG 1430-1530 Session II Rm 4 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Rm 5 IRTF qirg Quantum Internet Research Group Rm 6 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvwg Transport Area Working Group WG THURSDAY, March 11, 2021 1200-1400 Session I Rm 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 3 INT add Adaptive DNS Discovery WG Rm 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Rm 4 INT homenet Home Networking WG - Joint with DNSSD Rm 8 SEC saag Security Area Open Meeting Rm 9 TSV tsvarea Transport Area Open Meeting 1430-1530 Session II Rm 1 ART wpack Web Packaging WG Rm 4 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 5 RTG *** roll Routing Over Low power and Lossy = networks WG Rm 6 SEC openpgp Open Specification for Pretty Good = Privacy WG Rm 7 SEC *** suit Software Updates for Internet of Things = WG 1600-1800 Session III Rm 2 INT 6man IPv6 Maintenance WG Rm 4 IRTF*** t2trg Thing-to-Thing Rm 7 RTG rtgarea Routing Area Open Meeting - Joint with = RTGWG Rm 8 SEC secdispatch Security Dispatch WG Rm 9 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG FRIDAY, March 12, 2021 1200-1400 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 IRTF cfrg Crypto Forum Rm 7 RTG rift Routing In Fat Trees WG Rm 8 SEC *** danish DANE AutheNtication for Iot Service = Hardening BOF 1430-1530 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 3 INT add Adaptive DNS Discovery WG Rm 5 IRTF maprg Measurement and Analysis for Protocols 1600-1800 Session III Rm 2 ART httpapi Building Blocks for HTTP APIs WG Rm 3 IRTF coinrg Computing in the Network Research Group Rm 7 SEC *** ace Authentication and Authorization for = Constrained Environments WG From nobody Sun Feb 7 02:55:59 2021 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 8C7643AFBC2; Sun, 7 Feb 2021 02:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 YEs4IYmtWH7F; Sun, 7 Feb 2021 02:55:55 -0800 (PST) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E299E3AFBC1; Sun, 7 Feb 2021 02:55:51 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 117AtmwH022338; Sun, 7 Feb 2021 11:55:49 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 55A431D53C1; Sun, 7 Feb 2021 11:55:48 +0100 (CET) Received: from 83.53.211.205 by webmail.entel.upc.edu with HTTP; Sun, 7 Feb 2021 11:55:48 +0100 Message-ID: <5e1904ad67f56adb0001ee0d25488349.squirrel@webmail.entel.upc.edu> Date: Sun, 7 Feb 2021 11:55:48 +0100 From: "Carles Gomez Montenegro" To: draft-ietf-core-fasor.authors@ietf.org Cc: core@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sun, 07 Feb 2021 11:55:49 +0100 (CET) Archived-At: Subject: [core] Review of draft-ietf-core-fasor-01 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: Sun, 07 Feb 2021 10:55:58 -0000 Dear FASOR authors, First of all, my apologies for providing you with this review later than I expected. I hope it is not too late, considering that the cutoff date is quickly approaching! Thank you for the document. Please find below a number of comments and suggestions: - Section 1, first paragraph: "Both default RTO mechanism for CoAP [RFC7252] and CoCoA [I-D.ietf-core-cocoa] have issues in dealing with unnecessary retransmissions". CoCoA is still work in progress, and there are ideas on the table to improve it. Perhaps some different phrasing (for the sentence I highlighted here) might better support future updates of CoCoA. - Section 1, last paragraph: s/unnecessary retransmissions that a sender may have sent due to an inaccurate RTT estimate/unnecessary retransmissions due to an inaccurate RTT estimate - The RTO acronym is defined (preceded by its expanded form) twice in the document. Also, there are instances of both "RTO" and retransmission timeout throughout the document. Once "RTO" has been introduced, just the acronym should probably be used. - Page 3: "However, there are couple of exceptions when the RTT estimation is not available". Well, the second bullet after that sentence corresponds rather to "is not updated" than "is not available". - Page 3: "- At the beginning of a flow where an initial RTO of 2 seconds is used." As a reader, I am not sure if this is mentioned as a negative aspect of CoCoA. Perhaps not, but it might be good to emphasize that something like this is unavoidable (and, as I understand, it is the same with FASOR), whereas the second bullet is where a problem may actually happen. - Page 3, last paragraph: "CoCoA being unable to take RTT samples at all". In my opinion, "at all" is probably not the right text here, and the phrasing used should be relative to the context of the problem mentioned. - Page 3, last paragraph: similar to my first comment, some adaptation might be needed for this paragraph to better support possible future updates of CoCoA. - Section 4.1, first line: s/an CoAP/a CoAP - Section 4.1, third line: "normal RTO or FastRTO". I was wondering if handling two terms for the same concept is really useful. But perhaps it may make sense depending on the context in each instance of either term. So feel free to proceed as you prefer. - Section 4.1, first paragraph: s/backup mechanisms/backup mechanism - Section 4.1, last paragraph: "FastRTO is updated only with unambiguous RTT samples. Therefore, it closely tracks the actual RTT of the network and can quickly trigger a retransmission when the network state is not dubious." Perhaps there may be lossy intervals during which the "actual RTT" might vary (regardless of losses), e.g. due to a change of the physical layer bit rate, but then FASOR would not be able to collect "actual RTT" samples during such interval... It might be interesting to consider this situation as well. If no modification to the FASOR algorithm is deemed necessary, then perhaps at least some discussion on this might be useful. - End of section 4.1. What is "K"? (I wasn't able to find a definition of "K" earlier in the document.) - The document assumes that responses are "acknowledgments". However, there may be responses that do not correspond to acknowledgments at the messages sublayer of CoAP, that still provide RTT samples. It may be good to clarify this, since otherwise perhaps a fraction of the full set of RTT samples may remain unused. - The document also assumes in several instances that the message that triggers some response/ACK/packet from the other endpoint is a "request". Please note that there may be messages that do not carry requests which may anyway be sent as CON messages, from which an RTT sample can be obtained. - Section 4.2, first paragraph. A factor of 1.5 (by default) is mentioned at the end of the paragraph. Is there any hint on how this factor should be set? - Section 4.2, first paragraph, last sentence. Perhaps adding some forward reference might help the reader? - Section 4.3.1, FAST_SLOW_FAST: "If the request message needs to be retransmitted, continue by using Slow RTO for the first retransmission in order to respond to congestion". This text implies that it is *known* that the retransmission is due to congestion, but it could also be due to bad link quality. - Section 4.3.1, SLOW_FAST: s/transmisssion/transmission - Section 4.3.1: s/if further retransmission are/if further retransmissions are - Section 4.3.1, last paragraph: "if RTO expires also for that request message". When mentioning "that request message", which one does the text refer to? Perhaps, consider rephrasing. I hope this feedback can be useful! Cheers, Carles From nobody Mon Feb 8 06:08:59 2021 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 CDCB03A15AD; Mon, 8 Feb 2021 06:08:52 -0800 (PST) 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 RsfcfeP8yX50; Mon, 8 Feb 2021 06:08:49 -0800 (PST) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (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 D70333A15C4; Mon, 8 Feb 2021 06:08:48 -0800 (PST) Received: by mail-lj1-f172.google.com with SMTP id a22so1392318ljp.10; Mon, 08 Feb 2021 06:08:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ovmsf/uOBi/l3dTBSJgi0juCutJNc4yX/hl7OnfQbEI=; b=ivvXmNi/DnHY1I4HWCRZf/HfMVVketbSxqWRCk5xLCkmvySlItg/zhIl2cs1EtXv6h g4oBL+HPPOEbmAPKKh1FtVhR8zsgADhKhyaN1q7d6APhz08uipxfIXYacTQ1vUzn4qmJ xn/NpkBMtiikzCoKHgm6bqL77bRbiYtIJnoRXpQGVVJEwWnkWuf3nSrFeZlkNAD4VZkQ ztsMQjOSNtoZGVTszIO9gEn4qw3U65644UJRAVtYusf4d9puMq88pGcQG+frzT2LxjYG yEkzmu9lZCic3ocQ+iB40YwJ/F5GBugxkJwX3N077YxwlIvYs5inf39iWYXQu5Vg5AZw mOdQ== X-Gm-Message-State: AOAM533mj05RmIAP3J/p9D8Xr/sa1d7s9P9rrI7V51RatSika/5/egnZ sLjKVRwPWBrt8cuZViZv1W9dxpXSaU8HQ6i25Z84ZOao5jo= X-Google-Smtp-Source: ABdhPJy6SvLnWJcOh+ExWNk17KMOvC/eVoWXlnbtY69xvVJsEZQB6/2fbPxFnJTUkej9XJch+7yNP+/sTwED0cP0lxg= X-Received: by 2002:a2e:93c7:: with SMTP id p7mr11125274ljh.75.1612793324899; Mon, 08 Feb 2021 06:08:44 -0800 (PST) MIME-Version: 1.0 References: <159730632066.12379.5174560093789503034@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103172739.GE45088@hephaistos.amsuess.com> In-Reply-To: From: Barry Leiba Date: Mon, 8 Feb 2021 09:08:33 -0500 Message-ID: To: Benjamin Kaduk , =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, The IESG , core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (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: Mon, 08 Feb 2021 14:08:53 -0000 Ping... On Fri, Jan 29, 2021 at 10:05 AM Barry Leiba wrot= e: > > Ben, can you check version -26 and see how much of your ballot is > addressed there? > > Christian, do you think you've addressed all of Ben's issues in -26? > > Barry > > On Tue, Nov 3, 2020 at 12:28 PM Christian Ams=C3=BCss wrote: > > > > (This is one of the point-to-point follow-up mails on the RD -25 > > reviews; for the preface, please see the preceding mail on "The various > > positions on draft-ietf-core-resource-directory-25" at > > ). > > > > As DISCUSS: > > > > > I agree with Roman that the authorization model seems under-developed= . > > > While I recognize that there is need for flexibility across various > > > deployments, I think that we should be providing a default model (and > > > procedures for it) that will apply in many cases, and let > > > deployments specify alternate models if needed. This stuff is hard > > > enough to get right that we should have a secure option that people c= an > > > use if they don't need to have customized details. (To be clear, I > > > agree with the change of focus from -24 to -25 on the properties that= a > > > security policy needs to provide and/or consider, as that is > > > fundamentally the important thing. I just want a fallback/default > > > option that "does something reasonable in most cases" in addition. > > > Doing that by reference to some other existing thing would be fine, i= f > > > such a thing exists.) > > > > response: > > > > There is no external policy we could reference, so a new section was cr= eated. > > The First-Come-First-Remembered policy implements one of the candidates= that > > were considered for this role, and was picked because unlike its "endpo= int name > > comes from the certificate" it is a mode which an implementation can us= e > > without any further configuration whatsoever. > > > > The related changes can be viewed in > > https://github.com/core-wg/resource-directory/issues/258. > > > > > In particular, the current text seems to rely on the authorization > > > model including: > > > > > > (1) the RD knowing how clients will be using it (and thus what > > > properties the RD needs to enforce), which in the general case cannot= be > > > known (though for static networks it could be), yet I don't see any > > > discussion that indicates this as a prerequisite; and > > > > > > (2) the client either knowing out-of-band that an entity is authorize= d > > > to act as a RD or just blindly trusting any of the unauthenticated (*= ) > > > advertisement mechanisms. (* Yes, there may be some protection in th= e > > > network on subscribing to the relevant multicast address, DNS-SD, etc= ., > > > but the client cannot a priori know that such protections are in plac= e.) > > > > > > Relatedly, the naming model and naming authority should have some > > > clearer discussion. We do mention in Section 7 the possibility for a > > > weak naming model where the RD is responsible for enforcing uniquenes= s > > > of names but otherwise link attributes are the primary authorization > > > criteria (vs. a traditional scheme with a naming authority and naming > > > hierarchy), but with naming as a fundamental prerequisite of any > > > authentication/authorization scheme, I think clearer discussion of ho= w a > > > naming model is to be selected (and, perhaps more importantly, that i= t > > > must be fixed as part of a given deployment) for a given network is > > > needed. > > > > respond: > > > > The responsibilities are the other way around. The RD does not need to = know the > > clients' expectations, the clients may only expect things they know to = be true > > of the RD. > > > > See GENERIC-WHOPICKSMODEL. > > > > > If I understand correctly, we have some codepoint squatting going on = in > > > the examples (e.g., for resource types). > > > > response: > > > > The rt=3Dtemperature-c, rt=3Dlight-lux and if=3Dsensor are used where e= ndpoints > > mimick the examples of RFC6690; it is a point here to have things look = just > > like in direct discovery. > > > > The if=3Dcore.a and if=3Dcore.p use values from the expired and partial= ly abandoned > > core-interfaces -- given its future is unclear, they've been replaced b= y > > examples with tag URIs, as has the et=3Doic.d.sensor (a value that's re= gistered, > > but not to for et but for rt) and rt=3D"light"; rt=3Dsensor was dropped= as it was > > not essential to the example. > > > > The individual changes are listed in > > https://github.com/core-wg/resource-directory/pull/266. > > > > > We should talk about the security properties of the various RD discov= ery > > > mechanisms that are defined. > > > > response: > > > > A section was added in the security considerations on this topic (see > > https://github.com/core-wg/resource-directory/pull/275 for text > > changes). It does not go into the properties of each mechanism, as the = host > > discovery steps are generally unprotected; instead, it emphasizes the > > importance of checking the RD's authorization for any security properti= es the > > client would expect. In the context of the server authorization topic (= see > > OPEN-SERVER), it was added that if the authorization is conditional on = the > > resources being advertised with a particular resource type, that author= ization > > already needs to be checked during the discovery phase (details in > > https://github.com/core-wg/resource-directory/pull/306). > > > > As COMMENT: > > > > > My apologies for where these comments diverge off into rambling > > > incoherency, or where I'm misunderstanding something that's clearly l= aid > > > out; this document had the misfortune of being the last one I got to > > > this week. > > > > > > Section 1 > > > > > > [RFC6690] only describes how to discover resources from the web > > > server that hosts them by querying "/.well-known/core". In many > > > constrained scenarios, direct discovery of resources is not practi= cal > > > due to sleeping nodes, disperse networks, or networks where multic= ast > > > traffic is inefficient. These problems can be solved by employing= an > > > entity called a Resource Directory (RD), which contains informatio= n > > > about resources held on other servers, allowing lookups to be > > > performed for those resources. > > > > > > nit(?): I'd consider specifying that the RD is "a trusted entity". > > > (Even when the resources themselves are authenticated, a hostile RD c= an > > > still deny existence of a given resource, so by choosing to use an RD > > > there is some level of trust involved.) > > > > response: > > > > Putting it in there as a trusted entity would give the reader a wrong > > impression of the general case. Any trust placed in the RD must be earn= ed by a > > security policy backed by the RD's credentials. > > > > > Section 2 > > > > > > Resource Directory (RD) > > > A web entity that stores information about web resources and > > > implements the REST interfaces defined in this specification fo= r > > > discovery, for the creation, the maintenance and the removal of > > > registrations, and for lookup of the registered resources. > > > > > > nit: the list structure is not parallel here. Maybe "for discovery, > > > creation, maintenance, and removal of registrations, and for lookup o= f > > > the registered resources"? > > > > response: > > > > The intended structure that's linearized into the sadly untreeish struc= ture of > > written language was > > > > * discovery > > * of registrations > > - creation > > - maintenance > > - removal > > * lookup > > > > I think this is what the current text expresses, whereas the proposed o= ne > > groups discovery with "of registrations", while it's more a top-level t= hing. > > > > > Commissioning Tool > > > Commissioning Tool (CT) is a device that assists during the > > > installation of the network by assigning values to parameters, > > > naming endpoints and groups, or adapting the installation to th= e > > > needs of the applications. > > > > > > Is "the installation of the network" a one-time event? (Might a CT = be > > > involved when adding a new device to a network at a later time?) > > > > response: > > > > CTs can come back to help new devices into the network; the text has be= en > > clarified to that point in > > https://github.com/core-wg/resource-directory/pull/295. > > > > There are remaining questions about how long a network can operate auto= nomously > > while the CT is absent and can thus not refresh registrations, but thos= e exceed > > the scope of the document. (Discussed at > > https://github.com/core-wg/resource-directory/issues/290). > > > > > Section 3.1 > > > > > > Information SHOULD only be stored in the RD if it can be obtained = by > > > querying the described device's /.well-known/core resource directl= y. > > > > > > When might that not be the case? > > > > response: > > > > The prime example here is with devices that don't even have a copy of w= hat they > > might want to (but can't for resource constraints) express there; those= use a > > CT to do their work. > > > > The second example I can come up with is when devices have complex > > confidentiality requirements on the links, but rely on the RD and thus = publish > > data to an authorized RD of which they don't even know who precisely mi= ght be > > authorized to read them. > > > > > Section 3.2 > > > > > > The RD architecture is illustrated in Figure 1. An RD is used as = a > > > repository of registrations describing resources hosted on other w= eb > > > servers, also called endpoints (EP). An endpoint is a web server > > > associated with a scheme, IP address and port. A physical node ma= y > > > > > > (side note) hmm, I feel like in the HTTP world an endpoint is more > > > likely to be associated with a DNS name than an IP address, in common > > > usage. Also, we later go on to assert that the endpoint's name has > > > primacy and that the IP address/port can be ephemeral. > > > > response: > > > > This is leading the reader from the CoAP definition of endpoints to the > > endpoints as registrants as used in the RD. > > > > > An endpoint uses specific interfaces to register, update and remov= e a > > > registration. It is also possible for an RD to fetch Web Links fr= om > > > endpoints and add their contents to its registrations. > > > > > > At the first registration of an endpoint, a "registration resource= " > > > is created, the location of which is returned to the registering > > > endpoint. The registering endpoint uses this registration resourc= e > > > to manage the contents of registrations. > > > > > > Does the "RD fetches links unilaterally" case count as a "first > > > registration of an endpoint"? I'm having a hard time seeing how thes= e > > > two statements are consistent with each other, and a naive reading > > > admits the possibility that a given endpoint could be "locked out" of > > > the ability to manage the contents of its registrations. > > > > response: > > > > The act of the endpoint triggering the RD to fetch links from it is the > > creation. And the "locking out" is the correct reading -- a client that= uses > > simple client has no way of managing the contents. If it were capable e= nough to > > do that, it'd go the regular registration route. > > > > > Section 4 > > > > > > REST clients (registrant-EPs and CTs during registration and > > > maintenance, lookup clients, RD servers during simple registration= s) > > > MUST be prepared to receive any unsuccessful code and act upon it > > > according to its definition, options and/or payload to the best of > > > their capabilities, falling back to failing the operation if recov= ery > > > is not possible. In particular, they should retry the request upo= n > > > > > > "MUST be prepared [...] to the best of their abilities" seems > > > non-actionable. The stuff after "In particular", on the other hand, = is > > > actual concrete guidance that could be mandated using normative > > > language. > > > > response: > > > > Right; fixed in https://github.com/core-wg/resource-directory/pull/276. > > > > > Section 4.1 > > > > > > 1. In a 6LoWPAN, just assume the Border Router (6LBR) can act as = an > > > RD (using the ABRO option to find that [RFC6775]). Confirmati= on > > > can be obtained by sending a Unicast to "coap://[6LBR]/.well- > > > known/core?rt=3Dcore.rd*". > > > > > > nit(?): I was unaware that "Unicast" was a proper noun. > > > > response: > > > > Addressed in https://github.com/core-wg/resource-directory/pull/277. > > > > > Section 4.3 > > > > > > "core.rd" in the query string. Likewise, a Resource Type paramete= r > > > value of "core.rd-lookup*" is used to discover the URIs for RD Loo= kup > > > operations, core.rd* is used to discover all URI paths for RD > > > operations. [...] > > > > > > Is the distinction between URIs (for RD Lookup) and URI paths (for RD= ) > > > important here? > > > > response: > > > > No, it isn't. Fixed in https://github.com/core-wg/resource-directory/pu= ll/277. > > > > > While the link targets in this discovery step are often expressed = in > > > path-absolute form, this is not a requirement. Clients of the RD > > > SHOULD therefore accept URIs of all schemes they support, both as > > > URIs and relative references, and not limit the set of discovered > > > URIs to those hosted at the address used for URI discovery. > > > > > > I'm not sure I see how the "not limit [...] to those hosted at the > > > address used for URI discovery" follows from the non-requirement for > > > expression of the link-targets from discovery in path-absolute form. > > > (Given the ability to send the discovery query to a multicast address= , > > > the guidance seems okay; it's just the "therefore" that is puzzling m= e.) > > > > response: > > > > If it was a requirement on the server, the clients could rely on it and= thus > > implicitly limit the set by failing to parse the full URIs. > > > > (It could say "explicitly or implicitly limit", but only the "implicitl= y > > limit" case justifies the "therefore".) > > > > > It would typically be stored in an implementation information link > > > (as described in [I-D.bormann-t2trg-rel-impl]): > > > > > > Req: GET /.well-known/core?rel=3Dimpl-info > > > > > > This seems to be depicting a link-relation type that is not registere= d > > > at https://www.iana.org/assignments/link-relations/link-relations.xht= ml > > > , i.e., codepoint squatting. Please put in a stronger disclaimer tha= t > > > this is an example link relation type, not just an example exchange. > > > > response: > > > > A note has been added that the type is just proposed in a WIP document = (in > > https://github.com/core-wg/resource-directory/pull/278). > > > > > Section 5 > > > > > > These first few paragraphs give the impression that this is > > > first-come-first-served with minimal authentication or authorization > > > checking. Mentioning that there are authorization checks, with a > > > forward-reference, might be helpful. > > > > response: > > > > It's more a last-come-longest-remembered, but even the most minimal sec= urity > > policies would ensure that the registration resources belong to the "sa= me" > > device (for whatever the policy defines as same). > > > > Clarified in https://github.com/core-wg/resource-directory/pull/292. > > > > > further parameters (see Section 9.3). The RD then creates a new > > > registration resource in the RD and returns its location. The > > > > > > Is this returned "registration resource" expected to function as a > > > "capability URL" (https://www.w3.org/TR/capability-urls/) that would > > > need to contain an appropriate amount of entropy to be reasonably > > > unguessable by parties other than the registrant-ep/CT responsible fo= r > > > it? > > > > response: > > > > No, it is not a capability URL -- it will be discoverable through the e= ndpoint > > lookup interface. > > > > Note that around ACE, bearer tokens (which capability URLs are) are gen= erally > > discouraged in favor of proof-of-possession tokens. > > > > > The registration request interface is specified as follows: > > > > > > Interaction: EP -> RD > > > > > > I thought that the CT could be a requestor as well as the EP. > > > > response: > > > > Yes it can be. The expression in the interaction tables is an artifact = of the > > CTs being a not-even-special case of EPs, but as we have both of them i= n the > > rest of the text, so do we now in those lists. (Changes in > > https://github.com/core-wg/resource-directory/pull/309). > > > > > well. The endpoint name and sector name are not set when on= e > > > or both are set in an accompanying authorization token. > > > > > > What should the RD do if they are set but also present in the > > > accompanying authorization token? > > > > response: > > > > The wording has been updated in > > https://github.com/core-wg/resource-directory/pull/273; it now (by > > construction, but also explicitly) explains conflict handling. > > > > > Req: POST coap://rd.example.com/rd?ep=3Dnode1 > > > Content-Format: 40 > > > Payload: > > > ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", > > > > > > (side note) XML for the sensors, not SenML? With Carsten as an autho= r, > > > even? ;) > > > > response: > > > > This is clearly a mistake, and got removed in an emergency update in > > https://github.com/core-wg/resource-directory/pull/279. > > > > More seriously, though, these examples are from RFC6690 (which does not= have > > ct=3D entries for reasons of chronology), and keeping them aligned is a= good > > thing. > > > > > An RD may optionally support HTTP. Here is an example of almost t= he > > > same registration operation above, when done using HTTP. > > > > > > Req: > > > POST /rd?ep=3Dnode1&base=3Dhttp://[2001:db8:1::1] HTTP/1.1 > > > Host: example.com > > > > > > Wouldn't "Host: rd.example.com" be closer to "almost the same > > > registration"? > > > > response: > > > > Fixed in https://github.com/core-wg/resource-directory/pull/277. > > > > (I had brief qualms about introducing a protocol-negotiation situation = here, > > but performing "almost the same registration" over two protocols alread= y > > necessarily does that). > > > > > Section 5.1 > > > > > > I'm a little uneasy about specifying new behavior for POST to the > > > existin /.well-known/core that was defined by RFC 6690 for other uses= . > > > What factors go into using the same well-known URI vs. defining a new > > > one for this usage? > > > > response: > > > > It-always-having-been-that-way, primarily. As no large deployments are = known, > > this is fixed in https://github.com/core-wg/resource-directory/pull/259 > > by switching to a standalone /.well-known/rd. > > > > > The sequence of fetching the registration content before sending a > > > successful response was chosen to make responses reliable, and the > > > caching item was chosen to still allow very constrained registrant= s. > > > > > > I'm not sure what "the caching item" is supposed to be (if it's not a > > > typo/misordering of words). > > > > response: > > > > Now phrased as "the point about caching" (in > > https://github.com/core-wg/resource-directory/pull/277) which should > > be easier to read. A few lines up we recommend that the RD caches the .= wk/c, > > and this provides the rationale. > > > > > Section 5.3 > > > > > > queries concerning this endpoint. The RD SHOULD continue to provi= de > > > access to the Registration Resource after a registration time-out > > > occurs in order to enable the registering endpoint to eventually > > > refresh the registration. The RD MAY eventually remove the > > > registration resource for the purpose of garbage collection. If t= he > > > Registration Resource is removed, the corresponding endpoint will > > > need to be re-registered. > > > > > > (This MAY is actually a MUST for the simple registration case, per = =C2=A75.1, > > > right?) > > > > response: > > > > No, it's a choice there as well. One server may keep them around foreve= r, and > > when the simple client comes back it'll show with the same registration > > resource in the resource lookup. Another server may GC it and assign a > > different registration resource when it returns. > > > > > Section 5.3.1 > > > > > > An update MAY update the lifetime or the base URI registration > > > parameters "lt", "base" as in Section 5. Parameters that are not > > > > > > What about the "extra-attrs"; are they inherently forbidden from > > > updates? > > > > response: > > > > The introduction paragraph was overly specific and fixed in > > https://github.com/core-wg/resource-directory/pull/294. > > > > > base :=3D Base URI (optional). This > > > parameter updates the Base URI established in the original > > > registration to a new value. If the parameter is set in an > > > update, it is stored by the RD as the new Base URI under whi= ch > > > to interpret the relative links present in the payload of th= e > > > original registration, following the same restrictions as in > > > the registration. If the parameter is not set in the reques= t > > > > > > nit: is it the interpretation of relative links that is following the > > > same restrictions as in the registration, or the new value of the > > > parameter being supplied in the update? > > > > response: > > > > The restrictions apply to the new value, and were moved up there in > > https://github.com/core-wg/resource-directory/pull/294. > > > > > The following example shows how the registering endpoint updates i= ts > > > registration resource at an RD using this interface with the examp= le > > > location value: /rd/4521. > > > > > > The path component "4521" contains a worryingly small amount of > > > unpredictableness; I would prefer examples that used longer random > > > locations, as for capability URLs. (Throughout the document, of > > > course.) See also draft-gont-numeric-ids-sec-considerations, that I'= m > > > AD sponsoring, though I do not see any clear issues on first glance. > > > > response: > > > > See comment on the original capability URL question -- they are not. > > > > > (Also, it might be worth another sentence that this update is serving > > > just to reset the lifetime, making no other changes, since this might= be > > > expected to be a common usage.) > > > > response: > > > > Stating purpose rather than mechanism now (since > > https://github.com/core-wg/resource-directory/pull/294). > > > > > Section 6 > > > > > > With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level > > > siblings, would it make sense to put 6.2, or at least 6.3, as > > > subsections under 6.1? > > > > response: > > > > It would from a hierarchical table-of-contents point of view, but given= the > > focus of lookup is on resource lookup, the existing sequence captures t= he > > narrative of "With an RD, you can look up resources, here is how you us= e it, > > here is what it looks like, and by the way if you really need it you ca= n even > > look at the registrations themselves". > > > > > Section 6.1 > > > > > > Resource lookup results in links that are semantically equivalent = to > > > the links submitted to the RD. The links and link parameters > > > returned by the lookup are equal to the submitted ones, except tha= t > > > the target and anchor references are fully resolved. > > > > > > Are the "submitted ones" the submissions at registration time, or dur= ing > > > the lookup query itself? (I assume registration-time, but being > > > explicit costs little.) > > > > response: > > > > Some words added for clarity in > > https://github.com/core-wg/resource-directory/pull/294. > > > > > If the base URI of a registration contains a link-local address, t= he > > > RD MUST NOT show its links unless the lookup was made from the sam= e > > > link. The RD MUST NOT include zone identifiers in the resolved UR= Is. > > > > > > Same link as what? > > > > response: > > > > The link the endpoint sits on; clarified in > > https://github.com/core-wg/resource-directory/pull/294. > > > > > Section 6.2 > > > > > > The page and count parameters are used to obtain lookup results in > > > specified increments using pagination, where count specifies how m= any > > > > > > (We haven't introduced the page and count parameters yet.) > > > > response: > > > > Wording has been enhanced in > > https://github.com/core-wg/resource-directory/pull/294. > > > > > operator as in Section 4.1 of [RFC6690]. Attributes that are defi= ned > > > as "link-type" match if the search value matches any of their valu= es > > > > > > Where is it specified how an attribute might be "defined as > > > 'link-type'"? This is the only instance of the string "link-type" in > > > this document, and it does not appear in RFC 6690 at all... > > > > response: > > > > That should have said "relation-types"; it does now, and also refers to > > the 6690 ABNF (since > > https://github.com/core-wg/resource-directory/pull/294. > > > > > references) and are matched against a resolved link target. Queri= es > > > for endpoints SHOULD be expressed in path-absolute form if possibl= e > > > and MUST be expressed in URI form otherwise; the RD SHOULD recogni= ze > > > either. The "anchor" attribute is usable for resource lookups, an= d, > > > if queried, MUST be for in URI form as well. > > > > > > I don't see how it can be only a SHOULD to recognize either given the= se > > > generation criteria. > > > > response: > > > > If the URI is on a different scheme/host, I assert things are clear. (J= ust to > > ensure I didn't get your point wrong.) > > > > Otherwise, in practice there can happen mistakes where server and clien= t > > disagree about the default values of the Uri-Scheme, Uri-Host and Uri-P= ort > > options -- as anyone who's ever tried to set up an HTTP reverse proxy f= or a > > WebDAV server can attest to. We're trying to avoid creating these situa= tions, > > but when they do happen. We don't automatically declare the offending p= arty > > broken by putting a MUST here, but encourage the peer to assist it. The= client > > can help by providing the relative reference (for then, disagreement pa= ssses > > unnoticed), and the server by recognizing the full URI (for the client = may have > > obtained it and not know that it'd match what the server thinks is its = Uri-Host > > name). > > > > (The "and MUST be expressed in URI form otherwise" sounds like a factua= l > > necessity, but it is here to rule out the corner case of a client handi= ng out > > //hostname/path style references). > > > > > Section 6.3 > > > > > > The following example shows a client performing a lookup of all > > > resources of all endpoints of a given endpoint type. It assumes t= hat > > > two endpoints (with endpoint names "sensor1" and "sensor2") have > > > previously registered with their respective addresses > > > "coap://sensor1.example.com" and "coap://sensor2.example.com", and > > > posted the very payload of the 6th request of section 5 of [RFC669= 0]. > > > > > > Er, the 6th request is a GET; do we mean to say the response to the 6= th > > > request? > > > > response: > > > > Yes. Fixed in https://github.com/core-wg/resource-directory/pull/294. > > > > > Section 6.4 > > > > > > The endpoint lookup returns registration resources which can only = be > > > manipulated by the registering endpoint. > > > > > > This seems to leave it unclear whether the endpoint lookup is expecte= d > > > to return resources that the requestor will not have permission to > > > manipulate (in addition to those it does have permission for). > > > > response: > > > > Clarified in https://github.com/core-wg/resource-directory/pull/294. > > > > > While Endpoint Lookup does expose the registration resources, the = RD > > > does not need to make them accessible to clients. Clients SHOULD = NOT > > > attempt to dereference or manipulate them. > > > > > > But why expose them at all if they're not going to be accessible? > > > > response: > > > > They serve as identifiers (think URI rather than URL), and may addition= ally be > > used in implementation defined operations on the resource that could be= allowed > > for administrators. Last but not least, link-format (unlike the upcomin= g CoRAL) > > does not have means of talking about something without naming it. > > > > (I do see the point, and if we started RD anew with the benefit of havi= ng > > CoRAL, chances are this would look a bit different, and the names would= not be > > exposed to just any lookup client). > > > > The WG discussion of this did, however, lead to a point added to the se= curity > > considerations about the RD's choice of what to put in there (change in > > https://github.com/core-wg/resource-directory/pull/267). > > > > > An RD can report endpoints in lookup that are not hosted at the sa= me > > > address. [...] > > > > > > The "same address" as what? > > > > response: > > > > Sharpened in https://github.com/core-wg/resource-directory/pull/294. > > > > > Section 7.1 > > > > > > Whenever an RD needs to provide trustworthy results to clients doi= ng > > > endpoint lookup, or resource lookup with filtering on the endpoint > > > > > > How will the RD know whether the client is expecting trustworthy > > > results? (When would a client *not* expect trustworthy results?) > > > > response: > > > > It won't per-client, it is configured for one. See GENERIC-WHOPICKSMODE= L. > > > > > name, the RD must ensure that the registrant is authorized to use = the > > > given endpoint name. This applies both to registration and later = to > > > operations on the registration resource. It is immaterial there > > > whether the client is the registrant-ep itself or a CT is doing th= e > > > registration: The RD can not tell the difference, and CTs may use > > > > > > I suppose there might be plausible authorization models where a > > > return-routability check to a given address constitutes authorization= to > > > use that address as an endpoint name, in which case the RD can tell t= he > > > difference between a registrant-ep and a CT attempting to act on its > > > behalf. > > > > WGF-6 > > response: > > > > The RD might do such checks, but then again the EP might just be using > > different network interfaces simultaneously. At that point where the EP= uses a > > different (and usually dormant) network interface for registration, the= line > > between EP and the CT gets blurry; we tolerate that blurriness because = the > > distinction is not so much a technical one (the REST server does not ca= re > > whether the request originates at its network peer, is proxied through = there or > > sent from there on behalf of someone completely different) as long as t= he > > credentials are good. > > > > Frankly, I'm personally not too happy with distinguishing CTs in the fi= rst > > place; it is more reflective of what I understand to be an industry pra= ctice > > than a distinction in this CoAP application. > > > > > When certificates are used as authorization credentials, the > > > sector(s) and endpoint name(s) can be transported in the subject. = In > > > an ACE context, those are typically transported in a scope claim. > > > > > > As Russ noted in the Gen-ART review, "transported in the subject" is > > > sufficiently vague to not really be actionable. It might be better t= o > > > say that the holder of the private key corresponding to the public ke= y > > > certified in the certificate is generally considered authorized to ac= t > > > on behalf of any identities (including endpoint names) contained in t= he > > > certificate's subject name. > > > > response: > > > > See GENERIC-SUBJECT. > > > > > Section 7.1.1 > > > > > > Conversely, in applications where the RD does not check the endpoi= nt > > > name, the authorized registering endpoint can generate a random > > > number (or string) that identifies the endpoint. The RD should th= en > > > > > > How much entropy/randomness in the random name? Does a CSPRNG need t= o > > > be used? (I do see the follow-up about doubling the length in case o= f > > > failure or starting with a UUID if that's not possible, but some > > > guidance on where to start still seems appropriate.) > > > > respond: > > > > There is no requirement here as collisions only result in retries. > > > > For those cases where the client implementer thinks they can get away w= ith not > > implementing retry, UUID URNs are pointed to, which themselves cover th= e topic. > > > > > Section 7.2 > > > > > > When lookup clients expect that certain types of links can only > > > originate from certain endpoints, then the RD needs to apply > > > filtering to the links an endpoint may register. > > > > > > As before, how will the RD know what behavior clients are relying on? > > > > response: > > > > It will not. It may, however, advertise it explicitly. If, for example,= an > > application like LwM2M always ensures trusted endpoint names, the RD ma= y > > advertise as rt=3D"core.rd-lokup-ep example.lwm2m", and then clients th= at trust > > that metadatum (which they'll want to verify from some claim) know they= can > > trust the RD to have checked ep names. > > > > See also GENERIC-WHOPICKSMODEL > > > > > An RD may also require that only links are registered on whose anc= hor > > > (or even target) the RD recognizes as authoritative of. One way t= o > > > > > > I don't think I can parse this sentence (especially "the RD recognize= s > > > as authoritative of"). > > > > response: > > > > Rephrased to "require that links are only registered if the registrant = is > > authorized to publish information about the anchor [...] of the link." = in > > https://github.com/core-wg/resource-directory/pull/294. > > > > > Section 8 > > > > > > In contexts where we discuss DTLS and TLS as being generally comparab= le, > > > we typically will state that DTLS replay protection is required in or= der > > > to provide equivalent levels of protection. > > > > response: > > > > This item rippled quite a bit beyond the original response of "Huh? CoA= P > > doesn't already do this? Well, here we need it". > > > > As things stand, requiring replay protection make it harder to exploit = the > > issue described at OPEN-REPLAY-FRESHNESS, but once that is addressed fo= r good, > > replay protection should not be necessary any more for the RD, as all i= ts > > operations are becoming long-term idempotent. > > > > > We might also want to reiterate or refer back to the previous discuss= ion > > > of the potential for attributes or resource/endpoint names, link > > > relations, etc. that may need to be confidential, the relevant access > > > control/filtering, and the avenues by which disclosure of resource na= mes > > > can occur even when access to those resources will not be permitted. = (I > > > think some of this overlaps with 8288 and 6690, but don't mind repeat= ing > > > it.) > > > > response: > > > > There is a pointer back saying that the necessary access control depend= s on the > > protection objectives set in the policies (since > > https://github.com/core-wg/resource-directory/pull/250). > > > > > Section 8.1 > > > > > > It's probably worth reiterating that all name comparisons must be don= e > > > at sector scope (since failing to do so can lead to attacks). > > > > response: > > > > It is; fixed since https://github.com/core-wg/resource-directory/pull/2= 96. > > > > > Endpoint authentication needs to be checked independently of wheth= er > > > there are configured requirements on the credentials for a given > > > endpoint name (Section 7.1) or whether arbitrary names are accepte= d > > > (Section 7.1.1). > > > > > > I think this is more properly authorization than authentication. > > > > response: > > > > Yes; fixed in https://github.com/core-wg/resource-directory/pull/271. > > > > > Section 8.3 > > > > > > attacks. There is also a danger that NTP Servers could become > > > implicated in denial-of-service (DoS) attacks since they run on > > > unprotected UDP, there is no return routability check, and they ca= n > > > have a large amplification factor. The responses from the NTP ser= ver > > > were found to be 19 times larger than the request. An RD which > > > > > > (It's not clear to me why the specific discussion of NTP numbers is > > > relevant here, since RD is not NTP.) > > > > response: > > > > The section has been shortened in > > https://github.com/core-wg/resource-directory/pull/249. > > > > > Section 9.3 > > > > > > Should we also include "rt" in the initial entries? I see it is used= as > > > a query parameter for resource lookup in the examples in Section 6.3. > > > > response: > > > > It's used as is any other link attribute. There's no registry for them,= and > > while there's been talk over ond over that it would be nice, I don't th= ink > > there will be any until linkformat-CoRAL conversion is defined (and eve= n then > > it may not be comprehensive). Selectively picking some distinguished co= mmon > > link attributes into this registry won't make things less messy. > > > > The prime line of defense against this getting messy is the expert guid= ance > > that for some types of parameters their short names should be checked a= gainst > > "commonly used target attributes". > > > > > > > * indication of whether it can be passed as a query parameter at > > > registration of endpoints, as a query parameter in lookups, or = be > > > expressed as a target attribute, > > > > > > (Since this text does not clarify about lookup of endpoints vs. > > > resources... > > > > > > Review" as described in [RFC8126]. The evaluation should consider > > > formal criteria, duplication of functionality (Is the new entry > > > redundant with an existing one?), topical suitability (E.g. is the > > > described property actually a property of the endpoint and not a > > > property of a particular resource, in which case it should go into > > > the payload of the registration and need not be registered?), and = the > > > > > > ... and this text suggests that query parameters for *resource* looku= ps > > > need not be registered.) > > > > > > potential for conflict with commonly used target attributes (For > > > example, "if" could be used as a parameter for conditional > > > registration if it were not to be used in lookup or attributes, bu= t > > > would make a bad parameter for lookup, because a resource lookup w= ith > > > an "if" query parameter could ambiguously filter by the registered > > > endpoint property or the [RFC6690] target attribute). > > > > > > Then why do we use it as an example of lookup filtering in Section 6.= 2? > > > > response: > > > > The text suggests that target attributes for registered resources need = not be > > registered. These unregistered wild-west attribute names can be used bo= th with > > resource lookups (matching only resources which), and in endpoint looku= ps > > (matching endpoints that contain any resource which). > > > > If `if` were to be put in for use in an RD parameter used with lookup, = that > > would not per se create ambiguous queries (the rules would still say "m= atches > > either"), but the results would be prone to causing confusion. > > > > > Section 10.1.2 > > > > > > Should we really be using unregistered resource types (i.e., codepoin= t > > > squatting) in the examples? > > > > response: > > > > Addressed together with the earlier code squatting comments in > > https://github.com/core-wg/resource-directory/pull/266. > > > > > After the filling of the RD by the CT, the application in the > > > luminaries can learn to which groups they belong, and enable their > > > interface for the multicast address. > > > > > > Just to check: the luminaries are learning their own group membership= by > > > querying the resource directory? > > > > response: > > > > Not directly. They (in this very particular example that seems to be ba= sed on > > industry process but which I'd not necessarily recommend for imitation)= use a > > heuristic to find any multicast URI they might possibly provide, and jo= in that > > group. > > > > > Section 10.2.2 > > > > > > Please expand MSISDN. > > > > response: > > > > Taking a step back from this and other comments led to a drastical shor= tening > > of the example. > > > > See also GENERIC-ODDEXAMPLES > > > > > Section 13.2 > > > > > > I think RFC 7252 should probably be normative. > > > > > > Likewise for RFC 8288 ("the query parameter MUST be [...] a token as > > > used in [RFC8288]"). > > > > response: > > > > RFC7252 (CoAP) and RFC7230 (HTTP) were promoted to a normative referenc= e. > > (RFC7641 (CoAP observe) wasc left as informative because while they are > > optional components, RD is not so much specified using them but more ha= ppens to > > combine with them). > > > > RFC8288 was also promoted, but not due to the quoted line (that's not > > implementation relevant but merely setting out rules for the registry > > operation), but because we explicitly pull it in in terminology and the > > information model. > > > > (Changes in https://github.com/core-wg/resource-directory/pull/307). From nobody Wed Feb 10 05:42:45 2021 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 081053A100C for ; Wed, 10 Feb 2021 05:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 l4ddDqXdzU_5 for ; Wed, 10 Feb 2021 05:42:39 -0800 (PST) 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 514373A0FF0 for ; Wed, 10 Feb 2021 05:42:39 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DbLY93WwvzyWt; Wed, 10 Feb 2021 14:42:37 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 634657356.8971961-8e0a40fc733d0ce9201638346830e46f Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 10 Feb 2021 14:42:37 +0100 Message-Id: <8F2BA41A-011C-4C3F-88BE-D7C3E05C9465@tzi.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] Endpoint type (et) vs. resource type (rt) 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, 10 Feb 2021 13:42:43 -0000 CoRE RD defines an endpoint type (et). https://w3c.github.io/wot-discovery/#introduction-core-rd =E2=80=A6 uses the endpoint type as if it were a replacement for RFC = 6990 rt (resource type). Is this replacement where we want to steer people to? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Feb 10 14:31:19 2021 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 0DEA83A0975 for ; Wed, 10 Feb 2021 14:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=armh.onmicrosoft.com header.b=XH8gZqyI; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=XH8gZqyI 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 nxIxV3Qq0gpX for ; Wed, 10 Feb 2021 14:31:15 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80042.outbound.protection.outlook.com [40.107.8.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807943A086E for ; Wed, 10 Feb 2021 14:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rspudeVbYjicVolAW+0/cD0YcR+vkUh/4lC/Vm5XLS8=; b=XH8gZqyIg0UEZ3WrjTIZDPeDeTOsj8W4aG3VZQLJUpZsoVo9nk6UnWzVpr6Z6NF8+afQa48dB0KP8m4NmXIsAHoPMZUc+YFCTCIhXHMpXUkmjcRQ/10f9q8U3hGfBRWJRQJUAuIfdiwtLd/JlBUs+bGrOZi+brNoTYgNJT/jD/A= Received: from DB6PR0202CA0030.eurprd02.prod.outlook.com (2603:10a6:4:a5::16) by PR3PR08MB5692.eurprd08.prod.outlook.com (2603:10a6:102:8a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Wed, 10 Feb 2021 22:31:11 +0000 Received: from DB5EUR03FT042.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a5:cafe::58) by DB6PR0202CA0030.outlook.office365.com (2603:10a6:4:a5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Wed, 10 Feb 2021 22:31:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT042.mail.protection.outlook.com (10.152.21.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Wed, 10 Feb 2021 22:31:11 +0000 Received: ("Tessian outbound 2b57fdd78668:v71"); Wed, 10 Feb 2021 22:31:10 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d7d4f2bd126f66b7 X-CR-MTA-TID: 64aa7808 Received: from 669200536223.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 970CC45E-B33D-4370-B2B3-091A7E2643A9.1; Wed, 10 Feb 2021 22:31:05 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 669200536223.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 10 Feb 2021 22:31:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k3KjlD5M7wxElCquz4zSBzSQBoSTp/lL9MRFk6qbcZhQrikiIoXfd8ZfkgtNfypTYstPeJrA7Lu2mnjA1zFRyJ7ahGpBLspPDo9GxDUacURrh3eOuBjtxEvZfQIRURGCPe/zJwD2s0TFRjOX1GwelAdPpMNToJoaKuQIL2FLNm+oHZm8FYUk3hLK2iRi6toExzPCsYxFU/AvtFB3QrX8X6JZGzBZL8rivNBeI+qF1e2heoZYOx4vrpXgpAxh06yLu+PitfoYa51lNe+eABNbXBmqO8HQauUXz4CC0lr6pYH+Am8LeONz0o5UWTcUz7ulhc9gvAzCgVMyLfcTrexxgQ== 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=rspudeVbYjicVolAW+0/cD0YcR+vkUh/4lC/Vm5XLS8=; b=a0E7L+gDM+dccn8FIOGbApDcedI9ShUsZHetpvIP8EAO2teo00MNng5u6aJW93qOpTRrovZHjnnsLNDKSwEWzBkRc7rCFJyHW20Bwnf2gnEmQc7T8/ZhqLByp7H0L6yEa25WOkJx07zi7TLRbALxsGrVSgJJloUpv9WbLiWsi7zzSq2OL7FFs+ft34zFU5qHe6yUMP93DZG9TesvtI4XQg0UtWAS/6QgFKPYbTt+RnF6tZE45uhRQ6FdZZ2KcXTtw9fS2IzEQM4EjPALSrxcbA8I3O3qqJAaH8CCgFIFiphgnXFcK7VcTyi7foIi/IrxQVhx1n8Gxts4ELlOo//tCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rspudeVbYjicVolAW+0/cD0YcR+vkUh/4lC/Vm5XLS8=; b=XH8gZqyIg0UEZ3WrjTIZDPeDeTOsj8W4aG3VZQLJUpZsoVo9nk6UnWzVpr6Z6NF8+afQa48dB0KP8m4NmXIsAHoPMZUc+YFCTCIhXHMpXUkmjcRQ/10f9q8U3hGfBRWJRQJUAuIfdiwtLd/JlBUs+bGrOZi+brNoTYgNJT/jD/A= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DB6PR0802MB2134.eurprd08.prod.outlook.com (2603:10a6:4:83::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.27; Wed, 10 Feb 2021 22:31:03 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::1f5:375c:310f:7df5]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::1f5:375c:310f:7df5%4]) with mapi id 15.20.3825.030; Wed, 10 Feb 2021 22:31:03 +0000 From: Thomas Fossati To: "core@ietf.org" Thread-Topic: IoT profile for TLS - input needed Thread-Index: AQHW//xq07cm1myMO0GyxOT5778WhA== Date: Wed, 10 Feb 2021 22:31:03 +0000 Message-ID: <85C37FB1-7547-4544-A1F3-792094CD5E0A@arm.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.12.10.179] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e3e06b05-d77f-4a87-2724-08d8ce13914b x-ms-traffictypediagnostic: DB6PR0802MB2134:|PR3PR08MB5692: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: IdYiRoVUw5VYb1t3WUp+rRuessmLzWpWcmvwTuHHPnzXDBS0Fx9S+jaLSBOVP+zDUpHj8ZoWEh1VjaHQqZHtFbnY5pfbfPMRG9SoCCp6JOG6pXLNKf7Q7nEPbumU7imoIY93GLyyGBIJyGEA5hfm4vXWmQCdcUT40cgJA6uE3aSP4z67Fkthxc46hIlL9QMmkTZquJ3zmjTqyUZJfE/jmZexnCjCCrOUazX6NbqPWyEL+5pvRTJwawhDyJvGKt/w4CpZMYR7IOPBg7P8zdEcUX0pcqLEJZJUPEN0G6BBtRjN6mwU/tcXxYYIxw64SwxKUAQb7fXKk+qyglZktUaGkEE+d2ga3hjD8fFXFpnx3f6+NtJYfv9t2VwyzQjhAeXB5OKlCBMvUUBQtA852xO2d5LiCdF1MIChPa11W5p9pZWPej9UgkitoIJFxRxKa7s1gF/MxRG7qxi3t/83Zl/v8cjjfONNBFsq1Y+AQrDTtpEu0x4XsZcWgNqcGFDMFCnDAcvA/ffdew6tEvh4StpsN0ET6h+agOBgIH1Y4/rGthr8D7kh1CDUlqxU8weRwdM3SDlcmCISMxljAvHzbW2ksf8NtgmkJDvXJi1uG5ineArOFxjM5Yeklt2PPUl5U7JPO4WETXCW+IDdZTNwSPUmkA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(39860400002)(366004)(376002)(396003)(66476007)(64756008)(4326008)(83380400001)(66446008)(478600001)(26005)(86362001)(8676002)(66556008)(2906002)(966005)(6916009)(6512007)(316002)(76116006)(5660300002)(2616005)(91956017)(4744005)(66946007)(36756003)(8936002)(33656002)(6486002)(71200400001)(6506007)(186003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cTE3SklWc2lvczRlN1BRaTViQXFack5KeVQvampCOGFXd2xuN2FOVUpERWpi?= =?utf-8?B?VUJqMmN1UW5GdXJSa1hTTXFFSU1hVEx0ZDgvYldMeElXMlZvVVhhWHVDU0lr?= =?utf-8?B?Y3N6dnFqdmh4OVNMWjZVLzhFQ041aHpocnJRcFZOc1JJam1qUVY3NmV3R2FZ?= =?utf-8?B?VkM5ZklTMWFFY2tVWlNSUVNnd0d2RDY4ODlZaUtSdE9DTmVmTW1LUUVLS0dD?= =?utf-8?B?TnNLc2Z3MkdmU24xdjlPdi9ZWGYyS2R6LzBpdTh5WlBZczA2WXpwa2U3dWpi?= =?utf-8?B?ejIrekU3TWNhRjRzZzBPT1FHMWQ4cHFLOE9POC9pTWE1OGlIQ3R6Z3FrNjNG?= =?utf-8?B?UHUzQlM4QXdVTC8rRExEMDlXOWhiTmNwSzV2OWM0SWI0UXFGWWhvNFFNREM0?= =?utf-8?B?RzRFdmRtbGo4NGUvR0h1VnlPV0RzTm85dFN4NmRRS1JRbUNISy9TblM3b1Vh?= =?utf-8?B?Y2lscGh4bDJDWVVxYWl4Y0I4ZGsweVZLeDBWdUI2SFhZWlc5ajVLNzh2Z3dF?= =?utf-8?B?ZnEyUG92YmJQWlNEUEJ2Z09lTWpLR0dRU3huMGpRVXhWS1ZTL0tBT2xqMWpL?= =?utf-8?B?dkJTRW40UnlqRWtlVzZhM1NGUVJxbEJNbkd5TGMra0g0WUZOWmEycTFnb1JY?= =?utf-8?B?dTJsYXljNEl3bUNWVjIrSW9HQXhqcnB6RVB2ODVzdVNtV1U5MkRDK1IyVExk?= =?utf-8?B?NHRzaGZvcG54OTh1S29mSFU0RkgwWDhNbUc3QkpFTFd5UllSbldGSUo0MVVy?= =?utf-8?B?d3VxVUtxTndzK0dKclBaaG1BK2dtbC9aR1ZqUWoxekY4eXNWcTZNaTRFT0dI?= =?utf-8?B?QTFMRHdVOGNObVhpY2I2OCtPekM2Y1NqMGFJdEljQVdpQmdzc1NzTWNzd2g2?= =?utf-8?B?bXF4SnpwS2JudVRnYm1nS1c4dDRVcW55amp0TUluZFBxdVptSnZDSVE0YllE?= =?utf-8?B?REMrWlRrcFlPRmM3UmpqR3h0NlltUzNYTTQ2UlV0Qjl6SHU5SEt6TjE2bnJl?= =?utf-8?B?MDJ0NjUweUJBUEIxbmlzUklmYXJKdllFdEtkRkY2Rld0SkZEclcxUmZVd3Ez?= =?utf-8?B?cENHc1ZsTGczekZuZEplZmNKVXZUUGd4YkpOVk5ZZ0k2RlhudTl0aFZwSGlt?= =?utf-8?B?MEN3UGc5eXBtQ09xbUxwTVAvaTQzZHR2b084dGcvOGVCdTJzUUN2ZVFNcTU1?= =?utf-8?B?OStRTHpmRmFya3d0SG9Da2hkazAva1FsQzY3OW5sdDNHL0NERE81N2FvdWl3?= =?utf-8?B?Z0k0MlhqbU1pWXFXVzg5dEZtcFJOK3orcStxdEk2WHJ5eG43YVYvQWNnN3FP?= =?utf-8?B?SStTb2Q2UXJvK0lzdUgvR2NXVWlqOUp0NVJzaW1PRktHeFdadHpnRDRoK3VB?= =?utf-8?B?UHN4bGE3ckZqWStoVkh1dmg4Y3RmL1p3VTg2OTY3VE8wUUdLenVnaVhxRWZV?= =?utf-8?B?WTZYTmg0QXRINGsyVUIxUEZabkNNM1Y3bEZlTVdDcUkvakJyYldMb285NEFV?= =?utf-8?B?anQvUUhsRnY0cS8zeUJkcEgrb2d2Y2k0QjVBbDIyWlRqK3BaSkx5R2lVRmxy?= =?utf-8?B?UU9aRGx3N3NGOWUzY2dDYXZFVitxL3RlbzhSeWxzWHpPU3N2R0VvQlRiUTE4?= =?utf-8?B?Mk0wdkZJWVltODBzTHI5MkRwMktQcXFTVkY4MXBBS0dlUUxjK1dTcGJWUmdH?= =?utf-8?B?R3BXR3R2TjhrZVluK05vNEVVU05zU1U5dGloNnJEYVF0TUxxdXR2QTk4UG96?= =?utf-8?Q?RDDCCbmKO4ZhwtH2XKfR015YHZmcyKDcRWMXcft?= Content-Type: text/plain; charset="utf-8" Content-ID: <53336AB0C0110F4988817801097C7026@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2134 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 876b2316-ae04-4658-1ded-08d8ce138cfc X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jEbZcyk1EFNbJr+NNtayrGYO/QFUVeEZ4HboV4AqP34qBNsLWZFgwQnheouFU8c2uT8MXUP9nC/YEqZqphzV9JCriLWnGIDCEZt7l4u8AdiBMr/pvrFZOWI5Ho1xg+xChiBRYK/tf30snDAoybZxuaX11HsEWKJmD/tItc+D7eJQ6sMwUPc4GRJndzOvuJWpiKhplZFky9ngRzOAFNqEv0IwGtaetYl3VUzYhCi77GjSvDclat4DgOaMJo6qS9ilFLBWVBoXCPnwVPkLOu1h8sWuCzY4SPI7BrSPWZXfUO0ByUIddSXqU6gt8U4J2fJ2k69tNKaAOTQ9jivvBKWIpwRaXsNboiA4fvMRQZIaqfuhLCy8xn/o2aZtWeTdAs1MIjI06BjKPMFADb0QKQ9KPrkitV75YC6B71P9Lbgr0yvXjY5DvDtF2q9oepVIMZew5I/xq0BNbfD02NKuwi9vdXVx8Muj2Khz617qUPgQzNFlN8nug9+Ps03O3vLsCUzoGXMx1c4UbBZK82CM6/Jw2OGdWKZyEwtnkEynvq1GqMWJw3zHqNlQrJqr2M7y4iAZoIedGofoc4yUMf4q9hwKe5rIAxe+1haGh15LcTq+m/lMwX935NV3BBB7r6xPRw76quIzws8vY7IZDUqJ2Ae6LJyBROYjElwTZJ+J6a8CbbvX5qD75KgvxyyP9xQqZOaT2ZcVVt0xV0wAH/KUHLXrL2A1XPcnZL8ZPqdtC079ICY= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(136003)(376002)(36840700001)(46966006)(6506007)(2616005)(356005)(26005)(186003)(70206006)(47076005)(70586007)(336012)(33656002)(8676002)(6486002)(5660300002)(36860700001)(81166007)(82740400003)(8936002)(316002)(6512007)(4744005)(83380400001)(6916009)(82310400003)(36756003)(4326008)(86362001)(966005)(2906002)(478600001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2021 22:31:11.0177 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e3e06b05-d77f-4a87-2724-08d8ce13914b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5692 Archived-At: Subject: [core] IoT profile for TLS - input needed 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, 10 Feb 2021 22:31:17 -0000 SGksDQoNCkkndmUganVzdCBzZW50IGFuIGVtYWlsIHRvIHRoZSBVVEEgbGlzdCBbMV0gdG8gZ2F0 aGVyIGlucHV0IG9uIGEgZmV3DQpvcGVuIHBvaW50cyBhYm91dCB0aGUgSW9UIHByb2ZpbGUgZm9y IFRMUyBbMl0uDQoNClRoZSBkb2N1bWVudCBpcyByZWxldmFudCB0byB0aGlzIGNvbW11bml0eSBh bmQsIHNpbmNlIEkgZG9uJ3QgdGhpbmsNCmV2ZXJ5b25lIGhlcmUgaXMgYWxzbyBzdWJzY3JpYmVk IHRvIFVUQSwgSSB3YW50ZWQgdG8gZ2l2ZSB5b3UgYQ0KaGVhZHMgdXAgaW4gY2FzZSB5b3Ugd2Fu dGVkIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNzaW9uLg0KDQpDaGVlcnMsIHRoYW5rIHlv dSENCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdXRhL0ozdGtj NjBCWWhfWnQ0eW1tNGY2QnFJaEVVQS8NClsyXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtdXRhLXRsczEzLWlvdC1wcm9maWxlLTAwDQoNCg0KDQoNCg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Wed Feb 10 19:52:06 2021 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 BFD253A10CA; Wed, 10 Feb 2021 19:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 4yrIQvjHz03c; Wed, 10 Feb 2021 19:51:59 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027133A10C7; Wed, 10 Feb 2021 19:51:58 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11B3pj2R030687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Feb 2021 22:51:50 -0500 Date: Wed, 10 Feb 2021 19:51:45 -0800 From: Benjamin Kaduk To: Christian =?iso-8859-1?Q?Ams=FCss?= Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20210211035145.GS21@kduck.mit.edu> References: <159730632066.12379.5174560093789503034@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103172739.GE45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201103172739.GE45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (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: Thu, 11 Feb 2021 03:52:04 -0000 Hi Christian, I am ashamed to have dallied so long in responding; your efforts to collate and respond to the feedback on this document have been, for lack of a better term, amazing, whereas mine ... have not. That said, I'm happy to report that I will be clearing my discuss shortly after sending this note. I do have some other comments staged for my updated ballot position, though a much smaller number than the initial list, and comparatively minor. (The most significant thing is in essence a long-winded question of whether "authorized" or "authoritative" is the better term in a handful of places.) I will give your responses here the careful reading they deserve, but attempt to only respond when I actually have something substantive to say. I do greatly appreciate them all, though, even where I do not specifically reply. On Tue, Nov 03, 2020 at 06:27:39PM +0100, Christian Amsss wrote: > (This is one of the point-to-point follow-up mails on the RD -25 > reviews; for the preface, please see the preceding mail on "The various > positions on draft-ietf-core-resource-directory-25" at > ). > > As DISCUSS: > > > I agree with Roman that the authorization model seems under-developed. > > While I recognize that there is need for flexibility across various > > deployments, I think that we should be providing a default model (and > > procedures for it) that will apply in many cases, and let > > deployments specify alternate models if needed. This stuff is hard > > enough to get right that we should have a secure option that people can > > use if they don't need to have customized details. (To be clear, I > > agree with the change of focus from -24 to -25 on the properties that a > > security policy needs to provide and/or consider, as that is > > fundamentally the important thing. I just want a fallback/default > > option that "does something reasonable in most cases" in addition. > > Doing that by reference to some other existing thing would be fine, if > > such a thing exists.) > > response: > > There is no external policy we could reference, so a new section was created. > The First-Come-First-Remembered policy implements one of the candidates that > were considered for this role, and was picked because unlike its "endpoint name > comes from the certificate" it is a mode which an implementation can use > without any further configuration whatsoever. It is nicely done; thank you! > The related changes can be viewed in > https://github.com/core-wg/resource-directory/issues/258. > > > In particular, the current text seems to rely on the authorization > > model including: > > > > (1) the RD knowing how clients will be using it (and thus what > > properties the RD needs to enforce), which in the general case cannot be > > known (though for static networks it could be), yet I don't see any > > discussion that indicates this as a prerequisite; and > > > > (2) the client either knowing out-of-band that an entity is authorized > > to act as a RD or just blindly trusting any of the unauthenticated (*) > > advertisement mechanisms. (* Yes, there may be some protection in the > > network on subscribing to the relevant multicast address, DNS-SD, etc., > > but the client cannot a priori know that such protections are in place.) > > > > Relatedly, the naming model and naming authority should have some > > clearer discussion. We do mention in Section 7 the possibility for a > > weak naming model where the RD is responsible for enforcing uniqueness > > of names but otherwise link attributes are the primary authorization > > criteria (vs. a traditional scheme with a naming authority and naming > > hierarchy), but with naming as a fundamental prerequisite of any > > authentication/authorization scheme, I think clearer discussion of how a > > naming model is to be selected (and, perhaps more importantly, that it > > must be fixed as part of a given deployment) for a given network is > > needed. > > respond: > > The responsibilities are the other way around. The RD does not need to know the > clients' expectations, the clients may only expect things they know to be true > of the RD. > > See GENERIC-WHOPICKSMODEL. > > > If I understand correctly, we have some codepoint squatting going on in > > the examples (e.g., for resource types). > > response: > > The rt=temperature-c, rt=light-lux and if=sensor are used where endpoints > mimick the examples of RFC6690; it is a point here to have things look just > like in direct discovery. > > The if=core.a and if=core.p use values from the expired and partially abandoned > core-interfaces -- given its future is unclear, they've been replaced by > examples with tag URIs, as has the et=oic.d.sensor (a value that's registered, > but not to for et but for rt) and rt="light"; rt=sensor was dropped as it was > not essential to the example. > > The individual changes are listed in > https://github.com/core-wg/resource-directory/pull/266. > > > We should talk about the security properties of the various RD discovery > > mechanisms that are defined. > > response: > > A section was added in the security considerations on this topic (see > https://github.com/core-wg/resource-directory/pull/275 for text > changes). It does not go into the properties of each mechanism, as the host > discovery steps are generally unprotected; instead, it emphasizes the > importance of checking the RD's authorization for any security properties the > client would expect. In the context of the server authorization topic (see > OPEN-SERVER), it was added that if the authorization is conditional on the > resources being advertised with a particular resource type, that authorization > already needs to be checked during the discovery phase (details in > https://github.com/core-wg/resource-directory/pull/306). In light of the "host discovery steps are generally unprotected" point, this seems like the right choice. > As COMMENT: > > > My apologies for where these comments diverge off into rambling > > incoherency, or where I'm misunderstanding something that's clearly laid > > out; this document had the misfortune of being the last one I got to > > this week. > > > > Section 1 > > > > [RFC6690] only describes how to discover resources from the web > > server that hosts them by querying "/.well-known/core". In many > > constrained scenarios, direct discovery of resources is not practical > > due to sleeping nodes, disperse networks, or networks where multicast > > traffic is inefficient. These problems can be solved by employing an > > entity called a Resource Directory (RD), which contains information > > about resources held on other servers, allowing lookups to be > > performed for those resources. > > > > nit(?): I'd consider specifying that the RD is "a trusted entity". > > (Even when the resources themselves are authenticated, a hostile RD can > > still deny existence of a given resource, so by choosing to use an RD > > there is some level of trust involved.) > > response: > > Putting it in there as a trusted entity would give the reader a wrong > impression of the general case. Any trust placed in the RD must be earned by a > security policy backed by the RD's credentials. > > > Section 2 > > > > Resource Directory (RD) > > A web entity that stores information about web resources and > > implements the REST interfaces defined in this specification for > > discovery, for the creation, the maintenance and the removal of > > registrations, and for lookup of the registered resources. > > > > nit: the list structure is not parallel here. Maybe "for discovery, > > creation, maintenance, and removal of registrations, and for lookup of > > the registered resources"? > > response: > > The intended structure that's linearized into the sadly untreeish structure of > written language was > > * discovery > * of registrations > - creation > - maintenance > - removal > * lookup Ah! In that case, I'd suggest using semicolons for the "outer" list, and commas for separating creation/maintenance/removal. > I think this is what the current text expresses, whereas the proposed one > groups discovery with "of registrations", while it's more a top-level thing. > > > Commissioning Tool > > Commissioning Tool (CT) is a device that assists during the > > installation of the network by assigning values to parameters, > > naming endpoints and groups, or adapting the installation to the > > needs of the applications. > > > > Is "the installation of the network" a one-time event? (Might a CT be > > involved when adding a new device to a network at a later time?) > > response: > > CTs can come back to help new devices into the network; the text has been > clarified to that point in > https://github.com/core-wg/resource-directory/pull/295. > > There are remaining questions about how long a network can operate autonomously > while the CT is absent and can thus not refresh registrations, but those exceed > the scope of the document. (Discussed at > https://github.com/core-wg/resource-directory/issues/290). > > > Section 3.1 > > > > Information SHOULD only be stored in the RD if it can be obtained by > > querying the described device's /.well-known/core resource directly. > > > > When might that not be the case? > > response: > > The prime example here is with devices that don't even have a copy of what they > might want to (but can't for resource constraints) express there; those use a > CT to do their work. > > The second example I can come up with is when devices have complex > confidentiality requirements on the links, but rely on the RD and thus publish > data to an authorized RD of which they don't even know who precisely might be > authorized to read them. Thanks. Sometimes it's useful to list some example reasons to deviate from a SHOULD in the document; sometimes it's not. In this case ... I'd probably lean towards "not" (and I'm sure you will do the right thing). > > Section 3.2 > > > > The RD architecture is illustrated in Figure 1. An RD is used as a > > repository of registrations describing resources hosted on other web > > servers, also called endpoints (EP). An endpoint is a web server > > associated with a scheme, IP address and port. A physical node may > > > > (side note) hmm, I feel like in the HTTP world an endpoint is more > > likely to be associated with a DNS name than an IP address, in common > > usage. Also, we later go on to assert that the endpoint's name has > > primacy and that the IP address/port can be ephemeral. > > response: > > This is leading the reader from the CoAP definition of endpoints to the > endpoints as registrants as used in the RD. > > > An endpoint uses specific interfaces to register, update and remove a > > registration. It is also possible for an RD to fetch Web Links from > > endpoints and add their contents to its registrations. > > > > At the first registration of an endpoint, a "registration resource" > > is created, the location of which is returned to the registering > > endpoint. The registering endpoint uses this registration resource > > to manage the contents of registrations. > > > > Does the "RD fetches links unilaterally" case count as a "first > > registration of an endpoint"? I'm having a hard time seeing how these > > two statements are consistent with each other, and a naive reading > > admits the possibility that a given endpoint could be "locked out" of > > the ability to manage the contents of its registrations. > > response: > > The act of the endpoint triggering the RD to fetch links from it is the > creation. And the "locking out" is the correct reading -- a client that uses > simple client has no way of managing the contents. If it were capable enough to > do that, it'd go the regular registration route. Your response here is fine; it just caused me to do a string search for "regular registration" in the -26, where I found just a single occurrence that does not act as a definition ... perhaps a section reference would help that one instance clarify which route it means. > > Section 4 > > > > REST clients (registrant-EPs and CTs during registration and > > maintenance, lookup clients, RD servers during simple registrations) > > MUST be prepared to receive any unsuccessful code and act upon it > > according to its definition, options and/or payload to the best of > > their capabilities, falling back to failing the operation if recovery > > is not possible. In particular, they should retry the request upon > > > > "MUST be prepared [...] to the best of their abilities" seems > > non-actionable. The stuff after "In particular", on the other hand, is > > actual concrete guidance that could be mandated using normative > > language. > > response: > > Right; fixed in https://github.com/core-wg/resource-directory/pull/276. > > > Section 4.1 > > > > 1. In a 6LoWPAN, just assume the Border Router (6LBR) can act as an > > RD (using the ABRO option to find that [RFC6775]). Confirmation > > can be obtained by sending a Unicast to "coap://[6LBR]/.well- > > known/core?rt=core.rd*". > > > > nit(?): I was unaware that "Unicast" was a proper noun. > > response: > > Addressed in https://github.com/core-wg/resource-directory/pull/277. > > > Section 4.3 > > > > "core.rd" in the query string. Likewise, a Resource Type parameter > > value of "core.rd-lookup*" is used to discover the URIs for RD Lookup > > operations, core.rd* is used to discover all URI paths for RD > > operations. [...] > > > > Is the distinction between URIs (for RD Lookup) and URI paths (for RD) > > important here? > > response: > > No, it isn't. Fixed in https://github.com/core-wg/resource-directory/pull/277. > > > While the link targets in this discovery step are often expressed in > > path-absolute form, this is not a requirement. Clients of the RD > > SHOULD therefore accept URIs of all schemes they support, both as > > URIs and relative references, and not limit the set of discovered > > URIs to those hosted at the address used for URI discovery. > > > > I'm not sure I see how the "not limit [...] to those hosted at the > > address used for URI discovery" follows from the non-requirement for > > expression of the link-targets from discovery in path-absolute form. > > (Given the ability to send the discovery query to a multicast address, > > the guidance seems okay; it's just the "therefore" that is puzzling me.) > > response: > > If it was a requirement on the server, the clients could rely on it and thus > implicitly limit the set by failing to parse the full URIs. > > (It could say "explicitly or implicitly limit", but only the "implicitly > limit" case justifies the "therefore".) > > > It would typically be stored in an implementation information link > > (as described in [I-D.bormann-t2trg-rel-impl]): > > > > Req: GET /.well-known/core?rel=impl-info > > > > This seems to be depicting a link-relation type that is not registered > > at https://www.iana.org/assignments/link-relations/link-relations.xhtml > > , i.e., codepoint squatting. Please put in a stronger disclaimer that > > this is an example link relation type, not just an example exchange. > > response: > > A note has been added that the type is just proposed in a WIP document (in > https://github.com/core-wg/resource-directory/pull/278). > > > Section 5 > > > > These first few paragraphs give the impression that this is > > first-come-first-served with minimal authentication or authorization > > checking. Mentioning that there are authorization checks, with a > > forward-reference, might be helpful. > > response: > > It's more a last-come-longest-remembered, but even the most minimal security > policies would ensure that the registration resources belong to the "same" > device (for whatever the policy defines as same). > > Clarified in https://github.com/core-wg/resource-directory/pull/292. > > > further parameters (see Section 9.3). The RD then creates a new > > registration resource in the RD and returns its location. The > > > > Is this returned "registration resource" expected to function as a > > "capability URL" (https://www.w3.org/TR/capability-urls/) that would > > need to contain an appropriate amount of entropy to be reasonably > > unguessable by parties other than the registrant-ep/CT responsible for > > it? > > response: > > No, it is not a capability URL -- it will be discoverable through the endpoint > lookup interface. > > Note that around ACE, bearer tokens (which capability URLs are) are generally > discouraged in favor of proof-of-possession tokens. > > > The registration request interface is specified as follows: > > > > Interaction: EP -> RD > > > > I thought that the CT could be a requestor as well as the EP. > > response: > > Yes it can be. The expression in the interaction tables is an artifact of the > CTs being a not-even-special case of EPs, but as we have both of them in the > rest of the text, so do we now in those lists. (Changes in > https://github.com/core-wg/resource-directory/pull/309). > > > well. The endpoint name and sector name are not set when one > > or both are set in an accompanying authorization token. > > > > What should the RD do if they are set but also present in the > > accompanying authorization token? > > response: > > The wording has been updated in > https://github.com/core-wg/resource-directory/pull/273; it now (by > construction, but also explicitly) explains conflict handling. > > > Req: POST coap://rd.example.com/rd?ep=node1 > > Content-Format: 40 > > Payload: > > ;ct=41;rt="temperature-c";if="sensor", > > > > (side note) XML for the sensors, not SenML? With Carsten as an author, > > even? ;) > > response: > > This is clearly a mistake, and got removed in an emergency update in > https://github.com/core-wg/resource-directory/pull/279. > > More seriously, though, these examples are from RFC6690 (which does not have > ct= entries for reasons of chronology), and keeping them aligned is a good > thing. > > > An RD may optionally support HTTP. Here is an example of almost the > > same registration operation above, when done using HTTP. > > > > Req: > > POST /rd?ep=node1&base=http://[2001:db8:1::1] HTTP/1.1 > > Host: example.com > > > > Wouldn't "Host: rd.example.com" be closer to "almost the same > > registration"? > > response: > > Fixed in https://github.com/core-wg/resource-directory/pull/277. > > (I had brief qualms about introducing a protocol-negotiation situation here, > but performing "almost the same registration" over two protocols already > necessarily does that). > > > Section 5.1 > > > > I'm a little uneasy about specifying new behavior for POST to the > > existin /.well-known/core that was defined by RFC 6690 for other uses. > > What factors go into using the same well-known URI vs. defining a new > > one for this usage? > > response: > > It-always-having-been-that-way, primarily. As no large deployments are known, > this is fixed in https://github.com/core-wg/resource-directory/pull/259 > by switching to a standalone /.well-known/rd. > > > The sequence of fetching the registration content before sending a > > successful response was chosen to make responses reliable, and the > > caching item was chosen to still allow very constrained registrants. > > > > I'm not sure what "the caching item" is supposed to be (if it's not a > > typo/misordering of words). > > response: > > Now phrased as "the point about caching" (in > https://github.com/core-wg/resource-directory/pull/277) which should > be easier to read. A few lines up we recommend that the RD caches the .wk/c, > and this provides the rationale. > > > Section 5.3 > > > > queries concerning this endpoint. The RD SHOULD continue to provide > > access to the Registration Resource after a registration time-out > > occurs in order to enable the registering endpoint to eventually > > refresh the registration. The RD MAY eventually remove the > > registration resource for the purpose of garbage collection. If the > > Registration Resource is removed, the corresponding endpoint will > > need to be re-registered. > > > > (This MAY is actually a MUST for the simple registration case, per 5.1, > > right?) > > response: > > No, it's a choice there as well. One server may keep them around forever, and > when the simple client comes back it'll show with the same registration > resource in the resource lookup. Another server may GC it and assign a > different registration resource when it returns. It looks like I was thinking of the line about "the RD MUST delete registrations created by simple registration after the expiration of their lifetime", but I'm willing to believe there's a subtle difference between "registration" and "registration resource" that makes the situations different. > > Section 5.3.1 > > > > An update MAY update the lifetime or the base URI registration > > parameters "lt", "base" as in Section 5. Parameters that are not > > > > What about the "extra-attrs"; are they inherently forbidden from > > updates? > > response: > > The introduction paragraph was overly specific and fixed in > https://github.com/core-wg/resource-directory/pull/294. > > > base := Base URI (optional). This > > parameter updates the Base URI established in the original > > registration to a new value. If the parameter is set in an > > update, it is stored by the RD as the new Base URI under which > > to interpret the relative links present in the payload of the > > original registration, following the same restrictions as in > > the registration. If the parameter is not set in the request > > > > nit: is it the interpretation of relative links that is following the > > same restrictions as in the registration, or the new value of the > > parameter being supplied in the update? > > response: > > The restrictions apply to the new value, and were moved up there in > https://github.com/core-wg/resource-directory/pull/294. > > > The following example shows how the registering endpoint updates its > > registration resource at an RD using this interface with the example > > location value: /rd/4521. > > > > The path component "4521" contains a worryingly small amount of > > unpredictableness; I would prefer examples that used longer random > > locations, as for capability URLs. (Throughout the document, of > > course.) See also draft-gont-numeric-ids-sec-considerations, that I'm > > AD sponsoring, though I do not see any clear issues on first glance. > > response: > > See comment on the original capability URL question -- they are not. > > > (Also, it might be worth another sentence that this update is serving > > just to reset the lifetime, making no other changes, since this might be > > expected to be a common usage.) > > response: > > Stating purpose rather than mechanism now (since > https://github.com/core-wg/resource-directory/pull/294). > > > Section 6 > > > > With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level > > siblings, would it make sense to put 6.2, or at least 6.3, as > > subsections under 6.1? > > response: > > It would from a hierarchical table-of-contents point of view, but given the > focus of lookup is on resource lookup, the existing sequence captures the > narrative of "With an RD, you can look up resources, here is how you use it, > here is what it looks like, and by the way if you really need it you can even > look at the registrations themselves". > > > Section 6.1 > > > > Resource lookup results in links that are semantically equivalent to > > the links submitted to the RD. The links and link parameters > > returned by the lookup are equal to the submitted ones, except that > > the target and anchor references are fully resolved. > > > > Are the "submitted ones" the submissions at registration time, or during > > the lookup query itself? (I assume registration-time, but being > > explicit costs little.) > > response: > > Some words added for clarity in > https://github.com/core-wg/resource-directory/pull/294. > > > If the base URI of a registration contains a link-local address, the > > RD MUST NOT show its links unless the lookup was made from the same > > link. The RD MUST NOT include zone identifiers in the resolved URIs. > > > > Same link as what? > > response: > > The link the endpoint sits on; clarified in > https://github.com/core-wg/resource-directory/pull/294. I suspect that my brain was too tired to remember that there are both (web) links and (network) links, when I was reading this :) > > Section 6.2 > > > > The page and count parameters are used to obtain lookup results in > > specified increments using pagination, where count specifies how many > > > > (We haven't introduced the page and count parameters yet.) > > response: > > Wording has been enhanced in > https://github.com/core-wg/resource-directory/pull/294. > > > operator as in Section 4.1 of [RFC6690]. Attributes that are defined > > as "link-type" match if the search value matches any of their values > > > > Where is it specified how an attribute might be "defined as > > 'link-type'"? This is the only instance of the string "link-type" in > > this document, and it does not appear in RFC 6690 at all... > > response: > > That should have said "relation-types"; it does now, and also refers to > the 6690 ABNF (since > https://github.com/core-wg/resource-directory/pull/294. > > > references) and are matched against a resolved link target. Queries > > for endpoints SHOULD be expressed in path-absolute form if possible > > and MUST be expressed in URI form otherwise; the RD SHOULD recognize > > either. The "anchor" attribute is usable for resource lookups, and, > > if queried, MUST be for in URI form as well. > > > > I don't see how it can be only a SHOULD to recognize either given these > > generation criteria. > > response: > > If the URI is on a different scheme/host, I assert things are clear. (Just to > ensure I didn't get your point wrong.) > > Otherwise, in practice there can happen mistakes where server and client > disagree about the default values of the Uri-Scheme, Uri-Host and Uri-Port > options -- as anyone who's ever tried to set up an HTTP reverse proxy for a > WebDAV server can attest to. We're trying to avoid creating these situations, > but when they do happen. We don't automatically declare the offending party > broken by putting a MUST here, but encourage the peer to assist it. The client > can help by providing the relative reference (for then, disagreement passses > unnoticed), and the server by recognizing the full URI (for the client may have > obtained it and not know that it'd match what the server thinks is its Uri-Host > name). > > (The "and MUST be expressed in URI form otherwise" sounds like a factual > necessity, but it is here to rule out the corner case of a client handing out > //hostname/path style references). > > > Section 6.3 > > > > The following example shows a client performing a lookup of all > > resources of all endpoints of a given endpoint type. It assumes that > > two endpoints (with endpoint names "sensor1" and "sensor2") have > > previously registered with their respective addresses > > "coap://sensor1.example.com" and "coap://sensor2.example.com", and > > posted the very payload of the 6th request of section 5 of [RFC6690]. > > > > Er, the 6th request is a GET; do we mean to say the response to the 6th > > request? > > response: > > Yes. Fixed in https://github.com/core-wg/resource-directory/pull/294. > > > Section 6.4 > > > > The endpoint lookup returns registration resources which can only be > > manipulated by the registering endpoint. > > > > This seems to leave it unclear whether the endpoint lookup is expected > > to return resources that the requestor will not have permission to > > manipulate (in addition to those it does have permission for). > > response: > > Clarified in https://github.com/core-wg/resource-directory/pull/294. > > > While Endpoint Lookup does expose the registration resources, the RD > > does not need to make them accessible to clients. Clients SHOULD NOT > > attempt to dereference or manipulate them. > > > > But why expose them at all if they're not going to be accessible? > > response: > > They serve as identifiers (think URI rather than URL), and may additionally be > used in implementation defined operations on the resource that could be allowed > for administrators. Last but not least, link-format (unlike the upcoming CoRAL) > does not have means of talking about something without naming it. > > (I do see the point, and if we started RD anew with the benefit of having > CoRAL, chances are this would look a bit different, and the names would not be > exposed to just any lookup client). > > The WG discussion of this did, however, lead to a point added to the security > considerations about the RD's choice of what to put in there (change in > https://github.com/core-wg/resource-directory/pull/267). > > > An RD can report endpoints in lookup that are not hosted at the same > > address. [...] > > > > The "same address" as what? > > response: > > Sharpened in https://github.com/core-wg/resource-directory/pull/294. > > > Section 7.1 > > > > Whenever an RD needs to provide trustworthy results to clients doing > > endpoint lookup, or resource lookup with filtering on the endpoint > > > > How will the RD know whether the client is expecting trustworthy > > results? (When would a client *not* expect trustworthy results?) > > response: > > It won't per-client, it is configured for one. See GENERIC-WHOPICKSMODEL. > > > name, the RD must ensure that the registrant is authorized to use the > > given endpoint name. This applies both to registration and later to > > operations on the registration resource. It is immaterial there > > whether the client is the registrant-ep itself or a CT is doing the > > registration: The RD can not tell the difference, and CTs may use > > > > I suppose there might be plausible authorization models where a > > return-routability check to a given address constitutes authorization to > > use that address as an endpoint name, in which case the RD can tell the > > difference between a registrant-ep and a CT attempting to act on its > > behalf. > > WGF-6 > response: > > The RD might do such checks, but then again the EP might just be using > different network interfaces simultaneously. At that point where the EP uses a > different (and usually dormant) network interface for registration, the line > between EP and the CT gets blurry; we tolerate that blurriness because the > distinction is not so much a technical one (the REST server does not care > whether the request originates at its network peer, is proxied through there or > sent from there on behalf of someone completely different) as long as the > credentials are good. > > Frankly, I'm personally not too happy with distinguishing CTs in the first > place; it is more reflective of what I understand to be an industry practice > than a distinction in this CoAP application. > > > When certificates are used as authorization credentials, the > > sector(s) and endpoint name(s) can be transported in the subject. In > > an ACE context, those are typically transported in a scope claim. > > > > As Russ noted in the Gen-ART review, "transported in the subject" is > > sufficiently vague to not really be actionable. It might be better to > > say that the holder of the private key corresponding to the public key > > certified in the certificate is generally considered authorized to act > > on behalf of any identities (including endpoint names) contained in the > > certificate's subject name. > > response: > > See GENERIC-SUBJECT. > > > Section 7.1.1 > > > > Conversely, in applications where the RD does not check the endpoint > > name, the authorized registering endpoint can generate a random > > number (or string) that identifies the endpoint. The RD should then > > > > How much entropy/randomness in the random name? Does a CSPRNG need to > > be used? (I do see the follow-up about doubling the length in case of > > failure or starting with a UUID if that's not possible, but some > > guidance on where to start still seems appropriate.) > > respond: > > There is no requirement here as collisions only result in retries. > > For those cases where the client implementer thinks they can get away with not > implementing retry, UUID URNs are pointed to, which themselves cover the topic. > > > Section 7.2 > > > > When lookup clients expect that certain types of links can only > > originate from certain endpoints, then the RD needs to apply > > filtering to the links an endpoint may register. > > > > As before, how will the RD know what behavior clients are relying on? > > response: > > It will not. It may, however, advertise it explicitly. If, for example, an > application like LwM2M always ensures trusted endpoint names, the RD may > advertise as rt="core.rd-lokup-ep example.lwm2m", and then clients that trust > that metadatum (which they'll want to verify from some claim) know they can > trust the RD to have checked ep names. > > See also GENERIC-WHOPICKSMODEL > > > An RD may also require that only links are registered on whose anchor > > (or even target) the RD recognizes as authoritative of. One way to > > > > I don't think I can parse this sentence (especially "the RD recognizes > > as authoritative of"). > > response: > > Rephrased to "require that links are only registered if the registrant is > authorized to publish information about the anchor [...] of the link." in > https://github.com/core-wg/resource-directory/pull/294. > > > Section 8 > > > > In contexts where we discuss DTLS and TLS as being generally comparable, > > we typically will state that DTLS replay protection is required in order > > to provide equivalent levels of protection. > > response: > > This item rippled quite a bit beyond the original response of "Huh? CoAP > doesn't already do this? Well, here we need it". Thank you for following through with it to the final resolution! (I have nothing further to add and just wanted to specifically commend this.) -Ben > As things stand, requiring replay protection make it harder to exploit the > issue described at OPEN-REPLAY-FRESHNESS, but once that is addressed for good, > replay protection should not be necessary any more for the RD, as all its > operations are becoming long-term idempotent. > > > We might also want to reiterate or refer back to the previous discussion > > of the potential for attributes or resource/endpoint names, link > > relations, etc. that may need to be confidential, the relevant access > > control/filtering, and the avenues by which disclosure of resource names > > can occur even when access to those resources will not be permitted. (I > > think some of this overlaps with 8288 and 6690, but don't mind repeating > > it.) > > response: > > There is a pointer back saying that the necessary access control depends on the > protection objectives set in the policies (since > https://github.com/core-wg/resource-directory/pull/250). > > > Section 8.1 > > > > It's probably worth reiterating that all name comparisons must be done > > at sector scope (since failing to do so can lead to attacks). > > response: > > It is; fixed since https://github.com/core-wg/resource-directory/pull/296. > > > Endpoint authentication needs to be checked independently of whether > > there are configured requirements on the credentials for a given > > endpoint name (Section 7.1) or whether arbitrary names are accepted > > (Section 7.1.1). > > > > I think this is more properly authorization than authentication. > > response: > > Yes; fixed in https://github.com/core-wg/resource-directory/pull/271. > > > Section 8.3 > > > > attacks. There is also a danger that NTP Servers could become > > implicated in denial-of-service (DoS) attacks since they run on > > unprotected UDP, there is no return routability check, and they can > > have a large amplification factor. The responses from the NTP server > > were found to be 19 times larger than the request. An RD which > > > > (It's not clear to me why the specific discussion of NTP numbers is > > relevant here, since RD is not NTP.) > > response: > > The section has been shortened in > https://github.com/core-wg/resource-directory/pull/249. > > > Section 9.3 > > > > Should we also include "rt" in the initial entries? I see it is used as > > a query parameter for resource lookup in the examples in Section 6.3. > > response: > > It's used as is any other link attribute. There's no registry for them, and > while there's been talk over ond over that it would be nice, I don't think > there will be any until linkformat-CoRAL conversion is defined (and even then > it may not be comprehensive). Selectively picking some distinguished common > link attributes into this registry won't make things less messy. > > The prime line of defense against this getting messy is the expert guidance > that for some types of parameters their short names should be checked against > "commonly used target attributes". > > > > * indication of whether it can be passed as a query parameter at > > registration of endpoints, as a query parameter in lookups, or be > > expressed as a target attribute, > > > > (Since this text does not clarify about lookup of endpoints vs. > > resources... > > > > Review" as described in [RFC8126]. The evaluation should consider > > formal criteria, duplication of functionality (Is the new entry > > redundant with an existing one?), topical suitability (E.g. is the > > described property actually a property of the endpoint and not a > > property of a particular resource, in which case it should go into > > the payload of the registration and need not be registered?), and the > > > > ... and this text suggests that query parameters for *resource* lookups > > need not be registered.) > > > > potential for conflict with commonly used target attributes (For > > example, "if" could be used as a parameter for conditional > > registration if it were not to be used in lookup or attributes, but > > would make a bad parameter for lookup, because a resource lookup with > > an "if" query parameter could ambiguously filter by the registered > > endpoint property or the [RFC6690] target attribute). > > > > Then why do we use it as an example of lookup filtering in Section 6.2? > > response: > > The text suggests that target attributes for registered resources need not be > registered. These unregistered wild-west attribute names can be used both with > resource lookups (matching only resources which), and in endpoint lookups > (matching endpoints that contain any resource which). > > If `if` were to be put in for use in an RD parameter used with lookup, that > would not per se create ambiguous queries (the rules would still say "matches > either"), but the results would be prone to causing confusion. > > > Section 10.1.2 > > > > Should we really be using unregistered resource types (i.e., codepoint > > squatting) in the examples? > > response: > > Addressed together with the earlier code squatting comments in > https://github.com/core-wg/resource-directory/pull/266. > > > After the filling of the RD by the CT, the application in the > > luminaries can learn to which groups they belong, and enable their > > interface for the multicast address. > > > > Just to check: the luminaries are learning their own group membership by > > querying the resource directory? > > response: > > Not directly. They (in this very particular example that seems to be based on > industry process but which I'd not necessarily recommend for imitation) use a > heuristic to find any multicast URI they might possibly provide, and join that > group. > > > Section 10.2.2 > > > > Please expand MSISDN. > > response: > > Taking a step back from this and other comments led to a drastical shortening > of the example. > > See also GENERIC-ODDEXAMPLES > > > Section 13.2 > > > > I think RFC 7252 should probably be normative. > > > > Likewise for RFC 8288 ("the query parameter MUST be [...] a token as > > used in [RFC8288]"). > > response: > > RFC7252 (CoAP) and RFC7230 (HTTP) were promoted to a normative reference. > (RFC7641 (CoAP observe) wasc left as informative because while they are > optional components, RD is not so much specified using them but more happens to > combine with them). > > RFC8288 was also promoted, but not due to the quoted line (that's not > implementation relevant but merely setting out rules for the registry > operation), but because we explicitly pull it in in terminology and the > information model. > > (Changes in https://github.com/core-wg/resource-directory/pull/307). From nobody Wed Feb 10 19:53:40 2021 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 391A33A10B4; Wed, 10 Feb 2021 19:53:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161301561820.4693.9535939287401361803@ietfa.amsl.com> Date: Wed, 10 Feb 2021 19:53:38 -0800 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT) 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: Thu, 11 Feb 2021 03:53:38 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-resource-directory-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates in the -26; they help a lot. I'm particularly happy to see the (default/example) "first-come-first-remembered" policy in § 7.5, which does a good job of documenting its properties (including potential deficiencies) and can be usable for many environments. (I do have some suggestions for improvements to the specific wording in the section-by-section comments, but on the whole I like it.) It does lead in to a more general comment, though (which is not exactly new to the changes in the -26 though it is reflected in several of them): some aspects of the concept of "authorization" to appear in a directory, and the verification of authorization for the entire flow from client locating the RD server to final request at the discovered resource, are somewhat subtle. (The new text discusses, e.g., "repeat the URI discovery step at the /.well-known/core resource of the indicated host to obtain the resource type information from an authorized source" and "a straightforward way to verify [discovered information] is to request it again from an authorized server, typically the one that hosts the target resource".) The aspects I'm concerned about are not matters of a resource server being authorized to publish to a directory or a client deeming that a server is authorized to act as an RD (though both of those are also important), but seems to rather just be relating to the RD faithfully disseminating the information the RD retrieved from /.well-known/core discovery on the given server(s) (or otherwise learned via some other mechanism). In this sense the RD is just acting as a cache or efficiency aid, but the authoritative source of the information remains (in general) the server hosting the resource. To be clear, I think the procedures that this document specifies are good and correct procedures for a client to perform, I'm just not sure whether "authorized" is the right term in these cases; "authoritative" might be more appropriate, in that the operation in question is to verify the information retrieved from the RD (which acts in some sense as an intermediary) at the more authoritative source. (On a tangent from that note, it seems that there is not necessarily any indication to a client that a server claiming to provide a given resource (whether discovered via RD or /.well-known/core) is actually authorized to provide such a resource and be trusted by the client. But that's not really a property of RD, and rather the underlying CoRE mechanism and any provisioned trust database, so my thoughts about it seem out of scope for this document.) Section 5.1 URI Template Variables are as they are for registration in Section 5. The base attribute is not accepted to keep the registration interface simple; that rules out registration over CoAP-over-TCP or HTTP that would need to specify one. For some time during this document's development, the URI template "/.well-known/core{?ep,...}" has been in use instead. (It's not entirely clear to me what the reader is expected to do with the information about the previous formulation.) Section 7.3 In this case, the endpoint (and not the lookup clients) needs to be careful to check the RD's authorization. (It seems that something also needs to cause the RD to check the authorization of lookup clients to receive the information in question, which might be worth reiterating in this section.) Section 7.5 * If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be the system's trust anchor store), all those subject names are stored. [...] I'm pretty sure the intent here is that only the subject names that are certified by the recognized authority(ies) are stored, in which case I'd suggest to s/all those/all such/. With X.509 certificates, the Common Name (CN) and the complete list of SubjectAltName entries are stored. In both cases, the authority that certified the claim is stored along with the subject, as the latter may only be locally unique. (I can understand why the "store the whole list" logic is used, though there may be some subtleties about name constraints on the (X.509) CAs used, which is why we typically don't recomment treating the entire list of names in the certificate as validated from a single operation, instead preferring "is this certificate authenticated for this specific name?" when the specific target name is available.) * If neither is present, a reference to the security session itself is stored. With (D)TLS, that is the connection itself, or the session resumption information if available. With OSCORE, that is the security context. Should we talk about whether the lifetime of registration entries is related to the various lifetimes of these credentials/identifiers? DTLS without resumption is perhaps an interesting case, in that keeping the DTLS association "live" just to be able to update the registration information seems impractical, so perhaps some fixed cap would be applied on the lifetime in that case. If resumption is used, the resumption information (ticket or session state) has some finite lifetime that could be used to bound the lifetime of the registration. IIRC an OSCORE security context can also have an expiration time; certificates and JWT/CWT have expiration time as well (though the procedures in the first bullet point would effectively allow a "renewal" operation), but the validity period (if any) of a raw public key would have to be provisioned along with that key (or just have RPK be handled akin to DTLS without resumption, I guess). Any operation on a registration resource, including registrations that lead to an existing registration resource, MUST be rejected by the RD unless all the stored information is found in the new request's credentials. (Similar to my earlier parenthetical comment, the requirement for exact match of all subject name information is unusual. In effect this is a way of pinning the set of names that the CA has chosen to include in a single certificate, which is arguably a stronger requirement than needed but should not lead to any unauthorized access.) From nobody Fri Feb 12 00:40:01 2021 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 3AC773A141B for ; Fri, 12 Feb 2021 00:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 YwOsOaIn1m6n for ; Fri, 12 Feb 2021 00:39:54 -0800 (PST) Received: from wforward2-smtp.messagingengine.com (wforward2-smtp.messagingengine.com [64.147.123.31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4873A1418 for ; Fri, 12 Feb 2021 00:39:54 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 148749C0; Fri, 12 Feb 2021 03:39:53 -0500 (EST) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Fri, 12 Feb 2021 03:39:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KtKCV+ LAkOmpKimnOPev1u+N0yi9O9Cl99Iw+xQyQV0=; b=LHzfEIk7UkRvUkglFEp9yF mm8xx9nC8Qt8im9N7mvZL0J+yMaBG7mDbvP10tD0Mfps8XNjYEGE6G9kAL67QKe/ yXWl3QJsv+6hgy2pOyiV3+Dbnh7LyQUA+9HwwxsinwKMym2kBI/3IscfeVIgMXoN 4hIGhLixhbWD3UyS9aBjP7AV0107KlTJyfix1rlJhvqYkDkb6sJcOzVipwBlQQ/5 l4Red9SiWOZ7B1sm/NiimgqOPeYzCGTetmkXtPh0yrBJfeNo0PWqcGm3VEG185Fp NV7Is9ns/hOl6Zyl8XREbtWJoRxL77DOK6vx9EqfJGmIbl25uGUXGL2i/qqp9lDg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledriedtgdduvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgfgsehtqhertderreejnecuhfhrohhmpeflrghimhgv pgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpe fggfejkeelgfeiteehfffftddtgeejffehfeevudetteelgfdvheegfeeltdegvdenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvse hikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B5CCB420067; Fri, 12 Feb 2021 03:39:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <422b8d83-ee97-4a6c-81ec-3cf004f2cd09@www.fastmail.com> Date: Fri, 12 Feb 2021 10:39:30 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org, "Carsten Bormann" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [core] Review of draft-ietf-core-senml-versions-01 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, 12 Feb 2021 08:39:59 -0000 Dear authors, first of all I'd like to apologise for the delay when providing the revi= ew. While I did not find any mistakes, there are few additions to the docume= nt that *could* help clarify it for the benefit of the readers: - Mention somewhere in the text that the maximum amount of features is 5= 3 and that therefore the highest version number is 2**53-1 in decimal no= tation. Therefore readers should not expect the usual linear semantic ve= rsioning for each version (1,2,3,4...) but rather (10, 26, 42, 58...). - Give an example of the current bitmap -for example in a double or floa= t representation- providing all features that are currently supported fo= r bver=3D26. 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00011010 - The limitation to 53 versions in total as well as potential feature de= precation was already discussed in various IETFs and neither authors nor= the group see that as a limitation. I agree with that providing that ex= pert review is conservative when adding new features. Potentially we cou= ld also think about bundling some future features if they are related be= fore publication; but it is very hard to forecast that. Note that, ahead of the shepherd writeup, it would be good to document e= xisting implementations out there. Editorial: "Network Working Group" should be CoRE. independently selectable "features" Use of quotes for features seems unnecessary, as those literally are fea= tures. =20 =20 Ciao! --=20 Jaime Jim=C3=A9nez From nobody Fri Feb 12 01:48:49 2021 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 491823A14C8 for ; Fri, 12 Feb 2021 01:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNHg8w0tohzY for ; Fri, 12 Feb 2021 01:48:44 -0800 (PST) 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 84B993A14C6 for ; Fri, 12 Feb 2021 01:48:44 -0800 (PST) Received: from [192.168.217.152] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DcTGJ3P3tzyVj; Fri, 12 Feb 2021 10:48:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Carsten Bormann In-Reply-To: <422b8d83-ee97-4a6c-81ec-3cf004f2cd09@www.fastmail.com> Date: Fri, 12 Feb 2021 10:48:31 +0100 Cc: core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3388E5A7-FF68-490A-8DA8-075CBF94DEDE@tzi.org> References: <422b8d83-ee97-4a6c-81ec-3cf004f2cd09@www.fastmail.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [core] Review of draft-ietf-core-senml-versions-01 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, 12 Feb 2021 09:48:48 -0000 On 12. Feb 2021, at 09:39, Jaime Jim=C3=A9nez wrote: >=20 > Dear authors, >=20 > first of all I'd like to apologise for the delay when providing the = review. >=20 > While I did not find any mistakes, there are few additions to the = document that *could* help clarify it for the benefit of the readers: >=20 > - Mention somewhere in the text that the maximum amount of features is = 53 and that therefore the highest version number is 2**53-1 in decimal = notation. Therefore readers should not expect the usual linear semantic = versioning for each version (1,2,3,4...) but rather (10, 26, 42, 58...). Actually, that is already mentioned in the IANA Considerations. I have now added a subsection =E2=80=9CDiscussion=E2=80=9D to Section 2 = . > - Give an example of the current bitmap -for example in a double or = float representation- providing all features that are currently = supported for bver=3D26. >=20 > 00000000 00000000 > 00000000 00000000 > 00000000 00000000 > 00000000 00011010 This example has 64 bits; we only have 53=E2=80=A6 I=E2=80=99ve put in = 0b00000000000000000000000000000000000000000000000001010 as an example. > - The limitation to 53 versions in total as well as potential feature = deprecation was already discussed in various IETFs and neither authors = nor the group see that as a limitation. I agree with that providing that = expert review is conservative when adding new features. Potentially we = could also think about bundling some future features if they are related = before publication; but it is very hard to forecast that. Added discussion of an allocation rate limit of about two codes per year = or less. > Note that, ahead of the shepherd writeup, it would be good to document = existing implementations out there. >=20 > Editorial: >=20 > "Network Working Group" should be CoRE. (Will go away in the RFC.) > independently selectable "features" > Use of quotes for features seems unnecessary, as those literally are = features. =20 Went for italic (but not in the abstract, where fonts are more easily = lost). Thanks! Now https://github.com/core-wg/senml-versions/pull/1 (WG members: Please review and approve and/or comment!) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 12 02:18:48 2021 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 135AD3A150F for ; Fri, 12 Feb 2021 02:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 TYKORHN27gPs for ; Fri, 12 Feb 2021 02:18:44 -0800 (PST) Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2693A1510 for ; Fri, 12 Feb 2021 02:18:44 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 28AA49DC; Fri, 12 Feb 2021 05:18:41 -0500 (EST) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Fri, 12 Feb 2021 05:18:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=3uZ1U0a6MS9IdgQVWx30dr4dxv5Thq63sPFB3U9tN J8=; b=GDbeaXF70yvMe813rP5qmL3/ySyIFdmPMVp282TGE+yhtjyFBxAHKjeTa 15QOVDatUj74flioxVsIyMNTLj+Nz9EiDpKudyuFMrlU2FwoFvF082kXpb+Z6niC 9KdpwqLowBT/Rg+fiKBluOuCAJd0OlrrHjn5HW+pYJ7/ffhdV/NZJEESJUqmYvMB sXJc2ckfCYC6j1SOW5Dz/g3euZ+AUn3XHBMfaGaTbWUJcVtfN00pRFrlZogA3DPN e0BZR0jAcj+GavPbFvMHoI5XmJ+DMfuxZLXzsKCXfRWdeZcqtdoyM+U2S86vkttv SmqBNzmg+8wOpk0wMIrSDhDvVC7MQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledriedugddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomheplfgrihhm vggplfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnh epueeileevteevudejtdeuvdelheffuedtuddtieetgeegfeeijeeivdevfeevudfgnecu ffhomhgrihhnpehtrhgrvhhishdqtghirdhorhhgpdhgihhthhhusgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvsehi khhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EB274420067; Fri, 12 Feb 2021 05:18:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <232df620-b11d-4fd4-b9ed-4be6e1ab411f@www.fastmail.com> In-Reply-To: <3388E5A7-FF68-490A-8DA8-075CBF94DEDE@tzi.org> References: <422b8d83-ee97-4a6c-81ec-3cf004f2cd09@www.fastmail.com> <3388E5A7-FF68-490A-8DA8-075CBF94DEDE@tzi.org> Date: Fri, 12 Feb 2021 12:18:19 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "Carsten Bormann" Cc: core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Review of draft-ietf-core-senml-versions-01 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, 12 Feb 2021 10:18:47 -0000 Thanks Carsten, much more clear now, I added the review on GitHub. BTW there seems to be some travis-ci issue.=20 https://travis-ci.org/github/core-wg/senml-versions/jobs/758663186 I have replicated the same error on other repos. It seems the container = is not launched for some reason.=20 Also, in few weeks we might have to spend some time migrating from travi= s-ci.org to .com. I don't think it will be fully automatic. Ciao! --=20 Jaime Jim=C3=A9nez On Fri, Feb 12, 2021, at 11:48 AM, Carsten Bormann wrote: > On 12. Feb 2021, at 09:39, Jaime Jim=C3=A9nez wrote: > >=20 > > Dear authors, > >=20 > > first of all I'd like to apologise for the delay when providing the = review. > >=20 > > While I did not find any mistakes, there are few additions to the do= cument that *could* help clarify it for the benefit of the readers: > >=20 > > - Mention somewhere in the text that the maximum amount of features = is 53 and that therefore the highest version number is 2**53-1 in decima= l notation. Therefore readers should not expect the usual linear semanti= c versioning for each version (1,2,3,4...) but rather (10, 26, 42, 58...= ). >=20 > Actually, that is already mentioned in the IANA Considerations. > I have now added a subsection =E2=80=9CDiscussion=E2=80=9D to Section = 2 . >=20 > > - Give an example of the current bitmap -for example in a double or = float representation- providing all features that are currently supporte= d for bver=3D26. > >=20 > > 00000000 00000000 > > 00000000 00000000 > > 00000000 00000000 > > 00000000 00011010 >=20 > This example has 64 bits; we only have 53=E2=80=A6 > I=E2=80=99ve put in 0b000000000000000000000000000000000000000000000000= 01010 as=20 > an example. >=20 > > - The limitation to 53 versions in total as well as potential featur= e deprecation was already discussed in various IETFs and neither authors= nor the group see that as a limitation. I agree with that providing tha= t expert review is conservative when adding new features. Potentially we= could also think about bundling some future features if they are relate= d before publication; but it is very hard to forecast that. >=20 > Added discussion of an allocation rate limit of about two codes per=20= > year or less. >=20 > > Note that, ahead of the shepherd writeup, it would be good to docume= nt existing implementations out there. > >=20 > > Editorial: > >=20 > > "Network Working Group" should be CoRE. >=20 > (Will go away in the RFC.) >=20 > > independently selectable "features" > > Use of quotes for features seems unnecessary, as those literally are= features. =20 >=20 > Went for italic (but not in the abstract, where fonts are more easily = lost). >=20 > Thanks! >=20 > Now https://github.com/core-wg/senml-versions/pull/1 > (WG members: Please review and approve and/or comment!) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > From nobody Fri Feb 12 16:37:55 2021 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 7F3813A11CD; Fri, 12 Feb 2021 16:33:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641250.31337.2541379234766715298@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:32 -0800 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 110 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: Sat, 13 Feb 2021 00:33:41 -0000 Dear Marco Tiloca, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (2:00 requested) Monday, 8 March 2021, Session III 1700-1900 Room Name: Room 2 size: 502 --------------------------------------------- core Session 2 (2:00 requested) Friday, 12 March 2021, Session I 1300-1500 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/core.ics Request Information: --------------------------------------------------------- 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, 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: ace cbor t2trg cose lake artarea Technology Overlap: teep saag secdispatch sacm lwig 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;amp;PRGs tht mght cme up. Prefer some time between the two meetings (48 h or more). --------------------------------------------------------- From nobody Fri Feb 12 23:42:06 2021 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 4D1163A1076; Fri, 12 Feb 2021 23:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 2MIo-0MGtgpd; Fri, 12 Feb 2021 23:41:52 -0800 (PST) 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 629543A1075; Fri, 12 Feb 2021 23:41:52 -0800 (PST) Received: from [192.168.217.152] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4Dd2PT5m1MzyT7; Sat, 13 Feb 2021 08:41:49 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Sat, 13 Feb 2021 08:41:49 +0100 Message-Id: To: ace@ietf.org, core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF110: "FINAL" AGENDA 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, 13 Feb 2021 07:41:57 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF110. Remember that further agenda changes can still happen. A number of changes have been made with respect to the draft agenda. CBOR has moved to Monday into what was ASDF's slot, and ASDF is now on top of IOTOPS (ugh). COSE has moved into Friday's middle slot that had been used by CBOR. Other conflicts that remain are LAKE/RATS, CORE/DANISH -- you just can't do both IoT application layer and IoT security this time (ROLL/SUIT and LPWAN/RATS are probably bearable). All times *on my agenda* are in UTC (the default page is UTC+0100). https://datatracker.ietf.org/meeting/agenda-utc might be handy, and the main agenda tool now has an awesome timezone selection tool. Note that both EU and US are still on winter time (standard time) then; the US moves forward on Mar 14 with the EU following Mar 28 -- we'll have two weeks of confusion this time right after the IETF. Gr=C3=BC=C3=9Fe, Carsten MONDAY, March 1, 2021 1600-1800 Hackathon Kickoff Rm 1 GEN hackathon Hackathon THURSDAY, March 4, 2021 1700-1900 Technology Deep Dive Rm 1 tdd Technology Deep Dive FRIDAY, March 5, 2021 1600-1800 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, March 8, 2021 1200-1400 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF irtfopen IRTF Open Meeting Rm 6 RTG raw Reliable and Available Wireless WG Rm 8 SEC emu EAP Method Update WG 1430-1530 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 2 IRTF maprg Measurement and Analysis for Protocols Rm 3 RTG detnet Deterministic Networking WG Rm 5 RTG rift Routing In Fat Trees WG Rm 6 SEC mls Messaging Layer Security WG 1600-1800 Session III Rm 2 ART *** core Constrained RESTful Environments WG Rm 3 ART webtrans WebTransport WG Rm 7 SEC tls Transport Layer Security WG Rm 8 TSV tsvwg Transport Area Working Group WG TUESDAY, March 9, 2021 1200-1400 Session I Rm 3 INT 6man IPv6 Maintenance WG Rm 6 RTG bier Bit Indexed Explicit Replication WG Rm 8 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 9 SEC *** rats Remote ATtestation ProcedureS WG 1430-1530 Session II Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things WG Rm 4 INT add Adaptive DNS Discovery WG Rm 5 OPS *** iotops IOT Operations WG Rm 6 RTG babel Babel routing protocol WG Rm 7 RTG detnet Deterministic Networking WG Rm 9 SEC acme Automated Certificate Management = Environment WG 1600-1800 Session III Rm 3 INT *** drip Drone Remote ID Protocol WG Rm 5 OPS v6ops IPv6 Operations WG Rm 8 SEC gnap Grant Negotiation and Authorization = Protocol WG Rm 9 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG WEDNESDAY, March 10, 2021 1200-1400 Session I Rm 2 ART jsonpath JSON Path WG Rm 3 IRTF icnrg Information-Centric Networking Rm 8 SEC *** teep Trusted Execution Environment = Provisioning WG Rm 9 TSV quic QUIC WG 1430-1530 Session II Rm 4 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Rm 5 IRTF qirg Quantum Internet Research Group Rm 6 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvwg Transport Area Working Group WG THURSDAY, March 11, 2021 1200-1400 Session I Rm 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 3 INT add Adaptive DNS Discovery WG Rm 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG - Joint with HOMENET Rm 4 INT homenet Home Networking WG - Joint with DNSSD Rm 8 SEC saag Security Area Open Meeting Rm 9 TSV tsvarea Transport Area Open Meeting 1430-1530 Session II Rm 3 IRTF panrg Path Aware Networking RG Rm 6 RTG *** roll Routing Over Low power and Lossy = networks WG Rm 7 SEC openpgp Open Specification for Pretty Good = Privacy WG Rm 8 SEC *** suit Software Updates for Internet of Things = WG 1600-1800 Session III Rm 2 INT 6man IPv6 Maintenance WG Rm 4 IRTF*** t2trg Thing-to-Thing Rm 7 RTG rtgarea Routing Area Open Meeting - Joint with = RTGWG Rm 8 SEC secdispatch Security Dispatch WG FRIDAY, March 12, 2021 1200-1400 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 IRTF cfrg Crypto Forum Rm 7 SEC *** danish DANE AutheNtication for Iot Service = Hardening BOF 1430-1530 Session II Rm 3 ART wpack Web Packaging WG Rm 4 INT intarea Internet Area Working Group WG Rm 6 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 8 SEC *** cose CBOR Object Signing and Encryption WG 1600-1800 Session III Rm 1 ART httpapi Building Blocks for HTTP APIs WG Rm 2 IRTF coinrg Computing in the Network Research Group Rm 6 SEC *** ace Authentication and Authorization for = Constrained Environments WG Rm 8 SEC privacypass Privacy Pass WG From nobody Mon Feb 15 14:01:44 2021 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 1179B3A1245; Mon, 15 Feb 2021 14:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=H5Fwlpfh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mNvJSJbr 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 Sn7pC7HynbGF; Mon, 15 Feb 2021 14:01:35 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35ABF3A12C1; Mon, 15 Feb 2021 14:01:20 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 393F35C00DF; Mon, 15 Feb 2021 17:01:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 15 Feb 2021 17:01:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=v +RVpklP7/Yw2EjdMl56x06nI07b0D027BlGgYDRqyE=; b=H5FwlpfhnzV9S29Jq SD/CoMmhZNVXSgu6skBM2o9x2JwjT5OULwoIXUyWeY+5cOI6XObqEIa0vjvnCIVb Vb0vg7x/smpOY3rWMuHH0QksZdEVpFiKKa3fOYNvNH2xKcQBaN+kEFsubjfJE94H Rwro2hltr7j5feLL03Awcg8hUgz9Uqw88DkgSBNdVUKFO0YLWvSEc0g+rcfqd0qr vGuyuk9MFT0CxmrrJGy3UO6FQ4RDihUZIhEPJJ15Q8OGjf5eA5m4ylFpUsxujOpD y7E6dbrDJxXmCCKpj8zi4ClURYJeNOplDQFXz11pIaTpFfffsJ9tBeOrmhiAIlP/ SR14w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=v+RVpklP7/Yw2EjdMl56x06nI07b0D027BlGgYDRq yE=; b=mNvJSJbrjYW9DZDoa9bdHPrsIo6lEbYluHGsTIJlTkD0DGHsNyin7rHLN tBPD5Xr0laiYu3/6HfGGDEEGhNuo5Lwpo2xX6DqLjIww4YByS/dwocfmYl6Y3z2l xoVUAdlYAA0qAX7kkpMitC38vXjEjoiGSOCdcg9cnYzN4RAJllcAIkYBjkb5zRDr T5S4xx/noUqHlOSLV4tQWeOFcIXAshinfaxGHMQ3knKsgZ+z+4e7tbj54INDeXKU 13P2NAkwY2A3fwe8lKbGxhPaBNRPtyJ40Vlvy88Ofa2vE1aBfKFn5s/QIUJhxb8T L3pU8WY3WUGxzKhJBoQ0q6iNACT5g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieekgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrg htthgvrhhnpefguedtkeethfekleehheethedvkeektedtvddvjefghfeikeffgeegveef ueegtdenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedrudduje drieehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-vpn3-175.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 9129724005A; Mon, 15 Feb 2021 17:01:18 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: Date: Mon, 15 Feb 2021 17:01:14 -0500 Cc: draft-ietf-core-echo-request-tag.all@ietf.org, Gen Art , core@ietf.org, Last Call Content-Transfer-Encoding: quoted-printable Message-Id: <37F35A21-4470-41D1-B106-AB7DFE07E60A@cooperw.in> References: <160693301574.8084.12485735068228324677@ietfa.amsl.com> To: =?utf-8?Q?=22Christian_M=2E_Ams=C3=BCss=22?= , Ines Robles X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-echo-request-tag-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: Mon, 15 Feb 2021 22:01:39 -0000 Ines, thanks for your review. Christian, thanks for your response. I = entered a No Objection ballot. Alissa > On Dec 9, 2020, at 9:10 AM, Christian M. Ams=C3=BCss = wrote: >=20 > Hello Ines, >=20 > thanks for your comments. >=20 > The expansions are done or WIP in our version, and will be part of the > next editing iteration. >=20 >> 2.- Figure 1 and Figure 4 have two columns named "U" (Unsafe), is = that Ok?, or >> should one of these columns be deleted/renamed? >=20 > That's indeed unfortunate; given tables of this format are common in > CoRE, I'll be checking back for the best course of action (but either > way it's to be fixed). >=20 > Best regards > Christian >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Feb 15 22:10:12 2021 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 78F203A0E27; Mon, 15 Feb 2021 22:10:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <161345580998.26953.3022353784814348423@ietfa.amsl.com> Date: Mon, 15 Feb 2021 22:10:10 -0800 Archived-At: Subject: [core] Erik Kline's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) 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: Tue, 16 Feb 2021 06:10:11 -0000 Erik Kline has entered the following ballot position for draft-ietf-core-echo-request-tag-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ nits ]] [ section 2.4 ] * "causing overheads" -> "causing overhead" From nobody Tue Feb 16 04:13:43 2021 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 634D83A0A2D; Tue, 16 Feb 2021 04:13:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se, lear@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <161347761786.11909.15773072075789476433@ietfa.amsl.com> Date: Tue, 16 Feb 2021 04:13:38 -0800 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-echo-request-tag-12=3A_=28with_COMMENT=29?= 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: Tue, 16 Feb 2021 12:13:39 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-echo-request-tag-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated). Eliot Lear (in copy) has also reviewed the document as IoT directorate reviewer at: https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-12-iotdir-telechat-lear-2021-02-05/ So, please address/reply to his comment. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2.2 -- "The Echo option value is a challenge from the server to the client..." Just wondering whether "echo" is the right choice for the option as it is too close to ICMP_ECHO_REQUEST, why not "challenge" ? I would have expected some statements related to non-idempotent requests (generic statement) and then specific examples such as actuators. -- Section 2.2.1 -- Are the authors confident enough to state a minimum length of 1 octet ? If the intent of the document is to prevent replay attack, then I wonder whether one octet is enough... Unsure whether Section 5 (security considerations) addresses this issue correctly. From nobody Tue Feb 16 04:16:57 2021 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 4E1AB3A0A65; Tue, 16 Feb 2021 04:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AFhR/YVn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XLmPWGSM 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 UowPmLSrEAUF; Tue, 16 Feb 2021 04:16:48 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA363A0A3F; Tue, 16 Feb 2021 04:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5958; q=dns/txt; s=iport; t=1613477808; x=1614687408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F1DJbprZ/AT4WSETc1D9yPkcMzb8ThtDm3E4xd3K1vU=; b=AFhR/YVnFqIxPkqVwj0qxiQiHMxC25v+/EeKBQoZBPk++U/QahKsABPS k7nN+hwC3+J6bUADiP+LxOutq1J32WGORvGaJzxGdmoY4GKMIhzP0mc6m 8bOA0ZSCJVOd8sGooi1zmaxDbOWmqsTGMXVstCn14BaBEKeAdJeoe+z7e Y=; IronPort-PHdr: =?us-ascii?q?9a23=3ASDL2YBHI0VIMpz07/zdRhp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gObUYDS8fkCiufKvebnQ2NTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrni79zVUGx?= =?us-ascii?q?jjO0xyPOumUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHEQCdtitg/5ldJa1iHgEBCxIMQIF?= =?us-ascii?q?RgVEpKAeBUDYxhEGDSAOOCAOZHYJTA1QLAQEBDQEBMgIEAQGETQIXgXICJTg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQYEcYVhDUMBEAGFbwEBAQMBIxEMAQE3AQsEAgEIEQM?= =?us-ascii?q?BAgECAiYCAgIwFQgIAgQBDQWCcIJWAw4gAaI7AooldoEygwQBAQaFDxiCEgm?= =?us-ascii?q?BDioBgnWCb1BIhkUmHIFBQYERJxyCVz5rGQGBWASBNAsGGIMWNIIrgkREKjs?= =?us-ascii?q?4LywKDAdGIwMBDQIKDQYBQpNHpD8JgQsKgnqcCwMfoy2UOp0jIIQ5AgQCBAU?= =?us-ascii?q?CDgEBBoFsI4FXcBVlAYI+UBcCDY4fDAwLFG4BCASCP4pZcwI1AgYBCQEBAwl?= =?us-ascii?q?8hWSCb4JEAQE?= X-IronPort-AV: E=Sophos;i="5.81,183,1610409600"; d="scan'208";a="860908461" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Feb 2021 12:16:47 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 11GCGktn017849 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Feb 2021 12:16:47 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 16 Feb 2021 06:16:46 -0600 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 16 Feb 2021 06:16:46 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Tue, 16 Feb 2021 06:16:46 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CAJ9jnUSlZYPUQj/RuxCa159WhHhGCIrMVGGQvNgarMNfXr+lLcugp+MM6Mu0eUOSJoJ41BDX2iLRTirj0xte2KbXONp97AY7btZuoaSAYzN0kWhjmhwalwKZ3c1LHz4Mc1HRqlAMwDMoBxuWd9Uhf0ZMViexM6uh67W5gOdUwiV8hmXGqs/5vTX/j881gBl5TrZht11KAWAqiOrOszR8wyU+piGMKDsaHEauDoDlnGSERevqe6HBMcIULrsiO4t0cXk/NcKPdaE8xqXlGkOG6QSSfcTRxFRlSQIgsDY5CcV7StqbJ8JYbFOToDhj/D3GhVMkCYDUHDIvj8lZYQVVA== 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=F1DJbprZ/AT4WSETc1D9yPkcMzb8ThtDm3E4xd3K1vU=; b=BrlIntwGP2R+LxpUfiULBttw4Z8QMcPsCyvVtaY+MClgQBvETZjH+9enw4yn22qjWBEs2NlkFmuwOpTww5aAI610aCN2oKIzh2Iq/kwQAgqRZLIjv2PTjUZQs3+stR/g6ZoqW5svZwZMorN2CmPzhxMP2rTiClOpaO77FZ4VXcgwo6/pPhtXKH1U7BH3iIu1imMQVK+x7L4uH6qbXccFKTqld5sKMLpNnEOk9Zv/ADNRmnxQVHIYsHqmv4vWGfAA2uqYWrBEl48gXN3zXU4kkj/LaUsSJ0j3GqQok9GnL5egIr50eZEViOVwcoKrZcEk33j4tz5ekU9kzbFRmbyaUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F1DJbprZ/AT4WSETc1D9yPkcMzb8ThtDm3E4xd3K1vU=; b=XLmPWGSMREnQ10T3R8jgP6j4sUGLhEGgosDT8/U+U5yaCY9Feo0reECqM7H3IzdI4dAV1GQqpheYlyqd1VA3xM0JykH6dXXEITY9bX7YpGYOEhiu7/LN1B/k2tD/D82Y+/JzS9Zsy/iHdxLLVoJ8Gnyy1b3dpnHQKeNhn4/n7Fo= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4888.namprd11.prod.outlook.com (2603:10b6:510:32::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Tue, 16 Feb 2021 12:16:45 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3846.043; Tue, 16 Feb 2021 12:16:45 +0000 From: "Eric Vyncke (evyncke)" To: Eliot Lear , =?utf-8?B?IkNocmlzdGlhbiBNLiBBbXPDvHNzIg==?= CC: "iot-directorate@ietf.org" , "core@ietf.org" , "draft-ietf-core-echo-request-tag.all@ietf.org" Thread-Topic: [Iot-directorate] Iotdir telechat review of draft-ietf-core-echo-request-tag-12 Thread-Index: AQHW++HbAqveKn9Cf0S4GalseRTV6qpJ16oAgAAQ5oCAEOucgA== Date: Tue, 16 Feb 2021 12:16:44 +0000 Message-ID: <068E0EBB-BCCA-44ED-AAE1-0C73F40B5C8E@cisco.com> References: <161254498927.30549.15609771383242038227@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:ecdc:c86f:cff9:1167] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa13241a-666f-4231-4715-08d8d274b9f9 x-ms-traffictypediagnostic: PH0PR11MB4888: 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: UOQ0Z+PbB9ydfsKGrZQs2esN8IUqFT6EfEfDcGmeGF+zzDs6mNY39nD6auHw4ACSk7Ff7dlQZjqb8RRJlOvVcZ/f63Gt0WtQTSip8uKA2ZvikzqJi3Z/PwJURz2udceCykv9iyZK7uHnJLPxO921Er1SOZbVzndsYNW1fp8XUYJCcI0fGJfjmCWq/Ea0G7dPv7sgZW9RxRquQB7YQIQMwGNWh+K63MGW+Y1hxDAySNpiLifsg7YXirq+6ooSUamk4TwOckakKIb8RxTKpSqFPPiKYO4i8n1yK4+35e2kCnrx9rRTyOqFnw23uM7IV/ZIAVmJtQzEiAxvRWdzfoV5CzG87ve7DESIGCuaCkyBoZxklNMZLESz8nhDGsYWkdoIiXEMzqz8NlMwPaBmCOs0WY5APpdAWjfa9XV8b5anX2jN13vi1Dga3JX9SmMvGC1Rr1fCfD2p2B61Xbb8EIvB/PUTY/FUmkIlGEFGGc7VbpBRRlZDofZE9CaxSwFoOSLVnwSkr5LyrsbzSFbeNlSBHCV4KLYIMSTeq/vvqboeaBvWVJWc0d5yJFIHMqwQucaNSX91HmNi9BTQLsWhb4ZsKA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(376002)(39860400002)(366004)(86362001)(83380400001)(6486002)(54906003)(8936002)(76116006)(66946007)(2906002)(6506007)(5660300002)(4326008)(91956017)(64756008)(478600001)(186003)(66574015)(66446008)(2616005)(6512007)(110136005)(71200400001)(66476007)(53546011)(66556008)(36756003)(316002)(33656002)(8676002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cEpEV1VvR0U1NVJqTzVHTmhhSGRVVTlQUlUvZVB6cEt2MzVsUWxWYkEvM1BG?= =?utf-8?B?L1did0NjK1RVc05HK0VNR0JxV3NaNzdHZElTWGE0WG54U3N1Y3hUVHlSbUlU?= =?utf-8?B?YjN5Nmp3MUZnNDMxTkgxSktGNTdVME1KV0hqL1FRK1daR0p0MVV3QnRrN3lJ?= =?utf-8?B?Vm12V0dndjVqMXBWaS9VUThJUDQxbDZsUnlKM2xXL3JRUGhBUjc0eFk1TGpH?= =?utf-8?B?NFlRR1pUS1BDOVZKZmw0SUVpVkY2a1VEajZIQStIMmhrUHh6NmNIOEdoQWxa?= =?utf-8?B?R25tTTgrcGFKRm1RRXMzU0htdXJhM29TYjArek5XWStVYkd5SStSQkpES0o3?= =?utf-8?B?azZwK1BpZ2ZkckFRY2x6amZpamdsK0ZCdURabFJvWFA1ckN4cUtjUUpvanFk?= =?utf-8?B?amZKV2g1eVM5MFhTeFZJc3FBb3hlK29yeXdZL0hER1p5Sy96aUtSMWZQTDFL?= =?utf-8?B?T21oYW1NOGVBeVl4NlBIRUFMQ2tadVJKbTZaZkhxZjFuSWFvQzJ0WXdEYmE5?= =?utf-8?B?T3IydzU1cElNb2E3VVZTWUNIYnhQRGNXQldrWnFQOHJCREN1SzFvQmpxMG1H?= =?utf-8?B?RnZtczRrb0ZFSlI0d1RMYWt2VlJoRlM5SksvbkFBZWRZNEtLdzdwMkNjOFNi?= =?utf-8?B?Y3BCalBDQUxhUlRROGxlYXhhcW84bmUxdWhaRDFQQkhOYTBKR2hyeVRwQnUy?= =?utf-8?B?WFhyRzhIOUlhR2tKTm1yNmNMaFFjTk91UTVJNVlUYmxEMk5OVFhrVHVKazBD?= =?utf-8?B?MExjOGJOcU1JK0JVWnYwVDR2NGhBZ0M1SDFWOWJKT0J6Ukt4Y0FMdEFLbENh?= =?utf-8?B?WEZYTnltbDI3Rm1ITmV2eEIrT3Mxdm5lRHA5WGFNUzdnZjNDeEhoWmpnU01L?= =?utf-8?B?STdZWjZHVnBOei83QjFIUVZRTUxXWlRoUWNHbXdrTFpSWUZjQzRkZkRmZDZM?= =?utf-8?B?Q0toeFJ4TjU1L0o4bjYwQzZBTldRUXBtVzVyRStZSVVsTTltakZxZmtEQ0Yw?= =?utf-8?B?aGZ4SWlIQmE5cVlkWnV5TmdYbTlTWm9Dbkx4T25RN2dpMVlOYWpWclY1aEIw?= =?utf-8?B?cnl0Y3RScDJQNzZmcWJtYjZydnZkbmY4MVRJRTBFdnlhdGNVZTZVUnBESzFo?= =?utf-8?B?dFpqSDA5aTlEb2hWY1E4OUYxSmJoSFdpMU95bkNCZVZ3RENYd3FhMGtKVnVW?= =?utf-8?B?MkpaR3ZobHFUSlZwd29VNFd4a3hKUndkbXdVbFBqakRycFNXMFBuTGxBQ3NB?= =?utf-8?B?ZElGVGluaEFxUi9Vd1Q4N2wzU3lsY3Q1RVdZVFRET0tMREpkc0JEbnhhelhz?= =?utf-8?B?SXVmRXRQdEZrT2pIYXpNL3BQYkU3ZjMwbmdyWTNMUzM0azg5VTRPNm5kc2hW?= =?utf-8?B?Y0hsVFJ4NU9jbG5YUHNxNlBvZnVIa0IwbzJmek15NjBCSy95bzlhMTg3M3Fa?= =?utf-8?B?MzZiMG94Ti9YdSttc3hnWjQwSUpKZFN5eXBncGJZSFBXT21ISDVaU3R1SWcr?= =?utf-8?B?dXFEaVIyTUwzMy9nMmtsNGlJa3c3blVMME1la201bng2QzRlWGR0Yzk0Ukk2?= =?utf-8?B?ZWtmODYwWHNRdFN5UDI3Zm9CZzRZdXEwcnNoZmgvOWdwV1VwNTBhVU9ZaGlO?= =?utf-8?B?QXR2VVppcEdWUGVURXN0NlN1d2l5SjhreUV2UGhPR3FsbGQ2Tm5WTUR2cDIr?= =?utf-8?B?eGczanJJQkxNWExCeHlDSUREOGcyYjAwblAycmxKZHQzWHhrd3ZKQ0ZNQTdk?= =?utf-8?B?MjE1ejk2U3BQcE5rYTJDS2xsQ09FZVdsVml6bVB4ekNBeElCZE9wemVUd3NR?= =?utf-8?B?SFpTdmRKTmxuMkNzWHkxbkJwUk5rS21FVHVJSGV1OEFCZmtVNk1RWERmNm5B?= =?utf-8?Q?OE/psKmWUTVgc?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa13241a-666f-4231-4715-08d8d274b9f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2021 12:16:44.9921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xOiw2GTr2WFNFLnLkjNzth8+mmA5bKrSlzvFlsTwtZyJsX966uFVvc/+41JW4v4MmWyInIMQYvxrtnRULy7i9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4888 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [core] [Iot-directorate] Iotdir telechat review of draft-ietf-core-echo-request-tag-12 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, 16 Feb 2021 12:16:50 -0000 RWxpb3Q6IHRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcsIEkganVzdCByZXBlYXRlZCBpdCBpbiB0 aGUgJ25vIG9iamVjdGlvbicgSUVTRyBiYWxsb3QgZm9yIGFyY2hpdmluZyBwdXJwb3NlDQpDaHJp c3RpYW46IHRoYW5rIHlvdSBmb3IgeW91ciBxdWljayByZXBseSB0byBFbGlvdCdzIHJldmlldw0K DQotw6lyaWMNCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSW90LWRp cmVjdG9yYXRlIDxpb3QtZGlyZWN0b3JhdGUtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IEVsaW90IExlYXIgPGxlYXI9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBGcmlk YXksIDUgRmVicnVhcnkgMjAyMSBhdCAxOTo1Mw0KVG86ICJcIkNocmlzdGlhbiBNLiBBbXPDvHNz XCIiIDxjaHJpc3RpYW5AYW1zdWVzcy5jb20+DQpDYzogImlvdC1kaXJlY3RvcmF0ZUBpZXRmLm9y ZyIgPGlvdC1kaXJlY3RvcmF0ZUBpZXRmLm9yZz4sICJsYXN0LWNhbGxAaWV0Zi5vcmciIDxsYXN0 LWNhbGxAaWV0Zi5vcmc+LCAiY29yZUBpZXRmLm9yZyIgPGNvcmVAaWV0Zi5vcmc+LCAiZHJhZnQt aWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWcuYWxsQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1jb3Jl LWVjaG8tcmVxdWVzdC10YWcuYWxsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJb3QtZGlyZWN0 b3JhdGVdIElvdGRpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVx dWVzdC10YWctMTINCg0KICAgIENocmlzdGlhbiwNCg0KICAgIFRoYW5rcy4gIFRoaXMgYW5zd2Vy cyBteSBxdWVzdGlvbnMgd2VsbC4NCg0KICAgIFJlZ2FyZHMsDQoNCiAgICBFbGlvdA0KDQogICAg PiBPbiA1IEZlYiAyMDIxLCBhdCAxODo1MiwgQ2hyaXN0aWFuIE0uIEFtc8O8c3MgPGNocmlzdGlh bkBhbXN1ZXNzLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEhlbGxvIEVsaW90LA0KICAgID4g DQogICAgPiBPbiBGcmksIEZlYiAwNSwgMjAyMSBhdCAwOTowOTo0OUFNIC0wODAwLCBFbGlvdCBM ZWFyIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCiAgICA+PiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdo eSB0aGUgRWNobyBvcHRpb24gcmVxdWlyZXMgb3BhcXVlIGRhdGEsIGFuZCB3aHkgdGhpcw0KICAg ID4+IHNob3VsZCBub3QgYmUgc3RhbmRhcmRpemVkLCBhcyBpdCBzZWVtcyB0aGF0IHRoZSBiZWhh dmlvciB5b3UgYXJlIHNlZWtpbmcgaXMNCiAgICA+PiBzdGFuZGFyZGl6ZWQuICAgQXMgeW91IGdp dmUgdHdvIGV4YW1wbGUgbWV0aG9kcyBpbiB0aGUgZHJhZnQsIHdoeSBub3QgcmVzZXJ2ZSBhDQog ICAgPj4gZmV3IGV4dHJhIGJpdHMgdG8gc3BlY2lmeSB3aGljaCBtZXRob2QgaXMgaW4gdXNlPyAg VGhpcyB3b3VsZCBhbHNvIGFsbG93IHlvdSB0bw0KICAgID4+IGRyb3AgdGhlIG5lY2Vzc2FyeSBj YWxsYmFjayByb3V0aW5lcyBpbiBsaWJyYXJpZXMuDQogICAgPiANCiAgICA+IEkgZG9uJ3Qgc2Vl IHdoaWNoIGNhbGxiYWNrIHJvdXRpbmVzIHdvdWxkIGJlIGludm9sdmVkIGhlcmUuIEluIGN1cnJl bnQNCiAgICA+IGltcGxlbWVudGF0aW9ucywgdGhlIHZhbHVlIGlzIHBhc3NlZCBhcm91bmQgYXMg YW4gb3BhcXVlIGJ1ZmZlciB0byB0aGUNCiAgICA+IGNvbXBvbmVudCB0aGF0IGlzIHRha2luZyBy ZXNwb25zaWJpbGl0eSBvZiB0aGUgRWNobyBvcHRpb24uIElmIG11bHRpcGxlDQogICAgPiBjb21w b25lbnRzIGluc2lkZSB0aGUgc2VydmVyIHByb2R1Y2UgRWNobyB2YWx1ZXMgYW5kIG5lZWQgdG8g dGVsbCB0aGVtDQogICAgPiBhcGFydCwgdGhlIHNlcnZlciBpcyBvZiBjb3Vyc2UgZnJlZSB0byB1 c2UgdGhlIGZldyBiaXRzIGFzIGl0IG5lZWRzDQogICAgPiB0aGVtIChhIHBhdHRlcm4gdGhhdCdz IGFsc28gdXNlZCB3aXRoIHNpbWlsYXIgb3BhcXVlIHZhbHVlcyBsaWtlIHRoZQ0KICAgID4gdG9r ZW5zKS4gQnV0IG1heWJlIEkgZGlkIG5vdCBxdWl0ZSBnZXQgdGhlIHBvaW50IGFib3V0IHRoZSBj YWxsYmFja3MsDQogICAgPiBjb3VsZCB5b3UgZWxhYm9yYXRlPw0KICAgID4gDQogICAgPiBUaGUg YmVoYXZpb3Igd2UgYXJlIHNlZWtpbmcgYW5kIHN0YW5kYXJkaXppbmcgaXMgdGhlIGNsaWVudCdz OyBzZXJ2ZXJzDQogICAgPiBjYW4gdXNlIHRoZSBvcHRpb24gYXMgYSB0b29sIGZvciBhIHZhcmll dHkgb2YgYXBwbGljYXRpb25zICh0aG9zZSBpbg0KICAgID4gc2VjdGlvbiAyLjQgYW5kIG1vcmUp IHdoaWNoIGNhbiBhbGwgd29yayB1c2luZyB0aGUgc2FtZSBnZW5lcmljIGNsaWVudA0KICAgID4g YmVoYXZpb3IuDQogICAgPiANCiAgICA+IE5vbmUgb2YgdGhlIGVudmlzaW9uZWQgYXBwbGljYXRp b25zIGhhdmUgYW55IGRhdGEgaW4gdGhlcmUgdGhhdCdkIGJlDQogICAgPiByZWxldmFudCB0byB0 aGUgY2xpZW50LCBhbmQgd29yc2UsIGlmIHRoZSBjbGllbnQgd2VyZSB0byB1bmRlcnN0YW5kIGl0 LA0KICAgID4gaXQgY291bGQgdHJ5IHRvIGNvbnN0cnVjdCB2YWx1ZXMsIGFuZCBhbGwgb2YgYSBz dWRkZW4gdGhlIHNlY3VyaXR5DQogICAgPiBjb25zaWRlcmF0aW9ucyBmb3IgYXBwbGljYXRpb25z IG9mIHRoaXMsIGxpa2Ugc2VydmVyIHN0YXRlIHJlY292ZXJ5LA0KICAgID4gd291bGQgZ3JvdyAq d2F5KiBtb3JlIGNvbXBsZXg6IEZyb20gYSBzaW1wbGUgcnVsZSAoIk9ubHkgc2VuZCBhbiBFY2hv DQogICAgPiB2YWx1ZSBpZiB5b3UgZXZlciByZWNlaXZlZCBpdCBmcm9tIHRoYXQgcGVlciBiZWZv cmUiKSB0aGF0IHRoZSBzZXJ2ZXINCiAgICA+IGNhbiByZWx5IG9uIHRoZSBjbGllbnQgdG8gb2Jl eSwgaXQnZCBncm93IGludG8gcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8NCiAgICA+IHVuZGVyc3Rh bmQgd2hlbiBpdCBtYXkgb3IgbWF5IG5vdCB0YW1wZXIgd2l0aCB0aGUgdmFsdWUuDQogICAgPiAN CiAgICA+IElmIGEgcGFydGljdWxhciBhcHBsaWNhdGlvbiBuZWVkcyB0aGUgY2xpZW50IHRvIHVu ZGVyc3RhbmQgYSB2YWx1ZSBvZiBhbg0KICAgID4gRWNoby1saWtlIHZhbHVlLCBpdCBzaG91bGQg dGFrZSAidGhlIGZldyBiaXRzIiBvdXQgb2YgdGhlIG9wdGlvbiBudW1iZXIuDQogICAgPiAoRm9y IGV4YW1wbGUsIEknZCBiZSBoYXBweSB0byByZXZpZXcgYSBkcmFmdCBvbiBzZW5kaW5nIGEgcmVh bHRpbWUNCiAgICA+IHRpbWVzdGFtcCBpbiByZXF1ZXN0cyAtLSBidXQgdGhhdCB3b3VsZCBjb3Zl ciBxdWl0ZSBhIGRpZmZlcmVudCBzZXQgb2YNCiAgICA+IHVzZSBjYXNlcywgYW5kIG5lZWQgdmFz dGx5IGRpZmZlcmVudCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucykuDQogICAgPiANCiAgICA+IA0K ICAgID4+IFRoZSBsYXN0IHNlbnRlbmNlIGluIDIuMjogaXMgdGhpcyBtZWFudCB0byBiZSBsaW1p dGVkIHRvIE9TQ09SRSBvciBhbGwgdXNlcyBvZg0KICAgID4+IERUTFM/ICBJIGZvdW5kIHRoZSBp bm5lci9vdXRlciB0ZXh0IGNvbmZ1c2luZywgYW5kIHRoYXQgYSBkaWFncmFtIG1pZ2h0DQogICAg Pj4gYWN0dWFsbHkgaGVscC4NCiAgICA+IA0KICAgID4gVGhhdCBzZW50ZW5jZSBpcyBtZXJlbHkg aWxsdXN0cmF0aW5nIHRoZSBjb3JuZXIgY2FzZSBleGNlcHRpb24sIEknbQ0KICAgID4gY29uZmlk ZW50IHdlIGNhbiBlbmhhbmNlIHJlYWRhYmlsaXR5IGhlcmUgYSBiaXQgYnkgbm90IHJlZmVycmlu ZyB0bw0KICAgID4gRFRMUy4gKEl0IGlzIGdlbmVyYWwgdG8gRFRMUyBpbiB0aGF0IGluIERUTFMg YWxsIHByb3hpZXMgYWx3YXlzIHNlZSB0aGUNCiAgICA+IENvQVAgb3B0aW9uczsgaXQgc2F5cyBz b21ldGhpbmcgYWJvdXQgT1NDT1JFIGlzIHRoYXQgKERUTFMgb3Igbm90KSwNCiAgICA+IHByb3hp ZXMgc2VlIHRoZSBvdXRlciBvcHRpb25zIG9ubHkpLg0KICAgID4gDQogICAgPiBPbiB0aGUgZ2Vu ZXJhbCBpbm5lci9vdXRlciBkaWFncmFtIC4uLiBobSwgd2UgY291bGQgYWRkIHNvbWV0aGluZw0K ICAgID4gZm9yIHN1cmUsIGJ1dCBJJ2QgYmUgd29ycmllZCB0aGF0IGl0J2QgZGlzdHJhY3QgYnkg cHV0dGluZyBmb2N1cyBvbiBhDQogICAgPiB0b3BpYyB0aGF0IHJlYWxseSBiZWxvbmdzIHRvIE9T Q09SRS4gSSdsbCBsZWF2ZSBhbiBpc3N1ZSBvcGVuIGluIHRoZQ0KICAgID4gYXV0aG9ycycgdHJh Y2tlciB0byByZXZpc2l0IHRoaXMgd2hlbiBtb3JlIHJldmlld3MgaGF2ZSBjb21lIGluLg0KICAg ID4gDQogICAgPiBUaGFuayB5b3UgZm9yIHlvdXIgaW5wdXQNCiAgICA+IENocmlzdGlhbg0KICAg ID4gDQogICAgPiAtLQ0KICAgID4gVG8gdXNlIHJhdyBwb3dlciBpcyB0byBtYWtlIHlvdXJzZWxm IGluZmluaXRlbHkgdnVsbmVyYWJsZSB0byBncmVhdGVyIHBvd2Vycy4NCiAgICA+IC0tIEJlbmUg R2Vzc2VyaXQgYXhpb20NCg0KDQo= From nobody Tue Feb 16 04:40:54 2021 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 91A8E3A0B20; Tue, 16 Feb 2021 04:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 f8j-E13OuY95; Tue, 16 Feb 2021 04:40:46 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25B63A0B1D; Tue, 16 Feb 2021 04:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7488; q=dns/txt; s=iport; t=1613479246; x=1614688846; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=0RNnd9JV8ok9MbVbVaoGIXgI01VmzLk0ihktzbdgP9w=; b=jrdsrLUurSz6VUl9StTu39UMpPNfIzpqlTpdH3U6W2Jn55HKBhEv0LTb bU2BEepAQUf028Ck/whAYitna+J76SPm73/ziPU8bnNpScRP/7jCKoN9s FRptl2zRfoxI50uekMCXytY18qqnEdEAFvYQWwtX4owCsREXXA5IwaOYb 0=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.81,183,1610409600"; d="asc'?scan'208,217";a="31057661" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Feb 2021 12:40:44 +0000 Received: from ams3-vpn-dhcp722.cisco.com (ams3-vpn-dhcp722.cisco.com [10.61.66.210]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 11GCehwB001126 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Feb 2021 12:40:43 GMT From: Eliot Lear Message-Id: <2CAA815D-7E90-4AAC-809C-C7208E6B41CA@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D1E09ACF-763C-404A-A1BB-F82E837B9BDF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 16 Feb 2021 13:40:41 +0100 In-Reply-To: <161347761786.11909.15773072075789476433@ietfa.amsl.com> Cc: The IESG , draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca To: Eric Vyncke References: <161347761786.11909.15773072075789476433@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.66.210, ams3-vpn-dhcp722.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-echo-request-tag-12=3A_=28with_COMMENT=29?= 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, 16 Feb 2021 12:40:49 -0000 --Apple-Mail=_D1E09ACF-763C-404A-A1BB-F82E837B9BDF Content-Type: multipart/alternative; boundary="Apple-Mail=_E5D4E649-4AA9-4F70-B1B6-EE7D45D0E831" --Apple-Mail=_E5D4E649-4AA9-4F70-B1B6-EE7D45D0E831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, I=E2=80=99m not sure if it was lost, but the authors did address the = questions I raised to my satisfaction. Thanks to all. Eliot > On 16 Feb 2021, at 13:13, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-core-echo-request-tag-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for the work put into this document. >=20 > Please find below some non-blocking COMMENT points (but replies would = be > appreciated). >=20 > Eliot Lear (in copy) has also reviewed the document as IoT directorate = reviewer > at: > = https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-12-iotd= ir-telechat-lear-2021-02-05/ > So, please address/reply to his comment. >=20 > I hope that this helps to improve the document, >=20 > Regards, >=20 > -=C3=A9ric >=20 > =3D=3D COMMENTS =3D=3D >=20 > -- Section 2.2 -- > "The Echo option value is a challenge from the server to the = client..." Just > wondering whether "echo" is the right choice for the option as it is = too close > to ICMP_ECHO_REQUEST, why not "challenge" ? >=20 > I would have expected some statements related to non-idempotent = requests > (generic statement) and then specific examples such as actuators. >=20 > -- Section 2.2.1 -- > Are the authors confident enough to state a minimum length of 1 octet = ? If the > intent of the document is to prevent replay attack, then I wonder = whether one > octet is enough... Unsure whether Section 5 (security considerations) = addresses > this issue correctly. >=20 >=20 >=20 --Apple-Mail=_E5D4E649-4AA9-4F70-B1B6-EE7D45D0E831 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

I=E2=80=99m = not sure if it was lost, but the authors did address the questions I raised to my = satisfaction.

Thanks to all.

Eliot

On 16 Feb 2021, at 13:13, =C3=89r= ic Vyncke via Datatracker <noreply@ietf.org> wrote:

=C3=89= ric Vyncke has entered the following ballot position for
draft-ietf-core-echo-request-tag-12: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-t= ag/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thank you for the work put into = this document.

Please find below some = non-blocking COMMENT points (but replies would be
appreciated).

Eliot Lear (in = copy) has also reviewed the document as IoT directorate reviewer
at:
https://datatracker.ietf.org/doc/review-ietf-core-echo-request-= tag-12-iotdir-telechat-lear-2021-02-05/
So, please = address/reply to his comment.

I hope that = this helps to improve the document,

Regards,

-=C3=A9ric

=3D=3D COMMENTS =3D=3D

-- Section 2.2 --
"The Echo option value is a = challenge from the server to the client..." Just
wondering = whether "echo" is the right choice for the option as it is too close
to ICMP_ECHO_REQUEST, why not "challenge" ?

I would have expected some statements related to = non-idempotent requests
(generic statement) and then = specific examples such as actuators.

-- = Section 2.2.1 --
Are the authors confident enough to state = a minimum length of 1 octet ? If the
intent of the = document is to prevent replay attack, then I wonder whether one
octet is enough... Unsure whether Section 5 (security = considerations) addresses
this issue correctly.




= --Apple-Mail=_E5D4E649-4AA9-4F70-B1B6-EE7D45D0E831-- --Apple-Mail=_D1E09ACF-763C-404A-A1BB-F82E837B9BDF 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmArvUkACgkQh7ZrRtnS ejPcSgf8DlnfxJ27Zm+33RzuwrY3B8f6R9NedI2CnvcQQMvDZ/ENham2dm8DU29v n/Mo4pFwU/ubFqt9XPTEswtbSNMcSmRaJuo3nOzicwfRpJfyuZucgmlg5Qdis/ZW L0Hg2uqGLkWRRnXAxTLqw/hTtwvChuMD3mELTjF/gP4IXvJsxbPTJCzfUn4oGTfv m7X6zkrAUpQSYs/ldf42u4xsJnQ//rZakIOneG8CgS+h+akYsmBqfkdv5cFHLEJy S6iw2yuSEu8Ud7/9Jw3lMgCgHm5FCcte9slLxPTYfG4sWmBMzHvN2n4rk9Azf96B CdepCefgG7r6nXRbV5p6dD2B+eF2zw== =hIad -----END PGP SIGNATURE----- --Apple-Mail=_D1E09ACF-763C-404A-A1BB-F82E837B9BDF-- From nobody Tue Feb 16 12:23:12 2021 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 B5C243A1073 for ; Tue, 16 Feb 2021 12:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 u9Bk3A3Dc0AF for ; Tue, 16 Feb 2021 12:23:08 -0800 (PST) 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 7DEF03A1079 for ; Tue, 16 Feb 2021 12:23:07 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id CD89C40887; Tue, 16 Feb 2021 21:23:05 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id CCD00FD; Tue, 16 Feb 2021 21:23:04 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 808FB44; Tue, 16 Feb 2021 21:23:04 +0100 (CET) Received: (nullmailer pid 603940 invoked by uid 1000); Tue, 16 Feb 2021 20:23:04 -0000 Date: Tue, 16 Feb 2021 21:23:04 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: "core@ietf.org WG (core@ietf.org)" Message-ID: References: <8F2BA41A-011C-4C3F-88BE-D7C3E05C9465@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jmt24qtcy6kwZEEY" Content-Disposition: inline In-Reply-To: <8F2BA41A-011C-4C3F-88BE-D7C3E05C9465@tzi.org> Archived-At: Subject: Re: [core] Endpoint type (et) vs. resource type (rt) 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, 16 Feb 2021 20:23:11 -0000 --Jmt24qtcy6kwZEEY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 10, 2021 at 02:42:37PM +0100, Carsten Bormann wrote: > https://w3c.github.io/wot-discovery/#introduction-core-rd > =E2=80=A6 uses the endpoint type as if it were a replacement for RFC 6990= rt (resource type). >=20 > Is this replacement where we want to steer people to? No -- but it's not so much the et/rt that bugs me, but rather that they intend to do endpoint lookups rather than resource lookups. Opened ; maybe the reactions also give a clue on why that turn was taken. thx c --=20 Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Terry Pratchett (attributed) --Jmt24qtcy6kwZEEY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsKaUACgkQOY0REtOk veHc0xAAi4xTQnhTHPZaeHiwq0TRkd4dnU9novDtAw/WecXFGQzrFS44I8qyQ3a7 aT8lqGO45Pjp3WSrNBRz5hUIsl31WYTs/j9V35dRT8J5mryAAZS6T9jSEHYGwmsg 8MT4KTSmN1ZlKDayNf6IR0b28MsA4fdvsvTmud0QpUwgbG35Vd5KNdV+fb+Tqc97 sRgvG0w4fezzAhsmjwLYNbO+EZ8FyWkMVL8DQDi2YMEDH3FWwP6UkbsXtQINYIqi cAM37gU/fbMKqFofx0HXF0TtEee3DJ9ycGtqWK6e0nVv+0ZIfMLf+Q4KkkWUfMgB vSBDcQA9sN02fmg7GJqPGIc+dtsrqQbMsUNWliFjzAmhgAr/dtDNOUwCHxPqbjns djtlXy5CNtnws6zdyp9CiQlaMXVhlzhpZg8r5V1VuWUlKeqDW/ENE4ghIbGaT1PU 71WtPySO0WoFMm3n0cW+HRdVp26BYs9mJsxxnQIdZ++1nce2xecWUNAvckORCMAQ 3Ue+rPIDfO0Kt1uMO4YHsaEIvfrCnkWudfTnV9tXTVMkKp0d024zeQWwNPG6P6yL tTzSqX+UdfQ2Lo1/B6VPmXJhfz9oTx44N0TiirttjTTsF0NJRcECss95WF8/C/Em fgyntCONFK6fyzmmEv+QbvKTKPsg/65Hp78kq4qStDKo0KJ+vy4= =7CTU -----END PGP SIGNATURE----- --Jmt24qtcy6kwZEEY-- From nobody Tue Feb 16 12:29:59 2021 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 963733A10BF for ; Tue, 16 Feb 2021 12:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldfNmYGrr0uR for ; Tue, 16 Feb 2021 12:29:53 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922073A10A3 for ; Tue, 16 Feb 2021 12:29:53 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7ADC440887 for ; Tue, 16 Feb 2021 21:29:51 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B7192FD for ; Tue, 16 Feb 2021 21:29:50 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6142E44 for ; Tue, 16 Feb 2021 21:29:50 +0100 (CET) Received: (nullmailer pid 604186 invoked by uid 1000); Tue, 16 Feb 2021 20:29:50 -0000 Date: Tue, 16 Feb 2021 21:29:50 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4twL7e+S2Jb6ZaMS" Content-Disposition: inline Archived-At: Subject: [core] Responses to NON with 4.02 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, 16 Feb 2021 20:29:58 -0000 --4twL7e+S2Jb6ZaMS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, reviewing new-block told me something new about RFC7252, that is that a response to a NON request containing an unknown critical option MUST be either RST or complete silence (whereas in the CON case, 4.02 is the logical response). Why is that? A NON 4.02 response would be just the same size, give better information, and (to me, most importantly) would not require the additional case distinction between "it's a 4.02 because some option value doesn't make sense" and "it's a 4.02 because I don't know the particular option" at a very different place than were the options are understood. (Or worse yet: A NON may arrive at a proxy that forwards it over TCP or as a CON, and by the time the proxy gets the 4.02, it doesn't know either). And will anything go Really Bad if I ignore that MUST? (I currently do -- up to now for ignorance, going forward because my libraries all work under the fiction that the library is an intermediary, and thus may do all things an intermediary may do). BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --4twL7e+S2Jb6ZaMS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsKz0ACgkQOY0REtOk veHvuw//XtMvCC0FTXn+wIfYFb/lqJ/y8VA6bQRbc+owyMvDx+vYfiN1n1forp1d IT6+h/njI0RvNO5pyGGgBKmvnvTWSa31pqjAoQwdteOsjrH9Sb9zFy5R30ULG6dJ viHdIF+ytRArirr1MB9CMV9cAWUQY4so6ahf06/B5sAfYV9v6xPd1+7YVIcUSVJJ mpnw8sv8opX8MwQXYZ2YrEw6RNpyn+1tdK4R5yrjduMlp+84gJTuYjVD0duclfi+ +jAllcpaRnLddmLQr+gGhkmAByjohQLa/g67DjrLyIhX13OWZ2z7veQHelfXF5og UJcEwq89tVNQrcHPlDAQAiwNrt7aM6400kO1SF2Wuoh6ApbP2DEDHPzDOWIbgmQW 7mWbAtpR6I0XvyWwBSS76RcfVKFWLyrb/BebiR/uPHJQHpEm3agMaPW3uBxtTwS6 IjIvaznsOno/gkDNY0MrmjCS/aGFomygEbcnNAduLr0VGhJQv9cxdPdMlZ1c8FDs KywU1Dei0s8A80l/ML3DcH5ZC39//u2kTXTBkKxX9aa5tB+jXDfqCxJUO9Qj62aq ouyQpRmBQzZKCg3ZNMsVFgHCVFE+6lVbzgOYapHEXVJdiE6MKsVTPFlAjzVkJPoU 9dGeE2ll4rgmATXo0keQfd+44U29EEDT86Lk6+JZ+HwGvFbPPs4= =50k6 -----END PGP SIGNATURE----- --4twL7e+S2Jb6ZaMS-- From nobody Tue Feb 16 15:49:02 2021 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 2414B3A12F0; Tue, 16 Feb 2021 15:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSQAYUerv_Ng; Tue, 16 Feb 2021 15:48:58 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5243A12E9; Tue, 16 Feb 2021 15:48:55 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9AEB540887; Wed, 17 Feb 2021 00:48:53 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6472FFD; Wed, 17 Feb 2021 00:48:52 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2FD9D44; Wed, 17 Feb 2021 00:48:52 +0100 (CET) Received: (nullmailer pid 612178 invoked by uid 1000); Tue, 16 Feb 2021 23:48:51 -0000 Date: Wed, 17 Feb 2021 00:48:51 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: supjps-ietf@jpshallow.com, mohamed.boucadair@orange.com Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gBSk+H9RigFJnM2C" Content-Disposition: inline In-Reply-To: <32574_1612339432_601A58E8_32574_29_1_787AE7BB302AE849A7480A190F8B9330315C6345@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 16 Feb 2021 23:49:01 -0000 --gBSk+H9RigFJnM2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, where not explicitly responded to, the updates address my points, thank you for updating the document. > > * The Q-Block options do not support stateless operation / random > > access. >=20 > [Jon] Actually Q-Block2 does now support this following the redefinition = of > the M bit usage in a previous iteration (with M=3D0 you can ask for any > individual block). Random access can also be in the Block1 phase; a standalone `PUT /resource Block1:5/0/6` can be used independenlty of other operations to overwrite a particular part of a resource. > [Jon] For stateless, Request-Tag is included so this should be fine. > https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#sectio= n-4 By stateless, I was referring to the server not keeping state per body. That is the opposite of using a Request-Tag. > > * Proxying of Q-Block is limited to caching full representations. > >=20 > > (The latter might be mitigated by additional text around caching, but > > I doubt it's worth the effort given it's not part of the use case). > > [Jon] I am not entirely convinced that Block1/2 have got the caching by > block properly sorted out - e.g. what happens when different clients make > requests with different SZX and Block2 is part of the cache key. The > limiting to caching full representations is there so that a new can of wo= rms > is not opened up. The Block options are not part of the cache key -- they are not-safe-to-forward and thus come with rules as to the cache behavior, rather than havign a cache-key property. The behavior is sorted out: If an earlier client requested, say, block2:0//6 (first 1KiB), then while that is fresh, it may be used to serve any request for smaller chunks (say, block2:1//5 for bytes 512-1024). The same is true in the other direction: A proxy may use its cached 3x256 bytes (even exceeding the Max-Age), ask the server for the 4th 256 byte block (which by its ETag confirms the others are still good), and then serve them combined as a 1KiB response. Thus, I think these two points (Incomplete support for random access, and block-by-block proxying) still stand to be added to the considerations. To give you background on why I'm so picky about this list: People *will* still get the initial impression that this is the later-and-greater version, and for the outlined purposes it is, but if we don't set the expectations right here, there will be disappointment. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --gBSk+H9RigFJnM2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsWeAACgkQOY0REtOk veHSYBAAuK173YgteA42G9jYZ7Oa0MySwEli/ctRAhWOVAoQ+GVLeA18PS6SA53r od5OEwoZtmGa7+QgV3rUZgu9jAi3gLoWM8IwQ804bUfsPgK78qFuIdp+ebNQN3cY Cdh5sSnor1DcScFve42rJmtRxr4Ey3hOvU058BDINBiq9+hix0zki/jPDuCQo7Zm UNH8L6e84QCA1JtuzGV+MbBkaR+wBtavTda+2c2Yy66lcZdtC2+emwtx/8L0/bzg coCzkr8pKTfmXFfVO2PA8vfg7CzdIh8AVDyQ7sKijCLihmm7WK3hNDVW2gXn8hQC bVwaEKNfPPqMHPdR/3FdyaSjhmR6W88ttwbPobvVTQD6oG0mhZYcm6MvrZ/m4lfZ aZBn+KEbxtM01ZkNx67lltjHf4D4QNIpbeS1U/nalaGJuzLdRI8X95OKiVmP2cwT 1LJajvj9S9IrW682dsIEbXaB9U4Sl/Bp26JhIu8vLq7zdghlFQFbIll0PG0aueN3 gxFSdEqtL3qf7v5ruNCvMObhVz7y7kG1i/QDa0gXxAuTq3LiTIduxVfe21Sq6Q7i OoasTEkJiLB8Q+hTHjR6qyaDJfvEYBmypAdc0uzhZOKzhkFfrA0Us8embGhEWEeK OOPCBHADcGbp5ZyseDy6Mznn+mNlebvgiohAO3XDUHWX+EdiAfA= =IAL3 -----END PGP SIGNATURE----- --gBSk+H9RigFJnM2C-- From nobody Tue Feb 16 15:53:48 2021 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 D206D3A12FA; Tue, 16 Feb 2021 15:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVH1Dz7sHn2n; Tue, 16 Feb 2021 15:53:44 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EDF3A12F4; Tue, 16 Feb 2021 15:53:43 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0CCC740887; Wed, 17 Feb 2021 00:53:41 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1AACAFD; Wed, 17 Feb 2021 00:53:40 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D720944; Wed, 17 Feb 2021 00:53:39 +0100 (CET) Received: (nullmailer pid 612561 invoked by uid 1000); Tue, 16 Feb 2021 23:53:39 -0000 Date: Wed, 17 Feb 2021 00:53:39 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: mohamed.boucadair@orange.com Cc: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HoBOzF5stQ3CqCEx" Content-Disposition: inline In-Reply-To: <23740_1612339780_601A5A44_23740_98_8_787AE7BB302AE849A7480A190F8B9330315C6374@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) 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, 16 Feb 2021 23:53:47 -0000 --HoBOzF5stQ3CqCEx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, On Wed, Feb 03, 2021 at 08:09:40AM +0000, mohamed.boucadair@orange.com wrot= e: > As a follow-up on this issue, we finally went with an approach that > does not require No-Response. We do have the following to avoid extra > delays, e.g.,=20 The need to indicate when a client wants confirmation has been avoided by having timeouts on both sides, and relying more on MAX_PAYLOADS being aligned. For my taste, that makes unnecessary sacrifices in robustness over the simple two-byte NoResponse:0 that'd go with every MAX_PAYLOADS'th Q-Block2 from the client (and would completey avoid the risk of stalling in a lossless situation). (For the other direction, corective heuristics can easily be applied). But given they are explicitly configured in the DOTS case where Q-Block is used, so -- well. Food for a block-bis (or generalized additions that allow block to be used that way). That aside, in the interest of readers who try to understand the ecosystem and the trade-offs involved, I think that at least a reference to it in a statement like "was not chosen because of X" would be helpful. The "Note that similar performance benefits" section would lend itself to that. Text suggestion: [messages are provided in Appendix A.] Similarly, The No-Response option can be applied to Block1 requests, but offers no corresponding facility for Block2 responses. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --HoBOzF5stQ3CqCEx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsWwMACgkQOY0REtOk veE0+g//evS9LOaNlDgc8UJnmAr6U7EFVScfJVd2qZIb2eMaxD0JDDVgYy4pjnoI ekMIvCN65ZNC97y7eTNRH4G9nPrJSJdOBaIB0yLJn7BW4mrgqCWersJ+V0dninR0 PDZGcDGvpOoNvPUWmO2nDTLnS6s2VGTO3PZlxdYgNvk8PVsgOx6nCr5zP0YXIg4a GDSjVhssbBAoMgqDw7E0aok8nntDESjufdA8DTulVXanYI9v48CSvIUcfBiuNdBt hgZ92drQhdpyTQcZt9S4ygapVDpTCEwv6UsxoxdPbZOrwl2OkGjlk6fNdeeNv22X ztgXQ9IkPhf3UOb1st2Jt9dljebGlN36jX/L4zVcItHoQnzi9tRl/XXJTQMgumth hdnp2kOsJUICB6RT3P/6DQGWEEbsRFrKwQwPDFwWuSpCyqBQC5pHkjm+ysKtTKZy BfqdfEyMEGhPL9AQHCYy9snJ+ZXG/f5qP8B7wD3RKB5sHPb82v5h7lqQHn9+rkG9 6V1PE0N0FFqNBLNYP+99RZ/NB7rYb7NHAFINqr4FXOXj6wBIzZyczzMCZE3/WpR6 PDNgjTvDhsw9lQ4iM0ZAXSuq7S/ABHNZ2FWT9gZJK92+cE95y1prL1dADkAb4hW+ kJc7Q3DMGhbwIxExax+rvqNGS/1T8IncgoU4GEK9ul5Bs/h7EnM= =7oZB -----END PGP SIGNATURE----- --HoBOzF5stQ3CqCEx-- From nobody Tue Feb 16 16:26:10 2021 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 422CB3A1342; Tue, 16 Feb 2021 16:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd3X90a7i4cc; Tue, 16 Feb 2021 16:26:01 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE093A1365; Tue, 16 Feb 2021 16:25:59 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4C0B640887; Wed, 17 Feb 2021 01:25:57 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 38E07FD; Wed, 17 Feb 2021 01:25:56 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BFF6E44; Wed, 17 Feb 2021 01:25:55 +0100 (CET) Received: (nullmailer pid 613591 invoked by uid 1000); Wed, 17 Feb 2021 00:25:55 -0000 Date: Wed, 17 Feb 2021 01:25:55 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: supjps-ietf@jpshallow.com, Michael Richardson Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I678fPgJbZy4TJia" Content-Disposition: inline In-Reply-To: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 17 Feb 2021 00:26:04 -0000 --I678fPgJbZy4TJia Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, and hello Michael (grep for MCR, first point could use your response), thanks for your responses and updates; on these concrete points, the only that remain are: > > * "If there is insufficient space to create a response PDU": I don't > > understand what that means. (Where are request options reflected > > back?). >=20 > [Jon] This was triggered by a question by Michael Richardson " So, given a > Christmas-Tree-Packet (largest packet, every possible option space used, > every extension turned on...) how much data can I get back? :-)" and not > fully thought through. > It could happen though with Location-Path, Location-Query, Q-Block2, ETag, > Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in response= to > a POST. > OLD > If there is insufficient space to create a response PDU with a block > size of 16 bytes (SZX =3D 0) to reflect back all the request options as > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size2 Option. > NEW > If there is insufficient space to create a response PDU with a block > size of 16 bytes (SZX =3D 0) to send back all the response options as > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size1 Option. I think that is a corner case that deserves an error in *every* CoAP based protocol and is not specific to it; MCR do you think that this comment needs to be resolved in this way? > > * "For NON transmissions": This seems to imply that the full exchange of > > a body is either NON or CON; I don't see where that'd come from. I'd > > have expected to read something like "Each individual request can be > > NON or CON independent of the others. In particular, it can be > > convenient to send the ultimate payload...". >=20 > [Jon]The DOTS environment will only be using NON. To make Congestion > Control simple, > the expectation is that all transmissions are NON or (not recommended) are > all CON. The draft now generally records this expectation. Then why spend time talking about CON in the first place, and risk that things go awry in a case that's neither tested nor really specified for? It may be worth considering (ie. working group discussion; next interim maybe?) to just state that this works with NON only. I do see potential for the use of CON and NON mixed (in particular, the "but it doesn't have a dual version for server pushes" you dread of No-Response problem might go away), but if it's not explored to fruition in the problem set out for this document, confirmable messages may be better ruled out at all rather than getting second-class treatment. > > Caching: > >=20 > > * "are not part of the cache key": How about "are removed as part of the > > block assembly and thus do not reach the cache"? >=20 > [Jon] OK. > OLD > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are not part of the cache key. > NEW > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are removed as part of the > block assembly and thus do not reach the cache. It may help to make the same statement about Request-Tag; then, there is no more (IMO questionable) SHOULD about "a new Request-Tag [being] generated", and the "Ideally" sentence can be dropped too. > > Generally, the all-NON and all-CON examples don't look to me like > > what I'd be doing with this spec; the mixed "a CON every > > MAX_PAYLOADS" appears much more realistic. >=20 > [Jon] It is unsafe to use CON in the (potentially lossy) DOTS environment > (up to 93 secs timeout per payload with the defaults). Hence why we are > separating out the NON / CON usage. See above: then maybe don't do it at all. (Also, in the "not related to previous points" follow-up mail to come, there are some CON related questions that might be moot then). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --I678fPgJbZy4TJia Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsYpAACgkQOY0REtOk veGfvhAAjpKcfSj6kmq0sXGHgAdgdGa70doOTsEb+TXYe1cIR27rTQqY6klXlra4 L73PLM5lLAADLhYRjz847tH8YkdjYJx166KK7USjAwPlpdSjaS3Th4LrpZQZ6iP4 TvRq5n4rmvYwaW1a6h4dsMH1b8/eMs41VbpDO7o4LTZZMxZNdsfZ1tKkKioqm8QJ ktIqjjl4h2+Qvz+OzSXOli3ROs9wdZtWEO/qYAmWJXubd8hvBmu7l1jvaoxHowqD +D6La/k7z2iLUq4+rg9FxrLqQ+gvIcQ/r/i+y88u79Y7bcw4K5AvH/msOyts8Wor 4q4eEudafOwGH+xj84orFBXrJsOwsS/JmCXeepbrwjfT00E02fJJheyknXNXsXM1 SbpUFm5MjKF+ML/IV6EBPj4hVLYRx8n5osfjVd65SoX6CCyMeisnRQ52e7SqJTuO Zc8CaMW5uF+wq9pdWmJ4l02B40cSBwq3GUmWoN4IQeeDafXenH7GjP2Pw6Nh998j i6JH8cZlib93+jrtkvXV3hmjelFPoenMVyQ+TimJoyOSJxiZhoIg+OwiQkx1BKGi XoCfXbsV0ekXQEr1dbfCgUs5QRhabrbhLWUau2GNgSV6v7ejgfzx/l9ujW65vyZf ymPvb7MDA/l9ZVjmBL21mjfM0xjQ+Haon6DfuLJkFvPMw6wTQWY= =Pc+U -----END PGP SIGNATURE----- --I678fPgJbZy4TJia-- From nobody Tue Feb 16 16:26:26 2021 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 9234C3A1388; Tue, 16 Feb 2021 16:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E94TTHjxuUYc; Tue, 16 Feb 2021 16:26:18 -0800 (PST) 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 EDB663A13A7; Tue, 16 Feb 2021 16:26:15 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1CF0340887; Wed, 17 Feb 2021 01:26:14 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D2DDAFD; Wed, 17 Feb 2021 01:26:12 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9BAD644; Wed, 17 Feb 2021 01:26:12 +0100 (CET) Received: (nullmailer pid 613621 invoked by uid 1000); Wed, 17 Feb 2021 00:26:12 -0000 Date: Wed, 17 Feb 2021 01:26:12 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org, draft-ietf-core-new-block@ietf.org Message-ID: References: <161106954627.30354.11510619547642306741@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T9YApoBcqYkLdOQh" Content-Disposition: inline In-Reply-To: <161106954627.30354.11510619547642306741@ietfa.amsl.com> Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-06.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, 17 Feb 2021 00:26:25 -0000 --T9YApoBcqYkLdOQh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello new-block authors, here a few notes that I didn't see fitting any of the previous threads (or so I hope): * "can fall back to using Block1 and Block2 Options, respectively": Even though the rest says (as agreed on) that it's both-or-none, the "respectively" seems to imply otherwise -- maybe just drop the word. * CSM option: "There is little, if any, benefit of using these options with [reliable transports]" ... and reliable transports are the only thing CSMs are defined for. So why define a CSM if it's not expected to be useful? * Ad Class E/U: It may be worth stating that it *is* allowed to mix Block and Q-Block when one is inner and the other is outer -- for the simple reason that there'd be no way to enforce anything else, for proxies along the path can perform outer-blockwise transfers in ignorance of the content. (Then, at a receiver, an outer Block option could arrive, and when that's done, it should still process the inner Q-Block without erring just because the two worlds met). * 3.3 Use of the QB1 option: The rules for the final message are different between 2.04 Changed ("token SHOULD be from the last received payload") and 2.05 Content (~"MUST be the one in the final block"). Any reason for that? The former sounds more sensible. (I originally favored the latter, but then when a 4.08 comes back on the last-block request, the same token would need to be used for the final successful response too, and that'd be awkward -- and I'd prefer to avoid it if we can pick the one rule set ("SHOULD from the last received") that allows having only one response per token unless there are actually multiple blocks transported on it). * 3.5 Block + Observation: Has this been implemented and tested? The combination of Block1(!)+Block2+Observer is already tricky with regular blocks, and made harder by the semi-noresponse blocks here. Unless you have a use case for it, I'd ask to see this implmeneted before it is published, or else to leave this as "interactions are up to further specification" (with a corresponding note in the ups-and-downs list) in the interest of getting this on speedily (given this document's purpose is to get the DOTS use case running). * The 2.31 Continue rules: Why not send it with CON? A 2.31 Continue is just as compact as an ACK, and can convey to the client that all packages up to that point have been received, so it doesn't need to retransmit the earlier ones even though the corresponding ACK may have gotten lost. * The new QB2 M-bit rules depend on MAX_PAYLOADS to be agreed. But that agreement is SHOULD only, and even that's already stretching what I'd expect of a configurable CoAP parameter. It's also rather complicated. How is this better than a simple "M=3D1 means this block plus as many as you can comfortably send, where M=3D0 is for this one only"? * "is meant to prevent amplification attacks": Could you elaborate? A client permitted the use of QB2 has already some leverag on the server to start attacks, and would in any case (overlaps or not) only be permitted MAX_PAYLOADS on a single request by the server, no matter how it requests more than that. * "then the body response SHOULD be restarted with a different ETag Option value": That behavior sounds like a recipe for endless running requests when CON is involed (which, granted, are under flow control, but still don't do anything useful). Given there is also a recommendation to keep the being-transmitted version alive, why not just stop the transmission? Or send just one final block of the new value -- and then it's up to the client to decide whether that's a representation it already knows (and just got a freshness statement for) or needs to get it as a whole again? * 3.6 Size1/2: These options MUST be used per 3rd paragraph, so the "If" in the 4th is odd. * (General wording: It's "A comprise X and Y" or "A is comprised of X and Y"; https://en.wiktionary.org/wiki/comprise#Usage_notes "in the passive voice") * 4 the new 4.08 format: Since this is a CBOR sequence, the implementation note on telling the array length in advance does not apply. As for the CDDL, I don't know whether the array format is OK to use for the sequence, or whether the CBOR=20 * 5. Use of Tokens: The MUST on the unique tokens misrepresents echo-request-tag. There are rules there about when a token can or can not be reused, and they depend on factors immaterial to the present specification. In particular, when used with CoAP-over-TLS or with OSCORE, using non-unique tokens is quite alright. I recmomend not making a normative statement where none is required; eg. "Each new request generally uses a new Token (and sometimes must, see Section 4 of ERT). Additional responses to a request all use the token of the request they respond to". * "Implementation Note: To minimize": I'd prefer to go with "it is suggested" rather than "recommended", but as long as it's not in normative language, I don't care too much. * "Servers continue to treat": While not factually incorrect considering the above recommendation, the reference to the 32 bits in the paragraph about the server is confusing. Last prenthized expression could read "(i.e., is sent on the token of the request that caused its retransmission)". * (I skipped through the congestion contol section for the time being; it's probably best read by someone with some experience in congestion control which I lack). * "When the next client completes building the body, any existing partial body transmission to the CoAP server is terminated": Just a note, you're already using Request-Tag, so you could leave it up to the proxy to try to run them simultaneously (it obviously can, as it already got to the point of having both request bodies loaded in full). The server can then still cancel one or postpone the other. * Figure 6: The first line says "for RT=3D11", that's probably a remnant from when the Request-Tag was copied into the payload. (Same for later '[for RT=3D...]' items Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --T9YApoBcqYkLdOQh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsYqQACgkQOY0REtOk veEDFxAAvf/LfdUL6E6lY7cq08uvCycKcrdYvaj/C+uOfpL5Mprn5AqIJ4Y/LBS5 dyw6lMPrFAICaBm1fL52UBZMWNKG5+/l4c3UZvxGbWkaHvVY/EQAgRrFaBEg8IRH sLWRXDRM6+EWrk/3RAU9QhXSfu7MuUyZTSEE1lOJs9kCurdB4z3wqwu9mg5A2PP9 hgnjOiyHibc/6JRFLpokaNWKwKH6KUGd3tDJCVMRVoYV7mftbbSUH509JBCZgt0p 8HvGPtG5yWTo/bLT5b9w/VQ19C4bEsN2i0OIpXFAkZ/b59nHLr0HhUBKX0yh37wh 7kDATdj3CV6KVXKB6QG5zbBz91zNsl/sPb+ODuPLewS6CYywXxDR/CtWaGf7jlwW EuYL5UrNMJIxo4oDPWe3KXVx0oikyngUmusvKe3vS5/Apk8bn+0kfDXlvrp044kZ UsiBhyFYhfuQtBqZqku8qE+a8f3aUx0+n9QuOdZ1bJPfESoLjQILxjp2ZX5sIXzp H23wQ61UOfxnusZ0wNibsl0YpWwyvsM2QdqR+FjA9BUtm/8MdhwtbDBxDvg2LAnR XmAXmP3MctimxYMMk8PdDDxMgn/5ztAUZPzZIfiQ6XE8W0VcO9pqKSNpNBzzep3G CBmCK6LXZsSrHwDVAQV7NwJvh8CaN1S0mA9Dyj6wjizdNUgUB9I= =pvzE -----END PGP SIGNATURE----- --T9YApoBcqYkLdOQh-- From nobody Wed Feb 17 00:21:22 2021 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 867C43A17E8 for ; Wed, 17 Feb 2021 00:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6BD__ufEoh9 for ; Wed, 17 Feb 2021 00:21:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 AD36F3A17E4 for ; Wed, 17 Feb 2021 00:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613550073; bh=SRRiaQYv0Jo4IXUB9wG2eMMbvibtPikhGr4Ny1ZnowA=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=ZY4G6bVBta7DzXNtlZok9sUEQIKr8dcU9OzzR+CBUux6VqWpUtYymkXSnFPiZcvxf 6iCh+jJOON0N2C7aSgQmXv2zKYc5h422ejZzG/0JO3W9henUd+UDeHXEwv6puXIpzF qXRly+UuiRm1PGGnu79b6ysDyTQIno/O/7CwVQPw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.100] ([94.216.249.255]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MEFvj-1l2hh612wP-00AIro; Wed, 17 Feb 2021 09:21:13 +0100 To: =?UTF-8?Q?Christian_Ams=c3=bcss?= References: Cc: Core WG mailing list From: Achim Kraus Message-ID: <97bbdcaa-a413-22b8-b06e-49d6ed97b235@gmx.net> Date: Wed, 17 Feb 2021 09:21:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:qgSAdYZsbdr37MngavzqollVk0MIzbjN0YyISB3QedIT/byaf2P DPHtadCZ5pWcpQFUQY2MbmgqG0wV7SxcUju0m8Uv/wUEBOW/50N7dqRaDdmrISDLMu5QI0Q N9leB0DW+wrzBCvpxCyulJ3kw/sYIJaXnkBHkr45p/pCC579WSR3aYRua1X0CNgEJcesM9Y Dx5TSgUiVXSIOTN5xz2vA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Qnyz6DoAh3M=:1BdjgKdmzW3czrXEkVUnu0 NY96G38RsNqFZrbjp/CqW+cgVuaMRIq5BAU9pCM/hp/fOqS3MXiDGHnDLSsXwt5dwn6g5W7Y/ s39s5H4CNz1cyiSyXv3DWi+IFmeKdaHYSRAb2v4/oGqs1V44zhizpufWGvjE/HjMwpRyH4fyp 1+3jqvaIfUqIPNIHOtsAth0nX0AI5uTQNoDnZ71ImYfMbQXSwbdeGXHz8NAsjespNIyGkxJS9 3p+/tZVKbfH7CKh5Pojr5MtgrbLiiCTH5e/9U0CBDdO2PsEauM7ERpkks/ZYH7U/ZN+/srtna QFyhVtjg7PJf88rLnlzW5Is31XKhypTaJvAum5pMHbGLrhX3U9b8AcuZneWlj6/noZJSrEbU7 6Nkim6FMI5I+6/YrljHvkCz8EXIDVDDSyDXb9PJ5DRqfPj+mM5DPDXj690UZSBIKH2EW8CRkM LSY7yiXHWTjKlOMYAZ3O9nfsIqspe2NHicjGC4V2p+fVvBVJPdEC7fwswLOB+SR0QfC6bDW5w o6AmFI6V5ejF1FDIBCJOwucJbNuawNzq5vKzPfZ/8XZJw4t55XivM5XWQ3VK6E/Pc90qidied 127sMVAIbw4vd6e1EvnTo7stXHIc2Vi9eky1IULg7CxVSSKZeTTnoRIwvYBYmkQ+ijX6AdwMa vxcq/AGobK7Y08GS9O45NnvQk16i3o8jFkmSBbbVusNgn5QiyQTLBmqL+RAvlWCY3c+WzvrkD WWxWyRlQObJpe4YtUNokEunlDO6bMU/y0ZZ2Cn43ntBrEmBWz1vpflUKglUZRkiQTERkNsnFb If+4spbBlnLiSUvBrBtneFRBt4nU68LM0mRN1JgoQgZcfS4V/kGVQmmX+MuOdJEshzyAZWgfZ oO07ocKFTcpfPr/oNa0Q== Archived-At: Subject: Re: [core] Responses to NON with 4.02 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, 17 Feb 2021 08:21:20 -0000 Hello Christian, I think, this discussion from April 2020 is at least related to your question. https://mailarchive.ietf.org/arch/msg/core/wd4LleVnnvt2WOXj28ouNZcCTXU/ best regards Achim Kraus Am 16.02.21 um 21:29 schrieb Christian Ams=FCss: > Hi, > > reviewing new-block told me something new about RFC7252, that is that a > response to a NON request containing an unknown critical option MUST be > either RST or complete silence (whereas in the CON case, 4.02 is the > logical response). > > Why is that? A NON 4.02 response would be just the same size, give > better information, and (to me, most importantly) would not require the > additional case distinction between "it's a 4.02 because some option > value doesn't make sense" and "it's a 4.02 because I don't know the > particular option" at a very different place than were the options are > understood. > > (Or worse yet: A NON may arrive at a proxy that forwards it over TCP or > as a CON, and by the time the proxy gets the 4.02, it doesn't know > either). > > And will anything go Really Bad if I ignore that MUST? (I currently do > -- up to now for ignorance, going forward because my libraries all work > under the fiction that the library is an intermediary, and thus may do > all things an intermediary may do). > > BR > c > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Feb 17 00:27:37 2021 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 9A9083A17F4 for ; Wed, 17 Feb 2021 00:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9do8R67Qzpkn for ; Wed, 17 Feb 2021 00:27:33 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD533A1831 for ; Wed, 17 Feb 2021 00:27:31 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6817040887; Wed, 17 Feb 2021 09:27:29 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C84C9FD; Wed, 17 Feb 2021 09:27:28 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8AE6D190; Wed, 17 Feb 2021 09:27:28 +0100 (CET) Received: (nullmailer pid 633433 invoked by uid 1000); Wed, 17 Feb 2021 08:27:28 -0000 Date: Wed, 17 Feb 2021 09:27:28 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Achim Kraus Cc: Core WG mailing list Message-ID: References: <97bbdcaa-a413-22b8-b06e-49d6ed97b235@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qzt13ntyw7gApnTF" Content-Disposition: inline In-Reply-To: <97bbdcaa-a413-22b8-b06e-49d6ed97b235@gmx.net> Archived-At: Subject: Re: [core] Responses to NON with 4.02 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, 17 Feb 2021 08:27:37 -0000 --qzt13ntyw7gApnTF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Achim, > https://mailarchive.ietf.org/arch/msg/core/wd4LleVnnvt2WOXj28ouNZcCTXU/ thanks, that's indeed essentially the same question, I just failed to find it. I concur with Klaus that it's weird and belongs to the request/response layer. Just to ensure I didn't miss anything too relevant in my (so far, to be continued) "I just pretent to be a proxy" excuse, what were the complaints you got about the behavior about? For whatever gets upset by your original implementation would probably also get upset by the presence of proxies. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --qzt13ntyw7gApnTF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAs020ACgkQOY0REtOk veFHXxAAzAQvm+eRVrKkHszCuySzHld8s7+0vbkir15LPW3ThDksQLLe0rNYVqFN 5mHeXBthpLaRihMjz7cMeFY+EDm81Zhdw8ftLcTIxeXYsfiGrrNyId2+wU8guP2F o4f5yIojrrpKqcMF1TBuzkxtRDXNQLxKKFGBTxUbPtOdGXXIK/v8paWAaLbBFAu8 ve3yxeeIdzdgb0sEvs1H3AtALKLOtL8I9Z42NYnwdaAE3sYtkCon+swKzel9IuzF 04p39CvYwTr7ZyJV5fd4DN4MPOsr7blTcpoi5aNQOsM57E7D342jtTnJegnP1ZAx UpHwSkgqIK/siRS3H3/SLyWelycCBaQo00aNsOP/YWO8iivfMHIVm+pOw3lOgFF3 xTRr8IL9O2EpHW6Y67iL9OLZuIn+nIMQDyutYkZGT+dxSKVBS2a/O5GHXwriljXE dlYmaQp062dTlJbNpetwHwSWdmdpJHC8mFiLWxHn4BZ0H2VM/VE3gYIkZ5HcDfRl itwfIF+zSsya0MKNOqOQ3anugAVcs8Bk1uJMFw/FIkl18AR3pO8fabuRMTnRls+p 7IX9roYH13ob0tovp0UeygqdzEmt7DOrSOgWmznKecBONjPcx3sw+G44Y1Scm4eL 0fvF1SvnHKuCZt5GhJZ6hrtaPHsExWQ0tvX69RuhRfnE6+rMe9g= =1/dS -----END PGP SIGNATURE----- --qzt13ntyw7gApnTF-- From nobody Wed Feb 17 00:42:48 2021 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 8E5E83A1812 for ; Wed, 17 Feb 2021 00:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wy0FYnYW7KL for ; Wed, 17 Feb 2021 00:42:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 AABC43A1810 for ; Wed, 17 Feb 2021 00:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613551360; bh=FOLMQUwL1vjvGE+iXYGmIuxRj2aWiudb00cB6n/NlAo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=QafsSk2d8N4353QyTkxbYf/K2/aRzfqx5XSWL7M72EsmYtUzlqIbPaQjABImYRmrp 5qy0VdGdWhY7WLpVETQ1MyVJ6wbk0OtrtFi91ObMkSDIoQyI5F+Xcku/SdKwgDqDUD ZFSrvKMpvKAFfTDf7ZfPB8J3Q65BS2W31wZUm/FA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.100] ([94.216.249.255]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MXp9i-1lM9HQ30dY-00Y8lE; Wed, 17 Feb 2021 09:42:40 +0100 To: =?UTF-8?Q?Christian_Ams=c3=bcss?= Cc: Core WG mailing list References: <97bbdcaa-a413-22b8-b06e-49d6ed97b235@gmx.net> From: Achim Kraus Message-ID: <856f5a32-2ebd-76e4-c5bc-9f7754a3cc9e@gmx.net> Date: Wed, 17 Feb 2021 09:42:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:8Wgdke4ZqIG3DMK8N/I+8SUYAcvuR5Vf5XZ5zhII5iwXdnKd7u2 Xf0dyAjGK6eWqWVPZFQrEplpixxkADjH2YCx2pe21bjBeLOYkLqGlfX8V2zWTgYK4AW1D5Q gviLYI+y4lbg3agfqqmrr1WCJR9Dxbv6VIPBV0f7z3pkeFhtBhE5Vcc3rFCZsLkguDyvJxs t+3Verg9490Up6kQEhXEw== X-UI-Out-Filterresults: notjunk:1;V03:K0:sE8yF3kB7dI=:6MPobSwUKo3nnIISOhXJHM u61l/6i/Mn6IUAElS+gGi5hWYu6miJ4+IhR3gnp6etgOdhMbXofZqbVDGRv/iQJ21g34WexwK VT8H60IFgAcM9Eoqfx4HUGrIHQ9vwS2W6cU5OCnUzCnQE7lEwSAisQ6VA+n3H9wk2MCrU8AvV EExWzxkokvJrtT8Sz8L0ZTwPGz/2QAIMRso17ucid/DWB5QflVJ55Tj8zClGqdmIR8wycfe9o IDuNnT3PbZ0OGqeX+dmthEtDdkzZGhW444KBQeqWFD7XU5uDMT+htuKuvxlCDUMeXUKbpEc5V xw+aEzLwE4Tdr39mHl/k7AjYY2bEqEEq+FUWieRR3cy7N5AbgWQStmiK1lNIhATA3ZZxCG1Mn DZGTdEd7ubKEGx9UPDrSz9CkRBrjefgSFQTjGUgtf9IAhv2mgd7pg7L7+5KiJU1F3/DYmhGrR UvJzf0syK3EVg7UBbVyfbDUInj4XW7btgO/z1CDVlp+KYjsfuEE5v0Ig7IvM3rMahZtxU+XPn cOPWSEWMypSe60iWBy6/XnJkLLVyunyN+y/+7Y+Y3DhpxBsoP7qvHKJ2sIALMN4L9bHnggTwr XxdyYD0EpdSFE8eN61On+9oEJwip6bH1a9PfJRk5V0UqkIsZAJ4TY6716soDlvJ0V87kzKNe2 Hg3gHin1Y+41QvuZVN87S80RfLjDwXMdY7ouy7EWg2mDmTb42L7PCuZcQ+7IcJ6dgjPHJaE/M wsOV7NBXNG7uMbk3zUNPXnlrhSIkvYurxlMqPetibcbh7vNLv3JVxuXqGxxbhzbLFlSzvK1z6 RV8wNKohZ/rcea6u7dZ7rXxloD8i8ahW0oqGv7vH6C7cQDC6DXdeOzR+V8dVBMIt8UAEHfKDx RtSFZ5Qd32ZtjU0gM9wQ== Archived-At: Subject: Re: [core] Responses to NON with 4.02 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, 17 Feb 2021 08:42:47 -0000 Hi Christian, > what were the complaints you got about the behavior about? (Hope, I understand that ...) 3 years ago, a colleague was working on the the option validation and found, that this seems to be wired in the specification. Last year the Eclipse/Californium project got a similar request about that= , https://github.com/eclipse/californium/issues/1288 and so I decided to ask the list about the intention behind that. AFAIK, there is no real issue with that. Basically the main failure is sending the "bad option", not the way, the other peer responds. So the behavior seems to be more important for developing and debugging then for real production. And during developing it should be not too hard, to switch to CON to see, which error response your get back. best regards Achim Kraus Am 17.02.21 um 09:27 schrieb Christian Ams=FCss: > Hi Achim, > >> https://mailarchive.ietf.org/arch/msg/core/wd4LleVnnvt2WOXj28ouNZcCTXU/ > > thanks, that's indeed essentially the same question, I just failed to > find it. > > I concur with Klaus that it's weird and belongs to the request/response > layer. > > Just to ensure I didn't miss anything too relevant in my (so far, to be > continued) "I just pretent to be a proxy" excuse, what were the > complaints you got about the behavior about? For whatever gets upset by > your original implementation would probably also get upset by the > presence of proxies. > > BR > c > From nobody Wed Feb 17 00:55:31 2021 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 3F10D3A1830 for ; Wed, 17 Feb 2021 00:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 sODT14f3nrGm for ; Wed, 17 Feb 2021 00:55:27 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113233A182E for ; Wed, 17 Feb 2021 00:55:26 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B5BAE40887; Wed, 17 Feb 2021 09:55:24 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 550D3FD; Wed, 17 Feb 2021 09:55:23 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 154CB190; Wed, 17 Feb 2021 09:55:23 +0100 (CET) Received: (nullmailer pid 635385 invoked by uid 1000); Wed, 17 Feb 2021 08:55:22 -0000 Date: Wed, 17 Feb 2021 09:55:22 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Achim Kraus Cc: Core WG mailing list Message-ID: References: <97bbdcaa-a413-22b8-b06e-49d6ed97b235@gmx.net> <856f5a32-2ebd-76e4-c5bc-9f7754a3cc9e@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zz57kb3YKn5/Hr9j" Content-Disposition: inline In-Reply-To: <856f5a32-2ebd-76e4-c5bc-9f7754a3cc9e@gmx.net> Archived-At: Subject: Re: [core] Responses to NON with 4.02 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, 17 Feb 2021 08:55:29 -0000 --Zz57kb3YKn5/Hr9j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 17, 2021 at 09:42:39AM +0100, Achim Kraus wrote: > > what were the complaints you got about the behavior about? >=20 > (Hope, I understand that ...) Precisely as I meant it :-) > 3 years ago, a colleague was working on the the option validation and > found, that this seems to be wired in the specification. OK thanks, so both look more like "it confused people" than "it confused software", so no urgent action needed. IMO this is something to put in corrections and clarifications; issue now open at . Thank you Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --Zz57kb3YKn5/Hr9j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAs2fcACgkQOY0REtOk veHfeQ/8DNsysHrx0Qo4fQN4b4i6MPf6H5z/epj5tSDnzHhsspdJ9voj28aOqfzP pVibHU9bcJRWakKICiBUdyIzafdqi+5heNh1qX9SEY1mfdBuPV/RQnC1HT/6A8OR PSeOyUGbP5BNB/sGHuJYOz0MFlAX6rLDNSdV38pzg6RBGiJVQlHFLSEkfb23wfix lGGQk/oRtKv4cYen+k+Y5MvoD7vJnbKR3vS07LFTiACIOUcE6vJsgMXIsc3C+rHX ZsP+O51Fz2YNfIDAF8vO+9TUP+s2EccnLE2WNaBx1c+bM/hNQERj56vdHOMud2RX RbGZLQdiHBWeKJHjw2Ajn8uOfY5jk/AnK9fpL2ntIszEVSHL4D7Kr9PXJjUDSq39 P531+jx/ai12eF2SSrhwX2279Q1w8ZeSS7GK/BkWoC9TrqNS3fVqzKBgOk/e2fIw 4MSNiQTtvWtMh6xrQhtn3b3i8N/MLkC42h7fybJavbJEI9DPXLlJxjqFY8C4C3RP FPbtyAIgt8WRAk6NrMJo2ilq8Ey8n0UiA3/6lRlTpMv8jYXOZF1TJzRnNQ/TgozY e5rt0J1w9b+/mVZ1vpNRHo51GQJEYhj7EmtDt7ooMbsz5t4yEnKfRPd6uJbBIV1T e4gHpHn+Sk1mwCRh7Nd0XeoLn27pqEs4iRPLVbbINxQbYr5lLCw= =YOXf -----END PGP SIGNATURE----- --Zz57kb3YKn5/Hr9j-- From nobody Wed Feb 17 09:13:48 2021 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 18A9C3A1BA2 for ; Wed, 17 Feb 2021 09:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyIYPfUEYcLo for ; Wed, 17 Feb 2021 09:13:43 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60047.outbound.protection.outlook.com [40.107.6.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 70DE93A1B9F for ; Wed, 17 Feb 2021 09:13:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G9L2DpHIqmPy06SzoLlFsc4gFsevXRo8XmcGxxVHfQ661aoqsL3+YjMUnJN0OZck3lG7Samme9Wnf28lYpmp1pep2RUILS+Q+oxxdM+6y/F8lO7NhABQXplh6IXFlp3/SVWuWFD9au5ZCuQ6qbPRJjwBamK3rag10C9Mud0UGTHFCQNhjr66oNMkYurlcy3ZfNpGPRlswpzb81Bj5ykuqHnO1abxE0FOyXAGPJTaufOUM03+IpeakXDFix3NITGsBkqbnS0RxEx0+Nyo7OJYLtIJ+F/khQp1Ss7kwMGJUtRRyYSrU7VxFi3sN6yWlNthsUj59GlRb7j9lx3uW8FSqw== 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=yKMqMYwmz7hXAM/1Lpv9oV7yI8xg+bf55HLrw+75Cpw=; b=hh6pREOhXzbDZrQe9qi2TAS2CD0//6ayQkjSoYgDjllTYY6mznKpZRgWN7iBIVUPY4RL76Fqcln2YoXXwYzTdquQz2++lJnWHAhQ1jq99mS0SZMspUQFjXGWWrHAjVwVix4p/NfOxuG819xxBd0hywjazYS8B/OSxx1Cuf7Fkw/AXrZL+hKFdSwYWwArYR3wR15UAl6kr6yymHChley47U9+hRpqCYivgY//gP0b6tUcaUCvys8mlp5qoXKFn/tNkaxhJVwEXpWEg6R6N/OQEGOpnLfIUERNWthu0D2nKASVRSRRR4rNbvUoPbde4HiOuRcg1nCDdq3QYcKrN0Xdsg== 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=yKMqMYwmz7hXAM/1Lpv9oV7yI8xg+bf55HLrw+75Cpw=; b=OnTmwXjzoM7hHZnKOmklobm/pfoinYD9DMo5Uovnxrwo4y2RYdsf+q8pmcUWiRYOAQRENWbiciIozLyY+8H8TpBn/bca6Un5J4rmYFFAIJe+KoYL5fdxTzJoXJL4FWJWXrTjUUwL5h4iQCIRpa4KUkYl/mDWd40TMSbnHKplY0k= 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 DB9P189MB1578.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a6::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.28; Wed, 17 Feb 2021 17:13:40 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%7]) with mapi id 15.20.3846.043; Wed, 17 Feb 2021 17:13:40 +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: <384f4726-b707-9cda-6d64-82f5a32eb3c1@ri.se> Date: Wed, 17 Feb 2021 18:13:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TBHWi3EutU4nj9ic5TXYA0esCnvfPE9e5" X-Originating-IP: [84.17.36.151] X-ClientProxiedBy: HE1PR05CA0295.eurprd05.prod.outlook.com (2603:10a6:7:93::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.4] (84.17.36.151) by HE1PR05CA0295.eurprd05.prod.outlook.com (2603:10a6:7:93::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Wed, 17 Feb 2021 17:13:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7d3a2f13-535d-4694-6dba-08d8d3675ee6 X-MS-TrafficTypeDiagnostic: DB9P189MB1578: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uRXF9kDUYZ+8rCyaQ+Qopms3Nx+PpgrKQlVYK/Hh0Mju0zsXihCwOeC+haU7nMLmn83upsGwgWjBylmoGCT98wrW/+2ltpyXhRpl11A1vme/tMGYvU1tBtxISfSwo5vsz1LLbcvKvp0tidmqegw8DNJfjyN1/MI83r3wBk8SwidPZQfqZVvqVMM4lJ9xBtJDEFSlvJHfWo+7J2egnmHOWX2lBIGAQ7vhyZkuwu3knYpPBc8YSQU0veN2jGkBQD39w6Z0dmRSBhhSxelCS9/aqUQumupW/eF7PajmTeV+DyEOd5+/pvlwp4KTVnxHsrn7d6GwRrjH4u3rXP8PAenAtDeuAJCILfpS8dp73+E7hJxRg2bwTMA9nbCgLf+kBRYg/F9ZAkHjU0zaHrGBAS6XzB6GGgkYo/vZKlaJubj3eiocT5/pocXIdzdqDcm641U56zY5wHXjAHe4gQHOT+H3HG0NPx+whHTADyqUMZ7m7zqP6aiy4QxFVlzxF6LJKQRDtGenTp7J1BSENa1b3DW0NaVcS8EYyLGdn4K4U+H5apirpQKfrhVFRfW+H1W4zKTQ1UHXc1bV5qQzQYgq6LZHgSpEJpz+jjcFseGT9u9qCe0oop1wuiW76I0dF695js7yo2dpCqVAef4y/hWYjxodXTRmhuRK8Wf/1ThEmsePRNFb818qb6nmvAPdKN6CGlpV X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(346002)(376002)(366004)(136003)(8936002)(16576012)(6486002)(6916009)(86362001)(6666004)(66476007)(66556008)(36756003)(8676002)(5660300002)(52116002)(66946007)(26005)(21480400003)(956004)(16799955002)(16526019)(186003)(33964004)(44832011)(83380400001)(966005)(66574015)(316002)(235185007)(2906002)(31686004)(2616005)(478600001)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Y2NYT2NjYTI5ZUxDQUVvamgxdGRFb3hXS1M0NzR1R3VDSzREM2V0ck5PdE1H?= =?utf-8?B?dDVBYUdsWVNyUHFZdXo5bnE3NXZZb3FDSG9VRXczMmsxMCtRRGdwaTdjcWgr?= =?utf-8?B?OW5XVXZreEljRnd4ek5wUlFBNmRTS1FaeFdtcnlvOGR4UW5KeGpoK1RzbWNN?= =?utf-8?B?UkFrWVpIM1hNdkovUTJOc25LbGhKMnU4VzZZdi9KeUpzQ2F2L2loUjB5TU9y?= =?utf-8?B?UWNMYTJzNGI1SUQwZWJTZVdUeHZ5K1ZLNzFQTEpFc1o3OEtkcThyQ2V6SGNr?= =?utf-8?B?bG1Mc2JNM3lsZGEzeXptTUVPdnVHSVdneGtOL3pzWFFQSWxFVHFlaFRieSs2?= =?utf-8?B?dzF5bDJSb3dFaFl5Mmd6YlFSQ1pHYU15aUtOVjA3ZVdGVDVBY3hsdTA4cTlo?= =?utf-8?B?cHF4V1Z3K29iQWxSUTh3K3VnRk9Nd2lLNW1RRkFVQk8xOUVFWXdDK2NMRko0?= =?utf-8?B?WFFoL041elNtV3UrZzFtbVpHUm9abGovTVJnREY1SEIyRFM2M3ZVVnhrU1pQ?= =?utf-8?B?YlpUSjBXZzIxaTI1NjJvQW0yVkxMSWNqVlI3Y3pVMW9HSDZyNGtxbjhwcGtM?= =?utf-8?B?N2UvWEt1MlJ1UW5KU2lhV0pqYVAzdEN3ZzJzbjBzT0RxQStTVTFVVWl4a0Y2?= =?utf-8?B?QlBVNDluSDgzbzBzWVBkVXJaL2hYZ2dQK3JhMGpxbnRPL09vVGRhOXpVVG1k?= =?utf-8?B?LzRZU3JRbTl3cy9MaXl0UHpqSGR5WGZNcS9zRE9UcHdXYzFnOEVGN1czS3Va?= =?utf-8?B?ZXc3MFRicEFsK0FLelprZ2pjNDBWQlhOb2x6MmNMdklhVlFvK0FGVnk2Z0tz?= =?utf-8?B?VndBNmIwWmJkdkpEZzNCdVNYZXdxeDNpdVorbFVXOXNMTE1rKzE0emxrRGxw?= =?utf-8?B?dFFNUGtiZ2FCMmxiK3VVdWVSbnE3WGNOejZyZ0RlUVZocTVZWlhVc0dYc3F6?= =?utf-8?B?NU1PM25adktvUHhjL1dKY2Z0a2RGMG8rSi9ESnltQzllaU1FOWhXUXZRTzNY?= =?utf-8?B?OEF6blQ4QUQ5Y1YyU0xWdnowQzV2T0RUSEI5a3ZOajdHVGgzcU5YMm5ZWXNC?= =?utf-8?B?YkN1NXdWVFZpUzNTWGdlTDR3clhPRjl1YVVlQWJ2L2luNWlIcDhrODJvVjVm?= =?utf-8?B?c04rMXBqQitDajlldWE1OHJrekl2eUxnQmVsMFlXQlY4YmJ5Vm9WWDBkbldp?= =?utf-8?B?bWs4QnA5emN3NHd4R2M5UDdYVFI0bkJRYU1uUm4yWk8yU1ZHZmxoR1BiVG4y?= =?utf-8?B?Y2xDVGpSWXZ6c1psSU94WDBBM1BmM1N1Mnd1MnFNQkxTUmwybUIxYlFHT3Vh?= =?utf-8?B?RCtHdExySzhLTFp1eHNoZEtvcTNLMEpZUnZ4ejBpb1E1Ukh5ZS82N1paeDl2?= =?utf-8?B?Ny83cXpRTkFMVDJrRHRYVFlMUHgvZEI2UzY5bkhJVW54RFRxR0pyMVgwVENT?= =?utf-8?B?dlZreTlldVJUNkluVlcvU085R1lwbDlQbmxINk9iNW83bzdGTFEwZWNua2ZJ?= =?utf-8?B?QWhlRXNrR1FOcUxrRkNDRnczb1hnblI4azZVRTVLVDJ3RlJKVDVnOWtlZ2dG?= =?utf-8?B?b3l2OUxLYis2N2hGTmdYdlMvVUhqMzlpRHgxUWhGV1Q5cUk3eDNtQmVNQlZi?= =?utf-8?B?UnpPcXdRN3VyKytCcHMwcCtJblBjK1pLODJRQ2xKNW56eWF2aE1IWUhyL2h4?= =?utf-8?B?S2tGVDJQOVYzeTVBMk1uWElSTlVid0plODVmNTRLL2VraEdxVmdEOHJsc2tJ?= =?utf-8?Q?MAqgV0C7dlkAbyJ9zyD9/p1eABoKkYGw0kgz1/a?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 7d3a2f13-535d-4694-6dba-08d8d3675ee6 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2021 17:13:40.1949 (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: GDJ37oyKDztbqJPr7yq+3MOURWOeShj7ibDsuGZm2Dlel5rJxMfsdvQRf99iJGLu7TqIOmFXw7mSfT+KZU2/1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1578 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-02-18 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, 17 Feb 2021 17:13:47 -0000 --TBHWi3EutU4nj9ic5TXYA0esCnvfPE9e5 Content-Type: multipart/mixed; boundary="Fo6lQgPQ5t5NZRgIuvDf0BOqa8TEasuNR" --Fo6lQgPQ5t5NZRgIuvDf0BOqa8TEasuNR 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 15:00 UTC we'll have a virtual interim via Webex. The agenda is to discuss about limits of key usage for OSCORE, following up on what raised at IETF 109 [1][2]. Please, find below the information to join the meeting. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/109/materials/slides-109-core-sessb-= ietf-109-core-aead-limits-oscore-00 [2] https://mailarchive.ietf.org/arch/msg/core/bbzZCt6ZZn4ysR7yLujPNscBF3= g/ =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-03-core?bo= th Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dmb6a8494e161c079941cba71c5c26a21= 2 Meeting number: 178 721 6307 Password: constrained More ways to join Join by video system Dial 1787216307@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: 178 721 6307 --=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 --Fo6lQgPQ5t5NZRgIuvDf0BOqa8TEasuNR-- --TBHWi3EutU4nj9ic5TXYA0esCnvfPE9e5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAtTrsACgkQ7iZktA5Y 2kMjjggApcJ+qWfAL47YtJd/rb1nxV1HCjpxT42oeRApzWr1MgH9U8v/qtqRveQs vEeCLie7vnvd8iwdKIcOdW1drrl1/qFYQMLKv3j8YUeCFL8dlJExsRrDRL+TVk5T 6Kv85ZB82om6Rk3l5qjzI1O9JzawnPcmiyKf3ojAx/entNpGxxJYEcnVGf8+o1R3 uxaVp6D701wDIWHM3D65zmY5YU+06Bekm+OWFqtTzw5cIM721+qiRlCg2vDHNNDv Cqqjcp0o/e28JiuTpwz8GQpEw+Si63CBamY+oDQ2ooqbnIMNKxfYo+MMXfuh47dC j3AmmX+X08KA5zre6UNHulyqWkRotQ== =f6lX -----END PGP SIGNATURE----- --TBHWi3EutU4nj9ic5TXYA0esCnvfPE9e5-- From nobody Wed Feb 17 12:54:33 2021 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 855E63A1D0E; Wed, 17 Feb 2021 12:54:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <161359527152.11372.63177839446582675@ietfa.amsl.com> Date: Wed, 17 Feb 2021 12:54:31 -0800 Archived-At: Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) 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, 17 Feb 2021 20:54:32 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-core-echo-request-tag-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this mitigation for draft-mattsson-core-coap-actuators. ** Section 5. Per “As each pseudorandom number most only be used once …”, how will that be possible when echo values as small are 1-byte are possible? ** Section 5. However, this may not be an issue if the communication is integrity protected against third parties and the client is trusted not misusing this capability. -- Why is the use of integrity presented as only a possibility here? Didn’t Section 2.3 require it when assuring the freshness requirement – “When used to serve freshness requirements including client aliveness and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints ...” -- Would it be clearer here to say that this is mitigation against an on-path attacker, not against rogue/compromised clients? ** Appendix A helpfully tries to lay out recommendations. A few comments: -- all of the recommendations here have option values much larger than the permitted minimum of 1-byte. In addition to the recommendations, could the circumstances of the lower bound also be discussed -- it would be helpful to explicitly state which methods apply to the specific use cases (client aliveness, request freshness, state synchronization, network address reachability). For example, method 3 (persistent counter) notes that it can be used for state synchronization but not client aliveness From nobody Wed Feb 17 20:15:25 2021 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 ADF303A1F9D; Wed, 17 Feb 2021 20:15:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161362172020.28530.15247844895355003249@ietfa.amsl.com> Date: Wed, 17 Feb 2021 20:15:20 -0800 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) 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: Thu, 18 Feb 2021 04:15:21 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-echo-request-tag-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for working on this document; these mechanisms are important and will help fill some long-standing gaps in CoAP operation. That said, I do have some fairly substantive comments that might result in significant text changes. While I recognize that there is going to be a spectrum of requirements for determining freshness, I would have expected the far extreme of that spectrum to include a strongly time-limited single-use cryptographic nonce (akin to what the ACME protocol of RFC 8555 uses but with time limit), as well as discussion of some points on the spectrum and which ones might be more or less appropriate in various cases. I do see some discussion of different use cases, but not much about the tradeoffs along the spectrum, and no discussion at all about the strongest properties that it is possible to obtain with this mechanism. In several places we mention that the Echo option enables a server to "synchronize state", which to me is a confusing or misleading characterization -- as I understand it, both additional (application) protocol mechanism and constraints are required in order for state synchronization to occur. Specifically, the client has to be the authority for the state in question, and the application protocol needs to specifically indicate under what conditions and which state is to be synchronized. In essence, the Echo option provides a mechanism for ensuring request freshness, and that mechanism is leveraged by the application protocol to make a synchronzed transfer of state from client to server. But AFAICT it is not a generic state synchronization mechanism, the state to be synchronized is not conveyed in the option body, etc. My preference would be to take "synchronize state" out of the primary list of what is possible and mention it in a separate sentence as something that can be constructed using the functionality that the Echo option provides. There are a couple places where we recommend (implicitly or explicitly) a sequential counter in contexts that might otherwise use a randomized value. I think I mention them all in my section-by-section comments, but in general the sequential counter might be placing too strong a requirement on the value, and the considerations of draft-gont-numeric-ids-sec-considerations seem relevant. I think it would also be enlightening to have a comparison between the anti-replay/freshness properties provided by the optional DTLS replay protection mechanism and the Echo option. I know they have differences, but I think there is also some commonality, and giving readers guidance on whether one vs the other suffices or both are needed could be useful. Section 2.3 Upon receiving a 4.01 Unauthorized response with the Echo option, the client SHOULD resend the original request with the addition of an Echo option with the received Echo option value. [...] [just noting that IIUC the revised requirements on token generation made later in this document are needed in order for this "resend the original request" to be safe" ... I am not sure if it needs to be called out here specifically, though.] > The cache values MUST be different for all practical purposes. Since we're at least advocating using crypto to enforce this property, I think that "execpt with negligible probability" would be a more conventional expression than "for all practical purposes". I don't think the example of this in Figure 3 meets the requirements, though, since the echo option value is just a counter that is easily spoofable. [...] When used to demonstrate reachability at a claimed network address, the Echo option SHOULD contain the client's network address, but MAY be unprotected. What does "contain" mean, here? Plaintext? That seems potentially problematic; using it as an input to the MAC that is not transmitted (as I mention later) is more conventional, in my understanding. The CoAP client side of HTTP-to-CoAP proxies SHOULD respond to Echo challenges themselves if they know from the recent establishing of the connection that the HTTP request is fresh. Otherwise, they SHOULD respond with 503 Service Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive connection. If the HTTP request arrived in Early Data, the proxy SHOULD use a 425 Too Early response instead (see [RFC8470]). They MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. Where is the MUST-level requirement to actually ensure freshness (by whatever mechanism is available/appropriate)? Section 2.4 * The same Echo value may be used for multiple actuation requests to the same server, as long as the total round-trip time since the Echo option value was generated is below the freshness threshold. The "round-trip" in "total round-trip time" is a bit confusing to me, since what's being described doesn't really seem like a round-trip operation, rather a "get a thing, do some stuff, do some more stuff, keep sending the echo option, send a particular request to the server that we are talking about checking the freshness of", with the final request not very correlated to the issuance event. 2. A server may use the Echo option to synchronize properties (such as state or time) with a requesting client. A server MUST NOT synchronize a property with a client which is not the authority of the property being synchronized. E.g. if access to a server resource is dependent on time, then server MUST NOT synchronize time with a client requesting access unless it is time authority for the server. Also, disambiguating the final "it" seems like it would be worthwhile, just in case, since this is rather important to get right. * If a server reboots during operation it may need to synchronize state or time before continuing the interaction. For example, with OSCORE it is possible to reuse a partly persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option, see Section 7.5 of [RFC8613]. In light of my toplevel comment, I'd suggest rewording this to clarify that the protocol specified in RFC 8613 includes a mechanism for resynchronizing the partial IV state, that uses the Echo option in a specific controlled protocol interaction. (A similar consideration would apply to the group communication example, though it might be a little harder to write clearly.) 3. A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of [RFC7252] (where an attacker would put a victim's address in the source address of a CoAP request). The RECOMMENDED way to do this is to ask a client to Echo its request to verify its source address. [...] (editorial) this usage of "ask a client to Echo its request" seems rather divorced from the actual mechanicis of the Echo option...in the rest of the document (bar one other instance noted below) we restrain ourselves to saying that the Echo option is what is echoed, divorced from the containing request/response. This needs to be done only once per peer [...] How is the "peer" identified in this case? Is it tied to a single (security) association, or the identity (if any) associated with that security association, or IP address (and port?), or something else? How long can/should the reachability information be cached for? reachability as described in Section 2.3. The proxy MAY forward idempotent requests immediately to have a cached result available when the client's Echoed request arrives. (The "Echoed request" phrasing again.) Section 3.1 In order for a security protocol to support CoAP operations over unreliable transports, it must allow out-of-order delivery of messages using e.g. a sliding replay window such as described in Section 4.1.2.6 of DTLS ([RFC6347]). My understanding is that the requirement is only to allow out-of-order delivery of messages (not necessarily including replay detection), so the clause about the sliding window is not needed. here. Section 3.2 In essence, it is an implementation of the "proxy-safe elective option" used just to "vary the cache key" as suggested in [RFC7959] Section 2.4. The referenced section of RFC 7959 covers Block2 operation, but my understanding is that the Block1 operation (covered in Section 2.5 of that same document) would be a more applicable reference. Section 3.3 Also, a client that lost interest in an old operation but wants to start over can overwrite the server's old state with a new initial (num=0) Block1 request and the same Request-Tag under some circumstances. Likewise, that results in the new message not being part of the old operation. Where are those "some circumstances" enumerated? Section 3.5.1 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. (editorial?) when I read this I feel like it's missing a clause -- consider those messages for the purposes of what operation? * 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, [...] nit: confirmed as what? Delivered? Typically, in OSCORE, these confirmations can result either from nit: I suggest "When security services are provided by OSCORE, these confirmations typically result from" In DTLS, this can only be confirmed if the request message was not retransmitted, and was responded to. Similarly, this would be "When security services are provided by DTLS" -- DTLS does include a native retransmission layer, but only for DTLS handshake messages, so this phrasing is needlessly ambiguous as to whether it is the CoAP request that got retransmitted. Authors of other documents (e.g. applications of [RFC8613]) are invited to mandate this behavior for clients that execute block-wise interactions over secured transports. In this way, the server can rely on a conforming client to set the Request-Tag option when required, and thereby conclude on the integrity of the assembled body. Could you clarify which client behavior would be mandated? The overall "body integrity based on payload integrity" procedures, or the specific "typically, in OSCORE" behavior? Also (nit), the phrasing "conclude on the integrity of" seems unusual to me; I think the intent is more like "thereby have confidence in the integrity of". Section 3.5.2 For those cases, Request-Tag is the proxy-safe elective option suggested in [RFC7959] Section 2.4 last paragraph. (Per above, Section 2.5?) Section 3.6 The Request-Tag option is repeatable because this easily allows several cascaded stateless proxies to each put in an 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. Thanks for including this! However, it wasn't clear to me from reading https://tools.ietf.org/html/rfc7252#section-5.4.5 and this document whether the order of repeated Request-Tag options was significant. Some clarification might be helpful. Section 3.7 That approach would have been difficult to roll out reliably on DTLS where many implementations do not expose sequence numbers, and would still not prevent attacks like in [I-D.mattsson-core-coap-actuators] Section 2.5.2. (I agree that DTLS implementations largely don't expose sequence numbers and that is unlikely to change. But) I am not sure I fully understand the scenario referenced in draft-mattsson-core-coap-actuators §2.5.2. Perhaps it is not what was intended to be conveyed, but it seems like in a setup that is tracking both sequence and fragment numbers, it would be pretty easy to enforce that a fragment-0 block will only start a new request if the sequence number is larger than the sequence number of the current/previous blockwise request. IIUC that would reject the "withheld first block" as being too old. Section 3.8 and MUST NOT use the same ETag value for different representations of a resource. (side note) I was a little surprised that this was not already a requirement, but I couldn't find an equivalent statement in a quick review of RFC 7252. (It's definitely correct that this is required behavior to get the protection in question.) Section 4.1 In HTTPS, this type of binding is always assured by the ordered and reliable delivery as well as mandating that the server sends responses in the same order that the requests were received. [...] I believe this description applies to HTTP/1.1 over TLS, but not to HTTP/2 or HTTP/3 (both of which provide other mechanisms for reliably binding requests and responses in the form of stream IDs). Section 4.2 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. I note that sequential assignment often has some additional undesirable properties, as discussed in draft-gont-numeric-ids-sec-considerations. Would a different method (e.g., one listed in draft-irtf-pearg-numeric-ids-generation) provide the needed properties with fewer side effects? In particular, sequential increment is at odds with the "nontrivial, randomized token" recommended for clients not using TLS (that is intended to guard against spoofing of responses). ("use of a sequence number" and "a sequence number approach" also appear in §5.1, if this is changed.) Section 5 The freshness assertion of the Echo option comes from the client reproducing the same value of the Echo option in a request as in a previous response. [...] nit/editorial: I suggest s/as in/as it received in/ However, this may not be an issue if the communication is integrity protected against third parties and the client is trusted not misusing this capability. [...] nit: s/trusted not misusing/trusted to not misuse/ See ([RFC8613], Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. nit: redundant word in "solution approaches"? For the purpose of generating timestamps for Echo a server MAY set a timer at reboot and use the time since reboot, in a unit such that different requests arrive at different times. [...] Something about this sentence confuses me, possibly around "in a unit". Section 5.1 Tokens that cannot be reused need to be handled appropriately. This could be solved by increasing the Token as soon as the currently used Token cannot be reused, or by keeping a list of all blacklisted Tokens. editorial: perhaps "unsafe to reuse" is more clear than "blacklisted"? Section 6 This seems to be the first (and only) place where we use the term "preemptive Echo values"; it might be worth a bit more exposition that these are ones piggybacked on non-4.01 responses (assuming that's correct, of course). Section 8.1 I note that DTLS 1.3 is in IETF Last Call. I did not notice anything in this document that's specific to a DTLS version, which suggests that it woudl be safe to change the reference according to relative publication order of these documents. It would be good for the authors to confirm that at their leisure, so as to not be rushed into a decision if/when the RFC Editor asks during their processing. Section 8.2 I note that draft-mattsson-core-coap-actuators is referenced from several locations (for useful additional discussion, to be clear), but it is only an individual draft that expired almost two years ago. Is there any likelihood that it will ever progress to an RFC? One might argue that "SHOULD use a 425 Too Early response" is enough to promote RFC 8470 to being a normative reference (see https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/). Section A 2. Integrity Protected Timestamp. The Echo option value is an integrity protected timestamp. The timestamp can have different resolution and range. A 32-bit timestamp can e.g. give a resolution of 1 second with a range of 136 years. The (pseudo-)random secret key is generated by the server and not shared with any other party. The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit timestamp and a 64-bit MAC, the size of the Echo option value is 12 bytes and the Server state is small and constant. The security against an attacker guessing echo values is given by the MAC length. If the server loses time continuity, e.g. due to reboot, the old key MUST be deleted and replaced by a new random secret key. Note that the privacy considerations in Section 6 may apply to the timestamp. Therefore, it might be important to encrypt it. Depending on the choice of encryption algorithms, this may require a nonce to be included in the Echo option value. I note that a MAC construction allows additional information to be covered under the MAC that is not sent alongside it, e.g., identity information about the client to which the Echo option value is being associated. Are there common situations in which including such additional contextual information under the MAC would be valuable (to prevent an echo option value received on one connection from being usable on a different one)? 3. Persistent Counter. This is an event-based freshness method usable for state synchronization (for example after volatile state has been lost), and cannot be used for client aliveness. It requires that the client can be trusted to not spuriously produce Echo values. I have severe qualms about specifying a protocol mechcanism that relies on trusting a client to this extent. It seems to expose a lot of latent risk; even if we think there should be mechanisms in place to protect against that risk, they might fail, or the mechanism might get used outside its intended context, etc.; if there are other mechanisms available for similar cost that provide the needed properties it seems more robust to suggest their use in place of the persistent counter. From nobody Thu Feb 18 00:39:46 2021 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 14BF33A0DF7; Thu, 18 Feb 2021 00:39:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <161363758006.28269.10539291789085222217@ietfa.amsl.com> Date: Thu, 18 Feb 2021 00:39:40 -0800 Archived-At: Subject: [core] Murray Kucherawy's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) 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: Thu, 18 Feb 2021 08:39:40 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-echo-request-tag-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There are several SHOULDs (e.g., near the top of page 8, and again at the end of Section 2.3) that left me wondering why an implementer would do something other than what it says. Since SHOULD offers a choice, some advice would be helpful here. Otherwise, maybe those ought to be MUSTs. I suggest giving them all a once-over to see if any such advice would be helpful to include. From nobody Thu Feb 18 05:19:03 2021 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 DACD23A11F1 for ; Thu, 18 Feb 2021 05:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXT8mC0G-UB1 for ; Thu, 18 Feb 2021 05:18:52 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70FA3A11F0 for ; Thu, 18 Feb 2021 05:18:51 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCjCi-0005KQ-Tv; Thu, 18 Feb 2021 13:18:48 +0000 From: To: , Cc: , , References: <32574_1612339432_601A58E8_32574_29_1_787AE7BB302AE849A7480A190F8B9330315C6345@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 13:18:52 -0000 Message-ID: <004201d705f8$9a108080$ce318180$@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: AQF93Q3vI61hNRrbjU+ftA4PQN3RvasQHx+g Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 18 Feb 2021 13:18:58 -0000 Hi Christian, We have gone for adding in the following to the disadvantages list.=20 * The Q-Block Options do not support stateless operation/random access. * Proxying of Q-Block is limited to caching full representations. Regards Jon > -----Original Message----- > From: Christian M. Ams=FCss [mailto: christian@amsuess.com] > Sent: 16 February 2021 23:49 > To: jon@jpshallow.com; mohamed.boucadair@orange.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello, >=20 > where not explicitly responded to, the updates address my points, = thank you for > updating the document. >=20 > > > * The Q-Block options do not support stateless operation / = random > > > access. > > > > [Jon] Actually Q-Block2 does now support this following the > > redefinition of the M bit usage in a previous iteration (with M=3D0 = you > > can ask for any individual block). >=20 > Random access can also be in the Block1 phase; a standalone `PUT = /resource > Block1:5/0/6` can be used independenlty of other operations to = overwrite a > particular part of a resource. >=20 > > [Jon] For stateless, Request-Tag is included so this should be fine. > > = https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#sec > > tion-4 >=20 > By stateless, I was referring to the server not keeping state per = body. > That is the opposite of using a Request-Tag. >=20 > > > * Proxying of Q-Block is limited to caching full = representations. > > > > > > (The latter might be mitigated by additional text around = caching, but > > > I doubt it's worth the effort given it's not part of the use = case). > > > > [Jon] I am not entirely convinced that Block1/2 have got the caching > > by block properly sorted out - e.g. what happens when different > > clients make requests with different SZX and Block2 is part of the > > cache key. The limiting to caching full representations is there so > > that a new can of worms is not opened up. >=20 > The Block options are not part of the cache key -- they are not-safe-to-forward > and thus come with rules as to the cache behavior, rather than havign = a cache- > key property. >=20 > The behavior is sorted out: If an earlier client requested, say, > block2:0//6 (first 1KiB), then while that is fresh, it may be used to serve any > request for smaller chunks (say, block2:1//5 for bytes 512-1024). >=20 > The same is true in the other direction: A proxy may use its cached > 3x256 bytes (even exceeding the Max-Age), ask the server for the 4th = 256 byte > block (which by its ETag confirms the others are still good), and then serve them > combined as a 1KiB response. >=20 >=20 > Thus, I think these two points (Incomplete support for random access, = and block- > by-block proxying) still stand to be added to the considerations. >=20 > To give you background on why I'm so picky about this list: People > *will* still get the initial impression that this is the = later-and-greater version, and > for the outlined purposes it is, but if we don't set the expectations right here, > there will be disappointment. >=20 > BR > c >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 05:31:56 2021 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 0B91F3A1209; Thu, 18 Feb 2021 05:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34kEmk4IQOO0; Thu, 18 Feb 2021 05:31:47 -0800 (PST) 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 42D673A1200; Thu, 18 Feb 2021 05:31:44 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3016A40887; Thu, 18 Feb 2021 14:31:42 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 52C14FD; Thu, 18 Feb 2021 14:31:41 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C608B190; Thu, 18 Feb 2021 14:31:40 +0100 (CET) Received: (nullmailer pid 826586 invoked by uid 1000); Thu, 18 Feb 2021 13:31:40 -0000 Date: Thu, 18 Feb 2021 14:31:40 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: supjps-ietf@jpshallow.com Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jd9hOaZ5pb197ncl" Content-Disposition: inline In-Reply-To: <004601d705f8$acbec250$063c46f0$@jpshallow.com> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 18 Feb 2021 13:31:50 -0000 --Jd9hOaZ5pb197ncl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Picking a quick one because I don't know when I'll get to the rest: > > * 4 the new 4.08 format: Since this is a CBOR sequence, the > > implementation note on telling the array length in advance does not > > apply. As for the CDDL, I don't know whether the array format is OK to > > use for the sequence, or whether the CBOR >=20 > [Jon] Not sure what you are trying to ask here. I know we removed the > Request-Tag from the CDDL which may have changed things. If the array were sent in CBOR, indeed the sequence 1, 10, 20 would look like this (courtesy of cbor.me): 83 # array(3) <--- here is where you need to know the length in advance 01 # unsigned(1) 0A # unsigned(10) 14 # unsigned(20) But as the content format is a cbor-sequence one, what you actually send is this: 01 # unsigned(1) 0A # unsigned(10) 14 # unsigned(20) (No array header, just a sequence of self-delimited items). So now the implementer's worst worry is that if they start writing an item in the last byte and the item needs a u16 they gotta roll back, but that is simple. Picking the array length in advance would be hard (and the implementation note's suggestion of not exceeding 23 items would apply), but by using a CBOR sequence you're already free of that. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Jd9hOaZ5pb197ncl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAubDQACgkQOY0REtOk veFbbA/7BPh7S3PNlQ/WckFLVe0zY3/W5v8360+3mDw7jDRi7sIgMf3GMnbimR1+ VMtCCcUvA+Vt/SHANhVHVtV+919P5yvOWK3VCnmE8pcfA7Wloa9V6tV+BA/tCiEc Gsj9szQruXRnrCLI6q0wXbZhhPqSGAyQsuB0qNPBA+jgT3vmjPV2nvttEjf/2TRk Ml8VrRVIyO0wuIzgmJ3dRyQELeQRa5BTNShfom5TIxKWrb8UZ47sarkOIauRJqVO 77p7Wg6WMVMTp6NH1fL1/k2qj3GgLeoaGfUQa7MKeda8hMycWKsuVLitbGinBHo0 ebAbmgKcyyF2GVywJ7v1LMYn7g/sFctzA++2Su7LwMkPgPzsRGYtcMWcTG/ojlxN rf28Tr3yYKpRT3R9yF4xDmAvE1Zo2BGnZVWOa+AuwdKFyXzRGzPPBmT7C2e1GMrt XCs6jGkCl4PwY2eTMpHK31YEG12IZkcGC9av9vQ+2NRtyKDHImJJV/13t1x+zBtE 1uvepZ1s7KBXq80eqWRtDMJnCqZQ0UWm35/q0qVTiDFeZkc+fcEuV2PNw85esz9Q cS+yWxRsFcwYYMnm6DrGeHis/CrOmWoprHNCpL22EHUkuKX8CBKd2NfrsWnTU1N0 9sSkjtoBMmgN51OgnO7X7a/V3VsUamfMW3L45p2GLRPRgejnEVU= =uxQb -----END PGP SIGNATURE----- --Jd9hOaZ5pb197ncl-- From nobody Thu Feb 18 06:29:35 2021 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 32EE13A12C9 for ; Thu, 18 Feb 2021 06:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktKZ_MytpJ77 for ; Thu, 18 Feb 2021 06:29:26 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B393A129F for ; Thu, 18 Feb 2021 06:29:23 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCjDE-0005Ko-8f; Thu, 18 Feb 2021 13:19:20 +0000 From: To: , "'Michael Richardson'" Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 13:19:23 -0000 Message-ID: <004601d705f8$acbec250$063c46f0$@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: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8qO6PjMA= Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 18 Feb 2021 14:29:34 -0000 Hi Christian, Thanks for taking the time to review this. See inline [Jon] Changes can be seen at https://tinyurl.com/new-block-latest=20 Regards Jon > -----Original Message----- > From: Christian Ams=FCss [mailto: christian@amsuess.com] > Sent: 17 February 2021 00:26 > To: core@ietf.org; draft-ietf-core-new-block@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-new-block-06.txt >=20 > Hello new-block authors, >=20 > here a few notes that I didn't see fitting any of the previous threads = > (or so I > hope): >=20 > * "can fall back to using Block1 and Block2 Options, respectively": = Even > though the rest says (as agreed on) that it's both-or-none, the > "respectively" seems to imply otherwise -- maybe just drop the word. [Jon] "respectively" dropped >=20 > * CSM option: "There is little, if any, benefit of using these options > with [reliable transports]" ... and reliable transports are the only > thing CSMs are defined for. So why define a CSM if it's not expected > to be useful? [Jon] This is here for completeness. DOTS tries to use UDP, but falls = back to using TCP if unable to use UDP.=20 >=20 > * Ad Class E/U: It may be worth stating that it *is* allowed to mix > Block and Q-Block when one is inner and the other is outer -- for = the > simple reason that there'd be no way to enforce anything else, for > proxies along the path can perform outer-blockwise transfers in > ignorance of the content. >=20 > (Then, at a receiver, an outer Block option could arrive, and when > that's done, it should still process the inner Q-Block without = erring > just because the two worlds met). [Jon] Good point. OLD Note that if Q-Block1 (or Q-Block2) Option is included in a packet, = Block1 (or Block2) Option MUST NOT be included. NEW (moved to after the OSCORE statement) Note that if Q-Block1 or Q-Block2 Options are included in a packet as = Inner options, Block1 or Block2 Options MUST NOT be included as Inner options. Similarly there MUST NOT be a mix of Q-Block and Block for the Outer options. Q-Block and Block Options can be mixed across Inner and Outer options as these are handled independently of each other. >=20 > * 3.3 Use of the QB1 option: >=20 > The rules for the final message are different between 2.04 Changed > ("token SHOULD be from the last received payload") and 2.05 Content > (~"MUST be the one in the final block"). Any reason for that? [Jon] The original thinking was that with FETCH and Observe, the server needs a token for sending back any Observes. The client needs to know = the exact token that will get used for matching up any Observe responses. = Hence the MUST. However, see next response. > The > former sounds more sensible. (I originally favored the latter, but > then when a 4.08 comes back on the last-block request, the same = token > would need to be used for the final successful response too, and > that'd be awkward -- and I'd prefer to avoid it if we can pick the = one > rule set ("SHOULD from the last received") that allows having only = one > response per token unless there are actually multiple blocks > transported on it). [Jon] It is true that the final block can be sent, and then = re-requested, so the server does not know which token to pick for the Observe in this = case. OLD This Response Code indicates successful receipt of the entire FETCH = request body (Section 2 of [RFC8132]) and the appropriate representation of the resource is being returned. The token used in the response MUST be the = one in the FETCH request that has the Q-Block1 with the M bit unset. If the FETCH request includes the Observe Option, then the server MUST use the = same token for returning any Observe triggered responses. NEW This Response Code indicates successful receipt of the entire FETCH = request body (Section 2 of [RFC8132]) and the appropriate representation of the resource is being returned. The token used in the response SHOULD be = from the last received payload. If the FETCH request includes the Observe = Option, then the server MUST use the same token for returning any Observe = triggered responses so that the client can match them up. >=20 > * 3.5 Block + Observation: Has this been implemented and tested? The > combination of Block1(!)+Block2+Observer is already tricky with > regular blocks, and made harder by the semi-noresponse blocks here. >=20 > Unless you have a use case for it, I'd ask to see this implmeneted > before it is published, or else to leave this as "interactions are = up > to further specification" (with a corresponding note in the > ups-and-downs list) in the interest of getting this on speedily = (given > this document's purpose is to get the DOTS use case running). [Jon] Yes, this has been implemented and tested. =20 >=20 > * The 2.31 Continue rules: Why not send it with CON? A 2.31 Continue = is > just as compact as an ACK, and can convey to the client that all > packages up to that point have been received, so it doesn't need to > retransmit the earlier ones even though the corresponding ACK may = have > gotten lost. [Jon] For DOTS, we have to have the entire conversation for the = transmission of the telemetry data as NON, as there could be a flooded pipe in one direction because of a DDoS attack. >=20 > * The new QB2 M-bit rules depend on MAX_PAYLOADS to be agreed. But=20 > that > agreement is SHOULD only, and even that's already stretching what = I'd > expect of a configurable CoAP parameter. [Jon] Having the flexibility and ability to configure the actual value = and mutually agree on the new value could beneficial to DOTS (clients on low bandwidth networks may want to tune it down as suggested as per:- "If the CoAP peer reports at least one payload has not arrived for each = body for at least a 24 hour period and it is known that there are no other network issues over that period, then the value of MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and the situation = re-evaluated for another 24 hour period until there is no report of missing payloads under normal operating conditions. The newly derived value for = MAX_PAYLOADS should be used for both ends of this particular CoAP peer link. Note = that the CoAP peer will not know about the MAX_PAYLOADS change until it is reconfigured. As a consequence of not being reconfigured, the peer may indicate that there are some missing payloads prior to the actual = payload being transmitted as all of its MAX_PAYLOADS payloads have not arrived." >=20 > It's also rather complicated. How is this better than a simple = "M=3D1 > means this block plus as many as you can comfortably send, where = M=3D0 > is for this one only"? [Jon] We still need to have a concept of 'Continue' to reduce any NON_TIMEOUT delays for every MAX_PAYLOADS for handling congestion = control. 'Continue' is used in multiple places in the draft. >=20 > * "is meant to prevent amplification attacks": Could you elaborate? A > client permitted the use of QB2 has already some leverag on the = server > to start attacks, and would in any case (overlaps or not) only be > permitted MAX_PAYLOADS on a single request by the server, no matter > how it requests more than that. [Jon] A single request, containing multiple Q-Block2 with M set and the = same NUM (0 meaning all blocks is a really bad case) would otherwise (no = overlap protection) cause MAX_PAYLOADS to be sent, NON_TIMEOUT pause, next set = of MAX_PAYLOADS, NON_TIMEOUT pause etc. for quite some time. Request = packet of 1k+, each Q-Block2 being 2 bytes gives 500+ requests for lots of = packets. Yes, there are NON_TIMEOUT gaps giving respite against a single request, = but multiple requests would average things out. >=20 > * "then the body response SHOULD be restarted with a different ETag > Option value": That behavior sounds like a recipe for endless = running > requests when CON is involed (which, granted, are under flow = control, > but still don't do anything useful). Given there is also a > recommendation to keep the being-transmitted version alive, why not > just stop the transmission? Or send just one final block of the new > value -- and then it's up to the client to decide whether that's a > representation it already knows (and just got a freshness statement > for) or needs to get it as a whole again? [Jon] My implementation maintains the cached body as per previous RECOMMENDED statement which keeps things simple. I was then trying to = cover the non-cached copy case. I agree with your concern. [Jon] From the client's perspective, ETag is opaque with no way of = knowing a newly seen ETag is earlier or later. If a NON (old) ETag is out of = sequence on arrival or there is a CON retransmit with an (old) ETag the client = has to make a decision on seeing the (old) ETag (which may be for a single = packet that holds the whole body and hence is not in the clients history). = Does the current receipt of multiple payloads get aborted or ... when the = (old) ETag is seen? [Jon] The new data length may be less than the previous payload, and so = the currently being transmitted block is beyond the size of the new data. [Jon] The (needs terminating) response can be for something other than a GET, making it a bit more problematic for the client to continue - especially if there is non-idempotent usage. [Jon] Two ways forward here 1. Make previous statement a MUST and delete this statement Or 2. OLD If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the = old data, then the body response SHOULD be restarted with a different ETag Option value. Any subsequent missing block requests MUST be responded to using the latest ETag Option value. NEW If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the = old data, then the transmission is terminated. Any subsequent missing block requests MUST be responded to using the latest ETag and Size2 Option = values with the updated data. [Jon] Preferences ? >=20 > * 3.6 Size1/2: These options MUST be used per 3rd paragraph, so the = "If" > in the 4th is odd. >=20 > * (General wording: It's "A comprise X and Y" or "A is comprised of X > and Y"; https://en.wiktionary.org/wiki/comprise#Usage_notes "in the > passive voice") [Jon] OLD The Size1 Option MUST be used with the Q-Block1 Option when used in a request. The Size2 Option MUST be used with the Q-Block2 Option when = used in a response. If Size1 or Size2 Options are used, they MUST be used in all payloads of = the body and MUST preserve the same value in each of those payloads. NEW The Size1 Option MUST be used with the Q-Block1 Option when used in a request and MUST be present in all payloads of the request preserving = the same value. The Size2 Option MUST be used with the Q-Block2 Option when = used in a response and MUST be present in all payloads of the response = preserving the same value. >=20 > * 4 the new 4.08 format: Since this is a CBOR sequence, the > implementation note on telling the array length in advance does not > apply. As for the CDDL, I don't know whether the array format is OK = to > use for the sequence, or whether the CBOR [Jon] Not sure what you are trying to ask here. I know we removed the Request-Tag from the CDDL which may have changed things. >=20 > * 5. Use of Tokens: The MUST on the unique tokens misrepresents > echo-request-tag. There are rules there about when a token can or = can > not be reused, and they depend on factors immaterial to the present > specification. >=20 > In particular, when used with CoAP-over-TLS or with OSCORE, using > non-unique tokens is quite alright. >=20 > I recmomend not making a normative statement where none is required; > eg. >=20 > "Each new request generally uses a new Token (and sometimes must, = see > Section 4 of ERT). Additional responses to a request all use the > token of the request they respond to". [Jon] Gone with your suggestion. >=20 > * "Implementation Note: To minimize": I'd prefer to go with "it is > suggested" rather than "recommended", but as long as it's not in > normative language, I don't care too much. [Jon] Ok >=20 > * "Servers continue to treat": While not factually incorrect = considering > the above recommendation, the reference to the 32 bits in the > paragraph about the server is confusing. Last prenthized expression > could read "(i.e., is sent on the token of the request that caused > its retransmission)". [Jon] OLD To minimize on the number of tokens that have to be tracked by clients, = it is recommended that the bottom 32 bits is kept the same for the same = body and the upper 32 bits contains the current body's request number (incrementing every request). This allows the client to be alleviated = from keeping all the per-request-state, e.g., in Section 3 of [RFC8974]. Servers continue to treat the token as a unique opaque entity. If an individual payload has to be resent (e.g., requested upon packet loss), = then the retransmitted packet keeps the same bottom 32 bits and the upper 32 = bits is incremented. NEW To minimize on the number of tokens that have to be tracked by clients, = it is suggested that the bottom 32 bits is kept the same for the same body = and the upper 32 bits contains the current body's request number = (incrementing every request, including for every re-transmit). This allows the client = to be alleviated from keeping all the per-request-state, e.g., in Section 3 = of [RFC8974]. >=20 > * (I skipped through the congestion contol section for the time being; > it's probably best read by someone with some experience in = congestion > control which I lack). [Jon] Noted. >=20 > * "When the next client completes building the body, any existing > partial body transmission to the CoAP server is terminated": Just a > note, you're already using Request-Tag, so you could leave it up to > the proxy to try to run them simultaneously (it obviously can, as it > already got to the point of having both request bodies loaded in > full). The server can then still cancel one or postpone the other. [Jon] If the proxy uses multi-plexing client logic to talk to a singular server with a common 'CoAP session', it has to determine which body = entity to terminate - and may chose the wrong one based as timing, whereas it = is simpler to get the proxy to make the correct decision. >=20 > * Figure 6: The first line says "for RT=3D11", that's probably a = remnant > from when the Request-Tag was copied into the payload. (Same for = later > '[for RT=3D...]' items [Jon] Fixed ~Jon >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater=20 > powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 08:29:29 2021 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 632733A1405 for ; Thu, 18 Feb 2021 08:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 655i5Z9sRe_B for ; Thu, 18 Feb 2021 08:29:22 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E853A13EA for ; Thu, 18 Feb 2021 08:29:22 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCjCt-0005KZ-7A; Thu, 18 Feb 2021 13:18:59 +0000 From: To: , Cc: , , References: <23740_1612339780_601A5A44_23740_98_8_787AE7BB302AE849A7480A190F8B9330315C6374@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Thu, 18 Feb 2021 13:19:02 -0000 Message-ID: <004401d705f8$a0333de0$e099b9a0$@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: AQKB62JphLL4G1Ld1UlfNpXpEuFZPqkIBQCQ Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) 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, 18 Feb 2021 16:29:28 -0000 Hi Christian, We have gone with adding to Section 1.1 " The No-Response Option was considered but was abandoned as it does not apply to Q-Block2 responses. A unified solution is defined in the = document." Regards Jon > -----Original Message----- > From: Christian M. Ams=FCss [mailto:christian@amsuess.com] > Sent: 16 February 2021 23:54 > To: mohamed.boucadair@orange.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org = WG > (core@ietf.org) > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) >=20 > Hello Med, >=20 > On Wed, Feb 03, 2021 at 08:09:40AM +0000, mohamed.boucadair@orange.com > wrote: > > As a follow-up on this issue, we finally went with an approach that > > does not require No-Response. We do have the following to avoid = extra > > delays, e.g., >=20 > The need to indicate when a client wants confirmation has been avoided = by > having timeouts on both sides, and relying more on MAX_PAYLOADS being > aligned. >=20 > For my taste, that makes unnecessary sacrifices in robustness over the simple > two-byte NoResponse:0 that'd go with every MAX_PAYLOADS'th > Q-Block2 from the client (and would completey avoid the risk of = stalling in a > lossless situation). >=20 > (For the other direction, corective heuristics can easily be applied). >=20 > But given they are explicitly configured in the DOTS case where = Q-Block is used, > so -- well. Food for a block-bis (or generalized additions that allow block to be > used that way). >=20 >=20 > That aside, in the interest of readers who try to understand the = ecosystem and > the trade-offs involved, I think that at least a reference to it in a statement like > "was not chosen because of X" would be helpful. The "Note that similar > performance benefits" section would lend itself to that. Text = suggestion: >=20 > [messages are provided in Appendix A.] Similarly, The No-Response = option > can be applied to Block1 requests, but offers no corresponding = facility > for Block2 responses. >=20 > BR > c >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 08:40:31 2021 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 A85503A1425 for ; Thu, 18 Feb 2021 08:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pAECU5UTeFq for ; Thu, 18 Feb 2021 08:40:23 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2493A1428 for ; Thu, 18 Feb 2021 08:40:18 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCmIy-0005Tw-LR; Thu, 18 Feb 2021 16:37:28 +0000 From: To: Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 16:37:32 -0000 Message-ID: <00f901d70614$5ab51b50$101f51f0$@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: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYCKEdkN6jNWQ8Q Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 18 Feb 2021 16:40:27 -0000 Hi Christian, We are following https://tools.ietf.org/html/rfc8742#section-4.1 here. = CDDL does not support a notation for top-level CBOR sequences so have gone = with the recommendations of this section. As CDDL defines it as an array using the documentation text "This = defines an array, the elements of which are to be used in a CBOR Sequence:", I am thinking that we need to keep it as an array. I guess that we need an expert understanding of what to do here. - Maybe leave out the CDDL definition and give an example? Regards Jon > -----Original Message----- > From: Christian M. Ams=FCss [mailto: christian@amsuess.com] > Sent: 18 February 2021 13:32 > To: supjps-ietf@jpshallow.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Picking a quick one because I don't know when I'll get to the rest: >=20 > > > * 4 the new 4.08 format: Since this is a CBOR sequence, the > > > implementation note on telling the array length in advance does = not > > > apply. As for the CDDL, I don't know whether the array format is = OK to > > > use for the sequence, or whether the CBOR > > > > [Jon] Not sure what you are trying to ask here. I know we removed = the > > Request-Tag from the CDDL which may have changed things. >=20 > If the array were sent in CBOR, indeed the sequence 1, 10, 20 would = look like this > (courtesy of cbor.me): >=20 > 83 # array(3) <--- here is where you need to know the length in = advance > 01 # unsigned(1) > 0A # unsigned(10) > 14 # unsigned(20) >=20 > But as the content format is a cbor-sequence one, what you actually = send is this: >=20 > 01 # unsigned(1) > 0A # unsigned(10) > 14 # unsigned(20) >=20 > (No array header, just a sequence of self-delimited items). >=20 > So now the implementer's worst worry is that if they start writing an = item in the > last byte and the item needs a u16 they gotta roll back, but that is simple. Picking > the array length in advance would be hard (and the implementation = note's > suggestion of not exceeding 23 items would apply), but by using a CBOR > sequence you're already free of that. >=20 > BR > c >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 08:44:00 2021 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 36F203A136C; Thu, 18 Feb 2021 08:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikpC00kFSe0Z; Thu, 18 Feb 2021 08:43:52 -0800 (PST) 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 466793A142D; Thu, 18 Feb 2021 08:43:49 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DCDED40887; Thu, 18 Feb 2021 17:43:47 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DF2EAFD; Thu, 18 Feb 2021 17:43:46 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9DB99190; Thu, 18 Feb 2021 17:43:46 +0100 (CET) Received: (nullmailer pid 839522 invoked by uid 1000); Thu, 18 Feb 2021 16:43:46 -0000 Date: Thu, 18 Feb 2021 17:43:46 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: supjps-ietf@jpshallow.com Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aDaF68xRb12J6Va2" Content-Disposition: inline In-Reply-To: <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 18 Feb 2021 16:43:54 -0000 --aDaF68xRb12J6Va2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, On Thu, Feb 18, 2021 at 04:37:32PM -0000, supjps-ietf@jpshallow.com wrote: > I guess that we need an expert understanding of what to do here. > - Maybe leave out the CDDL definition and give an example? the CDDL definition is fine and following the state-of-the-art workaround. But what it means is that the array wrapping is only there on paper to make the CDDL happy. And as the array header does not hit the wire (and is not generally constructed in memory either), the implementation note is moot. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --aDaF68xRb12J6Va2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAumT4ACgkQOY0REtOk veEPbA//d865P9xMR7jFfd+6JWJ9+Ou5RMIvFyDqPN/whCO3V3Zv6ib80RLX3edj GFzqitykklEIEUQZDCxGDcOU2P3h3GqSfBvVs4Xl2dWRp6nbIUXSndYw7bqVp7Ba q8RHWeM1DZaYxwudFW4pXuYoPGlGczK5VvQVujuFjsHCFfQN9tODgSFzzKYfZgzE TAsINVyXaAVfgW9qVP5VbTxCzWvPli9+rfSOlm+Oh61eDmwdrIkRHHjV2rjwcI8W k50e2/e8nFCyGgmKVcmr255H7f37WiAkIgOwCIzx5UXD4WWZ+kwEw6EvlaTpxzZx LpcY5kIGCBgHRJ85xU2izMBa2brJko8J5sK1jx56xJtYsbyDeMv6AevWviQCbFKa l1cFlUF4qgLv6R7Nbb03omyo7KSYgSRVQ0EgB9WCXmLtHT/ZXST7PxyBTV7sC4mN 3MBY8j20BF2vP3yJxHKFVto10VsVssfxfHprwAymWI3RDf0hftLkLMlXkzITMjcP M5pU6L/DuZPZuEov1H/X+kXHJikoYwM0Hj5LJ99FOpH7wCCViCymlBnJuo57GTCo aBRwcmkctqm5ov++s2Z9P77RCfePweQxUpDo3sSRZtG7uROnEoVrd+GIFVTjRFr5 ShEDjzDf6CwKzsFZaYIDdJTrMUQYA3Ov5EBgv5Lm00tsVwLH10A= =AZjU -----END PGP SIGNATURE----- --aDaF68xRb12J6Va2-- From nobody Thu Feb 18 09:01:04 2021 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 520A73A145F for ; Thu, 18 Feb 2021 09:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty67UNSIFTs8 for ; Thu, 18 Feb 2021 09:01:00 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D3D3A1454 for ; Thu, 18 Feb 2021 09:00:53 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCmfb-0005Vy-Jv; Thu, 18 Feb 2021 17:00:51 +0000 From: To: Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 17:00:55 -0000 Message-ID: <011801d70617$9eeb3c70$dcc1b550$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYCKEdkNwJGSVBOANS1kPiotIo9wA== Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 18 Feb 2021 17:01:03 -0000 Hi Christian, > the CDDL definition is fine and following the state-of-the-art workaround. > > But what it means is that the array wrapping is only there on paper to make the > CDDL happy. And as the array header does not hit the wire (and is not generally > constructed in memory either), the implementation note is moot. Happy to remove the (actual) array wrappers and associated stuff despite CDDL documentation text. I think I will add in an example to keep me happy by removing any ambiguity about the array. Regards Jon From nobody Fri Feb 19 01:47:40 2021 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 503BD3A1330 for ; Fri, 19 Feb 2021 01:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 A3cxFWbxHkmp for ; Fri, 19 Feb 2021 01:47:37 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA1D3A132D for ; Fri, 19 Feb 2021 01:47:36 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lD2Nq-0006BJ-Rj; Fri, 19 Feb 2021 09:47:34 +0000 From: To: Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> <011801d70617$9eeb3c70$dcc1b550$@jpshallow.com> In-Reply-To: <011801d70617$9eeb3c70$dcc1b550$@jpshallow.com> Date: Fri, 19 Feb 2021 09:47:37 -0000 Message-ID: <01ab01d706a4$41b1bf10$c5153d30$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYCKEdkNwJGSVBOANS1kPgBkCyM3KipIksA Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 19 Feb 2021 09:47:39 -0000 Hi Christian, I have gone with just updating the wording. Changes can be found at https://tinyurl.com/new-block-latest for page 16. Regards Jon > -----Original Message----- > From: supjps-ietf@jpshallow.com [mailto:ietf-supjps-supjps- > ietf@jpshallow.com] > Sent: 18 February 2021 17:01 > To: christian@amsuess.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > > Hi Christian, > > > the CDDL definition is fine and following the state-of-the-art workaround. > > > > But what it means is that the array wrapping is only there on paper to > make the > > CDDL happy. And as the array header does not hit the wire (and is not > generally > > constructed in memory either), the implementation note is moot. > > Happy to remove the (actual) array wrappers and associated stuff despite > CDDL documentation text. > > I think I will add in an example to keep me happy by removing any ambiguity > about the array. > > Regards > > Jon > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 19 03:54:08 2021 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 44B613A0ABD; Fri, 19 Feb 2021 03:53:57 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161373563722.4811.9796253912466877103@ietfa.amsl.com> Date: Fri, 19 Feb 2021 03:53:57 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-07.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: Fri, 19 Feb 2021 11:53:59 -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-07.txt Pages : 45 Date : 2021-02-19 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://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-07 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 19 04:19:39 2021 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 1877D3A0A29 for ; Fri, 19 Feb 2021 04:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3JFC-UfYbtvU for ; Fri, 19 Feb 2021 04:19:36 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40ACA3A097D for ; Fri, 19 Feb 2021 04:19:35 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lD4kv-0006Fr-E7 for core@ietf.org; Fri, 19 Feb 2021 12:19:33 +0000 From: To: References: <161373563722.4811.9796253912466877103@ietfa.amsl.com> In-Reply-To: <161373563722.4811.9796253912466877103@ietfa.amsl.com> Date: Fri, 19 Feb 2021 12:19:36 -0000 Message-ID: <01c601d706b9$7cbc9890$7635c9b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD2GJ0yVLT4jjRXMHfCOcoYizYiWKwhP/UQ Content-Language: en-gb Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-07.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: Fri, 19 Feb 2021 12:19:38 -0000 Hi All, The main changes between -06 and -07 are:- * minor updates based on the implementation feedback. * fixes based on the feedback from Christian. We believe that all comments have been addressed and we would like to progress the draft. Regards Jon & Med > -----Original Message----- > From: internet-drafts@ietf.org [mailto: internet-drafts@ietf.org] > Sent: 19 February 2021 11:54 > To: i-d-announce@ietf.org > Cc: core@ietf.org > Subject: [core] I-D Action: draft-ietf-core-new-block-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments WG of the > IETF. > > Title : Constrained Application Protocol (CoAP) Block-Wise Transfer > Options for Faster Transmission > Authors : Mohamed Boucadair > Jon Shallow > Filename : draft-ietf-core-new-block-07.txt > Pages : 45 > Date : 2021-02-19 > > Abstract: > This document specifies alternative Constrained Application Protocol > (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. > > These options are similar to the CoAP Block1 and Block2 Options, not > a replacement for them, but do enable faster transmission rates for > large amounts of data with less packet interchanges as well as > supporting faster recovery should any of the blocks get lost in > transmission. > > > The IETF datatracker status page for this draft is: > https://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-07 > https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-07 > > > 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/ > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 19 08:33:24 2021 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 512733A1121 for ; Fri, 19 Feb 2021 08:33:22 -0800 (PST) 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 PQtc2nXBZZ27 for ; Fri, 19 Feb 2021 08:33:18 -0800 (PST) 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 F3BBA3A1117 for ; Fri, 19 Feb 2021 08:33:17 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4Dhxvw4wFyzyTH; Fri, 19 Feb 2021 17:33:16 +0100 (CET) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_8455D0E5-E7FB-42A0-AEAD-550DACC96F76" X-Mao-Original-Outgoing-Id: 635445196.015727-38531109b596353201904c72f5851130 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Feb 2021 17:33:16 +0100 Message-Id: References: <0DA2C70A-AF06-4629-BA3C-D22F942526AE@tzi.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [core] Fwd: draft-bormann-core-media-content-type-format 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, 19 Feb 2021 16:33:22 -0000 --Apple-Mail=_8455D0E5-E7FB-42A0-AEAD-550DACC96F76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If you have an opinion on whether this draft should go forward, you may = want to follow (and/or speak up in) the DISPATCH WG in the next few = weeks. Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Carsten Bormann > Subject: draft-bormann-core-media-content-type-format > Date: 2021-02-19 at 17:31:00 CET > To: dispatch@ietf.org > Message-Id: <0DA2C70A-AF06-4629-BA3C-D22F942526AE@tzi.org> >=20 > In the CoRE working group, we noticed that we were stumbling over = terminology around media-types, content-types, content-codings, = content-formats (a CoAP term), etc.; essentially creating rather = imprecise documents as a result. > We also noted that we needed some ABNF that we can import into = specifications such as draft-ietf-core-senml-data-ct [1]. >=20 > So at some point we broke down and wrote it up: >=20 > = https://datatracker.ietf.org/doc/draft-bormann-core-media-content-type-for= mat/ >=20 > But the CoRE WG cannot really adopt this document on its own, as (most = of) these are not CoRE terms, and the CoRE WG is not chartered to fix up = IETF-wide terminology (and ABNF). >=20 > I would like to bring this document up at the IETF110 meeting, and = would welcome a list discussion here leading up to that. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > [1]: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ >=20 --Apple-Mail=_8455D0E5-E7FB-42A0-AEAD-550DACC96F76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = you have an opinion on whether this draft should go forward, you may = want to follow (and/or speak up in) the DISPATCH WG in the next few = weeks.

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


Begin forwarded message:

From: = Carsten Bormann <cabo@tzi.org>
Subject: = draft-bormann-core-media-content-type-format
Date: = 2021-02-19 at 17:31:00 CET
To: = dispatch@ietf.org
Message-Id: <0DA2C70A-AF06-4629-BA3C-D22F942526AE@tzi.org>

In = the CoRE working group, we noticed that we were stumbling over = terminology around media-types, content-types, content-codings, = content-formats (a CoAP term), etc.; essentially creating rather = imprecise documents as a result.
We also noted that we = needed some ABNF that we can import into specifications such as = draft-ietf-core-senml-data-ct [1].

So at = some point we broke down and wrote it up:

https://datatracker.ietf.org/doc/draft-bormann-core-media-conte= nt-type-format/

But the CoRE WG cannot = really adopt this document on its own, as (most of) these are not CoRE = terms, and the CoRE WG is not chartered to fix up IETF-wide terminology = (and ABNF).

I would like to bring this = document up at the IETF110 meeting, and would welcome a list discussion = here leading up to that.

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

[1]: = https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/


= --Apple-Mail=_8455D0E5-E7FB-42A0-AEAD-550DACC96F76-- From nobody Sun Feb 21 10:00:22 2021 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 0D8753A0DDD; Sun, 21 Feb 2021 10:00:17 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161393041700.21259.6101326679475731385@ietfa.amsl.com> Date: Sun, 21 Feb 2021 10:00:17 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-versions-02.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: Sun, 21 Feb 2021 18:00:17 -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 : SenML Features and Versions Author : Carsten Bormann Filename : draft-ietf-core-senml-versions-02.txt Pages : 7 Date : 2021-02-21 Abstract: This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 21 10:01:45 2021 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 993B13A0DE0 for ; Sun, 21 Feb 2021 10:01:42 -0800 (PST) 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 JnnFPcPpBk9d for ; Sun, 21 Feb 2021 10:01:39 -0800 (PST) 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 E51F93A0DDD for ; Sun, 21 Feb 2021 10:01:31 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DkCmp2DQYzyjQ; Sun, 21 Feb 2021 19:01:30 +0100 (CET) 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: <161393041700.21259.6101326679475731385@ietfa.amsl.com> Date: Sun, 21 Feb 2021 19:01:29 +0100 X-Mao-Original-Outgoing-Id: 635623289.747951-eb243832bab3a80765275fbc844a6ca1 Content-Transfer-Encoding: quoted-printable Message-Id: <385D7304-E905-48F5-96D0-43DDC047B3E9@tzi.org> References: <161393041700.21259.6101326679475731385@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-versions-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: Sun, 21 Feb 2021 18:01:43 -0000 -02 has the updates from a review by Jaime. Gr=C3=BC=C3=9Fe, Carsten > On 2021-02-21, at 19:00, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Constrained RESTful Environments WG = of the IETF. >=20 > Title : SenML Features and Versions > Author : Carsten Bormann > Filename : draft-ietf-core-senml-versions-02.txt > Pages : 7 > Date : 2021-02-21 >=20 > Abstract: > This short document updates RFC 8428, Sensor Measurement Lists > (SenML), by specifying the use of independently selectable "SenML > Features" and mapping them to SenML version numbers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-02.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Feb 21 10:05:52 2021 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 A40B03A0DFB for ; Sun, 21 Feb 2021 10:05:51 -0800 (PST) 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 2ASD_iP1l3T8 for ; Sun, 21 Feb 2021 10:05:49 -0800 (PST) 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 4F1463A0DF3 for ; Sun, 21 Feb 2021 10:05:48 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DkCsk6J10zyfY; Sun, 21 Feb 2021 19:05:46 +0100 (CET) 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: <232df620-b11d-4fd4-b9ed-4be6e1ab411f@www.fastmail.com> Date: Sun, 21 Feb 2021 19:05:46 +0100 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 635623546.407421-cc86500de88257e87c602f8794610fdc Content-Transfer-Encoding: quoted-printable Message-Id: <319CA1C6-4FA4-489A-A849-E923D9659D98@tzi.org> References: <422b8d83-ee97-4a6c-81ec-3cf004f2cd09@www.fastmail.com> <3388E5A7-FF68-490A-8DA8-075CBF94DEDE@tzi.org> <232df620-b11d-4fd4-b9ed-4be6e1ab411f@www.fastmail.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Review of draft-ietf-core-senml-versions-01 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: Sun, 21 Feb 2021 18:05:52 -0000 On 2021-02-12, at 11:18, Jaime Jim=C3=A9nez wrote: >=20 > BTW there seems to be some travis-ci issue.=20 > https://travis-ci.org/github/core-wg/senml-versions/jobs/758663186 Generally, travis seems to have problems and we are moving to github = workflows anyway. The docker image that I-d-template currently uses does not support the = kind of math(*) that is used in the document, so right now builds need = to be manual. Gr=C3=BC=C3=9Fe, Carsten (*) Yes, one can have math in plaintext and HTML I-Ds and RFCs! From nobody Sun Feb 21 10:15:12 2021 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 3DD403A0E13; Sun, 21 Feb 2021 10:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, 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 w5bpuXKzUen1; Sun, 21 Feb 2021 10:15:05 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2088.outbound.protection.outlook.com [40.107.20.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 56BC33A0E15; Sun, 21 Feb 2021 10:15:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=asSKiXjkt63Ua+ednZ6u4tUB0hY+eSUTxCu3kQ4gCd1MjgbxUd0gTSKnvRi+Ouf1Ari3hsfQzLMe+3vASihm587lNMEDTOCtCrAgFrzBoW50OKVdkby77z+nVKJ3LlGvZ6gFEf5nU8UpH1kEtJAnapS6swHbrfservKKlaksUdFql87FNcQ/iJd+o0Eg7re/kaxe7RA1tF3yaOVjYaTC9Uw/yCqQ6Vt/VTMvUKYYxqE0at6Sa/tCv3R0qE5Lug8G9Gu7bxjuQ0o9pnRbZOtF/rbFb2f3UdsY95Gdp2djBSCGUv1wBFyVfAtL5tpFImGJFAmSrScq7CmnvtlDv7pCCw== 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=+ErzdvBdRX0iKO2/kfR6puMJaKktra/aWj8zL9Gismg=; b=KZA4UFmWxwjHjvNv2qQpWEqpfAUkP29lYrEbyw2B92U6bAonYUwn9VLC8HPb1qKoqAfrb7zGo1wH29JKPHtz7iauFmg0hHf6Btlmnv2Z9V1nFj0RFJ+mFhZN9HNNWXKd2k6JTrp1XLdOcVwFZiM5e80OvcBZlmSguxHHuP3xoWmSp2qOEDh9IYB5ne2OqInOIaAqEaySxcBMyFa/3EcHlseDslnfmCP+E1w0Ah/G0riwvZPXBz2C/3BlmNsyB2PyK6/yWLZy/AA7Zka1OQOv5MnBG8SCSotLsFiOrbjz7XlaC8N0qAHWSDI5WGYFeOSy/2i5Ju1Sle2wXgey2oXx4w== 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=+ErzdvBdRX0iKO2/kfR6puMJaKktra/aWj8zL9Gismg=; b=nqd17r9fOL0M/EjU+wXgKkMkmYDDB/wdPR1KcjsUjHzwZByflwX9CpoK0r4xugsyBaPEC4Zr/mMm4syOUnH87hzlTkUMlYM24aeveJg/e2uZU4LeYX7hWpCFx0egAVh5sKuZ3Rt+cgJDuayIrqwNGFjhFhoVqIAzRxe0gnGQ6XU= Received: from (10.168.92.136) by HE1PR07MB4363.eurprd07.prod.outlook.com (20.176.164.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Sun, 21 Feb 2021 18:14:09 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::c555:6e47:970c:1268]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::c555:6e47:970c:1268%11]) with mapi id 15.20.3868.025; Sun, 21 Feb 2021 18:14:08 +0000 From: John Mattsson To: "cfrg@ietf.org" , "TLS@ietf.org" , "quic@ietf.org" , "core@ietf.org" Thread-Topic: Applied AEAD limits in (D)TLS, QUIC, OSCORE, ... Thread-Index: AQHXCH1YiGAcTblN70aS3TibPweiaw== Date: Sun, 21 Feb 2021 18:14:08 +0000 Message-ID: <36004EDE-523A-42AC-83BF-33F05AA08C27@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14bdcb02-0095-4b07-916f-08d8d6947b91 x-ms-traffictypediagnostic: HE1PR07MB4363: 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: 1xoG+WhiCWVR6VuuTGlfpJ/eA8nm7MNg8i9UvGnV9t3fjT3MKHi/f0mQhzWR78Y9dKRIY4PegYwU8GKwBwdhBbLBf5a2VD3m8wmTqWraoLPOhCfOX7pluiLmQGWuzCZEVwTecPJbHsZzDm8RSMO7mSL0cX4tvmgaxdXbte6r8P5aZQUIWiUE8LnxVGk/j5YNieIuhRSzSKVFiYBx0wzd4DnezaRYFkrzN7d7WssuQgWo2XlnqhyXvev7SLg2f49ICVHsR67LqgddBpVz8za/zy/ZR+gZyTk4N96a/naCpQ6JAXCrMROR+lwt8wQ7smZ4U335tFgRk3f6Oy9nYmi50wRbxQKEURXeB7+F6XJknp/I+485zvscb7b4e7elGQH7NQtPqN3zK7QPNfGWDsXiYT9VkDb3mfkoV5rfkZX4CbWHgyoFQMuBVloR1icsp3lMD06ZCrlzQIbexsA2J/gwqoKGNvoBu/AlMm+KZ2qWQYpr6ZvzjgU6xk+4JwysHVtxKwZqfXbHn/+KTPMeZt+7I/qNo9wzCZzMNlTKWV98bi7eJ8M5vPy5OSGoVzx/cRpyUhY1SHT03UPYI7MXAjxj3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(39860400002)(366004)(396003)(64756008)(26005)(66446008)(8676002)(5660300002)(66556008)(6506007)(66946007)(450100002)(478600001)(186003)(2906002)(76116006)(66476007)(33656002)(44832011)(71200400001)(83380400001)(316002)(6512007)(8936002)(110136005)(36756003)(86362001)(6486002)(2616005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?ckFXTzJ2czRwb0RwakxENHFUQkEyT3VlcVlRODdaYXh0RDRvcDBKaEI4WERE?= =?utf-8?B?S1pSWXpHd0J2Q295NTZ4cUw0UDkvNWdjeG9kYWhSaXdnVmJZNllYR0hIQWRj?= =?utf-8?B?Zms4SzQySEoxb21wNWQzdWhCb0xrRmpEczlKYXpPczdJTzJFMEwzRGJIWkY4?= =?utf-8?B?VXBPcjNxRTJqSzFFOWFrTE91c09PSnczc1NmbVE3QTlsRXVvRk5ObzRlODB6?= =?utf-8?B?YVQ4dTFQWWo0ZUhoT0xQaklFRnJnWjd2VjNSNVAydUpndFJHakV3YmpsaUtZ?= =?utf-8?B?SnZwSUFhdmZHRHVaeTZNWVJ0NVJoSHd6Um1jU1BpdlNlY1dYY2lHSjhmVnk2?= =?utf-8?B?c1RWY2tmWFBlZ3dBcm1YV0NiM2lvNXUzSEcrb1BKZDU1TzBnS0Fqa3U0LzJT?= =?utf-8?B?TGhKYVlXcWd4ZWUrUzh6RGpKNlN2NmN5TWZkdGlQZEx0M3lUM09WVEFaakV6?= =?utf-8?B?TTB4VW4weGlMNzMzblA4MzErMFFSelc4eDEwOSttbjRWWVBLZ0hLaDZBMHk2?= =?utf-8?B?RE9PakZUbGdod1RRakNXTThZWVFZUmU0Rk5WdFlIWVRNVUdhQ1BJSTA1dHVv?= =?utf-8?B?eHJaYUNPQTRoWHBxRk9pOExiK3hQQTFrU3M3b0lCdE8zN2VacHBaYmR5UlNW?= =?utf-8?B?RzkxRDlma3QybUJ2eHFkdFlqeHUwbEd6MXR6YlBaYVFTRUxpVEE5OFpqZGZC?= =?utf-8?B?SXpRWXoyWTM1ekY4YlZHbU1CZlJpQ2ptdktmR2IwZGtOVnZLTXRmeFlUckcx?= =?utf-8?B?VGxRTWpsRnFGNjAvQU0rYzhFd3FRSndXYXlBQTBpQWZqWk1WcEIrV1ZIVTg1?= =?utf-8?B?QTllQjJhVjVnVW9PRWszaXFCajUxQ1I1b1dwU0ZPaHY1Wkl6am9sL0xqbUs1?= =?utf-8?B?UTEzM3ZUTnVVMUxjUWFvVUV6YlNZYmJCR0RnNDJsRzhoSW9uSFc3dW5mMEor?= =?utf-8?B?cEt3VWdqbTBQZDRXNWUzRmVMR1NBUk9IVTM0YlZ2THN3Z1Q3UUtWc01OWTJp?= =?utf-8?B?b2Y3c2xOTkFzMHJWUHRyaUZnWk5yYXVFZUx2QWxGOG1UcnZhZmMvM1dVT0Js?= =?utf-8?B?b3BMK2lUZVZmTHJENlV2ajJMeGxYVjhTVGlVL2phQ0R3d3NlN3UyanBiSW91?= =?utf-8?B?Y3FFdE1lcllqemI2WHkxYXVCVDNuei9adWpKTG9aSG1qTzV2NTRxUnllcUgv?= =?utf-8?B?bkpiRlJ6M0h2SDcyVGlydER2aE0zMnJrYWNtcHk2N1VKZ1NIck1QN2JZMFVp?= =?utf-8?B?eGFTUHk5ekNjWlpBcE53cnFYKytobUZLNjVrV3FMRFNXdXd0WGIxQWs5Wmxm?= =?utf-8?B?K1M4TER0SHNHMGE4UGc5UFJTZUoyZysrcUNwcHpSd2ZoaTVVM2drYTNMdElN?= =?utf-8?B?YlNLcmtDVFphNGFmNWdNN3JjckRMRk9lcDRzRTFKSmU1eStRdmtKUTVhM2Rn?= =?utf-8?B?cDZUNjJwRGU3QjYwdzIwVitKRE9PS2tiTlNDOHU5ZGFSNmlZdTF5V3B3Sit1?= =?utf-8?B?SkdYWllmbjRGaDNQM2VFMXRIZWtqUHI4VWc3enN0Uk5nWmEzNHdvRHJwVjJq?= =?utf-8?B?NUN5cE0ya2RqVEtIdVFKdS9wMVI5TkFRenFuMmRSa1RPRyttR2RHZXdBWDJQ?= =?utf-8?B?WWo5bm9zK3JldnpEV1BTUkpXU0VyQ1Rac0tqaksvRTBrWFlwYktxUWhiNzNP?= =?utf-8?B?Rkd2VXJPVjNqTTM1YUVVSElxaGNnUEFaRHlsVEFKMmc2bldSMzdwUUlqTFZo?= =?utf-8?Q?VuCOpNSTbW+UDGRSRXBTD+ESex67vOVsPyGLOzj?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8406E33DD5342042BC2264E7383FB64E@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: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14bdcb02-0095-4b07-916f-08d8d6947b91 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2021 18:14:08.8356 (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: 9Kkl+GYiI6dvVQ24tBdr4mR8zpYMQvBurScQMn5ca+vv8Eh6mGx3NVuW1qr1Rhoy/AAW6tIrH2H5wJsRfKXU7+7Qj8pcWwmi4Qdpmxe/RQ8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4363 Archived-At: Subject: [core] Applied AEAD limits in (D)TLS, QUIC, OSCORE, ... 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: Sun, 21 Feb 2021 18:15:07 -0000 SGksDQoNCkkgdG9vayBhIG1vcmUgZGV0YWlsZWQgbG9vayBhdCBob3cgKEQpVExTIGFuZCBRVUlD IGFwcGx5IHRoZSBhZHZhbnRhZ2UgYm91bmRzIGluIHByYWN0aWNlLiBJZiBJIGhhdmUgdW5kZXJz dG9vZCBjb3JyZWN0bHksIChEKVRMUyBhbmQgUVVJQyBzZXQgYm91bmRzIG9uIENBIGFuZCBJQSBm b3IgYSBzaW5nbGUga2V5IChjYWxsZWQgQ0Ffa2V5IGFuZCBJQV9rZXkgYmVsb3cpIGFuZCB0aGVu IGZvcmNlIGEgcmVrZXkgd2hlbiAob3IgYmVmb3JlKSB0aGlzIGxpbWl0IGlzIHJlYWNoZWQuIA0K DQpJIHRoaW5rIGl0IGlzIGdyZWF0IHRoYXQgdGhlIEFFQUQgbGltaXQgd29yayBoYXMgbWFkZSBp dCBjbGVhciB0aGF0IGNvdW50ZXJzIGZvciB2IGFuZCBxIGFzIHdlbGwgYXMgZnJlcXVlbnQgcmVr ZXlpbmcgYXJlIG5lZWRlZC4gSG93ZXZlciB0aGUgcHJvY2VzcyBvZiBsaW1pdGluZyBDQS9JQSBw ZXIga2V5IGRvZXMgbm90IHNlZW0gbGlrZSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gZm9yIGEgc2Vj dXJpdHkgcHJvdG9jb2wgd2hlcmUgZWFjaCBjb25uZWN0aW9uIGhhcyBtYW55IGtleXMsIGNvbW11 bmljYXRpb24gYmV0d2VlbiB0d28gcGFydGllcyBjYW4gdXNlIG1hbnkgY29ubmVjdGlvbnMsIGFu ZCBhZHZlcnNhcmllcyBjYW4gb2Z0ZW4gdHJpY2sgdGhlIHBhcnRpZXMgdG8gdGVhciBkb3duIHRo ZSBvbGQgY29ubmVjdGlvbiBhbmQgc2V0IHVwIGEgbmV3IGNvbm5lY3Rpb24uIEkgdGhpbmsgYSBn ZW5lcmFsIHByb2Nlc3MgbmVlZCB0byBiZSBkZXNpZ25lZCBhIGJpdCBkaWZmZXJlbnRseS4NCg0K VGhlIGNvbmNyZXRlIGxpbWl0cyBvbiB2IGFuZCBxIHNldCBieSAoRClUTFMgMS4zIGFuZCBRVUlD IHNlZW0gZXNzZW50aWFsIHRvIGtlZXAgdGhlIEdDTSBDQSwgQ0NNIENBLCBhbmQgdGhlIENDTSBz dWNjZXNzIHByb2JhYmlsaXR5IHBlciBmb3JnZXJ5IGF0dGVtcHQgbG93LiBUaGUgcHJvY2VzcyB1 c2VkIGNhbiBob3dldmVyIGdpdmUgYSBiaXQgc3RyYW5nZSBhbmQgbWlzbGVhZGluZyByZXN1bHRz IGFzIHNlZW4gYmVsb3c6DQoNCg0KDQpFeGFtcGxlIDE6IFRoZSBpZGVhbCB0LWJpdCBNQUMNCg0K SUFfa2V5ID0gdiAvIDJedA0KDQpVc2luZyB0aGUgcHJvY2VzcyBvZiBzZXR0aW5nIGFuIHVwcGVy IGJvdW5kIHAgPSAyXi01NyBmb3IgYSBzaW5nbGUga2V5IGdpdmVzIHYgPD0gMl50ICogMl4tNTcg YW5kIGZvbGxvd2luZyBRVUlDIGFuZCBEVExTIHlvdSBtdXN0IHJlLWtleSB3aGVuIHRoYXQgbGlt aXQgaXMgcmVhY2hlZCwgYnV0IHRoaXMgZG9lcyBub3QgaW1wcm92ZSB0aGUgc2VjdXJpdHkgYXQg YWxsIGZvciB0aGUgaWRlYWwgTUFDLiBUaGUgZm9yZ2VyeSBwcm9iYWJpbGl0eSBvZiBlYWNoIHBh Y2tldCBpcyBhbHdheXMgMl4tdCBhbnl3YXkuDQoNCg0KRXhhbXBsZSAyOiBTZW5kaW5nIDJeNjQg cGFja2V0cyB3aXRoIENoYUNoYTIwLVBvbHkxMzA1IChsPTJeMTApDQoNCkNBX2tleSA8PSB2ICog bCAvIDJeMTAzDQoNCmEpIFJla3lpbmcgZXZlcnkgVExTIHBhY2tldCBnaXZlcyBDQV9rZXkgPD0g Ml4tOTMNCmIpIFJla3lpbmcgZXZlcnkgMl4zNiBUTFMgcGFja2V0IGdpdmVzIENBX2tleSA8PSAy Xi01Nw0KYykgUmVreWluZyBldmVyeSAyXjY0IFRMUyBwYWNrZXQgZ2l2ZXMgQ0Ffa2V5IDw9IDJe LTI3DQoNClRoZXNlIGxvb2tzIGRyYXN0aWNhbGx5IGRpZmZlcmVudCwgYnV0IGFzc3VtaW5nIHRo ZSBzaW5nbGUta2V5IGJvdW5kcyBhcmUgdGlnaHQsIGFuIGFkdmVyc2FyeSB0cnlpbmcgdG8gYXR0 YWNrIHRoZSB3aG9sZSBjb25uZWN0aW9uIGNhbiBkbyBzbyB3aXRoIGFuIGFkdmFudGFnZSBvZiAy Xi0yNyAoQ0Ffa2V5ICogbnVtYmVyIG9mIGtleXMpIGZvciBhbGwgdGhyZWUgb3B0aW9ucy4NCg0K DQpFeGFtcGxlIDM6IElBIGJvdW5kZXJpZXMgcGVyIGtleS4NCg0KRFRMUyAxLjMgbGltaXRzIElB IHBlciBrZXkgYnV0IGRvZXMgbm90IGxpbWl0IHRoZSBudW1iZXIgb2Yga2V5cyBwZXIgY29ubmVj dGlvbi4gVGhhdCBtZWFucyBhbiBhdHRhY2tlciBjYW4gbWFrZSBJQSBmb3IgdGhlIGNvbm5lY3Rp b24gYXJiaXRyYXJ5IGhpZ2guIExpbWl0aW5nIHRoZSBJQSBwZXIgY29ubmVjdGlvbiBkb2VzIG5v dCBoZWxwIGVpdGhlciBpZiB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBwYXJ0aWVzIGp1c3Qg c2V0IHVwIGEgbmV3IGNvbm5lY3Rpb24uIFRoZSBvbmx5IHBvc3NpYmxlIHRoaW5nIHRvIGRvIGlz IGxpa2VseSB0byBsaW1pdCB0aGUgZm9yZ2VyeSBzdWNjZXNzIHByb2JhYmlsaXR5IHBlciBmb3Jn ZXJ5IGF0dGVtcHQuDQoNCg0KDQpJdCBzZWVtcyBxdWl0ZSBlYXN5IHRvIHNlZSBmcm9tIHRoZSBp bmVxdWFsaXRpZXMgd2hlbiByZWtleWluZyBsb3dlciB0aGUgYWR2YW50YWdlIGZvciB0aGUgY29u bmVjdGlvbiBhcyBhIHdob2xlLiBMb29raW5nIGF0IHRoZSB0aGUgc2luZ2xlLWtleSBpbmVxdWFs aXRpZXMuIElmIHRoZSBkb21pbmF0aW5nIHRlcm0gaW4gdGhlIGFkdmFudGFnZSBpdCBwcm9wb3J0 aW9uYWwgdG8gcV4yIG9yIHZeMiBpdCBpcyBiZW5lZmljaWFsIHRvIHJlLWtleSBhbHNvIGZvciBz bWFsbCB2IGFuZCBxLg0KDQpBRVMtR0NNIENBIDw9ICgocyArIHEgKyAxKV4yKSAvIDJeMTI5DQpB RVMtQ0NNIENBIDw9ICgybCAqIHEpXjIgLyAyXjEyOA0KQUVTLUNDTSBJQSA8PSB2IC8gMl4xMjgg KyAoMmwgKiAodiArIHEpKV4yIC8gMl4xMjgNCg0KSWYgdGhlIGFkdmFudGFnZSBpcyBwcm9wb3J0 aW9uYWwgdG8gcSBvciB2LCByZS1rZXlpbmcgZG9lcyBub3QgbG93ZXIgdGhlIGFkdmFudGFnZSBm b3IgdGhlIGNvbm5lY3Rpb24gYXMgYSB3aG9sZSBldmVuIGZvciBsYXJnZSB2IGFuZCBxOg0KDQpB RVMtR0NNIElBIDw9IDIgKiAodiAqIChsICsgMSkpIC8gMl4xMjgNCkNoYUNoYSAgQ0EgPD0gdiAq ICgoOCAqIGwpIC8gMl4xMDYpDQpDaGFDaGEgIElBIDw9IHYgKiAoKDggKiBsKSAvIDJeMTA2KQ0K DQpGb3IgQUVTLUNDTSB3aXRoIDY0LWJpdCB0YWdzLCB0aGUgYWR2YW50YWdlIGlzIGRvbWluYXRl ZCBieSB0aGUgdGVybSANCnYgLyAyXjY0IHdoZW4gdixxIGlzIHNtYWxsIGFuZCB0aGUgdGVybSAo MmwgKiAodiArIHEpKV4yIC8gMl4xMjggd2hlbiB2LHEgYXJlIGxhcmdlci4NCg0KQUVTLUNDTV84 IElBIDw9IHYgLyAyXjY0ICsgKDJsICogKHYgKyBxKSleMiAvIDJeMTI4DQoNCkFzc3VtaW5nIGw9 Ml44IGFuZCBsaW1pdHMgdiA9IHEgPSAyXjQwLCB0aGUgaW50ZWdyaXR5IGFkdmFudGFnZSBhZnRl ciAyXjQwIHBhY2thZ2VzIGlzIElBIDw9IDJeLTI0ICsgMl4tMjggd2hpY2ggaXMgdmVyeSBjbG9z ZSB0byB0aGUgYWR2YW50YWdlIElBID0gMl4tMjQgZm9yIGFuIGlkZWFsIDY0LWJpdCBNQUMgYWZ0 ZXIgMl40MCBmb3JnZXJ5IGF0dGVtcHRzLiBDQ01fOCBoYXMgbXVjaCB3b3JzZSBJQSB0aGFuIHRo ZSBvdGhlciBhbGdvcml0aG1zIGJlY2F1c2Ugb2YgaXQgdGFnIGxlbmd0aCwgYnV0IHJla2V5aW5n IGZyZXF1ZW50bHkgZG9lcyBub3QgaW1wcm92ZSBhcHBsaWNhdGlvbiBzZWN1cml0eS4NCg0KDQoN ClRvIHN1bW1hcml6ZToNCg0KLSBGb3IgR0NNIENBLCBDQ00gQ0EsIGFuZCBDQ00gSUEsIGNvdW50 ZXJzIGZvciB2IGFuZCBxIGFuZCByZWtleWluZyBkZWZpbml0ZWx5IG5lZWRzIHRvIGJlIG1hbmRh dGVkIHRvIGtlZXAgdGhlIHF1YWRyaWNseSBncm93aW5nIGFkdmFudGFnZSBib3VuZGVkLiBJIHRo aW5rIHRoZSBBRUFEIGxpbWl0IHdvcmsgaXMgZ3JlYXQgaW4gc2hvd2luZyB0aGUgbmVlZCBmb3Ig dGhpcy4gVGhhbmsgeW91IQ0KDQotIFRoZSBsaW1pdHMgaW4gdGhlIERMVFMgMS4zIGRyYWZ0IGFs c28gcHV0cyBjbGVhciBib3VuZHMgb24gQ0EgZm9yIHRoZSB3aG9sZSBjb25uZWN0aW9uLCBDQSBw ZXIgcHJvdGVjdGVkIG1lc3NhZ2UsIGFuZCBJQSBwZXIgZm9yZ2VyeSBhdHRlbXB0LCB3aGljaCBp cyBncmVhdC4gVGhlIENBIGFkdmFudGFnZSBmb3IgYW4gYXR0YWNrZXIgZm9yIHRoZSB3aG9sZSBj b25uZWN0aW9uIHZhcmllcyBxdWl0ZSBhIGxvdCBiZXR3ZWVuIHRoZSBhbGdvcml0aG1zLCBidXQg dGhhdCBpcyBvay4gVGhlIGxpbWl0cyBpbiBEVExTIDEuMyBkb2VzIG5vdCBsaW1pdCB0aGUgSUEg Zm9yIHRoZSB3aG9sZSBjb25uZWN0aW9uLg0KDQotIEkgdGhpbmsgdGhlIHByb2Nlc3MgdG8gcHV0 IGEgbGltaXQgb24gQ0EgYW5kIElBIGZvciBhIHNpbmdsZSBrZXkgZG9lcyBub3QgZ2l2ZSB0aGUg d2FudGVkIHJlc3VsdHMgZm9yIGEgc2VjdXJpdHkgcHJvdG9jb2wgd2l0aCBtYW55IGtleXMgcGVy IGNvbm5lY3Rpb24sIG1hbnkgY29ubmVjdGlvbiBwZXIgcGVlcnMsIGFuZCBhdHRhY2tlcnMgY2Fu IGZvcmNlIG5ldyBjb25uZWN0aW9ucy4gSXQgbWlnaHQgYmUgYmV0dGVyIHRvIGxvb2sgYXQgIm11 bHRpLWtleSIgc2VjdXJpdHkgaW52b2x2aW5nIGFsbCB0aGUga2V5cyBpbiB0aGUgY29ubmVjdGlv biBhbmQgY2FsY3VsYXRpbmcgQ0EvSUEgZm9yIGEgY29ubmVjdGlvbiB3aXRoIGEgZml4ZWQgbnVt YmVyIG9mIG1lc3NhZ2VzLiBUaGUgYmVzdCBhcHByb2FjaCBpcyBtaWdodCBob3dldmVyIGJlIHRv IGp1c3QgbG9vayBhdCAic2luZ2xlLWtleSIgc2VjdXJpdHkgYW5kIHNldCBtYXhpbXVtIGxpbWl0 cyBmb3IgQ0EgLyBxIGFuZCBJQSAvIHYgb3Igc29tZXRoaW5nIHNpbWlsYXIuIA0KDQotIFdoZW4g dXNpbmcgQ0NNXzgsIGZyZXF1ZW50IHJla2V5aW5nIGRvZXMgbm90IHNpZ25pZmljYW50bHkgaW1w cm92ZSBJQSBmb3IgYSBsb25nIGNvbm5lY3Rpb24uIFdoZW4gdiA8PCAyXjQwIGFuZCBxIDw8IDJe NDAgQ0NNXzggaXMgdmVyeSBjbG9zZSB0byBhbiBpZGVhbCA2NC1iaXQgTUFDLiBBbnkgNjQtYml0 IE1BQyBkb2VzIG9mIGNvdXJzZSBwcm92aWRlIG11Y2ggd29yc2UgSUEgdGhhbiBhIGdvb2QgMTI4 LWJpdCBNQUMuDQoNCi0gVmVyeSBmcmVxdWVudCByZWtleWluZyBzaG91bGQgYmUgcmVjb21tZW5k ZWQsIGJ1dCBtYXliZSBldmVuIG1vcmUgYXMgYSB3YXkgdG8gbGltaXQgdGhlIGVmZmVjdCBvZiBr ZXkgbGVhZ2FnZSB0aGVuIHRvIGxvd2VyIENBIGFuZCBJQS4gVGhpcyBwdXQgaGlnaGVyIHJlcXVp cmVtZW50cyAoZm9yd2FyZCBzZWNyZWN5LCBwb3N0LWNvbXByb21pc2Ugc2VjdXJpdHkpIG9uIHdo aWNoIHJlLWtleWluZyBtZWNoYW5pc20gdGhhdCBpcyB1c2VkLg0KDQotIEkgZG9uJ3Qgc2VlIGFu eSBuZWVkIGZvciBEVExTIDEuMyBhbmQgUVVJQyB0byBjaGFuZ2UgZXhjZXB0IG1heWJlIGJlaW5n IG1vcmUgYWxsb3dpbmcgdG8gQ0NNXzggZm9yIElvVCBhcHBsaWNhdGlvbnMuIEkgdGhpbmsgQ09S RSBzaG91bGQgaW50cm9kdWNlIGNvdW50ZXJzIGZvciB2IGFuZCBxIGFuZCByZWtleWluZywgYnV0 IHByb2JhYmx5IHVzZSBhIHNsaWdodGx5IGRpZmZlcmVudCBwcm9jZXNzLiBJIHNlZSBubyBuZWVk IHRvIGZyZXF1ZW50bHkgcmVrZXkgQ0NNXzguIENDTV84IGlzIGNsb3NlIHRvIHRoZSBpZGVhbCA2 NC1iaXQgTUFDIHVubGVzcyBmb3IgaGlnaCB2YWx1ZXMgb2YgdiBhbmQgcS4gQ0NNXzggaXMgb2sg YXMgbG9uZyBhcyA2NC1iaXQgTUFDcyBhcmUgYWNjZXB0YWJsZSwgd2hpY2ggSSB0aGluayB0aGV5 IGFyZSwgZXNwZWNpYWxseSBmb3IgY29uc3RyYWluZWQgSW9UIHJhZGlvLCB3aGVyZSBzZW5kaW5n IDJeNjQgcGFja2V0cyAoNC4zIGJpbGxpb24gbWVzc2FnZXMgcGVyIHNlY29uZCBmb3IgNjggeWVh cnMpIGlzIGluZmVhc2libGUuDQoNCkNoZWVycywNCkpvaG4NCg0K From nobody Mon Feb 22 06:28:13 2021 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 44EF23A0B3A; Mon, 22 Feb 2021 06:28:05 -0800 (PST) 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, 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, 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 8KaKakromamj; Mon, 22 Feb 2021 06:27:59 -0800 (PST) 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 96F193A0B91; Mon, 22 Feb 2021 06:27:58 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4Dkkzw5qVHzyWk; Mon, 22 Feb 2021 15:27:56 +0100 (CET) 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: Date: Mon, 22 Feb 2021 15:27:56 +0100 Cc: netmod@ietf.org X-Mao-Original-Outgoing-Id: 635696876.345477-c0bfc7c999841cb404045beae4649fdd Reply-To: "core@ietf.org WG (core@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: <63510607-74A6-4218-BE87-10EC6F4ACB38@tzi.org> References: To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] draft-ietf-core-comi-11 shepherd 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: Mon, 22 Feb 2021 14:28:11 -0000 Please note an interesting discussion over at netmod. Archived-At: = = and up. It seems we a converging to a conclusion that means that the table at = the top of page 14 in draft-ietf-core-comi-11.txt [1] is not wrong (it = would make certain updates of a YANG module a non-backwards compatible = change in the way we build URIs from that). [1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14 That said, maybe we still want to look at why uint and int coding are so = (unnecessarily?) different in their URL encodings. Gr=C3=BC=C3=9Fe, Carsten > On 2021-02-04, at 05:47, Carsten Bormann wrote: >=20 > In my shepherd review of draft-ietf-core-comi-11, I have found a few = points that probably need some WG action before we can submit this draft = to IESG. > (I also have submitted a PR addressing some nits, = https://github.com/core-wg/comi/pull/1 .) >=20 > Specifically: >=20 > # Major >=20 > *** 5: This whole section is rather disappointing. What does this > really do except for pointing at RFC 7959? Is there any > recommendation in how to work around the race condition? The > recommendation to use indefinite length is not solving any problem > (does not work except in very fortuitous cases). >=20 > *** 6.2.2 How does the pagination work, then? > This SHOULD is not actionable. >=20 > *** 7: This creates confusion between 4.01 and 4.03 >=20 > # Minor >=20 > *** 2.2: While it is not clear whether there will be a SID 0, the text > seems to imply that this would be encoded in the empty string. > Should it rather specify a single "A=E2=80=9D? >=20 > *** Appendix A: Updated to reference RFC 8949 (see PR). > Do we need a new module version after this edit? >=20 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 From nobody Mon Feb 22 06:47:43 2021 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 BB3F33A0DFE; Mon, 22 Feb 2021 06:47:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161400525271.10207.9301826478095210012@ietfa.amsl.com> Date: Mon, 22 Feb 2021 06:47:32 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-04-28 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, 22 Feb 2021 14:47:39 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-04-28 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m888a990760425271a1327f53c6714b07 From nobody Mon Feb 22 06:47:54 2021 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 6BC6C3A1228; Mon, 22 Feb 2021 06:47:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161400526340.18126.9381432738329045031@ietfa.amsl.com> Date: Mon, 22 Feb 2021 06:47:43 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-05-12 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, 22 Feb 2021 14:47:49 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-05-12 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mb2d62b1da561183acc59e83e93a5dae6 From nobody Mon Feb 22 07:01:14 2021 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 12FF03A1657; Mon, 22 Feb 2021 07:01:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161400606404.30216.2655499361584272818@ietfa.amsl.com> Date: Mon, 22 Feb 2021 07:01:04 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-05-26 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, 22 Feb 2021 15:01:10 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-05-26 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mba8c947cd147f3335a5455cfbcc067dc From nobody Mon Feb 22 07:01:26 2021 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 CAD3E3A1682; Mon, 22 Feb 2021 07:01:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161400607579.14888.10943439491595471406@ietfa.amsl.com> Date: Mon, 22 Feb 2021 07:01:15 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-06-09 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, 22 Feb 2021 15:01:21 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-06-09 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m39160e23c122b545abcd4e12f73da257 From nobody Mon Feb 22 07:01:31 2021 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 2D3143A1697; Mon, 22 Feb 2021 07:01:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161400608515.8010.719881914830772605@ietfa.amsl.com> Date: Mon, 22 Feb 2021 07:01:25 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-06-23 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, 22 Feb 2021 15:01:29 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-06-23 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m9a2d53595d20a6faffb464cfee95297e From nobody Mon Feb 22 07:01:56 2021 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 042843A1973; Mon, 22 Feb 2021 07:01:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161400609998.31325.5730916172717927897@ietfa.amsl.com> Date: Mon, 22 Feb 2021 07:01:40 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-07-07 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, 22 Feb 2021 15:01:46 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-07-07 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m9e7a5d60740a53d0694df4397a9cbe8c From nobody Mon Feb 22 08:45:24 2021 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 DE07F3A1DB1; Mon, 22 Feb 2021 08:45:19 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161401231987.27584.16703068935555652980@ietfa.amsl.com> Date: Mon, 22 Feb 2021 08:45:19 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-11.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: Mon, 22 Feb 2021 16:45:20 -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 : Group OSCORE - Secure Group Communication for CoAP Authors : Marco Tiloca Goeran Selander Francesca Palombini John Preuss Mattsson Jiye Park Filename : draft-ietf-core-oscore-groupcomm-11.txt Pages : 80 Date : 2021-02-22 Abstract: This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g. sent over IP multicast. In particular, the described approach defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 08:50:31 2021 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 649D83A1E25; Mon, 22 Feb 2021 08:50:25 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161401262536.16901.14863530937225963846@ietfa.amsl.com> Date: Mon, 22 Feb 2021 08:50:25 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-groupcomm-bis-03.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: Mon, 22 Feb 2021 16:50:27 -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 : Group Communication for the Constrained Application Protocol (CoAP) Authors : Esko Dijk Chonggang Wang Marco Tiloca Filename : draft-ietf-core-groupcomm-bis-03.txt Pages : 58 Date : 2021-02-22 Abstract: This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, using UDP/IP multicast as the underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource- constrained devices or networks. This document replaces RFC7390, while it updates RFC7252 and RFC7641. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 10:23:15 2021 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 22BDD3A1EBD; Mon, 22 Feb 2021 10:23:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161401819311.5486.2233693362223797570@ietfa.amsl.com> Date: Mon, 22 Feb 2021 10:23:13 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-27.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: Mon, 22 Feb 2021 18:23:13 -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 : CoRE Resource Directory Authors : Christian Amsüss Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-27.txt Pages : 88 Date : 2021-02-22 Abstract: In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-27.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 12:44:41 2021 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 F3A9F3A1FC0; Mon, 22 Feb 2021 12:44:40 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161402668094.25558.11946063639393319020@ietfa.amsl.com> Date: Mon, 22 Feb 2021 12:44:40 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dynlink-13.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: Mon, 22 Feb 2021 20:44:41 -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 : Dynamic Resource Linking for Constrained RESTful Environments Authors : Michael Koster Bilhanan Silverajan Filename : draft-ietf-core-dynlink-13.txt Pages : 26 Date : 2021-02-22 Abstract: This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252). This specification also defines Conditional Notification and Control Attributes that work with Link Bindings or with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at https://github.com/core- wg/dynlink The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dynlink-13 https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 15:21:52 2021 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 246273A2180; Mon, 22 Feb 2021 15:21:51 -0800 (PST) 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.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161403611110.6110.17495851776976239078@ietfa.amsl.com> Date: Mon, 22 Feb 2021 15:21:51 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-11.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: Mon, 22 Feb 2021 23:21:51 -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 : Uniform Resource Names for Device Identifiers Authors : Jari Arkko Cullen Jennings Zach Shelby Filename : draft-ietf-core-dev-urn-11.txt Pages : 21 Date : 2021-02-22 Abstract: This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be passed along in applications that need the information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dev-urn-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dev-urn-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 15:23:48 2021 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 BE26C3A21DD for ; Mon, 22 Feb 2021 15:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)" header.d=gundogan.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83DhODlj-diG for ; Mon, 22 Feb 2021 15:23:39 -0800 (PST) Received: from mail.localdomain (trantor.gundogan.net [37.120.167.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0E33A21BB for ; Mon, 22 Feb 2021 15:23:38 -0800 (PST) Received: from localhost (unknown [84.242.29.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.localdomain (Postfix) with ESMTPSA id 3BA623C73A for ; Tue, 23 Feb 2021 00:01:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gundogan.net; s=201712; t=1614034917; bh=jBqt+D1j6JzREVxbv4+v67GxRU+lj66vYF6VqCFN4Ow=; h=References:From:To:Subject:Date:From; b=jFVWNa22uZBOeDo/kReKWM+LfIRHOPiLjBbeBhbynVW5rrY5KU+j8IjTZBTjFFuMi ONSXVmUBxedmAYCK0itGWPcYTZjBt/qLEQ/7rgwDq/vNEb5LkYxVL56fuZ0x4RY039 fNbjvFGU3XQoZ7bL1FIuAl1422w06hOVvZiHxtO8CPJvdastuJLrg+U/6XU/muLqiZ YHyJYxKA6AbJlPDYPDkLrNe5HWvjRDUa6TEVos3ZtcZvIsR0+4WNaW5QGV1PIZfM6g TIu7KKGoz2LN5sLQlO5pYwhE2Ov+qo93O6fmwKiLRdO/grS5icpP0bv5QbIWZDmZw3 5elL+EpoxBrJg== References: <161403502389.25152.13184178509630896225@ietfa.amsl.com> User-agent: mu4e 1.4.15; emacs 28.0.50 From: Cenk =?utf-8?B?R8O8bmRvxJ9hbg==?= To: core@ietf.org Date: Tue, 23 Feb 2021 00:23:36 +0100 Message-ID: <877dmzit53.fsf@gundogan.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [core] Fwd: New Version Notification for draft-gundogan-core-icncoap-00.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, 22 Feb 2021 23:23:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE WG, for quite some time, we have been investigating information-centric networking (ICN) approaches (mainly CCNx [1], NDN [2]) for use in constrained IoT setups. ICN deployments reveal synergistic effects that increase the reliability in low-power, lossy networks and reduce network resource demands due to their (i) stateful forwarding fabric, (ii) on-path caching, (iii) hop-wise retransmissions, and (iv) content object security properties. While we formerly argued for an IoT based on CCNx or NDN, we are now revisiting another idea. We teamed up with Christian Ams=C3=BCss and discovered that CoAP already supports many features to construct an IoT of data-centric nature; and it replicates the very same ICN performance benefits [3,4] using a pure CoAP deployment with its proxy, caching, and OSCORE capabilities. We regularly report our findings to the ICN community (e.g., at ICNRG [5]) and we think that this particular work might also be of interest to CoRE. The attached -00 draft is a condensed rundown on the topic .. and if there is interest, then we would gladly discuss more on the mailing list, or in form of a presentation in a next meeting slot; if agenda permits. Cheers, Cenk G=C3=BCndo=C4=9Fan [1] https://tools.ietf.org/html/rfc8569 [2] https://named-data.net/project/ [3] https://ieeexplore.ieee.org/document/9142731 [4] https://dl.acm.org/doi/10.1145/3405656.3418718 [5] https://datatracker.ietf.org/rg/icnrg/about/ On Tue, Feb 23 2021 at 00:03 +0100, internet-drafts@ietf.org wrote: > A new version of I-D, draft-gundogan-core-icncoap-00.txt > has been successfully submitted by =3D?utf-8?b?Q2VuayBHw7xuZG/En2Fu?=3D a= nd posted to the > IETF repository. > > Name: draft-gundogan-core-icncoap > Revision: 00 > Title: A Data-centric Deployment Option for CoAP > Document date: 2021-02-22 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/archive/id/draft-gundogan-core-icnco= ap-00.txt > Status: https://datatracker.ietf.org/doc/draft-gundogan-core-icnc= oap/ > Html: https://www.ietf.org/archive/id/draft-gundogan-core-icnco= ap-00.html > Htmlized: https://tools.ietf.org/html/draft-gundogan-core-icncoap-00 > > > Abstract: > The information-centric networking (ICN) paradigm offers replication > of autonomously verifiable content throughout a network, in which > content is bound to names instead of hosts. This has proven > beneficial in particular for the constrained IoT. Several > approaches, the most prominent of which being Content-Centric > Networking (CCNx) and Named-Data Networking (NDN), propose access to > named content directly on the network layer. Independently, the CoRe > WG developed mechanisms that support autonomous content processing, > on-path caching, and content object security using CoAP proxies and > OSCORE. > > This document describes a data-centric deployment option using > standard CoAP features to replicate information-centric properties > and benefits to the host-centric IoT world. > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat =2D-=20 Cenk G=C3=BCndo=C4=9Fan Hamburg University of Applied Sciences Dept. of Computer Science / Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49 40 42875 - 8426 Mail: cenk.guendogan@haw-hamburg.de Web: https://www.inet.haw-hamburg.de/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO3dMsPVVAdvZ+Oc2o9vC90TUhNIFAmA0PPgACgkQo9vC90TU hNL1Yg//cNXCOBZxvYXUmMteJ+ZqBgg3rZ9b51o9y3wlBwEo6gfOR1xWQl6+amuM evn2AKIoV1CWSIc3DKe3ox7ELaHLaqSQibONwnIMsynwVF02hzvoE9pl0II+FMRR 5BZy5mFo4uzu8x/XFUXFEaqhzTh3D3nXad2ZMhstYgq+e4IPvXsn7XU0k5mBB7ev yBCm95VG0eXP0WK3YWhqjk7AQglu/cG86w84avEBjiebsRuCXtR/oLkUkwaVdx2M 672ilgCyOEcfFRmjny+LPxObhdDJwCBVqjZPb2U9wmWTJuFdpV/bjffiH4S1Pbw8 pXE8eiiorvK2ryJPQuCa5GwZkAU7jvHdeQuLZS+CxZqtnCrG6ehrq2YS6ru8oahX 8Yx3dv/AciFOW9ZsdlgIj6pc1X3KYrCHePWSdFt+8IWT6dcSa7B61HH33Vj/P1Od t100N+U0IdDVLzwiA8S+qbRpA9Q9bBcvIiMTKBBojMU9iF+tLvPudmmU/s4Z/sIG RD2i+Mf2OvwZBwrylldJxUc6aQFmvoFXE0SFmTKrsFf/6TI1/uILBAGSNQjtZV9G U1sLjSJnuGC4xaBqOc0SQRKQCFiDDMs4qrGbB3XnyAKBo1Tf1pN8O3L6nDiiCGFj PiagLU64Az7juJfXnglGUBNdH2Pm4LUwqvEmKDpeURtasPtKlig= =0tgx -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 22 15:55:48 2021 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 547243A2264; Mon, 22 Feb 2021 15:55:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Marco Tiloca , The IESG , barryleiba@gmail.com, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-dev-urn@ietf.org, marco.tiloca@ri.se, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161403814032.348.10466311283180200899@ietfa.amsl.com> Date: Mon, 22 Feb 2021 15:55:40 -0800 Archived-At: Subject: [core] Protocol Action: 'Uniform Resource Names for Device Identifiers' to Proposed Standard (draft-ietf-core-dev-urn-11.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: Mon, 22 Feb 2021 23:55:47 -0000 The IESG has approved the following document: - 'Uniform Resource Names for Device Identifiers' (draft-ietf-core-dev-urn-11.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ Technical Summary The document defines a Uniform Resource Name (URN) namespace, to express device URN-based identifiers for HW devices. Relevant target applications are sensor data streams and storage, smart object systems, and equipment inventories. The device URN is recommended especially for constrained environments. On top of the "DEV" URN identifier type and its hierarchically structured syntax, the document defines a number of subtypes, as affecting the exact identifier assignment. Defined subtypes support device URNs that reflect: built-in EUI-64, MAC-48 and EUI-48 MAC addresses; 1-Wire proprietary identifiers; organization-specific identifiers, possibly including product class and serial number. Working Group Summary and Document Quality The document has been discussed on multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need. This document is expected to be referenced by other organizations. Personnel Document Shepherd: Marco Tiloca Area Director: Barry Leiba From nobody Wed Feb 24 04:40:10 2021 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 EB52D3A14FE; Wed, 24 Feb 2021 04:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, 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 6taukmkTfdl8; Wed, 24 Feb 2021 04:40:07 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2069.outbound.protection.outlook.com [40.107.21.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A514C3A1516; Wed, 24 Feb 2021 04:40:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jtCqWIv4FNYrS2VpUn499a0tPmbPgOqezNYUI7vadikKPiXUi5piqEyDtheY1LNPiq6uHvzUlPyQ67yyyuW4FFHOSWIz+Xs46A8cNO7LiVCvr6dpeGf8K5ph5pcojjqUbS/DyeKvw+bxWTOxAX4VAVrCIrGRLPVMakyzpxlUi1gp8y3ModlmASOnbTLxFCSUW7IQGVR1Mt5pirN0eVE53kWS3Wtz5hc4guN5wPVJVa9xp/OQp2KxruYb8joKN5W8w2VSzfVBdTzEbxbG2TuN4UVTFj7k8xWX8UWIK/o/ZCt+qf8HkLuEFt+TWlso0W7jXFbZzr4A6wlX/+UmWSC6jw== 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=JNnFrnK0oU7lFhvME9LPSKH/ZPVOsIr6QeLzHeyibwI=; b=cHDOswKkghlWzXeKwWYF/JRnGEnZMRkAMUy8yBKO/Dcq+HvqG6M/Vroxs5BGm1Bmc1kYbxePPMd/UqJGZk60MfxaXR7rHM7pIjKUwQ84TelkBrKjmjQHCMQkYdk76L0gwNwbqW4BQF73uRmcdEaS8WgYGHIZnrR4tnE9Lbqt7h6rb2ske80Axvx9UuLASCIEdn+BPhRg2J1D5Gw4BVePy9UvnQcgNptNLcrmgjy1etW42dttYdWCc71J+a1w1ZNBqUBXn/urKwdKdFn30XnHWwoJG7wI5tBP/oUuZQtZvrlNJN07AlfCnEnP6F/PK6wLfjzQNN544mDweJIVujLrwg== 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=JNnFrnK0oU7lFhvME9LPSKH/ZPVOsIr6QeLzHeyibwI=; b=Ob9kPXxaQczHhFlE5Wh0MLUlbhPaoT5n4C8VZlxvWUVqY+qf7cLFiEY/OHUYLorh3NhhzzU5NDb+DRvKmv2So+iGrEKGaNiA6MarVeN/0f0nv/RaWq1DbnlUypWZUGTYEUCWIAitPX5bBPmVmtUgXBcmuR3V0K2ASW4LCE4keGs= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR07MB6478.eurprd07.prod.outlook.com (2603:10a6:800:13c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.8; Wed, 24 Feb 2021 12:40:03 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::c5e9:fb9a:e4a0:e7a4]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::c5e9:fb9a:e4a0:e7a4%5]) with mapi id 15.20.3890.018; Wed, 24 Feb 2021 12:40:03 +0000 From: Francesca Palombini To: "draft-ietf-core-sid@ietf.org" CC: "core@ietf.org" , "core-chairs@ietf.org" , "barryleiba@computer.org" Thread-Topic: Review of draft-ietf-core-sid-15 Thread-Index: AQHXCqos5zhnUNLZ50aJmGO0QhI9xg== Date: Wed, 24 Feb 2021 12:40:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:c100:2419:35d:8efa:cace] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 20505f50-fa7f-4fa2-8063-08d8d8c14ed0 x-ms-traffictypediagnostic: VI1PR07MB6478: x-ms-exchange-minimumurldomainage: rfc-editor.org#8321 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FRnz/tZMeOqKiy5dNZa50ALRcAYjG7sDeoFsSkYC8Rh7SzAR+6UH9ksYa76nYm9y2to333dyWsX8PfMYkKjG43ul3lxuwyNOudI/ZZFYUfLE2eXO60OoR0UtNHwlYhWbN59YoW6IOv7X3D6HPyHrJ3xnY8DPf/YBNLRkYMg2WI6HgjCsJ07nHgy1xNYcShPBGS9IF5TC7pcPHxi5lfIUwGLfN2AvOuPD317XiWRjNOkuxLdQ6Fpqz62NzaVDqpanXD4+x+egs46oaWm4hOYuK3HgtXyTRqH92eiy5BVsy4ixcHCsSzp9X5d2GyvQScy8QnkE1AlLmeJqhNuMcSLaSW7BkRX3Bcr31V6o00GLoeH35zXlTKFSoO8YUBen/QiQlbFODOp4vEBJPlhGTuzCt/3Am2MdqmeN/y9iABelBF68l2H2kZ3DupMaOyA5m3LzVMS0dnGBNT6/ufudGOVTAk8biS0srpqqU87Huz85258PQrKqz6MHL8MByJbzQaM+Kb7oYVYdZ9AjD4Ph/M+LtwsX1B4gxl2v7UZu9ZAaVd6vCtc5WHVc0aQ3yjw/3jAKoF6/D2OOk4J5GNIdX+dfOv7BBUWZBC8wSflJd9qGYthhUkHestHwtHfJkX6dg7x+gHhye8L91ypPcEtcAn/YTq5c1+C05Oh4XxAl3DH6f9E= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(376002)(396003)(39860400002)(316002)(2906002)(6506007)(6486002)(64756008)(66556008)(4326008)(66446008)(86362001)(6916009)(6512007)(54906003)(44832011)(5660300002)(8936002)(186003)(83380400001)(66476007)(966005)(71200400001)(8676002)(66946007)(478600001)(91956017)(2616005)(33656002)(36756003)(76116006)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?dFQ1TUgwWE5ZV1c3WFF3VEhjakRuRjR4QllYd1RkaFJ5dGNRWndydWh3M21Y?= =?utf-8?B?QTBRRHpLc0VTeW9iSkNrMlJaYUFaaFBGUjRVdnBzWWdKQU5MN2ZWNU9xTW8w?= =?utf-8?B?b08vT2VoeFVUODAycE13RkZtLzFIZk9KaUdWbFg0Ly9pbVlCK2NveFA2SjhO?= =?utf-8?B?dkgwUUhVRTJybmlaRGFXWElTZlFGcnBXSnFsRzNQUWRkMnVlb1pkWjRUVnJU?= =?utf-8?B?WXFUSlFkZ0h6UitJcTZlV3lTdTBRRy9xT25SQWpNWGxmajFoT0pONVBLU3dk?= =?utf-8?B?eE5QeTVxMFY5aGNBRTRxT0lQVmFEeEdyNktOZ2RzL05YQ3Y0YXc1UEV4Wk9u?= =?utf-8?B?MVRwMm5DMnRjUGZqckZsZVNFLzBwSVFPUlZndlUrVzlTZzAxcXZnVm05OGNn?= =?utf-8?B?UWRzN0FVTytoR0FYRXMrM2pySSsyZmVPUlR1VGdZaXZLVTZBR0dOVU5pNCs5?= =?utf-8?B?TDdZZDNPSnUwN05NMm4zSkF6L0dGUVVTc2lEN1ZCVXdWOUpYNXlMYkxCM1lS?= =?utf-8?B?N0VOOWhRWW5UczQ5bm9POUc0eTRSZjZDdng0blhVYXFycjlqUk91UTNYd3M1?= =?utf-8?B?NVhOYUZ2SCs2NG1ySzEyY054dU1tZVo4V2tIaTZZRXVub0t1eFJ1MlBleGg3?= =?utf-8?B?ZWc4Q2w5aFI4MEFWUlM3K1JSaXVadnNjd0JWTmtncjNGUEFISENYcnhJZ3hp?= =?utf-8?B?bEh1NGtsa2FRWE5HQ3JxYWxsUWdyTHRuajMzVHlqZFkxQVNTVzZwMEVtd01n?= =?utf-8?B?U21tSCt1MlpTZ1MyQ2diRWtJWWZ1aGthaS9RaUV6VFFWUUZ5elBMRzRINy82?= =?utf-8?B?WXkrNnUxR2x2L1dxMmI1cXpLbGdwcFUxQ3JXQ3ByOThra1c2cDRNWmRockJr?= =?utf-8?B?b3VDcG1pV2xxVFpFSlkrMTB2bEdhU3EyNmtDemJRaVBPWDBZaGx3RFd2by9n?= =?utf-8?B?dzdOUU1HbkluQnpRUWNGVGFxL05FdGEzWmNHNkVmNVUyNnpZWlh4T0dFdHhm?= =?utf-8?B?cDVwSVF3M1BoZlBnUi8yeGpvVXlXZ2pSdW11ZUJvclUxY3MraHJBQjNvZVd1?= =?utf-8?B?T3hrWGxtbFAveVB4bUJNU0xucFY1c3NZclRHTVJMcDBCSXBIUkE1NTNjWUtr?= =?utf-8?B?TGFNVGtNS3ZQTTcxeGY5RTN3ek5EdlZhWklTZ1NtdHBLdDRkSWtuWDNTOUYr?= =?utf-8?B?SmNtenZydk5OZDUxMXN0bFJFeFFDTmdSYndxemFkaVlqT3k5dC9uQy9SdHds?= =?utf-8?B?UWFCekkydzNJdkN5d2NYdDdoUWpLZzB0SklBcnU5YnpWd1liL3JtOHV4WnNa?= =?utf-8?B?Vzd1Q3AxM3ZMNjk0dmR0cUdjQnFtOWdGZHFuOEdzOWZNWXhRSWR3VFc4NnNW?= =?utf-8?B?eFptM002eHVyd0Z4UlpETnVpK2dQM0dzNjhFM2YvWWFaSXdieEhRTmdhTEpC?= =?utf-8?B?UEpERmZqdy9EK1VzZUljL3dFb3ZVWk1UaXVmZVlBODNPVFlYazYvNHdBM2VR?= =?utf-8?B?OVVnY0ZrN3I0VWFHY29tcXZuRUJSRk1tTDR0VnB3cThYVnNXNXhLT2NrYW1T?= =?utf-8?B?cUo1VXBRem5NRTcza0tFaTYvKytXc2tUcnczaE9URENpZWpsUVJuOGM2VERo?= =?utf-8?B?QmtZeUJWcWN6UTFRS0tVeEQwa3hyamVhYlZnT0VGZEZVYXJabVhYa09tZHJ5?= =?utf-8?B?WTRjUlZ0R2lsSVArUmxNVElYYjc2bWpNN25NUjNsK2JWVFcwQjhkaXZJOU9x?= =?utf-8?B?WG5aWXJaRC92bm9rRlVLSkgyMWtpUkxzTXlEMjJRRFptT2VueWpyS1NIdC9s?= =?utf-8?B?MGhBTUxaQzBtM093S25FNm9Sbk81U0ZwZVc1VkEwZWFmdE9MSVhFdEx1eFBF?= =?utf-8?B?R28zQ2FTQXFyRXMyS2MwdlNDMzhtYzFVSEJWM3dvVzUzM0E9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5009B620DC6981458A67501062AADE8C@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: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20505f50-fa7f-4fa2-8063-08d8d8c14ed0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2021 12:40:03.4310 (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: bgIgbwc+Jg7w+2vOHAuAQMHJX0zuQCs/PDyyncxbKSUAvzZz7klFpVQK9bDB/iTsP4UB5fhnqYSu0gqxaUaK9jJ1XAqsfqzWUFG6kmRFOlNP/CTtD9l2P7W/HojA0TJU X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6478 Archived-At: Subject: [core] Review of draft-ietf-core-sid-15 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, 24 Feb 2021 12:40:09 -0000 VGhhbmtzIGZvciB0aGUgd29yayBvbiB0aGlzIGRvY3VtZW50LiBJIGhhdmUgcmV2aWV3ZWQgaXQg YW5kIGhhdmUgc29tZSBjb21tZW50cy4gUGxlYXNlIGhhbmRsZSB0aGVzZSBjb21tZW50cyB0b2dl dGhlciB3aXRoIHRoZSBMYXN0IENhbGwgY29tbWVudHMuDQoNCkNoYWlyczogSSBiZWxpZXZlIGl0 IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gcmVxdWVzdCBhIHJldmlldyBmcm9tIFlBTkcgRG9jdG9ycyBm b3IgdGhpcyBkb2N1bWVudC4gTGV0IG1lIGtub3cgaWYgeW91IG5lZWQgaGVscCBzZXR0aW5nIHRo YXQgdXAuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQo9PQ0KDQpTZWN0aW9uIDE6DQoNCiAgIFNJ RHMgYXJlIGFzc2lnbmVkIHBlcm1hbmVudGx5LCBpdGVtcyBpbnRyb2R1Y2VkIGJ5IGEgbmV3IHJl dmlzaW9uIG9mDQogICBhIFlBTkcgbW9kdWxlIGFyZSBhZGRlZCB0byB0aGUgbGlzdCBvZiBTSURz IGFscmVhZHkgYXNzaWduZWQuICBJZiB0aGUNCiAgIG1lYW5pbmcgb2YgYW4gaXRlbSBjaGFuZ2Vz LCBmb3IgZXhhbXBsZSBhcyBhIHJlc3VsdCBmcm9tIGEgbm9uLQ0KICAgYmFja3dhcmQgY29tcGF0 aWJsZSB1cGRhdGUgb2YgdGhlIFlBTkcgbW9kdWxlLCBhIG5ldyBTSUQgc2hvdWxkIGJlDQogICBh c3NpZ25lZCB0byBpdC4NCg0Kc2hvdWxkIG9yIFNIT1VMRD8gSW4gZ2VuZXJhbCBpdCBpcyBub3Qg Y2xlYXIgdG8gbWUgd2hlbiBpdCBtYWtlcyBzZW5zZSBmb3IgU0lEIG5lZWQgdG8gYmUgcmUtcmVn aXN0ZXJlZCBhbmQgd2hlbiB0aGV5IGRvbid0LCBtYXliZSBzb21lIGV4YW1wbGVzIHdvdWxkIGJl IHVzZWZ1bC4NCg0KPT0NCg0KU2VjdGlvbiAzOg0KDQogICBFYWNoIHRpbWUgYSBZQU5HIG1vZHVs ZSBvciBvbmUgb2YgaXRzIGltcG9ydGVkIG1vZHVsZShzKSBvciBpbmNsdWRlZA0KICAgc3ViLW1v ZHVsZShzKSBpcyB1cGRhdGVkLCBhIG5ldyAiLnNpZCIgZmlsZSBNQVkgbmVlZCB0byBiZSBjcmVh dGVkLg0KDQpNYXliZSBzL01BWSBuZWVkIHRvL01BWS4gSSBhc3N1bWUgdGhpcyBpcyBhcHBsaWNh dGlvbiBzcGVjaWZpYyBpZiB0aGUgbmV3IC5zaWQgZmlsZSBpcyBjcmVhdGVkIG9yIG5vdCwgc28g eW91IGFyZSBsZWF2aW5nIGl0IHNvbWV3aGF0IG9wdGlvbmFsLCBpcyB0aGF0IGNvcnJlY3Q/IE1p Z2h0IGJlIGdvb2QgdG8gY2xhcmlmeS4NCg0KPT0NCg0KU2VjdGlvbiA3OiBJQU5BIGlzIGdvaW5n IHRvIGFzayB3aGVyZSB0byBjcmVhdGUgdGhlIHJlZ2lzdHJpZXMuIENvdWxkIHRoaXMgYmUgdW5k ZXIgeWFuZy1wYXJhbWV0ZXJzIG9yIGRvZXMgaXQgbmVlZCBhIG5ldyByZWdpc3RyeT8NCg0KPT0N Cg0KU2VjdGlvbiA3LjQ6IEJlY2F1c2UgdGhlIHBvbGljeSBpcyBleHBlcnQgcmV2aWV3LCBJIHdv bmRlciBpZiBhIGNoYW5nZSBjb250cm9sbGVyIGZpZWxkIHNob3VsZCBiZSBhZGRlZCAoc2VlIFJG QyA4MTI2KQ0KDQogICBXaGVuIGNyZWF0aW5nIGEgbmV3IHJlZ2lzdHJ5IHdpdGggRXhwZXJ0IFJl dmlldyBhcyB0aGUgcmVnaXN0cmF0aW9uDQogICBwb2xpY3ksIGluIGFkZGl0aW9uIHRvIHRoZSBj b250YWN0IHBlcnNvbiBmaWVsZCBvciByZWZlcmVuY2UsIHRoZQ0KICAgcmVnaXN0cnkgc2hvdWxk IGNvbnRhaW4gYSBmaWVsZCBmb3IgY2hhbmdlIGNvbnRyb2xsZXIuICBIYXZpbmcgYQ0KICAgY2hh bmdlIGNvbnRyb2xsZXIgZm9yIGVhY2ggZW50cnkgZm9yIHRoZXNlIHR5cGVzIG9mIHJlZ2lzdHJh dGlvbnMNCiAgIG1ha2VzIGF1dGhvcml6YXRpb24gb2YgZnV0dXJlIG1vZGlmaWNhdGlvbnMgbW9y ZSBjbGVhci4NCg0KPT0NCg0KU2VjdGlvbiA3LjUuMyBJbmNsdWRlcyBpbml0aWFsIGVudHJpZXMg Zm9yIHRoZSByZWdpc3RyeSB0aGF0IGFyZSBub3QgY29uc2lzdGVudCB3aXRoIHRoZSBndWlkZWxp bmU6IA0KDQorICAiRXhwZXJ0IFJldmlldyIgW1JGQzgxMjZdIGluIGNhc2UgdGhlICIuc2lkIiBm aWxlIGNvbWVzIGZyb20NCiAgICAgICAgICAgIGEgWUFORyBtb2R1bGUgZnJvbSBhbiBleGlzdGlu ZyBSRkMsIG9yDQoNCnNpbmNlIHNvbWUgb2YgdGhlc2UgcG9pbnRzIGFyZSByZWdpc3RlcmVkIGZy b20gZHJhZnRzLiBTaG91bGQgdGhlIFdHIGRvIGVhcmx5IGFsbG9jYXRpb24gb2YgdGhvc2U/DQoN Cj09DQoNCk5pdHMNCg0KLSBleHBhbmQgYWNyb255bXMgb24gZmlyc3QgdXNlICggZS5nLiBORVRD T05GLCBSUEMsIHNlZSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2 LmV4cGFuc2lvbi50eHQgKQ0KDQo= From nobody Wed Feb 24 04:41:28 2021 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 BB68E3A1517; Wed, 24 Feb 2021 04:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, 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 i6yBCmEw7JtF; Wed, 24 Feb 2021 04:41:25 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30062.outbound.protection.outlook.com [40.107.3.62]) (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 F099A3A1516; Wed, 24 Feb 2021 04:41:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KrDDRWp+buN0ZcR9oPXihdg6EbrEd4l3C8RuTucGGJqiUtb8grbLSHLXV+aeCeyrH5500GeHuVJrgkn10HwHNbxQ1LswpnRKVccr43Bk2T4CfoF1qUEpSArbcy7sCDl/HSEVl8I1o6jQIHmoFoCAMuPqnejoIwtr9MoaCZnYHExvN1KbRqDzSK1kex9uVvmAgqFV8z9usK7aOxfE4iHC1Q2GbP/zdzNctA2lAOarwgCxl3iNDUluAkGBIDuAWrHmZtVSwnGSm06g/samTALMmg8SoIbMMyuHa0hv1AsxDIQbpOuzBXDEmO89RubkE7r/TdZB4vq0CXJjBJuEPySGHQ== 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=B/uxp9esruQOVVKyGPSUvF6cIFLA0X4rYUp+Eg27ocU=; b=S5f3RMeNG/ge3wFzq6I+r8olSTbfMtGLl2dZTR1K2xILfg6J4AVjVklhJoGePSJqy6I7rvT7UddsP4+moMdln0qvZcmyh9487UK4RulXzs9XVoXCvfDXc8NZyW4+FHE/HChOOHWpOT6Ijnyzi+N9l3fSUHgiC5NX517PGbvu+z8M3L6QQAo9HiQ6oL7NLUM13sbQWU8isJ5a+XVUgQBzAsfX2MOKOK5gJKHNkfk2WB9A4WBc1B1xIl38/YjeWr/LmhXBkgTFHVLo8pcp0hx5M84cCxMJGkdV1h2P49gwq1t0lZmnXaPhg2vt2udfcZdMnvgmddMHRx9WykuHznM6bg== 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=B/uxp9esruQOVVKyGPSUvF6cIFLA0X4rYUp+Eg27ocU=; b=kkcrR+ppdxIgSFpZXCO03OoTcxwAz707WLbVGxOIxGu1uRsqZfoWotUibRWaGi88CF/Sev6b69NAIY62z6+eYbZrzskLqIFDtMg1YOsWPGB6Yvgwlcg9zFYJ25Otm0VFzTXJNDjSrjaD8XUmzaG9PGtp0pAdWOTQXbaQ5rYjAoE= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR0701MB7022.eurprd07.prod.outlook.com (2603:10a6:800:17e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.14; Wed, 24 Feb 2021 12:41:23 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::c5e9:fb9a:e4a0:e7a4]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::c5e9:fb9a:e4a0:e7a4%5]) with mapi id 15.20.3890.018; Wed, 24 Feb 2021 12:41:23 +0000 From: Francesca Palombini To: "draft-ietf-core-yang-cbor@ietf.org" CC: "core@ietf.org" , "core-chairs@ietf.org" , "barryleiba@computer.org" Thread-Topic: Review of draft-ietf-core-yang-cbor-15 Thread-Index: AQHXCqpbWqAoYRZiFki+vT40wc8LMw== Date: Wed, 24 Feb 2021 12:41:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:c100:2419:35d:8efa:cace] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14f80e43-92ab-47ec-2c8e-08d8d8c17e36 x-ms-traffictypediagnostic: VI1PR0701MB7022: x-ms-exchange-minimumurldomainage: rfc-editor.org#8321 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: IdHXX1+WhLaXVZSYYMaX17D6HjJFHBoIlp7DYUVUsVvKviXObdurmQ2WT14Ksg6Cc9z9UdJb2mI5Xb8bikl2MYC5aCCuOQBZrYddE+vZr/kJQY0ssnIOsrV2DYR27I5XFQ5+ZJmwCx818VKRk11MD8mFD1Jc8cBQrNvtZ3GlglV22k5IUkBL7TTo+m02htuh3U6r7CanylB5bYwvaaT/FX8aJH7LIk0ikRR3i9Ff5i3QVkh+kceSRV0aUeq3jFC917BGgmC24yqxEMgBHuWmz/c1LZfQj74Q7/GX/hXyYIDw/pTJw3jS7rWK8V7N7OTi+mjj93X3jkJo5D07Y8WkIGwyPFieIQpih0X6QRrQ3PXicnBATrWMR0Ptyk12bxzyOuF9WrAn5dcFBayNjCGvStZQKEcPx7AiMaVbBdsz88sAPeejBa5M5mZRpxyJM4Zn4qcv81nl2yIckfUdqkrRyFMTjXjAdSp3lss7LR41fFE9Si0HwqeFjiQ0ZB195iTz/Be30IO2WcfHFFWoFS+DDe2wIIInc02tH2egG2XmP99WaNBH5geYsCvaSrq485HosWzDQnUxZMgZgN4lKWUDFGOXNd+HNuY0yahV/6cNi3Q/muBFH7RrsZJb8ChHiPFkYqeMFN8gsPl4fjsupZo8kWmY91zXJbVDfyj/R6DILp0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(396003)(376002)(136003)(39860400002)(8676002)(54906003)(64756008)(186003)(6916009)(316002)(6486002)(33656002)(66556008)(91956017)(966005)(66476007)(86362001)(5660300002)(4326008)(6512007)(66446008)(8936002)(2616005)(478600001)(76116006)(66946007)(83380400001)(36756003)(6506007)(44832011)(2906002)(71200400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?c3NCSEN4ZnpmL0ZqaHJ3Y2V2UjNiZUZpRmVyTSs0VEoxQjhXUElneFR6SnJT?= =?utf-8?B?MFRJRDhYVUZpOU1jRkVYUm5qa2RIa0MxelJQMHUvd0MyVDZSQVhFckdraitM?= =?utf-8?B?VWNBenFjYWhlcWNnclBJaFdXY250bEV6bWZHMHoybWppZWpQeUtlSUxaelVV?= =?utf-8?B?T2YvcndxYmdaZDdyMVA2bXNFZ0NuUm1oWlhhWlROVDh1ZW54SUQ3MlBwM0gr?= =?utf-8?B?am94cENYd0FYc3RRVGo3d2JXbG8rYjQ0d3ZseWtNY3Q3cUF5WkJtSks1RVA3?= =?utf-8?B?LzJQNHlmSXp3aWRNY1MxdWdtY0tQZThMR0tBaVJmKzQ4NjQ5RldIVWYzMEdG?= =?utf-8?B?MjlRT0JQczV0RkQwM2dKL1JFM2VRKzVwb2QxalVXam5qanF2RUN0S28wZXdI?= =?utf-8?B?NXdDK3UvS25IMUhYTUR5TFN3L2lSeC9uQ3FjU0M0WlNrSGJ3c0dScEg4WHBH?= =?utf-8?B?WTFIOGNHdVpZSUlQRTR0S0N3MjZ3SzdJcVpVS0xWU29PemhXdUhCTnJDbmdM?= =?utf-8?B?M2QvTkRrTlFmVnJnMDFpcHV1Qzl5STNXZmhDWE1jMmp3U2JCZjdKNFJES3pP?= =?utf-8?B?bWRKVHVZRkpCNFFlNjI3dW1jL0U2dnVLN0JZMmwyNDloNjd6aXEyWEZWVDU2?= =?utf-8?B?M1c2ZHJGSHJzM1RzVGUzTWxqaitKT3RVYlBlQVVWU0RUaFdpYUdWZW00VDlo?= =?utf-8?B?ZnhWVlpQTTRQS0wrNXh6RnVFYWVuRUlHTThWN3R6UDROWUNKSDBlL0RleWRX?= =?utf-8?B?L2lOR2lpNzV3ZlRzaHJQK1hLeVp1bHNZbllVUHc5NUZYaUFpRndhYWU0Skxy?= =?utf-8?B?ZGN4N255REpFcmFDbEt4alNsQUFCcnZBcnZ6aGcxc3lPZW40SmdKa3hKdlFP?= =?utf-8?B?UUNpTHk3Qzl0dkVQb0c0elVZUnd6aCt0MzJvdE5rYURsd1d5ZVBHUWtxYitk?= =?utf-8?B?Tjc1Zk5nQjZ3Sm1qSmpqZXFFTWRLMm9PQ1p4OFpNR1ViUjFQNnMvTEw2SnIr?= =?utf-8?B?YThvT09QMW1panVxL2U3MjRBOVpRaVdzSGlZM1RqMVNsd0Frc0hkQUFFdjdD?= =?utf-8?B?ZXo1dW1WWmFOdWJpZWl6SzNkcFB0QzQ0ZklvYnl1K1pGS2tiaUw4RDVnamp5?= =?utf-8?B?dUZwc0JYTHNUS2E0am1WMmZKUjZYSGVxS0Z0QThvbERCaWt2VngyU05VSndq?= =?utf-8?B?ZEpERkRHL0hIQ0FuU0d2TGNGUmNkeS9jTzc3RWZmZElpSmY5ZGhCRURtQ2hi?= =?utf-8?B?UnpoeXNmb0Jmd0lybUNpYTNFS1c5cXFINkNXcE1OTWF6NUltNG9tZVNTdFFL?= =?utf-8?B?TWkrMEQxQUxyTjNZRVFyaGo4OHhzZHlmOGRicEtVSkx3NEVBMTExNHZNS01l?= =?utf-8?B?WFFNT3RFNkJoZ3dDMkNIdlg1S1ZqMHpqVjQrOFcrK1FjYVEvck1hR1JFSTRZ?= =?utf-8?B?dFFyWVBXYXZtYkM3Z0FIRVJHdnZIMlB1c0lMV0tYaFFsQlNQVGdaczdnSFV4?= =?utf-8?B?RWgxYTFGLzJ1SlNaZHo4c0NtYW9qZkxFL2I1YzUvb3QweDVIajFTbHc3ZmZF?= =?utf-8?B?aDIvL3BINHZSRUdiSnNudGJ0Q3J6cW9qOTJxQzEwdC9MRVpYT2tEcE93bXpB?= =?utf-8?B?Q1Y3cUJjMlNwZmdzekxBTDhqYUxrQnIwcnc1R2hNTDNVaWd3ajg2TGNWcmNF?= =?utf-8?B?YzNkc3d6dFFFUTkwdldaeHhsNDgrcTVCVEFLOUkxY0k1WEZKUVQ2SDB0Ynpt?= =?utf-8?B?a2dVSk91WkxhcXpUY0phaFVQb1lUTkNtYjZEY2x3a1VuUW5helFiUk5xYXlH?= =?utf-8?B?MTFvRzQycXZyVEEzSHdOcHovTDE1b0hXOElvTm01WDVWVjVYRzNLWHhqQ2g4?= =?utf-8?B?K3BGZkhLRmZ5SmcybURzclV4SGRkQVhVMCtYK3Z2REVmSkE9PQ==?= 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: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14f80e43-92ab-47ec-2c8e-08d8d8c17e36 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2021 12:41:23.0052 (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: N42Wkt+NqJ+6ZhxFDX74tsQQiyOOpYzAmvR/l8RfWDTgNQ5tyxNmwIi8NqZoz84Ci2vPRGrqTmzc6tvtJaiHurkWOugB14z+BSYk9dVYs3xG97Kdu25QcB3ZAjHhiIvp X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB7022 Archived-At: Subject: [core] Review of draft-ietf-core-yang-cbor-15 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, 24 Feb 2021 12:41:27 -0000 IFRoYW5rcyBmb3IgdGhlIHdvcmsgb24gdGhpcyBkb2N1bWVudC4gSSBoYXZlIHJldmlld2VkIGl0 IGFuZCBoYXZlIHNvbWUgY29tbWVudHMuIFBsZWFzZSBoYW5kbGUgdGhlc2UgY29tbWVudHMgdG9n ZXRoZXIgd2l0aCB0aGUgTGFzdCBDYWxsIGNvbW1lbnRzLg0KDQpDaGFpcnM6IEkgYmVsaWV2ZSBp dCB3b3VsZCBtYWtlIHNlbnNlIHRvIHJlcXVlc3QgYSByZXZpZXcgZnJvbSBZQU5HIERvY3RvcnMg Zm9yIHRoaXMgZG9jdW1lbnQuIExldCBtZSBrbm93IGlmIHlvdSBuZWVkIGhlbHAgc2V0dGluZyB0 aGF0IHVwLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KPT0NCg0KNC40LiAgVGhlICdsaXN0JyBh bmQgJ2xpc3QnIGluc3RhbmNlKHMpIC0gc2hvdWxkIHRoaXMgc2Vjb25kICdsaXN0JyBiZSAic3Vi c2V0IG9mICdsaXN0JyINCg0KPT0NCg0KU2VjdGlvbiA0LjY6DQoNCmFueXhtbCB2YWx1ZSBNQVkN CiAgIGNvbnRhaW4gQ0JPUiBkYXRhIGl0ZW1zIHRhZ2dlZCB3aXRoIG9uZSBvZiB0aGUgdGFncyBs aXN0ZWQgaW4NCiAgIFNlY3Rpb24gOS4zLCB0aGVzZSB0YWdzIHNoYWxsIGJlIHN1cHBvcnRlZC4N Cg0KV2h5IG5vdCBCQ1AgMTQgU0hBTEw/DQoNCj09DQoNCiogR2VuZXJhbCBxdWVzdGlvbjogYWJv dXQgdGhlIFNJRCB2YWx1ZXMgdXNlZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudDogYXMgZmFyIGFz IEkgY2FuIHRlbGwgdGhlc2UgYXJlIG5vdCBhbGxvY2F0ZWQgcmlnaHQgbm93IChhbmQgdGhleSB3 aWxsIHRha2Ugc29tZSB0aW1lIHRvIGdldCByZWdpc3RlcmVkIGFzIGRlZmluZWQgaW4gY29yZS1z aWQgZG9jdW1lbnQpIEl0IG1pZ2h0IGJlIGdvb2QgdG8gYWRkIGEgc2VudGVuY2UgYWJvdXQgd2hl cmUgdGhlIFNJRCB2YWx1ZXMgZnJvbSB0aGUgZXhhbXBsZXMgY29tZSBmcm9tLg0KDQo9PQ0KDQpT ZWN0aW9uIDYuNiAoYW5kIG90aGVyIHNlY3Rpb25zIHRoYXQgdXNlIHRhZ3MgZGVmaW5lZCBieSB0 aGlzIGRvY3VtZW50KToNCg0KVGhlcmUgaXMgYSBuZXcgQ0JPUiB0YWcgYXBwZWFyaW5nIGluIHRo aXMgc2VjdGlvbidzIGV4YW1wbGUsIHRhZyA0NC4gVGhpcyBpcyBxdWl0ZSBzdXJwcmlzaW5nIHdp dGhvdXQgYW55IHRleHQuIEFsdGhvdWdoIHRoZSByZWdpc3RyYXRpb24gZm9sbG93cyB0aGUgdGVt cGxhdGUgZnJvbSBSRkM4OTQ5LCBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgdG8gc2VlIHNvbWUgZGVz Y3JpcHRpdmUgdGV4dCBhYm91dCB0aGUgdGFnIChhbmQgbm90IG9ubHkgYXBwZWFyaW5nIGluIHRo ZSBzZW50ZW5jZSAiVGhlIGVuY29kaW5nIE1VU1QgYmUgZW5jbG9zZWQgYnkgdGhlIGVudW1lcmF0 aW9uIENCT1IgdGFnIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDkuMy4iIC0gbm90ZSB0aGF0IHNl Y3Rpb24gOS4zIGRvZXMgbm90IHNwZWNpZnkgaG93IHRvIHVzZSB0aGUgdGFncykuDQpUaGlzIGlz IHZhbGlkIGZvciB0aGUgZm9sbG93aW5nIHNlY3Rpb25zIHNwZWNpZnlpbmcgbmV3IENCT1IgdGFn cyBhcyB3ZWxsLg0KDQo9PQ0KDQpTZWN0aW9uIDYuNzoNCg0KSSBmaW5kIGl0IGhhcmQgdG8gdW5k ZXJzdGFuZCB0aGUgZXhhbXBsZSwgd2l0aG91dCBhbnkgaW5kaWNhdGlvbiBvbiB3aGljaCBiaXRz IGFyZSBzZXQuIA0KDQo9PQ0KDQpOaXRzDQoNCi0gZXhwYW5kIGFjcm9ueW1zIG9uIGZpcnN0IHVz ZSAoIGUuZy4gTkVUQ09ORiwgUlBDLCBzZWUgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvbWF0 ZXJpYWxzL2FiYnJldi5leHBhbnNpb24udHh0ICkNCg0KLSBtb3ZlIFlBTkcgU0lEIHRlcm1pbm9s b2d5IGRlc2NyaXB0aW9uIGJlZm9yZSBkZWx0YSBkZXNjcmlwdGlvbi4NCg0KU2VjdGlvbiA0LjUN Cg0KICAgbW9kdWxlIGV2ZW50LWxvZyB7DQogICAgIC4uLg0KICAgICBhbnlkYXRhIGxhc3QtZXZl bnQ7ICAgICAgICAgICAgICAgICMgU0lEIDYwMTIzDQoNClBsZWFzZSBjbG9zZSB0aGUgcGFyZW50 aGVzaXMgb2YgdGhpcyBleGFtcGxlDQoNCg0KDQoNCg== From nobody Wed Feb 24 07:38:24 2021 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 EE9F83A1727; Wed, 24 Feb 2021 07:38:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk CC: Carsten Bormann , barryleiba@gmail.com, cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-yang-cbor@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161418110295.24294.2180225004081628867@ietfa.amsl.com> Date: Wed, 24 Feb 2021 07:38:22 -0800 Archived-At: Subject: [core] Last Call: (CBOR Encoding of Data Modeled with YANG) to Proposed Standard 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, 24 Feb 2021 15:38:23 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CBOR Encoding of Data Modeled with YANG' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-03-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 8949). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 24 07:39:49 2021 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 AE04F3A193B; Wed, 24 Feb 2021 07:39:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk CC: Carsten Bormann , barryleiba@gmail.com, cabo@tzi.org, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-sid@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161418118269.26748.8995127112399706832@ietfa.amsl.com> Date: Wed, 24 Feb 2021 07:39:42 -0800 Archived-At: Subject: [core] Last Call: (YANG Schema Item iDentifier (YANG SID)) to Proposed Standard 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, 24 Feb 2021 15:39:44 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'YANG Schema Item iDentifier (YANG SID)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-03-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of YANG SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-sid/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 24 09:15:42 2021 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 AA1013A09F5 for ; Wed, 24 Feb 2021 09:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtY8kAHrOgT9 for ; Wed, 24 Feb 2021 09:15:37 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40056.outbound.protection.outlook.com [40.107.4.56]) (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 DEB743A09ED for ; Wed, 24 Feb 2021 09:15:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mT0m4c7eI3iKYQj3+CfRo7To7jBtUWIOxxb5m4WqdbGerlIMqroXFzkYXBAr9yQFqdEZoMOwGSQh2rpks1ik+mZzRQ+1W9EshJHaYZgK127fy5RPdxonNobb2RGHZLqoytOR0RVeluhFdRv8hrQ4wXiphEtMFRW8OIDmNITRUPxFjNpmXa7oswYVLkOpoelinSUcgD8qxgqzcce+T57I/+0ZXsCECnhS9PFNS88G5CmuTztYE9zSTL1t/pFvZO8PXoD0BRDTciH12vIKNJhbJ4EZy2Qg32vMmWiOe/fw7du8UlmJPY4sNtdVjWFG8yk+AntVQk6gIWyCn1Obb0ED9A== 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=mIM0VxGP9P+78ORSY8JIkAA+EVjlLcCRRL4AVxjT+1w=; b=P7irOkWblvGngOT271A98/3Fhvq7mq2kIuolPzrSPK0PbckjlTjFV9C/DQlWrRZaCEjoJhfFN1JwnUMjqvYjsTLeaHFmlFf4yvKlfphTFLNAUuszTmhGYy6x+nKdKnwpq/oIVIxwxnc/UWP73jKEgrS/9Ea/LWTJ9kUrr1jub1A/DvEPPEHMIYawx6HWyMWfOr4Y0c+HcpbfIdgesjRpnvD4XytzrAL8K196p+UvchqAZSOxCzECKJeU9biret5syNfsVScVX7a1J7C43FjO1a2ZZPwg/z+Ia82q6I9BfzOwdEy0fQFAdcGEZ6sZxucOlOfrTA3ulDniduOBIA9RXA== 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=mIM0VxGP9P+78ORSY8JIkAA+EVjlLcCRRL4AVxjT+1w=; b=i+1ASmDaI2IpdJ5fLB4aFHrSXqg1oXfVcMkOoNaIdY5Yz/sVsgVSC1e3d6kZkFtT/91WxaAAffdgHet/4EMdRqVpfZ64uugcwo3ZLWVHvi6v1h07tPkjZh56UjxcxZag5TDUZxRC641HbyhXOXStStQGv08Z/aI0OYumBq3g5R4= 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 DB8P189MB1096.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:168::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Wed, 24 Feb 2021 17:15:33 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3890.020; Wed, 24 Feb 2021 17:15:33 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> Date: Wed, 24 Feb 2021 18:15:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lQPZ2gKB6oVMgZs582KXauYydpbIWD36G" X-Originating-IP: [45.12.220.212] X-ClientProxiedBy: HE1PR0902CA0013.eurprd09.prod.outlook.com (2603:10a6:3:e5::23) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.4] (45.12.220.212) by HE1PR0902CA0013.eurprd09.prod.outlook.com (2603:10a6:3:e5::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Wed, 24 Feb 2021 17:15:33 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 28b5caf3-3960-49fc-cc82-08d8d8e7cb56 X-MS-TrafficTypeDiagnostic: DB8P189MB1096: 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: uNyedRLvitDOJgxQoFntZ7b8O4kkDZDJ3XblNx9vG8g8VJr+O7d9Ayy7j27dbA9Jul6pDz2NmHWY/eADaScohWIQbIkJ5jKWREHQp1HDuQn8bepbH/SC+8hodk+HsdR0ojxPySn7+cp9YDeulPp8fDYIjbOMkV4VuvzXzQ0RJxm2CjpGNN25RrEozYCuBKyfafmkECjbJXlcZmZxNaGaN3l81ZZHqF8CmsEW0IeFvaSFtMZrxa8jZczHaqTVD5DSozLzM78k2d2a/oHIKJXzlmiV4aOFkVen4cTIL7zuqXFp/ZV6/yWOe6I0H9JMnXJTL1xr5+91mhWlDIecvTw+Ueiz8OSFpr3GFVBdAhs3J0qwcOebp7mmT2z+22inCk1bS1NBvX7wIyfd4ZXmqJNSFksJHK+kjQRYTl+mUWEtSdeFCIt80tLm13KSt4k4WWo+USFlNjHQOs8PCZXtW+z29Y0MyL485pWRxl08coCEj6TBpSj6SieQ8EnymIa0ICczr4tVYUDGMLiqci0DM2aG4K7XAUhGiwa2Leeqj2H4B8rOZG175Oy7szQxpEYS310kI97iZegMktJNgVOGa/c2wqQJ+Uq7qON7O18tDzogDMXCKwYWVivj3YZ1HfqfkIUWtM95o8UlXjiauOui5lH3CMuDuXfkW0OOV9+eO2l6gdqzyjmACVYY5JBCAOGez3A/ X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(396003)(366004)(39850400004)(376002)(36756003)(21480400003)(33964004)(31696002)(8936002)(316002)(966005)(86362001)(31686004)(6486002)(6916009)(478600001)(66476007)(5660300002)(235185007)(16526019)(52116002)(66556008)(16576012)(2906002)(83380400001)(2616005)(956004)(66946007)(66574015)(44832011)(186003)(8676002)(26005)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?czIwd1A2aTBBYVppMmVpZWVBTHRScUNWSk1vZlRGUUVBQ1c0U2lEL1BGcysy?= =?utf-8?B?TFFFSlJuU3ZMTm1Lc2FXR29sSVNXSWlUWW0vQmtSVHZNUG1uR3dFYzRqVzh1?= =?utf-8?B?TnFWM1dKaERVQWViTVJDNXRCdUJ5WWJHaGRuUUlkVWs0MDZsbFlBbFk0SHFp?= =?utf-8?B?TUp2emoyQU1oVFA5WFRRNmRtWERVcHd4S1NWenFZdkRVZTJqOXpUaUJYcGpS?= =?utf-8?B?VzNRRFA0ZlFlbVdRYUtpMm9zcGFsWXppb2x5aFgwRkxMQWgxRTN2N2NrUjFx?= =?utf-8?B?RkxsQVJxRHpvY0tiU1E1aFZXblJYK0tvamFaTVlxZzBEcXl0NXp1N29zRTMv?= =?utf-8?B?Ky9tR0xLeFpvK2F1WGtBSk15Snd2Mk5ndEpheGVsL1l4YTFLOURyZ212Y2U2?= =?utf-8?B?U2YvMm9PWDdUaXB3QnhqTFlGWGFsS3VDWHVYZzM0MnVpcGtGOUpqWlRrckZW?= =?utf-8?B?elRaNStHcTlhSGNTdHFHN1hJdkxUWHYvRVp2aHlraVQ5UFhtL0ZjZXpYZnRv?= =?utf-8?B?ZlZ1Mno2a0RPTUZwWnlvenpSMUZQMHpERUtRVjR5cWRDTkF6aTYycUYzaytV?= =?utf-8?B?V0tORy8xSGFqM21pVy94WWQ0RVJPR2xhY2c3VFlURmpBdG1BU1VFTE5UY0R1?= =?utf-8?B?ajhiME9UNGRGRldPTDBMRnh2bVpOWnlWOGNkZWV3T1ZXTjg4YlFENUcvN1Ji?= =?utf-8?B?OFVtTlhCZHM4S3lYc2E5Y1lFMmV2VHpmZWhKNEtTcjFzL3F3N0U5N2oxcEFm?= =?utf-8?B?MDBLMUc3c3FuVitQRkY0NmhpZlVickJCL1ZKcHY1anV5NHp1ZkxYN08rM0ZX?= =?utf-8?B?M1JlVzl2RERObktQUnlwendnNzgxdlNmR0RFS3dxczlkVklUN01sb3VQd2ZN?= =?utf-8?B?YTlBemY4UWJOVTZKUXF0dUJJYkhVTGNMMmlONjdHbTdDUXFZZXE2RWZzVzlm?= =?utf-8?B?cVRSVXkzQ1VVeGxGRXpDV2pCTGQyZnBrZUcwL3NISjJEbC9XRTRmUXV0THFj?= =?utf-8?B?Q1J3VTFEaXZYMEIvbDZ3aVBWeDJvUkIyZjZXclk2TzBEbjlNVk1xclZrNk9w?= =?utf-8?B?dEdNRFIyQ0NoR1Bqb3FGSHhTcXE5QzZUNE0rbFZLMGViYTNjY3p4NjNJR2lj?= =?utf-8?B?SkhVczVnd244REpBV2J3SDU1bjE1MW04c051bGZnQnRESmJ6V3RJY3gvQWpZ?= =?utf-8?B?WXJDa253S3lXZFdXQWlIeWcya21pTEtxOWt5d29TSmptV0VCUEN5U0FNQTFT?= =?utf-8?B?QUN3MzEzVmZBcGhrWWhSdXZnU3ZLMHZJN1VJWXN2K3hhTlZ1MDFHYWluZUZq?= =?utf-8?B?Y1BiemFWUXlIa1g4RThuSVRza0FuOXJ3TXZsNlRMcUpKMk9LTkpJdEdjMDFi?= =?utf-8?B?Slc0MXpQSm4vNmZQK2YxTTdYNTlBQ056SGZaYXZ5OCtnOExtTTZiQ3JXTGI1?= =?utf-8?B?QitEeS9SenEyV0lMVW9CcEdLdnB1bWxTdG9MbGlseUxhbHIvc2wxZkd1czY4?= =?utf-8?B?Q1RCdkl2dWJoZE9FalIzUlVmR1JaN1RKQXZMOFgzL3Z4MEk0SnYxdmdhQi9N?= =?utf-8?B?ajN5WGJZQTVyRXlFUkZDUCs4aHdsMHRlSFVDb3pOUDlkSmxmYlJLZ1Z5ZFk1?= =?utf-8?B?eEU1UU9MbjMxb2U5N0l2YmQrdXcyN2dqb1k4RXZPclRDNDNKaVFadEZnVll6?= =?utf-8?B?WWE0V1JWWUk2Y0Q1UldoN0pJSEZWc2RlSkxndVFvVEprejRBM2ZSQXJDRm0r?= =?utf-8?Q?K9/fvcfE8Ymc58Nn0ne+Ok5VeC6jOp5/pDwgThz?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 28b5caf3-3960-49fc-cc82-08d8d8e7cb56 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2021 17:15:33.5484 (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: llqKi7RhRQvDMriKgFavpPwVJxJ2SZbtocdEtksJVdr/Wj/Q+lK8PI+vQqplFOCac0UZklYGhWGEtB3MNZuosQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1096 Archived-At: Subject: [core] CoRE Agenda for IETF 110 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, 24 Feb 2021 17:15:41 -0000 --lQPZ2gKB6oVMgZs582KXauYydpbIWD36G Content-Type: multipart/mixed; boundary="tnkBhtXIupcnB2L2HFYO5pe6UBUWK1ap7"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <00d7c5da-eb17-1dda-cd57-749b419a0b8f@ri.se> Subject: [core] CoRE Agenda for IETF 110 --tnkBhtXIupcnB2L2HFYO5pe6UBUWK1ap7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, An agenda based on what has been submitted and on recently ongoing=20 activities is available at: [Day1] https://datatracker.ietf.org/doc/agenda-110-core-sessb/ [Day2] https://datatracker.ietf.org/doc/agenda-110-core-sessa/ Those who want to run slots, please: - check the objectives we have guessed, or provide alternative ones - check that the estimated time for the slot is ok - confirm who should run which slot, or provide an alternative - send a mail with this information to core-chairs@ietf.org Please, come back to us also if you think there should be a slot on a=20 topic/document which is not included. Best, Marco and Jaime --=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 --tnkBhtXIupcnB2L2HFYO5pe6UBUWK1ap7-- --lQPZ2gKB6oVMgZs582KXauYydpbIWD36G Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmA2ibMFAwAAAAAACgkQ7iZktA5Y2kPQ YQf/ftjFi2UoqlNovLUG+yb0T9q/HMuRnfMxb/wHGJKQrgC2DvwgPx0FS5CfywZvbT2o5IimoCNo 5/Uhwkc9F2yxoKUH2h9gzNdHeopJbYYNgKEBLJSfIukQtJXvS4ZydBaG4qRdmffGfegLCrMGvSAV LaT0u3tV0/VzdalyAc/Q0vJfjEw99dejpKCsXWd17FprOZif4rCvWyng78Ik5J0znDYQh6C0hIjG 18Dvh5SemgypPGw1vFFo1zKpmyRWkiCpPBUiAVomFwQS2elJhCl9oj6AM7efvJBMr1UkISRJYwGM T790VHk3deuCyVJk3O+Zl+jybrr6eci6KBT49HAi0Q== =A7In -----END PGP SIGNATURE----- --lQPZ2gKB6oVMgZs582KXauYydpbIWD36G-- From nobody Wed Feb 24 09:23:07 2021 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 55A333A0B02; Wed, 24 Feb 2021 09:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BIaT63h3K4RD; Wed, 24 Feb 2021 09:22:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD5A3A0AE1; Wed, 24 Feb 2021 09:22:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 21E95389B1; Wed, 24 Feb 2021 12:27:09 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qgfc6IKucgzu; Wed, 24 Feb 2021 12:27:08 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AC54438990; Wed, 24 Feb 2021 12:27:08 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2E2CC152; Wed, 24 Feb 2021 12:22:57 -0500 (EST) From: Michael Richardson To: last-call@ietf.org cc: draft-ietf-core-yang-cbor@ietf.org, core-chairs@ietf.org, core@ietf.org, barryleiba@gmail.com In-Reply-To: <161418110295.24294.2180225004081628867@ietfa.amsl.com> References: <161418110295.24294.2180225004081628867@ietfa.amsl.com> 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] Last Call: (CBOR Encoding of Data Modeled with YANG) to Proposed Standard 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, 24 Feb 2021 17:23:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The IESG wrote: > The IESG has received a request from the Constrained RESTful > Environments WG (core) to consider the following document: - 'CBOR > Encoding of Data Modeled with YANG' > as Proposed Standard draft-ietf-anima-constrained-voucher successfully uses this mechanism. That is, we have "running code", to the extent that this document is about transforming YANG into CBOR. Our biggest challenge has been that the documents have taken so long to pro= gress. Please progress ASAP. =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+93Q3WUFAmA2i3AACgkQgItw+93Q 3WWu0QgAl6jXQKw0VhQqEewo3MiKYgK004peYvo5DfMzxyddkg3S++PReVA6+Xeb fOP5Q3c/TkhsZQwvOYretLHDicB6I+HSHrobVzDJYSiBEKUgdsyzFv5X2LCbTYlJ mH766WJjJTioyxO7ymj4TOKzkpm3wce4VGiPl3unPXKqReXIqfWz+pYx6aHgwWcJ SBhw7K4MaDY4sYfmvb47nS+73ZgtzGz0cLTshgTKtxHpNaDx0wim10uKYArr6Ufp zuw0dEZx5XiVHD/NUbNlz9LLzM0t7IYTsrhcffwEcqrE+nKCB6Jg/UBpyX40iL6R r7BFdudSRPyTn/VoT1/0jtxSw7KUdQ== =HmKv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 24 09:53:09 2021 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 9135B3A188D for ; Wed, 24 Feb 2021 09:53:07 -0800 (PST) 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.25, 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 mWH_HXOkDQvA for ; Wed, 24 Feb 2021 09:53:06 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (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 3C5A83A188B for ; Wed, 24 Feb 2021 09:53:06 -0800 (PST) Received: by mail-lf1-f47.google.com with SMTP id m22so4358323lfg.5 for ; Wed, 24 Feb 2021 09:53:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dClxFWvjUp+/WmFIL3fdRWxpiyWlxPAcRLkaRED3mj0=; b=f2nUkVvmrMnkF4o5rH3IUuR3/RCSISKbCjQbuFJ89KcIDZ3y3sHmSH02hzFhJl0Zml eZFDk++AtkRVmfUVgWR6dtJY8nrid22jDukVueIevyGwseu8pYL7RU3/60n6t6TvkPNo 2/m2iVpuTMoLZOoC3y7L+bCQ4Tx6414IO9WR1pS1dRgaxxS2X5MSIV2U45fE7sLdonlc uHfJREPyGdXBtgMabkfwWVNYdc0W36aWModi/TkerAWi2F9zc5JE7Xj50yzcjIWe+s7A FdrJ2THFGJrtfM417aNT6hr1QJfjsoQ3+obNrfh6ZjTGOZ7C0OC3UnneMPsRxxcaulmw GRjg== X-Gm-Message-State: AOAM530aly9KSqCNlMB0by1BybPCga4PIyT6xVVj+nlDUNXt7u9muQ4N UOwhSEwzYZLFzqG5mdyYnz8lg7aWjPTmbSRrGc25nuekGd0= X-Google-Smtp-Source: ABdhPJwBCBCNvdyN+DW+hG4+VTetVh1TRH+xVX4kxaWdDc093XITPth5HVBMtrQ9eCJR7Mi32+6z/04Lee1w1/e2wUk= X-Received: by 2002:a05:6512:3443:: with SMTP id j3mr16363717lfr.123.1614189183813; Wed, 24 Feb 2021 09:53:03 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Wed, 24 Feb 2021 12:52:52 -0500 Message-ID: To: core WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [core] CORE chairs at IETF 110 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, 24 Feb 2021 17:53:08 -0000 Marco and Jaime have let me know that Jaime won't be able to attend IETF 110, and we've asked Carsten to help Marco with chairing the CORE sessions during the meeting. In order to Meetecho to give Carsten the right authorizations, I'll need to make Carsten a CORE co-chair again temporarily, and to un-do that after the second CORE session at the meeting. So I'm going to go do that now. This is just a temporary expediency in order to make the IETF 110 sessions work more smoothly. Barry, (outbound) ART AD From nobody Wed Feb 24 15:27:56 2021 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 2EF943A1D4F for ; Wed, 24 Feb 2021 15:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, 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 QzVyZ-kdYsFf for ; Wed, 24 Feb 2021 15:27:53 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2089.outbound.protection.outlook.com [40.107.22.89]) (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 F0EC73A1D56 for ; Wed, 24 Feb 2021 15:27:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cxdEzP5M7HI5zsXqrMhFKOjnW5r5Lk62GwAK6H8TFCSMPPEz1LL4FoDSkIErM+1fzkL9QtNr35h/K6vRa5TqPJwq9YAfSBuDanYhA3lCN1rvQLYr2cYBXGpqT7kR/lSeXcjrwHsS6eaSnzLf08DIH7QdnKR7VubvcfSlYjk/KahNGcWmbXIQXzKLlhWm6W6gv/qgGVCoO1ZwN5up5ECMuF/0/9UCH7L3a6Pry9/J/6XVHYMu+oJdZtvQUp9ivW4cfBYSm7XO/cyDoZDZv4xf8aj3sBtpI2jvH7H3QvEPZEEFj8L4TFSEtbscPwCLt18ZNjhqxG7ZM//jkxzFhutdjg== 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=mgoeLG5tqg9/pXopKvJaDKZMEtMZuaDBm1rpabZuOec=; b=FeXePb5n59DkeogYrZ5v/9PxnMVGLu5PsC++FeGlNBVSrtJnRgwcbxuOOXIX4J3cL7T2SHIEpeOvQCZ8AX6AhMntw4HnoiVBHkJQIvjvYeQrEkhthX1lEXLNkv8v00z35mTcAdL8mIDVR9YBNkyG9MRjSfIHwYjVktHwSJVuSaSw9UzdBr6UVLC/GAlFY0hqk9yNW5CFjBkBMK+t4bLA+M5E5qfAt2dkAX5JyW+Stgdd7ujORDphdLIR6qhwd5/3Wr6/X9huEfHiRHpp1zmFBkps/E0JvNRSlj3Fj24HTyLmHJTh3+v3CUL7gfDh6ZfiQ8Lz0GxrlLO/BpyEF4Bq3A== 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=mgoeLG5tqg9/pXopKvJaDKZMEtMZuaDBm1rpabZuOec=; b=J6tnIqt8H4/1J923fkSUqkzaQhcwfzCQZDcVS34RV5A3G/gs2WSJErThp+wqOzW+X+TMBddHS2fwe7E7ZHTEzkSapluRfG9WBWN5obNzMHVfQtUHan6J8A+FQxHZGNUoki+0qP7m9bov3+hk4eGFdwDeJqwzgD9gEVQ4156hD+Y= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR07MB3434.eurprd07.prod.outlook.com (2603:10a6:7:2c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Wed, 24 Feb 2021 23:27:50 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::69ab:83ff:dd6e:3536]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::69ab:83ff:dd6e:3536%4]) with mapi id 15.20.3912.009; Wed, 24 Feb 2021 23:27:50 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: Review of draft-ietf-core-groupcomm-bis-03 Thread-Index: AQHXCwSqc4rdNewjlUGtn83ROTnvRQ== Date: Wed, 24 Feb 2021 23:27:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21bf6dc0-0159-4cc7-1f83-08d8d91bcd3e x-ms-traffictypediagnostic: HE1PR07MB3434: 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: 8cdvA5ojCuPjtCLjscKgBNfimTtGQnH2ptW0nsd1XVwotTS5or8y3FHrnA1yXcRAJmyqtcD/iWHgXQLACAB4ar8og36zTXNY93bTmUVQVuecfuWBiO6vDgba0Z7A1bnMSEH02zY55GvCwhGAMx/rWJiM+k7B+aMPvHBlJUWQWazr2SLqsPEvgz7T26LF/jShT9Li61LECSGlKiIWtJFALMlaiU/EKhahitZe0WbHFMZbhXsLv0q1cvKdk16KrDHMg3Wgf+cvEoxL27TZEa3UTMxLJmb2ofOHGu5J2Ca1RJcDbkKv9mXDiNYA8hKQAIxnvQvHZwT6fui4ZoLvsnKFE57dJtR8krQpPWDUD4RNNOp/FLcXnwLeny1jR+/sv7XzRj9PL4EIPkH6JpCr1+pvbKvetbHAEk/blB8GVm98KwGxq4MO4WWrN/mcCdiHxbMw5fSG37x+U6X5QCPIUbClwwWNwo573+TcNQ8x0CRYZ2V/qcT9xtr3a6BNzNyXJEiEB+Z+QrPOBSa/JRcYW+kKZTqWtmwbmFssaVlLzg3gdWOt3SCfwzW8HtNA1PXoJvoePvKwgc8CoFiLVj2q1P23pLGN/i+4+dQisCXs6mTruzizekaHJG/P/QAwT82ZAIz5AKQej6Du4gnVQV98+IEWSg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(396003)(39860400002)(366004)(33656002)(316002)(5660300002)(6916009)(2906002)(44832011)(2616005)(8936002)(71200400001)(8676002)(6506007)(66446008)(76116006)(86362001)(6512007)(66556008)(6486002)(64756008)(66946007)(966005)(36756003)(66574015)(478600001)(83380400001)(66476007)(186003)(26005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Qkx6Snd2cHgvNHN5ZWV1Zi9QRnFmRUw0ZHMvOE04ZjFTWHZKVU4rZWdLeHhM?= =?utf-8?B?Yy9VKzgrTkFjSTh5ZUZNb2hUQjRzS1dQVksrM04ybHZvMEpRQ21DSHc1WDdF?= =?utf-8?B?OGRzMUZUZmFIUnV6T1NSK1RQNmZhR2ZEYWJXcVB1NHFsbVJMOTFBeGRaclBt?= =?utf-8?B?eVc5VFBwKzFyYXJPSDQ5ekJzaWJSa2JOMlV2SkU0cHQyOXNDMGcwem9zbktC?= =?utf-8?B?TjU4Y041WGlwTEZwTlVURnkyc1hNMldQaFlXR2IwcnFFSDR5ZFZDV1RKdmFK?= =?utf-8?B?VVl6b01rbzIzakF3b3NKMFhsbDZpeGkwMmpUNU4rVGxWUVR2M1kyMTNBdDRY?= =?utf-8?B?cEVHMXROMHRYdTE5SFdDZmpMZUVkWWNMMzByUWtDekxNMmJYd3dlakNkTGJI?= =?utf-8?B?ZnlDWTBVb3VpNE95emszUzc2dnpBUFJlZktSOUNCeGlqaUdtazd2Sjk1V3hw?= =?utf-8?B?TWtpOXpNT09idWxnTS9RUms2bnpnNzc0TmJ5SkdCbTc0V29KWkczK2Zma01T?= =?utf-8?B?MjJzK0c1c3IrekJ5UEVORS9keEg1SW9MNXZ3cTBBSXliSjRtRUtBVkQzUWFl?= =?utf-8?B?Q3Y0TzRXZFJDTlVXMk1USkN6MGlObVhCd3pMNXYvVWhoS3FJVzFNYzlTVHVI?= =?utf-8?B?NFVycklsOXg4dGQzOGRxTXFVSy9FTnVSU3FsTzRQQis1N1FINmpTQklNNFpk?= =?utf-8?B?d0F6L2tjUmxvQy9aSS9xQ2JLUWROUHJBcTdZcndaT29HMnZldEhCNFJOTVZk?= =?utf-8?B?UGJHdHpSV3VPekduQTg3VWx6ZjNZZStCVkpGcWF6dUZoZWVVcms5VjE2aktl?= =?utf-8?B?aGZrTll1Skg4VmMwNVpJVnUxVkptdFZsVGs4WUw5dzBoYldYMUVUK2xIVUxE?= =?utf-8?B?U202VVRMVE9aNjRPd0I3NGtNdkVid1c5WkR1WnVPb2xaU3ZjN3dqMk84bno0?= =?utf-8?B?WVdHOWRCb1d3WkhVVytUL0E1TVBSQkRiT1lIeDR6T0Y2K0ZiS3NNbEhNSVRL?= =?utf-8?B?N3hjNlN1OFV6OVJKRlVWdVgzTWFRZVk3Y0NYYyswSjYxVzYrSkpTY0VScDhT?= =?utf-8?B?N1hiRys0dHdBOUxRM25qemlNTVNkUENFdjNqQ0FkcTFxek9SYlUreUF4a2RB?= =?utf-8?B?bjhncnFIOHVDd1VBaStXbE53emRqSGdnNEEybnNGUjI4YS90Q3NnK203R3RM?= =?utf-8?B?dGordytlckVSelVlcnNYd0pmWmIzV0N3YXJOblZUT0dvMXBDMHgzZlZRQjJC?= =?utf-8?B?MGR5dWtXUVNoaVg3NTlqNFIvc21GOWJ1cXNnU1pCUWxMcENDaFBjREx1TlhS?= =?utf-8?B?cUdleXM4N2Q3dEkyYmNoNkdOSHNPdnoyUlJkZjhtb3VISUF2S0hLTUVDNENa?= =?utf-8?B?UFoveVJCNURuelRQUGw4ZGZ2Rkp5dlVwNjdxTFpTZmxkQjRNMHBoN0xrY0R5?= =?utf-8?B?YjdzZHE0TUNhdlJUTFM3d0RqMStnZUpyNXFVbGxiM1FzbmFiV3ZrL0hJR1d3?= =?utf-8?B?SzRUcUFPSzUxSkxsb0xCQTExSTFsbzIzUUxaUFl1eW52SWNNZ29XSXFhYStY?= =?utf-8?B?MjlWMzRYUm9SeVo5MkRVVkRicWVJYjN0cWlGYzNrZmE0amErTStEZDVBcTdS?= =?utf-8?B?Y1FscVpXUVdEY2kwWGdHZUlwNk5oekJZVkZZQzBMWGhndncvdis3NXlSbDVP?= =?utf-8?B?YWVybFZibVE5SHB1bGdtL2VzeW9DbGNScWxMWjZKalR2WGt3N21WTkFYNk1k?= =?utf-8?B?NW5nZ3MzSmsyUHdCTUFNYjVLSnE2cUZrTytGVlVQS25uM3NrVmpHd0JkNzVa?= =?utf-8?B?YnRHVmhReFUzbHV6VmJFUT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2E1EC2C72D96B746943AE6BB9B0E5E90@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: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21bf6dc0-0159-4cc7-1f83-08d8d91bcd3e X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2021 23:27:50.2550 (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: 2LPKxqOTKfheluTAIlX9bRCuX/30MrBrgL6hE/Cf1v1mrxs9vcWY8NWc5ayAFP7zUSW09jEV4kcK3Yj1fvrzbsu4A7tkV6vqPO+j+6c5r6E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3434 Archived-At: Subject: [core] Review of draft-ietf-core-groupcomm-bis-03 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, 24 Feb 2021 23:27:55 -0000 UmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzLTAzDQoNCkkgdGhpbmsgdGhp cyBsb29rcyB2ZXJ5IHdlbGwtd3JpdHRlbi4gSSByZWFkIHRocm91Z2ggbW9zdCBvZiB0aGUgZG9j dW1lbnQgcXVpY2tseSBhbmQgZm91bmQgdmVyeSBsaXR0bGUgdG8gY29tbWVudCBhYm91dC4NCg0K LSBJdCBzZWVtcyB1bmNsZWFyIHRvIG1lIGV4YWN0bHkgaG93IHRoaXMgdXBkYXRlcyBSRkMgNzI1 Mi4gRG8gZXZlcnl0aGluZyBpbiBSRkMgNzI1MiBzdGlsbCBhcHBseSwgb3IgYXJlIHNvbWUgbXVs dGljYXN0IHBhcnRzIHJlcGxhY2VkPyBJbiBzdWNoIGNhc2Ugd2hpY2ggcGFydHM/DQoNCi0gVGhl IGRvY3VtZW50IHNlZW1zIGEgYml0IHRvbyBsb2NrZWQgdG8gIlVEUC9JUCBtdWx0aWNhc3QiIGZv ciBteSB0YXN0ZS4gUkZDIDcyNTIgbGVmdCB0aGluZ3MgbXVjaCBtb3JlIG9wZW4gd2l0aCBzdGF0 ZW1lbnRzIGxpa2UgImJ5IGRlZmF1bHQsIGFyZSB0cmFuc3BvcnRlZCBvdmVyIFVEUCIuIENvQVAg aXMgbm93IHBvcHVsYXIgaW4gbWFueSBlbnZpcm9ubWVudCB3aXRob3V0IFVEUC9JUCBhbmQgdGhl IHNhbWUgd2lsbC9pcyB0cnVlIGZvciBHcm91cCBDb0FQLiBJIGRvbid0IHNlZSBhbnkgcmVhc29u IHdoeSBtb3N0IG9mIHRoZSB0aGluZ3MgaW4gdGhlIGRvY3VtZW50IGNvdWxkIG5vdCBlYXNpbHkg YmUgdXNlZCB3aXRoIGJyb2FkY2FzdCwgZ2VvY2FzdCwgdW5pY2FzdCwgYW5kIG5vbi1JUCBtdWx0 aWNhc3QuIE1heWJlIHlvdSBjb3VsZCBzb2Z0ZW4gaXQgZG93biBhIGJpdCBzbyBwZW9wbGUgd2Fu dGluZyB0byB1c2UgR3JvdXAgQ29BUCBvdmVyIEZvbyBjYW4gc3RpbGwgY2xhaW0gdGhleSBhcmUg ZG9pbmcgZ3JvdXAgQ29BUCBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLWJpcy4NCg0KLSBJIHRo aW5rIGdyb3VwIENvQVAgbmVlZHMgcXVpdGUgYSBiaXQgbW9yZSB0ZXh0IG9uIGFwbGlmaWNhdGlv biBhdHRhY2tzIGFuZCBEb1MuIFRoZXJlIGhhcyBiZWVuIHNldmVyYWwgbmVnYXRpdmUgYXJ0aWNs ZXMgcmVnYXJkaW5nIENvQVAgYW5kIEREb1MgaW4gdGhlIGxhc3QgeWVhcnMuIEdyb3VwIENvQVAg d2l0aCBpdCdzIDEgcmVxdWVzdHMgYW5kIE4gcmVzcG9uc2VzIGlzIGEgYW1wbGlmaWNhdGlvbiBp biBpdHNlbGYuIE11bHRpY2FzdCBPYnNlcnZlIGlzIGV2ZW4gd29yc2UsIDEgcmVxdWVzdHMgYW5k IE5eMiByZXNwb25zZXMuIE11bHRpY2FzdCBjYW4gaG93ZXZlciBub3QgYmUgdXNlZCBvbiB0aGUg cHVibGljIEludGVybmV0IHdoaWNoIGxpbWl0cyBhbnkgYXR0YWNrcy4gVGhlIGN1cnJlbnQgZG9j dW1lbnQgb25seSBtZW50aW9uIGFtcGxpZmljYXRpb24gaW4gc29tZSBzcGVjaWZpYyBjYXNlcy4g SSB0aGluayB0aGUgZHJhZnQgbmVlZHMgdG8gZXhwYW5kIG9uIHRoZSB0ZXh0IGluIFJGQyA3MjUy Og0KDQogIlRoaXMgc3BlY2lmaWNhdGlvbiBhdHRlbXB0cyB0byByZWR1Y2UgdGhlDQogICBhbXBs aWZpY2F0aW9uIGVmZmVjdHMgb2YgbXVsdGljYXN0IHJlcXVlc3RzIGJ5IGxpbWl0aW5nIHdoZW4g YQ0KICAgcmVzcG9uc2UgaXMgcmV0dXJuZWQuICBUbyBsaW1pdCB0aGUgcG9zc2liaWxpdHkgb2Yg bWFsaWNpb3VzIHVzZSwNCiAgIENvQVAgc2VydmVycyBTSE9VTEQgTk9UIGFjY2VwdCBtdWx0aWNh c3QgcmVxdWVzdHMgdGhhdCBjYW4gbm90IGJlDQogICBhdXRoZW50aWNhdGVkIGluIHNvbWUgd2F5 LCBjcnlwdG9ncmFwaGljYWxseSBvciBieSBzb21lIG11bHRpY2FzdA0KICAgYm91bmRhcnkgbGlt aXRpbmcgdGhlIHBvdGVudGlhbCBzb3VyY2VzLiAgSWYgcG9zc2libGUsIGEgQ29BUCBzZXJ2ZXIN CiAgIFNIT1VMRCBsaW1pdCB0aGUgc3VwcG9ydCBmb3IgbXVsdGljYXN0IHJlcXVlc3RzIHRvIHRo ZSBzcGVjaWZpYw0KICAgcmVzb3VyY2VzIHdoZXJlIHRoZSBmZWF0dXJlIGlzIHJlcXVpcmVkLiIN Cg0KQSByZWFkZXIgb2YgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMgbWlnaHQgdGhpbmsg dGhhdCBHcm91cCBPU0NPUkUgYW5kIEVjaG8gaXMgZW5vdWdoIHRvIHN0b3AgYW1wbGlmaWNhdGlv biwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLiBFY2hvIG9ubHkgaGVscHMgYSBiaXQgYnkgbGltaXRp bmcgdGhlIHNpemUgb2YgdGhlIHJlc3BvbnNlcyBidXQgbm90IHRoZSBudW1iZXIgb2YgcmVzcG9u c2VzLiBBbiBhdHRhY2tlciBjYW4gc3Bvb2YgdGhlIHNvdXJjZSBJUCBvZiB0aGUgcmVxdWVzdCBh bmQgYSBzbWFydCBhdHRhY2tlciB3b3VsZCBzZW5kIGl0IHRvIGEgcmVzb3VyY2UgdGhhdCBzdXBw b3J0cyBtdWx0aWNhc3QgcmVxdWVzdHMuIE5vdCBzdXJlIEdyb3VwIE9TQ09SRSBoZWxwcyBtdWNo IGF0IGFsbCBhcyBhbiBhdHRhY2tlciBjYW4gdGFrZSBhbiBleGlzdGluZyBncm91cCByZXF1ZXN0 IGFuZCBjaGFuZ2UgdGhlIHNvdXJjZSBJUC4gDQoNCkNoZWVycywNCkpvaG4NCg0K77u/LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+DQpSZXBseSB0bzogImNvcmVAaWV0Zi5vcmciIDxjb3JlQGlldGYub3JnPg0KRGF0 ZTogTW9uZGF5LCAyMiBGZWJydWFyeSAyMDIxIGF0IDE3OjUxDQpUbzogImktZC1hbm5vdW5jZUBp ZXRmLm9yZyIgPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiAiY29yZUBpZXRmLm9yZyIgPGNv cmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbY29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jb3Jl LWdyb3VwY29tbS1iaXMtMDMudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVu dHMgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogR3JvdXAgQ29t bXVuaWNhdGlvbiBmb3IgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQ KQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBFc2tvIERpamsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgQ2hvbmdnYW5nIFdhbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY28g VGlsb2NhDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMt MDMudHh0DQoJUGFnZXMgICAgICAgICAgIDogNTgNCglEYXRlICAgICAgICAgICAgOiAyMDIxLTAy LTIyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIHVzZSBvZiB0 aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24NCiAgIFByb3RvY29sIChDb0FQKSBmb3IgZ3JvdXAg Y29tbXVuaWNhdGlvbiwgdXNpbmcgVURQL0lQIG11bHRpY2FzdCBhcw0KICAgdGhlIHVuZGVybHlp bmcgZGF0YSB0cmFuc3BvcnQuICBCb3RoIHVuc2VjdXJlZCBhbmQgc2VjdXJlZCBDb0FQIGdyb3Vw DQogICBjb21tdW5pY2F0aW9uIGFyZSBzcGVjaWZpZWQuICBTZWN1cml0eSBpcyBhY2hpZXZlZCBi eSB1c2Ugb2YgdGhlDQogICBHcm91cCBPYmplY3QgU2VjdXJpdHkgZm9yIENvbnN0cmFpbmVkIFJF U1RmdWwgRW52aXJvbm1lbnRzIChHcm91cA0KICAgT1NDT1JFKSBwcm90b2NvbC4gIFRoZSB0YXJn ZXQgYXBwbGljYXRpb24gYXJlYSBvZiB0aGlzIHNwZWNpZmljYXRpb24NCiAgIGlzIGFueSBncm91 cCBjb21tdW5pY2F0aW9uIHVzZSBjYXNlcyB0aGF0IGludm9sdmUgcmVzb3VyY2UtDQogICBjb25z dHJhaW5lZCBkZXZpY2VzIG9yIG5ldHdvcmtzLiAgVGhpcyBkb2N1bWVudCByZXBsYWNlcyBSRkM3 MzkwLA0KICAgd2hpbGUgaXQgdXBkYXRlcyBSRkM3MjUyIGFuZCBSRkM3NjQxLg0KDQoNClRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMvDQoN ClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLWJpcy0wMw0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNvcmUtZ3JvdXBj b21tLWJpcy0wMw0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3Jl LWdyb3VwY29tbS1iaXMtMDMNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29y ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoN Cg== From nobody Thu Feb 25 01:52:31 2021 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 4D54D3A169C for ; Thu, 25 Feb 2021 01:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 9uF2xf4KvZo2 for ; Thu, 25 Feb 2021 01:52:26 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (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 067203A169D for ; Thu, 25 Feb 2021 01:52:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OEnTEUOGS07pO6Th8zo6K6V7VPSq+gv9+QWLrW1182/jNXXc6154jqERnrcAWUKepagM0Fwy7D8L/930Ix4KEwb5mJ/E2yTXktUNYp48AKxX3mXbOBFqYPuwEewY/G9Xh0Ii8wDNYNUITmbkTwB2at8LUEqve+0SSbPSnSQjg1aGYwr5fojieuWm9GSIi32Le3CSjv0++R7X7yriTwx5bfMIcpEkZ3WC4hjYnf5r/wEFnGfQyPG0j+dC0luzY16QCiIj3hlUhIda1LnsXp0GL8uZfO0u+THgHx9ota/rgUIYUQKm32M5VTSwBjbqjYcP4s1ibM1Ms6VvAd7hOoWBow== 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=HEkYz+TbvoQ29hstRDhS0uHpcwEldm+51lb3RpET9EA=; b=HlaDAPbM3UIPXisl8L4XuQctvvlddeEY7YgjcFVx8dRY+Wc+S3q2wXE2GcB8tDV6A6HMFNd6uWtN3BlMkereVpcIq/j53B2s/sxxT03Hg81ZSdVloeQDVYPHNOjHfCKezXdXj2pS05948Rw8Ii4L3aD4F/0/9tdNHsVY9CmDm2eV4xSUXeCZY9ujHThvWkoGPQuOjeb3CqYk4fQRnJ97qk+LoKBuqtSySOnE1vt1+K9VKNlB7L4vK2nNRpzWsCj2gEuCBslcAXodmfCvJdiZCaDPQJokpAopA6nk8zOOyIXGUiuNZjKyWsDOCJ1zY5iGDpsB2WvH0H11+1fp5laYSg== 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=HEkYz+TbvoQ29hstRDhS0uHpcwEldm+51lb3RpET9EA=; b=IiQlfHUXn2g9yMQpv3pu8cJqHOarXeftAFCpX8ejUJUi/clV9Ak03wf122Z0MnopP6fUZXthvBYHVWFNKvvszKfbVeQ38xbzugUZ6NjS7hpLCNyTxpPYYIJlF8g1D2q7iJ2XGBP8tjdxteq2xV9h8s+5AuiVKUFO6FHtjdcCWZE= Received: from HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:9b::19) by HE1P189MB0265.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:5e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.27; Thu, 25 Feb 2021 09:52:21 +0000 Received: from HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM ([fe80::300a:1114:baea:a1a5]) by HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM ([fe80::300a:1114:baea:a1a5%10]) with mapi id 15.20.3868.033; Thu, 25 Feb 2021 09:52:21 +0000 From: =?iso-8859-1?Q?Rikard_H=F6glund?= To: "core@ietf.org" Thread-Topic: New Version Notification for draft-palombini-core-oscore-edhoc-02.txt Thread-Index: AQHXBuqaDo6R/7ASFEClf/UlIcelBapoqcQJ Date: Thu, 25 Feb 2021 09:52:21 +0000 Message-ID: References: <161375826598.5236.6490040784409212199@ietfa.amsl.com> In-Reply-To: <161375826598.5236.6490040784409212199@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; x-originating-ip: [85.228.122.38] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ead90ac0-4e8c-4270-7326-08d8d9730bf4 x-ms-traffictypediagnostic: HE1P189MB0265: 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: k20ZP5DdQadXL3szTresSVNJ9vCwbMOKJekOOsa26U/+AUevqw/4SLdOOjkx1PzYSS9qMB1ZGwkjasYHyr8SEWkyUyCZozqnwLfdVXKf8sq9tYqh24Kf3p5Y70ZvvntJ1U0uDjfK7duxtJyGsZroENvBs+UWKhaeYau2anuE7r9JtxHLlq4bIQYUDYj+UgVbC43q2QonckZt4dDMOuX589GWcLLSM7byf/jIDhO3LtI5buOUPyUKRt7k4iCjxETRK0dsBdjGuUxUaZPGsB+UWOB6rsrXSjP5dV7sPkdvAUhcYijszBrk4rfA/EA1r+rEZ81+9qj3hDidtTxq7IgMDJgN2t6grEsfjT2XfYhOj3dVRAUbDHfkZkbdCdHUt0DhrhUy6WvfNNoVaBIurgLIi78Vn7A/rq876Gy9msGL32kKFGmFylZeV9X5fJV0jQ4lM3R9mCbfX3jZhdzqx/4CFWm1G4LIRuzJz3QEOlthLtvavYpMDCA3tK4LJVrYIsiKR7kIbwulMaZZtA9d0N6r0r+G37jpfxkLFmM81uL4wXhuY7FLlrw276w0qXPKw494X7dMzIMy7q41hZZfPjmr+NgPwqQ92u2WL1r22JqNcYs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(39850400004)(396003)(346002)(66446008)(86362001)(55016002)(64756008)(71200400001)(26005)(19627405001)(52536014)(478600001)(6506007)(33656002)(66946007)(966005)(66574015)(66476007)(83380400001)(5660300002)(166002)(45080400002)(6916009)(2906002)(316002)(53546011)(9686003)(76116006)(66556008)(186003)(8936002)(7696005)(15650500001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?zH7AepinjiQh3pX4I6d3ynjz3MVZAEtNkCfOYrzGzN1JWUKfnzkl5sZ9SE?= =?iso-8859-1?Q?5QsUeI/Gle35GwwcPdI0YIzN7XjmR4s15wvMefhogPQgHcdUz1aLIudwxZ?= =?iso-8859-1?Q?aWwq5v+fkggXErRnhIlGbpfLHh5jIKya4TusN8U/GDn8LiIvlGAGgHlvQF?= =?iso-8859-1?Q?6BFZ4lyri0CJQo7ry1rXTIlGKohYnFNkImcmvNKnUROqkBZNCxPd+ju7Hg?= =?iso-8859-1?Q?1ITJ3gBQSF7JHAFdNIWzq0OSVEAIASgjDW9tMVUlrTqXLzvrkV1CLkkLAm?= =?iso-8859-1?Q?yxpGdNhe4sN6Lv4rXC0dTR+4dC+RGgAWWhO2xHwU3ThXQ0WAKi6kxFYqEk?= =?iso-8859-1?Q?/s7PE0ulE0fgi3Ca72/n4KD7tJlvfpiRa39naiUqeijty2UqR6CaAp0PQn?= =?iso-8859-1?Q?NvaqBdz9JNvDOLWYIh6qmZrr/mgcGryB5w+pMIOdjQyp2Ab+Ch32ZdLDnB?= =?iso-8859-1?Q?yGXUHq1iHz4/rURUhrfkZLu4Yk7JETD2es+4evXqSsX919+nUXfYqxNXuo?= =?iso-8859-1?Q?27/H+EHHj4t+FcY3KZK0yQgys9hw7IkXEFotR8E5MzFJBIITJwCUEu5glJ?= =?iso-8859-1?Q?dyTkx2UdAJeUuDqQzURckKQ0J6xZC9i2FwpLPdTbjTBOQFQw5RZs4kow7p?= =?iso-8859-1?Q?15QouA6REuc2q9mDSzr6TuuwROlDE7SBhXdC1h+ctmOXqZwObzFvySBX5h?= =?iso-8859-1?Q?cHtfIVoPjcBEmHNfEaKNeVSs+OEQ0KisqKkSi/QS2OADeJcQxqGMGewra9?= =?iso-8859-1?Q?BJQ88PBN5Xu4HUGepaw5aelAMCyvFEXGQlVe11agx7POKhAJZ0uaXatzDi?= =?iso-8859-1?Q?0CcLSF1CuekuWQZmR1QFYBK/cAjuZqJNYiR0RILqM7EYM4DL8d6JKSV2h7?= =?iso-8859-1?Q?Eyv55LRAqmv6k3MybAZJhR8VBWqP0LNVkttOwJqjtrOnpsS4h18nPYQFIs?= =?iso-8859-1?Q?OVNC5osj6hw5WGJ7iJWe694TC1UppJimClpLGfNH3ZD5GQhc0rWHZf+n1W?= =?iso-8859-1?Q?I5b9DqTzbKbn0wQVJ6xkFxxSBQ8wroWlhNNs2nayx7m+Z5oM6HF1XHdCmG?= =?iso-8859-1?Q?tLzqXlV8AbiDBO9boYGD+uH48PjoeAqsisqK187qjoJ76gyA8I105Tbm9U?= =?iso-8859-1?Q?lw90IUKxVzg4u/NQRZFNiynxXJz7Oif248SlYawnGt3YjJlNWZBvAdry6D?= =?iso-8859-1?Q?XN59O/6eEgtxUUaeDnPu2wPZiy+YZnkT3aXz9c6QFG5cgujdt9Rq8tf8nD?= =?iso-8859-1?Q?wmVe0TVQ2dt1FAhglJfHfO43jS79daV3Ft2LFwREq7DnLkkrNvs/r6l5zf?= =?iso-8859-1?Q?uX3uHN9+R8o8+lP6J6IzTROHSKShAnf3EQABssmFQEwUb8k=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1P18901MB0043BA1F14C90B1E5533FE2E839E9HE1P18901MB0043_" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ead90ac0-4e8c-4270-7326-08d8d9730bf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 09:52:21.6262 (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: hNaw90RX8H1+xzU3DKRz/StDCGyOksqyKAzRNFUzCrXN2LEDBLmmNVTpMr4LvLzjfqLIQYMkw27L4RWBhkTqJw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P189MB0265 Archived-At: Subject: [core] Fw: New Version Notification for draft-palombini-core-oscore-edhoc-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, 25 Feb 2021 09:52:30 -0000 --_000_HE1P18901MB0043BA1F14C90B1E5533FE2E839E9HE1P18901MB0043_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted a new version of the draft "Combining EDHOC and = OSCORE". https://tools.ietf.org/html/draft-palombini-core-oscore-edhoc-02 This document defines an optimization for combining EDHOC (run over CoAP) w= ith the first subsequent OSCORE transaction. This reduces the number of rou= nd trips required to set up an OSCORE Security Context and to complete an O= SCORE transaction using that Security Context. This update covers especially: 1) Having only one signaling method, using the new EDHOC option, based on f= eedback from IETF 109 and implementors. This includes a reasoned proposal f= or the option number. 2) Improved presentation of the message processing, with an additional opti= mization to save more bytes on the wire. The provided example has also been= updated. 3) Improved success and error handling on the server side. Any feedback, questions or comments are welcome. Best wishes Rikard H=F6glund ________________________________ From: internet-drafts@ietf.org Sent: Friday, February 19, 2021 19:11 To: Francesca Palombini ; Goeran Selander= ; Marco Tiloca ; Rikard H= =F6glund ; Stefan Hristozov Subject: New Version Notification for draft-palombini-core-oscore-edhoc-02.= txt A new version of I-D, draft-palombini-core-oscore-edhoc-02.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-palombini-core-oscore-edhoc Revision: 02 Title: Combining EDHOC and OSCORE Document date: 2021-02-19 Group: Individual Submission Pages: 12 URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-palombini-core-oscore-edhoc-02= .txt&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8= d501baca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7C= Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL= CJXVCI6Mn0%3D%7C1000&sdata=3DiXdZq3kzFp1UXkvww90lBINHn%2BCOOM7wNDVPXPIt= IFU%3D&reserved=3D0 Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-palombini-core-oscore-edhoc%2F&= amp;data=3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d501b= aca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC= I6Mn0%3D%7C1000&sdata=3DrLWMVbh9GqJyETAsRlegmKe8HfFdGcQx2FlcAOZ%2BWDA%3= D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-palombini-core-oscore-ed= hoc&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d= 501baca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC= JXVCI6Mn0%3D%7C1000&sdata=3DE6CtZWyFoe6Hhc2yT1c5cGcSAv%2BKeqnB837rmHIla= y8%3D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-palombini-core-oscore-edhoc-02&d= ata=3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d501baca%7= C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0= %3D%7C1000&sdata=3DPG3hMLCU6WDGzDVEt4TKYpdoIE%2BE32oH%2Fcyol4DCjw8%3D&a= mp;reserved=3D0 Diff: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-palombini-core-oscore-edhoc-= 02&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d5= 01baca%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ= XVCI6Mn0%3D%7C1000&sdata=3DP22R8MdmgrrauizhjuabPfJNg3Ss4WqIfSd6nfui2Bc%= 3D&reserved=3D0 Abstract: This document defines an optimization approach for combining the lightweight authenticated key exchange protocol EDHOC run over CoAP with the first subsequent OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_HE1P18901MB0043BA1F14C90B1E5533FE2E839E9HE1P18901MB0043_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello CoRE,

We have recently submitted a new version of the draft "Combining = EDHOC and OSCORE".


This document defines an optimization for combining EDHOC (run over Co= AP) with the first subsequent OSCORE transaction. This reduces the number o= f round trips required to set up an OSCORE Security Context and to complete= an OSCORE transaction using that Security Context.

This update covers especially:

1) Having only one signaling method, using the new EDHOC option, based= on feedback from IETF 109 and implementors. This includes a reasoned propo= sal for the option number.

2) Improved presentation of the message processing, with an additional= optimization to save more bytes on the wire. The provided example has also= been updated.

3) Improved success and error handling on the server side.

Any feedback, questions or comments are welcome.

Best wishes
Rikard H=F6glund

From: internet-drafts@ietf.= org <internet-drafts@ietf.org>
Sent: Friday, February 19, 2021 19:11
To: Francesca Palombini <francesca.palombini@ericsson.com>; Go= eran Selander <goran.selander@ericsson.com>; Marco Tiloca <marco.t= iloca@ri.se>; Rikard H=F6glund <rikard.hoglund@ri.se>; Stefan Hris= tozov <stefan.hristozov@aisec.fraunhofer.de>
Subject: New Version Notification for draft-palombini-core-oscore-ed= hoc-02.txt
 

A new version of I-D, draft-palombini-core-oscore-edhoc-02.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name:           draft-pal= ombini-core-oscore-edhoc
Revision:       02
Title:          Combining EDHO= C and OSCORE
Document date:  2021-02-19
Group:          Individual Sub= mission
Pages:          12
URL:            https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-palombini-core-oscore-edhoc-02.txt&amp;dat= a=3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d501baca%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUnknown%7CTW= FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&amp;sdata=3DiXdZq3kzFp1UXkvww90lBINHn%2BCOOM7wNDVPXPItIFU%3D&a= mp;amp;reserved=3D0
Status:         https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-palombini-core-oscore-edhoc%2F&amp;data=3D0= 4%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d501baca%7C5a9809= cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1= 000&amp;sdata=3DrLWMVbh9GqJyETAsRlegmKe8HfFdGcQx2FlcAOZ%2BWDA%3D&am= p;reserved=3D0
Htmlized:       https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-palombini-core-oscore-edhoc&amp;data= =3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d501baca%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUnknown%7CTWF= pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&amp;sdata=3DE6CtZWyFoe6Hhc2yT1c5cGcSAv%2BKeqnB837rmHIlay8%3D&am= p;amp;reserved=3D0
Htmlized:       https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-palombini-core-oscore-edhoc-02&amp;data=3D04%7C0= 1%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d501baca%7C5a9809cf0bc= b413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUnknown%7CTWFpbGZsb3d8= eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a= mp;amp;sdata=3DPG3hMLCU6WDGzDVEt4TKYpdoIE%2BE32oH%2Fcyol4DCjw8%3D&amp;r= eserved=3D0
Diff:           https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-palombini-core-oscore-edhoc-02&amp;data= =3D04%7C01%7Crikard.hoglund%40ri.se%7Cbf2765aabd4f4656a07208d8d501baca%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493550707927903%7CUnknown%7CTWF= pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&amp;sdata=3DP22R8MdmgrrauizhjuabPfJNg3Ss4WqIfSd6nfui2Bc%3D&= amp;reserved=3D0

Abstract:
   This document defines an optimization approach for combining t= he
   lightweight authenticated key exchange protocol EDHOC run over= CoAP
   with the first subsequent OSCORE transaction.  This combi= nation
   reduces the number of round trips required to set up an OSCORE=
   Security Context and to complete an OSCORE transaction using t= hat
   Security Context.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


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

The IETF Secretariat


--_000_HE1P18901MB0043BA1F14C90B1E5533FE2E839E9HE1P18901MB0043_-- From nobody Thu Feb 25 01:54:52 2021 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 EFB403A16A5 for ; Thu, 25 Feb 2021 01:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 njVkvMtFRne2 for ; Thu, 25 Feb 2021 01:54:46 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2068.outbound.protection.outlook.com [40.107.21.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 569133A16A6 for ; Thu, 25 Feb 2021 01:54:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cJ/w9jvq6MPIs2G16OYG97eSxGEvoDA1i2bA4QytofUYfQDXjD1eo1meUz0WvKXsXM+Oh75m3hm0Z65K4lWntu+YFIsoHj3GXY4PIua/TBGfPrIvJLXz40S2SKy/0RZX0MJGL8sJylECw6yg+fzFkzGuXIyl4nXYoy5MalS0aM/aTokX6MAmhp9nSSVamTtBohVedCJFC6Aa8tEgr8+w3PokTveA5vqkogNmxcSH/DYM2kA8I8iPWJK9qlz2gtAYB0r5Yp4c2ATiRaVBi5IZpfvIKgOPglMfaW2cH3N/AiE0JcXqknmjkg82B47828j3nFRfKRBhntdqTLSHeg0BNA== 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=iqX9yDaf7KM1sBwH8WiNOgyJ9CpntKBnPBZijTHdlTM=; b=kSB/28602WsDY+P2m8H/EqiCiTJTZmZGfTks6siMy+8qbknV2WOfTNjZLSzQjMzk8sBC4oBpp0pZ6XtiEn4gXoldiano0M5FKa3FZonM8L791W2ZrxVlKVkXVZoQrQrY0kHBtsEUkWOwZetUB7W6z7yiLd6h/rGn1nSteneIUni50seLV0R7Ljn5uoC0P0z1TXKUwiSJyk3V/StMGF4vkRmMUsNXjLLIda2d+pMlljT7yuCodiHgrkUPkvjA3CSErH8zztvWZonkFU8ATPgpHDHLb7MUO9jfRahtKjJKCSB4YnUsjece9/CACQT/CAl9nePXIdxwb0ch3uQflCAPTw== 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=iqX9yDaf7KM1sBwH8WiNOgyJ9CpntKBnPBZijTHdlTM=; b=Oqz4wqcfpzNGHrEmTVFfNSLs0BK24Rs9YvHI/NMyhGRRft8erOq6hlBA2/ZfGt5kS07lhz/8IfNbho15VuzXNkbgS7xGeMfiuZzVdr+e9KK5DZvS48r3KSnUBsODpBZkx0eoPEcr0B3ncWvVtHx//YGdkKLMYAWbpnhwjHwCSkY= Received: from HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:9b::19) by HE1P18901MB0235.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:96::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.29; Thu, 25 Feb 2021 09:54:43 +0000 Received: from HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM ([fe80::300a:1114:baea:a1a5]) by HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM ([fe80::300a:1114:baea:a1a5%10]) with mapi id 15.20.3868.033; Thu, 25 Feb 2021 09:54:43 +0000 From: =?iso-8859-1?Q?Rikard_H=F6glund?= To: "core@ietf.org" Thread-Topic: New Version Notification for draft-hoeglund-core-oscore-key-limits-00.txt Thread-Index: AQHXBub/+RSmg8u+P0qWc+cs+0+fgqpoqnua Date: Thu, 25 Feb 2021 09:54:43 +0000 Message-ID: References: <161375663635.29021.5183681155799278431@ietfa.amsl.com> In-Reply-To: <161375663635.29021.5183681155799278431@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; x-originating-ip: [85.228.122.38] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a080884e-eef7-4794-3873-08d8d973603a x-ms-traffictypediagnostic: HE1P18901MB0235: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zZCbkJd55vEgeHtm05x7xkZ6vJfvQNKD598B6nvdlqWlPY259F06YEO7AvKceBEe8aWwBFjmiqdFbcIvaGpMHQjc5o+va2XUDx5994P5vzuK1iybcdc8m9XOugh2o7M0gjR6nT/JgfxsHAwTU3JJhKZkaZATyr9Eaq+7vhFpp7/jRSmT1uu1aq6dafo5opPexLnBN2x71VXWV2Zr69LsLxKo2QNGxfWmRDaEEDBKEwIA6H82Dwh3IFNqjyjnAGXJoV4gKHpzhm5UhuJ/aN36TK4C7oG/XXcaRQg+xuE6DX39SUw3rW5JWcMwi5mnWd4uII23O7FcbuBfXSuwcbA0ioCGkCZLvsprywMx+ioLJAaIaBT+uaDvVdgHjAaa9YYf8UUCbdNvZ3YM9aqxIHHotMfiAwzxE8vKkmW8Bi0NX6dfrZfo5E/g4mGTxtJUyP9mUQAKv9EiUBmvvH9bCmiKeEzDieFSbvhyL3khh/Rmz1TIs335Jb/xl3hGH/Wma5tsq0PHH2bduJpyzHQ6ZXjYntWWzjLMxczbqDhprCEp1txHzsFyOPppZzbPHOCsRPNXDmSf+Q2xzFiOI5EfUcUR4A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(396003)(346002)(39850400004)(26005)(186003)(966005)(15650500001)(478600001)(86362001)(8936002)(2906002)(316002)(71200400001)(6916009)(8676002)(19627405001)(66556008)(45080400002)(66946007)(52536014)(9686003)(166002)(5660300002)(6506007)(53546011)(7696005)(66574015)(76116006)(66476007)(64756008)(83380400001)(55016002)(66446008)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?AR02Gh84S8n+/AzYN5ceat7F6i6cDkyryU9Nh338h7sQUAChPuBHaH7TY3?= =?iso-8859-1?Q?g97LEZheccdTGuJNmynd7PQF16CT1TlXKIFqGmy4NsfNlYSI8d6YzjABHS?= =?iso-8859-1?Q?SWyV/6FhkUZ66LOsLVxcJ71qsfM+/+hjHVXl2bQiqkCU5tGQSb4XaGTjlf?= =?iso-8859-1?Q?n2GYIrvdx5fZ1hxQll9xnmrUcFDN9D68v7I6JN29Tx0OBAaMzhdfUeakzt?= =?iso-8859-1?Q?6E8QDWHt+y4g5HG6M2DHRxbLkrF7bJzM90qIEIdKEPA9lSP8QtGAp7gfN8?= =?iso-8859-1?Q?641EX525D89iEW3zktU9vdvmdkQJhmU6fCL+OKV3BaRMzpgLdPyPjXpf+O?= =?iso-8859-1?Q?6j1Yq0LjMEd4aie0bCXTuziXq257FzrgrnBM2rxovmYHISlTD6l7s8LDV4?= =?iso-8859-1?Q?Xl0ihbU8T3Ybx1C/rm+yN+nCSI0r4EQE86dN3n8Knrnp1xValLREU+qKvc?= =?iso-8859-1?Q?KLaB1eTDxukPipc6MTb1V3jy/660s7ucYWWdwHJZ4/WD0sZipL1o3V9GSM?= =?iso-8859-1?Q?ZCvRjva111goRDlsau5CHEteYMc+aFJN0AvbbQau2Y2Fo1cuwVTsWppXW4?= =?iso-8859-1?Q?moO0Elv+gqOcJnbrO5cSEuadeuu8VtyhQ6Uu+eT1ixMOqQydci+0vAhumK?= =?iso-8859-1?Q?YeF9K1wYjULyVrjukBlHSN3gihdwjTA/vjSwahc2ncCnieey7lLCrkJISi?= =?iso-8859-1?Q?qBqejuuBNwXNiMWgE/NtcRypacsYyObpOmn+ER7YNEH0x+Uy2nX134qK0K?= =?iso-8859-1?Q?KzIX+yDeDPmeZKVLytlzSkxKdrJb95XCpjSBNG1hgMbKiFeM6pGwMLvT4y?= =?iso-8859-1?Q?VcmhFh8fARlsV5419KBER6E3vNeDFeCbSkET/W12VHEUitUV7hRYYrKPLT?= =?iso-8859-1?Q?3h914hAbH+3ollK/5ogQGcpPVu5FRzykWr0B1CJXCI4GgowmEUanKTzY5Q?= =?iso-8859-1?Q?U6xPMvi4IDT/r5oaCLV/1P+57GSeAMtbSCOVyxNzaU3wDvk34waoBwHnTh?= =?iso-8859-1?Q?ycCeJrXx7f3+tGAcQdX73L5+C87w9IzDZBj/BRubJU1iMwtQ/2dB6LDN8a?= =?iso-8859-1?Q?H9Wp6zkztQ/X271vD/pMOoNkaA5lhFbTVEFN7ASKxobTifEQp0+nv1OuIE?= =?iso-8859-1?Q?plbe71qD2feLTthYLNbmzWpND9C3/NcGGwghTbvahcDF1w0Exnplkwyr+7?= =?iso-8859-1?Q?KW4+wKYDRKGu8kWUPo2iCW6MRWeiXWVHrtPDy96vNn8fF3LwQy7em+GFX3?= =?iso-8859-1?Q?dnfW095tAGBTAFAxP8vJWEmGYveuIUSGdrm+7UWn0WKE5erDooQCXOcZVt?= =?iso-8859-1?Q?0lUlLM+mpipnQ4igjY+YTpm/rgv0kjZwwth3LuGKAhAK6ms=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1P18901MB0043FDF359FA0A2A00734F77839E9HE1P18901MB0043_" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1P18901MB0043.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a080884e-eef7-4794-3873-08d8d973603a X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 09:54:43.0190 (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: 5A0RWowJvwXOCwmJaxLi1RXZTE3uJtqRUm2bQ1U3eohuUulOnf833JzolSfLnz0Pd4LN9trKS2bX/CMU+J67Kg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P18901MB0235 Archived-At: Subject: [core] Fw: New Version Notification for draft-hoeglund-core-oscore-key-limits-00.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, 25 Feb 2021 09:54:51 -0000 --_000_HE1P18901MB0043FDF359FA0A2A00734F77839E9HE1P18901MB0043_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted a new draft "AEAD Key Usage Limits in OSCORE". https://tools.ietf.org/html/draft-hoeglund-core-oscore-key-limits-00 This document considers the CFRG draft at [1], and accordingly defines how = two peers using OSCORE must take limits of the used AEAD algorithm into acc= ount, and what steps to take in order to preserve the security of their com= munications. This includes details on the limits for key usage, instruction= s for messages processing and a brief overview of existing mechanisms to re= key OSCORE. This work follows a discussion started around IETF 109 [2][3] and recently = continued with a broader scope [4]. Any feedback, questions or comments are welcome. Best wishes Rikard H=F6glund [1] https://tools.ietf.org/html/draft-irtf-cfrg-aead-limits-02 [2] https://mailarchive.ietf.org/arch/msg/core/bbzZCt6ZZn4ysR7yLujPNscBF3g/ [3] https://datatracker.ietf.org/meeting/109/materials/slides-109-core-sess= b-ietf-109-core-aead-limits-oscore-00 [4] https://mailarchive.ietf.org/arch/msg/core/h5JHgX5wTBkJtrKl_ezswiCdUBI/ ________________________________ From: internet-drafts@ietf.org Sent: Friday, February 19, 2021 18:43 To: Marco Tiloca ; Rikard H=F6glund Subject: New Version Notification for draft-hoeglund-core-oscore-key-limits= -00.txt A new version of I-D, draft-hoeglund-core-oscore-key-limits-00.txt has been successfully submitted by Rikard Hoeglund and posted to the IETF repository. Name: draft-hoeglund-core-oscore-key-limits Revision: 00 Title: AEAD Key Usage Limits in OSCORE Document date: 2021-02-19 Group: Individual Submission Pages: 9 URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hoeglund-core-oscore-key-limit= s-00.txt&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f31= 08d8d4fe1fc3%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63749353523658186= 6%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha= WwiLCJXVCI6Mn0%3D%7C1000&sdata=3DidqLof2Nf7U%2BsHyoO%2F0Pt%2FY7iazBHmn2= jBTZwSvzDzc%3D&reserved=3D0 Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hoeglund-core-oscore-key-limits= %2F&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f3108d8d= 4fe1fc3%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493535236581866%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC= JXVCI6Mn0%3D%7C1000&sdata=3DdEkYUUM7AN%2FAUpsEQ7SgaRHeMJBQA%2BekjZlZTwt= eSvE%3D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hoeglund-core-oscore-key= -limits&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f310= 8d8d4fe1fc3%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493535236581866= %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW= wiLCJXVCI6Mn0%3D%7C1000&sdata=3DpzoPc0ARBCQmxFqoPUXcm1nXSzSteZMfnLf7Wlg= %2Fqkg%3D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hoeglund-core-oscore-key-limits-00&a= mp;data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f3108d8d4fe1f= c3%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493535236581866%7CUnknow= n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI= 6Mn0%3D%7C1000&sdata=3DYit87j47zLL99nUJCWEywfgRgBHyCJMBYS%2BNQxLfIpE%3D= &reserved=3D0 Abstract: Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. This document defines how two peers using OSCORE must take these limits into account and what steps they must take to preserve the security of their communications. Therefore, this document updates RFC8613. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_HE1P18901MB0043FDF359FA0A2A00734F77839E9HE1P18901MB0043_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello CoRE,

We have recently submitted a new draft "AEAD Key Usage Limits in = OSCORE".


This document considers the CFRG draft at [1], and accordingly defines= how two peers using OSCORE must take limits of the used AEAD algorithm int= o account, and what steps to take in order to preserve the security of thei= r communications. This includes details on the limits for key usage, instructions for messages processing = and a brief overview of existing mechanisms to rekey OSCORE.

This work follows a discussion started around IETF 109 [2][3] and rece= ntly continued with a broader scope [4].

Any feedback, questions or comments are welcome.

Best wishes
Rikard H=F6glund


From: internet-drafts@ietf.= org <internet-drafts@ietf.org>
Sent: Friday, February 19, 2021 18:43
To: Marco Tiloca <marco.tiloca@ri.se>; Rikard H=F6glund <ri= kard.hoglund@ri.se>
Subject: New Version Notification for draft-hoeglund-core-oscore-key= -limits-00.txt
 

A new version of I-D, draft-hoeglund-core-oscore-key-limits-00.txt
has been successfully submitted by Rikard Hoeglund and posted to the
IETF repository.

Name:           draft-hoe= glund-core-oscore-key-limits
Revision:       00
Title:          AEAD Key Usage= Limits in OSCORE
Document date:  2021-02-19
Group:          Individual Sub= mission
Pages:          9
URL:            https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-hoeglund-core-oscore-key-limits-00.txt&amp= ;data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f3108d8d4fe1fc3= %7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493535236581866%7CUnknown%= 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&amp;sdata=3DidqLof2Nf7U%2BsHyoO%2F0Pt%2FY7iazBHmn2jBTZwSvz= Dzc%3D&amp;reserved=3D0
Status:         https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-hoeglund-core-oscore-key-limits%2F&amp;data= =3D04%7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f3108d8d4fe1fc3%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493535236581866%7CUnknown%7CTWF= pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&amp;sdata=3DdEkYUUM7AN%2FAUpsEQ7SgaRHeMJBQA%2BekjZlZTwteSvE%3D&= amp;amp;reserved=3D0
Htmlized:       https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hoeglund-core-oscore-key-limits&amp;= data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f3108d8d4fe1fc3%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493535236581866%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&amp;sdata=3DpzoPc0ARBCQmxFqoPUXcm1nXSzSteZMfnLf7Wlg%2Fqkg%3= D&amp;reserved=3D0
Htmlized:       https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-hoeglund-core-oscore-key-limits-00&amp;data=3D04= %7C01%7Crikard.hoglund%40ri.se%7Ce6b2a6a03fa3468b3f3108d8d4fe1fc3%7C5a9809c= f0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637493535236581866%7CUnknown%7CTWFpbGZs= b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10= 00&amp;sdata=3DYit87j47zLL99nUJCWEywfgRgBHyCJMBYS%2BNQxLfIpE%3D&amp= ;reserved=3D0


Abstract:
   Object Security for Constrained RESTful Environments (OSCORE) = uses
   AEAD algorithms to ensure confidentiality and integrity of exc= hanged
   messages.  Due to known issues allowing forgery attacks a= gainst AEAD
   algorithms, limits should be followed on the number of times a=
   specific key is used for encryption or decryption.  This = document
   defines how two peers using OSCORE must take these limits into=
   account and what steps they must take to preserve the security= of
   their communications.  Therefore, this document updates R= FC8613.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


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

The IETF Secretariat


--_000_HE1P18901MB0043FDF359FA0A2A00734F77839E9HE1P18901MB0043_-- From nobody Thu Feb 25 04:47:25 2021 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 41AE63A1960; Thu, 25 Feb 2021 04:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_hosNHhPznm; Thu, 25 Feb 2021 04:47:16 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862493A195E; Thu, 25 Feb 2021 04:47:13 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 63D1C4008A; Thu, 25 Feb 2021 13:47:12 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D6EE8D3; Thu, 25 Feb 2021 13:47:11 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8d2b:9123:ff:4508]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8B03F14E; Thu, 25 Feb 2021 13:47:11 +0100 (CET) Received: (nullmailer pid 1590284 invoked by uid 1000); Thu, 25 Feb 2021 12:47:11 -0000 Date: Thu, 25 Feb 2021 13:47:11 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Erik Kline Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com Message-ID: References: <161195926061.2651.9906207311487711748@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0RxofKuaOhiL7ULt" Content-Disposition: inline In-Reply-To: <161195926061.2651.9906207311487711748@ietfa.amsl.com> Archived-At: Subject: Re: [core] Erik Kline's No Objection on draft-ietf-core-resource-directory-26: (with 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: Thu, 25 Feb 2021 12:47:19 -0000 --0RxofKuaOhiL7ULt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Erik, > In the case (perhaps not the common case) there the RDAO IPv6 address is = the > same as the source address of the RA itself, the length field could be ju= st 1 > and the IPv6 address field omitted. >=20 > [...] > > I'll leave it up to the group to consider whether this is a useful optimi= sation > or not. Perhaps this idea has already been considered and rejected, thou= gh. it hasn't been considered before, but I think that the case is rare enough to cause more trouble than be worth it (for it's a corner case that'd receive little testing). One reason for this is that RDs will prefer to announce global addresses to get reachable base addresses (cf. Section 4.1, where we give guidance for multicast cases to pick global addresses). Thank you Christian --0RxofKuaOhiL7ULt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmA3nE8ACgkQOY0REtOk veE00w/9HmvVei+1BNuVanmxzYet6akm4bSeIqVrWnxDzP9eNHcyhHxs3+CJhVu3 PHioHP/ZXaDt3/24YYMCjvTYqIGWmqZKD+c1YMkqgo9CBpcQ3kw4VlJuXxCBShN3 V06Jjte/cfSJ2580kH4fEKureXEtmXZYvnF0kmgH8ZlmuOPmDSKg7k0j5Wg6Jrug IffmG29wUPqaaEe3LS1VKTIt1WyL5NNCqG2JZqH+iiAvXw4GGDTdZAL+d+RjfiF9 EDVTTx0Mi03NAIjDUZd8c2bHgO7mneYpKM0kVbvnE8x6++1ekIDxW+kpE2bEz7OI kwrYgb0yTQ7ax6yg2N0znauwZ3NNjJLONaDVvaJ1crlBBUQmKQnXcwjFcwO5dSNz RVWb0mLa+WDjXWg3a+3+ej8ZYVXveeBroThdR8AOwYR1ljDG9351pZG/fhSVMfL2 JLRDkGMJDjCFA57Lqy0dVsMqdAYBQfULzP1Bl8MI3mCbDFVfZd6Yw3FMf8sjQ1cp Hc1JsFrBtXcaq1v24xI3siVtgP5dT3/2WyhseScNrs1wpoyM77k7KyL2boUau2Dz OUaAD9Z8FMo+V7G1BGR9P1HHZ2jKTHn1TXJTCXEM0mFDB+XGycbB9ESocCWYazmC 7y8rRx+X3kr5HIB0kSxpIpMWxeixQD8OWRpI6agRwKok/cNyvq0= =VImo -----END PGP SIGNATURE----- --0RxofKuaOhiL7ULt-- From nobody Thu Feb 25 04:53:16 2021 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 C2CE63A196E for ; Thu, 25 Feb 2021 04:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=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 GdCm8mi2ZeOw for ; Thu, 25 Feb 2021 04:53:11 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::624]) (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 899693A1971 for ; Thu, 25 Feb 2021 04:53:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RcqypR8jNlfJOn/5dlI1ion4NNP69S2rObBZdX4KurFXvm/vAAlwn1nm66GmVBYEHk1Too0BrdgC7akh+7uxR5kEdImBOYrvZe/onjWFRUp3mbvUabIRGYDmLC8NVsPhz60vPbidqvr8vUedq/187BrMV4+X+roEkNvx6QzK/IzpuZyTcqq+iD0uvAJ40tlTub9/dCTn0mhEsX7+/RewYXU16V/ZBRgJpXqGc+khB/iQQcBzw2C+Rihi/wB4vgEZRMrQ96chsLmcbgPGty3BK9CV6za2Z8Z0rJ0XWxAW1jlmcUyFlgCMzYUF3cyjZ6J3tvgOlnFoCNcHlel/viuNAg== 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=RGfHvzU1eCfqp07coMU/cQw/Sb3g4UvD/DX7UVx/rd0=; b=a0GN7ThjWNn2lXJeFQyZ7NLwS25i3QHEGgeaWtuP+I4K276XE9kDrXZzfEm13Rww7p0sxElVV2RBEKxC4f1xw9luWJCUdWAAvna550Xg2s9IHyZmP8xeGoJadzKIOqB0ibeNhen8cI6JeZc3O4YNpaFYKOfE4fXlwKR/4BP5X1BpyGegJDjsISlt1JoJyB0b6NJu8PX350YwGHbh30IzQMtcYpgJU2gK2fh7KGhpo4QYshSwMtHweUWDxO76BaJQ8wY9JkUzLN9soEA/Ji3Ls3XRqUG8WXqRiqi4n7QQhmff9Nseg5QPBaXUhRvT4MuvbFxWdAUbHnzv0314f2E9tQ== 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=RGfHvzU1eCfqp07coMU/cQw/Sb3g4UvD/DX7UVx/rd0=; b=Pd0O/gBm7aUewAWzV+Fkl6+luR9Mb4i3+iwuYwohncyq+ew3Cwq47Mfj1CJsnoJRHv/RYQ7Dv1Q4Oqzt6cjHZPQ1z/I/PFK9UogwzkB4cGunTq6bxYhNqwYXNksEMLiJhYsG5+pjxcz4uiPawL9ZARYx5UR/yO2eGH4BiqIi7kw= 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 DB8P189MB0716.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:12f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.33; Thu, 25 Feb 2021 12:52:53 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3890.020; Thu, 25 Feb 2021 12:52:53 +0000 References: <161401287875.12908.16520416117230850265@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <161401287875.12908.16520416117230850265@ietfa.amsl.com> Message-ID: <92d8a3cb-1e36-ef88-2bad-c940ce226d04@ri.se> Date: Thu, 25 Feb 2021 13:52:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <161401287875.12908.16520416117230850265@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BntnNPpQPF8Oi6sUIiStlhEA8z1gxin4t" X-Originating-IP: [185.236.42.111] X-ClientProxiedBy: HE1PR0902CA0043.eurprd09.prod.outlook.com (2603:10a6:7:15::32) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.6] (185.236.42.111) by HE1PR0902CA0043.eurprd09.prod.outlook.com (2603:10a6:7:15::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Thu, 25 Feb 2021 12:52:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 885aac51-ed31-444d-ae3f-08d8d98c43f6 X-MS-TrafficTypeDiagnostic: DB8P189MB0716: 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: 6f2eiVUjQ+1j3gURMxk/zd9elm7v8WQntjzcrB4jOciyGSWZamm4FK7CO/KmhlRywROjAQz61XVj0hJTEB1GRl0RPoNQE2OqSPOFCLkHWmv36xtUCVHu/T4NJJYi2wxPEWjS0U5r6VvA7j3HWBvTDDhZe6I+UAbv5TYPqhKlJKKG++L1qiKD6IT0kPjEWyNjvbE2eKYkji1f4eMXF+LonkeEOvDjI9nOduhOgNDFRjdxaSYH5X4WGLFzVgvwMxF/9b1GupA2rwB3wF4LE0Wi9e20lN5Dp2EI46HjjusWjlTqLdL5loEscLLnt5dQhI/mRaDe7GEhdHfafov5vjkOWEfG484znZm4WDzHPbcGo4pLdVfXHJc+FC7/XNr8/ld+zECSh9yWh+uSQGAgBLRzhCOD+IWvFgGulncMSfNu1yKqTKZZe8aiVjTBbLj2UxfzXyfQeCZxc+MFUIF7zq7wr0v0Lz2WDNusWNYGJuBgRfwuMZ7PXurnYvuQWt40aVQUU3CLPf8GHzSdsvZASriOpXrQV4Iyjenf6gs8UXB8HHgvgSwXqWKgW+RrjRcsvcpZ75J6Lmu2ZZEo8g1YXMzbY2UNxGCRCKZYYc/2lVHu4LkAFf4wkqHZn9xxWH4CUOe96fLKRDB9ErAZjJ9jxU0+eyCpV3K9cY52nVUG+SnR7CFRTk8nGPRjgHzJqS/m4hUL X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(396003)(366004)(136003)(316002)(26005)(15650500001)(2906002)(956004)(186003)(31686004)(8936002)(44832011)(2616005)(66574015)(6916009)(16576012)(6486002)(66556008)(31696002)(86362001)(5660300002)(21480400003)(52116002)(33964004)(8676002)(45080400002)(36756003)(66476007)(235185007)(16526019)(478600001)(66946007)(166002)(966005)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?aTB0MElqb1FIZWJQKysxQnhQVjFSVWFNcVFOWlo2aEUyRHVQNkxEQmEvZDF4?= =?utf-8?B?MS9ka3BjRTJGL252VWJYQ3JLYzg3dWVhVGZkaG5hKytXazBlTHhnaDBqMDd1?= =?utf-8?B?b3FKanZVWTB5T1ZHUEJzYzc2c01NMnRXQ0FPN0VUek16YUtBSmVuWGx0VmVK?= =?utf-8?B?TlBXZEZyVld4dlhnZmxiVDA2YS9HdlQ4dlh2YXRROFhSWFNXa2dUWm9zRUdv?= =?utf-8?B?OWV5Smh5QWJtZUQ2OHNCU2JhOEVETWloc2dreThIM2NRM1J0STFPUng1OTdL?= =?utf-8?B?b1paM0ZIendIeEdNVThGZ0F5aXhya0x6WkhHQTRma0E5Um1sR2M5MUVyUUov?= =?utf-8?B?ODR2ZDV4WWtUZ2puV01BeVA5Tk9ua1FSRUI0RXZxOG15RHRxWVVtYk5zcUNK?= =?utf-8?B?LzJzRS95aTZ4N3pqS0FPdUxtMzRXajltMjVwbWV1aFZPUFN1dVY2Q2VxKytO?= =?utf-8?B?Y1grdEQ0QjRuV3lRMFB4VWtPNDB0aHUrWnlBYzk3OElaZ1V0dmVxaWxNLys0?= =?utf-8?B?cEZJcFVjYlp6blpka0FDQXB1VjA2aGN5a0JKZHkzaTZJZVpQK3piVVkxd1pZ?= =?utf-8?B?L3ZPektDTmxmUDZmZER4L0w2a2RCUWsra25RcWY4TjhPWm1UMnZTQ3VVU2Zt?= =?utf-8?B?YUVFSU9iSDlqck5rVFpRQnVnWG9FcVZoVHRPMTRNbmRZVC9jU2pFTWlpMWVv?= =?utf-8?B?NHpVT2wvZXFaSTdVK3ZWeHRnbDk5ay9VdDBsK3Q4UkYzRnFUYUVGRHNWVFNs?= =?utf-8?B?WnA0Sk5sSHNONjgycmdhbGJHUk8wSE9LR3BDQlNUZ1pWZW13MGVsdFJiaVR5?= =?utf-8?B?N2xRZlBGV0VyU1Q2RmkwbzZ0UUQwd3JSQkUveXhxZTZSM3F3akJnNlhTZFRj?= =?utf-8?B?ME5tbml0UUV4SCtZbnBxNm83OTdHcU9QWXZtOVdYN1FqMU9paHRYYmJGa2dZ?= =?utf-8?B?aXlqL3dCOW1qSGVUQTRWNHpWQU1LOHZvVXQyQVFqbG82UythWndFZ0pVY25i?= =?utf-8?B?VmNBRkdRenYzbWtiVG9KamI1WU9qNU5ZTkdRYlZja2hsS0VMM0R3eDVnc3F2?= =?utf-8?B?YmRrS1FaSWZWbTNVYVBvOGFBZGRwaW56eUo3VkI1dE5mNE4xdjVITVVGRGE1?= =?utf-8?B?ZndWWVhHNkluUVhHRE5Ic0NlOVBQcE1iWm5XSjErcVprVjFZcmdFaFZyYVg2?= =?utf-8?B?TDdtNW1aSnNrMENIUTd0Qk5xWkZ5eEVPTGtJTHMzalg3MXJ2a3E2aGpuaTVn?= =?utf-8?B?TDZKbnhyQzl1RW1iNHZDVGd3cUVFMjdwY05ReEtpb1pKN2hncWdBbEJvcWRx?= =?utf-8?B?MnB6MjgxdFk4SDI1NHA5V01lblA0dlRkQUFobDdXTzFkdjA1Y3FjVzM5RmtU?= =?utf-8?B?OWF5OS9XajJEUU55cHQ0WnF5M0oyQ0gwb2MyRzhTR2U3RlZnZjlobVEycUp2?= =?utf-8?B?T1Vmd0Z6T25oaFF2dGMreEk4TlhNVStDSlJjSTFyRTZoRVhLNFo3c1pWL3pj?= =?utf-8?B?ak5SU0dhTjAzR1R0MGhPS2lEVEdtcEpHbFpBdzRtOEFZY0thVDN2NGhmMVBt?= =?utf-8?B?aHF2cjduallJNmgydFdhdkxhQndJcENwaFZjdDNmSlhMaEZhRXlQUVVqekhq?= =?utf-8?B?aXFlLzRjY29TaXJteGVJZGtDS1RUOGJiNXhrODRWUUtrMmczczh2YnFjem1j?= =?utf-8?B?eWw5N2pWc1JIcDA1dzJ4bkJTakgxUGdLdExCSjRBcDNPbWIyb2QzT2gxUWVw?= =?utf-8?Q?Uo5cl6paOFLkeMHXgLrzT+W+q5Cv1S7xufMG82G?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 885aac51-ed31-444d-ae3f-08d8d98c43f6 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2021 12:52:53.3675 (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: VeMPzv4HZusKVTFUxyxXCS+RGurDrR3dNDWQBhQc/FvH4Z0sBFc8Azd1u8fmOHRKfvGCL/bj+KmxtsjNaOso+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0716 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-groupcomm-proxy-03.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, 25 Feb 2021 12:53:15 -0000 --BntnNPpQPF8Oi6sUIiStlhEA8z1gxin4t Content-Type: multipart/mixed; boundary="4y7nsscsCZnovLqGga6AMWJ92MiGDCXnC"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <92d8a3cb-1e36-ef88-2bad-c940ce226d04@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-core-groupcomm-proxy-03.txt References: <161401287875.12908.16520416117230850265@ietfa.amsl.com> In-Reply-To: <161401287875.12908.16520416117230850265@ietfa.amsl.com> --4y7nsscsCZnovLqGga6AMWJ92MiGDCXnC Content-Type: multipart/alternative; boundary="------------BA625FAB96B79C81E4D17F69" Content-Language: en-US This is a multi-part message in MIME format. --------------BA625FAB96B79C81E4D17F69 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an update for the draft "Proxy Operations for = CoAP Group Communication". https://tools.ietf.org/html/draft-tiloca-core-groupcomm-proxy-03 The document details the operations of CoAP proxies supporting CoAP=20 group communication and addresses the related issues identified in=20 Section 3.4 of [1]. In particular, a client can send a unicast CoAP group request to the=20 proxy including a new Option to indicate to the proxy the time period to = collect responses. Also a new Option is included in the servers'=20 responses, to enable the client to distinguish the multiple responses it = receives via the proxy, as well as the different servers originating them= =2E This update is especially about: 1) Extending the approach to cover also reverse-proxies as pointed out=20 by Christian [2], and providing related examples in Appendix B. 2) Aligning the format of the server address information to the same=20 encoding defined in [3]. Thanks to Christian for the suggestion, also=20 from [2] ! 3) More general rule for processing the OSCORE option when=20 OSCORE-in-OSCORE is used between client and proxy, as in Appendix A. Comments are very welcome! Best, /Marco [1] https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/ [2] https://mailarchive.ietf.org/arch/msg/core/Aoeiz7w0lv-unrnRgNjwFyOx_f= Y/ [3]=20 https://datatracker.ietf.org/doc/draft-tiloca-core-observe-multicast-noti= fications/ -------- Forwarded Message -------- Subject: New Version Notification for=20 draft-tiloca-core-groupcomm-proxy-03.txt Date: Mon, 22 Feb 2021 08:54:38 -0800 From: internet-drafts@ietf.org To: Esko Dijk , Marco Tiloca=20 A new version of I-D, draft-tiloca-core-groupcomm-proxy-03.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-groupcomm-proxy Revision: 03 Title: Proxy Operations for CoAP Group Communication Document date: 2021-02-22 Group: Individual Submission Pages: 36 URL:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-groupcomm-proxy-03.txt&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827590626%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&sdata=3DemE7tAz0%2Bwsf8OdXiAWyhk1z5BWYyszBMZ3e1rWMMoY%3D= &reserved=3D0 Status:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-groupcomm-proxy%2F&data=3D0= 4%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5a9809= cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&sdata=3DzDMf9ku9kwZL0fAgc3GEanYj8QpOcGLGRMHnxU5bxEA%3D&re= served=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy&data= =3D04%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&sdata=3DQNgUzrE%2FulQg4UHa%2BvBDjjVx0HFaJFKERhxH3xd8qhk%3= D&reserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= =2Eietf.org%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy-03&data=3D04%7= C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5a9809cf0= bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown%7CTWFpbGZs= b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 1000&sdata=3Dl7D4Y9MWwyN78tLJhNB5YlvE9wSg5NR5zLsVuZOkibg%3D&reser= ved=3D0 Diff:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-groupcomm-proxy-03&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&sdata=3DZ1PzgIN0%2BJgDiKX1IaxCy0OphSmQz0ZZ55TvO9kzZlY%3D&= ;reserved=3D0 Abstract: This document specifies the operations performed by a forward-proxy or reverse-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such CoAP proxy processes a single request, sent by a CoAP client over unicast, and distributes the request over IP multicast to a group of CoAP servers. It then collects the individual responses from these CoAP servers and sends these responses to the CoAP client such that the client is able to distinguish the responses and their origin servers through addressing information. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------BA625FAB96B79C81E4D17F69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an update for the draft "Proxy Operations for CoAP Group Communication".

https://tools.ietf.org/html/draft= -tiloca-core-groupcomm-proxy-03

The document details the operations of CoAP proxies supporting CoAP group communication and addresses the related issues identified in Section 3.4 of [1].

In particular, a client can send a unicast CoAP group request to the proxy including a new Option to indicate to the proxy the time period to collect responses. Also a new Option is included in the servers' responses, to enable the client to distinguish the multiple responses it receives via the proxy, as well as the different servers originating them.

This update is especially about:

1) Extending the approach to cover also reverse-proxies as pointed out by Christian [2], and providing related examples in Appendix B.
2) Aligning the format of the server address information to the same encoding defined in [3]. Thanks to Christian for the suggestion, also from [2] !

3) More general rule for processing the OSCORE option when OSCORE-in-OSCORE is used between client and proxy, as in Appendix A.<= br>

Comments are very welcome!

Best,
/Marco

[1] https://datatracker.ietf.org/d= oc/draft-ietf-core-groupcomm-bis/

[2] https://mailarchive.ietf.o= rg/arch/msg/core/Aoeiz7w0lv-unrnRgNjwFyOx_fY/

[3] https://datatracke= r.ietf.org/doc/draft-tiloca-core-observe-multicast-notifications/
=


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-groupcomm-proxy-03.txt
Dat= e: Mon, 22 Feb 2021 08:54:38 -0800
Fro= m: internet-drafts@ietf.org
To:= Esko Dijk <esko.dijk@iotconsultancy.nl>, = Marco Tiloca <marco.tiloca@ri.se>



A new version of I-D, draft-tiloca-core-groupcomm-proxy-03.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-groupcomm-proxy
Revision: 03
Title: Proxy Operations for CoAP Group Communication
Document date: 2021-02-22
Group: Individual Submission
Pages: 36
URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Farchive%2Fid%2Fdraft-tiloca-core-groupcomm-proxy-03.txt&am= p;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c4= 7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827590626%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C1000&amp;sdata=3DemE7tAz0%2Bwsf8OdXiAWyhk1z5BWYyszBMZ3e1= rWMMoY%3D&amp;reserved=3D0
Status: http= s://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatrack= er.ietf.org%2Fdoc%2Fdraft-tiloca-core-groupcomm-proxy%2F&amp;data=3D0= 4%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5a9809= cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&amp;sdata=3DzDMf9ku9kwZL0fAgc3GEanYj8QpOcGLGRMHnxU5bxEA%3D&am= p;amp;reserved=3D0
Htmlized: = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy&amp;= data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC= I6Mn0%3D%7C1000&amp;sdata=3DQNgUzrE%2FulQg4UHa%2BvBDjjVx0HFaJFKERhxH3= xd8qhk%3D&amp;reserved=3D0
Htmlized: https://eur= 02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2= Fhtml%2Fdraft-tiloca-core-groupcomm-proxy-03&amp;data=3D04%7C01%7Cmar= co.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5a9809cf0bcb413a83= 8a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;sdata=3Dl7D4Y9MWwyN78tLJhNB5YlvE9wSg5NR5zLsVuZOkibg%3D&amp;reserv= ed=3D0
Diff: ht= tps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-groupcomm-proxy-03&amp;dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4a9a81e67973414a688f08d8d7528c47%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496096827595601%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&amp;sdata=3DZ1PzgIN0%2BJgDiKX1IaxCy0OphSmQz0ZZ55TvO9kzZl= Y%3D&amp;reserved=3D0

Abstract:
This document specifies the operations performed by a forward-proxy
or reverse-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such CoAP proxy processes a
single request, sent by a CoAP client over unicast, and distributes
the request over IP multicast to a group of CoAP servers. It then collects the individual responses from these CoAP servers and sends
these responses to the CoAP client such that the client is able to<= br> distinguish the responses and their origin servers through addressing
information.



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


--------------BA625FAB96B79C81E4D17F69-- --4y7nsscsCZnovLqGga6AMWJ92MiGDCXnC-- --BntnNPpQPF8Oi6sUIiStlhEA8z1gxin4t Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmA3naMFAwAAAAAACgkQ7iZktA5Y2kN6 9Qf6AjCZrmOgPJaNYbG99XTLngD09NSNc/Nj9lyjDYGZSDeJCHGwBgI0e7ddbyaIqtZcWCC+rkNm NBnN17HwfdgDUEL8IXNh9zO5OR6sfygA0yO0XYgROcSfX4RIZQQeVOeioLbQZPg5eFJn3uElQduC A7rs7ZJRdiPNQmp88Nax7NQaDriFPBuIE6QxXOp28h8lpQ18A+PEudy8sowlUTusT3I0DyRgOstU iuGLpqzSn3TdGZg3IzdsXNb3jFDGx1dxp1MFUZlq4/qD1ClYxYMpD7rB1Uc7E5Hm3NOGvteehxN/ gnusnzVEciqFrZC6dHh4b2v/wXd+yK2HotzZFFuXyA== =kTQY -----END PGP SIGNATURE----- --BntnNPpQPF8Oi6sUIiStlhEA8z1gxin4t-- From nobody Thu Feb 25 04:53:43 2021 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 83F773A1973 for ; Thu, 25 Feb 2021 04:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 QJnwoQrTe3IZ for ; Thu, 25 Feb 2021 04:53:39 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2089.outbound.protection.outlook.com [40.107.20.89]) (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 BA4E63A196E for ; Thu, 25 Feb 2021 04:53:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mvwVDuG+hN/NRLosBX1ziYGqkgXULyYm/hH0W4xrxJfci/Ose+zeuvajtcC9AxXCeyBygtd0m0FnvT60SOjB1VFflqo3nZRfAuW5YApeO0pehZyDOPby4cTvtQv7Da7Op/Cny4y3Ov4HITBFESETFph9bRdPmaMnKoYMZNWePnfkdCKP2B2yDwDDTcrcwZKBznLZJwIDmCYEq0T/MBb3ZSROCtiWn/0A3IC8HFrURGUyhNIOVBnMvmMzyyKyqcskSN8EMO6c/5bcWwSdIWKRqhhTE52JLKNNjMYDfPEVJDLc+5hQe89trTxXRTUsdXE/7n3Jp8FrlVRffiiOyGbEyw== 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=nUczi0Emq/fregUhnqsAwOZoZqgjDQdR9HNj46lW/gQ=; b=H7oVD170ElOWIXjyNk1W/FRQeN/OlauCsYUAkwADXZ+Xnu7QmTZqQuQ0HmSvXVas7iTTi3W7ouHZpZNL/a/v8GGb60VSU6Bvm8BzH79DDHdRoYgAMD/ApkoQP8M7MwdAnz00ESNsG8wRG9pG8g34Qa+59vFL9Io2GCP31Ei7uTQqmR000VW0pfqVu/CSqitQ1I6tv8/59uHI/0q+gZ6b6YO5I9jPiXfGEDnSiqDqhVWayZoF2I24/1Ej2j6gudro8S3rfk3bRQmCtXxpuO3EXFdp8oB9qwlP2c6P2h+AnSzu0MNw5oMMrK/S2EO341ailoSzLtHPAlCS20VwLvB3+w== 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=nUczi0Emq/fregUhnqsAwOZoZqgjDQdR9HNj46lW/gQ=; b=iwwGQDMbDCU/flhh/NqSvlcAa2d3y3rKw/jqBq4b+VBpM4KE3jGF9dNvctSYg/Wtd4FSa9K6cJQTwS6Txp9Wj2Dn+m+OR+Ah74z1mDfRpX0DOqrhAoy2vMJ/ATxIPQ3ON/SidcHI2ja0hS3gxyyF8/wYstIHUl80Due6089ClEw= 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 DB6P18901MB0037.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:25::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.33; Thu, 25 Feb 2021 12:53:35 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3890.020; Thu, 25 Feb 2021 12:53:35 +0000 References: <161401313911.16964.17515374415578341016@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <161401313911.16964.17515374415578341016@ietfa.amsl.com> Message-ID: <7b2f4dc9-8a35-4def-8ea2-2a51d01081ea@ri.se> Date: Thu, 25 Feb 2021 13:53:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <161401313911.16964.17515374415578341016@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BVrYaVVYjgyiewTUYtC08S6EFQ213MjTS" X-Originating-IP: [185.236.42.111] X-ClientProxiedBy: HE1PR0902CA0029.eurprd09.prod.outlook.com (2603:10a6:7:15::18) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.6] (185.236.42.111) by HE1PR0902CA0029.eurprd09.prod.outlook.com (2603:10a6:7:15::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20 via Frontend Transport; Thu, 25 Feb 2021 12:53:34 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 76e76fa0-887c-43b9-6350-08d8d98c5cb4 X-MS-TrafficTypeDiagnostic: DB6P18901MB0037: 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: pWgIPD1qhCP4vY4agBYu/xh+FbC/l7lv/v56pS19RFU3UtEFCDsdvllbmw6OVhXj3FXXfgJSiNTmauowAdIF2cdlOp4UCvjtd+1w0+oyPsoOcjITtw7drVrWz5Juyhmp4aKU+hqK5cVQT95SNriVk2KBziM89Z49itRWKOs5WdFedYzdt80R14GsnUuh9qzkOWDHcARJLJOsmQzKxX9SFIiwgRNtIMn0qd+NMKnhj4wHhuvdA+c1hPpDf/bS6HFTJAci6FYuaExMnd2eO+1YuGyN0mosg3OReyoXyejaaS8lCyBCi2IDwtX62FNnJqg7iEw3eOmsWsTONOS4SdACzDA5ZfS/2m+gQee0tJORI4jquUmULbWMYb6i/ZADd3vFHLGXsz/cOEpMz107m9bH6u5rwOYD7Om2VtbuAFt/CCfv62d8RQxQ+M0fZKsoU8xrdTa/pylS6CGSR5MIod675K5Iw8017bwJmXoQvk6opo/VAY/ZNkLeVxZjo4cNGCVWtpJBNb1FybhzPOVGco281lNM+7+yWkaN/phPzhXxWC9ouJ8g5v2ihVGszIzREjRuvFQyab+5H/dM+F8C21z4MEt0fNVvqG9CQEAyaon3/dvSNRi7ALWHaS6MTenuNjJutp1fjzh1h5d+TJKshZrxpY8b8KtRbMBe8wiGf7lGRhJfzqMD6ayOZR9SIcrB1dFD 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)(396003)(346002)(366004)(136003)(39860400002)(316002)(478600001)(33964004)(52116002)(45080400002)(36756003)(66574015)(83380400001)(15650500001)(966005)(166002)(31696002)(2906002)(86362001)(16576012)(956004)(2616005)(8676002)(8936002)(6486002)(21480400003)(6916009)(66476007)(186003)(66946007)(31686004)(66556008)(235185007)(44832011)(26005)(16526019)(5660300002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?MHordlBsN2h3REU5VnRTTFNENTBsZUxvazlwMUpCdEFLZ2dkWkhIK0twZ01C?= =?utf-8?B?bGMxNGM0RUtnaGxuMThXeStCWGNuUE1TVVRTRUNGZTVzZy9UQ2RaeWFpSE1N?= =?utf-8?B?TUZBUW9HUDNCQWYzZWFhWkg3aFY2b1B3WW90OEdCUlNKR0xwMkQ2ZGFnU0Qy?= =?utf-8?B?NXlCWnZDY0RKT0VuMTNCV2pBK0hDM3VFQmNycW1OL1Y0a1JOY3Mycm1NOWxP?= =?utf-8?B?YzlnNEc3bU54Tkp1Vm1USUhMM2xVNTZRcVJqSjVxVCthOWc0SFptU1V0Z2dv?= =?utf-8?B?bTcvVW9FU3lPSTBhdnNMT29rNEEvNGZNa3NHaHJaU3I3VlI2dTJoalErZ1ly?= =?utf-8?B?aFZTTWpVYVFVam1Rek1ZaE4vODcrUnFYNDhqNk8xd0Y0bzhFUkozSitBMUVO?= =?utf-8?B?ck4zdmdoTWhrb2dQcjZHY3ltWWQxZ1lZYW5uMVFVaDMzeDR0TXJJWlNkMnl1?= =?utf-8?B?M0hvTno4ZWZ4NnJ3K0hhd1o1SHlSVWZYaDY3TDAraUxVSmkxMWlFSkhrZVJh?= =?utf-8?B?akN5aVh5cVNlWDk1NGNTbHp4UVNsQTJOMDZhTW9Mb2JYQllDTHNKdk1rakQv?= =?utf-8?B?ZGNhV1FsNlRkTGtndkFJWThzNUViUzZ0MTRmUElnY2RwclBWSTZ1ckw5Vm85?= =?utf-8?B?dnpxZ2ErK1JtdnB6MUNOZUxCT2hQY3FoZ0xnWG9weUJocVN6NnE0Wmd1Tmpo?= =?utf-8?B?Y3htS1k0T1luZjJqOVBpVmJJSWNIM3lPWFMwcVNHaUl0a0JyS0xsUGQ0WmZa?= =?utf-8?B?OTJCamVGK2wwa1E0cUJqTGJ4MEM3QXY0WnV5V2oyS1NqOC9mNDVuTXRTL2o5?= =?utf-8?B?ZkN6dm55anJQbGFmeFphM0d5elFXTC9JRFh5MzFHRmJwV1plb21DbXFRTGdK?= =?utf-8?B?elRhK3ZWNUdzZ2s4enFSOXRHUzh6STZGTkE5NDdmVGt5dzRocXlvMlpUOXV1?= =?utf-8?B?UVdYV3c1aEZDa1hPVXMwaWlCbUxrL01sVVNTeTU4TWVkR0NOSEkzTXVFZHNI?= =?utf-8?B?WWhSTUxvYWlBOUp5OExVNHZ5SUt0ZzlzNUZPVmZOMElLOVlEaWozTDFUcXdO?= =?utf-8?B?Y0hPZjkyV3BmWU5RMUxoUXFCbGZVNWZaM0ErcTNJVWhoMDlXdmlXT21RMzF5?= =?utf-8?B?MUN3NjY0eGVqb2V5a2F1UGVpZjBzTGJobU5tMDZxckVZNnYxVHlHRnlDNEFZ?= =?utf-8?B?MndHZnloRlZuT1NuSDFZWTB1WjJhLzBITEx1NkM4dzRQU2k0ZUVEZ2tvL01z?= =?utf-8?B?THVubXB5dmY0MG5WdnQ5Q1FkaDZaSXJnNDlJbVVnZE1sUUs1Z0kxRWdpT3JY?= =?utf-8?B?WHJYVmRWdDJCQlBSUlF0TG4vdUw3TGhjT0VoVlNiTERFbys5UHVEUmlhNSs0?= =?utf-8?B?Y3BYR2ZJcXc4dHZJN0wxdWhkMGhwVDNuMW9Sbnk3ZFZPd20zSCsyODY3VzNo?= =?utf-8?B?REZicEFlczFSZ2dIUWEvK3QwcFZaUy9tUnBGaWVBTElzYU1SWDVRdzdZcHkw?= =?utf-8?B?bTM4djYvd1drMDdpTU5laVB1MHpPVEtXN3NReDAwNXVpQ1JCTFVlOCs1MDRO?= =?utf-8?B?RG1BVWZoNE9pY29tdFIvOWRqZy9NV2pmTm9QNnJMZmd2ZG0xS2FMaFRQdnlp?= =?utf-8?B?OUhDZU0vUXpqc3ArNDljMjRvMUc4b0tXZkQrbU16Q0FxUldyemRSamR1NjZt?= =?utf-8?B?bTJ3a3ljU2dmTzJoSVFJcWtqdGl0ek4vV1c5anVTZG4yMm1XWW5Tb01nTU01?= =?utf-8?Q?icC7f259fnG9QcVWpG3DEDaL7gYdPNu7gFIr4f4?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 76e76fa0-887c-43b9-6350-08d8d98c5cb4 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2021 12:53:34.8791 (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: DwsvaVwGplSH4TKEhBYMa4mLVRM0jewHbYukbF5mEW/iL0wfle3M7/Vte6UEAoKN30BiCWtz7JnlqdBQ8r6VvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0037 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-oscore-discovery-08.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, 25 Feb 2021 12:53:43 -0000 --BVrYaVVYjgyiewTUYtC08S6EFQ213MjTS Content-Type: multipart/mixed; boundary="UrMWZ02CFZllex2mcPDfPphHM9xbJ0mw8"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <7b2f4dc9-8a35-4def-8ea2-2a51d01081ea@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-core-oscore-discovery-08.txt References: <161401313911.16964.17515374415578341016@ietfa.amsl.com> In-Reply-To: <161401313911.16964.17515374415578341016@ietfa.amsl.com> --UrMWZ02CFZllex2mcPDfPphHM9xbJ0mw8 Content-Type: multipart/alternative; boundary="------------EAE310D3788B8A7929F0234E" Content-Language: en-US This is a multi-part message in MIME format. --------------EAE310D3788B8A7929F0234E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an updated version of=20 draft-tiloca-core-oscore-discovery https://tools.ietf.org/html/draft-tiloca-core-oscore-discovery-08 The document describes how to use the CoRE Resource Directory for=20 discovering OSCORE groups, by retrieving the link to join them through=20 their Group Manager. This update is especially about: 1) Adding target attributes related to the pairwise mode of Group OSCORE.= 2) Considering also additional types of clients querying the RD, e.g.=20 signature verifiers in Group OSCORE. 3) Using the content-format "application/ace-groupcomm+cbor" for the=20 links to join OSCORE groups. 4) Fixes and improvements in the examples. Comments are very welcome! Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for=20 draft-tiloca-core-oscore-discovery-08.txt Date: Mon, 22 Feb 2021 08:58:59 -0800 From: internet-drafts@ietf.org To: Christian Amsuess , Marco Tiloca=20 , Peter van der Stok A new version of I-D, draft-tiloca-core-oscore-discovery-08.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-oscore-discovery Revision: 08 Title: Discovery of OSCORE Groups with the CoRE Resource Directory Document date: 2021-02-22 Group: Individual Submission Pages: 33 URL:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-discovery-08.txt&da= ta=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%7C= 5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423582420%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C1000&sdata=3DDoXzVcYi8IaOKiIzM6WLjUqb4DMpyQE6PTK9sxhpgUM%3D&= amp;reserved=3D0 Status:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-discovery%2F&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&sdata=3DbiebqoqEq4PIAxHqCF5CsLGaMKaXuHCejKRFxPWaHGI%3D&r= eserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-discovery&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&sdata=3Dq3Crv9FVCNJYIZhTIwijEEr5H4inGAmDw4uXPwpbn14%3D&a= mp;reserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= =2Eietf.org%2Fhtml%2Fdraft-tiloca-core-oscore-discovery-08&data=3D04%= 7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%7C5a9809cf= 0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C1000&sdata=3DeEgrnOiHmXoF0Ew1vl%2FAKSeY3StOk8ZU%2By6YSYSJoek%3D&= reserved=3D0 Diff:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-oscore-discovery-08&data= =3D04%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&sdata=3Dr1pDHs6SsIWRGskPM85%2F8zR5Juuiye1mPKE0fF%2BPHBU%3= D&reserved=3D0 Abstract: Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------EAE310D3788B8A7929F0234E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an updated version of draft-tiloca-core-oscore-discovery

https://tools.ietf.org/html/draf= t-tiloca-core-oscore-discovery-08

The document describes how to use the CoRE Resource Directory for discovering OSCORE groups, by retrieving the link to join them through their Group Manager.

This update is especially about:

1) Adding target attributes related to the pairwise mode of Group OSCORE.

2) Considering also additional types of clients querying the RD, e.g. signature verifiers in Group OSCORE.

3) Using the content-format "application/ace-groupcomm+cbor" for the links to join OSCORE groups.

4) Fixes and improvements in the examples.


Comments are very welcome!

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-oscore-discovery-08.txt
Dat= e: Mon, 22 Feb 2021 08:58:59 -0800
Fro= m: internet-drafts@ietf.org
To:= Christian Amsuess <christian@amsuess.com>, Marc= o Tiloca <marco.tiloca@ri.se>, Peter van der Stok <consultancy@vanderstok.org>



A new version of I-D, draft-tiloca-core-oscore-discovery-08.txt
= has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-oscore-discovery
Revision: 08
Title: Discovery of OSCORE Groups with the CoRE Resource Directory<= br> Document date: 2021-02-22
Group: Individual Submission
Pages: 33
URL: = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-discovery-08.txt&am= p;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d753270= 1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423582420%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C1000&amp;sdata=3DDoXzVcYi8IaOKiIzM6WLjUqb4DMpyQE6PTK9sxh= pgUM%3D&amp;reserved=3D0
Status: https= ://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracke= r.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-discovery%2F&amp;data=3D0= 4%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%7C5a9809= cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&amp;sdata=3DbiebqoqEq4PIAxHqCF5CsLGaMKaXuHCejKRFxPWaHGI%3D&am= p;amp;reserved=3D0
Htmlized: h= ttps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr= acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-discovery&amp;= data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC= I6Mn0%3D%7C1000&amp;sdata=3Dq3Crv9FVCNJYIZhTIwijEEr5H4inGAmDw4uXPwpbn= 14%3D&amp;reserved=3D0
Htmlized: https:= //eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.= org%2Fhtml%2Fdraft-tiloca-core-oscore-discovery-08&amp;data=3D04%7C01= %7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%7C5a9809cf0bcb= 413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown%7CTWFpbGZsb3d= 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100= 0&amp;sdata=3DeEgrnOiHmXoF0Ew1vl%2FAKSeY3StOk8ZU%2By6YSYSJoek%3D&= amp;reserved=3D0
Diff: = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-oscore-discovery-08&amp;= data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cea90a03cc7c24123548308d8d7532701%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496099423587409%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC= I6Mn0%3D%7C1000&amp;sdata=3Dr1pDHs6SsIWRGskPM85%2F8zR5Juuiye1mPKE0fF%= 2BPHBU%3D&amp;reserved=3D0

Abstract:
Group communication over the Constrained Application Protocol (CoAP)
can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may
not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining
process. This document describes how a CoAP endpoint can use
descriptions and links of resources registered at the CoRE Resource
Directory to discover security groups and to acquire information for
joining them through the respective Group Manager. A given security
group may protect multiple application groups, which are separately
announced in the Resource Directory as sets of endpoints sharing a<= br> pool of resources. This approach is consistent with, but not limited
to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments.



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


--------------EAE310D3788B8A7929F0234E-- --UrMWZ02CFZllex2mcPDfPphHM9xbJ0mw8-- --BVrYaVVYjgyiewTUYtC08S6EFQ213MjTS Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmA3ncwFAwAAAAAACgkQ7iZktA5Y2kPw mggApG3axiXz5lNpnNkSqa8LNEV9OROgXa2lKwQvl4z8q61fikJ8O8RNocnh2ShXD8KkkosNx+5S DjYELr0uzxCN1i+bdJKXcG47l6YmsPLE9zvEjkDsNPxAQMgJ6ydeJkYaHGqeXmPpQgDylmu5hgoe dJj4xENnC29W1mrav/IRNwyWLeZFnPvkfYLWdXUQde8Q46tADpyLnCZ5f72YoMiwphaBfAlTrM0z djQR8C2VNTNzYdb+MtMpJ8NsyjCWIE4f2r+fJxrcBlcS4ODgWbjs2PEgsnNx0PJ62NDwYcktUyf8 ItjOHRZqTaBsQgJshvjGhbAOSEKfgsif70NqzPFenQ== =frPG -----END PGP SIGNATURE----- --BVrYaVVYjgyiewTUYtC08S6EFQ213MjTS-- From nobody Thu Feb 25 04:54:45 2021 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 A52813A1908 for ; Thu, 25 Feb 2021 04:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 amr3Rt6TgJ6X for ; Thu, 25 Feb 2021 04:54:40 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2084.outbound.protection.outlook.com [40.107.20.84]) (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 0E56F3A14C9 for ; Thu, 25 Feb 2021 04:54:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RXuyYpbZMX7eLpnxwOuyLGzJloEufAkVM471+CTt+rdiFNUvaLFebXyBXp1pVsGqATgLj4M/Pyev5YuF6tQa1Jblg7/nLaniMZmSnUfM6hewS9ueowwID187uTyGWlD0j1jMLqw7QzUqflVi6iZMD8ykMVdSrGta29ahZkFc41fYUxUWNnquvzrb0zelyIR+wHAO4cQCySJ/ZX9RuqHfxmLZcDcErdr+zRJmqk29uU/PWjh1YGddEQ4Rk/wmfJvlgobgQXX1fKeLS3nsL4qY/mKBd0Condw8jpofcc2GmrVPB4WaacM2YwpdQhcWKNFu7y5GtLo+a7b8QJNPsMiH2w== 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=s1QveTW3eki/WgHKiMOscOPvm161IN/QRzzMIMw4bJw=; b=HAc4J8UQpMhAh+a2H1Mtd7mzc6piOFtWYmGiFReny3P/Bv8Huu/qZk+CE8oPbeKIAq3LnzX89kkPf/pFLI5VsFApI13r7C9KCpU9JtYUE3sMgnZHqy974cuQ7smh+ovzNho5nTrDhHOetYR63+wip+gFZj0kJ0/2lhvZnAHaWHa9+6ofDhx8QSsqw+7xJ5gEcSS49G8QShUVzeqeRbMAP5S9ylVbwccA1U4YuCWiuN2aK67VWlUpyDdjUw0eEeUhIF0IVaY37ZK1Xznpuk0Y9e9hU1mOKnnhBQf1UPA6RTlYxcj14pfXxjskxL/xSekUWdqIeH2i+mwTc58GDc1L/Q== 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=s1QveTW3eki/WgHKiMOscOPvm161IN/QRzzMIMw4bJw=; b=f/98SK4Mkcjo8DFP6wYgu2pUI//0cHmCm6Ssvmq4qmPzhndZPeSug2kFh2ywyqpjEt3FoGIAzstg+VUd/3wcwU6kUuv1CK/zg2SnbI6hpRi3qxHguVwlNnxmVlkaQMmR9R43qrKZ4oElnyOP/GN0T0TYpJ4818Wciei8ZggFtBM= 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 DB8P189MB0650.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:12b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Thu, 25 Feb 2021 12:54:36 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3890.020; Thu, 25 Feb 2021 12:54:36 +0000 References: <161401302982.14028.14113860823096266335@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <161401302982.14028.14113860823096266335@ietfa.amsl.com> Message-ID: <038d11dd-768c-9440-42a8-3a729c6e6c5c@ri.se> Date: Thu, 25 Feb 2021 13:54:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <161401302982.14028.14113860823096266335@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kmwMipin2ntHmnq7q47TY1iOUYPRjBVtf" X-Originating-IP: [185.236.42.111] X-ClientProxiedBy: HE1PR0401CA0050.eurprd04.prod.outlook.com (2603:10a6:3:19::18) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.6] (185.236.42.111) by HE1PR0401CA0050.eurprd04.prod.outlook.com (2603:10a6:3:19::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Thu, 25 Feb 2021 12:54:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 001153e2-0d2f-42a3-c82e-08d8d98c816a X-MS-TrafficTypeDiagnostic: DB8P189MB0650: 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: +IXebbKzmO9Qw4xkujm1vDBXMTlW7P9JnljqpyCIeMthctM7UM5BYRmA7Cy3Q9GNNfdOdkBLhIPIyJMSa10S49XoT5XPwlylv/S3dVCLvKlA2oh0aW7DRDDOB3EIuSrEIDRbrfU6UnQbBhZclUxY8J6Uy7y/Ws5c2bLfU2ugdDhKKOhqqTqQYnSaxg70xf1gfWG6/KcHKMZ705ZRdibxCuYRge1/rXbr3esKpmA8lkKd4IkSivmgsyhzFN81WG6PSqXF6o/2lW2rfHcWUpHgDhD4fH25vXQ44lCie7vix05BXQEJHpEQ5eSO0HRRsPYN58IFiKhwrwMIbnt0T730qqz/npU8/KS2WtMLZ0QshkorWtoqSMePPIZk9Qn2nGSDkHmq+b+bEoGYF+tCmydaqc6TUqMxUbge6sUUrZMhGoO1zB1cUGkqa9sbHgk9GxpECEt0i7mJkQNhyvsiycvyT5ruViqhsTBEuXCbnTJ429XhDaKG0IQDU1frBy2GxWrk7V9cmU3aExEUgIjFyPEy5xWLypAWOyfXv+5Xq9diKCntRyKaqEhuCT2W7rYV0iZKIqIlC4ohVpf+9ee4/RuOpIr0xLBhGFg6oBr3ok/ugrr0TubNwe4f2469gHZS7GZ1/gOdJQWC2C7xe6tmlno+MfDu1iDVg756ykdUBKqWvi3DiWxuTidUCnQIZU5/VvGx X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(39860400002)(396003)(136003)(346002)(21480400003)(26005)(186003)(8676002)(66556008)(36756003)(2616005)(66476007)(66946007)(31686004)(8936002)(16526019)(86362001)(44832011)(966005)(33964004)(316002)(83380400001)(2906002)(6916009)(52116002)(30864003)(45080400002)(31696002)(5660300002)(956004)(66574015)(15650500001)(166002)(478600001)(235185007)(16576012)(6486002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Qk1FZXJ4SDhyUC9QcnFPTFNxWFVtZHk0TkQxZ1VSR2lCVjd4NjBHRDZnYXN0?= =?utf-8?B?MkZhOWx6QnhnVTJCejF0eXBKVGlRZWtxbElTQ0dSODdTQkZKNFBRTE5KMmZl?= =?utf-8?B?bVJKVTVoQi9COUtuT1lxUEFkOTA2ZFdBNk9CaExobW8wTi9lM2tPaHFHOWxl?= =?utf-8?B?eWpZemJPK3BNMnpncHVuT3dGSXh6aUFYVkFGSjF2MUZ5WHZ5NE5tNFFaTTRJ?= =?utf-8?B?UWJkcUN4K1ZKakliWnozVzVaYlZkWXVLMnRKcXlDYUNadmtpZ1dIZjFuOXI3?= =?utf-8?B?bGVTRWo2eEhrU0VqODF0OWN2VkJnOXN3ZHdiM3d3akVOR0RzM3pyY3plWmFa?= =?utf-8?B?MkhiVXp1bWRiQTI0Wng4SWdTbGY1Q1VXZkdnbnlGdDV4aG1VWWMxQ0dmYXc0?= =?utf-8?B?YzlZb3JFYXFIZmhYbS83VGp5WkppSHBib0o5UVhabktTVHNQWVdBUjBwYTFR?= =?utf-8?B?NEZERHRRNWpzQVRITFE1NDF5VU4wZlVGekFGbTdDYzFNbUdFMWlyNS9jQjZH?= =?utf-8?B?T1FtNVJHMHFCb3RVbndyOEd3WGx6ODRmREtZbTg4aTZhUUpBdDdqMGFuWkpw?= =?utf-8?B?UytmWmxJazg5M21XcXRKL1pmY0JtQ25Gb1F1MVdoQlBoTVIzR3h2ZFp5djRD?= =?utf-8?B?dEpJdWhIQ1RZVSswWDdML3U1em5ldFQyNHZ5ZXFIa1A2QUFiMSsraS9Vcm9k?= =?utf-8?B?OWhubXNDVGZOK0pKS293TU4xQWJIZlkrQnA3aFRnSnRwMVBFZVNST1FsNnRs?= =?utf-8?B?bXdTZ3hQWDdNdEVwcHJlaUZqdHdQa045RTN3S0lvVFo0S3MvSzlCRVREY081?= =?utf-8?B?NnlRTDd5bC9HY0ZoKzFWVDBZMm0wZ05VcW9iZVVDb1pabW4rSWFHZ3FUMVVs?= =?utf-8?B?cjg0YXlqYXVvc1dRQXBlVXVqa2tmU1ZWcXJWMjhORTdRK1BHRWtsMUJUTjdv?= =?utf-8?B?YkxJa2ZQSkxCUE9WR0RSeTNBcE5yTlU3TSt6d25KNGVuY0lyNDE4T0x0ZVZ1?= =?utf-8?B?WndqS2FmenNhNHV2ZHBiWEt3emtuVG4vQk9pQWVGY3JyMXdVREpxeGZrcHhm?= =?utf-8?B?NlYyTEtqTytjNWJ6QjNHSW11NE5YWlM5TkNzL1lhWU5GeW5reGlQWmlqZXhE?= =?utf-8?B?ajZFQ0JLREJJeGhDdlpXcXVTR2V6UXNMTlRRd0hncWM3dTNnSVh2TmlOUGNn?= =?utf-8?B?akRwWnk0c0M1TDYwdVNuYnZWNGcwbEhnWTdyeHY4cHg1bWM3MFVvUmJvYzA4?= =?utf-8?B?RjhQRU9SM0VZRlh0UmZtNHFwaDJSbDBDbG5EK2QxbEE5NzFFVGFUbzcvTkZ4?= =?utf-8?B?VVM5dEZHMnBvWkhha241WnRTYjl5eS9TNU9QK1NJL2dURXd4bnBPYldSQnZG?= =?utf-8?B?VFRlYjZzRVZNbG1Kb0YzeVBXTHhDVENBbzdtTGtYRlhLUTRhd2l0R01RMGh2?= =?utf-8?B?V3AvdG5ZTTV0ZEdCS29pd3YvbldINGRrNitkQjNwdzdjU3VkQnJxVzQ0M2JH?= =?utf-8?B?bEhsVTdyLzYxWnVwZjlIV1ptb3lqUUtHNERTdmF1RDBTYU9HNDQxQnZzU2xS?= =?utf-8?B?Tkl4UFM0ZjV3aHpKOGtrQjhJQnNGTmo1czluUlUzSEtWUzd5ZXhPdTZ6Zm1Z?= =?utf-8?B?aGFHd0VTaWpKcUkzeW95ZThLUEJ2c2d3ZEdHamxINCtzN3NMNFhZbzMyL3I3?= =?utf-8?B?bGpSVWZBRHVaSndBQUNwcEJJckdwelNjdG5VSURuc2diZU9ORGl2MjJxMXJC?= =?utf-8?Q?yZDW1ekqoUP6l2iLH1Rv29O+2x3ncxvqkPfifDk?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 001153e2-0d2f-42a3-c82e-08d8d98c816a X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2021 12:54:36.4545 (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: PEtbFkzBNVM7oJafqv+fcLF0hBKRA13e51Wfnxew6MXkgXitgsMNL4AmMaa8qP9Q5RfX9GKgmR+M6MePl+MXvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0650 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-observe-multicast-notifications-05.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, 25 Feb 2021 12:54:45 -0000 --kmwMipin2ntHmnq7q47TY1iOUYPRjBVtf Content-Type: multipart/mixed; boundary="NfdtqXYQfgnDUvqSM1SDGd71pMcQxeh0E"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <038d11dd-768c-9440-42a8-3a729c6e6c5c@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-core-observe-multicast-notifications-05.txt References: <161401302982.14028.14113860823096266335@ietfa.amsl.com> In-Reply-To: <161401302982.14028.14113860823096266335@ietfa.amsl.com> --NfdtqXYQfgnDUvqSM1SDGd71pMcQxeh0E Content-Type: multipart/alternative; boundary="------------36B07AEA396BB5DDE217A313" Content-Language: en-US This is a multi-part message in MIME format. --------------36B07AEA396BB5DDE217A313 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an update for the draft "Observe=20 Notifications as CoAP Multicast Responses". https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notificat= ions-05 The document describes how a CoAP server can send Observe notifications=20 over multicast, and how Group OSCORE can be used to protect such=20 notifications. The proposed approach is especially relevant for, but not = limited to, a Publish-Subscribe scenario with the Broker taking=20 advantage of multicast. This update especially covers: 1) The latest notification is now optional to include in the informative = response from the server. 2) Added target attribute "grp_obs" to signal the possible use of=20 multicast notifications. 3) Improved encoding of transport information, as 'tp_info' parameter=20 specified in the informative response. 4) Revised processing in the presence of proxies, with updated examples=20 in Appendix E and Appendix F. 5) New Appendix C, defining how the server may self-manage the OSCORE gro= up. 6) New Appendix D, defining an optimization where the phantom request is = a deterministic request [1]. Comments are very welcome! Best, /Marco [1] https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/ -------- Forwarded Message -------- Subject: New Version Notification for=20 draft-tiloca-core-observe-multicast-notifications-05.txt Date: Mon, 22 Feb 2021 08:57:09 -0800 From: internet-drafts@ietf.org To: Christian Amsuess , Francesca Palombini=20 , Marco Tiloca ,=20 Rikard Hoeglund A new version of I-D,=20 draft-tiloca-core-observe-multicast-notifications-05.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-observe-multicast-notifications Revision: 05 Title: Observe Notifications as CoAP Multicast Responses Document date: 2021-02-22 Group: Individual Submission Pages: 67 URL:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-observe-multicast-notification= s-05.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7128568c43481d565f= 08d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496098328492= 857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I= k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DmqUV%2Br3bSEimgVSg2FtRsp7neKxwZY= r3qU17sIMZFyQ%3D&reserved=3D0 Status:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-observe-multicast-notifications= %2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7128568c43481d565f08d8d= 752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496098328497827%7= CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW= wiLCJXVCI6Mn0%3D%7C1000&sdata=3DBOHof%2BwACNYBwsyCiY9o2yW97C9k9epEMGF= 3xpI999I%3D&reserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-observe-multicast-notifi= cations&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7128568c43481d565f0= 8d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374960983284978= 27%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik= 1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DmbCZ9xQd3aAXlRmS77UkFdUH3z0gpfV76= jel1O0hnDU%3D&reserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= =2Eietf.org%2Fhtml%2Fdraft-tiloca-core-observe-multicast-notifications-05= &data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7128568c43481d565f08d8d752= e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496098328497827%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL= CJXVCI6Mn0%3D%7C1000&sdata=3DXP9q6ZsyZWutobEOjNN71SB%2BtxU%2FIxhf6iSG= b3hoWzc%3D&reserved=3D0 Diff:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-observe-multicast-notificati= ons-05&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7128568c43481d565f08= d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63749609832849782= 7%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1= haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DHDL%2FerImQ5lHgreWJQwdzmMEHsxykRoP= G7WgirChwoQ%3D&reserved=3D0 Abstract: The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------36B07AEA396BB5DDE217A313 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an update for the draft "Observe Notifications as CoAP Multicast Responses".

https://tools.ietf.or= g/html/draft-tiloca-core-observe-multicast-notifications-05

The document describes how a CoAP server can send Observe notifications over multicast, and how Group OSCORE can be used to protect such notifications. The proposed approach is especially relevant for, but not limited to, a Publish-Subscribe scenario with the Broker taking advantage of multicast.

This update especially covers:

1) The latest notification is now optional to include in the informative response from the server.

2) Added target attribute "grp_obs" to signal the possible use of multicast notifications.

3) Improved encoding of transport information, as 'tp_info' parameter specified in the informative response.

4) Revised processing in the presence of proxies, with updated examples in Appendix E and Appendix F.

5) New Appendix C, defining how the server may self-manage the OSCORE group.

6) New Appendix D, defining an optimization where the phantom request is a deterministic request [1].


Comments are very welcome!

Best,
/Marco

[1] https://datatracker.ietf.org/= doc/draft-amsuess-core-cachable-oscore/


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-observe-multicast-notifications-05.txt
Dat= e: Mon, 22 Feb 2021 08:57:09 -0800
Fro= m: internet-drafts@ietf.org
To:= Christian Amsuess <christian@amsuess.com>, Francesca Palombini <francesca.palombini@ericsson.com>, = Marco Tiloca <marco.tiloca@ri.se>, Rikard Hoeglund <rikard.hoglund@ri.se>



A new version of I-D, draft-tiloca-core-observe-multicast-notifications-05.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-observe-multicast-notifications
Revision: 05
Title: Observe Notifications as CoAP Multicast Responses
Document date: 2021-02-22
Group: Individual Submission
Pages: 67
URL: https://eur02.safelinks.protection.outlook.com/?url=3Dht= tps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tiloca-core-observe-multi= cast-notifications-05.txt&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7= C1e7128568c43481d565f08d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%= 7C0%7C637496098328492857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ= IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DmqUV%2B= r3bSEimgVSg2FtRsp7neKxwZYr3qU17sIMZFyQ%3D&amp;reserved=3D0
Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3= A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tiloca-core-observe-multicast-n= otifications%2F&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7128568= c43481d565f08d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374= 96098328497827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz= IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DBOHof%2BwACNYBwsy= CiY9o2yW97C9k9epEMGF3xpI999I%3D&amp;reserved=3D0
Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-observe-mu= lticast-notifications&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7= 128568c43481d565f08d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%= 7C637496098328497827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi= V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DmbCZ9xQd3aA= XlRmS77UkFdUH3z0gpfV76jel1O0hnDU%3D&amp;reserved=3D0
Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Ftools.ietf.org%2Fhtml%2Fdraft-tiloca-core-observe-multicast-notificat= ions-05&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7128568c43481d5= 65f08d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637496098328= 497827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi= I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DXP9q6ZsyZWutobEOjNN71SB%2= BtxU%2FIxhf6iSGb3hoWzc%3D&amp;reserved=3D0
Diff: https://eur02.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-observe-multi= cast-notifications-05&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1e7= 128568c43481d565f08d8d752e5ff%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%= 7C637496098328497827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi= V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DHDL%2FerImQ= 5lHgreWJQwdzmMEHsxykRoPG7WgirChwoQ%3D&amp;reserved=3D0

Abstract:
The Constrained Application Protocol (CoAP) allows clients to
"observe" resources at a server, and receive notifications as unicast
responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the<= br> server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and
RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of
a same resource on a same shared Token value. Besides, this document
defines how Group OSCORE can be used to protect multicast
notifications end-to-end between the server and the observer clients.



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


--------------36B07AEA396BB5DDE217A313-- --NfdtqXYQfgnDUvqSM1SDGd71pMcQxeh0E-- --kmwMipin2ntHmnq7q47TY1iOUYPRjBVtf Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmA3ngoFAwAAAAAACgkQ7iZktA5Y2kOK wQf9Gch0Sb96tpSml0KHhpNKYnh1XDddoCrT+GYRfGmV3MLt9X8ceG2W+LiesFOAXYP0Ejn8EqrB 0GnQZ7O53U1f04xYboEjQFTNZRmYMRkalCo+hgdif8A/ot+GNecd8QPjOOquQBjOKScqypi7HWxT J8brgHjLnqwHO8r98gRO1HL4oUt+T0mgN8aC9ONU+gKkgJbUfJyR4eFOdK0EdVeL/TeFT402BusO 8g5i9Ez3VhR+8I6oN6BmGkq72r/ZH79v4bam+bAQL2YmbEGaihUCS8LmsrmuBOoNcQ++eG7TLFsa o7ChbP68+IkgWnvEkdiZSMlP69kYN4xiVlRAKRjvLA== =PPV2 -----END PGP SIGNATURE----- --kmwMipin2ntHmnq7q47TY1iOUYPRjBVtf-- From nobody Thu Feb 25 10:34:39 2021 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 89FB13A1E66 for ; Thu, 25 Feb 2021 10:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjWuNETFyO2v for ; Thu, 25 Feb 2021 10:34:25 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2081.outbound.protection.outlook.com [40.107.21.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184C83A18AE for ; Thu, 25 Feb 2021 10:34:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GE8A594aWl9mk7qC1hKhvH0sWJvIh0iisFBcajs+8IydbS8yzwAfC33ujSPqLVJTajiZnJwl40WsZg74lPqfs8GHQwDo0fYo91SKxsWxf/W9VULsLYpj0ThYYK0c9MWj0UB8LnWVkFjmvFDRllLJfHOGQ7Tcfb2BvUjb1iil9qJInhoFZsiy+OagrPVnhnwo1bD95JuqNGNqIDxyM/G1mhZr4GKRySBC1cD2AzdCMp5S5pPsRD3yVxtJ9+T8DlICnbJ8tYINXMZH37OLlc7whxrgy5KnZdRDUVBgZAFIE9os6tSvvlESWZbmWvoumPp2PGpmch8JwoQ6HlpUj+BGxQ== 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=DvB8whKINLCXt+HHuNCnlkB9ojAp7fdD8xeXqPwxcv0=; b=bTkJf4gaJ/sO9pf1rCDpViEhS2ZGaO1hawr8N70MSqU8V3XZ9kojw8TN5SfrDjdbkOeINaCKsNsgc01SGNBk9DQFFhe8ezX6tlxEEVk0qe68pui3U0djSgZQPrDPPOi5NV20rLOAHxJFLj7/HZ3gMx+dgbKGaRBggQVHQsP+Sc7WE4acj/XTiZTSGkNh7PD8bZ0gve+u3G0y6ZEAj49MbY+fiTh9FiZoXvIAIPLxgbDrb+IDU6N98fT4dwyDELPJKaP1HwTdgJGCjASE7dlrvDFZcwDmMUl2Sf9S2KA8NSoOCYG4d2Bq7pWKyKxqmM88j98ym509Wj9qtR38DqA/1A== 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=DvB8whKINLCXt+HHuNCnlkB9ojAp7fdD8xeXqPwxcv0=; b=eW6TngoomFebCyXA2i1evMqbyK7lJnWTCjeCJHQCmfckQLu5c3b3g01mTOfU09HdeXsj1xMZVLrTjJ8j/oZOBcGLCSBXpN9WWPALGUZDccsB60APQOocE6a8Oaq7SuVlEBchvdruNKLcVuHuUSaOBoNOcn42vyQ+/6IZdgj9n5o= 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 DBBP189MB1162.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e2::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Thu, 25 Feb 2021 18:34:20 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3890.020; Thu, 25 Feb 2021 18:34:20 +0000 To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , core@ietf.org References: <160433906029.4820.14907779807204481594@ietfa.amsl.com> <20201110171530.GA1301772@hephaistos.amsuess.com> From: Marco Tiloca Message-ID: <4be0d9c5-7bf1-5b75-8668-a6674ff086c9@ri.se> Date: Thu, 25 Feb 2021 19:34:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <20201110171530.GA1301772@hephaistos.amsuess.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S6ANAbb8Fk0tLM3re6yKlftdVz2W7fSWH" X-Originating-IP: [185.236.42.111] X-ClientProxiedBy: OL1P279CA0034.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:13::21) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.6] (185.236.42.111) by OL1P279CA0034.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:13::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Thu, 25 Feb 2021 18:34:20 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a3616356-3122-42d3-a742-08d8d9bbf751 X-MS-TrafficTypeDiagnostic: DBBP189MB1162: 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: NSGYn61/n/wZB38r9nIcJXtv9HDbtEtOoYJ0s3nKboBlUSWyWVIOC7ycoIpNSeLxL3UcYqu437Ixx/J2Z4ZBrUIEFf1oNU8bwyDa2BKjt20u1oSq2WWYFZ8a8533mF+CE/IXLrChqs6GkcSSaeTRMomM2Jy/CyFJONYMYfdzjxc4rlgqLxADRdCSoLmLzLw3p4umXNYHoXVbZtlkVA5r9+kpTIfkilEsotwLma1aYuleSvM09D66t93COSXxNlfaCEkv+sFDKpOA0d0wDJq9VNVKQuuVDeZSs+epeGo7CQlbWAeL+ZJSr9YdSKgahlCGfdtqH8n2BipptoLVYOMeHezyvw0KgedUj6R7348O2S+UTNvAvIjjhMRW3UxMn+Z3vt+9ypfmwS5YdYws5DW5E3F2iMD9bubXmRpjV1ML7HdYHeZ+cVY5E7i0KrFB37OCELewXH8rslnEFtMjvYPZt3F27/SALp/V70zFGfUqSReQxTm+XDgENsFBjyBKU5yBmN8nb5r9QVADkQHcNpLbH1Ackc/Wi85EG058GYe+aDtjNKHljOw/IKQXg3HlX/uOMXTdkApjwZ+jE+TtYfWTDhQ8TNRVz+WsxXRqSw/EyxKDLZDS3xpKNrFKlu1bCJ02lvABfi/7RK5n5h+TOcs1a2NFVwGvNcBmDfm0Ubx2X72c/pJqlVNGldAhqvF+3Q26 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(39850400004)(346002)(366004)(235185007)(2616005)(16526019)(5660300002)(26005)(66946007)(4001150100001)(166002)(31686004)(66476007)(66556008)(186003)(8936002)(8676002)(2906002)(30864003)(6486002)(44832011)(956004)(6666004)(83380400001)(33964004)(478600001)(66574015)(36756003)(16576012)(966005)(31696002)(316002)(86362001)(45080400002)(52116002)(53546011)(21480400003)(45980500001)(43740500002)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?NFgya09mWkIwNDFoM0VmWDVwaG96Q05lNS95QUZEWklvcWNCa3dPK2UzOTZw?= =?utf-8?B?azBPUWl2d2N1UWRFTGMxbHpKZmRBclJBWEdvK0ZqNlA2VnFWTFYyNlNJNTdC?= =?utf-8?B?aVdoNEhCUEx1L2hUTVlUcVRHdmcvWHVtZ3RtYnd0OVlYZGd6TWU5UGtzNEpv?= =?utf-8?B?ZWZVeGhXbVlPZUUzdDZCdEpqZ2pRVEE0RStZNGt1eGlhQkFyeXVLR0pyZ1Z5?= =?utf-8?B?eFI2b0tlT2pJNUgyU3o0UjFqUWZUYVRWMG1XNDM4b2pNUEZPZ3V0MTJKZTMz?= =?utf-8?B?RTFRRXZBMk8wS1BXdDFqUi9NSUU4K1A5T0lKSWhSSlg4NUdtaTFFSWNGL2Fa?= =?utf-8?B?aU5KOXZXTXMxbWhEYTh0TTdObFVnWktJQzkyaGozL2k1U05CR3dKRkFJVkVw?= =?utf-8?B?OHhhQ1BINXdHeFpQT3VHc3B4TmNWY2pTdyt3dGswTUlXYnUwSWhZRzlWaDNz?= =?utf-8?B?R2UyUWFDUUpKR3ZvMHBKZENhK25aSlJDNHlqL1NTVElVMFlGRWl6Mk1DdVZq?= =?utf-8?B?NnR0SVV6aWg4cGxRaXVnYXpCRzhMeVFoY2FpRnZPMzk4YnNQaS8zNWNxcU5K?= =?utf-8?B?bWlCM2RDYTljcjhpbzdhNWpuYzRXWXBudUNXZEhTWUlsQStLRVR4QUJRMVJ5?= =?utf-8?B?Q2FwaHpTZDJyT3VMaFhuZ2t6cXR2RmlQajJrQk1Xc2Rra1k2VFZ3R29TOFdu?= =?utf-8?B?UitXK0lTczZHRVNRL2R3cG9xTnhyTlhMOUxKejRZY2FqNWgzQ1lpNE1hVXJX?= =?utf-8?B?OXhKeEU1YTR0eXU3OEsrMm1JV0VCcUErNk53ODFyVzkrTEkyb0I3OEYwZ0dw?= =?utf-8?B?eXBrcjRZaldIQXNhb2lJTGVFN05HeGFaTk4rM0FxcmtlNG5YRVBKYXdGS0FB?= =?utf-8?B?RWZKRzhuVW1vQitQZW5HcU5KSUQwZWlHYzNTek9vZDZBbjVtTmpLUnM3dnF2?= =?utf-8?B?QnpDYW5FeW95eGsvcGlYeVVhWDBnTUFta3Fmc1hMSGpwc0RZNjMzVjJvTHZi?= =?utf-8?B?dFNETDY5eDU3WVZzUDkxV3JNU2tmazJBVlhkZjdnWGRyOEtkZTFCd1kvREVH?= =?utf-8?B?ZVhubGVyY3R3RHZJMS9DRS96S0lndDhZWUtZb0ZBYStZWCsvdFdNdnBGbXRT?= =?utf-8?B?RVFuZnlTWmFKRkhJb3dtbmx3RjFoZWQzcTUwandqQ3JQRE8yTkRhUXlOVXJu?= =?utf-8?B?bFFPM0dJZmF1NmdOTVJOM3FkMUg5aXFzLzRDcW9xUC8vZCs0Z2psTnF1TzMx?= =?utf-8?B?ZmRwckJsSGllMjUxeFFYOFo5REw5d2NnY0g3b2FTZGNJWE5rQlZTeUJmMlpz?= =?utf-8?B?bkVxNTJDK2l0ZjFySTU2c3pKUjhxN3Y2NDZ4VnFpWVcrMWorYzF6UkYxZWJa?= =?utf-8?B?aG9QSFZIRXIvMDNoWXZEeXNyTmd5enJPNTF2R2Q1bnNjQzVIWkV6cEwzazRk?= =?utf-8?B?c3lpb3dvMDM5UmFYWGxOV3ZCTHM4eVZicms1c0VnOXdhalhSVVdEOWI4TlFI?= =?utf-8?B?d0h3c3FpWUVzM3FuOWFObTI3MlQrUUtBRmwzNUFLYnZXSFQ2T05iNWxnTVov?= =?utf-8?B?YzNzazQ3dXFzT2xaYk8rWnhkREl4Z3ptN3ZhdnZBVVY2SjZxMGRhc2dXaTdC?= =?utf-8?B?MzF4SGduZm9jRVdEbkdMUWxuQWdGRGhpQit3MkR6YWRBU05xMHhPMnpoV1Z3?= =?utf-8?B?WVdPZ1R4TGNadjQvcEQ5WnA3M2ZoblFURldoUUJmbWduS2JWQlJsQ241NUdQ?= =?utf-8?Q?0Ayl29B5HMFyCzLD2U+2IDUFiFfaea/D27mJc16?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: a3616356-3122-42d3-a742-08d8d9bbf751 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2021 18:34:20.7606 (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: TzFA+pZ4EgF8Q5GBL5l9NbjHH4K9oAFF/OnEde4nJ8pdf9OfKQJ0F2yFruP7L2UV333Hgidm1Psp3wJoxjKL3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1162 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-oscore-groupcomm-10.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, 25 Feb 2021 18:34:38 -0000 --S6ANAbb8Fk0tLM3re6yKlftdVz2W7fSWH Content-Type: multipart/mixed; boundary="vtVo2imYVap0oMzTLL4cz5BKLFE5h6rJD"; protected-headers="v1" From: Marco Tiloca To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , core@ietf.org Message-ID: <4be0d9c5-7bf1-5b75-8668-a6674ff086c9@ri.se> Subject: Re: [core] I-D Action: draft-ietf-core-oscore-groupcomm-10.txt References: <160433906029.4820.14907779807204481594@ietfa.amsl.com> <20201110171530.GA1301772@hephaistos.amsuess.com> In-Reply-To: <20201110171530.GA1301772@hephaistos.amsuess.com> --vtVo2imYVap0oMzTLL4cz5BKLFE5h6rJD Content-Type: multipart/alternative; boundary="------------10E28C7708CBBCCEB7ECA604" Content-Language: en-US This is a multi-part message in MIME format. --------------10E28C7708CBBCCEB7ECA604 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Christian, Thanks a lot for this review and the discussion around the raised=20 points, it was really useful! We have taken your comments into account in the latest version -11.=20 Please, check whether they are all properly addressed. See also below detailed inline replies to your comments. Best, /Marco On 2020-11-10 18:15, Christian Ams=C3=BCss wrote: > Hello OSCORE-groupcomm authors, > > thanks for incorporating my earlier comments. > > While reading -10 for the purpose of implementing it, a few more points= > came up (in linear order of the document): > > * "Furthermore, sufficiently large replay windows should be > considered,": This paragraph reads as if a server receiving a high > sequence number gets completely out of sync (to the point where it > needs to recover), when actually the only ill-effect of a, say, a ju= mp > from 1000 to 1100 with a 32bit replay window is that a delayed messa= ge > with sequence number 1002 will be rejected. The next message at 1101= > will still be accepted. > > Recovery *will* be necessary if the server has, in the mean time, > evicted the client's replay window out of its list of available > windows. So maybe the recommendation should rather be to not have > overly long replay windows (or to suggest the replay windows may be > truncated when unused), as that'd allow the server to keep more > clients' replay windows around. > > (Or I just misread the paragraph). =3D=3D>MT Section 6.1 "Update of Replay Window" now treats the possible jumping=20 forward of the Sender Sequence Number as something that the server has=20 to simply be fine to handle, just as in OSCORE. The recovery, including the case of overloading of Recipient Contexts,=20 is also mentioned here in Section 6.1, but now separately discussed in=20 Section 2.4.1.2 "Overflow of Recipient Contexts". <=3D=3D > > * It felt like there are different ways for the sender sequence number > to go back to 0. (Search for " to 0", first three occurrences). What= 's > really the case is that the first two *trigger* the third, but the > repetition around there made them read like separate things. =3D=3D>MT The text has been restructured to clarify cause-effect relations in a=20 more linear way. That is, Section 2.4.1 "Loss of Mutable Security Context" and Section=20 2.4.2 "Exhaustion of Sender Sequence Number" are both possible causes=20 that trigger what described in Section 2.4.3 "Retrieving New Security=20 Context Parameters". The resulting actions are getting a new Sender ID (Section 2.4.3.1)=20 and/or participating to a group rekeying (Section 2.4.3.2). In either=20 case, the involved client resets its Sender Sequence Number to 0. =3D=3D> > > * "and SHOULD preserve the current value of the Sender ID of each group= > member.": Why bother? It's not like anything can be reused after the= > master secret changed. > > ("bother", because the GM may want to hand out KIDs sequentially > rather than tracking a bitfield). > > * Oh, I see -- later on it says that KIDs can never be reused, even > when master parameters change. Doesn't that lead to irrecoverably > large KIDs over time? (Ie. they're shiny short first, but after a > few joinings, group leaves, device restarts and other fluctuation,= > they wind up in the >=3D4-byte range). > > This also reads a bit controversially -- it says "Even if Gid and > Master Secret are renewed as described in this section, the Group > Manager MUST NOT reassign", which sounds like "never ever", but > misses the master salt from the line above. And it refers to > 2.4.3.1, where it only talks about KID reuse ~"if none of the mast= er > parameters change". 3.2 item 5 reads like "never ever" again, so > this needs clarification first and then editing. =3D=3D>MT Following also more discussions, we went for the following updates. Within an OSCORE group, the Group Manager must assign a Sender ID that=20 has never been assigned before in the group under the current Gid value=20 (see Section 2.4.3.1 and Section 3.2). Within an OSCORE group, the Group Manager must assign a Gid that has=20 never been assigned ever before in the group (see Section 2.4.3.1 and=20 Section 3.2). <=3D=3D > > * "The value of the 'kid' parameter in the 'unprotected' field of > response messages MUST be set to the Sender ID of the endpoint > transmitting the message." > > Is this the case even when requests were made in pairwise mode? > > (For comparison, the section above (4.1) is explicitly "for group mo= de > only", and 4.3 says "in group and pairwise mode".) =3D=3D>MT We have updated Section 4.2 "The COSE Object" to mandate 'kid' in=20 responses only if sent as reply to a request protected in group mode. The examples in Section 5.1.2 are also updated accordingly. <=3D=3D > > * Does it make sense to use the 4.3 extended parameters (with the ne= w > algorithm data and the added group ID) in pairwise mode? > > After all, everything else in there (including the group mode bit)= > is really just vanilla OSCORE. Or are observations in > pairwise-pairwise mode supposed to survive rekeying? (If that's th= e > case, the question may arise whether anyone might be tempted to us= e > pairwise-pairwise in a 1:1 setting just to use that property). =3D=3D>MT Yes, observations are intended to continue after a group rekeying,=20 regardless the mode used to protect messages. Some information in the two external_aad is not relevant in pairwise mode= =2E As discussed at IETF 109, we ended up converging to a single=20 external_aad structure, used in both modes of operations and for both=20 encrypting and signing (see Section 4.3). <=3D=3D > > * external_aad: Why is countersign_key_type_capab in there twice? =3D=3D>MT As part of the external_aad restructuring (see previous comment), the=20 new single format in Section 4.3 does not repeat the key type=20 capabilities anymore. <=3D=3D > > * "The new element 'request_kid_context' contains the value of" could > use some explaining why this now is in here. > > AFAIR, it is to allow observations to extend over rekeyings. =3D=3D>MT We have added a bullet point in Section 4.3 to explain why the new=20 parameter is there. <=3D=3D > (Shouldn't also, due to this, KIDs be reusable once the KID-Context = is > changed?) =3D=3D>MT Yes, that's also been addressed (see previous comment on allowed=20 recyclying of Sender IDs under different GIDs). <=3D=3D > > Same for the OSCORE_option being present in the signature > external_aad. (A forward reference to 10.6.2 may do). =3D=3D>MT We have added a bullet point in Section 4.3 to explain why the new=20 parameter is there. This also includes a forward pointer to Section 10.6, which describes an = attack that the OSCORE_option parameter makes infeasible to perform when = the group mode is used. <=3D=3D > > * Examples in Group Mode: I think it's easier to grasp if rather than > using the value "COUNTERSIGN", a signature value a la "de 9e ... f1"= / > 0xde9e...f1 (depending on the representation) were used; the > COUNTERSIGN value reads too much like a constant in the > before-compression COSE object ("What's that, a numeric, a tagged > value?"). =3D=3D>MT Done. See examples in Section 5.1.1. <=3D=3D > > * "Note that, if the Group Flag is set to 0, and the recipient endpoint= > retrieves a Security Context which is valid to process the message > but is not associated to an OSCORE group," > > I don't have a fleshed-out proposal here, but we may manage to use t= he > same bit for other purposes in non-group-OSCORE messages. > > As the introduction to that section states, the receiver MUST be abl= e > to distinguish from the KID context and KID whether it's from a Grou= p > OSCORE or a different context. For Group OSCORE, that bit > distinguishes between group and pairwise. For other, that other may > use that bit. > > (I know that this is contradicting the previous suggestion that led = to > this bit being flipped in -09; recent discussions about flag bit usa= ge > indicate to me that other ways of getting OSCORE keys may have > different varieties as well, and this would align well then). =3D=3D>MT We have updated the text so that a Security Context is retrieved first,=20 before checking the Group Flag bit. See especially Section 7 (second bullet point) and the rephrasing for=20 the IANA registration in Section 11.1. <=3D=3D > > * "For each ongoing observation, the server MUST include in the first > notification": This may get sucked up by a proxy that doesn't forwar= d > until a following notification arrives. > > Moreover, it may be unnecessary if the rekeying fits snugly between > notifications. > > Suggested alternative: > > The server can help the client synchronize by sending the Gid as the= > ID Context for notifcations following a rekeying. If there is a know= n > upper limit to the duration of a full rekeying, it SHOULD set the Gi= d > during that time. Otherwise, it SHOULD set it until the Max-Age of t= he > last notification before the rekeying has expired. =3D=3D>MT Thanks, we have accordingly updated the last two paragraphs in Section=20 8.3.1. <=3D=3D > > * "Senders MUST NOT use the pairwise mode to protect a message intended= > for multiple recipients.": That's a factual and not an > interoperability statement. It can not. > > If that's meant to rule out a pairwise request to the broadcast > address (hoping that the right node will answer), it should say > "protect a message sent to multiple recipients". > > (But probably that's not what's meant, given 9.1 proposes an address= > discovery resource, and for accessing that by a single KID the > pairwise mode would make a good choice). =3D=3D>MT Thanks for this good input. It should be captured now in the sixth and=20 seventh paragraphs of Section 9. <=3D=3D > > * Sections 9.2ff are described as a delta to 8.1ff. > > Given the external_aad and key choices are already in the section 9 > header, would there be any per-step delta left to explain at all if > they were instead relative to RFC8613 Section 8? That'd make Section= 9 > a lot slimmer. =3D=3D>MT Sections 9.2-9.6 have been rewritten as a delta from RFC 8613. <=3D=3D > > * I'm still not fully sold on why the Object-Security option needs to b= e > in the external_aad -- but having two versions of the external_aad > seems extraneous to me. If the option needs to be in there, I think > it'd be easier to have it in the external_aad for all purposes right= > away. =3D=3D>MT This is now explained in the last bullet point of Section 4.3, together=20 with a forward pointer to Section 10.6 where the addressed attack is=20 discussed. This is also part of the broader update to the external_aad, now having=20 a single format for both modes of operation, and for both signing and=20 encrypting. <=3D=3D > > Also, was treating the OSCORE option as Class I considered? That > doesn't solve the problem of having many different external_aad > constructions, but it'd be using existing mechanism. (Although > implementors may curse if they didn't do Class I yet). > > I'll come back to that once I've actually implemented it. =3D=3D>MT Having the OSCORE option of class I was once considered but just=20 dismissed to not bother implementers :-) That's when relying on the=20 external_aad was considered instead. <=3D=3D > > * "Unless exchanges in a group rely only on unicast messages": I think > that's only understandable for readers that have an active memory of= > Section 7.4 of RFC8613; it'd need either more context or slimming > down, maybe like this? > > "As multicast usually involves unreliable transports, the > simplification of the replay window to a size of 1 that's suggested = in > RFC8613 Section 7.4 is not viable with Group OSCORE." =3D=3D>MT Based on your input, we updated Section 10.10 with the current third=20 paragraph. <=3D=3D > > * Summarizing the KID-reuse questions, I think a diagram of the > componetns may help, like: > > =E2=86=90--=E2=86=92 KID > Secret =E2=86=90--=E2=86=92 Group ID =E2=86=90--=E2=86=92 KID > =E2=86=90--=E2=86=92 KID > =E2=86=91 > Change in =E2=86=91 =E2=86=91-- Group ID changes allow = old KIDs to be reused > lockstep | (but KIDs usually stay the same for eff= icient rollout) > --- KID changes don't necessitate a Group ID c= hange > > (are there any other components that can chagnge?) > > In that context: Can an ancient group ID be reused? =3D=3D>MT Done. See Figure 2 in Section 3.1. <=3D=3D > > * E.1 and E.2 Best Effort Synchronization / Baseline Synchronization > > A server doing any of these needs to use own Partial IVs all the tim= e. > It may be acceptable in a scenario to eat the replays, but it's almo= st > certainly not acceptable to commit nonce reuse (which *can* happen > with Best Effort Synchronization). =3D=3D>MT Right, *that* whiteboard discussion at the IETF 109 Hackathon! :-) This has resulted in the following updates: * Section 2.2 (last paragraph) explains the need to limit the number of=20 Recipient Contexts for an endpoint, and the possibility of an overflow. * A clearer distinction between anti-replay and freshness. Changes=20 affect the following Sections: --- 2.2 "Security Context and Recipient Context" --- 2.4 "Update of Security Context" --- 2.4.1 "Loss of Mutable Security Context" --- 2.4.1.1 "Reboot and Total Loss" --- 2.4.1.2 "Overflow of Recipient Contexts" --- 6.1 "Update of Replay Window" --- 6.2 "Message Freshness" --- 10.10 "Replay Protection" (Security considerations) --- 10.11 "Message Freshness" (Security considerations) --- Appendix E (was E.3) "Challenge-Response Synchronization" * Removed the old Appendix E.1 and Appendix E.2, as non relevant=20 synchronization approaches. <=3D=3D > > * E.3 Challenge-Response Synchronization: > > "The server MUST NOT set the Echo Option to a value which is both > predictable and reusable." While this is technically correct, it's > hard to evaluate as a reader. How about "The Echo option value SHOUL= D > not be reused, and when it is MUST be highly unlikely to have been > used with this client recently."? =3D=3D>MT Done, see the second paragraph of current Appendix E. <=3D=3D > > * "sends a request as a unicast message addressed to the same server= ": > > That should indicate pairwise mode. > > There's later paragraphs on this where 10.7 is mentioned, but give= n > how widely this open things up, pairwise mode should be mandatory = on > Echo recovery. =3D=3D>MT Done, see the fifth paragraph of current Appendix E. <=3D=3D > > * "The server either delivers the request to the application if it i= s > an actual retransmission of the original one, or discards it > otherwise": For that the server would need to remember. Ther *is* > somethign to take care of, though: Only the first time the Echo > request arrives it can be processed, otherwise it may reset an > already good replay window. > > Suggesting to replace the paragraph with: > > "If the verification is successful and the replay window has not > been set yet, the server updates its Replay Window to mark the > current sequence number as seen (but all newer ones as new), and > forwards the message as fresh to the application. > > Otherwise, it discards the verification result and treats the > message as fresh or replay according to the existing replay window= =2E" =3D=3D>MT Done, see the second paragraph after the bullet list, in current Appendix= E. <=3D=3D > > "(believed to be) lost" > > How is that not a binary thing? (May relate to the first question)= =2E > Either there is a replay window, in which case it can be used (and= > it does get fast-forwarded in need be), or not and it needs to be > recovered. > > The following paragraphs elaborate on what a loss would mean, but > don't explain why it would be relevant. Something like this would = be > applicable if we only ever transported the last bits of the sequen= ce > numbers in a sliding-window fashion, but that's not what happens i= n > OSCORE. =3D=3D>MT Done. Thanks a lot again for your input and comments! Best, /Marco <=3D=3D > > KR > Christian > > > _______________________________________________ > core mailing list > core@ietf.org > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca= %40ri.se%7Cc21e90c15f74443ad3e008d8859c67df%7C5a9809cf0bcb413a838a09ecc40= cc9e8%7C0%7C0%7C637406254091815430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DS= C37JAoObx0rWMO%2FVKg89UqH54lmO3ObPSqcDBRPdtc%3D&reserved=3D0 --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------10E28C7708CBBCCEB7ECA604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Christian,

Thanks a lot for this review and the discussion around the raised points, it was really useful!

We have taken your comments into account in the latest version -11. Please, check whether they are all properly addressed.

See also below detailed inline replies to your comments.

Best,
/Marco

On 2020-11-10 18:15, Christian Ams=C3=BC= ss wrote:
Hello OSCORE-groupcomm autho=
rs,

thanks for incorporating my earlier comments.

While reading -10 for the purpose of implementing it, a few more points
came up (in linear order of the document):

* "Furthermore, sufficiently large replay windows should be
  considered,": This paragraph reads as if a server receiving a high
  sequence number gets completely out of sync (to the point where it
  needs to recover), when actually the only ill-effect of a, say, a jump
  from 1000 to 1100 with a 32bit replay window is that a delayed message
  with sequence number 1002 will be rejected. The next message at 1101
  will still be accepted.

  Recovery *will* be necessary if the server has, in the mean time,
  evicted the client's replay window out of its list of available
  windows. So maybe the recommendation should rather be to not have
  overly long replay windows (or to suggest the replay windows may be
  truncated when unused), as that'd allow the server to keep more
  clients' replay windows around.

  (Or I just misread the paragraph).

=3D=3D>MT
Section 6.1 "Update of Replay Window" now treats the possible jumping forward of the Sender Sequence Number as something that the server has to simply be fine to handle, just as in OSCORE.

The recovery, including the case of overloading of Recipient Contexts, is also mentioned here in Section 6.1, but now separately discussed in Section 2.4.1.2 "Overflow of Recipient Contexts".
<=3D=3D


* It felt like there are different ways for the sender sequence number
  to go back to 0. (Search for " to 0", first three occurrences). What's
  really the case is that the first two *trigger* the third, but the
  repetition around there made them read like separate things.

=3D=3D>MT
The text has been restructured to clarify cause-effect relations in a more linear way.

That is, Section 2.4.1 "Loss of Mutable Security Context" and Section 2.4.2 "Exhaustion of Sender Sequence Number" are both possible causes that trigger what described in Section 2.4.3 "Retrieving New Security Context Parameters".

The resulting actions are getting a new Sender ID (Section 2.4.3.1) and/or participating to a group rekeying (Section 2.4.3.2). In either case, the involved client resets its Sender Sequence Number to 0.
=3D=3D>


* "and SHOULD preserve the current value of the Sender ID of each group
  member.": Why bother? It's not like anything can be reused after the
  master secret changed.

  ("bother", because the GM may want to hand out KIDs sequentially
  rather than tracking a bitfield).

  * Oh, I see -- later on it says that KIDs can never be reused, even
    when master parameters change. Doesn't that lead to irrecoverably
    large KIDs over time? (Ie. they're shiny short first, but after a
    few joinings, group leaves, device restarts and other fluctuation,
    they wind up in the >=3D4-byte range).

    This also reads a bit controversially -- it says "Even if Gid and
    Master Secret are renewed as described in this section, the Group
    Manager MUST NOT reassign", which sounds like "never ever", but
    misses the master salt from the line above. And it refers to
    2.4.3.1, where it only talks about KID reuse ~"if none of the master
    parameters change". 3.2 item 5 reads like "never ever" again, so
    this needs clarification first and then editing.

=3D=3D>MT
Following also more discussions, we went for the following updates.
Within an OSCORE group, the Group Manager must assign a Sender ID that has never been assigned before in the group under the current Gid value (see Section 2.4.3.1 and Section 3.2).

Within an OSCORE group, the Group Manager must assign a Gid that has never been assigned ever before in the group (see Section 2.4.3.1 and Section 3.2).
<=3D=3D


* "The value of the 'kid' parameter in the 'unprotected' field of
   response messages MUST be set to the Sender ID of the endpoint
   transmitting the message."

  Is this the case even when requests were made in pairwise mode?

  (For comparison, the section above (4.1) is explicitly "for group mode
  only", and 4.3 says "in group and pairwise mode".)

=3D=3D>MT
We have updated Section 4.2 "The COSE Object" to mandate 'kid' in responses only if sent as reply to a request protected in group mode.

The examples in Section 5.1.2 are also updated accordingly.
<=3D=3D


  * Does it make sense to use the 4.3 extended parameters (with the new
    algorithm data and the added group ID) in pairwise mode?

    After all, everything else in there (including the group mode bit)
    is really just vanilla OSCORE. Or are observations in
    pairwise-pairwise mode supposed to survive rekeying? (If that's the
    case, the question may arise whether anyone might be tempted to use
    pairwise-pairwise in a 1:1 setting just to use that property).

=3D=3D>MT
Yes, observations are intended to continue after a group rekeying, regardless the mode used to protect messages.

Some information in the two external_aad is not relevant in pairwise mode.

As discussed at IETF 109, we ended up converging to a single external_aad structure, used in both modes of operations and for both encrypting and signing (see Section 4.3).
<=3D=3D


* external_aad: Why is countersign_key_type_capab in there twice?

=3D=3D>MT
As part of the external_aad restructuring (see previous comment), the new single format in Section 4.3 does not repeat the key type capabilities anymore.
<=3D=3D


* "The new element 'request_kid_context' contains the value of" could
  use some explaining why this now is in here.

  AFAIR, it is to allow observations to extend over rekeyings.

=3D=3D>MT
We have added a bullet point in Section 4.3 to explain why the new parameter is there.
<=3D=3D

  (Shouldn't also, due to this, KIDs be reusable once the KID-Context is
  changed?)

=3D=3D>MT
Yes, that's also been addressed (see previous comment on allowed recyclying of Sender IDs under different GIDs).
<=3D=3D


  Same for the OSCORE_option being present in the signature
  external_aad. (A forward reference to 10.6.2 may do).

=3D=3D>MT
We have added a bullet point in Section 4.3 to explain why the new parameter is there.

This also includes a forward pointer to Section 10.6, which describes an attack that the OSCORE_option parameter makes infeasible to perform when the group mode is used.
<=3D=3D


* Examples in Group Mode: I think it's easier to grasp if rather than
  using the value "COUNTERSIGN", a signature value a la "de 9e ... f1" /
  0xde9e...f1 (depending on the representation) were used; the
  COUNTERSIGN value reads too much like a constant in the
  before-compression COSE object ("What's that, a numeric, a tagged
  value?").

=3D=3D>MT
Done. See examples in Section 5.1.1.
<=3D=3D


* "Note that, if the Group Flag is set to 0, and the recipient endpoint
   retrieves a Security Context which is valid to process the message
   but is not associated to an OSCORE group,"

  I don't have a fleshed-out proposal here, but we may manage to use the
  same bit for other purposes in non-group-OSCORE messages.

  As the introduction to that section states, the receiver MUST be able
  to distinguish from the KID context and KID whether it's from a Group
  OSCORE or a different context. For Group OSCORE, that bit
  distinguishes between group and pairwise. For other, that other may
  use that bit.

  (I know that this is contradicting the previous suggestion that led to
  this bit being flipped in -09; recent discussions about flag bit usage
  indicate to me that other ways of getting OSCORE keys may have
  different varieties as well, and this would align well then).

=3D=3D>MT
We have updated the text so that a Security Context is retrieved first, before checking the Group Flag bit.

See especially Section 7 (second bullet point) and the rephrasing for the IANA registration in Section 11.1.
<=3D=3D


* "For each ongoing observation, the server MUST include in the first
  notification": This may get sucked up by a proxy that doesn't forward
  until a following notification arrives.

  Moreover, it may be unnecessary if the rekeying fits snugly between
  notifications.

  Suggested alternative:

  The server can help the client synchronize by sending the Gid as the
  ID Context for notifcations following a rekeying. If there is a known
  upper limit to the duration of a full rekeying, it SHOULD set the Gid
  during that time. Otherwise, it SHOULD set it until the Max-Age of the
  last notification before the rekeying has expired.

=3D=3D>MT
Thanks, we have accordingly updated the last two paragraphs in Section 8.3.1.
<=3D=3D


* "Senders MUST NOT use the pairwise mode to protect a message intended
  for multiple recipients.": That's a factual and not an
  interoperability statement. It can not.

  If that's meant to rule out a pairwise request to the broadcast
  address (hoping that the right node will answer), it should say
  "protect a message sent to multiple recipients".

  (But probably that's not what's meant, given 9.1 proposes an address
  discovery resource, and for accessing that by a single KID the
  pairwise mode would make a good choice).

=3D=3D>MT
Thanks for this good input. It should be captured now in the sixth and seventh paragraphs of Section 9.
<=3D=3D


* Sections 9.2ff are described as a delta to 8.1ff.

  Given the external_aad and key choices are already in the section 9
  header, would there be any per-step delta left to explain at all if
  they were instead relative to RFC8613 Section 8? That'd make Section 9
  a lot slimmer.

=3D=3D>MT
Sections 9.2-9.6 have been rewritten as a delta from RFC 8613.
<=3D=3D


* I'm still not fully sold on why the Object-Security option needs to be
  in the external_aad -- but having two versions of the external_aad
  seems extraneous to me. If the option needs to be in there, I think
  it'd be easier to have it in the external_aad for all purposes right
  away.

=3D=3D>MT
This is now explained in the last bullet point of Section 4.3, together with a forward pointer to Section 10.6 where the addressed attack is discussed.

This is also part of the broader update to the external_aad, now having a single format for both modes of operation, and for both signing and encrypting.
<=3D=3D


  Also, was treating the OSCORE option as Class I considered? That
  doesn't solve the problem of having many different external_aad
  constructions, but it'd be using existing mechanism. (Although
  implementors may curse if they didn't do Class I yet).

  I'll come back to that once I've actually implemented it.

=3D=3D>MT
Having the OSCORE option of class I was once considered but just dismissed to not bother implementers :-) That's when relying on the external_aad was considered instead.
<=3D=3D


* "Unless exchanges in a group rely only on unicast messages": I think
  that's only understandable for readers that have an active memory of
  Section 7.4 of RFC8613; it'd need either more context or slimming
  down, maybe like this?

  "As multicast usually involves unreliable transports, the
  simplification of the replay window to a size of 1 that's suggested in
  RFC8613 Section 7.4 is not viable with Group OSCORE."

=3D=3D>MT
Based on your input, we updated Section 10.10 with the current third paragraph.
<=3D=3D


* Summarizing the KID-reuse questions, I think a diagram of the
  componetns may help, like:

                        =E2=86=90--=E2=86=92 KID
  Secret =E2=86=90--=E2=86=92 Group ID  =E2=86=90--=E2=86=92 KID
                        =E2=86=90--=E2=86=92 KID
          =E2=86=91
  Change in             =E2=86=91  =E2=86=91-- Group ID changes allow old=
 KIDs to be reused
  lockstep              |      (but KIDs usually stay the same for effici=
ent rollout)
                        --- KID changes don't necessitate a Group ID chan=
ge

  (are there any other components that can chagnge?)

  In that context: Can an ancient group ID be reused?

=3D=3D>MT
Done. See Figure 2 in Section 3.1.
<=3D=3D


* E.1 and E.2 Best Effort Synchronization / Baseline Synchronization

  A server doing any of these needs to use own Partial IVs all the time.
  It may be acceptable in a scenario to eat the replays, but it's almost
  certainly not acceptable to commit nonce reuse (which *can* happen
  with Best Effort Synchronization).

=3D=3D>MT
Right, *that* whiteboard discussion at the IETF 109 Hackathon! :-)
This has resulted in the following updates:

* Section 2.2 (last paragraph) explains the need to limit the number of Recipient Contexts for an endpoint, and the possibility of an overflow.

* A clearer distinction between anti-replay and freshness. Changes affect the following Sections:

--- 2.2 "Security Context and Recipient Context"
--- 2.4 "Update of Security Context"
--- 2.4.1 "Loss of Mutable Security Context"
--- 2.4.1.1 "Reboot and Total Loss"
--- 2.4.1.2 "Overflow of Recipient Contexts"
--- 6.1 "Update of Replay Window"
--- 6.2 "Message Freshness"
--- 10.10 "Replay Protection" (Security considerations)
--- 10.11 "Message Freshness" (Security considerations)
--- Appendix E (was E.3) "Challenge-Response Synchronization"

* Removed the old Appendix E.1 and Appendix E.2, as non relevant synchronization approaches.
<=3D=3D


* E.3 Challenge-Response Synchronization:

  "The server MUST NOT set the Echo Option to a value which is both
  predictable and reusable." While this is technically correct, it's
  hard to evaluate as a reader. How about "The Echo option value SHOULD
  not be reused, and when it is MUST be highly unlikely to have been
  used with this client recently."?

=3D=3D>MT
Done, see the second paragraph of current Appendix E.
<=3D=3D


  * "sends a request as a unicast message addressed to the same server":

    That should indicate pairwise mode.

    There's later paragraphs on this where 10.7 is mentioned, but given
    how widely this open things up, pairwise mode should be mandatory on
    Echo recovery.

=3D=3D>MT
Done, see the fifth paragraph of current Appendix E.
<=3D=3D


  * "The server either delivers the request to the application if it is
    an actual retransmission of the original one, or discards it
    otherwise": For that the server would need to remember. Ther *is*
    somethign to take care of, though: Only the first time the Echo
    request arrives it can be processed, otherwise it may reset an
    already good replay window.

    Suggesting to replace the paragraph with:

    "If the verification is successful and the replay window has not
    been set yet, the server updates its Replay Window to mark the
    current sequence number as seen (but all newer ones as new), and
    forwards the message as fresh to the application.

    Otherwise, it discards the verification result and treats the
    message as fresh or replay according to the existing replay window."<=
/pre>

=3D=3D>MT
Done, see the second paragraph after the bullet list, in current Appendix E.
<=3D=3D


    "(believed to be) lost"

    How is that not a binary thing? (May relate to the first question).
    Either there is a replay window, in which case it can be used (and
    it does get fast-forwarded in need be), or not and it needs to be
    recovered.

    The following paragraphs elaborate on what a loss would mean, but
    don't explain why it would be relevant. Something like this would be
    applicable if we only ever transported the last bits of the sequence
    numbers in a sliding-window fashion, but that's not what happens in
    OSCORE.

=3D=3D>MT
Done.

Thanks a lot again for your input and comments!

Best,
/Marco
<=3D=3D


KR
Christian



____________________________=
___________________
core mailing list
core@=
ietf.org
https://eur02.safelinks.prote=
ction.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%=
2Fcore&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cc21e90c15f74443ad3=
e008d8859c67df%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374062540918=
15430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI=
6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DSC37JAoObx0rWMO%2FVKg89UqH=
54lmO3ObPSqcDBRPdtc%3D&amp;reserved=3D0


--=20
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------10E28C7708CBBCCEB7ECA604-- --vtVo2imYVap0oMzTLL4cz5BKLFE5h6rJD-- --S6ANAbb8Fk0tLM3re6yKlftdVz2W7fSWH Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmA37akFAwAAAAAACgkQ7iZktA5Y2kOT Owf/bApfbghs7HOibZMhR/QSDhin83jA2THgSRHZ1UM70cwj+bp85mLSIYFmA4i9SwIgq9gdrBAg z2A9oO2V64PJxSBmfXqKA19YIxQIygZmBXphUMgluLOOjDYR3L05cHB3IZn9yPtZLzKgPsP4Uzfl raX2MvuTGWDi+eqgOMWaRxogZQkhZMpzChlAfxx5mx6Q0STPNTQNajDfGnUZgIRxjsDns8as/kSB x4P03xMy3N2ot2CMFT0aDgmh8Kr6pFR76rBHH7YgCena5Xs/MHn0A7N1dhF8q3TH7fNsuMKXyTGg yctMkOKNx8IlJoEwRQ+I+s2NGKPMRDv6ll2pUZ3ecw== =rq/P -----END PGP SIGNATURE----- --S6ANAbb8Fk0tLM3re6yKlftdVz2W7fSWH-- From nobody Fri Feb 26 07:32:40 2021 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 A98ED3A0BF2; Fri, 26 Feb 2021 07:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0XfUKz3dWt9; Fri, 26 Feb 2021 07:32:31 -0800 (PST) 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 C4E0A3A0C35; Fri, 26 Feb 2021 07:32:29 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B2DCE4008A; Fri, 26 Feb 2021 16:32:27 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5FF15D3; Fri, 26 Feb 2021 16:32:26 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:75d0:c9b0:c6c2:2ab5]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2225B14E; Fri, 26 Feb 2021 16:32:26 +0100 (CET) Received: (nullmailer pid 1691897 invoked by uid 1000); Fri, 26 Feb 2021 15:32:25 -0000 Date: Fri, 26 Feb 2021 16:32:25 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Benjamin Kaduk Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com Message-ID: References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c/tqedRag0XcgZzl" Content-Disposition: inline In-Reply-To: <161301561820.4693.9535939287401361803@ietfa.amsl.com> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with 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: Fri, 26 Feb 2021 15:32:34 -0000 --c/tqedRag0XcgZzl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ben, thanks for the updates. All but the last have, if any, editorial changes pending in the issue tracker; on that certificates point I could use a short "yes that's what I meant" or other suitable answer. > [...], but seems to rather just be relating to the RD faithfully > disseminating the information the RD retrieved from /.well-known/core > discovery on the given server(s) (or otherwise learned via some other > mechanism). > In this sense the RD is just acting as a cache or efficiency aid, but > the authoritative source of the information remains (in general) the > server hosting the resource. To be clear, I think the procedures that > this document specifies are good and correct procedures for a client to > perform, I'm just not sure whether "authorized" is the right term in > these cases; "authoritative" might be more appropriate, in that the > operation in question is to verify the information retrieved from the RD > (which acts in some sense as an intermediary) at the more authoritative > source. To get these fine points right I think I'd need an updated security glossary and a generally more aligned CoRE terminology on authority and information sources. IMO the right place for this is the further discussion on how to do better in the space between "trust the RD" and "ask again". The continuing work on CoRAL at https://github.com/core-wg/coral/issues/59 is a starting point. > [...] For some time during this document's development, the URI > template "/.well-known/core{?ep,...}" has been in use instead. >=20 > (It's not entirely clear to me what the reader is expected to do with > the information about the previous formulation.) New readers can take it as a curious historical note -- but even though a rought survey indicated that all implementations are straightforward to upgrade, we might have missed some that took this mechanism that sat there stable for most of the lifetime of this document for stable and deployed based on it. For those cases, this gives the RD operator who finds themselves confused by such a POST the hint to find where things went wrong. > * If neither is present, a reference to the security session itself > is stored. With (D)TLS, that is the connection itself, or the > session resumption information if available. With OSCORE, that is > the security context. >=20 > Should we talk about whether the lifetime of registration entries is > related to the various lifetimes of these credentials/identifiers? DTLS > without resumption is perhaps an interesting case, in that keeping the > DTLS association "live" just to be able to update the registration > information seems impractical, so perhaps some fixed cap would be > applied on the lifetime in that case. If resumption is used, the > resumption information (ticket or session state) has some finite > lifetime that could be used to bound the lifetime of the registration. > IIRC an OSCORE security context can also have an expiration time; > certificates and JWT/CWT have expiration time as well (though the > procedures in the first bullet point would effectively allow a "renewal" > operation), but the validity period (if any) of a raw public key would > have to be provisioned along with that key (or just have RPK be handled > akin to DTLS without resumption, I guess). For DTLS, I expect that this is either done with resumption in mind, or on connections that are kept alive for other reasons (like the proxying =66rom resource-directory-extensions). When resumption is used, the finite lifetime of the ticket does not give an automatic limit to the permissible lifetime, for (AFAIK) a new ticket can be obtained. If lifetime limits base on the authorization are, they should be applied consistently not only to first-come-first-remembered, but also to other time-limited authorizations and other circumstances (eg. RDs that only take long-lived registrations from specially authorized registrants like CTs).=20 These are, in general, hard for the device to act on -- its choices are to not be discoverable (which, in models like LwM2M makes them not even available for reconfiguration) or to spend more resources for keepalives than it is configured to (which we currently have no means to express; core-problem-details would help here). Under those considerations, I expect that the RD taking the registration even with a longer-than-comfortable-or-realistic lifetime is usually the best option and should thus be the generally expected way of operation. Other modes can be explored as well, and I've taken this up in the resource-directory-extensions collection (but can't promise that anything will come of it). > Section 7.3 >=20 > In this case, the endpoint (and not the lookup clients) needs to be > careful to check the RD's authorization. >=20 > (It seems that something also needs to cause the RD to check the > authorization of lookup clients to receive the information in question, > which might be worth reiterating in this section.) Queued for updated text as "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)". > Section 7.5 >=20 > * If the client's credentials indicate any subject name that is > certified by any authority which the RD recognizes (which may be > the system's trust anchor store), all those subject names are > stored. [...] >=20 > I'm pretty sure the intent here is that only the subject names that are > certified by the recognized authority(ies) are stored, in which case I'd > suggest to s/all those/all such/. Good point, queued up. > With X.509 certificates, the Common Name (CN) and the complete > list of SubjectAltName entries are stored. In both cases, the > authority that certified the claim is stored along with the > subject, as the latter may only be locally unique. >=20 > (I can understand why the "store the whole list" logic is used, though > there may be some subtleties about name constraints on the (X.509) CAs > used, which is why we typically don't recomment treating the entire list > of names in the certificate as validated from a single operation, > instead preferring "is this certificate authenticated for this specific > name?" when the specific target name is available.) > > [...] > > (Similar to my earlier parenthetical comment, the requirement for exact > match of all subject name information is unusual. In effect this is a > way of pinning the set of names that the CA has chosen to include in a > single certificate, which is arguably a stronger requirement than needed > but should not lead to any unauthorized access.) Not sure I get this right -- would If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes **for that name** (which may be the system's trust anchor store), all those subject names are stored."=20 be a suitable resolution? I'd prefer to stick with the possibly suboptimal but at any rate easy to implement rule. I expect the typical RD to be coming more from a JWT / CWT / ACE background and not so much from an X.509 one. (Of course that may be just my personal angle speaking). "Match all" is hard to get wrong, even if it may be a tad stricter than absolutely necessary. If we can phrase the rule better in a concise form that is still easy to understand for implementers, let's get this last point right -- other than that, there can still be documented variations on this policy. BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --c/tqedRag0XcgZzl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmA5FIQACgkQOY0REtOk veFsQA/+OaskFMWxyG30GL9K5ARZCIyc8+DqyfffH1Mbd2mrks69pcK3UC95ElQy JU0wFDsox98BYkqqrMkjb1HYUuRxtmikIQgkhOrsiqCWN9ZYOi7DurLCQmhPkrG1 /YUx53/L9HDwreEVaqQyoT3mCoUvRKxQt9nJiL3ecI/bLXa6Ky4vYSFfYOg/0oEF fRbSO6f1pFi6rY7JQbPbo/MjDoUEGQ9h22ZaXTwRxEOt+/Gn0Yh60r2YyUTfmsWP FimVDPGOv3OuvEW1gRlEmTImjy1Krp7JlpImOV6cX28420Bvo6mPJNfS97TLH0mM 311VRK0BGcmCiQy08319qNt+HohZti8NaYDks77+BkMfsnxqHMhl7E2msMHEuXSZ NUSPIIe9BY9FQ9ZxQfINer3WoyBLz1pD3BBFBQuB6ONejAAyyiQDV4CiaMsgKfN+ EwOCo7/Z/dZfrlDwn27TpdPhxn6Vs0dPUWwqc7RjtMkOZJwAb+ZgAl32ISfL2Fxk +imaorVwoZO/uPX/XAjx/50PlBYEnugSR6e6kokRI+Bo9eCrVGRAnGcYVzjiZ6N/ uphnJr9r4bqL0xBQ0JrvSgCL8nPHXLnGFXMMA0TnVPejBiakjdOPF26QbQ89Amj9 Bu3hO3RmFOrNQyAG0nZnyxFko0sOi5cO2kAj3Q+L3KGa8NMJQqQ= =gA4M -----END PGP SIGNATURE----- --c/tqedRag0XcgZzl-- From nobody Sat Feb 27 12:56:56 2021 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 2DBC03A1445; Sat, 27 Feb 2021 12:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKF0eJ7hh_i5; Sat, 27 Feb 2021 12:56:53 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390DA3A1444; Sat, 27 Feb 2021 12:56:51 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11RKudTP027489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Feb 2021 15:56:44 -0500 Date: Sat, 27 Feb 2021 12:56:38 -0800 From: Benjamin Kaduk To: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com Message-ID: <20210227205638.GJ21@kduck.mit.edu> References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with 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: Sat, 27 Feb 2021 20:56:55 -0000 Hi Christian, (inline) On Fri, Feb 26, 2021 at 04:32:25PM +0100, Christian M. Amsss wrote: > Hello Ben, > > thanks for the updates. > > All but the last have, if any, editorial changes pending in the issue > tracker; on that certificates point I could use a short "yes that's what > I meant" or other suitable answer. > > > [...], but seems to rather just be relating to the RD faithfully > > disseminating the information the RD retrieved from /.well-known/core > > discovery on the given server(s) (or otherwise learned via some other > > mechanism). > > In this sense the RD is just acting as a cache or efficiency aid, but > > the authoritative source of the information remains (in general) the > > server hosting the resource. To be clear, I think the procedures that > > this document specifies are good and correct procedures for a client to > > perform, I'm just not sure whether "authorized" is the right term in > > these cases; "authoritative" might be more appropriate, in that the > > operation in question is to verify the information retrieved from the RD > > (which acts in some sense as an intermediary) at the more authoritative > > source. > > To get these fine points right I think I'd need an updated security > glossary and a generally more aligned CoRE terminology on authority and > information sources. > > IMO the right place for this is the further discussion on how to do > better in the space between "trust the RD" and "ask again". The > continuing work on CoRAL at https://github.com/core-wg/coral/issues/59 > is a starting point. That seems like a fine place to have this discussion; the only thing I might consider for this document is to use "authoritative" instead of "authorized" in the couple places I indicated. But I'll leave that up to you, since you've thought about it more than I have... > > [...] For some time during this document's development, the URI > > template "/.well-known/core{?ep,...}" has been in use instead. > > > > (It's not entirely clear to me what the reader is expected to do with > > the information about the previous formulation.) > > New readers can take it as a curious historical note -- but even though > a rought survey indicated that all implementations are straightforward > to upgrade, we might have missed some that took this mechanism that sat > there stable for most of the lifetime of this document for stable and > deployed based on it. For those cases, this gives the RD operator who > finds themselves confused by such a POST the hint to find where things > went wrong. > > > * If neither is present, a reference to the security session itself > > is stored. With (D)TLS, that is the connection itself, or the > > session resumption information if available. With OSCORE, that is > > the security context. > > > > Should we talk about whether the lifetime of registration entries is > > related to the various lifetimes of these credentials/identifiers? DTLS > > without resumption is perhaps an interesting case, in that keeping the > > DTLS association "live" just to be able to update the registration > > information seems impractical, so perhaps some fixed cap would be > > applied on the lifetime in that case. If resumption is used, the > > resumption information (ticket or session state) has some finite > > lifetime that could be used to bound the lifetime of the registration. > > IIRC an OSCORE security context can also have an expiration time; > > certificates and JWT/CWT have expiration time as well (though the > > procedures in the first bullet point would effectively allow a "renewal" > > operation), but the validity period (if any) of a raw public key would > > have to be provisioned along with that key (or just have RPK be handled > > akin to DTLS without resumption, I guess). > > For DTLS, I expect that this is either done with resumption in mind, or > on connections that are kept alive for other reasons (like the proxying > from resource-directory-extensions). When resumption is used, the finite > lifetime of the ticket does not give an automatic limit to the > permissible lifetime, for (AFAIK) a new ticket can be obtained. Yes. I think my mental model was that the limit based on the ticket lifetime would be provisional and could be extended if the ticket was used to resume and a new ticket issued on the resumed session. > If lifetime limits base on the authorization are, they should be applied > consistently not only to first-come-first-remembered, but also to other > time-limited authorizations and other circumstances (eg. RDs that only > take long-lived registrations from specially authorized registrants like > CTs). > > These are, in general, hard for the device to act on -- its choices are > to not be discoverable (which, in models like LwM2M makes them not even > available for reconfiguration) or to spend more resources for keepalives > than it is configured to (which we currently have no means to express; > core-problem-details would help here). > > Under those considerations, I expect that the RD taking the registration > even with a longer-than-comfortable-or-realistic lifetime is usually the > best option and should thus be the generally expected way of operation. > Other modes can be explored as well, and I've taken this up in the > resource-directory-extensions collection (but can't promise that > anything will come of it). Okay. That's all I can ask for, and thanks for talking it through a bit here. > > Section 7.3 > > > > In this case, the endpoint (and not the lookup clients) needs to be > > careful to check the RD's authorization. > > > > (It seems that something also needs to cause the RD to check the > > authorization of lookup clients to receive the information in question, > > which might be worth reiterating in this section.) > > Queued for updated text as "The RD (always, but especially here) then > needs to verify any lookup client's authorization before reveling this > information directly (in resource lookup) or indirectly (when using it > to satisfy a resource lookup search criterion)". > > > Section 7.5 > > > > * If the client's credentials indicate any subject name that is > > certified by any authority which the RD recognizes (which may be > > the system's trust anchor store), all those subject names are > > stored. [...] > > > > I'm pretty sure the intent here is that only the subject names that are > > certified by the recognized authority(ies) are stored, in which case I'd > > suggest to s/all those/all such/. > > Good point, queued up. > > > With X.509 certificates, the Common Name (CN) and the complete > > list of SubjectAltName entries are stored. In both cases, the > > authority that certified the claim is stored along with the > > subject, as the latter may only be locally unique. > > > > (I can understand why the "store the whole list" logic is used, though > > there may be some subtleties about name constraints on the (X.509) CAs > > used, which is why we typically don't recomment treating the entire list > > of names in the certificate as validated from a single operation, > > instead preferring "is this certificate authenticated for this specific > > name?" when the specific target name is available.) > > > > [...] > > > > (Similar to my earlier parenthetical comment, the requirement for exact > > match of all subject name information is unusual. In effect this is a > > way of pinning the set of names that the CA has chosen to include in a > > single certificate, which is arguably a stronger requirement than needed > > but should not lead to any unauthorized access.) > > Not sure I get this right -- would > > If the client's credentials indicate any subject name that is > certified by any authority which the RD recognizes **for that name** > (which may be the system's trust anchor store), all those subject > names are stored." > > be a suitable resolution? That might just be making things more complicated for minimal benefit (and if it is used the s/those/such/ from an earlier comment would still be needed). Basically, what the current text is doing is saying that "we trust this issuer at least sometimes, and will just lump everything they named into a single conglomerate and treat that conglomerate as an opaque thing that must match exactly in the future". In that sense we don't actually care which names the issuer put in or whether we trust the issuer to be an authority for all those names -- the actual identifier is "the stuff the CA put in the cert" and we only need it as an opaque identifier like that. > I'd prefer to stick with the possibly suboptimal but at any rate easy to > implement rule. I expect the typical RD to be coming more from a JWT / > CWT / ACE background and not so much from an X.509 one. (Of course that > may be just my personal angle speaking). "Match all" is hard to get > wrong, even if it may be a tad stricter than absolutely necessary. > > If we can phrase the rule better in a concise form that is still easy to > understand for implementers, let's get this last point right -- > other than that, there can still be documented variations on this > policy. I don't think we're really going to be able to do better than "match all" here without a lot of complications. The current "match all" is a little constraining on the CA's operations, but it is simple, as you note. So I think my comment here is really just a comment, and not suggesting any (additional) changes to this document at this time. Maybe in the future we'll have some better ideas... Thanks, Ben From nobody Sat Feb 27 13:01:43 2021 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 C3BE33A1453; Sat, 27 Feb 2021 13:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=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 MMSTYw47oxbz; Sat, 27 Feb 2021 13:01:38 -0800 (PST) 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 8AE6C3A1452; Sat, 27 Feb 2021 13:01:37 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DnzTq6b4NzyjR; Sat, 27 Feb 2021 22:01:35 +0100 (CET) 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: <20210227205638.GJ21@kduck.mit.edu> Date: Sat, 27 Feb 2021 22:01:35 +0100 Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, The IESG , core@ietf.org X-Mao-Original-Outgoing-Id: 636152495.4408799-035fe1448d9237c48d5e551c3beb31cf Content-Transfer-Encoding: quoted-printable Message-Id: <16D35A91-1919-44A7-97AB-16BF80CD85B9@tzi.org> References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> <20210227205638.GJ21@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with 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: Sat, 27 Feb 2021 21:01:41 -0000 On 2021-02-27, at 21:56, Benjamin Kaduk wrote: >=20 > use "authoritative" instead of > "authorized" in the couple places I indicated Authoritative sounds like it is an intrinsic property of the source. Authorized means that the specific policies that apply to the consumer = authorize use of the source for the purpose at hand. So I think this substitution should not occur lightly. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Feb 27 13:38:19 2021 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 5FE843A14C6; Sat, 27 Feb 2021 13:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 gPw2EHh9HCHk; Sat, 27 Feb 2021 13:38:12 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A163A14C5; Sat, 27 Feb 2021 13:38:11 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11RLbxgA005383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Feb 2021 16:38:04 -0500 Date: Sat, 27 Feb 2021 13:37:59 -0800 From: Benjamin Kaduk To: Carsten Bormann Cc: Christian =?iso-8859-1?Q?Ams=FCss?= , Jaime =?iso-8859-1?Q?Jim=E9nez?= , core-chairs@ietf.org, draft-ietf-core-resource-directory@ietf.org, The IESG , core@ietf.org Message-ID: <20210227213759.GN21@kduck.mit.edu> References: <161301561820.4693.9535939287401361803@ietfa.amsl.com> <20210227205638.GJ21@kduck.mit.edu> <16D35A91-1919-44A7-97AB-16BF80CD85B9@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16D35A91-1919-44A7-97AB-16BF80CD85B9@tzi.org> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-resource-directory-26: (with 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: Sat, 27 Feb 2021 21:38:14 -0000 On Sat, Feb 27, 2021 at 10:01:35PM +0100, Carsten Bormann wrote: > On 2021-02-27, at 21:56, Benjamin Kaduk wrote: > > > > use "authoritative" instead of > > "authorized" in the couple places I indicated > > Authoritative sounds like it is an intrinsic property of the source. > Authorized means that the specific policies that apply to the consumer authorize use of the source for the purpose at hand. > So I think this substitution should not occur lightly. When the data in question is "what resources are available at this host", I think authoritative is pretty intrinsically a property of the host itself :) Now, if the question was "what resources are supposed to be at this host that I'm allowed to use?", your considerations become quite relevant. -Ben From nobody Sun Feb 28 14:09:38 2021 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 E870D3A086E for ; Sun, 28 Feb 2021 14:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-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 (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 XHyV-TKCo2u9 for ; Sun, 28 Feb 2021 14:09:34 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 88C5F3A085E for ; Sun, 28 Feb 2021 14:09:34 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id u187so9900549wmg.4 for ; Sun, 28 Feb 2021 14:09:34 -0800 (PST) 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:content-transfer-encoding; bh=FP3b/Aay9AHiAJmKAl/ZkMDX1Y6QdPdWU1RtHEBxIdg=; b=UvAo4ySD6pec9eUQRr0uEtIXD7Yv4OSHpkhHLSG48kgoFe+2FNQYSV/WWtOrAac0UB YAFMZz6EJTd3UGCu+jsNXUJaezHbcgpdAxBTlrAX5HYWmFoVkLf26E/BBSc7XsiOCqfZ ebAa7ZbW+XxXQ77Tg7pER42DdOuAHtlhoB+9GkfBiLom5dr77xO4kyK1Gs+ta6wc6r/D 4Yp0ZTDzHQYRFBytELEXAiYaXsw9Tuzs684tSu/GVnEfmoh8nbHEbxg+YGchwYhrsc6K a391VjdW/v6wm5fxXPnXpC8KOmtC8zHdrbRcM0FJIHSatW2Ldr1jHR3qKyyZWVAFVa+7 P8tg== 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=FP3b/Aay9AHiAJmKAl/ZkMDX1Y6QdPdWU1RtHEBxIdg=; b=XGYQr8e0qhYVDOUqDgsSZ4AC/ldlaf+DBgrkzbEsMCYhszgGQP15M9vPuZnfcWPSoM EuZ9sBK8Rh4ezwQmYjQAJqIKyt3cjgi0+zTlYM7rNxU+6fORJsrrMbL1ipvPVrOSXuMW w7/xt4oirwn29P25LJIxQi3xn4roLLEdGG/n9Z4NSwBjuLvXsZ0S5+CvT3CcBSvJRSYk BFJtBSYZP2jW1clsBy310suaWHR68jRpuN/l/UvMcA7AHbkPqxHmMgDtClvrS8IHcrgJ lg+C0TnT+pe648qZX+B9Fy0S7Ct5WxRyRCBanPsVjfjm9J+vtPcSHuagj9FJahIyKndX wfAw== X-Gm-Message-State: AOAM533neZKvTl8kr6XUNsWBFHqWx2irtLoKRa+cZS1u0ZwEI7XAzJ8g JN+pFRa53XiVLgH1ZA2JuFr3RShAiRlPr69LjWnVZw== X-Google-Smtp-Source: ABdhPJzjOTtf40vt+XiqN/4P1n8TyC1AvksgiFauK1wpx0PpL5SmzVO2PrrtUNFWF6KSjSF5IoeZv6IVDhnN841tHqw= X-Received: by 2002:a7b:ca50:: with SMTP id m16mr2999410wml.113.1614550171779; Sun, 28 Feb 2021 14:09:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Sun, 28 Feb 2021 23:09:05 +0100 Message-ID: To: Carsten Bormann Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] draft-ietf-core-comi-11 shepherd 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: Sun, 28 Feb 2021 22:09:37 -0000 Hello Carsten, Thank you for your review! Please find my answers below (prefixed with [IP]= ). Best regards, Ivaylo On Thu, Feb 4, 2021 at 5:47 AM Carsten Bormann wrote: > > In my shepherd review of draft-ietf-core-comi-11, I have found a few poin= ts that probably need some WG action before we can submit this draft to IES= G. > (I also have submitted a PR addressing some nits, https://github.com/core= -wg/comi/pull/1 .) > > Specifically: > > # Major > > *** 5: This whole section is rather disappointing. What does this > really do except for pointing at RFC 7959? Is there any > recommendation in how to work around the race condition? The > recommendation to use indefinite length is not solving any problem > (does not work except in very fortuitous cases). [IP]: I understand your disappointment. It appears to me that we should try to state more clearly the issue that is being discussed and for me there are two separate ones that are mixed. The first one is insufficient resources to send the response. It might be insufficient bandwidth of the network (maybe can be solved with SCHC as well) or insufficient memory on the server. If it is the latter, I am really not certain if that is something we should be solving. The second issue is obtaining a snapshot of a consistent snapshot of the state. For me we can call this out as a possible issue, but indeed recommending indefinite length arrays solves such a small part of the issue, that probably it is better not mentioning it at all. > *** 6.2.2 How does the pagination work, then? > This SHOULD is not actionable. [IP]: If I understand correctly your objection is that we are not prescribing anything concrete, therefore the SHOULD is not helping in reality. If that is the case, do you still agree that this is a problem worth solving? If so, should we specify in more details a mechanism (or refer to one that is already well described elsewhere), or can you think of better options. > *** 7: This creates confusion between 4.01 and 4.03 [IP]: I will update the text to point to 4.01 as not having valid authentication, not as forbidden as it currently sounds. > # Minor > > *** 2.2: While it is not clear whether there will be a SID 0, the text > seems to imply that this would be encoded in the empty string. > Should it rather specify a single "A=E2=80=9D? [IP]: That sounds good to me. > *** Appendix A: Updated to reference RFC 8949 (see PR). > Do we need a new module version after this edit? [IP]: I don't know what are the best practices for module versions while writing the draft. I do not object to this. > > Gr=C3=BC=C3=9Fe, Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Feb 28 14:10:02 2021 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 1FC323A0890 for ; Sun, 28 Feb 2021 14:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kvEsJUTrV-AI for ; Sun, 28 Feb 2021 14:09:54 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 7EB213A08A7 for ; Sun, 28 Feb 2021 14:09:54 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id f12so10296773wrx.8 for ; Sun, 28 Feb 2021 14:09:54 -0800 (PST) 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:content-transfer-encoding; bh=MXBInk2549oS/oW95CjrCm79vfMSB5D09yKAgUDRAlM=; b=GJ7NRgJ7aL24qiw2hz4PKMPF1ZNAkMA97A78UPVT8pVJdT/rCWQSEE2s5jp1rdrJgi JKfIhZ7npH2sKsEvbAALL1eKB8/emtR/R5Jdjx7YFnUWB0shv7u6oQJCEo8T6TD9b/gL Tuu2hm1/WNvpGoFKV+kojmDQDqXCPOtnM2JyvDEF/GuD4T2iCJZ/WrS8/smHDdu0+dqb 4Tbq7vm7eh4uoipw8pWc8LQO0AjOJ/eLRQTkDiD2dvfi71Uv5go6PlfSZ/zX3ZZxF2Xg Y+qYDqTe8HafIUdDqjHQiI1MdZGkbnQhTvf5i1jIi/6ClaZI+hts++j0ItGAGwdrxP4/ VOng== 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=MXBInk2549oS/oW95CjrCm79vfMSB5D09yKAgUDRAlM=; b=ADW6ON29ssAnfEgjaWmeiunJXvtghvSAksT7F7mt//cdr3luTzVaF7EwFcly/YQ4L7 h0XRXtB13E30aq8InReajlmluaOp4v+PusAH6+AaM1qhJQQt2jQvEet/4FBeblliBspF 66dd1zSgaaZxfqyFnBFCfzAeJWA8dbx5hD8kTnZycTwsAJyiEhlV5uvbnUoCVHn+8v04 pVFAhTkOvoA/XuG701+Uknly1YI2GLbsiVRGz37XrCET3D9BrP3cO8w3jyP3Z+41WtZo 66i3ZXqczqkx6TVgRupYcN6aAaEiZFNRv7+XM2MwBwO8BUHOe+BnJ9Oih3SazeHxOHnB JjkQ== X-Gm-Message-State: AOAM533eirQ1Gn8rwbYSB5Hi0SbFHfCRn4O6SuF3Nr56SfywvUcZqkai 3mfOGrysC9j+mzzfr3Qw6UFqnllb7FzbLK1dzWd5fG9/JvG9oQ== X-Google-Smtp-Source: ABdhPJxSC/4mirZN+e76GSjxpfsMNWqAw/LYuXiix8xsm4pH1EHRXV2R0ZI9+t2hPwL9AIg311bJCXxJyFvgHgEZU+A= X-Received: by 2002:a5d:4203:: with SMTP id n3mr13396821wrq.116.1614550191658; Sun, 28 Feb 2021 14:09:51 -0800 (PST) MIME-Version: 1.0 References: <63510607-74A6-4218-BE87-10EC6F4ACB38@tzi.org> In-Reply-To: <63510607-74A6-4218-BE87-10EC6F4ACB38@tzi.org> From: Ivaylo Petrov Date: Sun, 28 Feb 2021 23:09:25 +0100 Message-ID: To: "core@ietf.org WG (core@ietf.org)" Cc: NetMod WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] draft-ietf-core-comi-11 shepherd 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: Sun, 28 Feb 2021 22:09:56 -0000 Hello Carsten, Thank you for your review! Please find my answers below (prefixed with [IP]= ). Best regards, Ivaylo On Mon, Feb 22, 2021 at 3:28 PM Carsten Bormann wrote: > > Please note an interesting discussion over at netmod. > > Archived-At: and up. > > It seems we a converging to a conclusion that means that the table at the= top of page 14 in draft-ietf-core-comi-11.txt [1] is not wrong (it would m= ake certain updates of a YANG module a non-backwards compatible change in t= he way we build URIs from that). > > [1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14 > > That said, maybe we still want to look at why uint and int coding are so = (unnecessarily?) different in their URL encodings. [IP]: It sounds better to me to harmonize this. I will try to see if any of the other authors have specific reasons not to do that. > > Gr=C3=BC=C3=9Fe, Carsten > > > > > On 2021-02-04, at 05:47, Carsten Bormann wrote: > > > > In my shepherd review of draft-ietf-core-comi-11, I have found a few po= ints that probably need some WG action before we can submit this draft to I= ESG. > > (I also have submitted a PR addressing some nits, https://github.com/co= re-wg/comi/pull/1 .) > > > > Specifically: > > > > # Major > > > > *** 5: This whole section is rather disappointing. What does this > > really do except for pointing at RFC 7959? Is there any > > recommendation in how to work around the race condition? The > > recommendation to use indefinite length is not solving any problem > > (does not work except in very fortuitous cases). > > > > *** 6.2.2 How does the pagination work, then? > > This SHOULD is not actionable. > > *** 7: This creates confusion between 4.01 and 4.03 > > > > # Minor > > > > *** 2.2: While it is not clear whether there will be a SID 0, the text > > seems to imply that this would be encoded in the empty string. > > Should it rather specify a single "A=E2=80=9D? > > > > *** Appendix A: Updated to reference RFC 8949 (see PR). > > Do we need a new module version after this edit? > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Feb 28 14:26:12 2021 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 5E2B83A0A25 for ; Sun, 28 Feb 2021 14:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cPPCsz6bzoPj for ; Sun, 28 Feb 2021 14:26:07 -0800 (PST) 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 9F5233A0A1C for ; Sun, 28 Feb 2021 14:26:07 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DpdJq6912zySB; Sun, 28 Feb 2021 23:26:03 +0100 (CET) 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: Date: Sun, 28 Feb 2021 23:26:03 +0100 Cc: "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 636243963.3886729-5219eee778714abbf228bb9cc2d82321 Content-Transfer-Encoding: quoted-printable Message-Id: <5004CBB9-0905-4B00-964A-B8C490AFA4CE@tzi.org> References: To: Ivaylo Petrov X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] draft-ietf-core-comi-11 shepherd 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: Sun, 28 Feb 2021 22:26:10 -0000 On 2021-02-28, at 23:09, Ivaylo Petrov wrote: >=20 >> *** 5: This whole section is rather disappointing. What does this >> really do except for pointing at RFC 7959? Is there any >> recommendation in how to work around the race condition? The >> recommendation to use indefinite length is not solving any problem >> (does not work except in very fortuitous cases). >=20 > [IP]: I understand your disappointment. It appears to me that we > should try to state more clearly the issue that is being discussed and > for me there are two separate ones that are mixed. The first one is > insufficient resources to send the response. It might be insufficient > bandwidth of the network (maybe can be solved with SCHC as well) or > insufficient memory on the server. If it is the latter, I am really > not certain if that is something we should be solving. >=20 > The second issue is obtaining a snapshot of a consistent snapshot of > the state. For me we can call this out as a possible issue, but indeed > recommending indefinite length arrays solves such a small part of the > issue, that probably it is better not mentioning it at all. I think my point was that this is a set of problems that all = applications that use block-wise transfer have. RFC 7959 has some brief = guidance in its section 7.1, but I agree that a more extensive treatment = should be written up. Just not here=E2=80=A6 I believe there should not be a section 5, and the one sentence or so = that points out the issue can maybe merged with the item down below. >> *** 6.2.2 How does the pagination work, then? >> This SHOULD is not actionable. >=20 > [IP]: If I understand correctly your objection is that we are not > prescribing anything concrete, therefore the SHOULD is not helping in > reality. If that is the case, do you still agree that this is a > problem worth solving? If so, should we specify in more details a > mechanism (or refer to one that is already well described elsewhere), > or can you think of better options. Resource-directory actually went ahead and put in a basic form of = pagination. But, again, this is a general YANG problem, and we should defer to that = being solved for YANG, e.g., as in https://tools.ietf.org/html/draft-wwlh-netconf-list-pagination-nc-01 (*) Putting in a SHOULD for something that isn=E2=80=99t defined yet is not = the right approach here, but we could very well mention that future = additions to YANG/*CONF for pagination could be used to mitigate the = problem. Gr=C3=BC=C3=9Fe, Carsten (*) Does anyone know what happened to this draft?