From nobody Mon Nov 1 05:23: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 A89843A12D0; Mon, 1 Nov 2021 05:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_JfuG1b-mjz; Mon, 1 Nov 2021 05:22:57 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03B03A1302; Mon, 1 Nov 2021 05:22:56 -0700 (PDT) Received: from smtpclient.apple (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HjXHJ5rfmz2xDS; Mon, 1 Nov 2021 13:22:52 +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.120.0.1.13\)) Date: Mon, 1 Nov 2021 13:22:52 +0100 Message-Id: To: "core@ietf.org WG" , cbor@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [core] coap.me, cbor.me outage 2021-11-02T1400Z for about 24 hours 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 Nov 2021 12:23:03 -0000 My group at Uni Bremen is moving within the building, and that will lead = to a temporary outage of the infrastructure behind coap.me and cbor.me We are going to shut down the servers at about 1400 UTC on 2021-11-02 = (tomorrow). If all goes well, we should be up again about 24 hours later. By the way, the functionality of cbor.me is also available on the = command line; please see=20 https://github.com/cabo/cbor-diag/blob/master/README.md =E2=80=A6for installation and usage instructions for the =E2=80=9Ccbor-dia= g=E2=80=9D gem underlying cbor.me Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 1 06:23: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 CC4DF3A12DF for ; Mon, 1 Nov 2021 06:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 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=-3.33, 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 iYauoFQHKAUE for ; Mon, 1 Nov 2021 06:23:03 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on061a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::61a]) (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 875093A1269 for ; Mon, 1 Nov 2021 06:23:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MojkJVNdGV4V0L9gkhboUCLnykKTKVZDPeVrxAqjkHWWwtOo4E4hKBisjYghuTkVlAb4z4tgKHEYtWnHmvmPBv1685QXhP6GrUQ7MbqaX+35LTKyplDQf2hz+EIqVBIZtmL7BgFUthfcouB3lVVkVMPQVLAL+Vf8olgY8zy9O/R69wGiyFn0dMTgF2wHHCn3y/dDCByxHshKvTUhZc2PbrtQmo0lO8Ew7rT5nPXugNIE5RLlRxZCNqURZMRdwQvP2MG+fcHiEE53rJ/8kUsYqg/yK4Opj2Aezya9Y6fux4pK8amt3g1tc1+R1becYE9+AdfEGnK4IuJsFeItjPzICg== 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=glpTjr0sxtGtK3edElnkDm275IfFfycqfczJHWKN+u4=; b=jq6vveo7Sgrf+qE5iRduR0iMccYH5kR+SDIqtR3UR7cdSsJnOvbPjqmIngKoo8BRJg2HImrTAQ8N378B+gjWFKuTl3kt7LWAoNPqDNSMe8Nt+1eMqnlQ8Zz3o0Ga+oyhif9OIQn3Y3Lk8Q2+nnNfCuvQWKV4dR5iBhHiUgpzNSeLn7VbLqR7iUXPNnvKAIvOm5a1Ls6TDcRBYkVledhql+04YDAVBzLv4QuaXlSCVKO5DtY72Xj2QcmHN5OpkNByAdwIUyM2RJkrgXb2n+kqBDcv1/qSqo2fUJkr+vqtqMxwOGVsuhwsjbzP88s0b5PL5tHinoVJBtNXhvDjGb0IAg== 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=glpTjr0sxtGtK3edElnkDm275IfFfycqfczJHWKN+u4=; b=e39C38j/ydzDZ3sTwXhaovoh1/1CN70UXJeQWvnawuo1a3H0xniWz2xE+tVZokGANaNX5yj0Uy7lpW2I9TqkdSyBe65dt1zBA8o30mwaSvterOPuDQhCd1y/n15TluOqLhOcqZd48y8IFvjvjW9DHUP1kG4UygkaEMD/gGTv+o4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0700.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fd::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.15; Mon, 1 Nov 2021 13:22:58 +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.4649.019; Mon, 1 Nov 2021 13:22:58 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <12858828-4b4b-cabf-29e4-92907fa4181b@ri.se> Message-ID: <4f8c77b7-55e4-7316-493d-0e0255cb58cd@ri.se> Date: Mon, 1 Nov 2021 14:22:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <12858828-4b4b-cabf-29e4-92907fa4181b@ri.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YHFgjhvBfiKAhDEjVokdiBkTUXU7to8FD" X-ClientProxiedBy: OL1P279CA0036.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:13::23) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.1.6] (185.219.140.95) by OL1P279CA0036.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:13::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.14 via Frontend Transport; Mon, 1 Nov 2021 13:22:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0e1de3de-1a15-4e66-7f4e-08d99d3ab8ae X-MS-TrafficTypeDiagnostic: DB8P189MB0700: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /ohK0ySCv/lQSEXPI7IK+i3HxwFUSrsWCi4vTuVWSmmlOL5pS2AptjSzQA+xjBhSd1+SibLBmmR4jbaf10of+xwU/rXTSwox7JiWhloMe8BPfS3zICcj94iBVX1x7cs2BKSK+mKCNvRUzshgLTOsDzFAgdMsLRoEPyLND4nvEjTdi7GX13AWP/vsnooBHAN2DmUfcNcDHzhwivyO1T1OIZVsrOgVWLV95fG0TG5FxYkXNmq4UksayqkmKr6Lpy/4W2UXgAp89JPsXRSWaDb2V+xJpMQHS+8cVBDLxzPhVHjHiTAFrxfSpx8AzD3FEwHiQKf1dlbxSVeMeXGI/G3NQUUSvsTxJsmFxMDDEkHGK9g2wp+lbvucZnJjP13RIHgCsHraDw9AdgXAhZ2DPh3vxuVD1EstcEibz7d2SjG9DYhCdC9pZ5gBVzksXfwl1Jj6BkUaqYE1oDfUiv1WArX5sqC1rbuIBxnmCc7SBeMRi7SIfVjhOI/WFJFKdEx1iuRHKvzNPYXmjlIwoQgxs9HrmqbIMoJaD0jKrYJRc0azPooWyV5yJClpxWgcAklrRBvWxU3HV/g9ZCMynbrdpVZjkX4Tqrcv0Vi24oioisjvlz6nmnIClrMqi0NopscetpSu5JWCX67TwaC0uYOeQip7FQCeZ8GX0nloWD99cbD4yqp2TvGy0WsWbvFtjZlhD/p2L/0+/n9HwEVg3Zh6zQyCYP00zAqNQNqIWncL/UmlADis5vYyrcjQcm6y9dLhBcF18d3Pz1tpFY1PEKasQEKTUS2zZqeAM5fNnQ3iPB31xzTgpKpvSgtbk8lIyB0tgLWJ 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)(508600001)(6486002)(44832011)(966005)(31696002)(38100700002)(21480400003)(2616005)(6916009)(956004)(86362001)(26005)(235185007)(36756003)(53546011)(31686004)(5660300002)(66476007)(66946007)(8936002)(8676002)(2906002)(66556008)(4001150100001)(16576012)(33964004)(83380400001)(316002)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QUJEdVd3NmlEeHpwb3RqeGxkK1paa3M4RkJQUUgxemlPN2dvVFFwL21CSWRU?= =?utf-8?B?YlNFVDBLbmJ3bXoxak9iR0V1amRXcUw2ZWw4Ry94UnJtaHg5Z0dJSm5PN2tS?= =?utf-8?B?ZHJyYm9vVy80N0RNRG1IQitVckNkd2lHWFZoeE5PK2E5UnFzcXNQQ3lwVjBz?= =?utf-8?B?VHVQa2dJOU1nM3dPSDE0TzNKc0taVURpRC9YTVZ5cFZLY0VCQzBDcjE0bnk5?= =?utf-8?B?YXBIbGVqQWRTT0FLRU14SXI0TDhsVDdNM3RjTHptVHYreFVNT2JCNUk5eDdU?= =?utf-8?B?SUtaSFhyQUNrK2g1aVFCeGdON2dxczJwbStKdnJsRGl4MjEzZDBsYzR5Ull2?= =?utf-8?B?WWZzdUpoemZRb2t6R09BUFJOeHg1U2cwRFphbTlvQmFVTk9xN1BmSzFMZ0Fp?= =?utf-8?B?SW81S0NReEhoQkx1a2psOXdlek0vdzZnSE9PTnBwUG96cU9lU0NEb1VlbDB6?= =?utf-8?B?eDlROTNXcU5tRElDeUwxS3BieFQxNWdQSkJJYzB2bkxFaHRYa0FaY0lZdi8z?= =?utf-8?B?anFWZ3h0R0pFMUdpbEJTNnZXWjZmYURLWlZ5T0VNbmhUSENOSFZjN21jYzVw?= =?utf-8?B?YkM0WGU4NEdVdElDM25ISDBXMVIrL0NTR2NOdHd2UE9KK3VvNjduTDA0SzhU?= =?utf-8?B?MHRyRkdvNXlva0lEa1JSNFVBMEU4Qk1mdVgvcDZUTmI2VDAwdzBYSjZ5cHVO?= =?utf-8?B?TFhhcXJDeDRBeTFzRXdOejdBazFzamxIdmRGVXZPMDQ2YWRMb0lVZGNCNEF6?= =?utf-8?B?Y3B4SW94MVF1cTY4U0hmLzg2cHJjUUxrdVh1aHZqM3FXYWY2SEhJcGdCWWkz?= =?utf-8?B?aWhHb1pyZGY2c1FYb0IwWFhxYndHcEg2OVN4Q3VLdWtvZHozbjd3VlpHK2cx?= =?utf-8?B?QmIwVWlnM3RZYjAvVTVFeC9LeG1RTVl0OC9uaHM2NkR1NUxLZmhVMjB2V09Z?= =?utf-8?B?cVlGczlPa3dWVnI4LzZiUk5rN0NxWSttc3hXMTl6MDd0enpjdFp0c25sSFQ1?= =?utf-8?B?cFByaVpiWTgvNFhKNm40K3cyRTA5VklqMmZsY2kwMGI0Z3dNNU1SOHVZL1U5?= =?utf-8?B?aVFlZk5FK1B1OTFUa2dUeFJHSWRkLzROcXM3SkpOSUx6aTBDZHlsbVdld2ZG?= =?utf-8?B?dTJleWxlWTZKTzNuZ3pKWEVGVThKQTJ5M09ZcDlRa1NTQ3BiVDdyOHZhbnFU?= =?utf-8?B?UFBmQzk1TnNpUlFJaGx1SENvaDJWRysyczBBMXNXT3dOWlk1cjZCNUJQZ2ZW?= =?utf-8?B?TEJ1bWZUcmYwZ1NDZmZYUldNT0ExaStXUUlYR2JqRU84bzYwVE5LcER3WDRs?= =?utf-8?B?cjNjWWhHbE41aURieCsvbGJpSWQ3Tlg2SVlwRDlOMmtnckxwREp1VVhra00r?= =?utf-8?B?K1BCZG9TSVZNSUtsVlZGdFhIK3F3bTVXU2U5cGZIRWdEYUN6QjVKQ2I1NFhW?= =?utf-8?B?SmcxUUxONDJxRWJncytDbUxseUdFRk0weC90RzBYZXlDWWdPa0FtSXA2alln?= =?utf-8?B?dzVKZXRwYmprMldyOHhnbS9CL2tsei8rWUZ5d1A5bmwySUFQQXBqWVQwYTQ0?= =?utf-8?B?VllYOEFDTlF1aERsczdTU1pySHJFc0Y4RkQyQlFoUTVWak54MVVBR0RmS0tw?= =?utf-8?B?eTBYUncxR2NXeVFhNW1XYlJrQWt0dEcveVJnSVJXMWZ1V25EQWRoSTBOQ09s?= =?utf-8?B?VWhLOUJBYU9KQ2lWaUJPajBHaFEvTUVSUURSQ29INVplcEh6LzJGQzhJcU9Q?= =?utf-8?B?T2NGWEYyN2dOcS9QNkN6OEJOcVAweWRCSkdNUlpZT1d0dnJzMUdWNTRHc3Bp?= =?utf-8?B?Z3ZNUnprbUtyY2RzeDNxTGgxRWd4NUtGZ1BTV2hTdG56SENqMEdIeERaMlVL?= =?utf-8?B?TFJoRm04WGxVT1krd25VV1NiMnVEUDVBYUFsb0d2Q0l2UlZaa0h3Q3JhWU5C?= =?utf-8?B?S2NON2s0bUk0aEJTMFc2aWhOek1vZ1cvMEp2L2ZhK2xCMUpnOUoxQ3FvYmg3?= =?utf-8?B?N1dCaWlacDhSNGxLcnlyS0gxOFZiQzlKTnRPYUtqVjFaZDFuZ0wyS1lvbHdy?= =?utf-8?B?RDBKS2ZRZCtyRE9KeFJWODVOSTYwcExPWThkT1c0V3JlbU5ubGpPYWFXMExZ?= =?utf-8?B?WTJWQU9lbEd2YTNqQWVOOGtTZ281eGpVdlZqUGhaSWpFaldWTmwwS0wvV0FI?= =?utf-8?Q?FJ8agO3uQIHPR81G1PaDGe0=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 0e1de3de-1a15-4e66-7f4e-08d99d3ab8ae X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2021 13:22:58.3814 (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: Aq0XW07koUV+9ynQVvZ8xzIPzgG7v3XRoG75yvzAPigr46hA9aK+AOaYgyDmIXttfK4tz+CnGLUeye6nMFSX/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0700 Archived-At: Subject: Re: [core] CoRE Agenda for IETF 112 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 Nov 2021 13:23:09 -0000 --YHFgjhvBfiKAhDEjVokdiBkTUXU7to8FD Content-Type: multipart/mixed; boundary="aGIXuUDULdN4gpysS9bzem5UcZxdREHPs"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <4f8c77b7-55e4-7316-493d-0e0255cb58cd@ri.se> Subject: Re: [core] CoRE Agenda for IETF 112 References: <12858828-4b4b-cabf-29e4-92907fa4181b@ri.se> In-Reply-To: <12858828-4b4b-cabf-29e4-92907fa4181b@ri.se> --aGIXuUDULdN4gpysS9bzem5UcZxdREHPs Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, The revised agenda for the CoRE session is now avaiable at: https://datatracker.ietf.org/doc/agenda-112-core/ Presenters, please upload your slides as a PDF file to [1] latest on=20 Sunday, the 7th of November. Thanks, Marco and Jaime [1] https://datatracker.ietf.org/meeting/112/session/core On 2021-10-27 22:30, Marco Tiloca wrote: > Dear all, > > An agenda based on what has been submitted and on recently ongoing=20 > activities is now available at: > > https://datatracker.ietf.org/doc/agenda-112-core/ > > > Those who want to run a slot, please: > > - check the person suggested to run the slot and possibly provide an=20 > alternative; > - check that the estimated time for the slot is ok > > > Please, send a mail with this information or other comments to=20 > core-chairs@ietf.org > > > Best, > Marco and Jaime > --=20 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=C3=A5ngen 16 SE-164 40 Kista (Sweden) --aGIXuUDULdN4gpysS9bzem5UcZxdREHPs-- --YHFgjhvBfiKAhDEjVokdiBkTUXU7to8FD Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmF/6jAFAwAAAAAACgkQ7iZktA5Y2kOD cwf/RqtoXdSrLQRmeiYjWCc9wA/BfPf5Dk28uWnH1pe77rDIxbO1K5/Cs7PiS2Fb6umy6Pg3tvpu JfwCUFA664cooXCPUjE7XBqPSfEiouU0Simsn00ulD4zZZ8kCcfWFfa3r2jJ/VSVfY58QUmGt0Oi XCX4ZNf7NEDXt9/eYGPoU8Vij8PpIszm8nNm2duioTbQzVhZwQrbBw+sHQIbvkeI0x42evWt52cY k56yOKGI23qMsC2Hafo9P64mtkuWXPv4hQbxxyurbPyDefozO2pizSSGFXIS4NfMzqhcxrQd3oXv xmq13cGDdUxQxLGVqs5PbVDXv/CdcJ5e9ViDldF4tA== =pxYH -----END PGP SIGNATURE----- --YHFgjhvBfiKAhDEjVokdiBkTUXU7to8FD-- From nobody Mon Nov 1 07:40: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 117B93A1386 for ; Mon, 1 Nov 2021 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 fWJGCw1YU0ZK for ; Mon, 1 Nov 2021 07:40:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7330F3A1385 for ; Mon, 1 Nov 2021 07:40:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 499) id 4B777200CEC; Mon, 1 Nov 2021 07:40:28 -0700 (PDT) To: rfc-editor@rfc-editor.org From: RFC Errata System Cc: veijo.pesonen@nordicsemi.no, fluffy@iii.ca, zach.shelby@arm.com, jari.arkko@piuha.net, ari.keranen@ericsson.com, cabo@tzi.org, core@ietf.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20211101144028.4B777200CEC@rfc-editor.org> Date: Mon, 1 Nov 2021 07:40:28 -0700 (PDT) Archived-At: Subject: [core] [Editorial Errata Reported] RFC8428 (6728) 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 Nov 2021 14:40:33 -0000 The following errata report has been submitted for RFC8428, "Sensor Measurement Lists (SenML)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6728 -------------------------------------- Type: Editorial Reported by: Veijo Pesonen Section: 11 Original Text ------------- SenML-Pack = [1* record] record = { ? bn => tstr, ; Base Name ? bt => numeric, ; Base Time ? bu => tstr, ; Base Units ? bv => numeric, ; Base Value ? bs => numeric, ; Base Sum ? bver => uint, ; Base Version ? n => tstr, ; Name ? u => tstr, ; Units ? s => numeric, ; Sum ? t => numeric, ; Time ? ut => numeric, ; Update Time ? ( v => numeric // ; Numeric Value vs => tstr // ; String Value vb => bool // ; Boolean Value vd => binary-value ) ; Data Value * key-value-pair } Corrected Text -------------- SenML-Pack = [1* record] record = { ? bn => tstr, ; Base Name ? bt => numeric, ; Base Time ? bu => tstr, ; Base Units ? bv => numeric, ; Base Value ? bs => numeric, ; Base Sum ? bver => uint, ; Base Version ? n => tstr, ; Name ? u => tstr, ; Units ? s => numeric, ; Sum ? t => numeric, ; Time ? ut => numeric, ; Update Time ? ( v => numeric // ; Numeric Value vs => tstr // ; String Value vb => bool // ; Boolean Value vd => binary-value ), ; Data Value * key-value-pair } Notes ----- It would show good style to set the comma even though it's not required. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8428 (draft-ietf-core-senml-16) -------------------------------------- Title : Sensor Measurement Lists (SenML) Publication Date : August 2018 Author(s) : C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Nov 1 08:09: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 2FFA23A08D6 for ; Mon, 1 Nov 2021 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzvWKBr-Rpus for ; Mon, 1 Nov 2021 08:09:19 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238DB3A1315 for ; Mon, 1 Nov 2021 08:09:19 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HjbzJ0qYFz2xKP; Mon, 1 Nov 2021 16:09:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <20211101144028.4B777200CEC@rfc-editor.org> Date: Mon, 1 Nov 2021 16:09:15 +0100 Cc: veijo.pesonen@nordicsemi.no, fluffy@iii.ca, Zach Shelby , jari.arkko@piuha.net, =?utf-8?Q?Ari_Ker=C3=A4nen?= , core@ietf.org X-Mao-Original-Outgoing-Id: 657472155.278751-6f636e841af27e73e231596cd9feccc3 Content-Transfer-Encoding: quoted-printable Message-Id: <6A230DD5-7695-4F0A-A7CF-93750E586D08@tzi.org> References: <20211101144028.4B777200CEC@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [Editorial Errata Reported] RFC8428 (6728) 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 Nov 2021 15:09:24 -0000 This is a valid stylistic nit, but of no consequence to implementation = or interoperability. Please mark as =E2=80=9Ceditorial=E2=80=9D. Gr=C3=BC=C3=9Fe, Carsten > On 2021-11-01, at 15:40, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8428, > "Sensor Measurement Lists (SenML)". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6728 >=20 > -------------------------------------- > Type: Editorial > Reported by: Veijo Pesonen >=20 > Section: 11 >=20 > Original Text > ------------- > SenML-Pack =3D [1* record] >=20 > record =3D { > ? bn =3D> tstr, ; Base Name > ? bt =3D> numeric, ; Base Time > ? bu =3D> tstr, ; Base Units > ? bv =3D> numeric, ; Base Value > ? bs =3D> numeric, ; Base Sum > ? bver =3D> uint, ; Base Version > ? n =3D> tstr, ; Name > ? u =3D> tstr, ; Units > ? s =3D> numeric, ; Sum > ? t =3D> numeric, ; Time > ? ut =3D> numeric, ; Update Time > ? ( v =3D> numeric // ; Numeric Value > vs =3D> tstr // ; String Value > vb =3D> bool // ; Boolean Value > vd =3D> binary-value ) ; Data Value > * key-value-pair > } >=20 > Corrected Text > -------------- > SenML-Pack =3D [1* record] >=20 > record =3D { > ? bn =3D> tstr, ; Base Name > ? bt =3D> numeric, ; Base Time > ? bu =3D> tstr, ; Base Units > ? bv =3D> numeric, ; Base Value > ? bs =3D> numeric, ; Base Sum > ? bver =3D> uint, ; Base Version > ? n =3D> tstr, ; Name > ? u =3D> tstr, ; Units > ? s =3D> numeric, ; Sum > ? t =3D> numeric, ; Time > ? ut =3D> numeric, ; Update Time > ? ( v =3D> numeric // ; Numeric Value > vs =3D> tstr // ; String Value > vb =3D> bool // ; Boolean Value > vd =3D> binary-value ), ; Data Value > * key-value-pair > } >=20 > Notes > ----- > It would show good style to set the comma even though it's not = required. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8428 (draft-ietf-core-senml-16) > -------------------------------------- > Title : Sensor Measurement Lists (SenML) > Publication Date : August 2018 > Author(s) : C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. = Bormann > Category : PROPOSED STANDARD > Source : Constrained RESTful Environments > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG From nobody Mon Nov 1 08:28: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 E52B13A07CC; Mon, 1 Nov 2021 08:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 0N584eMERb9f; Mon, 1 Nov 2021 08:28:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B2E3A0776; Mon, 1 Nov 2021 08:28:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 499) id 14AF4E52A3; Mon, 1 Nov 2021 08:28:12 -0700 (PDT) To: veijo.pesonen@nordicsemi.no, fluffy@iii.ca, zach.shelby@arm.com, jari.arkko@piuha.net, ari.keranen@ericsson.com, cabo@tzi.org From: RFC Errata System Cc: francesca.palombini@ericsson.com, iesg@ietf.org, core@ietf.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20211101152812.14AF4E52A3@rfc-editor.org> Date: Mon, 1 Nov 2021 08:28:12 -0700 (PDT) Archived-At: Subject: [core] [Errata Held for Document Update] RFC8428 (6728) 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 Nov 2021 15:28:17 -0000 The following errata report has been held for document update for RFC8428, "Sensor Measurement Lists (SenML)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6728 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Veijo Pesonen Date Reported: 2021-11-01 Held by: Francesca Palombini (IESG) Section: 11 Original Text ------------- SenML-Pack = [1* record] record = { ? bn => tstr, ; Base Name ? bt => numeric, ; Base Time ? bu => tstr, ; Base Units ? bv => numeric, ; Base Value ? bs => numeric, ; Base Sum ? bver => uint, ; Base Version ? n => tstr, ; Name ? u => tstr, ; Units ? s => numeric, ; Sum ? t => numeric, ; Time ? ut => numeric, ; Update Time ? ( v => numeric // ; Numeric Value vs => tstr // ; String Value vb => bool // ; Boolean Value vd => binary-value ) ; Data Value * key-value-pair } Corrected Text -------------- SenML-Pack = [1* record] record = { ? bn => tstr, ; Base Name ? bt => numeric, ; Base Time ? bu => tstr, ; Base Units ? bv => numeric, ; Base Value ? bs => numeric, ; Base Sum ? bver => uint, ; Base Version ? n => tstr, ; Name ? u => tstr, ; Units ? s => numeric, ; Sum ? t => numeric, ; Time ? ut => numeric, ; Update Time ? ( v => numeric // ; Numeric Value vs => tstr // ; String Value vb => bool // ; Boolean Value vd => binary-value ), ; Data Value * key-value-pair } Notes ----- It would show good style to set the comma even though it's not required. -------------------------------------- RFC8428 (draft-ietf-core-senml-16) -------------------------------------- Title : Sensor Measurement Lists (SenML) Publication Date : August 2018 Author(s) : C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Fri Nov 5 08:05:55 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 35B1F3A0FC0 for ; Fri, 5 Nov 2021 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 XWHS2wdnnkSP for ; Fri, 5 Nov 2021 08:05:48 -0700 (PDT) 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 429783A0FB8 for ; Fri, 5 Nov 2021 08:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1636124746; bh=PDUMhOL1iNNpfy0IT11+id7UHDJvCaViPPa2TLAnkAY=; h=X-UI-Sender-Class:To:From:Subject:Date; b=NznYoflIp3haxoLnHozYEDJouokF/AQ+ODz8jQpgeU+VAk0PCtCOQ2lHw6v5CZXth eRZkKRyF7LSVD53ZKS9g/ck+1QHU8WDnT9pyCM7XZbq/T+7Bdm6UfDDwLdTx1ZQdOL csKY3YKyVrzyaCA3rtpmdEwBZ0h5x+bnGqCBhxoM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MaJ3n-1nCQHc41Ab-00WDUB for ; Fri, 05 Nov 2021 16:05:45 +0100 To: "core@ietf.org" From: Achim Kraus Message-ID: Date: Fri, 5 Nov 2021 16:05:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:o/1g5162Z5AiKrqtbJ3Yna7O/V0ERhoijv/vsF0JQ2F1KPR4PPD rhIDhs28yuRK4jqEcbdLCKYFvfyj9MwU3Tiyo82CUA3QEN0WQBJfMmjrbGgU2tmSKsFa4m7 JJqSvY8Mui32f1NWG/xgFNJp1lLf1eVydePFvqwSughhgKpYpe+75d4Fsi9m0ZPET84k345 8WvKY/+Jp94kyrC5mS+Vw== X-UI-Out-Filterresults: notjunk:1;V03:K0:BJkBFPPLTf8=:4/oAxOas2xicgRlb1DXAJV wpS4AV4drXpNFHUzVlABs24LyzQoYfrY8igDMCDsHrbZ4HizwiMKcVRr4hIQvBPVUY3GLWXWs 7UyKtU/hz8kjWYu2sPdutgfLAwtur/VkGjzuanXggwXfwN8C5rvpVv/lLnhDU/sskskSHZfXk Z++nsOpyoQHoyLTFxiTm0kAMLKNVVrHR420oPY5Xc7Tb5xR5RWVRmtVwDGFIHRRIFijdX0wBh hH+AxFIoSyhAGmTl4gLfbuaugl66/FTa4DOiSdtZku2VjoapBLJBoH2YtzAAPceXAB7UERaPP sbdj5svLXSkbXKOPoq4YLTjsntCJhhmado3HSjFwaCXhvUEotqX3ZaYGzM5divavrvs7VgVnx K4De1YSIDa2h1QwKyv7eszIesgJyIS961HT+g/6unoAt1SZTnXjmC+H//arHfKwOrTSeOEyOw CTq3bPCuY2AyJatbpFGlySq2iiG2t+oz3TC4UW2v/hQwX9kBcAOburdcFhIB/VUoSs7k1I+h6 NzYnukH0EprnjLMeriWcZklhGGGBcu4adT2KM/k09avRDkwHVTWtcqIIBkX8xUEqsKcSgk7dn 1n+z6rSAVMcioR88fxMgd7kbqYxZ616JNfc6EXzE0Y7UC3/dPCwxzCCVoH3zEx/2/NO7HnUCC 2ZUbrj5v0AdKZNqs2NgY3csXLuZSmrRFse4ioo1mgzOCWsFuH+wMFCvXRkkgNGf1YhaApewOd 4kkJb4ljaJQvxu938INQoxlrNu8GwKpI7PUdrphUmX7IcKZQ4Gs17FM+zFpJtMkvZlLnFdgkY XyvceqJJDqeyHGOMWtvoq040TIjUdWCRLQxSgNn8Rb0GWhZ94OAkVQfYhPtkYYlq/HLxT6cMY 9+fYMKXhWT9/7Tt1TLAKvNEvH+bnMEuM7Bpt/P458OFmYOhWQCsBU2aRqZwUI7IVkarXwij+g 1CnrvvCLH1Rghi9Dsgi52qrGpn2pqRNw+RWUcXI6SDNTr+/bOVRwT1w1LpJO1KQuLxoIqpi/d 6Xr3q6yPB7iTEuZGpCPLgjfO8OWXLH697PuBvd5mf4j0RgssOCa1ZzBOKd5Di9208IzzF2VRe K7zHzfv8BrTmCs= Archived-At: Subject: [core] IANA - Content-Formats 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 Nov 2021 15:05:53 -0000 Hi List, according an issue in Eclipse/Californium from Jim, 2019 https://github.com/eclipse/californium/issues/1078 "There is an effort going on to get a sweep of all of the known media-types registered" he also referred to https://datatracker.ietf.org/doc/draft-bormann-core-proactive-ct/ Though we currently want to update the media-types in Californium, the question raises, if the ongoing effort is in the meantime finished? Is https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#con= tent-formats the consolidated result? best regards Achim Kraus From nobody Fri Nov 5 08:42: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 1F8563A1097 for ; Fri, 5 Nov 2021 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcT30g4pXc3t for ; Fri, 5 Nov 2021 08:42:33 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140090.outbound.protection.outlook.com [40.107.14.90]) (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 D63653A10A1 for ; Fri, 5 Nov 2021 08:42:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VzdrYXCiwEPDguWoegVi3tP1Gc46cGg0yOdBBv/Qm1lhtAt/UbRKVzt8Kwd04Tmo74e865eWY2m1C1TG5FzLQ9u3tDQppc6tQh+C+JM9GPYjoMmSJ1T+e3/gWm0PpI5dmrsPlomYu1PJTY1VmF97Zr1KD3Bo87Z0abeHNgdYOD/hdJ+VektrO16dN0aLx3Ad9bHkHKl7H6lvHnq6WhcrRB1Rqa6OyL/3DbSQ8q51F1OVGtvh/cbNuE03O8wS2HV56a2Su+BNI/dDJwB9gvrxe3SJLclD1+Ds/r7i1S7pzQRL1uCVaWRL8e9T5zT/n1X6IwdHZwBg1z0wEVflrk/Tig== 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=Y4lqatyVoWgyq+l7Sj1YYCadCnS8bXcaiDVzRil+SCs=; b=aVNAO1h6oBP7WiKgdv4vVzpx95aShTstRsJrMNbmc3Lj+7JR/vzRrG4EZaVY1dZmk7pxc3qgoa4Z1iMH9q3+3GnCvsp+rSC+qD/KDMhXu3Se8SPC1qDNJ3mUvTcnxyZWnDnr7UxbSJbdnUlJrscoMJvLWdE4FUB2trBBIWLssQC7Oat+B+oUVnzTGwCU0kcSiipTn3B92DiMP+6YZ+4mot9JXlXuyoosKb9M6NSRb+JzF79dSRTekE53coFUjBUVnt3QVX9+TGGk6uJnXmVw3MnUIpVU+BHgjzCuIMYjQuT6Et+KU1/ELhuia03XtKKhTb0zP9ItV2a4NJQFIzkM/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y4lqatyVoWgyq+l7Sj1YYCadCnS8bXcaiDVzRil+SCs=; b=eHw0aGI0hyCgZKFPivZO/bkawppgH1GqlmcSE0cAzlXp6QPK2EHMzTNAwMUIZF4MvVId8nI1c1+hlDwk/AYCWSvckK/pNMs4bwZd/KIv76MnAj00FvmX8ckyLBOqMGmuBtpsi7rjFZNshWF1nSJCagY6W/IvzCB4vPW/kHVPPu4= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0705.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11; Fri, 5 Nov 2021 15:42:28 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8%8]) with mapi id 15.20.4669.013; Fri, 5 Nov 2021 15:42:28 +0000 From: Esko Dijk To: Achim Kraus , "core@ietf.org" Thread-Topic: [core] IANA - Content-Formats Thread-Index: AQHX0lapnloXFCaD+06xlz6q27D/rav1DqdQ Date: Fri, 5 Nov 2021 15:42:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dcc79d21-847b-4d25-66f9-08d9a072df9a x-ms-traffictypediagnostic: AM0P190MB0705: x-microsoft-antispam-prvs: 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: Gkjpcl/DBXMUL170bpf1HTU7wGWyPo8TdLAs+4VUUKsIngveIMDMbeJZfCqt3xBeTM+U/tnL89vCkbEE1Nt/H97eEvyMNk85RcVnnOVoO3vreq1HYaTLwCOvM29/hb6QNl0RlGLeasDBv0y5X1Rci+mTI6sDgXx1LQEmbsABe6CtugMbq2YkHBxL7mVEoVH8lSneRVvkfK40HVgyu0MqvVuF/ko0mYDougQrCTaUPmxajxwqO/k4H4ptl8Sqgb1BzrmkHq2TuN83vp+idLlQWjyKKc0fzaNdDGMuOiSqCM+FT0gKHsj88hugcmve1nLyC9ZaPfeWE8wWt6XcG2w+j9tvX1maQPZKc3GIgXpwwmRqaezRdMzQrN+3/EV7hiIsb9w4OurYnJ0kIPX+M5ECjT8VNHmXs+lneR8JhW8DiyVVdjzaw+3RMIFwBqtSfcELKYUoNOFSvlk9AszTZoybjH1cWhxNWYQyGla21qs9/3olyxLXdNTb/aB8aEt0HbJ1zESmlIsphMsbnspYa5MQgorJ3MMNg7sWvhSOVoaCHyMh1VfCXUyLWEdlxHhn4czxVUaAy9eZxulC9QXKHaMrS9QOFLfLvpVfoSoN3dXKERChL5NMK7P+w3U6lnCoqJDk/2t2DSCxxbA0ADTaa5pkUy6v5MS0UlAUKz2K1WODpgub6OeaDy873gzyDs4ln6PEQdaMMD0DL0imzDfrMRs1cb46ZFl2yMGCRiulrFod0utC7r9HoTHktg89hKfJhI2S8gXLEWGue2rDZgeqDQDAuRDZmagV0J879Qyh1tF+5W4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(136003)(346002)(396003)(366004)(39830400003)(83380400001)(122000001)(66476007)(186003)(316002)(44832011)(7696005)(55016002)(71200400001)(66556008)(38100700002)(52536014)(8676002)(966005)(9686003)(66946007)(33656002)(508600001)(86362001)(64756008)(53546011)(76116006)(8936002)(2906002)(6506007)(66446008)(38070700005)(110136005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Rmlla3pVeGlWTzZ5aGRFUHg2R1lIYjNTVWw0S3REZXpHd2todVp3c1FpUG9t?= =?utf-8?B?WXIycUNnS0dJeW1DZ09UVnJ1clpBd0VHTHM1a3d6NVVPWDlMcXNpOS9lWm10?= =?utf-8?B?aXlYM0kxamlONGZmclhqNjJFSzdXeEVnT2l4a0ExRmtWRFE0MS9tN1BwQW9B?= =?utf-8?B?cXN3bUd0eW5ibzJBcGpWRU5jREdDdjhYamRYdzJHaDJjUzBQRzdjU0FkZWls?= =?utf-8?B?M3V5Z1ludFpnZkRLSzg4c2J6eExxamtONG45ZUlTSERBWlY3WFlaSm1QN1Q0?= =?utf-8?B?TTB4MWJ0V0ZwU1RzSHJBbWR0bUZaZmVGVElvR25ybVV2d0c2YkswTUg5b3hv?= =?utf-8?B?STg1N3dzSWZ2WG9lMFBKdHNlWnFkUWVicU5Uekp4MnZUMU1VMWNpTEJWRkxQ?= =?utf-8?B?VHQvNlJRa1VBcFZGVVF3ZGZNZno4dVB0eitjUFIvdG9YdHRCTHNzak8wdi9m?= =?utf-8?B?Z0dWY0xBaERSSHRDaVJ4dEdIa2RqdktJY0lkcmx2ZW9ycFZtOG5BNk9DdHY0?= =?utf-8?B?Snh6S3I1bjhrWVpFWHFwUDVzR1dNUTlHVFc0enpxSXdPV2dyQjFsOEV0ZjB5?= =?utf-8?B?UEdCVVBybWJRaFY1VW5lL0NuVzZjbmRNVlBMaTFzelptMGhpbXlDSFFubEw2?= =?utf-8?B?QXd2QlpXZU5Qem85SDlPSW9yRWZmd1R5YTNhSzE4NmtjTU9UNElncTA2M3g0?= =?utf-8?B?ZDhIckJxeUtwRHRkZkR3SjdJODlJd3hPZVpoOHBCQUlvK3dOWFRXQ2ZUckpn?= =?utf-8?B?cEo3WGY2VW1Uc0t6V3Z6Wkt4aVdWYnczczJuV1U2cExJWUdKN3Y2QlNYV1Bt?= =?utf-8?B?K1A1SVNCYXRZaGFTcFJOK01DSDZZb0dKT2tEbnRtdVl2ZXMwa2xuemd0cEIw?= =?utf-8?B?UjhycXc2TythcUp2ZVdUbVNlVHI0SUtHQlNSdnJWQjgyUEdOTUdhZ3FHQkxG?= =?utf-8?B?NmJoa2l1M0IzdzV3bWVXZGE3RmxEWUhuTTlIeVFEQWFqYUR2Qjdjb3hQbW5X?= =?utf-8?B?c1JCMTJPaFRpaGpOYkhzMmdob1FqcWhpNEltNWxTdWVtdUVXSjhodWp5c1R5?= =?utf-8?B?VWgybXM4VXlMQjFKMlN3ZTdHK2FPWm5PY25DZVNXclIyNHU0cnFLbW9QeFJz?= =?utf-8?B?SzRPUEM2L1ppT21uZ0pMZlNvUmFWblE3dXdtNitXS01ST01Uclo2c0EyUndq?= =?utf-8?B?b3B2blRXWjBDV2RtZ1p3NEJpdDhRMSt3citwNjRNMDV3NGx3U2FBUldzV2s1?= =?utf-8?B?MWVhSS9kdURJaC9XKzlldFcwbW5ySjkrYWc3OStTbjAwMm16WkZpRlBoSjlD?= =?utf-8?B?OEYvbWd0a0RoQ3pISEhIbWtBTGVpMGZYL3U5RU5qMTVLZ0g1dk9tTU1NYlNB?= =?utf-8?B?L0dMeHVLOTFZRGd3eGZWbkg2Qk02MjN2YlNiNDFwSkovT1c3SnRydGduNGdr?= =?utf-8?B?MTROc1htUWlKb2ZmK3VmKy91TXEwZzVTcWlsSzBobnh1dWtqbTJSMHEvRDFP?= =?utf-8?B?OTZ6REFaYThpTjNDZXROWHhlRHpoRkxUc0Z0SmIxUkJMNWxueGc1N21laVIx?= =?utf-8?B?NGs2Mkd4Nm1MWmR3QTZuQS8rSkxLWDF1ZnJIYUZNazFibTd1U0xCblVmR3dY?= =?utf-8?B?bDY4SUtRS3V6TXZsaFlwUkcrM2hQSTEvNnhsa3NNZm9ZVDIyZS94b1ZYRzd3?= =?utf-8?B?VkUzcWdML2EwaEY1bVZwcndwQ0V3UlYxOUl2cGUvTHg2U2hWR1dmT0M3cnFu?= =?utf-8?B?YnNHdUFVbHNpRUZyZ1FWamdrTkhZQ200OUVRdEVQQksyUFNPc2ZMYS9Camh1?= =?utf-8?B?enB0WDNOWTVWejMwVG05MTdjd3JmaWM5aEhyaW5rQzJNTFprN3h6djVwQ2Iw?= =?utf-8?B?SnAxYzlybm9DbUZ6TDBmOFY1RTV5MXV6WUxFeWJ3cjNHU2hBTWlUUWorL2wx?= =?utf-8?B?aXk5cVkxcUJydUU2TUVjWU5vSk5hbW5wdzRKZytXc3d5cDByYjF5L3kvdXBG?= =?utf-8?B?b1ZUcnVObzhJVFhvTVpkL3VtOXUrSUtHa0VJOHptbVozdVdYemlDV0xIczln?= =?utf-8?B?eHVYNFdaUm5XSUlLaXJMWXB5MXZ0SVRQcGhKamhtZzR6UmRlMWI5TWdla2hR?= =?utf-8?B?VloybEdsSnM2cFRuUTRtWXJUUzVqRmJCKytjS3ZMNlVMUEVmMTk4ODVCdDB2?= =?utf-8?B?YkpKMnNtZGxRK2NZK3dCdElXY0pYQklpdFdnMnYzdlgrSmo0SVZrWWZpRFdQ?= =?utf-8?B?Vk9sMHU4STBOcTZHbTl5eFpSS1N6U0puMjJ1SXQ0K1J1amFiQ0FjNjBjNjhq?= =?utf-8?B?U2szaVQrV1ROcHJORnNsS013Yk83VWlZVDZpMTllazYxRnE3a2l1Zz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: dcc79d21-847b-4d25-66f9-08d9a072df9a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2021 15:42:28.7421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iNPpZn+y9+ORP9gmClb8sN++k+c8+9Y/0Ep0SK5fRu/cumMdwvzao/URFmbCZSXX9fcQiTCPHHMOK4v5UYULeeOw8QtKV5r3TcYxZO6Z+VA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0705 Archived-At: Subject: Re: [core] IANA - Content-Formats 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 Nov 2021 15:42:38 -0000 SGkgQWNoaW0sDQoNCkkgZGlkIGEgcXVpY2sgY2hlY2sgb2YgdGhlIHR5cGVzIG1lbnRpb25lZCBp biBpc3N1ZSAxMDc4LiBOb3QgYWxsIG9mIHRoZXNlIGFyZSBjdXJyZW50bHkgcmVnaXN0ZXJlZCwg YWx0aG91Z2ggZm9yIG1vc3Qgb2YgdGhlc2UgdGhlIG51bWJlciBoYXMgYmVlbiBzZXQgdG8gIlVu YXNzaWduZWQiIGluIHRoZSBDb250ZW50LUZvcm1hdHMgSUFOQSByZWdpc3RyeS4gDQpTbyBpdCBs b29rcyBsaWtlIHRoZSBzd2VlcCBlZmZvcnQgd2FzIG5vdCBjb21wbGV0ZWQhDQoNCkluIGFueSBj YXNlIGZvciBhIENvQVAgbGlicmFyeSBpdCBtYWtlcyBzZW5zZSB0bw0KKiBhZGQgc3VwcG9ydCBm b3IgdGhlIGNvbnRlbnQgZm9ybWF0cyAob3IgYSBnb29kIHNlbGVjdGlvbiBvZiB0aGVzZT8gKSBs aXN0ZWQgaW4gdGhlIElBTkEgQ29yZSBQYXJhbWV0ZXJzIENvbnRlbnQtRm9ybWF0cyByZWdpc3Ry eS4gVGhpcyBpcyB0aGUgZGVmaW5pdGl2ZSByZWZlcmVuY2UuDQoqIHJlbW92ZSBzdXBwb3J0IGZv ciB0aGUgdHlwZXMgdGhhdCBhcmUgbm90IHJlZ2lzdGVyZWQgaW4gdGhlcmUuIChXaHkgd291bGQg d2Ugc3F1YXQgb24gdW5hc3NpZ25lZCBDb250ZW50LUZvcm1hdHM/IFBlb3BsZSBtYXkgZ2V0IGEg ZmFsc2UgaW1wcmVzc2lvbiB0aGF0IHRoZXNlIGFyZSB0aGUgb2ZmaWNpYWwgY29udGVudC1mb3Jt YXQgbnVtYmVycy4pDQogIC0gZm9yIHNvbWUgdHlwZXMgdGhlIHJlZ2lzdHJhdGlvbiBtYXkgYmUg cGVuZGluZyBlLmcuIGR1ZSB0byBhbiBJLUQuIFRoZXNlIHR5cGVzIGNhbiBvZiBjb3Vyc2Ugc3Rh eSBpbiB0aGUgbGlicmFyeSBjb2RlLiAgSG93ZXZlciBpdCBtYXkgYmUgaGFyZCB0byBpZGVudGlm eSBhbGwgc3VjaCBJLURzIDspDQoqIHRoZSBpc3N1ZSAxMDc4IGhhcyB0aGUgbGluZTogIkFwcGxp Y2F0aW9uL3gtb2JpeC1iaW5hcnkgPSA1MSIgLT4gdGhpcyBjb25mbGljdHMgd2l0aCB0aGUgY3Vy cmVudCBhc3NpZ25tZW50IGluIHRoZSByZWdpc3RyeTogYXBwbGljYXRpb24vanNvbi1wYXRjaCtq c29uICg1MSkuICBTbyBpdCBjYW4gYmV0dGVyIGJlIHVwZGF0ZWQgdG8gdGhlIHJlZ2lzdGVyZWQg dHlwZS4NCg0KU28gYmVzdCB0byB1cGRhdGUgaXQgbm93OyBhbmQgY3JlYXRlIGEgbmV3IGlzc3Vl IHRvIGNoZWNrIGFnYWluIGluIHNvbWUgZnV0dXJlIHRpbWUgd2hldGhlciBuZXcgdHlwZXMgd2Vy ZSBhZGRlZCBpbiB0aGUgbWVhbnRpbWUuDQoNCkJlc3QgcmVnYXJkcw0KRXNrbw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgQWNoaW0gS3JhdXMNClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgNSwgMjAyMSAx NjowNg0KVG86IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFtjb3JlXSBJQU5BIC0gQ29udGVudC1G b3JtYXRzDQoNCkhpIExpc3QsDQoNCmFjY29yZGluZyBhbiBpc3N1ZSBpbiBFY2xpcHNlL0NhbGlm b3JuaXVtIGZyb20gSmltLCAyMDE5DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9lY2xpcHNlL2NhbGlm b3JuaXVtL2lzc3Vlcy8xMDc4DQoNCiJUaGVyZSBpcyBhbiBlZmZvcnQgZ29pbmcgb24gdG8gZ2V0 IGEgc3dlZXAgb2YgYWxsIG9mIHRoZSBrbm93bg0KbWVkaWEtdHlwZXMgcmVnaXN0ZXJlZCINCg0K aGUgYWxzbyByZWZlcnJlZCB0bw0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1ib3JtYW5uLWNvcmUtcHJvYWN0aXZlLWN0Lw0KDQpUaG91Z2ggd2UgY3VycmVudGx5IHdh bnQgdG8gdXBkYXRlIHRoZSBtZWRpYS10eXBlcyBpbiBDYWxpZm9ybml1bSwNCnRoZSBxdWVzdGlv biByYWlzZXMsIGlmIHRoZSBvbmdvaW5nIGVmZm9ydCBpcyBpbiB0aGUgbWVhbnRpbWUgZmluaXNo ZWQ/DQoNCklzDQoNCmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2NvcmUtcGFyYW1l dGVycy9jb3JlLXBhcmFtZXRlcnMueGh0bWwjY29udGVudC1mb3JtYXRzDQoNCnRoZSBjb25zb2xp ZGF0ZWQgcmVzdWx0Pw0KDQpiZXN0IHJlZ2FyZHMNCkFjaGltIEtyYXVzDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0K Y29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQo= From nobody Sat Nov 6 00:54: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 240B53A14B4 for ; Sat, 6 Nov 2021 00:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 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=-3.33, 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 N26NjyYiifie for ; Sat, 6 Nov 2021 00:54:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 9DF853A14B3 for ; Sat, 6 Nov 2021 00:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1636185279; bh=FNFl7zM4aKFcCMNDn64N/lFdUW79w1T6epJQGD0/52c=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=KCexSSrJlDj8YE/CoUp3kyxPFjBdEINx8p/r1DEYje7n3zZJNWn/JIQjTq6roP6/1 S/DjLA4+8VaPhoEcE/f1kweoDhyLBMbOf0cJbZsyhie+dv3kGY9ja9sxsexY52fzGv pxRNEEqbcLYVxQuj47ae/5I2C3V4TADOMqwHBjfw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MlNpH-1mKLlS1k8D-00lpcP; Sat, 06 Nov 2021 08:54:39 +0100 To: Esko Dijk References: Cc: "core@ietf.org" From: Achim Kraus Message-ID: <35a5ffff-b51c-d107-65e0-377bfd868591@gmx.net> Date: Sat, 6 Nov 2021 08:54:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:LzxdFC53SdioDoaTCgk3gm0Pm1KB9uxd6JiVjZuuczq3RsPgLmL IPP9XF5ihnGTmBeacVd2XrWdDCZ6DjQ5uy1IePZ86qsLklAfrkTk35+gnYUh5chD2wA+S42 4UIwoAjhK4WjcesqVYJJHOr8os2B1BBzuvGKTYnowh21GnDSHPSZtI9NtjpXA2SSQDixdfR /0/Iz4urJ0SJgTn1CoiGw== X-UI-Out-Filterresults: notjunk:1;V03:K0:M52mHKo2o9U=:BElxSpHHngg37lrNCGaEJD fwLNAby0zxP5bNPQpaGov2atdmmgkQP9DXYLSLnFDrNFTT/jOkTtnUhsP1/S/cbYfvvEmQMPx 4y/s6Mxjn4P0KSZn40DxRawRnui0pf/xex5EbN/urJmenoomOkzYqGJMLYmW6yBtrDeBQ7gOE UpbR3bI745PExtln/DuQss6aCD8BFS/GCsILcCmMVYm+5wAPKVKTOtRLZszjGw/ASNsqqhi6u np63V73LYqBKNRnHSKFwT/+meiVq9BORYp9yDYkq92W6gc6777dFMKwqG7TMeEXUVbZ8sMBhQ 0dddOXjnZnx1SBDDESBHqgcqp7PcaUQXOLp8LdSaPnwxivSxYCxMOefqKHP0xGkAsLGc/Wk40 92a+dx2WgX6A8MQQEoIB98/3roB0rF0KeR1gx+MYf71WtOUbdKhsj+vWaDK0+I7CQOet3Jvm5 mC+VZfL5LYtxWSqwLGHS9qIDOXRTJM0UZt4e3cvB+N1ePQ/TYMeh+Ouip3b4kwiM1tb57oeFi 4kilgT75WBiNRcUaQ3Y7E4KjfIXma+kx8sGq30wxmcFoM5D5GROLpsSE8tublv7V5moJ1Ky8D SbjKSNqj7tpCWzMc21U1lI7jchaipCKM68gusX8EEpjltjrZLTrF/htT6FjRq29Ztd4AnqH3R foTfvdwdjMzFzxU8aNNnFDcGRFHvnYnQfUvfUaFJx5u5K1F3JJKU8/nCLfxmEChMGXjTQ5er8 XxGcu/tCtHgh68K+RYH+vQXibZm5+SvQlsE1pN1fPD3De04dLFQUQRCs4amUwrFcrciv7mKNi nyDnAHVLf878hyYzdvndTsHBpikZojH9r7Ytpzv+tSEdWWIk/Mn5u3Nje/7jv4gGy3WlVPxPz RhtOHHVIz/4anUOK2nGNHJFHHPHXBWc4QTJMvNy6oSynSOB+ZthW18Fxhvt6szNYkNQzBedev qiiESrOsq41wWj8Nv1in23NzR5BYg7hh5+T4HOkJJP6LiK8vsYa4vzJRBua5Xs/eb2X67IJI6 JAAdh8uPEY+RKglGehZGAD8LF52ym64WprQRpnhJwUbCjnYFR626/JwmJy1J8lSR5QHBRlFdY hXLSqmpHYX75UA= Archived-At: Subject: Re: [core] IANA - Content-Formats 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 Nov 2021 07:54:47 -0000 Hi Esk, that issue https://github.com/eclipse/californium/issues/1078 has been considered 2019. currently it's PR https://github.com/eclipse/californium/pull/1814 I'm asking for. That PR follows https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#con= tent-formats so according your answer, > add support for the content formats (or a good selection of these? ) listed in the IANA Core Parameters Content-Formats registry. This is the definitive reference. I think, the PR is well. I just don't want to add media-types again, and then remove them again, and so on. best regards Achim Am 05.11.21 um 16:42 schrieb Esko Dijk: > Hi Achim, > > I did a quick check of the types mentioned in issue 1078. Not all of the= se are currently registered, although for most of these the number has bee= n set to "Unassigned" in the Content-Formats IANA registry. > So it looks like the sweep effort was not completed! > > In any case for a CoAP library it makes sense to > * add support for the content formats (or a good selection of these? ) l= isted in the IANA Core Parameters Content-Formats registry. This is the de= finitive reference. > * remove support for the types that are not registered in there. (Why wo= uld we squat on unassigned Content-Formats? People may get a false impress= ion that these are the official content-format numbers.) > - for some types the registration may be pending e.g. due to an I-D. = These types can of course stay in the library code. However it may be har= d to identify all such I-Ds ;) > * the issue 1078 has the line: "Application/x-obix-binary =3D 51" -> thi= s conflicts with the current assignment in the registry: application/json-= patch+json (51). So it can better be updated to the registered type. > > So best to update it now; and create a new issue to check again in some = future time whether new types were added in the meantime. > > Best regards > Esko > > -----Original Message----- > From: core On Behalf Of Achim Kraus > Sent: Friday, November 5, 2021 16:06 > To: core@ietf.org > Subject: [core] IANA - Content-Formats > > Hi List, > > according an issue in Eclipse/Californium from Jim, 2019 > > https://github.com/eclipse/californium/issues/1078 > > "There is an effort going on to get a sweep of all of the known > media-types registered" > > he also referred to > > https://datatracker.ietf.org/doc/draft-bormann-core-proactive-ct/ > > Though we currently want to update the media-types in Californium, > the question raises, if the ongoing effort is in the meantime finished? > > Is > > https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#c= ontent-formats > > the consolidated result? > > best regards > Achim Kraus > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Sat Nov 6 04:52: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 34A353A0773 for ; Sat, 6 Nov 2021 04:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyhbI_iwv4AZ for ; Sat, 6 Nov 2021 04:52:32 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130109.outbound.protection.outlook.com [40.107.13.109]) (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 B5FBD3A0764 for ; Sat, 6 Nov 2021 04:52:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fL7W1AJa3IvhTfttNH8PkhwMJAQ0smg8s8wxsd1ADL9cUlkeOSY+SQ0W/IUqyPjBKHY4DNDkGCDADwSqbwLndGa7/Zxp6j4cP9oBS+Smd42CKeBiQBdnL/iKyD8zSVEuhzIpsDIJUe2ZzvCkBsePpfzT4ElYFGuzqndERjXd2dQejDIUi8YgJGRh9aRZ0PTAd1IIP1xayOB4OV2iUXYomuowKb2YDfHs4VG4xJVGRuiBQKQbCil6S8i9ZfjOLak+BcRwa29toFgrpFgLDM8TaCvFlkDa2NnLWunGJJcGz6Egox1Lf83E3vMSjj8D5VPpqK+OEmDiMTcoIREJkGr7gQ== 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=xwJiIye1EjAeOyvwL/oEZjteCH4xGtEYYnmWJSgOtYE=; b=GjyrGHoLHNaoGWIgjDadL2O1iJbTD8ugwTvo14gxsvYbSkMUYe1mmNOHHxnmiAODcqAu7ebn2sX0bCkAa/h35y3mj7ux12yodZDbdI3LQCpBl5QWUxfU8/oE1DIb1CJn+7dhdi3mTkdmZVNBWcHSO8SgFGLyiy3kb+8XUlcJIuXAwtDYV1GUVossrNy1KIVkZg9I0efOGtsPpBUhgiHyvbYHx+CrWsSsCijtdPCKiDa/eGRdskstq6gDmm4M2srAFUBWcxRdfqlycyMo29Ovyqc2VVHuz5+YQ175zPn+dfuhEZXppFp97LgjRQZQ+P/C6hZULVVSl7o9+p4HNkY+7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xwJiIye1EjAeOyvwL/oEZjteCH4xGtEYYnmWJSgOtYE=; b=AmDfxCgRy9Wh5QLNoa1H3fdTqmTDTAOiFH3PVrTxbRXYK36nFBLB3rvzNzRr8A9YsStOZ5QLKOSBfWIkkG3moWhZTKq3LKY3x8t+l5DfF09DoA5vgniHlWdtfg6chAdTDtCf5gTyHbmLrvH6gYWr4iB0S2jGuC8gMekSHTbc8hc= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1363.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:261::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10; Sat, 6 Nov 2021 11:52:27 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8%8]) with mapi id 15.20.4669.013; Sat, 6 Nov 2021 11:52:27 +0000 From: Esko Dijk To: Achim Kraus CC: "core@ietf.org" Thread-Topic: [core] IANA - Content-Formats Thread-Index: AQHX0lapnloXFCaD+06xlz6q27D/rav1DqdQgAETwoCAAD2kwA== Date: Sat, 6 Nov 2021 11:52:27 +0000 Message-ID: References: <35a5ffff-b51c-d107-65e0-377bfd868591@gmx.net> In-Reply-To: <35a5ffff-b51c-d107-65e0-377bfd868591@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c84806e-19c7-4007-3e1b-08d9a11be7c9 x-ms-traffictypediagnostic: AM9P190MB1363: x-microsoft-antispam-prvs: 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: 2yoqlkzjVwwoef1swuTLUo/Ra5wHqyK1SzdGLBVxfjhzVcqISgyDl24JWrRd545wFyBYBm1iBPA7jfyiEITwcBynIyjYh/kd2QEjtn8H6YigZzxn1QKZvKfl2irGMVNcwI+kx50kH/Fo2t4pnY/3O7w8LTMeAIVyhU7A1M2l8Gz9Jr2O+wpgyr+oDVAaSKYIYBBPXCpBiE3iLBjVpTKyffM4/ujTF2slTii3pxMaE8PvkBxchYUryNztFzJPwdG10+6H18SUIaIEgwiEAJ1IMiBOj3WTWWwct1TtP1H8/1euLHwYTd5ZpEd7XlvxhhHgD5OgEQdLgWG3ERPw7ksapdHMxERbrOGGl/nFKaOiZEPfE2OkF8M8NuTE6NbScsOb0XzlYAlgPb1GMOXJaMwWwRAr2vzticatCIdKZIuAUV4awkTUTq2LXBgBGYKr9QJAx1Yoq/YpBbrzh+r2GRT7hvRHoF1SBsQKQBjqXAuATONzYu4CB5GFYh0IVulxICbSOSWHJeADeyEBXhp9UfvUBzJPNUpnpF1wK49HeFaPNnyC0LIBJoV+Js0pa4xcJseaDvLy8UfLxB/56g/ghpIuWTUA4XijsllrQH+/IkLbVP93fAzzoWmmzFqJCuaEFbT9AsJ1e2nFI1fbK/3/tnvDuHscytFJxY/MgtlFw6hgshC6McCswJRKJKUS0UQDIBH7YhJTLKwhtIpCn3LOvKUn/k2W1/gmgL/w/xl9AmAm7ggv0l2LOtxhlyPQ434WBpfxdBywnKCqKXWQ+wnw/9lfSCIy2P1BlMOB1UJin19fne0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(136003)(346002)(39830400003)(122000001)(44832011)(5660300002)(966005)(83380400001)(186003)(66556008)(64756008)(6916009)(8676002)(6506007)(71200400001)(52536014)(8936002)(508600001)(9686003)(38070700005)(76116006)(316002)(86362001)(53546011)(2906002)(66946007)(7696005)(38100700002)(66476007)(33656002)(66446008)(4326008)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?R0RvT2NEWmhHdFVPUnozOFJvVjVxZkcvYXRxOU5jRDg3T3ljcEw0aFFTaWo4?= =?utf-8?B?SmFaZktvbk5tTnIzSFp0ZitqR3NkWlovblpvQ3JQQ2MxYzdVZkFKSysyQ3l2?= =?utf-8?B?aEJhc1Y3U2xpTVBVQVNKeWNDSmgxbGhocXpPenBOWklIY3RtU2RPSzlkSms1?= =?utf-8?B?Q1hlTWcwTjhqV0pLV2ZnUU5nR2dKZjliVjdBc1I0azFPcFlxQnl5ZXRRTWFW?= =?utf-8?B?OUFlTmlMTWh1NlAyN1cxZHdVUTgrYVh2NHI1T2MvajB1TExRME1oN1JHaHBh?= =?utf-8?B?Mzlub3NhQjBvVnpFY1ptQUExNWdMODgrVzhuOFVxYWRxUU82NFZIeWZPMVhB?= =?utf-8?B?ZXIxemlTc3RjYjlaZnp2K0NST2l0MFNCcTRTQnZic3hneEtlK0VDVWJ3MGlI?= =?utf-8?B?c29BcDM3N0o0YVZUWU5YV3ZTaU4rNy9BRyt6YllrY0VmN1VoOG0vSEpsTjl6?= =?utf-8?B?dloyaTFvbURubFVBL3pjNWhiZUtZbzNmTkY4QjhNM1Y3NXZwZ1dQSXBWNVA0?= =?utf-8?B?S2g4Qi9hNUFVY2ZQbDlFMFhDcnNldnVMdklNejU3bEF5WTBXd0k2cnBiaE9T?= =?utf-8?B?S1FLRFN1akszUzdVV2ZXZFhuM0JnOVJQQXg4SWFsVWlmSVk2NlQ1OHlXTGRm?= =?utf-8?B?MVZaNjdNc1RRWENJcTVLcXc0dXBRcmkveFNYSzROOXUvcUo5cGxJb1RNb1JF?= =?utf-8?B?ajVEMzc1WEpqbzJkdlVYQ1dLcnByQWtudGJ0RzBqMi91bUQ5V09FMjBsUWhO?= =?utf-8?B?SmdxWk9ZWTRpRTlFeVdoZUx1L3BpS0RVWURoNWRSV1dIdmxnUm9JVDJRY1E0?= =?utf-8?B?T0JZWTFScUNiTjNiMWlNMjFrVWpxVkMxYlM0ak5zUDRuaVlBeSsxc1JJbmlJ?= =?utf-8?B?bElBUkp4UnBOcSs1TTJGU0ZzclFkMTZvQ1hsbjI3VTJzdHJTVjNncnozdUpq?= =?utf-8?B?UTY3bTJnZ2NrVGswRWNJaGFYNENNVlVBcnhsYlZldFZuSHVLSFpaUEljeHY5?= =?utf-8?B?eXhCc0YyOHFOQU9DK1VJYmVXUHoxYUF6VG9kOTdlc1p0MWhmTnIzVS9ka2oy?= =?utf-8?B?aE1aWlBBb3E2NEJ1Qm9QanJhMmIxd055dVJUam1uaUtXTERXSkNuN1FzQjIr?= =?utf-8?B?NkxrRkcrMmdmQVArWVpvbXJmd1lvMDY3N2hGSXRnaXZUazBvWk92YW16L1hw?= =?utf-8?B?YXFGL1BNVlZKRTBkNDR4NGY1Tk1MYU83eDhROVIxd1UyR2FENll6WU5lcytP?= =?utf-8?B?YWdTLzU5cUUrcHkrdm5iVVdmT3NRZ2tXQnF1Rlh1YXVVMDY4OHdmWTlHRkRZ?= =?utf-8?B?STE5WVZNWE1KNU9MRkV4Mzc0RnNCbGx1ZlFWOVB5R2QxY3E4clhMMGdLRUp4?= =?utf-8?B?NVZ2S2FOVFpvemRQeTFwdkd2b1hMd012aTZmRWZsS0ZjcXlxRFR4OG03aTV6?= =?utf-8?B?d1YvbXVtbTdLQXBPL3VyUGRKYm1XKzMrT1JvUUZsZFlnRnhjUG54a2JjZytC?= =?utf-8?B?b3BZeWVmclpaVUZBTXg5UFUyZUxXQjlVK01CNWppWjdwdHpjS2VTZHpoSXhF?= =?utf-8?B?cjBLUm1KMW1iWFZKS04rOEFIZUlGNGZzM2VFd2k1VS9RaWltUEhJS2ZyL0hq?= =?utf-8?B?dmtvQ2hXZjc1S2ZmUlFxSzNraTR0dUVTOHduMjFMTWdiYUhZRnFXS3RrVGhO?= =?utf-8?B?Z2JYMUhpaGpMWTZhS3R4N01zVWR2TXEycEZEMEpEeGpXbFlzb0V1OHZhNkdz?= =?utf-8?B?QWR4OEpxb3ZpK2phbit5MnJhdVhnSE5DZVp0QUNJRXlzOE1PalVJREI5Lysr?= =?utf-8?B?aWtWdytLSWF2bThCNWl4NVhTSGsvdUM5VE13QmxvRWFmSEtKcG9jTlNpU0VN?= =?utf-8?B?RXpDKzVZVTgrVXJMN1hOeW5aekp6bnRGcWtRbmVLUllCaEZCcXNjc0RnRXZR?= =?utf-8?B?VkdWSlpJZ1dqemdidVRURFZvNkN1bGR2SEV6RVlQbXVXb1A0c016cnJodUhs?= =?utf-8?B?alVaNUxNYTNGMVRYM0swVXVQaGRzZFAwdmhDeEpWRjdoSHE1UW1qeENkZ25L?= =?utf-8?B?dnpUVFNMWGVpLzNuOEJzeEd3cXM0OGFXb0hMTWc4SkIrZTBFczlTTjJoaG93?= =?utf-8?B?aEt5dnEyZDJoZXV1WStFdU9ZYmxEUmdJYUM0SjI0VWgwS3VZMSsvaDRXVktp?= =?utf-8?B?TjhUY093OWlraGkxS0lHdUVZdWJTMURJZnlYUC91M0ZYNk5RMHJiSXRlWG1T?= =?utf-8?B?OTUwVlN2MHUrR3lxcTRFNmpzclFiTnhBaUsvRW9JdzFpZE1SYTdFbG9uYTYv?= =?utf-8?B?cXRhNjVPYVVGbEg1dVhQb2VRbGxSN1FGTE5GYTI1K0xzNmlna3dvZz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 8c84806e-19c7-4007-3e1b-08d9a11be7c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2021 11:52:27.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KiNh5kD9YMMu/PURBLm7lg9yBacaRb54Ea8s07oR9aYHuRWrodPvo4XxYuUETeVIw7dkbOFkSYz37fy73xTcgOiFKEWDAQndxnTRdHxFCHA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1363 Archived-At: Subject: Re: [core] IANA - Content-Formats 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 Nov 2021 11:52:37 -0000 WWVzLCBzb3JyeSwgSSBub3RpY2VkIHRoZSBpc3N1ZSAxMDc4IHdhcyBhbHJlYWR5IGNsb3NlZC4g IEkgbG9va2VkIGF0IGl0IGZpcnN0IGJlY2F1c2UgeW91IG1lbnRpb25lZCBpdCBhbmQgdGhlbiBm b3Jnb3QgdG8gbG9vayBhdCB0aGUgUFIgY29kZSENCg0KU28gYWdyZWUgdG8gdGhpcyBQUjsgaXQg d291bGQgYmUgZ29vZCB0byBhZGQgdGhlIGNvbnRlbnQtZm9ybWF0cyBmcm9tIHRoZSBJQU5BIHJl Z2lzdHJ5OyBzaW5jZSB0aGVzZSBhcmUgbm93IElBTkEtYWxsb2NhdGVkIGFuZCB1bmxpa2VseSB0 byBjaGFuZ2UuDQoNCkJlc3QgcmVnYXJkcw0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogQWNoaW0gS3JhdXMgPGFjaGlta3JhdXNAZ214Lm5ldD4gDQpTZW50OiBTYXR1 cmRheSwgTm92ZW1iZXIgNiwgMjAyMSAwODo1NQ0KVG86IEVza28gRGlqayA8ZXNrby5kaWprQGlv dGNvbnN1bHRhbmN5Lm5sPg0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0g SUFOQSAtIENvbnRlbnQtRm9ybWF0cw0KDQpIaSBFc2ssDQoNCnRoYXQgaXNzdWUgaHR0cHM6Ly9n aXRodWIuY29tL2VjbGlwc2UvY2FsaWZvcm5pdW0vaXNzdWVzLzEwNzggaGFzIGJlZW4NCmNvbnNp ZGVyZWQgMjAxOS4NCg0KY3VycmVudGx5IGl0J3MgUFINCg0KaHR0cHM6Ly9naXRodWIuY29tL2Vj bGlwc2UvY2FsaWZvcm5pdW0vcHVsbC8xODE0DQoNCkknbSBhc2tpbmcgZm9yLg0KVGhhdCBQUiBm b2xsb3dzDQpodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBhcmFtZXRlcnMv Y29yZS1wYXJhbWV0ZXJzLnhodG1sI2NvbnRlbnQtZm9ybWF0cw0KDQoNCnNvIGFjY29yZGluZyB5 b3VyIGFuc3dlciwNCg0KID4gYWRkIHN1cHBvcnQgZm9yIHRoZSBjb250ZW50IGZvcm1hdHMgKG9y IGEgZ29vZCBzZWxlY3Rpb24gb2YgdGhlc2U/ICkNCmxpc3RlZCBpbiB0aGUgSUFOQSBDb3JlIFBh cmFtZXRlcnMgQ29udGVudC1Gb3JtYXRzIHJlZ2lzdHJ5LiBUaGlzIGlzIHRoZQ0KZGVmaW5pdGl2 ZSByZWZlcmVuY2UuDQoNCkkgdGhpbmssIHRoZSBQUiBpcyB3ZWxsLiBJIGp1c3QgZG9uJ3Qgd2Fu dCB0byBhZGQgbWVkaWEtdHlwZXMgYWdhaW4sIGFuZA0KdGhlbiByZW1vdmUgdGhlbSBhZ2Fpbiwg YW5kIHNvIG9uLg0KDQpiZXN0IHJlZ2FyZHMNCkFjaGltDQoNCg0KQW0gMDUuMTEuMjEgdW0gMTY6 NDIgc2NocmllYiBFc2tvIERpams6DQo+IEhpIEFjaGltLA0KPg0KPiBJIGRpZCBhIHF1aWNrIGNo ZWNrIG9mIHRoZSB0eXBlcyBtZW50aW9uZWQgaW4gaXNzdWUgMTA3OC4gTm90IGFsbCBvZiB0aGVz ZSBhcmUgY3VycmVudGx5IHJlZ2lzdGVyZWQsIGFsdGhvdWdoIGZvciBtb3N0IG9mIHRoZXNlIHRo ZSBudW1iZXIgaGFzIGJlZW4gc2V0IHRvICJVbmFzc2lnbmVkIiBpbiB0aGUgQ29udGVudC1Gb3Jt YXRzIElBTkEgcmVnaXN0cnkuDQo+IFNvIGl0IGxvb2tzIGxpa2UgdGhlIHN3ZWVwIGVmZm9ydCB3 YXMgbm90IGNvbXBsZXRlZCENCj4NCj4gSW4gYW55IGNhc2UgZm9yIGEgQ29BUCBsaWJyYXJ5IGl0 IG1ha2VzIHNlbnNlIHRvDQo+ICogYWRkIHN1cHBvcnQgZm9yIHRoZSBjb250ZW50IGZvcm1hdHMg KG9yIGEgZ29vZCBzZWxlY3Rpb24gb2YgdGhlc2U/ICkgbGlzdGVkIGluIHRoZSBJQU5BIENvcmUg UGFyYW1ldGVycyBDb250ZW50LUZvcm1hdHMgcmVnaXN0cnkuIFRoaXMgaXMgdGhlIGRlZmluaXRp dmUgcmVmZXJlbmNlLg0KPiAqIHJlbW92ZSBzdXBwb3J0IGZvciB0aGUgdHlwZXMgdGhhdCBhcmUg bm90IHJlZ2lzdGVyZWQgaW4gdGhlcmUuIChXaHkgd291bGQgd2Ugc3F1YXQgb24gdW5hc3NpZ25l ZCBDb250ZW50LUZvcm1hdHM/IFBlb3BsZSBtYXkgZ2V0IGEgZmFsc2UgaW1wcmVzc2lvbiB0aGF0 IHRoZXNlIGFyZSB0aGUgb2ZmaWNpYWwgY29udGVudC1mb3JtYXQgbnVtYmVycy4pDQo+ICAgIC0g Zm9yIHNvbWUgdHlwZXMgdGhlIHJlZ2lzdHJhdGlvbiBtYXkgYmUgcGVuZGluZyBlLmcuIGR1ZSB0 byBhbiBJLUQuIFRoZXNlIHR5cGVzIGNhbiBvZiBjb3Vyc2Ugc3RheSBpbiB0aGUgbGlicmFyeSBj b2RlLiAgSG93ZXZlciBpdCBtYXkgYmUgaGFyZCB0byBpZGVudGlmeSBhbGwgc3VjaCBJLURzIDsp DQo+ICogdGhlIGlzc3VlIDEwNzggaGFzIHRoZSBsaW5lOiAiQXBwbGljYXRpb24veC1vYml4LWJp bmFyeSA9IDUxIiAtPiB0aGlzIGNvbmZsaWN0cyB3aXRoIHRoZSBjdXJyZW50IGFzc2lnbm1lbnQg aW4gdGhlIHJlZ2lzdHJ5OiBhcHBsaWNhdGlvbi9qc29uLXBhdGNoK2pzb24gKDUxKS4gIFNvIGl0 IGNhbiBiZXR0ZXIgYmUgdXBkYXRlZCB0byB0aGUgcmVnaXN0ZXJlZCB0eXBlLg0KPg0KPiBTbyBi ZXN0IHRvIHVwZGF0ZSBpdCBub3c7IGFuZCBjcmVhdGUgYSBuZXcgaXNzdWUgdG8gY2hlY2sgYWdh aW4gaW4gc29tZSBmdXR1cmUgdGltZSB3aGV0aGVyIG5ldyB0eXBlcyB3ZXJlIGFkZGVkIGluIHRo ZSBtZWFudGltZS4NCj4NCj4gQmVzdCByZWdhcmRzDQo+IEVza28NCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgQWNoaW0gS3JhdXMNCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciA1LCAyMDIxIDE2 OjA2DQo+IFRvOiBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFtjb3JlXSBJQU5BIC0gQ29udGVu dC1Gb3JtYXRzDQo+DQo+IEhpIExpc3QsDQo+DQo+IGFjY29yZGluZyBhbiBpc3N1ZSBpbiBFY2xp cHNlL0NhbGlmb3JuaXVtIGZyb20gSmltLCAyMDE5DQo+DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9l Y2xpcHNlL2NhbGlmb3JuaXVtL2lzc3Vlcy8xMDc4DQo+DQo+ICJUaGVyZSBpcyBhbiBlZmZvcnQg Z29pbmcgb24gdG8gZ2V0IGEgc3dlZXAgb2YgYWxsIG9mIHRoZSBrbm93bg0KPiBtZWRpYS10eXBl cyByZWdpc3RlcmVkIg0KPg0KPiBoZSBhbHNvIHJlZmVycmVkIHRvDQo+DQo+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvcm1hbm4tY29yZS1wcm9hY3RpdmUtY3QvDQo+ DQo+IFRob3VnaCB3ZSBjdXJyZW50bHkgd2FudCB0byB1cGRhdGUgdGhlIG1lZGlhLXR5cGVzIGlu IENhbGlmb3JuaXVtLA0KPiB0aGUgcXVlc3Rpb24gcmFpc2VzLCBpZiB0aGUgb25nb2luZyBlZmZv cnQgaXMgaW4gdGhlIG1lYW50aW1lIGZpbmlzaGVkPw0KPg0KPiBJcw0KPg0KPiBodHRwczovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBhcmFtZXRlcnMvY29yZS1wYXJhbWV0ZXJzLnho dG1sI2NvbnRlbnQtZm9ybWF0cw0KPg0KPiB0aGUgY29uc29saWRhdGVkIHJlc3VsdD8NCj4NCj4g YmVzdCByZWdhcmRzDQo+IEFjaGltIEtyYXVzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+DQoN Cg== From nobody Sat Nov 6 17:10:13 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 CF31D3A0B6B; Sat, 6 Nov 2021 17:09:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163624379976.20011.8071797609040604614@ietfa.amsl.com> Date: Sat, 06 Nov 2021 17:09:59 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-href-08.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, 07 Nov 2021 00:10:03 -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 Resource Identifiers Authors : Carsten Bormann Henk Birkholz Filename : draft-ietf-core-href-08.txt Pages : 21 Date : 2021-11-06 Abstract: The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-href/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-href-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-href-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Nov 6 17:52:51 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 C9D4A3A0C7B; Sat, 6 Nov 2021 17:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab89XrazSFy9; Sat, 6 Nov 2021 17:52:45 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442543A0C79; Sat, 6 Nov 2021 17:52:45 -0700 (PDT) Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Hmwh94lH7z2xHr; Sun, 7 Nov 2021 01:52:41 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <163624379976.20011.8071797609040604614@ietfa.amsl.com> Date: Sun, 7 Nov 2021 01:52:41 +0100 Cc: i-d-announce@ietf.org X-Mao-Original-Outgoing-Id: 657939161.25632-77e2f8caddf25293510a34b62f978ae7 Content-Transfer-Encoding: quoted-printable Message-Id: References: <163624379976.20011.8071797609040604614@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-href-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: Sun, 07 Nov 2021 00:52:50 -0000 -08 of the CRI (Constrained Resource Identifier) specification corrects = one crucial error in the definition of left-out authority sections. It also allocates -5 and -6 for the urn: and did: schemes (and provides = an example for the latter). On a more experimental level, it also makes a proposal for accommodating = percent-encoded segments to achieve better parity with URIs, without = needing fall back to string scanning and duplication; this might be an = optional part of CRIs for those applications that need this parity. = Please discuss: = https://www.ietf.org/archive/id/draft-ietf-core-href-08.html#name-extended= -cri-accommodating- Gr=C3=BC=C3=9Fe, Carsten > On 2021-11-07, at 01:09, 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 : Constrained Resource Identifiers > Authors : Carsten Bormann > Henk Birkholz > Filename : draft-ietf-core-href-08.txt > Pages : 21 > Date : 2021-11-06 >=20 > Abstract: > The Constrained Resource Identifier (CRI) is a complement to the > Uniform Resource Identifier (URI) that serializes the URI components > in Concise Binary Object Representation (CBOR) instead of a sequence > of characters. This simplifies parsing, comparison and reference > resolution in environments with severe limitations on processing > power, code size, and memory size. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-href/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-core-href-08.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-href-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Nov 7 08:46: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 EC91B3A095C for ; Sun, 7 Nov 2021 08:46: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 bVACyi1P47GI for ; Sun, 7 Nov 2021 08:46:41 -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 E28793A0965 for ; Sun, 7 Nov 2021 08:46:39 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8AF9C4042B; Sun, 7 Nov 2021 17:46:28 +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 3D1C3154; Sun, 7 Nov 2021 17:46:27 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4f69:be08:bb2:9f43]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EEA56CD; Sun, 7 Nov 2021 17:46:21 +0100 (CET) Received: (nullmailer pid 2715637 invoked by uid 1000); Sun, 07 Nov 2021 16:46:21 -0000 Date: Sun, 7 Nov 2021 17:46:21 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Giuseppe Fioccola Cc: "core@ietf.org" , Mauro Cociglio , Tianran Zhou , Massimo Nilo , Fabio Bulgarella Message-ID: References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7LNuJO4rR1HDjSOy" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Sun, 07 Nov 2021 16:46:47 -0000 --7LNuJO4rR1HDjSOy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Giuseppe, On Fri, Oct 22, 2021 at 04:17:02PM +0000, Giuseppe Fioccola wrote: > We have just uploaded a new draft on CoAP Performance Measurement > Option, which we hope to discuss at IETF 112. This document aims to > specify a method for the Performance Measurement of CoAP. skimming through your slides and the document I'm left wondering what the obtained details would be used for. Estimates for RTT and losses are produced, for example, also in the FASOR draft[1] -- but these get applied to retransmission parameters, which are per-hop (ie. up to the next proxy), where good estimates are direly needed. What would the derived values be used for? What are the intermediaries this is intended to work with? CoAP proxies hide the identity of the client, and moreover often apply caching (which will at any rate need a bit of consideration if this is to be applied through proxies). Thus, on the server side the data in the bits would likely appear completely mixed in presence of more than one client, and clients would receive mixed signals in presence of cache entries. So, for both aspects, it'd be helpful if you could sketch out the envisioned use cases. Best regards Christian [1]: https://datatracker.ietf.org/doc/html/draft-ietf-core-fasor-01 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --7LNuJO4rR1HDjSOy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGIAtoACgkQOY0REtOk veH10w//TSpdc6OqpFaJ/QuZM2DTmaKmrfbcoiBBM925nxwl61qm600Th8lmAUe/ Uc/fRBVmEr/c777zhaqubrLg/fRUn6hnj5/r/SqnsjeyPJt4x/kcSZD3xy4dsSaU ea8NE+UBkW4WxmIjYm0Y0FYC2mj2Fq96KsduxTGk4ci880HGhz6dUpq6fRawhLyW KB29yfwMiAmwOIBm1fu0Isurd8pyMm0vzoaPd+qG1Lto3LL0cMnUk7UtqYAlnWPS sVss7LJ50XOThdOC2wkUEkVpB1sNv2rDklDJUDlCszPEJRoFH81oCWOKhCIi4YQt HQqYa6oVZR68qLLFMijad0b79wAR1xz0bhtpHdO2TTxzxL8qAKHAC8nd5Qm/wB0T r0RYYvobgp/GQ/GyyUjzIzM5sK/5F4wG2rdzPxqynQRDwFaG3sbjuscLZrcd7dHl 5vQ6Ehl0uNfE90XIf4QSWBpqdn62vSqODDVuYi80xiBwshgbdfJzZGqRkRuanNbr 1W0Jk3F4t5G+M0etsHSG4S/wGgiq0qwEJy2ivnshdfCY/rrXtpKQKC9ou+OMPqTI H7vPD89BplMWbQcdDmtMAOcjHlM7BPjN7IvCZIiyudxfF98t3ErGvP2aSNFYnqer Kw7TRYSVAJ03qHlOIezhhSDcFH1JZAXIGcNw5FiQiql0xkKi4ZM= =EOcl -----END PGP SIGNATURE----- --7LNuJO4rR1HDjSOy-- From nobody Mon Nov 8 00:51: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 230133A0C7B for ; Mon, 8 Nov 2021 00:51:04 -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_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 SyHpnXiMHAW2 for ; Mon, 8 Nov 2021 00:50:58 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712273A0C6E for ; Mon, 8 Nov 2021 00:50:58 -0800 (PST) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hnl826dzzz67ybm for ; Mon, 8 Nov 2021 16:46:10 +0800 (CST) Received: from kwepeml100004.china.huawei.com (7.221.188.19) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 8 Nov 2021 09:50:53 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by kwepeml100004.china.huawei.com (7.221.188.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 8 Nov 2021 16:50:51 +0800 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.015; Mon, 8 Nov 2021 09:50:49 +0100 From: Giuseppe Fioccola To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "core@ietf.org" , Mauro Cociglio , Tianran Zhou , Massimo Nilo , Fabio Bulgarella Thread-Topic: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt Thread-Index: AQHXx17e3fh7XXlrQEuEwuZTp3pIr6vfMGlAgBkeEoCAAP+nsA== Date: Mon, 8 Nov 2021 08:50:49 +0000 Message-ID: <33b733997e454534a7155b839b657a74@huawei.com> References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.210.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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, 08 Nov 2021 08:51:04 -0000 Hi Christian, Thank you for your comments. Please find my answers inline as [GF]. Regards, Giuseppe -----Original Message----- From: Christian Ams=FCss =20 Sent: Sunday, November 7, 2021 5:46 PM To: Giuseppe Fioccola Cc: core@ietf.org; Mauro Cociglio ; Tianra= n Zhou ; Massimo Nilo ; Fabio Bulgarella Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-= 00.txt Hello Giuseppe, On Fri, Oct 22, 2021 at 04:17:02PM +0000, Giuseppe Fioccola wrote: > We have just uploaded a new draft on CoAP Performance Measurement=20 > Option, which we hope to discuss at IETF 112. This document aims to=20 > specify a method for the Performance Measurement of CoAP. skimming through your slides and the document I'm left wondering what the o= btained details would be used for. Estimates for RTT and losses are produce= d, for example, also in the FASOR draft[1] -- but these get applied to retr= ansmission parameters, which are per-hop (ie. up to the next proxy), where = good estimates are direly needed. What would the derived values be used for? [GF]: The derived values (RTT, losses) can be useful for an operator or an = enterprise that is managing a constrained, low-power and lossy network. As = IoT and M2M keep growing, a mechanism to measure the performance can become= useful to meet the operational requirements. Also, it should be a simple m= echanism to be developed on constrained nodes.=20 What are the intermediaries this is intended to work with? CoAP proxies hid= e the identity of the client, and moreover often apply caching (which will = at any rate need a bit of consideration if this is to be applied through pr= oxies). Thus, on the server side the data in the bits would likely appear c= ompletely mixed in presence of more than one client, and clients would rece= ive mixed signals in presence of cache entries. [GF]: The intermediaries or on-path observers could also be network gateway= or probes, that can see deep into application and read the measurements. T= his information can be used to monitor the network in order to check the op= erational performance and to employ further network optimization. The measu= rements can be end-to-end between Client and Server or can be split. If CoA= P Proxies are used, the measurements can be done between the Proxies or bet= ween the Proxy and the Client. The Server can distinguish the source client= , for example by using additional flow information such as the IP addresses= . It could also possible to bundle different clients if they are mixed. I t= hink we have to clarify the different scenarios in the next version of the = draft. So, for both aspects, it'd be helpful if you could sketch out the envisione= d use cases. Best regards Christian [1]: https://datatracker.ietf.org/doc/html/draft-ietf-core-fasor-01 -- To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom From nobody Mon Nov 8 04:11: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 236303A0DD1 for ; Mon, 8 Nov 2021 04:11:57 -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 CpYzclBm1iRL for ; Mon, 8 Nov 2021 04:11:54 -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 43B2C3A0DCE for ; Mon, 8 Nov 2021 04:11:53 -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 5A9E54042B for ; Mon, 8 Nov 2021 13:11:46 +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 F11A3154 for ; Mon, 8 Nov 2021 13:11:44 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:63a1:4cf4:d190:b295]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 900202A for ; Mon, 8 Nov 2021 13:11:44 +0100 (CET) Received: (nullmailer pid 2812271 invoked by uid 1000); Mon, 08 Nov 2021 12:11:44 -0000 Date: Mon, 8 Nov 2021 13:11:44 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l2Vd8loM29BmLerq" Content-Disposition: inline Archived-At: Subject: [core] CoRE applications side meetings (pubsub / dynlink)? 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 Nov 2021 12:11:57 -0000 --l2Vd8loM29BmLerq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, The CoRE applications (pubsub, dynlink) get little attention on this round's meeting -- shall we meet to see where and how we can make progress? (This may include aligning with current CoRAL, but also involve general discussion of what CoRE can be used for). I'd be happy both with a larger meeting (like Wednesday or Thursday 2h before the WG meetings), and in smaller groups ("everyone interested in X"). BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --l2Vd8loM29BmLerq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGJE/wACgkQOY0REtOk veF3+A//S5MIen6p5v73BwVZ1wRQb5vbM8BPPemR65kB4BuNiLc3uMYjQpGTQ2eC gO98G0UpKKBW+8Gmpx5bN/GGQ/KKyfo6J8XWncABLyM9FxH452g0lCar4GNz0hXB NPMdQgu6WE8CbT+ukm4Tas41hRp/3jV9QPIMhEILNcT5lq8ooyJ+nKZW5/1yfoor gW2nCxhFcoI4Dz+cYj+ZuukQSqyWvyy0VimCV0ekrq10mX32TxZUvlFRPvpModWw HjX9JmOnCQy8IMLEafrR0Hy40igAGz0IJkw3Fp1IrA+KrpHOCDKw/FHB2kdlTvyr /svBMxrRrqe8bE2NiWqO14TYwaJow+OAiSZG0SX8RS0gFsWkFdtZyj9jMkHTk7GB o9qoCAKpeproquWX48H3t86jF1sZYE5Y6UWIUHpDAXFYPqMIhRDTIsOf7ikiv5nb EVsKoDIFLJd2w8I0aYnkflPP8h+h+m8vZ7VNHOykxsPU9MX6/9k7FbajBNh+jfVu NBGO41HE3/DfYoqt7ZdRmw40zyD/LQds31mJP2yO2aQ0rSE6UoC/U8XxTsjYVlpa JLXBNjuwSrj1+4m72jfrGTL/ncQvYshrrmUra4/tUOOQ/ttQeSu7deu7BZAGt0RY +PeX0UIjBSaK4dEui5j5FmhI56VU18STyo+PlzNPaOQB70aXGOw= =CbS+ -----END PGP SIGNATURE----- --l2Vd8loM29BmLerq-- From nobody Mon Nov 8 05:19: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 DBC4C3A0FE3 for ; Mon, 8 Nov 2021 05:19:26 -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_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 Nt5eLFhOMjIK for ; Mon, 8 Nov 2021 05:19:22 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FC13A1007 for ; Mon, 8 Nov 2021 05:19:22 -0800 (PST) Received: from smtpclient.apple (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HnsCC3z1Xz30Lx; Mon, 8 Nov 2021 14:19:19 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: Date: Mon, 8 Nov 2021 14:19:18 +0100 Cc: core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9DDCD35B-7044-4939-BC59-0BB95D1B2E3B@tzi.org> References: To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [core] CoRE applications side meetings (pubsub / dynlink)? 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 Nov 2021 13:19:27 -0000 This week is full. Can we instead have an earlier interim for this? Gr=C3=BC=C3=9Fe, Carsten > On 8. Nov 2021, at 13:11, Christian Ams=C3=BCss = wrote: >=20 > Hi, >=20 > The CoRE applications (pubsub, dynlink) get little attention on this > round's meeting -- shall we meet to see where and how we can make > progress? (This may include aligning with current CoRAL, but also > involve general discussion of what CoRE can be used for). >=20 > I'd be happy both with a larger meeting (like Wednesday or Thursday 2h > before the WG meetings), and in smaller groups ("everyone interested = in > X"). >=20 > BR > Christian >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Nov 8 23:49: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 1E4C53A0D73 for ; Mon, 8 Nov 2021 23:49:11 -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 s6QUiox5c-Bf for ; Mon, 8 Nov 2021 23:49:06 -0800 (PST) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE773A0D71 for ; Mon, 8 Nov 2021 23:49:06 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id 5FA791AC0078; Tue, 9 Nov 2021 02:49:03 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute6.internal (MEProxy); Tue, 09 Nov 2021 02:49:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=s0AKhG VDD7ftYx2Wuq4/WK9ODmx4Sc9VYk5ONvmkIHI=; b=QwEd3RyI63O9HNRaJEZElc ZcuDrGTS5BY02IR2/GvW3PHh06Vg6MWo8qOKXvFuwBArfPVudcD9rrPCQpsbn0Tk ofByyYbUMSle6cZQ5MVhpcZ8FyUfTICkCFSbcsoP0PnvDhoFeHL9wjbyMCY8PlSy xsDkLBLBQ4wSmIvtahXnUV1XRmWf0Ha7cF/ee2+aX7mVTMUACJSTWHZRXUp9ZFB1 16MTZBJMJTcJTeqduXIe/+4GDJgYpwnsln9gjpOpf7M/XZxQiNEZtrZZgs718Tf3 ToTSKhpcStknv9it44fCMw1hg0kl7oMVolInR8POdCCMK2YcItuitGEbV3M4nk7g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgfgsehtqhertderreejnecuhfhrohhmpeflrghimhgv pgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpe fggfejkeelgfeiteehfffftddtgeejffehfeevudetteelgfdvheegfeeltdegvdenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvse hikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C2C0424A0074; Tue, 9 Nov 2021 02:49:02 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34 Mime-Version: 1.0 Message-Id: <97d7f098-ff89-4dae-a9dd-be09225553aa@www.fastmail.com> Date: Tue, 09 Nov 2021 09:48:42 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_Confirming_adoption_of_draft-hoegl?= =?utf-8?q?und-core-oscore-key-limits-02_as_a_CoRE_WG_document?= 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, 09 Nov 2021 07:49:11 -0000 Dear CoRE, In yesterday's CoRE meeting, we had good in-room consensus to adopt draft-hoeglund-core-oscore-key-limits as a WG draft (Adoption call= : +9, one "not raise hand" ). As usual, we need to confirm consensus on the list. If you are opposed t= o adopting this document, please speak up on this list. The WGA call will last until November 22 to give time to process t= hings after IETF 112. If you were in the meeting, you don't have to confirm consensus again. Ciao! --=20 Jaime Jim=C3=A9nez From nobody Tue Nov 9 08:17:50 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 3F8403A0AAD for ; Tue, 9 Nov 2021 08:17:49 -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 80QZk_sDPMRo for ; Tue, 9 Nov 2021 08:17:47 -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 CFFA53A0AA0 for ; Tue, 9 Nov 2021 08:17:46 -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 71F564042B for ; Tue, 9 Nov 2021 17:17:42 +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 876C9154 for ; Tue, 9 Nov 2021 17:17:40 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4224:536:dec1:aafe]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EF593CD for ; Tue, 9 Nov 2021 17:17:39 +0100 (CET) Received: (nullmailer pid 2957848 invoked by uid 1000); Tue, 09 Nov 2021 16:17:39 -0000 Date: Tue, 9 Nov 2021 17:17:39 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nlXhgRbS18XPaZNi" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] CoRE applications side meetings (pubsub / dynlink)? 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, 09 Nov 2021 16:17:49 -0000 --nlXhgRbS18XPaZNi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Mon, Nov 08, 2021 at 01:11:44PM +0100, Christian Ams=FCss wrote: > The CoRE applications (pubsub, dynlink) get little attention on this > round's meeting -- shall we meet to see where and how we can make > progress? (This may include aligning with current CoRAL, but also > involve general discussion of what CoRE can be used for). based on the feedback that arrived, a small group will meet tomorrow (Thursday) 10:00 UTC in the hackathon area to look through some applications (pubsub, problem-details), possibly doing examples or check out how things align with current CoRAL. We should probably meet in a larger group at some point too (maybe on one of the wednesdays before CBOR/CoRE resume interims) still, but this should get us a bit of a start already. BR c PS. STP is one more of the applications I'd like to see a bit of progress on, maybe we can push this in the same context. --=20 A beginning is the time for taking the most delicate care that the balances= are correct. -- Princess Irulan, Manual of Muad'Dib --nlXhgRbS18XPaZNi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGKnx8ACgkQOY0REtOk veFacQ/8CzChjb43FL0NiIRK6luRt8CGVxDDalMsXV8QLtthR+3vFWxHjFtke16g pUTO1oDaMd6iCgg8tVRDgjQE5POAv1wWUdHVUlrOiiH+hEPHjG9ddhH2Uu5GoTce 5XEVL20th19EUyOZrWwsPOK6h8PjMdiGjcgWtJczPZQ7aDdg93rew9mbBLLgDPpb 0XH9pdbNe9rmMOf7XeptH+cv64cMAE/11sJUUCcqMh9kYxj7EHKdKoXHUW3PUEoa leH2R164BrQihQ/chY7vewwLdxnLwY4yhMvW6rc3eBDDizd034i8xzimWuPA1tah A014JNe4lJBEyNsq1kSx+T9p0lZcRHAWMR5EJcQZ1EZCrpB135UDYntjxVRwmI5A UuYjZS9pVZJ0mZHgBbIgtlh49074bPGhJRn4YpKmwKkXujS+EC/PubxVdMZUoeab NB6yu+gpxdDbbSXPzZ+BhPl+rPKLCDqyovW2I8Lf6JxPeIZL2Y1o5ZNmN5S1J+2s B7j2Fo6xiAyb1UF+XAoLUAHVPwSmFMeKP2deBKCdIhUPgpizRN7fTqZlAd3+bjhN pgkXP/HER87GJX2UglE1b+SQyvurZddHIsUO/uw1JtcRn/40gY90MWtei3GbQccM BCUuSiaNHvybJNFUaYiZpU6vlJ7dIkqnX88bqe/B8W14bwYzFO4= =p2Rk -----END PGP SIGNATURE----- --nlXhgRbS18XPaZNi-- From nobody Tue Nov 9 08:25: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 70E743A0C2E for ; Tue, 9 Nov 2021 08:25:06 -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 J3gx-x3-yEAx for ; Tue, 9 Nov 2021 08:25:01 -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 96B5C3A0BDE for ; Tue, 9 Nov 2021 08:25:00 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id BF35B4042B; Tue, 9 Nov 2021 17:24:58 +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 8877C154; Tue, 9 Nov 2021 17:24:57 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4224:536:dec1:aafe]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1A294CD; Tue, 9 Nov 2021 17:24:57 +0100 (CET) Received: (nullmailer pid 2958434 invoked by uid 1000); Tue, 09 Nov 2021 16:24:56 -0000 Date: Tue, 9 Nov 2021 17:24:56 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jaime =?iso-8859-1?Q?Jim=E9nez?= Cc: core@ietf.org Message-ID: References: <97d7f098-ff89-4dae-a9dd-be09225553aa@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rfDKR7bEiH+Jlw5v" Content-Disposition: inline In-Reply-To: <97d7f098-ff89-4dae-a9dd-be09225553aa@www.fastmail.com> Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirming_adoption_of_draft-hoegl?= =?utf-8?q?und-core-oscore-key-limits-02_as_a_CoRE_WG_document?= 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, 09 Nov 2021 16:25:07 -0000 --rfDKR7bEiH+Jlw5v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jaime, > In yesterday's CoRE meeting, we had good in-room consensus to > adopt draft-hoeglund-core-oscore-key-limits as a WG draft (Adoption > call: +9, one "not raise hand" ). I was one of the 9, and just want to reiterate here that I consider both parts of the document important for the WG. I do not understand all the pieces that come together on the IA and CA limits part, but can offer reviews of KUDOS part as this will progress. Thank you Rikard and Marco for working on this Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --rfDKR7bEiH+Jlw5v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGKoNgACgkQOY0REtOk veE/QBAAlEU8rEwxXqre2xwL/C0m1NvT3ZjmSK4nBz7n4OB2jaykDdxponmrcdeL IB776Ue3z793RUesQOt8TOl978RtYqsk7CEWsQrmCySH1qfyTfB4I8P3i2+7Dspm /0aXp76VK8a9IsjaHPV+bixUXNcVKet5qe5oJ+V407hEqXJk20V2DoueOt332060 Y7P7iMgM2r4U01kY0kz39XLpMSgm22+JLSUNheBNPqZRjta7F0FV8TKDDi9K6YpB 4ZJOaGu18Jg25p3Eq4R+7hhLEci/wFsGvli8m4WnxFdyXzpgTZrbMdP6WjyxNskH zxHsDZIbxeeZ248aZkhS7fVMtf83QJEb4T7olYe9j//hJdo1nn2tCiJY09NNHnIR qFKX2Cv5sivZQ6qDR0TSLVmHS1fw1tvf1lsG7w9kUMHnpCgeuvR+WAUEZj7unGRN nYFE7gY31NYcWy+MmZX070/3CHK4kHSAbn92YmC76JxQ1GlwqkmchKq2MvGhfUoU WuyvMDtjlxeGO53fiTFzqHtVjRAY25/SKPhaFVRjgMZ6EoRRNZwMIGM7IoRk6OKq dc9sEVQUi+n4K4arQTZyTBUTWujaWWZEWxWl/kgSD4+4ze+YA7kZO+IrqvKyRFYf JhBjLzMGd5zPScFkE/yy7oxGrfT79p0z7G+zfQNPoMt9oH5p9v4= =x9Nz -----END PGP SIGNATURE----- --rfDKR7bEiH+Jlw5v-- From nobody Tue Nov 9 08:58: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 6ACBF3A0CE0 for ; Tue, 9 Nov 2021 08:58:15 -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 3iYoWkhzQjhU for ; Tue, 9 Nov 2021 08:58:10 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2065.outbound.protection.outlook.com [40.107.21.65]) (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 A81883A0CD9 for ; Tue, 9 Nov 2021 08:58:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ekzPEDAelbhMIaKS9WY7v6+2TQTkT3Vp6ZSkIBtGADyOl+ySSuBz+uLx9fnbo18uDvM0PVud2ggNWShyJyaW/HDv9rPFluuGTcZeMkUrgFZdw/hr9tgNti3PLt8kcBpxp0V3fKdOfbt1GajXbmxov2zCTCGgWbv+oSQeYD1GNEhQ41c+xwOJq8lE50HtmpgWLB3R5W4lfWRIyHQNyxqw2eVYasDThL3wnqm/UZcuKipTVnKJrhBIhrc+RWZnaQCgmYm2CESpzwtDs9kk8vXJB5C5ajV+Xo23eHFeZ045NJlIuPKXgSMyA8VvBN9veyliL4eaXnu9l+tOZWSLgTPvFA== 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=0sGHXLpbnB14JnMwDltSFUyusdCe4j5c1U9hMp/rA1k=; b=aQ/XJ64Ts1uXh+lZG78baChKzHVzztbert9V6cbGjFpP9ypAtKalZlmsTyOszlcfDau7S8jNMn54L2lPfT1MBoA8atQ78J2Ssm5tk14hPDSFJgGiix+wH2nO1kwGWlmMjTPUPw24HN28RorNP4wP2esnpnDj3awpbNl68/8NA4qoF6nWGsKdQDH0HpOvkQnJ47xbI9Ym0G2Mdxdf5op1LVJO5Ra6uIy9LGLPi6B/3IfBoz6l38f6ZVa06W9Mx2DdczvBBs5TM42nxW/BYzDGj1gAZqefgkFBWvCONg6hSt2kOyrIHX7vFQjwJyWc0NFzX8PXhw0bnVogFt3PYSUOEQ== 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=0sGHXLpbnB14JnMwDltSFUyusdCe4j5c1U9hMp/rA1k=; b=JYJ/d85BiWvSV4nr6z0kLETrU3Mm4M1Kme20VbMv5b7B3tMHL1um6MzmLRqf4xPeFS+O2qjON7e6fnuG8gLpDyXk8r2e3Z226PS8/fTpShjNH7i4VCar0r/lM7aD4dS9UsO0o3h6sk3RkbkLsMZE8ZU69kyml3wxBkz2GNztrug= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0918.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10; Tue, 9 Nov 2021 16:58:06 +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.4669.016; Tue, 9 Nov 2021 16:58:06 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <691b5afb-5210-861f-7439-7b55e741a7f4@ri.se> Date: Tue, 9 Nov 2021 17:58:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hFb5zQ9HDk5f89khHmGGSoE8Om3E1kUmi" X-ClientProxiedBy: MN2PR07CA0001.namprd07.prod.outlook.com (2603:10b6:208:1a0::11) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [192.168.0.65] (92.34.13.218) by MN2PR07CA0001.namprd07.prod.outlook.com (2603:10b6:208:1a0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.15 via Frontend Transport; Tue, 9 Nov 2021 16:58:05 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bca372d2-cf0f-4a03-1da6-08d9a3a219d0 X-MS-TrafficTypeDiagnostic: DB8P189MB0918: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kmiKwytO3ip2za0tI8KD7ZMrO/oRJ7t5FMXOVDMxW2RV5oms6FBZ15fynCS6lXHl/ki7BR0tpNStsQglLqLMLdtWIzEZ9fxzK06nAkoFr9hYvtSi6PBi6QORLPPBYvoCknXVo3bIKhoCaeMjrTiJZVeLu7TE8L4rCeXsEPHC2+D3DEvSmLYhqJOFe1Z3pcDY0WuW0Zqivwn30gI2Jx6Tu4RAxyAJ9OhnF4e4W4GLJzyR1+VRJVSzXOozPR7IrFptCq+PjHpkTTm3Blja0MkTJ6jBbo9aysY5zZ128dDHE+u1r7lSm8w2CIPPScPUxW0auCxhNbAgCEcYIRvOm9zFvr9+8JRu8a7zsaHjFGfRFQLhRYLKvrY8Cspqi4HsDP/VQ1xriGISuCRmb/cj098fp63SXcHET3eFZtKhF9lIzhdYurx2pA/Eie1FW2Yexb/d0fByg4vNTONgP/qMyhYevUS4r0oe815j+pvpvzCfGZKoC3fBBxU55Srekq2XtX+biivGv8peB929V+QRhRKgGcybX0euLm8y9wMoKjZjczZ1beBuw//pJR9i0/4nHb/zIO3KtEw+5jQrKshh1WnYLcNPlWm0eWZ7HhiZo8VOh0RNCeRelGdJDh4lVDd/OurRSzTVITt33/2TL0fK1P8CeqsUVYZwRf2IOykRckiuzL2rkJ31BNbVuveO3nCHuL6cGj0AiVKzqs/RRbdzwjAPY4jmMk9oc81xJPCOgbpMhV4PFNqziD6f6gdTTOaVOZi1WTHhx3evNrGDzh9I8ADVsRqw4mN9gOkAo0/urKFk5EL1hSiqbvh1wgKOMG0ltFrhdAN2hNaL8Vtr0EW03tJHrnWNGIUg8Ns2NdmfkPXlMCU= 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)(6666004)(966005)(8936002)(316002)(44832011)(508600001)(83380400001)(33964004)(235185007)(16576012)(8676002)(36756003)(66946007)(66476007)(38100700002)(6916009)(31686004)(66556008)(186003)(5660300002)(2906002)(2616005)(26005)(86362001)(31696002)(21480400003)(956004)(6486002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NnNLNEhpRGRjUkoxSmY5WVhtd29CZ3hxNUw1YWtHRVA2RFBONlMxcTNXbTU1?= =?utf-8?B?MWlPeTVTV2FxRlRuVktwM0txZndMR2lJR3VoTzVWZ1p0SVVFQnF6MEZMdk5L?= =?utf-8?B?RWF6WDNGdnBlK0l6WnpPdTZ5YTV0OWM2Q3BreUdEU3daaWRuK2NrOFJweXdY?= =?utf-8?B?dWxuc01wUGJWeDFxVjYrbGdqK04yTE9HYjhOOUw4d3hXd1ZwTWFnaXhBOHBD?= =?utf-8?B?WXpnaHowbndVdVBucldzSEhkOXAxWG9Wc05Xa2NHTXhmS0FxUWJpWXZsblQ0?= =?utf-8?B?V0w3YVd5YnpHWnoyZ0IwOHFEQ2lnQUhzWG9yOUJyalN0eG0wRGQrOWV2SWMx?= =?utf-8?B?S1NvTHNTVThZbXU0a1p5QzRuNy9RZnlISWRERVdtWGxBTjF0S3NjbFBIY0JN?= =?utf-8?B?YlRMV2JrYWpxSzM4UDAzNjRteEkyelJWSW90NERjdDJsN2dUVG9RMlhyaWZL?= =?utf-8?B?amdYWlJLcFU2VXdSTTRNRVdpbUhCUEtQNGo3SU92eVlsZTRGRXo4ZWtnRmk2?= =?utf-8?B?SEdOUWVNZWVRM1RTeGg3VzdBSmlaak0yQkRrWXczNTltcjBmalZhTmJGb1Ri?= =?utf-8?B?dzVlYmY1RW13ZHE0VDZabE96Vm5CS1hjVmZKRWZiMGlqRk01ckVnTmtQNmN5?= =?utf-8?B?Ry9yanFxbytGd3BoUXNKNXJOV1N4eldkU09XMUFPYzArdGZ5ajB6QzAvck5G?= =?utf-8?B?NHovNVZYQXBuMFo5anNQdVV5bkZJNzlKNHJjODNISzQzaXZKMmtKN3Nobmcz?= =?utf-8?B?d2pLL1lkTmJaV1JlQk1iSkdEeUk3UnRCVlFST0JNcE1vRmsybnlMUDVPK0lO?= =?utf-8?B?VUM2ZnJjNHRUQnZ0eXhZS3RGMnZlUGxTTjFrSno2WDlhZlVsK0pyWWZRam5o?= =?utf-8?B?cWFKZjVzL0Z1TDBlcXRHdUhVSlh3ZTdyVy92ZDRBWUNUNGVpYWlsOVBxWVhw?= =?utf-8?B?aktCWkJyOEFhV0pvbEg5d01lbHdLenB4MkdjQ1lMamJRekFYRU02cDR3Z1or?= =?utf-8?B?R0ttSlpIaE9GbmJ1ZkxMc0FKcjZ3S2RkRnZVN28rYWlnREZEaVZ6b2dOVjlL?= =?utf-8?B?Rk15MkxxUEVxZkdVd0prVWpDdHVaeWY5TW9McTNtUHlNeGtweDYwalFaWmJx?= =?utf-8?B?OE1hMEpORkNzRDRSRU1DN1BwbzNoRlFHS2pSenZDSHlLZkZPN1RNSlgyMEpk?= =?utf-8?B?bFZNRXBPWmt2eDFiSU43UnZacFBjaVZyRVpUK0ExZk1DS1FJU2ZROVdqWDFX?= =?utf-8?B?V0ZOS09ydXlRc3FnbENzT2xyY3lNay9mUk5tdU5tK0N0cWM4bXRLcTRYM2ZU?= =?utf-8?B?U2dheHBEb0Y2eUhaSDl0b1pURlJFd1I3OUlFRCsyVFB4THN2OHhUY25hR1lR?= =?utf-8?B?Ny9icURUM05HU3FnQ3hxQTNkNnpZVXlXazJUQVlUb0ZjWVdVV042SXBIMDYr?= =?utf-8?B?ZUJrTU0yaDhYeUVaNWFwYjh2ZEFoTGl0SmxNVG15ZWxXWHhtQ2ltSjJ3YTZY?= =?utf-8?B?Ukh5Tk1ESU9iM3c5bDNKNXpZUEZWOXBOTWxyWm14SERTcTdrS1VhT1pQWFR6?= =?utf-8?B?elE3RGY2Nmh5NU9ISDB5TzhBZlRZK1o4eDVNMTBLZXZmOTFQU2NZcWdja1gz?= =?utf-8?B?R3llYTRKUTZoY05Dbkx6Z0F2WFhsWWttbWdCeVRVaVN3VmlUaHZ5WXBuU2Iy?= =?utf-8?B?cHhWczlZT3VlZU44SXJNb2hXdlQrQW5hK1h0eXRvN2EvME92Ly9QVS96UDhi?= =?utf-8?B?SDZMcmkyRkNJVmNpamo0bnM4NkR6dkpXdjNEYm1lMFdIYnM4Q0lzd2FhRDZy?= =?utf-8?B?MWlCMWNXajg1SGMyMmc2OGd0N2haUHpzUWhIS2RNbTYwaGxQeUlJd1AyYkRP?= =?utf-8?B?TCt3bjBNdUZMNXV5dHdmMkcyRXR6ZHlUZlJCeFZPR2pvWE83MjN6WVovL0E3?= =?utf-8?B?cFBYNjROZzlrbzNKVmRQN2U3WXE2K1BkM0VVR1lVcnV3YzhqUjY3a1JnaEEz?= =?utf-8?B?U1V5MGlHaWN6ZXVvZUZ0bmYrT3BPWThLWUJVcjdtRCtxWlVmUWNqWCtpYWJx?= =?utf-8?B?Zk1jeWlTcUsyM2NXVXpFcUw4bGNpR3ZRbnVqdndVY1M2NVRvZWFXSWlSSTV1?= =?utf-8?B?RUViTHJOTzZmTkVCaGRvUEFucUhhaU9BZGQ0Q1g2Qnc0TnUrS0d5d3VXUjAy?= =?utf-8?Q?Qwd7KqR7Hbk/XWyfvjU7Cck=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: bca372d2-cf0f-4a03-1da6-08d9a3a219d0 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2021 16:58:06.4855 (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: nDO3rkiwrab/o9h+xLeLcSzXUxucrVLDNtrfUui59Usite5Pv7gfJ8LU8+5OEpp2pTDPZwzOgjOTArDlAIht5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0918 Archived-At: Subject: [core] CoRE @ IETF 112 - Minutes 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, 09 Nov 2021 16:58:15 -0000 --hFb5zQ9HDk5f89khHmGGSoE8Om3E1kUmi Content-Type: multipart/mixed; boundary="EEvtM4yQVThUgZKPghH8pKkSBd8PTEXMA"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <691b5afb-5210-861f-7439-7b55e741a7f4@ri.se> Subject: [core] CoRE @ IETF 112 - Minutes --EEvtM4yQVThUgZKPghH8pKkSBd8PTEXMA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, The minutes for the CoRE session are available at [1]. Thanks a lot to=20 the note takers Christian Ams=C3=BCss and G=C3=B6ran Selander! Please, send possible fixes and updates to=C2=A0 core-chairs@ietf.org=C2=A0= or to=20 the mailing list, preferably within the next 7 days. The recording of the CoRE session is available at [2]. Thank you all for your participation and contribution! Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/112/session/core [2] https://www.youtube.com/watch?v=3DW_gQYnCMtzk --=20 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=C3=A5ngen 16 SE-164 40 Kista (Sweden) --EEvtM4yQVThUgZKPghH8pKkSBd8PTEXMA-- --hFb5zQ9HDk5f89khHmGGSoE8Om3E1kUmi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmGKqJkFAwAAAAAACgkQ7iZktA5Y2kOq IQgAszc6bJtV3a9vzAgIOLVVWK0v0l3FGQgrpthwt/j1L6J/z9+1sXllHtrlDSOtAoE6b5d2iV1y F5ASAd9SQVJ0WczkBcvl+pHP76HFgBNx+s3AMUbJ+CoKYcrGr1N/mdrUidRNHdVxmXTiWXoeRScq BBjJuBOEy/hTXm0A2rb7sKMPkyyXFC6pcquy5TxZKdIvC00qgGt2Jcwm63jSHMJ9rNOKw3Az9IaK syIelgdGoSVkJf166h+wAbg0ulKbZBjglmApKwEV5zAplUfFXbsQE7nPweeG5A0eEhm+iSc1HDZM jhBFV/tU4B5vCxFpAvr7zO84/N3Yk+56lcUwPESbUA== =0rzh -----END PGP SIGNATURE----- --hFb5zQ9HDk5f89khHmGGSoE8Om3E1kUmi-- From nobody Tue Nov 9 09:11: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 B1C593A0D60 for ; Tue, 9 Nov 2021 09:11: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 5zkNzErxmbOh for ; Tue, 9 Nov 2021 09:11:43 -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 EA2D83A0CBC for ; Tue, 9 Nov 2021 09:11:42 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8D47D4042B; Tue, 9 Nov 2021 18:11:35 +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 2C993154; Tue, 9 Nov 2021 18:11:34 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4224:536:dec1:aafe]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CD9B2CD; Tue, 9 Nov 2021 18:11:33 +0100 (CET) Received: (nullmailer pid 2962177 invoked by uid 1000); Tue, 09 Nov 2021 17:11:33 -0000 Date: Tue, 9 Nov 2021 18:11:33 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Giuseppe Fioccola Cc: Mauro Cociglio , Massimo Nilo , "core@ietf.org" , Fabio Bulgarella Message-ID: References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oHZyG8k5qBzH/j8+" Content-Disposition: inline In-Reply-To: <33b733997e454534a7155b839b657a74@huawei.com> Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Tue, 09 Nov 2021 17:11:46 -0000 --oHZyG8k5qBzH/j8+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Giuseppe, On Mon, Nov 08, 2021 at 08:50:49AM +0000, Giuseppe Fioccola wrote: > [GF]: The derived values (RTT, losses) can be useful for an operator > or an enterprise that is managing a constrained, low-power and lossy > network. As IoT and M2M keep growing, a mechanism to measure the > performance can become useful to meet the operational requirements. > Also, it should be a simple mechanism to be developed on constrained > nodes.=20 OK, so this sounds more like a "characterization" (to demonstrate meeting some requirements?) than "feeding these values into the protocol again", is that correct? Or is concrete action to be taken based on these? (If so, I'd imagine it would need to be more fine-grained than across all involved proxies). > [GF]: The intermediaries or on-path observers could also be network > gateway or probes, that can see deep into application and read the > measurements. This information can be used to monitor the network in > order to check the operational performance and to employ further > network optimization. The measurements can be end-to-end between > Client and Server or can be split. If CoAP Proxies are used, the > measurements can be done between the Proxies or between the Proxy and > the Client. The Server can distinguish the source client, for example > by using additional flow information such as the IP addresses. It > could also possible to bundle different clients if they are mixed. I > think we have to clarify the different scenarios in the next version > of the draft. Let me illustrate what I mean here by describing a use case like those I'd expect to see it around this document (not necessarily in a document update -- OK if that helps, but for initial steps this thread may suffice): 1 -- 2 -- 3 -- 4 -(Internet)- 5 1. Devices: Sensors with 6LoWPAN connectivity, operated by A. 2. Gateway: Proxy (eg. running on a cellular-to-6lowpan router) shipped with the sensors and operated by A. 3. Uplink: provided by B. 4. Probe: passive monitoring device operated by B. 5. Backend: Data center operated by A. If this protocol is run between 1 and 5 (across intermediaries), the values read at 4 would be total round-trip times over the 6LoPAN, the cellular network and the remaining Internet. I wouldn't know what to do with those values; given that 2 is acting as a proxy, they are not the relevant parameters to tune their CoAP stack, and wouldn't tell anyone where to add capacity. (Moreover, data at 4 would look like garbage -- different clients at 1 would send uncoordinated PM values, and at 4 the clients are not distinguishable any more by design). If, to set up a similar but different scenario, 4 was also a CoAP proxy, the PM option were hop-by-hop, and the protocol would be performed between 2 and 4, then this would result in a characterization of the cellular uplink, and (in my vastly oversimplifying imagination) might be used to place additional cell towers there. The operator situation here does raise an additional concern: If 2 is operated by A and 4 by B, wouldn't this be prone to A forcing B to take action (for example) by maliciously flipping the square bit every 62nd message, giving B the impression that there is message loss? I'm not asking for security considerations here at this point (I would later, and privacy on top of that), more about the assumptions underlying this work. BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --oHZyG8k5qBzH/j8+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGKq8UACgkQOY0REtOk veE88w/6AtkI4xS8fLYHrG9tnti8uCyzMU8ueC3rK/zIEBdZhweuyACRR/85iOtQ 3zkWWGGM0oBuGMIFPdlIeyghXiuf4U0U0fiZVEInaGDl2ehsylI0oD0uy47QVOFe MY/e/PiFGDkHmyA+PplWDKpDRj7jbtbOzpIZc57Mm5F9rCZCxhEphff8uKLCN3bG ZxU3tktmHreDXv7rtU04hcSq0sg4Bb3+5eB3/oqEkcOGwlB8CiyprDYGZccMoBLd g9RTJkEP9er82kvcES6e+g9+qFGXOmHu6SYSYLV22cS34MHpS6tGbRAcCYxeo5Wp 3dd6JP8aPEawCkY0s+FN8CFEZf3pHeR21kJeP6PRp8KNMkjTZLWgJ1+OOG2znanr n3benaIcAslJs4IjvJYqdJOhCyOxjgFIy8kcsXCpd3EewLfowfYvwPEMHdEaoGeF gQtebnWReJz8QhJv+B1wzGjrJAYeNM2oRAvQa0zFw8DDv31CLKZDL1opnXQHMPz9 FgmZ2Mlx/GaRd0SX2LCTtzhr2Imwgl4CWMYsg727qVIpr3CJe9yzO7sUabEU6xTq 1gz16z5BsPXkfC03r5l0S7S7tf4UffcUlhkCNk42cQAb148D3UMg+Gqdzk0pYCPV Mo8NPSiySZPjSUme2RqMQ4bqClZ/4YtYZSd33HV+jcnLFnwhsZU= =mlMj -----END PGP SIGNATURE----- --oHZyG8k5qBzH/j8+-- From nobody Tue Nov 9 09:56: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 C239E3A0EC7 for ; Tue, 9 Nov 2021 09:56:25 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlBj-98krzNi for ; Tue, 9 Nov 2021 09:56:23 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 3013B3A0EC4 for ; Tue, 9 Nov 2021 09:56:23 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id 1so137910ljv.2 for ; Tue, 09 Nov 2021 09:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GE6TASG9xOGKFZd9X0N5cvzyLEo/iDmcY+wXc2lIX4o=; b=eRNiO8m1G07bkZuAH6UHTZ5FvQVp9eHLeGSLgtez6eSVDPcHg6b65VsKE53cyDPSaj SxWCdxtu4K1YRA5dYxH68sH2Aary18JLH1nEmQYrMhxTVc7oYaIbSdt5f9mTqTVQgr6Q +Ls2vavAglzn8ysnuSfzrEFcsGBBPKg3Xw+tj0ZWhFlNBSeOHphTfORz0vUBH3CeLZ80 MiUvgzdZJBlR6oYQo43Pq5HWgf13gA4Vpj30Odz0yQE4y9dFTGe53gW+ukk0H7po/+yG ucz82ECvPihU3xB55efEUxVAeNdlAfSPjBC0z/r7lmSWiCrwu29CDTGnd0xYY+B2Ld1W M4yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GE6TASG9xOGKFZd9X0N5cvzyLEo/iDmcY+wXc2lIX4o=; b=g8TndgTZc+GFqwTM1nJyVaRKrzrTHsdG7dDrLudprhCM5Hhxu2/TQ0o3XVGS9rO8UM On2lJvdHzfLwRaqtqxR9LAh2PBKxOhNwmPyeAozP5GpN3W/kiAgQTqRHytkY1fRqbES4 bIZAAhRvRRH1IsaL2mxdE8Xc78vPMUyZ14Gp8ueDAkN7aS2Gjg0PpwJ5+qH9sL5j9wYk uLK7w3cZHvo6rghzS23VwjklZB5QA3pIf4WB9j0dW+a5TioeSGDArqRPJIUP/V6/Fr/i m6qvJ41DGL+A+5ayl9EJDQche1MW0IRQFL78cRpvu3q3BwR4gK9tbNcjEGBEBDJ5Lvkr lTqQ== X-Gm-Message-State: AOAM532ZQtHoLSvlEoMMxBsv3sAInda2lck2Y8hm7xRWifaGRvmDHOOY N+yEL0AwrC2oQDUtDc1HDSl3blDdjsAe2tSMVyE= X-Google-Smtp-Source: ABdhPJyVN8aiwi6GX9eYWMVL+se/FrB3w3DPPKBVrxhbJhaEFXRfxbUJl4M9/IsQfQg8etAzZwx8UtXyYPzwl3YdcUQ= X-Received: by 2002:a2e:b88b:: with SMTP id r11mr9423960ljp.474.1636480581018; Tue, 09 Nov 2021 09:56:21 -0800 (PST) MIME-Version: 1.0 References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> In-Reply-To: From: Thomas Fossati Date: Tue, 9 Nov 2021 17:56:10 +0000 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: Giuseppe Fioccola , Mauro Cociglio , Massimo Nilo , "core@ietf.org" , Fabio Bulgarella Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Tue, 09 Nov 2021 17:56:26 -0000 Hi Christian, Giuseppe, Mauro, Massimo, Fabio, On Tue, Nov 9, 2021 at 5:11 PM Christian Ams=C3=BCss wrote: > > Hello Giuseppe, > > On Mon, Nov 08, 2021 at 08:50:49AM +0000, Giuseppe Fioccola wrote: > > [GF]: The derived values (RTT, losses) can be useful for an operator > > or an enterprise that is managing a constrained, low-power and lossy > > network. As IoT and M2M keep growing, a mechanism to measure the > > performance can become useful to meet the operational requirements. > > Also, it should be a simple mechanism to be developed on constrained > > nodes. > > OK, so this sounds more like a "characterization" (to demonstrate > meeting some requirements?) than "feeding these values into the protocol > again", is that correct? Or is concrete action to be taken based on > these? (If so, I'd imagine it would need to be more fine-grained than > across all involved proxies). > > > [GF]: The intermediaries or on-path observers could also be network > > gateway or probes, that can see deep into application and read the > > measurements. This information can be used to monitor the network in > > order to check the operational performance and to employ further > > network optimization. The measurements can be end-to-end between > > Client and Server or can be split. If CoAP Proxies are used, the > > measurements can be done between the Proxies or between the Proxy and > > the Client. The Server can distinguish the source client, for example > > by using additional flow information such as the IP addresses. It > > could also possible to bundle different clients if they are mixed. I > > think we have to clarify the different scenarios in the next version > > of the draft. > > Let me illustrate what I mean here by describing a use case like those > I'd expect to see it around this document (not necessarily in a document > update -- OK if that helps, but for initial steps this thread may > suffice): > > 1 -- 2 -- 3 -- 4 -(Internet)- 5 > > 1. Devices: Sensors with 6LoWPAN connectivity, operated by A. > 2. Gateway: Proxy (eg. running on a cellular-to-6lowpan router) shipped > with the sensors and operated by A. > 3. Uplink: provided by B. > 4. Probe: passive monitoring device operated by B. > 5. Backend: Data center operated by A. > > If this protocol is run between 1 and 5 (across intermediaries), the > values read at 4 would be total round-trip times over the 6LoPAN, the > cellular network and the remaining Internet. I wouldn't know what to do > with those values; given that 2 is acting as a proxy, they are not the > relevant parameters to tune their CoAP stack, and wouldn't tell anyone > where to add capacity. > > (Moreover, data at 4 would look like garbage -- different clients at 1 > would send uncoordinated PM values, and at 4 the clients are not > distinguishable any more by design). > > If, to set up a similar but different scenario, 4 was also a CoAP proxy, > the PM option were hop-by-hop, and the protocol would be performed > between 2 and 4, then this would result in a characterization of the > cellular uplink, and (in my vastly oversimplifying imagination) might be > used to place additional cell towers there. > > The operator situation here does raise an additional concern: If 2 is > operated by A and 4 by B, wouldn't this be prone to A forcing B to take > action (for example) by maliciously flipping the square bit every 62nd > message, giving B the impression that there is message loss? I'm not > asking for security considerations here at this point (I would later, > and privacy on top of that), more about the assumptions underlying this > work. Yep, it looks like the ideal scenario is one where the new CoAP options are clear-text and integrity protected end-to-end by OSCORE. Then A and/or B can put their measurement boxes (or functions) in one or more places to break down the different RTT contributions where it makes sense (e.g., at the ingress/egress of their respective network segments). If we can't assume integrity protection we'd need to take cheating inventives, trust relationships and all those things into consideration, which tend to make the analysis much more complicated. cheers! > > BR > Christian > > -- > To use raw power is to make yourself infinitely vulnerable to greater pow= ers. > -- Bene Gesserit axiom > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Thomas From nobody Tue Nov 9 10:20: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 3391C3A0F48 for ; Tue, 9 Nov 2021 10:20:38 -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 yx74CnExJPNL for ; Tue, 9 Nov 2021 10:20:36 -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 6893B3A0F46 for ; Tue, 9 Nov 2021 10:20:36 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 707A74042B; Tue, 9 Nov 2021 19:20:29 +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 5D34D154; Tue, 9 Nov 2021 19:20:28 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4224:536:dec1:aafe]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 25CECCD; Tue, 9 Nov 2021 19:20:28 +0100 (CET) Received: (nullmailer pid 2967757 invoked by uid 1000); Tue, 09 Nov 2021 18:20:27 -0000 Date: Tue, 9 Nov 2021 19:20:27 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Thomas Fossati Cc: Giuseppe Fioccola , Mauro Cociglio , Massimo Nilo , "core@ietf.org" , Fabio Bulgarella Message-ID: References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v/Bw+2p35CsSr7ys" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Tue, 09 Nov 2021 18:20:38 -0000 --v/Bw+2p35CsSr7ys Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 09, 2021 at 05:56:10PM +0000, Thomas Fossati wrote: > Yep, it looks like the ideal scenario is one where the new CoAP > options are clear-text and integrity protected end-to-end by OSCORE. > Then A and/or B can put their measurement boxes (or functions) in one > or more places to break down the different RTT contributions where it > makes sense (e.g., at the ingress/egress of their respective network > segments). If we can't assume integrity protection we'd need to take > cheating inventives, trust relationships and all those things into > consideration, which tend to make the analysis much more complicated. Just because it's integrity protected E2E doesn't mean that the ends are not lying to the observer. The integrity protection would only tell the ends if someone tampered, and if they are the ones interested in it, they could encrypt it right away (if it helps *them* assess the link properties, of which I'm not sure). How would any of this tell the observer about the contribution of different hops to the total loss? BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --v/Bw+2p35CsSr7ys Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGKu+sACgkQOY0REtOk veFLXQ/+Nj3FJqADqWuRB4TlQgISPv1MA/NllIevOnsJ5lqjCwRB57AYUpe3Ka43 5hq0oXTrIqOzrCyGIfrUIM/OxokhMgvvhXqKmEhJKfh5uLoNoW4l1ZG68cz5oHxD JGvkUiLHorIHZvW/+5KSEbAvgT7P35aDrfYeYYyq5bUyWETAyf+xpnswxCAuomIi Dg8tiVRej3Qlzd0fJdedOr3pRhIzyyYUjzc5qmc36UyV++r7TrTy2564eRexvQ/C irVeQktw2eeEascWmpJoLqM/+s5NVYjCcC/TGxxC2hlQXWuMSR0FYYIN1gD7W0Is AXEtm+KEKS2/kTvuG73Cuk58eyupYbzHFXpVlQEoHlAOuO8B53c63rCOoJZV4OC7 pQxUzYee7cuOQPVrBa6XOuQY3G30qJL1e/obErdxoyM5uUWrE1vP+oKo/TEu5Raz tpAkGnyzwLVEPLmWU0rApFLJJ4l0bxQcG/uzB3DhM3F8NAXpqKCktTQVbaIdr9I3 LTOPpuilBqEMe/5g4RwAMky9AyPf/T0aHd56S07FNen8NoupD2MLx+Htu1R11/LP 1aDxEsw9ZM/6tlXBieWzMij7E7C7XCu82Qv/B9QojLwhftHEPeY3dUD/d+kCNgh3 Z6rIaMis4wDVQZbtojJym72b5vwg6I/l/2/e43P5OFyCUXTRgts= =C/ok -----END PGP SIGNATURE----- --v/Bw+2p35CsSr7ys-- From nobody Tue Nov 9 11:00:05 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 C291B3A0E7B; Tue, 9 Nov 2021 11:00:03 -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 091X6s7B5zFi; Tue, 9 Nov 2021 10:59:59 -0800 (PST) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29353A0E1C; Tue, 9 Nov 2021 10:59:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.nyi.internal (Postfix) with ESMTP id 2983F19407D3; Tue, 9 Nov 2021 13:59:55 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute6.internal (MEProxy); Tue, 09 Nov 2021 13:59:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=xhvzA2 fxICag78ZBlVQ1e0lB2Vh/uBNcKXtZKNWQgC0=; b=l/D9PDzCsFpIlJuUsgYCGc y7Bou4RC03e0lU5C0iXthd91Mzp7L57VA5Cb11aRsg1b6kBV7KKydcptax0UhgTM ipypnY0oINWbs7PzX0XAvcML4PHr/8u5655EN56yKABqjskLdVLYoRgzTBHaQoS0 1nqPWaB1BKmCVJyJUJem2YKWZ82nnhNRAHsxqwQEfhGGVgM4WV8Ynfh/R0vgv8Wo ukYl8eGd08oSi7C9NQXQlE7lpcxQbf9jP8qqYkJCD8y0BzX0nSxJXlU+xcP5pP7U iBWNIXziCRnLdLNiUZfhnHxhjnF5ZkEmeewQYBolXI5vlvW7obDzW6U2KZZCek2A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeggdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgfgsehtqhertderreejnecuhfhrohhmpeflrghimhgv pgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpe ekhffggeejieegiedthfevgfeugfelfeduhfekgeduvddtgffhuddtieekffefjeenucff ohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1838024A0074; Tue, 9 Nov 2021 13:59:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34 Mime-Version: 1.0 Message-Id: Date: Tue, 09 Nov 2021 20:59:32 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org Cc: draft-ietf-core-oscore-groupcomm.authors@ietf.org, "Marco Tiloca" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-os?= =?utf-8?q?core-groupcomm?= 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, 09 Nov 2021 19:00:04 -0000 Dear CoRE, as we discussed yesterday, the authors of draft-ietf-core-oscore-groupco= mm think their draft is ready for a 2nd WGLC. The current version of the= draft (v13) is not expecting any updates so you can start your planned = reviews. https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-13 In addition to the email list discussion reviewers could consider openin= g new issues on the Github repo of the draft as courtesy to the authors. https://github.com/core-wg/oscore-groupcomm As we have the IETF ongoing and the document needs time to be digested, = we place the end of the call on the 1st of December with a possibility o= f extension depending on the number of reviews. >From the minutes I take that CA, RH, ED and TF would give it thorough lo= ok. Thank you already for that, much appreciated!! Ciao! --=20 Jaime Jim=C3=A9nez From nobody Tue Nov 9 11:17: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 C1C3A3A1003 for ; Tue, 9 Nov 2021 11:17:53 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EerjFMCffVKO for ; Tue, 9 Nov 2021 11:17:50 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 A795C3A0E81 for ; Tue, 9 Nov 2021 11:17:49 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id t11so506521ljh.6 for ; Tue, 09 Nov 2021 11:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KaOewEWx0og+c/fUyXi/Vcw+uL/OprHWX7Q8GrtqZ2A=; b=UZC5TjTl06FxGh51jPk33p6h3+yZUVsTtNjr9KJya4CZ68t+TP0AzQ5MEgU7JZS+ll h1DBzVnYGWyj/ARlbmWN8zIMDTkSeWi80Y2b7ad8Uu9eYfXXfzYUfKn7WAzBXFhgTVt/ krwZqCkSNzebVkN1LYiN6/Fdc5LbNRku4SUF2FE2Hkjj0uJ3JY43FO33DWMCF+DWLbQC TzCNv8Zc/fp9ftk6VdbM3egm2aYkIjW1ouCVRDpl6kzYnX9p7RhFLuIbywticU0VZ4Sw vsks96HUFMJRDCtbI0FMGQrf8NqpZuXrySjiqYITWnpH1Nmz837lrgTOtZlBDT7DuL94 rQtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KaOewEWx0og+c/fUyXi/Vcw+uL/OprHWX7Q8GrtqZ2A=; b=OTHqjUcJHKiJct1nKEMY8ykVxvJTqbNIiduGjW3Ss0vs23kOofco/0WGnzEcUiE3oO Bcnc1pp+Sz5eFDsC8CvTnO0aMiwjdRqk7uPFfqwsOANHurSe0P4jTVnFBXG2LXrYVgA6 R+OAXPjsYsM/Fmb+LQL+0KeTKKi6j3YFWJ0eB5HjzDjpb4C/cESEihJQ/2sC1Hw2AL3d iV6p9Qglha6HP5rdydhBAjWAGSMGXbLQngW/EmcJQy6LmQpwcdB20PdPykT0M6d9LGg4 eJCJxtCsyt/w3v2ShCkYrtN7nsApWg7IBgnZccoMTwK5yA3NctvF0nQKaohzfU5bLIJW 2IKg== X-Gm-Message-State: AOAM530cfBQFn3masu3nspP1bcDISzYzfgb1cuv258kks4ox3BBRaPFn avpnroD5BSBeC9sK1FgTYv/76UWAhP9BG1kOJao= X-Google-Smtp-Source: ABdhPJyotYZh0y8BZZmnUf5zby0zpSZRFVaBdKGG/q/vJjou88576cRVNiU0XR5JFWgsdtv7IERSwtW6zBmxMYphYSg= X-Received: by 2002:a2e:8099:: with SMTP id i25mr7781793ljg.528.1636485462733; Tue, 09 Nov 2021 11:17:42 -0800 (PST) MIME-Version: 1.0 References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> In-Reply-To: From: Thomas Fossati Date: Tue, 9 Nov 2021 19:17:27 +0000 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: Giuseppe Fioccola , Mauro Cociglio , Massimo Nilo , "core@ietf.org" , Fabio Bulgarella Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Tue, 09 Nov 2021 19:17:54 -0000 On Tue, Nov 9, 2021 at 6:20 PM Christian Ams=C3=BCss wrote: > > On Tue, Nov 09, 2021 at 05:56:10PM +0000, Thomas Fossati wrote: > > Yep, it looks like the ideal scenario is one where the new CoAP > > options are clear-text and integrity protected end-to-end by OSCORE. > > Then A and/or B can put their measurement boxes (or functions) in one > > or more places to break down the different RTT contributions where it > > makes sense (e.g., at the ingress/egress of their respective network > > segments). If we can't assume integrity protection we'd need to take > > cheating inventives, trust relationships and all those things into > > consideration, which tend to make the analysis much more complicated. > > Just because it's integrity protected E2E doesn't mean that the ends are > not lying to the observer. I am much more worried by the signal being tampered with by a random on-path attacker rather then the endpoints trolling the observer. What is their incentive to lie? If they don't want to (or cannot) participate they just do nothing. It's zero cost for them being removed from the measured set. > The integrity protection would only tell the > ends if someone tampered, and if they are the ones interested in it, > they could encrypt it right away (if it helps *them* assess the link > properties, of which I'm not sure). I see the proposed mechanism -- correct me if I'm wrong -- as a way for network diagnostic tools to do their large-scale measurements requiring (just a minimal amount of) collaboration from the endpoints. The information they extract from the options' signals is not something the endpoints don't already know (possibly with higher quality). cheers, > How would any of this tell the observer about the contribution of > different hops to the total loss? > > BR > c > > -- > To use raw power is to make yourself infinitely vulnerable to greater pow= ers. > -- Bene Gesserit axiom --=20 Thomas From nobody Tue Nov 9 11:47: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 D23D73A103E for ; Tue, 9 Nov 2021 11:47:43 -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 OF95ZxwzaA4h for ; Tue, 9 Nov 2021 11:47:40 -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 61C883A103B for ; Tue, 9 Nov 2021 11:47:40 -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 3C9314042B for ; Tue, 9 Nov 2021 20:47:37 +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 CBB99154 for ; Tue, 9 Nov 2021 20:47:35 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4224:536:dec1:aafe]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 70B49CD for ; Tue, 9 Nov 2021 20:47:35 +0100 (CET) Received: (nullmailer pid 2974668 invoked by uid 1000); Tue, 09 Nov 2021 19:47:35 -0000 Date: Tue, 9 Nov 2021 20:47:35 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l6G5tkI1qlHjoGm4" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] CoRE applications side meetings (pubsub / dynlink)? 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, 09 Nov 2021 19:47:44 -0000 --l6G5tkI1qlHjoGm4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 09, 2021 at 05:17:39PM +0100, Christian Ams=FCss wrote: > based on the feedback that arrived, a small group will meet tomorrow > (Thursday) 10:00 UTC in the hackathon area to look through some it's only Tuesday and I'm already in a state of mind melt. tomorrow is Wednesday, which is when this *should* happen (at least Marco, Jaime and me will be there). Sorry for the mixup c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --l6G5tkI1qlHjoGm4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGK0FMACgkQOY0REtOk veFjaA/+P6kJQuSAUO8IxIHIdSvnS3VR0FHQaidOw3AOzh3Qjh20mPOLR3i8LSwb OgzytiUd9uQBlpo0U2We6Q4rsxKc3FBCIoflnz+5hDal8lrOnafzkGN40bte+/JV 6DAaQH3igYqnYuCne5z09CaVQ0iIeJJ9EZwBK8TzRgiwoFFURYsVbvYHQNm9bLO6 4lrzf1FmCtdpaiXQ1bzk5LqqbvK9403C9Uw5jDKIxe4LQVz0S3bDYiQMu9UyD2PM T1TkRKCuR41FPuC50VEnhTQGS7rPMjQDIurTQht5Qi7zvYc3G8FoeLRazhlgNU2N A7FFjUyXbuMzpg3eScEP1aksDytzrhOKnVzkqyyu13E7dEwENk85BQWa2fAL5lRD i/ZSGg/J0GidMAAxU0+NZuzM+hVZ08Zf9TwNR6+Qvt9iLsbyau74ANtHLrwZ13DH c3/JYpkwDuxpK2Idc4BTSl2+BTYnY2gxn1w+PzuQxnLlwCx/Xrt0RTuNYYwoXjUR vIQrBA28/iE4LXMrP1ApY0QvkhzoISiv/bKMkTPSV1iXxbuOF4i5uWxdJYo2xny/ +1+8dQHLTzBM538pxtcHLbiXhe+IHOQR9DZCVkbhRncqR7y85FPsipZYxz/YE6pJ 1uBHoUqDDkX7ySTwgZ6Os9kBXGRh5p8k00IBp6PWr3WgrWbdZGU= =oPhr -----END PGP SIGNATURE----- --l6G5tkI1qlHjoGm4-- From nobody Wed Nov 10 09:04: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 7CA743A126C for ; Wed, 10 Nov 2021 09:04:35 -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_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 fWCkPKsVMelp for ; Wed, 10 Nov 2021 09:04:30 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE213A1234 for ; Wed, 10 Nov 2021 09:04:28 -0800 (PST) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HqB1t6FNZz67Mrt; Thu, 11 Nov 2021 01:00:50 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 10 Nov 2021 18:04:25 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.015; Wed, 10 Nov 2021 18:04:24 +0100 From: Giuseppe Fioccola To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: Mauro Cociglio , Massimo Nilo , "core@ietf.org" , "Fabio Bulgarella" Thread-Topic: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt Thread-Index: AQHXx17e3fh7XXlrQEuEwuZTp3pIr6vfMGlAgBkeEoCAAP+nsIACLA2AgAGcq/A= Date: Wed, 10 Nov 2021 17:04:24 +0000 Message-ID: <5d3f81311cc64a31b3d96688cf1c379a@huawei.com> References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.221.222] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Wed, 10 Nov 2021 17:04:38 -0000 Hi Christian Please find my answers inline as [GF]. Regards, Giuseppe -----Original Message----- From: Christian Ams=FCss =20 Sent: Tuesday, November 9, 2021 6:12 PM To: Giuseppe Fioccola Cc: Mauro Cociglio ; Massimo Nilo ; core@ietf.org; Fabio Bulgarella Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-= 00.txt Hello Giuseppe, On Mon, Nov 08, 2021 at 08:50:49AM +0000, Giuseppe Fioccola wrote: > [GF]: The derived values (RTT, losses) can be useful for an operator=20 > or an enterprise that is managing a constrained, low-power and lossy=20 > network. As IoT and M2M keep growing, a mechanism to measure the=20 > performance can become useful to meet the operational requirements. > Also, it should be a simple mechanism to be developed on constrained=20 > nodes. OK, so this sounds more like a "characterization" (to demonstrate meeting s= ome requirements?) than "feeding these values into the protocol again", is = that correct? Or is concrete action to be taken based on these? (If so, I'd= imagine it would need to be more fine-grained than across all involved pro= xies). [GF]: Yes it can be both. It can surely be used for a characterization but = it can also imply concrete actions to be taken based on these measurements. > [GF]: The intermediaries or on-path observers could also be network=20 > gateway or probes, that can see deep into application and read the=20 > measurements. This information can be used to monitor the network in=20 > order to check the operational performance and to employ further=20 > network optimization. The measurements can be end-to-end between=20 > Client and Server or can be split. If CoAP Proxies are used, the=20 > measurements can be done between the Proxies or between the Proxy and=20 > the Client. The Server can distinguish the source client, for example=20 > by using additional flow information such as the IP addresses. It=20 > could also possible to bundle different clients if they are mixed. I=20 > think we have to clarify the different scenarios in the next version=20 > of the draft. Let me illustrate what I mean here by describing a use case like those I'd = expect to see it around this document (not necessarily in a document update= -- OK if that helps, but for initial steps this thread may suffice): 1 -- 2 -- 3 -- 4 -(Internet)- 5 1. Devices: Sensors with 6LoWPAN connectivity, operated by A. 2. Gateway: Proxy (eg. running on a cellular-to-6lowpan router) shipped with the sensors and operated by A. 3. Uplink: provided by B. 4. Probe: passive monitoring device operated by B. 5. Backend: Data center operated by A. If this protocol is run between 1 and 5 (across intermediaries), the values= read at 4 would be total round-trip times over the 6LoPAN, the cellular ne= twork and the remaining Internet. I wouldn't know what to do with those val= ues; given that 2 is acting as a proxy, they are not the relevant parameter= s to tune their CoAP stack, and wouldn't tell anyone where to add capacity. [GF]: It is correct. Spin bit allows RTT measurement for all the intermedia= te points but with sQuare Bit and by applying the methodologies in RFC8321,= it is also possible to do hop-by-hop measurements for loss and delay. I ca= n include these considerations in the draft.=20 (Moreover, data at 4 would look like garbage -- different clients at 1 woul= d send uncoordinated PM values, and at 4 the clients are not distinguishabl= e any more by design). If, to set up a similar but different scenario, 4 was also a CoAP proxy, th= e PM option were hop-by-hop, and the protocol would be performed between 2 = and 4, then this would result in a characterization of the cellular uplink,= and (in my vastly oversimplifying imagination) might be used to place addi= tional cell towers there. [GF]: This could be possible by applying RFC8321 on the sQuare Bit signal. The operator situation here does raise an additional concern: If 2 is opera= ted by A and 4 by B, wouldn't this be prone to A forcing B to take action (= for example) by maliciously flipping the square bit every 62nd message, giv= ing B the impression that there is message loss? I'm not asking for securit= y considerations here at this point (I would later, and privacy on top of t= hat), more about the assumptions underlying this work. [GF]: Agree, security considerations need to be taken into account. For sim= ilar mechanisms we are considering the precondition of the controlled domai= n application, but security mechanisms, e.g. OSCORE can also be used. BR Christian -- To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom From nobody Wed Nov 10 09:24: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 E831C3A0CBA for ; Wed, 10 Nov 2021 09:24:11 -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_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 e1s00LqIfNjM for ; Wed, 10 Nov 2021 09:24:06 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9173A0CB2 for ; Wed, 10 Nov 2021 09:24:06 -0800 (PST) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HqBSP3H1pz67xN7; Thu, 11 Nov 2021 01:20:21 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 10 Nov 2021 18:23:55 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.015; Wed, 10 Nov 2021 18:23:55 +0100 From: Giuseppe Fioccola To: Thomas Fossati , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: Mauro Cociglio , Massimo Nilo , "core@ietf.org" , "Fabio Bulgarella" Thread-Topic: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt Thread-Index: AQHXx17e3fh7XXlrQEuEwuZTp3pIr6vfMGlAgBkeEoCAAP+nsIACLA2AgAAMdwCAAAbJgIAAD+2AgAF+oGA= Date: Wed, 10 Nov 2021 17:23:55 +0000 Message-ID: <76f5f82a0f52416a94157a2ffa72d8da@huawei.com> References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.221.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Wed, 10 Nov 2021 17:24:12 -0000 SGkgVGhvbWFzLA0KVGhhbmsgeW91IGZvciB0aGUgaW5wdXRzLA0KUGxlYXNlIGZpbmQgbXkgcmVw bGllcyBpbmxpbmUgYXMgW0dGXS4NCg0KUmVnYXJkcywNCg0KR2l1c2VwcGUNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVGhvbWFzIEZvc3NhdGkgPHRoby5pZXRmQGdtYWls LmNvbT4gDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciA5LCAyMDIxIDg6MTcgUE0NClRvOiBDaHJp c3RpYW4gQW1zw7xzcyA8Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPg0KQ2M6IEdpdXNlcHBlIEZpb2Nj b2xhIDxnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPjsgTWF1cm8gQ29jaWdsaW8gPG1hdXJv LmNvY2lnbGlvQHRlbGVjb21pdGFsaWEuaXQ+OyBNYXNzaW1vIE5pbG8gPG1hc3NpbW8ubmlsb0B0 ZWxlY29taXRhbGlhLml0PjsgY29yZUBpZXRmLm9yZzsgRmFiaW8gQnVsZ2FyZWxsYSA8ZmFiaW8u YnVsZ2FyZWxsYUBndWVzdC50ZWxlY29taXRhbGlhLml0Pg0KU3ViamVjdDogUmU6IFtjb3JlXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mei1jb3JlLWNvYXAtcG0tMDAu dHh0DQoNCk9uIFR1ZSwgTm92IDksIDIwMjEgYXQgNjoyMCBQTSBDaHJpc3RpYW4gQW1zw7xzcyA8 Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPiB3cm90ZToNCj4NCj4gT24gVHVlLCBOb3YgMDksIDIwMjEg YXQgMDU6NTY6MTBQTSArMDAwMCwgVGhvbWFzIEZvc3NhdGkgd3JvdGU6DQo+ID4gWWVwLCBpdCBs b29rcyBsaWtlIHRoZSBpZGVhbCBzY2VuYXJpbyBpcyBvbmUgd2hlcmUgdGhlIG5ldyBDb0FQIA0K PiA+IG9wdGlvbnMgYXJlIGNsZWFyLXRleHQgYW5kIGludGVncml0eSBwcm90ZWN0ZWQgZW5kLXRv LWVuZCBieSBPU0NPUkUuDQo+ID4gVGhlbiBBIGFuZC9vciBCIGNhbiBwdXQgdGhlaXIgbWVhc3Vy ZW1lbnQgYm94ZXMgKG9yIGZ1bmN0aW9ucykgaW4gDQo+ID4gb25lIG9yIG1vcmUgcGxhY2VzIHRv IGJyZWFrIGRvd24gdGhlIGRpZmZlcmVudCBSVFQgY29udHJpYnV0aW9ucyANCj4gPiB3aGVyZSBp dCBtYWtlcyBzZW5zZSAoZS5nLiwgYXQgdGhlIGluZ3Jlc3MvZWdyZXNzIG9mIHRoZWlyIA0KPiA+ IHJlc3BlY3RpdmUgbmV0d29yayBzZWdtZW50cykuICBJZiB3ZSBjYW4ndCBhc3N1bWUgaW50ZWdy aXR5IA0KPiA+IHByb3RlY3Rpb24gd2UnZCBuZWVkIHRvIHRha2UgY2hlYXRpbmcgaW52ZW50aXZl cywgdHJ1c3QgDQo+ID4gcmVsYXRpb25zaGlwcyBhbmQgYWxsIHRob3NlIHRoaW5ncyBpbnRvIGNv bnNpZGVyYXRpb24sIHdoaWNoIHRlbmQgdG8gbWFrZSB0aGUgYW5hbHlzaXMgbXVjaCBtb3JlIGNv bXBsaWNhdGVkLg0KPg0KPiBKdXN0IGJlY2F1c2UgaXQncyBpbnRlZ3JpdHkgcHJvdGVjdGVkIEUy RSBkb2Vzbid0IG1lYW4gdGhhdCB0aGUgZW5kcyANCj4gYXJlIG5vdCBseWluZyB0byB0aGUgb2Jz ZXJ2ZXIuDQoNCkkgYW0gbXVjaCBtb3JlIHdvcnJpZWQgYnkgdGhlIHNpZ25hbCBiZWluZyB0YW1w ZXJlZCB3aXRoIGJ5IGEgcmFuZG9tIG9uLXBhdGggYXR0YWNrZXIgcmF0aGVyIHRoZW4gdGhlIGVu ZHBvaW50cyB0cm9sbGluZyB0aGUgb2JzZXJ2ZXIuDQpXaGF0IGlzIHRoZWlyIGluY2VudGl2ZSB0 byBsaWU/ICBJZiB0aGV5IGRvbid0IHdhbnQgdG8gKG9yIGNhbm5vdCkgcGFydGljaXBhdGUgdGhl eSBqdXN0IGRvIG5vdGhpbmcuICBJdCdzIHplcm8gY29zdCBmb3IgdGhlbSBiZWluZyByZW1vdmVk IGZyb20gdGhlIG1lYXN1cmVkIHNldC4NCg0KW0dGXTogSSBhZ3JlZSB3aXRoIHlvdSwgd2UgY2Fu IGFzc3VtZSB0aGF0IGZvciB0aGUgdHlwaWNhbCBDT0FQIGFwcGxpY2F0aW9ucyBpdCBpcyBsZXNz IGxpa2VseSB0aGF0IHRoZSBlbmRwb2ludHMgYXJlIGF0dGFja2Vycy4NCg0KPiBUaGUgaW50ZWdy aXR5IHByb3RlY3Rpb24gd291bGQgb25seSB0ZWxsIHRoZSBlbmRzIGlmIHNvbWVvbmUgdGFtcGVy ZWQsIA0KPiBhbmQgaWYgdGhleSBhcmUgdGhlIG9uZXMgaW50ZXJlc3RlZCBpbiBpdCwgdGhleSBj b3VsZCBlbmNyeXB0IGl0IHJpZ2h0IA0KPiBhd2F5IChpZiBpdCBoZWxwcyAqdGhlbSogYXNzZXNz IHRoZSBsaW5rIHByb3BlcnRpZXMsIG9mIHdoaWNoIEknbSBub3QgDQo+IHN1cmUpLg0KDQpJIHNl ZSB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtIC0tIGNvcnJlY3QgbWUgaWYgSSdtIHdyb25nIC0tIGFz IGEgd2F5IGZvciBuZXR3b3JrIGRpYWdub3N0aWMgdG9vbHMgdG8gZG8gdGhlaXIgbGFyZ2Utc2Nh bGUgbWVhc3VyZW1lbnRzIHJlcXVpcmluZyAoanVzdCBhIG1pbmltYWwgYW1vdW50IG9mKSBjb2xs YWJvcmF0aW9uIGZyb20gdGhlIGVuZHBvaW50cy4NClRoZSBpbmZvcm1hdGlvbiB0aGV5IGV4dHJh Y3QgZnJvbSB0aGUgb3B0aW9ucycgc2lnbmFscyBpcyBub3Qgc29tZXRoaW5nIHRoZSBlbmRwb2lu dHMgZG9uJ3QgYWxyZWFkeSBrbm93IChwb3NzaWJseSB3aXRoIGhpZ2hlciBxdWFsaXR5KS4NCg0K W0dGXTogWWVzIGl0IGlzIHJpZ2h0Lg0KDQpjaGVlcnMsDQoNCj4gSG93IHdvdWxkIGFueSBvZiB0 aGlzIHRlbGwgdGhlIG9ic2VydmVyIGFib3V0IHRoZSBjb250cmlidXRpb24gb2YgDQo+IGRpZmZl cmVudCBob3BzIHRvIHRoZSB0b3RhbCBsb3NzPw0KPg0KPiBCUg0KPiBjDQo+DQo+IC0tDQo+IFRv IHVzZSByYXcgcG93ZXIgaXMgdG8gbWFrZSB5b3Vyc2VsZiBpbmZpbml0ZWx5IHZ1bG5lcmFibGUg dG8gZ3JlYXRlciBwb3dlcnMuDQo+ICAgLS0gQmVuZSBHZXNzZXJpdCBheGlvbQ0KDQoNCg0KLS0N ClRob21hcw0K From nobody Wed Nov 10 09:29:18 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 895BC3A0CC3 for ; Wed, 10 Nov 2021 09:29: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, 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 PpOj14v5nTlS for ; Wed, 10 Nov 2021 09:29:12 -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 7667F3A0CBE for ; Wed, 10 Nov 2021 09:29:11 -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 3C1BC40432; Wed, 10 Nov 2021 18:29:08 +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 0FF9D154; Wed, 10 Nov 2021 18:29:06 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:7e72:4702:4fa5:7df8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BF221CD; Wed, 10 Nov 2021 18:29:05 +0100 (CET) Received: (nullmailer pid 655505 invoked by uid 1000); Wed, 10 Nov 2021 17:29:05 -0000 Date: Wed, 10 Nov 2021 18:29:05 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Giuseppe Fioccola Cc: Mauro Cociglio , Massimo Nilo , "core@ietf.org" , Fabio Bulgarella Message-ID: References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> <5d3f81311cc64a31b3d96688cf1c379a@huawei.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K83Bttz9+CNW2KYQ" Content-Disposition: inline In-Reply-To: <5d3f81311cc64a31b3d96688cf1c379a@huawei.com> Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Wed, 10 Nov 2021 17:29:18 -0000 --K83Bttz9+CNW2KYQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Giuseppe, still sounds all very vague to me, but for that I'd guess I'll have to wait for an update with concrete usage examples. As proxy traversal has not falled out in the course of this discussion, let me come back to the question I had hoped wouldn't even need to be considered (if this would have all become hop-by-hop already): On the link from a proxy to servers, how would any of that information be useful? On that link, traffic from different clients would be mixed, so (eg. in the case of the square bit) there isn't a square wave left, but just square bits sampling into whichever client that request happens to come from. Conversely, on the link from the client to the proxy, communication may happen with different servers, so just looking at the bit pattern gernerated by a pair of addresses (client and proxy) would be insufficient just as well. (Unlike on the other link, here there *is* the information available, unless the client has an OSCORE context with the server, in which case it would likely not expose the PM options as they'd leak whether one or different servers are being used). So where are probes supposed to find useful information? On the proxy-server link I wouldn't understand how, and on the client-proxy link they'd have to parse the remainder of the message to understand which server this is aimed for. Is that the intention? BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --K83Bttz9+CNW2KYQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGMAV0ACgkQOY0REtOk veFLuQ/+JvuRGG8G4Yg8TF1QE2PWMcmuk4uglqtOO+SOP8V8qquXu72mRkYv/Y2+ uh2smAhjYde/lAcbETvBfd/fteboVMMg/HVzMF8/A5o7Lw+KFR4ac3iWGNARQXxK x78GxghX557sl2ey+naHlABNdzWyTfv4yslEXp9S9v2aB/ePNsH/U3n+i3K+bRhT EgsJPVxmQoHC+Pj6EbOx4GJIH5+wSphTPeIGaGjqp+rcfL22UWuOm5PY58iPeUvb oXKkReDF1f8gFrk3WGweNm5giy7Mmppo5fy6L7BW13S6K/MN7NwhxVEuxSJyZXfD sy+WccM3w+UDan9C2dQN4F33lfe64IWZ82iogXoztfauVoU0HVFREp0AbzGYr6kf /XIKq6sT0pvlMDL9o/1WLvVwvIaqX42pBBJQdkFs+qyWar06w8P9Pk0lGSPB0Dpn 3VhsU2Cbi+EQxlLc+sUB2ITLpxNFr3a3upHnhGX73oFGRDr2mkZwdQVmpFC40M6s tFbMXualuAUP/RQX35lubRLrkgxPztgu/lkmvoJ/FRWSwlXaCRX69ygmMTDyFK5k GWkMtKyQS8Nh7lMSZey+2JxADo++PUe0+rnOCyWoxpNXJDbOESl0SDCynt85DBkh SVDyf7IXNq58ljdXKDWM2jhwX/5n2dWbsts9j0CdKdfjZP2o3MA= =Fyfj -----END PGP SIGNATURE----- --K83Bttz9+CNW2KYQ-- From nobody Wed Nov 10 10:01: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 55F3A3A1280 for ; Wed, 10 Nov 2021 10:01:44 -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_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 OIfBsPtl1dAE for ; Wed, 10 Nov 2021 10:01:38 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9875A3A1278 for ; Wed, 10 Nov 2021 10:01:37 -0800 (PST) Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HqCHl359sz67NKf; Thu, 11 Nov 2021 01:57:55 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 10 Nov 2021 19:01:29 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.015; Wed, 10 Nov 2021 19:01:29 +0100 From: Giuseppe Fioccola To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: Mauro Cociglio , Massimo Nilo , "core@ietf.org" , "Fabio Bulgarella" Thread-Topic: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt Thread-Index: AQHXx17e3fh7XXlrQEuEwuZTp3pIr6vfMGlAgBkeEoCAAP+nsIACLA2AgAGcq/D///qQgIAAE1UA Date: Wed, 10 Nov 2021 18:01:29 +0000 Message-ID: <9383b4b8b19a4e32b37aa547936b4147@huawei.com> References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <33b733997e454534a7155b839b657a74@huawei.com> <5d3f81311cc64a31b3d96688cf1c379a@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.221.222] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-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: Wed, 10 Nov 2021 18:01:51 -0000 Hi Christian, My answers inline as [GF], Regards, Giuseppe -----Original Message----- From: Christian Ams=FCss =20 Sent: Wednesday, November 10, 2021 6:29 PM To: Giuseppe Fioccola Cc: Mauro Cociglio ; Massimo Nilo ; core@ietf.org; Fabio Bulgarella Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-= 00.txt Hello Giuseppe, still sounds all very vague to me, but for that I'd guess I'll have to wait= for an update with concrete usage examples. As proxy traversal has not falled out in the course of this discussion, let= me come back to the question I had hoped wouldn't even need to be consider= ed (if this would have all become hop-by-hop already): On the link from a proxy to servers, how would any of that information be u= seful? On that link, traffic from different clients would be mixed, so (eg.= in the case of the square bit) there isn't a square wave left, but just sq= uare bits sampling into whichever client that request happens to come from. [GF]: In this case, the proxy can still use the Option to set Spin Bit and = sQuare Bit for the bundle of clients. The measurement can be done but it is= an information related to a bundle of clients. An alternative can be to us= e the Option only for a single client at once in order to avoid to do a gro= uped measurement. Conversely, on the link from the client to the proxy, communication may hap= pen with different servers, so just looking at the bit pattern gernerated b= y a pair of addresses (client and proxy) would be insufficient just as well= . (Unlike on the other link, here there *is* the information available, unl= ess the client has an OSCORE context with the server, in which case it woul= d likely not expose the PM options as they'd leak whether one or different = servers are being used). [GF]: It is necessary to check the other fields to understand the server. So where are probes supposed to find useful information? On the proxy-serve= r link I wouldn't understand how, and on the client-proxy link they'd have = to parse the remainder of the message to understand which server this is ai= med for. Is that the intention? [GF]: As said, it is possible to manage this use case. It is also worth emp= hasizing that the first usage of this Option is to do end-to-end measuremen= t between the client and the server. The on-path measurement is the additio= nal feature. But, based on our discussion, it needs to be further explained= in the draft in order to consider the different e2e scenarios, the type of= proxy implemented and so on. BR c -- To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom From nobody Fri Nov 12 15:02: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 1136D3A08CC for ; Fri, 12 Nov 2021 15:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 6Ki9tv7BskIL for ; Fri, 12 Nov 2021 15:02:23 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6633A08D5 for ; Fri, 12 Nov 2021 15:02:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8503F18029 for ; Fri, 12 Nov 2021 18:04:27 -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 mH62FdgqmBiQ for ; Fri, 12 Nov 2021 18:04:24 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DD8E118023 for ; Fri, 12 Nov 2021 18:04:24 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF50140 for ; Fri, 12 Nov 2021 18:02:16 -0500 (EST) From: Michael Richardson To: core@ietf.org In-Reply-To: <304B093F-12D4-40BA-8922-DBFAFE4C17D6@akamai.com> References: <304B093F-12D4-40BA-8922-DBFAFE4C17D6@akamai.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] [Acme] get-as-post draft 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 Nov 2021 23:02:27 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Salz, Rich wrote: > The WG here might find this draft interesting: https://datatracker.ie= tf.org/doc/html/draft-ietf-httpbis-safe-method-w-body-02 > Abstract > This specification defines a new HTTP method, QUERY, as a safe, > idempotent request method that can carry request content. =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+93Q3WUFAmGO8ngACgkQgItw+93Q 3WVsAggAwmxEHvXxnW3MM4UQGGyBHuFEfT9A1QGf5LrMBqdhOWH4zsr7V3CStQpl ONTWr27yLuHinmW+JiB7qE7bD5FrfbjBM0XeCOzSGA30Hnkb9F+oWGbJFWHNFCGU iVQtT+c9SgbJaI4cRTjiyt2SNI92oR+Y3O6OpEVLgFZ7rAehesXx43segzD9Fu2p 9oisf1Z0sL7ZM2OrF4Rubm/ZFZ3+qbI+67jW9XECXBQ1vp3tJICsctSq8reGuFEV dDsHuud7/XRtUIXlW9vduWpEEg30GiDrIHqMdLoZUTNodnoXvpy7/I/mVPk5G2tv DzXxue9VZqmrP7xU09zX6wcwGtR3TQ== =2FTw -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 14 13:19: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 0AAAC3A0811; Sun, 14 Nov 2021 13:19:40 -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_H3=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 iD2AzMRCBkvD; Sun, 14 Nov 2021 13:19:35 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B706B3A0817; Sun, 14 Nov 2021 13:19:34 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HslZW2xGNz2xrl; Sun, 14 Nov 2021 22:19:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <0133A9EE-45A5-4240-85FC-60D30280F4B0@tzi.org> Date: Sun, 14 Nov 2021 22:19:31 +0100 Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org X-Mao-Original-Outgoing-Id: 658617570.970914-18301371293e26de891c1e9303dd06e0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162634134491.20957.9891384677904460366@ietfa.amsl.com> <0133A9EE-45A5-4240-85FC-60D30280F4B0@tzi.org> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (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: Sun, 14 Nov 2021 21:19:40 -0000 Hi Zahed, just checking whether you got the below (I=E2=80=99m sometimes having = problems reaching ericsson.com mail addresses). Gr=C3=BC=C3=9Fe, Carsten > On 2021-10-29, at 20:45, Carsten Bormann wrote: >=20 > [Duplicate copy because of mail weirdness:] >=20 > Hi Zahed, >=20 > it took us a while to process the DISCUSS positions and COMMENTS on = core-sid. > We didn=E2=80=99t quite finish before the I-D deadline, but did submit = a -17. > Link to diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-sid-17.txt >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >>=20 >> This should be very easy to resolve and I want to make sure that we = understand >> the situation here better - >>=20 >> *Section 3 : says - >>=20 >> "The creation of this new version of the ".sid" file >> SHOULD be performed using an automated tool" >>=20 >> If this is supposed to be the automation process written in appendix = B then >> putting a reference here makes sense. If not, then as this is very = important >> tool, more information need to be added here in this specification = (like, >> where to find it, who create and maintains it, any reference to such = an >> existing tools). Also I am missing what consequences one need to = consider if >> the process is not automated. If this is same as written in the = introduction - >>=20 >> "Assignment of SIDs to YANG items can be automated. For more details >> how this can be achieved, please consult Appendix B." >>=20 >> Then we have two kind of instructions for the same thing - "can be" = and a >> normative "SHOULD". Hence it need to be clarified which one should = prevail. >=20 > Indeed. We have converged on SHOULD. -17 says: >=20 > (Intro:) > Assignment of SIDs to YANG items SHOULD be automated. For more > details how this can be achieved, and when manual interventions may > be appropriate, see Appendix B. > [=E2=80=A6] > At the time of writing, a tool for automated SID file generation is > available as part of the open-source project PYANG [PYANG]. >=20 > (Informative References:) > [PYANG] Bjorklund, M., "An extensible YANG validator and converter > in python", . >=20 > (Appendix B:) > Assignment of SIDs to YANG items SHOULD be automated. The > recommended process to assign SIDs is as follows: [=E2=80=A6] >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Thanks for the efforts in this document. >>=20 >> * I support Robert Wilton's Discuss and Benjamin Kaduk's discuss no.2 >=20 > We will address these in separate emails. >=20 >> One more clarification comment - >>=20 >> * Section 7.5.2: says - >>=20 >> " The >> maximum SID range size is 1000. A larger size may be requested by >> the authors if this recommendation is considered insufficient. It is >> important to note that an additional SID range can be allocated to an >> existing YANG module if the initial range is exhausted." >>=20 >> I have hard time understanding the mentioning of the maximum SID = range here. >> does this mean this document sets the maximum range to 1000 but = others can >> have more? please clarify. >=20 > This text was indeed a bit clumsy. > It now says: >=20 > The > SID range size SHOULD NOT exceed 1000; a larger size may be requested > by the authors if this recommendation is considered insufficient. It > is important to note that an additional SID range can be allocated to > an existing YANG module if the initial range is exhausted; this then > just leads to slightly less efficient representation. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Nov 15 02:22: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 B4E9B3A08CE; Mon, 15 Nov 2021 02:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 8ujohDEgjm4J; Mon, 15 Nov 2021 02:22:18 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2055.outbound.protection.outlook.com [40.107.20.55]) (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 893033A08AE; Mon, 15 Nov 2021 02:22:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FsjdfuAMj1j0Gf2oB+8+fwVVm6BfWUgQv2Sj48YDJs5iPO9iF0IHDO8hbshwA0rOfkaCa6oPXgv4WV8Zo3UM+ZJsBfybkCkTOnIlTOkK+HLYZqhOMm4JsR54RsKrK0uhrKJa5oCIzQf6J+iLuyKLLdYloTQjUPorsKlxQadaOaz1Zn6ZCS1f7qKEp8jYnQ4oG+OC2utfYTBQ9OYTHTOaFXn0wFkHVs2Ejpj/75USuz+Kint5aqUlLvrWrs6ucYujxsrEG416YsnDUGk19SCz1RX6i3GPy4oPmFEv5vKhj6WCk6+rlBz9YnQKLP7axL5EL2dlOVR5pwTtwHAowxUxkQ== 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=MCCYXwRcEH7QZZSN3NNmlJF29dXSrZg6bNpoLxj02QM=; b=HfLvqDyMYBiPJwPCiGZVYplCRYTHIGBqCUSF6fcYRTTE/OT7TE9pQaHoTzst711n60FKI0Uckgy5BgTklofsHSIbth1ypdRu1NSg1W1sHaVuf+2bpXN/SD5LuxC3mAIpCsVGxKGnnnVBvo7cbMP76+PEnGu+WQjR/yW2SQStxJr68babTkhbEbsay1LdrJo1Qs4sKPj9pCTLEOGFuVTuzA7CXG5idSkA5nlAZcf0F4z/2Qw3sORhDNQnJJsmXqgSx2sPFWMluvPAO9s+XrpFqb8gnIyvEHiz5Khy9oSN1jT/tw24kkvcHfI7v/d9kUC/yFQ7xLU6RPD0WgM2gbAf3A== 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=MCCYXwRcEH7QZZSN3NNmlJF29dXSrZg6bNpoLxj02QM=; b=Qss9HI1C/y1CjhVPm1Nlh1YytRV4a7Z2P5GOurAWCxh+XJ2Yg2YU91yuetwrKvlngBHLG6pkQ0v7wgiS8fSaubVqOI5cV6bxSlEb3bn4sgD4/5i6NQN26h1pCe8gFZzC0ywjsvA4xsp9B6ak4+PxPIGh4ghH6I1x5EeZpZsscro= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR0701MB2218.eurprd07.prod.outlook.com (2603:10a6:3:20::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.14; Mon, 15 Nov 2021 10:22:14 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9458:17fc:2f2f:70e7]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9458:17fc:2f2f:70e7%6]) with mapi id 15.20.4713.019; Mon, 15 Nov 2021 10:22:14 +0000 From: Zaheduzzaman Sarker To: Carsten Bormann CC: "draft-ietf-core-sid@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" Thread-Topic: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) Thread-Index: AQHXeVvjUF8GoC5m/Ei0K30WppPo/qvq928AgBlQeYCAAOtzgA== Date: Mon, 15 Nov 2021 10:22:14 +0000 Message-ID: References: <162634134491.20957.9891384677904460366@ietfa.amsl.com> <0133A9EE-45A5-4240-85FC-60D30280F4B0@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9cf56bb0-352a-4e15-0731-08d9a821cb0e x-ms-traffictypediagnostic: HE1PR0701MB2218: x-microsoft-antispam-prvs: 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: TwpcT5CZVs9rL1HWEiiRU/8SM1LZquTXdEYnvQ8luyRLhbgNldPzCKsU1gEG3z6rnW/QoAIz7l6H6spd+XHL/JamkJC61wOd8gnJN7e4OoGyIaYHwQlYeVUIQH8QBNOS+FwAdoZRnyGV3IpoC3pPjS535/jMIFpKYwlCTK12Xh0LCA8bBuyVkmm2/Fc+CwtlOkHfBVPeq8FYprUFtTierm2FD9L2/Cj4QK84DdyNkLjFOPhtVQt00X+JCdqnL9jTx+yzIdRwlr3tp8wHjRY7GEqLhgf+P7K9H89h3KSzFOgR5A4lPrPbrnqvO5bFlxCc6WaXqKqReEDivOGnlh3+67Otx+MwVQZwnJtpimsDwCDBJ8C7fWbmJUxCadud0DtDhkxl7zv4Xb33YwJijH9bEDHKoKhganZVnq+kcjEE0QracPDGC1YL/XEuiSR3eitanDqDVXEMq1DCB+x3kGYVbJB4fXnRISi+OWJtzt1gXF25EADDgUcrv+FAH1ZherTMJ77F4WtMDcUlzxB43P0lX6xIMdmLmLwNr1Y+UmUtVPDK8HDjoN0T7hwYVYJyVcQzaa0AbV6lm8W5ufFTtMHX1R1liEg+/JB+wOEzk2yFQjD/9KwOme4nXk6NFSijy+9F/uYTbEOK4RzFnw36aEyJfa945So+X/6ipT7QJPnvlr81/PvmYTQZO2nfIPwycUpxX5IqZEKDpTh9hRlx/JAXMmXG6V7281CH2P9ZduT1JqrNVx5IwNbxzgYT7eGtvQEpdQVPYjSUFUoSALym5jiAJlZwx9VGGYBgElISXsi8LCmUG/uWBXPtY3pEVvGHhHdXIT3bnTJOL0hDScBRtX9Odqpi41MGM4lodkAaWLJqo0c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(44832011)(71200400001)(76116006)(2616005)(2906002)(316002)(6916009)(4326008)(83380400001)(38100700002)(54906003)(5660300002)(26005)(122000001)(8676002)(6512007)(966005)(4001150100001)(86362001)(66476007)(33656002)(186003)(508600001)(66556008)(64756008)(8936002)(66446008)(66946007)(36756003)(38070700005)(91956017)(53546011)(6486002)(82960400001)(6506007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aitQYjYwSHQ0d0s5L3FVdjBEY1RFdmd2dHRVQkdPd0pvSUFOa1ltUVFiWUtU?= =?utf-8?B?SzRmOHRFZ3pRUUJ0ZDRCdDZhYVhjWVoybGpPVERCUG9kMEtGUGpvTlJ4dFVu?= =?utf-8?B?VDFaZUpLamdFQkVsS0pDaDlGcEs3WkxzWEZPZ3JKLzdVMk5FNi9xOWd3ZUdR?= =?utf-8?B?QWxYbTBOR0pzdkxpeGVFUmNXTDFaZGMvMFcvWkJmdGgrSkpDNHpXMGZYUTBH?= =?utf-8?B?WEwxaHZpRGhUT1l0OWgwb21WbVpvZENiRks5ckVFOXNSS0piZkpJMDRPZGZE?= =?utf-8?B?ZW9rUHpObGh4SEN2L1pETG1xRytSZlNvOUtXYXE1aTJ2ellmVmRGTWthK1c2?= =?utf-8?B?cEdFMndwWnNGUG1vakxXclM2dktJQkM3SG5qeEpyOEpCQzZlZlRGcHVhRDRh?= =?utf-8?B?UnJKNGdWSkNkM3JSTDdTMHkrZXhRZjV4S3NnV0t6anNDcFhFaWxDUEI3SDZN?= =?utf-8?B?WEJDck1aNGNGUDc5T1Q3YWtua0dRdnJQbjFGWDQ4UGhQM3UxbHVYL2wxcTFO?= =?utf-8?B?eCtzTGw2bUpEa2syaDFIc2REdTlKbURjcUVhSFhlZ2NCdnFsUlBFYWRxelVu?= =?utf-8?B?Nk9oUjBIZWc1b28wQlllRDlkdHQ0VWZ4T3ltS2lvZXcwbHdHa2JONUpOOGw0?= =?utf-8?B?RHN3aVkxUGQyV2tZa3ZlZTZ3bkp5NC9URzlqM08wRCtya1NweUVHa0haL3k0?= =?utf-8?B?aGtrQzZEeEgzWGpoaWExckpoYkQ2Zjdob3hOWlNnS01NZ0grbWZBbU9wUEU3?= =?utf-8?B?UnZ0NmJiMGEwR0FwUW1xS3AyMUlsVlg4L1lNK1ZZVm52NUJobE1NbEs5NnYv?= =?utf-8?B?ajJzMUVBM3c4eHNFNUtvSnh0QW4vVGdQRmw0WnRQMisxd0c1MTJYZXpuam5x?= =?utf-8?B?QlN0UnhtN3pFcldnNm9kNVhTNGJ1OEhadzRyK1ZxbFMrU2RtMXBWaUh1bFIy?= =?utf-8?B?UTE3R0xYRnRLMk5UeXM4WlgzcFpDNUhtckJHNHlHc3pRM0ZRQTlPWXg1NTJK?= =?utf-8?B?WWk1TkxyMXRJRjhSRGRJbHcxNk8rK3E1M3J6N3VSLzBVNzdIVDZudms5eHVB?= =?utf-8?B?UG5VKzRwVEF0VlF4WXFGblZzV2JBZzEzNzRTM3hNdGhmcExtbExKS05Tb1Js?= =?utf-8?B?MVk1WlBPcDJoM3l2V0RWS21jRmt1OUZzNFVxdXpSTnY1cXg5cFRvcFhGaE5K?= =?utf-8?B?WWFPQzQ5ZkpKNENFdUhyU3lVYmNuLzZoeHFKWkQ3d2VhZkthMlRJQlVWUFFs?= =?utf-8?B?ZUJuQzhBcmRraXNiMTNkZXFBc3A4WXZURG8rRUxocjd6cDZVaS9qWlRxVkpt?= =?utf-8?B?ejFNZjl5bWtKc01waTRhdXlmbWdsN3l6YTVSZ3Q4TnV5Lys2K0dtZVc4aDln?= =?utf-8?B?NlU4M3JveDJqcjhtQy9PUHlzRnRJUHZaQmltMWxGdHZUUVhheXBPZklPSEFL?= =?utf-8?B?RFVTYkJQb2tMTXRrMEJIbXpaVGt6UVc3UjRNbmk0WVZNMThESmRHZnpTT2FR?= =?utf-8?B?NVVnNmFrWWFrNGtSby9lZFE3aENaa1oxNHFjTms3QmpycEhUTWY3b2R1SjhT?= =?utf-8?B?K05SVlhqTEcrSEdSV3RCMVNseDJyVUNvdkx1UURTL3pudTNJRVJjV1NJRXc5?= =?utf-8?B?MVFCTGYrWkFLK3VIeWdPODNzYlR3TDM2WkZ2dWlSSWNQU0JZaWttTytuZ3ZX?= =?utf-8?B?RmpOVmV0TjF0ZGpqM3ZuYmlyQ2Z3U0p4KzJucW16eU9SU3ZNVWNQWnZ5V1NO?= =?utf-8?B?SWRuVG1wS0lFM1orUEk5NGhIQjV2RUdDOWZpWFh5VHRwOWFPTlV3RHpGNElG?= =?utf-8?B?R1FSVEZUQ1NNSVRPMzcrVUtUcHZ1VUY4M08xZmFxMlhtNEt6UEtFZjNTRWhx?= =?utf-8?B?ZncvditHUnZBRXFtUTZ4c29GaUJ5NWFtcTd3S1BQTWZqUVpBZnV2MC9kTXFt?= =?utf-8?B?MTRMU2xmTlZyWUtxTUVOYVQ2eG5pKzkyMnRobldudDFlUEIxcHg0R1NtMjJY?= =?utf-8?B?blpXT2VYQjFKNjYvVlh4MnpSZW5KYndacEFOeUo2SHFtRHByNXVSeDA0c0Mz?= =?utf-8?B?RWpuWHZ0bStYRld2TkIyMlB5d0d3Sk95cks4eGh0d2FUUThyNDZ2eUo3QStv?= =?utf-8?B?YWVIdmtoTkpINnpPenF4WjdlYmk5RURlcURIWk81dm11VERKVG5ObjdYWVN6?= =?utf-8?B?UHl6OEYwM1F0czRRU0pQWFBxRUVNR1lWcUFSSmNzQ3liYVBDT2l5YTFoWFpS?= =?utf-8?B?N1dNM1dhYlpuMVRtQ2VacFdtV2Y4b3o4YzhaVmxHMTAyalJITTJGSTk4d3pB?= =?utf-8?B?R3VDOWJSZWdZVlZnKy9ETy9HYUVqZ212NWtKNU42eUY4Kzl0ZmpQdz09?= Content-Type: text/plain; charset="utf-8" Content-ID: <18DF58B00FB2DC468632F291F8597B23@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: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf56bb0-352a-4e15-0731-08d9a821cb0e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2021 10:22:14.2527 (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: TsOqRrijSLRpm3ax7InP8lVdo3mZi4nidAhuoWCIBQ1mU4rBAhnlBRs2wKtGegq4bnFNMk1Zha5Q6/dn/L+fORKIZwCQt3jayRKVgMcR2aYH4FkBEu1mDJXwGbpXNw/6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2218 Archived-At: Subject: Re: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (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, 15 Nov 2021 10:22:22 -0000 VGhhbmtzIGZvciB0aGUgUGluZyBDYXJzdGVuLiBJbmRlZWQgdGhlcmUgd2FzIHNvbWUgaXNzdWVz IHdpdGggZW1haWwuLi4uDQoNCkkgdGhpbmsgdGhlIGFtZW5kbWVudCBpbiAtMTcgYWRkcmVzc2Vk IG15IERJU0NVU1MgY29tbWVudHMsIGhlbmNlIEkgd2lsbCBjbGVhciBpdC4NCg0KVGhhbmtzIGZv ciBhZGRyZXNzaW5nIHRoaXMuDQoNCkZvciBSb2JlcnQgV2lsdG9uJ3MgRGlzY3VzcyBhbmQgQmVu amFtaW4gS2FkdWsncyBkaXNjdXNzIG5vLjIsIGFzIEkgc3VwcG9ydGVkIHRoZW0sIEkgd2lsbCB3 YXRjaCBmb3IgdGhlIHJlc29sdXRpb24gYW5kIHBlcmhhcHMgcmVjb25maXJtIG15IHBvc2l0aW9u IHRoZXJlIGlmIG5lZWRlZC4gDQoNCkJSDQpaYWhlZA0KDQoNCg0K77u/T24gMjAyMS0xMS0xNCwg MjI6MTksICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KDQogICAgSGkg WmFoZWQsDQoNCiAgICBqdXN0IGNoZWNraW5nIHdoZXRoZXIgeW91IGdvdCB0aGUgYmVsb3cgKEni gJltIHNvbWV0aW1lcyBoYXZpbmcgcHJvYmxlbXMgcmVhY2hpbmcgZXJpY3Nzb24uY29tIG1haWwg YWRkcmVzc2VzKS4NCg0KICAgIEdyw7zDn2UsIENhcnN0ZW4NCg0KDQogICAgPiBPbiAyMDIxLTEw LTI5LCBhdCAyMDo0NSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KICAg ID4gDQogICAgPiBbRHVwbGljYXRlIGNvcHkgYmVjYXVzZSBvZiBtYWlsIHdlaXJkbmVzczpdDQog ICAgPiANCiAgICA+IEhpIFphaGVkLA0KICAgID4gDQogICAgPiBpdCB0b29rIHVzIGEgd2hpbGUg dG8gcHJvY2VzcyB0aGUgRElTQ1VTUyBwb3NpdGlvbnMgYW5kIENPTU1FTlRTIG9uIGNvcmUtc2lk Lg0KICAgID4gV2UgZGlkbuKAmXQgcXVpdGUgZmluaXNoIGJlZm9yZSB0aGUgSS1EIGRlYWRsaW5l LCBidXQgZGlkIHN1Ym1pdCBhIC0xNy4NCiAgICA+IExpbmsgdG8gZGlmZjoNCiAgICA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtc2lkLTE3LnR4dA0K ICAgID4gDQogICAgPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4+IERJU0NVU1M6DQogICAgPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KICAgID4+IA0KICAgID4+IA0KICAgID4+IFRoaXMgc2hvdWxkIGJlIHZlcnkg ZWFzeSB0byByZXNvbHZlIGFuZCBJIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgd2UgdW5kZXJzdGFu ZA0KICAgID4+IHRoZSBzaXR1YXRpb24gaGVyZSBiZXR0ZXIgLQ0KICAgID4+IA0KICAgID4+ICpT ZWN0aW9uIDMgOiBzYXlzIC0NCiAgICA+PiANCiAgICA+PiAiVGhlIGNyZWF0aW9uIG9mIHRoaXMg bmV3IHZlcnNpb24gb2YgdGhlICIuc2lkIiBmaWxlDQogICAgPj4gU0hPVUxEIGJlIHBlcmZvcm1l ZCB1c2luZyBhbiBhdXRvbWF0ZWQgdG9vbCINCiAgICA+PiANCiAgICA+PiBJZiB0aGlzIGlzIHN1 cHBvc2VkIHRvIGJlIHRoZSBhdXRvbWF0aW9uIHByb2Nlc3Mgd3JpdHRlbiBpbiBhcHBlbmRpeCBC IHRoZW4NCiAgICA+PiBwdXR0aW5nIGEgcmVmZXJlbmNlIGhlcmUgbWFrZXMgc2Vuc2UuIElmIG5v dCwgdGhlbiBhcyB0aGlzIGlzIHZlcnkgaW1wb3J0YW50DQogICAgPj4gdG9vbCwgbW9yZSBpbmZv cm1hdGlvbiBuZWVkIHRvIGJlIGFkZGVkIGhlcmUgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIChsaWtl LA0KICAgID4+IHdoZXJlIHRvIGZpbmQgaXQsIHdobyBjcmVhdGUgYW5kIG1haW50YWlucyBpdCwg YW55IHJlZmVyZW5jZSB0byBzdWNoIGFuDQogICAgPj4gZXhpc3RpbmcgdG9vbHMpLiBBbHNvIEkg YW0gbWlzc2luZyB3aGF0IGNvbnNlcXVlbmNlcyBvbmUgbmVlZCB0byBjb25zaWRlciBpZg0KICAg ID4+IHRoZSBwcm9jZXNzIGlzIG5vdCBhdXRvbWF0ZWQuIElmIHRoaXMgaXMgc2FtZSBhcyB3cml0 dGVuIGluIHRoZSBpbnRyb2R1Y3Rpb24gLQ0KICAgID4+IA0KICAgID4+ICJBc3NpZ25tZW50IG9m IFNJRHMgdG8gWUFORyBpdGVtcyBjYW4gYmUgYXV0b21hdGVkLiAgRm9yIG1vcmUgZGV0YWlscw0K ICAgID4+IGhvdyB0aGlzIGNhbiBiZSBhY2hpZXZlZCwgcGxlYXNlIGNvbnN1bHQgQXBwZW5kaXgg Qi4iDQogICAgPj4gDQogICAgPj4gVGhlbiB3ZSBoYXZlIHR3byBraW5kIG9mIGluc3RydWN0aW9u cyBmb3IgdGhlIHNhbWUgdGhpbmcgLSAiY2FuIGJlIiBhbmQgYQ0KICAgID4+IG5vcm1hdGl2ZSAi U0hPVUxEIi4gSGVuY2UgaXQgbmVlZCB0byBiZSBjbGFyaWZpZWQgd2hpY2ggb25lIHNob3VsZCBw cmV2YWlsLg0KICAgID4gDQogICAgPiBJbmRlZWQuICBXZSBoYXZlIGNvbnZlcmdlZCBvbiBTSE9V TEQuICAtMTcgc2F5czoNCiAgICA+IA0KICAgID4gKEludHJvOikNCiAgICA+IEFzc2lnbm1lbnQg b2YgU0lEcyB0byBZQU5HIGl0ZW1zIFNIT1VMRCBiZSBhdXRvbWF0ZWQuICBGb3IgbW9yZQ0KICAg ID4gZGV0YWlscyBob3cgdGhpcyBjYW4gYmUgYWNoaWV2ZWQsIGFuZCB3aGVuIG1hbnVhbCBpbnRl cnZlbnRpb25zIG1heQ0KICAgID4gYmUgYXBwcm9wcmlhdGUsIHNlZSBBcHBlbmRpeCBCLg0KICAg ID4gW+KApl0NCiAgICA+IEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIGEgdG9vbCBmb3IgYXV0b21h dGVkIFNJRCBmaWxlIGdlbmVyYXRpb24gaXMNCiAgICA+IGF2YWlsYWJsZSBhcyBwYXJ0IG9mIHRo ZSBvcGVuLXNvdXJjZSBwcm9qZWN0IFBZQU5HIFtQWUFOR10uDQogICAgPiANCiAgICA+IChJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzOikNCiAgICA+IFtQWUFOR10gICAgQmpvcmtsdW5kLCBNLiwgIkFu IGV4dGVuc2libGUgWUFORyB2YWxpZGF0b3IgYW5kIGNvbnZlcnRlcg0KICAgID4gICAgICAgICAg ICBpbiBweXRob24iLCA8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az02N2Yx YTlmYi0zODZhOTEyOS02N2YxZTk2MC04NjYxMzJmZTQ0NWUtZDM1ZTk5MDUyMThhMTVmOSZxPTEm ZT1mOGE2N2MyZi1lZjJhLTQ2MzYtYjdjNi1mOWJmMzNhNTFlYjAmdT1odHRwcyUzQSUyRiUyRmdp dGh1Yi5jb20lMkZtYmo0NjY4JTJGcHlhbmc+Lg0KICAgID4gDQogICAgPiAoQXBwZW5kaXggQjop DQogICAgPiBBc3NpZ25tZW50IG9mIFNJRHMgdG8gWUFORyBpdGVtcyBTSE9VTEQgYmUgYXV0b21h dGVkLiAgVGhlDQogICAgPiByZWNvbW1lbmRlZCBwcm9jZXNzIHRvIGFzc2lnbiBTSURzIGlzIGFz IGZvbGxvd3M6IFvigKZdDQogICAgPiANCiAgICA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4gQ09N TUVOVDoNCiAgICA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4gDQogICAgPj4gVGhhbmtzIGZvciB0 aGUgZWZmb3J0cyBpbiB0aGlzIGRvY3VtZW50Lg0KICAgID4+IA0KICAgID4+ICogSSBzdXBwb3J0 IFJvYmVydCBXaWx0b24ncyBEaXNjdXNzIGFuZCBCZW5qYW1pbiBLYWR1aydzIGRpc2N1c3Mgbm8u Mg0KICAgID4gDQogICAgPiBXZSB3aWxsIGFkZHJlc3MgdGhlc2UgaW4gc2VwYXJhdGUgZW1haWxz Lg0KICAgID4gDQogICAgPj4gT25lIG1vcmUgY2xhcmlmaWNhdGlvbiBjb21tZW50IC0NCiAgICA+ PiANCiAgICA+PiAqIFNlY3Rpb24gNy41LjI6IHNheXMgLQ0KICAgID4+IA0KICAgID4+ICIgIFRo ZQ0KICAgID4+IG1heGltdW0gU0lEIHJhbmdlIHNpemUgaXMgMTAwMC4gIEEgbGFyZ2VyIHNpemUg bWF5IGJlIHJlcXVlc3RlZCBieQ0KICAgID4+IHRoZSBhdXRob3JzIGlmIHRoaXMgcmVjb21tZW5k YXRpb24gaXMgY29uc2lkZXJlZCBpbnN1ZmZpY2llbnQuICBJdCBpcw0KICAgID4+IGltcG9ydGFu dCB0byBub3RlIHRoYXQgYW4gYWRkaXRpb25hbCBTSUQgcmFuZ2UgY2FuIGJlIGFsbG9jYXRlZCB0 byBhbg0KICAgID4+IGV4aXN0aW5nIFlBTkcgbW9kdWxlIGlmIHRoZSBpbml0aWFsIHJhbmdlIGlz IGV4aGF1c3RlZC4iDQogICAgPj4gDQogICAgPj4gSSBoYXZlIGhhcmQgdGltZSB1bmRlcnN0YW5k aW5nIHRoZSBtZW50aW9uaW5nIG9mIHRoZSBtYXhpbXVtIFNJRCByYW5nZSBoZXJlLg0KICAgID4+ IGRvZXMgdGhpcyBtZWFuIHRoaXMgZG9jdW1lbnQgc2V0cyB0aGUgbWF4aW11bSByYW5nZSB0byAx MDAwIGJ1dCBvdGhlcnMgY2FuDQogICAgPj4gaGF2ZSBtb3JlPyBwbGVhc2UgY2xhcmlmeS4NCiAg ICA+IA0KICAgID4gVGhpcyB0ZXh0IHdhcyBpbmRlZWQgYSBiaXQgY2x1bXN5Lg0KICAgID4gSXQg bm93IHNheXM6DQogICAgPiANCiAgICA+IFRoZQ0KICAgID4gU0lEIHJhbmdlIHNpemUgU0hPVUxE IE5PVCBleGNlZWQgMTAwMDsgYSBsYXJnZXIgc2l6ZSBtYXkgYmUgcmVxdWVzdGVkDQogICAgPiBi eSB0aGUgYXV0aG9ycyBpZiB0aGlzIHJlY29tbWVuZGF0aW9uIGlzIGNvbnNpZGVyZWQgaW5zdWZm aWNpZW50LiAgSXQNCiAgICA+IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgYW4gYWRkaXRpb25h bCBTSUQgcmFuZ2UgY2FuIGJlIGFsbG9jYXRlZCB0bw0KICAgID4gYW4gZXhpc3RpbmcgWUFORyBt b2R1bGUgaWYgdGhlIGluaXRpYWwgcmFuZ2UgaXMgZXhoYXVzdGVkOyB0aGlzIHRoZW4NCiAgICA+ IGp1c3QgbGVhZHMgdG8gc2xpZ2h0bHkgbGVzcyBlZmZpY2llbnQgcmVwcmVzZW50YXRpb24uDQog ICAgPiANCiAgICA+IEdyw7zDn2UsIENhcnN0ZW4NCiAgICA+IA0KICAgID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IGNvcmUgbWFpbGluZyBs aXN0DQogICAgPiBjb3JlQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUNCg0K From nobody Mon Nov 15 02:22: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 68D653A0811 for ; Mon, 15 Nov 2021 02:22:56 -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, DKIMWL_WL_HIGH=-0.701, 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] 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 k0S6urwLH4ce for ; Mon, 15 Nov 2021 02:22:51 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on061d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::61d]) (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 655143A08AE for ; Mon, 15 Nov 2021 02:22:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AiGPgo10/BvDmN/v129PbEtOQ9+eAVQkpPhPVQKsElOEcIIJxlKxQkEDyj6bk5iha7QlNx0flTlcsOmjBqVPMPYfgQjoi/XvWpw8NsCPj3D1qtCjQKq7mXTqMWApnV+JRdFWTfZCznMnHGnduxkNqUzQUWY0ecZ6mOmJZp4FTA1ItEmgeZw9iWyx0OJ42F79s2m/Kn0NteMpRKYTQUjYCZ8l+xJ81gb1y5QtEW0qbkn9podEZHpdGfMn8cuWeUjVeIqJ2IA9Q4BXcbP9aOsPSGskYCV4Xy/TVP0dIVmNMP31NYabCkxCLIg+LjvzOUIxYY6B4ZMP49BCw4utlIG6cw== 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=3ksDYX4YjRxCbeYLmNlllYql6vjV4UHRkQ2lHICgBSc=; b=TvyUYN+V1MgIt1lHOh6HUqHHy0nbYoKONGtzYJDfU2b1h5g9OxJsYHmX/R5C7zd5I2E1AuS4aiSqxkgcfTsUWs5EhCuDfMioC/ju16RCYR7DDEprSvXe7GOu/wFIEAYB0tH1//3HCTVyPQYw3w0lW+qgifSG1lb/i7jPbzCsbb47koHLdUJc70U/hpaGQIXHX/1COhSso0JV6cX21bbaSkQ96EONsd9o4awG3zx2H+aJEaKP/1X1joSMbXXGwBiRymG4U76Clp9ZuYZcd1u+uhD09eS5gXKWdz8TzV9dbBmkHO0rXwSBZVFG5i/PyyA+LP5um1vn45t5z46+r59e5Q== 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=3ksDYX4YjRxCbeYLmNlllYql6vjV4UHRkQ2lHICgBSc=; b=mtnzawgQ14OCYiEY4J6Y3STQ5fgXRiqyXXQqeFQxpeTVEgezyhKo8y/cH6dzZAZTPc1M1KkcJq/KMB/eTOU7JR9xnkvUewrQtUyG1TsIFDn6vvE9dQ9uDFESm7sxyqq3VDAQzbiREkBQzPo7uSQu1MME5Uvvrri54mJo8wF9VRM= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2778.eurprd07.prod.outlook.com (2603:10a6:3:98::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.8; Mon, 15 Nov 2021 10:22:46 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::acd7:51e8:bdfe:c133]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::acd7:51e8:bdfe:c133%7]) with mapi id 15.20.4713.018; Mon, 15 Nov 2021 10:22:46 +0000 From: John Mattsson To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= CC: "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIENvbmZpcm1pbmcgYWRvcHRpb24gb2YgZHJhZnQtaG9l?= =?utf-8?B?Z2x1bmQtY29yZS1vc2NvcmUta2V5LWxpbWl0cy0wMiBhcyBhIENvUkUgV0cg?= =?utf-8?Q?document?= Thread-Index: AQHX1YZkXnChFe1lSkKHNl8MwUUHRKwEZ/Q0 Date: Mon, 15 Nov 2021 10:22:46 +0000 Message-ID: References: <97d7f098-ff89-4dae-a9dd-be09225553aa@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f1ea95e-5805-49e2-c434-08d9a821de28 x-ms-traffictypediagnostic: HE1PR0701MB2778: x-microsoft-antispam-prvs: 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: qnuGXHpTGdYj0nNlw9jsmE/xe06DXCvrfXGth9LqBKpR3tX7NonRLRH3GuiAkBidSa0PXNuTSeZqOztbDo7GW+j4Lzf/ypOMG2NIU1SvBK6zLnojR3D/gceEPe9qhDgSgElODB0ZvGW93i6mR8FN1iVeiOKZWU+PiQOZQFxBhQpSyVNO3SuLQ5jUPy2eTucmowldEdRKmwstAa/FBkKmLsgiKms/GgncrU8hV/z5QeskDZuIX3tndAA8a3wzUT8AqC5nex2PIVcsajj5K9wIj460pKbl9wGg170+t3Is7i7fbtfmWMuGDcy2LbpoEiuSNUUcJcrOXvMnYdd2wIBj1Yd2UzQU3zJNLo5eDS7CJXgbWIZ/0/zGNJlwhKn9IvxhNQp5OYjAxhh2vmBB/HKZFqWSWqgTaPaAgH+1buair2j00GwTWFWhEDAHJ/5ouyNXJuoVcxNigQcXqSQ79JvBA2juFomkAqY08IYohukOYSKSQoflgqgb4cDplvel5msodXsuIiolOwFGNMzD9/r5XgAd0II6HYHMjxAa/wqfoj1k5MQn/3BW0/hTI/kcyU9tj8qjR1xcpHREJV3n0ln/kwzlGqB6BTElC9GcHNfNgurt029+CGtTZ9VFIbiDM3YphLZL2ATNaV8jGw6YJw0fXYJkQakQYvqC/0cTg4AGNq47u6lWXNqJotI4q6gko7G599dcrk1y3iqGhxlv5YwoU0q4IOdlpEhaH19vdyGsv/pv5M9SWsc4QFTGADZbUviArL8yUFEktigUBbI+9xdW73K28By/lP3ZRkDr6ve/YiK6Ima/IcjLVg+6BHPVnSXYgUzyJtUrSEnhDkRL1O9Rug== 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)(366004)(91956017)(33656002)(9686003)(53546011)(66476007)(66446008)(6506007)(86362001)(66946007)(71200400001)(83380400001)(4326008)(966005)(7696005)(66574015)(110136005)(82960400001)(38100700002)(44832011)(122000001)(508600001)(38070700005)(52536014)(5660300002)(55016002)(316002)(66556008)(186003)(64756008)(2906002)(8936002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ekRVWVZSWjAzNUxOeThTdElmaTIwanBTYlVUQ0NOUXVZOHE3Smk0WVFQTzBu?= =?utf-8?B?Tkc1NFU5cFhxdUVZNmExaUN0WklpUUQ0bXBYOTEvc0w1VW9sVDN6eXpmSUdR?= =?utf-8?B?MVI3SlUzV0NYRkk1WWV6VUM2bWFHb2JKR0lFMHQyaG5zMStMaXNzRVMxc2Uw?= =?utf-8?B?bythQVo0K3JMY2F3Q1hrTDV3Z2dOaEVEWUxyaVdyakNzTXk2MWhMbTlWOHlI?= =?utf-8?B?UW02UW1oN0FCSVl5Mys3dlRSc3BOSW54ZGRFZjhtMnQxQ0p3K091dG5zYStu?= =?utf-8?B?Q3JoZGhoV1FUVnVqeVJodE13N3J3TForSVhDZ05uRFNLazlZZXFSMGJsS09o?= =?utf-8?B?c3pqY2ZDMVhjT0IwcmdXbnVMb01GMS9iaGFmc0RueGcwaXp1SEVuL1JrbDd6?= =?utf-8?B?NHBkYXVIemd1bDBubVBIUWk1UE4wVXhwcnpNK1E5c0VUN0V6Z0swKyt4cHVh?= =?utf-8?B?dUZSWGlyNmRyc3BMME8wTnNER1hiZVJLUmRPRTcxMVV6VEdBeFZ4Qm9GaER5?= =?utf-8?B?dUp4NmJvSkg5eWhjZWJKa2RpYWhydWp6OTcwL0U1cmM2WXRuSE4yN0NJaE53?= =?utf-8?B?YktFcU15ZHNHZWlMcSs4akRpRGxhb0RlUU9sclFCTTVZS0xZekxBZHhzeHF4?= =?utf-8?B?QmF1Qk1PVVJYZUNJUXlZNHZackc2QUsxbVZBUDhmVEFrQmV5UHc3TDF2ZS8z?= =?utf-8?B?UEhyK0JtQk1HSlZKY2ptQUhoYU1NM3ArZjhlN2lJaFFyZ0VvUjc3eVQ4VDZv?= =?utf-8?B?RHBJR3dIOWhYdHYyV1B1NXVOWXA5RENlSXVPT3FlcGdxWVB2OC9lUFNWT0c3?= =?utf-8?B?UCtQeHcvNnFVWGJRLzc1NkRsMHk5NE4zQ1ovMEE2dm84dnp4bkUyaFF2WmVl?= =?utf-8?B?TCtrdkE2MlNaaDNpd1lydGxnaEQrWHdZeXZERTROV1NxS3l6ekdURHpyeFlp?= =?utf-8?B?cWdaamZNWWJsdVlqeXFRWTVPeVBVWTZNZ3djK3lFRHZtZU1vZnA2VGxucjgy?= =?utf-8?B?eFl5Tnhoa2ZDZ1JqKzRSUmtXT0F4ZlNTRVpGYkJOMkJvZE51QTd1M255cy8r?= =?utf-8?B?OXBub0JId0gwdWNSNkhTYlZkVVFCc3pjbm5TMFhlYVl4QXA3dHlFSUdKejVY?= =?utf-8?B?azBtbURRemFKT3RsYUhKZCtjdHdOUzFHNVhsNS95ZTVZSzhxVzExWHlsZWk3?= =?utf-8?B?QlFraVhIK2h1OWhJUVd6Wk9NUnpyUUJpVndUVWtUandUK2VackNsZXdTSXM1?= =?utf-8?B?YjUyK2RjOEllVGV2L1ZOVVVuTndKZWFkVnZySWtwcUROVUJ2Q3JzcFJNbmJj?= =?utf-8?B?d1p1M0xWNmIzT0JxM1FZMVArQ1ljYkFmWTFZWW55RDVJU3lhU3pVMlFmcDhD?= =?utf-8?B?aG1WdHc2bWRYVnlPRHZsT1R1bDNXSXpRaXVVVWxET2ZLZHNmd0ErYms3WEd2?= =?utf-8?B?TjJWMHNDb3RLMzFmK3dkUWJ4ZHJxMmJzbnVadkV2OWtkYWl1YXZ6UXBiV2U2?= =?utf-8?B?T1lWMXJncGlRUjRWQStNQkNLbG9Fc1hVdXVuOE5JSm44VHAvY3BNd2wrRnYv?= =?utf-8?B?R0Z0WHhCKzI4Qm4ydVZYWFBvckpsejZZYTgvV1hQWW1IWnYxWThhTTlNUlZt?= =?utf-8?B?ZWl0UDMwSW8zNVJUR3N5eWtodGNRWFFjRXRlcVdKSXUyWGZyWllWREkyNzFm?= =?utf-8?B?ZlBoT3FLU2wxSE1TSHprOXFIS3VqSnkydEE3Sk1JMXM4b2VjL045UktHbzcy?= =?utf-8?B?NzhBT1Q3MXVPVDg5R1hocHlxNHNZWlFZNWhueDNEZ0JrR2lIZkw1emZUUHJH?= =?utf-8?B?NmpwQTQ5UGw0THZFMFRDWHVsb3dScFhSU3doRU1mOXlXOSsrYXNYcThhS01T?= =?utf-8?B?VU9BWXpBSVh1K1ZoMjBRSkFYNGcyQUw3T05QTk91d2tncHk5enJDWTkxYTZS?= =?utf-8?B?Wm9QMTE0V2Q5UHhwV05TZSs2Q05qTmZ1cTY4K3hJZkVkUXVvZm5BU1QvQUlD?= =?utf-8?B?VE5rclFseTNiQmFqNVU5UDUrWG8yNHJnbStSOHpScHdDZ1EyanNCeFozN1hr?= =?utf-8?B?SGpsWDJnTVgrYmZXYzY2ZE5BazhPQTFhVTlFcFpEcE5mNHdTN1diWjNUSGcx?= =?utf-8?B?dUVhMGFPVU9sOWVaRnlUUVdvVkNsanBFZ0c3Tk1qQ1RRM2RxSk1iR240RzNN?= =?utf-8?B?SUYwNTBjWGM0Y2ZKazZScVlWVW1iV0RiazlzZWtmRTh6ZEVicUxmRVFsTHFs?= =?utf-8?B?ZVU5ZjVXY0FJdGtWNzBHVmY2T1IvanpDR3AxdHhoaDNNbjhXb002YTVQdUVY?= =?utf-8?B?Myt0NUlObnI1ZXJLQkY0enlKOFJFanc5SjVEOEZoZ2l5dWVDaFQ5SGMvbjVu?= =?utf-8?Q?x8BYJONEpS65Cdqg=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30509A4728E4C8F88B45C00389989HE1PR0701MB3050_" 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: 3f1ea95e-5805-49e2-c434-08d9a821de28 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2021 10:22:46.2637 (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: iSQ85a2oIoXL94+phtWQtGy75b5suQ4yXLD6bVSX16QXDjXoEkDdEKbnPbblb26N6uWDWRnMMvP2LPm+bKXbX71PujZyMKUtLbBGb2Ux+A4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2778 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirming_adoption_of_draft-hoegl?= =?utf-8?q?und-core-oscore-key-limits-02_as_a_CoRE_WG_document?= 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 Nov 2021 10:22:56 -0000 --_000_HE1PR0701MB30509A4728E4C8F88B45C00389989HE1PR0701MB3050_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIGhhcyByZWNlbnRseSBiZWVuIGRpc2N1c3Npb24gYWJvdXQgY29ubmVjdGlv biBJRCBwcml2Y2FjeSBpbiBMQUtFIFdHIGFuZCB0aGUgY29ycmVzcG9uZGluZyBpZGVudGlmaWVy cyBpbiB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wuIEkuZS4gU2VuZGVyIElEIGFuZCBSZWNpcGll bnQgSUQgaW4gT1NDT1JFLiBDaHJpc3RpYW4gd3JvdGUgdGhhdCBhYmlsaXR5IHRvIGNvcnJlbGF0 ZSBjb25uZWN0aW9uIGJldGVlbiB0d28gcG9pbnRzIGluIHRpbWUgb3IgYmV0d2VlbiBwYXRocyBp cyBhbHNvIHJlbGF0ZWQgdG8gc2VxdWVuY2UgbnVtYmVycy4NCg0KSSB0aGluayBpdCB3b3VsZCBi ZSBnb29kIHRvIGRpc2N1c3MgaWYgdGhlIEtVRE9TIHJla2V5aW5nIG1lY2hhbmlzbSBzaG91bGQv Y291bGQgYmUgdXNlZCB0byBhbHNvIHVwZGF0ZSB0aGUgaWRlbnRpZmllcnMuIEtVRE9TIHJlc2V0 cyB0aGUgc2VxdWVuY2UgbnVtYmVycy4gSSBoYXZlIG5vdCB0aG91Z2h0IGFib3V0IHRoaXMgaW4g YW55IGRldGFpbCBvciB0aGF0IGl0IGlzIHNvbWV0aGluZyB3ZSBzaG91bGQgZG8sIEkganVzdCBz dWdnZXN0IHRoYXQgd2UgZGlzY3VzcyBpdC4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cv b3Njb3JlL2lzc3Vlcy8yNjMNCmh0dHBzOi8vZ2l0aHViLmNvbS9sYWtlLXdnL2VkaG9jL2lzc3Vl cy8yMDINCg0KQmFja2dyb3VuZCBpbmZvIG9uIGNvbm5lY3Rpb24gSUQgdXBkYXRlIGluIFFVSUMg YW5kIERUTFMgMS4zOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM5 MDAwI3NlY3Rpb24tNS4xDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtdGxzLWR0bHMxMy00MyNzZWN0aW9uLTkNCg0KQ2hlZXJzLA0KSm9obg0KDQpGcm9t OiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaHJpc3RpYW4gQW1z w7xzcyA8Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPg0KRGF0ZTogVHVlc2RheSwgOSBOb3ZlbWJlciAy MDIxIGF0IDE3OjI1DQpUbzogSmFpbWUgSmltw6luZXogPGphaW1lQGlraS5maT4NCkNjOiBjb3Jl QGlldGYub3JnIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIENvbmZp cm1pbmcgYWRvcHRpb24gb2YgZHJhZnQtaG9lZ2x1bmQtY29yZS1vc2NvcmUta2V5LWxpbWl0cy0w MiBhcyBhIENvUkUgV0cgZG9jdW1lbnQNCkhlbGxvIEphaW1lLA0KDQo+IEluIHllc3RlcmRheSdz IENvUkUgbWVldGluZywgd2UgaGFkIGdvb2QgaW4tcm9vbSBjb25zZW5zdXMgdG8NCj4gYWRvcHQg ZHJhZnQtaG9lZ2x1bmQtY29yZS1vc2NvcmUta2V5LWxpbWl0cyBhcyBhIFdHIGRyYWZ0IChBZG9w dGlvbg0KPiBjYWxsOiArOSwgb25lICJub3QgcmFpc2UgaGFuZCIgKS4NCg0KSSB3YXMgb25lIG9m IHRoZSA5LCBhbmQganVzdCB3YW50IHRvIHJlaXRlcmF0ZSBoZXJlIHRoYXQgSSBjb25zaWRlciBi b3RoDQpwYXJ0cyBvZiB0aGUgZG9jdW1lbnQgaW1wb3J0YW50IGZvciB0aGUgV0cuIEkgZG8gbm90 IHVuZGVyc3RhbmQgYWxsIHRoZQ0KcGllY2VzIHRoYXQgY29tZSB0b2dldGhlciBvbiB0aGUgSUEg YW5kIENBIGxpbWl0cyBwYXJ0LCBidXQgY2FuIG9mZmVyDQpyZXZpZXdzIG9mIEtVRE9TIHBhcnQg YXMgdGhpcyB3aWxsIHByb2dyZXNzLg0KDQpUaGFuayB5b3UgUmlrYXJkIGFuZCBNYXJjbyBmb3Ig d29ya2luZyBvbiB0aGlzDQpDaHJpc3RpYW4NCg0KLS0NClRvIHVzZSByYXcgcG93ZXIgaXMgdG8g bWFrZSB5b3Vyc2VsZiBpbmZpbml0ZWx5IHZ1bG5lcmFibGUgdG8gZ3JlYXRlciBwb3dlcnMuDQog IC0tIEJlbmUgR2Vzc2VyaXQgYXhpb20NCg== --_000_HE1PR0701MB30509A4728E4C8F88B45C00389989HE1PR0701MB3050_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQXBwbGUgQ29sb3IgRW1vamkiOw0KCXBh bm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1TRSIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29y ZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlcmUgaGFz IHJlY2VudGx5IGJlZW4gZGlzY3Vzc2lvbiBhYm91dCBjb25uZWN0aW9uIElEIHByaXZjYWN5IGlu IExBS0UgV0cgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGlkZW50aWZpZXJzIGluIHRoZSBhcHBsaWNh dGlvbiBwcm90b2NvbC4NCjwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JLmUuIDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlNlbmRlciBJRCBhbmQgUmVjaXBpZW50IElEIGluIE9TQ09SRS4gQ2hyaXN0 aWFuIHdyb3RlIHRoYXQgYWJpbGl0eSB0byBjb3JyZWxhdGUgY29ubmVjdGlvbiBiZXRlZW4gdHdv IHBvaW50cyBpbiB0aW1lIG9yIGJldHdlZW4gcGF0aHMgaXMgYWxzbyByZWxhdGVkDQogdG8gc2Vx dWVuY2UgbnVtYmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsgaXQNCjwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPndvdWxkIGJlIGdvb2QgdG8gZGlz Y3VzcyBpZiB0aGUgS1VET1MgcmVrZXlpbmcgbWVjaGFuaXNtIHNob3VsZC9jb3VsZCBiZSB1c2Vk IHRvIGFsc28gdXBkYXRlIHRoZSBpZGVudGlmaWVycy4gS1VET1MgcmVzZXRzIHRoZSBzZXF1ZW5j ZSBudW1iZXJzLiBJIGhhdmUgbm90IHRob3VnaHQgYWJvdXQgdGhpcyBpbiBhbnkgZGV0YWlsIG9y IHRoYXQgaXQgaXMgc29tZXRoaW5nDQogd2Ugc2hvdWxkIGRvLCBJIGp1c3Qgc3VnZ2VzdCB0aGF0 IHdlIGRpc2N1c3MgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL29zY29yZS9p c3N1ZXMvMjYzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5odHRwczovL2dpdGh1Yi5jb20v bGFrZS13Zy9lZGhvYy9pc3N1ZXMvMjAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJhY2tncm91bmQgaW5mbyBvbiBjb25uZWN0 aW9uIElEIHVwZGF0ZSBpbiBRVUlDIGFuZCBEVExTIDEuMzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjOTAwMCNzZWN0 aW9uLTUuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRscy1kdGxzMTMtNDMjc2VjdGlvbi05PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkpvaG48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5jb3JlICZsdDtjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBDaHJpc3Rp YW4gQW1zw7xzcyAmbHQ7Y2hyaXN0aWFuQGFtc3Vlc3MuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UdWVzZGF5LCA5IE5vdmVtYmVyIDIwMjEgYXQgMTc6MjU8YnI+DQo8Yj5UbzogPC9iPkphaW1l IEppbcOpbmV6ICZsdDtqYWltZUBpa2kuZmkmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5jb3JlQGlldGYu b3JnICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2NvcmVd IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cHBsZSBDb2xvciBFbW9qaSZxdW90Oztjb2xvcjpibGFjayI+JiMxMjgyNzY7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4gQ29uZmlybWluZyBhZG9wdGlv biBvZiBkcmFmdC1ob2VnbHVuZC1jb3JlLW9zY29yZS1rZXktbGltaXRzLTAyIGFzIGEgQ29SRSBX RyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhlbGxvIEphaW1lLDxicj4N Cjxicj4NCiZndDsgSW4geWVzdGVyZGF5J3MgQ29SRSBtZWV0aW5nLCB3ZSBoYWQgZ29vZCBpbi1y b29tIGNvbnNlbnN1cyB0bzxicj4NCiZndDsgYWRvcHQgZHJhZnQtaG9lZ2x1bmQtY29yZS1vc2Nv cmUta2V5LWxpbWl0cyBhcyBhIFdHIGRyYWZ0IChBZG9wdGlvbjxicj4NCiZndDsgY2FsbDogKzks IG9uZSAmcXVvdDtub3QgcmFpc2UgaGFuZCZxdW90OyApLjxicj4NCjxicj4NCkkgd2FzIG9uZSBv ZiB0aGUgOSwgYW5kIGp1c3Qgd2FudCB0byByZWl0ZXJhdGUgaGVyZSB0aGF0IEkgY29uc2lkZXIg Ym90aDxicj4NCnBhcnRzIG9mIHRoZSBkb2N1bWVudCBpbXBvcnRhbnQgZm9yIHRoZSBXRy4gSSBk byBub3QgdW5kZXJzdGFuZCBhbGwgdGhlPGJyPg0KcGllY2VzIHRoYXQgY29tZSB0b2dldGhlciBv biB0aGUgSUEgYW5kIENBIGxpbWl0cyBwYXJ0LCBidXQgY2FuIG9mZmVyPGJyPg0KcmV2aWV3cyBv ZiBLVURPUyBwYXJ0IGFzIHRoaXMgd2lsbCBwcm9ncmVzcy48YnI+DQo8YnI+DQpUaGFuayB5b3Ug UmlrYXJkIGFuZCBNYXJjbyBmb3Igd29ya2luZyBvbiB0aGlzPGJyPg0KQ2hyaXN0aWFuPGJyPg0K PGJyPg0KLS0gPGJyPg0KVG8gdXNlIHJhdyBwb3dlciBpcyB0byBtYWtlIHlvdXJzZWxmIGluZmlu aXRlbHkgdnVsbmVyYWJsZSB0byBncmVhdGVyIHBvd2Vycy48YnI+DQombmJzcDsgLS0gQmVuZSBH ZXNzZXJpdCBheGlvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_HE1PR0701MB30509A4728E4C8F88B45C00389989HE1PR0701MB3050_-- From nobody Mon Nov 15 02:24:34 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 ED9123A0811; Mon, 15 Nov 2021 02:24:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <163697187231.22434.1422869521626935017@ietfa.amsl.com> Date: Mon, 15 Nov 2021 02:24:32 -0800 Archived-At: Subject: [core] Zaheduzzaman Sarker's No Objection on draft-ietf-core-sid-17: (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: Mon, 15 Nov 2021 10:24:33 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-core-sid-17: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the addressing my DISCUSS in the -17 version of this document. From nobody Mon Nov 15 06:31: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 48BD33A0CB5 for ; Mon, 15 Nov 2021 06:31:11 -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 PwdHzkZAwGOg for ; Mon, 15 Nov 2021 06:31:06 -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 8F7353A0CAC for ; Mon, 15 Nov 2021 06:31:05 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id A736640418; Mon, 15 Nov 2021 15:31:01 +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 4FC46154; Mon, 15 Nov 2021 15:30:59 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a8a2:900b:f999:58a7]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E6161CD; Mon, 15 Nov 2021 15:30:58 +0100 (CET) Received: (nullmailer pid 235290 invoked by uid 1000); Mon, 15 Nov 2021 14:30:58 -0000 Date: Mon, 15 Nov 2021 15:30:58 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: John Mattsson Cc: Jaime =?iso-8859-1?Q?Jim=E9nez?= , "core@ietf.org" Message-ID: References: <97d7f098-ff89-4dae-a9dd-be09225553aa@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8mA/8xMYCGx/QR37" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirming_adoption_of_draft-hoegl?= =?utf-8?q?und-core-oscore-key-limits-02_as_a_CoRE_WG_document?= 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 Nov 2021 14:31:11 -0000 --8mA/8xMYCGx/QR37 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello John, KUDOS authors, On Mon, Nov 15, 2021 at 10:22:46AM +0000, John Mattsson wrote: > I think it would be good to discuss if the KUDOS rekeying mechanism > should/could be used to also update the identifiers. KUDOS resets the > sequence numbers. I have not thought about this in any detail or that > it is something we should do, I just suggest that we discuss it. The two are related but at different layers; any solution combining them would need to operate on both. (KUDOS sending unprotected nonces, new KIDs would need to be negotiated in encrypted data). It may help to see them independent initially: * KUDOS allows using new key material from a preexisting context, with sequence numbers starting at 0 again, but keeps the same KIDs. * KID switchovers could be announced using inner options -- "Please address me as ${my_new_sender_ID} henceforth". Keeping the master key, whoever changes their KID needs to be aware of all KIDs previously used on that shared context. In particular, the ID needs to stay unused until the peer has acknowledged (eg. by using the new ID) that it didn't try to switch to that ID at the same time. The requirement to know history (lest a sender key get drived a second time) is what makes KID changes convenient to do at KUDOS time (when the list of previously used KIDs is empty again). BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --8mA/8xMYCGx/QR37 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGSbx4ACgkQOY0REtOk veEmIw/+P1y0c3ME6bBiBwGJFmlFHzzMJ6c5wJMGJRBZKzNzvHEjcsUFFcgp8gVU 6DjfjQuy1VPoYQvDqVGo2yEVLKkU2+bnbQv32dTBhnyDR04bYqYoN/gsYJ3HcgKE 3bmA/mZ3u+BS0+YokdTLi3g0E9NYT4y+lT5Fy7mfG0lgry1Jrnop/93AyVzihRr0 I0sKbx5V3OvdF9uTas4QQEZ9E/SQvEbvnyHyGbCFgYdULIvNmhG3vHU0Zy0jjELz a9dBJWp/3lmxDbcBRtaDQ1l1McoPa0Y2b2ECnR/wBT/6nU9iNSsVn5vb/2PpO+6l TLYMphAgMOrtAJmUZtdtrviACXKO2lUhVMNjrgv21BoqjXlJXV4/Vv29YyyaWEi1 l2ICnaIECnXF7bygKpqXA1jYTytraoOf6evEyFq1cOiYsq6S7pjmzySXLsNup9SH ImRIy5AE1iiBuu3iBCwh69VFn2tNV47c3BEOH8Y88zVSnOaCUjn9HUeeca2R9cnl p5I6oOXi3vyCcU3SIoJ2WQxkbuoCmSsg2AIpiBOXOuuzYjyJFFKY2f9uOqoYos+/ PXX3j/fihNd0vKnBtlIzNJBqQNTQ8IvouGh7COb152YyAAo1phU7loFJSTq6Qpe5 z3ChBW30CyLakFNEZsK9ZEUcqqVvJoXPKgnXeAKX6tQBmTe6emo= =Ohzu -----END PGP SIGNATURE----- --8mA/8xMYCGx/QR37-- From nobody Mon Nov 15 07:26: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 E59733A0D52; Mon, 15 Nov 2021 07:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 CYb1OX6qGNOs; Mon, 15 Nov 2021 07:26:53 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02EC3A0D43; Mon, 15 Nov 2021 07:26:53 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HtCj70kKKz2xvC; Mon, 15 Nov 2021 16:26:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162621573715.1426.3300364400283622807@ietfa.amsl.com> Date: Mon, 15 Nov 2021 16:26:50 +0100 Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , Jaime Jimenez X-Mao-Original-Outgoing-Id: 658682810.667624-3d1237b7ddf5203766900e915d2609de Content-Transfer-Encoding: quoted-printable Message-Id: <0878C5CB-B976-46EE-ADA8-A43333DAEF31@tzi.org> References: <162621573715.1426.3300364400283622807@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (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, 15 Nov 2021 15:26:58 -0000 [Draft for discussion today] Hi Ben, Here is our response, but to the 2021-10-16 updated version in the = datatracker (thanks for this): > Discuss (2021-10-26) > (1) I think there is a new security consideration with this work that = is > important to document clearly -- not only do we define a new type of > identifier, but we define a file format and other mechanisms for > disseminating that information. An entity that's processing > application/yang-data+cbor; id=3Dsid information needs to ensure that = the > .sid files (or other source of SID information) it uses for such > processing came from a trustworthy authority (or at least the same > source as the data file). It would be possible for malicious > manipulation of .sid file contents to cause a message recipient to > mis-interpret the received message without any indication of such > tampering. > [ed. there seems to be some proposed text in >=20 > = https://mailarchive.ietf.org/arch/msg/core/JS0uD9aUNwim_fwhBpGnZut9kns/ > ] Indeed. We have slightly improved on the text in that discussion;=20 https://github.com/core-wg/yang-cbor/pull/102 > (2) Per =C2=A77.4.2, YANG SID range registries with public ranges MUST > include a reference to the ".sid" file for such ranges, but the > IANA-managed YANG SID range registry established by =C2=A77.5 does = not, in > and of itself, make such a provision. This function seems to be = served > by the "IETF YANG SIG Registry" created by =C2=A77.6, so we may just = need to > point to the one registry from the other in order to remain internally > consistent. Right, we added more explanatory text and a pointer. https://github.com/core-wg/yang-cbor/pull/99 > (3) There may be another inconsistency to look into; Section 7.6.2 = says > that: >=20 > * If another ".sid" file has already allocated SIDs for this YANG > module (e.g. for older or newer versions of the YANG module), = the > YANG items are assigned the same SIDs as in the other ".sid" = file. >=20 > But we are supposed to allocate a new SID for a YANG item if its > semantics change in a revision of the YANG module. Perhaps it's just > the "for older or newer versions of the YANG module" phrase that needs > tweaking? We toned down the need for a new SID quite a bit;=20 See updated appendix B. The point of the text here is to say that existing allocations stay in = place; the exceptions listed in Appendix B notwithstanding. >=20 > Comment (2021-10-26) >=20 > Would RFC 8792 folding be suitable for Appendix A rather than using > a custom scheme/disclaimer? We don=E2=80=99t think so. The appendix is an illustration, not = something one would extract as sourcecode to work on. The line-breaking scheme we used is noiseless; you cannot say this of = RFC 8792! > I see that most mention of what to do with SID assignments if the > semantics of a node (name) changes, or a node name changes without > changing semantics, has been moved to Appendix B. I'm not sure if > it's helpful to retain some mention that this discussion exists, > in the main body text (e.g., Section 1). Section 1 now points there and mentions manual interventions. https://github.com/core-wg/yang-cbor/pull/97 > [The rest of this COMMENT section populated by taking the comment = section from the -16 > and removing a small handful of things that are clearly addressed. > Some items that are retained may have been addressed as well and no > longer applied] >=20 > The yangdoctors review mentioned the structure extension from RFC = 8791, > and the authors (understandably) expressed reluctance to make such a > large change at this stage in the process. I'll note that the DOTS WG > has recently completed work on a "bis" of RFC 8782, with primary aim = of > replacing yang-data with structures and minimal other changes. (A > yangdoctors review of a related document was sufficiently insistent = that > structures are the right way to do this that the WG was convinced to = put > in the effort.) =E2=80=94 discuss today 1 =E2=80=94 > The yangdoctors review also asked why sid-file/module-name is = optional, > which was tagged for follow-up. I have the same question and am > interested in the outcome of the discussion amongst the authors. It can=E2=80=99t really, can it? We wouldn=E2=80=99t know how to make use of the =E2=80=9Cidentifier=E2=80=9D= fields without the module name? > If SIDs are supposed to be globally unique identifiers, the reference = in > the YANG module to "namespace" identifiers for individual allocations = is > puzzling to me. The presence of a namespace would typically allow for > identifier reuse across namespaces (e.g., using the same SID integer = value > for an identity and a data node within the same module). I see how = the > current list structure makes it easy to have a single flat list of all > identifier/sid mappings, but if the SIDs truly are globally unique, = then > the "namespace" should not be a list key, and might be less = confusingly > described as just indicating the type for which the SID is used. (It > would also be possible to have separate lists for module SIDs, = identity > SIDs, etc., but it's not clear that doing so is actually the right > approach.) =E2=80=94 discuss today 2 =E2=80=94=20 > Section 4 >=20 > If the scope of a sid-file-version-identifier resets when the module > revision is bumped, it seems highly unlikely that we'll need 64 bits = of > identifier for it. Fixed in https://github.com/core-wg/yang-cbor/pull/84 > Section 5, 7.3 >=20 > It's not entirely clear that we need to mention the > content-type/content-format in this document, as we only indicate use = of > the JSON encoding for the .sid file and the use of SIDs in the > application/yang-data+cbor; id=3Dsid case seems adequately described = by > the existing treatment in draft-ietf-core-yang-cbor. =E2=80=94 discuss today 3 =E2=80=94 Yes, we can delete this section. = Should we? >=20 > Section 7.4.1 >=20 > I appreciate that the "mega-range" allocations are sized for the > appropriate SI prefix :) We discussed decimal vs. binary a lot but decided this is mainly for = humans. >=20 > The information associated to the Organization name should not be > publicly visible in the registry, but should be available. This > information includes contact email and phone number and change > controller email and phone number. >=20 > Available to whom? We removed this overspecification in = https://github.com/core-wg/yang-cbor/pull/98 > Section 7.5.2 >=20 > In case a SID range is required before publishing the RFC due to > implementations needing stable SID values, early allocation as > defined in [BCP100] can be employed. As specified in Section 4.6 = of > [RFC8126], RFCs and by extension documents that are expected to > become an RFC fulfill the requirement for "Specification Required" > stated in Section 2 of [BCP100], which allows for the early > allocation process to be employed. >=20 > While the first bit of this is all true, the registry here doesn't use > the "Specification Required" policy for any range, and early = allocations > are available for the "RFC Required" range. So we should probably = tweak > or remove the second sentence. =E2=80=94 discuss today 4 =E2=80=94 >=20 > Section 7.6.3 >=20 > Early Allocations are made with a one-year period, after which they > are expired. [BCP100] indicates that at most one renewal may be > made. For the SID allocation a far more lenient stance is desired. >=20 > 1. An extension of a referencing documents Early Allocation should > update any referenced Early Allocations to expire no sooner = than > the referencing document. >=20 > 2. The [BCP100] mechanism allows the IESG to provide a second > renewal, and such an event may prompt some thought about how = the > collection of documents are being processed. >=20 > The first point is rather curious, since it can have no normative = force > (this is not a BCP that would override BCP 100) and is merely a > continnation of how a more lenient stance is desired. It's rather odd > to see it written in this way. The second point seems to be the only > really useful part, and in practice this IESG approval of second (and > more!) renewals has become rather common, to the extent where a = revision > of BCP 100 has been discussed to change the discussion of extensions = for > early renewals. >=20 > This is driven by the very generous size of the SID space and the > often complex and deep dependencies of YANG modules. Often a core > module with many dependencies will undergo extensive review, = delaying > the publication of other documents. >=20 > Having many *dependencies* and taking a while shouldn't delay > publication of anything else; however, having many other modules > dependent on a core module would be likely to do so. =E2=80=94 discuss today 4 continued =E2=80=94 > Appendix A >=20 > IIRC the mismatch between "ietf-system@2014-08-06.yang" and the = toplevel > "module-revision" of "2020-02-05" was noted by an earlier reviewer, = but > I'll mention it here just in case I do not remember correctly. Still as task https://github.com/core-wg/yang-cbor/issues/66 on the list=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 16 06:55: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 8DCA03A0414 for ; Tue, 16 Nov 2021 06:55:36 -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 Itxzj3dD9Pz3 for ; Tue, 16 Nov 2021 06:55: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 9AFC33A0406 for ; Tue, 16 Nov 2021 06:55:30 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7FB4F40438 for ; Tue, 16 Nov 2021 15:55:22 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 37B88154 for ; Tue, 16 Nov 2021 15:55:20 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:3145:c320:9e2b:828f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C9CB2CD for ; Tue, 16 Nov 2021 15:55:19 +0100 (CET) Received: (nullmailer pid 1494843 invoked by uid 1000); Tue, 16 Nov 2021 14:55:19 -0000 Date: Tue, 16 Nov 2021 15:55:19 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j46kIKPmbozZ9TXW" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] CoRE applications side meetings (pubsub / dynlink)? 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 Nov 2021 14:55:37 -0000 --j46kIKPmbozZ9TXW Content-Type: multipart/mixed; boundary="8TbZDpSnUQZ8T9Ju" Content-Disposition: inline --8TbZDpSnUQZ8T9Ju Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Tue, Nov 09, 2021 at 05:17:39PM +0100, Christian Ams=FCss wrote: > based on the feedback that arrived, a small group will meet tomorrow > (Thursday) 10:00 UTC in the hackathon area to look through some > applications (pubsub, problem-details), possibly doing examples or check > out how things align with current CoRAL. the small group was not all that small and very lively -- thanks everyone for participating! I've attached the minutes here in case the pad we used[1] goes away. While we figure out how to best make more of the CoRE ecosystem publicly visible at coap.technology, we can already start collecting material at the wiki[2]. Best regards Christian [1]: https://notes.ietf.org/GaM_PWd2TnmY0DrTe6DdQA?view [2]: https://github.com/core-wg/wiki/wiki --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --8TbZDpSnUQZ8T9Ju Content-Type: text/markdown; charset=utf-8 Content-Disposition: attachment; filename="applications.md" Content-Transfer-Encoding: quoted-printable IETF 112 Hackathon Table F URL: https://notes.ietf.org/GaM_PWd2TnmY0DrTe6DdQA CoRE applications: CoAP with batteries included =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Selecting focus points for today: * CA: Rounding off the big picture, CoRAL * MT: Pubsub * JJ: Pubsub, problem-details * CB: STP Components out and around (annotated with where they are in the process): * [pubsub](https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/) WG * [Latest discussion](https://hackmd.io/2eqcQ0tWRsGle090mQaJLw?view) * JJ: see above, just work to do. * CA: How important are 3rd party extensions or vendor extensions? * JJ: Not sure, not went that deep yet. CoRAL part could be minimal (no= normative examples). Still incorporate structures from KH and MJK on topic= creation. * JJ: Originally we had rt=3D for pubsub brokers. CA: see no reason not= to. * CA: timeline? JJ: No specific one, work on it on spare time. MT: The = pub-sub profile of ACE depends on it. * MT: If considering add'l author, should have stake in ACE doc. Maybe = Cigdem. JJ: wishes for Klaus to join. * [STP](https://datatracker.ietf.org/doc/html/draft-bormann-t2trg-stp-03) i= ndividual * (event streams, keyboard?) * Used in https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-tok= en-notification/ * CA: What'd it need to progress? * CB: Depends on kind of document we'd like to have. Currently informat= ional, structure to be defined by specific document. Maybe can extract comm= on backbone. Should probably read ACE document. * CA: Link relation could be common. * MT: We didn't notice we were using STP until you pointed it out in yo= ur review. CB: Need to read more there. * CA: Maybe marketing materials? * JJ: CB, timeline? CB: Now I'm becoming aware of use cases, now more i= nterested. * CA: Serial terminal is coming up from RIOT. * CB: YANG is standardizing pagination. Obviously related, pagination s= hould be mentioned. CA: Extending automaticaly to CoRECONF? CB: Think so. R= eading up ... have netconf extensions for pagination. Should put this toget= her; individual now but names involved. * https://www.ietf.org/id/draft-wwlh-netconf-list-pagination-nc-02.html * ackl.io, Michel Veillette (trilliant), MCR (?) using both. * =E2=86=92CA: CoRAL example? CB: Yes. Need to put in contrast between = that schema driven and hypermedia driven. Documenting how either can be com= bined woudl be later step. CoRECONF is 2 things: translation of YANG to SID= , and having SIDs w/o writing model in YANG. SIDs could also do structured = data. YANG is very schema driven, hypermedia people want structure in data,= need reconciliation. * [ASDF-CORAL](https://notes.ietf.org/notes-ietf-interim-2021-core-06-core#= Relation-between-CoRAL-and-SDF) * MT: Getting closer to doing this with the people involved. * CB: SDF in here is similar to YANG, but SDF more non-schema-oriented. O= peration on instance level (concrete resource) not describable in SDF yet. = Can't stay in class now that instance can have particular properties. * CB: Got a student? Comparing YANG features (call-home?) to links would = be interesting. * [later] * Links to instances ... does target need to be SDF? No, may be (optional= attribute). AK: In LwM2M can point insdie same realm. Same mechanism, diff= erent qualities. * [CoRAL](https://datatracker.ietf.org/doc/draft-ietf-core-coral/) WG * Input/inspiration for modelling FETCH and PATCH is in https://datatra= cker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/ * CA: Look into applying what's there to the pubsub use case. * CA: Easy when everyone agrees that properties are single-valued. * MT: In gm-admin, multi-valued lists are literal-valued. * CA: Try describe interaction as forms, even though not required in gm= -admin? * MT: In 2020, feedback on CoRAL forms in this context [from JLS](https= ://mailarchive.ietf.org/arch/msg/core/BoYGYmEpJMUS8bk4PNHOEaFFcdU/). Respon= ses to administrator in CoRAL could be descriptive of API. Blends with prob= lem-details. * [problem-details](https://datatracker.ietf.org/doc/draft-ietf-core-proble= m-details/) WG * JJ: Based heaveily on HTTP equivalent (which is being revised 7807bis= ). Differences: CoAP PD are in CoRAL. Need to standardize number describing= problem -- not in draft, but discussion. Same for title / description. Pro= gress, but not in draft yet. Check issues on tracker. Keep monitoring the b= is. * GS: How to disseminate? Wiki? * JJ: coap.technology * CA: assemble material in wiki, move to coap.technology JJ: or other memor= able page. * JJ: Or a short book ;-) * GS: Pointers to implementations as a start. And to components. * CB: Book would add latency ... need little snippets of "TIL about CoAP" o= ut. * MT: Just revisiting coap.technology can work. CB, JJ: Good. * CB: Will need a bit of technology update. ## AOB GS: CoRE security forum? (see mail sent around). Coordination on pieces fit= ting together ... regular meeting? Need / use? JJ: Scope? CB: Yes. Running own series of interims for CoRE security could get progres= s. Many "yes". Work between meetings, mutual updates in meetings. CB: Proposing something like WISHI (under T2TRG umbrella) ## not handled (but still relevant) * "ping-pong protocols"? * ~~core-interfaces~~ (still not covered elsewhere: core.s, core.a) * [dynlink](https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/) WG * [conditional-attributes](https://datatracker.ietf.org/doc/draft-ietf-core= -conditional-attributes/) WG * AIF=20 * [CoAP MUD](https://datatracker.ietf.org/doc/html/draft-jimenez-t2trg-mud-= coap-00) * [RD](https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/= ) RFC * SUIT Which draft to push to get full picture? --8TbZDpSnUQZ8T9Ju-- --j46kIKPmbozZ9TXW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGTxlMACgkQOY0REtOk veG9Rw//UAUXlWB0akCV4t+IfFrdYJ4SL3AZfXPiAz7rjFTa90mM9wjWPvsosv9g 0eOU8QHR2QY8ryOhK6W3vSXee0rR0BR4u5UZM2oT/s5+dcx20JEdPa+t1hx2GaiT 8YDNUHErCP9Z2IvPrktu+NIMvH0YBIol3RHOGzhRflOoretl6D05kuRkhTM5Wu33 9FF/mVnWoJvSpCS42IU5ybTmsj2o1dv/XMFT5lIgqjfAUQveKFapWRlRTxWaVGtm 2HI+qY6Xvmz6w0754+1+nP3mBC2x2xLsx59I5n/LNlt8A/hbTIdkVUm8UucLrBa3 0dOwsZvKiQooxMwzMBim6Nr8YhbX3YTdqrcLD+zBM2Gud37tFHjd1ROZ/Td0h5kn wHxjkNhBtbATRbYrWvYsOYy14oDwSY12pxPpwXdmGG2w5zMMLV9IPo0hPYgL9Hrs fwTw4aWgNcHs1aDNHIyru5j68Jfw8B3zz3rR0Q24ApWvAQutnMDScYeVkMmGHJkq SFCy5RY2QrRldkj9Q6zLEqOIgKkFjaJoo0ZkWkC3zNFG2YvGvAeFy5ngwn+wgDnc pvvaHlDMdqND8OiaD2bKuHDg7CQizcadAdAd4LVKROBap35KsG2DffXI+YHLYm43 7qXLhDh9L9PN5fuzY5XMJ/YRiENCVx+FsECpzaIITPO8deoen4Y= =r5Z4 -----END PGP SIGNATURE----- --j46kIKPmbozZ9TXW-- From nobody Wed Nov 17 10:07: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 19DA83A0E4B; Wed, 17 Nov 2021 10:07:51 -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 H99tEi3hdCJZ; Wed, 17 Nov 2021 10:07:46 -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 9E77A3A040B; Wed, 17 Nov 2021 10:07:44 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id ABD9C4042A; Wed, 17 Nov 2021 19:07:41 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B8361154; Wed, 17 Nov 2021 19:07:40 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:cfa8:a360:fbf3:770e]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 833BFCD; Wed, 17 Nov 2021 19:07:40 +0100 (CET) Received: (nullmailer pid 2078331 invoked by uid 1000); Wed, 17 Nov 2021 18:07:40 -0000 Date: Wed, 17 Nov 2021 19:07:40 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-hoeglund-core-oscore-key-limits@ietf.org, core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S5WFiiFpv0zEMtor" Content-Disposition: inline Archived-At: Subject: [core] KUDOS, PFS and operations considerations 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 Nov 2021 18:07:51 -0000 --S5WFiiFpv0zEMtor Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello KUDOS authors, looking through the current state of KUDOS (compared to earlier discussions, and prompted by the trackability discussion coming out of EDHOC), I noticed that KUDOS nowadays discards old key material. This is nice in that it ensures that old conversations can not be deciphered from key material obtained from one of the participants later, but raises operational concerns, especially aiming to replace B.2: OSCORE keys are notoriously difficult to back up (or distribute for high reliability); in that, they behave like the stateful signing keys of HSS/LMS. A backup can only be done if the backup is replaced before the sequence number reaches a committed point (eventually stopping the running system if the backup system fails). For a distributed JRC, this is about as hard as persisting the mapping between old and new ID Context values. On embedded implementations, using OSCORE requires a device that starts up to commit something to flash memory after startup, which is an operation preferably avoided. Appendix B.2 provides a way out of this -- a device that doesn't want persistent commitment would just always do B.2 on startup and thus always start sequence numbers from 0. KUDOS as currently described helps a bit here (in that the first request can be sent without flash operations), but then requires persisting CTX_NEW and removing CTX_OLD. The new context needs to be persisted at latest before sending any second request, because if it's not, the peer may drop the old context and they have no chance of syncing again. Thus, it's not really helping to circumvent that impracticality. This is a conflict between two goals (provide PFS and enable stateless operation) that I currently see no easy way out of (other than introducing variants for either into the protocol) -- do you? BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --S5WFiiFpv0zEMtor Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGVROwACgkQOY0REtOk veFOIw//cHGlqn15WOvahxscAe5D1/rZ1Qlo7b1dluwNsbX24XWPmwnhogg8a5L9 5VOY6OTagVD7KWN7n4qxL86j2F8Kv5xtEjQb7fHccw+zeJQ8RacLn68Bg4/Q5Fkl 0gM8cT2BwZ2AnnOhpIHKz31+NEdHmRnG8UZLgGIhr/EvdKPTd8Exza747a/vIBZc geBqzM67Xs+/LNLYBc0WgO8EfNfR7NBCU67Wrg8hdfqYdy665XSDYIjbWF8zWK9a TQ6fM+XAWYcbU0I6W7JTKj941ohtJ8wSQ/7BCq9KjnwMn0SBMfeszDS8i6ih/es0 ZH7IIBkGy3T7hOomrhYVpw/BTHwy7t+h7zm6ERIG8X1A0fbxoK/tCliIzmVCiWkk OixOa2ru2McRmQCoK+DIMGIo/i49UuMUFkfgj7YO0E7/mZiSSkBRLxGTZ59AHaFZ Yv+OCmNlmqnSqti/aSgXZtrcBKCE3yM+dELvq50XGI7XDKtHf+ghdixWcK17434M GujpBFC2Msid6msM3IWkTyLBhKqUVNNhy0HViL10F8zQ5Dkwom035tNtvgohQFEe F+4D52L2wsvDTACXDR8r1b8bOhPQGAcEn/cj0kq3xQuhLtrC2JLtLdSKR1etOm7T RHOMkdYm/Sqch36KhhUqI2eMS8vfkzOSJ7y36YcJqIa8AEqEki8= =7oLQ -----END PGP SIGNATURE----- --S5WFiiFpv0zEMtor-- From nobody Wed Nov 17 10:59:34 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 6709F3A005C for ; Wed, 17 Nov 2021 10:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 JijiVwi5QlRV for ; Wed, 17 Nov 2021 10:59:28 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD843A0062 for ; Wed, 17 Nov 2021 10:59:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C8CD91801B for ; Wed, 17 Nov 2021 14:01:51 -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 NdD7o_ltuO8V for ; Wed, 17 Nov 2021 14:01:49 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF6A11800C for ; Wed, 17 Nov 2021 14:01:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1637175708; bh=Bod+s5HzMmMeSdlw9JFjbhGA69x6t6ju5yBRZPNvAQc=; h=From:To:Subject:Date:From; b=aPdlEoPppzB1Xi+SxfyASQzUrqn1BRrDJpicrRBAOo1SXeJTtaDXNI45T5SDjfg40 9ixWm64GT091K/QcNyIVw7PNb3ZbBEi0Yc1yLhdu1cap959/mp70AfnGeFGSH3w/sn u/40YR7pIHkIyZ++uckNy6+5T3cAPKp6aapKWhjI/Idac/le6d5eVEFTS5lx8LWx3+ cUXA6t7Re5lrqmmqGvt7jqnxs/zPShXExK4sw5RofzGbo0J4IdbIVEt9it3w0LC9Sw 3tDRpjsStR/YU9JTtMoqg0U6jK9OYBGSicctjH7fFSblGR4EhQSVGUBd5IRIbCWHT9 41IurkR59SrRw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AB9108D5 for ; Wed, 17 Nov 2021 13:59:22 -0500 (EST) From: Michael Richardson To: core@ietf.org X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Wed, 17 Nov 2021 13:59:22 -0500 Message-ID: <24049.1637175562@localhost> Archived-At: Subject: Re: [core] KUDOS, PFS and operations considerations 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 Nov 2021 18:59:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Ams=3DC3=3DBCss wrote: > This is a conflict between two goals (provide PFS and enable stateless > operation) that I currently see no easy way out of (other than > introducing variants for either into the protocol) -- do you? maybe this is worth a two page lwig problem statement draft, and then a pun= t to CFRG for help? =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+93Q3WUFAmGVUQoACgkQgItw+93Q 3WW8SwgAvZJEvoKTw+zxitIBYHXAP30H1wccK0AU+yGKgevuWUWeEGHZtvwNtlpm Gvqb+RUAlHt8OGhbbEZgp3rFxsFSD8xG/hkIeioA0ER2PGwksvhtFcKIvGhfTRyY TXPXiNpLSBS57a1+Rid48PDOmADNyThyWWKe9hq3lGK2asv86UmvI0NVfUzwUcp+ kfkEpEVBRlmWahw+JxYyWERqlut5D2cIQV49DUmWdQpq6Y8bIxVgTDJcXRhbr4He 9wLxIDKt3BwdNMA8oCim/+MX7dFph4ednb72Ysn7hZdpMx8BTDeHAhB9caDKZLUb p0R9k307MFyUZ69Z9RHibLGW4KQa5w== =bLRL -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 17 22:36: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 835A63A0542; Wed, 17 Nov 2021 22:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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=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 I3F6FwLah6W5; Wed, 17 Nov 2021 22:36:08 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50083.outbound.protection.outlook.com [40.107.5.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F693A0400; Wed, 17 Nov 2021 22:36:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uym2FVF3SSD2oKsxLMVLyP7k8IQRIW0iZJGC9pJm174/KlCUoTvWhEJO6XG4Qb5UhPLFpRL1z03KkS5R1PsVZgjXAz7f08ai2Zz9DRiqwEE1/ogbuR6lNHBuWm5zDtCdcERjYVVUplgcokt98zdJrVMi1Mg2agS4b537+xzq2tlW6fFWsdnIk+TiypsEuz8CaVOfQTFNVEHY8HOpW8eiBCn/HcllTrXlpahiFAdKL/LH3cCwCx6Oa8FJJlKs1BGY8Rgl9leSUohuUkH6iVgGPCTw+mYgUd0+87tXeK1td/8qiPtxc+70/93jljq9Tx+lonF9E2jofeY9ZwtPEKTN3g== 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=ZHF6fswXBEniyYVqQ4X8jNNLNLl3sRGemQBnnWfdBps=; b=ex5tbyrOTkGzSUqmdl7AI+lCg6o3xW+vw/GEHed4MjHFgA7MdBGBYxy3qgoaiem6QT+TualiS7IaW5tn37Wp/oCzMvrXL8jrNIFVjXNT5m/sV+OXId3exk5DSQY8CYMO5/KoUmwzQT9beCP6vJLB13qbbaKInhA5Xd60T464B8+61xUXxQR3dNvmWyHLstOgnICy4kjCiEI4FNGOcEgr8zoy+6M2ZCOOHzFFvuh3/TL3jUGHqMtLWA7YwWOKHYF25yVh7ZQVu7r+ypIERswCwH/I8E78Ya9Ud1hJThMQ1DCIVRRTUW/L233cZapH1yPOjn602refTd0Vn6huqajfVQ== 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=ZHF6fswXBEniyYVqQ4X8jNNLNLl3sRGemQBnnWfdBps=; b=cKLzEev211oYZuJeX+VYx4z6fmRINfUjyLn/VkCFwpPnG3J3db3LxWyzHQ3sJs3veJ2hqVQmCEVsP+IBgv5L6SkJcBe3ufKsQFcjbNGZEkNT8JZiLF7DGSV7lwPsWxbn0vSbaiH25YRJiAE9/1QcHRTBa9tF/lasDmb38YVuccc= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM4PR07MB3316.eurprd07.prod.outlook.com (2603:10a6:205:5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.9; Thu, 18 Nov 2021 06:36:02 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::7dea:b76c:191:ec29]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::7dea:b76c:191:ec29%11]) with mapi id 15.20.4734.010; Thu, 18 Nov 2021 06:36:02 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: =?iso-8859-1?Q?Christian_Ams=FCss?= , "draft-hoeglund-core-oscore-key-limits@ietf.org" , "core@ietf.org" Thread-Topic: [core] KUDOS, PFS and operations considerations Thread-Index: AQHX294UPnsF0iTPZk6ravxX6Tw9HKwIz/QQ Date: Thu, 18 Nov 2021 06:36:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 05f37391-6b83-4ca4-b861-08d9aa5db0cb x-ms-traffictypediagnostic: AM4PR07MB3316: x-microsoft-antispam-prvs: 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: RtxxBhwI/I8u0kDmJaELsHHkfbNXb+ValVSM6ZwjhEtm6rUwxNk2MeI9aCVz+ZNw0yClHWV0jNDKiy9zaLmcxiVBQHldn1w08iN3TEeEMHMgcs4OqeG0COO8JeJWQg9aSikefxtdvuq1GhjTZNLQ3m9EWtoL0oirNwBSh7eO5IAauEnEDknME7cuN5f3qB7vu+ILWnTs5SJhzHFu+Ivf3pZtEzCfU1+2Etv6VwPGvIPNX0D4S7GsHxupOJ2g85OxksfFzHF0dsE3Vs3GNVTEDLJXUnuFqCcg+WnsjYxecR2qqopKrDGD9Bp5bXYzsDPT2LcbIQ0zb1Kw6KRiJurknviiu3SZ5VwuCyj04HiQ7kpIDfGrMgtpJbjDHO+MiE2pdLw14VJ64b0d47udsYnutC69KGKGCY4j7iEAHAl8eZFLocR+ugFyuQUwqUUve3dN91x8U0xPwH+kHbz3dketfLd0PML5MgctpCd0jpuaRBJIQWMFIjhni355pw6jvXjMHj4GjQ98mA7B3pubiR3TrW/cT96WaMjhqNvdCTSLsvPW8QV+zt2LWLhYZk7S6uOc5GD2k/DkwRC2ZgPclGoZcirkFQ7Rbgq/cZmkj30mPFsHJ9diUICF6bVVtRVDTra5EbOa/c63CYXpXe4Ljdf+gZ4xF2N5Ri8C7mTtVq15vLAQevbw+07LrNpLuuMtJp5clRksSoXqr+gKIYhOmvuEEQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(66946007)(66476007)(52536014)(82960400001)(508600001)(71200400001)(6506007)(26005)(53546011)(122000001)(5660300002)(316002)(33656002)(55016002)(110136005)(2906002)(9686003)(8676002)(66446008)(64756008)(66556008)(91956017)(66574015)(38100700002)(83380400001)(76116006)(38070700005)(8936002)(7696005)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?zu/3Xe/JaAwBd16iDcz2r2cMEAsiHcNz2Pvm70kqhKbmWqbnKyieJ0Qiem?= =?iso-8859-1?Q?dd48cbVRm81Olq6oLFz2TXX9nJW4DPRm1jXK2/BrFHOwPYE6jVIzblOQty?= =?iso-8859-1?Q?lDUVr9pdE251VUMkWus3P7+hV0fEYNEgJT1NDe2gokaAAFx1ilEs0ayOHP?= =?iso-8859-1?Q?0fXF5A2yxJiMgbozfNJW3SO0fncivO1yGKkXZBCwRyMERUHBA+JL+bhsep?= =?iso-8859-1?Q?qZjjjqmqSXoH1EKbiSX0ZkKfjQ9sAPla076eqCs37ybbAsQDpA+L0KmzL+?= =?iso-8859-1?Q?xtEcBEyK54Oo+k1Npy3lVCvh0CLSW2y4G5Zu3BwjPXX+EauzOy7c8qh5xt?= =?iso-8859-1?Q?33jOCVroFOR8zLuqgr7g60OEZJ59LhkKsvyUCnlF/e3lZp20I9EIeZubDQ?= =?iso-8859-1?Q?vJM2Sk8UCcIO+ofX/li2sxopWPuuZdbzvRnqrcvOdPCuqgTgClY5MC1uly?= =?iso-8859-1?Q?nb5EkybdJIeVrrE3oTW7QCW3lLWkF430Gaot6DcTc4jLS3PggO0WXXgwm9?= =?iso-8859-1?Q?Ho0hHDrZatGPtiAHB/QZ6bg2K9y/Bo6UGU2XVhHmz5QSIhu7bYd4O9hfvZ?= =?iso-8859-1?Q?S3xra+guB63MN4EgNpZPxZdflyUllUlZqwuhuvWZjdhjmIrVqY9yuWjJ+G?= =?iso-8859-1?Q?MWXNLD2jkKumqg2sicG6NaaQ3l7K+PedzS756nz50ATV1+cCyLtlk7c49i?= =?iso-8859-1?Q?3fg40+hOewlwPE4QC9oqoDCKZ/hXpK6nr4TMogGs2b3sbMEh+RXSQRFS9Z?= =?iso-8859-1?Q?jtWcNAp3q4SvWJcHHyoxTQdJI/NHA0XjtyM9jHdbW6qEr5gwZwj7hQE5lo?= =?iso-8859-1?Q?DLkJP8Wz18ANvaWYq9jkOG2g8Q7Elzu7k5MFNNy8Bw4DiyptqRtnnAGm07?= =?iso-8859-1?Q?XjD1kAJt9yMlrs9U0iWiva/BybOhXDQ/OxRIrg+ATVDn3Qsi5Kw3zRzqM0?= =?iso-8859-1?Q?RUy71qLoZyqKTDcJz3fA2v89JMbQdeld9M9quZJWWq9oM8re9l/MIHo0Dg?= =?iso-8859-1?Q?boy3rkcX9l1GUnAiHpmp3MFrvCyECAmzy//v0NZuiXphj107DripJsYu6S?= =?iso-8859-1?Q?heAsOjs/ksOeXK/5qI3Y7A2mzBlYGgP5iSgkHw1Fl7jRVnKyjgqM+dEKTF?= =?iso-8859-1?Q?FgMjr7cu43vPCwI0rzb4T0M0LAmS9J2oKuP73cjtDwmOVxL2PIophJOol9?= =?iso-8859-1?Q?ZcAlYM+uQ1PCQqbbYgMNbAigTWh7BG1GcrRJWR+owE3EDtvWxpNm/UadWT?= =?iso-8859-1?Q?j8IGDjL386SAdjNZKXzrkLWKGCb7ZcZuP6Ymquy4Ba6N/zS3pGyoE37z4A?= =?iso-8859-1?Q?UlYFsvwQwhugCbXB6jdIUGLRLKK2QmeTHrY+mdFHkp2wrFTWsQJiCuCHgE?= =?iso-8859-1?Q?qSWTBg2K13VzC+NkmabNsp/klioni/fILyPTPQeXq1OcWoHUH9b2tgYDHN?= =?iso-8859-1?Q?g4bCXxHQcxsdTp8YQGWvcFad8O59xMXuvDR4AXvgAh7FUIaoATg0unOsyD?= =?iso-8859-1?Q?Nx5cbe9chsMOu0Hvzw8+mYmAbtUbzOx28yWGp8adsTq/JbKPjo8yfnr+BJ?= =?iso-8859-1?Q?bT4tmvaBIgV4Q1Ig9e2X0/dkSIM1AUco61dU5Uyvsr1xtKUQdVwlxMdEhW?= =?iso-8859-1?Q?cFx5DyafVzC0ENXC6lhD2skku4m12Zn+jnZnfYLJWoufAOL+pq6DbMTZUm?= =?iso-8859-1?Q?b5jQozrkHOpv/IkUlbYHKMVGqExY4Tx/XFqCl5wf4TP1mDZsMB2cs9Kqi4?= =?iso-8859-1?Q?2Dn/J9aXfsmajmmYyGGKa7OLs=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB21954E6AF7631D0ABDE18127F49B9AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 05f37391-6b83-4ca4-b861-08d9aa5db0cb X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2021 06:36:02.2418 (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: I8dnaIgcqIcPr83e8J3DbP41ZIuG21Ta7BxF07e1mvtMqAlX/Nvu9qOiYRR98jzOylzYnY2OTESVAZV8ODRGciaxyO3OFGPW0ldO9SM2G+M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3316 Archived-At: Subject: Re: [core] KUDOS, PFS and operations considerations 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 Nov 2021 06:36:15 -0000 --_000_AM4PR0701MB21954E6AF7631D0ABDE18127F49B9AM4PR0701MB2195_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christian, Thanks for raising this point. > This is a conflict between two goals (provide PFS and enable stateless op= eration) ... I suppose the constraint to keep the overhead down also come in here. > ... that I currently see no easy way out of (other than introducing varia= nts for either into the protocol) That is something worth exploring in parallel to trying to find an common s= olution. In combination with the change of connection IDs, this is now starting to w= arrant a breakout session. G=F6ran From: core on behalf of Christian Ams=FCss Date: Wednesday, 17 November 2021 at 19:08 To: draft-hoeglund-core-oscore-key-limits@ietf.org , core@ietf.org Subject: [core] KUDOS, PFS and operations considerations Hello KUDOS authors, looking through the current state of KUDOS (compared to earlier discussions, and prompted by the trackability discussion coming out of EDHOC), I noticed that KUDOS nowadays discards old key material. This is nice in that it ensures that old conversations can not be deciphered from key material obtained from one of the participants later, but raises operational concerns, especially aiming to replace B.2: OSCORE keys are notoriously difficult to back up (or distribute for high reliability); in that, they behave like the stateful signing keys of HSS/LMS. A backup can only be done if the backup is replaced before the sequence number reaches a committed point (eventually stopping the running system if the backup system fails). For a distributed JRC, this is about as hard as persisting the mapping between old and new ID Context values. On embedded implementations, using OSCORE requires a device that starts up to commit something to flash memory after startup, which is an operation preferably avoided. Appendix B.2 provides a way out of this -- a device that doesn't want persistent commitment would just always do B.2 on startup and thus always start sequence numbers from 0. KUDOS as currently described helps a bit here (in that the first request can be sent without flash operations), but then requires persisting CTX_NEW and removing CTX_OLD. The new context needs to be persisted at latest before sending any second request, because if it's not, the peer may drop the old context and they have no chance of syncing again. Thus, it's not really helping to circumvent that impracticality. This is a conflict between two goals (provide PFS and enable stateless operation) that I currently see no easy way out of (other than introducing variants for either into the protocol) -- do you? BR c -- To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --_000_AM4PR0701MB21954E6AF7631D0ABDE18127F49B9AM4PR0701MB2195_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Christian,

 

Thanks for raising this point.

 

> This is a conflict = between two goals (provide PFS and enable stateless operation) ...

 

I suppose the constraint to kee= p the overhead down also come in here.

 

> ... that I currentl= y see no easy way out of (other than introducing variants for either into t= he protocol)

 

That is something worth explori= ng in parallel to trying to find an common solution.

 

In combination with the change of connection IDs, this is now startin= g to warrant a breakout session.

 

G=F6ran

&nbs= p;

&nbs= p;

From: core <core-bounc= es@ietf.org> on behalf of Christian Ams=FCss <christian@amsuess.com&g= t;
Date: Wednesday, 17 November 2021 at 19:08
To: draft-hoeglund-core-oscore-key-limits@ietf.org <draft-hoeglun= d-core-oscore-key-limits@ietf.org>, core@ietf.org <core@ietf.org><= br> Subject: [core] KUDOS, PFS and operations considerations<= /span>

Hello KUDOS authors,

looking through the current state of KUDOS (compared to earlier
discussions, and prompted by the trackability discussion coming out of
EDHOC), I noticed that KUDOS nowadays discards old key material.

This is nice in that it ensures that old conversations can not be
deciphered from key material obtained from one of the participants
later, but raises operational concerns, especially aiming to replace
B.2:

OSCORE keys are notoriously difficult to back up (or distribute for high reliability); in that, they behave like the stateful signing keys of
HSS/LMS. A backup can only be done if the backup is replaced before the
sequence number reaches a committed point (eventually stopping the
running system if the backup system fails). For a distributed JRC, this
is about as hard as persisting the mapping between old and new ID
Context values.

On embedded implementations, using OSCORE requires a device that starts
up to commit something to flash memory after startup, which is an
operation preferably avoided.

Appendix B.2 provides a way out of this -- a device that doesn't want
persistent commitment would just always do B.2 on startup and thus
always start sequence numbers from 0. KUDOS as currently described helps a bit here (in that the first request can be sent without flash
operations), but then requires persisting CTX_NEW and removing CTX_OLD.
The new context needs to be persisted at latest before sending any
second request, because if it's not, the peer may drop the old context
and they have no chance of syncing again. Thus, it's not really helping
to circumvent that impracticality.


This is a conflict between two goals (provide PFS and enable stateless
operation) that I currently see no easy way out of (other than
introducing variants for either into the protocol) -- do you?

BR
c

--
To use raw power is to make yourself infinitely vulnerable to greater power= s.
  -- Bene Gesserit axiom

--_000_AM4PR0701MB21954E6AF7631D0ABDE18127F49B9AM4PR0701MB2195_-- From nobody Thu Nov 18 09:40: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 A8BCD3A08FF; Thu, 18 Nov 2021 09:40:00 -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.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163725720063.22255.15959643972449819150@ietfa.amsl.com> Date: Thu, 18 Nov 2021 09:40:00 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-18.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: Thu, 18 Nov 2021 17:40: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 : YANG Schema Item iDentifier (YANG SID) Authors : Michel Veillette Alexander Pelov Ivaylo Petrov Carsten Bormann Michael Richardson Filename : draft-ietf-core-sid-18.txt Pages : 41 Date : 2021-11-18 Abstract: YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-sid-18.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 18 09:51:32 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 DC13D3A08ED; Thu, 18 Nov 2021 09:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, T_FILL_THIS_FORM_SHORT=0.01, 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 wM8FU7L0AH_o; Thu, 18 Nov 2021 09:51:26 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABA63A08EB; Thu, 18 Nov 2021 09:51:24 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Hw6mV1gHzz2xt5; Thu, 18 Nov 2021 18:51:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162621573715.1426.3300364400283622807@ietfa.amsl.com> Date: Thu, 18 Nov 2021 18:51:21 +0100 Cc: The IESG , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , jaime@iki.fi X-Mao-Original-Outgoing-Id: 658950681.859742-b58612efb990ccf2b087b600cfc9ae9e Content-Transfer-Encoding: quoted-printable Message-Id: <5F4E288F-668F-40E3-A0EC-E913C20C6418@tzi.org> References: <162621573715.1426.3300364400283622807@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (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, 18 Nov 2021 17:51:31 -0000 Hi Ben, here is our response, but to the 2021-10-16 updated version in the = datatracker (thanks for this). We have prepared an updated core-sid document at: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ https://www.ietf.org/archive/id/draft-ietf-core-sid-18.html https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-sid-18.txt > Discuss (2021-10-26) > (1) I think there is a new security consideration with this work that = is > important to document clearly -- not only do we define a new type of > identifier, but we define a file format and other mechanisms for > disseminating that information. An entity that's processing > application/yang-data+cbor; id=3Dsid information needs to ensure that = the > .sid files (or other source of SID information) it uses for such > processing came from a trustworthy authority (or at least the same > source as the data file). It would be possible for malicious > manipulation of .sid file contents to cause a message recipient to > mis-interpret the received message without any indication of such > tampering. > [ed. there seems to be some proposed text in >=20 > = https://mailarchive.ietf.org/arch/msg/core/JS0uD9aUNwim_fwhBpGnZut9kns/ > ] Indeed. We have slightly improved on the text in that discussion;=20 https://github.com/core-wg/yang-cbor/pull/102 > (2) Per =C2=A77.4.2, YANG SID range registries with public ranges MUST > include a reference to the ".sid" file for such ranges, but the > IANA-managed YANG SID range registry established by =C2=A77.5 does = not, in > and of itself, make such a provision. This function seems to be = served > by the "IETF YANG SIG Registry" created by =C2=A77.6, so we may just = need to > point to the one registry from the other in order to remain internally > consistent. Right, we added more explanatory text and a pointer. https://github.com/core-wg/yang-cbor/pull/99 > (3) There may be another inconsistency to look into; Section 7.6.2 = says > that: >=20 > * If another ".sid" file has already allocated SIDs for this YANG > module (e.g. for older or newer versions of the YANG module), the > YANG items are assigned the same SIDs as in the other ".sid" = file. >=20 > But we are supposed to allocate a new SID for a YANG item if its > semantics change in a revision of the YANG module. Perhaps it's just > the "for older or newer versions of the YANG module" phrase that needs > tweaking? We toned down the need for allocating a new SID quite a bit; see updated = appendix B. The point of the text here is to say that existing allocations stay in = place; the exceptions listed in Appendix B notwithstanding. > Comment (2021-10-26) >=20 > Would RFC 8792 folding be suitable for Appendix A rather than using > a custom scheme/disclaimer? We don=E2=80=99t think so. The appendix is an illustration, not = something one would extract as sourcecode to work on. The line-breaking scheme we used is noiseless; you cannot say this of = RFC 8792. We added a script that removes the added newlines and indentation in = https://github.com/core-wg/yang-cbor/pull/116 > I see that most mention of what to do with SID assignments if the > semantics of a node (name) changes, or a node name changes without > changing semantics, has been moved to Appendix B. I'm not sure if > it's helpful to retain some mention that this discussion exists, > in the main body text (e.g., Section 1). Section 1 now points there and mentions manual interventions. https://github.com/core-wg/yang-cbor/pull/97 > [The rest of this COMMENT section populated by taking the comment = section from the -16 > and removing a small handful of things that are clearly addressed. > Some items that are retained may have been addressed as well and no > longer applied] >=20 > The yangdoctors review mentioned the structure extension from RFC = 8791, > and the authors (understandably) expressed reluctance to make such a > large change at this stage in the process. I'll note that the DOTS WG > has recently completed work on a "bis" of RFC 8782, with primary aim = of > replacing yang-data with structures and minimal other changes. (A > yangdoctors review of a related document was sufficiently insistent = that > structures are the right way to do this that the WG was convinced to = put > in the effort.) We changed the ietf-sid-files module to use sx:structure. https://github.com/core-wg/yang-cbor/pull/116 (I don=E2=80=99t think we can validate the sid file example any more = after that change. Can we?) So this is about the documents=E2=80=99s *use* of rc:yang=E2=80=94data = migrating to sx:structure. As far as showing sx:structure examples with encoding from YANG-CBOR: We plan to set up another document with that, metadata, etc. > The yangdoctors review also asked why sid-file/module-name is = optional, > which was tagged for follow-up. I have the same question and am > interested in the outcome of the discussion amongst the authors. The authors agree that it needs to be mandatory. Also in https://github.com/core-wg/yang-cbor/pull/116 > If SIDs are supposed to be globally unique identifiers, the reference = in > the YANG module to "namespace" identifiers for individual allocations = is > puzzling to me. The presence of a namespace would typically allow for > identifier reuse across namespaces (e.g., using the same SID integer = value > for an identity and a data node within the same module). I see how = the > current list structure makes it easy to have a single flat list of all > identifier/sid mappings, but if the SIDs truly are globally unique, = then > the "namespace" should not be a list key, and might be less = confusingly > described as just indicating the type for which the SID is used. (It > would also be possible to have separate lists for module SIDs, = identity > SIDs, etc., but it's not clear that doing so is actually the right > approach.) We apologize that we are as confused about namespaces as Section 6.2.1 = of RFC 7950 is=E2=80=A6 SIDs are needed for some of the names in these (Section = 6.2.1)-namespaces, and it is useful to identify which namespace is meant = in the SID file. We can leave out some namespaces such as the ones for = grouping names, as these are not directly encoded. Since the same name can be used in multiple namespaces, we need multiple = entries in the list =E2=80=9Citem=E2=80=9D for the same = =E2=80=9Cidentifier=E2=80=9D, and so we need to include the namespace in = the key (which also gives us a check that an identifier is not assigned = a SID twice in the same namespace). The (local) uniqueness of the SID = is separately checked by the =E2=80=9Cunique =E2=80=9Csid=E2=80=9D=E2=80=9D= statement. > Section 4 >=20 > If the scope of a sid-file-version-identifier resets when the module > revision is bumped, it seems highly unlikely that we'll need 64 bits = of > identifier for it. Fixed (now uint32) in https://github.com/core-wg/yang-cbor/pull/84 > Section 5, 7.3 >=20 > It's not entirely clear that we need to mention the > content-type/content-format in this document, as we only indicate use = of > the JSON encoding for the .sid file and the use of SIDs in the > application/yang-data+cbor; id=3Dsid case seems adequately described = by > the existing treatment in draft-ietf-core-yang-cbor. This was meant more as a cross-reference in case one wonders where to = find the IANA registration, but IANA doesn=E2=80=99t need that, so it = should not be in the IANA Considerations section. We removed it. https://github.com/core-wg/yang-cbor/pull/117 > Section 7.4.1 >=20 > I appreciate that the "mega-range" allocations are sized for the > appropriate SI prefix :) We discussed decimal vs. binary a lot and decided that, since the = registry structure is mainly for humans to look at, we=E2=80=99d stick = with decimal ranges. There appears to be very little coding efficiency that could be gained = by going to binary range boundaries. > The information associated to the Organization name should not be > publicly visible in the registry, but should be available. This > information includes contact email and phone number and change > controller email and phone number. >=20 > Available to whom? We removed this overspecification in = https://github.com/core-wg/yang-cbor/pull/98 > Section 7.5.2 >=20 > In case a SID range is required before publishing the RFC due to > implementations needing stable SID values, early allocation as > defined in [BCP100] can be employed. As specified in Section 4.6 of > [RFC8126], RFCs and by extension documents that are expected to > become an RFC fulfill the requirement for "Specification Required" > stated in Section 2 of [BCP100], which allows for the early > allocation process to be employed. >=20 > While the first bit of this is all true, the registry here doesn't use > the "Specification Required" policy for any range, and early = allocations > are available for the "RFC Required" range. So we should probably = tweak > or remove the second sentence. Indeed, this should have been "RFC Required=E2=80=9D. Addressed in https://github.com/core-wg/yang-cbor/pull/103 > Section 7.6.3 >=20 > Early Allocations are made with a one-year period, after which they > are expired. [BCP100] indicates that at most one renewal may be > made. For the SID allocation a far more lenient stance is desired. >=20 > 1. An extension of a referencing documents Early Allocation should > update any referenced Early Allocations to expire no sooner than > the referencing document. >=20 > 2. The [BCP100] mechanism allows the IESG to provide a second > renewal, and such an event may prompt some thought about how the > collection of documents are being processed. >=20 > The first point is rather curious, since it can have no normative = force > (this is not a BCP that would override BCP 100) and is merely a > continnation of how a more lenient stance is desired. It's rather odd > to see it written in this way. The second point seems to be the only > really useful part, and in practice this IESG approval of second (and > more!) renewals has become rather common, to the extent where a = revision > of BCP 100 has been discussed to change the discussion of extensions = for > early renewals. >=20 > This is driven by the very generous size of the SID space and the > often complex and deep dependencies of YANG modules. Often a core > module with many dependencies will undergo extensive review, = delaying > the publication of other documents. >=20 > Having many *dependencies* and taking a while shouldn't delay > publication of anything else; however, having many other modules > dependent on a core module would be likely to do so. This is a useful discussion, but it is not quite clear to the authors = what we should change. Clearly, this is an uncovered check on the = future of BCP100, but it is not clear what we should do now. (Of = course, we could change "RFC required" into Expert review and instruct = the Expert to act exactly as defined above, but I=E2=80=99m not sure = IANA would be happy about Expert-generated provisional registrations.) > Appendix A >=20 > IIRC the mismatch between "ietf-system@2014-08-06.yang" and the = toplevel > "module-revision" of "2020-02-05" was noted by an earlier reviewer, = but > I'll mention it here just in case I do not remember correctly. This (together with the module-revision of ietf-sid-file itself) is now = updated. A task to make a final pass through all the version numbers when all the = dust has settled is at https://github.com/core-wg/yang-cbor/issues/66 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Nov 18 16:12: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 EE7933A0C32; Thu, 18 Nov 2021 16:11:50 -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, PDS_OTHER_BAD_TLD=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 7uXrM_3dnNq3; Thu, 18 Nov 2021 16:11:46 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49093A0C61; Thu, 18 Nov 2021 16:11:40 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HwHCF2WfQz2xn7; Fri, 19 Nov 2021 01:11:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162619194652.5730.10916340155265302741@ietfa.amsl.com> Date: Fri, 19 Nov 2021 01:11:37 +0100 Cc: The IESG , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi X-Mao-Original-Outgoing-Id: 658973497.208443-b502f8105794bdc74d899169d40d28e9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> To: Robert Wilton X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (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: Fri, 19 Nov 2021 00:11:55 -0000 Hi Rob, We have prepared an updated core-sid document at: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ https://www.ietf.org/archive/id/draft-ietf-core-sid-18.html https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-sid-18.txt > On 2021-07-13, at 17:59, Robert Wilton via Datatracker = wrote: > [=E2=80=A6] > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Hi, >=20 > Thank you for this work, I believe that it likely to be useful, = perhaps not > only for constrained devices, it may also turn out to be popular for = streaming > telemetry. >=20 > There are a couple of points that I would like to see discussed and = perhaps > addressed: >=20 > (1) I would like further discussion regarding whether SIDs are bound = just to > the schema name, or the schema item definition. The draft states that = if the > definition is changed in a non-backwards-compatible (NBC) way then a = new SID > SHOULD be allocated. But I don't understand how this will work. = Given that > the .sid file would then contain exactly the same path but with = different sids > assigned (for every time the meaning of the definition changes), then = how do > consumers of the sid file know which sid to use for a given path = (given that > there is no indication in the .sid file)? Instead, I think that this = is the > wrong way to be handling NBC changes, and SIDs should be bound only to = the > schema path (i.e., the name of the item), and a new SID is only = allocated if > the name/path changes, and otherwise the same SID is used, even if the > definition changes in a non-backwards-compatible way. We have toned down the need for allocating a new SID quite a bit; see = updated appendix B. The point of the text here is to say that existing allocations stay in = place; the exceptions listed in Appendix B notwithstanding. Now it seems to me that you are arguing for a more mechanistic rule: = essentially a bijection between SIDs and (namespace, name) pairs. This = takes away the possibility to =E2=80=9Coptimize=E2=80=9D the renaming of = an identifier by keeping a SID, or a change in the semantics of a name = by allocating a second SID. But the rule would sure be simpler, and = taking away some of the discretion now afforded in Appendix B by = creating a simple mechanism. (It would not be a very strict bijection =E2=80=94 anyone can create a = SID file for a module where one already exists, out of ignorance, = malice, or technical reasons; the expectation is that owners of modules = will want to make sure their SID file is prominent.) > (2) I think that this document should be clearer as to the = relationship between > SIDs and submodules (more details in the comment). We essentially removed submodules from the document (well, they are = still in the term import list, because the parallel yang-cbor document = needs to say: >> Note that any structuring of modules into submodules is transparent = to YANG-CBOR: >> SIDs are not allocated for the names of submodules, and any >> items within a submodule are effectively allocated SIDs as part of >> processing the module that includes them. ). >=20 > (3) This draft makes use of the rc:yang-data extension. Was there any > discussion about using "YANG Data Structure Extensions" (RFC 8791) = instead, > which is meant to be a cleaner formulation of the rc:yang-data = extension, and > without the dependency on RESTCONF? I would suggest that using RFC = 8791 would > be preferable if possible. We changed the ietf-sid-files module to use sx:structure (RFC 8791). https://github.com/core-wg/yang-cbor/pull/116 (I don=E2=80=99t think we can validate the sid file example against the = module after that change. Can we?) (The above is about the core-sid documents=E2=80=99s *use* of = rc:yang=E2=80=94data migrating to sx:structure. As far as showing sx:structure examples with encoding over in the = yang-cbor document: We plan to instead set up another follow-on document with such examples, = rules for encoding metadata, etc.) > (4) The policy in 7.4.2 for allocation a SID mega-range seems to = aiming this > towards organizations rather than individuals. The policy in 7.6 for = the "IETF > YANG SID Registry" requires an RFC. What is the mechanism if an = individual or > open source project wanted to get SIDs assigned for some of their YANG = modules? > I.e., should we be defining a separate mega-range, managed by IANA, = with just > Expert Review or Specification Required so that these modules could = use SIDs > allocated? Or do you envisage a separate entity taking up the = responsibility > for coordinating this? The mega-range concept means there can be more than one such entity. https://comi.space is a proof of concept for how such an entity could = operate. I=E2=80=99d expect at least one of the organizations in the YANG = ecosystem to pick this up and become such an entity. Whether IANA also wants to be such an entity (beyond its role for IETF = modules), I don=E2=80=99t know. To demonstrate that we are entirely on the safe side, I=E2=80=99ve also = written a PoC for a organization-less approach (leveraging IANA PENs): https://datatracker.ietf.org/doc/draft-bormann-core-yang-sid-pen/ I=E2=80=99m not sure we want to pursue this; the advantage is a = low-threshold (and low-disclosure!) way to get a sizable SID space; the = disadvantage is that we would lose people who otherwise would have used = services such as comi.space that make the registrations much more useful = to the community. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1. Regarding the relationship between sids and submodules, I think is = best > summed up by this comment in the appendix: "Note that ".sid" files can = only be > generated for YANG modules and not for submodules." I.e., I don't = think that > sids should be allocated for the name of the submodule, and any items = within a > submodule are effectively allocated sids as part of processing the = module that > includes them. This topic should be addressed early in the document, = and > probably the existing references to submodule in the introduction and = the YANG > module can be removed. See above. Do we still need text here, or is the text over in yang-cbor sufficient? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 24 09:49: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 A3AEE3A08FF; Wed, 24 Nov 2021 09:49:06 -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 j9GKb2uj7HcI; Wed, 24 Nov 2021 09:49:02 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E175F3A08F9; Wed, 24 Nov 2021 09:49:01 -0800 (PST) Received: from dooku.sandelman.ca (cpef81d0f835a73-cmf81d0f835a70.sdns.net.rogers.com [174.115.215.42]) by relay.sandelman.ca (Postfix) with ESMTPS id C7CC91F455; Wed, 24 Nov 2021 17:48:57 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3F2BB1A0E37; Wed, 24 Nov 2021 12:48:56 -0500 (EST) From: Michael Richardson To: Esko Dijk , core@ietf.org cc: Sheng Jiang , "anima\@ietf.org" , Peter van der Stok In-reply-to: References: Comments: In-reply-to Esko Dijk message dated "Wed, 24 Nov 2021 11:32:03 +0000." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Wed, 24 Nov 2021 12:48:56 -0500 Message-ID: <80674.1637776136@dooku> Archived-At: Subject: Re: [core] [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming 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 Nov 2021 17:49:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Esko Dijk wrote: > I checked the new version against my review comments; and the followi= ng > comment is still open =E2=80=93 this is where Peter and me disagree. understood. I have no real opinion. > core.* - CoRE WG types > ace.* - ACE WG types > brski.* - ANIMA WG types for BRSKI =E2=80=93 not yet in the registry = but specified in > draft-constrained-voucher. > oic.* - any types specified by OCF/OIC > fa.* - any types specified by Fairhair Alliance > Hence my request to comply to this convention, however undocumented it > is today. Any system architect would agree to that seeing the current > list. Can we ask core@ to review and comment then? original message: https://mailarchive.ietf.org/arch/msg/anima/s9yU6LPnV8pE1= 7Ws2xjH2f0mrO0/ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmGeewcACgkQlUzhVv38 QpAaTwgAk5fEyscthZz0PT7edhXgi89aBQ/T89JcmUiB98ldst0htSsN+WwLzDEl cwghEiyHQPCFDir205x0HR/IZWCWIxlY2TqjOYinuHO4T5R6SYtgZbcz6BhFWhKx 8Av4vEOmBGY73j21pnm8Gmni3nR93rizrzChWaDcrex/RP/I3LbFe3i8iavNI2LU x7W8LvAdRY26FPnPAS3LyONDf+kltTIUJRotzEZqC41X+xNaxo3w0jxAaeZCzJIH 6jIQONOPCKDnCCcIulMhxZsmkCXTivra2BHpCbnEnH9cq7/AbsAX3/MaWli7+IXo ZRMGpeq6Ho31nE/AFPoKJH9qUxDM+w== =WVG3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 26 08:53: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 2EEB53A079C for ; Fri, 26 Nov 2021 08:53:16 -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 mR8TUdbpUEGl for ; Fri, 26 Nov 2021 08:53:11 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B2C3A0824 for ; Fri, 26 Nov 2021 08:53:09 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4J115V1JgVz2xPN; Fri, 26 Nov 2021 17:53:02 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <26071.1636758136@localhost> Date: Fri, 26 Nov 2021 17:53:01 +0100 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 659638381.567704-2a522e84fe6c4f2d296cb8468ebdecf6 Content-Transfer-Encoding: quoted-printable Message-Id: <6B53AFDD-E199-4498-86EC-3AFE668C16D7@tzi.org> References: <304B093F-12D4-40BA-8922-DBFAFE4C17D6@akamai.com> <26071.1636758136@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [Acme] get-as-post draft 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 Nov 2021 16:53:16 -0000 On 2021-11-13, at 00:02, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Salz, Rich wrote: >> The WG here might find this draft interesting: = https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-bod= y-02 >=20 >> Abstract >=20 >> This specification defines a new HTTP method, QUERY, as a safe, >> idempotent request method that can carry request content. It is quite satisfying to compare the timeline graphics in: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/ with https://datatracker.ietf.org/doc/rfc8132/ Just saying=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 29 02:17: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 254ED3A0035; Mon, 29 Nov 2021 02:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEyngyxThLCI; Mon, 29 Nov 2021 02:17:15 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60130.outbound.protection.outlook.com [40.107.6.130]) (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 486923A0028; Mon, 29 Nov 2021 02:17:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C2bu1HoovhXw9+YMM23ZkJ21CXqZG8VuhfZNcG3Cl+8Lwf2xEMbFxY4p9v6TVDudQqSJEbiZEpChWqZ1pvMMSI139d1kayjeXFXSUcVZaLSZEiKI3S62Ln87SL13dYQIm1puCJ5Tzmtw8Z3t5ARkhNPdFU1irfqEANhZskOG9dszY0c7mht39JNzF+u6/H8UFmMvEX5wf+vGFBjrRRRnXuzI5Cn7zAH8mBskXLW1rIhXvVUPXw24d/OBKgHIMyvDh5tbSCC1cy3Fm4EMPQbEsP/fnhRdCetQnUdeVnWb6lcUEVxy7Hy+o7D+RYAgpDcE8sa0sLCmm5AOanBeGHHBQw== 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=4MWsemjOYWEYelEXW8hJ/LsZdUEOGn5Q2CgJjGISTY4=; b=Gz7OkHTe/2PxyR2w5L/y1EvF8hi3PHgfHj1Yq2RaWbJpRbjWgVOWEas8s2TrOLIOmMPhPqke8WAvk0P0h4JwP9RZARuc7WBif3rCEt5w5IljYqGthv5iPFDdtgEsqfqimk2c4elND7CSU+nEg16cBzZGJqfeGmZoAGPlyKjlW9Y5hjm8fiNsbOnlXTBpMv3ACnbMM2jlRW0exPhwDE4Oy0yGaOBA6M0m9mLTOaxuqqFxzbLQklKnkabGEqlibTjLpeQ4ixmeVcYiZylKORZ8heiia2PWVx4j3C2uvNwnDgri1s7ziuGIpGWUujkqnPBvWjfo2yMc1NWaRIExw7+AnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4MWsemjOYWEYelEXW8hJ/LsZdUEOGn5Q2CgJjGISTY4=; b=t3ih2JOTavK09ki1w7HEmSB7qzjlucof3OOchjmph1cXpZuJn9cNwFbdu+wuc3xteyxbrqRuRUrG3A/RWQskScH8e7OOJoqZITEYRKijkUzH8Y5oRr/4acRXjjIMgySiUF1x6/I0XEwoWj+ighN7EZrhAwPiFSH0ve9Pwuq/Ajo= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0643.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20; Mon, 29 Nov 2021 10:17:12 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8%8]) with mapi id 15.20.4734.024; Mon, 29 Nov 2021 10:17:12 +0000 From: Esko Dijk To: Michael Richardson , Peter van der Stok CC: "anima@ietf.org" , "core@ietf.org" Thread-Topic: [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming Thread-Index: AdfhJnPx9ouoruebQZCUwRi2dyPFRgANRlgAAOtpNHA= Date: Mon, 29 Nov 2021 10:17:12 +0000 Message-ID: References: <80674.1637776136@dooku> In-Reply-To: <80674.1637776136@dooku> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca85143c-5ed0-46ec-7d2b-08d9b3216906 x-ms-traffictypediagnostic: AM0P190MB0643: x-microsoft-antispam-prvs: 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: fm+hokP1tXQCPYeUI9y0k5984IOWOoIRmFh8g+M3bCdKZSmP5VVsXn0FVcugCgaTsYHfgTJSQaWJDLe2QvWbvEAlragD2C4yoJ69FTbKqp3meYN8iXAra8SfAi9EdVTPSHf96zVMSHWkiCB5K6fG7zgzG5waspMIleL2jnr9cysmaMZq7m7t/xwV01rzxaz/gPEpZRilZeJc76jAAcP0KXmXHnQd7J/6bI9kPH+hhFvYbBxfN31VOAvRO11etFSg7dti3IlPSNp1RT1vFWv1CGoC4+tFU2s1cw5m09l7xvvvjWU6UEsDgpi3eU1kCKL7FX9nvbp0x/yAnW8o52zbiuT9T2uvHMuC+2W6S5yuZ3KK6v0mxG6Og0My+7yYL3MYN6qJcvU3aIqyJH3fOJowba8PXk0XnbkaMhC9vMM07yaw59Wp+D3lyva8SoM8/0B9Jf284rOaT2qhxD4h9GEnJcouMlfY0cIHlVbMgw2uDcK9yOvReC7o0fDJxlM7QBckbo5xWSf3bFBEM5iX7ia3Cjr8RA1bQXAT7rm9s53dz8zJ3qSJEaNwTDaGZM8l4owIjT5nIJstBGfqOZgNoxpJmZRinVvJ/76e3XtSyw8VT7ZXs0epx0LH08LFtIf+Db7iACGWsXn79ljMsWU2cCoKgGJgN2AXERBizWfJINn8UtgRtV5DSQYKy+5fSoYmunaObwa5AOKKgvJr0LuofnTG2q7zimqaeMLe/RjgZT7dZzjKZTpjZk8wNmjuYf2V/4LADt4Sn3hITAFS6FBFkiAzgz49nv83zLcp9vI4apO1/VM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(346002)(396003)(39830400003)(376002)(366004)(38070700005)(55016003)(83380400001)(71200400001)(86362001)(7696005)(66946007)(38100700002)(4326008)(44832011)(9686003)(66476007)(53546011)(52536014)(8936002)(33656002)(64756008)(66446008)(54906003)(316002)(8676002)(6506007)(76116006)(186003)(966005)(2906002)(5660300002)(122000001)(66556008)(110136005)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZlVPaHFkM3c1S3F3YlNmcVd0WVVkVUtDNE8rdk1MMzJSd01YUVUwTzNjT2t4?= =?utf-8?B?SlRQUy85aDNQclgwWjl3T0FKVUw1bWJXem96cVRSV0hodUsvRWxkSTVEMjM0?= =?utf-8?B?ajF3b0s1a3REZnZQTm1rUnFsN05XVkVxdlN3dnQzZCtscVRNYmdFUG5iRnFz?= =?utf-8?B?V1BsbzN3VUhmZGFVZFQyQ0hmZjU5V25ZQ1RqSlc1cTJ6VHBPaERGVDc4ZnNW?= =?utf-8?B?djB3QmZHeW51NHJIaThWQ3lQREhtaE5Ma3BVckxNUVJ0YjgwZWtBOVIxUU5D?= =?utf-8?B?VkVsNm9BQU1Cd0J4Tkt3WGlHNHBzYlpQOEs2cm5QaEZVZWJCVGZZYWFWeE9M?= =?utf-8?B?M3ltbG92bG9aaHM4azF1U3U3VjE5Q29lak9zR2poMnFoM1ZMU0lNZGRLTlJ5?= =?utf-8?B?UGVxYXdPMDhuTXd5elJuczFDRTNzc1ViUStFOWU3aEV6Wmo0Q3dYYitFM0Nw?= =?utf-8?B?OGQrallXeldQaUxGZlVpVFJLdTUvYk1Vd0ZIV3BwRHBxanM4cGZHRzN4enhY?= =?utf-8?B?MjEzam9mUWtqMmdoYWxUUmtxM3MydmZicTFrZkpvZ3ZYYWVyMW1kNXlLNysr?= =?utf-8?B?UW5TNHYvcXJnb2FqeTlkMHFxaTlEMzZoZ0tsQTNiNnlIc0RqUWJTVFY5VzJL?= =?utf-8?B?RFpNUXBybVVnZk5zTTdadzREeGdwVDBXS1ViU0gwZUZNaXVmODN6Q05FNUVB?= =?utf-8?B?RTdMcVkxMXM2alFQc0Rubk41cGFsUTI4Sm95N2VQcHZzVXNxb3pxbGViSVE1?= =?utf-8?B?UjVrSE5jak5sVXJFcnUwaTUrbzlta2JQOGRTNndhY1VDS2R0b0RuMEMyR092?= =?utf-8?B?ckdvamhZVkRNcW5ZcmhnbHNPVUNKUzJrdHhQSGo2SnhTSUFlR0hBNnRsdU9X?= =?utf-8?B?MUdGWEk1WnRyWkpucEN5Q3VvN1pVUFBnejZpbG8rdVNJVjJuUllUdis4bDNJ?= =?utf-8?B?VE51SDRINHpsaG5RaGtERHdma2E0Sk9MRnlidnpONVI3VVQrZXNGRy9DTDBD?= =?utf-8?B?SzJqamFYWHF1ZlJiY0Zra3pmemxSYmcxZTRZOStRR3AwNzhKWVRXQXJ5MWpE?= =?utf-8?B?OURZNkxhYjlYVk9DU2Q0Rm5hekxaM0hDWlZRNy9OU01zWGdzSytJcVQ5NDlI?= =?utf-8?B?aG1yNk1tYlpCMVJnUnhxVXNQMVVNbmNseEVhRHBtT0ZOZVpxaVNwb0ZQUkE2?= =?utf-8?B?YmNKOU9DTXB4SXdSQlF2aWNMelRlaVdSRS9KaDRXSXZPQUNkWUpCb1N5U3Fi?= =?utf-8?B?Nkt3RmJxdUxHOGlDMXdYRzVET1ViQ25rT1dJc0dFNnFGM2FoT0xnVThXMFpz?= =?utf-8?B?ajZEMEU0bUJCR1hsdWlNdUdKbTBxWWM2dUhzbS9IN2tGVEdQK3JxMmpBMkRV?= =?utf-8?B?SW96VWF2Vk5NSGNpOGp0ZTNiMFp4RDJDRGR1UFFORE9iUG1jcmdZSGEvMGZr?= =?utf-8?B?eXNqR0dUQmxRS1YxSGU4UkNOMTQ3SDR0SEsxNG9sSU9DTTBUTjU1MjA4NnhW?= =?utf-8?B?T0VzZGRjaFM3d1ZFREVmMmlUUU56VmtaTE5FYnNHMUU4YzYrRGNOYVN4OVhF?= =?utf-8?B?UndLRW5tSllMM0VtVnpFcldsK1diM0lTL3VicFhMSXlzRjhRRmhkODdpSmN0?= =?utf-8?B?SERxNVRYZ3NFcE5QSXg3Z0Qwa0JRclRkU1NkRGQzanpjM05nVnJKbWZ6ZW80?= =?utf-8?B?SnhWMjB2b1U4dEVmYWhkUUN4cmVIZis3a05xV1JiL3B0UFMzZ2JONyt5V3Av?= =?utf-8?B?eUIrODYzSzFvcVVXWG5URWRmdFA2bGJtcStVREZ4SXNtMzgrN3FCeWQvL2Q3?= =?utf-8?B?cTdseDZiWHQraW1hcWpzd3JBKzlDbStIRDljV2FlRTUxN0hKWUdveW9vUDhS?= =?utf-8?B?OCtFb1BzbUp4bXlIQ3ROdlRKcmx3bFFPMnRqUjlwVmxubWJMR1VYYWZKdk1E?= =?utf-8?B?d2d1WTVja2lnSWFFb296OXNleHAvOUtKVGRiTVo5OEZwdGFsbEduSzk4ZXdz?= =?utf-8?B?MTZrZXZOcTBucW5pR1lnOEh2NE9yRFNOekFnOFBxNUJUSkFTTUZpNndKRnpx?= =?utf-8?B?OE9ZL2MwTzZKcjQ2YnpXUDlVRUc2cVFtS1NER0tZYVBvWHRqTVpETTF4K2xy?= =?utf-8?B?RVRoK09wOEdHRFBQdlp3YVI0U25oNWFNb1FERGxyVTBxRGRLdnhJb2dOUHAz?= =?utf-8?B?L3JrZHo0YnB2Wnhvam9SRFhIRkpEOGR1YjVSRVY3eGh4UHJENU9lRWgxaEVE?= =?utf-8?B?b3FrK0VPNlZjV2c5eVV2bGl6Zzl2YnJGOWYwN0tJUHdhQmJNU2ovaTR6TFgv?= =?utf-8?B?U29EMnR5WDRtbFM3TE11bktyT0Q3STVHMm5yMElZY2hxTk54NWc4QT09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ca85143c-5ed0-46ec-7d2b-08d9b3216906 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2021 10:17:12.6105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C8d1+EiIjCknRnTR7zdu1eH6MOqG+tUN8kBH1wNx2+aMoJpANtCJj763rDjgBNzvYx+2zPXv/ZM3lHYCfBiS07XqFGSAU4gEnXcBIcFwHtY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0643 Archived-At: Subject: Re: [core] [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming 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, 29 Nov 2021 10:17:21 -0000 QXBhcnQgZnJvbSB0aGUgZGlzY3Vzc2lvbiB3aGV0aGVyIHRoZSAoY3VycmVudCkgaGllcmFyY2hp Y2FsIG5hbWluZyBjb252ZW50aW9uIGlzIHRvIGJlIHVzZWQsIG9yIGFueSBuYW1lcyB3aXRob3V0 IGhpZXJhcmNoeSAoYmVjYXVzZSBpdCBpcyBhbGxvd2VkIGZvciBydCksIHRoZXJlIGlzIGFuIGFk ZGl0aW9uYWwgY29uc2lkZXJhdGlvbiB0byBtYWtlLg0KDQpJZiBhIFBsZWRnZSB3YW50cyB0byB1 c2UgQ29BUCBkaXNjb3ZlcnkgdG8gZGlzY292ZXIgb25lIG9mIGEgQ29uc3RyYWluZWQgSm9pbiBQ cm94eSBvciBSZWdpc3RyYXIgb24gdGhlIGxpbmssIGJlY2F1c2UgdHlwaWNhbGx5IGl0IHdvdWxk IGJlIGFibGUgdG8gY29udGFjdCBib3RoIChEVExTIGNvbm5lY3Rpb24gJiBtZXNzYWdlcyBhcmUg aWRlbnRpY2FsKSwgaXQgd291bGQgaGVscCB2ZXJ5IG11Y2ggaWYgaXQgb25seSBoYXMgdG8gZG8g YSBzaW5nbGUgZGlzY292ZXJ5IGFjdGlvbiBmb3IgYm90aC4gQW5kIG5vdCAyIHNlcGFyYXRlIGRp c2NvdmVyeSBhY3Rpb25zLg0KDQpJZiB0aGUgUGxlZGdlIGRpc2NvdmVycyBmb3IgcmVzb3VyY2Vz IHdpdGggcnQ9YnJza2kqICwgdGhpcyBpcyB1c2VmdWwgYXMgaXQgd2lsbCBmaW5kIHJlc291cmNl ICJydD1icnNraSIgaW5kaWNhdGluZyBhIFJlZ2lzdHJhciBhbmQgYWxzbyByZXNvdXJjZXMgInJ0 PWJyc2tpLmpwIiBpbmRpY2F0aW5nIGEgQ29uc3RyYWluZWQgSm9pbiBQcm94eS4gSSBjYW4gcGlj ayBlaXRoZXIgb25lIGl0IGZpbmRzLiBJZiBib3RoIGFyZSBmb3VuZCBpdCBtYXkgcHJlZmVyIHRo ZSBSZWdpc3RyYXIgZGlyZWN0bHkgKHJ0PWJyc2tpKS4gDQoNCkluIG15IHZpZXcgdGhpcyBuYW1p bmcgY2hvaWNlIChicnNraS4qKSB0aHVzIG1ha2VzIHRoaW5ncyBtb3JlIGVmZmljaWVudCBhbmQg Y29uc2lzdGVudDsgaXQgaXMgbW9yZSB0aGFuIGp1c3QgYSBuYW1lLg0KDQpSZWdhcmRzDQpFc2tv DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitpZXRmQHNhbmRlbG1hbi5jYT4gDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI0LCAy MDIxIDE4OjQ5DQpUbzogRXNrbyBEaWprIDxlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+OyBj b3JlQGlldGYub3JnDQpDYzogU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbT47IGFu aW1hQGlldGYub3JnOyBQZXRlciB2YW4gZGVyIFN0b2sgPHN0b2tjb25zQGJiaG1haWwubmw+DQpT dWJqZWN0OiBSZTogW0FuaW1hXSBjaGVja2luZyBvbiBhZHZhbmNpbmcgZHJhZnQtaWV0Zi1hbmlt YS1jb25zdHJhaW5lZC1qb2luLXByb3h5IC8gJ3J0JyBuYW1pbmcNCg0KDQpFc2tvIERpamsgPGVz a28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubD4gd3JvdGU6DQogICAgPiBJIGNoZWNrZWQgdGhlIG5l dyB2ZXJzaW9uIGFnYWluc3QgbXkgcmV2aWV3IGNvbW1lbnRzOyBhbmQgdGhlIGZvbGxvd2luZw0K ICAgID4gY29tbWVudCBpcyBzdGlsbCBvcGVuIOKAkyB0aGlzIGlzIHdoZXJlIFBldGVyIGFuZCBt ZSBkaXNhZ3JlZS4NCg0KdW5kZXJzdG9vZC4NCkkgaGF2ZSBubyByZWFsIG9waW5pb24uDQoNCiAg ICA+IGNvcmUuKiAtIENvUkUgV0cgdHlwZXMNCiAgICA+IGFjZS4qIC0gQUNFIFdHIHR5cGVzDQog ICAgPiBicnNraS4qIC0gQU5JTUEgV0cgdHlwZXMgZm9yIEJSU0tJIOKAkyBub3QgeWV0IGluIHRo ZSByZWdpc3RyeSBidXQgc3BlY2lmaWVkIGluDQogICAgPiBkcmFmdC1jb25zdHJhaW5lZC12b3Vj aGVyLg0KICAgID4gb2ljLiogLSBhbnkgdHlwZXMgc3BlY2lmaWVkIGJ5IE9DRi9PSUMNCiAgICA+ IGZhLiogIC0gYW55IHR5cGVzIHNwZWNpZmllZCBieSBGYWlyaGFpciBBbGxpYW5jZQ0KDQogICAg PiBIZW5jZSBteSByZXF1ZXN0IHRvIGNvbXBseSB0byB0aGlzIGNvbnZlbnRpb24sIGhvd2V2ZXIg dW5kb2N1bWVudGVkIGl0DQogICAgPiBpcyB0b2RheS4gQW55IHN5c3RlbSBhcmNoaXRlY3Qgd291 bGQgYWdyZWUgdG8gdGhhdCBzZWVpbmcgdGhlIGN1cnJlbnQNCiAgICA+IGxpc3QuDQoNCkNhbiB3 ZSBhc2sgY29yZUAgdG8gcmV2aWV3IGFuZCBjb21tZW50IHRoZW4/DQoNCm9yaWdpbmFsIG1lc3Nh Z2U6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYW5pbWEvczl5VTZMUG5W OHBFMTdXczJ4akgyZjBtck8wLw0KDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRG QHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KIC09IElQdjYgSW9UIGNv bnN1bHRpbmcgPS0NCg0KDQoNCg== From nobody Mon Nov 29 08:15:51 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 B8D653A0BDE for ; Mon, 29 Nov 2021 08:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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=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 BfYzAtjdpT37 for ; Mon, 29 Nov 2021 08:15:43 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60061.outbound.protection.outlook.com [40.107.6.61]) (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 91A553A0BC1 for ; Mon, 29 Nov 2021 08:15:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WcsLsBVf3syA43v9CdFP9/MTrWqBggBh/DSQyLcry2kK1Wt4Wz7HuFB5+k+B0dQCJgl4tEyXqeKjurwL6+qPD5HyqeBa31RVvat/Sn3dSBk/FNJ1YzRykjfnBFJNxuMF5Mu1160D1viReAuyCGgiauFW9mMmA+MCTazxiC1vIus9IZ9Q43NvEu+H7r2OHCHqdT1+d9eJepW50H08u2W2P8VuXNQXF8F5+/6Docw02ixr6GcuNiZPeAK/anUwWE0fE2VNmxjhp33zJfJk37T4Xl6ExwVxvoVMnde10htpMQampzpVfGQHWRUGBNng2Hnn8tlQeSRewWvPvwAlUQZ3dg== 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=YmANg2Y07GOsDbZUo0cx/pi4T+2A3iASWrffH35I6Hc=; b=NGfcGAV4j7fXZ63OY1zF3rKU/lxSPAx8R12B0sxRq27WjqL94Q8mX/1VnQvSj5t8G2tNU3kK8mTtiSswcxwECbgV9nMlLJNMDCVmIkRCOJeKApx5cGMKAWHoJFNbShvLTCX01FuSGmEGakg6+TneerhfD/VUfsWAiHyXXLpQH9mo0wk7DQ+DMO3WkVTmzSAVVlmwG3XmJ8W/YnD1DFjKfSQgJvw0JQO1MG9H8VHfg/WW56SDQadt+Nbg+wSxxPGa6rIxFSZ4gcHUhNPuBlBLS5KvSd/63b0mbag9M7KWFtibKLMQkS7pXKYqdmRAEHkbwx2XyKF2xUc92AaAB+Uisg== 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=YmANg2Y07GOsDbZUo0cx/pi4T+2A3iASWrffH35I6Hc=; b=mHG5EwJ5+SN5L2LJcVFR0RuczRobABv4utOVzX60ovF2r3wcDM1RbBHRsiPzW60FDg7HIl4Jz8zEjqE1tWt4na6wU4hABszVoCLnToou1Vx/bH01CkLEe3TwhK9kWH8Yk0JK2hKlKHO+ldLRJUB9uRQPlYQd0BJwc93PUq8eLEE= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM0PR07MB3857.eurprd07.prod.outlook.com (2603:10a6:208:45::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.9; Mon, 29 Nov 2021 16:15:40 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::7dea:b76c:191:ec29]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::7dea:b76c:191:ec29%11]) with mapi id 15.20.4755.011; Mon, 29 Nov 2021 16:15:40 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "t2trg@irtf.org" CC: "core@ietf.org" Thread-Topic: New topic for T2TRG? Thread-Index: AQHX5TxaNY8Tkj4sdUS8+zuaOpzNdQ== Date: Mon, 29 Nov 2021 16:15:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ac0cca3-1e70-4438-60b7-08d9b3537cda x-ms-traffictypediagnostic: AM0PR07MB3857: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ihRLfsLXj9VP2LxW40BXNOvDdHtWGi+FDdcedWMKLECW75oaptW9hL6/wNT4C8isf0Kv0O20BvrRkwTKtsawD2GCHRof92RCNFxaOeHU3s9VlwEAddsF1LD5qwxuzV0jRnF1GNQaJmRxaMAoD6AOvt7IodxgAfnHMb0TkCtGcaz4EPVERmSJtwPDcCLMN3IJ8UmJ4PQXyiA6neCHFSQElj06HlumaVeINYeP8tM4CJ07wVN7Mt20FHWYsvkVOj5BbnurDeLG9VxtOdWCY3oXSkdx3zwMZVuOaz1PNNcCB/N1Uv3UUbP6RN26PB6bvZOhNQ9ZL8xylARsSjNTNtVPF5B6WcE4M9UcEEHWc9C0jqgNjIEO04ZnyuSm3/93oURW6MPYNUm44KZZCCocEwvZiF6Chphiyxcha6O85ls4movczby30M1MhsZrf+pTTIcX7/58OsEZbEk1i/ZcSmJQRd6nOl4Xo/IgdrKFSyNCQ6pC0ghN2IRQ9vKFzVARfS00ZyPzSycdrlnfjHBhhHAuf7kJq5OK9GYmdBu93YT1nLPX5SofQz3PtjmYxRi0ZlBTywNyB5Xjf+EEF/3cwzGkDvA/jsZ5Z1WV/3pDWhUVilxzQSRPNvpoWKDt5JA97pxaEwn8EVE9BML/cfYHzjHKo1KDErR8GCj94rT0sHd+vpTqVDB9olVoTbPIsghem7rX5AAOix+taZfoPbgvadEua67tWlsjbRewp1u39RRSHS4hDCyjbbHxSt3flR6Nu2a59KGonm2WeKAloPsEh2QFbIVkHgMzxI6W9CBJe8Ey2QWbh12Vr474vXnBpgNxjy1XUTKvMSrVY8yMYLkbqzb7Qw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(166002)(66574015)(66476007)(71200400001)(5660300002)(38100700002)(52536014)(66446008)(64756008)(66556008)(55016003)(122000001)(8936002)(4326008)(316002)(66946007)(76116006)(91956017)(83380400001)(86362001)(33656002)(53546011)(508600001)(7696005)(8676002)(6506007)(26005)(186003)(2906002)(9686003)(38070700005)(966005)(6916009)(82960400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Lk/nvhkCKXT+SMogJEAxCCrLnCkNgaSdZAxAkXrhXnuGIIb5TDeiC5edJ2?= =?iso-8859-1?Q?+K4jlPQxxaYjK9ucbXq2zNHDsnWKoMxjWA62L5KQw6xmHT2+lnIHH9fsod?= =?iso-8859-1?Q?6axckFXS9rsiEEofG9ii6D4YVauUVt/eARKMmwGXTnO0kaBnbfDcYcNoYY?= =?iso-8859-1?Q?9biuRvLzAH29IAx+5CuoDcMvOxfsHsmjMsJh/JMG4hRW6DWxHOO3ug8mLs?= =?iso-8859-1?Q?GufxpwyAxZmwLxw43tAhr8kxaUjkh/pBC5X+X60dNITrSuxffOXwetL38M?= =?iso-8859-1?Q?OducFOpQWymYQedewEgVO2zHbpRUvXETNkMB4/fIXclVajWqVuPc17cZgX?= =?iso-8859-1?Q?5iw/NupDtPzjkiMRzBlMQMQOtw3rIYeMZJx2euGuFZkMn2vaHBwNx5/a7Q?= =?iso-8859-1?Q?/WweJIHCD+AHSR9SoxaNtg/ezQFwzfYx0gFLq2rLfg+2KBRuviFv3pmp1A?= =?iso-8859-1?Q?mPQAWVQJJiCWSpFGoagvP2chkmCeZAw/Fvvi9GN27GSISdto0L5BrA2rJH?= =?iso-8859-1?Q?tetYyihq/OcWSVawI/LV8QbwfSU3j0H8USw4iT/iEuuFHUKzUBLQDMxkKY?= =?iso-8859-1?Q?h+XgmgQZWsr0UeqWIc1KTq2zTDX5WhER2PKVimgjpEBoUYJigeCwpTDl8D?= =?iso-8859-1?Q?cSY7BBGlcVQCESK7twTQzogec4kimGUKup1JOu9nKqlP3iKxU4p/Umh0Dr?= =?iso-8859-1?Q?j+MgeiiNVTM2fPO7qHjt/5GFrdKQ9549LdS/HAbOlT4et3ukEtXxvfeWqF?= =?iso-8859-1?Q?8kFOAQgCSMV6TKoD0O0KIhxTTKIjngshKVwVxJDZxtxvGWie/Rl97o0cgd?= =?iso-8859-1?Q?WzB4YmEb+ROlbVwys+5/ZkQurQydxhMzua7UPnRDLAq/QfNaYhk5V4X2j5?= =?iso-8859-1?Q?Bxo2pIQEDYtIlPohoRXQI87t1kRVCbJogz0w9kmmqBbLx/WyPjU0d0R0pW?= =?iso-8859-1?Q?hk++/NXaVtJSFXBOPeExsGyr0SYML3XV6zBQdYjOJpKg7OiNnaoyfYXUyM?= =?iso-8859-1?Q?Q8bHQAnnpH0iH5RlTM/AApTDsEpS0Te0CMmHrmuicNbfbOjTfkSwKtd/M6?= =?iso-8859-1?Q?DxXbkzlDXM6n82fbwj2mlKreBC9PZwAlJ8vO29L4weyQjyg/FVwdMsjLUX?= =?iso-8859-1?Q?6PBbpVA2y+tXKpC3QM8jToObRK8oJf+YSK6bQv1mOBI4k837JXlYPPd+nm?= =?iso-8859-1?Q?zvrvRkDkfH7t3BtR52ARZ6kS7+obW2Tzekcekax6NSrdl9VvsVrzSBdWDQ?= =?iso-8859-1?Q?zJuudTVrWNO4eMvYM1/9/OxYnXZ2/s+VOXVkvCcTS/Emhr5QlMinj39ZVq?= =?iso-8859-1?Q?Vwm3BjmJStKutcsqmvrYkt/VQiRRmhG0due7idT0PtcjHwPuO/eWCYG8Ch?= =?iso-8859-1?Q?zUnxDEgTu5drtoSPfNaMziLi4nnnMbUIy+eWodTGy4msdoZRY2o9UUgFHU?= =?iso-8859-1?Q?+GwB3DB+gjnpSWwemHmtqinGSh0uZ9qACCpT2zURfbf/MeFZ/m8uOHe0CE?= =?iso-8859-1?Q?oJwlG+7whEPY2D/pvTsZIAClJmBNlYTKbgyOCHNJqA8I7DgIPIXoSFhRvM?= =?iso-8859-1?Q?CG8ZECqLxarlIPWQ9HitV4WSo4rvgQvj5walba9iIy0SeAcain1fiMh+/h?= =?iso-8859-1?Q?FYVLaUq7ClmAWbB+RbTwAeMwdWuRjXacb46GFOWRGRh6tRSvw4OLSw26XB?= =?iso-8859-1?Q?4hYSF/w3wjCoCu3gxnFPcE+hRg16DRcMfVU2DjmhUvlnGwgq2BPXhP/kE+?= =?iso-8859-1?Q?IYy0iX1MmIgl5CbDDPiCzgwlo=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB21955D1AB35A1A335B5EFDD0F4669AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ac0cca3-1e70-4438-60b7-08d9b3537cda X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2021 16:15:40.6790 (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: 20HgJZUPe6vM6rxeTszkhKMw2jk9nMFQ3+3XIlPCCRiCHVFGTebdXdnXgr5RHmYl3HRW1i59puqZnACybQidCd4gZT6ANbrQu6MmXbyO5tQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3857 Archived-At: Subject: [core] New topic for T2TRG? 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, 29 Nov 2021 16:15:49 -0000 --_000_AM4PR0701MB21955D1AB35A1A335B5EFDD0F4669AM4PR0701MB2195_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear T2TRG, As reported from the CoRE applications side meeting below, there seems to b= e an interest in progressing topics in the area of security for constrained= RESTful environments, and a proposal to host that work in T2TRG. * What? CoAP can be used in various settings beyond simple REST. How do we adapt ex= isting security requirements and solutions to these new modes of operation?= Some work of this kind is already in progress in the IETF but some issues = go beyond the individual IETF WGs, or could benefit from additional contrib= utions from a wider audience, reviews and information sharing. Examples include: - Rekeying with PFS vs. stateless operations [2] - Firmware updates using group communication - Efficient and secure tunnelling of CoAP in CoAP - Notifications surviving rekeying - Progressing pub-sub with CoAP * Why? To progress applications of CoAP in different security settings which "touc= h standardization in the IETF" [1] but are not necessarily in scope of a si= ngle working group like CoRE, ACE, SUIT, COSE, LAKE, etc. * How? Through a "sister" of WISHI: A recurring meeting series under the T2TRG um= brella about topics on security for constrained RESTful environments. Worki= ng name: seccore (which apparently may mean "dryness" in some Italian conte= xt; not intended as a characterization of the content :-) Frequency and to= pics open for discussion. * Comments? What do people think? Should we try to have a first meeting before the upcoming holiday season? G=F6ran [1] Thing-to-Thing (t2trg) - (ietf.org) [2] [core] KUDOS, PFS and operations considerations (ietf.org) From: core on behalf of Christian Ams=FCss Date: Tuesday, 16 November 2021 at 15:57 To: core@ietf.org Subject: Re: [core] CoRE applications side meetings (pubsub / dynlink)? Hello, On Tue, Nov 09, 2021 at 05:17:39PM +0100, Christian Ams=FCss wrote: > based on the feedback that arrived, a small group will meet tomorrow > (Thursday) 10:00 UTC in the hackathon area to look through some > applications (pubsub, problem-details), possibly doing examples or check > out how things align with current CoRAL. the small group was not all that small and very lively -- thanks everyone for participating! I've attached the minutes here in case the pad we used[1] goes away. While we figure out how to best make more of the CoRE ecosystem publicly visible at coap.technology, we can already start collecting material at the wiki[2]. Best regards Christian [1]: https://notes.ietf.org/GaM_PWd2TnmY0DrTe6DdQA?view [2]: https://protect2.fireeye.com/v1/url?k=3Df4bbca08-ab20f04d-f4bb8a93-867= b36d1634c-1b783ca428431080&q=3D1&e=3Da3621d21-f226-4875-acd7-faaf5c694f88&u= =3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fwiki%2Fwiki -- To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --_000_AM4PR0701MB21955D1AB35A1A335B5EFDD0F4669AM4PR0701MB2195_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear T2TRG,

 

As reported from the CoRE applications side meeting below, there seem= s to be an interest in progressing topics in the area of security for const= rained RESTful environments, and a proposal to host that work in T2TRG.

 

* What?

 

CoAP can be<= span style=3D"mso-fareast-language:EN-US"> used in various settings beyond = simple REST. How do we adapt existing = security requirements and solutions to these new modes of operation? Some w= ork of this kind is already in progres= s in the IETF but some issues go beyond = the individual IETF WGs, or could benefit from additional contributions from a wider audience, reviews and information sharing.

Examples include:

- Rekeying with PFS vs. statele= ss operations [2]

- Firmware updates using group communication

- Efficient and secure tunnelling of CoAP in CoAP

- Notifications surviving rekeying

- Progressing pub-sub with CoAP

&nbs= p;

&nbs= p;

&nbs= p;

* Why?

 

To progress applications of CoAP in different security settings which= "touch standardization in the IETF" [1] but are not necessarily = in scope of a single working group like CoRE, ACE, SUIT, COSE, LAKE, etc.

 

&nbs= p;

* How?

&nbs= p;

Through a "sister" of WISHI:  A recurring meeting seri= es under the T2TRG umbrella about topics on security for constrained RESTfu= l environments. Working name: seccore (which apparently may mean "dryness" in some Italian context; not intended as a ch= aracterization of the content :-)  Frequency and topics open for discu= ssion.

 

 

* Comments?

 

What do people think?

 

Should we try to have a first meeting before the upcoming holiday sea= son?

 

 

G=F6ran

&nbs= p;

[1] Thing-to-Thing (= t2trg) - (ietf.org)

[2] [core] KUDOS, PFS and operations considerations (ietf.org)

&nbs= p;

&nbs= p;

&nbs= p;

From: core <core-bounc= es@ietf.org> on behalf of Christian Ams=FCss <christian@amsuess.com&g= t;
Date: Tuesday, 16 November 2021 at 15:57
To: core@ietf.org <core@ietf.org>
Subject: Re: [core] CoRE applications side meetings (pubsub / dynlin= k)?

Hello,

On Tue, Nov 09, 2021 at 05:17:39PM +0100, Christian Ams=FCss wrote:
> based on the feedback that arrived, a small group will meet tomorrow > (Thursday) 10:00 UTC in the hackathon area to look through some
> applications (pubsub, problem-details), possibly doing examples or che= ck
> out how things align with current CoRAL.

the small group was not all that small and very lively -- thanks
everyone for participating!

I've attached the minutes here in case the pad we used[1] goes away.

While we figure out how to best make more of the CoRE ecosystem publicly visible at coap.technology, we can already start collecting material at
the wiki[2].

Best regards
Christian

[1]: https:/= /notes.ietf.org/GaM_PWd2TnmY0DrTe6DdQA?view
[2]: https://protect2.fireeye.com/v1/url?k=3Df4bbca08-ab20f04d-f4bb8a93-867b36d1= 634c-1b783ca428431080&q=3D1&e=3Da3621d21-f226-4875-acd7-faaf5c694f8= 8&u=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fwiki%2Fwiki

--
To use raw power is to make yourself infinitely vulnerable to greater power= s.
  -- Bene Gesserit axiom

--_000_AM4PR0701MB21955D1AB35A1A335B5EFDD0F4669AM4PR0701MB2195_-- From nobody Mon Nov 29 14:29: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 630D23A0ACD for ; Mon, 29 Nov 2021 14:29:20 -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 fmvKBXe_TFme for ; Mon, 29 Nov 2021 14:29:15 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10057.outbound.protection.outlook.com [40.107.1.57]) (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 0798D3A0745 for ; Mon, 29 Nov 2021 14:29:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NNiOAGegrpa7kQhbj+T3Yxefnt5Ad0ihClzd828ItomTwv75WaQKaMBuPGmB2QN8uj09afY4VCH96l+n1driS9Zh9dzVUjBKYxZd7VaGnbKsrNjL+DEVsSUojm7Mzu10pCNfhp5FuGzQ+ODKPJQlQ/4+dQoTAQOtxxGXPTo44VttFurckJFVc0raB5PsgPbUVB13qHyRAI/Iv9Ko4I2aQryBdEntFoTAyVMtG+UOYH5wTA6MqCrWyqKg8gsISi7cu7tPivS9Ho4hRl4PsGevO40cd4C6KPitkUZ0giRnvbh5GYKpdGHGJZyHY8Y8qLRwjVlO8QGn7YPaGaRPaXAj4Q== 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=pYFWA5e8h3LpxsM9y7intZ3S1M1d50AMSlERQH3XvRY=; b=SGYI9IKUBel+cE8UifNy6Mlfo1XhIq23PbtoqiXQtrAeNi221Y/X6MR3KvXAXFP3rDvEJqMuTD9Om7eQT3Ws68cucFotYsP7VWkXE5xoRMivx5D2FZVU/OWzhzXdv7cd0x7jwTEQFyAi6RpgZz89rwjOYjQ3wh9KR3qUEkbT5UmeM0+7yVSyYCKs9nrJYLy0aWhfXNGcuWPoRcR9tzoWp5S6jnwr1Zom5sA1Q2dTHHas50eA5/YhxkLxJNofWt6PfcFtylhBIXCDHqgYMQjc6bMjdBZmPW/zqtReN3NMm/bg+ggoPYJ5PPz9HnsdZDKPzatN64YATLpTw2WOO/DwwA== 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=pYFWA5e8h3LpxsM9y7intZ3S1M1d50AMSlERQH3XvRY=; b=aiEbDJru+r8c5gynyXvRvSxbr6dz95cw119QjTL0lspYXIJhPYscNNx947bzzvOk5aD+lu33XMvqEOwKA1nMQq5K/MeX19m9ohPSylAU8ZhlsfNKpzCvZS795O0QVCj0MYqb0nu/uxXzVQf9pDhXBs52kCdXlmG22n7IQpzp/14= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1689.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:26e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.22; Mon, 29 Nov 2021 22:29:06 +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.4734.024; Mon, 29 Nov 2021 22:29:06 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <3a21a3a2-720c-41d1-1258-9f1eb89be623@ri.se> Date: Mon, 29 Nov 2021 23:29:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HyL2tZmYf1cVVaJVWwnuGIpXDJWH5Cmo6" X-ClientProxiedBy: GV3P280CA0102.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:8::27) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.1.3] (185.219.140.213) by GV3P280CA0102.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:8::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20 via Frontend Transport; Mon, 29 Nov 2021 22:29:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c383f75-b37e-41df-3063-08d9b387a78b X-MS-TrafficTypeDiagnostic: DB9P189MB1689: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6O/MHOnHRMa229oq2YgGccPQOhw2+L0bAHJkAkxcJo+67BmhZ9fJxcrNcLHOflbDxKB0AlHzDTPXNCaMXy7X/d9ls7YdXSTNZR2voQ/JTmxZLUSrm1L8H/jPp565GgAUrB9VfxcLuTtA6BGMZhDEcC2UcF+xVmJJoWsqlp+BJ1Hz/lk2aPPj9uIeK2FINEqtcdp1FhlCF4F9YW692QFiEi91JAcRCEdokstR88jlN6zo3OL2nSkC9LF8weV1aJC4doV9R3hAtNzVI8zGba3EdqZM19lU52/Tfeehoc1ejCG3pNdPU8yPEUz40Jo42MA3PoRJN2KXNADNPMelA6MenGxPYxvO0RcP/AgLXMklV/nyhXNsH1OWXKC6DXYS4BapkWnk0UYuw6r41gjlLx09qNW4eKAzMTdbm8wrE/GgUarCBkUl/bNwwAezh22Y7CwEPj5nCVbwDizrfcYxDd7Qi/0hXnNrIcU//J37GMHBqgyJVwT1CpiBSTbshB7zheZC6BEVvBBPDRYVNoR7PhH7V+uCkxkbrdV8VfNfO6Y8KAf8srojNNqFUaPTEYd9ZnmInuJkwRsj52y7UoioUEwgmX2VdeK/gySJZcRt48TppJ4J2xta/ChICgRg6KwAd9cwsMPQPGa+NqUBPwlYpF0MVOtGKxLnOzR6YYQD7b6IY9EqYOGAieZQC7gonzVh3ofDk0l3kt50j1Flnmmz5U2dbLZbpC4VWGj7Bbdwd34v7fLGagkFJdQ9ydJFWfU0BrwTxNLNjMcq7wqsghLfDpm/NY00lST7+JizkrnUiAU1ZX3SMwvumZ5N5SrgwiwtHbNe 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)(8676002)(66946007)(66556008)(5660300002)(66574015)(31696002)(316002)(38100700002)(21480400003)(83380400001)(186003)(31686004)(235185007)(36756003)(2906002)(86362001)(6486002)(26005)(33964004)(966005)(956004)(16576012)(44832011)(8936002)(6916009)(66476007)(508600001)(2616005)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d2FUT3haWm5UV0VEUDc0Z1JoTXVqM2g3ZUJkZmtPTFd0UDlYL1BRSmtybVRj?= =?utf-8?B?Z1oxRFV0dVJIRVBDS0FnbGxoZWZudi91eEp1S0Vvb05ldU9qcnBTbS9xWkhz?= =?utf-8?B?NGpRam1SOGVlN3dkS1B5MExrbDhkQlNSYU1OaUtoTFpwWW91eWtBWVBGWkw5?= =?utf-8?B?dDlzdk9iV3BsSVMvMkxTQlNRMWxtb0NCY1JrR0V5dGdlMll3QUNBZEw5UUhC?= =?utf-8?B?cFIyaExONS8wcjhMSk83cTRUckNSUHlWY2piZEU2SW0reElxQlMwcUxUZzdQ?= =?utf-8?B?eG5QakdCQUdoYXc2SCsvSlU5b3hCVjk4a2dVb3c2U3J0N2V5eXY5a3haRU9S?= =?utf-8?B?N1NVby9PYjF5bk5mRmNEbHB1L1JSN3k2dFVHNHpIM2ZLVlRMR3JRSE1mSEZp?= =?utf-8?B?cEMyK29XcnJWYVY5QXpFVDFOdWFoOExmb3Byb0xOM0tIZFhGZ2VVUTBENFpX?= =?utf-8?B?MWJ1bDI0VTl5Q2JGRWJBN0tmZlpLbEZ6alhxZnplR0dtUjRvTHh2YmVscGti?= =?utf-8?B?RTltck1wYUtrV3N1UzdFcmFVaVhRV3huV0NxV1hmZlB4QXd2QTNtN0pQQmcy?= =?utf-8?B?RHJkbU9vbG54MkpBMEFSY2pCckFxWDNTOU9LcXJqK05kVmFFOVhweGtZNFow?= =?utf-8?B?MDgwVWVpRWYveVNRWW9WeWpidGN0VzF3TEZIVlcrQjJjaW1zTGhSWTZSN3pL?= =?utf-8?B?eDVGb3RyK0krM0lrNU9tUmhjcDRkZkpiSzJWcThxeERoSXo2c21YVWlPWW5P?= =?utf-8?B?SEc5MDM5OWNwRTZQWnFEK0FqcnVvVnBIMXdnSlhLUVRVNDZMMC9PTmNwTlA0?= =?utf-8?B?TEFTSXNyWXBQVVI4djdubUtIeWFDb1ZGUmdta3N6T2RoeU5iOVY1UXFnb2dk?= =?utf-8?B?TTNoc1A2dXZRUCtTMmUvQUtlSS9BZTZMQ0RpalhHUGZnTklIWDJyYVZWV1dk?= =?utf-8?B?RStTQWtyWkQxdGZMcURvaWFodlZiVk9ldzVrbWU2bTdwaGZHcmIrOXV6Z0JL?= =?utf-8?B?cUdTZGZsTVJhT2h3WmFBRHRZdTN3bTBXQ2JHdjhHUDdvT0ViS2Zucmw4WGEy?= =?utf-8?B?SVdFM3hzOXdCaDZCT1lqWnByN2kydzVMTFFNUUhwL2FBL3lDbmwyTWROK2xm?= =?utf-8?B?Rjh0MFJDUndIN2ZUd3lpQzlSUzhmZVBJR3VXYmthQ3oyOHhVdG43b3M1Rkc5?= =?utf-8?B?VHlDWDBrTUFIamJ5Q0VmdzV5bWtleXZOdVpubGJhYUxBRmNyY2t1Q2RYc2lD?= =?utf-8?B?TDgvaStDTHVMR2xOOHBpRmNmK0FGVUQrMTlPWWxTWlRtaVFuc0EwaTBlSk1v?= =?utf-8?B?SmZKNTVCeXh6ekRHN28xVldCeE9FT0ZrdkcvczFZa25sUkRCTFZOYW1Qamlq?= =?utf-8?B?bnRXc0U2MmZncDlob2dkYnorQUEvUVBKdm9kYWV2cDRSakpJTWtkTEhmdU95?= =?utf-8?B?MmU3MGtGRXBoZW1rTVRNQzBBUGJPbVJWT2lxby94a3VVa0NUK3MrVFYvbkhO?= =?utf-8?B?TDVtd09udjJob0tZZ25QTjZsOXd2MWdpeGZ4eC9HYm54MzdaYlAwN1NSUDh0?= =?utf-8?B?ME5WeTVHalJrMmVLc1M4WkwrQW1JRGpSUWh3WHVhN2tydmplSXVtbFhFWkN0?= =?utf-8?B?aW9PWlJWU2R6bEh0clBUV1htV2dDbGFINEQ5VzNjd0xvdHFBUldRU1kzNUFW?= =?utf-8?B?RkVwT2lDeTVEVURnYzdOc1MxZkxxKytTekQ2VDNQRThjTDNBbFBxbzdEZVVa?= =?utf-8?B?aUpCZDVWQ2hmZU9PMGZ5dklzUTRWbzJDdVNMQXdycGRjQzY3UExLNFIzVVk0?= =?utf-8?B?VE1GL2NMTEQrSVEzQXRNU3ZFTTlyWkE1VGtMUjhaQzBKZmFOWDFWY2Z5UkZi?= =?utf-8?B?MTFkVnRPV0hydTh5U0N6YW4wVjBIRE51SEJ3VzJ2TW5ialFVekdiU0h0YzBN?= =?utf-8?B?ZWFLYVNCSkgyajJJYThSRm1Oc0lKV21uSHRWZ3JXQUJiUWsrUm41U29kYkpq?= =?utf-8?B?TlBiM2Z0cElTWmZnbjFSQU8wRG96YVFJRStZbWtxb21QTFRxRHFJZmVRaElG?= =?utf-8?B?WURMQ3ZmUEVMTm9uM1l0b1Yvb2NPa0hOVndHbTR3SElnRFpxUi85b3dyTVM1?= =?utf-8?B?b2lmczVGd3NqcEs1bTgrK3J1Ky96WGoyYXlTWnpvZlY1L2MyOFdWK0FRei9W?= =?utf-8?Q?iSBfUqMTzUesWB3UU9e8Ea4=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 8c383f75-b37e-41df-3063-08d9b387a78b X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2021 22:29:06.4072 (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: tq2Mmaxaq2n9JAbPhkEd8lc/Y6uu9qxG+v26dKnUYlQuUHLwiZAvz5UwoQO7qPYrKUe69bhdgg6D3ACJduz5bw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1689 Archived-At: Subject: [core] Review of draft-amsuess-core-transport-indication-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: Mon, 29 Nov 2021 22:29:21 -0000 --HyL2tZmYf1cVVaJVWwnuGIpXDJWH5Cmo6 Content-Type: multipart/mixed; boundary="oBaIfpr5o1KA7aFoBW2UpG6MKH5sbBY63"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <3a21a3a2-720c-41d1-1258-9f1eb89be623@ri.se> Subject: Review of draft-amsuess-core-transport-indication-02 --oBaIfpr5o1KA7aFoBW2UpG6MKH5sbBY63 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, As promised, please find below a review of this draft. Best, /Marco ----------------------- [Abstract] * "unify these addresses" =C2=A0=C2=A0 Perhaps you mean "unify the coexisting use of their corresp= onding=20 addresses" ? * "This document provides terminology" =C2=A0=C2=A0 Yes, but it provides also enforceable means/approaches, rig= ht? :-)=20 (what Section 1.2 refers to as "provisions") [Section 1.1] * Please, add the usual disclaimer "Readers are expected to be familiar=20 with ..." * I wonder if the last paragraph about the Proxy-Uri option fits better=20 when defining the "same-host proxy" above. That's when I was wondering=20 about Proxy-Uri as an alternative, just to find it discussed later on. [Section 1.2] * Considering the given explanation, perhaps "No Aliasing" should be "No = unintended aliasing" ? * "This document will not concern itself with changes in transport=20 availability over time ..." =C2=A0=C2=A0 Sure, but are the building blocks defined here in principle= usable=20 for that purpose? Something along these lines is suggested at the end of = the paragraph. [Section 2] * On the mechanics in the first paragraph: =C2=A0=C2=A0 - Should the device just carry on and do the same thing if = it=20 strangely receives a CoAP-over-X request including Proxy-Scheme:X and=20 where it recognizes its name in Uri-Host? =C2=A0=C2=A0 - It can help to expand about returning 5.05, which is the = case=20 unless the device is also a forward-proxy other than a same-host proxy. [Section 2.3] * "Links to proxies may be annotated with additional metadata ..." =C2=A0=C2=A0 Simply by using (new) target attributes or are there possib= le=20 different means? [Section 3] * Perhaps introduce the device name device0815.example.com before the=20 example begins? * In the last paragraph, at least some of the text starting from "A=20 simplistic client ..." seems to actually refer to the example shown in=20 Figure 3 of Section 4. [Appendix B] * About the OSCORE interaction point: when mentioning the "Section=20 4.1.3.2 requirements" of RFC 8613, does it specifically refer to the=20 omission of Uri-Host and Uri-Port? Would it still be possible to use=20 OSCORE while taking advantage of a "has-proxy" relation? [Nits] * Section 1, s/indepenent/independent * Section 1.1 --- s/many application/many applications --- s/contentuous/contentious * Section 2, s/is can be used/can be used * Section 2.1 --- s/it may also/the server may also --- s/unless they contain/unless that contains * Section 2.3, s/renew their justification/to renew its justification * Section 3 --- s/the latter see/for the latter see --- s/interchangable/interchangeable --- s/one one hand/on one hand * Section 6.1 --- s/distrinction/distinction --- s/accomodate/accommodate * Section 6.3, s/In figure Figure/In Figure * Section 6.4, s/indepependently/independently * Section 7.2, s/would attackers/would allow attackers * Appendix B, s/correctnes/correctness --=20 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=C3=A5ngen 16 SE-164 40 Kista (Sweden) --oBaIfpr5o1KA7aFoBW2UpG6MKH5sbBY63-- --HyL2tZmYf1cVVaJVWwnuGIpXDJWH5Cmo6 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmGlVDAFAwAAAAAACgkQ7iZktA5Y2kPE Hgf+PUHQc31Z8UwYlrOMabcSWw47Ld6Hvo8A5gfLAKmhmMfhku4ryJb7cWko5c6BMe+bYU/ALRFP irMa6ztUcMXOioz4dcgBXMdYH1VjX01S1RRE8H7Qn062IQnEMqUUy15TzwiJyGRsqgMHAdNMm0IK IEHuCReNcA1+9e4DptOC5XQYA5bnemCaoZXklod0RNYdnYMOMucLOQrOt7MNNW9LrlBs44o7FNZU 2AqlWE7aj5cTKZPSDhGcA1LHkRIqkR0CP+B3z3XVbriHEdMpTPRHaNWw57RR19xb7JejgRtIcQaa O3HCeKUZQaJhrJ2GLu5RtGYjeJZp6jdWW8bVqcj2Ig== =Tl6f -----END PGP SIGNATURE----- --HyL2tZmYf1cVVaJVWwnuGIpXDJWH5Cmo6-- From nobody Tue Nov 30 01:13:05 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 EBEA93A11B2 for ; Tue, 30 Nov 2021 01:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 B5JY3scGmqAD for ; Tue, 30 Nov 2021 01:12:50 -0800 (PST) Received: from forward2-smtp.messagingengine.com (forward2-smtp.messagingengine.com [66.111.4.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B253A119E for ; Tue, 30 Nov 2021 01:12:49 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.nyi.internal (Postfix) with ESMTP id 6986A194088B; Tue, 30 Nov 2021 04:12:48 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute6.internal (MEProxy); Tue, 30 Nov 2021 04:12:48 -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=fm1; bh=x6nC40093K33IcxYNX4UbVm2xoI09zJynRJUd6Djf JU=; b=gvtEw+Wd0VFI9JFI0Rs/3PcluEooMd1q/Z/7H8ukVjR9ijWxZkpeYuyTf Z+Lb6VopuVQfYHna5DVvVTVjxVYCdRTpWhwjJppkochCziBOaoSx/3qr17EbEHWZ RBmB22WL0iaFTSxjrtBSe7fm00lqiTPSzWEngOCAuv8KmgeBKZ7SE8rfzRyE7XRL LXFLP38e/12N5tzobXrkbXjJBS4cCOojjAXgW2iNSNiLlfZNXNWODU92k3xuJjkB tb6OZ+cpkd4ifSYrMAKs/LzkZoaAl2GCbAHGpvl+XeY06DS+DsX7TcdR0qt11Ul8 P/1m/N5sUeEOFRMERpTZw1Vyamefw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddriedugddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomheplfgrihhm vggplfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnh epleduieffieduteetudeutdduhfekffefudefueeggedvtedvffevudduheelkeeknecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvg esihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D4B3A24A0077; Tue, 30 Nov 2021 04:12:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4410-g5528bb82a8-fm-20211130.003-g5528bb82 Mime-Version: 1.0 Message-Id: <478aabff-d2c4-45e1-bae1-aaa08688a632@www.fastmail.com> In-Reply-To: References: <97d7f098-ff89-4dae-a9dd-be09225553aa@www.fastmail.com> Date: Tue, 30 Nov 2021 11:11:56 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "core@ietf.org," Cc: =?UTF-8?Q?Christian_Ams=C3=BCss?= , "John Mattsson" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirming_adoption_of_draft-hoegl?= =?utf-8?q?und-core-oscore-key-limits-02_as_a_CoRE_WG_document?= 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, 30 Nov 2021 09:13:04 -0000 Dear all, we are a week past the confirmation deadline, hearing no-one against the= adoption and given the existing support I think it is time to adopt thi= s document. The authors are recommended to create a repository "oscore-key-limits" i= n the core-wg GitHub.=20 Thank you! --=20 Jaime Jim=C3=A9nez On Mon, Nov 15, 2021, at 4:30 PM, Christian Ams=C3=BCss wrote: > Hello John, KUDOS authors, > > On Mon, Nov 15, 2021 at 10:22:46AM +0000, John Mattsson wrote: >> I think it would be good to discuss if the KUDOS rekeying mechanism >> should/could be used to also update the identifiers. KUDOS resets the >> sequence numbers. I have not thought about this in any detail or that >> it is something we should do, I just suggest that we discuss it. > > The two are related but at different layers; any solution combining th= em > would need to operate on both. (KUDOS sending unprotected nonces, new > KIDs would need to be negotiated in encrypted data). > > It may help to see them independent initially: > > * KUDOS allows using new key material from a preexisting context, with > sequence numbers starting at 0 again, but keeps the same KIDs. > > * KID switchovers could be announced using inner options -- "Please > address me as ${my_new_sender_ID} henceforth". > > Keeping the master key, whoever changes their KID needs to be aware = of > all KIDs previously used on that shared context. In particular, the = ID > needs to stay unused until the peer has acknowledged (eg. by using t= he > new ID) that it didn't try to switch to that ID at the same time. > > The requirement to know history (lest a sender key get drived a second > time) is what makes KID changes convenient to do at KUDOS time (when t= he > list of previously used KIDs is empty again). > > BR > c > > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom > > Attachments: > * signature.asc From nobody Tue Nov 30 02:22: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 5763C3A1011; Tue, 30 Nov 2021 02:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2r_fhaN1ZgM; Tue, 30 Nov 2021 02:21:55 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA563A100B; Tue, 30 Nov 2021 02:21:54 -0800 (PST) Received: from omf12.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 091F310208437; Tue, 30 Nov 2021 10:21:52 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf12.hostedemail.com (Postfix) with ESMTPA id 665868019044; Tue, 30 Nov 2021 10:21:48 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 30 Nov 2021 11:21:51 +0100 From: Peter van der Stok To: Esko Dijk Cc: Michael Richardson , core@ietf.org, anima@ietf.org Reply-To: stokcons@bbhmail.nl Mail-Reply-To: stokcons@bbhmail.nl In-Reply-To: References: <80674.1637776136@dooku> Message-ID: <5259f69ffb5d08891bca1de956625a27@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy Content-Type: multipart/alternative; boundary="=_0e0a1d66b670ec54960c5031e1081549" X-Stat-Signature: 3kxuaouyoi35gk9x9y6yqmgo33ga3ais X-Rspamd-Server: rspamout02 X-Rspamd-Queue-Id: 665868019044 X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Session-ID: U2FsdGVkX1/5IRKx2g4S1JJub/blW9fb24S/pf3s5Mw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:cc:subject:reply-to:in-reply-to:references:message-id:content-type; s=key; bh=IAqoEN3emV2wryzQ346LB8HE1R/cSdghwkOBKWuzJkg=; b=if/hmffoiClbZT3Frsqb3A/eptv9CUGWYnmeg9jMuhcDU3rRSR0njVOmWg4+OkegXsgeu/6f7TNxHJJ+vN47Un0GprL+CQhWDhiKOJhfMnqVXwKCDHuwmqY4Duj611hXiBemPRBvMxRy/elSN2mvGAt46LLo/eBI41yJEht8tps= X-HE-Tag: 1638267708-247684 Archived-At: Subject: Re: [core] [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming 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, 30 Nov 2021 10:22:03 -0000 --=_0e0a1d66b670ec54960c5031e1081549 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed HI Esko, The PR of MCR has been applied to main, meaning that we now use the rt-values brski.jp and brski.rjp. Greetings, Peter Esko Dijk schreef op 2021-11-29 11:17: > Apart from the discussion whether the (current) hierarchical naming > convention is to be used, or any names without hierarchy (because it is > allowed for rt), there is an additional consideration to make. > > If a Pledge wants to use CoAP discovery to discover one of a > Constrained Join Proxy or Registrar on the link, because typically it > would be able to contact both (DTLS connection & messages are > identical), it would help very much if it only has to do a single > discovery action for both. And not 2 separate discovery actions. > > If the Pledge discovers for resources with rt=brski* , this is useful > as it will find resource "rt=brski" indicating a Registrar and also > resources "rt=brski.jp" indicating a Constrained Join Proxy. I can pick > either one it finds. If both are found it may prefer the Registrar > directly (rt=brski). > > In my view this naming choice (brski.*) thus makes things more > efficient and consistent; it is more than just a name. > > Regards > Esko > > -----Original Message----- > From: Michael Richardson > Sent: Wednesday, November 24, 2021 18:49 > To: Esko Dijk ; core@ietf.org > Cc: Sheng Jiang ; anima@ietf.org; Peter van der > Stok > Subject: Re: [Anima] checking on advancing > draft-ietf-anima-constrained-join-proxy / 'rt' naming > > Esko Dijk wrote: >> I checked the new version against my review comments; and the >> following >> comment is still open - this is where Peter and me disagree. > > understood. > I have no real opinion. > >> core.* - CoRE WG types >> ace.* - ACE WG types >> brski.* - ANIMA WG types for BRSKI - not yet in the registry but >> specified in >> draft-constrained-voucher. >> oic.* - any types specified by OCF/OIC >> fa.* - any types specified by Fairhair Alliance > >> Hence my request to comply to this convention, however undocumented it >> is today. Any system architect would agree to that seeing the current >> list. > > Can we ask core@ to review and comment then? > > original message: > https://mailarchive.ietf.org/arch/msg/anima/s9yU6LPnV8pE17Ws2xjH2f0mrO0/ > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --=_0e0a1d66b670ec54960c5031e1081549 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Esko,

The PR of MCR has been applied to main,
meaning th= at we now use the rt-values brski.jp and brski.rjp.

Greetings,
Peter

Esko Dijk schreef op 2021-11-29 11:17:

= Apart from the discussion whether the (current) hierarchical naming convent= ion is to be used, or any names without hierarchy (because it is allowed fo= r rt), there is an additional consideration to make.

If a Pledge= wants to use CoAP discovery to discover one of a Constrained Join Proxy or= Registrar on the link, because typically it would be able to contact both = (DTLS connection & messages are identical), it would help very much if = it only has to do a single discovery action for both. And not 2 separate di= scovery actions.

If the Pledge discovers for resources with rt= =3Dbrski* , this is useful as it will find resource "rt=3Dbrski" indicating= a Registrar and also resources "rt=3Dbrski.jp" indicating a Constrained Jo= in Proxy. I can pick either one it finds. If both are found it may prefer t= he Registrar directly (rt=3Dbrski).

In my view this naming choi= ce (brski.*) thus makes things more efficient and consistent; it is more th= an just a name.

Regards
Esko

-----Original Messa= ge-----
From: Michael Richardson <mcr+ietf@sandelman.ca>
Sent: Wednesday, November 24, 2= 021 18:49
To: Esko Dijk <esko.dijk@iotconsultancy.nl>; core@ietf.org
Cc: Sheng Jiang <jiangsheng@huawei.com>; anima@ietf.org; Peter van der Stok <stokcons@bbhmail.nl>
Subject: Re: [Anima] checking on a= dvancing draft-ietf-anima-constrained-join-proxy / 'rt' naming

<= br />Esko Dijk <esko.dijk= @iotconsultancy.nl> wrote:
    > I check= ed the new version against my review comments; and the following
 = ;   > comment is still open – this is where Peter a= nd me disagree.

understood.
I have no real opinion.
    > core.* - CoRE WG types
  &n= bsp; > ace.* - ACE WG types
    > brski= =2E* - ANIMA WG types for BRSKI – not yet in the registry but specifi= ed in
    > draft-constrained-voucher.
&nb= sp;   > oic.* - any types specified by OCF/OIC
 = ;   > fa.*  - any types specified by Fairhair Allian= ce

    > Hence my request to comply to th= is convention, however undocumented it
    > is= today. Any system architect would agree to that seeing the current
&n= bsp;   > list.

Can we ask core@ to review and = comment then?

original message: https://mailarchive.ietf.org/arch/msg/anima/s9yU6L= PnV8pE17Ws2xjH2f0mrO0/


--
Michael Richardson <= mcr+IETF@sandelman.ca>, San= delman Software Works
 -=3D IPv6 IoT consulting =3D-

<= br />
_______________________________________________
Anima maili= ng list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--=_0e0a1d66b670ec54960c5031e1081549--