Re: [core] CoRE rechartering: proposed text
Marco Tiloca <marco.tiloca@ri.se> Thu, 14 October 2021 13:56 UTC
Return-Path: <marco.tiloca@ri.se>
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 850943A16A0 for <core@ietfa.amsl.com>; Thu, 14 Oct 2021 06:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 N4y_MGDYL1kL for <core@ietfa.amsl.com>; Thu, 14 Oct 2021 06:56:33 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2079.outbound.protection.outlook.com [40.107.21.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C87A3A0982 for <core@ietf.org>; Thu, 14 Oct 2021 06:56:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q76SZ7og1UVTWURmVZa7NoiyJEMwCKDoM5v0q8LvoK7EleWzk7syYwg3WpxsJ+039udjWow0yZ7p7SLpypgfTbPf6Z26ADEXPQ7vXA2ZiMhuolupWknUNoftfYFLtYObjbxPKf2J0Y1qGk1W5aswbRZQRaZFTptC2zO44fkvOSS7GMJwN7jw8gRXkAL1RK/geQU4MVRX/hmMVfMPw8jgeHb5NrwkYud3TsoAsYSxY/jMFcVV51v2Z3JB+cItN2mL3SIS1l3q+xE4EPhUYyVaHGPHxGTEJG0TH6QzkXfbYZEcdgVhGuVTYQi5LqflAGt2a9R++HpGZqezN7A6IMH+Rw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZqAX62+dqkSUoKftnc88kqPkkhitp8K1VPrd75e9We8=; b=hYvA9bSZucHd5LilUpophz2hDQ32zV2eEdQVHL2fib/9LOlxESJcnfaWS3Nwy4rG3CgtkRVKbxUJ1k2VMXcEXuoQDjJR72Ae7T25SKRu20cmPbtkYiV1jfvethLgerzanSwHTlCxBcsBSWjkD42BnKFGKb0kzzdG7WPS/bRAOzDACpfXmRicO7nXMlTQRKvTJGhdduI+7idla0TmpXFJ+NmO3DqcdMOGW0ruMJqZcaIqGxLCBdmtOKN7yaMS/bd2RUr4JLE8+WF5Nb7RxReca+Y5yVsZjZ+JY5TMeOqCe7MWEzOHtQIdCcAFyvJG9tdBJ6GWT6KReNwam7nw0JRX+A==
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=ZqAX62+dqkSUoKftnc88kqPkkhitp8K1VPrd75e9We8=; b=Sv+bQ8n+syUcjj4eySwYQ+3bQfVsDDXTa2NLjILfnEA5JjBITYBMtO9icRIK9rNRTNzH4PU6F2/CBS9tE1I6/qOLAVfi5p3jbhgdb/x01ik3s56brMbMU6fFvQp+GBH2+1OkvWEnMNet/WDkOIPU8ThQh3WchW+5QDCkQlXWsR8=
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 DB9P189MB1498.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:26d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Thu, 14 Oct 2021 13:56:23 +0000
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4dd0:ed4b:e776:d560%3]) with mapi id 15.20.4587.026; Thu, 14 Oct 2021 13:56:22 +0000
To: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
References: <b91fb1fb-6d54-5594-2424-e1ca37d501f5@ri.se> <fe11a970-4750-1b58-eaed-1863fa0dfe48@ri.se> <AM8P190MB09799B48F4E50F7515BA60B8FDA09@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
From: Marco Tiloca <marco.tiloca@ri.se>
Message-ID: <290101ab-0022-0ed7-424e-dc5d6c73b401@ri.se>
Date: Thu, 14 Oct 2021 15:56:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: <AM8P190MB09799B48F4E50F7515BA60B8FDA09@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="e2Ez66JLFivLKOcepd4uzEWIVJ1cwVcpA"
X-ClientProxiedBy: HE1PR05CA0209.eurprd05.prod.outlook.com (2603:10a6:3:f9::33) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14)
MIME-Version: 1.0
Received: from [10.8.0.5] (185.236.42.79) by HE1PR05CA0209.eurprd05.prod.outlook.com (2603:10a6:3:f9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14 via Frontend Transport; Thu, 14 Oct 2021 13:56:22 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e64849e7-6004-4706-6e11-08d98f1a6801
X-MS-TrafficTypeDiagnostic: DB9P189MB1498:
X-Microsoft-Antispam-PRVS: <DB9P189MB1498386D9B3AA692848E6CF899B89@DB9P189MB1498.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: iYUOEzeDMIN5gs8h+iR+g8UUb6C2GJkcsj2mWn8nJB3jojr46La7cazEVQiT0u5+oHi5GzFXgySVvVIT4aaGE2/10QihetRwHrq1vuckrZmzmXhb6ZPVjq8Kvh9fVdrmtvoGL5HWPUdKyXTGKWP09KriTD1DwUVPsF4t4yWqfzaTvkbj25nW1Do6q59pXOZS/YVSa47CW+J1UQYmuc37xzmGKsQ6dxZ7SrKWFQvSHbwbtJTIGtMPDMhOX7okQdh95s+aQyatCnGMorhSwmhkkDAnX+uSbbnXI1EQ70HY/VjlzyIaYynFfO06WDkRIpWH6Y3FQgsjzuolMNca6MsO1vlU/gMq0//0mOOc7zXh468flE/mOO/rBomdXizJh2rUVro5w7elVcix0iznHCzBJJ35L44N2XhrK7aDLsIo/pw0/xArD5wc96TFsBUe127j+rZ8fvP5JvcGIvTczUyBHaLU2x9VHRv5jS9BK81NwZ3zEYqUPpZsoiwl1XRyO7xLglPE/F0JL8ko13lHgxEB847khMvmQ/8Ypdrj+ap/q29GuQ7EfOkMghVjT8/8pK2avtl+ZU+pG68RuUWLrRnFkNVeRtPWXs1SsvXXsLOGxB5IboLE7Kkct4sns0EfxXhm0Uw5H2d2fbzVdMEbCg32vRwtCnzoe56u3w+bkrKAaiR+A5nfIzdLfuKehVKhlvvjpNeSpH0Eg3nHLU6M5yvTAe2KFRXcZn56Ye6sPoxW9su/FP9In4D8OtJo/hVZM7BFj5szC/pntzpT/AwNIZL8Z7c0kvUeB5SQ3c4IwcjHm/mluCDBFHUuVuRlN8d9a80QqTAa+vsvsO/i26a9TVWH9/zdbVVd8rybTO0TNbNimJ4=
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)(16576012)(2906002)(6486002)(53546011)(966005)(66476007)(235185007)(45080400002)(33964004)(6916009)(44832011)(83380400001)(8676002)(4001150100001)(66946007)(66574015)(186003)(5660300002)(26005)(316002)(8936002)(66556008)(508600001)(31696002)(38100700002)(21480400003)(30864003)(2616005)(36756003)(956004)(31686004)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: VjkBNxMfGKlhCtmSOL0lU7ZkaRZBuThDOhD9BRCJZgmxGvADyqsqsTaCLdMq3VO/FGhRupcEXKPbVN9v4t0Mg7E7xY6+fDs4Be9YswFMQah1DCInjVCU2Ge34xtYpj4IjX1WOC1MpHTyV4R3/dJMh576peTE07TR8yP5VKqQYwTpd8hHQCxNKoloB3WNQdhALvWRI+bo9vElukMzUpd54Mi6PgDx9VS0HwRviSMAhjnjFjOg99JCoiWS5WYMZjd6At2O5SbSjQuYxyzw579HTc2pqMxg17bauIc7E5k7KYno5UWSbNPLl0i/ZmqsOOM68eyElir46oW/m418mCThVRcfN67nsNc7PdQ2rXVHgm3pRUXJfXeumArnZC5Fxs7tmMaYcLvoxvTrNYePlBki+UlKSSYSS2ygtdiT4x9he5acGj53+aCeapu4ucI+lWhDArlgxzJXEGZ2OzmJ3VivA45iwSHalP9D6zzidRfp2dQPWdmwDZqVCWPQkZGT7nuLrgDGL+2AHp0U6Qxf7phvvHqzYourkpAyh+NCJtLwwXL/BHXmVdKGIsq83qxATot5FN5hCy1w5pEA/IB0Rruv8DB05XyU7QTa5yNfBXpQbcsR7m4dYj5GFJL+0rdgK3/RKCX9tVmR/S2MnaELcHx4LGWQkCq8Zrx8d7MNHXnxKuiNMQ+BCr+twHiCQvDoJ5vFB9k35b+V4BqkS7mZXlJW/RY/6bWzaXBOEk+lvnmfC6yu1MayYiolEk4wd5J9nqFMho1TIhKl1IZH7X5EIRKfkfsW7xORI+OuI/ufRkJzUoiQMio+7JQyCm1oNpp8SiF6sXDh+7VGgqJ456pPEV9oH0iqonqapN/TAJ3wMs2bgfs/2qFzjv/E7WDPMWEOUUGWudFtTVPDQT1+TAT3KwjzAKyskuCs5Illu126opKVFxbo9JKiiw1nPyccxg9DZ9iGJAD6Cd4TvLRKCmXW63X4THvOz+RyEMN6ZLoc89xAFV0D8FoWxaNUk4aMXRkr8WA9odUw90UApas5QS1mIILlFniO2MHx0xn8YaE2jgJ/10d8cjdG861R6LxnzOu7V/zBHCkPNq1VN5nP9vccm9ahgg5cVdCw2m3d4Ni0SaXEruZJYIVeMOT5n22gMzVSL7Dul55a+HGh1hHoghWQ7Dqc85r+JmNa5pyJ7VQTp1vZMDIGbXpRf144R9oQLbTBSWpXinGpFjwMvs2tMviWrHZcsMZYG/wJcTDEYIFUgdaeTkqt5rGjuqyW+eNCoxbw+4ZkPeknEa49pMmSjZnzgK5/9B/Gv3pEWEEEGZZ+Iflr/sjY5YayjmGLJf3JhgEbwPGn
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: e64849e7-6004-4706-6e11-08d98f1a6801
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2021 13:56:22.8811 (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: IQdqzwAelVJseKRO+/DfdHhaF9goYMyiifcsGPfRTWOALBSZztyfbNwnQZ2M/Vitxrc0CZ87KF6+aPYkGh723g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1498
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/_GRboz-ir1581SOVUH5R7lonKg4>
Subject: Re: [core] CoRE rechartering: proposed text
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2021 13:56:42 -0000
Hi all, Following the discussion at the 2021-10-13 interim meeting [1], we have now made available the compressed charter text proposed by Göran --- Thanks! This is essentially a subset of the original proposal from 2021-09-08 with roughly the same content but fewer words. Hence, it is an improved starting point to build a revised charter for more convenient consideration. You can find the compressed text as a Pull Request at [2] and at the top of the usual CodiMD document at [3]. No word-smithing has been done on this text yet. Please, provide any comment and contribution on [2] and [3] as you prefer. Thanks, Marco and Jaime [1] https://datatracker.ietf.org/doc/minutes-interim-2021-core-12-202110131600/ [2] https://github.com/core-wg/core-wg.github.io/pull/1 [3] https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both On 2021-09-20 14:17, Esko Dijk wrote: > Hello, > > Current text looks good to me. It is a quite detailed charter; good to have it updated now to reflect recent progress. Also it is good as an introduction to CoRE, or as overview of the latest status & work. > Possible downside of a detailed charter is that it needs to be updated more often! > > Regards > Esko > > -----Original Message----- > From: core <core-bounces@ietf.org> On Behalf Of Marco Tiloca > Sent: Thursday, September 16, 2021 09:22 > To: core@ietf.org WG (core@ietf.org) <core@ietf.org> > Subject: Re: [core] CoRE rechartering: proposed text > > Hi all, > > During the 2021-09-15 interim meeting [1], we had a good first > discussion on the proposed new text for the possible updated charter. > > As mentioned at the meeting, please take some time to review the new > text and possibly provide input/comments. Even in case you are just fine > with the text "as is", it is valuable feedback to say so. > > > Please, provide your comments and proposed changes: > > - In this mail thread, where the first message [2] also includes the new > proposed charter text; > > and/or > > - In this CodiMD document [3], where editing requires to be logged in > with your Datatracker account. > > > The new charter text is also available on our Github at [4], together > with a diff from the present charter text at [5]. > > Thanks, > Marco and Jaime > > > [1] > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-interim-2021-core-10-202109151600%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QOc1k5wnajJE0H%2B7gSKx5RAmjWrI6eC3pIJz38f1Ksk%3D&reserved=0 > > [2] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FhaBtninO85UjsyqASeeO0FFr_Wo%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1opdeqGfrPVvgperbBLRrb%2Fn9oMMxQHHGp9li5UnlW4%3D&reserved=0 > > [3] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnotes.ietf.org%2FBkpQ-gttSRuVKlEgxho5gw%3Fboth&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wy7ZjbOS%2Fq8AKEu5N4l67WVb322r0pYYvwEYjsLQomo%3D&reserved=0 > > [4] > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fcore-wg.github.io%2Fblob%2Fmaster%2Fcore-charter.txt&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GUk2LT8JmyhSRH1cXjWjKkc%2BPtDfiRKjrUNsQVofLok%3D&reserved=0 > > [5] > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fcore-wg.github.io%2Fcommit%2F133861a92ef62a2130427521455fb58bce23aa3e%3Fbranch%3D133861a92ef62a2130427521455fb58bce23aa3e%26diff%3Dsplit&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PrCkKcNmh%2FxDWOyfRCSeuClrvu9oPpjNJJai77AGiZE%3D&reserved=0 > > > On 2021-09-08 19:34, Marco Tiloca wrote: >> Hi all, >> >> During the CoRE session at IETF 111 [1][2], it was proposed to update >> our charter, for better reflecting the current status of our work. >> This is also helpful for the IESG review processing and for newcomers >> to more easily understand the WG scope and direction. >> >> As promised, the Chairs have prepared an initial proposed text for the >> WG to consider. Please, find the proposed text at the end of this mail >> as well as in the CodiMD at [3]. >> >> With that as starting point, this mail starts a discussion on the new >> charter text. Please, provide your comments and proposed changes here >> on the mailing list or in the CodiMD at [3] (editing requires to be >> logged in). >> >> Best, >> Marco and Jaime >> >> >> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-111-core%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hp16Z5Pul%2BWqb3%2B3tZLBcqG9zpdacPKES39lKlQwYxk%3D&reserved=0 >> >> [2] >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F111%2Fmaterials%2Fslides-111-core-chairs-slides-00.pdf&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5KYC8BayVPx1Av5wXVkYHRruS1WZelLIVdmsutk0q8o%3D&reserved=0 >> >> [3] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnotes.ietf.org%2FBkpQ-gttSRuVKlEgxho5gw%3Fboth&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wy7ZjbOS%2Fq8AKEu5N4l67WVb322r0pYYvwEYjsLQomo%3D&reserved=0 >> >> >> ======================= >> >> The CoRE Working Group (WG) provides a framework for resource-oriented >> applications intended to run on constrained IP networks. A constrained >> IP network has limited packet sizes, may exhibit a high degree of >> packet loss, and may have a substantial number of devices that may be >> powered off at any point in time but periodically "wake up" for brief >> periods of time. These networks and the nodes within them are >> characterized by severe limits on throughput, available power, and >> particularly on the complexity that can be supported with limited code >> size and limited RAM per node [RFC 7228]. More generally, we speak of >> constrained node networks whenever at least some of the nodes and >> networks involved exhibit these characteristics. Low-Power Wireless >> Personal Area Networks (LoWPANs) are an example of this type of >> network. Constrained networks can occur as part of home and building >> automation, energy management, and the Internet of Things. >> >> The CoRE WG will define a framework for a limited class of >> applications: those that deal with the manipulation of simple >> resources on constrained networks. This includes applications to >> monitor simple sensors (e.g., temperature sensors, light sensors, and >> power meters), to control actuators (e.g., light switches, heating >> controllers, and door locks), and to manage devices. >> >> The general architecture targeted by the CoRE WG framework consists of >> nodes on the constrained network, called Devices, that are responsible >> for one or more Resources that may represent sensors, actuators, >> combinations of values, and/or other information. Devices send >> messages to change and query resources on other Devices. A Device can >> send notifications about changed resource values to Devices that have >> expressed their interest to receive notification about changes. A >> Device can also publish or be queried about its resources. Typically, >> a single physical host on the network would have just one Device but a >> host might represent multiple logical Devices. The specific >> terminology to be used here is to be decided by the working group. >> >> As part of the framework for building these applications, the CoRE WG >> has defined the Constrained Application Protocol (CoAP) for the >> manipulation of Resources on a Device. CoAP is designed for use >> between Devices on the same constrained network, between Devices and >> general nodes on the Internet, and between Devices on different >> constrained networks both joined by an internet. CoAP is also being >> used via other mechanisms, such as SMS on mobile communication >> networks. CoAP targets the type of operating environments defined in >> the ROLL and 6Lo WGs, which have additional constraints compared to >> normal IP networks. Nevertheless, the CoAP protocol also operates over >> traditional IP networks. >> >> There also may be intermediary nodes acting as proxies that possibly >> also interconnect between other Internet protocols and the Devices >> using the CoAP protocol. It is worth noting that a proxy does not have >> to occur at the boundary between the constrained network and the more >> general network, but can be deployed at various locations in the >> less-constrained network. The CoRE WG will continue to evolve the >> support of proxies for CoAP to increase their practical applicability. >> >> CoAP supports various forms of "caching". Beyond the benefits of >> caching already well known from REST, caching can be used to increase >> energy savings of low-power nodes by allowing them to be normally-off >> [RFC 7228]. For example, a temperature sensor might wake up every five >> minutes and send the current temperature to a proxy that has expressed >> interest in notifications. When the proxy receives a request over CoAP >> or HTTP for that temperature resource, it can respond with the last >> notified value, instead of trying to query the Device which may not be >> reachable at this time. The CoRE WG will continue to evolve this model >> to increase its practical applicability. >> >> The CoRE WG will perform maintenance as well as possible updating and >> complementing on its first four standards-track specifications as >> required: >> >> - RFC 6690 >> - RFC 7252 >> - RFC 7641 >> - RFC 7959 >> >> The CoRE WG will continue to evolve the support for CoAP group >> communication originally developed in the Experimental RFC 7390. The >> CoRE WG will not develop a solution for reliable multicast delivery of >> CoAP messages, which will remain Non-Confirmable when sent over >> multicast. >> >> RFC 7252 defines a basic HTTP mapping for CoAP, which was further >> elaborated in RFC 8075. This mapping will be evolved and supported by >> further documents as required. >> >> CoAP was initially designed to work over UDP and DTLS. Later on, >> mapping were defined between CoAP and IP-based transports, especially >> TCP and WebSockets including a secure version over TLS (RFC 8323). The >> CoRE WG will continue defining transport mappings for alternative >> transports as required, both IP-based and non IP-based (e.g., SMS and >> Bluetooth), working with the Security Area on potentially addressing >> the security gap. This includes defining appropriate URI schemes. >> Continued compatibility with CoAP over SMS as defined in OMA >> Lightweight Machine-to-Machine (LwM2M) will be considered. >> Furthermore, the CoRE WG will work on solutions to facilitate the >> signaling of transports available to a Device. >> >> The CoRE WG will continue and complete its work on the CoRE Resource >> Directory (draft-ietf-core-resource-directory), as already partially >> adopted by OMA LwM2M, and will perform maintenance as well as possible >> updating, complementing and specification of relevant uses as >> required. A primary related consideration is the interoperability with >> DNS-SD and the work of the dnssd WG. The use of CoAP to transport DNS >> queries and responses will also be investigated. Furthermore, the CoRE >> WG will also continue and complete its work on enabling broker-based >> publish-subscribe-style communication over CoAP >> (draft-ietf-core-coap-pubsub). >> >> The CoRE WG will work on related data formats, such as alternative >> representations of RFC 6690 link format and RFC 7390 group >> communication information. Also, the CoRE WG will complete its work on >> Constrained Resource Identifiers for serializing URI components in >> CBOR (draft-ietf-core-href). Furthermore, the CoRE WG will develop >> CoRAL (draft-ietf-core-coral), a constrained RESTful application >> language suitable also for constrained node networks, which comprises >> an information model and an interaction model, and is intended for >> driving automated software agents that navigate a Web application. The >> CoRE WG will complete the Sensor Measurement Lists (SenML) set of >> specifications, again with consideration to its adoption in OMA LwM2M. >> >> Besides continuing to examine operational and manageability aspects of >> the CoAP protocol itself, the CoRE WG will also complete the work on >> RESTCONF-style management functions available via CoAP that are >> appropriate for constrained node networks (draft-ietf-core-yang-cbor, >> draft-ietf-core-sid, draft-ietf-core-comi, >> draft-ietf-core-yang-library). This requires very close coordination >> with NETCONF and other operations and management WGs. YANG data models >> are used for manageability. Note that the YANG modeling language is >> not a target for change in this process, although additional >> mechanisms that support YANG modules may be employed in specific cases >> where significant performance gains are both attainable and required. >> The CoRE WG will continue to consider the OMA LwM2M management >> functions as a well-accepted alternative form of management and >> provide support at the CoAP protocol level where required. >> >> The CoRE WG originally selected DTLS as the basis for the >> communication security in CoAP. The CoRE WG will work with the TLS WG >> on the efficiency of this solution. The preferred cipher suites will >> evolve in cooperation with the TLS WG and CFRG. >> >> The CoRE WG considered object security as originally defined in JOSE >> and later adapted to the constrained node network requirements in >> COSE. Building on that, the CoRE WG has defined the Object Security >> for Constrained RESTful Environments (OSCORE) protocol (RFC 8613) for >> protecting CoAP messages at the application layer using COSE. The CoRE >> WG will complete the work on the Group OSCORE protocol >> (draft-ietf-core-oscore-groupcomm) that enables OSCORE-protection of >> CoAP messages in group communication environments. Also, the CoRE WG >> will complete an optimization-oriented profiling of the EDHOC protocol >> developed in the LAKE WG, when this is used to establish security >> material for OSCORE (draft-ietf-core-oscore-edhoc). Furthermore, the >> CoRE WG will perform maintenance as well as possible updating and >> complementing of the (Group) OSCORE documents above as required. >> >> The ACE WG is expected to provide solutions on authentication and >> authorization that may need complementary elements on the CoRE side. >> >> The CoRE WG will coordinate on requirements from many organizations >> and SDOs. The CoRE WG will closely coordinate with other IETF WGs, >> particularly of the constrained node networks cluster (6Lo, 6TiSCH, >> LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT), and with further >> appropriate groups in the IETF OPS and Security Areas. Work on these >> subjects, as well as on data/interaction models and design patterns >> (including follow-up work around the CoRE Interfaces draft) will >> additionally benefit from close cooperation with the Thing-to-Thing >> Research Group. >> >> ======================= >> >> -- Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)
- [core] CoRE rechartering: proposed text Marco Tiloca
- Re: [core] CoRE rechartering: proposed text Marco Tiloca
- Re: [core] CoRE rechartering: proposed text Esko Dijk
- Re: [core] CoRE rechartering: proposed text Marco Tiloca
- Re: [core] CoRE rechartering: proposed text Carsten Bormann
- Re: [core] CoRE rechartering: proposed text Michael Richardson
- Re: [core] CoRE rechartering: proposed text Carsten Bormann
- Re: [core] CoRE rechartering: proposed text Michael Richardson
- Re: [core] CoRE rechartering: proposed text Carsten Bormann